바이브 코딩은 앱을 만드는 이야기로만 들리지만, 데이터 분석가에게도 비슷한 변화가 오고 있습니다. 구글은 그것을 **'바이브 쿼리(vibe querying)'**라고 부릅니다.
SQL을 써 본 사람이라면 익숙한 상황이 있습니다. 머릿속에는 "토요일 기준으로 픽업 지역별 평균 이동 거리"가 분명한데, 테이블 이름과 컬럼 이름을 찾고 GROUP BY를 맞추는 데 시간이 더 걸립니다.
2026년 1월 구글 클라우드 블로그에 소개된 BigQuery의 Comments to SQL은 이 간극을 노립니다. 이 연재의 마지막 편으로, 코드 대신 쿼리에서 바이브 코딩이 어떻게 생겼는지 봤습니다.
주석이 곧 쿼리가 된다
블로그의 설명은 이렇습니다. Comments to SQL은 SQL 문 안에 자연어 표현을 직접 넣으면 시스템이 그것을 실행 가능한 SQL로 바꿔 주는 기능입니다.
예시가 짧고 분명합니다.
SELECT /* tip and passenger count columns */
FROM /* NYC taxi ride public data */
WHERE /* passenger count greater than 6 and tip is zero */
뼈대는 SQL로 쓰고, 구체적인 내용은 주석으로 채웁니다. 자연어 표현은 SELECT, FROM, WHERE, ORDER BY, GROUP BY 안에 둘 수 있다고 적혀 있습니다.
전부를 자연어로 맡기는 방식과 다른 점이 여기 있습니다. 쿼리의 모양은 사람이 정합니다. 무엇을 고르고, 어디서 가져오고, 어떻게 묶을지는 SQL 키워드로 못 박아 두고, 이름 찾기와 조건 쓰기 같은 세부만 맡깁니다.
쓰는 순서
블로그가 안내하는 절차는 다섯 단계입니다.
- BQ Studio를 엽니다.
- SQL Generation Widget이 켜져 있는지 확인합니다.
- 주석이 든 SQL을 선택하고 Gemini 버튼에서 "Convert comments to SQL"을 누릅니다.
- 생성 위젯이 변환된 SQL을 diff 화면으로 보여 줍니다.
- 삽입하거나, 여러 차례 다듬기 기능으로 계속 고칩니다.
네 번째 단계가 이 기능의 성격을 말해 줍니다. 결과를 바로 실행하지 않고, 무엇이 바뀌는지 먼저 보여 줍니다. 블로그는 자연어 표현을 고치면 SQL 출력이 어떻게 바뀌는지 바로 볼 수 있다는 점도 장점으로 듭니다.
정확도는 메타데이터가 정한다
그럼 모델은 'NYC taxi ride public data'가 어느 테이블인지 어떻게 알까요. BigQuery 문서가 단서를 줍니다.
Gemini는 최근에 조회한 테이블의 메타데이터를 써서 맞는 데이터를 찾으려 한다고 합니다. 그리고 SQL을 생성할 때 **열 설명(column description)**을 참고하므로, 정확도를 높이려면 스키마에 열 설명을 추가하라고 권합니다.
이 대목은 데이터 엔지니어에게 꽤 현실적인 숙제를 줍니다. 컬럼 이름이 amt2, flg_x 같은 식이고 설명이 비어 있다면, 사람이 헷갈리는 만큼 모델도 헷갈립니다. 바이브 쿼리의 품질은 결국 메타데이터를 얼마나 잘 써 뒀느냐에 묶입니다.
이 블로그의 Knowledge Catalog 글에서 다룬 이야기와 같은 결론입니다. AI가 데이터를 제대로 읽게 하려면, 데이터에 대한 설명이 먼저 있어야 합니다.
한계도 문서에 적혀 있다
문서는 한계를 숨기지 않습니다.
- Convert comments to SQL은 미리보기(Preview) 기능입니다. 정식 출시 전 기능은 '있는 그대로' 제공되고 지원이 제한될 수 있습니다.
- 그럴듯하지만 사실과 다른 출력을 낼 수 있으니 쓰기 전에 모두 검증하라고 적혀 있습니다.
- Gemini in BigQuery는 영어 프롬프트만 지원합니다. 위 예시의 주석이 영어인 이유입니다.
- 같은 프롬프트에도 매번 다른 문법을 제안할 수 있습니다.
데이터 거버넌스 쪽으로는, Gemini for Google Cloud가 명시적 허가 없이 프롬프트와 응답을 모델 학습에 쓰지 않는다고 밝힙니다. 쓰려면 프로젝트에 'Gemini for Google Cloud 사용자' 역할(roles/cloudaicompanion.user)이 필요합니다.
세 번째와 네 번째 항목은 실무에서 의미가 큽니다. 같은 주석에서 매번 다른 SQL이 나올 수 있다면, 생성된 SQL을 그대로 리포트 파이프라인에 넣으면 안 됩니다. 생성은 탐색 단계에서, 확정된 SQL은 코드로 남기는 구분이 필요합니다.
연재를 마치며
열 편을 지나오면서 회사와 도구는 계속 바뀌었지만 같은 모양이 반복됐습니다.
구글의 AI Studio는 배포 전에 공유 범위와 비용을 경고했고, Claude Code는 확인 수단과 훅을 권했습니다. Codex는 샌드박스와 승인으로 울타리를 쳤고, 아모레퍼시픽은 스펙으로 맥락을 넣었습니다. 그리고 BigQuery는 실행 전에 diff를 보여 줍니다.
어느 쪽이든 AI가 만든 결과물과 실제로 반영되는 것 사이에 사람이 확인하는 칸을 하나 남겨 두는 설계입니다. 1편에서 구글이 '책임 있는 AI 보조 개발'이라고 부른 것이 결국 이 칸입니다. 바이브로 시작하되, 그 칸은 비워 두지 않는 것. 열 편의 사례가 공통으로 하는 이야기입니다.
