텍스트-투-SQL

자연어 질문을 데이터베이스 구조에 맞는 SQL로 바꿔 주는 기술로, SQL을 모르는 사람도 미리 만든 대시보드에 없는 새 질문을 직접 조회할 때 쓴다. 다만 틀린 SQL이 나올 수 있어 실행 전 검증이 필요하다.

팀원이 직접 조회할 수 있게 되면 데이터 팀은 단순한 조회 요청을 덜 받게 된다.

스키마를 함께 줘야 맞는 SQL이 나온다

LLM은 내 데이터베이스에 어떤 테이블이 있는지 모른다. 그래서 테이블명·컬럼명, 그리고 테이블끼리 어떤 키로 연결되는지를 프롬프트에 함께 넣는 것이 핵심이다. 이런 맥락이 충분하면 조인과 집계가 섞인 꽤 복잡한 쿼리도 정확하게 만든다.

테이블이 너무 많아서 프롬프트에 다 넣을 수 없으면 질문과 관련 있는 테이블만 골라서 넣는다. 컬럼 이름이 amt, st_cd처럼 알아보기 어려우면 짧은 설명만 붙여도 결과가 눈에 띄게 좋아진다.

실행하기 전에 반드시 검증한다

생성된 SQL에는 없는 테이블, 잘못된 조건, 의도하지 않은 수정 명령이 섞여 있을 수 있다. 실행하기 전에 sqlglot 같은 라이브러리로 SQL을 파싱해서 구조부터 확인하는 패턴이 안전하다.

오류 없이 틀린 답이 가장 위험하다

문법 오류는 바로 드러난다. 하지만 실행은 되는데 뜻이 틀린 SQL은 그럴듯한 숫자를 내놓아서 알아채기 어렵다. 예를 들어 "매출"에 취소 건이 빠지는지, "지난달"이 어느 시간대 기준인지는 회사마다 다르다.

이런 용어의 정의를 프롬프트에 적어 두면 실수가 줄어든다. 탐색용 조회나 한 번만 할 질문에는 잘 맞는다. 보고용 공식 지표는 검증된 대시보드나 분석가의 확인을 거치고, Text-to-SQL은 보조 도구로 쓰는 편이 안전하다.

사내 데이터 질문 창구로 가장 많이 쓴다

가장 흔한 건 SQL을 모르는 팀원이 자연어로 데이터를 묻는 창구로 두는 방식이다. 분석가에게는 처음부터 쓰는 대신 초안을 받아 고치는 도구가 된다.