BigQuery 비용 줄이는 실무 전략 완전 정리 (쿼리 비용 폭증 원인과 스캔 용량 줄이는 설계 패턴)

 

BigQuery 비용 절감에 대해 실무에서 자주 겪는 문제와 해결 방법을 정리했습니다. BigQuery를 사용하다 보면

어느 날 갑자기 비용이 급증하는 순간이 온다.

 

• 어제는 몇 천 원이었는데
• 오늘은 몇 만 원
• 원인을 모르겠음

 

대부분의 비용 문제는

“쿼리를 많이 실행해서”가 아니라

스캔 데이터 용량이 커졌기 때문이다.

 

BigQuery 비용은 기본적으로:

 

스캔한 데이터 용량(GB) × 요금

 

이다.

 

---

자주 묻는 질문

Q. BigQuery 무료 한도는 얼마인가요?

매월 1TB의 쿼리 처리량과 10GB의 무료 저장 용량이 제공됩니다.

Q. BigQuery 비용을 줄이는 가장 좋은 방법은?

파티션 테이블 사용, SELECT * 대신 필요한 컬럼만 조회, 프리뷰 기능 활용이 가장 효과적입니다.

📌 함께 읽으면 좋은 글

👉 BigQuery 예약된 쿼리 즉시 실행 방법

👉 BigQuery 날짜 타입 차이 정리

👉 BigQuery WHERE 날짜 조건 오류 해결

핵심 정리: ① BigQuery 비용은 스캔 데이터 용량에 따라 결정된다. ② 불필요한 전체 테이블 스캔을 피해야 한다. ③ 파티션 및 클러스터링으로 쿼리 범위를 제한하는 것이 중요하다.

BigQuery 비용 구조 이해하기

 

BigQuery 비용 구조는 쿼리가 스캔한 데이터 용량에 따라 과금하는 On-demand 요금 모델이다.

BigQuery는 기본적으로

On-demand 요금 모델을 사용한다.

 

요금 계산 방식:

• 쿼리 실행
• 읽은 데이터 양 계산
• GB 단위 과금

즉, 결과 행 수는 중요하지 않다.

SELECT *
FROM big_table
LIMIT 10

 

→ 10행만 출력해도

전체 테이블을 스캔하면 비용은 동일하다.

---

가장 흔한 비용 폭증 원인 ① SELECT *

 

SELECT *는 모든 컬럼을 스캔하여 불필요한 데이터 처리 비용을 발생시키는 가장 흔한 비용 폭증 원인이다.

가장 위험한 패턴:

SELECT *
FROM dataset.sales

 

문제:

• 필요 없는 컬럼까지 모두 스캔
• 대용량 JSON/STRING 컬럼 포함 시 비용 폭증

✔ 해결 방법

SELECT order_id, amount, created_at
FROM dataset.sales

 

비교 항목	SELECT * 사용 시 (Before)	필요 컬럼 선택 시 (After)
스캔 용량	전체 테이블 스캔	필요 컬럼만 스캔
비용	높음 (불필요 데이터 포함)	낮음 (최소 데이터 스캔)
쿼리 성능	느림 (많은 데이터 처리)	빠름 (적은 데이터 처리)

SELECT * 사용과 필요 컬럼 선택은 BigQuery 비용에 큰 영향을 미친다.

필요한 컬럼만 선택.

 

---

비용 폭증 원인 ② 파티션 미사용

파티션 테이블인데도

파티션은 테이블을 특정 컬럼(예: 날짜)을 기준으로 물리적으로 분할하여 쿼리 시 스캔 범위를 줄이는 기능이다.

WHERE created_at >= '2025-01-01'

 

이렇게 쓰면

파티션 필터가 적용되지 않을 수 있다.

 

✔ 올바른 패턴

WHERE DATE(created_at) = DATE('2025-01-01')

 

또는

WHERE _PARTITIONDATE = '2025-01-01'

 

파티션 필터가 적용되면

해당 날짜 데이터만 스캔한다.

 

---

클러스터링을 활용한 추가 절감

 

클러스터링은 파티션 내 데이터를 특정 컬럼을 기준으로 정렬하여 특정 조건의 데이터를 효율적으로 조회하게 돕는 기능이다.

파티션이 날짜 단위라면

그 안에서 특정 컬럼으로 자주 필터링할 수 있다.

 

예:

CLUSTER BY user_id

 

→ 특정 사용자 조회 시

스캔 범위 축소

 

---

쿼리 실행 전 비용 예측하기

 

쿼리 실행 전 비용 예측은 실제 쿼리 실행 없이 스캔될 데이터 용량을 미리 확인하여 불필요한 비용 발생을 방지하는 작업이다.

BigQuery UI에서

“쿼리 검증” 버튼을 누르면

 

예상 스캔 용량이 표시된다.

 

✔ 10GB 이상이면 반드시 재검토

✔ 100GB 이상이면 구조 점검

---

중복 쿼리 실행 문제

 

중복 쿼리 실행 문제는 동일하거나 유사한 쿼리가 반복적으로 실행되어 불필요한 비용이 계속 발생하는 상황을 의미한다.

Looker Studio 연결 시

사용자가 페이지를 새로고침할 때마다 쿼리 실행 가능.

 

✔ 해결 방법

• 중간 집계 테이블 생성
• Scheduled Query 사용
• Materialized View 고려

---

실무 설계 패턴

📌 패턴 1 – 원본 테이블 분리

• raw_table
• summary_table

사용자는 summary_table만 조회.

 

---

📌 패턴 2 – 집계 전용 테이블 생성

매일 1회 집계:

집계 전용 테이블 생성은 자주 사용되는 집계 데이터를 미리 계산하여 저장해 둠으로써 반복적인 원본 테이블 스캔을 줄이는 전략이다.

CREATE OR REPLACE TABLE dataset.daily_sales AS
SELECT DATE(created_at) d,
       SUM(amount) total
FROM dataset.sales
GROUP BY 1

 

대시보드는 daily_sales 조회.

---

LIMIT은 비용을 줄이지 않는다

 

LIMIT 절은 쿼리 결과의 행 수를 제한하지만, 스캔하는 데이터 용량에는 영향을 주지 않아 비용 절감 효과가 없다.

이건 매우 중요한 오해다.

SELECT *
FROM table
LIMIT 100

 

→ 스캔량 동일

→ 비용 동일

---

비용 줄이기 체크리스트

✔ SELECT * 금지

✔ 파티션 필터 사용

✔ 클러스터링 고려

✔ 집계 테이블 분리

✔ 쿼리 검증으로 스캔 용량 확인

✔ Looker Studio 직접 연결 최소화

 

결론

 

BigQuery 비용 문제는

“많이 써서”가 아니라

“구조 설계를 안 해서” 발생한다.

 

파티션, 클러스터링, 집계 테이블 전략을 사용하면

비용은 절반 이하로 줄일 수 있다. 2026년 기준, 이러한 실무 전략은 더욱 중요해지고 있다.

 

이 블로그에서는

구글시트부터 BigQuery까지

실무 데이터 운영에서 반복적으로 발생하는 문제를

구조적으로 정리하고 있다.

💬 이 글이 도움이 되셨다면

BigQuery 비용 절감 관련 궁금한 점이나 더 알고 싶은 내용이 있다면 댓글로 남겨주세요! 실무에서 겪은 경험을 공유해 주셔도 좋습니다.