▲

OpenAI의 사내 데이터 에이전트 들여다 보기

 (openai.com)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • OpenAI는 3,500명 이상 내부 사용자와 600PB 규모 데이터를 효율적으로 분석하기 위해 맞춤형 AI 데이터 에이전트를 자체 구축
  • 자연어 질문만으로 테이블 탐색, SQL 실행, 노트북 및 리포트 발행까지 엔드투엔드 분석 워크플로를 자동 처리
  • 6개 계층의 컨텍스트(테이블 사용, 사람 주석, Codex 기반 코드 분석, 조직 지식, 메모리, 런타임 컨텍스트)를 결합해 정확도를 확보
  • 중간 결과가 잘못되면 스스로 원인을 조사하고 접근 방식을 수정하는 자기 학습 폐쇄 루프 구조로 운영
  • Evals API 기반의 체계적 평가 시스템으로 품질 회귀를 조기 탐지하며, 기존 보안·권한 모델을 그대로 상속해 신뢰성 유지

맞춤형 데이터 에이전트가 필요한 이유

  • OpenAI의 데이터 플랫폼은 3,500명 이상 내부 사용자와 600페타바이트 규모 데이터, 7만 개 이상의 데이터셋을 보유하며, 올바른 테이블을 찾는 것 자체가 분석에서 가장 시간이 많이 소요되는 작업
  • 유사한 테이블이 많아 로그아웃 사용자 포함 여부, 필드 중복 등 테이블 간 차이를 파악하기 어려운 상황
  • 올바른 테이블을 선택해도 many-to-many 조인, 필터 푸시다운 오류, null 미처리 등이 결과를 무효화할 수 있음
  • 분석가는 SQL 디버깅이 아닌 메트릭 정의, 가정 검증, 데이터 기반 의사결정에 집중해야 함

에이전트의 작동 방식

  • GPT-5.2 기반으로 구동
  • Slack 에이전트, 웹 인터페이스, IDE, Codex CLI(MCP 연동), 내부 ChatGPT 앱 등 직원이 이미 사용하는 환경에서 접근 가능
  • 복잡하고 개방형인 질문도 처리 가능
    • 질문 이해
    • 데이터 탐색
    • SQL 실행
    • 결과 분석 및 요약까지 엔드투엔드 수행
    • 예: NYC 택시 데이터셋에서 픽업-드롭오프 ZIP 쌍의 이동 시간 변동성이 가장 큰 조합을 분석
  • 고정된 스크립트를 따르지 않고 자체 진행 상황을 평가하며, 중간 결과가 잘못되면(예: 잘못된 조인이나 필터로 인한 0행 결과) 원인을 조사하고 접근 방식을 수정해 재시도
  • 전체 분석 워크플로를 커버: 데이터 발견, SQL 실행, 노트북 및 리포트 발행, 내부 지식 참조, 웹 검색, 메모리 기반 학습

컨텍스트 계층 구조

  • Layer 1: 테이블 사용(Table Usage)

    • 메타데이터 그라운딩: 스키마 메타데이터(컬럼명, 데이터 타입)를 SQL 작성에 활용하고, 테이블 리니지(상위·하위 테이블 관계)로 테이블 간 관계 파악
    • 쿼리 추론: 과거 쿼리를 수집해 에이전트가 자체 쿼리 작성 방식과 일반적으로 조인되는 테이블 조합을 학습

  • Layer 2: 사람 주석(Human Annotations)

    • 도메인 전문가가 테이블과 컬럼에 대해 큐레이션된 설명을 작성하며, 의도, 의미론, 비즈니스 맥락, 알려진 주의사항 등 스키마나 과거 쿼리에서 유추하기 어려운 정보를 포착
    • 메타데이터만으로는 테이블을 구별하기 어려우므로 생성 방식과 출처에 대한 이해가 필수

  • Layer 3: Codex 기반 코드 분석(Codex Enrichment)

    • 테이블의 코드 수준 정의를 도출해 데이터의 실제 내용을 깊이 이해
      • 값의 고유성, 테이블 데이터 갱신 빈도, 데이터 범위(특정 필드 제외 여부, 세분화 수준) 등 분석 이벤트 기반의 뉘앙스 제공
    • SQL 외에 Spark, Python 등 다양한 데이터 시스템에서의 사용 맥락 파악 가능
    • 유사해 보이지만 핵심적으로 다른 테이블 구별 가능(예: 1st-party ChatGPT 트래픽만 포함하는 테이블 여부)
    • 이 컨텍스트는 자동으로 갱신되어 수동 유지보수 불필요

  • Layer 4: 조직 지식(Institutional Knowledge)

    • Slack, Google Docs, Notion 등에서 런치, 장애 사례, 내부 코드네임, 핵심 메트릭의 정규 정의와 계산 로직 등 회사 컨텍스트를 수집
    • 문서를 수집·임베딩·메타데이터 및 권한과 함께 저장하며, 런타임에 액세스 제어와 캐싱을 처리하는 검색 서비스 운영

  • Layer 5: 메모리(Memory)

    • 에이전트가 수정 사항을 받거나 데이터 질문의 뉘앙스를 발견하면 이를 저장해 다음 분석 시 더 정확한 기준선에서 시작
    • 메모리의 목표는 다른 계층에서 추론하기 어려운 비자명한 수정, 필터, 제약 조건을 보존·재사용하는 것
      • 예: 특정 분석 실험을 필터링할 때 실험 게이트에 정의된 특정 문자열 매칭이 필요했으나, 메모리 없이는 퍼지 문자열 매칭을 시도하는 오류 발생
    • 수정이나 학습 발견 시 에이전트가 메모리 저장을 유도하며, 사용자가 수동으로 생성·편집도 가능
    • 글로벌 수준과 개인 수준으로 메모리 범위 구분

  • Layer 6: 런타임 컨텍스트(Runtime Context)

    • 테이블에 대한 사전 컨텍스트가 없거나 정보가 오래된 경우 데이터 웨어하우스에 라이브 쿼리를 발행해 스키마 검증 및 실시간 데이터 파악
    • 메타데이터 서비스, Airflow, Spark 등 Data Platform의 다른 시스템과도 통신해 웨어하우스 외부의 데이터 컨텍스트 획득

  • 일일 오프라인 파이프라인 및 RAG

    • 테이블 사용, 사람 주석, Codex 기반 강화 정보를 단일 정규화 표현으로 집계하는 일일 오프라인 파이프라인 운영
    • 강화된 컨텍스트를 OpenAI Embeddings API로 임베딩 변환 후 저장하고, 쿼리 시 RAG(Retrieval-Augmented Generation) 로 관련 컨텍스트만 검색
    • 수만 개 테이블에 걸쳐 테이블 이해를 빠르고 확장 가능하게 유지하며, 런타임 레이턴시를 예측 가능하고 낮게 유지

팀원처럼 사고하고 협업하는 설계

  • 원샷 답변이 아닌 대화형 반복 탐색을 지원하며, 턴 간 완전한 컨텍스트를 유지해 후속 질문이나 방향 전환 시 처음부터 다시 설명할 필요 없음
  • 에이전트가 잘못된 방향으로 진행 중이면 사용자가 분석 중간에 개입해 리디렉션 가능
  • 지시가 불명확하면 명확화 질문을 선제적으로 제시하고, 응답이 없으면 합리적 기본값(예: 최근 7일 또는 30일)을 적용해 진행
  • 반복적으로 동일 분석이 수행되는 패턴을 관찰한 후, 반복 분석을 재사용 가능한 워크플로(instruction set) 로 패키징
    • 주간 비즈니스 리포트, 테이블 검증 등이 예시
    • 컨텍스트와 모범 사례를 한 번 인코딩해 사용자 간 일관된 결과 보장

신뢰를 유지하면서 빠르게 개선하는 평가 체계

  • 항상 진화하는 에이전트이므로 품질 드리프트가 쉽게 발생 가능하며, 체계적 평가 없이는 회귀가 보이지 않게 진행
  • OpenAI Evals API 기반으로 질문-답변 쌍의 큐레이션된 세트를 구축하며, 각 질문에 수동으로 작성한 "골든" SQL 쿼리를 대응
  • 자연어 질문을 쿼리 생성 엔드포인트로 전송, 생성된 SQL을 실행한 뒤 예상 SQL 결과와 비교
  • 단순 문자열 매칭이 아니라 SQL과 결과 데이터를 모두 비교하고 Evals 그레이더에 투입해 정확도와 허용 변동을 반영한 최종 점수 및 설명 산출
  • 이 평가는 개발 중 지속적으로 실행되는 유닛 테스트 역할을 하며, 프로덕션의 카나리 역할로 회귀를 조기 포착

에이전트 보안

  • OpenAI의 기존 보안 및 액세스 제어 모델에 직접 연결되며, 동일한 권한과 가드레일을 인터페이스 계층으로 상속·적용
  • 모든 접근은 패스스루 방식으로, 사용자가 이미 권한이 있는 테이블만 쿼리 가능하며, 권한이 없으면 이를 알리거나 대안 데이터셋으로 폴백
  • 투명성을 위해 추론 과정을 공개: 가정과 실행 단계를 답변과 함께 요약하고, 실행된 쿼리의 원본 결과에 직접 링크해 사용자가 모든 분석 단계를 검증 가능

구축 과정에서 얻은 교훈

  • Lesson 1: 적을수록 좋음(Less is More)

    • 초기에 전체 도구 세트를 에이전트에 노출했으나 기능 중복으로 인한 혼란 발생
    • 인간이 수동 호출 시에는 유용한 중복 기능이 에이전트에게는 모호함을 야기하므로, 특정 도구 호출을 제한하고 통합해 신뢰성 향상

  • Lesson 2: 경로가 아닌 목표를 안내(Guide the Goal, Not the Path)

    • 매우 지시적인 프롬프팅은 결과를 오히려 저하시킴
    • 질문마다 세부 사항이 달라 경직된 지시가 에이전트를 잘못된 경로로 유도하므로, 상위 수준 가이던스를 제공하고 GPT-5의 추론에 실행 경로 선택을 위임하는 방식이 더 우수

  • Lesson 3: 의미는 코드에 있음(Meaning Lives in Code)

    • 스키마와 쿼리 이력은 테이블의 형태와 사용 방식만 설명하며, 진정한 의미는 테이블을 생성하는 코드에 존재
    • 파이프라인 로직이 가정, 신선도 보장, 비즈니스 의도를 포착하며 이는 SQL이나 메타데이터에 드러나지 않음
    • Codex로 코드베이스를 크롤링해 데이터셋의 실제 구축 방식을 이해함으로써, 웨어하우스 신호만으로는 불가능한 "무엇이 들어 있는가"와 "언제 사용할 수 있는가" 에 대한 정확한 답변 가능

향후 방향

  • 모호한 질문 처리 능력 향상, 더 강력한 검증을 통한 신뢰성·정확도 개선, 워크플로 통합 심화를 지속 추진 중
  • 별도 도구가 아닌 사람들이 이미 일하는 방식에 자연스럽게 녹아드는 형태를 지향
  • 에이전트 추론, 검증, 자기 수정의 기반 기술 향상에 따라 지속 발전하며,
    팀의 미션은 OpenAI 데이터 생태계 전반에 빠르고 신뢰할 수 있는 데이터 분석을 원활하게 제공하는 것
▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 신뢰성과 설명 가능성이 가장 큰 문제임
    우리는 10년째 Veezoo에서 자연어 분석을 개발 중인데, 단순한 Text-to-SQL 접근은 확장성이 떨어짐
    CFO가 매출을 물을 때 99%만 맞는 숫자는 의미가 없고, CFO가 SQL을 직접 검증할 수도 없음
    그래서 우리는 Knowledge Graph라는 추상화 계층을 두어, AI가 자연어를 의미 기반 질의 언어로 변환하고 이를 결정론적으로 SQL로 컴파일함
    반대로 이 의미 질의를 다시 자연어 설명으로 변환해 사용자가 결과가 의도에 맞는지 쉽게 검증할 수 있게 함
    비즈니스 로직은 Knowledge Graph에 존재하고, 컴파일러가 모든 질의가 이를 100% 따르도록 보장함
    자세한 구조는 Veezoo Architecture 문서에 정리되어 있음

    • 링크 공유 고마움. 아키텍처 개요가 매우 인사이트 있었음
      궁금한 점은 카디널리티 폭발을 어떻게 관리하는지, 그리고 이전 쿼리 결과에 의존하는 다중 쿼리 요청은 어떻게 처리하는지임
    • 그래도 생성된 SQL 산출물은 버전 관리와 단위 테스트가 필요하지 않음?
      어떤 날짜에 어떤 쿼리가 사용되었고 어떻게 검증되었는지를 추적할 수 있어야 함
      (물론 프롬프트도 버전 관리 대상임)

  • 첫 번째 예시가 완전히 비논리적이라 놀랐음
    이게 인간 검수를 통과했다면 아마 AI가 작성한 것 같고, 그렇다면 시스템의 신뢰성에 의문이 생김
    문제의 이미지 링크

  • 여러 BI 시스템을 써본 경험상, 이런 AI 에이전트는 완벽한 사용 사례라고 생각함
    BI는 본래 여러 층위에서 오류가 발생함 — 쿼리 자체가 틀리거나, 데이터를 해석하는 방식이 틀림
    이 두 가지가 합쳐지면 이미 ‘가상의 세계’에 들어간 셈이라, 차라리 AI가 1단계를 맡는 게 나음
    OpenAI가 신뢰성 문제를 해결했을까 기대했지만, 아쉽게도 그렇지 않았음

    • 잊지 말아야 할 점이 있음
      0단계: 데이터를 잘못 저장함
      -1단계: 모델링 자체를 잘못 이해함
      -2단계: 비즈니스 프로세스가 처음부터 틀림
      그래서 나는 ‘단일 진실의 원천’ 대신 ‘단일 거짓의 원천’이라고 부름

  • 신뢰를 확장하는 게 가장 어려운 부분임
    우리도 비슷한 걸 만들고 있는데, 아무리 에이전트 루프가 좋아도 결국 사람이 큐레이션한 표준 지표(canonical metrics) 가 필요함
    그렇지 않으면 비기술직 사용자는 검증 불가능한 SQL로 위험한 결정을 내리게 됨
    우리의 접근법은

    1. 데이터 파이프라인을 직접 통제하고, 고객 간 스키마가 일관된 데이터 소스만 사용함
    2. 검증된 지표가 있을 때는 그것을 사용하고, 없을 때만 SQL로 대체하며, 그 차이를 인간 검토 대상으로 기록함
      시간이 지나면 대부분의 쿼리가 표준 지표를 사용하게 되고, 에이전트는 단순 SQL 생성기가 아니라 의도→검증된 지표로의 스마트 라우터가 됨
      “신뢰를 깨지 않고 빠르게 움직이기” 섹션의 골든 SQL 평가 시스템도 같은 통찰을 담고 있음
      관련 글은 이 블로그 포스트에 정리했음
    • 맞음, 명확한 시맨틱 레이어가 꼭 필요함
      답으로 가는 경로가 여러 개면 서로 다른 결과가 나옴
      LLM은 종종 의미 없는 ‘xyz_index’ 같은 지표를 만들어내는데, 사용자들이 그럴듯하다고 믿고 그냥 써버림

  • 내 생각에 AI가 개발자 일자리에 미칠 진짜 영향은 데이터와 문서 품질임
    기업의 데이터가 얼마나 잘 정리되어 있느냐가 AI 활용 효율을 결정함
    공개 데이터는 이미 고갈됐고, 다음 자원은 내부 문서, 코드 저장소, 데이터 레이크임
    이런 기반이 잘 되어 있는 회사는 AI로 새로운 서비스를 빠르고 저렴하게 만들고 유지할 수 있음
    반대로 문서와 코드 관리가 엉망인 회사는 AI가 제대로 작동하지 않음
    결국 경쟁사에게 시장을 빼앗기게 될 것임
    그래서 앞으로 구직할 때는 문서·데이터·저장소 관리 수준을 꼭 물어볼 생각임

    • 문서와 데이터, 저장소 관련해서 구체적으로 어떤 점을 보고 좋은 아키텍처와 나쁜 아키텍처를 구분하는지 궁금함

  • Amplitude에서 Moda라는 비슷한 시스템을 만들었음
    수개월 전 Wade가 Claire Vo에게 데모 영상을 보여줬는데 정말 훌륭했음
    나는 매일 이걸로 다양한 질문을 던지며 사용 중임

  • 우리도 비슷한 기능을 Definite.app에서 5분 만에 제공함
    Spark나 Snowflake가 필요 없음
    데이터레이크, 파이프라인, 시맨틱 레이어, 데이터 에이전트를 하나의 앱으로 제공함
    사실 에이전트 자체보다 데이터 인프라 구축이 훨씬 어려움
    에이전트가 단순히 SQL만 작성할 수 있다면 한계가 크지만, 우리는 인프라 자체를 관리할 수 있게 해 큰 전환점을 만들었음

  • 정말 좋은 내용임
    다만 결과가 어떻게 계산되었는지 설명하는 부분이 빠진 것 같음
    OpenAI 내부용이라 사용자가 SQL을 읽을 수 있다는 전제는 괜찮지만, 비기술 사용자에게는 설계적으로 큰 도전임
    데이터 시스템을 다뤄보면 ‘답’만큼이나 ‘답이 어떻게 도출되었는가’가 중요하다는 걸 금방 깨닫게 됨

  • 개인적으로 Kimi의 In-House Data Agent가 더 흥미로움

  • 데이터 문제는 기술 문제가 아니라 조직 문제임

    • 정말 공감함
      내 경험상 데이터 문제의 원인은 ‘틀린 기술 선택’이 아니라 거버넌스와 소유권 결정에 있음
      결국 모든 것은 Conway의 법칙으로 귀결됨
답변달기