오픈AI가 8억 사용자를 단일 PostgreSQL로 처리하는 비결

개요

OpenAI는 ChatGPT의 8억 명 사용자를 30년 된 오픈소스 데이터베이스인 PostgreSQL 단일 주 서버로 처리하고 있습니다. 샤딩이나 최첨단 분산 데이터베이스 없이, 하나의 쓰기 서버와 50개 이상의 읽기 복제본만으로 초당 수백만 건의 쿼리를 감당합니다. 이는 많은 개발자들이 믿고 있는 “서비스가 커지면 무조건 복잡한 아키텍처가 필요하다”는 통념을 정면으로 반박하며, 단순함을 유지하면서도 극한의 규모로 확장할 수 있음을 증명합니다.

이 영상은 바이브코딩의 제임스가 OpenAI의 데이터베이스 엔지니어 보한 장(Bohan Zhang)의 사례를 바탕으로 제작한 콘텐츠입니다. 제임스는 에이전시 운영 경험을 통해 수백 개의 스타트업 프로젝트를 진행하며 데이터베이스 선택과 확장성에 대한 질문을 많이 받았고, 이를 바탕으로 실무자 관점에서 OpenAI의 전략을 해석합니다. 바이브코딩 채널은 비개발자도 웹서비스를 만들 수 있도록 돕는 교육 콘텐츠로 널리 알려져 있습니다.

핵심 내용

OpenAI의 PostgreSQL 아키텍처

OpenAI는 Azure의 매니지드 PostgreSQL 서비스를 사용하며, 구조는 놀라울 정도로 단순합니다. 하나의 주 서버(primary server)가 모든 쓰기 작업을 담당하고, 50개 이상의 읽기 복제본(read replicas)이 읽기 요청을 분산 처리합니다. 일부 복제본은 다른 지역에 배치되어 지리적 분산까지 고려합니다. 이 구조로 초당 수백만 건의 쿼리를 처리하며, 모니터링은 DataDog을 통해 이루어지고 Kubernetes 환경의 서비스들이 PgBouncer 커넥션 풀을 통해 데이터베이스에 접근합니다.

OpenAI가 샤딩을 하지 않는 이유는 명확합니다. 샤딩은 데이터를 여러 서버에 나누어 저장해 확장성을 제공하지만, 그 대가로 복잡도가 기하급수적으로 증가합니다. 조인 쿼리가 어려워지고, 트랜잭션 관리가 복잡해지며, 운영 부담이 커집니다. 보한 장 엔지니어는 “PostgreSQL이 대규모 읽기 부하에서 우아하게 확장될 수 있다는 것을 보여주고 있다”고 말하며, 단순한 아키텍처의 우수성을 강조했습니다.

NoSQL 데이터베이스(MongoDB, Cassandra 등) 대신 PostgreSQL을 선택한 이유도 설득력이 있습니다. 30년 넘게 검증된 PostgreSQL은 데이터 정합성이 중요한 서비스에서 필수적인 트랜잭션 보장을 제공합니다. ChatGPT의 사용자 대화 기록, 결제 정보, 구독 상태 같은 데이터는 절대로 잘못되면 안 되며, PostgreSQL은 이를 안전하게 관리할 수 있습니다. 게다가 PostgreSQL 생태계는 모니터링 도구, 백업 솔루션, 클라우드 매니지드 서비스까지 풍부하게 갖춰져 있어 운영 효율성도 뛰어납니다.

커넥션 풀링도 OpenAI 아키텍처의 핵심 요소입니다. PgBouncer를 사용해 데이터베이스 커넥션을 재사용함으로써 매번 새로 만들고 끊는 오버헤드를 크게 줄였습니다. 특히 Kubernetes처럼 서비스가 빈번하게 뜨고 내리는 환경에서 커넥션 풀링은 필수적이며, OpenAI는 비즈니스 로직 쪽에 PgBouncer를 배치해 데이터베이스 클러스터에 효율적으로 접근하도록 설계했습니다.

쓰기 병목 문제와 해결 전략

단순한 구조에도 치명적인 문제가 있습니다. 바로 쓰기 병목입니다. 읽기는 복제본을 늘리면 해결되지만, 쓰기는 모든 요청이 단일 주 서버로 몰립니다. 트래픽이 급증하면서 실제로 데이터베이스 성능이 서비스 전체에 영향을 미치는 장애가 발생했고, 이는 OpenAI의 가장 큰 도전 과제였습니다.

OpenAI는 쓰기 부하를 줄이기 위해 세 가지 핵심 전략을 도입했습니다. 첫째, 불필요한 쓰기 제거입니다. 애플리케이션 레벨에서 정말 필요한 쓰기인지 철저히 검토하고, 불필요한 쓰기는 과감하게 없앴습니다. 예를 들어, 페이지 조회수를 매번 데이터베이스에 기록하던 것을 인메모리에 모아뒀다가 주기적으로 배치로 쓰는 방식으로 변경하면 데이터베이스 부하가 절반으로 줄어듭니다.

둘째, 지연 쓰기(delayed writes)입니다. 급하지 않은 쓰기는 즉시 처리하지 않고 모아서 나중에 배치로 처리합니다. 이렇게 하면 순간적인 쓰기 폭주를 평탄화(smoothing)할 수 있어 주 서버의 부담이 크게 줄어듭니다.

셋째, 데이터 백필 속도 제어(backfill rate limiting)입니다. 대량의 데이터를 넣어야 할 때 한꺼번에 넣지 않고 속도를 조절해서 천천히 넣습니다. 이 세 가지 전략만으로도 쓰기 병목을 상당히 완화할 수 있었고, OpenAI는 이를 통해 안정성을 크게 향상시켰습니다.

읽기 최적화와 요청 우선순위 구분

쓰기 문제를 어느 정도 해결한 후, OpenAI는 읽기 최적화에 집중했습니다. ChatGPT 트래픽의 대부분은 읽기 요청이기 때문에 읽기 성능이 사용자 경험에 직접적인 영향을 미칩니다.

핵심 전략은 요청 우선순위 구분입니다. 모든 읽기 요청이 똑같이 중요한 것은 아닙니다. 사용자가 바로 기다리는 요청(user-facing requests)과 백그라운드에서 처리해도 되는 요청(background jobs)을 명확히 구분합니다. 높은 우선순위 요청에는 전용 읽기 복제본을 할당함으로써, 중요한 요청이 다른 트래픽에 영향받지 않고 빠르게 처리되도록 보장합니다.

쿼리 최적화도 중요한 과제였습니다. OpenAI가 겪었던 문제 중 하나는 12개 테이블을 조인하는 복잡한 쿼리였습니다. ORM이 자동으로 생성한 비효율적인 쿼리가 성능을 크게 저하시키고 있었고, 이를 수동으로 최적화해야 했습니다. 또한 세션, 문장, 클라이언트 레벨에서 타임아웃을 설정해 오래 실행되는 트랜잭션을 방지했습니다. 느린 쿼리 하나가 전체 시스템을 마비시킬 수 있기 때문에 이런 보호 장치는 필수적입니다.

엄격한 스키마 변경 규칙

OpenAI는 스키마 변경에 대해 매우 엄격한 규칙을 적용합니다. 새로운 테이블이나 워크로드를 PostgreSQL에 추가하는 것을 원칙적으로 금지했고, 가벼운 컬럼 작업만 허용하되 그것도 5초 타임아웃을 걸었습니다. 인덱스 생성은 반드시 CONCURRENTLY 옵션을 사용해야 하며, 1초 이상 지속되는 쿼리가 있으면 스키마 변경이 실패하도록 막았습니다.

왜 이렇게까지 엄격할까요? 대규모 시스템에서 스키마 변경은 매우 위험합니다. 잘못하면 테이블 락(lock)이 걸려 전체 서비스가 멈출 수 있습니다. 수백만 사용자가 동시에 사용하는 서비스에서 몇 초의 락도 치명적입니다. OpenAI는 안정성을 최우선으로 두고, 새로운 쓰기 워크로드는 Cosmos DB로 분산시키는 현실적인 타협을 선택했습니다. 기존 PostgreSQL 시스템을 안정적으로 유지하면서 새로운 요구사항은 다른 데이터베이스로 수용하는 것이죠.

장애 사례와 교훈

OpenAI가 겪었던 장애 사례도 매우 교육적입니다. 첫 번째 사례는 캐시 장애의 연쇄 효과입니다. Redis 캐시에 문제가 생기자 평소에 캐시에서 처리되던 요청들이 모두 데이터베이스로 몰렸습니다. 데이터베이스가 갑자기 늘어난 부하를 감당하지 못하면서 연쇄 장애(cascading failure)가 발생했습니다. 이는 캐시와 데이터베이스를 함께 설계해야 한다는 중요한 교훈을 줍니다. 캐시가 죽었을 때 데이터베이스가 버틸 수 있도록 여유 용량(capacity headroom)을 확보해야 합니다.

두 번째 사례는 더 기술적입니다. CPU 사용량이 극도로 높아졌을 때 발생한 PostgreSQL 버그로, CPU가 정상으로 돌아온 후에도 walsender 프로세스가 무한 루프에 빠져 WAL(Write-Ahead Log) 로그를 제대로 복제본에 보내지 못했습니다. 그 결과 복제 지연(replication lag)이 크게 늘어났습니다. 이런 엣지 케이스(edge case)는 예측하기 어렵지만, 철저한 모니터링과 빠른 대응이 피해를 최소화할 수 있습니다.

이런 경험을 통해 OpenAI는 9개월 동안 PostgreSQL 관련 중대 장애를 단 1건만 겪었다고 보고했습니다. 이는 단순한 아키텍처, 엄격한 운영 규칙, 철저한 모니터링이 얼마나 효과적인지 보여주는 강력한 증거입니다.

PostgreSQL 커뮤니티에 대한 기능 요청

OpenAI는 PostgreSQL 커뮤니티에 몇 가지 기능 개선을 요청했습니다. 첫째, 인덱스 비활성화 기능입니다. 사용하지 않는 인덱스는 쓰기 성능을 떨어뜨리고 유지보수 부담을 늘립니다. 하지만 인덱스를 바로 삭제하면 문제가 생길 수 있으니, 먼저 비활성화해서 성능을 모니터링한 후 안전하게 삭제하고 싶다는 것입니다.

둘째, 지연 시간 백분위수 메트릭입니다. 현재 pg_stat_statements는 평균 응답 시간만 제공하는데, P95(95번째 백분위수)나 P99(99번째 백분위수) 같은 백분위수 지표가 필요합니다. 평균은 이상치(outlier)에 의해 왜곡될 수 있고, 실제 사용자가 경험하는 최악의 경우를 반영하지 못하기 때문입니다.

PostgreSQL의 MVCC(Multi-Version Concurrency Control) 설계도 도전 과제를 안겨줍니다. MVCC는 쓰기가 발생할 때마다 새로운 버전의 행을 만들어 동시성을 보장하지만, 테이블과 인덱스 블로트(bloat, 부풀어 오름) 현상이 생깁니다. 이를 청소하는 autovacuum 프로세스를 적절히 튜닝하는 것이 쉽지 않고, 복제본이 많아지면 가시성 체크(visibility check) 오버헤드 때문에 복제 지연이 늘어날 수도 있습니다. OpenAI도 이런 문제들과 지속적으로 씨름하고 있습니다.

실전 가이드

영상의 내용을 실제로 적용하려면 다음 과정을 따라해볼 수 있습니다.

먼저 불필요한 쓰기를 점검합니다. 여러분의 애플리케이션에서 데이터베이스에 기록되는 모든 쓰기 작업을 나열해보세요. 로그를 남기기 위한 쓰기, 매번 업데이트하는 updated_at 타임스탬프, 조회수 카운터 같은 것들이 정말 실시간으로 데이터베이스에 기록되어야 하는지 검토합니다. 중요하지 않은 쓰기는 인메모리 큐에 모아뒀다가 주기적으로 배치 처리하는 방식으로 변경하면, 데이터베이스 부하를 크게 줄일 수 있습니다. 이 단계에서는 애플리케이션 코드를 분석하는 시간이 필요하며, 작은 서비스라도 10-20개의 불필요한 쓰기를 발견할 수 있습니다.

다음으로 슬로우 쿼리 로그를 활성화합니다. PostgreSQL에서는 log_min_duration_statement 설정을 통해 특정 시간 이상 걸리는 쿼리를 로그로 기록할 수 있습니다. 예를 들어 1초 이상 걸리는 쿼리를 모두 기록하도록 설정하고, 일주일 정도 모니터링하면 병목이 되는 쿼리들을 찾을 수 있습니다. 여기서 주의할 점은 ORM이 생성한 N+1 쿼리 문제나 불필요한 조인이 자주 발견된다는 것입니다. 이런 쿼리를 최적화하면 응답 시간이 10배 이상 빨라지는 경우도 많습니다.

마지막으로 읽기와 쓰기를 분리합니다. 서비스 규모가 어느 정도 커졌다면(일 활성 사용자 1만 명 이상), 읽기 복제본을 추가하는 것을 고려하세요. AWS RDS나 Azure Database for PostgreSQL 같은 매니지드 서비스는 클릭 몇 번으로 읽기 복제본을 추가할 수 있습니다. 애플리케이션 코드에서 읽기 전용 쿼리(SELECT)는 복제본으로, 쓰기 쿼리(INSERT, UPDATE, DELETE)는 주 서버로 라우팅하도록 설정합니다. 대부분의 웹 애플리케이션은 읽기가 쓰기보다 10배 이상 많기 때문에, 이 방법만으로도 주 서버의 부하를 크게 줄일 수 있습니다.

심층 분석

이 영상이 다루는 OpenAI의 접근 방식은 여러 강점이 있지만, 몇 가지 한계와 고려해야 할 점도 있습니다.

첫째, 쓰기 병목은 근본적인 한계입니다. OpenAI도 인정했듯이, 단일 주 서버 아키텍처는 쓰기 처리량에 명확한 천장이 있습니다. 아무리 쓰기를 최적화해도 결국 물리적인 서버 하나의 성능을 넘어설 수 없습니다. OpenAI는 이를 해결하기 위해 새로운 쓰기 워크로드를 Cosmos DB로 분산시키는 방식을 택했는데, 이는 사실상 하이브리드 데이터베이스 전략으로의 전환을 의미합니다. 즉, 순수한 PostgreSQL 단일 서버 아키텍처만으로는 더 이상 확장할 수 없는 지점에 도달했다는 뜻입니다.

둘째, 이 전략은 읽기 중심 워크로드에만 효과적입니다. ChatGPT는 읽기 요청이 압도적으로 많은 서비스입니다. 하지만 만약 쓰기와 읽기가 비슷한 비율로 발생하는 서비스(예: 실시간 협업 도구, 금융 거래 시스템)라면 이 아키텍처는 적합하지 않습니다. 쓰기가 많은 서비스는 처음부터 샤딩이나 분산 데이터베이스를 고려해야 할 수도 있습니다.

셋째, 매니지드 서비스 의존도가 높습니다. OpenAI는 Azure의 매니지드 PostgreSQL을 사용하기 때문에 자동 백업, 고가용성, 패치 관리 등을 클라우드 제공자에게 의존합니다. 이는 운영 부담을 줄여주지만, 동시에 클라우드 제공자의 성능 한계나 비용 구조에 종속됩니다. 자체 데이터센터를 운영하거나 클라우드 비용을 최소화해야 하는 조직에는 적합하지 않을 수 있습니다.

넷째, 복제 지연(replication lag) 문제입니다. 읽기 복제본은 주 서버에서 비동기적으로 데이터를 복사하기 때문에 항상 약간의 지연이 있습니다. 보통은 밀리초 단위지만, 부하가 높을 때는 수 초까지 늘어날 수 있습니다. 사용자가 방금 작성한 데이터를 읽기 복제본에서 조회했을 때 아직 반영되지 않았다면 혼란스러울 수 있습니다. 이를 해결하려면 쓰기 후 읽기(write-after-read) 일관성이 필요한 쿼리는 주 서버로 보내야 하는데, 이는 애플리케이션 로직을 복잡하게 만듭니다.

현재 데이터베이스 업계의 최신 트렌드를 보면, 분산 SQL 데이터베이스(CockroachDB, YugabyteDB, Google Spanner)가 주목받고 있습니다. 이들은 PostgreSQL 호환성을 유지하면서도 자동 샤딩과 수평 확장을 제공합니다. OpenAI가 미래에 더 성장한다면 결국 이런 분산 데이터베이스로 마이그레이션할 가능성도 있습니다. 하지만 현재로서는 기존 PostgreSQL 아키텍처를 최대한 활용하면서 새로운 워크로드만 분리하는 것이 가장 현실적인 선택입니다.

데이터 기반 인사이트

OpenAI의 데이터베이스 전략은 구체적인 수치와 사례로 뒷받침됩니다. 8억 명의 사용자를 단일 주 서버로 지원한다는 것은 초당 수백만 건의 쿼리를 처리한다는 의미입니다. 보한 장 엔지니어는 공개 발표에서 “50개 이상의 읽기 복제본”을 운영한다고 밝혔으며, 일부 복제본은 다른 지역에 배치되어 있다고 설명했습니다.

9개월 동안 PostgreSQL 관련 중대 장애 1건이라는 통계는 이 아키텍처의 안정성을 보여주는 강력한 지표입니다. 이는 99.99% 이상의 가용성을 의미하며, 금융 서비스에 준하는 수준입니다. 이러한 안정성은 엄격한 스키마 변경 규칙, 철저한 모니터링, 다단계 속도 제한 등 운영 원칙의 산물입니다.

제임스가 에이전시 운영 경험에서 언급한 사례도 실용적입니다. 페이지 조회수를 인메모리에 모아 배치 처리로 변경했을 때 데이터베이스 부하가 50% 감소했다는 것은, 불필요한 쓰기 제거가 얼마나 효과적인지 보여줍니다. 이는 작은 최적화가 큰 영향을 미칠 수 있음을 증명합니다.

PostgreSQL의 역사도 주목할 만합니다. 30년 이상 개발되어 온 오픈소스 프로젝트로, 전 세계 수천 명의 기여자가 참여하고 있으며, Fortune 500 기업의 상당수가 프로덕션 환경에서 사용합니다. 이런 검증된 기술을 선택함으로써 OpenAI는 예측 가능한 성능과 풍부한 생태계의 혜택을 누립니다.

출처의 신뢰도도 높습니다. 보한 장은 OpenAI의 인프라 팀에서 데이터베이스를 직접 담당하는 엔지니어로, 컨퍼런스 발표와 기술 블로그를 통해 이러한 정보를 공유했습니다. 제임스는 이를 바탕으로 실무자 관점에서 재해석하고, 자신의 에이전시 경험을 덧붙여 더 실용적인 가이드를 제공합니다.

핵심 인사이트

영상을 본 후 기억해야 할 다섯 가지 핵심 인사이트입니다.

단순함은 확장성의 적이 아니라 동반자입니다. OpenAI는 8억 사용자를 지원하면서도 샤딩 없는 단순한 아키텍처를 유지합니다. 복잡한 기술을 도입하기 전에, 기존 시스템을 깊이 이해하고 최적화하는 것이 먼저입니다. 실제로 에이전시를 운영할 때 많은 스타트업이 “우리 서비스가 커지면”을 걱정하며 처음부터 복잡한 마이크로서비스 아키텍처를 도입하려 했지만, 대부분은 모놀리식 구조로도 충분했습니다. 복잡함은 개발 속도를 늦추고, 버그를 늘리며, 운영 비용을 증가시킵니다.
읽기와 쓰기를 분리하면 대부분의 확장성 문제가 해결됩니다. 웹 애플리케이션의 전형적인 워크로드는 읽기가 쓰기보다 10배에서 100배 많습니다. 읽기는 복제본으로 확장하고, 쓰기는 불필요한 것을 제거하거나 지연시키는 전략만으로도 엄청난 규모를 감당할 수 있습니다. 이를 위해서는 애플리케이션 코드에서 읽기 전용 쿼리와 쓰기 쿼리를 명확히 구분해야 하며, 많은 ORM 프레임워크가 이를 지원합니다(예: Django의 using('replica')).
우선순위 기반 리소스 할당은 사용자 경험을 극적으로 개선합니다. 모든 요청을 동등하게 취급하면 백그라운드 작업이 사용자 대면 요청을 방해할 수 있습니다. OpenAI는 중요한 요청에 전용 읽기 복제본을 할당해 응답 시간을 보장합니다. 이는 쿠버네티스의 우선순위 클래스(PriorityClass)나 데이터베이스의 커넥션 풀 분리로 구현할 수 있으며, 사용자가 체감하는 성능이 크게 향상됩니다.
장애를 대비한 설계는 선택이 아니라 필수입니다. OpenAI의 캐시 장애 사례는 캐시와 데이터베이스를 따로 생각해서는 안 된다는 교훈을 줍니다. 캐시가 죽었을 때 데이터베이스가 버틸 수 있도록 용량 여유를 확보하거나, 서킷 브레이커(circuit breaker) 패턴을 도입해 연쇄 장애를 방지해야 합니다. 주 서버가 죽으면 어떻게 되나요? 복제본이 자동으로 승격될 수 있나요? 이런 질문에 답할 수 있어야 합니다.
매니지드 서비스는 팀의 역량을 애플리케이션 로직에 집중시킵니다. OpenAI처럼 세계 최고의 AI 회사도 데이터베이스 운영을 클라우드에 맡깁니다. 자동 백업, 고가용성, 보안 패치 같은 저수준 작업은 전문 인력과 24시간 모니터링이 필요하며, 대부분의 조직에게는 직접 운영하는 것보다 매니지드 서비스를 쓰는 것이 훨씬 효율적입니다. 초기 스타트업은 데이터베이스 인프라에 시간을 쏟기보다 AWS RDS, Azure Database, Google Cloud SQL 같은 서비스를 활용해 제품 개발에 집중해야 합니다.

요약자 노트

이 영상은 OpenAI의 데이터베이스 아키텍처를 매우 잘 설명하지만, 몇 가지 한계를 인지하고 시청해야 합니다.

첫째, 이 전략은 읽기 중심 워크로드에 최적화되어 있습니다. 만약 쓰기가 많은 서비스(예: IoT 데이터 수집, 실시간 거래)라면 처음부터 다른 접근이 필요할 수 있습니다. 샤딩이나 시계열 데이터베이스(TimescaleDB, InfluxDB), 분산 데이터베이스를 고려해야 할 수도 있습니다.

둘째, OpenAI는 엄청난 규모에 도달한 후 이런 최적화를 했다는 점입니다. 처음부터 이 모든 것을 구현할 필요는 없습니다. 실제로 트래픽이 늘어나면서 병목이 생길 때 하나씩 적용하는 것이 현실적입니다. 조기 최적화(premature optimization)는 개발 속도를 늦출 뿐입니다.

셋째, 영상에서는 구체적인 비용에 대해 언급하지 않습니다. Azure 매니지드 PostgreSQL의 고성능 인스턴스와 50개 이상의 복제본을 운영하는 비용은 상당할 것입니다. 작은 서비스는 이런 규모의 인프라 비용을 감당하기 어렵기 때문에, 자신의 서비스 규모와 예산에 맞는 수준으로 조정해야 합니다.

넷째, PostgreSQL의 한계도 있습니다. MVCC 설계로 인한 블로트, autovacuum 튜닝의 어려움, 복제 지연 문제 등은 여전히 숙제입니다. 이런 문제를 해결하려면 PostgreSQL에 대한 깊은 이해와 지속적인 모니터링이 필요합니다.

마지막으로, OpenAI도 미래에는 하이브리드 전략으로 전환하고 있습니다. 새로운 쓰기 워크로드를 Cosmos DB로 분산시킨다는 것은, 순수한 PostgreSQL 아키텍처만으로는 한계가 있다는 것을 인정한 것입니다. 따라서 이 영상의 내용을 “PostgreSQL로 모든 것을 해결할 수 있다”로 오해해서는 안 되며, “PostgreSQL을 최대한 활용하되 필요하면 다른 도구도 조합한다”로 이해해야 합니다.