AI VIDEO BRIEFING

OpenAI 데이터 에이전트 구조: 모델 하나와 도구 13개로 사내 질문에 답한다

OpenAI 사내 데이터 에이전트는 라우터도 파인튜닝도 없이 모델 하나와 도구 13개로 돌아간다. 7만 개가 넘는 테이블 중에서 정답을 찾아내는 컨텍스트 조립 계층의 설계와, 이를 만든 팀이 직접 밝힌 다섯 가지 엔지니어링 교훈을 정리했다.

OpenAI는 왜 사내 데이터 에이전트를 일부러 단순하게 만들었나 영상 대표 이미지

핵심 메시지

  • OpenAI 사내 데이터 에이전트는 매일 수천 명의 직원이 쓰지만, 라우터·다중 모델·파인튜닝 없이 모델 하나와 도구 13개, 실행 루프, 컨텍스트 조립 계층만으로 구성돼 있다.
  • 어려운 일은 질문이 도착하기 전에 끝난다. 7만 개가 넘는 사내 테이블 중 어떤 것을 써야 하는지 미리 정리해 두는 컨텍스트 조립 계층이 이 설계의 핵심이다.
  • 스키마만으로는 테이블을 구분할 수 없어서, 과거 쿼리 사용 기록과 담당자가 남긴 주석, 매일 밤 코드를 읽는 자동화 작업 세 가지를 합쳐 테이블 설명을 만든다.
  • 도구를 40개에서 겹치지 않는 13개로 줄이자 에이전트가 엉뚱한 도구를 고르거나 상충하는 답을 받는 문제가 사라졌다.
  • 에이전트보다 데이터 기반이 먼저다. 모든 테이블이 규약이 강제되는 하나의 저장소에서 나오기 때문에 평범한 에이전트도 신뢰할 만하게 동작한다.

쉽게 이해하기

AI 에이전트를 만드는 흐름은 갈수록 복잡해지고 있다. 여러 에이전트를 잇는 파이프라인, 질문 난이도를 가르는 라우터, 사내 데이터로 미세 조정한 모델이 흔히 등장한다. 그런데 최전선 연구소 내부에서는 오히려 반대 방향으로 가고 있다. ByteByteGo가 OpenAI 데이터 플랫폼 책임자 엠마 통을 만나 들은 사내 데이터 에이전트 이야기는 '꽤 단순하다'는 말로 요약된다.

이 에이전트가 하는 일은 이렇다. 엔지니어가 슬랙에 '지난 몇 주간 활성 사용자가 몇 명이었나요'라고 평범한 문장으로 물으면, 몇 초 뒤 답과 함께 실제로 실행한 SQL과 참조한 테이블 목록이 돌아온다. 구조를 뜯어보면 요청마다 같은 모델 하나를 쓰고, 도구는 13개이며, 나머지는 실행 루프와 컨텍스트를 모아 주는 계층뿐이다. 보통 시스템이 복잡해지는 지점들을 통째로 건너뛴 셈이다.

단순함이 가능한 이유는 사전 작업에 있다. 사내 데이터 창고에는 테이블이 7만 개가 넘어서, 질문에 답하려면 우선 쓸 만한 테이블부터 찾아야 한다. 스키마를 그대로 넣는 방법이 가장 먼저 떠오르지만 그것으로는 부족하다. 두 테이블이 똑같이 사용자 ID 열을 갖고 있어도 한쪽은 로그아웃 사용자를 포함하고 다른 쪽은 아닐 수 있는데, 스키마 어디에도 그 차이는 적혀 있지 않기 때문이다.

그래서 팀은 테이블 설명을 세 갈래로 만든다. 사람들이 그 테이블을 과거에 어떻게 조회했는지 보여주는 사용 기록, 테이블 담당자가 직접 쓴 주석, 그리고 매일 밤 테이블 뒤의 코드를 읽어 실제 내용과 쓰임새를 기록하는 자동화 작업이다. 이 셋을 하루 한 번 하나의 설명으로 합쳐 검색용으로 임베딩해 둔다. 여기에 사내 문서와 메신저에서 온 지식, 지난 대화에서 지적받아 기억해 둔 교정 사항이 더해진다.

질문이 들어오면 관련 테이블 설명과 지식을 꺼내고 기억을 붙여 컨텍스트를 완성한다. 그다음은 단순하다. 에이전트는 SQL을 쓰고, 실행하고, 결과를 확인하고, 답이 설 때까지 다듬는다. 같은 자동화 도구는 사내 다른 일도 맡아, 클라우드 용량이 바닥났을 때 테이블 9만 개와 600페타바이트 규모를 옮기는 변경 요청을 만들어 약 두 달 만에 이전을 끝냈고 십여 개 오픈소스 포크의 패치 배포와 지원 티켓 조사도 사람 손 없이 처리하고 있다.

주요 인사이트

  • 에이전트를 복잡하게 만드는 장치들은 저마다 도움이 되지만 그만큼 비용과 지연, 그리고 새로운 실패 지점을 함께 들여온다. OpenAI는 그 교환을 피하고 대신 컨텍스트 품질에 투자했다.
  • 데이터가 흩어져 있다면 첫 투자 대상은 에이전트가 아니라 기반이다. 규약이 지켜지고 주석이 붙은 데이터 위에서라야 특별할 것 없는 에이전트도 제 몫을 한다.
  • 도구는 많을수록 좋지 않다. 비슷한 일을 하는 도구가 섞여 있으면 모델이 무엇을 골라야 할지 흔들리고 서로 다른 답이 돌아온다.
  • 과거 쿼리를 전부 학습 예시로 넣는 시도는 실패했다. 대부분의 쿼리는 일회성 실험이라 좋은 본보기가 아니어서, 많이 쓰이는 대시보드가 참조하는 쿼리를 위로 올리는 신뢰도 순위가 해법이 됐다.
  • 프롬프트로 단계를 하나하나 지시하자 답이 오히려 나빠졌다. 높은 수준의 목표와 좋은 컨텍스트, 적절한 도구를 주고 경로는 모델에 맡기는 편이 나았다.

자주 묻는 질문

OpenAI 사내 데이터 에이전트는 구체적으로 무엇을 해 주나요?

엔지니어가 슬랙에서 평범한 문장으로 데이터를 물으면 몇 초 안에 답을 돌려줍니다. 이때 답만 주는 것이 아니라 실제로 실행한 SQL과 참조한 테이블까지 함께 보여주기 때문에 결과를 검증할 수 있습니다.

테이블이 7만 개나 되는데 어떻게 맞는 것을 고르나요?

질문이 오기 전에 미리 만들어 둔 테이블 설명을 검색해서 씁니다. 설명은 과거 쿼리 사용 기록, 테이블 담당자가 쓴 주석, 매일 밤 코드를 읽어 실제 내용을 기록하는 자동화 작업을 하루 한 번 합쳐 만듭니다.

도구 개수를 왜 줄였나요?

처음에는 약 40개로 시작했는데, 에이전트가 엉뚱한 도구를 고르거나 비슷한 일을 하는 도구들에서 서로 어긋나는 답을 받는 일이 반복됐습니다. 기능이 겹치지 않는 13개로 제한하자 이 문제가 해결됐습니다.

이 사례에서 일반 엔지니어가 가져갈 교훈은 무엇인가요?

기반이 에이전트보다 중요하고, 도구는 적을수록 낫고, 과거 사례는 신뢰도로 걸러야 하며, 경로 대신 목표를 지시하라는 것입니다. 마지막으로 AI 이전 시대의 일정 추정은 더 이상 맞지 않으니 더 야심 차게 잡으라는 조언도 있었습니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식