Text2SQL: LLM이 만드는 자연어-SQL 변환의 새로운 경계

TL;DR

Text2SQL은 자연어 질문을 SQL 쿼리로 변환하는 AI 기술입니다. 사용자가 한글로 "지난해 매출이 가장 높은 달은?"이라고 물으면, LLM이 해당 SQL을 생성해 데이터베이스에서 결과를 반환합니다. 기존 DIN-SQL, DAIL-SQL 같은 프롬프트 엔지니어링 기법과 RAG(검색 증강 생성)의 결합으로 정확도가 87.6%까지 올라갔고, 스키마 링크(Schema Linking), Self-Correction 같은 메커니즘이 오류를 크게 줄였습니다. 최근 당근페이, IBM, AWS 등이 실제 비즈니스에 적용 중이며, 데이터 민주화의 핵심 기술로 부상했습니다.

---

본문

1. Text2SQL이란 무엇인가?

Text2SQL은 자연어로 작성된 질문을 SQL 쿼리로 자동 변환하는 기술입니다. 전통적으로 데이터베이스에 접근하려면 SQL 문법을 알아야 했지만, Text2SQL은 이 진입 장벽을 제거합니다. 사용자가 "마케팅팀에 35살 이상 대리는 총 몇 명인가요?"라고 자연어로 질문하면, 시스템이 필요한 SQL을 생성해 즉시 결과를 반환하는 방식입니다.

기술적으로 Text2SQL은 Semantic Parsing 태스크로 분류되며, 일반적인 자연어 처리와 다릅니다. 자연어 질문(Natural Language Question, NLQ)과 데이터베이스 스키마(테이블, 컬럼, 데이터 타입)를 입력받아 SQL Executor가 실행 가능한 SQL 언어 형태로 번역하기 때문입니다.

왜 필요한가?

• 비전문가 접근성: SQL을 모르는 비개발자, 데이터 분석가, 마케터가 직접 데이터 조회 가능
• 속도 향상: 개발팀 의존도 감소, 데이터 기반 의사결정 시간 단축
• 민주화: 조직 전체의 데이터 활용 문화 정착

Why it matters: 기업이 데이터 기반 문화로 전환할 때, 모든 직원이 SQL을 배울 필요 없다면 데이터 접근성은 크게 향상됩니다. 당근페이 사례처럼 Text2SQL 도입 후 데이터 분석 요청이 급증했고, 의사결정 속도가 개선되었습니다.

---

2. Text2SQL의 작동 원리

2.1 기본 구조: 입력 → 처리 → 출력

Text2SQL 시스템은 다음과 같은 단계를 거칩니다:

1. 사용자가 자연어로 질문 입력 (예: "지난달 매출 상위 5개 고객은?")
2. 질의 분석 및 의도 파악 - LLM이 질문에서 핵심 의도 추출
3. 스키마 연결 (Schema Linking) - 데이터베이스의 어느 테이블·컬럼이 필요한지 매핑
4. SQL 쿼리 생성 - LLM이 정확한 SQL 작성
5. SQL 검증 및 Self-Correction - 문법·의미 오류 자동 감지 및 수정
6. 데이터베이스 실행 - 생성된 SQL을 DB에서 실행
7. 결과 반환 - 사용자에게 표·차트 형태로 제시

2.2 LLM의 역할: 지능의 핵심

현대 Text2SQL은 대규모 언어 모델(Large Language Model, LLM)을 기반으로 합니다. GPT-4, Claude, LLaMA 같은 모델들이:

• 자연어와 SQL 문법을 함께 학습해 정확한 변환 가능
• 코드 데이터가 풍부하게 포함된 모델일수록 SQL 생성 성능 우수
• 프롬프트 내 스키마 정보, 샘플 쿼리, few-shot 예제를 컨텍스트로 활용

벤더 비교 (2025년 기준):

구분	Claude 3.5/3.7 Sonnet	GPT-4o	Gemini 2.5 Pro
코딩/SQL 성능	매우 우수 (선임 엔지니어 수준)	우수 (프로토타이핑 강함)	우수
컨텍스트 윈도우	200,000 토큰	128,000 토큰	높음
추론 능력	매우 높음 (복잡 쿼리 강함)	높음	높음
API 비용 (입력)	$3/백만 토큰	더 높음	경쟁력 있음

Claude가 긴 컨텍스트 창으로 복잡한 다중 테이블 쿼리에 강점을 보이는 한편, GPT-4o는 빠른 속도와 이미지 처리에서 우위를 점합니다.

Why it matters: Text2SQL 정확도는 선택한 LLM에 크게 의존합니다. 간단한 쿼리는 GPT-3.5급도 충분하지만, 조인 5개 이상의 복잡한 다중 테이블 쿼리는 Claude 같은 고급 모델이 필수입니다.

---

3. 정확도를 높이는 핵심 기술들

3.1 RAG (Retrieval-Augmented Generation)

과거에는 데이터베이스의 전체 메타데이터를 프롬프트에 직접 삽입했습니다. 하지만 토큰 제한과 불필요한 정보로 인해 정확도가 떨어졌습니다.

RAG는 이 문제를 해결합니다:

• 메타데이터를 벡터 데이터베이스(Vector DB)에 저장
• 사용자 질문에 맞는 상위 N개 테이블·컬럼만 검색해 프롬프트에 삽입
• 불필요한 정보는 제외, 필요한 정보만 정밀 전달

HEARTCOUNT ABI의 예시: OpenAI의 최신 임베딩 모델 text-embedding-3-large(최대 3,072차원)를 768차원으로 설정해 성능과 효율성의 균형을 맞췄습니다. 코사인 유사도 알고리즘으로 문장의 길이가 아닌 의미 기반 유사성을 계산해 정확도를 높였습니다.

3.2 프롬프트 엔지니어링: DIN-SQL & DAIL-SQL

DIN-SQL (Decomposed In-Context Learning):

Text-to-SQL 태스크를 4단계로 분할:

1. Schema Linking - 질문과 관련된 테이블·컬럼 식별
2. Classification & Decomposition - 쿼리 난이도 분류 및 서브태스크로 분해
3. SQL Generation - 각 서브태스크별 SQL 생성
4. Self-Correction - 문법 오류, 의미 오류 자동 수정

Spider 벤치마크에서 SOTA(State-of-the-Art) 달성, 실행 정확도 91% 이상을 기록했습니다.

DAIL-SQL (Data-Aware In-Context Learning):

few-shot 예제 선택 방식을 개선:

• Query Similarity Selection - 생성된 SQL과 유사한 학습 데이터 쿼리 먼저 필터링
• Masked Question Similarity Selection - 선별된 데이터 중 질문 의미와 가장 유사한 K개 최종 선택
• Example Organization - Full-Information, SQL-Only, DAIL 조직 방식 비교

결과적으로 프롬프트에 제공하는 정보량을 줄이면서도 정확도를 크게 향상시켰습니다.

3.3 Self-Correction & 다단계 검증

생성된 SQL이 항상 정확한 것은 아닙니다. 최근 시스템들은 자동 검증 및 수정 메커니즘을 도입합니다.

당근페이 브로쿼리 아키텍처:

1. Intent Analysis - LLM이 자연어 질문 분석해 SQL 생성 필요 여부 판단
2. Context Enrichment - Amazon OpenSearch + Titan Embeddings로 하이브리드 검색 (Lexical + Semantic)
3. SQL Generation + Validation - LLM 생성 SQL을 내부 규칙 기반으로 검증
4. Self-Reflection - 문법 오류, 실행 오류 탐지 및 재생성

이 과정에서 LangGraph를 사용해 복잡한 분기형 워크플로우를 구현했습니다.

Why it matters: Text2SQL에서 발생하는 7가지 주요 오류:

오류 유형	설명	발생 빈도
스키마 오류	존재하지 않는 테이블/컬럼 호출, 오타	높음
문법 오류	SQL 구문 자체 오류	중간
의미 오류	질문 의도 잘못 해석	높음
값 오류	WHERE/HAVING 조건 값 잘못 지정	중간
구조·골격 오류	SELECT, JOIN, GROUP BY 설계 오류	높음
집계 오류	COUNT, SUM 등 함수 오류	낮음
정렬/제한 오류	ORDER BY, LIMIT 실수	낮음

Self-Correction 메커니즘이 이들 오류를 사전에 감지하고 수정합니다.

---

4. 벤치마크 & 성능 평가

4.1 Spider & BIRD 데이터셋

Text-to-SQL 성능 평가의 표준:

Spider:

• 200개 데이터베이스, 8,659개 훈련 샘플, 1,034개 개발 샘플, 2,147개 테스트 샘플
• 평가 지표: Execution Accuracy (EX) - 예측된 쿼리 실행 결과와 정답이 일치하는 비율
• PET-SQL (2024): 87.6% 실행 정확도, 기존 SOTA DAIL-SQL 대비 1% 향상
• DIN-SQL: 91% 이상 달성 (모델 크기별 차이)

BIRD:

• 실무 시나리오 시뮬레이션, 노이즈 포함 데이터셋
• 단순 쿼리보다 조인, 중첩 구문 등 복잡한 패턴 강조

4.2 벤치마크 한계

Reddit 커뮤니티 논의에서 지적된 점:

"기존 Spider 벤치마크도 실제 Text-to-SQL 성능을 반영하지 않는다는 주장이 제기됨. 특히 오버피팅 문제로 인해 실제 운영 환경에서는 성능이 크게 떨어질 수 있음."

Spider 2.0은 GUI 제어 추가로 이를 개선 중입니다.

Why it matters: 벤치마크 점수가 높아도 실제 비즈니스 데이터에는 도메인 특화성, 데이터 품질, 스키마 복잡도 차이로 인해 정확도가 떨어질 수 있습니다. 따라서 각 조직은 자체 골드 셋(Gold Standard Set)을 구축해 검증이 필수입니다.

---

5. 상용 도구 & 기업 적용 사례

5.1 상용 플랫폼

도구	특징	강점	약점
Text2SQL.ai	웹 기반 SQL 생성기	Regex/Excel 등 다목적, 저렴	복잡 JOIN 정확도 낮음
AI2sql	NoSQL 지원	복잡 쿼리 처리 우수	가격 높음
Vanna.ai	오픈소스 프레임워크	커스터마이징 가능	자체 유지보수 필요

Text2SQL.ai는 간단·중급 쿼리에 강하지만, 5개 이상 테이블 조인 시 정확도가 70% 대로 떨어집니다.

5.2 기업 사례

당근페이 "브로쿼리" (2025-06)

• 기술: Amazon Bedrock (Claude 기반) + OpenSearch VectorDB + Redshift
• 규모: 수백 개 테이블, 수천 개 컬럼 처리
• 혁신:
  • ENUM 값을 애플리케이션 소스 코드·Wiki에서 추출해 메타데이터 자동 증강
  • 비즈니스 용어사전 관리 (예: "MAU" = "최근 30일 이내 한 번 이상 앱 실행 고유 사용자")
  • Hybrid Search (Lexical + Semantic) 적용
  • LangGraph 기반 Agentic 워크플로우로 Context 유지 및 Self-Correction 구현
• 결과: 데이터 분석 요청 건수 급증, 의사결정 속도 단축

IBM Text2SQL (2025-08)

• 데이터 접근의 민주화 목표

AWS 데이터브릭스 Text2SQL 개선 (2024)

• Spider 벤치마크 기준 성능 평가 도구 제공

Why it matters: 기업 도입 사례 분석 결과, Text2SQL의 성공은 기술만이 아니라 데이터 거버넌스(스키마 문서화, 비즈니스 용어 정의, 품질 관리)에 크게 의존합니다. 따라서 단순히 LLM만 연결하는 것이 아니라, 조직 전체의 데이터 문화 정착이 선행되어야 합니다.

---

6. Python으로 구현하기: LangChain 예시

LangChain 라이브러리를 사용하면 기본적인 Text-to-SQL 시스템을 쉽게 구축할 수 있습니다.

6.1 기본 설치 및 세팅

# 필수 라이브러리
!pip install psycopg2-binary sqlalchemy
!pip install -U langchain langchain-community langchain-openai

from sqlalchemy import create_engine
from langchain.sql_database import SQLDatabase
from langchain_openai import ChatOpenAI
from langchain.chains import create_sql_query_chain

# PostgreSQL 연결
hostname = 'localhost'
username = 'your_user'
password = 'your_pass'
port = '5432'
database = 'your_db'

connect_url = f"postgresql://{username}:{password}@{hostname}:{port}/{database}"
engine = create_engine(connect_url)
db = SQLDatabase.from_uri(connect_url)

6.2 스키마 정보 확인

# 데이터베이스의 테이블 목록 출력
print(db.get_table_names())

# 특정 테이블의 스키마 정보 조회
print(db.get_table_info(table_names=['employees']))

# 출력 예:
# CREATE TABLE employees (
#     id SERIAL NOT NULL,
#     name TEXT NOT NULL,
#     age INTEGER NOT NULL,
#     department TEXT NOT NULL,
#     position TEXT NOT NULL,
#     CONSTRAINT employees_pkey PRIMARY KEY (id)
# )
#
# 3 rows from employees table:
# id | name | age | department | position
# 1  | 홍길동 | 25  | IT        | 사원
# 2  | 김철수 | 30  | 마케팅     | 대리
# 3  | 이영희 | 22  | 영업      | 사원

6.3 자연어로 SQL 생성

# LLM 초기화 (GPT-3.5-turbo 사용)
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)

# Text-to-SQL 체인 생성
chain = create_sql_query_chain(llm, db)

# 자연어 질문으로 SQL 생성
question = "employees 테이블에서 20대 사람들의 데이터를 모두 가져와줘"
generated_sql = chain.invoke({"question": question})

print(generated_sql)
# 출력:
# SELECT "id", "name", "age", "department", "position"
# FROM employees
# WHERE age >= 20 AND age < 30
# LIMIT 5;

6.4 생성된 SQL 실행 및 결과 조회

import pandas as pd
from sqlalchemy import text

# SQL 실행
df = pd.read_sql(text(generated_sql), engine)
print(df)

#    id  name  age department position
# 0   1  홍길동   25       IT     사원
# 1   3  이영희   22      영업     사원

6.5 실전 예제: 복잡한 쿼리

# 여러 자연어 질문 테스트
questions = [
    "직급별 인원 수를 구해줘",
    "평균 나이가 가장 높은 부서는 어디야?",
    "IT 부서에서 대리급 이상의 직원들만 보여줘"
]

for question in questions:
    generated_sql = chain.invoke({"question": question})
    df = pd.read_sql(text(generated_sql), engine)

    print(f"\n질문: {question}")
    print(f"SQL:\n{generated_sql}")
    print(f"결과:\n{df}\n")

주의사항:

• GPT-3.5-turbo는 간단한 쿼리에 강하지만, 5개 이상 테이블 조인 시 정확도 저하
• 복잡한 쿼리는 GPT-4 또는 Claude 추천
• 스키마 정보가 명확할수록 정확도 향상 (테이블 주석, 컬럼 설명 필수)
• 샘플 SQL 쿼리를 프롬프트에 포함시키면 few-shot learning으로 정확도 개선

---

7. Text2SQL의 도전 과제 & 극복 방안

7.1 남은 문제들

정확도 저하 시나리오:

1. 스키마 환각(Hallucination) - LLM이 존재하지 않는 테이블·컬럼 생성
2. 복잡한 조인 - 3개 이상 테이블 조인 시 정확도 급격히 하락
3. 다국어 지원 - 한글 질문에 대한 정확도는 영문보다 낮음
4. 도메인 특화성 - 의료, 금융 같은 특정 도메인 용어 오류
5. 데이터 타입 불일치 - 날짜, 시간대 처리 복잡성

Sky-high Accuracy 달성 방법:

• 스키마 검색 최적화: 테이블/컬럼/Few-shot 인덱스 별도 관리, Faiss 기반 Dense Search
• 비용 추정: SQL 실행 전 예상 비용·성능 예측 추가
• 자동 데이터 거버넌스: 스키마 변경, 메타데이터 정확도 자동 검증
• 데이터 증강: Text2SQL-Flow 같은 프레임워크로 시드 데이터로부터 의미적으로 유효한 다양한 학습 데이터 체계적 생성

7.2 부서별 맞춤 솔루션

현재 시장에서 요구하는 개선 방향:

• 금융부: FinStat2SQL 같은 도메인 특화 파이프라인 (재무제표 분석용 SQL 자동 생성)
• 의료부: HIPAA 준수 및 개인정보 보호 강화된 Text-to-SQL
• 마케팅: 세그먼테이션, 코호트 분석 같은 특정 분석 패턴 자동 인식

Why it matters: Text2SQL의 미래는 일반적 모델에서 벗어나 산업·조직별 맞춤형 솔루션으로 진화 중입니다. 따라서 각 조직은 자체 학습 데이터셋(Gold Standard) 구축을 통해 모델 파인튜닝(Supervised Fine-Tuning, SFT) 전략을 준비해야 합니다.

---

8. 2025년 & 그 이후: Text2SQL의 미래

8.1 기술 발전 방향

LLM 진화:

• Claude 3.7 Sonnet (2025): 200,000 토큰 컨텍스트, SQL 코딩 성능 대폭 개선
• GPT-4o, Gemini 2.5 Pro: 실시간 추론, 멀티모달 능력 강화
• DeepSeek: 비용 효율적 대안으로 부상

아키텍처 개선:

• 적응형 프롬프팅: 질문 난이도에 따라 프롬프트 자동 조정
• 멀티모달 AI: 차트, 이미지 포함 질의 지원
• 연합 학습(Federated Learning): 각 조직의 데이터를 공유하지 않으면서 모델 개선
• 자율 에이전트: 단순 쿼리 생성을 넘어 다단계 데이터 분석 자동화

8.2 기대 시나리오

기업 수준:

• 데이터 팀이 아닌 모든 직원이 데이터 분석 수행 가능
• SQL 작성 시간 80% 감소, 데이터 기반 의사결정 속도 3배 향상
• 데이터 리터러시 격차 축소로 조직 전체 역량 균등화

기술 수준:

• Text-to-SQL 정확도 95% 이상 달성
• 실시간 처리로 초단위 대시보드 업데이트
• 다언어 지원 완전화 (한글, 중국어, 일본어 등)

Why it matters: Text2SQL은 단순히 쿼리 생성 도구를 넘어, 데이터 접근 민주화를 실현하는 핵심 기술이 되고 있습니다. 각 조직이 준비하지 않으면 데이터 활용에서 경쟁력 격차가 더욱 벌어질 것으로 예상됩니다.

---

결론 (요약 정리)

Text2SQL이 주목받는 이유:

Text2SQL은 자연어로 SQL을 자동 생성하는 AI 기술로, 데이터 접근의 진정한 민주화를 가능하게 합니다. 2024-2025년 사이에 RAG, DIN-SQL, DAIL-SQL 같은 프롬프트 엔지니어링 기법과 Self-Correction 메커니즘이 결합되면서 정확도는 87.6%까지 올라갔습니다. 특히 당근페이, AWS, IBM 같은 주요 기업들이 실무 시스템으로 도입 중이며, 조직의 데이터 문화 정착의 필수 기술로 자리 잡고 있습니다. 다만 스키마 환각, 복잡 조인 오류, 도메인 특화성 부족 같은 과제는 여전하며, 각 조직의 맞춤형 학습 데이터셋 구축과 모델 파인튜닝이 성공의 열쇠입니다. 향후 멀티모달 AI, 자율 에이전트, 연합 학습 등 새로운 기술이 결합되면서 Text-to-SQL은 단순 쿼리 생성을 넘어 완전 자동화된 데이터 분석 플랫폼으로 진화할 것으로 예상됩니다.

---

References

• HEARTCOUNT Blog | Text-to-SQL이 뭔가요?
• HEARTCOUNT Blog | 더 정확해진 Text-to-SQL 2.0 근데 이제 RAG를 곁들인…
• HEARTCOUNT Blog | 텍스트를 SQL로 자동변환 해주는 기술, Text To SQL
• HEARTCOUNT Blog | 매일 새로운 기술이 쏟아지는 요즘, Text-to-SQL은 어떻게
• Swalloow Blog | AI를 통해 변화하는 데이터플랫폼 근황
• 데로스요초 | LLM 기반의 Text-to-SQL: A Survey
• 데로스요초 | Bird Benchmark의 Text-to-SQL 논문 정리
• Brunch | Text2SQL은 왜 자꾸 틀릴까?
• Brunch | NL2SQL (Text-to-SQL) Agents 설계
• 데이터브릭스 | 데이터브릭스에서 손쉽게 Text2SQL 성능 개선하기
• X2bee Tistory | Prompt 설정과 스키마 인식을 통한 향상된 SQL 쿼리 생성
• Skywork AI | Text2SQL.ai 완벽 분석: 2025년 최고의 Text to SQL 도구일까?
• IBM | IBM, 데이터 접근의 민주화와 가속화를 위한 AI 기반 Text2SQL 출시
• Reddit | Text 2 SQL 벤치마크
• Velog | Text To SQL 간단하게 구현하기
• Themoonlight | Text2SQL-Flow 논문 리뷰
• AWS Blog | 당근페이의 Amazon Bedrock 기반 Text-to-SQL (1부, 2부)
• YouTube | Decomposed In-Context Learning of Text-to-SQL
• MakeBot | 클로드 vs. ChatGPT
• Tilnote | 2025년 최신 AI 모델 성능 분석
• GLB GPT | 클로드 vs ChatGPT 코딩 대결