Analytics Engineering
dbt를 중심으로 변환 코드의 CI/CD·테스트·계약·모델 health를 소프트웨어 엔지니어링 규율로 관리
핵심 개념
Analytics Engineering은 SQL 변환(주로 dbt)을 소프트웨어처럼 다루는 분야다 — 버전 관리, CI/CD, 테스트, 계약(contract), 모델 health 모니터링. 데이터 모델이 비즈니스와 함께 빠르게 변할 때, 피드백 루프가 느려지거나 거버넌스가 decay하면 플랫폼이 멈춘다.
Slim CI — 변경분만 빌드
PR마다 전체 웨어하우스를 재빌드(dbt build)하면 240개 모델에 45분 → 엔지니어가 PR을 안 열고 main에 직접 push → 플랫폼 degrade. 성숙한 dbt 프로젝트가 개선을 멈추는 가장 흔한 이유. 해법은 --select state:modified+이되, 프로덕션에서 동작하려면 4단계가 필요:
fetch-depth: 0: 전체 git history(브랜치 전환에 필요)- main에서 state manifest 생성:
dbt parse --target prod로 fresh manifest(S3 prefetch는 stale·drift 유발) - incremental 모델 clone(거의 모두 빠뜨림): clone 안 하면 새 PR 스키마에서 full refresh로 동작해
is_incremental()깨짐. Snowflake zero-copy clone으로 instant - slim build:
dbt build --select state:modified+ --defer(변경분만, 미변경 upstream은 prod로 defer)
결과: 45분 → 3-8분.
dbt Mesh CI
여러 도메인 프로젝트는 도메인당 2개(slim CI + deploy) workflow로 분리:
paths:로 도메인 폴더 스코핑 → 독립 CI, zero coupling- PR-scoped 스키마(
pr_47_staging)로 동시 PR 격리, 종료 시 drop - cross-project 검증:
dbt ls로 다른 도메인의 contract 컬럼 참조를 컴파일 시점에 검증(Snowflake compute 쓰기 전)
Model Health Scorecard
manifest.json을 읽어 모든 모델을 5차원(각 20점)으로 채점:
| 차원 | 기준 |
|---|---|
| Documentation | 의미 있는 description + 모든 컬럼 설명 |
| Test coverage | 컬럼당 데이터 테스트(pro-rated) |
| Contracts | public mart에 contract: enforced, 모든 컬럼 data_type |
| Freshness | upstream source에 freshness 임계 |
| Blast radius | downstream 모델 수(임계 초과 시 페널티) |
scorecard는 거짓말하지 않는다 — 실제 프로젝트의 정직한 80.4점(stub 모델, 단일 장애점 staging 뷰, folder-level config 상속을 명명·위치·실행 가능하게 만듦).
거버넌스는 enforcement 없이 decay한다
Semantic Layer·canonical 모델은 tooling(에이전트가 structurally 라우팅)·CI(우회 시 review 실패)·mandate(governed 레이어 위 빌드)로 강제되어야 유지된다. 강제 없는 거버넌스는 곧 “여러 후보” 문제로 회귀(→ AI Self-Serve Analytics의 Anthropic 사례와 동일 교훈).
연관 개념
- Semantic Layer — 메트릭 정의(dbt MetricFlow)
- Data Modeling — 모델 설계
- Data Quality and Validation — 테스트·계약
- Workflow Orchestration — CI/CD 파이프라인
- AI Self-Serve Analytics — governed 모델이 AI 분석의 전제