✍️ 필사 모드: Snowflake 아키텍처 완전 가이드 2025: Compute-Storage Separation, Micro-Partition, Virtual Warehouse, Zero-Copy Clone 심층 분석

들어가며: 10년 만에 시장을 뒤엎은 회사

2012년의 결단

2012년, 세 명의 엔지니어 — Benoit Dageville, Thierry Cruanes, Marcin Zukowski — 가 데이터 웨어하우스 회사를 창업했다. 당시 시장은 Teradata, Oracle, IBM Netezza, Vertica가 지배했다. 모두 on-premises 어플라이언스. 수백만 달러짜리 하드웨어에 사전 약정된 용량.

그들은 한 가지 믿음을 가지고 있었다:

"클라우드 네이티브 데이터 웨어하우스가 모든 것을 바꿀 것이다."

2014년 Snowflake 출시. 2020년 IPO로 시가 총액 $70 billion. 역사상 가장 큰 소프트웨어 IPO. 10년 만에 시장을 완전히 바꿨다.

왜 성공했는가

기술적 이유는 하나의 핵심 결정에 있다:

"Compute와 Storage를 완전히 분리한다."

이 단순한 아이디어가 모든 것을 바꿨다:

• 탄력적 확장: Storage와 Compute 각자 독립 확장.
• 격리: 한 쿼리가 다른 쿼리에 영향 안 줌.
• 비용 효율: 사용한 만큼만 비용.
• 동시성: 수백 개 가상 웨어하우스 동시 실행.

전통적 shared-nothing MPP (Massively Parallel Processing) DB는 이걸 못했다. Teradata, Vertica는 compute와 storage가 같은 노드. 확장 = 데이터 재분배 = 엄청난 비용.

이 글에서 다룰 것

1. 3-tier 아키텍처: Storage, Compute, Service.
2. Micro-partition: Snowflake의 저장 단위.
3. Virtual Warehouse: 독립적인 컴퓨팅 클러스터.
4. Multi-cluster Warehouse: 자동 스케일링.
5. Time Travel & Fail-safe: 데이터 복구.
6. Zero-Copy Clone: 즉시 복제.
7. Query 실행: 최적화와 cache.
8. Snowflake vs 경쟁: BigQuery, Redshift, Databricks.

1. 3-Tier 아키텍처

Snowflake의 3개 층

Snowflake는 데이터베이스를 3개의 완전히 분리된 층으로 나눈다:

┌─────────────────────────────────────┐
│ Cloud Services Layer                │
│ (메타데이터, 옵티마이저, 보안, 거버넌스)  │
├─────────────────────────────────────┤
│ Query Processing (Compute) Layer    │
│ (Virtual Warehouses: 독립 클러스터)   │
├─────────────────────────────────────┤
│ Database Storage Layer              │
│ (S3/Azure Blob/GCS에 저장)           │
└─────────────────────────────────────┘

각 층은 독립적으로 확장되며, 서로에게 네트워크로만 통신한다.

Layer 1: Database Storage

가장 낮은 층. 실제 데이터가 저장됨.

특징:

• 클라우드 오브젝트 스토리지 사용 (AWS S3, Azure Blob, GCS).
• 영구적, 무한 확장, 저렴.
• 99.999999999% durability (11 nines).
• Snowflake 자체 독점 포맷 (columnar + 자체 인코딩).
• 압축 + 암호화.

사용자는 직접 접근 못 함. Snowflake의 compute가 중개.

비용: S3 가격 + 소량의 Snowflake 마진. 전통 데이터 웨어하우스의 1/10 이하.

Layer 2: Query Processing (Compute)

가상 웨어하우스(Virtual Warehouse) 라는 독립적인 클러스터들이 쿼리를 실행한다.

특징:

• 각 VW는 독립적인 MPP 클러스터 (여러 compute 노드).
• 여러 VW가 동시에 같은 데이터에 접근.
• VW 간 서로 영향 없음.
• 필요 시 생성, 사용 후 제거 (초 단위 과금).

크기:

• XS, S, M, L, XL, 2XL, 3XL, 4XL, 5XL, 6XL (2배씩 증가).
• XS = 1 노드, S = 2 노드, M = 4 노드, L = 8 노드, ..., 6XL = 512 노드.

Layer 3: Cloud Services

"두뇌". 모든 메타데이터와 조율 기능.

구성 요소:

• Query parser: SQL 분석.
• Query optimizer: 실행 계획 결정.
• Metadata manager: 테이블, 컬럼, 파티션 정보.
• Security: 인증, 인가, 암호화 키.
• Transaction manager: ACID 보장.
• Access control: RBAC.

특징:

• 상태가 거의 없음: 모든 상태는 Storage에.
• 서버리스: 사용자는 의식 못 함.
• 항상 실행: VW는 끌 수 있지만 Services는 항상.
• Free: 일정량까지 무료 (특정 임계 초과 시만 과금).

왜 이게 혁명적인가

전통 shared-nothing (Teradata):

Node 1: [Compute A] + [Storage A]
Node 2: [Compute B] + [Storage B]
Node 3: [Compute C] + [Storage C]

• Compute와 Storage가 같은 노드에 묶임.
• 확장하려면 노드 추가 → 데이터 재분배 (rebalancing) → 비싸고 느림.
• 일부 노드만 필요한 쿼리도 전체 클러스터 필요.

Snowflake:

Compute Layer:
  [VW 1 (4 nodes)] [VW 2 (8 nodes)] [VW 3 (2 nodes)]
         ↕                ↕               ↕
            Network
         ↕                ↕               ↕
Storage Layer (S3):
  [Table A] [Table B] [Table C] ...

• VW는 언제든 생성/삭제 (초 단위).
• Storage는 공유. 모든 VW가 같은 데이터 접근.
• VW 크기 변경은 즉시. 데이터 이동 없음.

2. Micro-Partition: Snowflake의 저장 단위

파일이 아닌 마이크로 파티션

Snowflake는 테이블을 micro-partition으로 분할한다:

• 크기: 압축 후 16 MB 이하 (일반적).
• 컬럼 지향 (columnar).
• Immutable: 한 번 쓰면 수정 안 됨.
• 자동 관리: 사용자가 파티션 키를 정의하지 않음.

왜 16 MB인가

너무 작음 (< 1 MB): 메타데이터 오버헤드, 파일 수 폭발. 너무 큼 (> 100 MB): 세밀한 pruning 불가, 병렬성 부족.

16 MB의 균형:

• 메타데이터 효율.
• 세밀한 pruning.
• 병렬 처리에 좋은 크기.
• S3 get 요청 최적.

Auto-clustering

Snowflake는 기본적으로 데이터 로드 순서로 micro-partition을 구성한다. 시간 기반 쿼리에 자연스럽게 좋음:

-- timestamp 컬럼이 시간순으로 로드되면
SELECT * FROM events WHERE event_time > '2025-04-15'
-- 최근 micro-partition만 스캔

Manual Clustering Key (선택적):

ALTER TABLE events CLUSTER BY (user_id, event_time);

특정 컬럼을 클러스터 키로 지정. Snowflake가 주기적으로 reclustering. 대량 데이터, 특정 쿼리 패턴에 유용.

주의: Auto-clustering은 추가 비용 (reclustering credits).

Pruning의 힘

Snowflake의 핵심 최적화: micro-partition pruning.

각 micro-partition의 메타데이터:

• 각 컬럼의 min/max.
• Null count.
• Distinct count.
• 각종 통계.

쿼리 시:

1. WHERE 조건 분석.
2. 메타데이터 확인.
3. 해당 micro-partition이 조건 만족 가능?
4. 불가능하면 완전히 건너뜀.

예시:

SELECT SUM(amount) FROM transactions WHERE date = '2025-04-15'

• Micro-partition 1: date ∈ [2025-01-01, 2025-02-01] → skip.
• Micro-partition 2: date ∈ [2025-04-10, 2025-04-20] → scan.
• ...

페타바이트 테이블에서 0.1% 미만만 스캔. 수 초 내 응답.

Columnar Storage

각 micro-partition 내부는 컬럼 지향:

Micro-partition structure:
[metadata header]
[column 1 data: compressed]
[column 2 data: compressed]
[column 3 data: compressed]
...

쿼리 시 필요한 컬럼만 읽기 (projection pushdown).

압축

Snowflake는 자동 압축:

• Dictionary encoding
• Run-length encoding
• Delta encoding
• Zstd 기반 압축

결과: 원본 대비 3~5배 압축. 스토리지 비용 절약.

3. Virtual Warehouse: 컴퓨팅의 단위

Virtual Warehouse란

Virtual Warehouse (VW) 는 독립적인 MPP 컴퓨팅 클러스터. 쿼리를 실제로 실행.

CREATE WAREHOUSE my_wh
  WAREHOUSE_SIZE = 'MEDIUM'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

USE WAREHOUSE my_wh;
SELECT * FROM large_table;

크기별 성능

2배 크기 = 2배 노드 = 2배 비용 = 2배 빠른 쿼리 (이론적 선형).

실제 성능 특성

Linear scaling: 데이터 병렬 처리가 완벽할 때 2배 크기 = 2배 속도.

다음 경우에 선형 확장 잘 됨:

• 큰 table scan.
• 대규모 group by.
• 대량 join.

다음 경우엔 덜:

• 작은 테이블 쿼리 (overhead 때문).
• Sequential 연산.
• 특정 skew.

Auto-Suspend / Auto-Resume

VW는 사용하지 않을 때 자동 일시 중지:

CREATE WAREHOUSE my_wh
  AUTO_SUSPEND = 60;  -- 60초 비활성 후 suspend

Suspended VW:

• 비용 없음.
• 하지만 cache도 사라짐.

Auto-resume: 쿼리가 도착하면 자동 재시작. 시작 시간: ~1-3초.

Multi-Cluster Warehouse

단일 VW는 고정 노드 수. 동시 쿼리가 많으면 큐에 쌓임.

Multi-cluster: 하나의 warehouse가 여러 클러스터 가능.

CREATE WAREHOUSE my_wh
  WAREHOUSE_SIZE = 'MEDIUM'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 10
  SCALING_POLICY = 'STANDARD';

• 부하가 늘면 자동으로 클러스터 추가 (최대 10개).
• 줄면 자동 축소.
• 각 클러스터는 독립적으로 쿼리 처리.

시나리오:

• 아침 9시: 1 cluster.
• 10시 회의 후 대시보드 폭주: 자동으로 5 cluster.
• 점심 시간: 2 cluster.
• 밤: 0 cluster (완전 suspend).

과금: 실제 활성 클러스터의 시간만.

Warehouse 격리

가장 중요한 이점: VW 간 완전 격리.

• ETL VW가 대량 로드 중이어도 BI VW는 영향 없음.
• 데이터 과학자의 무거운 쿼리가 프로덕션 대시보드 막지 않음.
• 각 팀이 자기 VW를 가짐.

전통 공유 클러스터의 악몽 ("누가 내 리포트 느려?")이 사라짐.

Size vs Multi-cluster

언제 크기 키우기:

• 단일 쿼리가 느림.
• 대량 데이터 처리.

언제 multi-cluster:

• 많은 동시 사용자.
• 각 쿼리는 빠르지만 큐가 길어짐.

둘을 조합 가능.

4. Query Execution: 최적화와 Cache

쿼리 실행 흐름

1. 사용자가 SQL 전송
2. Cloud Services Layer:
   - Parse
   - Analyze (catalog 조회)
   - Optimize (cost-based)
3. Execution plan 생성
4. Virtual Warehouse에 전송
5. VW node들이 병렬 처리
6. Storage에서 필요한 micro-partition fetch
7. 로컬 SSD cache에 저장
8. 처리 (vectorized execution)
9. 결과 취합
10. 사용자에게 반환

세 종류의 Cache

Snowflake는 세 단계의 cache를 유지:

1. Result Cache (Cloud Services Layer):

• 완료된 쿼리 결과를 24시간 유지.
• 정확히 같은 쿼리 반복 시 즉시 반환.
• Compute 비용 없음.
• 테이블 변경 시 무효화.

2. Warehouse Cache (VW 레벨):

• VW의 로컬 SSD에 micro-partition 캐싱.
• VW가 suspend되면 사라짐.
• 같은 VW에서 유사 쿼리 반복 시 빠름.

3. Metadata Cache (Cloud Services Layer):

• 테이블 메타데이터, 통계.
• Storage 접근 불필요.

Cache hit 시 성능:

• Result cache: 수 ms (compute 거의 없음).
• Warehouse cache: 수 초.
• Miss: 수 초~수 분.

Query Optimizer

Snowflake의 cost-based optimizer는:

1. 통계 활용: micro-partition 메타데이터.
2. Cardinality 추정: Join 결과 크기 예측.
3. Join 순서 최적화: 작은 테이블부터.
4. Predicate pushdown: 필터를 최하위로.
5. Projection pushdown: 필요한 컬럼만 읽기.
6. Partition pruning: 불필요한 micro-partition 스킵.

자체 특허: Snowflake의 optimizer는 많은 특허로 보호. 구체적 내부는 블랙박스.

Vectorized Execution

쿼리 실행은 vectorized:

• 한 번에 수천 row 처리 (column batch).
• SIMD 활용.
• CPU cache 효율.

ClickHouse, DuckDB와 비슷한 접근. 모두 현대 OLAP의 표준.

Query Profile

Snowflake UI의 Query Profile을 통해 상세 실행 통계 확인:

• 각 연산자의 시간.
• 읽은 데이터 크기.
• Network transfer.
• Spill to disk.
• Remote IO.

디버깅과 튜닝의 필수 도구.

5. Time Travel & Fail-Safe

Time Travel

Snowflake의 독특한 기능: 과거 시점의 데이터에 접근.

-- 1시간 전 데이터
SELECT * FROM orders AT(OFFSET => -3600);

-- 특정 timestamp
SELECT * FROM orders AT(TIMESTAMP => '2025-04-15 09:00:00'::timestamp);

-- 쿼리 ID 기준
SELECT * FROM orders BEFORE(STATEMENT => '01234-5678-9abc-def0');

어떻게 가능한가:

• Micro-partition은 immutable.
• 수정/삭제는 새 micro-partition 생성 + 구 partition을 "논리적으로" 제거.
• 구 partition은 일정 기간 유지.

유지 기간:

• Standard edition: 1일.
• Enterprise edition: 최대 90일.

용도

실수 복구:

-- 방금 실수로 DELETE
DELETE FROM users WHERE ...;  -- ❌

-- 5분 전으로 복원
CREATE OR REPLACE TABLE users AS
SELECT * FROM users AT(OFFSET => -300);

감사:

-- 어제 오후 3시의 상태
SELECT COUNT(*) FROM accounts 
AT(TIMESTAMP => '2025-04-14 15:00:00'::timestamp)
WHERE balance > 1000000;

테스트:

-- 특정 시점 데이터로 테스트
CREATE TABLE test_snapshot CLONE users AT(OFFSET => -86400);

Fail-Safe

Time Travel 기간이 지난 후에도 7일간 추가 보관:

• Snowflake 운영팀만 접근 가능.
• 고객 직접 접근 불가능.
• 재해 복구용.

Time Travel (최대 90일) + Fail-Safe (7일) = 최대 97일 복구 가능.

비용: 두 기간 동안 저장된 데이터도 storage 요금 발생. 대규모 테이블에선 주의.

6. Zero-Copy Clone: 즉시 복제

문제

전통 DB에서 "테이블 복사"는 시간이 걸린다:

• 10 TB 테이블 복사 = 수 시간.
• 공간도 2배.

개발/테스트 때마다 이렇게 할 수 없다.

Snowflake의 해결: Zero-Copy Clone

CREATE TABLE orders_test CLONE orders;

즉시 완료. 크기 무관. 추가 공간 거의 없음.

어떻게 가능한가:

1. Clone은 원본의 micro-partition 참조만 복사.
2. 실제 데이터는 공유.
3. Clone이나 원본 중 어느 것이 수정되면 그 micro-partition만 새로 생성.

Original table:
  ├── mp1 (10 MB)
  ├── mp2 (10 MB)
  └── mp3 (10 MB)
  Total: 30 MB

Clone table:
  ├── mp1 (참조)
  ├── mp2 (참조)
  └── mp3 (참조)
  Total: 0 MB additional

After modifying row in mp2 on clone:
  Original:
    ├── mp1 (참조, shared)
    ├── mp2 (참조, shared)
    └── mp3 (참조, shared)
  
  Clone:
    ├── mp1 (참조, shared)
    ├── mp2_new (10 MB, independent)
    └── mp3 (참조, shared)
  Additional: 10 MB (only changed partition)

스키마, DB 전체 clone

-- 스키마 clone
CREATE SCHEMA dev_schema CLONE prod_schema;

-- 데이터베이스 전체 clone
CREATE DATABASE dev_db CLONE prod_db;

수 TB 데이터베이스를 수 초 만에 clone. 개발/테스트 환경 구축의 혁명.

용도

개발 환경:

CREATE DATABASE dev_db CLONE prod_db;
-- Dev team이 실제 데이터로 테스트

A/B 테스트:

CREATE TABLE users_experimental CLONE users;
-- Experimental feature 적용

Backup:

CREATE TABLE orders_backup_20250415 CLONE orders;

스냅샷처럼 사용.

Rollback:

CREATE TABLE new_version CLONE orders;
-- 대규모 마이그레이션
-- 문제 생기면 new_version을 버리면 끝

제약

• Clone된 테이블의 수정은 원본에 영향 없음.
• Clone은 외부 stage (외부 파일)를 포함 못 함.
• Temporary 테이블 clone 불가.

7. Data Loading과 Unloading

Bulk Loading

COPY INTO:

COPY INTO orders
FROM 's3://my-bucket/orders/'
CREDENTIALS = (AWS_KEY_ID = '...' AWS_SECRET_KEY = '...')
FILE_FORMAT = (TYPE = 'CSV' FIELD_DELIMITER = ',' SKIP_HEADER = 1);

지원 포맷:

• CSV, TSV.
• JSON, JSONL, XML.
• Parquet, ORC, Avro.

대규모 로드 최적화:

• 파일 크기 100 MB~250 MB 권장.
• 병렬 처리: 여러 파일 동시 로드.
• VW 크기 클수록 빠름.

Snowpipe

연속 로드: 파일이 S3에 도착하면 자동 로드.

CREATE PIPE my_pipe
  AUTO_INGEST = TRUE
AS
COPY INTO orders FROM @my_stage;

• S3 event notification으로 트리거.
• 초~분 단위 지연.
• Serverless (VW 불필요).
• 사용량 기반 과금.

실시간에 가까운 데이터 입수.

External Tables

S3/GCS의 파일을 직접 쿼리 (로드 없이):

CREATE EXTERNAL TABLE ext_orders
  (order_id INT, amount DECIMAL)
  LOCATION = @my_stage
  FILE_FORMAT = (TYPE = 'PARQUET');

SELECT * FROM ext_orders WHERE amount > 1000;

장점:

• 로드 비용 없음.
• 원본 파일 그대로.
• data lake 스타일.

단점:

• Snowflake native 테이블보다 느림.
• 복잡한 최적화 제한.

Data Sharing

Snowflake Data Sharing: 다른 Snowflake 계정과 데이터 공유 without 복사.

CREATE SHARE my_share;
GRANT USAGE ON DATABASE mydb TO SHARE my_share;
GRANT SELECT ON TABLE mydb.public.orders TO SHARE my_share;

ALTER SHARE my_share ADD ACCOUNTS = partner_account;

소비자 측:

CREATE DATABASE shared_db FROM SHARE provider_account.my_share;
SELECT * FROM shared_db.public.orders;

특징:

• 데이터 이동 없음 (메타데이터만 공유).
• 실시간: 공급자의 변경 즉시 반영.
• Secure: 공급자 제어.
• 비용: 소비자는 자기 VW로만 쿼리. 공급자는 storage.

Snowflake Marketplace: 수천 데이터셋이 이 방식으로 공개.

8. Performance Tuning

Warehouse 사이징

원칙:

1. 작게 시작: XS부터.
2. 측정: 쿼리 시간 확인.
3. 2배 늘려 비교: 속도 2배 되는가?
4. 아니면 다른 문제: data skew, query plan 이슈.

경험칙:

• 작은 쿼리 (< 10 초): XS, S.
• 중간 쿼리 (10-60 초): S, M, L.
• 큰 쿼리 (1-10 분): M, L, XL.
• 매우 큰 (> 10 분): XL, 2XL, 3XL.

너무 큰 VW는 돈 낭비. 작은 쿼리엔 효과 없음.

Clustering Key

기본 auto-clustering이 느리면:

ALTER TABLE orders CLUSTER BY (customer_id, order_date);

언제 도움되는가:

• 테이블 > 1 TB.
• 특정 컬럼 기반 자주 필터.
• Range 쿼리 많음.

언제 도움 안 되는가:

• 작은 테이블.
• Random access 패턴.
• 로드 순서가 이미 최적.

Search Optimization

Point lookup (단일 row 조회)용 특수 인덱스:

ALTER TABLE events ADD SEARCH OPTIMIZATION ON EQUALITY(user_id);

• 수조 row 테이블에서 특정 user의 이벤트 즉시 검색.
• 추가 비용 (메모리 + credit).

Materialized Views

자주 집계되는 쿼리를 미리 계산:

CREATE MATERIALIZED VIEW daily_sales AS
SELECT date, SUM(amount) as total
FROM transactions
GROUP BY date;

• Snowflake가 자동 유지.
• 기본 테이블 변경 시 증분 업데이트.
• 제한: 특정 SQL 패턴만.

Query Acceleration Service (QAS)

대용량 table scan이 많은 쿼리를:

• Snowflake가 임시로 추가 리소스 할당.
• 쿼리 가속.
• Per-query 과금.

ALTER WAREHOUSE my_wh SET QUERY_ACCELERATION_MAX_SCALE_FACTOR = 8;

일반적인 튜닝 조언

1. EXPLAIN 활용: Query Profile 분석.
2. Pruning 확인: 몇 % 의 partition이 scan되나?
3. Spill 방지: 메모리 부족 시 disk spill → 느림.
4. Join 순서: 작은 테이블을 broadcast 유도.
5. Column pruning: SELECT * 피하기.
6. Filter 일찍: WHERE 조건을 subquery 안으로.

9. Snowflake vs 경쟁자

Snowflake vs AWS Redshift

Redshift:

• AWS의 native DW.
• 전통 MPP 기반.
• Redshift Serverless (2022): Snowflake 흉내.
• RA3 nodes: compute/storage 일부 분리.

Snowflake 우위:

• 완전한 분리: storage와 compute 독립적으로 확장.
• Multi-cluster warehouse: 동시성.
• Zero-copy clone.
• Cross-cloud: AWS, Azure, GCP 모두.

Redshift 우위:

• AWS 통합: IAM, S3, EMR과 매끄러움.
• 저렴: 지속 사용 시.
• Reserved instances로 추가 할인.

Snowflake vs BigQuery

BigQuery:

• Google의 완전 serverless DW.
• Dremel 기반 (Parquet의 원천).
• On-demand: 쿼리당 스캔한 데이터 과금.

BigQuery 우위:

• 진정한 serverless: VW 개념 없음. 자동 확장.
• 저렴한 소규모: 쿼리 적으면 매우 저렴.
• Google 생태계: GA, Ads, Vertex AI.

Snowflake 우위:

• 예측 가능한 비용: VW 시간 과금.
• 멀티클라우드.
• 세밀한 제어: VW 크기, 자동 스케일.

선택 기준:

• Google Cloud + ad hoc 분석 → BigQuery.
• 예측 가능한 엔터프라이즈 → Snowflake.

Snowflake vs Databricks

Databricks:

• Spark 기반 lakehouse.
• Delta Lake: ACID on data lake.
• ML + AI 중심.
• Unity Catalog: 거버넌스.

Databricks 우위:

• Unstructured data: 이미지, 텍스트.
• ML/AI 통합: MLflow.
• Streaming: Structured Streaming.
• 오픈 포맷: Delta, Parquet 기반.

Snowflake 우위:

• BI/SQL 중심 최적화.
• 더 쉬움: 단순 SQL.
• 더 빠른 시작.

수렴 추세:

• Snowflake도 ML (Snowpark), streaming 추가.
• Databricks도 BI (SQL Warehouse) 추가.
• 경계가 흐려지는 중.

Snowflake vs ClickHouse

ClickHouse:

• 오픈소스 columnar DB.
• 극한의 성능.
• 자체 호스팅 또는 ClickHouse Cloud.

ClickHouse 우위:

• 압도적으로 빠름 (특정 워크로드에서).
• 비용 효율: 동일 워크로드에 1/10 비용 가능.
• 실시간 분석: 짧은 지연.
• 오픈소스.

Snowflake 우위:

• 관리 편의성: 완전 관리형.
• 동시성: Multi-cluster warehouse.
• 엔터프라이즈 기능: Time travel, sharing.
• 생태계: 광범위한 통합.

10. 흔한 함정과 교훈

함정 1: 과도한 warehouse

증상: 월말 Snowflake 청구서 충격.

원인: 많은 VW가 계속 켜져 있음.

해결:

• AUTO_SUSPEND = 60 (1분).
• 사용하지 않는 VW suspend.
• Resource monitor 설정.

CREATE RESOURCE MONITOR my_monitor
  WITH CREDIT_QUOTA = 1000
  TRIGGERS 
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

함정 2: 너무 큰 warehouse

증상: 큰 VW 썼는데 성능은 비슷.

원인: 쿼리가 병렬화 안 됨. Overhead가 compute보다 큼.

해결:

• 작은 쿼리에 작은 VW.
• Query profile 분석.

함정 3: Clustering Key 남용

증상: Clustering 비용 폭발.

원인: 작은 테이블에 clustering 적용, 또는 너무 자주 바뀌는 데이터.

해결: 1 TB 이상 + 특정 필터 패턴일 때만 적용.

함정 4: Time Travel 비용 간과

증상: Storage 비용 증가.

원인: 90일 time travel로 설정된 대규모 테이블.

해결:

ALTER TABLE orders SET DATA_RETENTION_TIME_IN_DAYS = 7;

비즈니스 요구에 맞는 최소 기간.

함정 5: SELECT *

증상: 쿼리가 느림.

원인: 모든 컬럼을 읽음. Columnar 이점 상실.

해결: 필요한 컬럼만 명시.

함정 6: Cartesian Product

증상: 쿼리가 영원히 실행.

원인: JOIN 조건 누락.

-- 실수
SELECT * FROM a, b;  -- Cartesian!

-- 올바름
SELECT * FROM a JOIN b ON a.id = b.a_id;

Snowflake는 경고는 주지만 실행은 한다.

함정 7: JSON 남용

증상: JSON 컬럼 쿼리가 느림.

원인: JSON은 VARIANT 타입. 매번 파싱.

해결: 자주 쓰는 필드는 실제 컬럼으로 추출.

CREATE OR REPLACE TABLE events_flat AS
SELECT 
  raw:user_id::STRING AS user_id,
  raw:event_type::STRING AS event_type,
  raw:timestamp::TIMESTAMP AS timestamp,
  raw AS raw_data
FROM events;

11. 실전 사례

Capital One

미국 대형 은행. Snowflake 초기 대규모 고객.

규모:

• 수천 명의 사용자.
• 수백 TB 데이터.
• 수십 개 warehouses.

도입 효과:

• 기존 Teradata 대비 60% 비용 절감.
• 쿼리 시간 10배 단축.
• Multi-team 격리: 각 부서 자체 VW.

Instacart

2020-2021년 폭발적 성장.

Snowflake 역할:

• 주문 분석.
• 공급자 관리.
• 마케팅 attribution.
• A/B 테스트.

핵심: 탄력적 확장. 팬데믹 중 트래픽 5배 증가해도 자동 대응.

DoorDash

배달 플랫폼.

사용:

• 실시간 운영 대시보드.
• 드라이버 최적화.
• 메뉴 분석.
• 사기 탐지.

수천 명의 분석가와 데이터 과학자가 동시 사용.

Canva

디자인 툴. 수억 사용자.

Snowflake로:

• 사용자 행동 분석.
• 템플릿 추천.
• A/B 테스트.
• 제품 분석.

데이터 공유: 파트너와 Snowflake Data Sharing.

12. 미래와 최신 동향

Snowpark

Snowpark: Snowflake 내에서 Python, Java, Scala 실행.

from snowflake.snowpark import Session

session = Session.builder.configs(...).create()
df = session.table("orders")
result = df.filter(df.amount > 100).group_by("customer_id").count()
result.show()

Snowflake 내부에서 실행. 데이터 이동 없음. ML/Spark 워크로드 통합.

Snowflake ML

2024년 이후 ML 기능 대폭 확장:

• Cortex AI: LLM 함수 (translate, summarize, sentiment).
• Feature Store: ML 특성 관리.
• Model Registry.
• ML 지원 함수: PREDICT, ANOMALY_DETECTION.

Databricks와의 경쟁.

Unistore

Unistore: OLTP + OLAP 통합. 전통적 두 시스템을 하나로.

• Hybrid tables: 트랜잭션 + 분석.
• Row-store와 columnar 공존.

아직 실험적이지만 데이터베이스의 미래 방향.

Iceberg Tables

Apache Iceberg 테이블 포맷 지원:

• 오픈소스 테이블 포맷.
• 다른 엔진과 상호 운용.
• Lock-in 감소.

Snowflake가 오픈 생태계를 받아들이는 중요한 움직임.

Streaming

Streaming 기능 강화:

• Dynamic Tables: 자동 갱신 materialized view.
• Streams: Change data capture.
• Tasks: 스케줄링.

실시간 워크로드까지 영역 확장.

퀴즈로 복습하기

Node 1: [Compute A] + [Storage A]
Node 2: [Compute B] + [Storage B]
Node 3: [Compute C] + [Storage C]

Services Layer (metadata, optimizer, auth)
       ↕
Compute Layer (independent VWs)
       ↕ (network)
Storage Layer (S3/Blob/GCS)

SELECT SUM(amount) FROM orders WHERE date = '2025-04-15'

SELECT * FROM fact_orders f
JOIN dim_customers c ON f.customer_id = c.id
WHERE c.country = 'KR'

ALTER TABLE events ADD SEARCH OPTIMIZATION ON EQUALITY(user_id);

SELECT COUNT(*) FROM orders WHERE order_date = '2025-04-15'

ALTER TABLE events CLUSTER BY (user_id, event_date);

SELECT * FROM events WHERE event_data:user_id::INT = 12345

10명의 분석가 + 아침 9시 대시보드 새로고침
→ 수백 개 동시 쿼리
→ 큐에 쌓임
→ 모두 느려짐

ETL 작업이 대량 로드 중
→ 모든 다른 쿼리 영향
→ 대시보드 멈춤

ETL VW: Large, 24/7
BI VW: Medium, 업무 시간
Data Science VW: XL, 필요 시
Finance VW: Small, 월말

CREATE WAREHOUSE bi_wh
  WAREHOUSE_SIZE = 'MEDIUM'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 10
  SCALING_POLICY = 'STANDARD';

ALTER WAREHOUSE bi_wh SET AUTO_SUSPEND = 60;  -- 1분

Table "orders":
  Logical structure:
    Row 1, Row 2, Row 3, ... Row 1,000,000
  
  Physical storage:
    mp_001 (10 MB, rows 1-50000)
    mp_002 (10 MB, rows 50001-100000)
    mp_003 (10 MB, rows 100001-150000)
    ...
    mp_100 (10 MB, rows 999951-1000000)

CREATE TABLE orders_clone CLONE orders;

Table "orders_clone":
  Reference to same mp_001, mp_002, ..., mp_100

mp_001: 
  - referenced by: orders, orders_clone
mp_002:
  - referenced by: orders, orders_clone
...
mp_100:
  - referenced by: orders, orders_clone

UPDATE orders_clone SET amount = amount * 1.1 WHERE id = 500;

mp_001: referenced by orders, orders_clone (shared)
mp_002: referenced by orders (only)
mp_002_v2: referenced by orders_clone (only, NEW)
mp_003: referenced by orders, orders_clone (shared)
...

UPDATE orders SET amount = amount * 0.9 WHERE id = 700;

CREATE DATABASE dev_db CLONE prod_db;

-- 매일 아침 자동 실행
CREATE OR REPLACE DATABASE dev_db CLONE prod_db;
-- Dev team이 진짜 prod 데이터로 테스트

CREATE TABLE orders_new CLONE orders;
-- 새 스키마 적용 테스트
ALTER TABLE orders_new ADD COLUMN new_field STRING;
UPDATE orders_new SET new_field = ...;
-- 문제 있으면 DROP, 없으면 swap

-- Time travel + clone 조합
CREATE TABLE orders_restored CLONE orders AT(OFFSET => -3600);
-- 1시간 전 상태의 복사본

CREATE TABLE users_variant_A CLONE users;
CREATE TABLE users_variant_B CLONE users;
-- 각각 다른 알고리즘 적용

Raw data → Data Lake (S3)
            ↓
        Databricks (ML/ETL)
            ↓
        Snowflake (BI/분석)
            ↓
        End users (BI tools)

마치며: 클라우드 데이터의 청사진

핵심 정리

1. 3-tier architecture: Storage, Compute, Services 분리.
2. Micro-partitions: 16 MB immutable columnar units.
3. Pruning: 메타데이터 기반 파티션 스킵.
4. Virtual Warehouses: 독립적 MPP 클러스터.
5. Multi-cluster: 동시성을 위한 자동 확장.
6. Time Travel: 과거 데이터 접근.
7. Zero-copy clone: Immutability의 부산물.
8. Data Sharing: 실시간 파트너 공유.

Snowflake가 바꾼 것들

Snowflake는 단지 기술 혁신이 아니다. 산업을 재정의했다:

기술적으로:

• Compute/Storage 분리가 표준이 됨.
• Cloud-native DW가 기본.
• 예측 가능한 소비 기반 과금.

비즈니스적으로:

• 전통 어플라이언스 시장 (Teradata 등) 급감.
• 데이터 팀의 조직 구조 변화: 중앙 DBA → 분산 분석가.
• 데이터 기반 의사결정의 민주화.

개발자 경험:

• "DBA 기다리기" 없이 즉시 시작.
• 실패에 대한 공포 감소 (clone, time travel).
• 실험 문화 촉진.

한계와 비판

Snowflake는 완벽하지 않다:

1. Vendor lock-in: 전용 포맷. 탈출 어려움.
2. 비용 불투명: 예상보다 많은 청구서 흔함.
3. 소규모엔 과도: 수십 GB 데이터엔 overkill.
4. Streaming 약함: 전통적 배치 중심 설계.
5. SQL 중심: 복잡한 코드 로직엔 제한적.

이런 한계를 인식하고 선택해야 한다.

마지막 교훈

Snowflake의 성공은 기술 + 타이밍 + 실행의 결과다:

1. 기술: Compute-storage 분리의 올바른 구현.
2. 타이밍: 클라우드 성숙기 진입.
3. 실행: 엔터프라이즈 세일즈, 사용자 경험, 지속 혁신.

하나라도 빠졌으면 지금 위치에 없었을 것이다.

이는 **"최고의 기술만으론 부족하다"**는 교훈이다. Teradata는 기술적으로 뛰어났지만 비즈니스 모델이 구식이었다. Vertica는 먼저 columnar를 상용화했지만 클라우드 전환을 놓쳤다. Snowflake는 모든 것을 제대로 해서 승리했다.

당신이 다음에 데이터 플랫폼을 선택할 때, Snowflake의 내부 구조를 이해하는 것이 도움이 될 것이다:

• 왜 특정 쿼리가 느린지.
• 왜 특정 설정이 비용을 바꾸는지.
• 왜 특정 패턴이 성능을 좋게 만드는지.

그리고 더 중요하게, 이 아키텍처가 왜 그렇게 영향력 있는지를 이해하게 될 것이다. 많은 미래의 데이터 시스템이 이 청사진 위에 세워질 것이다. 이미 BigQuery, Databricks, Redshift 모두 그 방향으로 가고 있다.

클라우드 데이터의 미래는 Snowflake가 10년 전에 그린 것과 비슷하게 보일 것이다.

참고 자료

• The Snowflake Elastic Data Warehouse (SIGMOD 2016) - 원 논문
• Snowflake Documentation
• Snowflake Architecture
• Snowflake Blog
• Micro-partitions and Data Clustering
• Virtual Warehouses
• Time Travel
• Zero-Copy Cloning
• Snowflake vs BigQuery vs Databricks (comprehensive comparison)
• Building a Modern Data Platform on Snowflake (various sources)
• Dageville: How Snowflake Was Built