dbt를 10년 늦게 시작한 후기 (DuckDB 에디션)

Sources: 추출과 변환의 분리

• dbt의 source 개념으로 데이터 추출(Extract)과 변환(Transform)을 깔끔하게 분리할 수 있음
• DuckDB의 read_json으로 API 데이터를 직접 읽어올 수 있지만, dbt에서는 이를 source로 정의해서 관리함
• source 정의에 Markdown 설명을 넣으면 나중에 자동 문서화에 그대로 활용됨
• 비행기 안처럼 API 접근이 안 되는 환경에서는 정적 데이터셋으로 source만 교체하면 됨

Staging 모델과 매크로

• staging 모델에서 원본 데이터를 정리하고, 이후 mart 모델에서 비즈니스 로직을 적용하는 계층 구조를 사용함
• Jinja 템플릿으로 반복 로직을 매크로화할 수 있어서 SQL의 boilerplate를 크게 줄임
• {{ source() }}와 {{ ref() }}로 모델 간 의존성을 선언적으로 관리함

테스트: freshness부터 커스텀 테스트까지

• not_null, unique 같은 기본 테스트를 YAML 한 줄로 설정 가능함
• source freshness 테스트로 데이터가 얼마나 오래됐는지 자동 체크함
• singular test로 비즈니스 로직에 맞는 커스텀 검증도 SQL 파일 하나로 추가할 수 있음

문서화: 자동 생성 리니지 그래프

• dbt docs generate로 전체 파이프라인의 리니지 그래프가 자동 생성됨
• 모델 간 의존 관계가 시각적으로 표현되어 데이터 흐름을 한눈에 파악 가능함
• YAML에 작성한 description이 문서에 자동 반영되므로 별도 문서 관리가 필요 없음

Dagster로 오케스트레이션

• Dagster가 dbt와 네이티브로 통합되어 dbt 모델을 asset으로 인식함
• 실행 이력 추적, 스케줄링, 모니터링을 Dagster UI에서 한 번에 관리할 수 있음
• Dagster 설정 코드는 Claude가 작성해줬다고 저자가 직접 밝힘

핵심 인사이트

• dbt는 대규모 프로젝트만을 위한 도구가 아님 — 소규모 개인 프로젝트에서도 변환 로직에 구조와 엄격함을 부여해줌
• UK Environment Agency 홍수 모니터링 API 데이터를 DuckDB + dbt + Dagster로 엮은 전체 파이프라인 예제가 포함됨
• 10년 늦게 시작했지만 dbt가 가져다주는 체계적인 데이터 변환 관리의 가치를 실감했다는 후기임