2026년 Snowflake: 아키텍처, SQL, 데이터 엔지니어 면접 질문

Snowflake 면접 질문은 데이터 엔지니어가 SQL 문법뿐 아니라 플랫폼의 분리된 아키텍처를 이해하고 있는지를 검증합니다. Snowflake가 개척한 멀티 클러스터 공유 데이터(multi-cluster shared data) 설계는 스토리지, 컴퓨트, 서비스를 세 개의 독립된 계층으로 분리하며, 이 분리가 팀이 플랫폼 위에서 내리는 거의 모든 성능과 비용 관련 결정을 설명합니다. 이 가이드는 Snowflake 아키텍처, 2026년에도 쿼리를 빠르고 저렴하게 유지하는 SQL 패턴, 그리고 실제 프로덕션 경험을 드러내는 면접 질문을 다룹니다.

Snowflake 아키텍처: 스토리지, 컴퓨트, 클라우드 서비스

Snowflake 아키텍처의 가장 큰 특징은 스토리지와 컴퓨트가 물리적으로 분리되어 있다는 점입니다. 데이터는 Amazon S3나 Azure Blob Storage 같은 클라우드 오브젝트 스토어를 기반으로 하는 중앙 집중식 스토리지 계층에 단 한 번만 저장됩니다. 임의의 개수의 컴퓨트 클러스터가 데이터를 복사하지 않고도 동일한 데이터를 동시에 읽을 수 있으며, 이 방식은 원래 엔지니어링 팀이 2016년 SIGMOD 논문에서 설계를 소개하며 multi-cluster shared data라고 명명한 접근법입니다.

스토리지 계층은 데이터를 micro-partition이라 불리는 불변의, 압축된 컬럼형 파일로 보관합니다. 사용자는 이 파일들을 직접 관리하지 않습니다. Snowflake가 파일을 기록하고, 메타데이터를 추적하며, 회수합니다. 컴퓨트 계층은 virtual warehouse로 구성되며, 각 virtual warehouse는 Snowflake가 요청에 따라 프로비저닝하는 서버 클러스터입니다. 클라우드 서비스 계층은 두 계층 위에 자리 잡고 모든 것을 조율합니다. SQL을 파싱하고, 쿼리를 계획하며, 접근 제어를 강제하고, 트랜잭션을 관리하며, Time Travel이나 zero-copy cloning 같은 기능을 가능하게 하는 메타데이터를 저장합니다.

이 계층들이 독립적이기 때문에 warehouse는 데이터의 단 1바이트도 건드리지 않고 크기를 조정하거나 삭제할 수 있으며, 스토리지는 컴퓨트를 전혀 프로비저닝하지 않고도 페타바이트 규모로 늘어날 수 있습니다.

-- setup_warehouse.sql
-- Create an isolated compute cluster and a database.
CREATE WAREHOUSE analytics_wh
  WAREHOUSE_SIZE = 'MEDIUM'      -- 4 credits/hour, doubles each size step
  AUTO_SUSPEND = 60             -- suspend after 60s idle to stop billing
  AUTO_RESUME = TRUE            -- resume automatically on the next query
  INITIALLY_SUSPENDED = TRUE;

CREATE DATABASE sales_analytics;
USE WAREHOUSE analytics_wh;
USE DATABASE sales_analytics;

-- Storage and compute are independent: dropping the warehouse
-- leaves every table in sales_analytics untouched.

이 스크립트가 실행된 뒤 analytics_wh를 삭제하면 모든 컴퓨트 과금이 중단되지만, 새 warehouse가 생성되는 즉시 모든 테이블은 그대로 쿼리할 수 있습니다. 이 디커플링이야말로 면접에서 명확하게 설명해야 할 가장 중요한 개념입니다.

Virtual Warehouse가 Snowflake 컴퓨트를 확장하는 방식

virtual warehouse는 X-Small, Small, Medium, Large 등 티셔츠 사이즈 단위로 크기를 정하는 이름 붙은 컴퓨트 클러스터입니다. 한 단계 올라갈 때마다 서버 수와 시간당 크레딧 소비량이 모두 두 배가 되므로, Large warehouse는 Small보다 네 배 비싸지만 스캔이 많은 쿼리를 대략 네 배 빠르게 끝냅니다. 이 선형적인 가격 대비 성능 관계는, 가장 저렴한 선택이 종종 더 짧은 시간 동안 실행되는 더 큰 warehouse라는 의미입니다.

두 가지 확장 차원이 존재하며, 이 둘을 혼동하는 것은 흔한 면접 함정입니다. 수직 확장은 단일 warehouse의 크기를 조정해 하나의 쿼리를 더 빠르게 만듭니다. 수평 확장은 multi-cluster warehouse에 클러스터를 추가해 더 많은 동시 쿼리를 처리합니다. 오전 9시에 애널리스트 200명이 몰리는 대시보드에는 더 큰 warehouse가 아니라 더 많은 클러스터가 필요하고, 조 단위 행의 야간 백필에는 더 많은 클러스터가 아니라 더 큰 warehouse가 필요합니다.

-- scale_compute.sql
-- Multi-cluster warehouse: add clusters when concurrency rises and
-- remove them when demand falls. Each cluster is a separate MEDIUM engine.
ALTER WAREHOUSE analytics_wh SET
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4          -- up to 4 clusters during peak load
  SCALING_POLICY = 'STANDARD';   -- favor performance over credit savings

-- Resize vertically for one heavy job, then shrink back afterward.
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'XLARGE';
-- ... run the heavy backfill ...
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'MEDIUM';

이것을 경제적으로 만드는 요소는 AUTO_SUSPEND와 AUTO_RESUME입니다. 일시 중단된 warehouse는 비용이 전혀 들지 않으며, Snowflake는 최소 60초를 기준으로 초 단위로 과금합니다. 대화형 warehouse에 짧은 auto-suspend를 설정하면 유휴 클러스터가 쿼리 사이에 크레딧을 낭비하는 것을 방지합니다.

빠른 SQL을 위한 Micro-Partition과 Clustering Key

Snowflake는 모든 테이블을 micro-partition의 집합으로 저장하며, 각 micro-partition은 압축되지 않은 기준으로 50~500MB의 데이터를 컬럼형 포맷으로 담습니다. 모든 micro-partition에 대해 Snowflake는 각 컬럼의 최솟값과 최댓값을 메타데이터에 기록합니다. 쿼리가 특정 컬럼으로 필터링하면 옵티마이저가 그 메타데이터를 읽고 값 범위가 일치할 수 없는 파티션을 건너뛰는데, 이 과정을 partition pruning이라고 합니다. 이것이 Snowflake에 수동 인덱스가 필요 없는 이유입니다. pruning은 모든 컬럼에서 자동으로 일어납니다.

pruning은 필터 컬럼이 데이터가 적재된 순서와 상관관계가 있을 때 가장 잘 작동합니다. 날짜순으로 수집된 테이블은 날짜 범위 쿼리를 효율적으로 pruning합니다. 큰 테이블이 적재 순서와 무관한 컬럼으로 자주 필터링될 때는, clustering key가 관련된 행들을 여러 micro-partition에 걸쳐 함께 배치해 테이블이 커져도 pruning이 계속 효과적으로 유지되도록 합니다.

-- clustering.sql
-- Filters on naturally ordered columns prune partitions with no index.
SELECT order_date, SUM(amount_usd) AS revenue
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'
GROUP BY order_date;

-- For a multi-terabyte table queried by a non-load-order column,
-- a clustering key co-locates related rows to keep pruning effective.
ALTER TABLE orders CLUSTER BY (customer_region, order_date);

-- Inspect clustering depth before committing to a key.
SELECT SYSTEM$CLUSTERING_INFORMATION('orders', '(customer_region, order_date)');

clustering key는 공짜가 아닙니다. Snowflake는 이를 유지하기 위해 자동 백그라운드 서비스를 실행하며, 이 서비스는 크레딧을 소비합니다. 경험칙은 쿼리 프로파일이 pruning이 부실함을 보여주는 테라바이트 규모의 테이블에만 clustering key를 추가하는 것입니다. 더 작은 테이블은 스스로 pruning이 잘 되며, 성급한 clustering key는 돈을 낭비합니다. 이 트레이드오프를 설명하는 능력이 주니어와 시니어의 답변을 가르는 차이가 되는 경우가 많습니다.

데이터 적재와 변환: Snowpipe, Stream, Dynamic Table

세 가지 수집 패턴이 대부분의 워크로드를 커버합니다. 벌크 COPY INTO는 스테이징된 파일을 단일 명령으로 적재하며 예약된 배치 작업에 적합합니다. Snowpipe는 클라우드 스토리지 이벤트로 트리거되어 서버리스 마이크로배치로 파일을 지속적으로 적재하며 준실시간 도착에 적합합니다. Snowpipe Streaming은 1초 미만의 신선도가 중요할 때 저지연 API를 통해 개별 행을 밀어 넣습니다. 지연 시간과 파일 크기 요구사항에 따라 이 중에서 선택하는 것은 자주 나오는 면접 질문이며, 올바른 답은 "다운스트림 소비자가 실제로 필요로 하는 신선도에 달려 있다"로 시작합니다.

warehouse 내부의 변환은 역사적으로 Stream과 Task에 의존해 왔습니다. Stream은 테이블의 행 단위 변경(change data capture)을 캡처하고, Task는 예약된 일정에 따라 SQL을 실행해 그 변경을 소비하고 다운스트림으로 병합합니다.

-- incremental_pipeline.sql
-- A stream tracks row-level changes (CDC) on the raw landing table.
CREATE STREAM orders_stream ON TABLE raw_orders;

-- A task consumes the stream on a schedule and merges changes downstream.
CREATE TASK refresh_orders
  WAREHOUSE = analytics_wh
  SCHEDULE = '5 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
  MERGE INTO orders t
  USING orders_stream s ON t.order_id = s.order_id
  WHEN MATCHED THEN UPDATE SET t.amount_usd = s.amount_usd
  WHEN NOT MATCHED THEN INSERT (order_id, amount_usd)
    VALUES (s.order_id, s.amount_usd);

2026년에는 Dynamic Tables가 증분 변환을 표현하는 선호되는 방식이 되었습니다. Stream을 Task에 연결하고 병합을 직접 작성하는 대신, Dynamic Table은 목표 지연(target lag)과 쿼리를 선언하면 Snowflake가 증분 갱신을 자동으로 계산합니다. 결과를 신선하게 유지하면서 대부분의 오케스트레이션 보일러플레이트를 제거합니다.

-- dynamic_table.sql
-- Dynamic Tables replace the stream + task pattern with a declarative
-- target lag. Snowflake computes the incremental refresh automatically.
CREATE DYNAMIC TABLE daily_revenue
  TARGET_LAG = '5 minutes'
  WAREHOUSE = analytics_wh
AS
  SELECT order_date, SUM(amount_usd) AS revenue
  FROM orders
  GROUP BY order_date;

오픈 포맷 위에서 구축하는 팀을 위해, Snowflake의 Iceberg 테이블은 warehouse가 고객 자신의 클라우드 버킷에 저장된 Apache Iceberg 데이터를 읽고 쓸 수 있게 하여, Snowflake의 쿼리 엔진과 거버넌스를 유지하면서도 종속을 피합니다. 많은 팀은 버전 관리되고 테스트된 변환을 위해 Snowflake를 dbt와 결합하는데, 이 워크플로는 dbt 데이터 변환 및 테스트 가이드에서 다룹니다.

데이터 엔지니어를 위한 Snowflake 면접 질문

아래 질문들은 Snowflake 데이터 엔지니어링 면접에서 반복적으로 등장합니다. 강한 답변은 문법을 암송하기보다 기능을 스토리지-컴퓨트 분리와 연결합니다.

스토리지와 컴퓨트를 분리하면 어떤 문제가 해결되나요? 경합을 제거합니다. 대시보드를 실행하는 애널리스트, 피처를 학습시키는 데이터 사이언스 팀, 데이터를 적재하는 ELT 작업이 각자 자신의 warehouse에서 동일한 테이블을 대상으로, 자원을 두고 경쟁하거나 데이터를 복사하지 않고 실행할 수 있습니다. 컴퓨트는 무거운 작업을 위해 확장되고 유휴 상태에서는 일시 중단되는 반면, 스토리지 비용은 연결된 컴퓨트 양과 무관하게 일정하게 유지됩니다.

Time Travel과 zero-copy cloning은 어떻게 작동하나요? 둘 다 micro-partition의 불변성에 의존합니다. Snowflake는 micro-partition을 절대 덮어쓰지 않기 때문에, 이전 버전은 보존 기간(Enterprise에서는 최대 90일) 동안 디스크에 남아 있습니다. Time Travel은 그 이전 파티션을 가리켜 과거 타임스탬프 기준으로 테이블을 쿼리하고, CLONE은 어느 한쪽이 수정되기 전까지 스토리지를 복제하지 않고 동일한 파티션을 참조하는 새 테이블을 생성합니다. copy-on-write가 페타바이트 테이블의 클론을 즉각적이고 거의 무료로 만드는 요소입니다.

clustering key는 언제 정의해야 하나요? 적재 순서와 무관한 컬럼으로 자주 필터링되거나 조인되는 큰 테이블(대략 1테라바이트 이상)에서만, 그리고 쿼리 프로파일이 부실한 pruning을 확인한 뒤에만 정의합니다. clustering은 지속적인 유지 관리 크레딧 비용을 발생시키므로, 기본값이 아니라 의도적인 최적화입니다.

Snowflake 비용은 어떻게 통제하나요? warehouse 크기 조정, 공격적인 auto-suspend, 실제 동시성에 맞춘 클러스터 수, 그리고 크레딧 지출에 상한을 두는 resource monitor를 통해서입니다. resource monitor는 할당량에 도달하면 자동으로 알림을 보내거나 warehouse를 일시 중단할 수 있습니다.

-- cost_control.sql
-- A resource monitor caps credit spend and suspends warehouses
-- automatically when the monthly quota is reached.
CREATE RESOURCE MONITOR monthly_cap
  WITH CREDIT_QUOTA = 1000
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = monthly_cap;

Stream과 Task를 쓸까요, 아니면 Dynamic Table을 쓸까요? Dynamic Table은 목표 신선도가 요구사항이고 Snowflake가 갱신을 관리할 수 있는 선언적 파이프라인에 적합합니다. Stream과 Task는 변환에 명령형 제어, 부작용, 또는 단일 쿼리로 표현할 수 없는 로직이 필요할 때 여전히 올바른 도구입니다. 하나로 기본 설정하지 않고 각각이 어디에 맞는지 아는 것이 프로덕션 경험을 드러냅니다.

Snowflake의 ELT는 전통적인 ETL과 어떻게 다른가요? Snowflake의 저렴한 스토리지와 탄력적인 컴퓨트는 원시 데이터를 먼저 적재하고 그 자리에서 변환하는 것을 실용적으로 만드는데, 이는 ETL 대 ELT 아키텍처 가이드에서 탐구하는 패턴입니다. 전체 흐름을 준비하는 지원자는 더 넓은 데이터 엔지니어링 트랙과 함께 ETL 및 ELT 패턴 모듈을 훈련할 수 있습니다.

결론

• Snowflake 아키텍처는 스토리지, 컴퓨트, 클라우드 서비스를 세 개의 독립된 계층으로 분리하며, 거의 모든 설계 관련 답변은 그 분리로 거슬러 올라갑니다
• virtual warehouse는 더 무거운 단일 쿼리를 위해 수직으로, 더 높은 동시성을 위해 수평으로 확장하며, auto-suspend와 초 단위 과금은 유휴 컴퓨트를 무료로 유지합니다
• 컬럼별 min/max 메타데이터를 가진 micro-partition은 자동 partition pruning을 제공하며, 이것이 Snowflake에 수동 인덱스가 필요 없는 이유입니다
• clustering key는 pruning 부실이 입증된 테라바이트 규모의 테이블에만 추가하십시오. 유지 관리가 크레딧을 소비하기 때문입니다
• 수집 패턴을 필요한 신선도에 맞추십시오. 배치에는 벌크 COPY, 지속적인 마이크로배치에는 Snowpipe, 1초 미만의 지연에는 Snowpipe Streaming을 사용합니다
• 2026년에는 선언적 증분 변환에 Dynamic Tables를 우선하고, Stream과 Task는 명령형 로직을 위해 남겨 두십시오
• Time Travel과 zero-copy cloning은 모두 micro-partition의 불변성과 copy-on-write를 활용해 시점 쿼리와 즉각적인 클론을 저렴하게 만듭니다
• 적정 크기의 warehouse, 공격적인 auto-suspend, 동시성에 맞춘 클러스터, resource monitor로 비용을 통제하십시오