초당 7,000만 요청을 파이썬으로 버틴 오픈AI의 저장 플랫폼 해비탯

오픈AI는 2026년 9월 11일 공개한 엔지니어링 글에서 자사 온라인 저장 플랫폼 해비탯(Habitat)이 초당 7,000만 건 이상의 요청과 500페타바이트 이상의 데이터를 처리하며 주간 10억 명 이상이 쓰는 제품을 약 40개 지역에서 떠받치고 있다고 밝혔다. 해비탯은 2024년 중반 애저 코스모스 DB 하나에 붙은 작은 파이썬 라이브러리로 시작했고, 2026년 2분기에 엔지니어 두 명과 코덱스와 GPT-5.5가 전체 서비스를 러스트로 다시 썼다. ASAP은 오픈AI 기술진 존 리, 차오민 유, 벤 리스가 쓴 1부 글에서 확인되는 수치와 설계 결정만으로 이 플랫폼이 무엇을 포기하고 무엇을 얻었는지 정리한다.

해비탯은 제품 코드에서 데이터베이스를 지우기 위해 만든 계층이다

해비탯의 출발점은 제품 엔지니어가 데이터베이스 관리를 생각하지 않아도 되게 하자는 발상이다. 2024년 중반 ChatGPT 메인 서버와 통신하는 작은 파이썬 라이브러리로 시작했고, 지원하는 연산 집합은 작았으며 내부적으로는 애저 코스모스 DB로 매핑됐다.

라이브러리가 대신 처리한 항목은 글에 그대로 나열돼 있다. 스키마 조회, 라우팅, 인가, 암호화, 직렬화, 요청 정형화, 커넥션 풀링이다. 제품 개발자는 데이터가 애저 코스모스 DB에서 오는지 캐시에서 오는지도 신경 쓸 필요가 없었다.

효과는 채택률로 나타났다. 셀프서비스 포스트그레스와 애저 코스모스 DB에서 옮겨 오라는 중앙의 강한 압박이 없었는데도 오픈AI 제품 엔지니어들 사이에서 빠르게 퍼졌다고 글은 적었다. 클라이언트 측 캐싱, 압축, 암호화 같은 기능을 제품 개발자가 공유 라이브러리에 직접 추가하는 일도 쉬웠다.

라이브러리를 서비스로 옮긴 계기는 막으려던 장애를 그대로 맞은 사건이다

전환 시점은 2025년 중반이고 이유는 배포 조율 비용이었다. 단일 지역 장애의 폭발 반경을 줄이려고 가장 중요한 데이터셋을 지역 분산 애저 코스모스 DB 계정으로 옮기려 했을 때, 팀은 클라이언트에 라우팅 로직을 추가하고 기능 플래그 뒤에 숨긴 뒤 모든 클라이언트에 배포하고 나서야 플래그를 켤 수 있었다.

수십 개 서비스에 배포를 맞추는 데 며칠이 걸렸다. 샤딩 로직이 맞는지 확인할 섀도잉을 넣는 데 또 며칠, 잘못된 부분을 고치는 데 또 며칠이 들었다. 마침내 플래그를 켤 준비가 됐을 때 한 팀이 무관한 이유로 예전 버그 있는 클라이언트로 롤백했고, 그토록 피하려던 장애가 그대로 발생했다.

서비스로 분리하면서 얻은 것은 배포와 관측과 플랫폼 개선의 단일 통제점이다. 글은 보안 측면도 함께 들었다. 접근 제어 정책을 중앙에서 강제하고 감사 로깅을 수행하며 애저 코스모스 DB 같은 저장 자원 접근을 제한하는 단일 병목 지점이 생겼고, 외부와 내부와 에이전트 행위자의 무단 접근을 막는 역할을 해비탯이 맡는다고 적었다.

파이썬을 고수한 결정은 성능 판단이 아니라 부채 일정표였다

오픈AI는 파이썬 서비스가 열등한 선택임을 알면서 골랐다고 명시했다. 글의 표현은 전략적 기술 부채 감수(strategic incursion of technical debt)이며, 당시 목표가 비용이나 자원 최적화가 아니라 제품 개발자의 병목 해소와 플랫폼 안정화였다고 밝혔다. 100배 규모에서는 파이썬의 비효율이 용납되지 않을 것이므로 언젠가 재작성이 거의 확실하다는 인식도 함께 적혔다.

여기서부터는 ASAP의 해석이다. 이 대목은 인프라 글에서 보기 드물게 부채를 사후 변명이 아니라 사전 일정으로 다룬다. 보통의 기술 부채 서사는 급해서 대충 만들었고 나중에 갚았다는 순서를 따르는데, 해비탯은 갚을 시점과 갚을 방법을 미리 정해 두고 부채를 일으켰다.

주목할 부분은 상환 수단에 대한 베팅이다. 글은 자사 코딩 모델의 급속한 발전이 미래의 기술적 경로를 단순화하리라는 계산된 내기를 했다고 적었다. 전면 이전이 필요해질 무렵이면 코덱스와 GPT가 그 이전을 해낼 수 있게 되리라 봤고, 그 내기가 결국 맞았다고 밝혔다. 자기 회사 제품의 미래 성능을 인프라 로드맵의 전제로 깔 수 있는 조직은 극히 드물다는 점에서, 이 결정은 다른 회사가 그대로 복제하기 어려운 종류다.

꼬리 지연을 만든 범인은 설정 파일 파싱과 커넥션 재사용 순서였다

파이썬 서비스의 실제 문제는 처리량이 아니라 꼬리 지연이었다. 평균 사용자 요청 하나가 수백 번의 데이터베이스 호출로 이어지므로 가장 느린 호출이 사용자가 체감하는 값이 된다고 글은 설명했다. asyncio는 I/O 병행성을 주지만 GIL을 우회해 CPU 병렬성을 주지는 않는데, 해비탯은 라우팅, 압축, 암호화, 체크섬, 다운스트림 헬스체크, 요청 섀도잉, 헤징 같은 CPU 작업을 함께 짊어지고 있었다.

측정 방식은 단순하다. 배경 작업을 주기적으로 예약하고 예상 실행 시각과 실제 실행 시각의 차이를 기록해 이벤트 루프 스케줄링 지연을 실시간으로 잰다. 높은 사용률에서는 프로세스당 동시 요청이 많지 않아도 수백 밀리초, 일부 극단 사례에서는 수 초의 스케줄링 지터가 생겼다. 그래서 프로세스마다 소수의 동시 요청만 맡기고 파이썬 워커 프로세스 수를 대규모로 늘리는 방향을 택했다.

첫 번째 범인은 기능 플래그였다. 스탯시그(Statsig)가 기본값으로 1분마다 지터 없이 설정을 갱신했고, 그 설정에는 모든 서비스의 모든 프로덕션 규칙이 들어 있었다. 별개로 파드당 파이썬 프로세스를 최대 8개까지 띄우는 결정이 있었기 때문에, 매분 각 파드의 모든 워커가 처리 중인 요청을 멈추고 거대한 설정 파일을 파싱하는 순간이 생겼다. 해법은 대상을 좁힌 작은 설정 배포와 갱신 주기 연장과 배경 작업 지터 추가였다.

두 번째 범인은 커넥션 풀의 재사용 순서다. 파이썬 aiohttp의 TCPConnector는 기본적으로 LIFO 재사용을 쓰는데, 가장 최근에 반환된 커넥션을 다음 요청에 고른다. 버스트 구간에서는 느리고 과부하된 서버가 커넥션을 늦게 반환하므로 이후 요청에 더 자주 선택됐고, 이미 힘든 파드에 트래픽이 점점 몰렸다. 부하 균형을 손보기 전 꼬리 프로세스는 평균의 5배에서 10배에 이르는 동시 요청을 처리하고 있었다. FIFO 재사용으로 패치하자 이 피드백 루프가 끊겼고 정상 상태의 요청 분산 편차까지 줄었다.

프로세스를 늘린 대가는 다운스트림 쪽에서 청구된다

프로세스를 대규모로 늘리는 전략에는 청구서가 따라붙는다. 글은 이를 천둥소리 무리(thundering herd) 문제로 부르며, 튜닝하지 않은 일상 배포가 커넥션 순환만으로 상당한 CPU 급등을 일으키거나 커넥션 누수가 NAT 게이트웨이를 포화시켜 네트워크를 마비시킬 수 있다고 적었다. 다른 서비스에도 드물지 않은 문제지만, 프로세스가 한 자릿수 배수가 아니라 한 자릿수 자릿수만큼 많으면 촉발 임계가 크게 낮아진다는 것이 차이다.

해법으로 쓰는 계층이 엔보이(Envoy)다. 파이썬의 HTTP/1 커넥션을 HTTP/2로 승격해 멀티플렉싱을 활용하고, 그 커넥션을 풀링하며 수명을 늘린다. 각 파이썬 프로세스에 흩어져 있으면 효과가 떨어지는 속도 제한과 서킷 브레이커도 엔보이에 모았다. 커넥션 풀링과 부하 인지 균형은 현재 이스티오(Istio)와 엔보이에 맡겨 문제 자체를 회피하고 있다고 글은 밝혔다.

쿼리를 일부러 약하게 만든 설계가 파이썬을 여기까지 끌고 왔다

파이썬을 이 규모까지 끌고 온 진짜 이유로 글이 꼽은 것은 제한된 API다. 해비탯은 클라이언트가 임의의 SQL을 짜서 대규모 테이블 스캔이나 다중 조인을 일으키게 두지 않고, 단순한 NoSQL API만 노출한다. 강력한 API의 부재는 설계상 명시적 트레이드오프라고 적혀 있다.

근거로 제시된 경험은 포스트그레스 시절이다. 초기에는 모든 쿼리와 스키마 변경을 검토해 인덱스를 타는지 확인할 수 있었지만, 팀과 제품이 커지자 관리가 불가능해졌고 핫 경로의 값비싼 쿼리 하나가 데이터베이스를 통째로 무너뜨리는 장애가 잦았다. 문제의 본질은 비용 불균형이며, 실행하기 비싸고 어려운 SQL을 쓰기는 싸고 쉽다는 점이라고 글은 정리했다.

데이터 모델은 메타의 TAO에서 영감을 받은 객체와 엣지 구조다. 클라이언트가 객체와 엣지 타입과 관계를 미리 정의하되 각 타입의 내용은 정의하지 않으며, 결과는 그래프처럼 보이지만 해비탯은 특정 객체의 직접 엣지 조회를 벗어난 일반적인 그래프 순회 쿼리를 지원하지 않는다. 객체와 그 엣지는 저장소 수준 파티션에 함께 놓지만, 엣지가 가리키는 원격 객체까지 같은 곳에 모으려는 노력은 하지 않는다. 수평 확장은 쉬워지고 그래프 순회는 비효율적이 되는 교환이며, 한 홉이 서로 다른 지역의 서로 다른 애저 코스모스 DB 계정 조회를 부를 수도 있다.

복잡한 쿼리가 필요한 팀에는 탈출구를 따로 뒀다. 변경 데이터 캡처(CDC)로 온라인 저장소의 변경을 격리된 록셋(Rockset) 인스턴스로 준실시간 스트리밍하고, 각 클라이언트 팀이 자기 록셋 인스턴스 확장을 책임진다. 마찰이 생기지만 단순 쿼리를 기본값으로 두고 복잡한 쿼리에 탈출구를 주는 편이 지금 시점에 맞는 교환이라고 글은 평가했다.

엔지니어 두 명이 분기 하나에 러스트로 다시 쓴 결과가 1부의 결론이다

재작성 시점은 2026년 2분기이고 투입 인원은 엔지니어 두 명과 코덱스와 GPT-5.5다. 이 조합이 서비스 전체를 러스트로 다시 썼고, 새 러스트 서비스가 현재 프로덕션 요청의 95%를 처리하며 파이썬은 몇 주 안에 완전히 폐기될 예정이다. 오픈AI가 공개한 측정치는 러스트 서비스가 파이썬 버전보다 CPU 효율 6배, 메모리 효율 15배이며 평균 지연과 꼬리 지연이 모두 유의미하게 낮다는 것이다.

재작성 직전 해비탯의 위치도 함께 공개됐다. 코어 수 기준 오픈AI에서 두 번째로 큰 서비스였고 엔보이 사용량 기준으로는 네 번째였다. 파이썬이 감당한 최고치는 초당 2,000만 건 이상의 요청이다.

이 숫자들을 어떻게 읽어야 할지는 나눠서 봐야 한다. 인상적인 쪽은 인원이다. 초당 수천만 요청을 받는 시스템의 언어 전환을 두 명이 한 분기에 끝냈다는 사실은, 재작성 비용을 인건비와 일정으로 환산해 온 기존 판단 기준을 흔든다. 반면 신중히 볼 쪽은 배수다. CPU 6배와 메모리 15배는 파이썬 대비 러스트의 일반적인 기대치 범위 안에 있으므로, 이 수치 자체가 코딩 모델의 성과는 아니다. 모델이 기여한 지점은 효율 배수가 아니라 이전에 걸리는 시간이며, 두 값은 분리해서 읽어야 한다.

한국 팀이 이 글에서 실제로 가져갈 것은 규모가 아니라 순서다

국내 조직 대부분은 초당 7,000만 요청을 다룰 일이 없지만, 이 글에서 재사용 가능한 부분은 규모가 아니라 결정의 순서다. 첫째, 스케줄링 지연을 별도 지표로 재는 습관이다. CPU와 메모리와 네트워크와 디스크의 사용률 및 포화도 지표에 더해 asyncio 루프가 얼마나 바쁜지를 감시하고 그에 맞춰 튜닝하는 것이 파이썬 서비스에서 중요하다고 오픈AI는 명시했다. 파이썬이나 노드 기반 API 서버를 돌리는 팀이라면 오늘 추가할 수 있는 계측이다.

둘째, 라이브러리와 서비스의 경계다. 공유 클라이언트 라이브러리는 초기에 빠르지만 변경 한 건이 수십 개 서비스의 조율을 요구하는 순간 비용 구조가 뒤집힌다. 오픈AI가 그 전환점을 판단한 기준은 성능이 아니라 배포 조율 실패였고, 이 기준은 규모와 무관하게 적용된다.

셋째, API를 일부러 약하게 만드는 선택이다. 사내 공용 데이터 계층을 만들 때 기능을 많이 주는 쪽이 친절해 보이지만, 해비탯의 교훈은 예측 가능한 고정 비용 요청만 허용하고 복잡한 쿼리는 분리된 읽기 전용 경로로 밀어내는 구조가 운영을 단순하게 만든다는 것이다. 여기서 중요한 것은 금지가 아니라 탈출구를 함께 제공했다는 점이며, 록셋 경로가 없었다면 이 제약은 우회 시도로 무너졌을 것이다.

1부가 남긴 공백은 검증 가능한 비교치와 상세한 조건이다

글이 공개하지 않은 항목도 분명히 해 둘 필요가 있다. 가장 큰 공백은 러스트 전환 수치의 조건이다. CPU 효율 6배와 메모리 효율 15배가 어떤 워크로드와 어떤 트래픽 구성에서 측정됐는지, 지연이 얼마나 낮아졌는지의 구체 값은 제시되지 않았고, 추후 블로그에서 더 공유하겠다고만 적혔다.

두 번째 공백은 재작성 과정의 실제 분업이다. 엔지니어 두 명과 코덱스와 GPT-5.5라는 구성만 나올 뿐, 모델이 생성한 코드의 비율이나 검토 방식이나 마이그레이션 중 사고 유무는 언급되지 않았다. 코딩 모델의 실전 성능을 판단하려는 독자에게 가장 필요한 정보가 빠져 있는 셈이다.

세 번째 공백은 시리즈 구성 자체다. 다중 테넌시 신뢰성, 계층화된 읽기 성능 최적화 전략, 애저 코스모스 DB와의 협업 확장은 모두 2부로 미뤄졌다. 500페타바이트와 초당 7,000만 요청을 실제로 받아 내는 저장 계층 이야기가 2부에 있으므로, 1부만으로 해비탯의 확장성을 평가하기에는 이르다.

정리하면 이 글은 규모 자랑이 아니라 순서에 관한 기록이다. 오픈AI는 3년 연속 전년 대비 10배 이상 성장하는 동안 최적의 구현을 고르는 대신 지금 막아야 할 문제를 고르는 방식을 택했고, 파이썬의 비효율을 이자로 지불하면서 제품 속도를 샀다. 그 부채를 자사 코딩 모델로 상환했다는 결말이 이번 1부의 진짜 주제다.

출처: 오픈AI 엔지니어링 블로그 'Rapidly scaling online storage to serve over 1 billion ChatGPT users'(2026년 9월 11일, Jon Lee·Chaomin Yu·Ben Ries)