데이터 요청이 IT 부서 대기열에 쌓이는 회사
"지난달 거래처별 매출 좀 뽑아주세요." 이런 요청은 SQL 몇 줄이면 끝나지만, 요청 접수와 우선순위 조정, 결과 확인을 거치면 답을 받기까지 며칠이 걸리곤 합니다. 개발자는 하루에도 몇 번씩 본업을 멈추고, 현업 담당자는 기다리다 못해 엑셀로 직접 집계합니다.
Text-to-SQL은 자연어 질문을 SQL로 바꿔 이 대기열을 줄여 줍니다. 다만 해결 범위는 분명히 구분해야 합니다.
Text-to-SQL이 틀리는 지점
업무 용어와 스키마의 간극
현업은 "거래처"라고 말하지만 테이블에는 `CUST_MST`, `BP_CD` 같은 이름이 있습니다. "매출"도 수주 기준인지, 출고 기준인지, 세금계산서 발행 기준인지 회사마다 다릅니다. 모델은 이 간극을 추측으로 메우고, 그 추측은 그럴듯한 오답이 됩니다.
실행은 되지만 의미가 틀린 SQL
더 위험한 것은 오류 없이 실행되는 오답입니다.
숫자가 정상적으로 출력되기 때문에 사용자는 틀렸다는 사실을 알기 어렵습니다.
정확도를 올리는 설계
컨텍스트로 제공할 세 가지
원본 테이블 대신 조회 전용 뷰
수백 개의 원본 테이블을 그대로 노출하지 않고, `v_sales_monthly`처럼 업무 단위로 정리한 조회 전용 뷰 10~20개만 보여 주는 방식이 효과적입니다. 조인과 취소 건 제외를 뷰 안에서 미리 처리하면 모델이 조인을 잘못 만들 여지가 줄어들고, 민감한 컬럼도 처음부터 제외할 수 있습니다.
반드시 넣어야 할 안전장치
사용자가 결과를 믿을 수 있게 만들기
숫자만 보여 주면 신뢰가 쌓이지 않습니다. 생성된 SQL과 함께 "2026년 9월 1일~30일, 출고 확정 기준, 취소 건 제외로 집계했습니다"와 같은 해석을 함께 노출해야 사용자가 전제를 확인할 수 있습니다.
품질은 정기 평가로 관리합니다. 실제 질문과 정답 SQL을 묶은 정답 질의 세트를 100개 안팎으로 만들고, 프롬프트·모델·스키마가 바뀔 때마다 결과값 일치 여부로 다시 채점합니다.
질문이 모호하거나 용어집에 없는 지표라면 무리하게 답하지 않고 되묻거나 담당자에게 넘기는 흐름이 필요합니다. 이렇게 넘어온 질문은 용어집과 예시 질의를 보강하는 재료가 됩니다.
POLYGLOTSOFT가 돕는 방식
Text-to-SQL의 성패는 모델 선택보다 데이터를 얼마나 정확히 이해하고 정리했는지에 달려 있습니다. POLYGLOTSOFT는 ERP·MES·WMS 데이터 구조를 이해하는 팀이 조회 전용 뷰 설계, 업무 용어집 정리, 권한·검증 체계 구성, 정답 질의 세트 기반 평가까지 함께 구축합니다. 데이터 요청 대기열을 줄이고 싶으시다면 POLYGLOTSOFT에 문의해 주시기 바랍니다.