Snowflake

컴퓨트 모델 비교: 가상 웨어하우스 vs 서버리스 vs 클러스터

세 플랫폼 모두 2010년대 클라우드 네이티브 OLAP의 흐름 위에 있다 — 온프레미스 시절의 스토리지·컴퓨트 강결합을 끊고, 데이터를 클라우드 오브젝트 스토리지에 두면서 컴퓨트를 워크로드에 따라 독립적으로 확장할 수 있게 만들었다는 공통점이다. 다만 '사용자가 컴퓨트를 얼마나 직접 다뤄야 하는가'에서 세 플랫폼은 뚜렷이 갈린다.

BigQuery는 완전 서버리스 모델이다. 사용자가 소유·관리하는 컴퓨트 자원이라는 개념 자체가 없고, Google이 거대한 공유 컴퓨트 풀에서 쿼리마다 필요한 워커 수를 자동으로 결정해 배분한다. 고를 '잘못된' 클러스터 크기라는 것 자체가 존재하지 않을 만큼 자유롭지만, 그만큼 세밀한 컴퓨트 튜닝의 여지도 없다.

Snowflake는 그 중간에 있다. 사용자가 가상 웨어하우스 크기를 직접 고르지만 그 이후의 세부 사항(파일 레이아웃, 셔플, 캐싱)은 시스템이 처리한다. 워크로드끼리 서로 간섭하지 않고, 무언가 느려지면 원인을 특정 웨어하우스로 좁혀 진단할 수 있다는 점에서 예측 가능성이 높다.

Redshift는 가장 손이 많이 가는 모델이다. 리더 노드와 여러 컴퓨트 노드로 구성된 클러스터를 직접 사이징해야 한다. 과거에는 데이터가 노드에 직접 저장되어 컴퓨트 확장이 곧 스토리지 확장을 의미했지만, Managed Storage(RA3 노드) 도입 이후에는 데이터가 클라우드 오브젝트 스토리지에 저장되고 컴퓨트 노드는 무상태(stateless)가 되어 스토리지가 독립적으로 늘어날 수 있게 되었다. Redshift Serverless 옵션도 추가되어 클러스터 관리 부담을 줄일 수 있지만, 여전히 인스턴스 타입·노드 수 선택이라는 명시적 결정이 남아 있다.

스토리지·쿼리 실행 비교

BigQuery는 넓은 스캔에 최적화되어 있다 — 컬럼형 저장으로 필요한 컬럼만 읽고, 쿼리 도중에도 데이터 분포를 관찰해 남은 작업 실행 방식을 적응적으로 조정한다. 탐색적 분석이나 대규모 스캔에는 강하지만, 파티셔닝·필터링을 제대로 하지 않으면 예상보다 훨씬 많은 데이터를 읽어버릴 수 있다.

Snowflake는 마이크로파티션 메타데이터 기반 프루닝에 강하게 의존한다(모듈 2 참고). 그 결과 테이블이 커져도 쿼리가 어떤 데이터를 건드릴지 예측하기가 상대적으로 쉽고, 성능이 일관되게 유지되는 경향이 있다.

Redshift는 압축된 컬럼 블록에 데이터를 저장하고 자주 쓰이는 데이터를 로컬 SSD에 캐싱하며, 쿼리를 매번 해석하는 대신 스키마에 맞춰 최적화된 코드를 컴파일해 실행한다(자주 실행되는 쿼리는 컴파일된 코드를 재사용해 시간이 지날수록 유리해진다). 다만 분포 스타일(distribution style)이나 정렬 키(sort key) 설계가 나쁘면 데이터 쏠림으로 성능이 빠르게 나빠진다는 트레이드오프가 있다.

비용 모델 비교와 BigQuery 과금 최신화 — 정정

Snowflake는 가상 웨어하우스가 가동된 시간(초 단위)만큼 과금되며, Auto-Suspend와 워크로드별 웨어하우스 분리가 곧 비용 통제 수단이 된다.

정정 — 원문은 BigQuery의 비용을 오직 '쿼리가 스캔한 데이터량'에만 연동되는 것처럼 서술한다(온디맨드 스캔 바이트 과금). 이는 2023년 이전이라면 대체로 맞는 서술이지만, BigQuery는 2023년 BigQuery Editions(Standard/Enterprise/Enterprise Plus)를 도입하면서 슬롯(slot) 커밋 또는 오토스케일링 기반의 초 단위 컴퓨트 과금이라는 대안 모델도 제공하게 되었다. 즉 '데이터를 많이 스캔하는 대량·예측 가능한 워크로드'라면 스캔 바이트 기반 온디맨드 과금보다 슬롯 기반 과금이 오히려 유리할 수 있다 — 2026년 시점 기준으로 'BigQuery=오직 스캔량 과금'이라는 단순화는 정확하지 않다.

Redshift는 클러스터가 가동된 시간(또는 Serverless의 RPU 기반 사용량) 만큼 과금된다. 사이징이 잘 된 클러스터는 비용 효율적이지만, 유휴 상태에서도 켜져 있는 클러스터나 과도하게 큰 클러스터는 실제 작업량과 무관하게 비용이 계속 쌓인다는 리스크가 있다.

어떤 웨어하우스를 먼저 배울 것인가

세 플랫폼 중 어느 것도 절대적으로 '더 낫다'고 할 수 없으며, 선택은 대체로 맥락에 좌우된다. 이미 AWS 중심 인프라를 쓰는 팀은 자연스럽게 Redshift로 기울고, 주로 Google Cloud에서 작업하는 팀은 BigQuery와 잘 맞는다. Snowflake는 여러 클라우드에 걸친 유연성을 원하거나 특정 클라우드 제공자에 지나치게 묶이고 싶지 않은 팀, 혹은 깔끔한 SQL 중심 경험을 선호하는 팀에서 자주 선택된다.

초보자에게 가장 중요한 것은 '최고의 도구'를 좇는 것이 아니라, 컴퓨트·스토리지·성능·비용이 각 시스템에서 어떻게 동작하는지에 대한 근본 원리를 이해하는 것이다. 이 기본기가 갖춰지면 한 플랫폼에서 다른 플랫폼으로 전환하는 것은 생각보다 어렵지 않다.