Lineage — 모든 숫자 어디서 왔는지 알기 · Data Engineering Quest

모든 임원이 결국 묻는 질문

"왜 이 숫자가 바뀌었어?" — 이 질문에 대한 답이 잘나가는 데이터 팀과 신뢰받는 데이터 팀을 가르는 선이야. 답하려면 lineage 가 필요해 — 모든 출력의 모든 column 이 upstream source 에서 어떻게 흘러왔는지 보여 주는 그래프. 테이블 수준 ("이 대시보드는 이 mart 를 읽어"), column 수준 ("대시보드의 revenue 는 fct_orders 의 amount_usd 에서 와"), 이상적으론 row 수준 ("이 row 의 값은 2026-04-30 03:14 UTC run 이 만들었어") 까지.

오늘 lineage 를 주는 것들

dbt 의 docs 사이트 — 모든 model 의 lineage 그래프를 그려 줘. Model 을 클릭하면 뭐가 얘를 먹이고 뭐가 얘한테 기대는지 보여.
Dagster — lineage 를 orchestration 그 자체로 모델링해. 모든 asset 의 upstream 과 downstream 이 일급으로 붙어 다녀.
OpenLineage — 어떤 파이프라인 framework 에서든 lineage 이벤트를 내보내는, 자리를 잡아가는 open 표준. Airflow, Dagster, Spark, Flink 전부 통합이 있어.
Marquez / DataHub / OpenMetadata — OpenLineage 로 내보낸 lineage 를 저장하고 그려 주는 오픈소스 platform.

도구가 아니라 규율

그래프는 도구가 줘. 그런데 그 그래프가 뜻을 가지려면 transformation 이 구조를 갖고 있어야 해 — 그게 규율이야. 모든 mart 가 staging layer 에 기대고 모든 staging layer 가 source 에 기대는 dbt 프로젝트는 깔끔한 lineage 를 낳아. 전부를 하나의 거대한 CTE 사슬에서 해치우는 dbt 프로젝트는 — 틀린 말은 없는데 아무 쓸모 없는 lineage 그래프를 낳아.

Code

구조에 의한 lineage — staging → intermediate → marts 가 작동 패턴·text

models/
├── staging/                 # source 테이블과 1:1, 가벼운 rename + cast
│   └── stg_orders.sql       #     SELECT FROM {{ source('raw', 'orders') }}
├── intermediate/             # join, derive, 재사용되는 비즈니스 로직
│   └── int_orders__joined.sql
└── marts/                    # consumer-facing 테이블 (비즈니스 영역당 폴더)
    ├── core/
    │   ├── dim_customers.sql
    │   └── fct_orders.sql
    └── revenue/
        └── monthly_revenue.sql

# 이 구조가 dbt lineage 그래프에 깔끔한 left-to-right flow 로 나타남.
# Layer 건너뛰면 그래프가 아무도 디버깅 못 하는 hairball 됨.

Exercise

dbt 프로젝트가 있다면 dbt docs generate && dbt docs serve 를 돌려서 lineage 그래프를 클릭해 봐. 제일 하류의 model 을 골라서 거꾸로, model 하나씩, 모든 source 의 이름을 댈 수 있을 때까지 걸어 올라가. 이건 "왜 이 숫자가 바뀌었어?" 에 답하는 연습이야 — 누가 묻기 전에 하는.

Lineage — 모든 숫자 어디서 왔는지 알기