Text-to-SQL 도입 전에 조사한 것들 [1]

왜 조사부터 시작했나#

AWS Summit에서 당근페이의 Broquery 발표를 들었을 때만 해도 솔직히 남의 일 같았다. 그때는 제 담당 영역이 아니었고, 그냥 재밌는 사례 하나 본 정도였다. 그런데 나중에 기존 프로덕트의 AX(AI Transformation) 업무를 맡게 되면서, 이걸 직접 만들어야 하는 상황이 왔다.

처음엔 GPT-4에 프롬프트 하나 넣으면 대충 돌아가지 않을까 싶었다. 실제로 데모 수준에서는 된다. 문제는 그걸 실서비스에 올리려는 순간부터였다. 정확도, 보안, 멀티테넌트, 피드백 루프, 비용 관리가 한꺼번에 따라붙고, 설계를 잘못 잡으면 나중에 거의 갈아엎어야 한다.

붙여야 할 프로덕트도 만만하지 않았다. 레거시 시스템이었고 데이터 구조가 복잡했다. 테이블 이름은 약어투성이였고, 비즈니스 로직은 코드에만 있고 스키마에는 없는 상태였다. 질문하면 바로 완벽한 SQL이 나오는 구조를 처음부터 기대하는 건 현실적이지 않았다.

그래서 방향을 바꿨다. 한 번에 완벽한 시스템이 아니라, 사용자 피드백으로 계속 튜닝되는 시스템으로. 그러려면 먼저 다른 회사들이 이걸 실제로 어떻게 풀고 있는지부터 봐야겠다고 생각했다.

Claude로 리서치 세션 하나에서 관련 사례를 찾고, 별도 세션에서 그 결과를 압축/비교하는 방식으로 진행했습니다. 테크블로그, 컨퍼런스 발표, 논문, 오픈소스 문서에서 14개 기업의 사례를 수집했습니다.

당시에는 속도와 정확도 쪽으로 챌린지를 많이 받던 시점이라, 이 리서치는 단순한 기술 조사가 아니라 "이게 진짜 실서비스에 올릴 만한 수준인가?"라는 질문에 근거를 찾는 과정이기도 했다.

조사 대상#

한국 기업 3곳, 글로벌 빅테크 4곳, 클라우드 벤더 2곳, 스타트업/오픈소스 5곳. 총 14개입니다.

기술 채택 매트릭스#

14개 중 13개가 RAG를 씁니다. Fine-tuning만으로 운영하는 곳은 2022년 카카오 RYANSQL뿐이고, 이후 사례에서는 전부 RAG가 기본입니다.

한국 사례#

우아한형제들 — MulEoBoSae#

2023년 내부 해커톤(우아톤)에서 시작했습니다. 2024년 1월에 BADA(Baemin Advanced Data Analytics) TF가 정식으로 꾸려졌고, 전 직원 대상 AI 데이터 분석 서비스로 성장했습니다.

아키텍처: Slack 봇 + LangChain + RAG. LLM은 GPT-4o를 씁니다.

접근 방식: RAG만 사용하고 Fine-tuning은 안 합니다. 핵심 인사이트가 인상적이었습니다: "Text-to-SQL 성능의 핵심은 어떤 문서를 수집하느냐에 달려있다." 모델을 바꾸는 것보다 RAG에 넣어주는 메타데이터의 품질이 더 중요하다는 뜻입니다.

처음에는 단순 RAG로 시작해서, Part 3에서는 Agent + RAG-MCP 구조까지 진화했습니다. MVP를 2개월 만에 완성했다는 것도 인상적이었고, 현재는 Delivery Hero 글로벌 생태계로 확장을 준비 중이고 AaaS(Agent as a Service) 플랫폼화를 계획하고 있습니다.

당근페이 — Broquery#

앞서 얘기했듯이 AWS Summit 현장에서 직접 발표를 들었습니다. 당시에는 제 담당이 아니었지만, 나중에 직접 만들게 되면서 그때 들었던 내용이 설계에 큰 영향을 줬습니다. 핀테크 도메인의 내부 Text-to-SQL 챗봇입니다.

아키텍처:

• 오케스트레이션: LangGraph
• LLM: Amazon Bedrock (Claude 계열)
• RAG: Amazon OpenSearch (벡터 + 키워드 하이브리드 검색)
• 대화 관리: DynamoDB
• 데이터 소스: Redshift
• 통합: MCP 서버

특히 인상적이었던 건 메타데이터를 3가지로 분류한 점입니다:

1. 비즈니스 메타데이터: 용어 정의, 지표 산출 기준, 정책 맥락
2. 기술 메타데이터: 테이블/컬럼 스키마
3. 운영 메타데이터: 데이터 자산 소유자

스키마만 RAG에 넣으면 안 됩니다. "활성 사용자"가 뭔지, "매출"이 총매출인지 순이익인지 — 이런 비즈니스 맥락이 빠지면 LLM이 아무리 똑똑해도 맞는 SQL을 만들 수 없습니다.

Fine-tuning도 실험적으로 진행 중이었는데, 자주 쓰이는 SQL 구조와 내부 용어에 대해 SFT를 적용하고 있었습니다. 향후 계획으로 Hybrid Search 최적화, Llama/Qwen 기반 후보 SQL 선택용 SFT, 평가 프레임워크 구축을 언급했습니다.

카카오 — RYANSQL#

2022년 if(kakao) 컨퍼런스에서 발표된 한국어 특화 Text-to-SQL 모델입니다. BERT + RAT(Relation-Aware Transformer) 기반이고, Fine-tuning만 사용합니다.

Spider 영문 데이터셋을 한국어로 번역해서 학습시켰고, 영문 74.18%, 한국어 v2 68.06% EM을 달성했습니다.

다만 이건 2022년 사례라 지금 기준으로 보면 접근 방식이 다릅니다. RAG가 등장하기 전이라 Fine-tuning 외에 선택지가 제한적이었습니다. 이후 나온 사례들에서는 전부 RAG가 기본이 되었습니다.

글로벌 빅테크#

Uber — QueryGPT (가장 큰 스케일)#

2023년 5월 사내 해커톤에서 시작해서 현재 프로덕션 운영 중입니다. 스케일이 압도적입니다.

수치:

• 월 120만 건 쿼리 처리
• 쿼리 작성 시간 70% 단축 (10분 → 3분)
• 월 14만 시간 절약
• 연간 약 $120M 생산성 향상

아키텍처 (Multi-Agent):

사용자 질문
    ↓
[Intent Agent] → 의도 분석, 비즈니스 도메인(Workspace) 매핑
    ↓
[Table Agent] → 벡터 유사도 검색으로 관련 테이블 찾기
    ↓
[Column Prune Agent] → 불필요한 컬럼 제거, 토큰 최적화
    ↓
[LLM + RAG] → Workspace 예시 + 스키마로 SQL 생성
    ↓
SQL 결과

핵심 패턴: Workspace. Uber는 수천 개의 테이블을 Mobility, Ads, Core Services 같은 비즈니스 도메인별로 클러스터링합니다. 사용자가 질문하면 먼저 어떤 Workspace에 해당하는지 분류하고, 그 안에서만 테이블을 검색합니다. 검색 범위를 좁히는 것만으로 정확도가 크게 올라갑니다.

RAG만 사용하고 Fine-tuning은 안 합니다.

가장 인상적인 건 자체 평가 결과 **정확도가 50%**라는 점입니다. 그런데도 운영하고 있고 $120M의 가치를 내고 있습니다. 완벽한 SQL을 만드는 게 목표가 아니라, 빠른 초안을 제공해서 분석가의 시간을 절약하는 워크플로우입니다. 이 관점의 전환이 리서치에서 가장 큰 수확이었습니다.

LinkedIn — SQL Bot (DARWIN 플랫폼)#

2024년 12월 공개되었고, LangChain이 선정한 "Top 5 LangGraph Agents 2024"에 포함됐습니다.

아키텍처 (Multi-Agent + Knowledge Graph):

사용자 질문
    ↓
[Knowledge Graph Context]
  - DataHub, 쿼리 로그, 크라우드소싱 도메인 지식
  - 테이블 스키마, 필드 설명, 카테고리 값, 예시 쿼리
    ↓
[Sorting & Filtering Agent] → 수백만 개 → 20개 테이블
    ↓
[Ranking Agent] → 20개 → 7개 테이블
    ↓
[Field Ranking Agent] → 관련 필드 선택
    ↓
[Plan & Solve] → 단계별 SQL 생성
    ↓
[Validators] → 테이블/필드 존재 확인, EXPLAIN 검증
    ↓
[Self-Correction Agent] → 오류 자동 수정
    ↓
SQL 결과

수치:

• 사용자 만족도 95%
• DARWIN 플랫폼 통합 후 채택률 5-10배 증가

LinkedIn 사례에서 배운 가장 중요한 교훈: 단독 챗봇을 만들지 말고 기존 도구에 통합하라. 독립적인 Text-to-SQL 챗봇을 만들었을 때와, 기존 데이터 분석 플랫폼 DARWIN에 통합했을 때 채택률이 5-10배 차이 났습니다. 사용자들은 새로운 도구를 배우기 싫어합니다.

Multi-stage Ranking 구조도 참고가 많이 됐습니다. 수백만 개 테이블에서 시작해서 20개 → 7개로 단계적으로 줄여나가는 패턴은 그대로 가져왔습니다.

Pinterest — Querybook#

오픈소스 SQL 도구 Querybook에 Text-to-SQL을 통합한 사례입니다.

V1(단순 LLM)에서 V2(RAG 강화)로 진화했는데, V2에서는 오프라인 잡으로 테이블 요약과 과거 쿼리를 미리 벡터 인덱싱하고, 질문이 들어오면 벡터 유사도 검색 → LLM 최종 선택 → SQL 생성 순서로 처리합니다. 응답은 WebSocket 스트리밍으로 보냅니다.

Pinterest 팀이 남긴 말이 현실적이었습니다: "Spider 벤치마크는 실제 Pinterest 쿼리보다 훨씬 단순하다." 벤치마크 점수만 보고 시스템을 만들면 프로덕션에서 기대 이하의 결과를 얻을 수 있다는 경고입니다.

Salesforce — Horizon Agent + Waii 인수#

Salesforce는 독특한 접근을 합니다. Consensus Voting 방식으로, SQL을 1개가 아니라 10개 후보를 생성한 다음 코사인 유사도 + 레벤슈타인 거리로 투표해서 가장 많은 표를 받은 SQL을 선택합니다.

LLM의 비결정성(같은 질문에 매번 다른 SQL)을 해결하는 방법인데, 대신 비용과 레이턴시가 10배입니다. 비용이 문제가 안 되는 환경에서는 고려해볼 만한 전략입니다.

2025년 8월에 Waii를 인수했는데, Waii는 Dynamic Metadata Knowledge Graph를 가지고 있어서 테이블 관계, 지표, 거버넌스 규칙을 자동으로 업데이트합니다. 이걸 Tableau Next + Agentforce에 통합할 계획입니다.

클라우드 벤더#

Databricks — AI/BI Genie#

Unity Catalog의 메타데이터(테이블명, 설명, PK/FK)를 활용합니다. 추가 라이선스 없이 사용 가능하고, 2025년에는 SQL 결과 자동 요약, Knowledge Store(지표/필터 정의) 기능이 추가됐습니다.

Snowflake — Cortex Analyst#

사용자 정의 Semantic Model(YAML)을 기반으로 동작합니다. Logical Tables, Columns(dimensions/measures), Relationships를 YAML로 정의하면 이걸 기반으로 SQL을 생성합니다.

내부 벤치마크에서 90% 이상 정확도를 달성했다고 하는데, 모든 처리가 Snowflake 경계 내에서 이뤄져서 보안 측면에서도 강점이 있습니다.

Snowflake의 핵심 메시지: "스키마만으로는 부족하다. Semantic Model이 필요하다." 당근페이의 비즈니스 메타데이터와 같은 맥락입니다.

스타트업 / 오픈소스#

간략히 정리합니다.

벤치마크 vs 현실#

Spider 1.0에서 85%가 나와도, Spider 2.0에서는 31%로 떨어집니다. 실무 쿼리는 테이블 수십 개에 JOIN, 서브쿼리, 윈도우 함수가 난무하니까요.

프로덕션에서 자주 발생하는 오류 유형:

1. 잘못된 JOIN — 테이블 간 관계를 잘못 파악
2. 집계 오류 — GROUP BY, 집계 함수 실수
3. 필터 누락 — WHERE 조건이 빠짐
4. Hallucination — 존재하지 않는 테이블/컬럼을 참조

벤치마크 점수에 매달리기보다, 이런 실패 유형에 대한 방어 체계(Self-Correction, Schema Validation)를 구축하는 게 더 중요합니다. 그리고 사용자가 실패했을 때 피드백을 줄 수 있는 루프를 만드는 것이 장기적으로 정확도를 올리는 방법입니다.

성공 패턴 정리 (중요도 순)#

14개 사례를 계속 보다 보니 반복적으로 보이는 패턴이 있었다. 아래 순서는 리서치 결과를 종합하면서, 내가 설계에 반영해야겠다고 느낀 우선순위대로 정리한 것이다.

1. 도메인 스코핑

검색 범위를 좁히는 것이 정확도에 가장 큰 영향을 줍니다. Uber의 Workspace, LinkedIn의 Multi-stage Ranking이 대표적입니다. 전체 DB에서 테이블을 찾는 것과 특정 도메인 안에서 찾는 것은 난이도가 완전히 다릅니다.

2. 양질의 메타데이터 + RAG

13/14 시스템이 RAG를 쓰는 이유가 있습니다. LLM은 추론은 잘 하지만 우리 회사 테이블은 모릅니다. 스키마 + 비즈니스 용어 + 예시 SQL을 RAG로 제공해야 합니다.

3. Multi-Agent 아키텍처

의도 분류, 테이블 선택, 컬럼 정리, SQL 생성, 검증을 단일 LLM 호출에 다 시키면 컨텍스트가 너무 길어지고 정확도가 떨어집니다. 역할을 나누면 각 단계를 독립적으로 테스트하고 개선할 수 있습니다.

4. Self-Correction 루프

생성된 SQL을 바로 실행하면 안 됩니다. 문법 검증 → 스키마 대조 → EXPLAIN 실행으로 검증하고, 실패하면 자동 수정합니다.

5. 기존 도구에 통합

LinkedIn의 교훈입니다. 독립 챗봇으로 만들었을 때와 기존 플랫폼에 통합했을 때 채택률이 5-10배 차이 났습니다. Slack 봇으로 만드는 것도 이 맥락입니다 — 사용자가 이미 쓰는 도구에 붙여야 합니다.

6. Semantic Layer / Knowledge Graph

복잡한 기업 스키마에서는 테이블 관계, 비즈니스 지표 정의, 거버넌스 규칙을 구조화해서 제공해야 합니다. Snowflake, Waii, LinkedIn이 이 방향입니다.

7. 스트리밍 응답

SQL 생성에 30초 이상 걸리는 경우가 많습니다. 사용자가 빈 화면을 30초 동안 보고 있으면 안 되니까, 생성 과정을 SSE로 스트리밍해서 보여줘야 합니다.

8. 샘플 쿼리 자산

도메인 전문가가 큐레이션한 "질문-SQL" 쌍이 가장 강력한 RAG 소스입니다. 스키마와 설명만으로는 LLM이 복잡한 비즈니스 로직을 파악하기 어렵지만, 비슷한 질문에 대한 정답 SQL이 있으면 패턴을 그대로 참고할 수 있습니다.

Fine-tuning은 언제 쓰나#

14개 중 Fine-tuning을 쓰는 곳은 3곳(당근페이, 카카오, DB-GPT)입니다. 나머지는 전부 RAG만으로 운영합니다.

Fine-tuning이 필요한 상황:

• 비용/레이턴시 최적화: GPT-4 대신 작은 모델(Qwen, Llama)로 바꾸고 싶을 때
• 도메인 특화 SQL 패턴: RAG만으로 잡히지 않는 반복 패턴이 있을 때
• 후보 SQL 선택: 여러 후보 중 가장 적합한 SQL을 고르는 용도 (당근페이 접근)

다만 Fine-tuning만으로 운영하는 곳은 2022년 카카오뿐입니다. RAG가 지식을 제공하고, Fine-tuning이 생성을 최적화하는 보조 역할입니다.

이 리서치가 설계에 미친 영향#

결국 이 리서치는 읽고 끝난 자료 조사가 아니라, 바로 다음 PoC 설계의 뼈대가 됐다. 실제로 반영한 것들은 이렇다:

• Multi-Agent 구조 채택 — Uber, LinkedIn이 검증한 패턴
• RAG 중심 (Fine-tuning 없이) — 13/14 시스템이 RAG 기반
• Workspace 패턴 — Uber에서 가져옴
• Self-Correction 루프 — LinkedIn 패턴
• 기존 도구 통합 — Slack 봇으로 시작
• 멀티테넌트 Day 1 설계 — SaaS 제공을 고려

리서치 없이 시작했으면 아마 단일 LLM 호출 + 프롬프트 엔지니어링 쪽으로 갔을 가능성이 높다. 그런데 14개 기업이 이미 그 단계를 거쳐서 Multi-Agent + RAG로 넘어간 걸 보고 나니, 굳이 같은 삽질을 처음부터 반복할 이유가 없었다.

다음 글에서#

이 리서치를 바탕으로 7+1개 에이전트 구조의 시스템을 실제로 어떻게 구축했는지를 2편에서 다루겠습니다.