Inside OpenAI’s in-house data agent
Blog

Inside OpenAI’s in-house data agent

2026.01.30
·Service·by 이호민
#AI#Data Agent#OpenAI#LLM#Internal Tool

핵심 포인트

  • 1OpenAI는 600 petabytes가 넘는 방대한 내부 데이터에서 신속하고 정확한 인사이트를 얻기 위해 복잡한 SQL 작성 및 데이터 탐색의 어려움을 해결하는 맞춤형 AI data agent를 개발했습니다.
  • 2이 agent는 GPT-5.2를 기반으로 metadata, human annotations, Codex enrichment, institutional knowledge, memory, runtime context 등 다층적인 context를 활용하며, self-correction과 RAG 방식으로 데이터 분석 workflow를 자동화합니다.
  • 3그 결과, 직원들은 질문에서 insight를 얻는 데 걸리는 시간을 단축하고, 반복적인 분석을 자동화하며, Evals API를 통해 지속적으로 품질을 평가하고 개선하여 신뢰할 수 있는 데이터 분석을 가능하게 합니다.

OpenAI의 내부 AI 데이터 에이전트에 대한 본 논문은 OpenAI의 방대한 데이터 플랫폼(3.5K3.5K 내부 사용자, 70K70K 데이터셋, 600600 페타바이트)에서 데이터 분석 및 인사이트 도출을 자동화하는 맞춤형 내부 도구를 상세히 설명합니다. 이 에이전트는 직원들이 복잡한 데이터 질문에 대해 몇 분 만에 답변을 얻을 수 있도록 돕는 것을 목표로 하며, 이는 과거에 며칠이 걸리던 작업이었습니다.

주요 목적 및 문제 해결:
OpenAI는 수많은 유사한 테이블과 복잡한 SQL 쿼리로 인해 데이터 분석 과정에서 발생하는 비효율성을 해결하기 위해 이 에이전트를 구축했습니다. 기존 방식에서는 사용자가 올바른 테이블을 찾는 데 많은 시간을 소비하고, 잘못된 조인(join)이나 필터(filter)로 인해 결과가 무효화되는 경우가 잦았습니다. 이 에이전트는 이러한 문제들을 해결하여 데이터 과학자 및 분석가가 SQL 디버깅 대신 지표 정의 및 가설 검증에 집중할 수 있도록 지원합니다.

핵심 방법론 (Core Methodology):

이 에이전트는 GPT-5.2를 기반으로 하며, 질문 이해부터 데이터 탐색, 쿼리 실행, 결과 종합에 이르는 분석 워크플로우 전반을 처리합니다. 특히 '자기-추론(self-reasoning)' 능력을 통해 중간 결과가 잘못되었을 경우(예: 잘못된 조인으로 인한 0개 행) 원인을 파악하고 접근 방식을 조정하여 다시 시도합니다. 이 '폐쇄 루프(closed-loop)' 및 '자기-학습(self-learning)' 프로세스는 사용자의 개입 없이 에이전트 자체적으로 반복(iteration)을 수행하여 효율성을 높입니다.

에이전트의 핵심은 '컨텍스트(Context)'를 활용하여 정확하고 신뢰할 수 있는 답변을 생성하는 것입니다. 이는 여러 계층으로 구성됩니다:

  1. Layer #1: 테이블 사용 메타데이터 그라운딩 (Table Usage Metadata grounding)
    • Schema Metadata: 컬럼 이름, 데이터 타입 등의 스키마 정보를 활용하여 SQL 작성을 안내합니다.
    • Table Lineage: 테이블 간의 상위(upstream) 및 하위(downstream) 관계를 통해 테이블들이 어떻게 연결되는지 이해합니다.
    • Query Inference: 과거 쿼리 기록을 수집하여 어떤 테이블이 일반적으로 함께 조인되고 쿼리되는지 학습하여 쿼리 생성에 활용합니다.
  1. Layer #2: 휴먼 애노테이션 (Human Annotations)
    • 도메인 전문가가 제공하는 테이블 및 컬럼에 대한 선별된 설명을 포함합니다. 이는 스키마나 과거 쿼리만으로는 파악하기 어려운 비즈니스 의미, 의도, 의미론, 알려진 주의사항(caveats)을 제공합니다.
  1. Layer #3: Codex 인리치먼트 (Codex Enrichment)
    • 코드-레벨 정의 (Code-level definition): Codex를 사용하여 테이블의 코드-레벨 정의를 도출함으로써 데이터가 실제로 무엇을 포함하고 어떻게 파생되는지에 대한 깊은 이해를 구축합니다.
    • 세부 정보 (Nuances): 값의 고유성, 테이블 데이터의 업데이트 빈도, 데이터 범위(예: 특정 필드를 제외하는지 여부) 등 테이블에 저장된 내용과 분석 이벤트에서 파생되는 방식에 대한 미묘한 정보를 제공합니다.
    • 확장된 사용 컨텍스트 (Enhanced usage context): Spark, Python 등 SQL 이외의 데이터 시스템에서 테이블이 어떻게 사용되는지에 대한 컨텍스트를 제공하여 유사해 보이지만 중요한 차이가 있는 테이블을 구별하는 데 도움을 줍니다. 이 컨텍스트는 자동으로 업데이트됩니다.
  1. Layer #4: 기관 지식 (Institutional Knowledge)
    • Slack, Google Docs, Notion과 같은 내부 문서에 접근하여 출시, 신뢰성 사고, 내부 코드명, 주요 지표의 정의 및 계산 로직과 같은 회사 컨텍스트를 파악합니다.
    • 이 문서들은 Embeddings API를 사용하여 임베딩(embedding)되고 메타데이터 및 권한과 함께 저장됩니다. 실행 시, 검색 서비스(retrieval service)가 접근 제어 및 캐싱을 처리하여 효율적이고 안전하게 정보를 가져옵니다.
  1. Layer #5: 메모리 (Memory)
    • 에이전트가 데이터 질문에 대한 수정 사항이나 미묘한 차이를 발견하면, 이러한 학습 내용을 저장하여 다음 번에 재사용할 수 있습니다. 이는 에이전트가 반복적으로 동일한 문제를 겪는 대신, 더 정확한 기준선에서 답변을 시작할 수 있도록 합니다. 메모리는 특히 다른 계층만으로는 파악하기 어려운 중요한 수정, 필터, 제약 조건을 보존하고 재사용하는 데 중요합니다. 사용자는 메모리를 수동으로 생성하고 편집할 수 있으며, 전역(global) 및 개인(personal) 수준으로 범위가 지정됩니다.
  1. Layer #6: 런타임 컨텍스트 (Runtime Context)
    • 테이블에 대한 사전 컨텍스트가 없거나 기존 정보가 오래된 경우, 에이전트는 데이터 웨어하우스에 '라이브 쿼리(live queries)'를 발행하여 테이블을 직접 검사하고 쿼리할 수 있습니다. 이를 통해 스키마를 검증하고 데이터를 실시간으로 이해하며 그에 따라 응답할 수 있습니다.
    • 또한 에이전트는 데이터 웨어하우스 외부에 존재하는 더 넓은 데이터 컨텍스트를 얻기 위해 다른 데이터 플랫폼 시스템(메타데이터 서비스, Airflow, Spark)과도 통신할 수 있습니다.

데이터 처리 흐름:
에이전트는 매일 오프라인 파이프라인을 실행하여 테이블 사용량, 휴먼 애노테이션, Codex를 통해 파생된 인리치먼트를 단일의 정규화된 표현으로 집계합니다. 이 풍부한 컨텍스트는 OpenAI Embeddings API를 사용하여 임베딩으로 변환되고 검색을 위해 저장됩니다. 쿼리 시점에는 검색 증강 생성(Retrieval-Augmented Generation, RAG)을 통해 가장 관련성 높은 임베딩된 컨텍스트만 가져오므로, 수만 개의 테이블에서도 테이블 이해가 빠르고 확장 가능하며 런타임 지연 시간이 예측 가능하고 낮게 유지됩니다. 런타임 쿼리는 필요에 따라 데이터 웨어하우스에 실시간으로 발행됩니다.

사용자 경험 및 평가:
에이전트는 대화형으로 설계되어 사용자가 질문을 따라가고, 의도를 조정하고, 방향을 변경할 수 있도록 전체 컨텍스트를 유지합니다. 지침이 불명확하거나 불완전할 경우, 에이전트는 명확한 질문을 하거나 합리적인 기본값을 적용하여 진행합니다. 반복적인 작업을 위해 워크플로우(workflows)를 통해 반복되는 분석을 재사용 가능한 지침 세트로 패키징할 수 있습니다.

품질 유지를 위해 OpenAI Evals API를 활용한 체계적인 평가를 수행합니다. 이는 질문-답변 쌍으로 구성된 큐레이션된 세트를 기반으로 하며, 에이전트가 생성한 SQL 쿼리 결과와 수동으로 작성된 '황금(golden)' SQL 쿼리 결과를 비교합니다. 평가자는 구문적 차이에도 불구하고 동일한 의미를 가질 수 있는 SQL과 결과 데이터의 정확도를 판단하여 최종 점수와 설명을 제공합니다. 이러한 Evals는 개발 중에는 지속적으로 실행되는 '단위 테스트(unit tests)' 역할을 하여 회귀(regressions)를 식별하고, 프로덕션에서는 '카나리아(canaries)' 역할을 하여 에이전트의 기능이 확장될 때 문제점을 조기에 포착합니다.

보안 및 투명성:
에이전트는 OpenAI의 기존 보안 및 접근 제어 모델에 직접 연결됩니다. 사용자에게 이미 허용된 테이블만 쿼리할 수 있도록 '패스-스루(pass-through)' 인터페이스 역할을 합니다. 또한 투명성을 위해 각 답변과 함께 추론 과정, 가정, 실행 단계를 요약하여 노출하며, 쿼리가 실행될 때 기본 결과에 직접 연결되어 사용자가 원본 데이터를 검사하고 분석의 모든 단계를 확인할 수 있습니다.

배운 교훈:

  • Less is More: 초기에는 에이전트에 모든 도구를 노출했으나 기능 중복으로 인해 문제가 발생했습니다. 명확성을 위해 도구 호출을 제한하고 통합하는 것이 더 나은 결과를 가져왔습니다.
  • Guide the Goal, Not the Path: 지나치게 지시적인 프롬프트는 에이전트를 잘못된 경로로 이끌었습니다. 대신 높은 수준의 지침을 제공하고 GPT-5의 추론에 의존하여 적절한 실행 경로를 선택하도록 함으로써 에이전트가 더 견고하고 나은 결과를 생성하게 되었습니다.
  • Meaning Lives in Code: 스키마와 쿼리 기록이 테이블의 형태와 사용법을 설명하지만, 그 진정한 의미는 데이터를 생성하는 코드에 있습니다. Codex를 통해 코드베이스를 크롤링함으로써 에이전트는 데이터셋이 실제로 어떻게 구성되는지 이해하고 각 테이블에 무엇이 포함되어 있는지 더 정확하게 추론할 수 있게 되었습니다.