“SQL을 몰라도 데이터에 직접 질문할 수 있게 해주세요.”
데이터 조직이라면 한 번쯤 받아본 요청일 것입니다. 자연어 질문을 SQL로 바꿔 실행하고 결과를 설명해 주는 것을 NL2SQL(Text2SQL)이라고 하는데, LLM 등장 이후 가장 수요가 많은 기업용 AI 유스케이스 중 하나가 되었습니다.
구글 클라우드(GCP)에서 NL2SQL 에이전트를 도입하는 방법은 하나가 아닙니다. 완제품을 그대로 쓰는 방법부터 직접 만드는 방법까지 4가지 선택지가 있고, 각각 대상 사용자와 통제 수준이 다릅니다. 이 글에서는 4가지 방법의 특징과 장단점, 그리고 선택 기준을 정리합니다.
시작 전에 — NL2SQL이 어려운 진짜 이유
방법을 비교하기 전에 이것부터 짚어야 합니다. NL2SQL의 난이도는 SQL 문법이 아니라 컨텍스트에서 나옵니다.
- “지난달 매출”에서 매출은 어느 테이블의 어느 컬럼인가? 환불은 빼는가?
- 테이블이 3,000개인데 LLM에게 어떤 스키마를 보여줄 것인가?
- 생성된 SQL이 문법은 맞지만 의미가 틀렸다면 누가 어떻게 검증하는가?
4가지 방법의 차이는 결국 “이 문제들을 누가 해결해 주는가(Google인가, 나인가)”의 차이입니다.
방법 1 — BigQuery Agent: 콘솔 안에서 바로 쓰기
무엇인가.
BigQuery Studio에 내장된 에이전트 기능입니다. 데이터 캔버스나 SQL 에디터에서 자연어로 질문하면 Gemini가 SQL을 생성·설명·수정해 줍니다. 별도 구축 없이 BigQuery를 쓰고 있다면 바로 사용할 수 있습니다.
장점
- 설정이 거의 필요 없습니다. 가장 빠르게 시작하는 방법입니다.
- 콘솔에 통합되어 있어 생성된 SQL을 바로 확인·수정·실행할 수 있습니다.
- 스키마 컨텍스트를 BigQuery가 자동으로 활용합니다.
단점
- BigQuery 콘솔에 들어올 수 있는 사람만 쓸 수 있습니다. 결국 데이터 실무자용 생산성 도구이지, 현업에게 열어주는 셀프서비스가 아닙니다.
- 사내 앱이나 챗봇에 임베드할 수 없습니다.
- 생성된 SQL의 의미 검증은 전적으로 사용자 몫입니다.
한 줄 요약: 분석가와 데이터 엔지니어의 SQL 작성 속도를 높이는 도구입니다.
방법 2 — Conversational Analytics API: 내 앱에 임베드하기
무엇인가.
개발자용 API입니다(Gemini Data Analytics API). BigQuery 테이블이나 Looker 익스플로어를 데이터 소스로 하는 데이터 에이전트를 정의하고, 시스템 지침(용어 정의, 지표 규칙, few-shot 예시 등)을 YAML로 등록해 두면, 멀티턴 대화로 질문 → SQL 생성 → 실행 → 요약·차트까지 API 응답으로 받을 수 있습니다. 사내 포털, 슬랙 봇, 고객용 대시보드 등 원하는 곳에 임베드합니다.
장점
- NL2SQL 파이프라인(스키마 해석, SQL 생성, 실행, 시각화)을 Google이 관리합니다. 직접 프롬프트 엔지니어링을 하지 않아도 됩니다.
- 시스템 지침으로 우리 회사의 용어와 지표 정의를 주입할 수 있어 순수 프롬프트 방식보다 정확도가 좋습니다.
- Looker를 데이터 소스로 쓰면 시맨틱 레이어(LookML)의 지표 정의를 그대로 타므로 “매출이 뭐냐” 문제가 구조적으로 해결됩니다.
- UI를 우리가 만들므로 사용자 경험을 완전히 통제할 수 있습니다.
단점
- NL2SQL 코어 로직(모델 선택, 프롬프트, 검증 루프)은 블랙박스에 가깝습니다. 정확도가 아쉬운 케이스를 만나면 시스템 지침 튜닝 외에 손 쓸 방법이 제한적입니다.
- 프론트엔드와 권한 처리는 직접 개발해야 합니다.
한 줄 요약: NL2SQL 엔진은 빌려 쓰고, 제품 경험만 직접 만들고 싶을 때 가장 균형 잡힌 선택입니다.
방법 3 — Gemini Enterprise: 노코드로 전사 배포하기
무엇인가.
지난 글에서 다룬 기업용 AI 플랫폼(SaaS)입니다. BigQuery를 데이터 소스로 연결하면 전 직원이 챗 인터페이스에서 데이터에 질문할 수 있습니다. 내부적으로는 Conversational Analytics의 데이터 에이전트가 동작하는 구조입니다.
장점
- 가장 빠른 전사 배포. 개발 없이 커넥터 연결과 권한 설정만으로 현업에게 열어줄 수 있습니다.
- 문서 검색, 사내 지식 Q&A 등 다른 에이전트 기능과 한 인터페이스에서 함께 제공됩니다.
- 좌석 기반 과금이라 비용 예측이 쉽습니다.
단점
- 커스터마이징 여지가 가장 적습니다. 지표 정의 주입, 검증 로직 추가, UI 변경 모두 제한적입니다.
- 모델과 처리 위치를 선택할 수 없습니다. 지난 글에서 정리했듯 소버린티 요건이 있는 금융권·국가핵심기술 기업의 규제 데이터에는 쓸 수 없습니다.
- 정확도가 아쉬워도 튜닝 수단이 사실상 없습니다.
한 줄 요약: 비규제 데이터의 전사 셀프서비스 분석을 가장 싸고 빠르게 여는 방법입니다.
방법 4 — Agent Platform으로 직접 만들기
무엇인가.
Gemini Enterprise의 에이전트 플랫폼(ADK 기반 개발 + Agent Engine 배포)으로 NL2SQL 에이전트를 직접 개발하는 방법입니다. 스키마 검색(RAG), few-shot 예시 선택, SQL 생성, dry-run 검증, 실패 시 재생성 루프까지 전부 우리가 설계합니다. 완성한 에이전트는 Gemini Enterprise에 등록해 챗 인터페이스로 노출할 수도 있고, 독립 API로 서비스할 수도 있습니다.
장점
- 모든 것을 통제합니다. 모델 버전, 프롬프트, 스키마 컨텍스트 전략, 검증 로직, 오류 처리 — 정확도를 끌어올릴 수 있는 모든 레버가 우리 손에 있습니다.
- BigQuery dry-run으로 SQL을 실행 전에 검증하고, 실패하면 오류 메시지를 넣어 재생성하는 자가 수정 루프를 넣을 수 있습니다. 프로덕션급 정확도는 대부분 여기서 나옵니다.
- 행 수준 권한, 감사 로그, 쿼리 비용 가드레일 같은 거버넌스 요건을 원하는 대로 구현할 수 있습니다.
- Vertex AI regional endpoint를 직접 선택하므로 처리 위치를 고정할 수 있습니다. 소버린티 요건이 있는 조직이 선택할 수 있는 사실상 유일한 방법입니다.
단점
- 개발·운영 비용이 가장 큽니다. NL2SQL 품질에 대한 책임도 전부 우리가 집니다.
- 에이전트 평가 체계(질문-정답 SQL 셋, 회귀 테스트)를 함께 만들지 않으면 품질 관리가 불가능합니다. 만들 것이 에이전트 하나가 아니라는 뜻입니다.
한 줄 요약: 정확도·거버넌스·소버린티가 크리티컬한 워크로드를 위한 방법입니다.
한눈에 비교
| 구분 | 1. BigQuery Agent | 2. Conversational Analytics API | 3. Gemini Enterprise | 4. 직접 개발 (Agent Platform) |
|---|---|---|---|---|
| 대상 사용자 | 데이터 실무자 | 우리 서비스의 사용자 | 전 직원 (현업) | 요건에 따라 자유 |
| 개발 필요량 | 없음 | 중간 (임베드 개발) | 없음 | 큼 (에이전트 전체) |
| 앱 임베드 | 불가 | 가능 | 불가 (제공 UI 사용) | 가능 |
| 지표 정의 주입 | 제한적 | 시스템 지침·Looker | 제한적 | 자유 |
| 정확도 튜닝 | 불가 | 제한적 | 불가 | 자유 (검증 루프 포함) |
| 처리 위치 통제 (소버린티) | 리전 종속 | 제한적 | 불가 | 가능 (regional endpoint) |
| 시작 속도 | 즉시 | 수 주 | 수 일 | 수 개월 |
선택 가이드
시나리오별로 매핑하면 이렇습니다.
- 분석가 생산성이 목적 → 방법 1. 이미 있는 기능이니 그냥 켜세요.
- 자사 서비스·사내 포털에 분석 챗봇 임베드 → 방법 2. 엔진을 빌려 쓰고 경험에 집중하세요. Looker가 있다면 반드시 함께 쓰세요.
- 비규제 데이터의 전사 셀프서비스 → 방법 3. 단, 정확도 튜닝이 안 되므로 중요 의사결정용 지표는 대시보드로 이원화하세요.
- 금융권·규제 데이터, 또는 정확도가 비즈니스 크리티컬 → 방법 4. 처리 위치 통제와 검증 루프가 필요하다면 다른 선택지가 없습니다.
그리고 어떤 방법을 고르든 공통으로 적용되는 진실이 하나 있습니다. NL2SQL의 정확도 상한선은 모델이 아니라 메타데이터 품질이 결정합니다. 테이블·컬럼 설명, 지표 정의, 용어 사전이 없으면 4번 방법으로도 좋은 결과를 얻을 수 없습니다. 에이전트 도입 전에 데이터 사전과 시맨틱 레이어부터 정비하는 것이 가장 수익률 높은 투자입니다.
마무리
- 4가지 방법은 경쟁 관계가 아니라 스펙트럼입니다. 완제품(1, 3)과 반제품(2), 직접 개발(4)은 대상 사용자와 통제 수준이 다를 뿐입니다. 실제로는 1+3, 2+4처럼 조합해서 쓰게 됩니다.
- 통제가 필요한 만큼만 만드세요. 검증 루프와 소버린티가 필요 없다면 직접 개발은 과잉 투자입니다. 반대로 규제 데이터라면 처음부터 방법 4로 가야 재작업이 없습니다.
- 메타데이터가 먼저입니다. 어떤 방법이든 지표 정의와 데이터 사전 없이는 “그럴듯하지만 틀린 SQL”을 벗어날 수 없습니다.
제품 이름과 기능 범위는 빠르게 바뀌는 영역입니다. 이 글의 비교 프레임(대상 사용자 × 통제 수준)으로 후보를 좁히되, 세부 기능과 리전 지원은 도입 시점의 최신 문서로 확인하시기 바랍니다.