AI가 작성한 쿼리는 실행에 성공했다는 이유만으로 신뢰를 얻기 쉽다. 그러나 기업이 쓰는 숫자는 데이터베이스 구조만으로 결정되지 않으며, 무엇을 어떻게 계산할지 합의해두지 않으면 오류도 정상적인 결과처럼 보인다.
좋은 쿼리, 잘못된 답
기업용 데이터 에이전트는 SQL 문법보다 의미를 해석할 때 더 자주 틀린다. Omni Analytics가 잘못된 쿼리 4,602건을 분석한 결과, 스키마 선택과 의미 해석 오류가 81.2% 였다. 문법 오류는 18.8%에 불과했다.
문제는 의미 오류다. SQL이 정상 실행되고 그럴듯한 숫자까지 내놓기 때문에 더 위험하다. 실제 기업 데이터베이스를 다룬 Spider 2.0 에서 기존 벤치마크를 91% 수준으로 풀던 모델의 성능은 17~21%로 떨어졌다. 확장 벤치마크인 Spider 2.0-AIFunc에서는 최신 모델도 67~70%에 그쳤다. 실패의 상당수는 답변 거부가 아니라 실행 가능한 오답이었다.
반면 지표의 정의와 예외 규칙을 주면 정확도가 크게 오른다. 한 벤치마크에서는 모델을 바꾸지 않고 비즈니스 정의만 추가했는데도 정확도가 45~50%대에서 67~68%대로 상승 했다. SQL 실력보다 모델이 추측할 여지를 줄이는 쪽이 정확도를 더 크게 좌우하지 않을까.
당신 회사의 매출은 무엇인가
‘매출’에도 여러 계산법이 있다. 계약액과 인식 매출 중 무엇을 쓸지, 환불을 언제 차감할지에 따라 값이 달라진다. 이탈률도 해지 고객만 셀지 다운그레이드까지 포함할지 정해야 한다. 컬럼명만 보고 알 수 있는 기준일까.
같은 지표도 회사마다 다르게 쓴다.
| 회사 | ARR 취급 |
|---|---|
| Zscaler | 비GAAP 재무지표 |
| SentinelOne | 주요 운영 지표 |
Zscaler는 ARR(연간반복매출)을 비GAAP 재무지표로, SentinelOne은 주요 운영 지표로 다룬다. 회사 안에서도 대시보드가 늘어나면 같은 이름에 다른 계산식이 붙는다. 이를 메트릭 드리프트라 부른다.
그런데 숫자가 익숙할수록 사람들은 검증을 덜 한다. 재무 리더의 90%가 AI를 주요 의제로 다뤘지만 실행 계획을 세운 비율은 30%에 그쳤다. 자사 데이터를 믿지 못하는 점 이 주요 원인으로 꼽혔다. 하지만 데이터베이스 스키마는 컬럼의 위치만 알려줄 뿐 회사가 승인한 계산식은 알려주지 않는다. 이 정의가 없으면 에이전트는 쿼리마다 회사가 합의하지 않은 판단을 내린다.
시맨틱 레이어가 오답을 거부한다
거버넌스된 시맨틱 레이어는 지표의 계산식과 허용된 조인 경로를 미리 정한다. 정의하지 않은 조합에는 숫자 대신 오류를 돌려준다. dbt의 2026년 벤치마크에서 이를 적용하자 Claude Sonnet 4.6의 정확도는 90.0%에서 98.2%로 올랐다. GPT-5.3-Codex는 84.1%에서 100%로 상승했다. 지원하지 않는 질문에는 오류를 돌려주는 동작까지 정확도 계산에 넣은 결과다.
이 방식은 프로그래밍의 타입 시스템과 비슷하다. 지표의 자료형과 집계 방식, 사용할 관계를 선언하면 잘못된 조인은 실행 전에 거부된다. 거부된 기록에는 어떤 정의가 빠졌는지도 남는다.
그 정의가 바뀌면 어떨까. 이탈 기준을 ‘90일 미사용’에서 ‘60일 미사용’으로 바꿨다면 적용 시점과 승인자를 남겨야 하는 것처럼, 정의에도 버전 관리가 필요하다. 그래야 과거 보고서를 당시 기준으로 재현할 수 있다. 로그에도 질문과 실행 시각뿐 아니라 사용한 정의, 버전, 원본 데이터를 남긴다. EU AI법 제12조 이 고위험 AI 시스템에 요구하는 추적성도 이런 재현 가능성을 뜻한다.
컴퍼니 브레인에 숫자의 규칙을 심어라
회사의 지식을 한곳에 모을 때는 문서와 수치를 구분해야 한다. Y Combinator가 제안한 ‘컴퍼니 브레인’은 흩어진 지식을 모아 환불, 가격 예외, 장애 대응에 쓸 수 있게 구조화 한다. 문서 검색에는 어느 정도의 근사치가 허용되지만, 공식 매출은 승인된 값 하나를 내야 한다.
문서와 수치를 다루는 역할도 다르다.
- 문서 검색은 방법을 찾고, 도구 레지스트리는 무엇을 실행할 수 있는지 정리하며, 시맨틱 레이어는 그 숫자가 무엇을 뜻하는지 규정한다.
- 반면 MCP(Model Context Protocol)는 도구 호출 규약이지 지표 승인 체계가 아니다.
공식 레지스트리에 9,652개의 최신 서버 레코드 가 등록될 만큼 연결 범위가 넓어진 만큼 권한과 감사 추적은 따로 설계해야 한다. MCP 도구 오염 사례 도 연결 기술과 정책을 분리해야 하는 이유를 보여준다.
그래서 재무와 운영 부서가 지표 정의를 승인하고 모든 에이전트가 이를 함께 쓰면 된다. 환불 한도와 가격 예외도 권고문이 아니라 실행을 막는 정책으로 작동한다. 보드덱의 숫자에는 정의, 버전, 검증된 조인 경로가 따라붙어야 한다. 부서별 값이 다르면 그럴듯한 쪽을 고르는 대신 정의가 갈린 지점을 찾는다.
CFO는 매번 숫자를 다시 세는 대신 정의와 변경을 승인하고 과거 버전을 관리한다. 에이전트는 그 규칙을 통과한 계산만 제출한다. 이 절차를 거친 숫자는 나중에 설명되고 재현되며 책임 소재도 남는다.
사람들은 과연 결과 화면만 보고 숫자를 믿을까. 그 결과가 나온 경로를 보고 숫자를 신뢰한다. 같은 질문에 같은 기준으로 답한 기록이 쌓일수록 AI는 그때그때 돌리는 분석 도구가 아니라 조직이 공식적으로 쓰는 업무 체계로 자리 잡는다.