🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

OpenAI는 70k 데이터셋과 600PB 규모의 내부 데이터 환경에서 직원들이 자연어로 빠르고 정확한 분석을 수행하도록, 권한·맥락·워크플로에 맞춘 내부 전용 AI 데이터 에이전트를 구축했다.

📌 핵심 요약

• OpenAI의 내부 데이터 에이전트는 외부 제품이 아니라 OpenAI의 데이터, 권한 체계, 업무 흐름에 맞춰 설계된 사내 전용 도구이며, Codex, GPT-5 계열 모델, Evals API, Embeddings API 등을 활용해 구축됐다.
• 이 에이전트는 직원들이 질문에서 인사이트까지 걸리는 시간을 며칠이 아니라 몇 분 수준으로 줄이는 것을 목표로 하며, 엔지니어링, 데이터 사이언스, 고투마켓, 재무, 리서치 등 여러 조직에서 고영향 데이터 질문을 처리하는 데 사용된다.
• OpenAI의 데이터 플랫폼은 3,500명 이상의 내부 사용자, 600PB 이상의 데이터, 70,000개 데이터셋을 다루기 때문에 올바른 테이블을 찾고, 비슷한 테이블 간 차이를 이해하고, SQL 조인·필터·널 처리 오류를 피하는 일이 큰 병목이었다.
• 에이전트는 데이터 탐색, SQL 실행, 결과 합성, 노트북과 보고서 발행까지 분석 흐름을 end-to-end로 처리하며, 중간 결과가 이상하면 스스로 원인을 조사하고 접근 방식을 수정하는 폐쇄 루프 방식으로 작동한다.
• 핵심은 풍부한 맥락이다. 스키마 메타데이터, 테이블 계보, 과거 쿼리, 전문가 주석, 코드 수준의 테이블 정의, Slack·Google Docs·Notion의 조직 지식, 사용자와 대화에서 얻은 메모리, 실시간 데이터 웨어하우스 조회를 결합해 답변 품질을 높인다.

🧩 주요 포인트

1. OpenAI의 내부 데이터 에이전트는 외부 제품이 아니라 OpenAI의 데이터, 권한 체계, 업무 흐름에 맞춰 설계된 사내 전용 도구이며, Codex, GPT-5 계열 모델, Evals API, Embeddings API 등을 활용해 구축됐다.
2. 이 에이전트는 직원들이 질문에서 인사이트까지 걸리는 시간을 며칠이 아니라 몇 분 수준으로 줄이는 것을 목표로 하며, 엔지니어링, 데이터 사이언스, 고투마켓, 재무, 리서치 등 여러 조직에서 고영향 데이터 질문을 처리하는 데 사용된다.
3. OpenAI의 데이터 플랫폼은 3,500명 이상의 내부 사용자, 600PB 이상의 데이터, 70,000개 데이터셋을 다루기 때문에 올바른 테이블을 찾고, 비슷한 테이블 간 차이를 이해하고, SQL 조인·필터·널 처리 오류를 피하는 일이 큰 병목이었다.
4. 에이전트는 데이터 탐색, SQL 실행, 결과 합성, 노트북과 보고서 발행까지 분석 흐름을 end-to-end로 처리하며, 중간 결과가 이상하면 스스로 원인을 조사하고 접근 방식을 수정하는 폐쇄 루프 방식으로 작동한다.
5. 핵심은 풍부한 맥락이다. 스키마 메타데이터, 테이블 계보, 과거 쿼리, 전문가 주석, 코드 수준의 테이블 정의, Slack·Google Docs·Notion의 조직 지식, 사용자와 대화에서 얻은 메모리, 실시간 데이터 웨어하우스 조회를 결합해 답변 품질을 높인다.

🧠 상세 정리

1. 사내 전용 데이터 에이전트를 만든 이유

OpenAI는 데이터가 시스템 학습, 제품 개선, 회사 의사결정의 핵심이라고 설명하면서도, 실제로 빠르고 정확하며 맥락에 맞는 답을 얻는 일은 여전히 어렵다고 지적한다. 조직이 커질수록 데이터와 업무 흐름도 복잡해지기 때문에, 단순한 범용 도구만으로는 내부의 권한 구조, 데이터 의미, 분석 관행을 충분히 반영하기 어렵다. 그래서 OpenAI는 외부에 제공하는 제품이 아니라, OpenAI의 데이터와 권한, 업무 방식에 맞춘 내부 전용 AI 데이터 에이전트를 만들었다. 이 글은 그 도구를 어떻게 만들고 사용하는지, 그리고 AI가 일상적인 팀 업무에서 실제로 어떤 영향을 줄 수 있는지를 보여주는 사례로 제시된다.

2. 분석 병목: 올바른 테이블을 찾는 것부터 어렵다

OpenAI의 데이터 플랫폼은 3,500명 이상의 내부 사용자를 지원하고, 엔지니어링·제품·리서치 전반에 걸쳐 600PB 이상의 데이터와 70,000개 데이터셋을 다룬다. 이 정도 규모에서는 분석의 첫 단계인 ‘어떤 테이블을 써야 하는가’를 판단하는 것 자체가 시간이 많이 드는 일이 된다. 원문에 인용된 사용자는 비슷해 보이는 테이블이 많고, 어떤 테이블은 로그아웃 사용자를 포함하지만 어떤 테이블은 그렇지 않으며, 겹치는 필드도 많아 차이를 파악하기 어렵다고 말한다. 따라서 문제는 단순히 SQL을 빨리 쓰는 것이 아니라, 데이터셋의 의미와 범위를 제대로 이해하는 데 있다.

3. 정확한 결과를 막는 SQL과 데이터 관계의 함정

올바른 테이블을 골랐다고 해서 분석이 끝나는 것은 아니다. 분석가는 테이블 내부 데이터와 테이블 간 관계를 이해한 뒤, 변환과 필터가 의도대로 적용되는지 확인해야 한다. 원문은 many-to-many 조인, 필터 푸시다운 오류, 처리되지 않은 널 값 같은 흔한 실패 모드가 조용히 결과를 무효화할 수 있다고 설명한다. 180줄이 넘는 SQL 예시처럼, 실제 업무에서는 어떤 테이블을 조인해야 하는지, 어떤 컬럼을 질의해야 하는지 판단하기가 쉽지 않다. OpenAI는 분석가들이 SQL 의미론이나 쿼리 성능 디버깅에 시간을 빼앗기기보다, 지표 정의와 가정 검증, 데이터 기반 의사결정에 집중해야 한다고 본다.

4. 에이전트의 기본 작동 방식과 사용 환경

이 내부 데이터 에이전트는 GPT-5.2로 구동되며 OpenAI의 데이터 플랫폼 위에서 추론하도록 설계됐다. 직원들은 이미 일하는 환경 안에서 에이전트를 사용할 수 있는데, 원문은 Slack 에이전트, 웹 인터페이스, IDE, MCP를 통한 Codex CLI, OpenAI 내부 ChatGPT 앱의 MCP 커넥터를 언급한다. 사용자는 여러 차례의 수동 탐색이 필요했을 복잡하고 개방형 질문을 자연어로 던질 수 있다. 예시로는 뉴욕 택시 이동 데이터에서 일반적인 소요 시간과 최악의 경우 사이의 차이가 가장 큰 픽업·드롭오프 ZIP 조합과 변동성이 나타나는 시점을 찾는 질문이 제시된다. 에이전트는 질문 이해, 데이터 탐색, 쿼리 실행, 결과 종합까지 분석을 끝까지 수행한다.

5. 고정 스크립트가 아니라 스스로 점검하며 반복하는 분석

원문이 강조하는 에이전트의 강점 중 하나는 고정된 절차를 기계적으로 따르지 않고, 문제를 풀어가는 과정에서 자신의 진행 상황을 평가한다는 점이다. 예를 들어 조인이나 필터가 잘못되어 중간 결과가 0행으로 나오면, 에이전트는 그 결과를 그대로 받아들이지 않고 무엇이 잘못됐는지 조사한다. 그런 다음 접근 방식을 수정하고 다시 시도하며, 각 단계에서 얻은 맥락과 학습을 다음 단계로 이어간다. 이 폐쇄 루프 방식은 사용자가 직접 반복하던 탐색과 수정의 상당 부분을 에이전트 내부로 옮긴다. 그 결과 수동 워크플로보다 더 빠른 결과와 일관되게 높은 품질의 분석을 제공하는 것을 목표로 한다.

6. 맥락이 답변 품질을 좌우한다

OpenAI는 강력한 모델이라도 충분한 맥락이 없으면 잘못된 결과를 낼 수 있다고 말한다. 예를 들어 사용자 수를 크게 잘못 추정하거나, 내부 용어를 오해하는 문제가 생길 수 있다. 이를 줄이기 위해 에이전트는 OpenAI의 데이터와 조직 지식에 기반한 여러 계층의 맥락을 사용한다. 스키마 메타데이터는 컬럼명과 데이터 타입을 바탕으로 SQL 작성에 도움을 주고, 테이블 계보는 상류·하류 테이블 관계를 통해 데이터셋 간 연결을 설명한다. 또한 과거 쿼리를 수집해 어떤 테이블이 함께 조인되는지, 실제 분석에서는 어떤 패턴으로 쿼리가 작성되는지 추론한다.

7. 전문가 주석과 코드 수준 정의로 테이블 의미를 구분한다

메타데이터만으로는 비슷해 보이는 테이블의 실제 차이를 충분히 설명하기 어렵다. 그래서 에이전트는 도메인 전문가가 제공한 테이블과 컬럼 설명을 활용해 의도, 의미, 비즈니스 맥락, 알려진 주의사항을 반영한다. 여기에 더해 테이블의 코드 수준 정의를 도출함으로써 데이터가 어떻게 만들어졌고 무엇을 포함하는지 더 깊게 이해한다. 원문은 값의 유일성, 업데이트 빈도, 데이터 범위, 특정 필드 제외 여부, 세부 granularity 같은 정보가 추가 맥락이 된다고 설명한다. 또한 SQL뿐 아니라 Spark, Python, 기타 데이터 시스템에서 테이블이 어떻게 사용되는지도 파악해, 겉보기에는 비슷하지만 중요한 차이가 있는 테이블을 구분할 수 있게 한다.

8. 조직 지식, 메모리, 실시간 조회를 결합한 자기 개선

에이전트는 Slack, Google Docs, Notion에도 접근해 출시, 신뢰성 사고, 내부 코드명과 도구, 핵심 지표의 공식 정의와 계산 로직 같은 회사 맥락을 활용한다. 이 문서들은 임베딩되어 메타데이터와 권한 정보와 함께 저장되며, 런타임에는 검색 서비스가 접근 제어와 캐싱을 처리한다. 또한 사용자가 교정하거나 대화 중 특정 데이터 질문에 관한 미묘한 사실을 발견하면, 에이전트는 이를 다음번에 저장할 수 있도록 제안한다. 메모리는 전역 수준과 개인 수준으로 범위가 나뉘며 사용자가 직접 만들고 편집할 수도 있다. 기존 맥락이 없거나 낡았을 때는 데이터 웨어하우스에 실시간 쿼리를 실행하고, 메타데이터 서비스, Airflow, Spark 같은 다른 데이터 플랫폼 시스템과도 상호작용해 최신 정보를 확인한다.

9. 확장 가능한 검색 구조와 협업형 사용자 경험

OpenAI는 매일 오프라인 파이프라인을 실행해 테이블 사용량, 사람의 주석, Codex 기반 보강 정보를 하나의 정규화된 표현으로 통합한다. 이 강화된 맥락은 OpenAI Embeddings API로 임베딩되어 검색용으로 저장되며, 질의 시점에는 원시 메타데이터나 로그 전체를 훑는 대신 RAG 방식으로 가장 관련성 높은 맥락만 가져온다. 이는 수만 개 테이블이 있는 환경에서도 테이블 이해를 빠르고 확장 가능하게 만들고, 런타임 지연을 예측 가능하고 낮게 유지하기 위한 설계다. 사용 경험 측면에서도 에이전트는 한 번에 답하는 도구라기보다 함께 추론하는 팀원처럼 설계됐다. 사용자는 후속 질문을 하거나 방향을 바꿀 수 있고, 에이전트는 맥락을 유지하며 필요하면 명확화 질문을 하거나 합리적인 기본값으로 진행한다.

🧾 핵심 주장 / 시사점

• 이 사례의 핵심은 모델 성능 자체보다 ‘맥락 설계’에 있다. OpenAI는 스키마, 계보, 과거 쿼리, 코드 정의, 문서, 사용자 교정, 실시간 조회를 결합해 데이터 분석에서 흔히 생기는 오해와 침묵하는 오류를 줄이려 한다.
• 데이터 에이전트는 분석가를 대체하는 단순 자동화보다, 반복 탐색과 SQL 디버깅 부담을 줄여 사용자가 지표 정의와 가정 검증, 의사결정에 더 집중하게 하는 협업 도구로 설명된다.
• 에이전트가 실제 조직에서 유용해지려면 자연어 인터페이스만으로는 부족하며, 권한 관리, 최신성, 메모리 편집 가능성, 내부 문서와 코드 기반 지식, 잘못된 중간 결과를 스스로 수정하는 반복 구조가 함께 필요하다는 점을 보여준다.

✅ 액션 아이템

• 사내 데이터 분석 에이전트를 검토할 때 먼저 권한 체계, 데이터셋 탐색, SQL 오류 방지처럼 병목이 큰 업무 구간을 분리해 우선순위를 정한다.
• 스키마 메타데이터, 테이블 계보, 과거 쿼리, 전문가 주석, 조직 문서 등 에이전트가 참조할 맥락 자산을 목록화하고 품질을 점검한다.
• 질문부터 결과 합성, 노트북·보고서 발행까지 이어지는 분석 워크플로에서 사람이 검토해야 할 중간 결과와 자동 수정 가능한 지점을 구분한다.

❓ 열린 질문

• 자연어 데이터 에이전트가 올바른 테이블 선택과 SQL 조인·필터·널 처리 오류를 줄였는지 어떤 평가 지표로 측정할 수 있을까?
• 3,500명 이상이 쓰는 내부 도구에서 사용자별 권한과 대화 메모리를 결합할 때 답변 품질과 접근 통제 사이의 균형은 어떻게 잡아야 할까?
• 분석 시간을 며칠에서 몇 분으로 줄이는 효과가 조직별로 다르게 나타난다면, 어떤 업무 흐름부터 폐쇄 루프 자동화를 확장해야 할까?