Both Ends Count! Just How Good are LLM Agents at "Text-to-Big SQL"?

이 논문은 대규모 데이터 환경에서 기존 Text-to-SQL 평가 지표의 한계를 지적하고, 실행 효율성, 비용, 데이터 규모 영향을 종합적으로 반영하는 새로운 'Text-to-Big SQL' 평가 지표와 LLM 에이전트에 대한 통찰을 제시합니다.

핵심

🍽️ 비유: "레스토랑 주문과 요리사"

이 논문의 상황을 한 가지 비유로 풀어보면 다음과 같습니다.

• 사용자 (고객): "저기, 맛있는 스테이크 한 접시 주세요." (자연어 질문)
• AI 에이전트 (주문 접수원): 고객의 말을 듣고 주방에 전달할 주문서를 작성합니다. (SQL 생성)
• 빅데이터 엔진 (주방/요리사): 주문서를 받아 실제 요리를 해냅니다. (쿼리 실행)
• 기존 평가 기준: "주문서가 메뉴판과 똑같은지?"만 확인했습니다. (정확도만 봄)
• 이 논문의 새로운 시각: "주문서가 메뉴판과 비슷하더라도, 요리사가 그걸로 요리를 하다가 재료를 다 태우거나, 너무 비싼 고기를 낭비하지는 않았는가?"를 봅니다. (비용과 효율성까지 봄)

---

🚨 문제점: "작은 실수가 큰 재앙이 되는 곳"

기존의 AI 평가는 작은 데이터베이스 (소규모 식당) 에서 주로 이루어졌습니다. 거기서는 주문서에 "소금 조금 더"라고 잘못 적어도, 요리사가 다시 한 번 해보면 그만입니다.

하지만 **빅데이터 (거대한 공장형 주방)**에서는 상황이 다릅니다.

1. 실수의 비용이 천문학적입니다: 주문서에 잘못된 재료가 하나라도 들어가면, 수만 톤의 재료를 다 태워버리게 되어 전기세와 재료비가 폭탄처럼 날아갑니다.
2. 시간이 돈입니다: AI 가 주문서를 작성하는 데 10 분 걸리고, 요리가 1 분 걸린다면? 고객은 기다리다 지쳐서 나가버립니다. AI 가 너무 느리면 의미가 없습니다.

논문은 "기존 평가는 **정확성 (주문서와 메뉴가 같은가)**만 보는데, 빅데이터 세상에서는 **비용 (재활용 비용)**과 **속도 (주문서 작성 시간)**가 훨씬 중요하다"고 말합니다.

---

💡 해결책: "양쪽 끝을 모두 세어라 (Both Ends Count!)"

저자들은 새로운 평가 지표인 **'Text-to-Big SQL'**을 제안합니다.

1. 단순한 O/X 가 아닙니다:

   • 기존: "스테이크가 나왔나요? (O)" -> 끝.
   • 새 기준: "스테이크가 나왔나요? (O) + 불필요한 양파가 100 개 더 들어있진 않나요? + 요리하는 데 돈이 너무 많이 들진 않았나요?"를 봅니다.
   • 예시: 필요한 스테이크가 나왔는데, 불필요한 양파가 같이 나왔다면, 고객은 양파만 빼면 되지만 (약간 귀찮음), 빅데이터 시스템은 그 양파를 다 씻고 버리는 데 엄청난 비용을 지불합니다.

2. 새로운 점수표 (메트릭):

   • VES (효율 점수):* 얼마나 정확한지 + 얼마나 빠른지 + 불필요한 데이터 (양파) 를 얼마나 덜 뽑았는지.
   • VCES (비용 효율 점수): 이 주문을 처리하는 데 실제로 돈이 얼마나 들었는지.

---

🔍 실험 결과: "가장 똑똑한 AI 가 가장 비쌀 수도 있다"

저자들은 최신 AI 모델들 (GPT-4o, Claude Opus, Gemini 등) 을 시험해 보았습니다.

• 기존 평가: "정답률 100%!"라고 칭찬받는 AI 가 있었습니다.
• 새로운 평가: "정답은 맞는데, 주문서를 작성하는 데 너무 오래 걸려서 고객이 지루해하고, 불필요한 데이터를 검색해서 비용이 10 배 더 들었다"는 결과가 나왔습니다.
• 반면: 정답률은 95% 였지만, 순식간에 처리하고 비용도 싼 AI 가 실제 비즈니스 환경에서는 더 좋은 평가를 받았습니다.

결론: "완벽한 정답"보다 **"빠르고 저렴한 실용적인 답"**이 빅데이터 세상에서는 더 중요합니다.

---

🌟 요약: 이 논문이 우리에게 주는 교훈

1. AI 는 똑똑해졌지만, '비용'을 모릅니다: AI 가 문장을 잘 만들어낸다고 해서, 그 명령을 실행할 때 돈과 시간이 얼마나 드는지까지 고려하지는 않습니다.
2. 빅데이터는 '작은 실수'도 용납하지 않습니다: 작은 데이터에서는 괜찮은 실수가, 거대한 데이터에서는 엄청난 낭비로 이어집니다.
3. 새로운 기준이 필요합니다: 이제 AI 를 평가할 때는 "정답률"만 보지 말고, "얼마나 빨리, 얼마나 싸게" 결과를 내는지까지 봐야 합니다.

한 줄 요약:

"AI 가 주문서를 잘 쓰는 것만 중요한 게 아니라, 그 주문서를 바탕으로 요리를 할 때 재료를 낭비하지 않고, 빨리, 싸게 해내는지가 진짜 실력입니다."

기술 요약

1. 문제 정의 (Problem Statement)

기존의 Text-to-SQL 연구와 벤치마크는 주로 중소규모의 관계형 데이터베이스를 대상으로 하며, 정확도 (Accuracy) 나 문법적 일치도 (Exact Matching) 와 같은 전통적인 지표에 집중해 왔습니다. 그러나 실제 산업 환경에서는 대규모 데이터 처리 (Big Data) 와 상호작용하는 데이터 분석 워크플로우가 일반화되고 있습니다.

이 논문은 기존 Text-to-SQL 접근 방식이 Big Data 환경 (예: Amazon Athena, Spark SQL) 에서는 다음과 같은 한계를 가진다고 지적합니다:

• 비용과 지연 시간의 증폭: 소규모 데이터셋에서는 사소한 오류 (불필요한 컬럼 포함 등) 가 큰 문제가 되지 않지만, 대규모 데이터셋에서는 잘못된 쿼리 실행이 막대한 컴퓨팅 비용과 지연 시간 (Latency) 을 초래합니다.
• 기존 지표의 부적절성: '0 또는 1'의 이진법적 정확도 지표는 쿼리의 부분적 정확성 (예: 필요한 데이터는 포함되었으나 불필요한 컬럼이 추가된 경우) 을 평가하지 못하며, 쿼리 실행 비용과 에이전트의 추론 오버헤드를 고려하지 않습니다.
• 상호작용의 복잡성: LLM 에이전트가 스키마를 확인하고 쿼리를 검증하는 과정에서 발생하는 에이전트-도구 상호작용의 지연 시간이 전체 성능을 저해할 수 있습니다.

저자들은 이를 "Text-to-Big SQL" 이라는 새로운 개념으로 정의하며, SQL 생성 (Generation) 과 실행 (Execution) 양쪽 끝을 모두 고려한 평가가 필요함을 주장합니다.

2. 방법론 (Methodology)

이 연구는 생산 환경 수준의 LLM 에이전트를 대상으로 한 체계적인 벤치마킹을 수행했습니다.

• 에이전트 아키텍처: ReAct (Reasoning + Acting) 패턴을 기반으로 한 에이전트를 사용했습니다. 에이전트는 Thought(추론), Action(도구 사용), Observation(피드백 해석) 의 사이클을 반복하며, Spark SQL 엔진과 상호작용합니다.
  • 사용된 도구: list_tables(테이블 목록 조회), get_schema(스키마 확인), check_query(쿼리 문법 검증), run_query(쿼리 실행).
  • 제약 조건: 비용 낭비와 무한 루프 방지를 위해 첫 번째 run_query 실행 후 에이전트 작동을 종료하도록 설계했습니다.
• 데이터셋 및 환경:
  • BIRD: 현실적인 데이터베이스 번역 정확도를 평가하는 Text-to-SQL 벤치마크.
  • TPC-H: 대규모 데이터 분석 성능을 측정하는 벤치마크. 데이터 규모 (Scale Factor: 10, 100, 1000) 를 조절하여 확장성을 테스트했습니다.
  • 모델: GPT-4o, GPT-5, Claude Opus 4.5/4.6, Gemini 3 Flash/Pro 등 다양한 최신 Frontier LLM 모델 평가.
  • 인프라: AWS EC2 및 Amazon EMR 클러스터에서 실행.

3. 주요 기여 (Key Contributions)

기존 Text-to-SQL 메트릭의 한계를 극복하기 위해 Text-to-Big SQL을 위한 새로운 평가 지표를 제안했습니다.

1. VES* (Valid Efficiency Score Star):

   • 기존 VES(Valid Efficiency Score) 를 확장하여, 불필요한 컬럼 (Superfluous columns) 을 포함하는 경우의 패널티를 반영합니다.
   • 공식: $VES^* = \frac{1}{N} \sum (1(V_i, \hat{V}_i) \cdot P(S_i, \hat{S}_i) \cdot \frac{T_{gold}}{T_{e2e}})$
   • 여기서 $P$는 컬럼 수준의 정밀도 (Precision) 로, 불필요한 컬럼이 포함되면 점수가 감소하지만, 데이터가 정확하다면 완전히 0 점으로 처리되지 않습니다.
   • $T_{e2e}$는 LLM 에이전트 상호작용, 도구 실행, 쿼리 실행을 포함한 전체 종단간 (End-to-End) 시간을 의미합니다.

2. VCES (Valid Cost-Efficiency Score):

   • 실행 비용 (Token 비용 및 쿼리 실행 비용) 을 고려한 지표입니다.
   • 쿼리 실패로 인한 재시도 비용과 토큰 사용량을 반영하여, 실제 클라우드 환경에서의 비용 효율성을 평가합니다.

3. CVQ (Expected Cost per Valid Query):

   • 성공할 때까지 재시도하는 전략 (Retry-until-success) 하에서 유효한 결과를 얻기 위해 예상되는 비용을 계산합니다.
   • 데이터 규모가 커질수록 정확도 부족으로 인한 비용 손실이 기하급수적으로 증가함을 정량화합니다.

4. 실험 결과 (Results)

• 정확도만으로는 부족함:

  • BIRD 벤치마크에서 많은 모델이 높은 실행 정확도 (Execution Accuracy) 를 보였으나, **VES***와 VCES 지표에서는 큰 차이가 발생했습니다.
  • 예를 들어, Claude Opus 4.6 은 정확도가 100% 였지만, GPT-4o 에 비해 에이전트 추론 및 도구 호출로 인해 실행 시간이 92% 더 길었습니다.
  • GPT-4o 는 속도가 가장 빠르고 VES* 점수가 가장 높았으나, 비용 효율성 (VCES) 측면에서는 Gemini 3 Flash 보다 비쌌습니다.

• 데이터 규모의 영향 (Scale Matters):

  • TPC-H 실험 결과, 데이터 규모 (Scale Factor) 가 커질수록 정확도 차이가 비용에 미치는 영향이 극대화되었습니다.
  • 작은 규모 (SF 10) 에서는 모델 간 비용 차이가 미미했으나, 대규모 (SF 1000) 에서는 정확도가 10% 만 낮아도 (예: Opus 4.5 vs GPT-5.2) 실패한 쿼리로 인한 재실행 비용이 기하급수적으로 증가하여 CVQ 가 크게 차이 났습니다.
  • 기존 Text-to-SQL 지표 (VES) 는 데이터 규모에 따른 비용 증폭을 포착하지 못했으나, 제안된 CVQ는 이를 명확히 보여주었습니다.

• 에이전트 단계별 분석:

  • 대부분의 모델에서 check_query(문법 검증) 단계가 전체 실행 시간의 상당 부분을 차지했습니다.
  • 모델마다 list_tables와 run_query 단계의 시간 분포가 달라, 에이전트 파이프라인의 각 단계에 맞는 최적의 모델을 조합 (Ensemble) 하는 것이 가능함을 시사했습니다.

• 오류 분석:

  • 오류 중 약 39% 가 '출력 형식 (Output Format)' 관련이었으며, 그중 93% 는 불필요한 컬럼 추가였습니다. 이는 기존 메트릭에서는 '오류'로 처리되지만, 실제 Big Data 환경에서는 재실행 없이도 유용한 결과일 수 있음을 보여줍니다.

5. 의의 및 결론 (Significance & Conclusion)

• 패러다임 전환: Text-to-SQL 평가가 단순한 '문법/정확도'에서 **'비용, 지연 시간, 데이터 규모'**를 종합적으로 고려하는 'Text-to-Big SQL' 평가로 전환되어야 함을 주장합니다.
• 실무적 통찰:
  • 속도 vs 비용 트레이드오프: 저지연이 중요한 상호작용 분석에는 VES*가 높은 모델을, 비용 효율성이 중요한 배치 처리에는 VCES 가 높은 모델을 선택해야 함을 보여줍니다.
  • 확장성 인식: 데이터 규모가 커질수록 작은 정확도 차이가 막대한 비용 손실로 이어지므로, 대규모 데이터 환경에서는 높은 정확도와 효율적인 에이전트 설계가 필수적입니다.
• 미래 연구 방향:
  • 에이전트 내부 단계별 모델 최적화 (Model Ensembling).
  • 물리적 실행 계획 (Physical Plan) 기반의 쿼리 최적화 및 비용 예측.
  • UDF(User-Defined Functions) 지원 및 근사 쿼리 (Approximate Query) 처리를 위한 Text-to-Big SQL 프레임워크 개발 필요성을 제시합니다.

이 논문은 LLM 기반 데이터 분석 시스템이 실제 Big Data 환경에서 어떻게 평가되고 최적화되어야 하는지에 대한 새로운 기준을 제시하며, 향후 연구 방향을 제시하는 중요한 이정표가 됩니다.