1.1 데이터 파이프라인이란?
데이터 파이프라인은 데이터를 한 장소에서 다른 장소로 이동시키면서 필요한 변환을 수행하는 자동화된 프로세스입니다. 마치 물리적 파이프라인이 원유를 정제소로 운반하듯이, 데이터 파이프라인은 원시 데이터를 분석 가능한 형태로 전달합니다.
왜 파이프라인인가?
데이터는 흐름입니다. 한 곳에서 생성되어 여러 단계를 거쳐 최종 목적지에 도달합니다. 이 흐름이 막히거나 새면 전체 시스템이 마비됩니다. 따라서 견고하고 신뢰할 수 있는 파이프라인이 필수적입니다.
1.2 데이터 파이프라인의 역사
1세대: 수동 처리 (1990년대)
- 개발자가 직접 SQL 스크립트 작성
- cron으로 스케줄링
- 실패하면 수동으로 재실행
- 모니터링? 이메일 알림이 전부
2세대: ETL 도구 (2000년대)
- Informatica, Talend 같은 GUI 기반 도구
- 드래그 앤 드롭으로 파이프라인 구성
- 비즈니스 로직을 시각화
- 하지만 여전히 무겁고 비쌈
3세대: 빅데이터 시대 (2010년대)
- Hadoop, Spark 등장
- 페타바이트 규모 데이터 처리
- 분산 처리 아키텍처
- 오픈소스 생태계 폭발
4세대: 클라우드 네이티브 (2020년대)
- 서버리스 데이터 처리
- 실시간 스트리밍이 표준
- DataOps와 자동화
- AI/ML 통합
1.3 핵심 구성 요소
Data Source (데이터 소스)
데이터가 시작되는 곳:
- 애플리케이션 데이터베이스: PostgreSQL, MySQL, MongoDB
- API: REST, GraphQL, gRPC
- 파일: CSV, JSON, Parquet, Avro
- 스트림: Kafka, Kinesis, Pub/Sub
- SaaS: Salesforce, Google Analytics, Stripe
Data Pipeline (데이터 파이프라인)
데이터를 처리하는 과정:
- Ingestion: 데이터 수집
- Validation: 데이터 검증
- Transformation: 데이터 변환
- Enrichment: 데이터 보강
- Aggregation: 데이터 집계
Data Destination (데이터 목적지)
데이터가 도착하는 곳:
- Data Warehouse: Snowflake, BigQuery, Redshift
- Data Lake: S3, ADLS, GCS
- Data Mart: 특정 부서용 데이터
- 캐시: Redis, Memcached
- 애플리케이션: 다시 서비스로
1.4 데이터 파이프라인 패턴
ETL (Extract-Transform-Load)
┌──────────┐ ┌───────────┐ ┌──────────┐
│ Source │───▶│ Transform │───▶│ Dest │
└──────────┘ └───────────┘ └──────────┘
Extract Transform Load
장점:
- 목적지에 정제된 데이터만 저장 (저장 공간 절약)
- 민감한 데이터를 변환 단계에서 제거 가능
- 네트워크 대역폭 효율적
단점:
- 변환 로직이 복잡하면 병목
- 원본 데이터 보존 안 됨
- 유연성 떨어짐
ELT (Extract-Load-Transform)
┌──────────┐ ┌──────────┐ ┌───────────┐
│ Source │───▶│ Dest │───▶│ Transform │
└──────────┘ └──────────┘ └───────────┘
Extract Load Transform
장점:
- 원본 데이터 보존 (재처리 가능)
- 빠른 로딩
- 유연한 변환 (나중에 변경 가능)
- 클라우드 웨어하우스의 강력한 연산력 활용
단점:
- 저장 공간 많이 사용
- 민감한 데이터가 웨어하우스에 저장됨
- 네트워크 대역폭 많이 사용
Reverse ETL
┌───────────┐ ┌───────────┐ ┌──────────┐
│ Warehouse │───▶│ Transform │───▶│ SaaS │
└───────────┘ └───────────┘ └──────────┘
데이터 웨어하우스의 분석 결과를 다시 운영 시스템으로 전달:
- 고객 세그먼트를 Salesforce로
- 추천 목록을 이메일 마케팅 도구로
- 이탈 예측을 CRM으로
1.5 Batch vs Stream
Batch Processing (배치 처리)
개념: 데이터를 모아서 한 번에 처리
매일 새벽 2시:
1. 어제 하루 거래 데이터 수집
2. 정제 및 집계
3. 리포트 생성
4. 이메일 발송
적합한 경우:
- 대량 데이터 처리
- 복잡한 집계 (예: 월별 매출 분석)
- 정확성이 지연시간보다 중요
- 비용 최적화 (야간 시간대 활용)
Stream Processing (스트림 처리)
개념: 데이터가 생성되는 즉시 처리
실시간:
사용자 클릭 → Kafka → 실시간 분석 → 대시보드 업데이트
적합한 경우:
- 실시간 알림 (예: 이상 거래 탐지)
- 실시간 대시보드
- 이벤트 기반 액션 (예: 추천 시스템)
- 낮은 지연시간이 중요
Lambda Architecture
Batch와 Stream을 함께 사용:
┌─────────┐
│ Source │
└────┬────┘
├──▶ Batch Layer (정확성)
└──▶ Speed Layer (실시간)
↓
Serving Layer (결합)
- Batch Layer: 정확한 결과, 높은 지연시간
- Speed Layer: 근사치 결과, 낮은 지연시간
- Serving Layer: 두 결과를 합쳐서 제공
1.6 데이터 파이프라인의 도전과제
1. 데이터 품질
- 불완전한 데이터 (null 값)
- 중복 데이터
- 형식 오류 (잘못된 날짜 형식)
- 비즈니스 로직 위반 (음수 금액)
2. 확장성
- 데이터 양이 10배 증가하면?
- 새로운 데이터 소스 추가는?
- 처리 시간이 24시간을 넘으면?
3. 신뢰성
- 네트워크 장애
- 데이터베이스 다운타임
- API 변경
- 디스크 공간 부족
4. 모니터링
- 파이프라인이 실패했는지 어떻게 알까?
- 데이터 품질이 떨어지는지 어떻게 감지할까?
- 성능 저하를 미리 예측할 수 있을까?
1.7 WIA-DATA-004의 접근법
이 표준은 위의 도전과제를 해결하기 위한 체계적인 가이드를 제공합니다:
- 표준화된 데이터 형식: 모든 파이프라인이 따라야 할 스키마
- 명확한 API: 파이프라인 컴포넌트 간 통신 프로토콜
- 멱등성 보장: 재실행해도 안전한 파이프라인
- 관찰성: 모든 것을 로깅하고 모니터링
- 에러 핸들링: 실패는 당연하다, 복구가 중요하다
- 데이터 품질: 빠른 실패, 명확한 검증
홍익인간의 정신으로
데이터 파이프라인은 기술이 아닙니다. 사람들에게 가치를 전달하는 수단입니다. 의사가 정확한 환자 데이터를 받을 때, 기업이 올바른 비즈니스 결정을 내릴 때, 연구자가 신뢰할 수 있는 데이터로 새로운 발견을 할 때 - 그때 우리는 인류를 이롭게 합니다.
1.8 다음 장 미리보기
다음 장에서는 데이터 수집(Extract)의 세계로 들어갑니다:
- 다양한 데이터 소스에서 데이터 추출하기
- Full load vs Incremental load
- Change Data Capture (CDC)
- API 속도 제한 다루기
- 실전 코드 예제