'데이터에게 자연어로 물어보세요’라는 기능은 데모에서 잘 작동해 보인다. 하지만 같은 “지난달 매출” 질문도 환불, 세금, 취소 주문, 환율을 어떻게 처리하느냐에 따라 서로 다른 SQL과 결과가 나올 수 있다. 쿼리 문법이 모두 맞더라도 조직이 매출의 기준을 합의하지 않았다면 어느 결과를 공식 수치로 써야 할지 정할 수 없다.
SQL 정확도만으로는 충분하지 않다
텍스트-투-SQL 모델의 문법과 실행 정확도는 계속 좋아지고 있다. BIRD처럼 실제 데이터베이스를 반영한 벤치마크에서도 높은 점수를 내는 모델이 등장했다. 다만 벤치마크의 실행 정확도는 생성된 쿼리가 기대한 결과와 일치하는지를 볼 뿐, 조직이 사용하려는 지표 정의가 맞는지까지 보장하지 않는다.
FLEX 연구는 기존 실행 정확도와 인간 전문가 평가가 완전히 일치하지 않는 사례를 분석했다. 같은 결과를 내는 합리적인 쿼리가 여러 개일 수 있고, 데이터베이스 상태에 따라 잘못된 쿼리도 우연히 같은 결과를 낼 수 있기 때문이다. 여기에 환불과 세금처럼 조직별 규약까지 더해지므로, 모델 평가와 업무 지표 검증을 분리해야 한다.
스키마와 함께 업무 규칙도 전달한다
데이터베이스 스키마는 테이블 이름, 컬럼 타입, 외래키를 설명한다. 주석이나 별도 메타데이터에 업무 규칙을 기록할 수도 있지만, 실제로는 환불·세금·취소 주문 처리 기준이 BI 쿼리나 팀 문서에 흩어져 있는 경우가 있다. 에이전트가 이 정의를 찾지 못하면 컬럼 구조만 보고 계산 기준을 추론하게 된다.
스키마만 받은 모델은 빠진 업무 규칙을 추론해 쿼리를 만든다. 환불을 뺄지, 취소 주문을 어느 날짜에 반영할지 명시되지 않았다면 프롬프트 표현에 따라 다른 선택을 할 수 있다. 스키마는 테이블과 컬럼의 구조를 설명하고, 의미 계층은 지표와 용어의 계산 기준을 설명한다. 두 정보가 함께 있어야 쿼리 결과를 조직의 공식 수치와 맞출 수 있다.
의미 계층과 온톨로지는 연결해서 쓸 수 있다
시맨틱 레이어는 이런 업무 규칙을 버전 관리되는 코드로 정의한다. 예를 들어 매출을 완료 주문 금액에서 환불을 빼고 세금을 제외한 값으로 정했다면, 여러 대시보드와 에이전트가 같은 계산식을 사용하게 한다. dbt의 MetricFlow 같은 도구는 지표 정의를 중앙에서 관리하고 여러 질의 경로에 적용하는 방식을 제공한다.
시맨틱 레이어는 지표와 차원의 계산 규칙을 관리하고, 온톨로지는 고객·주문 같은 엔터티와 관계, 행동 규칙까지 더 넓게 표현할 수 있다. 두 개념은 같지 않지만 함께 사용하면 에이전트가 합의된 지표와 관계를 우선 조회하게 할 수 있다. 오픈 시맨틱 인터체인지(OSI)처럼 지표 정의를 여러 도구 사이에서 교환하려는 시도도 이 문제를 다룬다.
자주 쓰는 지표부터 정의한다
작은 팀이라면 자주 묻는 지표부터 다음 순서로 정리할 수 있다.
- 자주 쓰는 지표부터 정의하라. 데이터 질의 기능을 붙이기 전에 매출·활성사용자·이탈처럼 자주 묻는 지표의 계산식과 담당자를 버전 관리되는 코드에 기록한다.
- 에이전트가 의미 계층을 우선 조회하게 하라. 정의된 지표는 좁은 API로 제공하고, 원시 SQL이 필요한 예외에는 추가 검증을 둔다.
- 업무 규칙의 일관성을 검증하라. 같은 지표 질문이 승인된 정의를 사용했는지 답을 내기 전에 확인한다. SQL 문법이 맞아도 조직의 계산 규칙과 다를 수 있다.
자연어 데이터 질의의 신뢰도는 모델 성능과 함께 조직의 지표 정의에 달려 있다. ‘매출’ 같은 핵심 용어를 코드로 정의하고 변경 이력을 관리하면 대시보드와 에이전트가 같은 기준을 사용할 수 있다. 더 큰 모델을 기다리기 전에 자주 쓰는 지표부터 합의해 두는 편이 실제 운영의 오답을 줄이는 데 도움이 된다.