2026-02-04 / Last updated : 2026-02-04 Grace Technical Blog

OpenAI가 Postgres Distributed를 사용해야 하는 이유

Jozef de Vries

2026년 2월 3일

지난주, OpenAI는 단일 프라이머리(Single-primary) 기반의 PostgreSQL 인스턴스를 확장하여 8억 명의 사용자를 수용했던 자신들의 설계 방식을 상세히 공개했습니다. 발표 직후, MariaDB는 자사 제품을 사용했다면 OpenAI가 겪었던 여러 ‘균열’ 없이도 충분히 동일한 규모를 처리했을 것이라 주장하고 나섰습니다.

OpenAI가 보여준 방식은 분명 Postgres 설계와 운영에 대한 깊은 전문성을 입증했습니다. 하지만 동시에, 단일 쓰기(Single-writer) 아키텍처로 현대의 방대한 워크로드를 감당하기 위해 팀이 얼마나 뼈를 깎는 노력을 기울여야 하는지도 여실히 보여주었습니다.

MariaDB 측의 주장은 차라리 Postgres 생태계를 아예 떠나는 것이 낫다는 의미로 들립니다. 하지만 이에 대한 반론은 명확합니다. 이미 시장의 승자는 Postgres라는 점입니다. Postgres는 전 세계에서 가장 빠르게 성장하는 데이터베이스이며, 매년 실시되는 Stack Overflow 설문 조사에 따르면 지난 10년 동안 MariaDB보다 줄곧 10배 이상 높은 선호도를 기록해 왔습니다.

Postgres가 승리한 비결은 뛰어난 확장성의 토대와 혁신이 끊이지 않는 활기찬 생태계에 있습니다. 이러한 확장성과 혁신의 결합 덕분에 사용자는 일반적인 ‘순정(Off-the-shelf)’ Postgres가 제공하는 성능 그 이상을 끌어낼 수 있습니다. 오늘날의 대규모 워크로드를 처리하기 위해 굳이 Postgres를 떠날 필요는 없습니다. 더 나은 해결책이 이미 존재하기 때문입니다.

더 나은 대안: EDB Postgres Distributed를 통한 액티브-액티브 Postgres

EDB Postgres Distributed(PGD)를 활용하면 기업은 기존의 물리적 스트리밍 복제 모델이 가진 한계에 갇힐 필요가 없습니다. 또한 새로운 데이터베이스 엔진으로 이전하느라 고생할 필요도 없습니다. PGD는 100% Postgres 환경을 유지하면서도 액티브-액티브(Active-Active) 분산 Postgres 아키텍처를 구현해 줍니다.

PGD는 국가 핵심 인프라 수준의 확장성과 신뢰성이 요구되는 애플리케이션(응급 서비스, 전력망, 글로벌 결제 시스템 등)을 지원하는 클러스터 관리 솔루션입니다.

PGD는 표준 PostgreSQL을 ‘상시 가동(Always-on)’되는 분산 데이터베이스 플랫폼으로 변환합니다. 이는 현대 엔터프라이즈의 확장 요구에 맞춰 설계되었으며, 읽기 성능의 스케일아웃, 정교한 데이터 로컬리티(Data Locality) 관리, 모든 노드와 리전 간의 원활한 라이프사이클 관리를 완벽히 지원합니다.

파트 1: Azure “유연한 서버”가 한계에 부딪힌 이유

OpenAI는 매우 견고한 서비스인 Azure Database for PostgreSQL 유연한 서버(Flexible Server)를 사용했습니다. 하지만 이 서비스는 근본적으로 단일 프라이머리 아키텍처를 기반으로 합니다. 사용자 수가 폭발적으로 늘어나면서 비즈니스 연속성에 대한 시스템적 리스크가 수면 위로 드러났습니다.

1. 매출 리스크: 단일 쓰기 지점의 병목 현상

Azure 유연한 서버 환경에서는 모든 쓰기 작업, 즉 모든 ChatGPT 대화와 결제 기록이 단 하나의 프라이머리 노드를 통과해야 합니다. OpenAI는 가중되는 부하를 감당하기 위해 결국 쓰기 비중이 높은 트랜잭션을 Cosmos DB로 분산시켜야만 했습니다.

비즈니스 리스크: 만약 해당 프라이머리 노드나 가용 영역(AZ)에 장애가 발생하면 OpenAI는 즉시 전체 서비스의 쓰기 중단 사태를 맞이하게 됩니다. Azure에서 발생하는 60초의 장애 조치(Failover) 시간은 단순한 지연이 아닙니다. 이는 수백만 달러의 매출 손실과 고객 신뢰도 하락으로 직결됩니다.
PGD의 장점: PGD의 액티브-액티브(멀티 마스터) 아키텍처는 압도적인 우위를 점합니다. 빠른 장애 조치 기능을 갖추고 있으며, 쓰기 워크로드를 여러 노드와 리전에 분산하여 처리량을 극대화합니다. 이를 통해 단일 쓰기 리더에서 발생할 수 있는 모든 단일 장애점(SPOF)을 원천 차단합니다.

2. 운영 리스크: 유지보수가 곧 리스크가 되는 현실

OpenAI에 따르면, 관리자의 개입이나 정리가 필요한 일상적인 DB 변경조차 8억 명의 사용자에게는 성능 저하의 위험 요소가 되었습니다. 이러한 현실 때문에 스키마 설계나 시스템 구성에 제약이 생겼고, 가용성과 운영 안정성을 지키기 위해 최적화를 포기해야 하는 어려운 선택을 반복해야 했습니다.

비즈니스 리스크: 글로벌 24/7 서비스에는 ‘사용량이 적은 시간대’란 존재하지 않습니다. 결국 성능 저하를 감수하거나, 위험을 안고 운영 중단이 수반되는 유지보수를 강행해야 하는 딜레마에 빠집니다.
PGD의 장점: PGD는 상시 가동 유지보수(Always On Maintenance) 환경을 제공합니다. 다른 노드의 쓰기 작업을 멈추지 않고도 개별 노드별로 REINDEX, VACUUM FULL, 또는 메이저 버전 업그레이드를 순차적으로 진행할 수 있습니다. 또한 PGD의 ‘클러스터 인식 오케스트레이션’을 통해 단일 명령으로 클러스터 전체에 순차적인 작업을 실행할 수 있어, 가용성 저하나 운영 부담 없이 일상적인 유지보수가 가능합니다.

3. 고객 만족 리스크

OpenAI는 초기에 5,000개의 커넥션 제한에 걸리며 연쇄 장애를 경험했습니다. 이를 해결하기 위해 외부 프록시와 애플리케이션 단의 속도 제한(Rate Limiting) 등 추가적인 아키텍처 복잡성을 감수해야 했습니다.

비즈니스 리스크: 엔지니어가 업무 시간의 절반을 DB 한계를 우회하는 로직을 만드는 데 쓴다면, 정작 중요한 혁신은 뒷전으로 밀리게 됩니다.
PGD의 장점: PGD에는 네이티브 커넥션 매니저(Native Connection Manager)가 내장되어 있습니다. 수천 개의 커넥션을 효율적으로 관리하고 1초 미만(Sub-seconds) 내에 라우팅을 업데이트하여, 커넥션 과부하가 발생하기 전에 미리 차단합니다.

파트 2: 단순 고가용성(HA) vs 비즈니스 회복탄력성

주요 항목 / 리스크	Azure PG 유연한 서버 (OpenAI 현재)	EDB Postgres Distributed (PGD)
쓰기 아키텍처	단일 프라이머리 (고위험 병목 지점)	멀티 마스터 (액티브-액티브)
읽기 확장성	프라이머리에 부하 집중	구독 전용 노드 및 200개 이상 노드 확장
복구 시간 (RTO)	수 분 소요 (물리 복제 방식의 한계)	1초 미만 (리더 선출 방식)
유지보수 가용성	성능 저하 우려; 정교한 작업 공조 필수	온라인 유지보수 (DDL, VACUUM 등 상시 가능)
데이터 내구성	일반적인 동기/비동기 복제 방식	다중 커밋 스코프로 내구성과 일관성 확보
개발 생산성	DB의 제약 사항 해결에 많은 시간 소요	DB가 엔지니어의 요구에 맞춰 유연하게 확장
인프라 이식성	Azure 클라우드 환경에 국한됨	모든 클라우드, 온프레미스, K8s 지원

파트 3: MariaDB의 “대안” 주장에 대하여

MariaDB는 자신들의 Galera 클러스터가 Postgres의 한계를 극복할 수 있다고 말합니다. 하지만 이들은 가장 중요한 사실을 간과하고 있습니다. 바로 Postgres가 이미 개발자들의 표준이 되었다는 점입니다.

기술적 반론: 커밋 스코프(Commit Scopes)의 차이

MariaDB가 내세우는 Galera는 동기 복제 방식에 의존하는데, 이는 ‘인증 벽(Certification Wall)’ 문제를 야기합니다. 다른 리전에 노드가 있을 경우, 모든 쓰기 작업은 전역 합의를 기다려야 하며, 시스템이 분산될수록 지연 시간(Latency)은 걷잡을 수 없이 커집니다.

반면 PGD는 커밋 스코프라는 훨씬 정교한 해답을 제시합니다. 사용자는 워크로드의 특성에 맞춰 데이터 기록 및 커밋 방식을 자유롭게 제어할 수 있습니다.

동기 커밋 (Synchronous Commit): 로컬에서 트랜잭션을 커밋하되, 설정된 쿼럼 노드들이 수신을 확인할 때까지 락을 유지합니다. 만약 동기 노드에 문제가 생기면 자동으로 비동기 모드로 전환되는 자동 성능 저하(Auto-Degrade) 기능을 통해 가용성을 방어합니다.
지연 제어 (Lag Control): 비동기 복제 시 복제 지연 임계값을 설정하여, 데이터 유실 위험이 기준치를 넘으면 로컬 커밋 속도를 조절해 리스크를 자동으로 관리합니다.
선제적 충돌 해결 (Eager Conflict Resolution): 트랜잭션 커밋 전에 잠재적 충돌을 미리 감지하여 해결하는 비관적 전략으로, 클러스터 전체의 데이터 일관성을 완벽히 보장합니다.
합의 기반 동기 복제: PGD는 커스텀 Raft 합의 알고리즘을 통해 내구성을 확보합니다. 이를 통해 리더 선출을 자동화하고 모든 노드가 동일한 트랜잭션 상태를 유지하도록 관리합니다.

진정 목적에 부합하는 설계 (Purpose-Built)

8억 명의 사용자를 수용해낸 OpenAI의 사례는 Postgres의 저력을 보여주지만, 한편으로는 Postgres의 진정한 잠재력을 다 끌어다 쓴 것은 아닙니다. 그것은 엔지니어들의 영리한 임기응변과 양사 간의 긴밀한 협력으로 빚어낸 성과일 뿐, 과연 이 방식이 지속 가능한가에 대해서는 의문이 남습니다. Azure Postgres 유연한 서버가 과연 이러한 대규모 아키텍처를 수백 번이고 반복해서 구현해낼 수 있도록 설계된 제품일까요?

EDB Postgres Distributed는 바로 그 목적을 위해 태어났습니다. PGD는 태생부터 ‘상시 가동’ 워크로드를 위해 설계되었으며, 전 세계에서 가장 까다로운 핵심 워크로드를 처리하기 위해 만들어졌습니다. 이미 수백 개의 기업이 PGD를 통해 이를 증명하고 있습니다.

국가 핵심 인프라를 책임지는 위치에 계신다면, 여러분의 워크로드를 위해 본연의 설계부터 갖춰진 시스템을 선택하시겠습니까, 아니면 복잡한 설정으로 겨우 맞춰놓은 시스템을 선택하시겠습니까?