'데이터에게 자연어로 물어보세요’라는 기능은 데모에서 늘 근사하다. "지난달 매출 얼마야"라고 치면 에이전트가 SQL을 짜서 숫자를 돌려준다. 그런데 실사용에 넣으면 이상한 일이 벌어진다. 재무팀이 물으면 4억 2천만이 나오고, 마케팅팀이 같은 질문을 던지면 4억 8천만이 나온다. 다음 주에 재무팀이 다시 물으면 또 다른 숫자다. 셋 다 문법상 멀쩡한 SQL이다. 모델이 거짓말을 한 게 아니다. '매출’이 무엇인지 조직 안에 단 하나로 정의된 적이 없었을 뿐이다.
텍스트-투-SQL은 이미 충분히 똑똑하다
먼저 흔한 오해부터 걷어내자. 이 문제는 모델이 SQL을 못 짜서 생기는 게 아니다. 실제 지저분한 데이터베이스로 텍스트-투-SQL 성능을 재는 BIRD 벤치마크에서 2025년 최고 모델(Arctic-Text2SQL-R1-32B)은 실행 정확도 71.8%를 기록했다. 반대로 말하면 최고 모델도 약 28%는 여전히 틀린다. 하지만 여기서 멈추면 진단을 놓친다.
더 흥미로운 건 벤치마크 자체의 균열이다. 2025년에 제안된 FLEX 지표로 다시 채점하니, BIRD의 실행 정확도가 인간 전문가의 판단과 62%만 일치했다. 열에 넷은 어긋났고, 대부분은 사람이라면 맞다고 볼 답을 벤치마크가 틀렸다고 깎은 경우였다. 즉 "정답 SQL"이라는 것 자체가 생각만큼 명확하지 않다. 같은 질문에도 합리적인 쿼리가 여러 개일 수 있고, 그중 무엇이 ‘맞는’ 답인지는 비즈니스가 정하는 규약이지 모델이 추론할 대상이 아니다.
의미는 스키마 안에 없다
에이전트가 창고에 붙을 때 손에 쥐는 건 스키마다. 테이블 이름, 컬럼 타입, 외래키. 그런데 스키마는 "orders 테이블에 amount 컬럼이 있다"까지만 말해줄 뿐, "매출을 셀 때 환불은 빼는가, 세금은 포함하는가, 취소 주문은 어느 시점에 제외되는가"는 한 글자도 담고 있지 않다. 사람은 이 규약을 각자 머릿속에, 혹은 흩어진 BI 대시보드의 수식 속에 들고 있다. 팀마다 조금씩 다른 채로.
에이전트에게 스키마만 주고 매출을 물으면, 모델은 그 빈칸을 매번 새로 '추측’해 메운다. 어떤 날은 환불을 빼고, 어떤 날은 안 뺀다. 온도를 0으로 놔도, 프롬프트를 조금만 바꿔도 추측은 흔들린다. 답이 매번 다른 건 모델이 불안정해서가 아니라, 답을 고정할 의미의 앵커가 없어서다. 스키마는 무엇이 존재하는지를 말하고, 의미 계층은 그것이 무엇을 뜻하는지를 말한다. 후자가 비어 있으면 아무리 똑똑한 SQL 생성기도 매번 즉흥연주를 한다.
그래서 의미 계층이 온톨로지다
이 빈칸을 코드로 메우려는 게 시맨틱 레이어(semantic layer)다. “매출 = 완료 주문 금액 - 환불, 세금 제외, 주문 확정일 기준” 같은 정의를 대시보드마다 다시 짜지 않고, 버전 관리되는 한 벌의 규약으로 못 박는다. dbt의 MetricFlow는 2025년 말 아파치 2.0으로 오픈소스화되면서 이 흐름을 대놓고 "신뢰할 수 있는 AI와 에이전트를 위한 거버넌스 지표"로 내세웠다. 지표를 코드로 한 번 정의하면, 사람이 보는 대시보드든 에이전트가 던지는 질의든 같은 정의를 지난다.
이게 정확히 온톨로지가 하는 일이다. 테이블 위에 한 겹을 얹어, 엔티티가 무엇이고 지표가 무엇을 세는지를 검색과 생성보다 앞에서 고정한다. 에이전트는 이제 원시 SQL을 즉흥으로 짜는 대신, 이미 합의된 지표를 조회한다. 즉흥의 여지가 줄어든 만큼 답이 흔들리지 않는다. 업계가 이 방향을 진지하게 본다는 신호도 뚜렷하다. Snowflake와 Salesforce가 참여한 오픈 시맨틱 인터체인지(OSI)는 지표 정의를 벤더에 묶이지 않는 표준으로 만들려는 시도다. MotherDuck의 표현을 빌리면, 결국 "당신의 데이터 모델이 곧 시맨틱 레이어"다.
처방: 에이전트를 붙이기 전에 말부터 합의하라
소규모 팀이 여기서 가져갈 실용 노선은 세 가지다.
- 에이전트보다 정의를 먼저 배포하라. 창고에 챗봇을 붙이기 전에, 회사에서 가장 자주 묻는 지표 열 개(매출·활성사용자·이탈 같은 것)를 버전 관리되는 코드로 못 박아라. 이 합의 없이 붙인 '데이터에게 물어보기’는 편리한 오답 생성기다.
- 에이전트가 원시 테이블이 아니라 의미 계층을 조회하게 하라. 모델에게 스키마를 통째로 던지고 SQL을 자유 작문시키는 대신, 정의된 지표를 조회하는 좁은 API로 통로를 좁혀라. 자유도가 줄면 정확도가 오른다.
- 일관성을 검증 단계로 걸어라. 같은 질문에 같은 답이 나오는지, 정의된 지표를 벗어난 즉흥 쿼리가 아닌지를 답 이전에 한 번 확인하라. 텍스트-투-SQL은 문법의 정합성은 챙겨도 규약의 정합성까지 보장하지 않는다.
결국 '데이터에게 물어보기’가 무너지는 자리는 모델의 지능이 아니라 조직의 합의다. 에이전트가 더 똑똑해질 필요는 없다. 당신의 회사가 '매출’이라는 단어의 뜻에 — 단 한 번 — 합의하면 된다. 남들보다 앞서는 팀은 더 큰 모델을 기다리는 팀이 아니라, 자기 도메인의 의미를 코드로 먼저 고정해 둔 팀이다. 그 고정된 의미가, 누구나 같은 SQL 생성기를 쓰는 시대에 마지막까지 복제되지 않는 해자다.