Data Eng Wiki

Data Pipeline Fundamentals

6 min read

Data Pipeline Fundamentals

데이터 파이프라인의 존재 이유, 핵심 패턴, 구축 요소, 그리고 운영 현실

핵심 개념

데이터 파이프라인은 소스에서 목적지로 데이터를 이동·변환·반복 실행하는 자동화된 프로세스다. 그러나 기술적 기능을 넘어 **비즈니스 성과(outcomes)**와 소유권(ownership) 관점에서 사고해야 진정한 가치를 발휘한다.

AI 시대에도 3,000줄짜리 SQL 쿼리와 커스텀 파이프라인은 건재하며, 도구가 발전할수록 파이프라인의 수와 복잡성은 오히려 증가하는 경향이 있다.

파이프라인 유형

소스 표준화 파이프라인

수십 개 외부 파트너의 이기종 데이터(CSV, XML, 포지셔널 파일, API)를 단일 데이터 모델로 통합. 값 표준화(성별, 카테고리), 포맷 정규화(날짜, 타임존), 매핑 관리가 핵심 과제. 표준화된 데이터셋 위에 마켓플레이스, 산업 리포트 등 다중 프로덕트 구축 가능.

분석/비즈니스 파이프라인

SaaS 소스에서 웨어하우스로 추출 → dbt 등으로 변환 → BI에 서빙하는 전형적 패턴. 소규모 조직도 수십 개의 커넥터 솔루션을 운영하게 된다.

로딩 전략: Full Refresh vs Incremental

기준Full RefreshIncremental
구현 난이도낮음 (CREATE OR REPLACE)높음 (변경 추적 필요)
컴퓨트 비용높음 (전체 재구축)낮음 (변경분만)
백필 용이성단순 (재실행)복잡 (파티션별 정합성)
업데이트/삭제자연스러움MERGE 또는 CDC 필요
적합 시나리오소규모, 변경 추적 불가대규모, 실시간 필요

WAP (Write-Audit-Publish) 패턴: 스테이징 → 검증 → 프로덕션 승격으로 두 전략 모두 안전성 강화.

파이프라인 시스템 핵심 컴포넌트

자체 구축 시 필요한 4가지 핵심 컴포넌트:

  1. 시크릿/커넥션 관리: 소스·목적지 중앙화, 비밀번호 단일 수정 포인트
  2. 로깅/모니터링: AI 생성 코드 시대에 추적 가능한 에러 메시지가 더욱 중요
  3. 의존성 그래프(DAG): Airflow set_downstream(), dbt ref() 등으로 태스크 간 의존성 선언
  4. 실행 엔진 라우팅: DuckDB, Presto, Spark 등 다중 컴퓨트 엔진 간 비용·성능 최적 라우팅

백필: 불가피한 현실

백필 원인

  • 잘못된 소스 데이터, 파이프라인 버그, 스키마/로직 변경

백필이 어려운 이유

  • 규모: Facebook에서 1,000+ 태스크 재실행
  • 비용: pay-as-you-go 환경에서 재실행 비용
  • Blast Radius: 수백 명의 소비자에게 영향, 신뢰 훼손

테이블 유형별 전략

  • 전통 테이블: 파라미터화된 파이프라인으로 특정 날짜·파트너만 재실행
  • 파티션 기반: blue-green 스타일 테이블 스왑이 일관성 면에서 더 안전
  • 스키마 변경: ORC/Avro/Parquet의 제한으로 테이블 재생성 필요

데이터 스택 복잡성의 함정

도구와 레이어를 무분별하게 추가하면 시스템이 프랙탈처럼 복잡해진다. BI sprawl, pipeline sprawl, model sprawl, agent sprawl, cost sprawl의 동시 발생이 현실.

레이어 추가 전 3가지 질문:

  1. 이 레이어가 해결하는 문제는 무엇인가?
  2. 추가하지 않으면 무엇이 깨지는가?
  3. 6개월 후 누가 소유하는가?

연관 개념

Source: Why Data Pipelines Exist, Common Data Pipeline Patterns, What It Actually Takes to Build a Data Pipeline System, Full Refresh vs Incremental Pipelines, Backfills - The Necessary Evil of Data Engineering, Layer by Layer We Built Data Systems No One Understands

그래프 뷰

백링크