NL2SQL

사용자가 자연어 질의를 입력한 뒤 최종 답변을 받을 때까지 각 컴포넌트가 어떤 순서로 동작하는지 정리한 글입니다. 이 글은 시리즈의 첫 글입니다. 각 구성 요소를 왜 그렇게 선택했는지, 실험 과정에서 무엇이 달라졌는지는 이어지는 글에서 다룹니다. 단일 NL2SQL의 한계와 라우팅 구조 NL2SQL을 실운영 환경에 처음 적용하면 같은 문제를 반복해서 만납니다. DDL만으로는 T_CUST_MST 같은 약어 테이블이 무슨 의미인지, “순매출"이 어떤 산식인지 LLM이 파악·추론하지 못합니다. 공개 벤치마크가 아무리 올라가도 실제 엔터프라이즈 환경에서는 정확도가 절반 이하라는 보고가 꾸준히 나옵니다. 같은 종류의 오답은 데이터셋을 바꿔도 사라지지 않습니다. ...

DB Schema를 통째로 전달해 SQL을 생성하는 대신 Fact 테이블 위에서 Semantic Layer를 조립하게 만드는 데이터 분석 에이전트 구조를 살펴봅니다.

자연어 질의로 SQL을 자동 생성하고 데이터 분석 시각화를 돕는 오픈소스 AI 데이터베이스 클라이언트 Chat2DB를 소개합니다.

외부 서버 업로드 없이 웹 브라우저 자체 파싱으로 DDL 문법을 분석하여 즉시 ERD를 그려주는 로컬 실행형 시각화 도구를 소개합니다.

구글이 BIRD 벤치마크에서 80.04%의 실행 정확도를 기록한 Gemini-SQL2를 공개했습니다. 현업 적용 가능성과 한계를 데이터 엔지니어 관점에서 짚어봅니다.

지난 10편까지는 SQL 생성 과정에서 주로 발생하는 오답 유형을 분석했습니다. BIRD와 Spider 벤치마크를 활용하고 다양한 모델을 테스트하면서 오답을 COLUMN_BINDING, VALUE_BINDING, DERIVED_METRIC 등의 유형으로 세분화했습니다. SQL 오답을 계속 들여다보면서, 확인하고 싶은 것이 달라졌습니다. “그렇다면 생성된 SQL과 답변의 근거는 화면에서 어떻게 시각화되어야 하는가?” 그동안 정확도 중심의 테스트에 집중하느라 실제 사용자가 화면에서 무엇을 확인해야 하는지는 놓치고 있었습니다. 비즈니스 환경에서 쓰는 데이터 분석 AI라면 수치가 어디서 왔는지 명확히 보여야 합니다. 근거를 확인할 방법이 없다면 결과가 정답처럼 보이더라도 사용자는 결국 SQL을 다시 실행하여 검증할 수밖에 없습니다. ...

9편에서 multi-candidate 실험 세 건이 모두 유의미한 결과를 내지 못했지만 Schema Binding Plan으로 넘어가기 전에 확인하고 싶은 것이 하나 더 있었습니다. 모델 성능이 병목의 원인일 수 있다는 가설을 검증했습니다. Gemini flash-lite 대신 Pro 모델을 쓰면 현재 56% 수준인 정확도를 개선할 수 있을 것이라 예상했습니다. 이 과정에서 오답 유형 분류와 Spider 실험도 함께 진행했습니다. Pro 모델로 바꿨더니 오히려 정확도가 떨어졌다 모델만 교체하고 동일한 BIRD 50문항을 실행했습니다(프롬프트, 컨텍스트, 파이프라인은 그대로). 지표는 EX(Execution Accuracy)로, 생성된 SQL을 실제로 실행했을 때 정답과 같은 결과가 나오는지 확인하는 방식입니다. ...

자체 30문항에서는 정확도 80%를 기록했지만 BIRD 공개 벤치마크 50문항에서는 56%였습니다. 9번의 실험 끝에 ‘후보 여러 개 만들어서 고르기’ 가설을 세 방향에서 모두 폐기했습니다. 남은 과제는 스키마 이해와 방법론이었습니다.

라우팅 설계를 붙인 뒤 30문항 벤치마크에서 NL2SQL EX(Execution Accuracy)를 66.67%에서 80%까지 올렸습니다. 4사이클 동안 무엇을 고쳤고 어떤 한계에 부딪혔는지 정리합니다.

용어 정의를 마친 뒤, 질문이 들어왔을 때 그래프를 탈지 SQL을 작성할지 벡터 검색을 실행할지 정하는 라우터 설계 과정을 정리합니다.

Conway 유출이 나온 지 얼마 지나지 않아 Anthropic이 Claude Managed Agents를 정식 발표했습니다. 에이전트 인프라가 플랫폼에 흡수되는 흐름 속에서 DataNexus의 온톨로지가 왜 안전한지 정리합니다.

DataNexus의 기술 스택을 DataHub + Vanna + ApeRAG + DozerDB로 결정한 과정을 정리합니다. 후보군에서 탈락한 것들과 그 이유도 함께 설명합니다.

“VIP 기준이 뭐죠?” 유통사 BI Agent 프로젝트에서 있었던 일입니다. 현업 담당자가 테스트 중에 Agent에게 물었습니다. “지난달 VIP 고객 매출 알려줘.” 시스템이 숫자를 뱉어냈는데, 담당자 표정이 좋지 않았습니다. “이거 뭔가 이상한데요. VIP 기준이 우리 팀이랑 다른 것 같아요.” 마케팅의 VIP와 CRM의 VIP가 달랐습니다. 매출도 마찬가지입니다. 순매출이냐 총매출이냐에 따라 수억 단위로 차이가 납니다. 처음 겪는 문제가 아니었습니다. DW를 클라우드로 옮기는 프로젝트에서도 봤고, 차세대 정보계를 여러 벤더와 1년 넘게 만들 때도 똑같았습니다. 벤더마다 “매출”, “원가"의 기준이 달라서 데이터 정합성 잡느라 몇 주씩 지연됐습니다. 용어 하나 안 맞으면 전체 일정이 밀립니다. DW/BI 프로젝트를 하면서 이 문제가 안 나온 적이 없습니다. ...