OpenAI가 사내 데이터, 권한, 워크플로에 맞춰 맞춤형 AI 데이터 에이전트를 구축해 직원들이 자연어로 빠르고 신뢰할 수 있는 분석을 수행하도록 한 방법과 그 과정에서 얻은 교훈을 소개한다.
데이터는 시스템이 학습하는 방식, 제품이 진화하는 방식, 기업이 의사결정을 내리는 방식을 좌우합니다. 하지만 빠르고 정확하게, 그리고 올바른 맥락까지 갖춘 답을 얻는 일은 종종 필요 이상으로 어렵습니다. OpenAI가 규모를 확장하는 과정에서 이를 더 쉽게 만들기 위해, 우리는 자체 맞춤형 사내 AI 데이터 에이전트를 구축했습니다. 이 에이전트는 우리 플랫폼 위에서 우리의 데이터를 탐색하고 추론합니다.
우리 에이전트는 외부에 제공되는 제품이 아니라, OpenAI의 데이터, 권한, 워크플로에 맞춰 특별히 설계된 내부 전용 커스텀 도구입니다. 우리는 이 글에서 에이전트를 어떻게 만들고 사용하고 있는지 공유함으로써, AI가 팀의 일상 업무를 실질적이고 의미 있게 지원할 수 있는 현실적인 사례를 보여주고자 합니다. 이를 구축하고 운영하는 데 사용한 OpenAI 도구(Codex, GPT‑5 플래그십 모델, Evals API(새 창에서 열림), Embeddings API(새 창에서 열림))는 전 세계 개발자에게 제공되는 것과 동일한 도구들입니다.
이 데이터 에이전트는 직원이 질문에서 인사이트까지 도달하는 시간을 ‘며칠’이 아니라 ‘몇 분’으로 줄여줍니다. 그 결과 데이터팀만이 아니라 모든 기능 조직이 데이터 추출과 정교한 분석을 더 쉽게 수행할 수 있습니다. 현재 OpenAI의 Engineering, Data Science, Go-To-Market, Finance, Research 팀 전반이 이 에이전트를 활용해 영향력이 큰 데이터 질문에 답하고 있습니다. 예컨대, 출시(launch)를 평가하고 비즈니스 건전성을 이해하는 데 도움을 주며, 이 모든 과정을 자연어라는 직관적인 형식으로 수행할 수 있습니다. 에이전트는 Codex 기반의 테이블 수준 지식과 제품 및 조직 맥락을 결합합니다. 또한 지속적으로 학습하는 메모리 시스템 덕분에 대화가 거듭될수록 더 나아집니다.
이 글에서는 맞춤형 AI 데이터 에이전트가 왜 필요했는지, 코드로 강화된 데이터 컨텍스트와 자기학습이 왜 유용한지, 그리고 그 과정에서 얻은 교훈을 정리합니다.
OpenAI의 데이터 플랫폼은 Engineering, Product, Research 전반에서 일하는 3,500명+의 내부 사용자를 지원하며, 600PB가 넘는 데이터가 7만 개 데이터셋에 걸쳐 존재합니다. 이 규모에서는 올바른 테이블을 찾는 것만으로도 분석에서 가장 시간이 많이 드는 작업 중 하나가 될 수 있습니다.
한 내부 사용자의 말입니다:
“비슷해 보이는 테이블이 정말 많아서, 서로 무엇이 다른지와 어떤 것을 써야 하는지 파악하는 데 시간을 엄청 씁니다. 어떤 건 로그아웃 사용자를 포함하고, 어떤 건 포함하지 않아요. 어떤 건 필드가 겹치기도 해서, 뭐가 뭔지 판단하기 어렵습니다.”
올바른 테이블을 고르더라도, 정확한 결과를 내는 것은 여전히 어렵습니다. 분석가는 변환과 필터가 올바르게 적용되도록 테이블 데이터와 테이블 간 관계를 추론해야 합니다. 흔한 실패 양상—다대다 조인(many-to-many join), 필터 푸시다운 오류(filter pushdown errors), 처리되지 않은 null—은 조용히 결과를 무효화할 수 있습니다. OpenAI 규모에서는 분석가가 SQL 의미론이나 쿼리 성능 디버깅에 시간을 쏟아서는 안 됩니다. 분석가의 초점은 지표 정의, 가정 검증, 데이터 기반 의사결정이어야 합니다.
이제 에이전트가 무엇인지, 어떻게 컨텍스트를 큐레이션하는지, 어떻게 자기개선을 이어가는지 살펴보겠습니다.
사용자는 보통 수차례의 수동 탐색이 필요한 복잡하고 개방형 질문을 던질 수 있습니다. 예를 들어, 테스트 데이터셋을 사용하는 다음 프롬프트를 보겠습니다: “NYC 택시 이동에서, 픽업-드롭오프 ZIP 페어 중 전형적인 이동 시간과 최악의 경우 이동 시간의 격차가 가장 큰(즉, 가장 ‘신뢰하기 어려운’) 페어는 무엇이며, 그 변동성은 언제 발생하나요?”
에이전트는 질문 이해부터 데이터 탐색, 쿼리 실행, 결과 종합까지 분석 전 과정을 엔드투엔드로 처리합니다.
에이전트의 강점 중 하나는 문제를 추론하는 방식입니다. 고정된 스크립트를 따르기보다, 에이전트는 자신의 진행 상황을 평가합니다. 중간 결과가 이상해 보이면(예: 잘못된 조인/필터로 인해 결과 행이 0개가 되는 경우), 무엇이 잘못됐는지 조사하고 접근을 수정한 뒤 다시 시도합니다. 이 과정에서 에이전트는 전체 컨텍스트를 유지하고, 단계 사이에서 학습을 누적해 다음 단계로 가져갑니다. 이런 폐쇄루프(closed-loop) 자기학습 프로세스는 반복 작업을 사용자에서 에이전트로 옮겨, 수작업 워크플로보다 더 빠른 결과와 일관되게 더 높은 품질의 분석을 가능하게 합니다.
에이전트는 데이터 발견, SQL 실행, 노트북과 리포트 게시까지 분석 워크플로 전체를 포괄합니다. 또한 사내 지식을 이해하고, 외부 정보를 위해 웹 검색을 할 수 있으며, 사용 패턴과 메모리를 통해 시간이 지날수록 개선됩니다.
고품질 답변은 풍부하고 정확한 컨텍스트에 달려 있습니다. 컨텍스트가 없으면, 강력한 모델이라도 사용자 수를 크게 잘못 추정하거나 사내 용어를 오해하는 등 잘못된 결과를 낼 수 있습니다.
메모리가 없는 에이전트는 효과적으로 쿼리하지 못합니다.
에이전트의 메모리는 올바른 테이블을 찾아 더 빠른 쿼리를 가능하게 합니다.
이런 실패를 피하기 위해, 에이전트는 OpenAI의 데이터와 조직 지식에 기반을 두도록 여러 겹의 컨텍스트 레이어를 중심으로 설계되었습니다.
메타데이터 기반(grounding): 에이전트는 스키마 메타데이터(컬럼명과 데이터 타입)에 의존해 SQL 작성에 참고하고, 테이블 계보(lineage)(예: 상류/하류 테이블 관계)를 사용해 테이블들이 어떻게 연결되는지에 대한 컨텍스트를 제공합니다.
쿼리 추론: 과거 쿼리를 수집하면, 에이전트가 자신의 쿼리를 어떻게 작성해야 하는지, 그리고 어떤 테이블들이 일반적으로 함께 조인되는지 이해하는 데 도움이 됩니다.
도메인 전문가가 제공하는 테이블/컬럼의 큐레이션된 설명: 스키마나 과거 쿼리만으로는 추론하기 어려운 의도, 의미론, 비즈니스 의미, 알려진 주의사항(caveat) 등을 담습니다.
메타데이터만으로는 충분하지 않습니다. 테이블을 제대로 구분하려면, 테이블이 어떻게 만들어졌고 어디에서 비롯되었는지까지 알아야 합니다.
테이블의 코드 수준 정의를 도출함으로써, 에이전트는 데이터가 실제로 무엇을 담고 있는지 더 깊게 이해합니다.
이를 통해 Spark, Python 등 다양한 데이터 시스템에서 SQL을 넘어 테이블이 어떻게 사용되는지를 보여주며 사용 컨텍스트가 강화됩니다.
그 결과, 겉보기에는 비슷하지만 중요한 차이가 있는 테이블들을 구분할 수 있습니다. 예를 들어, 특정 테이블이 1st-party ChatGPT 트래픽만 포함하는지 여부를 판별할 수 있습니다. 또한 이 컨텍스트는 자동으로 갱신되므로, 수동 유지보수 없이 최신 상태를 유지합니다.
에이전트는 Slack, Google Docs, Notion에 접근할 수 있으며, 여기에는 출시, 신뢰성(리라이어빌리티) 인시던트, 내부 코드네임과 도구, 핵심 지표의 정본(canonical) 정의 및 계산 로직 같은 중요한 사내 컨텍스트가 담겨 있습니다.
이런 문서들은 수집되어 임베딩되고, 메타데이터 및 권한과 함께 저장됩니다. 런타임에는 검색(retrieval) 서비스가 접근 제어와 캐싱을 처리해, 에이전트가 이 정보를 효율적이고 안전하게 가져올 수 있습니다.
에이전트가 수정 사항을 받거나 특정 데이터 질문에 대한 뉘앙스를 발견하면, 이를 다음에 사용할 수 있도록 학습 내용으로 저장할 수 있어 사용자와 함께 지속적으로 개선됩니다.
에이전트에 수정 사항을 알려주거나 대화에서 학습을 발견하면, 다음에도 쓸 수 있도록 그 메모리를 저장할지 사용자에게 묻습니다.
우리는 매일 오프라인 파이프라인을 실행하여 테이블 사용량, 사람의 주석(annotations), Codex로부터 도출한 보강(enrichment)을 하나의 정규화된 표현으로 통합합니다. 이렇게 보강된 컨텍스트는 OpenAI embeddings API(새 창에서 열림)를 사용해 임베딩으로 변환되어 검색을 위해 저장됩니다. 쿼리 시점에는 에이전트가 원시 메타데이터나 로그를 스캔하는 대신, 검색 증강 생성(RAG, 새 창에서 열림)을 통해 가장 관련성 높은 임베딩 컨텍스트만 가져옵니다. 이를 통해 수만 개 테이블이 존재하더라도 테이블 이해를 빠르고 확장 가능하게 만들고, 런타임 지연(latency)도 예측 가능하고 낮게 유지합니다. 런타임 쿼리는 필요에 따라 데이터 웨어하우스에 실시간으로 발행됩니다.
이 레이어들이 함께 작동함으로써, 에이전트의 추론은 OpenAI의 데이터, 코드, 조직 지식에 기반을 두게 되고, 오류가 크게 줄어들며 답변 품질이 향상됩니다.
문제가 명확할 때는 원샷(one-shot) 답변이 통하지만, 대부분의 질문은 그렇지 않습니다. 대체로 올바른 결과에 도달하려면 대화형으로 요구사항을 다듬고 중간에 방향을 바로잡는 과정이 필요합니다.
이 에이전트는 함께 추론할 수 있는 동료처럼 행동하도록 만들어졌습니다. 대화형이며 항상 켜져 있고(always-on), 빠른 답변과 반복적 탐색을 모두 처리합니다.
턴 간에 전체 컨텍스트를 그대로 가져가므로, 사용자는 모든 것을 다시 설명하지 않고도 후속 질문을 하거나 의도를 조정하거나 방향을 바꿀 수 있습니다. 에이전트가 잘못된 길로 가기 시작하면, 사용자는 분석 도중에 끼어들어 방향을 바꾸게 할 수 있는데, 이는 앞만 보고 밀어붙이지 않고 듣고 반응하는 인간 협업자와 비슷합니다.
지시가 불명확하거나 불완전하면, 에이전트는 먼저 확인 질문을 던집니다. 응답이 없으면, 진행을 위해 합리적인 기본값을 적용합니다. 예를 들어 사용자가 날짜 범위를 지정하지 않고 비즈니스 성장에 대해 물으면, 최근 7일 또는 30일을 가정할 수 있습니다. 이런 사전 가정(prior)은 에이전트가 막히지 않고 반응성을 유지하면서도 올바른 결과로 수렴하도록 돕습니다.
그 결과, 정확히 원하는 것이 있을 때(예: “이 테이블에 대해 알려줘”)도 잘 작동하고, 탐색 중일 때(예: “여기서 하락이 보이는데, 고객 유형과 기간별로 쪼개 볼 수 있을까?”)도 동일하게 강력한 에이전트가 됩니다.
롤아웃 이후, 사용자들이 루틴하고 반복적인 작업에서 같은 분석을 자주 실행한다는 점을 관찰했습니다. 이를 가속하기 위해, 에이전트의 워크플로는 반복 분석을 재사용 가능한 지침 세트로 패키징합니다. 예로 주간 비즈니스 리포트나 테이블 검증을 위한 워크플로가 있습니다. 컨텍스트와 모범사례(best practices)를 한 번 인코딩해 두면, 워크플로는 반복 분석을 간소화하고 사용자 간 일관된 결과를 보장합니다.
항상 켜져 있고 진화하는 에이전트를 만들면, 품질이 좋아지는 만큼 쉽게 드리프트(quality drift)할 수도 있습니다. 촘촘한 피드백 루프가 없다면, 회귀(regression)는 피할 수 없고 눈에 띄지도 않습니다. 신뢰를 깨지 않으면서 역량을 확장하는 유일한 방법은 체계적인 평가입니다.
에이전트의 Evals는 큐레이션된 질문-답변 쌍 집합으로 구축됩니다. 각 질문은 우리가 정확히 맞추는 것을 매우 중요하게 여기는 핵심 지표 또는 분석 패턴을 겨냥하며, 기대 결과를 내는 수작업 작성 “골든(golden)” SQL 쿼리와 짝을 이룹니다. 각 eval에서 우리는 자연어 질문을 쿼리 생성 엔드포인트에 보내고, 생성된 SQL을 실행한 다음, 기대 SQL의 실행 결과와 출력값을 비교합니다.
평가는 단순한 문자열 매칭에 의존하지 않습니다. 생성된 SQL은 문법적으로 다르더라도 정답일 수 있고, 결과 셋에 답변에 본질적으로 영향을 주지 않는 추가 컬럼이 포함될 수도 있습니다. 이를 반영하기 위해 우리는 SQL과 결과 데이터 모두를 비교하고, 이러한 신호를 OpenAI Evals 그레이더에 입력합니다. 그레이더는 최종 점수와 함께 설명을 제공하여, 정확성과 허용 가능한 변형을 함께 포착합니다.
이러한 eval은 개발 중 지속적으로 실행되는 유닛 테스트와 같고, 프로덕션에서는 카나리(canary)처럼 회귀를 식별하는 역할을 합니다. 이를 통해 문제를 조기에 포착하고, 에이전트의 역량이 확장되더라도 자신 있게 반복 개선할 수 있습니다.
우리 에이전트는 OpenAI의 기존 보안 및 접근 제어 모델에 직접 연결됩니다. 에이전트는 순수하게 인터페이스 레이어로만 동작하며, OpenAI 데이터에 적용되는 동일한 권한과 가드레일을 그대로 상속하고 집행합니다.
**에이전트의 모든 접근은 엄격히 패스스루(pass-through)**이므로, 사용자는 원래 자신이 접근 권한을 가진 테이블만 쿼리할 수 있습니다. 권한이 없으면 에이전트가 이를 표시하거나, 사용자가 권한을 가진 대체 데이터셋으로 폴백합니다.
마지막으로, 투명성을 위해 설계되었습니다. 어떤 시스템이든 실수할 수 있습니다. 에이전트는 각 답변에 가정과 실행 단계를 함께 요약해 추론 과정을 드러냅니다. 쿼리가 실행되면, 기반이 되는 결과로 직접 링크해 사용자가 원시 데이터를 확인하고 분석의 모든 단계를 검증할 수 있게 합니다.
에이전트를 처음부터 구축하는 과정은 에이전트가 어떻게 행동하는지, 어디서 어려움을 겪는지, 대규모에서 신뢰성을 실제로 만들어내는 요소가 무엇인지에 대한 실용적 교훈을 드러냈습니다.
초기에는 에이전트에 전체 도구 세트를 그대로 노출했고, 곧 기능이 겹치는 문제를 맞닥뜨렸습니다. 이런 중복성은 특정 커스텀 케이스에는 도움이 될 수 있고 사람이 수동으로 호출할 때는 더 명확하지만, 에이전트에게는 혼란을 줍니다. 모호성을 줄이고 신뢰성을 높이기 위해, 우리는 특정 도구 호출을 제한하고 통합했습니다.
또한 지나치게 규정적인 프롬프팅이 결과를 악화시킨다는 점을 발견했습니다. 많은 질문이 대체로 비슷한 분석 형태를 공유하지만, 세부 사항이 충분히 달라서 경직된 지시가 에이전트를 잘못된 경로로 밀어 넣는 경우가 잦았습니다. 더 높은 수준의 가이던스로 전환하고 GPT‑5의 추론이 적절한 실행 경로를 선택하도록 의존하자, 에이전트는 더 견고해졌고 더 나은 결과를 냈습니다.
스키마와 쿼리 히스토리는 테이블의 형태와 사용법을 설명하지만, 테이블의 진짜 의미는 그것을 생산하는 코드에 있습니다. 파이프라인 로직에는 SQL이나 메타데이터에서는 드러나지 않는 가정, 신선도 보장(freshness guarantees), 비즈니스 의도가 담겨 있습니다. Codex로 코드베이스를 크롤링함으로써, 우리 에이전트는 데이터셋이 실제로 어떻게 구성되는지 이해하고 각 테이블에 실제로 무엇이 들어 있는지 더 잘 추론할 수 있게 됩니다. 웨어하우스 신호만으로는 어려운 “여기에는 무엇이 있나”와 “언제 이걸 사용할 수 있나”를 훨씬 더 정확하게 답할 수 있습니다.
우리는 에이전트를 지속적으로 개선하고 있습니다. 모호한 질문을 처리하는 능력을 높이고, 더 강한 검증을 통해 신뢰성과 정확성을 강화하며, 워크플로에 더 깊이 통합하고 있습니다. 에이전트는 별도의 도구처럼 작동하기보다, 사람들이 이미 일하는 방식에 자연스럽게 녹아들어야 한다고 믿습니다.
우리의 툴링은 에이전트 추론, 검증, 자기수정의 기반 개선으로 계속 혜택을 받겠지만, 팀의 미션은 변함없습니다. OpenAI 데이터 생태계 전반에서 빠르고 신뢰할 수 있는 데이터 분석을 매끄럽게 제공하는 것입니다.
