3,500명의 직원이 70,000개의 데이터셋 중에서 필요한 정보를 찾아야 한다면 어떨까요? “비슷해 보이는 테이블이 너무 많아서 어떤 게 다른지 파악하는 데만 엄청난 시간이 걸린다”는 게 OpenAI 내부 직원들의 솔직한 고백이었습니다. 그래서 OpenAI는 직접 AI 데이터 에이전트를 만들었습니다.
OpenAI가 자사 직원들을 위해 만든 맞춤형 AI 데이터 에이전트에 대한 공식 기술 블로그를 발표했습니다. 이 에이전트는 현재 OpenAI 내부에서 엔지니어링, 데이터 과학, 영업, 재무, 연구 부서 직원들이 실제로 사용 중입니다. 600페타바이트 규모의 데이터에서 자연어 질문만으로 SQL 쿼리 생성부터 분석, 리포트 작성까지 자동으로 처리하죠. 6개월 만에 월 처리량이 수백 건에서 1,000건 이상으로 늘었지만, 추가 인력은 단 1명뿐이었습니다.
출처: Inside OpenAI’s in-house data agent – OpenAI
실제로 어떻게 작동하나
“뉴욕 택시 데이터에서 출발-도착 ZIP 코드 쌍 중 어느 구간이 가장 불안정하고, 전형적 시간과 최악의 경우 차이가 가장 크며, 언제 그런 변동이 발생하는가?”
이런 복잡한 질문을 던지면 에이전트는 다음 과정을 거칩니다:
- 관련 테이블 찾기: 70,000개 중에서 택시 운행 데이터 테이블 식별
- 필요한 컬럼 파악: 출발/도착 ZIP, 소요시간, 타임스탬프
- SQL 쿼리 생성: 통계 계산과 집계 쿼리 작성
- 중간 검증: 쿼리 실행 후 0행 반환되면 → 조인 방식이 잘못됐다고 판단 → 다른 방법 시도
- 결과 해석: 데이터를 분석하고 패턴을 찾아 인사이트 제시
이 모든 과정이 자동으로 진행되며, 중간에 막히면 사용자에게 명확한 질문을 던집니다. “날짜 범위를 지정하지 않으셨는데, 최근 30일로 가정하고 진행할까요?” 응답이 없으면 합리적인 기본값을 적용해 계속 진행하죠.
코드까지 읽어야 테이블을 안다
OpenAI의 데이터 에이전트가 특별한 이유는 테이블을 생성한 코드 자체를 읽는다는 점입니다.
예를 들어 “사용자 활동” 테이블이 두 개 있다고 해보죠. 컬럼 이름만 보면 거의 똑같습니다. 하지만 하나는 로그아웃한 사용자를 포함하고, 다른 하나는 로그인 사용자만 추적합니다. 이런 차이는 스키마나 과거 쿼리만 봐서는 절대 알 수 없습니다.
그래서 에이전트는 Codex를 활용해 데이터 파이프라인 코드를 크롤링합니다. 테이블 생성 코드를 읽으면서 다음을 파악하죠:
- 어떤 필터가 적용되는가 (로그인 여부, 특정 이벤트 타입)
- 데이터 갱신 주기 (실시간인가, 일 단위인가)
- 데이터 범위 (전체 트래픽인가, ChatGPT만인가)
“이 테이블은 ChatGPT 자사 트래픽만 포함하는가?” 같은 질문에 정확히 답할 수 있는 이유입니다.
6개 레이어로 쌓아올린 컨텍스트
에이전트는 6개 레이어의 컨텍스트를 조합해 정확한 답을 찾습니다:
1. 메타데이터: 테이블 스키마, 컬럼 타입, 테이블 간 관계(A와 B를 조인하려면 어떤 키를 써야 하는지)
2. 쿼리 추론: 과거 수천 개 쿼리를 분석해 “사용자 테이블과 구매 테이블은 주로 user_id로 조인된다”는 패턴 학습
3. 전문가 설명: 데이터 엔지니어가 작성한 테이블 설명 (“이 테이블에는 테스트 계정이 포함됨”)
4. 코드 기반 정의: 위에서 설명한 파이프라인 코드 분석
5. 조직 지식: Slack, Google Docs, Notion에서 회사 내부 용어, 프로젝트 코드명, 실험 이름 등을 추출. “Q3 성장 이니셔티브”가 내부적으로 “Project Phoenix”로 불린다는 것도 파악합니다.
6. 런타임 컨텍스트: 필요시 실시간으로 데이터 웨어하우스에 쿼리해 테이블 샘플 데이터를 확인하거나 최신 스키마 변경사항을 체크
한 번 배우면 다음엔 기억한다
가장 흥미로운 건 메모리 시스템입니다.
예를 들어 한 직원이 “Q3 실험 결과 보여줘”라고 물었는데 에이전트가 잘못된 데이터를 가져왔다고 해보죠. 직원이 “아니야, 이 실험은 ‘exp_growth_v3’라는 정확한 문자열로 필터링해야 해”라고 수정합니다.
그러면 에이전트가 묻습니다: “이 내용을 다음에도 기억할까요?”
승인하면 이 지식이 메모리에 저장됩니다. 다음번에 누군가 같은 실험에 대해 물으면, 에이전트는 처음부터 올바른 필터를 적용합니다. 퍼지 매칭으로 비슷한 문자열을 찾으려다 실패하는 실수를 반복하지 않죠.
이 메모리는 개인 레벨과 전체 조직 레벨로 관리되며, 사용자가 직접 편집할 수도 있습니다.
신뢰를 지키는 법: 지속적 평가
항상 켜져 있고 계속 진화하는 에이전트는 품질이 개선될 수도, 나빠질 수도 있습니다. OpenAI는 이 문제를 Evals(평가)로 해결합니다.
핵심 비즈니스 질문들(“지난 분기 MAU는?”, “제품별 전환율은?”)에 대해 정확한 답을 내는 “골든 SQL”을 미리 작성해둡니다. 에이전트가 생성한 SQL과 골든 SQL을 모두 실행해보고, 결과를 비교하죠.
단순히 문자열이 같은지 확인하는 게 아닙니다. 생성된 SQL이 구조는 다르지만 결과는 같을 수 있고, 추가 컬럼이 있어도 핵심 답은 맞을 수 있습니다. OpenAI의 Evals API가 SQL 구조와 결과 데이터를 종합적으로 평가해서 점수를 매깁니다.
이 평가는 개발 중에는 유닛 테스트처럼, 프로덕션에서는 조기 경보 시스템처럼 작동합니다. 새 기능을 추가할 때마다 기존 기능이 망가지지 않았는지 즉시 확인할 수 있죠.
보안 측면에서도 에이전트는 사용자 권한을 그대로 따릅니다. 당신이 접근할 수 있는 테이블만 쿼리하고, 권한이 없으면 명확히 표시합니다. 모든 추론 과정을 요약해서 보여주고, 쿼리 결과는 원본 데이터로 직접 링크되어 검증 가능합니다.
실패에서 배운 것들
OpenAI는 개발 과정에서 얻은 교훈도 솔직하게 공개했습니다.
도구 중복 문제: 초기에는 비슷한 기능을 하는 도구를 여러 개 제공했습니다. 예를 들어 테이블 정보를 조회하는 방법이 3가지였죠. 사람에게는 명확한 차이지만 에이전트는 혼란스러워했습니다. “지금 어떤 걸 써야 하지?” 결국 도구를 통합하고 선택지를 줄이니 정확도가 크게 개선됐습니다.
과도한 프롬프트의 역효과: “이런 경우엔 이렇게, 저런 경우엔 저렇게” 식으로 너무 상세한 지시를 주면 오히려 성능이 떨어졌습니다. 다양한 질문에 유연하게 대응하기 어려웠던 거죠. 고수준 가이드라인만 제공하고 GPT-5의 추론 능력에 맡기자 결과가 더 좋아졌습니다.
AI 에이전트의 실전 교과서
OpenAI의 데이터 에이전트는 “AI가 업무를 도울 수 있다”는 추상적 약속을 구체적 실행으로 옮긴 사례입니다. 며칠 걸릴 분석을 몇 분으로 줄인다는 건 단순히 빠른 SQL 생성이 아니라, 올바른 테이블을 찾고, 정확한 조인을 수행하고, 결과를 검증하고, 배운 것을 기억하는 전체 시스템이 필요하다는 걸 보여줍니다.
무엇보다 이 에이전트를 만드는 데 사용된 도구(Codex, GPT-5, Evals API, Embeddings API)는 모두 외부 개발자도 사용할 수 있는 것들입니다. OpenAI가 보여준 건 기술 자체보다 어떻게 조합하고 설계하느냐가 실용성을 결정한다는 점이죠.
참고자료:
- Turning contracts into searchable data at OpenAI – OpenAI (OpenAI가 같은 시리즈로 공개한 계약서 검토 에이전트 사례)
답글 남기기