월말 클라우드 청구서를 열어본 순간, 예상보다 두세 배 부풀어 오른 데이터 웨어하우스 비용에 놀란 경험이 한 번쯤 있을 것입니다. 특히 BigQuery, Redshift, Snowflake처럼 강력한 분석 플랫폼을 도입한 뒤, 쿼리 한 줄이 수십 달러를 소모한다는 사실을 뒤늦게 깨닫는 경우가 적지 않습니다. 문제는 단순히 “덜 쓰자”가 아니라, 과금 구조 자체를 이해하고 스토리지·쿼리 양쪽에서 체계적으로 비용을 줄이는 전략이 필요하다는 점입니다. 이 글을 끝까지 읽으면 세 플랫폼의 과금 메커니즘 차이를 명확히 파악하고, 파티셔닝과 클러스터링을 활용해 분석 비용을 실질적으로 절감하는 방법을 익힐 수 있습니다.
클라우드 데이터 웨어하우스의 비용은 크게 컴퓨팅(쿼리 처리)과 스토리지(데이터 저장)로 나뉩니다. 같은 쿼리라도 플랫폼에 따라 과금 기준이 완전히 다릅니다. BigQuery는 쿼리가 스캔한 데이터 용량(바이트)을 기준으로 요금을 매기고, Redshift는 클러스터 노드의 가동 시간으로 과금하며, Snowflake는 가상 웨어하우스의 크레딧 소비량을 측정합니다.
비유하자면 이렇습니다. BigQuery는 수도꼭지를 틀어 사용한 물의 양만큼 내는 수도 요금과 비슷합니다. 쿼리를 안 돌리면 비용이 0원에 가깝죠. 반면 Redshift는 집에 보일러를 설치해 놓고 24시간 켜 두는 방식입니다. 사용하든 안 하든 가동 시간만큼 비용이 발생합니다. Snowflake는 그 중간쯤으로, 필요할 때 보일러를 켜고 쓰지 않으면 자동으로 꺼지는 구조라고 보면 됩니다. Google Cloud 공식 가격 문서에서 온디맨드 가격이 TB당 $6.25로 명시되어 있으며, 이 수치는 스캔량 최적화의 중요성을 단적으로 보여줍니다.
BigQuery 온디맨드 모델에서 가장 흔한 실수는 SELECT *입니다. 10TB 테이블에서 컬럼 하나만 필요한데 전체를 스캔하면, 그 순간 약 $62.5가 청구됩니다. 반면 필요한 컬럼만 지정하면 스캔량이 수십 분의 1로 줄어듭니다. BigQuery는 컬럼 기반 저장 방식을 쓰기 때문에, SELECT 절에 명시한 컬럼만 읽는다는 점을 반드시 기억해야 합니다.
Redshift Serverless는 RPU(Redshift Processing Unit) 단위로 초당 과금합니다. 프로비저닝 방식은 노드 시간 기준이라 유휴 시간도 비용에 포함되죠. 실제 적용 사례를 살펴보면, 야간에 분석 쿼리가 거의 없는 팀이 프로비저닝 클러스터를 24시간 운영하다가 서버리스로 전환한 뒤 월 비용을 40% 이상 줄인 경우가 있습니다. Snowflake는 크레딧 단위로 과금하며, 웨어하우스 크기(X-Small~6X-Large)에 따라 분당 소비 크레딧이 달라집니다. 자동 일시 중지(auto-suspend) 기능을 5분에서 1분으로 줄이는 것만으로도 월간 수백 달러를 절약할 수 있습니다.
이처럼 서버리스 비용 모델 분석에서 다룬 것과 마찬가지로, 과금 구조를 정확히 이해하는 것이 비용 절감의 출발점입니다.
파티셔닝은 대형 테이블을 날짜나 특정 컬럼 값 기준으로 물리적으로 나누는 기법입니다. 마치 도서관에서 책을 장르별로 서가를 구분해 두는 것과 같습니다. “2월 매출 데이터를 보여줘”라는 쿼리가 들어오면, 전체 서가를 뒤지는 대신 2월 서가만 살펴보면 되니까요. BigQuery에서 날짜 파티셔닝을 적용한 테이블은 WHERE 절에 날짜 조건을 넣으면 해당 파티션만 스캔합니다. 1년치 데이터 중 1개월만 조회하면 스캔량이 약 1/12로 줄고, 비용도 비례하여 감소합니다.
파티셔닝만으로 부족할 때 클러스터링을 함께 적용하면 효과가 배가됩니다. 예를 들어, 이커머스 주문 테이블을 주문 날짜로 파티셔닝하고 고객 지역으로 클러스터링하면, “서울 지역 3월 주문”이라는 쿼리는 3월 파티션 내에서도 서울 블록만 읽습니다. 많은 사람이 처음에는 파티셔닝과 클러스터링의 차이를 혼동하는데, 파티셔닝은 큰 서랍을 나누는 것이고 클러스터링은 서랍 안에서 물건을 정렬해 두는 것이라고 이해하면 됩니다. BigQuery 파티셔닝 공식 문서에서 지원하는 파티셔닝 유형과 제한 사항을 상세히 확인할 수 있습니다.
BigQuery의 온디맨드 모델은 소규모 팀이나 간헐적 분석에 적합하지만, 쿼리가 많아지면 오히려 정액 요금제(BigQuery Editions)가 유리해집니다. Snowflake의 선불 크레딧은 할인율이 높지만, 사용하지 못한 크레딧이 만료되는 리스크가 있습니다. Redshift 프로비저닝은 일정한 워크로드에서 가성비가 뛰어나나, 트래픽 변동이 큰 환경에서는 낭비가 심해집니다.
파티셔닝이 만능은 아닙니다. 파티션 수가 너무 많아지면(BigQuery 기준 테이블당 최대 4,000개) 메타데이터 관리 오버헤드가 생기고, 작은 파티션이 지나치게 많으면 오히려 성능이 저하될 수 있습니다. 또한 WHERE 절에 파티션 키를 명시하지 않으면 전체 스캔이 발생하므로, 팀 내 쿼리 작성 가이드라인을 마련하는 것이 필수적입니다. 모든 환경에 동일한 전략이 통하지는 않으며, 데이터 특성과 쿼리 패턴에 맞춘 조정이 필요합니다.
지금 바로 시작할 수 있는 비용 절감 체크리스트를 정리합니다.
개인의 노력만으로는 한계가 있습니다. AWS Redshift 사용량 제한 가이드에서 권장하듯, 팀 단위로 쿼리 비용 상한을 설정하고 비효율 쿼리를 정기 리뷰하는 프로세스를 도입해야 합니다. 대시보드에 주간 비용 추이를 시각화하고, 비용 상위 10개 쿼리를 식별하는 것만으로도 상당한 효과를 볼 수 있습니다. 슬랙이나 팀즈 채널에 일일 비용 리포트를 자동 발송하는 팀도 늘어나고 있습니다.
클라우드 데이터 웨어하우스 비용 최적화의 핵심은 세 가지입니다. 첫째, 플랫폼별 과금 단위(스캔량·시간·크레딧)를 정확히 이해할 것. 둘째, 파티셔닝과 클러스터링으로 불필요한 데이터 스캔을 원천 차단할 것. 셋째, 비용 모니터링과 팀 가이드라인을 통해 지속적으로 관리할 것. 오늘 당장 가장 많이 실행되는 쿼리 3개를 뽑아 SELECT 절과 WHERE 절을 점검하는 것부터 시작해 보세요. 각 플랫폼의 세부 요금제 비교나 파티셔닝 실전 설정이 더 궁금하다면, 이 시리즈의 후속 글에서 깊이 있게 다룰 예정입니다.
대중교통을 자주 이용하는 청소년들에게 교통비는 큰 부담으로 작용할 수 있습니다.청소년후불교통카드는 잔액이 부족해도 후불로 이용할 수…
대중교통을 자주 이용하는 분들은 교통비지원 제도를 적극적으로 활용하는 것이 좋습니다.정부와 지방자치단체는 교통비 부담을 줄이기 위해…