AI가 만든 SQL에서 이름 하나가 틀렸을 때 질의 전체를 다시 생성하던 비용을 줄일 방법이 나왔다. KAIST 김민수 교수팀의 SafeQL은 데이터베이스가 반환한 오류와 실제 스키마를 이용해 잘못된 부분을 찾고, 실행 가능한 후보 가운데 원래 질의와 가장 가까운 수정안을 고른다. BIRD 벤치마크에서는 처음 생성된 SQL의 실행 오류를 최대 87.4% 해결했다.

Text-to-SQL은 “지난해 매출이 가장 많이 늘어난 상품은?” 같은 자연어 질문을 데이터베이스 질의로 바꾸는 기술이다. 문제는 LLM이 존재하지 않는 테이블이나 열 이름을 만들거나, 조인과 함수 또는 검색값을 잘못 쓰는 경우다. 기존 방식은 오류 메시지를 다시 LLM에 보내 SQL 전체를 새로 만들기 때문에 이미 맞은 부분까지 바뀌거나 다른 오류가 생길 수 있다.

SafeQL은 수정 범위를 좁힌다. 연구팀이 설계한 ‘안전 질의 공간’에서 실제로 실행할 수 있는 후보를 만들고, 원본과 가까우면서 성공 가능성이 높은 답부터 탐색한다. 맞지 않는 후보는 일찍 제외한다. PostgreSQL의 parser, binder, type analyzer와 연결해 복잡한 질의에서도 오류 위치를 찾고, 부분 수정으로 해결되지 않을 때만 LLM을 다시 호출한다.

KAIST가 9월 4일 공개한 결과에서 SafeQL은 BIRD 실행 정확도를 수정 전 기준보다 최대 5.8%포인트 높였다. 전체 재생성과 비교한 토큰 사용량은 최대 15.1배 적었고 수정 시간은 최대 29.6배 짧았다. Spider에서는 실행 정확도 91.7%를 기록했으며, 별도 공개 자료에 따르면 토큰과 시간 감소 폭은 각각 최대 96.5배와 34.5배였다.

이 연구는 데이터베이스 분야 학술대회 VLDB에서 공개되며 논문 DOI는 10.14778/3819518.3819545다. 제1저자는 이건호 연구원, 교신저자는 김민수 교수다. 수치는 BIRD와 Spider 벤치마크 결과이므로 기업의 복잡한 권한 체계와 계속 바뀌는 사내 스키마에서 그대로 재현된다고 단정할 수는 없다. 권한 때문에 보이지 않는 열, 회사마다 다른 함수, 오래된 데이터처럼 벤치마크 밖의 변수도 많다. 수정 후보를 실행해 보는 과정 자체가 읽기 전용 환경과 안전 장치를 요구할 수도 있다.

그래도 방향은 실용적이다. 에이전트가 매출·재고·고객 자료를 반복 조회할수록 작은 SQL 오류 하나의 재시도 비용이 누적된다. 여러 단계의 업무 흐름에서는 한 번의 실패가 뒤 작업까지 멈추므로 지연시간 감소의 효과가 더 커진다. SafeQL의 과제는 다양한 데이터베이스 엔진으로 범위를 넓히고, 실행은 되지만 의미가 틀린 질의까지 잡는 것이다. 부분 수리가 실제 운영에서도 정확성을 지킨다면 Text-to-SQL의 비용 구조를 바꿀 수 있다.

#text-to-sql

SafeQL, 생성 SQL 오류 87.4% 부분 수리…기업용 에이전트 토큰 최대 15.1배 절감