데이터 로딩과 인제스천 — Stage, COPY INTO, Snowpipe
55 Snowflake Interview Questions Hiring DEs Actually Ask (2026) — 미상 (데이터 엔지니어 인터뷰 준비 블로그, 2026) Data Loading & Ingestion Q11-Q20 (pp.5-7)
이 모듈을 다 읽으면
- Stage의 종류(User/Table/Named, Internal vs External)를 구분하고 각각의 용도를 판단할 수 있다
- COPY INTO와 Snowpipe의 과금·운영 모델 차이를 설명할 수 있다
- ON_ERROR 옵션별 동작과, 실제 Snowflake가 제공하는 로드 오류 디버깅 도구를 정확히 설명할 수 있다(정정)
- 적재 시 중복 방지 메커니즘(로드 메타데이터)의 동작 범위를 설명할 수 있다
Stage는 데이터가 테이블로 적재되기 전 머무는 중간 저장소이며, 내부 스테이지(User/Table/Named)와 외부 스테이지(고객 소유 클라우드 스토리지)로 나뉜다. 벌크 적재에는 사용자가 웨어하우스를 직접 띄워야 하는 COPY INTO가, 실시간에 가까운 지속 적재에는 서버리스로 동작하는 Snowpipe가 적합하며 과금 모델도 각각 웨어하우스 가동 시간과 처리된 데이터량으로 다르다. 다만 원문이 로드 오류 디버깅 도구로 언급한 'REJECTED_RECORDS 파라미터'는 실제 Snowflake COPY INTO에 존재하지 않는 이름이며, 실제로는 VALIDATION_MODE 옵션과 VALIDATE 테이블 함수, COPY_HISTORY를 사용해야 한다.
Stage의 종류와 PUT/GET
Stage는 파일이 테이블로 로드되거나 테이블에서 언로드되기 전에 임시로 머무는 위치다. 내부 스테이지(Internal Stage)는 Snowflake 환경 안에 있으며 Snowflake가 직접 관리한다. 내부 스테이지는 다시 세 종류로 나뉜다 — 모든 사용자에게 자동 할당되어 다른 사용자와 공유할 수 없는 User Stage, 각 테이블에 자동 할당되어 해당 테이블로만 로드 가능한 Table Stage, 그리고 CREATE STAGE 명령으로 수동 생성해 여러 사용자·테이블에서 공유할 수 있는 Named Stage(가장 유연하다).
외부 스테이지(External Stage)는 고객이 소유한 클라우드 스토리지(S3, GCS, Azure Blob) 버킷을 가리키는 포인터로, 다른 클라우드 서비스가 만들어내는 데이터를 다루는 프로덕션 파이프라인에서 선호된다.
PUT 명령은 로컬 머신이나 서버의 파일을 내부 스테이지로 업로드하는 데 쓰이며, 보통 SnowSQL 같은 CLI를 통해 실행한다. 중요한 제약으로, PUT은 외부 스테이지에는 사용할 수 없다 — 외부 스테이지에 파일을 올릴 때는 aws s3 cp 같은 클라우드 제공자의 네이티브 도구를 써야 한다. GET 명령은 PUT의 역방향으로, 스테이지의 파일을 로컬 파일 시스템으로 내려받을 때 쓰인다.
핵심 포인트
- 내부 스테이지는 User(개인용, 공유 불가)/Table(테이블 전용)/Named(공유 가능, 가장 유연) 세 종류로 나뉜다
- 외부 스테이지는 고객 소유 클라우드 스토리지를 가리키며 프로덕션 파이프라인에서 선호된다
- PUT은 로컬→내부 스테이지 업로드 전용이며 외부 스테이지에는 사용할 수 없다(외부는 클라우드 네이티브 도구 사용)
COPY INTO vs Snowpipe
COPY INTO는 대량의 과거 데이터를 한 번에 적재하는 벌크 로딩에 적합하다. 사용자가 직접 가동시킨 가상 웨어하우스가 필요하며, 그 웨어하우스의 가동 시간만큼 과금된다. 대신 로딩 과정을 세밀하게 제어할 수 있다는 장점이 있다.
Snowpipe는 실시간 또는 준실시간 인제스천에 적합한 서버리스·지속 적재 서비스다. 파일이 스테이지에 도착하면 클라우드 네이티브 알림(AWS S3 이벤트 알림, Azure Event Grid 등)이 트리거되어 '파이프(Pipe)' 객체가 COPY 문을 자동 실행한다. 서버리스이기 때문에 사용자가 웨어하우스를 관리할 필요가 없고, 과금도 웨어하우스 가동 시간이 아니라 실제로 적재된 데이터량(컴퓨트 사용량)을 기준으로 이루어진다 — '설정해두고 잊어버리는(set it and forget it)' 지속 스트림 처리에 적합하다.
핵심 포인트
- COPY INTO는 사용자 관리 웨어하우스가 필요한 벌크 로딩용이며 웨어하우스 가동 시간으로 과금된다
- Snowpipe는 클라우드 이벤트 알림으로 트리거되는 서버리스 지속 적재 서비스다
- Snowpipe는 웨어하우스 가동 시간이 아니라 실제 처리된 데이터량 기준으로 과금된다
오류 처리 옵션과 실제 디버깅 도구 — 정정
COPY INTO는 ON_ERROR 파라미터로 오류 발생 시 동작을 정의한다. CONTINUE는 유효한 행만 적재하고 오류가 난 행은 건너뛰며, SKIP_FILE은 파일 내에 오류가 하나라도 있으면 그 파일 전체를 건너뛴다. ABORT_STATEMENT는 오류가 발견되는 즉시 전체 로드 작업을 중단시킨다.
정정 — 원문은 로드 오류를 디버깅하는 방법으로 'VALIDATE 함수를 조회하거나 REJECTED_RECORDS 파라미터를 사용한다'고 서술하지만, Snowflake COPY INTO에는 REJECTED_RECORDS라는 이름의 파라미터가 존재하지 않는다. 실제로 제공되는 디버깅 도구는 다음과 같다: (1) COPY INTO 문에 VALIDATION_MODE = 'RETURN_ERRORS' (또는 RETURN_N_ROWS 등)를 지정해 실제로 데이터를 적재하지 않고 어떤 오류가 발생할지 미리 확인하는 '드라이런', (2) VALIDATE(<table_name>, JOB_ID => '_last') 테이블 함수로 직전 로드에서 발생한 오류를 조회하는 방법, (3) COPY_HISTORY 테이블 함수나 INFORMATION_SCHEMA 뷰로 과거 로드 이력과 오류 건수를 조회하는 방법이다.
핵심 포인트
- ON_ERROR의 CONTINUE/SKIP_FILE/ABORT_STATEMENT는 각각 행 단위 스킵/파일 단위 스킵/즉시 중단으로 동작한다
- 정정: 'REJECTED_RECORDS'라는 파라미터는 실재하지 않으며, 실제로는 VALIDATION_MODE 옵션(드라이런)을 사용한다
- VALIDATE 테이블 함수와 COPY_HISTORY(또는 INFORMATION_SCHEMA)로 과거 로드의 오류를 조회할 수 있다
중복 적재 방지와 VARIANT 크기 제한
Snowflake는 '로드 메타데이터'를 통해 이미 처리된 파일을 추적한다. 특정 테이블에 대해 COPY INTO나 Snowpipe를 통해 적재된 파일의 이력을 최근 64일간 보관하며, 동일한 파일명과 체크섬을 가진 파일이 다시 감지되면 자동으로 건너뛰어 중복 적재를 막는다. 이 동작을 우회하려면 FORCE = TRUE 파라미터를 사용할 수 있지만, 의도치 않은 중복 적재를 유발할 수 있어 신중하게 써야 한다.
또한 데이터를 URL에서 직접 로드할 수는 없다 — 데이터는 먼저 지원되는 클라우드 스토리지 위치(외부 스테이지)에 두거나 PUT으로 내부 스테이지에 올려야 한다. 반정형 데이터를 담는 VARIANT 컬럼은 압축된 상태 기준 최대 16MB까지 저장할 수 있으며, 이보다 큰 JSON 문서는 사전에 분할하거나 평탄화해야 한다.
핵심 포인트
- 로드 메타데이터는 최근 64일간 적재된 파일명·체크섬 이력을 보관해 동일 파일의 중복 적재를 자동으로 방지한다
- FORCE = TRUE로 중복 방지를 우회할 수 있지만 의도치 않은 재적재 위험이 있어 신중히 사용해야 한다
- VARIANT 컬럼은 압축 기준 최대 16MB까지 저장 가능하며, 초과 시 사전에 분할·평탄화가 필요하다