저는 MCP 서버를 통해 LLM (Large Language Models)을 데이터베이스에 연결하고 질문을 던지는 실험을 해왔습니다. 결과는 일정한 패턴을 보였습니다. 처음에는 모델이 존재하지 않는 테이블과 컬럼을 단순히 지어내고, 그에 맞춰 그럴듯해 보이는 SQL을 작성했습니다.

스키마 (Schema)를 조사할 수 있는 도구를 제공하자 첫 번째 실패는 해결되었습니다. 모델은 테이블 목록을 나열하고 컬럼을 설명할 수 있게 되었으며, 이제 직접 조회할 수 있으므로 구조를 지어내는 일을 멈췄습니다. 하지만 더 미묘한 실패가 남아 있었습니다. 컬럼의 의미가 명확하지 않을 때, 모델은 질문하거나 이를 표시하지 않았습니다. 대신 임의의 해석을 선택하고 그대로 진행해 버렸습니다.

이 두 번째 실패야말로 글을 쓸 가치가 있는 부분입니다. 현재 모델들은 상당히 수준이 높으며, 더 나은 모델이 부족해서 발생하는 문제라고 생각하지 않습니다. 부족한 것은 우리 측의 요소, 즉 데이터가 실제로 무엇을 의미하는지 모델에게 알려주는 컨텍스트 (Context)입니다.

벤치마크의 절벽

수년간 Text-to-SQL의 발전은 깨끗한 스키마, 데이터베이스당 소수의 테이블, 읽기 쉬운 컬럼 이름을 가진 학술적 벤치마크인 Spider를 통해 측정되었습니다. 최고 수준의 시스템은 91%의 실행 정확도를 기록했으며, 리더보드는 2024년 초에 동결되어 사실상 해결된 상태였습니다.

그 후 동일한 연구실에서 실제 기업용 웨어하우스(Warehouse)를 기반으로 구축된 Spider 2.0을 출시했습니다. 이는 컬럼이 1,000개를 초과하는 경우가 빈번한 BigQuery 및 Snowflake 데이터베이스를 대상으로 하며, 답변이 100줄 이상의 SQL로 작성될 수 있는 환경입니다. GPT-4o는 학술용 Spider에서는 86.6%를 기록했지만, 동일한 모델을 실제 스키마에 적용한 Spider 2.0에서는 10.1%를 기록했습니다.

또 다른 주요 벤치마크인 BIRD는 ChatGPT의 실패 사례 500개를 샘플링하여 분류했습니다. 41.6%는 잘못된 테이블이나 컬럼과 연관되었고, 또 다른 40.8%는 데이터베이스 내용을 오해하거나 존재하지 않는 스키마 항목을 생성했습니다. 실패의 80% 이상이 스키마 그라운딩 (Schema Grounding) 문제입니다. SQL 구문 (Syntax) 오류는 거의 범주에 들지 않을 정도입니다. 실패는 SQL에 있는 것이 아닙니다. 데이터베이스가 무엇을 의미하는지에 대한 모델의 이해(Picture)에 있습니다.

당신이 실제로 연결하게 될 웨어하우스

같은 회사에 있는 두 팀에게 지난 분기 매출을 물어보면, 각자의 정의에 따라 둘 다 정답인 서로 다른 두 개의 숫자를 받을 수 있습니다. 한 팀은 반품을 제외하고, 다른 팀은 포함합니다. 한 팀은 예약액(bookings)을 집계하고, 다른 팀은 인식된 매출(recognized revenue)을 집계합니다. 지표 이름(metric name)은 공유되지만, 그 뒤에 숨겨진 로직(logic)은 공유되지 않습니다. 그 로직은 대개 데이터 웨어하우스(warehouse)에 전혀 존재하지 않으며, 2023년의 Slack 스레드나 대시보드를 만든 분석가 팀장의 머릿속에만 들어 있습니다.

물리 계층(physical layer)도 마찬가지입니다. 몇 년간의 팀 변경을 거친 웨어하우스는 다음과 같은 모습일 것입니다:

SHOW TABLES LIKE 'customers%';
-- customers
-- customers_v2
...

customers_v2를 위한 마이그레이션(migration)은 우선순위가 바뀌기 전까지 거의 완료된 상태였습니다. 컬럼(column)들도 상황은 비슷합니다: amt와 amt_2가 나란히 놓여 있지만, 어느 쪽에도 주석(comment)이 없습니다. 스키마(schema) 접근 권한이 있는 모델은 이 모든 것을 볼 수 있습니다. 하지만 모델은 어떤 테이블이 정식(canonical) 테이블인지 알 수 없습니다. 쿼리(query)가 도달할 수 있는 곳 어디에도 아무도 그것을 기록해 두지 않았기 때문입니다.

Databricks Genie를 사용한 경험을 설명한 한 Hacker News 댓글 작성자는 이 함정을 다음과 같이 요약했습니다: "저는 여러 팀이 설계한 수백 개의 테이블을 가지고 있습니다. 테이블에 대한 괜찮은 문서(documentation)는 있지만, 만약 저에게 잘 정리된 데이터 모델(data model)이 있었다면 AI 어시스턴트 따위는 필요 없었을 것입니다." Text-to-SQL은 역설적으로 그것이 가장 필요하지 않은 웨어하우스에서 가장 잘 작동합니다.

동일한 모델, 다른 컨텍스트

제가 가장 신뢰하는 증거는 모델은 고정된 상태에서 컨텍스트(context)만 변하는 사례에서 나옵니다.

Pinterest는 내부적으로 Text-to-SQL을 구축했고, 병목 현상(bottleneck)이 SQL 생성 자체가 아니라 수십만 개 중에서 올바른 테이블을 찾는 것이라는 사실을 발견했습니다. 검색 인덱스(search index)에 테이블 문서(table documentation)를 추가하자, 모델을 변경하지 않고도 올바른 테이블을 찾는 적중률(hit rate)이 약 40%에서 90%로 상승했습니다.

BIRD는 각 질문에 데이터에 관한 사람이 작성한 선택적 문맥(context) 한 문장을 함께 제공합니다. 그 한 문장이 GPT-4의 성능을 약 20포인트 끌어올립니다. 제가 가장 설득력 있다고 느끼는 부분은, 그것이 인간의 정확도 또한 동일하게 20포인트(72%에서 93%로) 높여준다는 점입니다. 문맥의 부재가 모델만큼이나 전문가에게도 해를 끼친다면, 문제는 지능이 아닙니다. 단지 정보가 그곳에 없을 뿐입니다.

벤더(vendor)들의 수치조차 이를 말해줍니다. Snowflake의 엔지니어링 블로그에 따르면, 실제 환경 평가에서 가공되지 않은(raw) GPT-4o의 정확도는 51%였으나, 데이터에 대해 설명하는 시맨틱 모델(semantic model)을 사람이 직접 구축하자 90% 이상으로 상승했습니다. 그들은 Cortex Analyst를 판매하고 있으므로 이는 벤더의 벤치마크(benchmark)입니다. 하지만 그들이 인정한 사실은 핵심을 찌릅니다. 모델 단독으로는 동전 던지기 수준의 확률이지만, 그 차이 전체는 누군가가 작성한 메타데이터(metadata)에서 나온다는 것입니다.

하지만 에이전트(Agents)들은 발전했습니다

반론에는 실제 수치가 뒷받침되어 있습니다. Spider 2.0 점수는 2024년 말 약 10%에서 2026년 중반 Snowflake 트랙 기준 90% 이상이라고 주장되고 있으며, dbt의 벤치마크에 따르면 모델의 발전만으로도 2023년에서 2026년 사이 가공되지 않은 Text-to-SQL 정확도가 32.7%에서 64.5%로 거의 두 배 가까이 측정되었습니다. 만약 데이터 웨어하우스(warehouse)가 문제의 전부였다면, 이런 일은 일어나지 않았을 것입니다.

하지만 이러한 이득은 특정한 방식으로 발생했습니다. Spider 2.0 상위권에 있는 시스템들은 가공되지 않은 스키마(schema)에 대해 단일 프롬프트(single prompt)를 던지는 방식이 아닙니다. 이들은 데이터베이스를 프로파일링(profile)하고, 메타데이터와 방언(dialect) 문서를 읽으며, 값을 샘플링하고, 실행 오류에 대해 반복(iterate)하는 에이전트(agents)들입니다. 이들은 쿼리 시점에 메타데이터 작업을 수행함으로써 리더보드(leaderboard)를 올라갔습니다. 이는 본 논지에 반하는 증거가 아니라, 모델이 모든 쿼리에 대해 비용을 많이 들여 동일한 해결책을 적용하고 있는 것뿐입니다.

그리고 탐색(probing)을 통해 회복할 수 있는 것에는 한계가 있습니다. 에이전트는 customers_v2가 존재한다는 사실, 컬럼(column)들이 어떤 유형의 데이터를 담고 있는지, amt_2가 어떤 값들을 가지는지 등을 발견할 수 있습니다. 하지만 재무 부서가 세 가지 수익 정의 중 무엇을 정답으로 간주하는지는 발견할 수 없습니다. 왜냐하면 그 사실은 데이터베이스에 들어있지 않기 때문입니다. 에이전트가 도달할 수 있는 그 어디에도 존재하지 않습니다.

그것이 제가 경험한 MCP(Model Context Protocol)의 축소판이었습니다. 조사 도구(investigation tools)들은 환각(hallucinations)을 멈추게 했습니다. 하지만 도구가 도달할 수 있는 그 어떤 것도 모델에게 데이터의 의미가 무엇인지는 알려주지 못했습니다.

실제로 효과가 있는 방법

벤더사들의 자체 문서를 읽어보면 이미 답이 나와 있습니다. Databricks Genie의 best-practices page는 5개 이하의 테이블과 데이터를 이해하는 큐레이터(curator)와 함께 시작할 것을 권장합니다. Snowflake의 Cortex Analyst는 사용자가 시맨틱 모델(semantic model)을 작성하도록 요구하는데, 이는 스키마(schema) 자체에는 쿼리가 의존하는 비즈니스 정의(business definitions)가 결여되어 있기 때문입니다. Amazon Q는 큐레이션된 토픽(topics)과 사람이 검토하고 확인한 답변(human-reviewed verified answers)을 원합니다. 이들 각각은 AI 제품으로 판매되지만, 모두 동일한 숙제를 동반합니다. 바로 데이터를 먼저 문서화하라는 것입니다.

dbt 벤치마크는 이 숙제의 가치를 수치로 증명했습니다. 가벼운 데이터 모델링(data modeling)을 적용한 세 개의 dbt 모델을 추가했을 때, 순수 Text-to-SQL 성능은 60% 중반에서 84-90%로 상승했습니다. 그들의 시맨틱 레이어(semantic layer)를 통과했을 때는 범위 내 질문(in-scope questions)에 대해 98-100%에 도달했으며, 실패의 양상 또한 그럴듯한 오답에서 에러 메시지로 바뀌었습니다. 마지막 이 부분이 정확도보다 더 중요합니다. 답변 거부는 짜증스럽긴 하지만 눈에 보입니다. 하지만 그럴듯하게 틀린 숫자는 누군가 확인하기 전까지 이사회 보고서(board deck)에 그대로 올라갈 수 있습니다.

이러한 주장을 공개적으로 하는 사람들에게는 일정한 패턴이 있습니다. Collate는 메타데이터 플랫폼을 판매합니다. Omni와 dbt는 시맨틱 레이어 (semantic layers)를 판매합니다. a16z는 홍보할 포트폴리오 기업들을 보유하고 있습니다. 그렇다고 그들이 틀렸다는 뜻은 아닙니다. 저도 포스트 내내 그들의 수치를 인용해 왔습니다. 하지만 이는 왜 "데이터 웨어하우스를 문서화하라"는 조언이 계속해서 제품의 형태로 포장되어 등장하는지를 설명해 줍니다. 포장을 벗겨내면 남는 것은 데이터 팀이 지난 10년 동안 무시해 온 조언입니다: 데이터를 모델링하고, 정의를 기록하며, 무엇이 정전 (canonical)인지 표시하십시오. 시맨틱 레이어는 더 나은 이름을 붙인 문서화 부채 (documentation debt) 상환에 불과합니다.

Text-to-SQL은 이미 존재하던 문제를 드러냈습니다. 문서화되지 않은 데이터 웨어하우스가 작동할 수 있었던 이유는 분석가들이 누락된 컨텍스트 (context)를 머릿속에 담아두고 모든 쿼리에서 조용히 이를 보완했기 때문입니다. 하지만 모델을 동일한 데이터 웨어하우스에 투입하면, 더 이상 이를 보완해 줄 사람이 남아 있지 않습니다. 만약 이것이 제대로 작동하기를 원한다면, 해야 할 일은 언제나와 같습니다: 데이터를 모델링하고, 사물의 의미를 기록하며, 무엇이 정전 (canonical)인지 표시하는 것입니다. 그 작업은 인간이 그 비용을 흡수하고 있었을 때는 단지 미루기 쉬웠을 뿐입니다.