초당 7000만 요청·500PB 저장소, OpenAI가 Python을 Rust로 옮긴 이유

초당 7000만 건이 넘는 요청과 500PB 이상의 데이터를 받치는 저장소가 Python에서 Rust로 중심축을 옮겼다. OpenAI의 Habitat 기술 기록은 주간 사용자 10억 명 규모의 ChatGPT, API, Codex가 어떤 온라인 저장 계층에 기대는지 구체적인 운영 수치로 보여준다. 모델 성능이 아니라 로그인, 설정 조회, 새 대화 시작을 지탱하는 데이터 경로의 이야기다.

Habitat는 처음부터 거대한 분산 시스템이 아니었다. 2년 전에는 하나의 데이터베이스에 연결하는 Python 클라이언트 라이브러리였고, 제품 엔지니어들이 각자 Postgres나 Azure Cosmos DB를 쓰는 방식을 정리하기 위해 만들어졌다. 이후 캐시, 접근 제어, 데이터 위치, 암호화, 다중 사용자 격리, 요청 제한, 스키마 조회를 한 계층에서 처리하는 서비스로 확대됐다.

성장 속도가 설계를 압박했다. OpenAI 제품 트래픽은 최근 3년 연속 해마다 10배 이상 늘었다. 보통 시스템 팀이 다음 10배를 예상하고 수년간 여유를 확보하는 방식으로는 따라가기 어려웠다. Habitat 팀은 장기 재설계만 기다리지 않고 연결 풀 조정, 부하 분산, 하위 저장소 보호, 비동기 처리 지연 감소를 차례로 적용해 용량 부족까지 남은 시간을 벌었다.

Python 서비스도 정점에서는 초당 2000만 건 이상을 처리했다. 즉 언어를 바꾼 이유는 Python이 처음부터 실패해서가 아니다. 기능 확장과 트래픽 증가로 Habitat가 OpenAI 내부에서 CPU 코어 사용량 기준 두 번째로 큰 서비스가 됐고, Envoy 사용 규모도 네 번째에 이르자 같은 요청을 더 적은 장비로 처리할 여지가 중요해졌다.

전환 규모에 비해 투입 인력은 작았다. 2026년 2분기 엔지니어 2명이 Codex와 GPT‑5.5를 활용해 서비스 전체를 Rust로 다시 작성했다. 새 Rust 서비스는 현재 운영 요청의 95%를 처리한다. OpenAI 측정에서 CPU 효율은 Python 버전의 6배, 메모리 효율은 15배였고 평균 지연과 꼬리 지연도 크게 낮아졌다. Python 경로는 앞으로 몇 주 안에 완전히 종료될 예정이다.

이 수치는 단순한 언어 성능 대결로 해석하면 놓치는 부분이 있다. 팀은 Python 재작성을 1년 미루고 더 급한 안정성 문제와 플랫폼 기능을 먼저 해결했다. 서비스 경계와 트래픽 특성이 충분히 굳은 뒤에야 Rust 전환의 비용 대비 효과가 커졌다. 생성형 AI를 이용한 재작성도 두 엔지니어의 검토와 대규모 운영 전환 절차를 대체한 것이 아니라 구현 속도를 높이는 도구로 쓰였다.

Habitat는 약 40개 지역에서 Azure Cosmos DB, 자체 온라인 저장소 Nanobase, Valkey 캐시, Blob 저장소와 여러 변경 데이터 캡처 시스템을 연결한다. 각 요청에는 데이터 거주 지역, 권한, 격리, 속도 제한 조건이 붙을 수 있다. 상위 제품은 저장소 종류를 직접 다루지 않고 Habitat를 통해 일관된 정책과 라우팅을 받는다.

이번 공개가 보여주는 변화는 AI 서비스의 병목이 GPU에만 있지 않다는 사실이다. 사용자가 한 번 대화를 열 때도 여러 데이터 조회가 필요하고, 그중 하나가 느리거나 실패하면 모델이 빨라도 제품은 멈춘다. OpenAI는 후속 글에서 다중 사용자 환경의 장애 격리, 읽기 최적화, Cosmos DB 확장 방식을 다룰 예정이다. Rust 전환 뒤에도 남는 과제는 초당 7000만 건의 저장 요청을 지역별 장애와 데이터 규정 속에서 안정적으로 유지하는 일이다.