AI가 좋은 SQL을 작성하게 만들기: Text-To-SQL 테크닉

 (cloud.google.com)
4P by GN⁺ | ★ favorite | 댓글 1개
  • Gemini 기반의 Text-to-SQL 기능은 Google Cloud 전반에서 개발자와 비기술 사용자의 생산성을 높이는 데 활용됨
  • 실제 환경에서는 비즈니스 맥락 부족, 사용자 의도 해석 어려움, SQL 방언 차이로 인해 정확한 SQL 생성이 어려움
  • Google은 이를 해결하기 위해 지능형 데이터 검색, 문맥 기반 학습, 의미 계층화 기법 등을 도입함
  • 모델 자체의 한계는 다중 생성 후 최적 선택(self-consistency), 검증 후 재프롬프트, SQL 방언별 학습 등으로 극복함
  • 평가와 개선 측정에는 자체 벤치마크와 LLM을 심판으로 활용하는 기법을 포함해 실환경 적용 가능성을 높이고 있음

Techniques for improving text-to-SQL

텍스트에서 SQL로의 전환: Google Cloud의 현황

  • 조직은 신속하고 정확한 데이터 인사이트를 위해 SQL을 활용함
  • Gemini는 자연어로부터 직접 SQL을 생성하는 text-to-SQL 기능을 제공
  • 이 기능은 개발자뿐 아니라 비기술 사용자에게도 유용함
  • 현재 BigQuery Studio, Cloud SQL Studio, AlloyDB Studio, Vertex AI 등에서 이 기능을 제공

Text-to-SQL 기술의 주요 과제

1. 비즈니스 맥락 제공의 어려움

  • 정확한 SQL 작성을 위해선 LLM에게 데이터베이스 구조, 컬럼 의미, 실제 데이터 내용 등과 같은 충분한 컨텍스트 제공이 필요
  • 컨텍스트는 명시적 정보(스키마, 컬럼 정보 등)와 암묵적 정보(특정 데이터의 비즈니스 의미 등) 모두 포함
  • 데이터베이스 구조나 데이터셋의 변형, 스키마의 변화 등에 맞춰 LLM을 계속적으로 훈련(fine-tuning)하는 방식은 현실적으로 비용이 높음
  • 비즈니스 지식이나 의미 정보가 제대로 정리되어 있지 않고, 훈련 데이터로 전환하는 것 역시 어려움이 존재
  • 예시: DBA가 pcat_extension 테이블의 cat_id2 = 'Footwear'의 의미를 모르면 신발 판매 조회 SQL도 작성 불가함 — LLM도 동일하게 컨텍스트 부족시 정확하지 않은 질의 생성 위험 있음

2. 사용자 의도 해석 문제

  • 자연어 질의는 SQL에 비해 명확성 부족이 흔함
  • 실제 데이터 분석가나 엔지니어는 질문이 불분명할 경우 추가 질문을 통해 명확히 할 수 있지만, LLM은 주어진 질문에 바로 답을 생성하려는 경향으로 인해 잘못된 정보(hallucination) 위험이 있음
  • “가장 많이 팔린 신발은?” 같은 질문에서 ‘가장 많이 팔린’의 기준(주문 수, 매출액 등)이나 결과 수 등에 대한 세부 기준이 모호함
  • 기술적 역량이 있는 사용자는 대략적 SQL을 시작점으로 삼을 수 있지만, 비전문가는 정확히 동작하는 SQL이 더 중요함
  • 효과적으로 작동하기 위해선 LLM이 후속 질문, 추론 설명, 유저 가이드 기능을 지원해야 사용자의 의도를 명확히 파악 가능함

3. LLM의 생성 한계

  • LLM은 문서 요약, 정보 추출 등에는 강점 있지만, 정확한 SQL 문법이나 덜 쓰이는 SQL 기능에 대해선 취약점 있음
  • SQL 방언별로 문법이 다르며, 사소한 차이도 높은 정확성을 요함
  • 예: BigQuery에서는 EXTRACT(MONTH FROM timestamp_column)을 사용하지만, MySQL에선 MONTH(timestamp_column)을 써야 함
  • 복잡한 명세 준수에 꾸준히 맞춰 SQL을 생성하는 것이 LLM에는 쉽지 않은 과제임

Google Cloud의 Text-to-SQL 향상 기법

문제: 스키마 및 비즈니스 맥락

  • 의미 기반 검색 및 랭킹
  • 맥락 내 학습
  • 데이터 샘플링 및 연결
  • 의미 계층 구축
  • 사용 패턴 및 히스토리 분석

문제: 사용자 의도 해석

  • LLM을 통한 명확화
  • 개체 식별, 관련 정보 확인 후 적절한 후속 질문 유도

문제: LLM 한계 극복

  • Self-consistency로 다중 쿼리 생성 후 최적 선택
  • 유효성 검증 및 리프롬프트
  • SQL 방언 예시 포함한 맥락 학습
  • 모델 파인튜닝

주요 기술 적용 예시

SQL-aware 모델

  • Gemini는 고품질 SQL 생성을 위해 다양한 파인튜닝 버전 사용
  • SQL 방언별 정확도 확보를 위해 모델 버전 혼합 및 맞춤형 조정 수행

사용자 질문 명확화 (Disambiguation)

  • 질문이 모호할 경우 명확화 질문 생성
  • 예: "가장 잘 팔리는 신발?" → “주문 수 기준인가요, 매출 기준인가요?”로 유도

의미 기반 검색 및 맥락 구축

  • 다단계 의미 매칭 기반 벡터 검색으로 관련 테이블, 컬럼 식별
  • 유저 쿼리 기록, 비즈니스 규칙 예시 등을 포함해 프롬프트 구성
  • 긴 컨텍스트 윈도우 지원으로 대규모 스키마 대응 가능

검증 및 재생성

  • LLM 생성 쿼리의 파싱, Dry-run 등으로 명시적 오류 탐지
  • 오류가 감지되면 재프롬프트로 수정 유도

Self-consistency

  • 한 쿼리 대신 다양한 방식으로 다중 쿼리 생성
  • 여러 모델에서 동일한 쿼리를 추천할 경우 정확도 향상

평가 및 성능 측정

  • 기존 벤치마크(BIRD-bench 등)는 유용하지만 실제 스키마 반영에 한계 존재
  • Google은 자체 합성 벤치마크 세트를 구축

평가 전략

  • SQL 방언과 엔진별 기능 포괄: 쿼리 외 DDL, DML, 관리 작업까지 포함
  • 평가지표: 사용자 반응, 오프라인 지표, LLM-as-a-judge
  • 지속적 평가: 새로운 모델, 프롬프트 기술의 유효성 신속 확인 가능

마무리

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 텍스트에서 SQL로의 전환의 궁극적인 목표에 대한 고민이 있음, 데이터 분석가의 도우미를 만드는 것인지, 아니면 분석가를 거치지 않고 비즈니스 인사이트를 얻는 것인지가 목적임, 만약 두 번째라면 아무리 고도화되어도 비전문가가 SQL의 정확성과 충분함을 판단하는 것이 불가능한 문제임, "왜 어제 전자상거래 거래가 80%에 머물렀는가?", "고객 획득 비용이 왜 오르는가?", "뉴욕 캠페인이 샌프란과 비교해 왜 더 안 좋았는가?"와 같은 질문은 text2sql의 범주를 벗어나는 질문임

    • 실제로는 두 번째 목적에 가깝다고 보지만, 결과물은 기대에 미치지 못함, 비즈니스에서는 보고서를 마지막에 변경하고 싶어하지만 분석가 부족으로 원하는 정보를 적시에 얻지 못함, "무한 속도"로 해결하려 하지만, 실제로 문제는 메트릭에 대해 충분히 고민하지 않는 데서 발생함, 데이터가 복잡하고 비즈니스 지식이 외부에 암묵적으로 저장되어 있으며 데이터 인프라가 부족해서 분석에 시간이 오래 걸림, 똑똑한 분석 리더들은 AI 열풍을 이용해 기본 인프라에 투자함

    • 위의 질문들은 애초에 SQL로 풀 수 있는 문제가 아니라고 봄, SQL은 주로 "무엇(what)"에 대한 답변을 제공하는데, "왜(why)"에 답을 하지는 않음, 텍스트2SQL의 목표는 분석가가 "무엇"을 빠르게 해내도록 시간을 줄이고, 그렇게 해서 "왜"에 집중하도록 돕는 것임

    • 맞는 말이지만, 내 생각에는 자연어 텍스트가 LLM 시스템의 보편적 입력이 될 수 있다고 생각함, text2sql은 더 복잡한 질문의 답을 구성하는 정보 검색의 기반 역할을 할 수 있음, 단기적으로는 업무 보조 기능이지만 장기적으로는 자동화, 결과 비교, 더 큰 워크플로우로 통합하는 기초를 쌓는 게 목표임, 이런 질문에 답하는 기반 마련이 핵심임, 아직 할 일이 많음

    • 어떤 알고리즘도 사람이 할 수 있다면 만들고 테스트할 수 있음, 10명의 분석가가 있다면 데이터베이스와 비즈니스에 대한 이해도, 실력이 모두 다름, 자동화는 최소한의 실력과 지식을 보장하는 표준을 제공함, 새로운 분석가도 바로 더 나은 성과를 냄, 시스템을 전문가와 협력해 개발하면서 테스트하고, AI가 트레이드오프, 버그, 기대 결과와 비교해 해석하도록 하는 것이 유용한 목표임, 통찰력이나 ‘테이스트’는 자동화하기 어렵지만 도메인 전문가가 잘 설계된 자동화와 합리적 결과의 감각만 있다면 아주 멀리 갈 수 있음, 완벽하진 않지만 이런 것들이 내 목표임

  • OpenAI 4o 모델을 사용해 본 경험 공유, 비즈니스 지침, 업계 용어, 테이블과 외래키 설명을 함께 프롬프트에 전달함, 그러면 복잡한 조인 쿼리도 생성하고 결과를 반환함, SQL을 모르는 사용자를 위한 결과 제공이 목적이었지만 SQL 자체도 참고로 같이 보여줌

  • AI가 완벽한 SQL을 생성할 필요는 없음, 내 경우에는 출력물이 코드로 검증이 되더라도 미세한 의미 차이의 위험 때문에 복사해서 쓰진 않음, 대신 AI가 접근법을 제시해주면 그걸 참고해 직접 SQL을 처음부터 작성함

  • Google AI Studio의 최신 Gemini를 사용해 본 경험, 정말 놀랄 정도로 인상적이고 혁신적임, Claude와 ChatGPT의 코딩 결과는 마치 다른 세기에서 온 것처럼 느껴짐, 불과 한 달 전만 해도 Claude가 굉장하다고 생각했는데 지금은 Google Gemini 없이 어떻게 계속 코딩을 할 수 있을지 모르겠음, Gemini AI Studio는 프로그래밍에서 거대한 도약임

    • 더 많은 사람들이 아직 이 변화를 인식하지 못해 놀라움, Claude도 작은 작업은 잘 처리하지만 복잡한 문제로 발전하면 Gemini가 월등히 앞서감, 컨텍스트 핸들링 능력이 특히 인상적임, 나는 코딩 에이전트로 사용할 뿐만 아니라 85,000단어짜리 원고에 대한 베타 리딩에도 Gemini를 쓰고 있고, 전문가 수준의 피드백 리포트를 거의 실시간으로 받음

    • 이번 주에 무료 Gemini Pro에서 추론 모드를 비활성화한 것 같다는 느낌이 듦, 코드 작성 직전에 멈추거나 지나치게 일반화시키지 않도록 하면 상당히 유용함, 다만 Gemini는 코드를 과하게 작성하는 경향이 있음, 내가 주로 이용하는 방식은 코드 구현에 얽매이지 않고 Gemini를 통해 설계적 탐구에 활용하는 것임, Stripe로 구독 서비스를 만드는 사례처럼 내 기술 스택과 사례에 맞춘 기존 데이터를 맥락에 맞게 받아보면서 단 한 줄의 코드를 쓰기 전에도 설계 방향을 바꿀 수 있었음

  • 답은 “시맨틱 레이어(semantic layer) 사용”임, 올바른 맥락 전달에 가장 효과적이고 사람이 직접 개입할 최적의 지점임, 사람이 모든 핵심 지표를 명확히 정의해두면 LLM이 그걸 언제든 활용할 수 있음, 예를 들어 MAU를 정의해두면 LLM이 그 정의를 기준으로 쿼리를 생성함, SQL 대신 JSON으로 쿼리를 쓰면 LLM이 훨씬 일관적으로 결과를 냄, 우리는 cube를 사용하는데, 최고의 오픈소스 시맨틱 레이어임, 네이버에 닫힌 소스 옵션들도 있음, 과거 내 회사가 관련 블로그도 썼었는데 지금은 소유 회사가 호스팅을 중단함

    • “쿼리를 SQL 대신 JSON으로 쓸 수 있다”가 장점이라는 주장에는 동의하기 어려움, 도저히 받아들일 수 없음

  • 실제 업무에서 AI를 써서 SQL을 만들면 위험함, SQL을 모르는 사람이 잘못된 쿼리를 써서 서버에 심각한 영향을 줄 수 있음, 우리 팀에서 데이터베이스는 대다수 개발자 기준 크지만 정말 거대하지는 않음, 가끔 최적화된 쿼리를 더욱 개선해달라고 AI에 요청해도 AI가 더 나은 답을 준 적이 없음, 때론 AI가 헛소리를 하거나 실제로는 쓸모없는 제안을 함, 마치 멍청한 앵무새가 예전에 들은 이야기를 반복하는 느낌임

    • 경험상 프로그래밍을 잘 모르는 사람은 AI가 아니더라도 일단 해보고 일이 망가지면 남 탓을 함, AI는 그저 이런 사고의 빈도를 늘려줄 뿐임

  • AI의 텍스트-정규표현식 변환 기능이 있으면 정말 편리할 거란 생각임

    • 이 의견을 자주 보는데 솔직히 놀람, 사람들은 정규표현식을 정말 모르는 건지 궁금함, 정규표현식은 엄청나게 널리 쓰이고 학습 자료도 많고 진입 장벽도 낮음, 90%의 용도는 아주 간단하고 결과적으로 AI에 설명하느니 직접 쓰는 게 더 빠름

  • 내가 써봤던 모든 AI 도구 중 가장 실망스러운 게 BigQuery에 내장된 Gemini임, 컬럼 명도 명확하고 설명도 잘 달았는데, 문제 해결에 전혀 근접하지 못함

    • 내가 지금까지 쿼리를 가장 많이 작성한 언어가 SQL임, AI에게 쿼리를 써달라고 해도 내가 직접 작성했을 때보다 결과 다듬는 데 훨씬 더 시간이 오래 걸림, 부차적으로, SQL을 훨씬 더 빠르게 쓸 수 있게 해주는 기능 하나가 있다면 좋겠음, 우리 회사의 DSL에는 외래키 기준으로 자동 조인하는 연산자가 있어서 너무 편리함, SQL을 작성할 때 가장 귀찮은 것은 10개, 20개 넘는 조인문을 일일이 써야 하는 부분임, 다른 점은 그에 비해 그리 어렵지 않음

    • 경험상 명확한 제약 조건, 외래키가 잘 잡혀 있으면 거의 모든 게 해결됨, 테이블마다 명확한 제약 조건이 있어야 AI가 모든 연결 구조를 정확하게 파악할 수 있음, SQL은 아주 정확한 명세가 있지만, 그만큼 제약과 외래키가 잘 정의되어 있지 않으면 AI가 답을 정확히 내줄 수 없음

  • 모든 파운데이션 모델에서 꽤 간단해진 상태임, 테이블 스키마에 코멘트만 잘 달려 있으면 쿼리 생성 요청이 간단함

    • smolagents 라이브러리로 모델 주변 스캐폴딩 만들어주면 꽤 편리함, text2sql은 데모로는 단순해 보여도 실제로 복잡한 실제 케이스에서 이걸 적용하는 건 매우 어렵다는 글도 있음

    • Step 1: 스키마에 수천 개 테이블이 있고 주석이 거의 없음, Step 2...

    • 정말 그렇다고 봄, 이제는 별로 마법이 없음, 테이블 생성 DDL은 테이블의 정확한 설명이라 거의 더 필요 없는 게 사실임, 필요한 쿼리만 자세히 설명하면 웬만한 LLM이 쉽게 쿼리를 생성함

  • "Show HN: We open sourced our entire text-to-SQL product" (2024) 글에서 언급된 자료로 awesome-Text2SQL과 Awesome-code-llm > Benchmarks > Text to SQL 등의 훌륭한 레퍼런스가 있음

답변달기