기업용 SQL, 언제까지 '자연어 질문'만 던질 것인가

수천 개 테이블과 조인의 벽

기업용 Text-to-SQL은 자연어 질문을 SQL로 바꾸는 기술이다. 하지만 현장에서 더 어려운 문제는 SQL 문법이 아니라, 데이터에 담긴 업무 지식을 이해하는 일이다.

한 연구진이 대형 온라인 유통사의 실제 쿼리를 분석한 결과, 쿼리 하나에는 평균 약 5개의 원본 테이블과 7개의 중간 처리 단계가 사용됐다. Text-to-SQL 벤치마크인 Spider나 BIRD에서는 대개 한 자릿수의 테이블만 다룬다. 반면 기업 환경에서는 수천 개의 테이블 중 필요한 것을 찾고, 그 관계까지 파악해야 한다.

실제 쿼리를 공통 테이블 표현식(CTE, 쿼리 안에서 이름을 붙여 재사용하는 임시 결과 집합)과 서브쿼리 단위의 그래프로 복원한 실험에서도 이 문제가 확인됐다. Claude Sonnet 4.5에 자연어 질문만 제공했을 때 추상 구문 트리(AST) 유사도는 0.100이었다. 검색으로 찾은 관련 정보를 추가하자 0.278로 높아졌다.

제공 조건	AST 유사도
자연어 질문만	0.100
검색 컨텍스트 추가	0.278
정답 쿼리의 전체 구조	0.341
구조 + 검색 컨텍스트	0.582

정답 쿼리의 전체 구조를 제공했을 때는 0.341을 기록했다. 여기에 검색 컨텍스트까지 더하자 0.582로 크게 상승했다. 즉, 쿼리의 구조를 알려주는 것만으로는 충분하지 않았다. 검색을 통해 어떤 업무 지식을 제공하느냐도 그만큼 중요했다.

기업 데이터 환경을 다루는 BEAVER 벤치마크에서도 비슷한 한계가 나타났다. BEAVER는 사설 데이터 웨어하우스에서 수집한 9,128개의 질문, SQL 쌍으로 구성되며, 19개 업무 도메인과 812개 테이블을 포함한다. 최신 모델을 활용한 에이전트 시스템도 실행 정확도가 약 10.8%에 그쳤다. 다섯 가지 하위 과제의 정답을 모두 힌트로 제공해도 정확도는 30.1%에 머물렀다.

이 결과는 기업용 Text-to-SQL이 하나의 문제가 아니라는 점을 보여준다. 먼저 올바른 테이블과 조인 관계, 업무 규칙을 찾아야 한다. 그다음에야 이를 바탕으로 SQL을 작성할 수 있다. 필요한 지식을 고르는 단계와 SQL을 생성하는 단계가 분리되어 있는 셈이다.

Anthropic은 컨텍스트 엔지니어링을 ‘제한된 주의 예산 안에서 신호가 강한 토큰을 최소한으로 선택하는 작업’으로 정의한다. 기업용 Text-to-SQL에서 신호가 강한 정보는 긴 스키마 설명보다 실제로 사용된 조인과 필터 조건, 반복되는 CTE 패턴에 더 가깝다. 결국 성능을 좌우하는 것은 얼마나 많은 정보를 넣느냐가 아니라, 실제 업무를 설명하는 정보를 얼마나 정확히 골라내느냐다.

레퍼런스 카드가 만든 격차

연구진은 5,176개의 실제 운영 쿼리를 이용해 두 요소를 따로 최적화했다. 하나는 검색기와 프롬프트 같은 실행 체계인 ‘하네스’이고, 다른 하나는 모델이 검색해 활용할 지식이다.

하네스만 개선했을 때 AST 유사도는 상대적으로 Sonnet에서 약 3%, Qwen Coder에서 약 12% 높아졌다. 반면 문서와 원시 프로필을 ‘SQL 레퍼런스 카드’로 재구성하자 상승 폭은 각각 약 12%와 25%로 커졌다. 실제 실행이 가능한 102개 표본에서도 점수가 올랐다. Sonnet은 0.255에서 0.333으로, Qwen은 0.176에서 0.235로 향상됐다.

SQL 레퍼런스 카드는 설명을 짧게 압축한 요약문이 아니다. 원본 SQL과 조인 절차, 필터 패턴, CTE 예시 등 실제 쿼리 작성에 바로 활용할 수 있는 정보를 담는다. 전체 토큰의 약 60%도 구체적인 SQL 예시에 할당한다.

카드를 만드는 과정은 다음과 같다. 먼저 쿼리의 실행 빈도, 사용자 수, 참조 테이블 수를 기준으로 유용한 이력을 선별한다. 그런 다음 테이블별로 레퍼런스 카드를 만든다. 어떤 이력을 고르고 어떻게 요약할지도 고정하지 않는다. Google DeepMind의 알고리즘 탐색 시스템 AlphaEvolve 방식의 ‘수락, 복원 탐색’을 적용해 여러 구성을 시험하고, 최종 SQL 점수를 높이는 구성만 채택한다.

레퍼런스 카드의 품질이 높아질수록 하네스를 추가로 개선했을 때의 효과는 작아졌다. Qwen의 경우, 하네스 개선은 기본 문서와 함께 사용했을 때 약 12%의 추가 향상을 냈다. 그러나 최적화된 카드와 함께 사용했을 때는 추가 향상이 약 2%에 그쳤다. 이는 검색 방식이나 프롬프트뿐 아니라, 모델이 검색할 지식의 품질 자체가 성능을 크게 좌우한다는 뜻이다.

비슷한 접근은 다른 시스템에서도 찾아볼 수 있다. 데이터 분석 기업 Databricks의 TailorSQL은 과거 쿼리에서 조인 경로와 모호한 스키마의 의미를 추출한다. LinkedIn의 사내 시스템 SQL Bot은 로그에서 자주 쓰이는 필드와 조인을 찾아 지식 그래프에 반영한다. 다만 두 시스템이 정해진 추출 규칙과 재순위, 수정 과정에 초점을 맞춘다면, 이 연구는 레퍼런스 카드의 구성 방식까지 최종 SQL 성능을 기준으로 최적화한다.

메타데이터 부재의 부작용

운영 환경의 사용 기록이 부족한 BEAVER에서는 다른 양상이 나타났다. 에이전트 루프 없이 홀드아웃 300개를 평가한 결과, 실행 정확도는 카드만 검색했을 때 6.67%, 원시 이력 SQL만 검색했을 때 6.33%였다. 두 자료를 함께 검색하자 정확도는 9.00%로 상승했다. 이는 비교 기준보다 2.67%, 상대적으로는 약 42% 높은 수치다. 다만 대응표본 검정의 p값이 약 0.12였으므로, 통계적으로 확정적인 차이라고 보기는 어렵다.

이 결과는 BEAVER의 제한된 메타데이터와 관련이 있다. BEAVER에는 실행 빈도, 데이터 소비자, 조인 프로필과 같은 운영 메타데이터가 거의 없고, 테이블 정보도 컬럼명과 자료형, 일부 예시 행 정도로 제한된다. 이처럼 정보가 부족한 환경에서는 카드로 증류하는 과정에서 사라진 세부 정보와 원시 SQL에 남아 있는 세부 정보가 서로 다른 오류를 보완할 수 있다. 따라서 신규 도메인이나 공개 벤치마크에서는 카드와 원문을 별도의 채널로 검색하는 방식이 더 안전하다.

정확도 향상은 주로 테이블 선택과 스키마 연결에서 나타났다. 반면 여러 단계를 깊게 조합해야 하는 쿼리는 컨텍스트를 제공해도 정확도가 거의 0에 머물렀다. 이는 공개 평가가 탐색, 투표, 수정과 같은 에이전트 루프의 비교에만 집중할 경우, 운영 로그를 검색 가능한 카드로 변환하는 핵심 단계가 평가에서 빠질 수 있음을 보여준다.

이 문제는 RAG 전반에도 적용된다. 검색기는 이미 만들어진 후보 가운데 적절한 항목을 고를 뿐이다. 따라서 후보가 단순한 문서형 잡음인지, 아니면 조인, 필터, CTE 정보를 담은 코드북인지에 따라 같은 검색기를 사용하더라도 달성할 수 있는 성능의 상한이 달라진다.

성공한 쿼리에서 패턴 추출

운영 쿼리 로그와 소비 메타데이터가 충분하다면, 검색 시스템보다 먼저 ‘검색할 지식’을 정제하는 편이 효과적이다.

우선 성공한 쿼리에서 테이블과 도메인별 조인 절차, 필터 조건, CTE 패턴을 추출해 재사용 가능한 지식 아티팩트로 만든다. 이 정제 과정의 품질은 최종 SQL의 정확도로 평가한다. 그런 다음 검색 도구와 프롬프트, 에이전트 실행 과정을 개선한다. 내부 실험에서 관찰된 약 12~25%와 3~12%의 성능 차이도 이러한 접근 순서를 뒷받침한다.

반면 사용 데이터가 없는 콜드스타트 단계에서는 정제된 카드를 원본 데이터의 대체재로 취급하면 안 된다. 스키마와 소수의 예시만으로 만든 카드는 담을 수 있는 정보가 제한적이기 때문이다. 이때는 원본 SQL과 정제된 지식을 함께 인덱싱해야 한다. 이후 사람이 검증한 예시와 성공적으로 실행된 쿼리 로그가 쌓이면, 정제에 사용할 입력과 카드의 내용을 지속적으로 갱신한다.

판단 기준은 간단하다. 모델에 정보를 제공하기 전에, 사용 이력을 바탕으로 가공할 수 있는 자료가 있는지를 확인하면 된다.

자료가 있다면 선별 기준, 요약 방식, 카드 형식을 먼저 최적화한다.
자료가 없다면 원본 증거를 보존하면서 정제된 지식을 함께 축적한다.

핵심은 검색을 없애는 것이 아니다. 먼저 검색할 만한 지식을 만들고, 그다음 검색 방식을 다듬는 것이다.

출처

#기업 AI #에이전트 #지식 인프라