Gemini로 BigQuery 분석하기: 연결 시트에서 반복 보고서까지

채팅으로 만든 답에서 다시 계산할 수 있는 보고서로

매주 월요일, 운영 담당자가 데이터팀에 “지난달 반품이 늘어난 이유를 알려 달라”고 요청한다. 처음에는 지역별 표를 받고, 다음에는 상품군을 나누고, 마지막에는 회의용 차트를 만든다. 질문이 조금 바뀔 때마다 CSV를 다시 받는다면 분석 자체보다 자료를 주고받는 시간이 길어진다.

Google은 2026년 10월 19일 BigQuery에 연결된 Sheets에서 Gemini로 질문·후속 분석을 하고 대시보드를 만드는 기능을 발표했다. 화면에 보이는 범위에 국한하지 않고 BigQuery의 전체 데이터셋에 질의한다. 대시보드 요청에서는 계획을 먼저 보여 준 뒤, 새 탭에 연결된 수식·피벗 테이블·차트 같은 갱신 가능한 객체를 만든다고 설명한다. 공식 발표

업무상 변화는 답변을 복사하는 데서 끝나지 않고 다음 회의에도 쓸 분석 결과를 같은 작업 공간에 남길 수 있다는 점이다. 이 글은 그 가능성을 반품 주문율 보고서로 구체화한다. 공식 문헌 분석과 직접 설계한 가상 사례이며, 유료 계정에서 Gemini나 BigQuery를 실행한 사용기는 아니다. 예시의 계산만 로컬에서 확인했다.

지금 누구에게 열리고 있나

발표는 Rapid Release·Scheduled Release 모두 10월 19일부터 최대 15일에 걸쳐 기능이 나타나는 순차 배포로 안내한다. 대상은 Business Standard·Plus, Enterprise Standard·Plus, Google AI Pro·Ultra, Google AI Pro for Education, AI Expanded Access다. 연결된 데이터를 질의할 권한이 있는 사용자가 Gemini 사이드 패널에서 시작하며, 기능은 기본 켜짐이고 이 기능만의 관리자 제어는 없다고 설명한다. 배포와 이용 조건

10월 22일에 모든 해당 계정에서 이미 쓸 수 있다는 뜻은 아니다. 한국 계정의 실제 노출·한국어 질의 품질도 이 글에서 확인하지 않았다. 모델 이름이 Gemini라는 이유로 Argon의 앱·API 이용 조건을 이 기능에 대입할 수도 없다. 이번 발표는 Sheets 안의 제품 기능에 관한 것이며 사용 모델 버전을 여기서 특정하지 않는다.

또한 구독과 데이터 접근은 별개다. Connected Sheets 시작 안내는 Google Cloud·BigQuery 접근과 결제가 설정된 프로젝트 등을 전제로 한다. 컴퓨터에서 Data → Data connectors → Connect to BigQuery로 프로젝트와 테이블 또는 뷰를 고른다. 모바일 앱에서는 연결 데이터를 볼 수 있지만 작성·편집·갱신은 컴퓨터에서 하도록 안내한다. 일반 Gemini 모바일 기능의 제공을 이 연결 시트 작업 전체의 지원으로 읽으면 안 된다. 연결 시트 시작 조건

‘전체 데이터’는 무엇이 전체라는 뜻일까

Connected Sheets의 기존 기반은 BigQuery에서 질의를 실행하고 결과를 스프레드시트에 저장하는 방식이다. 사용자가 요청하거나 예약한 시점에 실행한다. 시트에서 BigQuery의 원본 데이터를 직접 바꾸는 기능은 아니다. 데이터와 결과의 관계

여기에 자연어로 질문과 분석 계획을 주고받는 입구가 더해진 것으로 이해하면 된다. 큰 테이블을 셀에 모두 복사해야만 집계할 수 있는 것은 아니다. 반대로 “전체”라는 말이 모든 사내 테이블에 접근하거나 모든 원본 행을 모델 문맥에 전송한다는 의미도 아니다. 공개 발표만으로 모델 내부의 입력·도구 호출 구조까지 알 수는 없다.

독자가 먼저 고정할 전체는 이 보고서가 대상으로 삼은 연결 데이터와 조건이다. 다음 세 가지는 다른 숫자를 만든다.

질문	실제로 세려는 범위	보고서에서 함께 밝힐 것
지금 시트에 보이는 주문 중 반품은?	현재 표시하거나 추출한 일부 주문	표본·추출 조건
8월 배송 완료 주문 중 반품은?	연결 데이터의 해당 배송 코호트	배송일 기준과 반품 관측창
8월에 접수된 반품은?	접수일이 8월인 반품 사건	원주문 시점과 중복 접수 처리

코호트는 같은 조건으로 묶은 대상 집단이다. 8월 배송 주문에 대한 반품은 9월에도 접수될 수 있으므로 두 번째와 세 번째 질문의 결과가 다르다. 질문을 자연어로 쉽게 쓸 수 있을수록, 이 차이를 먼저 명시하는 일이 중요해진다.

반품률이 올라도 모든 상품군이 나빠진 것은 아니다

다음은 실제 사업 자료가 아닌 가상 집계다. 2025년 8월과 2026년 8월에 배송 완료된 주문을 비교한다. 분모는 고유 주문 수, 분자는 배송 후 30일 이내 승인된 반품이 하나 이상 있는 고유 주문 수다. 두 집단 모두 관측창이 끝났고, 각 주문은 한 상품군에만 속한다고 가정한다. 부분 반품도 주문 한 건으로 세는 정의다.

기간·상품군	배송 주문	반품 주문	반품 주문율
2025년 8월 · 일반	9,000	180	2%
2025년 8월 · 프리미엄	1,000	100	10%
2026년 8월 · 일반	6,000	120	2%
2026년 8월 · 프리미엄	4,000	400	10%

전체율은 280 ÷ 10,000 = 2.8%에서 520 ÷ 10,000 = 5.2%로 오른다. 하지만 두 상품군의 비율은 각각 그대로다. 반품률이 높은 프리미엄 주문의 구성비가 10%에서 40%로 늘어난 것이 이 가상 숫자의 차이를 만든다. 전체 변화는 2.4%포인트이며, 2.4% 증가와 구분해야 한다.

2026년의 상품군별 비율에 2025년 주문 구성비를 적용하면 0.9 × 2% + 0.1 × 10% = 2.8%다. 이는 구성을 고정한 비교이며 실제 2026년 전체율을 대체하는 숫자가 아니다. 운영자가 전체율 상승만 보고 모든 상품군에 품질 개선을 지시하는 대신, 판매 구성 변화와 상품군 안의 변화를 나누어 조사할 이유를 보여 준다.

실제 데이터에서는 같은 상품군 안에서도 가격대·판매 채널·고객 구성이 달라질 수 있다. 이 표만으로 프리미엄 상품에 결함이 있다거나 구성 변화가 모든 원인을 설명한다고 결론 내릴 수 없다. 후속 질문은 “문제 원인을 단정해 줘”보다 “같은 관측창에서 상품군별 비율과 주문 비중을 함께 보여 줘”가 더 구체적이다.

분모 정의도 지켜야 한다. 주문 테이블 한 행에 반품 이벤트 여러 행을 그대로 결합하면 주문이 중복될 수 있다. 이 사례에서는 반품 여부를 주문별로 한 번 요약한 다음 배송 주문과 결합하는 설계를 검토한다. 여러 상품군을 담은 주문이라면 주문 단위 분류 규칙부터 다시 정하거나 주문상품 단위 지표로 바꿔야 한다. 그때는 위 표와 같은 지표라고 부르면 안 된다.

분석 계획에서 확인하고, 결과 탭에 남길 것

일반 Gemini in Sheets의 입구는 컴퓨터 화면 오른쪽 위의 Ask Gemini이며 대화는 사이드 패널에서 진행된다. Gemini 사이드 패널 안내 새 BigQuery 기능의 계획 검토·연결 객체 생성은 앞의 10월 19일 발표를 근거로 한다. 아래는 실제 제품 캡처가 아니라 이 글의 업무 구성도다.

넓은 화면에서는 왼쪽의 데이터·결과와 오른쪽 대화를 함께 비교하는 동선이 유용하다. 질문을 고치는 내용은 대화에, 다음 주에도 읽어야 할 지표 정의와 기준 시각은 결과 탭 가까이에 남기는 것이 이 글의 제안이다. 좁은 컴퓨터 창에서는 표와 패널을 번갈아 확인하더라도 분모·기간을 다시 찾을 수 있게 결과에 적어 둔다. 제품의 창 너비별 자동 재배치나 모바일 편집을 직접 검증했다는 뜻은 아니다.

다음 의뢰서는 예시다. 연결한 데이터의 실제 열 이름과 조직의 반품 규칙으로 바꿔야 하며, 이 문구를 넣었다고 원하는 계획이나 객체가 반드시 생성된다고 보장하지 않는다.

목적: 전년 같은 달 대비 반품 주문율 변화 검토
대상: 2025년 8월과 2026년 8월 배송 완료 주문
기간: 한국시간 배송일 기준, 각 배송 후 30일 관측
지표: 반품 승인 주문 수 / 배송 완료 주문 수
반품 주문: 관측창 안에 승인된 반품이 하나 이상인 고유 주문
구분: 주문별 상품군, 미분류는 별도 표시

먼저 사용할 테이블·열, 주문 중복 제거 방식,
관측창 종료 여부와 분모를 포함한 계획을 보여 줘.
정의가 불명확하면 계산 전에 질문해 줘.

검토 후 필요한 결과:
전체율, 상품군별 비율, 상품군별 주문 비중,
전년 구성비를 고정한 비교를 각각 구분한 보고서.
결과 옆에 지표 정의·대상 기간·데이터 기준 시각을 남겨 줘.

계획을 읽을 때는 “차트를 잘 만들 것인가”보다 어떤 행이 들어가고 어떤 주문이 한 번만 세어지는가를 먼저 본다. 승인 반품과 신청 반품을 섞었거나 30일이 안 지난 주문을 같은 분모에 넣었다면 여기서 질문을 고친다. 계획이 맞아도 실행 결과가 같다는 보증은 아니므로, 결과에서 분모 합계와 미분류 수, 알려진 소수 주문의 포함 여부를 다시 확인한다.

생성된 결과에는 전체율 차트만 남기지 말고 상품군 비율과 구성비를 함께 둔다. 설명 문장에는 “품질 저하”처럼 데이터가 증명하지 않은 원인 대신 실제 확인된 변화를 쓴다. 형식이 맞는 결과와 업무상 맞는 결과를 나누는 문제는 구조화 출력의 업무 검증에서도 다룬다.

공유받은 사람이 다음 주에도 새로 계산할 수 있을까

시트에서 결과를 볼 수 있는 것과 BigQuery를 다시 질의할 수 있는 것은 다르다. 관리자 문서의 일반 권한 표에서는 기존 차트·피벗·결과를 보는 데 BigQuery IAM 역할이 필요하지 않지만, 생성·갱신에는 시트 편집 권한과 해당 BigQuery 권한이 필요하다. 별도로 관리하는 위임 접근 기능도 있으므로 조직의 적용 여부를 확인해야 한다. Connected Sheets 권한과 위임

따라서 원본 DB 권한이 없는 사람도 공유된 결과를 볼 수 있다는 점을 고려해 결과 시트의 공유 범위를 정한다. “DB가 잠겨 있으니 보고서를 넓게 공유해도 된다”는 판단은 성립하지 않는다. 반대로 시트 편집 권한만 줬는데 갱신이 실패했다고 AI 기능의 오류로 단정해서도 안 된다.

갱신 역시 상시 동기화가 아니다. 현재 도움말은 수동 또는 예약 갱신을 설명한다. 예약은 설정한 사용자로 실행되며 다른 사용자가 데이터 소스를 추가·수정하면 일시 중지된다. 미리보기·실패 상태인 객체는 예약 갱신 대상에서 빠지고, 사용자 IP·기기 문맥을 요구하는 VPC Service Controls 조건도 예약 실패 요인이 될 수 있다. 갱신 규칙

반품 보고서를 넘길 때 다음 항목을 결과 가까이에 남기자. 이는 제품이 자동 제공하는 필드 목록이 아니라 팀의 인수인계 양식이다.

인수인계 항목	적을 내용
의미	지표 정의, 주문 단위, 관측창, 미분류 처리
자료	연결 대상, 원본 적재 완료 시각, 결과 갱신 성공 시각
담당	예약 소유자, 대체 담당자, 공유 대상
실패 대응	어떤 객체가 실패했는지, 마지막 유효 결과, 다음 확인자

예약이 성공해도 원본 적재가 늦었다면 새로 계산한 옛 데이터일 수 있다. 또 일부 차트만 갱신됐다면 한 페이지에 서로 다른 시점이 섞일 수 있다. 결과를 회의 자료로 쓰기 전 두 시각과 객체별 상태를 보는 이유다. 시각의 해석은 UTC·현지 시각과 반복 일정으로 이어서 읽을 수 있다.

자연어 질문이 쉬워져도 조회 비용은 남는다

BigQuery에는 처리 바이트를 기준으로 하는 온디맨드 방식과 슬롯 같은 계산 자원을 기준으로 하는 용량 방식이 있다. 작은 결과 표를 받았다는 사실만으로 조회가 작았다고 볼 수 없다. 비클러스터 테이블에서 LIMIT로 반환 행만 줄여도 읽는 바이트는 줄지 않는다는 것이 공식 비용 문서의 주의점이다. BigQuery 비용 통제

예를 들어 “상위 10개 상품만 보여 줘”라는 요청은 출력 크기를 줄이는 조건이다. 그 10개를 찾기 위해 모든 기간·상품을 집계하는지, 필요한 기간·열만 읽는지는 별도 문제다. 반품 사례에서도 무심코 전체 이력을 거듭 조회하지 않도록 데이터팀과 대상 기간·필요 열·집계 자료를 정한다. 기간 필터를 적었다고 비용이 특정 비율만큼 감소하는 것은 아니며 실제 저장 구조와 질의를 확인해야 한다.

온디맨드에서는 BigQuery의 프로젝트·사용자별 일일 질의 할당량, 개별 질의의 최대 청구 바이트 같은 통제 수단을 검토할 수 있다. 다만 이 글은 Gemini의 모든 자동 질의에 그 설정을 지정하는 Sheets 화면이 있다고 확인한 것이 아니다. 관리자는 실제 실행 경로에 적용되는 통제를 점검해야 한다. 질의 비용 제한의 범위

Connected Sheets는 하단 Refresh의 정보 아이콘에서 BigQuery 질의 상세를 열 수 있다. 질의 없이 얻은 데이터에는 아이콘이 나타나지 않을 수 있다. Sheets 시간 초과가 나도 DB 질의가 계속될 수 있다는 조건 역시 확인해야 한다. 질의 상세와 취소 오류가 난 화면에서 재요청을 반복하기 전에 기존 작업의 상태를 살피는 편이 낫다.

도입할 만한 업무와 아직 이른 업무

이 기능의 좋은 출발점은 BigQuery에 정돈된 데이터가 있고, Sheets로 결과를 공유하며, 담당자가 후속 질문을 자주 바꾸는 반복 보고 업무다. 사람이 매번 열과 차트를 옮기는 부분을 줄일 가능성이 있다. 다만 절약한 시간과 결과 품질은 실제로 측정해야 한다.

반품 정의조차 팀마다 다르거나 원본이 여러 파일에 흩어져 있다면 먼저 분석 기준과 연결 자료를 정리할 일이 남는다. 고정된 규제 보고나 엄격한 승인 절차가 필요한 산출물은 검증된 질의와 변경 이력을 중심으로 두는 편이 적절할 수 있다. 작은 일회성 표라면 새 결제 프로젝트와 권한·갱신 운영을 준비하는 부담이 더 클 수도 있다.

첫 적용에서는 이미 정답을 대조할 수 있는 보고서 하나를 고르자. 같은 기간·정의로 결과를 재현한 다음 후속 질문 한 가지를 추가하고, 마지막으로 다른 담당자가 갱신할 수 있는지 확인한다. 이 글의 의뢰서와 인수인계표를 저장해 그때 다시 사용할 수 있다. 후속 주제는 AI 시스템 모음과 RSS에서 이어 볼 수 있다.