# OpenAI의 사내 데이터 에이전트 들여다 보기 > Clean Markdown view of GeekNews topic #26654. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26654](https://news.hada.io/topic?id=26654) - GeekNews Markdown: [https://news.hada.io/topic/26654.md](https://news.hada.io/topic/26654.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-02-13T12:55:09+09:00 - Updated: 2026-02-13T12:55:09+09:00 - Original source: [openai.com](https://openai.com/index/inside-our-in-house-data-agent) - Points: 13 - Comments: 1 ## Summary OpenAI가 내부의 방대한 **600PB 규모 데이터**를 다루기 위해 자연어 기반의 **맞춤형 데이터 에이전트**를 구축했다고 공개했습니다. 이 에이전트는 테이블 탐색, SQL 실행, 리포트 생성까지 자동화하며, 중간 결과를 스스로 점검·수정하는 **자기 수정 루프** 구조로 동작합니다. 테이블 메타데이터, 코드 분석, 조직 지식 등 6개 계층의 컨텍스트를 결합해 정확도를 높이고, Evals API 기반 평가 체계로 품질 저하를 조기에 감지하도록 설계되었습니다. 단순한 질의응답 도구가 아니라, 분석가가 SQL 디버깅 대신 **데이터 기반 의사결정**에 집중할 수 있도록 지원하는 내부 전용 시스템이라는 점이 특징입니다. AI가 외부 서비스가 아닌 기업 내부의 ‘데이터 인터페이스’로 자리 잡아가는 흐름을 보여주는 사례를 직접 보여주는 것 같아서 인상적이네요. ## Topic Body - 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 데이터 생태계 전반에 **빠르고 신뢰할 수 있는 데이터 분석을 원활하게 제공**하는 것 ## Comments ### Comment 51109 - Author: neo - Created: 2026-02-13T12:55:10+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46814115) - 신뢰성과 **설명 가능성**이 가장 큰 문제임 우리는 10년째 [Veezoo](https://www.veezoo.com/)에서 자연어 분석을 개발 중인데, 단순한 Text-to-SQL 접근은 확장성이 떨어짐 CFO가 매출을 물을 때 99%만 맞는 숫자는 의미가 없고, CFO가 SQL을 직접 검증할 수도 없음 그래서 우리는 **Knowledge Graph**라는 추상화 계층을 두어, AI가 자연어를 의미 기반 질의 언어로 변환하고 이를 결정론적으로 SQL로 컴파일함 반대로 이 의미 질의를 다시 자연어 설명으로 변환해 사용자가 결과가 의도에 맞는지 쉽게 검증할 수 있게 함 비즈니스 로직은 Knowledge Graph에 존재하고, 컴파일러가 모든 질의가 이를 100% 따르도록 보장함 자세한 구조는 [Veezoo Architecture 문서](https://docs.veezoo.com/veezoo/architecture-overview)에 정리되어 있음 - 링크 공유 고마움. 아키텍처 개요가 매우 인사이트 있었음 궁금한 점은 **카디널리티 폭발**을 어떻게 관리하는지, 그리고 이전 쿼리 결과에 의존하는 다중 쿼리 요청은 어떻게 처리하는지임 - 그래도 생성된 SQL 산출물은 **버전 관리와 단위 테스트**가 필요하지 않음? 어떤 날짜에 어떤 쿼리가 사용되었고 어떻게 검증되었는지를 추적할 수 있어야 함 (물론 프롬프트도 버전 관리 대상임) - 첫 번째 예시가 완전히 **비논리적**이라 놀랐음 이게 인간 검수를 통과했다면 아마 AI가 작성한 것 같고, 그렇다면 시스템의 신뢰성에 의문이 생김 [문제의 이미지 링크](https://images.ctfassets.net/kftzwdyauwt9/2tMhL5Www2vA6I62DVpNgv/4923ef472351cdb3a87ff4130a83ed14/Mobile-Light.png?w=1200&q=70&fm=webp) - 맞음, 데스크톱 버전과 모바일 버전이 따로 있음 데스크톱은 [정상 프롬프트](https://images.ctfassets.net/kftzwdyauwt9/5EoAd2fIvVRf8V51LNl7ae/4130864f70f3ffd0ffcc00172f8cc20e/Desktop-Light.png?w=3840&q=80&fm=webp), 모바일은 [잘못된 프롬프트](https://images.ctfassets.net/kftzwdyauwt9/2tMhL5Www2vA6I62DVpNgv/4923ef472351cdb3a87ff4130a83ed14/Mobile-Light.png?w=3840&q=70&fm=webp)임 - 여러 BI 시스템을 써본 경험상, 이런 **AI 에이전트**는 완벽한 사용 사례라고 생각함 BI는 본래 여러 층위에서 오류가 발생함 — 쿼리 자체가 틀리거나, 데이터를 해석하는 방식이 틀림 이 두 가지가 합쳐지면 이미 ‘가상의 세계’에 들어간 셈이라, 차라리 AI가 1단계를 맡는 게 나음 OpenAI가 신뢰성 문제를 해결했을까 기대했지만, 아쉽게도 그렇지 않았음 - 잊지 말아야 할 점이 있음 **0단계**: 데이터를 잘못 저장함 **-1단계**: 모델링 자체를 잘못 이해함 **-2단계**: 비즈니스 프로세스가 처음부터 틀림 그래서 나는 ‘단일 진실의 원천’ 대신 ‘단일 거짓의 원천’이라고 부름 - 신뢰를 확장하는 게 가장 어려운 부분임 우리도 비슷한 걸 만들고 있는데, 아무리 에이전트 루프가 좋아도 결국 **사람이 큐레이션한 표준 지표(canonical metrics)** 가 필요함 그렇지 않으면 비기술직 사용자는 검증 불가능한 SQL로 위험한 결정을 내리게 됨 우리의 접근법은 1. 데이터 파이프라인을 직접 통제하고, 고객 간 스키마가 일관된 데이터 소스만 사용함 2. 검증된 지표가 있을 때는 그것을 사용하고, 없을 때만 SQL로 대체하며, 그 차이를 인간 검토 대상으로 기록함 시간이 지나면 대부분의 쿼리가 표준 지표를 사용하게 되고, 에이전트는 단순 SQL 생성기가 아니라 **의도→검증된 지표**로의 스마트 라우터가 됨 “신뢰를 깨지 않고 빠르게 움직이기” 섹션의 골든 SQL 평가 시스템도 같은 통찰을 담고 있음 관련 글은 [이 블로그 포스트](https://www.graphed.com/blog/update-2)에 정리했음 - 맞음, 명확한 **시맨틱 레이어**가 꼭 필요함 답으로 가는 경로가 여러 개면 서로 다른 결과가 나옴 LLM은 종종 의미 없는 ‘xyz_index’ 같은 지표를 만들어내는데, 사용자들이 그럴듯하다고 믿고 그냥 써버림 - 내 생각에 AI가 개발자 일자리에 미칠 진짜 영향은 **데이터와 문서 품질**임 기업의 데이터가 얼마나 잘 정리되어 있느냐가 AI 활용 효율을 결정함 공개 데이터는 이미 고갈됐고, 다음 자원은 내부 문서, 코드 저장소, 데이터 레이크임 이런 기반이 잘 되어 있는 회사는 AI로 새로운 서비스를 빠르고 저렴하게 만들고 유지할 수 있음 반대로 문서와 코드 관리가 엉망인 회사는 AI가 제대로 작동하지 않음 결국 경쟁사에게 시장을 빼앗기게 될 것임 그래서 앞으로 구직할 때는 **문서·데이터·저장소 관리 수준**을 꼭 물어볼 생각임 - 문서와 데이터, 저장소 관련해서 구체적으로 어떤 점을 보고 좋은 아키텍처와 나쁜 아키텍처를 구분하는지 궁금함 - Amplitude에서 **Moda**라는 비슷한 시스템을 만들었음 수개월 전 Wade가 Claire Vo에게 [데모 영상](https://www.youtube.com/watch?v=9Q9Yrj2RTkg)을 보여줬는데 정말 훌륭했음 나는 매일 이걸로 다양한 질문을 던지며 사용 중임 - 우리도 비슷한 기능을 [Definite.app](https://www.definite.app/)에서 **5분 만에 제공**함 Spark나 Snowflake가 필요 없음 데이터레이크, 파이프라인, 시맨틱 레이어, 데이터 에이전트를 하나의 앱으로 제공함 사실 에이전트 자체보다 **데이터 인프라 구축**이 훨씬 어려움 에이전트가 단순히 SQL만 작성할 수 있다면 한계가 크지만, 우리는 인프라 자체를 관리할 수 있게 해 큰 전환점을 만들었음 - 정말 좋은 내용임 다만 결과가 **어떻게 계산되었는지 설명하는 부분**이 빠진 것 같음 OpenAI 내부용이라 사용자가 SQL을 읽을 수 있다는 전제는 괜찮지만, 비기술 사용자에게는 설계적으로 큰 도전임 데이터 시스템을 다뤄보면 ‘답’만큼이나 ‘답이 어떻게 도출되었는가’가 중요하다는 걸 금방 깨닫게 됨 - 개인적으로 **Kimi의 In-House Data Agent**가 더 흥미로움 - 데이터 문제는 기술 문제가 아니라 **조직 문제**임 - 정말 공감함 내 경험상 데이터 문제의 원인은 ‘틀린 기술 선택’이 아니라 **거버넌스와 소유권 결정**에 있음 결국 모든 것은 **Conway의 법칙**으로 귀결됨