오픈AI, 10억 챗GPT 사용자 지원하는 저장소 플랫폼 'Habitat' 공개

10억 명이 넘는 사용자가 매일 ChatGPT와 대화할 때 백엔드 데이터베이스는 어떻게 버티고 있을까.

OpenAI 엔지니어링 팀은 10월 23일 공식 블로그를 통해 40개 지역에서 500페타바이트(PB) 이상의 데이터를 처리하는 자체 스토리지 플랫폼 'Habitat'의 확장 과정을 공개했습니다. 마이크로소프트 애저 코스모스 DB(Azure Cosmos DB)를 기반으로 극한의 최적화를 거친 기록입니다.

'시끄러운 이웃'에서 '출시 당일 장애'로 이어진 시행착오

초기 OpenAI는 단순하게 모든 데이터를 하나의 공유 컨테이너에 넣었습니다. 하지만 특정 부가 기능에서 트래픽이 폭증하면 동일한 물리적 파티션을 공유하던 로그인이나 가입 같은 핵심 기능까지 마비되는 '시끄러운 이웃(Noisy Neighbor)' 문제가 빈번하게 터졌습니다.

게다가 저장 데이터가 늘어나 물리적 파티션이 분할될수록 파티션당 할당되는 처리량 한도가 오히려 줄어드는 구조적 문제도 나타났습니다.

이를 해결하고자 각 서비스별로 독립된 전용 컨테이너를 할당하는 방식을 도입했습니다. 장애 격리에는 성공했지만 이번엔 조직 운영이 꼬였습니다. 개발팀들이 사전 용량 산정을 잊은 채 기능을 배포해, 서비스 출시 날마다 장애 대응 회의실에서 급하게 컨테이너 용량을 늘리는 악순환이 반복됐습니다.

애저 팀과의 밀착 협업과 Rust 재작성

결국 OpenAI는 다시 멀티테넌트 방식으로 유턴하며 애저 팀과 손을 잡고 '공동 관리 컨테이너' 체계를 구축했습니다.

특정 핫키(Hot Key)만 골라내 먼저 트래픽을 제한하고, 대량 배치 작업보다 사용자 대화 요청을 우선 처리하는 QoS 등급제를 적용했습니다.

여기에 사용자와 가까운 리전에 데이터를 분산 배치하고, 지연 시간에 민감한 데이터만 선별 복제하는 기법을 더했습니다. 프록시 계층을 Rust 언어로 전면 재작성하고 캐시를 통합한 결과, 500PB 규모의 데이터를 다루면서도 읽기 속도를 12배나 끌어올렸습니다.

왜 중요한가

초거대 AI 서비스를 지탱하는 진짜 난제는 모델 학습뿐 아니라 전 세계 사용자의 실시간 상태를 보관하는 스토리지 엔지니어링에 있음을 잘 보여줍니다.

일반 개발사나 인프라 엔지니어가 500PB 규모의 설계를 그대로 따라 할 필요는 없습니다. 하지만 시스템 격리에만 집착하다가 조직 전체의 운영 비용이 감당하기 힘들 정도로 커졌던 OpenAI의 실패 사례는 클라우드를 쓰는 조직이라면 누구나 눈여겨볼 대목입니다.

자체 분산 데이터베이스를 바닥부터 새로 만드는 대신 클라우드 제공업체와 협력해 기존 솔루션의 한계를 밀어붙인 선택은 매우 영리했습니다. 다만 코스모스 DB의 내부 메커니즘에 인프라가 이토록 깊숙이 결합되면서, OpenAI가 향후 특정 클라우드 종속에서 벗어나 멀티 클라우드로 전환하기는 훨씬 더 어려워진 것으로 보입니다.