SQL 쿼리는 제한된 복잡도, 템플릿으로 충분히 커버 가능

본 논문은 “LLM이 데이터베이스 접근에 과연 필요가 한가?”라는 질문을 출발점으로, 실제 데이터베이스와 질의의 복잡도 특성을 정량적으로 분석한다. 연구자는 376개의 데이터베이스 스키마와 20,489개의 자연어 질문(NLQ)‑SQL 쌍을 수집했으며, 이때 사용된 데이터는 Spider 1·2, Bird, KaggleDBQA, drawSQL 등 다양한 공개 벤치마크와 오픈소스 저장소를 포함한다. drawSQL에서는 Claude‑Sonnet‑4.6을 활용해 난이도(easy, medium, hard)별 NLQ‑SQL 페어를 자동 생성하고, 인간 검증을 통해 정확성을 확보하였다. 모든 SQL은 SQLite 방언으로 통일해 비교 가능성을 높였다. 복잡도 측정은 6가지 프록시(테이블 수, JOIN 수, 서브쿼리 수, 최대 중첩 깊이, 집계·GROUP BY 수, 고급 기능 수)로 정의하였다. 통계 결과, 평균 테이블 수는 1.73, 평균 JOIN 수는 0.73에 불과했으며, 최대값도 각각 27개와 26개에 머물렀다. 서브쿼리와 고급 기능(윈도우 함수, FILTER, CTE 등)의 평균 등장 횟수는 0.11과 0.06으로 매우 낮았다. 이동 평균 그래프와 스피어만 상관계수 분석을 통해 데이터베이스의 테이블 수가 증가해도 복잡도 프록시가 지속적으로 상승하지 않으며, 오히려 피크 이후 완만하거나 감소하는 경향을 보였다. 이는 실무에서 사용자가 요구하는 질의가 자연스럽게 제한된 복잡도 범위에 머무른다는 것을 의미한다. 다음으로, 질의를 템플릿화하는 두 단계(하드 템플릿, 소프트 템플릿)를 도입했다. 하드 템플릿은 테이블·컬럼·별칭 등을 개별 플레이스홀더로 유지해 구조적 정밀성을 보존했으며, 소프트 템플릿은 이러한 식별자를 모두 동일 변수로 통합해 더 넓은 범위의 유사 질의를 하나로 묶었다. 템플릿 추출 규칙은 부록에 상세히 제시되었으며, 예시를 통해 변환 과정을 명확히 보여준다. 템플릿 빈도 분석 결과, 하드와 소프트 템플릿 모두 긴 꼬리 형태의 파워‑로우‑유사 분포를 보였다. 부트스트랩 적합 검정(p≈0)으로 엄밀히는 파워‑로우가 아니지만, 로그‑로그 스케일에서 거의 직선에 가까운 경향을 나타냈다. 특히 소프트 템플릿에서는 전체 질의의 70%가 전체 템플릿의 13%에 해당하는 600여 개 템플릿으로 커버되었으며, 가장 빈번한 140개의 템플릿만으로 전체 질의의 50%를 설명할 수 있었다. 가장 흔한 템플릿은 “SELECT variable FROM variable WHERE variable = string”와 “SELECT COUNT(*) FROM variable” 등 단순 선택·집계 형태였다. 이는 복잡도가 낮은 템플릿이 실제 사용자 질의에서 높은 빈도로 사용된다는 점을 시사한다. 논문은 이러한 결과를 바탕으로 LLM 기반 코드 생성이 반드시 필요한가에 대한 논의를 전개한다. LLM은 토큰당 비용이 높고, 응답 변동성이 존재한다는 점에서 기업 환경에서의 비용·안전성 문제가 있다. 반면, 제한된 템플릿 집합은 사전 검증·감사 가능성이 높고, 실행 계획 최적화와 보안 정책 적용이 용이하다. 템플릿 기반 시스템은 질의가 제한된 복잡도와 높은 반복성을 보이는 실제 환경에 적합하며, LLM을 보조적인 역할(예: 템플릿 선택·파라미터 채우기)로 활용하는 것이 효율적일 수 있다. 연구의 한계로는 SQL이 비정규화된 형태로 표현될 수 있어 동일 결과를 내는 서로 다른 구문이 존재한다는 점을 들었다. 템플릿 정규화와 동형성 검증이 필요하며, 현재는 가장 “원시적인” 형태의 질의를 분석 대상으로 삼았다. 또한, 현재 분석은 SQLite 방언에 국한되어 있어 다른 DBMS(예: PostgreSQL, MySQL)에서의 적용 가능성을 추가 연구가 필요하다. 결론적으로, 실무 데이터베이스 접근에서 요구되는 질의는 복잡도 상한이 존재하고, 소수의 템플릿으로 대부분을 커버할 수 있다. 따라서 LLM 기반 전면 코드 생성보다 템플릿 기반 접근이 비용·안전성 측면에서 더 효율적이며, 향후 데이터베이스 인터페이스 설계에 있어 템플릿 중심 아키텍처가 유망한 방향임을 제시한다.