Ship Fast, Break Nothing: dbt CI/CD, Monitoring and Model Health

Author: Kiran Pothina | Source: Medium | Published: 2026-06-11

한 줄 요약

PR마다 전체 웨어하우스를 재빌드(45분)하는 dbt CI를 변경분만 빌드하는 slim CI(3-8분)로 바꾸는 4단계 패턴과, 모든 모델을 5개 health 차원으로 채점하는 scorecard 에이전트.

문제: dbt build가 PR마다 240개 모델 전체 재빌드 → 45분 → 엔지니어가 PR 안 열고 main에 직접 push → 플랫폼 degrade. 성숙한 dbt 프로젝트가 멈추는 가장 흔한 이유
slim CI 4단계(대부분 튜토리얼이 2단계에서 멈춤): ① fetch-depth: 0(전체 git history) ② main에서 dbt parse로 fresh state manifest 생성(S3 prefetch는 drift 유발) ③ incremental 모델 clone(거의 모두 빠뜨림 — clone 안 하면 full refresh로 동작) ④ dbt build --select state:modified+ --defer(변경분만, 미변경 upstream은 prod로 defer)
dbt Mesh CI: 6개 프로젝트 = 12개 workflow 파일(도메인당 slim CI + deploy). paths:로 도메인 폴더 스코핑 → 독립 CI, zero coupling. PR-scoped 스키마(pr_47_staging), dbt ls로 cross-project contract 검증(컴파일 시점)
Model Health Scorecard: manifest.json을 읽어 5차원(각 20점) 채점 — Documentation, Test coverage, Contracts, Freshness, Blast radius(downstream 수). 실제 프로젝트의 정직한 80.4점(stub 모델·단일 장애점·folder-level config 상속 발견)

45분 → 3-8분 PR 피드백, deploy 10-15분
Snowflake zero-copy clone(instant, 데이터 이동 없음)으로 incremental 정확성
scorecard: 18 A등급, 1 B, 5 C, 평균 80.4; stg_tpch__lineitem은 blast radius 23(단일 장애점)
향후: scorecard trend 추적, PR scorecard 코멘트, metric governance CI