모든 Text-to-SQL 벤치마크는 실제 데이터 저장소의 어려움을 다뤄야 한다

• 데이터 웨어하우스의 비정형 질의를 자연어로 처리하면 비개발자의 활용 장벽을 낮출 수 있음

  • 데이터 웨어하우스는 1990년대부터 고객·매출 이력 분석에 쓰였으며, 재고 회전을 개선해 6개월 안에 구축 비용을 회수한다는 사례가 널리 알려졌음

    • 유행이 지난 상품은 할인해 앞쪽에 배치하고 인기 상품은 경쟁사보다 먼저 대량 주문하는 식의 판단을 지원했음

  • 주간 매출 보고서처럼 반복되는 작업도 있지만 상당수 질의는 즉석에서 발생하며, 과거에는 Business Objects, Power BI, Tableau 같은 BI 도구의 그래픽 인터페이스로 비즈니스 사용자가 질의를 구성했음

  • LLM과 agentic AI는 별도 인터페이스 사용법을 익히지 않고 자연어로 대규모 정형 데이터 저장소를 조회할 가능성을 열었고, 공개 벤치마크도 유망한 결과를 제시함

• 공개 벤치마크의 높은 정확도는 실제 기업 데이터 웨어하우스의 난도를 충분히 반영하지 못함

  • Spider 1.0은 80% 이상, Bird-SQL은 90% 이상의 정확도를 기록했지만 네 가지 현실적 문제가 빠져 있음

    • 데이터가 공개 학습 자료에 포함될 수 있는 반면, 실제 데이터 웨어하우스는 강한 기업 접근 통제 뒤에 있어 공개되지 않음

    • 사업 환경, 사업부 인수·매각, 규제 변화로 스키마가 연중 여러 차례 수정되면서 구조가 점차 훼손됨

    • 같은 salary 이름을 가진 열 6개가 순급여·총급여처럼 문서화되지 않은 채 의미가 겹칠 수 있고, 자주 쓰는 질의를 위한 materialized view까지 존재해 정답 SQL 경로가 여러 개로 늘어남

    • MIT의 J-term처럼 조직 고유의 용어나 이름 대신 번호를 쓰는 건물 체계가 포함되며, 실제 질의에는 조인이 하나뿐인 경우가 드물고 흔히 2~3개가 필요함

  • Spider 2.0은 복잡한 질의 문제를 보완해 agentic AI 정확도가 90% 이상이지만, 공개 학습 데이터·스키마 훼손·조직 고유 데이터 문제는 해결하지 못했음

  • 이런 현실적 특성을 제외한 결과는 학술적 관심에는 의미가 있어도 실전 성능을 보여주지는 못한다는 결론임

Beaver Benchmark

• Beaver는 실제 데이터 웨어하우스의 네 가지 난점을 모두 포함하도록 구축됨

  • 연구진은 지난 2년 동안 실제 워크로드에 LLM 기반 Text-to-SQL을 적용했으며, 첫 대상은 CSAIL을 비롯한 MIT 여러 조직이 사용하는 1,400개 이상 테이블 규모의 Oracle 데이터 웨어하우스였음

  • 비즈니스 사용자가 IT 담당자에게 질문하고 필요하면 서로 조건을 확인한 뒤 SQL로 변환하는 실제 흐름을 반영함

    • Oracle 로그에서 실제 SQL을 확보하고 실제 사용자의 도움으로 대응하는 자연어를 작성해 (자연어, gold SQL) 쌍을 만들었음

    • 같은 방법을 다른 데이터 웨어하우스 3개에 적용한 뒤 허가를 받아 질의와 데이터를 익명화·확장해 Beaver 벤치마크로 공개했으며, 세부 구성도 온라인에 게시함

• Beaver에서는 기존 공개 벤치마크와 달리 전통적인 LLM·agentic AI 접근의 정확도가 크게 떨어짐

  • 순수 LLM의 정확도는 0이었고, RAG·프롬프트 엔지니어링·agentic AI를 추가해도 10% 이상에 머물렀으며, 이런 모델의 결과는 Jindal의 연구에서 확인할 수 있음

  • gold SQL의 from 절에 들어갈 특정 테이블과, 테이블이 여러 개일 때 실제 join 절까지 LLM에 제공해야 정확도가 30% 이상으로 올라갔으며 Beaver 리더보드에 결과가 공개돼 있음

  • 이는 공개 벤치마크보다 정확도가 50% 이상 낮은 수준으로, 기술이 유망하다는 평가와 실제로 작동하지 않는다는 판단을 나타냄

• 기존 LLM·agentic AI 기술은 깨끗한 스키마, 단순한 질의, 적은 조직 고유 데이터를 갖춘 환경에서만 좋은 결과를 낼 가능성이 큼

  • 연구진은 실무 비즈니스 애플리케이션에서 성능을 높일 시스템과 아이디어를 찾기 위해 Beaver를 공개했으며, 자체 접근법은 Rubicon 시스템에 담았음

  • 그 조건을 충족하지 못하는 데이터 웨어하우스에는 Rubicon이나 새로운 접근법이 필요하다는 제안임

^{source https://cacm.acm.org/blogcacm/if-you-think-you-can-do-real-world-text-to-sql/}

HN에서는 자연어를 SQL로 바꾸는 능력보다, 기업 데이터의 품질과 의미를 얼마나 안정적으로 정리했는지가 성패를 가른다는 반응이 중심을 이뤘다. 오래된 데이터 웨어하우스에는 같은 이름이지만 뜻이 다른 열, 불분명한 조인 관계, 누적된 스키마 변경이 얽혀 있다. 이런 환경에서는 모델의 SQL 문법 정확도만으로 실전 성능을 설명하기 어렵다는 판단이다.

실무 경험을 공유한 개발자들은 전면 재구축보다 사용 목적에 맞춘 정돈된 데이터 영역을 만드는 방식을 택했다. 명확한 마트와 문서, 관용적인 조인 규칙을 마련하고, 기본 계층과 스키마를 버전별로 관리해 변경 영향을 격리한다. 다른 사례에서는 오래된 데이터베이스를 정비한 뒤 dbt 모델과 YAML, 공통 문서에 업무 지표의 의미와 메타데이터를 담았다. 모델이 혼동할 지점을 줄이는 방향으로 데이터 모델 자체를 설계하자 초기 결과도 가능성을 보였다.

다만 비개발자가 결과를 그대로 사실로 받아들이는 상황에는 경계가 컸다. 필터 하나를 빼먹거나 매출 정의를 잘못 고르고, 모호한 질문을 지나치게 문자 그대로 해석해도 이를 검증할 사람이 없기 때문이다. 같은 지표도 부서와 목적에 따라 정의와 검증 규칙이 달라질 수 있어, 의미 계층을 추가하는 것만으로 문제가 끝나지 않는다. 오류를 찾아 올바른 질의로 복구하는 비용까지 고려해야 한다.

벤치마크 자체에 대한 신뢰도 엇갈렸다. 공개된 평가 기준은 최적화 대상이 되기 쉽고, 기사 속 낮은 정확도가 실제 제품 경험과 맞지 않는다는 지적도 나왔다. 결국 도입 판단에서는 순위표보다 실제 스키마와 질문으로 검증하고, 지표 정의와 조인 규칙을 누가 관리할지, 결과를 검토할 SQL 전문가가 있는지, 잘못된 답의 업무 비용을 감당할 수 있는지를 먼저 확인해야 한다.