PostgreSQL 확장성의 한계와 해법: EDB PGD 액티브-액티브 아키텍처

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를 떠날 필요는 없습니다. 더 나은 해결책이 이미 존재하기 때문입니다.

PostgreSQL 확장성의 대안: EDB Postgres Distributed 액티브-액티브

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

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

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

파트 1: Azure Database for PostgreSQL 유연한 서버가 한계에 부딪힌 이유

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: PostgreSQL 고가용성(HA)과 비즈니스 회복탄력성 비교

파트 3: MariaDB의 대안 주장과 PGD 커밋 스코프의 차이

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

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

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

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

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

상시 가동 워크로드를 위한 목적 지향적 설계

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

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

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

• 글로벌 결제 시스템이 단 60초라도 멈춘다면 어떤 일이 벌어질까요?
• 국가 전력망의 통제권이 단 하나의 프라이머리 리더에만 매달려 있다면 어떨까요?
• 누군가 실행한 쿼리 하나 때문에 응급 서비스 시스템이 유지보수 장애 위험에 처한다면 어떨까요?

PostgreSQL 확장성과 EDB PGD FAQ

PostgreSQL 단일 프라이머리 아키텍처의 한계는 무엇인가요?

모든 쓰기 작업이 하나의 프라이머리 노드를 통과하므로 대규모 워크로드에서는 쓰기 병목과 단일 장애점이 발생할 수 있습니다. 유지보수나 장애 조치가 전체 서비스의 쓰기 가용성에 영향을 줄 수 있다는 점도 주요 리스크입니다.

EDB Postgres Distributed(PGD)란 무엇인가요?

PGD는 100% Postgres 환경을 유지하면서 액티브-액티브 분산 아키텍처를 구현하는 클러스터 관리 솔루션입니다. 읽기 성능의 스케일아웃, 데이터 로컬리티 관리, 노드와 리전 간 라이프사이클 관리를 지원합니다.

PGD의 액티브-액티브 아키텍처는 어떤 이점이 있나요?

쓰기 워크로드를 여러 노드와 리전에 분산하고 단일 쓰기 리더에서 발생하는 장애점을 줄일 수 있습니다. 또한 개별 노드에서 유지보수와 업그레이드를 순차적으로 수행해 상시 가동 환경을 지원합니다.

PostgreSQL 고가용성과 비즈니스 회복탄력성은 어떻게 다른가요?

고가용성은 장애 발생 시 서비스 복구와 지속에 초점을 맞춥니다. 비즈니스 회복탄력성은 여기에 더해 쓰기 병목, 유지보수, 데이터 내구성, 인프라 이식성 및 개발 생산성까지 포괄적으로 고려합니다.

PGD의 커밋 스코프는 어떤 역할을 하나요?

커밋 스코프를 사용하면 워크로드 특성에 맞춰 데이터 기록과 커밋 방식을 제어할 수 있습니다. 본문에서 설명한 동기 커밋, 지연 제어, 선제적 충돌 해결 및 합의 기반 동기 복제를 통해 가용성·내구성·일관성 요구를 관리합니다.

메일: salesinquiry@enterprisedb.com