data-lineage

당근 데이터 지도를 그리다: 컬럼 레벨 리니지 구축기. SQL 파싱으로 구축한 컬럼 레벨 데이터 리니지 | by Jin-won Park | 당근 테크 블로그 | Dec, 2025 | Medium (새 탭에서 열림)

당근마켓(당근) 데이터 가치화팀은 데이터의 흐름을 투명하게 파악하여 신뢰성을 높이기 위해 SQL 파싱 기반의 **컬럼 레벨 데이터 리니지(Column-level Lineage)** 시스템을 구축했습니다. 기존의 테이블 단위 추적으로는 해결하기 어려웠던 연쇄 장애 대응과 민감 정보(PII) 관리 문제를 해결하기 위해, 모든 BigQuery 쿼리 로그를 분석하여 데이터 간의 세부 의존 관계를 시각화했습니다. 이를 통해 당근의 복잡한 데이터 생태계에서 변경 영향도를 정교하게 분석하고 장애 복구 시간을 단축하는 성과를 거두었습니다. ### 데이터 흐름의 불투명성으로 인한 문제점 * **연쇄 실패 대응의 어려움**: 특정 테이블의 파이프라인이 실패했을 때 이를 참조하는 하위 테이블들을 즉각 파악할 수 없어, 수동으로 쿼리를 전수 조사하며 문제를 해결해야 했습니다. * **스키마 변경의 불확실성**: 원천 데이터(MySQL 등)의 컬럼을 삭제하거나 타입을 변경할 때, 해당 컬럼을 사용하는 수많은 파생 테이블 중 어떤 곳에 장애가 발생할지 예측하기 어려웠습니다. * **민감 정보 추적 불가**: PII(개인정보)가 여러 가공 단계를 거치며 어떤 테이블의 어떤 컬럼으로 흘러가는지 파악되지 않아 보안 관리 측면에서 한계가 있었습니다. ### 컬럼 레벨 리니지 도입의 기술적 의사결정 * **테이블 레벨의 한계**: BigQuery의 기본 기능을 통한 테이블 단위 추적은 뷰(View)의 기저 테이블을 정확히 파악하기 어렵고, 세부 컬럼의 변화를 감지하지 못하는 단점이 있었습니다. * **오픈소스(OpenLineage) 대비 효율성**: 다양한 조직이 각기 다른 환경(Airflow, 노트북 등)에서 쿼리를 실행하는 당근의 특성상, 모든 환경에 계측 코드를 심는 방식보다는 중앙화된 BigQuery 로그를 분석하는 방식이 운영 부담이 적다고 판단했습니다. * **SQL 파싱 접근법**: 실행된 모든 SQL의 이력이 남는 `INFORMATION_SCHEMA.JOBS` 뷰를 활용하여, 실행 환경과 관계없이 모든 쿼리로부터 의존성을 추출하는 방식을 채택했습니다. ### 시스템 아키텍처 및 추출 프로세스 * **기술 스택**: 대량의 쿼리 병렬 처리를 위해 **Spark**를 활용하고, SQL 파싱 및 AST(Abstract Syntax Tree) 분석을 위해 **sqlglot** 라이브러리를 사용하며, **Airflow**로 주기적인 추출 프로세스를 자동화했습니다. * **데이터 수집 및 분석**: 모든 GCP 프로젝트에서 쿼리 로그를 수집한 뒤, sqlglot으로 쿼리 구조를 분석하여 `Source Column -> Target Column` 관계를 도출합니다. * **엣지 케이스 처리**: `SELECT *`와 같은 와일드카드 쿼리는 테이블 메타데이터를 결합해 실제 컬럼명으로 확장하고, 복잡한 CTE(Common Table Expressions)나 서브쿼리 내의 의존성도 AST 탐색을 통해 정확하게 추적합니다. ### 데이터 지도를 통한 실질적 변화 * **정교한 영향도 분석**: 특정 컬럼 수정 시 다운스트림에서 이를 참조하는 모든 컬럼을 즉시 확인하여 사전에 장애를 예방할 수 있게 되었습니다. * **거버넌스 강화**: 데이터의 원천부터 최종 활용 단계까지의 흐름을 시각화함으로써 데이터 가계도(Data Genealogy)를 완성하고, 데이터 보안 및 품질 관리 수준을 한 단계 높였습니다. * **운영 효율화**: 장애 발생 시 영향 범위를 데이터 지도를 통해 한눈에 파악함으로써 원인 파악과 복구에 소요되는 리소스를 획기적으로 줄였습니다. 데이터 플랫폼의 규모가 커질수록 수동 관리는 불가능해지므로, 초기부터 SQL 로그를 활용한 자동화된 리니지 체계를 구축하는 것이 중요합니다. 특히 실행 환경이 파편화된 조직일수록 애플리케이션 계측보다는 쿼리 엔진의 로그를 파싱하는 접근법이 빠른 도입과 높은 커버리지를 확보하는 데 유리합니다.

DBT, Airflow를 활용한 데이터 계보 중심 파이프라인 만들기 (새 탭에서 열림)

네이버웹툰은 기존 데이터 파이프라인에서 발생하던 복잡한 데이터 적재(Backfill) 작업과 높은 운영 비용 문제를 해결하기 위해 DBT와 Airflow를 결합한 'Flow.er' 시스템을 구축했습니다. Flow.er는 데이터 간의 의존성을 명확히 정의하는 데이터 계보(Lineage)를 중심으로 설계되어, 엔지니어가 데이터의 흐름을 온디맨드로 파악하고 관리할 수 있게 돕습니다. 이를 통해 데이터 품질을 높이는 동시에 여러 데이터 조직으로 확장 가능한 고도화된 데이터 플랫폼으로 발전하고 있습니다. **과거 파이프라인의 한계와 Flow.er의 탄생** * 과거에는 파이프라인 복구와 수동 백필 작업에 과도한 운영 리소스가 소모되어 업무 효율이 저하되는 문제가 있었습니다. * 데이터 간의 복잡한 연결 고리를 한눈에 파악하기 어려워 데이터 정합성을 유지하고 장애에 대응하는 데 한계가 존재했습니다. * 이러한 문제를 극복하기 위해 데이터 계보를 가시화하고 자동화된 운영이 가능한 'Flow.er' 서비스에 대한 PoC를 거쳐 실무에 도입했습니다. **DBT와 Airflow를 활용한 계보 중심 아키텍처** * **DBT의 역할**: SQL 기반의 데이터 모델링을 통해 데이터 변환 로직을 관리하며, 모델 간 의존성을 바탕으로 데이터 계보와 관련 문서(Documentation)를 자동 생성합니다. * **Airflow의 역할**: DBT로 정의된 모델들이 선후 관계에 맞춰 정확히 실행되도록 워크플로우를 오케스트레이션하고 스케줄링을 담당합니다. * **개발 생산성 향상**: 개인 인스턴스를 제공하여 개발자가 격리된 환경에서 모델을 테스트할 수 있게 하고, CI/CD 파이프라인을 통해 코드 변경 사항을 안전하게 배포합니다. **시스템 안정성 및 확장을 위한 컴포넌트** * **Playground & Tower**: 자유로운 데이터 실험을 위한 샌드박스 환경인 Playground와 파이프라인 상태를 실시간으로 감시하는 Tower를 통해 운영 가시성을 확보했습니다. * **Partition Checker**: 상위 데이터 소스의 파티션 생성 여부를 사전에 체크하여 데이터 누락을 방지하고 적재 정합성을 획기적으로 개선했습니다. * **Manager DAG System**: 수많은 데이터 모델과 DAG를 효율적으로 관리하기 위해 관리 전용 시스템을 개선하여 운영 편의성을 극대화했습니다. **Flow.er의 미래와 기술적 지향점** * **MCP(Model Context Protocol) 서버**: 데이터 모델의 컨텍스트를 외부 도구나 AI 에이전트가 이해할 수 있는 규격으로 제공하여 데이터 활용도를 높일 예정입니다. * **AI Agent 연동**: 단순한 파이프라인 운영을 넘어 AI가 데이터 계보를 분석하고 문제를 해결하거나 코드를 최적화하는 단계로의 발전을 준비하고 있습니다. 데이터 파이프라인의 복잡성으로 인해 백필과 운영에 고통받고 있다면, DBT를 활용해 계보를 명확히 정의하고 이를 Airflow와 유기적으로 연결하는 접근 방식이 필수적입니다. 데이터 계보 중심의 아키텍처는 단순한 자동화를 넘어 데이터 프로덕트의 신뢰성을 담보하는 가장 강력한 수단이 될 것입니다.