OpenAI Habitat, 매초 7천만 건 요청을 처리하는 ChatGPT 저장소의 구조

AI를 활용하여 생성한 이미지입니다.

ChatGPT에서 대화를 여는 동작은 화면에서는 간단하지만, 서비스 안에서는 계정 상태·설정·대화·파일 같은 데이터를 여러 번 읽고 쓰는 저장 요청의 연속입니다. OpenAI는 9월 11일 공개한 글에서 온라인 저장 플랫폼 Habitat이 매초 7,000만 건이 넘는 요청을 처리하고, 매주 10억 명이 넘는 사람을 지원한다고 설명했습니다.[1] 이 수치는 모델의 답변 속도만으로는 AI 서비스를 평가할 수 없다는 점을 보여 줍니다.

Habitat은 무엇을 맡는 저장 계층인가요?

Habitat은 ChatGPT와 Codex 같은 제품이 사용하는 온라인 저장 플랫폼입니다. OpenAI에 따르면 거의 40개 지역에서 5억 페타바이트가 넘는 데이터를 다루는 분산 시스템으로 확장됐어요.[1] 사용자가 대화를 열 때 보게 되는 메시지뿐 아니라 계정 상태, 제품 설정, 새 작업에 필요한 관계형 데이터가 저장 계층을 거칠 수 있습니다.

여기서 저장소는 단순한 파일 보관함과 다릅니다. 어떤 사용자의 어떤 객체를 어느 지역에서 읽을지, 여러 요청을 어떻게 일관되게 처리할지, 장애가 나면 어느 범위까지 복구할지까지 포함하는 서비스 기반이에요. 저장 요청이 지연되면 사용자는 모델이 느리다고 느낄 수 있고, 쓰기 요청이 실패하면 대화나 설정이 이어지지 않을 수 있습니다.

작은 클라이언트에서 공통 서비스로

OpenAI는 Habitat이 약 2년 전 단일 데이터베이스에 연결된 파이썬 클라이언트 라이브러리로 시작했다고 설명합니다.[1] 제품이 커지면서 저장 로직을 독립된 서비스로 분리해 배포, 관찰, 플랫폼 개선을 한곳에서 관리하는 구조로 바꿨어요. 제품마다 저장 방식을 따로 구현하는 것보다 공통 계층을 운영하면 반복 작업과 변경 범위를 줄일 수 있다는 판단입니다.

하지만 공통 계층은 장점만 있는 구조가 아닙니다. 여러 제품이 같은 저장 서비스에 의존하면 장애의 영향 범위가 넓어질 수 있어요. 그래서 제품별로 어떤 데이터가 꼭 필요한지, 저장 서비스가 느릴 때 읽기 전용이나 제한 기능으로 전환할 수 있는지, 한 제품의 트래픽이 다른 제품을 압박하지 않는지 설계해야 합니다.

파이썬에서 러스트로 전환한 배경

OpenAI는 Habitat이 한때 파이썬으로 초당 2,000만 건 이상의 요청을 처리했지만, 더 큰 규모에 대응하기 위해 러스트 전환을 진행했다고 밝혔습니다.[1] 2026년 2분기에 엔지니어 2명과 Codex, GPT-5.5를 이용해 서비스 전체를 다시 작성했고, 글 공개 시점에는 운영 요청의 95%가 새 러스트 서비스에서 처리된다고 설명했어요.[1]

이 사례를 “파이썬은 느리고 러스트는 항상 빠르다”로 읽으면 핵심을 놓칩니다. OpenAI가 함께 살핀 항목은 CPU·메모리·네트워크·디스크 사용률뿐 아니라 비동기 이벤트 루프의 바쁨과 연결 재사용, 부하 분산이었습니다.[1] 언어 전환은 병목을 발견하고 검증한 뒤 선택한 방법이지, 측정 없이 적용할 만능 처방은 아니에요.

1. 먼저 요청을 읽기·쓰기·갱신·삭제로 나눕니다.
2. 각 경로의 지연시간과 오류율을 같은 부하에서 기록합니다.
3. CPU나 메모리뿐 아니라 연결 풀, 이벤트 루프, 디스크 대기 시간을 확인합니다.
4. 병목이 확인된 경로만 구현을 바꾸고 이전 버전과 결과를 비교합니다.
5. 트래픽을 조금씩 새 경로로 보내며 데이터 정합성과 롤백 절차를 점검합니다.

NoSQL API와 데이터 모델의 경계

OpenAI는 Habitat이 객체와 관계를 클라이언트가 미리 정의하는 NoSQL API를 사용한다고 설명합니다.[1] 제품마다 필요한 관계를 유연하게 표현하기에는 적합할 수 있지만, 데이터 모델을 잘못 잡으면 한 화면을 만들기 위해 여러 조회를 이어 붙여야 하고 지연 경로가 복잡해질 수 있어요.

따라서 대규모 저장소를 평가할 때 용량 숫자만 보면 안 됩니다. 자주 읽는 키와 관계, 한 요청이 만드는 조회 수, 지역 간 복제 여부, 데이터 삭제가 백업에 반영되는 시점, 스키마 변경의 영향 범위를 함께 봐야 합니다. 저장 용량이 충분해도 접근 패턴이 비효율적이면 체감 성능은 나빠질 수 있습니다.

서비스를 선택하거나 직접 만들 때의 체크리스트

• 계정·대화·파일 데이터의 저장 지역과 보존 기간을 확인합니다.
• 삭제 요청 뒤 원본과 백업이 언제 정리되는지 약관과 기술 문서에서 찾습니다.
• 장애 시 기존 대화를 읽을 수 있는지, 읽기 전용 전환이나 복구 목표가 있는지 봅니다.
• API의 초당 요청 한도, 재시도 규칙, 중복 쓰기 처리 방식을 정합니다.
• 지역 장애와 공통 저장 계층 장애를 분리해 복구 계획을 작성합니다.

OpenAI의 Habitat 공개는 아직 확장 과정의 1부입니다.[1] 다음 글에서 Azure Cosmos DB를 포함한 저장 계층과 5억 페타바이트 이상의 데이터를 어떻게 다루는지 설명하겠다고 예고했지만, 현재 자료만으로 장애 빈도·지역별 지연시간·비용 구조까지 판단할 수는 없습니다. 모델 이름과 벤치마크만 보지 말고, 저장·네트워크·관찰·복구를 제품의 일부로 평가해야 하는 이유가 여기에 있습니다.

자주 묻는 질문

Habitat은 ChatGPT의 모델인가요?

아니요. 공개 글에서 Habitat은 ChatGPT와 Codex 같은 제품을 뒷받침하는 온라인 저장 플랫폼으로 설명됩니다. 모델이 생성하는 계산과 계정·대화 상태를 보관하고 전달하는 저장 계층은 구분해서 봐야 합니다.

러스트로 다시 작성하면 모든 저장 요청이 빨라지나요?

그렇게 일반화할 수 없습니다. 특정 서비스의 병목, 부하, 데이터 모델, 네트워크 조건에 따라 결과가 달라져요. 언어 전환 전후의 같은 요청과 오류·지연 지표를 비교해야 합니다.

대규모 AI 서비스에서 가장 먼저 확인할 것은 무엇인가요?

초당 처리량 하나보다 내가 쓰는 데이터의 지역, 보존·삭제 정책, 장애 때 기능 범위, API 한도와 복구 절차를 먼저 확인하는 편이 실용적입니다.

처리량 숫자를 해석할 때의 주의점

매초 7,000만 건이 넘는 요청이라는 숫자는 Habitat이 처리하는 저장 요청의 규모를 보여 주지만, ChatGPT의 모든 사용자 요청이 같은 비용과 경로를 거친다는 뜻은 아닙니다.[1] 읽기와 쓰기, 작은 상태 조회와 큰 데이터 저장, 지역 내 요청과 지역 간 복제는 서로 다른 부하를 만듭니다. 따라서 처리량 하나만으로 지연시간이나 안정성을 판단하면 안 돼요.

매주 10억 명을 지원한다는 표현도 서비스가 같은 순간에 10억 명을 모두 연결한다는 뜻으로 해석해서는 안 됩니다.[1] 어떤 기간과 제품 범위를 가리키는지 원문 정의를 함께 봐야 해요. 기술 글의 큰 숫자는 비교의 출발점이지, 내가 사용하는 계정의 응답 시간이나 보존 정책을 보장하는 SLA가 아닙니다.

공통 저장 계층의 장점과 위험

저장 로직을 공통 서비스로 만들면 인증, 설정, 대화 상태를 다루는 규칙을 제품마다 다시 구현하지 않아도 됩니다. 데이터 접근 패턴과 오류 처리도 한 팀이 관찰할 수 있어요. 반면 제품 간 요구가 다른데도 하나의 API에 억지로 맞추면 불필요한 조회가 늘거나, 한 제품의 배포가 다른 제품에 영향을 줄 수 있습니다.

이 구조를 설계할 때는 기능을 통합하는 것보다 장애 경계를 먼저 정하는 것이 좋습니다. 대화 목록이 늦어도 새 대화를 시작할 수 있는지, 설정 서비스가 멈춰도 이미 열린 세션을 유지할 수 있는지, 저장 실패를 사용자에게 어떻게 알릴지 정해야 해요. “공통화”는 운영 편의를 주지만, 독립적인 장애 격리와 함께 설계되지 않으면 단일 장애 지점이 될 수 있습니다.

데이터 모델과 관찰 도구를 같이 봐야 합니다

객체와 관계를 클라이언트가 미리 정의하는 API는 제품 요구가 바뀔 때 유연성을 제공할 수 있습니다.[1] 그러나 유연한 모델일수록 어떤 조회가 어떤 저장 객체를 연쇄적으로 읽는지 문서화해야 합니다. 새로운 기능을 넣을 때 조회 수가 늘지 않는지, 지역 복제가 지연되지 않는지, 삭제 요청이 관련 객체와 백업에 모두 전달되는지 확인해야 해요.

관찰 도구도 저장 시스템의 일부입니다. 평균 지연시간만 보면 일부 사용자가 겪는 긴 지연을 놓칠 수 있으므로 p50·p95·p99를 분리하고, 지역·읽기·쓰기·오류 유형별로 나누어 기록하는 편이 좋습니다. 장애가 발생했을 때 로그에 사용자 데이터가 그대로 남지 않도록 개인정보를 마스킹하는 절차도 필요합니다.

직접 운영하는 팀을 위한 작은 시작

1. 가장 자주 쓰는 데이터 흐름 하나를 선정하고 요청 단계를 그립니다.
2. 읽기와 쓰기의 목표 지연시간, 재시도 횟수, 중복 처리 규칙을 문서화합니다.
3. 부하 테스트에서 정상·지연·부분 장애 시나리오를 각각 실행합니다.
4. 데이터 삭제와 보존 만료가 원본·복제본·백업에서 어떻게 이어지는지 확인합니다.
5. 새 구현을 일부 트래픽에만 적용하고 데이터 불일치가 없는지 읽기 전후를 비교합니다.

이 순서는 특정 언어를 선택하기 전에 병목과 운영 조건을 고정하는 데 목적이 있습니다. 파이썬에서 러스트로 바꾼 Habitat의 사례는 팀의 규모와 부하가 다른 서비스에 그대로 복사할 레시피가 아니라, 실제 측정 결과를 바탕으로 저장 계층을 다시 설계한 사례로 읽는 것이 안전합니다.[1]

Sources

• [1] OpenAI, Rapidly scaling online storage to serve over 1 billion ChatGPT users