dbt — 코드로서의 transformation · Data Engineering Quest

Modern data stack 의 transformation layer

dbt (data build tool, 2026.8 기준 dbt-core 1.12) 는 modern data team 이 ELT 의 transformation 절반을 쓰는 방식이야. SQL 을 돌리는 Python 을 orchestrator 가 돌리는 겹겹의 포장 대신, dbt 는 SQL transformation 그 자체를 맡는 전용 도구야: version-controlled 코드로, 테스트와 docs 와 lineage 와 배포 방법까지 갖춰서.

dbt 가 관리하는 것

Model — dbt 가 테이블 또는 뷰로 materialize 하는 SQL SELECT 문.
Source — freshness 체크가 달린, 선언된 raw upstream 테이블.
Test — model 출력에 대한 assertion (uniqueness, non-null, accepted value, custom).
Docs — 자동 생성되는 lineage 그래프 + 문서 사이트.
Snapshot — SCD Type 2 이력 테이블의 dbt 식 이름.
Macro — Jinja 템플릿으로 재사용하는 SQL.

모두가 dbt 로 간 이유

dbt 전의 transformation layer 는 scheduler 가 돌리는 임시 SQL 이거나 orchestrator task 안에 파묻힌 SQL 이었어. 어느 쪽이든 SQL 자체는 일급 산출물이 아니었지 — 테스트 없고, docs 없고, version control 규율 없고. dbt 가 SQL 을 산출물로 만들었고, 그게 되는 순간 나머지 practice (review, test, lineage) 가 자연스럽게 따라왔어.

EV v2 · 2026-08-01: dbt 가 지금 갈아타는 중이야. 본인이 어느 쪽을 설치하는지는 알고 있는 게 좋아. Rust 기반 Fusion 엔진 위에 올라간 dbt v2 가 이제 dbt Labs 가 새 프로젝트와 업그레이드에 권하는 쪽이고, dbt 패키지를 설치하면 오는 게 그거야. 다만 dbt 가 스스로 붙인 단계 이름은 preview 야. 배포되는 패키지가 아직 정식 릴리스 전이고, 로컬 CLI 도 GA 가 아니고. dbt-core 1.x 는 Apache-2.0 런타임으로 계속 있고, 아직 옮길 준비가 안 된 기존 프로젝트한테는 그쪽이 맞아. 이 레슨이 가르치는 건 — model, ref, source, test, snapshot, macro — 그대로 넘어가. v2 는 더 빠르고 더 엄격하다고 설명되지, 모양이 다른 물건이 아니거든. 오늘 프로젝트를 새로 시작한다면 어느 패키지를 깔지 정하기 전에 업그레이드 가이드부터 읽어.

Code

ref 기반 의존성, schema, test 있는 dbt model·sql

-- models/marts/orders/fct_orders.sql
-- 테이블로 materialize; ref() 호출이 그래프에 의존성 생성.
{{ config(materialized='table') }}

WITH src AS (
    SELECT * FROM {{ ref('stg_orders') }}
),
customers AS (
    SELECT * FROM {{ ref('dim_customers') }}
)

SELECT
    s.order_id,
    s.line_item_id,
    c.customer_key,
    s.product_key,
    s.date_key,
    s.quantity,
    s.amount_usd,
    s.discount_usd
FROM   src s
LEFT JOIN customers c
  ON   s.customer_id = c.customer_id
  AND  s.order_date >= c.valid_from
  AND  s.order_date <  c.valid_to

schema.yml — 선언적 test + docs 가 model 옆에·yaml

version: 2

models:
  - name: fct_orders
    description: "주문 line item 당 한 row. 주문 시점 dim_customers 와 join."
    columns:
      - name: order_id
        description: "Source 주문 식별자."
        tests:
          - not_null
      - name: line_item_id
        tests:
          - not_null
      - name: customer_key
        tests:
          - relationships:
              to: ref('dim_customers')
              field: customer_key
      - name: amount_usd
        tests:
          - not_null
          - dbt_utils.expression_is_true:
              expression: "amount_usd >= 0"

Exercise

접근 가능한 warehouse 에 dbt-core 를 설치해 (제일 쉬운 건 local DuckDB: pip install dbt-duckdb). dbt init 하고, staging model 하나와 mart model 하나를 만들고 (둘 사이는 ref 로), key column 에 not_null test 를 달고, dbt build 를 돌려. 목표는 test → materialize → docs 로 이어지는 loop 를 처음부터 끝까지 한 번 느껴 보는 거야.

dbt — 코드로서의 transformation