Text-to-SQL의 다음 단계는 모델이 아니라 스키마 그래프다

테이블이 수백 개가 되면 Text-to-SQL의 문제는 모델이 SQL을 못 만드는 데 있지 않다. 질문과 관계없는 스키마까지 함께 보여주는 순간, 모델이 판단해야 할 공간이 너무 커진다는 데 있다. 이 글에서는 필요한 관계만 골라 더 작고 검증 가능한 컨텍스트를 만드는 방법을 살펴본다.

TL;DR

전체 스키마를 프롬프트에 넣는 대신 질문에 필요한 테이블·컬럼·업무 용어·조인 경로만 골라야 한다.
Vector Search는 의미가 비슷한 대상을 찾고, Graph Traversal은 실제 연결 경로를 찾는다. 둘은 경쟁 관계가 아니라 조합 대상이다.
개인정보나 거래 원문을 그래프에 복사할 필요는 없다. 스키마와 업무 메타데이터만으로도 더 작고 검증 가능한 컨텍스트를 만들 수 있다.

왜 지금 중요한가

Text-to-SQL은 자연어 질문을 SQL로 바꾸는 문제처럼 보인다. 그러나 실제 데이터베이스에서는 SQL 문법보다 어떤 테이블을 선택하고 어떤 JOIN을 구성할지가 더 어렵다.

스키마가 작을 때는 전체 구조를 모델에 전달해도 버틸 수 있다. 테이블과 컬럼이 늘어나면 관련 없는 후보가 섞이고, 토큰 비용이 증가하며, 잘못된 JOIN과 schema linking 오류가 함께 늘어난다. 다음 개선점은 모델을 무조건 키우는 것이 아니라 입력 컨텍스트를 구조적으로 줄이는 것이다.

핵심 흐름

1. 스키마를 문서가 아니라 관계로 표현한다

테이블 목록을 긴 텍스트로 나열하는 대신 다음 관계를 보존한다.

Table → Column → Business Concept → Relationship

여기에 외래키, 데이터 사전, 비즈니스 용어, 대표값, 자주 쓰인 JOIN 패턴을 연결하면 모델이 단순한 컬럼 이름 이상의 정보를 얻는다. 원본 거래 데이터를 옮기는 것이 아니라 질문 해석에 필요한 메타데이터를 구조화하는 방식이다.

2. 질문에서 시작 테이블을 찾는다

사용자의 질문에서 업무 용어와 엔터티를 추출한다. “지난 분기 지역별 해지율”이라면 고객, 구독, 해지, 지역, 기간 같은 개념이 seed가 된다.

이 단계의 출력은 아직 SQL이 아니다. 어떤 테이블과 컬럼이 후보인지에 대한 좁은 탐색 공간이다.

3. 필요한 JOIN 경로만 확장한다

seed table을 찾았다면 외래키 그래프를 따라 필요한 경로를 탐색한다. 무작정 모든 이웃을 가져오지 않고, 질문에 필요한 깊이와 관계 유형을 제한한다.

전체 스키마
  → seed table 탐색
  → business glossary 매핑
  → FK 경로 탐색
  → 필요한 컬럼만 확장
  → LLM에 전달할 context 생성

이 결과가 schema pruning이다. 모델에게 더 많은 정보를 주는 것이 항상 친절한 것은 아니다. 필요한 정보만 정확하게 주는 편이 추론과 검증을 쉽게 만든다.

4. 검색 방식은 하나로 고정하지 않는다

Vector Search는 의미적으로 비슷한 컬럼을 찾는 데 강하다. Full-text Search는 정확한 용어와 약어를 찾는 데 유리하다. Graph Traversal은 어떤 테이블을 어떤 경로로 연결할 수 있는지를 다룬다.

실용적인 파이프라인은 세 방법을 결합한다.

의미 검색으로 후보를 찾고, 텍스트 검색으로 용어를 보강한 뒤, 그래프 탐색으로 유효한 JOIN 경로를 검증한다.

실제 사례 / 신호

LinkedIn에 공유된 Text-to-SQL 메모는 Neo4j를 관계형 원본 DB의 대체재가 아니라 Semantic Layer로 사용하는 구상을 제안한다. 원본 RDB에는 transaction data를 두고, 별도 그래프에는 schema·glossary·relationship·join pattern을 둔다. SQL 생성은 LLM이 담당하고, SQLGlot 같은 검증 계층으로 구문과 위험한 출력을 확인하는 구조다. 이 내용은 원 게시물에 기반한 제안이므로 일반화된 성능 증거로 보기는 어렵다.

또 다른 GeekNews 사례인 memnest는 세션이 끝난 뒤에도 포트, 라이브러리 선택 이유, 버그 해결책을 기억해야 하는 문제에서 출발한다. 분야는 다르지만 두 사례는 같은 방향을 가리킨다. 좋은 AI 실행은 거대한 대화 기록이 아니라 다음 작업에 필요한 구조화된 맥락을 남긴다.

실전 활용 팁: 작은 스키마 그래프부터 만든다

처음부터 그래프 데이터베이스나 복잡한 온톨로지를 도입할 필요는 없다.

테스트용 SQL에서 테이블·컬럼·FK를 파싱한다.
업무 용어와 컬럼 별칭을 작은 사전으로 만든다.
질문 하나를 입력받아 seed table 후보를 출력한다.
FK 기준 1~2 hop만 확장한다.
전체 스키마와 가지치기 스키마를 각각 모델에 보내 결과를 비교한다.
생성 SQL을 파서로 검사하고, 선택된 테이블·조인 경로를 화면에 남긴다.

비교할 지표는 답변의 인상적인 문장이 아니다. 실행 가능한 SQL 비율, 잘못된 JOIN 비율, 입력 토큰 수, 사람이 수정한 횟수다.

바로 해볼 실험

하루짜리 실험은 다음처럼 구성할 수 있다.

20개 테이블과 FK가 있는 샘플 DB를 준비한다.
동일한 질문 10개를 전체 스키마 방식과 pruning 방식에 각각 입력한다.
생성 SQL의 실행 성공 여부와 정답 결과 일치 여부를 기록한다.
토큰 수와 응답 시간을 함께 측정한다.
실패한 질문을 검색 실패, 경로 실패, SQL 생성 실패, 검증 실패로 분류한다.

이렇게 하면 “그래프가 좋아 보인다”는 주장 대신 어느 단계가 실제 병목인지 알 수 있다.

리스크 / 반론

Schema graph가 자동으로 정확한 업무 의미를 보장하지는 않는다. 비즈니스 용어가 팀마다 다르고, FK가 있어도 업무적으로 유효한 JOIN이라는 보장은 없다. 대표값과 JOIN 패턴도 오래되면 잘못된 힌트가 된다.

또한 전체 스키마를 줄이면 필요한 예외 정보까지 제거할 수 있다. pruning 결과에는 선택된 이유, 제외된 후보, 사용한 관계, 스키마 버전을 함께 남겨야 한다. 작은 컨텍스트는 안전장치가 아니라 검증 가능한 가설이어야 한다.

결론

Text-to-SQL의 다음 경쟁력은 더 큰 프롬프트가 아니라 질문에 맞는 스키마를 고르고, 그 선택 근거를 보여주는 컨텍스트 컴파일러에 있다.

당장 거대한 플랫폼을 만들 필요는 없다. SQL 하나를 넣었을 때 관련 테이블과 JOIN 경로를 설명하고, 가지치기된 스키마를 export하는 작은 도구부터 시작하면 된다. 여러분의 Text-to-SQL 파이프라인은 전체 스키마를 보내고 있는가, 아니면 필요한 구조만 증명하며 보내고 있는가?