Lv.2 초급데이터 엔지니어링
25분 읽기Lv.2 초급
Data Engineering Playbook Part 3: 데이터 파이프라인 구축 실전 가이드
이 글은 2026년 기준 데이터 파이프라인 설계와 운영의 실무 기준을 정리합니다. ETL/ELT/Zero-ETL 선택 기준부터 dbt 3계층 모델링, Airflow·Dagster·Prefect 오케스트레이션 비교, Kafka+Flink 스트리밍 패턴까지 한 번에 다룹니다. 마지막에는 신뢰성 원칙과 모니터링 체크리스트를 통해 운영 단계에서 바로 적용할 수 있는 기준을 제공합니다.
시리즈 구성
- Part 1: 개요와 2026 핵심 트렌드 (완료)
- Part 2: 데이터 아키텍처 설계 (완료)
- Part 3: 데이터 파이프라인 구축 실전 가이드 (현재 글)
- Part 4: 데이터 품질과 거버넌스 (예정)
- Part 5: 클라우드 인프라와 FinOps (예정)
- Part 6: AI-Native 데이터 엔지니어링 (예정)
- Part 7: DataOps 팀 운영 플레이북 (예정)
목차
- 데이터 파이프라인이란?
- ETL vs ELT vs Zero-ETL: 무엇을 선택할까
- Ingestion: 데이터를 어떻게 가져올까
- Transformation: dbt 실전 패턴
- Orchestration: Airflow vs Dagster vs Prefect
- Streaming: Kafka + Flink 설계
- 신뢰성: 믿을 수 있는 파이프라인 만드는 법
- 모니터링과 알림 설계
- 실전 체크리스트
1. 데이터 파이프라인이란?
데이터 파이프라인은 여러 소스에서 데이터를 수집하고, 필요한 변환을 적용한 뒤, 분석/서비스 시스템으로 안정적으로 전달하는 자동화 흐름이다.
한 줄로 요약하면, 데이터를 "계속 쓸 수 있는 상태"로 공급하는 운영 시스템이다.
소스 시스템(DB, API, 이벤트, 파일, SaaS)
-> 수집(Ingestion)
-> 변환(Transformation)
-> 저장(Storage)
-> 제공(Serving: BI, ML, API)
파이프라인이 불안정하면 영향은 매우 넓다. 잘못된 대시보드, 늦은 리포트, 품질이 떨어진 모델 추론까지 결국 같은 문제로 연결된다.
2. ETL vs ELT vs Zero-ETL
핵심 차이: "어디에서 변환하나?"
ETL: Source -> Transform -> Load
- 별도 처리 레이어에서 먼저 변환한 뒤 웨어하우스에 적재
- 규제/컴플라이언스가 강한 환경에서 여전히 유효
ELT: Source -> Load -> Transform
- 원시 데이터를 먼저 적재하고 웨어하우스 내부에서 변환
- 현대 클라우드 분석 스택의 기본 선택지
Zero-ETL: Source -> Direct integration/query -> Analysis
- 파이프라인 운영 부담과 데이터 이동량 최소화
- 품질/거버넌스/의미 모델링 이슈는 별도로 관리 필요
| 항목 | ETL | ELT |
|---|---|---|
| 변환 위치 | 별도 처리 계층 | 클라우드 웨어하우스 내부 |
| 원시 데이터 보관 | 제한적 | 재처리 용도로 보관 가능 |
| 스키마 변경 대응 | 사전 정의 중심 | 비교적 유연 |
| 보안/컴플라이언스 | 로드 전 마스킹/정제 유리 | 로드 후 통제 체계 필수 |
| 비용 구조 | 별도 처리 비용 | 웨어하우스 컴퓨팅 비용 |
2026 실무 권고
- 기본값은
ELT로 두고 시작한다. - 규제 강도, 민감정보 처리, 레거시 시스템 제약이 크면
ETL또는 하이브리드를 사용한다. Zero-ETL은 이동을 줄여주지만, 데이터 품질/정의 통합 문제를 자동으로 해결해주지는 않는다.
3. Ingestion: 데이터를 어떻게 가져올까
배치 수집
| 도구 | 특징 | 적합한 상황 |
|---|---|---|
| Fivetran | 관리형 커넥터, 자동 스키마 추적 | 빠른 SaaS 연동 |
| Airbyte | 오픈소스, 커스텀 확장 유리 | 벤더 종속 최소화 |
| AWS Glue | 서버리스 ETL | AWS 중심 환경 |
스트리밍 수집
Event Sources -> Kafka -> Flink -> Serving Store
- 앱 이벤트 / IoT / CDC 스트림
- 대상: Iceberg, Warehouse, OLAP DB
CDC(Change Data Capture)는 트랜잭션 DB의 변경(INSERT/UPDATE/DELETE)을 이벤트로 추출해 전달하는 방식이다.
PostgreSQL -> Debezium(CDC) -> Kafka -> Data Lake/Warehouse
(near real-time replication)
4. Transformation: dbt 실전 패턴
dbt는 ELT의 T를 담당하는 SQL 기반 프레임워크다.
변환 로직을 코드로 관리하고, 테스트와 문서화를 통해 운영 신뢰성을 높인다.
3계층 모델링
my_dbt_project/
models/
staging/
stg_orders.sql
stg_customers.sql
intermediate/
int_order_items_joined.sql
marts/
core/fct_orders.sql
marketing/dim_customers.sql
tests/
macros/
dbt_project.yml
staging: 소스 정규화(이름/타입 정리)intermediate: 조인, 비즈니스 중간 계산marts: BI/ML이 직접 조회하는 최종 모델
예시: Staging 모델
with source as (
select * from {{ source('raw', 'orders') }}
),
renamed as (
select
id as order_id,
user_id as customer_id,
status as order_status,
created_at as ordered_at,
amount_cents / 100.0 as order_amount_usd
from source
)
select * from renamed
예시: 데이터 테스트
version: 2
models:
- name: fct_orders
columns:
- name: order_id
tests: [unique, not_null]
- name: order_status
tests:
- not_null
- accepted_values:
values: ['placed', 'shipped', 'delivered', 'cancelled']
Materialization 선택
Table
- 최종 마트 모델에 적합
View
- 단순 변환에 적합
Incremental
- 대용량 이벤트/로그 테이블에 적합
- unique_key + upsert 전략 필수
Ephemeral
- 보조 변환 로직 재사용에 적합(CTE 컴파일)
5. Orchestration: Airflow vs Dagster vs Prefect
오케스트레이터는 파이프라인의 실행 순서, 재시도, 의존성, 장애 대응을 관리한다.
| 항목 | Airflow | Dagster | Prefect |
|---|---|---|---|
| 핵심 모델 | DAG/Task | Asset | Flow/Task |
| 장점 | 생태계/검증된 운영성 | 계보/자산 중심 설계 | Python-first DX |
| 주의점 | 초기 운영 복잡도 | 학습 곡선 | 대규모 사례는 상대적으로 적음 |
6. Streaming: Kafka + Flink 설계
Kafka 핵심 개념
Topic: 이벤트 카테고리
Partition: 병렬 처리 단위
Consumer Group: 파티션을 나누어 읽는 소비자 집합
Offset: 파티션 내 이벤트 위치
Retention: 이벤트 보관 기간
Flink 처리 예시
from pyflink.datastream import StreamExecutionEnvironment
from pyflink.common import WatermarkStrategy, Duration
env = StreamExecutionEnvironment.get_execution_environment()
env.set_parallelism(4)
transactions = env.from_source(
kafka_source,
WatermarkStrategy.for_bounded_out_of_orderness(Duration.of_seconds(5)),
"Kafka Transactions"
)
스트리밍 레이크하우스 패턴
Event Sources
-> Kafka topics (durable log)
-> Flink (filter/join/window/feature compute)
-> Iceberg (Bronze/Silver)
-> Trino/Spark SQL (batch/ad-hoc)
-> Redis/Cassandra (low-latency serving)
7. 신뢰성: 믿을 수 있는 파이프라인 만드는 법
원칙 1. 멱등성(Idempotency)
같은 작업을 여러 번 실행해도 결과가 같아야 한다.
insert into orders_summary
select date, sum(amount) as total
from orders
group by date
on conflict (date) do update
set total = excluded.total;
원칙 2. Fail Fast
문제가 있으면 초기에 즉시 실패시켜야 한다.
def validate_orders(df):
if df[['order_id', 'customer_id', 'amount']].isnull().any().any():
raise ValueError("필수 컬럼 NULL 발견")
if (df['amount'] < 0).any():
raise ValueError("음수 금액 발견")
원칙 3. 재처리 가능성(Reprocessability)
원시(Bronze) 보존 후, Silver/Gold를 다시 계산할 수 있어야 한다.
1) Bronze 보존
2) 변환 로직 수정
3) Silver 재실행
4) Gold 재실행
원칙 4. Backfill 지원
특정 과거 구간을 안전하게 재실행할 수 있어야 한다.
8. 모니터링과 알림 설계
핵심 4지표
1) Success Rate: 연속 실패 감지
2) Freshness: SLA 시간 내 최신화 여부
3) Volume Anomaly: 입력량 급증/급감 감지
4) Runtime: 실행 시간 증가 추세 감지
알림은 "조치 가능"해야 한다
def alert_slack_on_failure(context):
dag_id = context['dag'].dag_id
task_id = context['task_instance'].task_id
log_url = context['task_instance'].log_url
message = f"[FAIL] {dag_id}.{task_id} | {log_url}"
send_slack_message(channel="#data-alerts", message=message)
9. 실전 체크리스트
설계
- ETL/ELT/Zero-ETL 선택 근거가 문서화되어 있는가
- 민감정보 처리(마스킹/권한/감사)가 파이프라인에 반영되어 있는가
수집
- 스키마 변경 감지와 대응 규칙이 있는가
- CDC 지연 허용 범위(SLA)가 정의되어 있는가
변환
- staging/intermediate/marts 계층이 분리되어 있는가
- 핵심 모델에
not_null,unique테스트가 있는가
운영
- 재시도/백필/재처리 경로가 준비되어 있는가
- 실패 알림이 실제 조치 단위로 연결되는가
마무리
좋은 파이프라인의 목표는 "흐르게 만드는 것"이 아니라, 신뢰 가능한 데이터 제품을 지속적으로 공급하는 것이다.
기술 선택(ELT, dbt, 오케스트레이터, 스트리밍)은 결국 이 목표를 얼마나 안정적으로 달성하느냐로 평가해야 한다.
다음 Part 4에서는 데이터 품질과 거버넌스를 코드로 구현하는 DataGovOps 실전 패턴을 다룬다.