ETL·CDC·데이터 파이프라인으로 설계하는 데이터 통합

데이터가 이동하는 방식부터 분리해 본다

데이터 통합은 여러 시스템의 데이터를 연결해 분석·서빙 환경으로 전달하는 작업이다. 소스에서 데이터를 꺼내 변환하고 저장하는 배치 처리, 변경분을 계속 발행하는 CDC, 이 흐름을 실행·감시하는 데이터 파이프라인이 함께 쓰인다.

ETL은 다양한 소스에서 데이터를 추출(Extract)한 뒤 정제·변환(Transform)하고 목적지에 적재(Load)하는 배치 중심 프로세스다. 데이터 웨어하우스나 데이터 마트 공급에 맞으며, 보통 소스 커넥터 설정, 스키마 매핑과 품질 규칙 적용, DWH·레이크 적재 순서로 이어진다. 스케줄 기반 실행과 재시도·체크포인트 적용도 여기에 포함된다.

데이터 파이프라인은 이 데이터 흐름을 연결하고 자동화하는 오케스트레이션 체계다. 작업 의존성, 스케줄, 리소스, 모니터링을 일관되게 다룬다. 소스 커넥터와 변환 작업(dbt/Spark/SQL), 싱크 커넥터, 로그·메트릭·트레이싱, 경보와 재시도가 하나의 운영 단위가 된다.

CDC(Change Data Capture)는 트랜잭션 로그(binlog/redo/WAL)에서 변경을 포착하는 방식이다. Insert, Update, Delete를 이벤트 스트림으로 전달하며, 초기 스냅샷 적재와 증분 스트리밍을 결합한다. 이때 이벤트 순서, 중복 처리, 재처리(idempotency)를 어떻게 설계할지가 핵심이다.

연결 지점과 운영 제약을 함께 설계한다

통합 대상은 RDBMS, 파일·오브젝트 스토리지, 메시지 브로커, SaaS API까지 넓어진다. 표준 드라이버와 커넥터 카탈로그를 활용하되, 프라이빗 링크·VPC 피어링·IP allowlist 같은 네트워크와 보안 조건, 쿼터·슬로틀링 같은 스루풋 제한도 설계에 반영해야 한다.

변환 계층에서는 스키마 추가·삭제·타입 변경에 대응해야 한다. 메타데이터와 데이터 계보(Data Lineage)를 추적하고, 단위와 코드셋을 표준화하며, 품질 검증(expectations)과 PII 마스킹·토큰화를 적용한다.

오케스트레이션은 DAG로 의존성을 관리하고, 동시성과 리소스 풀을 제어하며, SLA와 ALERT를 설정한다. 크론 기반 배치와 상시 스트리밍을 혼합 운영할 수 있고, 배포 파이프라인(CI/CD)과도 연결된다.

신뢰성은 트랜잭션 경계, 체크포인트와 오프셋 커밋에서 결정된다. 정확히 한 번 처리와 최소 한 번 처리는 서로 다른 운영 비용을 가진다. 재시도와 역추적(DLQ), 역압(backpressure) 제어, 키 기반 멱등 업서트가 이를 보완한다.

운영 중에는 처리량·지연·실패율을 지표로 보고, 로그 상관관계와 트레이스를 통해 원인을 추적한다. 데이터 품질 모니터링과 경보 라우팅을 연결하며, 파티셔닝, 파일 사이즈 튜닝, 컬럼너 저장, 캐시·브로드캐스트 조인으로 비용과 성능을 조정한다.

배치와 변경 이벤트가 합류하는 흐름

⤢✕

소스 데이터는 CDC 또는 배치 추출을 거쳐 변환되고, 레이크나 웨어하우스에 저장된 뒤 BI·ML·애플리케이션으로 제공된다. 이벤트 스키마가 맞지 않으면 DLQ로 격리하고, 배치 적재가 실패하면 재시도와 체크포인트로 복구한다.

CDC에서는 오프셋 커밋을, 배치에서는 스냅샷 커밋을 관리한다. 타임트래블과 버저닝은 재현성을 확보하는 수단이 된다.

통합 방식이 달라지는 장면

전사 데이터 웨어하우스를 만들 때는 야간 배치 ETL로 ERP·CRM·로그를 집계하고, 표준화한 차원 모델에 적재할 수 있다. 월 단위 코스트 최적화와 품질 규칙, 승인 워크플로우를 통해 인증 데이터셋을 관리한다.

실시간 마케팅이나 사용자 행동 분석에서는 CDC→Kafka→스트림 처리(Flink/Spark)→레이크·리얼타임 마트 적재 흐름을 사용할 수 있다. 캠페인 반응과 추천 피드백 루프에 5~10분 이내 지연 목표를 둔다.

마이크로서비스 간 동기화에서는 마스터 데이터 변경을 CDC로 발행하고, 구독 서비스가 지역 캐시와 읽기 모델을 갱신한다. 업서트 병합과 스키마 레지스트리는 변경에 따른 진화를 다루는 기반이 된다.

신선도와 비용의 균형

배치 T+1 갱신을 분·초 단위 갱신으로 바꾸면 데이터 신선도가 높아지고 MTTI(정보 획득 시간)를 줄일 수 있다. 자동 재시도와 격리를 적용하면 실패율을 낮추고 MTTR을 단축하며 SLA 준수율을 높일 수 있다.

스토리지와 컴퓨트를 분리하고 증분 처리 중심으로 구성하면 스캔 비용도 줄어든다. Full Scan 대비 50%+ 절감 사례가 다수 있다.

요구사항을 운영 규칙으로 바꾸는 과정

설계는 소스별 SLO(신선도, 지연, 정확도), 데이터 볼륨과 변동률, 개인정보 범주를 정의하는 데서 시작한다. 이어 배치 ETL, CDC, 하이브리드 중 어떤 구성을 택할지 정하고 스키마 레지스트리와 카탈로그 채택 여부를 결정한다.

스냅샷과 증분 데이터를 병합하려면 키·버전·메타타임스탬프를 설계하고, 멱등 업서트를 구현해야 한다. 지표·로그·트레이스 표준화, DLQ 설계, 카나리 릴리스와 백필 계획도 같은 시점에 마련한다.

유효성 검증에 실패한 레코드는 DLQ에 격리한 뒤 경보와 재처리 파이프라인으로 보낸다. 스키마 불일치는 백워드·포워드 호환 정책과 스키마 레지스트리 게이팅으로 제어한다. 다운스트림 장애에는 지연 커밋·오프셋 보류, 재시도 지수 백오프, 회로 차단기를 적용한다.

CDC는 로그 기반 비침투형 캡처와 트랜잭션 경계별 이벤트 배달, 오프셋 커밋 원자화를 다룬다. 배치에서는 Repeatable Read/Time Travel 스냅샷 읽기와 랜딩→프로덕션 원자적 스왑을 활용한다. 비즈니스 키와 버전을 바탕으로 머지하면 중복 이벤트를 무해화할 수 있다.

ETL·CDC·스트리밍이 갖는 운영상의 차이

항목	ETL(배치)	CDC(로그 기반)	스트리밍 처리
성능(지연)	분~시간 단위	초~분 단위	밀리초~분 단위
확장성	대용량 일괄 처리 강점	파티션/샤딩 필요	수평 확장 용이
일관성	스냅샷 기준 강함	트랜잭션 경계 보장	정확히 한 번 구현 난이도
안정성	재처리 용이	로그 손실 방지 중요	역압/재처리 설계 중요
운영 편의	스케줄 간단	커넥터/오프셋 운영 필요	상태/체크포인트 관리 필요

일반적 특성 기준이며, 플랫폼과 도구에 따라 달라질 수 있다.

Debezium MySQL에서 Kafka로 변경분 전달하기

전제조건: Kafka 3.x, Debezium 2.x, MySQL 8.0, 스키마 레지스트리 사용

{
  "name": "mysql-inventory-connector",
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
    "database.hostname": "mysql",
    "database.port": "3306",
    "database.user": "debezium",
    "database.password": "****",
    "database.server.id": "184054",
    "database.server.name": "dbserver1",
    "database.include.list": "inventory",
    "table.include.list": "inventory.customers,inventory.orders",
    "snapshot.mode": "initial",
    "include.schema.changes": "true",
    "tombstones.on.delete": "false",
    "transforms": "unwrap,route",
    "transforms.unwrap.type": "io.debezium.transforms.ExtractNewRecordState",
    "transforms.unwrap.drop.tombstones": "true",
    "transforms.route.type": "org.apache.kafka.connect.transforms.RegexRouter",
    "transforms.route.regex": "dbserver1.inventory.(.*)",
    "transforms.route.replacement": "inventory.$1",
    "key.converter": "org.apache.kafka.connect.storage.StringConverter",
    "value.converter": "io.confluent.connect.avro.AvroConverter",
    "value.converter.schema.registry.url": "http://schema-registry:8081"
  }
}

초기 스냅샷 이후 증분 이벤트를 발행하고, 토픽 라우팅으로 도메인을 분리한다. 업서트 싱크(예: Kafka Connect JDBC Sink)에서는 키 기준 MERGE로 멱등성을 확보한다.

일관성, 보안, 비용을 한꺼번에 다룬다

스키마 레지스트리는 진화 호환성을 보장하지만, 사전·사후 검증 파이프라인이 필요하다. 정확히 한 번 처리는 처리량 저하 가능성이 있으므로, 최소 한 번 처리와 멱등 업서트로 절충할 수 있다.

전송·저장 암호화, PII 최소화·토큰화, ABAC/RBAC 접근 제어, 감사 로그는 보안과 규정 준수 요구를 다루는 기본 요소다. 데이터 주권과 보관 주기도 함께 고려한다.

비용 측면에서는 증분 처리, 파티션 전략, Parquet/ORC 저장 포맷 최적화, 스팟·예약 인스턴스 혼용이 주요 선택지가 된다. 파일럿(1~2 도메인)에서 시작해 템플릿·DAG·모듈을 표준화하고, 이후 조직 차원의 거버넌스로 확장하는 흐름이 적합하다.