Chapter 12. 실전 예제 2: SQL 생성 AI의 정확도 판별을 위한 실행 결과 비교 오라클
사용자의 평범하고 비정형적인 자연어(Natural Language) 질의를 입력받아, 복잡한 다중 테이블 스키마를 넘나드는 관계형 데이터베이스(RDBMS)의 쿼리 표준어인 SQL(Structured Query Language)로 즉석에서 변환 생성해 주는 ‘텍스트-투-에스큐엘(Text-to-SQL)’ AI 파이프라인 아키텍처는, 현대 엔터프라이즈(Enterprise) AI B2B 애플리케이션 환경에서 비즈니스 지표(BI) 접근성을 위해 그 수요가 가장 압도적이면서도 동시에 가장 검증(Validation)과 평가가 극악한 수준으로 까다로운 최상위권 소프트웨어 공학적 난제(Engineering Challenge) 중 하나로 꼽힌다.
일반적인 B2C 대화형 챗봇(Conversational Agent) 모델이 고객의 감정을 다루며 부드러운 대화를 나누는 피상적이고 관대한 역할을 수행한다면, Text-to-SQL 에이전트는 기업의 재무, 인사, 회계 데이터가 총망라된 심장부이자 숨통인 마스터 데이터베이스(Master Database)를 타겟으로 삼아, 문법적(Syntactical), 논리적(Logical), 그리고 스키마적(Schematic)으로 단 한 줄의 에러도 없는 완벽하게 무결한 트랜잭션 쿼리(Transaction Query)를 한 치의 오차 없이 조립해 내야 하는 무겁고 엄중한 책임을 짊어지고 있기 때문이다. 단 한 줄의 JOIN 테이블 누락이나 조건문(WHERE)의 환각(Hallucination)은 경영진의 의사결정에 수백억 원짜리 오답 데이터를 제공하는 파국을 초래할 수 있다.
11장에서 우리가 구축했던 고도화된 이원화 검증 시스템이, API 통신을 위해 ’정형화된 JSON 파라미터 구조의 동등성’을 문자열 트리 차원에서 디핑(Diffing)하는 형태의 비교적 단순하고 정적인 1차원적 오라클(Structural Oracle) 방어망이었다면, 본 12장에서는 생성된 코드(Code) 그 자체의 생태계 특성을 파고드는 가장 극한의 고도화된 동적 검증 기법인 **‘실행 결과 비교(Execution Result Comparison) 기반 평가 오라클’**이라는 매우 강력하고 파괴적이면서도 이질적인 아키텍처 패러다임으로 그 테스팅 수준을 한 차원 더 극한으로 끌어올린다.
SQL 로직과 같은 튜링 완전(Turing-complete) 언어계열 혹은 고도의 데이터 도메인 특화 언어(DSL, Domain-Specific Language)의 검증 세계에서는 문자열 매칭 시야를 넘어서는 놀랍고도 실용적인 특징이 설계의 근간으로 존재한다. 인간 데이터 사이언티스트 전문가가 직접 작성하여 컴파일한 ‘완벽한 정답 쿼리(Golden Ground Truth Query)’ 코드와 LLM이 확률적으로 생성해 낸 ‘예측 쿼리(Predicted SQL Query)’ 코드가, 구문 구조(Syntax Node)의 형태, 테이블 JOIN 계층의 순서, 고차원 서브쿼리(Sub-query) 또는 CTE(WITH) 구문 사용 여부 등 텍스트 문자열(String) 단위에서는 겉보기에 100% 완전히 딴판으로 해괴하게 생겼을지라도, 이 두 코드를 동일한 격리된 상태(Isolated State)의 샌드박스 데이터베이스 엔진(Database Engine)에 강제로 밀어 넣고 런타임(Runtime) 환경에서 실제로 실행(Execution)시켰을 때 반환되어 떨어지는 **‘최종 결과 테이블 텐서(Final Result Set Table / Data Frame)’**가 모든 row와 column의 값 공간에서 100% 완벽하게 수학적으로 교차 동일정합(EqMatch)한다면, 이는 소프트웨어 공학적으로 그리고 의미론적(Semantically)으로 완벽한 100점짜리 정답(True)으로 당당히 간주된다는 사실이다. 즉, 소스 코드 텍스트(Source Code Text)의 거죽이 아니라, 단단히 통제되고 격리된 컴퓨팅 인프라 환경 위에서 ‘데이터베이스 런타임이 최종적으로 뱉어낸 실행 로직 데이터(Data Value)들의 물리적 일치 여부’ 그 자체가 오라클의 절대적이고 유일무이한 채점 기준(Evaluation Rubric)이 되는 경이로운 아키텍처다.
본 장(Chapter 12)에서는 이 고도의 집약체인 ‘실행 결과 비교 오라클(Execution-based Oracle)’ 파이프라인이 지니는 근본적인 설계 철학과 역동성을 밑바닥부터 파헤친다.
나아가 이 복잡하고 무거운 역동적 채점기를 기업의 CI/CD(Continuous Integration) 자동화 테스트 하네스(Test Harness) 서버망에 매끄럽게 결합하기 위해 필연적으로 수반되어야 하는 인프라적 전제 조건들—밀리초(ms) 단위로 기동하고 폐기되는 1회용 격리된 샌드박스 데이터베이스 도커 컨테이너(Sandbox DB Docker Container)의 프로비저닝 구축 설계 파이프라인 구조, SQL 언어 특유의 비결정적 출력 정렬(Non-deterministic Rows Ordering)을 강제로 맞추고 비교하기 위한 정규화 해싱 알고리즘(Normalization Hashing Algorithm), 그리고 무엇보다 현대 Text-to-SQL 연구의 최고 권위 기관인 예일대(Yale Univ.)와 알리바바(Alibaba) 그룹이 주도하는 글로벌 LLM 벤치마크 모델인 Spider 및 BIRD-SQL에서 채택한 공식 절대 평가지표인 실행 정확도(EX, Execution Accuracy: Execution with Exact Match) 지표의 수학적 산출 파이프라인의 실전 백엔드 파이썬(Python) 코드 구현 방안에 이르기까지 그 뼈대를 가장 깊고 정밀하게 해부해 나갈 것이다.