핵심 인사이트
- 본질: 데이터 리니지(Data Lineage)는 데이터가 발생지(Source)에서 변환(Transform)을 거쳐 최종 적재(Sink)에 이르는 전체 여정을 시각화하여 추적하는 기술로, "이 숫자는 어디서 왔는가"에 대한 완전한 답을 제공한다.
- 가치: 영향 분석(Impact Analysis)은 "이 컬럼을 수정하면 어떤 리포트와 ML 모델이 영향받는가"를 사전에 파악하게 하고, 규정 준수 감사에서 개인정보 데이터의 흐름 경로를 즉시 제시한다. OpenLineage 표준은 이종 시스템 간 리니지 통합을 가능케 한다.
- 판단 포인트: 컬럼 수준(Column-Level) 리니지는 행 수준(Row-Level) 리니지보다 구현 비용이 높지만, 데이터 품질 문제의 근본 원인 파악에 필수적이며, 데이터 플랫폼 규모에 따라 적정 수준을 선택해야 한다.
Ⅰ. 개요 및 필요성
1.1 데이터 리니지가 필요한 이유
글로벌 금융기업이 규제 기관에 특정 리스크 지표의 계산 근거를 소명해야 할 때, 데이터가 어느 원천 시스템에서 어떤 변환을 거쳐 현재 값이 됐는지 추적하는 데 수주가 걸릴 수 있다. 또는 데이터 파이프라인 변경으로 대시보드 숫자가 갑자기 달라졌을 때, 영향받은 모든 다운스트림 자산(리포트, ML 모델, 알림)을 파악하지 못하면 장애 대응이 지연된다.
데이터 리니지는 이러한 문제를 해결하기 위한 데이터 계보 추적 시스템이다. 데이터 웨어하우스, ETL 파이프라인, ML 파이프라인, BI 리포트까지 전체 데이터 생태계를 연결하는 지도를 제공한다.
1.2 리니지의 3대 수준
| 수준 | 설명 | 활용 |
|---|---|---|
| 테이블 수준 (Table-Level) | 소스 테이블 → 타겟 테이블 의존 관계 | 파이프라인 의존성 관리 |
| 컬럼 수준 (Column-Level) | 특정 컬럼의 발생지·변환 수식 추적 | 데이터 품질, 규정 준수 |
| 행 수준 (Row-Level) | 특정 레코드의 이동 경로 추적 | GDPR 데이터 주체 요청 |
📢 섹션 요약 비유: 데이터 리니지는 음식의 원산지 증명과 같다. "이 소고기가 어느 농장, 어느 도축장, 어느 유통 경로를 거쳤는가"를 추적하듯, 데이터도 어느 시스템에서 생성됐고 어떻게 가공됐는지 완전한 이력을 보장한다.
Ⅱ. 아키텍처 및 핵심 원리
2.1 데이터 리니지 추적 아키텍처
┌─────────────────────────────────────────────────────────────┐
│ Data Lineage Tracking Architecture │
│ │
│ [Source Systems] [Transform] [Sink/Consumers] │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ ERP DB │──────►│ ETL │──────►│ Data │ │
│ │(주문 원천)│ raw │ Pipeline │ clean │ Warehouse │ │
│ └──────────┘ │ │ └──────┬───────┘ │
│ │ dbt / │ │ │
│ ┌──────────┐ │ Spark │ ┌──────▼───────┐ │
│ │ CRM API │──────►│ │──────►│ Data Mart │ │
│ │(고객 원천)│ └──────────┘ └──────┬───────┘ │
│ └──────────┘ │ │
│ ┌──────▼───────┐ │
│ ┌─────────────────────────────────│ BI Report │ │
│ │ │ (매출 대시보드)│ │
│ │ Lineage Graph (리니지 그래프) └──────────────┘ │
│ │ ┌──────────────────────────────────────────┐ │
│ │ │ ERP.order_amount │ │
│ │ │ └─► ETL: SUM(qty * price) │ │
│ │ │ └─► DW.fact_sales.revenue │ │
│ │ │ └─► Report: 월별 매출 │ │
│ │ └──────────────────────────────────────────┘ │
│ └───────────────────────────────────────────────── │
└─────────────────────────────────────────────────────────────┘
2.2 리니지 수집 방식
| 방식 | 설명 | 장단점 |
|---|---|---|
| 수동 문서화 | 엔지니어가 직접 리니지 정보 입력 | 정확하지만 유지보수 어려움 |
| 파서 기반 (SQL 파싱) | SQL 쿼리를 파싱하여 컬럼 의존성 추출 | 자동화, 코드 변경 즉시 반영 |
| 런타임 캡처 | 실행 시점에 Spark/Flink 리니지 자동 수집 | 실제 실행 경로 추적, 비용 높음 |
| 메타데이터 API | OpenLineage 표준 API로 툴 간 통합 | 이종 시스템 통합, 표준화 |
2.3 OpenLineage 표준
OpenLineage는 데이터 리니지 이벤트의 오픈 표준으로, 다양한 데이터 도구(Airflow, Spark, dbt, Flink 등)에서 동일한 형식으로 리니지 이벤트를 발행할 수 있게 한다. Marquez 서버가 이를 수집·저장하며, Amundsen·DataHub·Apache Atlas가 소비한다.
{
"eventType": "COMPLETE",
"run": {"runId": "uuid-1234"},
"job": {"namespace": "etl-pipeline", "name": "transform_sales"},
"inputs": [{"namespace": "db", "name": "raw.orders"}],
"outputs": [{"namespace": "dw", "name": "fact.sales"}]
}
📢 섹션 요약 비유: OpenLineage는 전국 택배사가 공통으로 사용하는 운송장 표준 양식이다. CJ대한통운이든 한진이든 같은 양식으로 배송 이력을 기록하면, 소비자는 어떤 택배사를 이용해도 동일하게 배송 경로를 추적할 수 있다.
Ⅲ. 비교 및 연결
3.1 영향 분석(Impact Analysis) vs 근본 원인 분석 (Root Cause Analysis)
| 분석 방향 | 설명 | 질문 예시 |
|---|---|---|
| Impact Analysis (다운스트림) | 변경이 어떤 하위 자산에 영향을 미치는가 | "orders 테이블 컬럼 삭제 시 영향받는 리포트?" |
| Root Cause Analysis (업스트림) | 이 오류/변경이 어디서 시작됐는가 | "매출 수치가 틀린 이유는 어느 소스에서?" |
3.2 데이터 리니지 도구 비교
| 도구 | 방식 | 특징 | 통합 |
|---|---|---|---|
| Apache Atlas | 오픈소스 | Hadoop 생태계, HBase 저장 | Hive, Spark, Kafka |
| DataHub | 오픈소스 | 실시간 이벤트 기반, Graph 모델 | Airflow, Spark, dbt |
| Marquez | 오픈소스 | OpenLineage 레퍼런스 구현 | OpenLineage 표준 |
| dbt Lineage | 오픈소스 | SQL 변환 자동 리니지 | DW 중심 |
| Collibra Lineage | 상용 | 엔터프라이즈, 비즈니스 친화 | 멀티 소스 |
| Informatica | 상용 | 자동 리니지 + AI 거버넌스 | 광범위한 커넥터 |
📢 섹션 요약 비유: Impact Analysis는 도미노 넘어뜨리기에서 "첫 번째 도미노를 넘어뜨리면 몇 번째까지 쓰러지는가"를 미리 예측하는 것이고, Root Cause Analysis는 "저 도미노가 왜 쓰러졌는지 처음 발동 지점을 역추적"하는 것이다.
Ⅳ. 실무 적용 및 기술사 판단
4.1 리니지 활용 시나리오
시나리오 1: 스키마 변경 사전 영향 평가
요청: orders 테이블에서 discount 컬럼 삭제 검토
리니지 조회 → 영향받는 자산:
- ETL_pipeline_001 (TRANSFORM 단계에서 사용)
- DW.fact_sales.net_revenue (컬럼 계산식에 포함)
- BI.monthly_report (매출 대시보드 KPI)
- ML.revenue_forecast_model (피처로 사용)
결론: 4개 자산 동시 수정 필요 → 변경 계획 수립
시나리오 2: GDPR 데이터 주체 삭제 요청
요청: 고객 ID C12345 개인정보 삭제 요청
리니지 조회 → C12345 데이터 존재 위치:
- CRM.customers (원천)
- DW.dim_customer (복사본)
- ML.training_dataset_2024 (학습 데이터 내 포함)
- backup.archive_2023 (백업 포함)
결론: 4개 위치 모두 삭제 처리 필요
4.2 기술사 핵심 출제 포인트
- 리니지 수준 3단계: 테이블·컬럼·행 수준 추적의 차이와 활용
- OpenLineage 표준: 이종 시스템 리니지 통합의 의의
- Impact Analysis vs Root Cause Analysis: 방향성(다운스트림 vs 업스트림) 차이
- 리니지와 GDPR/규제 대응: 데이터 주체 요청 처리, 감사 지원
📢 섹션 요약 비유: 컬럼 수준 리니지는 혈액 검사에서 특정 성분이 어느 장기에서 생성됐는지 추적하는 것과 같다. 단순히 "혈액 이상(테이블 수준)"이 아니라 "이 수치는 간에서 생성된 효소의 이상(컬럼 수준)"까지 정밀하게 파악해야 정확한 치료가 가능하다.
Ⅴ. 기대효과 및 결론
5.1 데이터 리니지 도입 효과
| 효과 | 내용 |
|---|---|
| 변경 영향 가시화 | 스키마 변경 전 다운스트림 영향을 100% 파악 |
| 사고 해결 시간 단축 | 데이터 오류 근본 원인 추적 시간 80% 절감 |
| 규정 준수 자동화 | GDPR/개인정보보호법 대응 데이터 흐름 증적 |
| 데이터 신뢰도 향상 | 데이터 생성부터 소비까지 투명한 이력 보장 |
| 의존성 관리 | 파이프라인 장애 전파 경로 사전 파악 |
5.2 미래 방향
데이터 리니지는 데이터 메시의 데이터 프로덕트 간 의존성 추적, ML 파이프라인의 모델 리니지(피처 → 학습 데이터 → 모델 버전) 추적으로 확장되고 있다. OpenLineage 표준의 보급으로 이종 플랫폼 간 엔드투엔드(End-to-End) 리니지가 현실화되고 있으며, AI 기반 자동 리니지 생성·보완이 차세대 방향이다.
📢 섹션 요약 비유: 데이터 리니지는 DNA 검사와 같다. DNA 한 조각이 어느 조상에서 왔는지, 어떤 유전적 변이가 있었는지를 추적하여 질병 원인을 밝히듯, 데이터의 계보를 추적하여 "이 오류 수치의 조상은 어느 소스 시스템의 어떤 변환 오류"인지를 정확히 밝힌다.
📌 관련 개념 맵
| 개념 | 설명 | 연관 키워드 |
|---|---|---|
| Data Lineage | 데이터 발생→변환→적재 전 경로 추적 | 리니지 그래프, 의존성 |
| Impact Analysis | 변경이 미치는 하위 자산 영향 사전 분석 | 다운스트림, 변경 관리 |
| Root Cause Analysis | 오류·이상의 발생 원인 역추적 | 업스트림, 디버깅 |
| OpenLineage | 이종 도구 간 리니지 이벤트 오픈 표준 | Marquez, Airflow |
| Column-Level Lineage | 컬럼 단위 변환 수식·발생지 추적 | 정밀 추적, GDPR |
| dbt (data build tool) | SQL 변환 자동 리니지 오픈소스 도구 | DW, 변환 파이프라인 |
| Data Catalog | 데이터 자산 탐색·메타데이터 관리 플랫폼 | Collibra, DataHub |
👶 어린이를 위한 3줄 비유 설명
- 데이터 리니지는 음식 원산지 추적 시스템이야. "이 우유가 어느 농장 어느 소에서 나왔는지, 언제 가공됐는지" 알 수 있는 것처럼, 데이터도 어디서 왔고 어떻게 변환됐는지 추적할 수 있어.
- Impact Analysis는 도미노 게임이야. 첫 번째 도미노(소스 데이터)를 바꾸면 몇 번째 도미노(리포트·모델)가 쓰러지는지 미리 계산해서, 원치 않는 도미노는 미리 치워두는 거야.
- OpenLineage는 모든 택배사가 쓰는 공통 운송장 양식이야. 어느 회사 택배든 같은 양식으로 배송 경로를 기록하면, 중간에 다른 회사로 전달돼도 끊기지 않고 추적할 수 있어.