데이터웨어하우스 구축 비용 2026, Redshift·Snowflake 예산 산정 기준

데이터웨어하우스 구축 비용 예산 검토와 클라우드 데이터 분석 회의 장면 — 데이터웨어하우스 구축 비용은 저장소보다 컴퓨트 시간, 동시성, 보안 통제, 운영 습관에서 크게 흔들린다.

데이터웨어하우스 구축 비용을 찾는 팀은 보통 Redshift, Snowflake, BigQuery 중 하나를 고르면 예산이 정리된다고 생각한다.

실제 견적서는 엔진 선택보다 컴퓨트 실행 시간, 저장소 증가율, 동시 접속 피크, 데이터 적재 방식, 권한 통제, 백업 보존 기간에서 먼저 갈린다.

이 글은 AWS, Google Cloud, Snowflake 공식 문서를 기준으로 데이터 플랫폼 담당자가 첫해 예산안을 검토할 때 바로 확인할 숫자와 질문만 묶었다.

핵심 요약

데이터웨어하우스 구축 비용은 저장소, 컴퓨트, 쿼리 피크, 데이터 적재, 보안 감사, 운영 인력으로 분해해야 한다.
Amazon Redshift Serverless는 공식 가격표 기준 최저 $1.50/hour부터 시작하며 RPU-hours와 RMS 저장소를 따로 계산한다.
Snowflake는 warehouse 크기별 credits/hour가 핵심이며 X-Small 1, Small 2, Medium 4, Large 8 credits/hour처럼 배수로 늘어난다.
BigQuery는 on-demand per TiB 방식과 slot-hours 예약 방식을 분리하므로 dry run, quota, reservation 설계가 비용 통제의 중심이다.

공식 가격표 핵심 숫자부터 본다

아래 표는 2026년 8월 28일 확인한 공식 문서의 공개 숫자를 데이터웨어하우스 구축 비용 항목으로 다시 묶은 것이다.

리전, 약정, 환율, 세금, 마켓플레이스 계약은 실제 결제액을 바꾸므로 구매 전에는 각 벤더 계산기와 계약서를 다시 확인해야 한다.

비용 항목	공식 공개 숫자	예산이 커지는 조건	검토 질문
Redshift Serverless 컴퓨트	Amazon Redshift pricing 기준 최저 $1.50/hour, RPU-hours per-second, 60-second minimum	대시보드 피크가 길고 Max RPU 제한이 없을 때	Base RPU와 Max RPU 상한을 월별로 정했는가
Redshift base capacity	공식 문서 기준 Base capacity는 4~1024 RPUs 범위에서 조정 가능	개발·검증 workgroup도 높은 base로 남겨둘 때	개발 workgroup과 운영 workgroup을 분리했는가
Redshift Managed Storage	AWS 가격 예시는 US East $0.024/GB-Month, 51,250 GB-month 예시는 $1,230	스냅샷, 복제, 압축 전 데이터가 같이 늘 때	RMS와 manual snapshot 저장소를 따로 산정했는가
Redshift Serverless limit	공식 문서 예시는 weekly 100 RPU hour limit 도달 시 user queries turn off	ad-hoc 분석이 예산을 넘겨도 계속 실행될 때	알림, 로그, 쿼리 중지 중 어떤 액션을 쓸 것인가
Snowflake warehouse	Gen1 기준 X-Small 1, Small 2, Medium 4, Large 8, X-Large 16, 2X-Large 32 credits/hour	로드, BI, 배치가 같은 warehouse를 공유할 때	업무별 warehouse와 auto-suspend 시간을 나눴는가
Snowflake 최소 과금	per-second charging with 60-second minimum each time the warehouse starts	짧은 작업이 수백 번 깨워지는 스케줄일 때	작업 묶음과 warehouse 재사용 시간을 조정했는가
Snowflake cloud services	일일 warehouse 사용량의 10%까지는 보통 포함, 초과분만 별도 credit 영향	메타데이터 작업과 권한 작업이 폭증할 때	cloud services 사용량을 resource monitor와 같이 보는가
Snowflake 예시 견적	공식 예시는 compute 4,464 credits @$2 = $8,928, storage 65 TB @$23 = $1,495, total $10,423	압축 후 TB와 warehouse 시간이 함께 커질 때	압축률, warehouse 크기, 사용자 시간을 한 표로 받았는가
BigQuery 비용 통제	공식 문서는 on-demand per TiB와 slot-hours 예약 방식을 분리하고 dry run 예시 10,918 bytes를 제시한다	LIMIT으로 탐색 비용이 줄어든다고 오해할 때	maximum bytes billed와 custom daily quota를 설정했는가

이 표에서 바로 보이는 결론은 하나다.

데이터웨어하우스 구축 비용은 월 저장 용량보다 컴퓨트가 깨어 있는 시간과 사용자가 만드는 피크를 먼저 계산해야 한다.

이 글이 필요한 사람

데이터웨어하우스 구축 비용을 Redshift나 Snowflake 견적서 한 줄로 판단하기 어려운 데이터 플랫폼 담당자.
BI 대시보드, ELT 적재, 배치 집계, 임시 분석을 한 엔진에 몰아도 되는지 검토하는 아키텍트.
데이터레이크 구축 비용과 웨어하우스 비용을 분리해 예산안을 설명해야 하는 FinOps 담당자.
개인정보와 권한 감사가 필요한 데이터를 분석계로 옮기려는 보안팀.
Snowflake, Redshift, BigQuery 중 무엇을 먼저 PoC해야 하는지 구매 기준을 잡는 팀장.

구축 비용은 여섯 계정으로 쪼갠다

첫째 계정은 컴퓨트다.

Redshift는 RPU나 노드 시간으로, Snowflake는 credits/hour로, BigQuery는 per TiB 또는 slot-hours로 컴퓨트 비용을 드러낸다.

둘째 계정은 저장소다.

압축 후 데이터, Time Travel, clone, snapshot, backup, cross-region 복제를 같은 줄에 넣으면 실제 증분 비용이 보이지 않는다.

셋째 계정은 적재와 변환이다.

ELT 작업이 자주 warehouse를 깨우거나 전체 재처리를 반복하면 BI 쿼리보다 적재 비용이 더 커질 수 있다.

넷째 계정은 동시성과 피크다.

월 평균 사용량이 낮아도 월요일 오전 보고서 피크가 있으면 reservation, multi-cluster, Max RPU 상한을 따로 봐야 한다.

다섯째 계정은 보안과 감사다.

column masking, row policy, key management, audit log, 권한 승인 흐름은 제품 기능보다 운영 담당자 시간을 먼저 요구한다.

여섯째 계정은 데이터 품질이다.

테이블 owner, freshness, lineage, 테스트가 없으면 빠른 웨어하우스가 잘못된 지표를 더 빨리 배포한다.

계정	대표 비용	숨은 증가 지점	초기 통제 기준
컴퓨트	RPU-hours, credits/hour, slot-hours, per TiB processed	idle session, 재시도, 피크 동시성, 큰 warehouse 고정	업무별 compute 분리와 자동 정지
저장소	RMS, compressed storage, snapshot, clone, backup	테스트 복제본, 장기 보존, raw와 mart 중복 저장	보존 기간과 삭제 승인 기준
적재·변환	ELT warehouse, ingestion task, scheduler, dbt run	전체 재처리, 작은 파일, late-arriving data 보정	증분 처리와 실패 재처리 범위
동시성	multi-cluster, reservation, Max RPU, queue 대기 비용	피크 보고서와 임시 분석이 겹칠 때	SLA별 workload queue 분리
보안·감사	masking, row policy, audit, key, 접근 리뷰	권한 예외와 임시 계정이 오래 남을 때	권한 matrix와 월별 리뷰
운영 품질	lineage, test, owner, catalog, incident response	데이터 오류가 재집계와 의사결정 손실로 이어질 때	table owner와 freshness SLO

Redshift 예산은 RPU 상한과 저장소를 분리한다

Amazon Redshift Serverless는 쿼리가 없을 때 compute capacity 과금이 없고, 쿼리가 돌 때 RPU-hours 기준으로 과금된다고 공식 문서가 설명한다.

하지만 Redshift Managed Storage는 별도 GB/month 비용으로 남기 때문에 서버리스라는 말만 보고 저장소 예산을 지우면 안 된다.

공식 pricing 페이지는 Serverless를 최저 $1.50/hour부터 시작한다고 설명하고, Base capacity를 4~1024 RPUs 범위에서 조정할 수 있다고 안내한다.

운영팀이 먼저 잡아야 할 값은 평균 RPU가 아니라 Max capacity와 Maximum RPU hours usage limit다.

개발 workgroup은 낮은 base capacity와 짧은 idle 정책으로 둔다.
운영 BI workgroup은 월요일 오전, 월말 결산, 배치 집계 피크를 따로 측정한다.
최대 RPU hours는 일·주·월 단위로 걸고, 초과 시 alert만 보낼지 query off까지 할지 정한다.
RMS 저장소, manual snapshot, cross-region snapshot, Spectrum의 S3와 Glue 비용을 견적서에 따로 적는다.
connection pool의 health-check query가 비용을 만들 수 있으므로 validation query 주기를 검토한다.

이 조건이면 Redshift 구축은 빠르게 시작할 수 있지만, 피크 사용량을 모르는 상태에서 높은 Max capacity를 열어두는 계획은 보류하는 편이 낫다.

Snowflake 예산은 warehouse 시간을 사람 단위로 본다

Snowflake 공식 문서는 전체 비용을 compute, storage, data transfer로 나누고, compute는 consumed credits와 credit price를 곱해 계산한다고 설명한다.

warehouse 크기는 X-Small 1 credit/hour에서 시작해 Small 2, Medium 4, Large 8, X-Large 16처럼 커진다.

크기를 한 단계 올리는 결정은 단순 성능 옵션이 아니라 매시간 credit 배수를 바꾸는 구매 결정이다.

Snowflake 문서는 warehouse가 초 단위로 계산되지만 시작할 때 60-second minimum이 있고, 기본 auto-suspend와 auto-resume을 쓸 수 있다고 설명한다.

업무	warehouse 분리 기준	비용 통제	보류 신호
적재	Small 또는 Medium에서 파일 수와 적재 시간을 먼저 본다	스케줄 묶음과 자동 정지	짧은 task가 1분 미만으로 계속 깨움
BI	업무 시간 사용자와 피크 보고서를 분리한다	auto-suspend, query timeout, 전용 role	모든 dashboard가 같은 Large를 깨움
무거운 배치	월말 집계와 임시 분석을 별도 warehouse로 둔다	작업 완료 후 suspend와 tag 기록	batch 실패 재시도가 밤새 반복
데이터 과학	notebook형 탐색을 운영 BI와 분리한다	credit quota와 사용 시간 제한	임시 사용자가 owner 없이 table 생성
공유·복제	외부 공유와 DR 비용을 별도 검토한다	data transfer와 storage 증가율 확인	복제 켠 뒤 삭제 정책이 없음

Snowflake resource monitor는 credit quota를 정하고 threshold 도달 시 alert나 suspend 같은 action을 낼 수 있다.

공식 문서의 예시처럼 1000 credits quota에서 warehouse 700 credits와 cloud services 300 credits가 합쳐져 threshold 판단에 들어갈 수 있다는 점도 예산 리뷰에 넣어야 한다.

BigQuery는 쿼리 전에 비용을 보이게 만든다

BigQuery는 on-demand per TiB processed 방식과 capacity slot-hours 방식을 동시에 이해해야 비용 오해가 줄어든다.

Google Cloud 공식 문서는 on-demand에서 custom daily query quota를 걸 수 있고, query validator와 dry run으로 실행 전 처리 바이트를 추정하라고 설명한다.

문서 예시는 dry run 응답에 10,918 bytes processed 같은 값이 나오며, 콘솔 query validator도 읽을 바이트 추정치를 보여준다고 안내한다.

1단계: 정기 BI와 임시 분석 project를 분리하고 결제 책임자를 붙인다.
2단계: on-demand project에는 maximum bytes billed와 custom daily quota를 먼저 둔다.
3단계: 반복 dashboard는 예약 슬롯과 edition 기능 제한을 따져본다.
4단계: table preview와 bq head로 탐색하고, LIMIT만 붙인 비클러스터 테이블 조회를 비용 절감으로 착각하지 않는다.
5단계: dry run 결과의 bytes processed를 티켓이나 PR 설명에 남긴다.
6단계: 저장소 과금 방식은 dataset별 설정과 장기 보관 정책을 따로 확인한다.

이 경우는 데이터팀이 SQL을 많이 쓰지만 사용자가 예산 책임을 보지 못하는 조직이다.

BigQuery 구축 비용은 엔진 자체보다 project, quota, reservation, dataset owner를 누가 관리하는지에서 먼저 안정된다.

데이터레이크와 웨어하우스 예산을 섞지 않는다

AWS 비교 문서는 데이터레이크가 정형, 반정형, 비정형 데이터를 폭넓게 저장하고, 데이터웨어하우스는 정제된 정형 분석과 보고에 맞는다고 설명한다.

오늘 발행 후보는 데이터웨어하우스 구축 비용이므로 S3 raw zone과 Athena 중심 예산은 데이터레이크 글로 분리하고, 여기서는 반복 BI와 정형 mart의 compute 예산을 중심으로 본다.

둘을 섞으면 데이터레이크 저장 단가가 싸다는 이유로 웨어하우스 피크 컴퓨트 비용이 가려진다.

구분	주요 비용	맞는 업무	같이 보면 좋은 내부 글
데이터레이크	S3 저장소, Glue ETL, Athena scan, catalog	원본 보존, 로그, ML feature, 탐색 분석	데이터레이크 구축 비용 글
데이터웨어하우스	compute hour, credit, slot, storage, concurrency	정형 KPI, BI 보고서, 재무·영업 mart	Snowflake 비용 최적화 글
Lakehouse	table format, compaction, warehouse 연동, governance	원본 보존과 트랜잭션 table 병행	Databricks Snowflake 비교 글
CDC 미러링	복제 실행, 중복 저장, 지연 모니터링, 재처리	운영 DB 변경을 분석계로 전달	Postgres CDC Snowflake 글

데이터웨어하우스 구축 비용이 비싸다고 느껴지면 먼저 workload를 네 갈래로 쪼개야 한다.

실시간 운영 분석, 반복 보고서, 월말 배치, 임시 탐색을 한 warehouse로 묶는 계획은 거의 항상 과다 견적으로 이어진다.

실무 시나리오 1: 중견 이커머스 BI 전환

실무 시나리오 1은 주문, 결제, 재고, 광고 데이터를 매일 적재하고 25명의 분석가가 업무 시간에 dashboard를 보는 이커머스 팀이다.

Snowflake로 보면 적재용 Small warehouse 2 credits/hour를 하루 6시간, BI용 Medium warehouse 4 credits/hour를 월 160시간, 월말 배치 Large 8 credits/hour를 월 16시간 쓰는 가정을 둘 수 있다.

credit 가격을 공식 견적서의 예시 값으로 $2라고 놓으면 적재 360 credits, BI 640 credits, 배치 128 credits로 월 1,128 credits가 된다.

이 예시는 compute만 $2,256이고 storage, cloud services 초과분, data transfer, 보안 운영 시간을 아직 더하지 않은 숫자다.

이 조건이면 첫 PoC의 성공 기준은 쿼리 속도보다 업무별 warehouse 분리와 auto-suspend가 실제로 작동하는지다.

업무	월 사용량 예시	공식 단위 근거	월 비용 예시
적재 warehouse	Small 2 credits/hour × 180 hours	Snowflake warehouse size table	360 credits
BI warehouse	Medium 4 credits/hour × 160 hours	Snowflake warehouse size table	640 credits
월말 batch	Large 8 credits/hour × 16 hours	Snowflake warehouse size table	128 credits
compute 합계	1,128 credits × $2/credit 예시	Snowflake overall cost example의 credit 계산 방식	$2,256
저장소	압축 후 20 TB 가정	Snowflake storage는 평균 on-disk bytes와 TB 단가 기준	계약 단가로 별도 계산

실무 시나리오 2: Redshift Serverless로 월 피크를 제한

실무 시나리오 2는 운영 보고서 사용량이 월말에 몰리고 평소에는 분석 요청이 낮은 제조 데이터팀이다.

Redshift Serverless를 쓰면 query가 없을 때 compute 과금이 멈추는 장점이 있지만, 월말 피크에서 자동 scaling이 예산을 넘길 수 있다.

공식 문서의 Max capacity 예시는 base 256 RPUs와 Max 512 RPUs를 두어 3일간 갑자기 높은 통계 보고서 부하가 와도 상한을 잡는 상황을 설명한다.

이 경우는 응답 속도 SLA가 분명한 dashboard와 느려져도 되는 ad-hoc 분석을 workgroup이나 사용자 정책으로 나누는 편이 안전하다.

반대로 모든 사용자가 같은 workgroup에서 월말 쿼리를 던지는 구조라면 저렴한 서버리스 선택보다 쿼리 중지 기준과 알림 기준을 먼저 정해야 한다.

보안·권한 비용은 초기에 넣어야 싸다

데이터웨어하우스는 정제된 지표를 제공하기 때문에 원본 데이터레이크보다 더 많은 사람이 접근하게 된다.

마스킹 정책, row-level policy, role hierarchy, 감사 로그, 키 관리, 승인 기록은 나중에 붙이면 쿼리, dashboard, ETL 작업을 함께 고쳐야 한다.

보안 항목	초기 포함 기준	비용 누락 지점	검증 방법
역할 설계	분석가, 엔지니어, 재무, 외부 파트너 role 분리	공용 관리자 권한 회수 작업	월 1회 role grant export 리뷰
민감정보	PII column tag와 masking 정책	이미 만든 mart 재생성과 dashboard 수정	샘플링 query와 DLP 결과 대조
쿼리 감사	사용자, warehouse, query tag, 비용 tag 기록	장애나 감사 요청 때 근거 수집 지연	월별 top cost query 리뷰
데이터 보존	Time Travel, snapshot, clone, backup 기간 분리	테스트 clone과 오래된 snapshot 누적	삭제 후보 table과 owner 목록
계정 운영	SSO, MFA, break-glass 계정, 퇴사자 회수	예외 계정 장기 유지와 접근 로그 공백	IdP와 warehouse 사용자 대조

보안팀이 PoC 끝나고 들어오면 비용은 기능 라이선스가 아니라 재작업 시간으로 터진다.

그래서 첫 견적서에는 warehouse 크기와 함께 role matrix, audit retention, 민감정보 처리 범위를 같은 장에 넣어야 한다.

견적서와 PoC에 넣을 스켈레톤

아래 YAML은 데이터웨어하우스 구축 비용 견적을 받을 때 단가와 통제 항목을 빠뜨리지 않기 위한 내부 검토용 스켈레톤이다.

# warehouse_budget_review.yaml
# 목적: 데이터웨어하우스 구축 비용을 컴퓨트, 저장소, 쿼리, 보안, 운영으로 분리해 검토한다.
# 단가는 2026-08-28 확인한 공식 문서 예시이며, 실제 견적 전 리전과 계약 조건을 다시 확인한다.

project:
  primary_keyword: 데이터웨어하우스 구축 비용
  checked_date: 2026-08-28
  owner:
    data: analytics-platform-team
    finance: finops
    security: data-security

published_unit_facts:
  redshift_serverless_starting_compute_usd_hour: 1.50
  redshift_serverless_minimum_charge_seconds: 60
  redshift_serverless_base_rpu_min: 4
  redshift_serverless_base_rpu_max: 1024
  redshift_serverless_max_capacity_example_rpu: 512
  redshift_managed_storage_us_east_usd_gb_month: 0.024
  redshift_reservation_discount_1_year_percent: 24
  redshift_reservation_discount_3_year_percent: 45
  snowflake_x_small_credits_hour: 1
  snowflake_small_credits_hour: 2
  snowflake_medium_credits_hour: 4
  snowflake_large_credits_hour: 8
  snowflake_x_large_credits_hour: 16
  snowflake_minimum_charge_seconds: 60
  snowflake_cloud_services_daily_included_percent: 10
  snowflake_resource_monitor_example_credit_quota: 1000

monthly_inputs:
  compressed_storage_tb: 20
  loading_hours_per_day: 6
  bi_query_hours_per_day: 8
  heavy_batch_hours_per_week: 4
  analyst_users: 25
  peak_concurrency: 12

controls:
  required:
    - separate_loading_bi_and_batch_compute
    - set_auto_suspend_or_idle_timeout
    - set_daily_or_monthly_spend_limit
    - tag_warehouse_by_owner_cost_center_env
    - review_snapshot_and_clone_storage
    - restrict_raw_pii_query_path
  reject_if:
    - single_shared_compute_for_all_users
    - no_query_budget_limit
    - no_owner_for_tables
    - backup_retention_not_priced
    - no_security_review_before_migration

아래 Python 예시는 실제 결제액 산정기가 아니라, 견적서 사용량 가정이 어디서 커지는지 빠르게 분해하는 검토 스크립트다.

# warehouse_cost_check.py
# 목적: 견적서의 데이터웨어하우스 월 사용량을 비용 축별로 나누는 내부 검토용 예시다.
# 실제 결제액 계산기는 아니며, 공식 가격표와 리전 단가로 숫자를 교체해야 한다.

FACTS = {
    "redshift_serverless_start_usd_hour": 1.50,
    "redshift_storage_usd_gb_month": 0.024,
    "snowflake_credit_price_example_usd": 2.00,
    "snowflake_xsmall_credits_hour": 1,
    "snowflake_small_credits_hour": 2,
    "snowflake_medium_credits_hour": 4,
    "snowflake_large_credits_hour": 8,
}


def snowflake_compute_cost(credit_price, loading_hours, bi_hours, batch_hours):
    credits = (
        FACTS["snowflake_small_credits_hour"] * loading_hours
        + FACTS["snowflake_medium_credits_hour"] * bi_hours
        + FACTS["snowflake_large_credits_hour"] * batch_hours
    )
    return {"credits": round(credits, 2), "usd": round(credits * credit_price, 2)}


def redshift_storage_cost(compressed_tb):
    return round(compressed_tb * 1024 * FACTS["redshift_storage_usd_gb_month"], 2)


print(snowflake_compute_cost(2.00, loading_hours=180, bi_hours=160, batch_hours=16))
print({"redshift_storage_usd": redshift_storage_cost(20)})

스켈레톤의 숫자는 공식 문서와 예시에서 가져온 기준점이므로 실제 도입 전에는 선택 리전, 계약 유형, 환율, 세금으로 바꿔야 한다.