If You Think You Can Do Real-World Text-to-SQL
Author: Michael Stonebraker, Peter Baile Chen (MIT) | Source: Communications of the ACM (BLOG@CACM) | Published: 2026-07-21
한 줄 요약
Spider/Bird에서 80~90%대를 찍는 text-to-SQL이 실제 기업 데이터 웨어하우스에서는 순수 LLM 정확도 0%, RAG·프롬프트 엔지니어링·에이전틱 AI를 다 더해도 10%대로, 그 차이가 “기술에 가능성이 있다”와 “기술이 작동하지 않는다”의 차이다.
핵심 주장/내용
- 공개 벤치마크의 4가지 문제:
- 데이터가 “the pile”에 있어 LLM이 학습할 수 있다. LLM은 이전에 본 데이터만 찾을 수 있다는 것이 널리 알려져 있는데, 우리가 아는 거의 모든 데이터 웨어하우스는 진지한 기업 접근 통제 뒤에 있고 공개되어 있지 않다
- 실제 웨어하우스는 “schema rot”을 겪는다. 웨어하우스는 필연적으로 잘 구조화된 스키마로 시작하지만, 비즈니스 조건 변화·사업부 매각/인수·규제 변경에 따라 갱신되고 스키마 변경이 종종 연 여러 차례 일어난다. 기업이 시간을 들여 잘 구조화된 대체 스키마를 만들면 좋겠지만 예외 없이 그렇지 않고 스키마가 시간이 지나며 썩는다
- 결과는 직관적이지 않은 테이블·컬럼 이름이다. 여러 테이블에 “salary”라는 컬럼이 6개 있을 수 있고, 문서화되지 않은 겹치는 의미를 가진다 — 하나는 “세금·수수료 차감 후 순액”, 다른 하나는 “총 급여”. 인기 쿼리를 빠르게 하려고 materialized view가 쓰이기도 한다. 이런 특성이 LLM에게 쿼리를 푸는 여러 방법과 두통을 준다
- 실제 웨어하우스는 종종 특이한(idiosyncratic) 데이터를 가진다. MIT 행정 데이터 웨어하우스에는 “J-term”(가을·봄 학기 사이 1월의 한 달 학기)과 건물 번호가 언급된다(MIT 건물은 이름이 아니라 번호로 불려서 Stata Center의 공식 명칭은 Building 32). 이런 맞춤 정보는 LLM에게 어렵다
- 실제 웨어하우스 쿼리는 Spider·Bird의 학생 생성 쿼리보다 복잡하다. 조인이 하나뿐인 경우는 드물고 보통 둘 셋이다. (Spider 2.0이 이 마지막 문제는 다뤘지만 앞의 셋은 다루지 않았다)
- Beaver 벤치마크: 2년간 실제 웨어하우스의 실제 워크로드로 LLM 기반 text-to-SQL을 시도. 1,400개 이상 테이블의 MIT Oracle 웨어하우스에서 시작 — 전형적으로 비즈니스 사용자가 IT 인력에게 질문하면 그 사람이 SQL로 번역하고, 종종 둘 사이에 명확화 대화가 오간다. Oracle 로그에서 실제 쿼리를 받고 실제 사용자의 도움으로 대응하는 자연어를 생성해 (자연어, gold SQL) 쌍의 컬렉션을 만들었다. 나중에 같은 방법론을 다른 세 웨어하우스에 적용하고, 허가를 받아 익명화·확장
- 결과가 냉정하다:
- 순수 LLM: 정확도 0점
- RAG + 프롬프트 엔지니어링 + 에이전틱 AI 추가: 10%대
- 더 높이려고 LLM에게 gold SQL의
FROM절 테이블과 여러 테이블일 때의 실제join절을 직접 줬더니 30%대 - 공개 벤치마크보다 50%p 이상 낮고, 이것이 “기술에 가능성이 있다”와 “기술이 작동하지 않는다”의 차이
- 결론: 전통적 LLM/에이전틱 AI 기술로 좋은 결과가 나올 가능성은 깨끗한 스키마, 단순한 쿼리, 특이 데이터가 적은 웨어하우스에서만 있다. 그 외에는 Rubicon 같은 다른 접근을 시도하라. 어떤 text-to-SQL 벤치마크든 실세계 데이터 저장소의 어려움을 다뤄야 하고, 그러지 않는 것은 학술적 관심사일 뿐 현실을 반영하지 않는다
관련 위키
- AI Self-Serve Analytics
- Semantic Layer
- Semantic Control Plane
- Schema Evolution
- Knowledge Spine
- LLM Evaluation
- Data Modeling
Source: 원문 보기