비용 — DuckDB 가 Snowflake 이길 때 (그리고 반대) · Data Engineering Quest

제일 자주 잊히는 production 고민

클라우드 warehouse 는 근사하고, 초 단위로 청구서를 끊어. 같은 워크로드가 머신 한 대의 DuckDB stack 에선 월 $50, Snowflake 에선 월 $5,000 일 수 있어 — 모양에 따라 그 반대일 수도 있고. 어느 게 어느 쪽인지 가려내는 눈이 2026 데이터 엔지니어 실력의 일부야.

머신 한 대의 DuckDB / Polars 가 이길 때

Disk 위 데이터가 500GB 미만이고 실한 머신 한 대에 워크로드가 들어갈 때.
워크로드가 batch 일 때 (하루 cron 몇 개) — 상시 인터랙티브 query 가 아니라.
동시성이 낮을 때 (분석가 한 명, 대시보드 몇 개).
서버 한 대 굴리는 운영 부담을 이미 지고 있거나 기꺼이 질 때.

클라우드 warehouse 가 이길 때

분석가 여럿과 BI 도구가 동시에 query 를 던질 때.
데이터가 1TB 를 넘거나 해마다 50% 씩 클 때.
인프라를 아예 안 굴리고 싶을 때 (DBA 없음, platform 팀 없음).
Cross-region 복제, 깊은 BI 통합, 자동 scaling 이 필요할 때.

자주 이기는 건 중간이야

Dev 와 즉석 분석은 local DuckDB, BI 도구가 붙는 production mart 는 진짜 warehouse. Storage 는 공유하고 (S3 / GCS / R2 의 Parquet), compute 는 consumer 마다 맞는 걸 붙이는 거야. 이렇게 가르면 dev 비용은 0 에 붙어 있고, production 은 warehouse 의 동시성과 신뢰성을 그대로 받아.

Code

Production warehouse 가 읽는 같은 Parquet 을 노트북-on-DuckDB 로 읽기·python

import duckdb

con = duckdb.connect()
con.execute("INSTALL httpfs; LOAD httpfs;")
con.execute("""
    SET s3_region='us-east-1';
    SET s3_access_key_id='...';
    SET s3_secret_access_key='...';
""")

# 같은 Parquet, 같은 query, 다른 compute — production S3 lake 에 대해 실행
result = con.sql('''
    SELECT date_trunc('month', order_date) AS month,
           SUM(amount_usd) AS revenue
    FROM 's3://my-warehouse/orders/year=2026/**/*.parquet'
    GROUP BY 1 ORDER BY 1
''').to_df()

Exercise

지난달 warehouse 비용 리포트를 꺼내 (대부분의 warehouse 에 있어). 제일 비싼 query / model 다섯 개에 대해 물어봐: 이거 노트북 DuckDB 에서 몇 초면 돌지 않아? 돈다면 — warehouse 에 두는 이유가 뭐야? 답이 정당할 때도 있고 (동시성, 거버넌스), 그냥 관성일 때도 있어.

비용 — DuckDB 가 Snowflake 이길 때 (그리고 반대)