OpenAI 내부 데이터 에이전트 - 질문에서 인사이트까지 수 분 만에
목차
개요
OpenAI가 자사 내부에서 사용하는 맞춤형 AI 데이터 에이전트를 공개했다. 이 에이전트는 OpenAI의 데이터, 권한, 워크플로에 특화된 내부 전용 도구이며 외부에 제공되는 제품은 아니다.
OpenAI의 데이터 플랫폼은 3,500명 이상의 내부 사용자가 사용하며, 600페타바이트 이상의 데이터와 7만 개의 데이터셋을 포함한다. 이 에이전트는 자연어로 질문하면 수 분 안에 인사이트를 제공하여, 기존에 며칠이 걸리던 데이터 분석 작업을 크게 단축한다. Engineering, Data Science, Go-To-Market, Finance, Research 등 전사 조직이 이 에이전트를 활용하고 있다.
에이전트 구축에 사용된 도구는 Codex, GPT-5 플래그십 모델, Evals API, Embeddings API이다. 이는 모두 외부 개발자에게도 제공되는 도구들이다.
맞춤형 데이터 에이전트가 필요한 이유
테이블 탐색의 어려움
600페타바이트 규모의 데이터에서 올바른 테이블을 찾는 것 자체가 분석에서 가장 시간이 많이 드는 작업이다. 내부 사용자의 표현을 빌리면 다음과 같다.
“비슷한 테이블이 너무 많고, 차이점을 파악하는 데 많은 시간을 쓴다. 로그아웃 사용자를 포함하는 테이블도 있고 아닌 것도 있다. 겹치는 필드가 있어서 뭐가 뭔지 구분하기 어렵다.”
정확한 결과 생성의 어려움
올바른 테이블을 선택한 후에도 정확한 결과를 생산하는 것은 쉽지 않다. 분석가는 테이블 데이터와 테이블 간 관계를 이해하여 변환과 필터를 올바르게 적용해야 한다.
일반적인 실패 유형은 다음과 같다.
- 다대다(many-to-many) 조인
- 필터 푸시다운 오류
- 처리되지 않은 NULL 값
이러한 오류는 결과를 조용히 무효화할 수 있다. OpenAI 규모에서 분석가가 SQL 의미론이나 쿼리 성능 디버깅에 시간을 쏟는 것은 비효율적이다. 분석가의 초점은 지표 정의, 가정 검증, 데이터 기반 의사결정에 있어야 한다.
에이전트 동작 방식
아키텍처
에이전트는 GPT-5.2로 구동되며 OpenAI의 데이터 플랫폼에 대해 추론하도록 설계되었다. 직원들이 이미 업무에 사용하는 곳에서 접근할 수 있다.
| 접근 방식 | 설명 |
|---|---|
| Slack Agent | Slack 내 에이전트 |
| Web Interface | 웹 기반 인터페이스 |
| IDE | 개발 환경 내 통합 |
| Codex CLI (MCP) | MCP를 통한 Codex CLI 연동 |
| Internal ChatGPT (MCP) | 내부 ChatGPT 앱 MCP 커넥터 |
분석 프로세스
에이전트는 복잡하고 개방적인 질문을 end-to-end로 처리한다. 질문 이해 → 데이터 탐색 → 쿼리 실행 → 결과 종합의 전체 분석 워크플로를 수행한다.
예를 들어 “NYC 택시 여행에서 출발지-도착지 ZIP 쌍 중 일반 이동시간과 최악의 이동시간 차이가 가장 큰 곳은 어디인가?”라는 질문을 처리할 수 있다. 에이전트는 약 21,000건의 여행 데이터를 탐색하고, 중앙값(p50)과 최악값(p95)을 정의하고, 필터를 적용하여 결과를 도출한다.
자기 교정(Self-Correction) 능력
에이전트의 핵심 강점은 문제를 추론하는 방식에 있다. 고정된 스크립트를 따르는 대신 자체 진행 상황을 평가한다. 중간 결과가 잘못된 경우(예: 잘못된 조인이나 필터로 인해 결과가 0행인 경우), 에이전트는 원인을 조사하고 접근 방식을 조정한 후 다시 시도한다. 이 과정에서 전체 컨텍스트를 유지하며 단계 간 학습을 이어간다.
이 폐쇄 루프(closed-loop) 자기 학습 프로세스는 반복 작업을 사용자가 아닌 에이전트 자체로 이동시킨다. 결과적으로 수동 워크플로보다 더 빠르고 일관되게 높은 품질의 분석을 제공한다.
6계층 컨텍스트 시스템
고품질 답변은 풍부하고 정확한 컨텍스트에 의존한다. 컨텍스트 없이는 강력한 모델도 사용자 수를 크게 오추정하거나 내부 용어를 잘못 해석할 수 있다. 에이전트는 6개의 컨텍스트 계층으로 구성되어 OpenAI의 데이터와 제도적 지식에 기반한다.
Layer 1 - 테이블 사용 정보 (Table Usage)
스키마 메타데이터(컬럼명, 데이터 타입)를 기반으로 SQL 작성을 안내한다. 테이블 리니지(상류/하류 테이블 관계)를 활용하여 테이블 간 관계를 파악한다. 과거 쿼리 이력을 수집하여 쿼리 작성 방법과 일반적으로 함께 조인되는 테이블을 이해한다.
Layer 2 - 휴먼 어노테이션 (Human Annotations)
도메인 전문가가 작성한 테이블과 컬럼에 대한 선별된 설명이다. 스키마나 과거 쿼리에서 쉽게 추론할 수 없는 의도, 의미론, 비즈니스 의미, 알려진 주의사항을 담고 있다. 메타데이터만으로는 테이블을 구분하기에 충분하지 않으며, 테이블이 어떻게 생성되었고 어디에서 기원하는지 이해해야 한다.
Layer 3 - Codex 보강 (Codex Enrichment)
테이블의 코드 수준 정의를 도출하여 데이터가 실제로 무엇을 포함하는지에 대한 깊은 이해를 구축한다. Codex가 코드베이스에서 추출하는 정보는 다음과 같다.
| 추출 항목 | 내용 |
|---|---|
| 테이블 목적 | 테이블이 존재하는 이유와 용도 |
| 그레인 및 기본 키 | 데이터의 세분화 수준과 고유 식별자 |
| 하류 사용 패턴 | SQL 외에 Spark, Python 등에서의 활용 방식 |
| 대안 테이블 옵션 | 유사하지만 다른 테이블 목록 |
| 데이터 신선도 | 데이터 업데이트 주기와 최신성 |
이를 통해 에이전트는 외관상 유사하지만 중요한 차이가 있는 테이블을 구분할 수 있다. 예를 들어 특정 테이블이 1st-party ChatGPT 트래픽만 포함하는지 여부를 판별할 수 있다. 이 컨텍스트는 자동으로 갱신되어 수동 유지보수 없이 최신 상태를 유지한다.
Layer 4 - 제도적 지식 (Institutional Knowledge)
에이전트는 Slack, Google Docs, Notion에 접근할 수 있다. 이 문서들에는 다음과 같은 핵심 회사 컨텍스트가 포함된다.
- 제품 출시 정보
- 안정성 인시던트
- 내부 코드명과 도구
- 핵심 지표의 정규 정의와 계산 로직
문서들은 수집, 임베딩, 메타데이터 및 권한과 함께 저장된다. 런타임 시 검색 서비스가 접근 제어와 캐싱을 처리하여 효율적이고 안전하게 정보를 가져온다.
예를 들어 “12월에 커넥터 사용량이 왜 떨어졌는가?”라는 질문에 대해, 에이전트는 2025년 11월 13일부터 시작된 로깅 이슈로 ChatGPT 5.1 출시 이후 사용량이 과소 집계되었다는 원인을 설명할 수 있다.
Layer 5 - 메모리 (Memory)
에이전트가 수정 사항을 받거나 데이터 질문에 대한 뉘앙스를 발견하면, 다음번을 위해 학습 내용을 저장한다. 이후 답변은 동일한 문제를 반복적으로 겪는 대신 더 정확한 기준선에서 시작한다.
메모리의 목표는 데이터 정확성에 중요하지만 다른 계층만으로는 추론하기 어려운 비자명적 수정, 필터, 제약 조건을 유지하고 재사용하는 것이다. 예를 들어 특정 분석 실험을 필터링할 때 실험 게이트에 정의된 특정 문자열과 매칭해야 하는 경우, 메모리가 없으면 에이전트는 퍼지 문자열 매칭을 시도하여 잘못된 결과를 생성한다.
에이전트가 수정을 받거나 대화에서 학습을 발견하면 메모리에 저장할 것을 제안한다. 사용자가 수동으로 메모리를 생성하고 편집할 수도 있다. 메모리는 글로벌과 개인 수준으로 범위가 지정된다.
Layer 6 - 런타임 컨텍스트 (Runtime Context)
테이블에 대한 사전 컨텍스트가 없거나 기존 정보가 오래된 경우, 에이전트는 데이터 웨어하우스에 실시간 쿼리를 발행하여 테이블을 직접 검사할 수 있다. 이를 통해 스키마를 검증하고 데이터를 실시간으로 이해하며 응답한다.
에이전트는 웨어하우스 외부에 존재하는 광범위한 데이터 컨텍스트를 얻기 위해 메타데이터 서비스, Airflow, Spark 등 다른 데이터 플랫폼 시스템과도 통신할 수 있다.
컨텍스트 파이프라인
일일 오프라인 파이프라인이 테이블 사용 정보, 휴먼 어노테이션, Codex 보강 데이터를 단일 정규화된 표현으로 집계한다. 이 보강된 컨텍스트는 OpenAI Embeddings API를 사용하여 임베딩으로 변환되어 저장된다. 쿼리 시점에 에이전트는 원시 메타데이터나 로그를 스캔하는 대신 RAG를 통해 가장 관련성 높은 임베딩된 컨텍스트만 가져온다. 이를 통해 수만 개의 테이블에서도 빠르고 확장 가능한 테이블 이해가 가능하며, 런타임 레이턴시를 예측 가능하고 낮게 유지한다.
동료처럼 사고하고 협업하는 에이전트
대화형 반복 탐색
대부분의 질문은 한 번의 답변으로 해결되지 않는다. 정확한 결과에 도달하려면 반복적인 정제와 방향 수정이 필요하다.
에이전트는 턴 간 완전한 컨텍스트를 유지한다. 사용자는 모든 것을 다시 설명하지 않고도 후속 질문을 하거나 의도를 조정하거나 방향을 바꿀 수 있다. 에이전트가 잘못된 방향으로 진행하면 사용자가 분석 도중에 개입하여 리디렉션할 수 있다.
명확화 질문과 기본값
지시가 불명확하거나 불완전할 때 에이전트는 선제적으로 명확화 질문을 한다. 응답이 없으면 합리적인 기본값을 적용하여 진행한다. 예를 들어 사용자가 날짜 범위 없이 비즈니스 성장을 물으면, 최근 7일 또는 30일을 가정할 수 있다.
워크플로 자동화
출시 후 사용자들이 반복적인 분석을 자주 실행하는 것이 관찰되었다. 이를 효율화하기 위해 에이전트의 워크플로(Workflow) 기능이 반복 분석을 재사용 가능한 지시 세트로 패키징한다. 주간 비즈니스 리포트, 테이블 검증 등이 워크플로의 예시이다. 컨텍스트와 모범 사례를 한 번 인코딩하면 사용자 간 일관된 결과를 보장할 수 있다.
평가 파이프라인
에이전트의 응답 품질을 측정하고 보호하기 위해 OpenAI Evals API를 활용한다.
평가 구조
평가는 선별된 질문-답변 쌍으로 구성된다. 각 질문은 정확히 맞추는 것이 중요한 핵심 지표나 분석 패턴을 대상으로 한다. 수동으로 작성된 “골든” SQL 쿼리가 예상 결과를 생성한다.
평가 프로세스
- 자연어 질문을 쿼리 생성 엔드포인트에 전송한다.
- 생성된 SQL을 실행하고 예상 SQL의 결과와 비교한다.
- 단순 문자열 매칭이 아닌 SQL과 결과 데이터를 모두 비교한다.
- OpenAI Evals 채점기가 최종 점수와 설명을 생성한다.
생성된 SQL은 구문이 달라도 정확할 수 있고, 결과 셋에 답에 영향을 미치지 않는 추가 컬럼이 포함될 수 있다. 이러한 허용 가능한 변이를 반영하여 평가한다.
이 평가는 개발 중에 지속적으로 실행되는 유닛 테스트와 같은 역할을 하며, 프로덕션에서는 카나리 역할을 수행한다. 이를 통해 에이전트의 기능이 확장되더라도 문제를 조기에 발견하고 자신 있게 반복할 수 있다.
보안 모델
에이전트는 OpenAI의 기존 보안 및 접근 제어 모델에 직접 연결된다. 순수한 인터페이스 레이어로 작동하며, OpenAI 데이터를 관리하는 동일한 권한과 가드레일을 상속하고 적용한다.
에이전트의 모든 접근은 엄격한 패스스루(pass-through) 방식이다. 사용자는 이미 접근 권한이 있는 테이블만 쿼리할 수 있다. 접근 권한이 없으면 이를 알리거나 사용자가 사용 권한이 있는 대안 데이터셋으로 폴백한다.
투명성을 위해 에이전트는 각 답변과 함께 가정과 실행 단계를 요약하여 추론 과정을 노출한다. 쿼리가 실행되면 기저 결과에 직접 링크하여 사용자가 원시 데이터를 검사하고 분석의 모든 단계를 검증할 수 있다.
교훈
에이전트를 처음부터 구축하면서 얻은 세 가지 실질적 교훈이다.
Lesson 1 - 적을수록 좋다 (Less is More)
초기에 전체 도구 세트를 에이전트에 노출했더니 기능 중복으로 인한 문제가 발생했다. 이 중복성은 사람이 수동으로 호출할 때는 유용할 수 있지만, 에이전트에게는 혼란을 준다. 모호성을 줄이고 신뢰성을 높이기 위해 특정 도구 호출을 제한하고 통합했다.
Lesson 2 - 목표를 안내하되 경로를 지시하지 마라 (Guide the Goal, Not the Path)
매우 지시적인(prescriptive) 프롬프팅이 결과를 저하시킨다는 것을 발견했다. 많은 질문이 일반적인 분석 형태를 공유하지만, 세부 사항은 충분히 달라서 경직된 지시가 에이전트를 잘못된 경로로 밀어붙였다. 고수준 가이던스로 전환하고 GPT-5의 추론에 의존하여 적절한 실행 경로를 선택하게 하자 에이전트가 더 강건해지고 더 나은 결과를 생산했다.
Lesson 3 - 의미는 코드에 있다 (Meaning Lives in Code)
스키마와 쿼리 이력은 테이블의 형태와 사용 방법을 설명하지만, 진정한 의미는 테이블을 생성하는 코드에 있다. 파이프라인 로직은 SQL이나 메타데이터에서 절대 드러나지 않는 가정, 신선도 보장, 비즈니스 의도를 담고 있다. Codex로 코드베이스를 크롤링함으로써 에이전트는 데이터셋이 실제로 어떻게 구성되는지 이해하고 각 테이블이 실제로 무엇을 포함하는지에 대해 더 잘 추론할 수 있다. 웨어하우스 신호만으로는 “여기에 무엇이 있는가”와 “언제 사용할 수 있는가”에 정확히 답하기 어렵다.