쿼리 로그로 스키마 문서 없는 기업 DB의 Text-to-SQL을 푼다

무엇인가

Text-to-SQL은 Spider나 BIRD 같은 학술 벤치마크에서는 거의 포화 상태의 정확도를 보이지만, 기업 환경에 배포하면 성능이 급락한다. 저자들은 그 원인을 가정의 불일치로 지목한다. 기존 접근은 데이터베이스 식별자, 완전한 테이블 스키마, 명시적 외래키, 해석 가능한 컬럼명을 입력으로 전제하는데, 기업 DB는 이 중 어느 것도 제공하지 않는다. 테이블과 컬럼에는 설명이 없고 이름은 팀 밖 사람이 이해할 수 없는 도메인 약어이며, 외래키는 거의 선언되지 않아 조인 관계가 DBA의 암묵지나 과거 쿼리 패턴에만 존재한다. 테이블 수는 수백에서 수천에 이르고 스키마는 계속 바뀌어 정적 문서는 금방 낡는다. 논문은 이 상황을 스키마 모호성 문제(schema ambiguity problem)라고 부른다.

어떻게 동작하나

저자들의 통찰은 문서가 없어도 구조적 지식의 원천이 남아 있다는 것이다. 바로 프로덕션 SQL 쿼리 로그다. 로그는 어떤 테이블이 함께 조회되는지, 실제로 어떻게 조인되는지, 어떤 컬럼이 어떤 업무 개념에 대응하는지를 담고 있다. 즉 문서에 있어야 할 내용을 수작업 주석 대신 사용 패턴에서 얻자는 발상이다. 이에 따라 문제를 세 단계로 분해한다. 질문이 들어오기 전 오프라인으로 쿼리 로그에서 지식 그래프를 구축하고, 질문이 오면 그래프에서 필요한 컨텍스트를 검색하고, 그 컨텍스트만 근거로 SQL을 생성한다.

무엇과 다른가

1단계 지식 그래프 구축은 구조 추출, 메타데이터 생성, 엔티티 주석으로 나뉜다. 먼저 각 쿼리를 파싱해 테이블 등장 빈도 freq(T)를 세고, 빈도가 높은 테이블을 핵심 엔티티로 우선한다. 조인 관계 추출은 단순 파싱으로는 부족하다. WHERE 절의 암묵적 조인, CTE를 매개로 한 관계, 다중 조인이 흔하기 때문에 LLM에게 쿼리를 분석시켜 조인 컬럼 쌍과 조인 타입으로 이루어진 트리플릿 J(Tj,Tk)={(cj,ck,τ)}를 뽑아낸다. 이 조인 패턴의 빈도가 그래프 엣지 가중치가 된다. 다음으로 d_wfm_fclty_pop_dfntn_mnl 같은 이름만으로는 의미를 알 수 없으므로, 각 테이블을 참조하는 대표 쿼리를 LLM에 주고 테이블 목적·컬럼 의미·전형적 사용 패턴을 담은 합성 메타데이터를 생성한다. 마지막으로 그 메타데이터에서 'employee', 'time-off', 'approval rate' 같은 도메인 엔티티를 추출해 테이블에 붙인다. 이것이 사용자 질문과 스키마 사이의 어휘 격차를 잇는 다리다.

어떻게 쓰나

2단계 검색은 엔티티 매칭, 그래프 탐색, 구조적 랭킹을 조합한다. 임베딩 유사도만으로는 사용자가 'shift swaps'나 'approval rates'를 물을 때 d_shft_swp_agg를 찾아내지 못한다. 그래서 질문에서 같은 방식으로 엔티티를 추출하고, |E(Q)∩E(T)|/|E(Q)|로 테이블별 엔티티 겹침 점수를 계산해 시드 노드로 삼는다. 여기에 엔티티 점수, 메타데이터와의 임베딩 유사도, 유사한 과거 질문에 등장한 이력 점수를 α·s_ent+β·s_emb+γ·s_hist로 결합하되 α>β>γ로 엔티티 매칭에 가장 큰 비중을 둔다. 시드에서 시작해 최대 k홉 너비 우선 탐색으로 조인 관계를 따라 추가 테이블을 찾고, 경로 점수는 경로상 엔티티 커버리지와 엣지 가중치(조인 빈도)의 합으로 매긴다. 질문에 직접 언급되지 않았지만 완전한 SQL에 필요한 테이블을 이 과정에서 발굴하는 것이다. 또한 시드 테이블을 개인화 벡터로 한 Personalized PageRank를 적용해 엔티티로 직접 매칭되지 않아도 구조적 역할이 큰 브리지 테이블을 찾아낸다. 3단계에서는 테이블 메타데이터, 과거 패턴에서 얻은 조인 경로, 유사 과거 쿼리 퓨샷 예시를 계층적으로 조립해 LLM에 넣고 SQL을 생성한다. 이때 프롬프트는 제공된 메타데이터에 존재하는 테이블·컬럼만 쓰고 식별된 경로대로 조인하며 스키마 요소를 환각하지 말라고 지시한다.

전제와 한계

실험은 두 축이다. 아마존 내부 배포는 수천 개 중 자주 조회되는 240개 테이블과 약 50만 건의 과거 쿼리로 구성됐고 스키마 문서는 전혀 없었으며, 그래프에는 쿼리 패턴에서 뽑은 1,847개 조인 엣지가 생성됐다. 평가는 LLM이 생성한 25문항과 현업 전문가가 만든 10문항, 총 35문항으로 진행하고 데이터 엔지니어 2명이 블라인드 비교했다. 공개 벤치마크인 BEAVER는 209문항, 463개 테이블 규모로, 원래 스키마 파일만 제공되고 쿼리 로그가 없어 스키마 문서에서 동등한 메타데이터를 만들어 파이프라인 입력 형식을 맞췄다. 이 과정에서 선언된 127개 관계 외에 1,113개의 암묵적 조인을 추가로 발견해 총 1,310개 엣지를 얻었다. 베이스라인은 동일한 메타데이터를 E5-base-v2로 임베딩해 코사인 유사도 상위 12개 테이블을 검색하는 RAG로, 차이는 오직 검색 전략이다.

결과는 BEAVER에서 실행 유효성 95.7% 대 베이스라인 60.8%로 35포인트 차이다. 지식 그래프 구조가 일관된 테이블-컬럼 조합을 만든다는 뜻이다. 블라인드 페어와이즈 비교에서 LLM 심판은 45.5% 대 34.0%로, 루브릭 기반 심판은 47.8% 대 30.6%로 이 시스템을 선호했다. 차원별로는 실행 가능성에서 +74 대 +1, 스키마 유효성에서 +60 대 +17로 격차가 가장 컸는데, 이는 그래프 유도 검색이 환각 컬럼을 줄인다는 것을 직접 보여준다. 아마존 배포에서는 전문가가 70% 대 10%, LLM 심판이 80% 대 16%로 선호했고, 인간이 명확한 선호를 보인 케이스에서 LLM 판정과의 일치율은 83%였다. 제거 실험에서 엔티티 매칭을 빼면 점수가 5.4% 떨어지고 페어와이즈 비교의 43%를 잃어 가장 큰 기여를 했고, KG 탐색은 2.1%, PPR 랭킹은 60.8%가 동률일 만큼 미세한 개선에 그쳤다. 별도로 생성 SQL을 BEAVER의 사람이 작성한 골드 SQL과 같은 블라인드 프로토콜로 비교했더니, 해석이 갈리는 개방형 질문에서는 9.00 대 8.85로 골드를 앞섰고 46% 케이스에서 동등 이상 판정을 받았다. 정답이 명확한 결정적 질문에서는 골드가 우세했다.

실무 관점에서 이 논문이 주는 메시지는 명확하다. 스키마 문서를 정비하는 대신 이미 쌓여 있는 쿼리 로그를 자산으로 취급하라는 것이다. 조인 빈도, 동시 등장 테이블, 컬럼과 업무 용어의 대응을 로그에서 추출해 그래프로 만들고, 검색 단계에서 임베딩 유사도에 의존하기보다 도메인 엔티티 매칭을 1순위 신호로 두라는 설계 지침은 사내 데이터 카탈로그가 빈약한 조직에 바로 적용할 수 있다. 다만 도입 전 확인할 것은 세 가지다. 첫째, 로그가 충분히 축적돼 있고 조인 패턴이 반복적으로 나타나는지. 둘째, 메타데이터와 엔티티를 LLM으로 합성하는 단계에서 잘못된 의미가 그래프에 굳어지지 않는지. 셋째, 개방형 질문이 많은 워크로드라면 단일 골드 정답 기반 정확도 대신 실행 유효성과 전문가 블라인드 평가를 함께 봐야 한다는 점이다.

저자들이 밝힌 한계는 BEAVER 적응 방식에 있다. BEAVER는 쿼리 로그 대신 스키마 문서를 주기 때문에, 이 벤치마크에서 만든 엣지는 로그에서 유도한 것이 아니라 스키마에서 유도한 것이다. 따라서 빈도 정보가 없고 실제 사용 패턴에는 등장하지 않는 관계가 섞여 있을 수 있다. 또한 내부 배포 결과는 재현이 불가능하고, 외래키가 아예 선언되지 않은 환경에서 로그가 희박하면 그래프 구축 자체가 어려워진다는 전제도 깔려 있다.