데이터 파이프라인(Data Pipeline)

•

2026년 09월 13일 발행•2026년 09월 13일 수정

요약

원천 시스템에서 데이터를 수집·변환·적재하여 분석과 서비스에 사용할 수 있는 형태로 자동 전달하는 일련의 처리 흐름

중급

데이터베이스와 분산 처리에 대한 기본 이해가 필요하며, 스케줄링, 멱등성, 이벤트 시간과 같은 운영 설계 개념을 함께 알아야 한다.

태그

ETL 데이터 웨어하우스 데이터 레이크 데이터 엔지니어 지연 시간

#개념

데이터 파이프라인(Data Pipeline)은 여러 원천 시스템에서 발생한 데이터를 수집(ingestion)하고, 정제·변환(transformation)한 뒤, 데이터 웨어하우스(Data Warehouse)나 데이터 레이크(Data Lake), 서비스 데이터베이스 등 목적지에 적재(loading)하기까지의 과정을 자동화한 처리 흐름이다. 각 단계는 입력을 받아 출력을 만드는 태스크(task)로 구성되며, 태스크 간 의존 관계는 일반적으로 방향 비순환 그래프(Directed Acyclic Graph, DAG)로 표현된다.

데이터 파이프라인은 데이터 엔지니어(Data Engineer)의 핵심 산출물로, 분석가의 대시보드, 데이터 과학자의 학습 데이터셋, 온라인 서비스의 특징(feature) 제공까지 조직의 모든 데이터 활용이 이 흐름 위에서 이루어진다. 파이프라인을 단순한 스크립트의 나열이 아니라 신뢰성, 재현성, 관측 가능성을 갖춘 소프트웨어 시스템으로 다루는 것이 현대 데이터 엔지니어링의 기본 관점이다.

파이프라인은 데이터를 처리하는 시간 단위에 따라 두 가지로 나뉜다.

배치 처리와 스트리밍 처리

배치 처리(Batch Processing) : 일정 주기(시간, 일 단위)로 누적된 데이터를 한 번에 처리하는 방식이다. 구현이 단순하고 대용량 데이터를 효율적으로 처리할 수 있지만, 결과가 반영되기까지 주기만큼의 지연이 발생한다. Apache Spark, Hadoop MapReduce, SQL 기반 변환이 대표적이다.
스트리밍 처리(Stream Processing) : Apache Kafka와 같은 메시지 브로커를 통해 이벤트가 발생하는 즉시 연속적으로 처리하는 방식이다. 초 단위 이하의 지연 시간(Latency)을 달성할 수 있으나, 이벤트가 순서대로 도착하지 않는 문제(out-of-order)를 다루어야 한다. 이를 위해 이벤트가 실제 발생한 이벤트 시간(event time)과 시스템이 처리하는 처리 시간(processing time)을 구분하고, 윈도우(window)로 데이터를 묶으며, 늦게 도착한 데이터를 어디까지 기다릴지 결정하는 워터마크(watermark)를 사용한다. Apache Flink, Spark Structured Streaming, Google Cloud Dataflow가 이 모델을 구현한다.

과거에는 배치 계층과 스트리밍 계층을 병행 운영하는 람다 아키텍처(Lambda Architecture)가 사용되었으나, 동일한 로직을 두 번 구현해야 하는 부담 때문에 스트리밍 엔진 하나로 통합하는 카파 아키텍처(Kappa Architecture)나 배치·스트리밍을 하나의 API로 다루는 통합 엔진이 널리 쓰이고 있다.

변환이 이루어지는 위치에 따라 파이프라인 패턴은 ETL(Extract, Transform, Load)과 ELT(Extract, Load, Transform)로 구분된다. ETL은 목적지에 적재하기 전에 별도의 처리 엔진에서 변환을 완료하는 전통적 방식으로, 목적지 저장소의 용량과 연산 자원이 비쌌던 시기에 정립되었다. 반면 ELT는 원본 데이터를 먼저 데이터 레이크나 클라우드 웨어하우스에 그대로 적재한 뒤, 저장소 내부의 분산 SQL 엔진으로 변환을 수행한다.

저장 비용이 낮아지고 연산과 저장이 분리된 클라우드 환경이 보편화되면서 ELT가 주류가 되었으며, dbt와 같은 도구는 SQL 변환을 버전 관리, 테스트, 문서화가 가능한 모듈 단위로 관리하게 해 준다. 원본을 보존하는 ELT는 변환 로직이 바뀌었을 때 처음부터 다시 계산할 수 있다는 점에서 재처리에도 유리하다.

수십에서 수천 개의 태스크가 서로 의존하는 파이프라인을 정해진 순서와 일정에 따라 실행하고, 실패 시 재시도하며, 상태를 추적하는 역할을 오케스트레이션(orchestration)이라 한다. Apache Airflow는 파이썬 코드로 DAG를 정의하고 스케줄러가 의존 관계에 따라 태스크를 실행하는 가장 널리 쓰이는 오케스트레이터이며, Dagster, Prefect, Argo Workflows 등이 대안으로 사용된다.

오케스트레이터는 스케줄링뿐 아니라 태스크 간 의존성 관리, 실패 알림, 재시도 정책, 실행 이력과 로그 보관, 특정 시점의 재실행을 담당한다. 최근에는 시간 기준 스케줄 대신 상위 데이터가 갱신되었을 때 하위 태스크를 실행하는 데이터 인지형(data-aware) 스케줄링이 도입되어, 파이프라인을 태스크 중심이 아닌 데이터 자산(asset) 중심으로 정의하는 흐름이 강화되고 있다.

파이프라인은 네트워크 오류, 원천 시스템 장애, 코드 버그 등으로 언제든 실패할 수 있으므로, 같은 작업을 여러 번 실행해도 결과가 동일하게 유지되는 멱등성(idempotency)이 설계의 핵심 원칙이다. 이를 위해 결과를 단순히 추가(append)하는 대신 파티션 단위로 덮어쓰기(overwrite)하거나, 고유 키를 기준으로 병합(merge/upsert)하는 방식을 사용한다.

멱등성이 보장되면 실패한 구간을 안심하고 재실행하는 재처리(reprocessing)가 가능하며, 변환 로직이 변경되거나 과거 데이터 오류가 발견되었을 때 특정 기간의 데이터를 소급하여 다시 생성하는 백필(backfill)도 안전하게 수행할 수 있다. 오케스트레이터가 각 실행에 논리적 처리 구간(예: 2026-09-12 하루치)을 부여하고, 태스크가 실행 시각이 아닌 이 구간을 기준으로 데이터를 읽고 쓰도록 설계하면 과거 구간의 백필과 정상 실행이 동일한 코드로 처리된다. 스트리밍 파이프라인에서는 체크포인트와 정확히 한 번(exactly-once) 처리 의미론이 같은 역할을 한다.

파이프라인이 오류 없이 종료되었다는 사실이 데이터가 올바르다는 것을 보장하지는 않는다. 원천 스키마가 예고 없이 변경되거나, 특정 컬럼이 전부 null로 채워지거나, 행 수가 평소의 절반으로 줄어드는 문제는 코드 오류 없이도 발생한다. 이를 방지하기 위해 각 단계의 출력에 대해 null 비율, 고유 키 중복, 값의 범위, 행 수 변화 등을 검사하는 데이터 품질 테스트를 파이프라인 안에 내장하며, Great Expectations나 dbt test 같은 도구가 이를 지원한다.

여기에 데이터의 신선도(freshness), 분포(distribution), 볼륨(volume), 스키마(schema), 리니지(lineage)를 지속적으로 감시하고 이상 징후를 자동 탐지하는 데이터 관측성(data observability) 개념이 소프트웨어 관측성에서 차용되어 정착했다. 파이프라인의 성공 여부와 실행 시간 같은 운영 지표뿐 아니라 데이터 자체의 상태를 측정 대상에 포함하는 것이 핵심이다.

데이터 리니지(data lineage)는 특정 테이블이나 컬럼이 어떤 원천에서 어떤 변환을 거쳐 만들어졌는지를 추적하는 계보 정보다. 리니지가 확보되면 상위 데이터에 오류가 발생했을 때 영향을 받는 하위 대시보드와 모델을 즉시 파악하는 영향 분석(impact analysis)이 가능하고, 반대로 대시보드 수치가 이상할 때 원인을 상류로 거슬러 올라가는 근본 원인 분석(root cause analysis)이 쉬워진다.

개인정보가 어디로 흘러가는지 증명해야 하는 규제 대응에서도 필수적이다. OpenLineage와 같은 개방형 표준은 Airflow, Spark, dbt 등 서로 다른 도구가 실행 중에 생성하는 리니지 메타데이터를 공통 형식으로 수집하여 데이터 카탈로그에 통합한다.

결론적으로 데이터 파이프라인은 단순히 데이터를 옮기는 도구가 아니라, 배치와 스트리밍 처리 모델의 선택, ETL과 ELT 패턴, 오케스트레이션, 멱등성에 기반한 재처리·백필 설계, 품질 검증과 관측성, 리니지 추적이 결합된 하나의 데이터 제품(data product)이다. 잘 설계된 파이프라인은 장애가 발생해도 예측 가능한 방식으로 복구되고, 사용자가 데이터를 신뢰할 수 있는 근거를 제공하며, 요구사항 변화에 따라 안전하게 확장될 수 있어야 한다.

#관련 용어

추출·변환·적재(ETL)

원천에서 데이터를 추출하고 변환한 뒤 목적지 저장소에 적재하는 전통적 데이터 통합 패턴

오케스트레이션

의존 관계를 가진 여러 태스크를 정해진 순서와 일정에 따라 실행하고 실패를 관리하는 작업 조율 체계

멱등성

동일한 작업을 여러 번 실행해도 결과가 한 번 실행한 것과 같게 유지되는 성질

백필

변환 로직 변경이나 데이터 오류 발생 시 과거 특정 기간의 데이터를 소급하여 다시 생성하는 작업

데이터 리니지

데이터가 어떤 원천에서 어떤 변환을 거쳐 현재 위치에 도달했는지를 추적하는 계보 정보

데이터 레이크

원본 형태의 정형·비정형 데이터를 대규모로 저장하는 중앙 저장소

#직무 연관도

Data Analyst높음

분석에 사용하는 테이블이 어떻게 생성되고 얼마나 신뢰할 수 있는지 판단하려면 파이프라인의 흐름과 품질 검증 방식을 알아야 한다

Data Scientist높음

학습 데이터셋과 특징의 생성이 파이프라인에 의존하므로 재현 가능한 실험과 모델 운영을 위해 그 구조를 이해해야 한다

Data Engineer밀접

데이터 파이프라인의 설계, 구축, 운영은 데이터 엔지니어의 핵심 업무이며 신뢰성과 확장성을 좌우한다

#사용 사례

전자상거래금융인터넷 서비스제조통신온라인 광고

개요

데이터 파이프라인은 로그 수집과 지표 집계, 데이터 웨어하우스 적재, 머신러닝 학습 데이터 생성, 실시간 개인화와 이상 탐지 등 데이터가 생성되어 활용되기까지의 모든 경로에 사용된다. 운영 데이터베이스와 분석 환경을 분리하고, 여러 원천의 데이터를 일관된 기준으로 통합하는 데 필수적이다.

사례

전자상거래 서비스에서는 주문·결제 이벤트를 Kafka로 수집하고, 스트리밍 파이프라인으로 실시간 매출 지표와 이상 거래 탐지를 수행하는 동시에, 일 단위 배치 파이프라인이 Airflow의 스케줄에 따라 상품·사용자 데이터를 결합하여 추천 모델의 학습 데이터셋을 생성한다. 원천 로그 형식이 바뀌어 특정 날짜의 집계가 잘못되었을 때는 해당 기간만 백필하여 하위 대시보드와 모델 데이터를 일괄 복구한다.