Text-to-SQL과 데이터 분석 에이전트: 자연어로 데이터베이스에 묻기

왜 필요했나: SQL을 아는 사람만 데이터를 꺼낼 수 있었다

회사 데이터는 대부분 관계형 데이터베이스(표 여러 개를 키로 엮어 저장하는 시스템)에 들어 있다. 여기서 원하는 숫자를 꺼내려면 SQL이라는 질의 언어를 써야 한다. '지난 분기 지역별 재구매율'처럼 간단해 보이는 질문도 표 여러 개를 JOIN(표 잇기)하고 GROUP BY(묶어서 집계)해야 답이 나온다. 그래서 현업 담당자가 데이터팀에 요청을 넣고 기다리는 일이 흔하다.

Text-to-SQL은 이 간극을 메우는 기술이다. 사람이 자연어로 물으면 시스템이 질문을 SQL로 바꿔 실행하고 결과를 돌려준다. BIRD 논문논문은 이 연구의 동기를 '전문가가 아닌 분석가도 자연어로 관계형 데이터베이스에서 원하는 정보를 꺼낼 수 있게 하는 것'으로 설명한다.

그런데 예전 연구들은 실제보다 쉬운 시험을 치르고 있었다. Spider 논문논문에 따르면 이전 데이터셋은 대부분 데이터베이스 하나로 학습과 시험을 함께 치렀고, 같은 SQL이 질문 표현만 바뀐 채 학습 세트와 시험 세트 양쪽에 들어 있었다. 일부 기존 벤치마크에서 80%가 넘는 정확도가 나왔지만, 모델이 질문-SQL 짝을 외워 템플릿을 고르는 수준이었으므로 그 정확도는 부풀려진 것이라고 지적했다. 반대로 WikiSQL처럼 규모가 큰 데이터셋은 표 하나짜리 단순한 질의만 담고 있었다.

핵심 아이디어: 데이터베이스 전담 통역사

Text-to-SQL 시스템은 데이터베이스 전담 통역사에 비유할 수 있다. 좋은 통역사는 단어만 바꿔 말하지 않는다. 먼저 상대 회사 장부가 어떻게 생겼는지, 곧 어떤 표에 어떤 칸이 있고 표끼리 어떻게 이어지는지 익힌다. 그다음 질문 속 '매출'이 장부의 어느 칸인지 찾아 맞추고, 장부가 알아듣는 문장으로 옮긴다. 말이 애매하면 되묻고, 옮긴 문장이 통하는지 먼저 확인한다.

이 비유에서 '장부 구조'가 스키마(표·열·관계의 설계도)이고, 질문 속 말과 스키마를 이어 주는 일이 스키마 연결(schema linking)이다. BIRD논문는 여기에 한 가지를 더했다. 스키마만으로는 부족하고 실제 값까지 이해해야 한다는 것이다. 예를 들어 급여가 'US$'와 쉼표가 섞인 문자열로 저장돼 있으면 특수 문자를 지우고 숫자로 바꿔야 평균을 낼 수 있다. '대출 자격은 소유주(OWNER) 계좌에만 있다' 같은 업무 지식(외부 지식)을 알아야 조건을 올바르게 걸 수 있다.

그래서 오늘날의 Text-to-SQL은 '문장 번역'보다 '데이터베이스를 이해한 다음 답을 찾아가는 일'에 가깝다. LLM(대규모 언어 모델)이 나온 뒤로는 이 일을 여러 단계로 나누고 도구를 써 가며 처리하는 AI 에이전트 형태가 늘고 있다.

어떻게 작동하나: 질문에서 답까지

LLM 기반 Text-to-SQL 시스템은 대체로 다음 순서로 움직인다. 세부 구현은 시스템마다 다르지만 뼈대는 비슷하다.

첫째, 질문을 받는다. 데이터베이스와 상관없는 질문이나 답할 수 없는 질문은 여기서 거르고, 뜻이 모호하면 되묻는다. 둘째, 스키마 연결을 한다. 수많은 표와 열 가운데 질문에 필요한 것만 골라낸다. 이때 열 설명, 값 예시, 업무 용어 정의 같은 메타데이터(데이터에 대한 설명 정보)를 참고한다. 스키마 전체를 프롬프트에 넣으면 컨텍스트 윈도가 넘치고 토큰 비용도 커지기 때문이다. 셋째, 골라낸 스키마와 질문을 넣고, 필요하면 비슷한 질문-SQL 예시도 함께 넣어 LLM이 SQL을 쓰게 한다.

넷째, 실행하기 전에 검증한다. 문법 오류가 없는지 시험 실행(dry run)을 해 보고, 오류가 나면 오류 메시지를 LLM에 다시 보여 주고 고치게 한다. 이 '생성-검증-수정' 고리가 정확도를 크게 좌우한다. 다섯째, 통과한 SQL을 실제 데이터베이스에서 실행하고, 결과 표를 사람이 읽기 쉬운 말로 풀어 설명한다.

연구마다 이 흐름의 어느 단계에 힘을 주는지가 다르다. 아래 발전 흐름에서 보듯 DIN-SQL은 질문 분해와 자기 수정에, DAIL-SQL은 프롬프트 구성에, CHESS는 스키마 고르기와 검증에 집중했다.

발전 흐름: 벤치마크가 문제를 키우고, 방법이 따라갔다

출발점은 2018년에 나온 Spider논문다. 대학생 11명이 1,000시간을 들여 200개 데이터베이스(138개 도메인), 10,181개 질문, 5,693개의 복잡한 SQL을 만들었다. 핵심은 시험 방식에 있었다. 학습과 시험에 서로 다른 데이터베이스를 써서 모델이 처음 보는 스키마에도 일반화하도록 요구했다. 이 설정에서 당시 최고 모델의 정확 일치(exact matching, 정답 SQL과 똑같이 썼는지 보는 지표) 정확도는 12.4%에 그쳤다.

2023년에는 LLM이 들어오면서 판도가 바뀌었다. DIN-SQL논문은 SQL 생성을 작은 하위 문제로 쪼개 그 답을 차례로 LLM에 넣는 방법에 자기 수정(self-correction)을 결합했다. 이 방법은 예시 몇 개만 보여 주는 단순 퓨샷 프롬프트보다 성능을 약 10% 끌어올렸고, Spider 비공개 시험 세트의 실행 정확도를 85.3으로 높였다. 실행 정확도는 SQL을 실제로 돌려 결과가 정답과 같은지 보는 지표다. 같은 해 DAIL-SQL 연구논문는 질문 표현 방식, 예시 고르기, 예시 배치 같은 프롬프트 엔지니어링 기법을 체계적으로 비교했다. 그 결과를 하나로 묶어 Spider 실행 정확도 86.6%를 기록했고, 토큰 효율과 오픈소스 LLM 파인튜닝의 가능성도 함께 살폈다.

Spider 점수가 오르자 'LLM이 이미 데이터베이스 창구 역할을 할 수 있나'라는 질문이 나왔다. 2023년의 BIRD논문는 아직 아니라고 답했다. BIRD는 37개 전문 분야, 95개 데이터베이스(합계 33.4GB), 12,751개 질문-SQL 짝으로 크고 지저분한 실제 값, 외부 지식, SQL 실행 효율을 시험했다. 데이터 누수를 막으려고 시험용 데이터베이스 15개는 따로 만들어 숨겼다. GPT-4도 실행 정확도가 54.89%에 머물러 사람의 92.96%와 차이가 컸다. DIN-SQL은 BIRD 비공개 시험 세트에서 55.9%를 기록했다.

2024년의 CHESS논문는 일을 네 에이전트로 나눴다. 관련 값과 설명을 찾는 정보 검색, 큰 스키마를 작은 하위 스키마로 줄이는 스키마 선택, SQL 후보를 만들고 반복해서 고치는 후보 생성, 자연어 단위 테스트로 검증하는 단위 테스트 에이전트다. 스키마 선택만으로 정확도가 약 2% 오르고 LLM 토큰 사용량은 5분의 1로 줄었으며, BIRD 시험 세트에서 71.10%를 기록했다. 같은 해 Spider 2.0논문은 시험장을 기업 현장으로 옮겼다. BigQuery·Snowflake 같은 클라우드 데이터 웨어하우스에 있고 열이 1,000개를 넘기도 하는 실제 데이터베이스로 632개 워크플로 문제를 만들었다. 문제를 풀려면 메타데이터, SQL 방언(데이터베이스마다 조금씩 다른 SQL 문법) 문서, 프로젝트 코드까지 찾아봐야 하고 100줄이 넘는 SQL을 쓰기도 한다. o1-preview 기반 코드 에이전트는 Spider 1.0에서 91.2%, BIRD에서 73.0%를 풀었지만 Spider 2.0에서는 21.3%만 풀었다.

요즘 어디로 가고 있나: 되묻고, 멈추고, 행동하는 데이터 에이전트

2026년 연구의 관심은 'SQL을 맞게 쓰는가'에서 '믿고 쓸 수 있는가'와 'SQL 너머의 일까지 하는가'로 옮겨 가고 있다.

첫째 갈래는 모호성이다. ARCS논문는 실제 배포 환경에서 질문의 모호함이 주된 오류 원인이 된다고 본다. 그래서 자유로운 대화로 되묻는 대신 명시적이고 제약된 상호작용으로 모호함을 푸는 '구조화된 모호성 해소'를 제안했다. 이 연구가 실제 데이터베이스에서 자연스럽게 생긴 모호함과 가능한 해석, 해석별 SQL을 모두 표시해 벤치마크를 만들었더니, gpt-6-sol도 처음부터 끝까지 맞힌 실행 정확도가 51%에 그쳤고 오픈소스 모델은 27%를 넘지 못했다.

둘째 갈래는 언제 멈출지 아는 능력이다. 의료 기록 질의를 다룬 Sentinel 연구논문는 에이전트의 추론 과정, 코드, 데이터베이스 출력을 분석하는 신뢰도 판정 층을 붙여 세 지점에서 멈출지 정한다. 실행 전에는 답할 수 없는 질문을 거절하고, 실행 중에는 가망 없는 Trajectory를 끊고, 마지막에는 믿기 어려운 답을 내보내지 않는다. EHRSQL 벤치마크에서 답을 내는 비율은 84%에서 55%로 줄었지만, 내보낸 답의 정확도는 54%에서 69%로 올랐다.

셋째 갈래는 데이터 에이전트로의 확장이다. Argo-Bench논문는 기존 Text-to-SQL 벤치마크가 질의 생성만 평가하고, 감사 결과 정답지에도 오류가 잦았다고 짚는다. 이 연구는 235개 표, 75억 행 규모의 ERP(전사적 자원 관리) 웨어하우스 위에 210개 데이터 과학·분석 과제를 만들었다. 에이전트는 사기 계정 정지나 배달원 인센티브 예산 배분 같은 행동까지 하고, 채점은 그 행동이 시뮬레이터에 낳은 결과로 한다. 14개 모델 가운데 가장 강한 모델도 95점 이상을 받은 과제가 34.8%에 그쳤다.

한계와 쟁점

가장 큰 한계는 '실행됐다'와 '맞았다'가 다르다는 점이다. 문법에 문제가 없는 SQL도 질문의 뜻을 잘못 잡으면 그럴듯하지만 틀린 숫자를 돌려준다. 결과가 깔끔한 표로 나오니 사용자는 의심하기 어렵다. ARCS논문가 지적하듯 모호함은 미묘하고 도메인과 데이터마다 달라서, 시스템이 사용자 의도에서 조용히 벗어나게 만든다. 그래서 실무에서는 생성된 SQL과 시스템이 세운 가정을 함께 보여 주고, 중요한 숫자는 사람이 확인하는 휴먼 인 더 루프 장치를 두는 경우가 많다.

둘째, 평가 자체가 흔들린다. 벤치마크 점수는 실제 업무 성능을 그대로 보여 주지 않는다. Spider 1.0과 BIRD에서 높은 점수를 낸 에이전트가 Spider 2.0논문에서는 크게 떨어졌고, Argo-Bench논문는 기존 벤치마크 정답지의 오류를 문제로 꼽았다. 지표에도 약점이 있다. 정확 일치는 다르게 썼지만 같은 결과를 내는 SQL을 틀렸다고 판정하고, 실행 정확도는 우연히 결과만 같은 SQL을 맞았다고 판정할 수 있다.

셋째, 운영 문제다. BIRD논문가 효율 지표를 따로 둔 것처럼, 큰 데이터베이스에서는 맞는 SQL이라도 느리면 쓸모가 떨어진다. 또 LLM이 쓴 SQL을 그대로 실행하는 구조이므로 읽기 전용 권한, 실행 시간 제한, 민감한 열에 대한 접근 통제 같은 기본 안전장치는 모델 성능과 별개로 갖춰야 한다. 열 이름이 알아보기 어렵거나 업무 용어 정의가 여기저기 흩어져 있으면 어떤 모델도 헤맨다. 데이터 카탈로그나 시맨틱 레이어처럼 데이터의 '뜻'을 정리해 두는 작업이 정확도의 바탕이 되는 이유다.

더 공부하려면

처음이라면 Spider논문의 서론부터 읽기를 권한다. 왜 '처음 보는 데이터베이스로 시험'해야 하는지가 이 분야 문제 정의의 핵심이다. 이어서 BIRD논문의 그림 1에 나오는 세 가지 예시(지저분한 값, 외부 지식, 실행 효율)를 보면 현실 데이터가 왜 어려운지 감이 온다.

방법론은 DIN-SQL논문로 '쪼개서 풀고 스스로 고치기'를, DAIL-SQL 연구논문로 프롬프트 구성 요소별 효과를, CHESS논문로 에이전트 분업 구조를 차례로 보면 좋다. 기업 환경을 염두에 둔다면 Spider 2.0논문이 기존 벤치마크보다 무엇을 더 요구하는지 확인하면 된다.

최근 흐름은 ARCS논문로 모호성 문제를, Sentinel 연구논문로 신뢰도와 멈춤 판단을, Argo-Bench논문로 SQL을 넘어선 데이터 에이전트 평가를 읽으면 2026년의 주요 쟁점을 대부분 훑을 수 있다.