데이터 리니지 (Data Lineage)

#개념

데이터 리니지(Data Lineage)는 데이터의 출처(origin), 이동 경로, 변환 과정, 최종 소비처를 끝에서 끝까지 추적하여 "이 숫자는 어디서 왔고 무엇을 거쳐 여기까지 왔는가"에 답하는 메타데이터 체계다. 데이터베이스 연구에서는 오래전부터 데이터 프로비넌스(Data Provenance)라는 이름으로 연구되어 왔으며, 질의 결과의 각 튜플이 어떤 입력 튜플로부터 유도되었는지를 설명하는 why-provenance, where-provenance, how-provenance 같은 형식 모델이 제안되었다.

현대의 데이터 플랫폼에서 리니지는 보통 방향 그래프(Directed Graph)로 표현된다. 노드는 데이터셋(테이블, 파일, 토픽, 대시보드, 모델)과 이를 만들어 내는 작업(SQL 쿼리, Spark 잡, dbt 모델, 노트북)이며, 간선은 "작업이 데이터셋을 읽는다" 또는 "작업이 데이터셋을 쓴다"는 입출력 관계다.

리니지는 적용 범위에 따라 수준이 나뉜다.

리니지의 수준

테이블 수준 리니지(Table-level Lineage): 어떤 테이블이 어떤 테이블로부터 만들어졌는지를 보여 준다.
컬럼 수준 리니지(Column-level Lineage): 결과 테이블의 각 컬럼이 입력 테이블의 어떤 컬럼을 어떤 연산(복사, 집계, 조인 키, 표현식)으로 참조했는지를 추적한다. 예를 들어 SELECT user_id, SUM(amount) AS gmv FROM orders JOIN users USING (user_id) GROUP BY user_id에서 gmv 컬럼은 orders.amount에서 집계로 유도되고, user_id는 두 테이블의 조인 키로 참조된다는 사실이 컬럼 수준 리니지에 기록된다.
행 수준(row-level) 리니지: 더 세밀하게 특정 레코드가 어떤 입력 행에서 왔는지를 추적하지만, 저장 비용이 커서 금융 거래 추적처럼 꼭 필요한 영역에서만 쓰인다.

또한 특정 시점에 실제로 실행된 작업을 기록하는 운영 리니지(Operational/Runtime Lineage)와, 코드를 분석하여 실행 없이 얻는 정적 리니지(Static/Design Lineage)를 구분하기도 한다.

리니지를 수집하는 방식은 크게 네 가지로 나뉜다.

리니지 수집 방식

SQL 파싱(SQL Parsing): 쿼리 문자열을 추상 구문 트리로 분석하여 FROM·JOIN 절의 입력 테이블과 INSERT·CREATE TABLE AS 절의 출력 테이블, SELECT 목록의 컬럼 참조 관계를 추출한다. 컬럼 수준 리니지를 얻으려면 각 테이블의 스키마를 알아야 SELECT *나 별칭이 가리키는 실제 컬럼을 풀어낼 수 있으므로, 파서는 보통 메타스토어의 스키마 정보와 결합되며, sqlglot, sqllineage 같은 오픈소스 파서가 이 역할을 한다.
쿼리 로그(Query Log) 분석: 데이터 웨어하우스가 남기는 실행 이력(Snowflake의 ACCESS_HISTORY, BigQuery의 INFORMATION_SCHEMA.JOBS, Redshift의 STL 테이블 등)에서 실제로 실행된 쿼리와 읽고 쓴 객체를 추출하는 방식으로, 실행된 것만 기록되므로 가장 신뢰할 수 있는 운영 리니지를 제공한다.
오케스트레이터·프레임워크 메타데이터: Airflow, dbt, Spark, Flink 같은 실행 엔진에 리스너나 플러그인을 붙여 작업이 실행되는 순간 입출력 데이터셋을 보고하게 하는 방식이다. dbt는 ref()와 source() 함수로 모델 간 의존성을 선언하므로 manifest 파일에서 테이블 수준 리니지를 바로 얻을 수 있고, Spark는 쿼리 실행 계획(logical plan)을 리스너로 가로채 입출력 경로를 수집한다.
OpenLineage 표준: 이러한 수집기들이 공통 형식으로 이벤트를 보낼 수 있도록 등장한 표준이다.

OpenLineage는 Run(실행), Job(작업), Dataset(데이터셋)이라는 세 개의 핵심 엔티티와, 스키마·통계·컬럼 리니지·데이터 품질 같은 부가 정보를 담는 확장 가능한 패싯(Facet)으로 이루어진 JSON 이벤트 규격이며, 작업이 시작(START)·완료(COMPLETE)·실패(FAIL)할 때 이벤트를 HTTP 엔드포인트로 전송한다. Airflow, Spark, dbt, Flink, Great Expectations 등의 통합이 제공되어 각 도구마다 커넥터를 중복 개발하지 않고도 하나의 리니지 그래프를 구성할 수 있다.

리니지 수집기는 SQL 파싱처럼 코드로부터 정적으로 얻는 경우 실행되지 않은 분기까지 포함하여 과대 추정될 수 있고, 로그 기반은 실행된 것만 포착하여 아직 실행되지 않은 신규 파이프라인은 비어 있을 수 있으므로, 실무에서는 두 방식을 보완적으로 결합한다.

리니지의 가치는 그래프를 양방향으로 탐색할 때 드러난다. 하류(downstream) 방향으로 따라가는 영향 분석(Impact Analysis)은 어떤 테이블의 컬럼을 삭제하거나 타입을 바꾸기 전에 그 변경이 어떤 파이프라인, 대시보드, 머신러닝 모델에 파급되는지를 미리 파악하여 스키마 변경 사고를 막고, 담당자에게 사전 통지하는 데 쓰인다.

상류(upstream) 방향으로 거슬러 올라가는 근본 원인 분석(Root Cause Analysis)은 대시보드의 지표가 갑자기 틀어졌을 때 그 지표를 만든 쿼리, 그 쿼리가 읽은 테이블, 그 테이블을 적재한 잡과 원천 시스템까지 역추적하여 어느 단계에서 지연·누락·중복이 발생했는지를 찾는다. 데이터 관측성(data observability) 도구가 이상을 감지하면 리니지를 통해 영향 범위와 원인 후보를 즉시 좁힐 수 있다.

규제 대응도 핵심 활용처다. EU의 일반 개인정보 보호법(General Data Protection Regulation, GDPR)은 개인정보가 어떤 목적으로 어디에 처리·저장되는지를 조직이 설명할 수 있어야 하고, 정보 주체의 삭제 요구(right to erasure)에 응해야 하므로, 개인 식별 정보가 담긴 컬럼이 어떤 파생 테이블과 리포트로 복제·전파되었는지를 컬럼 수준 리니지로 추적하는 것이 사실상 전제 조건이 된다.

금융권의 BCBS 239(효과적인 리스크 데이터 집계 원칙)나 미국 SOX 같은 규제 역시 보고 수치의 출처를 증명할 것을 요구하며, 감사(audit) 시 "이 보고서의 숫자가 어떤 원천 데이터와 변환 규칙에서 나왔는가"를 리니지 그래프로 재구성하여 제시한다. 이 밖에도 리니지는 사용하지 않는 테이블과 잡을 찾아 저장·컴퓨팅 비용을 줄이는 데, 중복 파이프라인을 통합하는 데, 그리고 분석가가 신뢰할 만한 데이터 원천을 찾는 데이터 디스커버리에 활용된다.

리니지는 단독 시스템이라기보다 데이터 카탈로그(Data Catalog)의 핵심 기능으로 통합되는 것이 일반적이다. 대표적인 플랫폼은 다음과 같다.

리니지를 제공하는 주요 플랫폼

DataHub: LinkedIn에서 시작된 메타데이터 플랫폼으로, 푸시·풀 방식의 인제스천 커넥터와 SQL 파싱을 통해 테이블·컬럼 수준 리니지를 수집하고 OpenLineage 이벤트도 수신한다.
Apache Atlas: Hadoop 생태계를 중심으로 Hive, Spark, Kafka의 리니지를 훅(hook)으로 수집하며 분류(classification) 태그를 리니지를 따라 전파하여 민감 데이터 거버넌스를 지원한다.
Unity Catalog: Databricks의 통합 거버넌스 계층으로, 클러스터와 SQL 웨어하우스에서 실행되는 모든 쿼리의 테이블·컬럼 수준 리니지를 자동으로 캡처하여 노트북, 워크플로, 대시보드까지 연결하고 시스템 테이블로도 조회할 수 있게 한다.
Marquez: OpenLineage의 참조 구현으로, 이벤트를 저장하고 그래프로 시각화하는 경량 메타데이터 서비스다.

그 밖에 Amundsen, OpenMetadata, 그리고 Collibra, Alation, Google Dataplex 같은 상용 제품이 리니지를 제공한다. 리니지는 머신러닝(Machine Learning)으로도 확장된다. ML 리니지(ML Lineage)는 원천 데이터 → 특징 엔지니어링(Feature Engineering) 결과 → 학습 데이터셋 버전 → 학습 실행과 하이퍼파라미터 → 모델 아티팩트 → 배포 엔드포인트로 이어지는 사슬을 기록하여, 프로덕션에서 서비스 중인 모델이 정확히 어떤 데이터와 코드로 만들어졌는지를 재구성한다.

이는 MLOps의 재현성과 모델 감사의 기반이며, 피처 스토어와 모델 레지스트리가 리니지 정보를 함께 보관한다. OpenLineage 역시 데이터셋뿐 아니라 모델 학습 잡을 같은 그래프에 담을 수 있도록 확장되고 있으며, EU AI Act처럼 고위험 AI 시스템의 학습 데이터 출처 문서화를 요구하는 규제가 늘면서 ML 리니지의 중요성이 커지고 있다.

리니지에는 분명한 한계가 있다. 가장 큰 어려움은 동적 SQL(Dynamic SQL)이다. 문자열 연결로 실행 시점에 조립되는 쿼리, 저장 프로시저 안에서 변수에 따라 달라지는 테이블명, 템플릿 엔진으로 생성되는 쿼리는 정적 파싱으로는 실제 입출력을 알 수 없고, 실행 로그에서 사후에 복원해야 한다.

또한 Python이나 Scala로 작성된 사용자 정의 함수, pandas 변환, 외부 API 호출, 스프레드시트 수작업처럼 SQL이 아닌 블랙박스 코드(Black-box Code)는 입출력을 선언하지 않는 한 리니지가 끊긴다. 파일 경로로 테이블을 참조하거나 임시 테이블을 거치는 경우 컬럼 수준 리니지가 유실되기 쉽고, 테이블 이름이 바뀌면 과거 이력이 단절되기도 한다.

수집된 리니지는 시간이 지나면 코드와 어긋나는 리니지 부패(Lineage Decay)가 발생하므로 수동 등록보다는 실행 시점 자동 수집을 원칙으로 삼고, 수집기가 포착하지 못하는 구간은 OpenLineage 이벤트를 직접 전송하거나 카탈로그 API로 수동 보완해야 한다. 거대한 그래프를 사람이 읽기 쉽게 요약하는 시각화, 컬럼 수준 리니지의 저장·질의 비용, 여러 도구에 흩어진 리니지를 하나의 식별자 체계로 통합하는 문제 역시 실무적 과제다.

결론적으로 데이터 리니지는 데이터 거버넌스(Data Governance)의 뼈대이자 데이터 품질, 규제 대응, 비용 최적화, 모델 재현성을 연결하는 공통 기반이며, 자동 수집 범위를 넓히면서 공백을 표준 이벤트로 메우는 운영 원칙이 그 실효성을 좌우한다.

#관련 용어

데이터 거버넌스

데이터의 품질·보안·접근 권한·규제 준수를 조직 차원에서 관리하는 체계로, 리니지는 그 핵심 메타데이터

데이터 파이프라인

데이터를 수집·변환·적재하는 자동화된 처리 흐름으로, 리니지 그래프의 작업 노드를 구성하는 단위

ETL

원천에서 데이터를 추출·변환·적재하는 과정으로, 각 단계의 입출력이 리니지 간선으로 기록된다

데이터 웨어하우스

분석용 데이터를 통합 저장하는 시스템으로, 쿼리 로그와 메타스토어가 리니지 수집의 주요 원천이 된다

데이터 카탈로그

조직의 데이터 자산과 메타데이터를 검색·관리하는 시스템으로, 리니지 그래프를 저장하고 시각화하는 통합 지점

MLOps

데이터·특징·모델·배포로 이어지는 ML 리니지를 활용해 모델의 재현성과 감사 가능성을 확보하는 운영 체계

#직무 연관도

Data Analyst높음

대시보드 지표가 어떤 원천 테이블과 변환 규칙에서 나왔는지 확인하고, 신뢰할 수 있는 데이터 원천을 찾아 분석의 정확성을 보증하는 데 필수적이다

Data Scientist보통

학습 데이터와 특징의 출처를 추적하여 모델 재현성을 확보하고, 특징 값 이상이나 데이터 누수의 원인을 상류에서 진단하는 데 활용된다

Data Engineer밀접

리니지 수집기 구축, 카탈로그 통합, 스키마 변경 영향 분석, 파이프라인 장애의 근본 원인 분석을 담당하는 데이터 엔지니어의 핵심 영역

#사용 사례

금융전자상거래인터넷 서비스의료통신제조

개요

데이터 리니지는 스키마 변경 영향 분석, 데이터 품질 사고의 근본 원인 추적, GDPR·금융 규제에 따른 개인정보 흐름 추적과 감사 대응, 미사용 데이터 자산 정리를 통한 비용 절감, 그리고 머신러닝 모델의 학습 데이터 출처 문서화와 재현성 확보에 활용된다.

사례

전자상거래 기업에서 경영 대시보드의 일일 매출 지표가 전일 대비 30% 급감했을 때, 분석가가 카탈로그에서 해당 지표의 상류 리니지를 따라가 보니 매출 집계 테이블이 읽는 주문 테이블의 적재 잡이 원천 DB 스키마 변경으로 절반만 적재된 것을 10분 만에 찾아냈다. 반대로 데이터 엔지니어는 주문 테이블의 currency 컬럼을 삭제하기 전에 하류 리니지로 영향받는 12개 파이프라인과 3개 추천 모델 특징을 확인하고 담당 팀에 사전 공지했다.