OpenAI 600PB 데이터 탐색 혁명: 6층 문맥 시스템의 비밀

회사에 데이터가 많다는 말은 흔하지만, “600페타바이트(PB)”는 체감이 잘 안 됩니다. 쉽게 말해, 조직의 기억이 너무 커져서 기존의 검색과 분석 방식이 더는 버티지 못하는 수준이죠. OpenAI는 이 문제를 해결하기 위해 직원들이 자연어로 질문하면, 내부 데이터(70,000개 데이터셋 포함)를 빠르게 찾아 분석까지 이어주는 ‘AI 데이터 에이전트’를 만들었고, 핵심 장치로 6층 문맥(context) 시스템과 Codex Enrichment라는 방법을 꺼내 들었습니다.¹²

600PB 시대의 문제: “어디에 뭐가 있는지”가 제일 어렵다

데이터가 크면 보통 “쿼리가 느리다”를 떠올리지만, 실제 현장에서는 그 이전 단계가 더 큰 난관입니다. 같은 이름의 테이블이 여러 팀에서 각자 만들어지고, 비슷한 컬럼 구성이 여기저기 반복되며, 지표 정의가 미묘하게 달라지기 시작합니다. 어느 순간부터는 SQL을 잘 짜는 능력보다 “내가 지금 올바른 테이블을 잡고 있나?”가 더 중요해집니다.

OpenAI의 데이터 에이전트는 이런 환경을 전제로 설계되었습니다. 특히 내부에 수만 개 데이터셋이 존재하는 상황에서, 겉보기엔 유사한 테이블들 사이의 ‘중요한 차이’를 잡아내는 데 초점을 맞춥니다.²

6층 문맥 시스템: 데이터 바다에서 길 잃지 않는 지도책

OpenAI가 꺼낸 해법은 ‘문맥을 한 방에 다 넣는’ 방식이 아니라, 문맥을 6개의 레이어로 층층이 쌓아 올리는 방식입니다.¹

이 레이어들은 대략 “큰 분류 → 더 구체적 범위 → 실제 구조와 사용 맥락”으로 내려가며, 질문에 필요 없는 문맥은 과감히 덜어내고 필요한 것만 활성화하는 역할을 합니다. 덕분에 에이전트는 방대한 저장소에서 헤매지 않고, 질문과 관련된 데이터 도메인과 테이블 후보를 빠르게 좁힐 수 있습니다.

결국 핵심은 이겁니다. AI가 똑똑해지는 것도 중요하지만, 그 똑똑함을 낭비하지 않게 만드는 문맥 정리 기술이 생산성을 좌우한다는 것.

Codex Enrichment: “테이블 설명서”를 SQL이 아니라 코드에서 뽑아낸다

여기서 가장 흥미로운 포인트가 Codex Enrichment입니다. 많은 조직이 테이블 문서화를 메타데이터(스키마 설명)나 SQL 쿼리 기록에 의존하는데, 현실은 늘 빈틈이 생깁니다. 컬럼 이름은 같아도 “어떤 필터를 거쳐 들어왔는지”, “어떤 변환/집계 규칙이 숨어 있는지”는 메타데이터만으론 부족하거든요.

Codex Enrichment는 방향을 바꿉니다. 테이블을 만든 코드(생성·파이프라인 코드)를 읽어 그 테이블이 실제로 무엇을 담는지 정의를 끌어옵니다. 테이블 생성 과정에 포함된 필터링, 변환, 집계 방식까지 파악해 “이 테이블은 어떤 데이터의 결과물인가?”를 더 깊게 설명할 수 있게 됩니다.

즉, 표지만 보고 책을 고르는 게 아니라, 목차와 서문을 읽고 “이 책이 진짜 어떤 책인지”를 판단하는 방식에 가깝습니다.

자연어 데이터 분석의 함정: 텍스트-to-SQL만으로는 부족하다

자연어로 질문해서 SQL을 자동 생성하는 접근은 매력적이지만, 업계에서는 “신뢰”가 늘 논쟁거리입니다. 실제로 개발자 커뮤니티에서도 단순한 텍스트-to-SQL은 확률적 오류를 피하기 어렵고, 비즈니스 사용자가 결과를 검증하기도 힘들다는 지적이 꾸준히 나옵니다.³

OpenAI의 접근이 흥미로운 이유는, 단순히 SQL을 잘 만드는 문제가 아니라 ‘어떤 테이블이 정답인지’까지 포함해 문맥을 설계했다는 점입니다. 다시 말해, 쿼리 생성 능력만 자랑하는 게 아니라 “데이터 정의를 확보하는 방법”을 시스템 레벨에서 강화한 셈이죠.

“22분 → 1분 22초”가 말해주는 것: 분석 속도는 기억력이 좌우한다

실험 결과도 인상적입니다. 단순 질문에 대해, 메모리(문맥 축적/활용)를 쓰지 않으면 약 22분이 걸리던 응답이, 메모리를 활용하면 1분 22초로 줄었다고 합니다.¹

또한 일부 쿼리는 원래 며칠 걸리던 분석이 몇 분으로 단축될 수 있다고 알려졌습니다.¹ 이 대목에서 중요한 건 “모델이 갑자기 더 똑똑해졌다”보다, 조직 지식과 데이터 정의를 재사용 가능한 형태로 쌓아두는 구조적 기억 장치가 성능을 만든다는 점입니다.

시사점 내용 (핵심 포인트 정리 + 개인적인 생각 또는 실용적 조언)...

OpenAI 사례가 던지는 메시지는 의외로 단순합니다. 데이터가 커질수록 문제는 ‘연산’이 아니라 ‘탐색’이 되고, 탐색의 병목은 ‘SQL 실력’이 아니라 ‘정의와 문맥’이 됩니다.

그래서 조직에서 비슷한 문제를 겪고 있다면, “자연어로 쿼리하게 해보자”보다 먼저 “테이블 정의가 코드/파이프라인에 어떻게 박혀 있는지”, “비슷한 테이블이 왜 여러 개 생겼는지”, “지표의 공식이 어디에서 관리되는지”를 정리하는 게 효과가 큽니다. AI는 그 다음에 붙여도 늦지 않거든요.

참고

¹Inside OpenAI's Kepler: How a GPT-5.2-Powered Data Agent Manages 600 Petabytes of Internal Intelligence

²OpenAI’s ‘Kepler’ Unveiled: The Autonomous Agent Platform Powering the Future of Data Science

³OpenAI's In-House Data Agent | Hacker News