한 줄 요약

LLM은 SQL을 직접 쓰지 않습니다. 계획(JSON)만 내고, SQL은 서버가 렌더링하며, read-only 게이트를 통과해야만 실행됩니다. 사내에서 실제로 쓰는 Text-to-SQL 도구입니다.

결과

업무 소요 시간 기준 수치이며, 모델 정확도 수치가 아닙니다.

문제

팀의 데이터 질문이 전부 개발자에게 가는 SQL 요청이 되어 병목이 생겼습니다. 그대로 LLM에게 SQL을 쓰게 하면, 그럴듯하지만 틀린 테이블·컬럼·조인·집계를 쓰거나 위험한 쿼리를 만들 수 있습니다.

내 역할

• 사내 AI 콘테스트 조장이자 유일한 개발자
• 실제로 쿼리를 쓰는 실무자 팀과 요구사항 정의
• 설계·구현 후 실무에 적용

설계 결정

• LLM은 계획만 낸다. 구조화된 JSON 스키마로 plan 또는 clarify만 받고, 모델이 직접 쓴 SQL 응답은 차단합니다.
• SQL은 서버가 렌더링한다. 스키마 카탈로그에 묶인 plan 객체를 서버가 SQL로 바꿉니다.
• 실행 전 read-only 게이트. SELECT / WITH … SELECT만 허용하고, 금지 토큰·허용 객체·행 수 제한을 검사합니다.
• 애매하면 되묻는다. 플랜으로 표현할 수 없거나 모호한 질문은 SQL을 만들지 않고 clarify로 돌려보냅니다.
• 사람이 확인할 수 있게 남긴다. 라우팅 상태, 검증 코드, 결과 계약 코드, 축·필터를 trace로 노출하고, SQL 원문 보기는 세션 기반 잠금 해제 뒤에만 허용합니다.

실패에서 배운 것

실패를 8종으로 분류하고 회귀 테스트로 관리합니다: 잘못된 테이블, 잘못된 컬럼, 잘못된 조인, 집계 오류, 존재하지 않는 스키마, 위험한 쿼리, 모호한 질문, 실행은 되지만 오해를 부르는 결과.

공개 범위