자연어로 데이터베이스를 다루는 일이 쉬워질수록, 답이 만들어진 경로를 확인하는 일은 더 복잡해진다. 데이터 에이전트가 그럴듯한 결과를 내놓는 것과 조직의 기준에 맞는 결과를 내놓는 것은 별개의 문제다.
이름이 비슷한 테이블들
OpenAI의 데이터 플랫폼에서는 3,500명 넘는 사용자가 7만 개 데이터셋, 600페타바이트의 데이터를 다룬다. 이곳에서 어려운 일은 쿼리 작성보다 알맞은 테이블을 고르는 것이었는데, 이름이 비슷해도 포함 대상과 집계 기준이 달랐기 때문이다. 내부 사용자들도 테이블을 구분하는 데 많은 시간을 쓴다고 답했다.
events_user_daily와 user_events_v2를 모두 찾아도 어느 쪽이 비로그인 사용자를 포함하는지는 이름이나 컬럼으로 알기 어렵다. 검색 기능을 개선하는 것만으로 해결될까. 데이터가 만들어진 목적과 조직에서 쓰이는 방식을 알아야 한다.
그 한계는 벤치마크에서도 확인된다. GPT-4o는 Spider 1.0에서 86.6%를 기록했지만 기업 환경을 반영한 Spider 2.0에서는 10.1%에 그쳤다. 수천 개의 컬럼과 여러 SQL 방언, 다단계 변환이 더해지자 SQL 생성보다 데이터 구조와 작업 절차의 파악이 더 어려워졌다.
그런데 다대다 조인으로 행이 불어나거나 NULL을 잘못 처리해도 차트는 나온다. 틀린 쿼리도 멀쩡히 실행된다는 점이 더 큰 문제다. 실행 성공을 정답으로 착각하지 않으려면 예상과 다른 수치를 의심하고 중간 결과를 확인해야 한다.
스키마가 말해주지 않는 것
OpenAI는 스키마에 사용 이력, 리니지(데이터가 만들어지고 이동한 경로), 과거 쿼리를 결합했다. 스키마를 보면 데이터의 형태를 알 수 있지만 어떤 테이블을 함께 쓰고 어떻게 연결하는지는 쿼리 이력에 남는다. 자주 쓰이는 조합과 공식 분석 관행도 여기서 찾을 수 있다.
도메인 전문가의 설명은 봇 트래픽 제외 여부처럼 스키마로 알 수 없는 조건을 보충한다. 하지만 수동 문서는 금세 낡는다. 그래서 OpenAI는 Codex로 코드베이스를 읽어 데이터 범위, 집계 단위, 변환 로직, 갱신 주기를 추출했다. 설명도 코드가 바뀔 때마다 자동으로 갱신된다. 테이블의 실제 의미는 그것을 만드는 코드에 있다는 판단이다.
게다가 웨어하우스 밖의 정보도 필요하다. Slack과 문서에는 출시 일정, 장애, 지표 정의 변경이 남는다. 특정 달의 수치가 바뀐 이유가 마이그레이션이라면, 데이터만 봐서는 그 이유를 어떻게 알 수 있을까.
다만 검색 범위를 넓힐 때는 원본 권한을 그대로 적용해야 한다. 그렇지 않으면 맥락이 풍부해지는 만큼 노출 위험도 커진다. OpenAI의 에이전트는 사용자가 볼 수 있는 테이블만 조회하고 권한이 없으면 허용된 데이터셋에서 대안을 찾는다.
교정된 규칙을 저장하고 관리하는 법
메모리는 에이전트가 일하면서 새로 만든 맥락이다. 특정 실험의 필터나 제외할 내부 계정은 스키마와 코드만으로 찾기 어렵다. status = 'active'가 아니라 status IN ('active', 'trialing')을 써야 한다는 교정을 저장하지 않으면 같은 실수가 반복된다. OpenAI는 이런 필터와 제약을 다음 분석에 재사용한다.
다만 메모리는 전사 규칙과 개인 설정으로 나눠야 한다. 봇 트래픽 제외는 모두가 공유할 규칙이지만 성장률을 주간 대비로 보는 습관은 개인 설정에 가깝다. 둘을 섞으면 어떻게 될까. 개인의 표현이 회사 표준으로 굳거나, 공통 규칙을 사용자마다 다시 확인하게 된다.
저장 방식도 중요하다. 메모리 전체를 매번 요약하면 세부 조건이 사라진다. 맥락을 통째로 재작성하는 대신 필요한 부분만 갱신하는 방식을 다룬 ACE(Agentic Context Engineering) 논문은 이 위험을 다른 기법의 실패 사례로 확인했다. 그 논문은 AppWorld 벤치마크에서 별도 기법인 Dynamic Cheatsheet가 맥락을 1만8,282토큰에서 122토큰으로 압축하자 정확도가 66.7에서 57.1로 떨어졌다고 밝혔다. 전체 재작성보다 항목별 변경분을 반영해야 하는 이유다.
그렇다고 저장된 정보가 최신이라는 보장도 없다. 새 테이블이 생기거나 설명이 낡았다면 실행 시점에 스키마와 값을 다시 확인해야 한다. 메모리에는 과거 실행을 통째로 남기기보다 교정된 규칙과 적용 조건을 구조화해 저장하는 편이 안전하다.
골든 SQL을 카나리로 세워라
전사 데이터 에이전트에는 하나의 RAG가 아니라 성격이 다른 여섯 가지 맥락이 필요하다.
- 쿼리 이력과 리니지
- 도메인 전문가의 주석
- 파이프라인 코드에서 추출한 정의
- 권한이 적용된 사내 문서와 대화
- 업무 중 축적한 메모리
- 실행 시점의 라이브 조회
다만 RAG는 관련 정보를 찾는 수단일 뿐, 정보의 생성과 갱신, 권한 관리까지 대신하지는 않는다.
그래서 구축은 이미 있는 자산부터 시작한다. 쿼리와 리니지는 웨어하우스에 남아 있고 코드 분석도 파이프라인 저장소에서 바로 시작할 수 있다. 전문가 주석은 꼭 필요한 빈틈에 집중한다. 메모리는 운영을 시작한 뒤에야 만들어지므로 초기 기반으로 삼기 어렵다.
그다음은 검증이다. 결과가 0행이거나 집계값이 비정상적이면 조인과 필터를 바꿔 다시 실행해야 한다. 질문과 기준 쿼리를 짝지은 골든 SQL 평가로 결과 집합을 비교하면 품질 변화도 추적할 수 있다. OpenAI는 이 평가를 카나리(변경으로 생긴 회귀를 조기에 감지하는 지속 평가)로 삼아 개발과 프로덕션에서 계속 실행한다.
또한 반복 분석은 재실행 가능한 워크플로로 저장한다. 매주 같은 분석을 대화로 다시 만들면 테이블과 필터가 조금씩 달라진다. 검증된 절차를 고정해두면 대화는 새로운 질문과 예외 처리에 집중할 수 있다.
결국 좋은 데이터 에이전트를 좌우하는 기준은 SQL을 한 번 잘 만드는 능력이 아니다. 올바른 맥락을 찾고 권한을 지키며 결과를 검증하고 오늘의 교정을 내일도 적용하는 능력이다.
그런데 에이전트가 축적한 맥락은 시간이 지날수록 유용해지지만 언제 만들어졌고 누구에게 적용되는지에 따라 의미가 달라진다. 데이터 업무의 자동화가 늘어날수록 분석 결과뿐 아니라 판단에 쓰인 맥락의 이력도 운영 대상이 된다.