3. 슬롯과 컴퓨트 과금

지난 편에서는 데이터를 보관할 때 발생하는 storage 비용을 다뤘습니다. 이번 편의 주제는 쿼리를 돌릴 때 발생하는 compute 비용입니다.

1편에서 BigQuery의 컴퓨팅 단위는 슬롯이라고 짚어두기만 했습니다. 이번 편에서는 슬롯이 실제로 어떻게 할당되는지, on-demand와 editions 두 모드는 어떻게 다른지, 약정·autoscaling·idle 공유가 청구서에 어떤 식으로 반영되는지를 살펴봅니다. 따져 보고 나면 결국 "지금 워크로드에 어느 모드가 맞나"라는 질문 하나에 답하는 과정이라는 게 드러납니다.

1. 슬롯 다시 보기

1-1. 슬롯이 실제로 하는 일

슬롯은 BigQuery가 추상화한 가상 워커입니다. 약 0.5 vCPU와 일정량의 메모리에 해당하는 연산 능력 한 단위로, 한 쿼리에 슬롯이 더 많이 할당될수록 1편에서 설명한 Leaf와 Mixer가 더 많이 동시에 돌고 쿼리가 빨라집니다.

다만 슬롯 수를 두 배로 늘렸다고 항상 쿼리가 두 배 빨라지지는 않습니다. 셔플 단계는 어차피 모아야 하는 단계라 병렬화에 한계가 있고, 데이터 스큐가 심하면 일부 슬롯에 작업이 몰려서 다른 슬롯이 놀게 됩니다. 한 쿼리에 의미 있게 쓰이는 슬롯 수는 보통 그 쿼리가 만들어내는 stage 폭과 파티션 수에 의해 정해집니다.

1-2. 슬롯이 부족하면

슬롯은 무한히 받을 수 있는 자원이 아닙니다. 부족할 때 일어나는 일은 두 가지입니다.

1) 적게 할당된 채로 실행 → 쿼리 자체는 돌지만 느려짐
2) 풀에 여유가 없어 대기 → 큐잉(queueing) 발생

큐잉이 자주 일어나면 ETL이 SLA를 자주 넘기고, 분석가가 던진 쿼리도 한참 멈춰 있는 것처럼 보입니다. 실제로 슬롯이 부족한 상태인지를 보려면 두 가지 지표를 같이 봐야 합니다. INFORMATION_SCHEMA.JOBS_BY_PROJECT의 total_slot_ms / TIMESTAMP_DIFF(end_time, creation_time, MILLISECOND)는 쿼리의 평균 동시 슬롯 사용량이라서 그 자체가 부족을 직접 보여주진 않습니다. 부족 여부는 큐잉 시간(creation_time → start_time의 간격)이 더 직접적인 지표이고, editions를 쓰는 경우 INFORMATION_SCHEMA.RESERVATIONS_TIMELINE에서 시간대별 사용량 추이도 함께 봅니다.

2. On-demand 모드

2-1. 스캔 바이트로 청구

on-demand는 쿼리가 스캔한 바이트 수로 과금합니다. US multi-region 기준 $6.25/TiB가 표준 단가이고, 매월 첫 1 TiB는 무료입니다. 쿼리 실행 시간이나 슬롯 사용량과는 무관하게, 컬럼/파티션 프루닝으로 스캔량을 줄이면 그만큼 청구액이 줄어듭니다.

sql

-- 같은 결과, 다른 청구액
SELECT * FROM events
WHERE event_date = '2026-05-01';
-- 1 TiB 스캔 → $6.25

SELECT user_id FROM events
WHERE event_date = '2026-05-01';
-- 컬럼 선택 + 파티션 프루닝 → 5 GiB 스캔 → $0.03

슬롯도 같이 제공되지만 별도 청구가 아니라 공유 풀에서 자동 할당됩니다. 프로젝트당 기본 한도가 약 2,000슬롯이고, 이 풀을 같은 region의 다른 사용자들과 함께 씁니다.

2-2. on-demand의 한계

공유 풀이라 피크 시간대에 신청한 만큼 못 받는 경우가 있습니다. 풀에 여유가 적으면 BigQuery가 자동으로 슬롯 할당을 줄여서 처리하는데, 그러면 같은 쿼리가 평소보다 두세 배 느려질 수 있습니다.

비용 예측이 어렵다는 점도 큽니다. 분석가가 무심코 SELECT *를 돌리면 그 한 번이 수십만 원짜리 청구로 이어질 수 있고, dashboard가 자주 새로고침하는 쿼리가 자동화되어 있으면 누적 비용이 폭발합니다.

on-demand가 맞는 경우:
  - 쿼리량이 적고 산발적 (개인 분석, dev/test)
  - 워크로드가 예측 불가능
  - 슬롯 부족이 거의 안 일어남

on-demand가 안 맞는 경우:
  - 정기 ETL이 매일 큰 데이터를 스캔 (`SELECT *` 류)
  - 슬롯 부족으로 SLA가 흔들림
  - 비용 예측·통제가 필요

이 한계가 보이면 다음 단계는 editions로 슬롯을 직접 예약하는 것입니다.

3. Editions 세 가지

3-1. 단가와 약정

editions 모드는 슬롯-시간으로 과금합니다. 슬롯 N개를 H시간 동안 잡고 있었다면 N × H × 단가만큼 청구됩니다. 같은 슬롯-시간이라도 어느 edition을 쓰는지에 따라 단가가 다릅니다.

Edition	PAYG	1년 약정	3년 약정
Standard	$0.04 / slot-hour	약정 불가	약정 불가
Enterprise	$0.06	$0.048 (-20%)	$0.038 (-37%)
Enterprise Plus	$0.10	$0.080 (-20%)	$0.060 (-40%)

흥미로운 점은 Enterprise 3년 약정 단가($0.038)가 Standard PAYG($0.04)보다 싸다는 것입니다. 안정적인 baseline 워크로드가 있다면 Standard 대신 Enterprise + 약정 조합이 비용과 기능 모두 이득입니다.

3-2. 기능 차이

edition은 단가만 차이 나는 게 아니라 사용할 수 있는 기능 자체가 다릅니다. 실무 결정에 영향을 주는 항목은 다음과 같습니다.

항목	Standard	Enterprise	Enterprise Plus
약정 (1년/3년)	불가	가능	가능
Autoscale 최대	1,600 slots	region 쿼터까지	region 쿼터까지
Managed DR (크로스 리전)	미지원	미지원	지원
CMEK / VPC SC	일부	지원	지원
워크로드 관리 (RLS, Column ACL)	일부	풀	풀

Time Travel은 edition과 무관하게 2~7일 범위로 고정되어 있고, Fail-safe는 추가 7일 고정입니다. 둘 다 edition 사이의 차별 항목이 아니므로 표에서 뺐습니다. Enterprise Plus의 복구 관련 진짜 차별점은 Managed DR(크로스 리전 페일오버)이고, 자세한 동작은 10편에서 다룹니다.

실무에서 자주 걸리는 항목이 Standard의 1,600슬롯 천장입니다. autoscaling이 1,600에서 멈추기 때문에, 무거운 쿼리가 몇 개만 동시에 돌아도 큐잉이 발생합니다. 약정 불가 + 1,600 천장 조합 때문에 Standard는 실질적으로 작은 워크로드 전용입니다.

4. Baseline + Autoscaling

4-1. 두 부분으로 나뉘는 슬롯

editions의 reservation은 두 부분으로 구성됩니다.

Reservation 구조:

  ┌─ Max slots ─────────────────────────┐
  │                                     │
  │  Autoscale 영역                      │
  │  (사용한 만큼만 청구, 50개 단위)        │
  │                                     │
  ├─ Baseline ──────────────────────────┤
  │                                     │
  │  Baseline 슬롯                       │
  │  (항상 할당, 항상 청구)                │
  │                                     │
  └─────────────────────────────────────┘

Baseline은 reservation에 항상 할당돼 있는 슬롯입니다. 쓰든 안 쓰든 시간만큼 무조건 청구됩니다. 약정 슬롯은 여기에 배치됩니다.
Autoscale은 baseline 위에 동적으로 붙는 슬롯입니다. 부하가 늘면 50개 단위로 추가되고, 줄면 다시 회수됩니다. 사용한 시간만큼만 청구됩니다.

4-2. autoscale의 동작 규칙

autoscale에는 두 가지 약속이 있습니다. 첫째, 슬롯은 50개 단위로만 증감합니다. 30개가 더 필요해 보여도 50개가 올라가고, 정확히 71개가 필요하면 100개가 올라갑니다. 둘째, 한 번 올라간 슬롯은 최소 60초(scale-down window) 동안 유지됩니다. 60초 안에 다시 부하가 줄어 들면 그 슬롯들은 아무것도 안 하는 상태로 청구만 됩니다.

이 두 규칙 때문에 짧고 자주 튀는 워크로드는 autoscale 효율이 떨어집니다. 30초짜리 쿼리가 매 분마다 한 번씩 들어오면 슬롯이 거의 항상 켜져 있는 상태가 되어, autoscale을 쓰는데도 baseline처럼 청구됩니다.

4-3. Idle slot sharing과 scaling mode

reservation에는 다른 reservation의 idle 슬롯을 빌려 쓰는 기능이 있고, idle 차용·autoscale의 동작은 scaling mode로 조절합니다.

- ALL_SLOTS         : idle 슬롯 차용 + autoscale 둘 다 사용
- IDLE_SLOTS_ONLY   : idle만 빌리고 autoscale은 안 함
- AUTOSCALE_ONLY    : idle 차용은 끄고 autoscale만 사용

scaling_mode는 비교적 새 옵션입니다. 전통적으로는 ignore_idle_slots 플래그 하나로 idle 차용만 켜고 껐는데, scaling_mode는 max_slots와 함께 잡으면 비용 상한까지 명시적으로 정할 수 있어서 신규 reservation에 권장됩니다. 기존 프로젝트는 두 방식이 한동안 공존하니, 운영 중인 reservation의 설정이 어느 쪽인지 한 번씩 확인할 만합니다.

같은 organization에서 reservation을 여럿 운영하면, 어떤 reservation이 baseline을 다 못 쓰는 동안 다른 reservation이 그 idle 슬롯을 빌려 쓸 수 있습니다. 차용한 쪽도 빌려준 쪽도 추가 비용이 없습니다.

다만 idle 차용은 우선순위가 낮아서, 빌려준 reservation에서 자기 슬롯이 필요해지면 즉시 회수됩니다. 안정적인 보장이 필요한 ETL은 baseline에 의존하고, idle은 그 위의 보너스로 보는 게 안전합니다.

4-4. 청구 계산 예시

baseline 100 슬롯, autoscale 0~500 슬롯으로 잡힌 Enterprise reservation을 PAYG로 운영하는 경우를 보겠습니다.

하루 24시간 중:
  - baseline 100 슬롯: 24시간 내내 청구 → 100 × 24h × $0.06 = $144
  - autoscale: 평균 사용 시간 6시간 × 평균 200 슬롯 → 200 × 6h × $0.06 = $72

하루 총 compute 비용: 약 $216
한 달(30일): 약 $6,480

baseline 비용은 사용량과 무관하게 고정이고, autoscale은 실제 사용 시간에 비례합니다. baseline을 너무 낮게 잡으면 매번 autoscale 50개 단위로 켜졌다 꺼져서 응답이 늦어지고, 너무 높게 잡으면 안 쓰는 시간에도 청구가 됩니다.

5. 약정과 손익분기점

5-1. 어느 부분을 약정해야 하는가

약정 슬롯은 baseline에 배치되어 항상 청구됩니다. 따라서 약정 효과를 최대로 받으려면 하루 24시간 거의 항상 사용하는 슬롯만큼만 약정하는 게 맞습니다.

Enterprise 기준으로 손익분기점을 잡아 보면 이렇습니다.

PAYG 단가:  $0.06 / slot-hour
1년 약정:   $0.048 / slot-hour (20% 할인)
3년 약정:   $0.038 / slot-hour (37% 할인)

손익분기 계산
  약정은 사용 여부와 무관하게 24시간 항상 청구되고, PAYG는 실제 사용한
  만큼만 청구됩니다. 슬롯 1개를 하루 t시간 동안 쓴다고 하면:

    1년 약정이 이득:  0.048 × 24 ≤ 0.06 × t  → t ≥ 19.2시간 (24시간의 80%)
    3년 약정이 이득:  0.038 × 24 ≤ 0.06 × t  → t ≥ 15.2시간 (24시간의 63%)

  즉, 손익분기율은 (약정 단가 / PAYG 단가) 자체입니다. 1년 약정은 슬롯이
  하루의 80% 이상 꾸준히 쓰일 때, 3년 약정은 63% 이상 쓰일 때 이득입니다.

baseline에 배치되어 거의 항상 사용되는 슬롯이라면 1년 약정도 곧장 이득이고, 그게 정말 3년 내내 안 줄어들 자신이 있으면 3년 약정으로 더 깎습니다.

3년 약정은 비용을 더 깎지만 워크로드 자체가 3년 동안 안정적이라는 가정이 들어가서, BigQuery 이전 계획이나 큰 아키텍처 변경이 예상되면 신중해야 합니다.

5-2. 약정과 autoscale의 조합

흔한 실무 구성은 약정 baseline + autoscale 조합입니다.

Reservation 예시 (Enterprise, 3년 약정):

  baseline:  500 slots (3년 약정, $0.038/slot-hour)
  max:      2,000 slots (autoscale는 PAYG $0.06)

  안정적인 ETL/BI 부하       → baseline 500 슬롯이 항상 처리
  피크 분석 워크로드          → autoscale로 최대 1,500 슬롯 추가

이 구조는 안정 부하의 비용을 최저로 잡고, 가끔 튀는 피크에만 PAYG를 내는 방식입니다. 1년 단위로 baseline 사용량을 다시 보고, 꾸준히 사용된 부분을 약정으로 더 옮기면 비용이 또 줄어듭니다.

약정 슬롯과 reservation은 일반적으로 Organization 또는 Billing Account 레벨에서 중앙 집중적으로 잡고 프로젝트에 할당하는 방식이 효율적입니다. 프로젝트별로 따로 약정을 잡으면 한쪽은 슬롯이 남고 다른 쪽은 부족해지는 상황이 자주 생겨서, 같은 비용으로 더 큰 reservation 하나를 만들고 idle 차용으로 공유하는 게 활용도가 높습니다.

6. 어느 모드를 골라야 하는가

6-1. on-demand vs editions 판단 기준

판단의 출발점은 두 비용을 직접 비교해 보는 것입니다.

한 달 평균 쿼리 스캔량 × $6.25/TiB    (on-demand 예상 비용)
              vs.
필요 슬롯-시간 × edition 단가          (editions 예상 비용)

쿼리 워크로드가 다음 중 하나라도 해당되면 editions로 넘어가는 게 일반적입니다.

정기 ETL이 매일 수십 TiB 이상 스캔
슬롯 부족으로 SLA가 흔들림
비용 예측·통제가 비즈니스에 중요
Time Travel 확장, Managed DR 등 고급 기능 필요

반대로 다음 경우는 on-demand가 더 단순하고 싸게 먹힙니다.

데이터는 많지만 쿼리는 가끔
잘 좁힌 컬럼/파티션으로 스캔량이 작은 워크로드
슬롯 부족이 거의 안 일어나는 환경

6-2. edition 선택

Standard는 약정 불가 + 1,600슬롯 천장이라, 약정 워크로드가 있거나 큰 쿼리가 동시 다발인 환경에서는 한계가 빨리 옵니다. 작은 팀, 단순 워크로드 전용입니다.
Enterprise는 약정 가능 + autoscale 천장 없음으로 대부분의 프로덕션 환경에 맞습니다. 약정 슬롯 단가가 Standard PAYG보다 싸기 때문에, 베이스라인이 잡혀 있는 환경이라면 비용도 유리합니다.
Enterprise Plus는 Managed DR, 확장된 Time Travel 등 엔터프라이즈 보안·복구 기능이 필요한 경우 선택합니다. 단가는 가장 높지만, 8편(권한과 보안), 10편(리전과 DR)에서 다룰 기능들을 쓰려면 사실상 이 edition이 필요합니다.

6-3. 슬롯 활용도 모니터링

reservation을 운영한다면 baseline을 얼마나 쓰고 있는지가 핵심 지표입니다. 다음 쿼리로 시간대별 슬롯 사용량 추이를 볼 수 있습니다.

sql

-- 지난 7일간 시간별 슬롯 사용량 (Enterprise reservation 가정)
-- 실행에는 bigquery.resourceAdmin 이상의 권한이 필요합니다.
SELECT
  TIMESTAMP_TRUNC(period_start, HOUR)   AS hour,
  reservation_name,
  AVG(slots_assigned)                   AS avg_baseline,
  AVG(slots_max_assigned)               AS avg_assigned_peak,
  AVG(period_slot_ms / 1000)            AS avg_slot_seconds_used,
  AVG(autoscale.current_slots)          AS avg_autoscale_used
FROM `region-us`.INFORMATION_SCHEMA.RESERVATIONS_TIMELINE
WHERE period_start > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY hour, reservation_name
ORDER BY hour DESC;

이 데이터로 두 가지를 판단할 수 있습니다. 첫째, baseline이 너무 높거나 낮은지: baseline 활용률이 꾸준히 50% 미만이면 baseline을 줄이고, 자주 100%에 닿으면 baseline을 늘리거나 약정을 더 잡습니다. 둘째, autoscale이 60초 scale-down에 갇혀 비싸지는지: autoscale 슬롯이 거의 항상 켜져 있다면 그 부분을 baseline + 약정으로 옮기는 게 단가 면에서 더 싸집니다.

마무리

BigQuery compute 비용은 슬롯을 어떻게 잡느냐의 문제로 수렴합니다. on-demand는 스캔 바이트로 청구되고 공유 풀에서 슬롯이 자동 할당되는 단순한 모델이지만, 워크로드가 늘어나면 비용 예측과 슬롯 부족 양쪽에서 막힙니다. 반면 editions는 슬롯을 직접 예약·관리하면서 약정으로 단가를 깎는 구조라, baseline과 autoscale을 어떻게 배합하느냐가 청구서의 모양을 결정합니다.

이 구성은 한 번 정해 놓고 끝나는 게 아니라, 사용량을 보면서 baseline과 약정 비중을 계속 조정해 가는 작업입니다. 그러려면 우선 쿼리 한 건이 어떻게 실행되고 어디서 슬롯을 많이 쓰는지를 읽을 줄 알아야 합니다. 다음 편에서는 실행 계획과 INFORMATION_SCHEMA로 느린 쿼리를 디버깅하고, 자주 만나는 안티패턴을 정리해 보겠습니다.