[글로벌 AI·AX 핫뉴스 15/100] 오픈AI 저장소 운영 공개, 공유와 격리 사이에서 찾은 서비스의 조건

AI 서비스의 응답을 기다리는 시간에는 모델이 답을 만드는 시간만 들어 있지 않다. 로그인과 설정 확인, 대화에 필요한 데이터 조회도 서비스 경험을 구성한다. OpenAI가 공개한 저장소 운영 사례는 AI 전환의 판단 범위를 모델 선택에서 그 주변의 운영 조건까지 넓혀 보여준다. 서비스가 커지는 동안 무엇을 함께 쓰고 무엇을 나눠야 했는지가 이번 사례의 핵심이다.

공유에서 분리로, 다시 공유로 돌아온 저장소

OpenAI는 10월 23일 엔지니어링 글에서 Habitat의 Azure Cosmos DB 운영 과정을 설명했다. 이 저장 플랫폼은 회사 설명상 10억 명 이상 사용자를 지원하며 40개 지리적 리전에 걸쳐 작동한다. 팀별 작업이 하나의 저장 자원을 함께 쓰면 특정 작업의 과부하가 다른 기능에 영향을 주는 문제가 있었다. 회사는 작업별 컨테이너 분리를 거쳐, 혼잡한 키의 요청을 제한하고 대량 데이터 작업보다 이용자의 상호작용 요청을 우선하는 공유 구조로 이동했다고 밝혔다.

이는 내부 운영 사례 공개다. Habitat라는 외부 상품의 정식 출시나 공개 API, 한국 출시, 신규 요금표를 발표한 글은 아니다. Azure 팀이 OpenAI를 위해 만든 개선도 언급되지만 이를 모든 고객에게 제공되는 표준 기능으로 읽을 수는 없다. 발표의 핵심은 특정 구조의 우월성보다 자원 공유와 업무별 격리를 오가며 발견한 운영상의 절충이다.

요청 수와 실제 자원 사용량은 다르다

앞서 9월 11일 공개한 1편에서 OpenAI는 저장 로직을 별도 서비스로 분리해 배포와 관측의 제어점을 모았다고 설명했다. 복잡한 임의 질의를 폭넓게 허용하기보다 단순하고 예측 가능한 요청을 지향한 설계도 소개했다. 저장소는 단순히 용량이 큰 파일함이 아니라 작업마다 부담이 다른 처리 시스템이라는 의미다.

Microsoft 문서에서 Cosmos DB의 요청 단위인 RU는 CPU와 입출력, 메모리 등 데이터베이스 작업에 필요한 자원을 묶어 표현한다. 모델의 토큰과는 다른 단위이며, 요청 한 건이 언제나 같은 자원을 쓰는 것도 아니다. 데이터 크기와 질의 복잡도 등이 소비량에 영향을 준다. 또한 논리적으로 나뉜 데이터가 같은 물리 파티션의 처리량을 나눠 쓸 수 있다. 전체 자원이 남아 보여도 일부 구간에 요청이 몰리면 제한이 발생할 수 있는 이유다.

따라서 월간 요청 수가 같은 두 서비스라도 작업 내용과 분포가 다르면 저장 계층의 부담을 같다고 볼 수 없다. 이때의 처리량은 저장 계층이 감당하는 작업량이다. 이를 모델의 답변 생성 속도나 전체 서비스의 동시 사용자 한도로 바꾸어 읽으면 측정 대상을 혼동하게 된다. 저장소 지표와 이용자 경험 지표 사이의 연결 역시 별도 확인이 필요하다.

중요 요청을 우선한다는 말의 보장 범위

혼잡할 때 무엇을 먼저 처리하는지는 기술 설정인 동시에 서비스 운영의 선택이다. 이용자가 기다리는 조회와 나중에 끝나도 되는 일괄 작업은 지연의 영향이 다르다. 다만 우선순위라는 이름만으로 핵심 업무의 응답이 보장되는 것은 아니다.

별도의 Microsoft 공개 문서에 따르면 Cosmos DB의 우선순위 기반 실행은 처리량 한도를 넘을 때 낮은 우선순위 요청을 먼저 제한하려는 기능이다. 이 기능은 최선 노력 방식이며 성능에 연결된 서비스 수준 협약은 없다. 서버리스 계정은 지원하지 않고, 공유 처리량 데이터베이스 컨테이너에서는 동작이 비결정적이라는 제한도 적혀 있다. 이 공개 기능을 OpenAI 내부 개선과 동일한 설정으로 단정하면 적용 범위를 오해하게 된다.

사례가 보여주는 원리와 고객이 실제 계약·설정으로 얻는 기능은 따로 확인할 대상이다. 운영 검토에서 의미 있는 질문은 우선순위의 이름보다 대상 작업, 한도 초과 시 처리 방식, 재시도 정책과 보장 수준이 어디까지 명시돼 있느냐다.

국내 저장 지원이 국내 추론을 뜻하지는 않는다

국내에서 이 사례를 읽을 때는 글로벌 인프라의 규모와 이용 계약의 데이터 위치 조건을 구분할 필요가 있다. 지리적 리전 수만으로 한국 이용자의 데이터가 어디에 머무는지 알 수는 없다. 별도의 OpenAI API 데이터 통제 문서에서 한국 리전은 지역 내 저장을 지원하지만 지역 내 처리는 지원하지 않는 것으로 표시돼 있다. 지역 접속 주소는 kr.api.openai.com이며, MAM 또는 ZDR 승인이 필요한 조건이 붙는다. 미국 외 리전의 데이터 레지던시에는 악용 모니터링 통제 승인과 보존 조건 변경 약정도 요구된다.

문서는 처리 지원이 없는 리전의 고객 콘텐츠가 서비스 제공을 위해 역외에서 처리되거나 일시 저장될 수 있다고 명시한다. 계정·사용량 등 시스템 데이터도 레지던시 적용 대상에서 제외된다. 이는 API의 조건이며 ChatGPT 전체 상품의 국내 처리 보장으로 확대할 수 없다.

국내 조직이 비교할 항목은 한국어 지원 여부만이 아니라 사용하는 엔드포인트와 모델, 저장과 처리의 구분, 예외 데이터의 범위다. 이번 발표만으로 국내 도입 실적이나 규정 충족 여부가 확인되는 것은 아니다.

캐시의 빠른 응답과 비용은 조건을 붙여 읽는다

운영 자료를 검토할 때는 지연, 최신성, 과금의 경계를 함께 읽는 방식이 유용하다. 이를 보여주는 별도 사례가 Cosmos DB의 통합 캐시다. Microsoft 문서는 캐시에 적중한 읽기가 RU를 소비하지 않는다고 설명한다. 그러나 통합 캐시를 담는 전용 게이트웨이는 시간 단위로 과금되므로 RU가 0이라는 설명을 전체 비용이 0이라는 뜻으로 바꿀 수 없다.

캐시는 원본을 매번 다시 읽는 대신 저장해 둔 결과를 활용한다. 문서에는 세션·최종 일관성 읽기만 지원하며 강한 일관성 등의 읽기는 원본 데이터베이스로 우회한다고 돼 있다. 요청별로 허용할 데이터의 오래된 정도를 설정할 수 있다는 조건도 있다. 이 기능이 Habitat에 그대로 적용됐다고 단정할 수는 없지만, 빠른 읽기의 조건을 해석하는 배경 자료는 된다.

국내 서비스의 검토 질문도 구체적일 수 있다. 어떤 조회에 최신 결과가 필요한지, 캐시 밖 요청은 어디서 처리되는지, 별도 컴퓨팅 비용이 포함되는지, 혼잡 때 지연되는 업무는 무엇인지다. 각 답은 해당 서비스의 문서와 계약, 실제 측정으로 채워질 사항이며 이 사례가 특정 비용 절감률이나 응답 속도를 보장하지는 않는다.

이용자에게는 하나의 AI 답변으로 보이지만, 그 뒤에는 조회와 저장, 혼잡 제어가 이어진다. Habitat의 운영 공개는 이 과정의 선택을 드러낸다. 성능을 읽는 범위가 모델의 정답률에서 서비스가 요청을 받아 처리하는 조건까지 넓어지고 있다.

글로벌 AI·AX 핫뉴스 연재 모아보기 →