OpenAI, Habitat 스토리지 아키텍처 공개: 매주 10억 명 넘게 사용하는 규모와 한계

2026년 9월 11일, OpenAI는 공식 엔지니어링 블로그에 「Rapidly scaling online storage to serve over 1 billion ChatGPT users」라는 제목의 글을 게시하고, 사내 스토리지 플랫폼 Habitat이 지난 몇 년간 Python 클라이언트 라이브러리에서 독립적으로 운영되는 서비스로 발전해 온 과정을 설명했습니다. 이 글은 Engineering(엔지니어링) 카테고리에 속하며, 저자로 기술 인력 3명 Jon Lee, Chaomin Yu, Ben Ries의 이름이 실려 있고, 글 말미에는 엔지니어 채용 공고 링크가 첨부되어 있습니다. 이는 신제품이나 신규 요금제 발표가 아니라 기술 블로그 글입니다.

본 기사는 2026년 9월 18일에 OpenAI의 공식 글 원문, OpenAI의 공식 뉴스 RSS 피드, 공식 사이트맵의 Engineering 카테고리 페이지를 확인했습니다. openai.com의 글 페이지는 그 이전 며칠 동안 접근 제한 페이지만 반환하기도 했으나, 확인 당일에는 본문을 바로 읽을 수 있었습니다. 아래 수치는 모두 OpenAI 자신의 설명이며, 본 사이트는 직접 시험해 보지 않았고, 구매나 이용에 관한 어떠한 조언도 제공하지 않습니다. 본 기사에서는 가상의 생활 시나리오를 사용하지 않았습니다.

이 글은 무엇인가: 신제품 발표가 아니라 엔지니어링 블로그 글

OpenAI는 이 글을 Engineering(엔지니어링) 카테고리로 분류하고, Habitat을 자체적으로 구축한 온라인 스토리지 플랫폼이라고 설명합니다. 이를 통해 산하 제품이 필요한 데이터를 빠르고 안정적으로 가져올 수 있다고 하며, 사용자가 로그인하거나 Codex 설정을 확인하거나 ChatGPT에서 새 대화를 시작하는 것 모두 이면에서 여러 차례의 데이터 조회를 수반할 수 있다고 설명합니다. OpenAI는 이런 조회가 느려지면 제품 자체가 느리게 느껴지고, 조회가 실패하면 제품이 그대로 작동하지 않는다고 적었습니다.

글 서두의 통계 블록에는 초당 7000만 건이 넘는 요청, 매주 10억 명이 넘는 사용자, 500PB가 넘는 데이터량이라는 세 가지 수치가 나란히 제시되어 있습니다. OpenAI의 설명에 따르면 Habitat은 원래 2023년 DevDay에서 GPTs를 지원하기 위해 등장했으며, 처음에는 단일 데이터베이스에 연결되는 단순한 Python 클라이언트 라이브러리였지만 지금은 복잡한 분산 시스템으로 성장했습니다.

글 말미에는 엔지니어 채용 공고 링크가 첨부되어 있으며(URL에 시애틀이라는 지명이 포함되어 있습니다), 이는 스토리지를 주제로 한 2부작 시리즈의 첫 번째 글입니다. 두 번째 글에서는 멀티테넌시 안정성, 읽기 성능을 위한 계층화 전략, Azure Cosmos DB와의 협력을 어떻게 확대했는지를 다룰 예정입니다. 공식 사이트맵과 뉴스 피드를 2026년 9월 18일까지 확인한 결과, 두 번째 글에 해당하는 항목은 아직 보이지 않으며 날짜도 발표되지 않았습니다.

OpenAI가 말하는 규모: 몇 가지 수치를 함께 읽어야 하는 이유

OpenAI는 본문에서 Habitat이 현재 초당 7000만 건이 넘는 요청을 처리하고, 산하 제품은 매주 10억 명이 넘는 사람이 사용하며, 서비스 범위는 40개에 가까운 지역에 걸쳐 있다고 밝힙니다. 글은 해당 지역의 국가명이나 도시명을 나열하지 않으며, 스스로 '단순화'한 것이라고 밝힌 모식도에 us0, us1, eu0이라는 세 가지 예시 데이터베이스 코드만 등장합니다. 이는 그림 속 라벨일 뿐, 공개된 지역 목록이 아닙니다.

주목할 점은 OpenAI의 공식 RSS 피드와 페이지 메타데이터에 별도로 '22M requests per second'라고 적혀 있다는 것입니다. 그러나 본 기사가 확인 당일 본문 전체를 다시 읽어 본 결과, 이 수치는 요약과 메타데이터에만 등장할 뿐 본문에서는 한 번도 다시 언급되지 않았으며, 7000만이나 2000만과 어떤 관계인지도 설명되어 있지 않습니다.

OpenAI는 또한 지난 3년간 매년 10배가 넘는 성장을 기록했다고 설명합니다. 글 본문에는 시스템 엔지니어들이 보통 현재 규모의 10배를 염두에 두고 설계하며, 이것이 몇 년은 버티기를 바라는 동시에 다음 10배에도 대비한다는 문장이 있습니다.

느려진 조회 하나를 사용자가 체감할 수 있는 이유

OpenAI의 설명에 따르면 일반 사용자의 요청 한 건 이면에서 수백 건의 데이터베이스 호출이 발생할 때, 사용자가 체감하는 것은 그중 가장 느린 한 건입니다. 글은 이렇게 소수의 유난히 느린 조회, 즉 '테일 레이턴시(tail latency)'를 관리하는 일을 이 규모에서 Python 서비스를 운영할 때의 주된 과제라고 부릅니다.

글은 한 가지 사례를 제시합니다. Habitat은 기능 플래그를 관리하는 도구 Statsig를 사용하는데, 기본값으로 시간차 없이 1분마다 갱신된 설정을 폴링합니다. 이 설정에는 모든 서비스의 모든 프로덕션 규칙이 포함되어 있습니다. 여기에 '파드 하나당 Python 프로세스는 최대 8개까지 실행한다'는 아키텍처 결정이 겹치면서, 매분마다 각 파드에서 어느 한 순간에 모든 워커 프로세스가 처리 중이던 요청을 멈추고 대신 그 거대한 설정 파일을 파싱하는 데 CPU를 쓰는 상황이 벌어졌습니다. OpenAI는 CPU 프로파일링으로 근본 원인을 찾아낸 뒤에는 해결책이 단순했다고 말합니다. 범위를 좁힌 설정을 배포하고, 폴링 주기를 늘리고, 이런 백그라운드 작업에 무작위 시간차를 추가하는 것입니다.

또 다른 사례는 커넥션 풀과 관련이 있습니다. OpenAI에 따르면 Python의 aiohttp 라이브러리는 기본적으로 가장 최근에 반환된 커넥션을 우선적으로 재사용하도록 되어 있으며, 이는 평소에는 합리적인 기본값입니다. 그러나 요청이 급증할 때는 느리고 이미 과부하된 서버일수록 커넥션을 풀에 더 늦게 반환하기 때문에 오히려 이후 요청에 더 자주 선택되고, 트래픽이 점점 이미 버거운 파드로 몰리게 됩니다. OpenAI는 이를 일종의 '준안정 장애(metastable failure)'라고 부릅니다. 과부하를 일으킨 클라이언트가 멈춘 뒤에도 일부 프로세스는 계속 악화되며, 재시작을 해야만 회복되는 현상입니다. 가장 먼저 반환된 커넥션을 우선하는 방식으로 바꾸자 피드백 루프가 해소됐을 뿐 아니라, 정상 상태에서의 요청량 편차도 함께 줄어들었습니다. 현재 이런 커넥션 관리는 대부분 Istio와 Envoy가 맡고 있습니다.

OpenAI가 이 글에서 설명하지 않은 것

본 기사는 영어 원문 표현을 그대로 대조했으며, 글에는 durability, backup, replica라는 단어가 등장하지 않고, 데이터 한 건을 몇 개의 복제본으로 보관하는지도 나와 있지 않습니다. OpenAI가 설명한 것은 가장 중요한 데이터셋을 여러 지역에 분산된 Azure Cosmos DB 계정으로 옮기고 싶었다는 경위를 한 차례 언급한 것뿐이며, 이는 단일 지역 장애의 영향 범위를 줄이기 위해서라고 밝혔지만 그 이상의 보관이나 이중화 메커니즘은 설명하지 않았습니다. 글에는 가용성 수치나 서비스 수준 계약(SLA)도 없으며, 자사 시스템에서 실제로 있었던 몇 가지 상황만 설명합니다. 예를 들어 한 팀이 무관한 이유로 문제가 있는 클라이언트가 포함된 구버전으로 자신들의 서비스를 롤백했다가, 오히려 그토록 피하려 애썼던 장애를 일으킨 사례가 있지만, 날짜나 지속 시간, 사용자에게 미친 실제 영향은 나와 있지 않습니다.

지역과 관련해서는 글에 40개에 가까운 지역이라고만 나와 있을 뿐, 어떤 국가나 도시도 데이터 보관 장소로 명시하지 않았고, 대만이나 아시아도 언급하지 않았습니다. 지역 정보에 가장 가까운 것은 모식도에 있는 세 가지 데이터베이스 코드와 채용 공고 링크 URL에 포함된 도시명입니다. 글은 또한 Habitat이 실제로 어떤 데이터를 저장하는지도 명확히 밝히지 않습니다. 로그인, Codex 설정 확인, 새 대화 시작은 모두 데이터 조회를 수반할 수 있다고 하지만, 대화 내용 자체가 Habitat에 저장되는지는 명확히 밝히지 않고, 이곳이 외부, 내부, 에이전트에 의한 무단 접근으로부터 사용자 데이터를 지키는 핵심 지점이라고만 말합니다.

Rust로 다시 작성한 뒤의 수치도 마찬가지입니다. OpenAI는 자체 데이터에 따르면 새 버전이 CPU 효율은 6배, 메모리 효율은 15배가 됐고 평균 지연과 테일 레이턴시 모두 크게 줄었다고 하며, 현재 프로덕션 요청의 95%를 처리하고 있고 앞으로 몇 주 안에 Python 버전을 완전히 폐지할 계획이라고 밝혔습니다. OpenAI는 또 앞으로 더 많은 경험을 공유하는 글을 하나 더 낼 예정이라고 했지만, 이 후속 글 역시 날짜는 발표되지 않았습니다. 글에는 테스트 방법이나 테스트 시나리오, 제3자 검증이 첨부되어 있지 않아 이 수치들은 현재로서는 OpenAI가 스스로 발표한 내부 측정 결과로만 볼 수 있습니다.

독자는 이 글을 어떻게 받아들이면 좋을까

이 글은 신제품, 신규 요금제, 신규 지역, 신규 설정 중 어느 것도 발표하지 않았으므로 ChatGPT나 Codex 사용자가 이 때문에 무언가를 바꿀 필요는 없습니다. OpenAI 스스로도 글에서 사용자가 더 빠르거나 더 저렴하다고 체감할 것이라고 주장하지 않으며, 다시 작성한 효과는 현재로서는 OpenAI 내부의 설명에 그칩니다.

이 글은 오히려 다음과 같은 사실을 일깨워 주는 자료로 받아들이는 편이 적절합니다. 어떤 서비스든 그 이면에는 저마다의 스토리지와 가용성 설계가 있으며, 운영사가 스스로 발표하는 규모 수치는 요청량이든 사용자 수든 성장 배수든 제3자의 검증이 있기 전까지는 어디까지나 그 업체 자신의 설명일 뿐입니다. 독자는 이런 글이 내구성, 서비스 수준 계약, 장애 세부 사항을 언급하는지 살펴보는 것이 좋습니다. 이는 흔히 눈에 띄는 수치 하나보다 서비스의 안정성을 더 잘 보여줍니다.

후속 소식을 직접 확인하고 싶은 독자는 OpenAI의 뉴스 RSS 피드와 Engineering 카테고리 사이트맵이라는 두 가지 무료 공식 채널을 스스로 확인할 수 있습니다. 본 기사도 바로 이 두 채널을 이용해 두 번째 글이 아직 나오지 않았음을 확인했습니다. 다만 사이트맵에 표시된 시각은 페이지에 인쇄된 게시일과 맞지 않으므로 글의 게시일이나 수정일로 여겨서는 안 되며, 이는 본 기사가 확인 당일에 관찰한 내용입니다.

2026년 AI 뉴스 총정리: 1월부터 9월까지의 핵심과 일상 적용

OpenAI와 Broadcom, Jalapeño 칩 공개: 공식 발표가 말하는 단계, 역할 분담, 그리고 아직 밝히지 않은 것

• AI 도구
• 앱·소프트웨어
• AI 뉴스