Part 2: PostgreSQL이 개발자들에게 최고가 되기까지의 놀라운 여정
Tom Kincaid | 2025년 10월 19일
올해 8월, 저는 PostgreSQL이 개발자들에게 최고가 되기까지의 놀라운 여정이라는 제목의 블로그를 게시했습니다. 이 블로그는 Stack Overflow의 연례 개발자 설문조사 결과에 따라 Postgres가 어떻게 ‘가장 많이 사용되고, 가장 사랑받으며, 가장 원하는’ 데이터베이스가 되었는지 보여주었습니다.
저는 그 블로그에서 이 시리즈를 2부작으로 만들고 싶다고 말했습니다. 하지만 조금 더 생각해 본 후, 3부작 시리즈로 만들기로 결정했습니다. 시리즈는 다음과 같이 구성됩니다.
- Part 1: 앞서 언급한 블로그 – Stack Overflow 설문조사에 따라 Postgres가 개발자들에게 가장 사랑받고, 가장 원하며, 가장 많이 사용되는 데이터베이스가 되었다는 ‘사실’에 관한 내용입니다.
- Part 2: 90년대 중후반, MySQL이 압도적인 1위를 차지하던 초창기에 Postgres가 어떻게 ‘아주 먼 2위’ 자리에서 살아남을 수 있었는지에 대한 이유입니다. (바로 지금 읽고 계신 블로그입니다.)
- Part 3: Postgres가 어떻게 최고의 자리를 차지하게 되었는지에 대한 방법입니다. 이번에는 언제 이 블로그가 나올지 예측하는 실수를 저지르지 않겠습니다.
자, 그럼 이제 오픈소스 관계형 데이터베이스 초창기에 MySQL이 놀라운 인기와 성공을 거두었음에도 불구하고 Postgres가 어떻게 살아남았는지에 대해 이야기해 보겠습니다. 이 시리즈의 첫 번째 블로그가 단지 ‘사실’에 관한 것이었다면, 이번 블로그는 대부분 제 개인적인 경험과 그 경험에서 비롯된 의견을 기반으로 합니다. 따라서 제 배경과 제가 수년에 걸쳐 누구와 이야기할 수 있었는지에 대해 잠시 말씀드리고자 합니다.
저는 15년 이상 Postgres 및 Postgres 관련 기업들과 함께해 왔습니다. Postgres 프로젝트 첫날부터 참여했던 많은 분들, 그리고 Postgres의 초기 도입자(early adopter)들과 이야기할 수 있는 영광을 누렸습니다. 또한 저는 Sun Microsystems에 재직 중이었는데, 당시 제 상사가 Sun의 10억 달러 규모 MySQL 인수를 이끌었습니다. 저는 MySQL의 탄생과 그 이후의 성공에 관여했던 일부 사람들, 그리고 이 업계를 뒤흔든 인수의 전략적 배경에 있던 많은 사람과도 대화할 기회가 있었습니다.
MySQL이 초창기에 앞서 나갔던 이유
MySQL과 Postgres는 모두 90년대 중반에 등장했습니다. 그 이후로 많은 것이 변했고, 두 데이터베이스 모두 서로의 강점 일부를 받아들이며 진화해 왔습니다. 제가 여러 대화, 저의 희미해지는 기억, 그리고 웹상의 다양한 출처에서 수집한 정보를 바탕으로, 초창기에 MySQL이 Postgres를 앞질렀던 이유는 다음과 같습니다.
- 7년이나 앞선 Windows 지원: MySQL은 Postgres보다 7년 먼저 Windows를 지원했습니다. MySQL은 98년에 Windows 버전을 출시했지만, Postgres는 7년 후인 2005년에야 출시했습니다. 요즘 젊은 분들을 위해 설명하자면, Windows NT와 Windows 95(1995년 출시)가 나온 이후 대다수의 개발자가 Windows 95+로 이동했습니다. 이 운영체제는 대부분의 개발자가 직장에서는 물론 개인 프로젝트를 위한 로컬 머신에서도 사용했던 OS입니다. 따라서 Postgres는 출시 후 첫 7년 동안 대다수의 개발자가 접근조차 할 수 없었습니다.
- 웹에 최적화된 속도: MySQL은 짧고 간단한 쿼리에서 매우 빨랐습니다. 이는 월드 와이드 웹(World Wide Web)의 등장으로 탄생한 이 놀라운 신규 산업에 정확히 필요한 것이었습니다. 반면, 당시 Postgres는 적절한 트랜잭션 처리와 복잡한 쿼리 최적화에 더 중점을 두었기 때문에, 일반적인 웹 애플리케이션에는 더 느리고 덜 적합했습니다. (이 시기에 대한 두 데이터베이스의 성능 수치는 없으므로, 이는 전적으로 제가 들은 바에 근거합니다.)
- 초기 마케팅 및 투자: MySQL은 초기부터 투자 기반의 회사(MySQL AB)가 뒤에 있었고, 기술을 마케팅하고 사용자 컨퍼런스를 개최할 수 있었습니다. Postgres의 경우, 이러한 규모의 지원은 훨씬 나중에야 이루어졌습니다. (Postgres가 MySQL과 유사한 마케팅 투자를 받기 시작한 시점에 대해서는 의견이 분분합니다. Postgres를 지원한 초기 회사로는 Great Bridge와 EDB 등이 있습니다.)
- LAMP 스택의 ‘M’: LAMP (Linux, Apache, MySQL, PHP) 브랜드가 부상하면서 MySQL의 ‘M’은 매우 강력한 인지도를 얻었습니다. 이 스택/브랜드는 매일 새로운 웹사이트와 웹 기반 비즈니스가 생겨나던 시기에 가장 빠르게 성장하는 웹 개발 플랫폼 중 하나가 되었습니다. LAMP 스택 개발에 관한 온갖 종류의 책이 출판되었고, 많은 대학 과정과 부트캠프에서 이 새로운 방식의 웹사이트/웹앱 개발을 가르쳤습니다.
그렇다면 초창기에 Postgres는 왜 LAMP 스택의 ‘L'(Linux)에 밀려 거의 사라진 Berkeley Unix와 같은 길을 가지 않았을까요?
Postgres가 사라지지 않은 이유
다시 한번 제가 대화, 개인적인 경험, 그리고 웹에서 찾은 것들을 통해 배운 것을 바탕으로, MySQL의 이러한 놀라운 이점과 출발선에서의 우위에도 불구하고 Postgres가 초기에 강력하고 충성도 높은 팬층을 확보할 수 있었던 이유는 다음과 같습니다.
- 라이선스 (The License): Postgres는 과거에도 그랬고 지금도 가장 관대한 라이선스(permissive license) 중 하나를 가지고 있습니다. 덕분에 초창기 Greenplum, Netezza, EDB 및 기타 여러 회사가 자사 제품에 Postgres를 활용할 수 있었습니다. Postgres의 작동 방식과 기능에 대한 일반적인 이해가 이들 기업과 그 사용자 기반에 스며들었습니다.
- 트랜잭션 (Transactions): MySQL은 2000년대 초반까지 진정한 ACID 트랜잭션을 지원하지 않았으며, 심지어 그 당시에도 기본 스토리지 엔진(MyISAM)은 ACID를 준수하지 않았습니다. 이 점이 데이터베이스 순수주의자(purist)들과 학계, 그리고 이러한 트랜잭션 속성을 절대적으로 필요로 했던 기관들(예: 금융)을 끌어들였습니다.
- 소스 코드 (The source code): 제가 들은 바에 따르면, 그리고 제 두 눈으로 직접 확인한 바로도 Postgres의 소스 코드는 절대적으로 깔끔합니다(pristine). 최고 수준의 개발자들은 이 소스 코드로 작업하는 것을 좋아했습니다. 특히 데이터베이스 학계에 있거나, 어떤 방식으로든 데이터베이스 작업을 계속하고 싶어 했던 상용 데이터베이스 회사(proprietary database companies) 출신의 개발자들이 그러했습니다. 매우 엄격한 검토 및 개발 프로세스를 통해 소스 코드는 오늘날까지도 깨끗하고 잘 문서화된 상태를 유지하고 있습니다.
- 옵티마이저 (The optimizer): Oracle이나 다른 상용 데이터베이스에서 마이그레이션하는 많은 애플리케이션은 Postgres가 제공하는 일부 최적화 기술을 필요로 했습니다. 또한, 이전 옵티마이저에 대한 경험이 있던 많은 사람이 Postgres 옵티마이저와 함께 작업하기를 원했습니다. 제가 오랫동안 활동한 여러 Postgres 커뮤니티 멤버에게 “무엇이 당신을 Postgres로 이끌었나요?”라고 물었을 때, 그들은 간단히 **”옵티마이저”**라고 답했습니다.
- 확장성 (Extensibility): MySQL은 서드파티가 스토리지 엔진을 플러그인할 수 있다는 점에서 매우 확장성이 뛰어났습니다. 하지만 Postgres는 새로운 ‘데이터 타입(data type)’을 플러그인할 수 있는 기능을 갖추고 있었습니다. 이것이 바로 Postgres가 지리 공간 정보(Geo Spatial) 분야에서 믿을 수 없을 만큼 강력한 솔루션이 된 방식입니다. PostGIS 확장 기능 덕분에, 완전히 새로운 유형의 기업들과 유스케이스가 Postgres로 유입되었습니다.
이러한 기반을 바탕으로 Postgres는 살아남았고, 매우 강력한 팬층을 확보했으며, 개발자들 사이에서 꾸준한 성장을 경험했습니다. Postgres가 어떻게 정상에 올랐는지에 대한 제 견해는 이 블로그 시리즈의 3부에서 기다려 주시기 바랍니다.
