Rust로 바꾸기 전에 고친 지연: Habitat의 이벤트 루프와 연결 재사용

OpenAI가 2026년 9월 11일 공개한 수치에 따르면 Habitat는 현재 초당 7,000만 건이 넘는 요청과 500 PB가 넘는 데이터를 처리하며, 주간 사용자 10억 명이 넘는 제품을 뒷받침한다. 다만 이 전체 규모를 Python 구현 시절의 peak 수치인 초당 2,000만 요청과 단순 전후 비교해서는 안 된다.

이벤트 루프 지연, 주기 작업, 연결 재사용, 하위 서비스 호출부터 계측한다. 이 문제들을 해결한 뒤에도 CPU·메모리 한계와 긴 꼬리 지연이 확장을 가로막고, API와 운영 경계가 안정됐다면 재작성을 검토할 수 있다.

근거는 OpenAI의 공식 엔지니어링 글이다. CPU 효율 6×와 메모리 효율 15×는 자사 운영 부하에서 측정한 결과이며 하드웨어와 정확한 부하 구성, 통계 분포는 공개되지 않았다.

Habitat는 DevDay 2023에 Azure Cosmos DB를 감싼 작은 Python 클라이언트 라이브러리로 시작했다. 2025년 중반에는 수십 개 서비스에 프로토콜 변경을 배포하기 어려워졌다. 한 팀이 다른 변경을 되돌리다가 결함 있는 클라이언트를 복구해 장애가 발생했고 OpenAI는 스토리지 로직을 독립 서비스로 옮겼다.

중앙 Habitat 서비스는 배포·관측·플랫폼 개선을 한곳에서 수행하는 경계가 됐다. 접근 제어, 감사 로그, 스토리지 접근 제한도 모을 수 있었다. 다만 중앙 서비스 자체가 새로운 병목과 장애 지점이 될 수 있어 운영 책임까지 사라진 것은 아니다.

OpenAI는 Python을 유지하는 선택을 의도적으로 받아들인 기술 부채라고 설명한다. 당시에는 비용 최적화보다 핵심 API를 확정하고 플랫폼을 안정시켜 제품 팀의 개발을 지원하는 일이 우선이었다. 목표가 바뀌는 동안 재작성하면 언어 이전과 인터페이스 변경을 동시에 감당해야 한다.

Habitat는 라우팅·압축·암호화·체크섬 계산 같은 CPU 작업도 수행했다. 스토리지 응답이 도착한 뒤에도 코루틴이 다시 실행되기를 기다려 p99 이상 지연이 길어지는 trace가 관찰됐다. OpenAI는 이벤트 루프에 주기 작업을 넣고 예정 시각과 실제 실행 시각의 차이로 스케줄링 지연을 측정했다.

백그라운드 작업과 연결 재사용도 원인이었다. 최대 8개 Python 프로세스가 1분마다 시차 없이 큰 feature flag JSON을 함께 파싱해 요청 처리가 멈췄다. 설정을 줄이고 갱신 간격을 늘리고 실행 시각에 jitter를 넣어 고쳤다. aiohttp TCPConnector의 LIFO 재사용은 느린 프로세스가 늦게 반환한 연결을 다시 선택해 부하를 몰았다. FIFO로 이 순환을 끊었고 공개 시점에는 Istio와 Envoy의 서버 부하 기반 분산을 주로 사용했다.

지연의 위치는 작은 시간선으로 나누어 볼 수 있다. 가상 요청이 0ms에 저장소를 호출하고 20ms에 응답을 받았지만, CPU를 쓰는 작업 때문에 코루틴이 80ms에 재개되어 5ms 동안 응답을 처리했다고 하자. 저장소 시간은 20ms지만 전체는 85ms이고, 응답 도착 후 대기가 60ms다. 저장소 호출만 더 빠르게 바꿔도 이 대기를 없애지는 못한다. 이는 OpenAI의 실제 trace 수치가 아니라 계측 구간을 구분하는 예시다.

연결 풀도 반환 순서로 추적할 수 있다. 가상으로 A 연결이 먼저, 느린 C 연결이 나중에 풀로 돌아오면 LIFO는 마지막에 돌아온 C를 다음 요청에 먼저 쓴다. 순간 부하 뒤에도 느린 쪽을 다시 고르는 피드백이 생길 수 있다. FIFO는 A를 먼저 고르지만, 그것만으로 모든 부하를 균등하게 만든다고 보장할 수는 없다. 연결 수·서버 상태·요청 길이가 다르므로 재사용 순서 변경 뒤에도 프로세스별 동시 요청과 꼬리 지연을 측정해야 한다.

Python Habitat도 최대 초당 2,000만 요청을 처리했다. 대신 asyncio 지연을 낮추려고 프로세스당 동시 요청을 줄이고 worker 프로세스를 크게 늘렸다. 늘어난 연결과 배포 때의 연결 교체가 하위 서비스를 압박할 수 있는 구조였다.

OpenAI는 Envoy로 Python의 HTTP/1 연결을 HTTP/2로 전환하고 다중화와 연결 풀을 적용했다. 요청 제한과 circuit breaker도 개별 Python 프로세스 대신 중앙에서 처리했다. 언어 이전 전에 연결 구조와 과부하 제어를 고친 것이다.

Habitat는 무제한 SQL이나 복잡한 join 대신 작업량을 예측할 수 있는 NoSQL API를 제공한다. 복잡한 쿼리는 CDC로 격리된 Rockset view에 보내고 각 클라이언트 팀이 해당 인스턴스를 확장한다. 온라인 스토리지는 보호되지만 제품 팀에는 별도 시스템을 운영할 부담이 생긴다.

재작성은 플랫폼이 성숙한 2026년 2분기에 이뤄졌다. OpenAI는 엔지니어 2명이 Codex와 GPT‑5.5를 사용해 전체 서비스를 Rust로 옮겼다고 밝혔다. 새 서비스는 공개 시점에 운영 요청의 95%를 처리했고 자체 측정에서 Python보다 CPU 효율은 6×, 메모리 효율은 15× 높았다. 특정 운영 부하의 결과이며 일반적인 Python 대 Rust 벤치마크가 아니다.

클라이언트 라이브러리 변경이 여러 서비스의 배포·복구에 묶여 있다면 중앙 제어 경계를 먼저 검토한다. 이어 p99 trace에서 이벤트 루프가 기다림을 만드는지, 주기 작업과 연결 재사용이 부하를 집중시키는지 측정한다. 이를 고친 뒤에도 CPU와 메모리 사용량이 비용과 SLO를 지배하면 재작성을 검토한다.

현재 언어가 목표를 충족하거나 API가 자주 바뀐다면 보류하는 편이 낫다. 동작 동등성 검사, 점진적 트래픽 전환, 복구 경로를 만들 수 없는 상황도 마찬가지이다. 더 빠른 서비스도 부하 분산과 요청 제어가 잘못되면 같은 문제를 겪을 수 있다.

도입 판단에는 Habitat의 6×·15×보다 자신의 기준선이 필요하다. 같은 트래픽 재현에서 CPU 시간, 요청당 메모리, p50·p99 지연, 이벤트 루프 지연, 하위 서비스 연결 수를 비교해야 한다. 실제 비용과 이전 검증 절차는 공개되지 않아 투자 회수 기간을 계산할 근거는 없다.

이 자료는 OpenAI의 자체 사례이며 독립 재현이 아니다. Habitat 전체의 초당 7,000만 건이 넘는 요청을 Rust 전환만의 성과로 돌릴 근거는 없다. 스토리지 계층 최적화와 멀티테넌트 안정성은 예고된 Part II의 범위여서 여기서는 판단하지 않았다.

재작성 계획에는 새 언어의 예상 성능보다 먼저 현재 병목의 측정값과 해결하지 못한 이유를 남기는 편이 좋다. 배포 경계, API 비용, 연결 부하를 정리한 뒤에도 남는 한계가 있어야 언어 이전의 효과를 비교할 수 있다.

Rapidly scaling online storage to serve over 1 billion ChatGPT users (새 창)

· OpenAI, 2026-09-11