liminfoData Pipeline Reference
데이터 파이프라인 아키텍처 레퍼런스 - ETL/ELT, CDC, 스트리밍
Data Pipeline Reference 소개
데이터 파이프라인 레퍼런스는 현대 데이터 엔지니어링의 핵심 패턴, 아키텍처, 개념을 다루는 간결하고 검색 가능한 가이드입니다. 패턴(ETL, ELT, 배치, 스트리밍, CDC), 아키텍처(람다, 카파, 데이터 레이크, 데이터 웨어하우스, 레이크하우스, Medallion), 개념(Schema-on-Read vs Schema-on-Write), 품질(Exactly-once 시맨틱, 멱등성) 등 4개 카테고리로 구성됩니다. 각 항목은 개념을 설명하고 관련 실제 도구를 명시하며 언제 어떻게 적용하는지 간결한 예시를 제공합니다.
이 레퍼런스는 아키텍처 접근 방식의 차이와 트레이드오프를 빠르게 구분해야 하는 데이터 엔지니어, 애널리틱스 엔지니어, 데이터 아키텍트를 위해 설계되었습니다. 패턴 섹션은 두 가지 주요 통합 스타일을 다룹니다. ETL(Informatica, Talend, SSIS 등 도구로 로드 전 변환)과 ELT(dbt, Fivetran, Airbyte로 데이터 웨어하우스 내에서 변환). 배치 처리(Spark, Airflow로 주기적 실행), 스트리밍(Kafka, Flink, Kinesis로 지속적 저지연 처리), CDC(Debezium으로 DB 변경 로그를 실시간 스트리밍)도 포함됩니다.
아키텍처 섹션은 주요 데이터 저장 및 처리 패러다임을 다룹니다. 람다 아키텍처는 배치 레이어(정확한 재계산)와 스피드 레이어(실시간 근사)를 서빙 레이어에서 병합합니다. 카파 아키텍처는 모든 데이터를 스트림으로 처리하여 단순화합니다. 데이터 레이크는 원시 데이터를 어떤 형식으로든 저장하고 읽기 시 스키마를 적용합니다. 데이터 웨어하우스(Snowflake, BigQuery, Redshift)는 쓰기 시 스키마를 강제합니다. 레이크하우스(Delta Lake, Apache Iceberg, Hudi)는 ACID 트랜잭션과 오픈 포맷으로 두 방식을 통합합니다. Medallion 아키텍처는 데이터를 Bronze(원시), Silver(정제), Gold(비즈니스 집계) 레이어로 구성합니다.
주요 기능
- 4개 카테고리: 패턴, 아키텍처, 개념, 품질 — 각 항목에 실제 도구명 포함
- ETL vs ELT 비교: Informatica/Talend vs dbt/Fivetran/Airbyte 도구 생태계
- 배치 vs 스트리밍 트레이드오프: MapReduce/Spark/Airflow vs Kafka/Kinesis/Flink
- Debezium과 Kafka를 이용한 CDC(Change Data Capture) 실시간 DB 변경 스트리밍
- 람다 아키텍처(배치+스피드+서빙 레이어)와 카파 아키텍처(스트림 전용) 비교
- 데이터 레이크 vs 데이터 웨어하우스 vs 레이크하우스 — 스키마 전략, 열 기반 저장, ACID 트랜잭션
- Medallion 아키텍처: Bronze/Silver/Gold 데이터 품질 레이어와 각 레이어의 목적
- 데이터 품질 개념: Exactly-once 처리 보장, 멱등성, MERGE/UPSERT 패턴
자주 묻는 질문
ETL과 ELT의 차이는 무엇인가요?
ETL(Extract-Transform-Load)은 데이터를 목적지에 로드하기 전에 변환합니다. 변환은 Informatica, Talend, SSIS 같은 별도 처리 레이어에서 이루어집니다. ELT(Extract-Load-Transform)는 먼저 데이터 웨어하우스에 원시 데이터를 로드한 후 웨어하우스 내부의 컴퓨팅 파워를 사용하여 변환합니다. dbt, Fivetran, Airbyte가 ELT 패턴을 따릅니다. 클라우드 데이터 웨어하우스에서는 컴퓨팅이 저렴하고 데이터를 재추출하지 않고도 변환을 재실행할 수 있어 ELT가 선호됩니다.
배치 처리와 스트리밍 중 어떤 것을 선택해야 하나요?
배치 처리는 주기적으로(시간별, 일별, 주별) 실행하며 누적된 대량 데이터를 한 번에 처리합니다. 구현이 단순하고 높은 레이턴시를 허용하며 야간 보고서, 일별 집계 같은 경우에 적합합니다. 스트리밍은 데이터가 도착하는 즉시 낮은 레이턴시(초 또는 밀리초)로 지속적으로 처리합니다. 실시간 대시보드, 사기 감지, 실시간 추천, 새 데이터에 즉시 반응하는 것이 비즈니스 가치를 갖는 경우에 사용하세요. 배치에는 Spark/Airflow, 스트리밍에는 Kafka/Flink/Kinesis를 사용합니다.
CDC(Change Data Capture)란 무엇이고 왜 중요한가요?
CDC는 데이터베이스 트랜잭션 로그에서 모든 INSERT, UPDATE, DELETE 작업을 캡처하여 실시간으로 하위 시스템에 스트리밍합니다. 전체 테이블을 주기적으로 쿼리하는 방식(느리고 삭제를 놓침)과 달리, CDC는 MySQL binlog나 PostgreSQL WAL을 읽어 정밀한 변경 이벤트 스트림을 생성합니다. Debezium이 가장 널리 사용되는 오픈소스 CDC 커넥터로, 주로 Kafka와 함께 사용됩니다. CDC는 데이터 웨어하우스, 캐시, 마이크로서비스를 낮은 레이턴시로 동기화하는 데 필수적입니다.
Medallion 아키텍처(Bronze/Silver/Gold)란 무엇인가요?
Medallion 아키텍처는 레이크하우스의 데이터를 세 가지 품질 계층으로 구성합니다. Bronze는 소스에서 수집된 원시 데이터를 중복과 오류를 포함하여 전체 이력과 함께 저장합니다. Silver는 정제, 중복 제거, 타입 캐스팅, 기본 변환을 적용하여 신뢰할 수 있는 정규화 데이터셋을 만듭니다. Gold는 BI 도구와 머신러닝에 바로 사용할 수 있는 비즈니스 수준의 집계와 도메인별 뷰를 포함합니다. 이 레이어 구조는 데이터 계보를 추적 가능하게 하고 원본 데이터를 잃지 않고 어느 레이어든 재처리할 수 있게 합니다.
데이터 레이크와 데이터 웨어하우스의 차이는 무엇인가요?
데이터 레이크는 스키마를 미리 강제하지 않고 원시 형식(CSV, JSON, Parquet, 이미지, 로그)으로 데이터를 저장합니다. 이것이 Schema-on-Read입니다. 쿼리 시 스키마를 적용합니다. S3, ADLS, GCS가 대표적입니다. 데이터 웨어하우스는 쓰기 시 스키마를 강제하는 구조화된 데이터를 저장합니다. 이것이 Schema-on-Write입니다. 빠른 분석 쿼리를 위해 열 기반 저장을 사용합니다. Snowflake, BigQuery, Redshift가 대표적입니다. 데이터 레이크는 유연하지만 품질 유지가 어렵고, 데이터 웨어하우스는 구조화 분석에 고성능이지만 유연성이 부족합니다.
레이크하우스란 무엇이고 Delta Lake, Apache Iceberg와 어떤 관계인가요?
레이크하우스는 데이터 레이크의 저비용 유연한 스토리지와 데이터 웨어하우스의 ACID 트랜잭션, 스키마 강제, 쿼리 성능을 결합한 아키텍처입니다. Delta Lake(Databricks), Apache Iceberg, Apache Hudi는 S3 같은 클라우드 객체 스토리지 위에 트랜잭션 기능(ACID 트랜잭션, 타임 트래블, 스키마 진화)을 추가하는 오픈 테이블 포맷입니다. 동시 읽기/쓰기, 롤백, 증분 처리를 지원하면서 Parquet 같은 오픈 파일 포맷을 유지합니다.
스트리밍 파이프라인에서 Exactly-once 처리란 무엇인가요?
Exactly-once 처리는 스트림의 각 이벤트가 정확히 한 번만 처리됨을 보장합니다. 0번(at-most-once)도, 두 번 이상(at-least-once)도 아닙니다. Exactly-once를 달성하려면 두 가지가 필요합니다: 재시도 시 중복을 생성하지 않는 멱등성 프로듀서, 부분 처리를 롤백할 수 있는 트랜잭셔널 컨슈머. Kafka는 트랜잭션 API와 멱등성 프로듀서를 통해 exactly-once 시맨틱을 지원합니다. 금융 거래, 청구, 중복 처리에 실질적 결과가 있는 모든 경우에 필수적입니다.
데이터 파이프라인에서 멱등성이란 무엇이고 왜 중요한가요?
멱등성 파이프라인은 여러 번 실행해도 한 번 실행한 것과 동일한 결과를 냅니다. 장애와 재시도는 불가피하므로 내결함성 파이프라인에 필수적입니다. 멱등성을 달성하려면 일반적으로 INSERT 대신 UPSERT(MERGE) 문 사용, 중복을 감지하고 무시하기 위한 고유 키 사용, 이미 처리된 데이터에서 재실행해도 오류가 발생하지 않도록 변환 설계가 필요합니다. 멱등성 파이프라인은 실패 시 안전하게 재시도하고, 백필하고, 스키마 변경 후 재실행할 수 있습니다.