증분 모델의 내부 동작과 incremental_strategy
50 dbt Interview Questions for Data Engineers (Real Answers, 2026) — 미상 (데이터 엔지니어링 커리어 블로그, 2026) Section 3: Incremental Models & Performance, Q19-Q21 (pp.6-7)
이 모듈을 다 읽으면
- 증분 모델이 첫 실행과 이후 실행에서 각각 어떤 SQL로 컴파일되는지 설명할 수 있다
- is_incremental() 블록이 왜 필요한지, 빠뜨리면 어떤 문제가 생기는지 설명할 수 있다
- 여러 incremental_strategy의 차이를 근거로 웨어하우스·데이터 특성에 맞는 전략을 판단할 수 있다
증분 모델은 첫 실행에서는 전체 SELECT로 테이블을 만들고, 이후 실행에서는 신규/변경분만 처리하는 MERGE·INSERT·DELETE+INSERT 문으로 컴파일된다. 어떤 행이 '신규'인지는 is_incremental() 블록의 필터가 결정하며, 이를 빠뜨리면 매번 원천 테이블 전체를 재처리해 증분의 의미가 사라진다. dbt는 이런 SQL 패턴을 incremental_strategy로 추상화해 웨어하우스별 최적 방식을 고를 수 있게 한다.
증분 모델의 내부 동작과 is_incremental()
증분 모델은 첫 실행에서 (table materialization처럼) 전체 SELECT로 테이블을 만든다. 이후 실행부터는 dbt가 사용자의 SELECT를 MERGE, INSERT, DELETE+INSERT 중 하나의 문으로 감싸, 신규 또는 변경된 행만 처리한다. 어떤 행이 '신규'인지는 타임스탬프나 이벤트 ID로 필터링하는 is_incremental() 블록으로 제어한다. 핵심은 dbt가 마법 같은 일을 하는 게 아니라, 웨어하우스가 실행할 표준 SQL로 컴파일한다는 점이다.
is_incremental()은 모델이 이미 테이블로 존재하고 실행이 --full-refresh가 아닐 때 True를 반환한다. {% if is_incremental() %} 블록 안에 WHERE 필터를 추가하는 식으로 쓴다: SELECT * FROM {{ source('raw', 'events') }} {% if is_incremental() %} WHERE event_timestamp > (SELECT MAX(event_timestamp) FROM {{ this }}) {% endif %}. 이 블록이 없으면 dbt는 매 실행마다 원천 테이블 전체를 재처리해 증분의 목적 자체가 사라진다. 흔한 실수는 {{ this }}를 빠뜨리는 것인데, 이는 현재 모델의 이미 구체화된 테이블 자체를 가리킨다.
핵심 포인트
- 첫 실행은 전체 SELECT로 테이블을 만들고, 이후 실행은 MERGE/INSERT/DELETE+INSERT로 신규·변경분만 처리한다
- is_incremental()은 모델이 이미 존재하고 --full-refresh가 아닐 때 True를 반환하며, WHERE 필터를 조건부로 추가하는 데 쓴다
- is_incremental() 블록이 없으면 매 실행마다 원천 전체를 재처리해 증분의 의미가 사라진다
- {{ this }}는 현재 모델의 이미 구체화된 테이블을 가리키며, 이를 빠뜨리는 것이 흔한 실수다
incremental_strategy — 네 가지, 그리고 microbatch
incremental_strategy로 웨어하우스·데이터 특성에 맞는 SQL 패턴을 고를 수 있다. append는 지연 도착 중복이 없다고 확신할 때(예: append-only 이벤트 로그) 쓴다. merge는 행이 업데이트될 수 있을 때(예: 주문 상태 변경) unique_key 기준으로 upsert를 수행한다. delete+insert는 MERGE가 비싸거나 지원되지 않는 웨어하우스에서 일치하는 행을 먼저 삭제한 뒤 삽입한다. insert_overwrite는 BigQuery나 Spark처럼 파티션 인지형 웨어하우스에서 전체 파티션을 효율적으로 교체한다.
— 정정: '네 가지 전략'이라는 설명은 dbt-core 1.9(2024년 12월/2025년 1월 릴리스) 이전 기준이다. 이후 microbatch라는 다섯 번째 전략이 추가됐다. microbatch는 대용량 시계열 데이터를 위해 설계된 전략으로, event_time·batch_size·lookback 설정만으로 dbt가 자동으로 시간 구간(배치)별 파티션 처리와 재처리 범위 산정을 대신해 준다. 기존에는 개발자가 is_incremental() 블록 안에 수동으로 MAX(timestamp) 룩백 윈도우를 작성해야 했지만(모듈 dbt-blog-draft-07 참고), microbatch는 이 패턴을 표준화해 재실행(backfill)과 동시성 처리까지 더 안전하게 만든다. 2026년 인터뷰에서 '증분 전략'을 묻는 질문에는 이 다섯 번째 전략까지 언급하는 것이 최신 지식을 보여준다.
핵심 포인트
- append: 지연 도착 중복이 없는 append-only 데이터에 사용
- merge: unique_key 기준 upsert, 행이 업데이트될 수 있는 데이터에 사용
- delete+insert: MERGE가 비싸거나 미지원인 웨어하우스에서 사용
- insert_overwrite: 파티션 인지형 웨어하우스(BigQuery, Spark 등)에서 파티션 단위로 효율적으로 교체
- dbt-core 1.9(2024-2025)부터 대용량 시계열 데이터 전용의 microbatch 전략이 다섯 번째로 추가됐다 — 정정