웨어하우스와 크레딧 (크기, Gen2, 멀티 클러스터, Adaptive)

웨어하우스는 컴퓨트 묶음입니다

가상 웨어하우스(virtual warehouse)는 쿼리와 DML 을 실행하는 컴퓨트 클러스터입니다. 저장소와 분리되어 있어 같은 데이터를 여러 웨어하우스가 동시에 읽을 수 있고, 켜져 있는 시간만큼 크레딧을 씁니다. 저장소, 클라우드 서비스와의 관계는 아키텍처 문서를 봅니다.

크기별 시간당 크레딧

Snowflake Service Consumption Table (2026-10-15 시행판) 기준입니다.

한 단계 커질 때마다 컴퓨트 자원과 크레딧이 두 배가 됩니다. 크레딧을 돈으로 바꾸는 단가는 에디션, 클라우드, 리전, 계약에 따라 다르고, 크레딧 비용 계산기 로 어림할 수 있습니다.

과금 규칙

• 초 단위 과금이지만 웨어하우스를 켤 때마다(재개, 크기 키우기 포함) 최소 60초가 붙습니다.
• AUTO_SUSPEND 기본값은 600초(10분)입니다. 쿼리가 끝나도 이 시간 동안은 계속 과금됩니다.
• AUTO_RESUME = TRUE 면 쿼리가 들어올 때 자동으로 켜집니다.
• 웨어하우스를 쓰지 않는 서버리스 기능(Snowpipe, 서버리스 Task, Automatic Clustering 등)은 따로 과금됩니다.

Gen2 표준 웨어하우스

Gen2 표준 웨어하우스는 2025년 5월 5일 GA 가 되었고, 2026-10 기준 새로 만드는 표준 웨어하우스의 기본값입니다. 더 새로운 하드웨어와 DML, 스캔 최적화로 같은 크기에서 더 빨리 끝나므로, 시간당 크레딧은 비싸도 총 크레딧이 줄어드는 작업이 많습니다.

CREATE WAREHOUSE etl_wh
  WAREHOUSE_SIZE = 'MEDIUM'
  GENERATION = '2'          -- 생략해도 기본
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE;

ALTER WAREHOUSE old_wh SET GENERATION = '2';   -- 기존 웨어하우스 전환

팁 Gen1 과 Gen2 를 비교할 때는 시간당 크레딧이 아니라 같은 작업의 총 크레딧을 봅니다. 대표 작업을 두 세대에서 돌려 QUERY_HISTORY 의 실행 시간과 WAREHOUSE_METERING_HISTORY 를 비교하세요.

멀티 클러스터 웨어하우스

동시에 들어오는 쿼리가 많아 대기(queue) 가 생길 때는 크기를 키우는 대신 클러스터 수를 늘립니다 (Enterprise 이상).

ALTER WAREHOUSE bi_wh SET
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4
  SCALING_POLICY = 'STANDARD';   -- 또는 'ECONOMY'

• 크기 키우기(scale up)는 한 쿼리를 빠르게, 클러스터 늘리기(scale out)는 많은 쿼리를 동시에 처리합니다.
• MIN_CLUSTER_COUNT 를 1 보다 크게 두면 그만큼 항상 떠 있습니다.

그 밖의 웨어하우스 유형

Adaptive Warehouse

Adaptive Compute 는 2026년 6월 16일 GA 가 되었습니다 (Enterprise 이상, 서울 리전 포함). 크기와 클러스터 수 대신 최대 성능 수준과 처리량 배수만 정하면 Snowflake 가 쿼리마다 자원을 배정합니다.

CREATE ADAPTIVE WAREHOUSE adhoc_wh
  MAX_QUERY_PERFORMANCE_LEVEL = 'XLARGE'   -- 기본값 XLARGE
  QUERY_THROUGHPUT_MULTIPLIER = 2;         -- 기본값 2, 0 또는 2 이상

-- 같은 뜻: CREATE WAREHOUSE ... WAREHOUSE_TYPE = 'ADAPTIVE'

• 과금은 웨어하우스가 켜진 시간이 아니라 쿼리 단위입니다. 비용은 웨어하우스가 켜져 있던 시간보다 실제로 실행한 쿼리의 양에 따라 움직입니다.
• 여러 웨어하우스를 한꺼번에 전환할 때는 SYSTEM$BULK_UPDATE_WH 를 씁니다.
• 쿼리 단위 과금이므로 계산기 의 시간 기반 식으로는 계산하지 않습니다. 정확한 과금 방식은 공식 문서와 Consumption Table 을 확인합니다.

크기 고르는 요령

1. XS 나 S 에서 시작해 대표 쿼리를 돌리고, 원격 디스크 유출(spill)이 보이거나 너무 느리면 한 단계씩 올립니다.
2. 크기를 두 배로 하면 크레딧도 두 배지만, 시간이 절반 이하로 줄면 총비용은 같거나 줄어듭니다. 스캔이 큰 쿼리는 대체로 이 조건을 만족합니다.
3. 작은 쿼리가 많은 BI 는 크기보다 멀티 클러스터가 맞습니다.
4. 용도별로 웨어하우스를 나눕니다 (적재, 변환, BI, 데이터 과학). 비용 배분과 문제 격리가 쉬워집니다.
5. 적재 웨어하우스는 AUTO_SUSPEND = 60 처럼 짧게, BI 웨어하우스는 캐시를 살리려 조금 길게 둡니다. 캐시 문서를 참고합니다.

설정 점검 쿼리

SHOW WAREHOUSES;   -- 크기, 세대, auto_suspend, 클러스터 수

-- 최근 30일 웨어하우스별 크레딧
SELECT warehouse_name, SUM(credits_used) AS credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY 1 ORDER BY 2 DESC;

-- 대기가 많은 웨어하우스 (멀티 클러스터 후보)
SELECT warehouse_name, AVG(avg_queued_load) AS queued
FROM snowflake.account_usage.warehouse_load_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY 1 ORDER BY 2 DESC;

트러블슈팅

• 증상: 쿼리가 몇 초짜리인데 웨어하우스 크레딧이 하루 종일 쌓입니다.

• 원인: 모니터링 도구나 BI 의 주기적 쿼리가 AUTO_SUSPEND 보다 짧은 간격으로 들어와 웨어하우스가 한 번도 멈추지 않습니다.

• 해결: QUERY_HISTORY 에서 그 웨어하우스의 쿼리 간격과 사용자를 확인하고, 주기를 늘리거나 결과 캐시를 쓰게 하거나 전용 XS 웨어하우스로 옮깁니다.

• 증상: 크기를 키웠는데 쿼리가 빨라지지 않습니다.

• 원인: 병목이 컴퓨트가 아니라 대기, 잠금, 컴파일 시간, 외부 함수 호출, 또는 한 노드에 몰리는 데이터 쏠림입니다.

• 해결: 쿼리 튜닝 의 Query Profile 읽는 법으로 병목을 먼저 찾습니다.

공식 문서

• Overview of warehouses
• Gen2 standard warehouses
• Adaptive warehouses
• Snowflake Service Consumption Table (PDF)