12.1 파편화된 환상의 타파: SQL 생성 AI(Text-to-SQL) 평가의 거대한 난제와 실행 기반(Execution-based) 패러다임으로의 강제 전환

자연어(Natural Language) 프롬프트를 입력받아 엔터프라이즈급의 복잡하고 정확한 RDBMS 쿼리문을 출력해 내는 Text-to-SQL(이하 NL2SQL) 파운데이션 모델(Foundation Model) 기반 AI 에이전트를 개발하고, 이를 실제 100만 건의 트래픽이 몰리는 프로덕션 환경(Production Environment)에 배포하기 전에 모델의 ’코드 정확성(Code Correctness)’을 자동화된 CI/CD 파이프라인에서 100% 신뢰할 수 있게 평가하는 작업은, 일반적인 대화형 챗봇(Conversational Chatbot)이나 요약 모델 개발과는 본질적으로 궤를 완벽히 달리하는 **‘거대한 기계 공학적 난제(Monumental Engineering Challenge)’**를 수반한다.

과거 수십 년간 딥러닝과 자연어 처리(NLP) 학계에서 기계 번역(Machine Translation)이나 문서 요약(Summarization) 분야의 모델 성능을 평가하기 위해 빛나는 절대적인 벤치마크 표준으로 군림했던 BLEU(Bilingual Evaluation Understudy)나 ROUGE와 같은 정적인 텍스트 N-gram 유사도 비교 오라클(Static Text-Similarity Oracle) 체계는, SQL이라는 우주에서 가장 엄밀하고 절망적으로 복잡한 ‘논리 대수학(Logical Algebra)’ 언어 앞에서는 완전히 신뢰성을 상실하고 한낱 웃음거리인 무용지물(Useless Noise)로 전략해 버린다.

1. 지옥의 다형성(Polymorphism): 구문적 동등성(Syntactic Equivalence) 맹신의 참혹한 한계

NL2SQL 평가가 백엔드 MLOps 엔지니어들에게 극도로 어렵고 혐오스러운 작업인 근본적인 이유는, SQL이라는 선언적 언어(Declarative Language) 특유의 ‘단일한 결과 셋(Result Set) 목적지로 향하는 논리적 경로(Path)의 무한한 다형성(Infinite Polymorphism)’ 때문이다.

예를 들어, “현재 우리 회사의 영업부(Sales)에 근무하는 5년 차 이상 직원들의 총 인건비 합산액을 계산해 줘“라는 B2B 사용자의 대시보드 프롬프트 질문에 대해, 사내 최고 등급 데이터베이스 설계자(DBA)가 수제작으로 튜닝해 놓은 절대적인 황금 정답지 쿼리(Golden Reference Query)는 성능 최적화를 위해 우아한 INNER JOIN을 사용하여 Employees 테이블과 Departments 테이블을 결합했을 수 있다.
그러나 거대 언어 모델(LLM)이 런타임에 추론해 낸 쿼리는, WHERE ... IN 절을 복잡하게 엮은 중첩 서브쿼리(Nested Sub-query) 방식을 작성했거나, 혹은 최신 데이터 웨어하우스 문법을 뽐내듯 CTE (Common Table Expressions, WITH 절)나 분할 Window Function 논리 블록을 무자비하게 동원했을 수 있다.

이 두 쿼리문 코드는 평문 문자열 소스 코드(Plain Text String)나 단순 컴파일 기반의 AST(추상 구문 트리) 구조 비교 관점에서는 겹치는 키워드 토큰이 거의 없는 **‘얼굴 모양이 매우 다르게 생긴 완전한 오답(False Negative)’**처럼 보인다.
하지만 데이터베이스의 내부 쿼리 옵티마이저(RDBMS Query Optimizer) 파싱 엔진이라는 진실의 용광로 속으로 던져지는 순간, 이 생김새가 완전히 다른 두 개의 SQL 스크립트는 완전히 동일한 백그라운드 논리적 실행 계획(Execution Plan)으로 스스륵 수렴하여 1원 단위까지 똑같은 결괏값(Tensor)을 0.1초 만에 반환한다.

한마디로, “LLM 에이전트가 방금 작성한 코드가, 저장된 텍스트 정답 쿼리와 똑같이 생겼는가?”(Exact Match)를 문자열 단위로 묻는 순진한 구문적 기반(Syntactic-based)의 텍스트 비교 검증기 봇은, AI 모델의 경이롭고 다양한 논리적 구문 창의성을 오히려 오답과 에러로 치부하여 0점을 매겨 처벌(Hard Penalty)해 버리는, CI 파이프라인 전체를 박살 내는 치명적인 구조적 결함을 내포하는 것이다.

2. 모래성 붕괴와 의미론적 실행 결과 비교(Semantic Execution Comparison) 패러다임으로의 피 튀기는 진화

따라서 수십억 원의 돈과 회사의 명운이 오가는 미션 크리티컬(Mission-critical)한 엔터프라이즈 환경에서, Text-to-SQL 모델의 릴리즈 코드를 MLOps CI/CD 파이프라인에 태워 안전하게 운영 서버(Database)에 배포하기 위해서는, 소스 코드 텍스트의 피상적인 생김새와 글자 수만 수동적으로 채점하던 고전적인 구문론적 오라클(Syntactic Oracle) 패러다임을 인프라 레벨에서 스위치를 내리듯 완전히 폐기(Total Deprecation) 선언을 해야만 한다.

그 대신, 인간 데이터 사이언티스트의 정답 쿼리 블록과 AI 엔진의 즉흥적인 예측 쿼리 블록을, 운영 서버의 DB와 완전히 동일한 스키마 구조와 수만 건의 더미(Dummy) 데이터를 가진 상태(State)로 스냅샷(Snapshot) 찍힌 **‘100% 철저히 통제된 샌드박스 데이터베이스(Ephemeral Sandbox DB Container)’**에 각각 병렬로 직접 밀어 넣고 강제 런타임(Runtime)을 터뜨려보는 막대한 I/O, CPU 고비용의 험난한 오라클 파이프라인 로직을 감내해야 한다.
그리고 두 개의 완전히 다르게 생긴 쿼리가 DBMS 엔진을 긁고 지나가 메모리에 반환해 낸 최종 산출물 데이터, 즉 ‘동적 데이터 매트릭스 텐서(Data Tensor, 행 Row과 열 Column의 2차원 부동소수점 배열)’ 내의 모든 레코드 원소값들이 단 1%의 누락이나 순서 뒤틀림 없이 물리적으로 100% 교차 일치(Exact Data Match)하는가를 검증하는 가장 차갑고, 가장 비싸며, 가장 원초적이고 신뢰성 높은 **[실행 결과 비교(Execution Result Comparison)]**의 무자비한 패러다임으로 시스템의 전면적인 진화와 세대교체가 이루어져야만 한다.

본 12.1장 하위 절들에서는 기존 텍스트 기반 얕은 평가 지표들이 파이프라인 내부에서 구체적으로 어떠한 수학적, 논리적 오판(False Negatives)을 어처구니없이 빈번하게 저지르는지 구체적인 쿼리 분해 사례를 통해 증명한다. 더불어, 왜 오직 AWS/GCP의 막대한 컴퓨팅 컨테이너 자원을 태워가며 구동하는 무거운 [실행 기반(Execution-based, 샌드박스) 오라클 시스템]만이 이 제어 불가능한 Text-to-SQL 언어 모델의 지능을 판별할 수 있는 유일하고 절대적인 ’은검(Silver Bullet)’인지 그 철학적, 데이터 공학적 당위성을 바닥까지 낱낱이 파헤칠 것이다.