데이터를 묻는 방식은 대시보드의 메뉴와 필터에 오래 맞춰져 있었다. 자연어로 질문하는 도구가 늘면서 화면의 완성도보다 조직이 숫자의 의미를 얼마나 명확히 적어 두었는지가 답의 품질을 좌우한다.
대시보드가 답하지 못한 질문
LangChain의 데이터팀은 세 명이다. 요청이 몰리자 질문은 순서를 기다렸고 답을 기대하기 어려운 질문은 아예 나오지도 않았다. 셀프서비스 에이전트를 도입한 뒤에는 최근 30일간 약 2,200건의 대화가 오갔다. 사용자당 월평균 23건으로 데이터팀이 직접 처리하던 요청의 약 40배에 이른다.
업무 속도가 40배 빨라진 것일까. 그동안 묻지 못했던 질문까지 드러난 결과다. 대시보드는 미리 정한 질문에는 잘 답하지만 “지난달 이탈 고객 중 다운그레이드한 곳은?” 같은 후속 질문에는 약하다. 실무 분석은 이런 질문을 거듭하며 답을 좁혀 가는 과정이다. 화면을 늘리는 방식에는 한계가 있다. 실제로 직원의 29%만 비즈니스 인텔리전스(BI) 도구를 쓰고 조직의 58%는 채택률이 25%에 못 미친다.
그래서 데이터의 정의와 관계, 업무 규칙은 완성된 화면보다 에이전트에 중요하다. ARR(연간 반복 매출) 계산법과 고객, 계약 모델의 관계가 정리돼 있으면 다양한 질문에도 같은 기준으로 답할 수 있다. LangChain은 기존 BI 도구를 6주 만에 옮겼고, 이 과정에서 dbt(데이터 변환, 모델링 도구) 모델과 정의를 활용했다. 핵심은 대시보드 화면이 아니라 그 안에 있던 계산 논리였다.
정의 하나가 정확도를 바꾼다
account_status를 ‘계정 상태’라고만 적으면 에이전트는 의미를 추측해야 한다. ‘Salesforce의 현재 라이프사이클 상태’라고 밝히고 Active, Churned, Prospect의 조건, 고객 보고에는 Active만 포함한다는 원칙까지 적으면 판단 기준이 생긴다. LangChain이 권하는 정의는 이처럼 컬럼 설명에 열거값과 기본 필터를 함께 담는다.
좋은 맥락은 모델 성능만큼 중요하다. dbt Labs의 벤치마크에서 스키마(데이터베이스의 구조 정보)만 제공했을 때 정확도는 Claude Sonnet 4.6이 90.0%, GPT-5.3 Codex가 84.1%였다. 시맨틱 레이어는 지표 정의와 테이블 관계, 조인 규칙을 한곳에 명시해 질의를 통제하는 계층이다. 시맨틱 레이어를 더하자 각각 98.2%와 100%로 올랐다. 반면 원래의 고도로 정규화된 스키마에서 11개 질문을 시험했을 때 정확도는 64.5%까지 떨어졌다.
| 모델 | 스키마만 | 시맨틱 레이어 추가 |
|---|---|---|
| Claude Sonnet 4.6 | 90.0% | 98.2% |
| GPT-5.3 Codex | 84.1% | 100% |
시맨틱 레이어는 실패도 안전하게 만든다. 일반 Text-to-SQL(자연어 질문을 SQL 질의로 바꾸는 방식)은 잘못된 조인(여러 테이블을 연결하는 연산)으로 그럴듯한 오답을 낼 수 있지만 시맨틱 레이어는 정의 밖의 요청에 오류를 낸다. 오류는 원인을 찾을 수 있다. 정상 실행된 오답은 알아채기조차 어렵다.
게다가 기업 환경에서는 필요한 컬럼을 찾는 것부터 난관이다. 컬럼이 1,000개가 넘는 Spider 2.0 초기 리더보드에서 o1-preview의 성공률은 약 17%에 그쳤다. 자세한 컬럼 정의는 탐색 범위를 줄이는 색인 역할을 한다.
그 맥락은 성격에 따라 나눠 둔다. dbt에는 테이블과 컬럼의 의미를, 시맨틱 모델에는 메트릭(업무 지표) 계산법과 모델 관계를 적는다. 업무 규칙은 평문 가이드에 두고 실제 SQL은 GitHub에서 확인한다. 여러 후보 중 믿을 만한 자산을 표시하는 endorsement 권한은 제한된 관리자만 갖는다.
어디서 물어도 ARR은 같아야 한다
LangChain에서는 모든 직원이 새 데이터 스택을 쓰지만 권한은 다르다. 약 70%는 읽기 전용 권한을 갖고 30%만 에이전트에 접근한다. 셀프서비스 이용 권한과 정본 관리 권한을 분리한 구조다.
접점도 Hex 화면에 가두지 않았다. Slack과 CLI, MCP, 노트북에서도 같은 데이터 맥락을 불러온다. 질문이 대시보드 앞에서만 생길까. 업무 대화나 코딩 중 떠오른 의문도 그 자리에서 묻는다.
MCP로 연결하면 데이터는 다른 에이전트도 쓰는 도구가 된다. 코드 에이전트는 배포 전 사용량을 확인하고 지원 에이전트는 고객 상태를 조회한다. 어느 경로에서 묻든 같은 정의를 참조해야 답도 같다. BI, 분석 엔지니어링, AI가 지표를 따로 정의해 생기는 불일치는 접점이 많을수록 더 자주 드러난다.
대화에서 만든 노트북과 쿼리는 다음 분석에 다시 쓸 수 있다. 다만 Slack의 ARR과 노트북의 ARR이 달라서는 안 된다. 사용 경로는 넓어지지만 메트릭 정의와 정본은 한곳에서 관리한다.
버린 것은 화면뿐
데이터 에이전트의 품질은 배포로 완성되지 않는다. 스키마와 제품이 바뀌면 정의도 낡는다. Hex Context Studio는 대화와 오류를 분류하고 수정 내용을 배포 전에 시험하게 한다. 자체 에이전트에서는 LangSmith 같은 관측 가능성 도구가 이 역할을 맡는다.
데이터팀은 반복되는 실패를 찾아 모델과 가이드를 고친다. 비슷한 질문 열두 건에 따로 답하는 대신 공통으로 참조하는 정의 하나를 바로잡는다. 역할도 요청마다 SQL을 쓰는 데서 모델, 맥락, 가드레일(오류와 권한을 통제하는 안전장치)을 관리하는 쪽으로 바뀐다. 중요한 의사결정은 데이터팀이 직접 검증한다는 규칙도 필요하다.
운영 조건은 네 가지다.
- 예외까지 담은 정의
- 정본을 승인하는 제한된 권한
- 기존 업무 공간에서의 접근
- 실패를 검토하고 수정하는 절차다.
하나라도 빠지면 새 도구는 기존의 혼선을 더 빠르게 되풀이한다.
그렇다면 먼저 손댈 것은 대시보드가 아니라 데이터에 담긴 판단이다. 그 판단을 문장으로 옮기는 일은 거창한 AI 전략이 아니라 컬럼 하나에 제대로 된 세 문장을 적는 데서 시작한다.
결국 질문할 수 있는 곳이 많아질수록 데이터팀의 일은 답변 생산보다 공통 기준의 유지에 가까워진다. 에이전트가 드러내는 오류와 애매한 질문은 데이터 문서에서 어느 부분이 아직 사람의 추측에 기대는지 보여주는 운영 기록이 된다.