Text2SQL은 왜 자꾸 틀릴까?

2,460개의 LLM 기반 SQL 쿼리 오류 전격 분석

A Study of In-Context-Learning-Based Text-to-SQL Errors 리뷰 (arXiv:2501.09310, 2025)

최근 Text2SQL 관련 공부를 하다가 흥미로운 논문을 보게 되었는데요. 바로 “A Study of In-Context-Learning-Based Text-to-SQL Errors“라는 제목으로 2,460개의 LLM 기반 SQL 쿼리 오류를 직접 분석해 총 29개 유형, 7가지 대분류로 정리한 논문입니다.

Error Taxonomy

---

왜 중요한가?

Text2SQL은 “데이터베이스에 자연어로 질문하면 AI가 SQL 쿼리로 변환해 답을 주는 기술”입니다.

하지만 서비스 단계에서 가장 큰 문제는 정확성입니다.

쿼리가 조금만 잘못돼도 실행이 불가능하거나, 더 위험하게는 엉뚱한 데이터를 근거로 잘못된 결론을 내릴 수 있기 때문이죠.

제가 현재 진행 중인 ERP Analytics Agent 프로젝트에서도, 사용자 질문을 SQL로 바꿔 실행하는 과정에서 이러한 문제가 반복적으로 드러납니다.

---

주요 오류 유형과 통계

연구진이 밝힌 오류는 크게 7가지 대분류로 나뉩니다.

스키마 오류 (Schema errors): 존재하지 않는 테이블/컬럼 호출, 오타, 스키마 환각(hallucination)

문법 오류 (Syntax errors): SQL 구문 자체 오류, 함수 사용 오류

의미 오류 (Semantic errors): 질문 의도를 잘못 해석해 틀린 쿼리 생성

값 오류 (Value errors): WHERE/HAVING 조건 값 또는 집계 대상 잘못 지정

구조·골격 오류 (Skeleton errors): SELECT, JOIN, GROUP BY 등 쿼리 구조 자체 설계 오류

Schema Error

통계적으로 보면 전체 쿼리의 37.3%가 오류 포함했고,

그중 형식(format) 오류가 26.0%, 의미(semantic)오류가 30.9% 로 가장 흔하게 발생했습니다.

제가 현업에서 겪었던 문제도 거의 비슷했습니다. 실제로 오류 로그를 분석해보면, LLM이 존재하지 않는 컬럼을 생성하거나 JOIN을 무리하게 붙이는 경우가 굉장히 잦습니다.

---

기존 오류 수정 접근의 한계

연구에서는 기존의 5가지 자동 수리(Repair) 방식을 평가했는데, 결과는 실망스러웠습니다.

LLM-Value’s repairing result

수정률은 10.9~23.3%에 그쳤고, 오히려 5.3~40.1%는 오류가 더 늘어나는 오수리(mis-repair) 현상이 발생했고, 지연(latency)도 1.03~3.82배로 늘어났습니다.

즉, 단순히 “LLM에게 다시 물어본다” 수준의 자기교정(Self-correct)은 비용 대비 효과가 제한적이었습니다.

---

MapleRepair: 새로운 해결책

Maplerepair Architecture

논문에서 제안한 솔루션은 MapleRepair로 효율적인 오류 감지·수리 프레임워크입니다.

Maplerepair workflow

특징

5개의 모듈로 구성 특정 오류 그룹별로 최적화

증상 기반 감지(rule-based detection)

단순 문법/구조 오류는 LLM 호출 없이 즉시 처리

LLM은 보조적 수단 룰로 해결되지 않는 복잡한 경우에만 활용

Maplerepair errors result

효과

기존 대비 13.8% 더 많은 쿼리 수정 성공

오수리 현상은 거의 제거

추가 오버헤드 67.4% 감소

즉, 더 정확하고 더 가볍게 문제를 해결한 셈입니다.

---

실무 적용 관점

ERP Analytics Agent를 설계하면서 느낀 점은, 단순 LLM 의존보다 “오류 탐지 규칙 기반 보정 필요한 경우만 LLM 호출”하는 하이브리드 구조가 훨씬 효과적이라는 겁니다.

특히 스키마 오류는 스키마 정보와 데이터 리니지(Lineage)를 캐싱하고, 룰 기반 필터로 1차 검증하는 게 매우 효과적입니다.

이번 논문에서 제시한 MapleRepair 구조는, 실무에서 Text-to-SQL을 안정적으로 서비스에 녹여내려는 저 같은 팀들에게 좋은 레퍼런스가 될 수 있을것 같습니다.

---

정리하면 이렇습니다.

37%의 SQL 쿼리가 오류를 포함한다.

의미·스키마 오류가 전체의 절반 이상을 차지한다.

기존 오류 수리 접근은 한계가 뚜렷하다.

MapleRepair는 13.8% 더 높은 수정률, 낮은 오버헤드를 보인다.

---

이렇듯 Text-to-SQL은 “한 번에 정답을 낼 수 있느냐”보다, 틀린 쿼리를 얼마나 빠르게 감지하고 교정하느냐가 앞으로의 Text2SQL의 핵심 과제가 될 것입니다.

다음 글에는 AWS, GCP(Google Cloud Platform)등에서 Text2SQL을 어떻게 사용하고 있고, 다양한 Text2SQL 아키텍쳐에 대해 알아보겠습니다. 감사합니다.