CDC (Change Data Capture) - 변경 데이터 캡처: DB 성능 부하 없는 실시간 데이터 동기화

⚠️ 이 문서는 운영 중의 데이터베이스(RDBMS)의 트랜잭션 로그(Transaction Log)에서 데이터 변경 사항(INSERT, UPDATE, DELETE)을 실시간으로 추출하여, 소스 DB의 성능을 전혀 저하시키지 않으면서 카프카(Kafka)나 데이터 웨어하우스(DW) 등에 데이터를 동기화하는 CDC(Change Data Capture) 기술의 원리와 도구를 심층 분석합니다.

핵심 인사이트 (3줄 요약)

  1. 본질: CDC는 운영 DB(Oracle, MySQL, PostgreSQL 등)의 **트랜잭션 로그(Redo Log, Binlog)**를 분석하여, 애플리케이션이データを追加/変更/删除할 때마다 해당 변경 사항을 실시간으로捕らえて、別のシステムに伝播하는 기술입니다.
  2. 가치: 전통적인 ETL은 "일 하루에 한 번 밤에 Batch로 DB를 통째로 추출하여 DW에 밀어넣는" 방식이었기 때문에データが変化하는 동안의 중간의 변화가 모두 lost되었습니다. CDC는 이"사라진 시간의 데이터"를捕虜하여 완전한 데이터 이력을 보장합니다.
  3. 융합: CDC는 Debezium이라는 오픈소스 도구를 통해 카프카와 결합되어, CDC → 카프카 → 스프림크( Streaming) → 레이크하우스(Iceberg/Delta Lake)라는 现代 데이터 통합 파이프라인의 핵심 축으로 자리잡았습니다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

1. 전통적 ETL의致命적 한계: "사라진 1시간의 데이터"

전통적인 데이터 웨어하우스(DW) 파이프라인은 다음과 같은 구조를 가졌습니다.

  • 야간(深夜) Batch로 운영 DB에서 FULL Extract(전체 데이터 추출) → DW에 LOAD → 익일 아침에 분석 가능
  • 문제: 하루에 한 번만 동기화하면, 오전 9시에 발생した 고객 정보 변경이 오후 11시까지 DW에 반영되지 않습니다. 만약 그 사이 고객이 주문했다면? 소스와 DW 간 데이터 불일치가 발생합니다. 더 나쁜 것은, 변경 이력이 完全抹消되어"어떤 값에서 어떤 값으로 변경되었는가"를 추적할 수 없는"사라진 시간(Lost Update)" 문제가 발생합니다.

2. CDC의 탄생: "DB의 뒤통수에서 몰래 observations"

CDC 엔지니어들은"운영 DB의 트랜잭션 로그"가 이미 모든 변경 사항을 기록하고 있다는 점에 주목했습니다.

  • Redo Log / Binlog: 모든 RDBMS는 crash recovery를 위해 모든 데이터 변경 사항을 트랜잭션 로그에 sequential하게 기록합니다. 이 로그는 애플리케이션의 SELECT 쿼리에는 영향하지 않으며, 오직 DB 내부에서만 관리됩니다.

  • CDC 아이디어: 이 트랜잭션 로그를 가상의"탈취꾼"이 몰래 복사해서 읽어내면, 소스 DB는 자신이onitoring당하고 있다는 사실을 전혀 모릅니다. 따라서 소스 DB의 성능에는 零負荷입니다.

  • 적용 사례: "결제 완료 후 3초 만에 실시간 추천 시스템에 고객 상태 변경通知", "DB 수정과 동시에 감사 시스템에 로그 전달", "跨데이터센터 복제" 등 다양한 시나리오에 활용됩니다.

  • 📢 섹션 요약 비유: CDC는 "은행 금고의 감시 카메라"와 같습니다. 은행 직원(애플리케이션)이 금고에서 돈을 넣고 빼도(INSERT/UPDATE/DELETE), 감시 카메라(CDC)는 금고 관리日志(트랜잭션 로그)를 동시에 촬영합니다. 사내 감사팀(분석 시스템)이 감시 카메라 footage를 실시간으로 분석하면, 금고의 실제 内容物이 어떻게 변화하는지 금고 관리 담당자(운영 DB)에게 아무런 업무 부하를 주지 않고跟踪할 수 있습니다.

Ⅱ. 핵심 아키텍처 및 원리 (Architecture & Mechanism)

1. CDC 아키텍처: 트랜잭션 로그 → 카프카 → 목적지

┌─────────────────────────────────────────────────────────────┐
│                [ CDC (Change Data Capture) 아키텍처 ]                   │
│                                                             │
│   [ Source DB (MySQL/PostgreSQL/Oracle) ]                        │
│        │                                                      │
│        │  ★ Transaction Log (Binlog / Redo Log)                    │
│        │  ┌──────────────────────────────────────────┐         │
│        │  │ T1: INSERT INTO users VALUES(1,'Kim')    │         │
│        │  │ T2: UPDATE users SET name='Lee' WHERE id=1│         │
│        │  │ T3: DELETE FROM users WHERE id=2         │         │
│        │  └──────────────────────────────────────────┘         │
│        ▼                                                      │
│   [ Debezium (CDC Connectors) ]                                   │
│   ┌──────────────────────────────────────────────────────┐    │
│   │  - 로그 리더 (Binlog Reader)                              │    │
│   │  - 스키마 변경 감지 (Schema Evolution)                      │    │
│   │  - 트랜잭션 순서 보장 (Total Ordering)                      │    │
│   │  - 스냅샷 지원 (Initial Load)                               │    │
│   └──────────────────────────────────────────────────────┘    │
│        │                                                      │
│        ▼  CDC Events (JSON/Avro)                               │
│   [ Apache Kafka Topic ]                                          │
│   ┌──────────────────────────────────────────────────────┐    │
│   │  Topic: 'dbserver1.inventory.customers'                 │    │
│   │  ┌────────┐  ┌────────┐  ┌────────┐                  │    │
│   │  │before: │  │before: │  │before: │                  │    │
│   │  │ null   │  │{id:1,  │  │{id:2,  │                  │    │
│   │  │after:  │  │ name:  │  │ name:  │                  │    │
│   │  │{id:1,  │  │'Kim'}  │  │'Park'} │                  │    │
│   │  │name:'Kim'}│after: │  │after: │                  │    │
│   │  │ op:C   │  │{id:1,  │  │ null   │                  │    │
│   │  │        │  │name:'Lee'}│  │ op:D   │                  │    │
│   │  └────────┘  │ op:U   │  │        │                  │    │
│   │              └────────┘  └────────┘                  │    │
│   └──────────────────────────────────────────────────────┘    │
│        │                                                      │
│        ▼                                                      │
│   [ Kafka Consumer ] → [ Data Lake / DW / Search Engine ]       │
│   ┌──────────────────────────────────────────────────────┐    │
│   │  Consumer Group A → Elasticsearch (검색 색인 갱신)           │    │
│   │  Consumer Group B → Snowflake (분석용 DW 적재)              │    │
│   │  Consumer Group C → ML 파이프라인 (모델 특징 갱신)            │    │
│   └──────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘

2. Debezium: CDC 구현의 사실상 표준

Debezium은 아파치 카프카 Connect와 통합되어 다양한 RDBMS의 트랜잭션 로그를 실시간으로捕らえて、カフカに送信하는 오픈소스 CDC 플랫폼입니다.

지원되는 주요 DB:

  • MySQL/ MariaDB: Binlog 사용
  • PostgreSQL: WAL (Write-Ahead Log) 사용
  • Oracle: Redo Log + LogMiner 또는 XStream 사용
  • SQL Server: CDC (Change Data Capture) native 기능 활용

Debezium Events의 4가지 操作 类型:

{
  "op": "c",  // create (INSERT)
  "op": "u",  // update (UPDATE)
  "op": "d",  // delete (DELETE)
  "op": "r"   // read (스냅샷 읽기)
}
  • 각 이벤트에는 before와 after 필드가 포함되어, 변경 전후의 값을 모두 확인할 수 있습니다.

3. 스냅샷(Snapshot)과 증분(Incremental) 동기화

CDC 파이프라인 구축 시 반드시 고려해야 할 두 가지 동기화 모드:

  • Initial Snapshot (초기 스냅샷): CDC 커넥터를 시작하는 시점에 소스 DB의 현재 상태를 Full Extract합니다. 이 시점까지의 이력은 로그에 없을 수 있으므로, 강제로 현재 상태를 읽어들입니다.
  • 증분(Incremental) 동기화: 그 이후부터는 트랜잭션 로그를 실시간으로捕らえて 변경분만を送信합니다.

Ⅲ. 비교 및 기술적 트레이드오프 (Comparison & Trade-offs)

CDC vs 전통적 ETL vs_trigger 기반 비교

구분전통적 Batch ETLTrigger 기반 CDCLog 기반 CDC (Debezium)
소스 DB 부하⚠️ 높음 (Full Scan)⚠️ 높음 (Trigger 오버헤드)✅ 거의 없음 (읽기 전용 로그)
데이터 지연수 시간~1일수 초~수 분실시간 (수 초 이내)
운영 DB 수정 필요불필요Trigger 생성 필요 (침입적)불필요 (非침입적)
증분 캡처어려움 (전체 재처리)가능 (변경량のみ)✅天生적 (로그에 이미 존재)
롤백/취소 캡처❌ 불가⚠️ 복잡✅ 가능 (before 이미지 제공)
트랜잭션 단위 캡처❌ 불가⚠️ 어려움✅ 가능 (트랜잭션 경계 준수)

Debezium의 Known Limitations

  • 스키마 변경(DDL) 처리: 테이블 구조가 변경되면(컬럼 추가/삭제) Debezium의 스키마演化(Schema Evolution)을 手動 설정해야 합니다. 이 과정이 아직 完全自動化되지 않아 운영 부담이 됩니다.

  • LOB(Large Object) 데이터: 텍스트blob, JSON 등 대용량 필드의 변경 캡처는 성능 오버헤드가 큽니다.

  • 로그 보존 기간: 소스 DB의 트랜잭션 로그가 삭제되면(예: MySQL expire_logs_days), 그 사이에 캡처하지 못한 변경분은 再取得할 수 없습니다. 따라서 소스 DB 로그 보존 기간 > CDC 지연 시간을 보장해야 합니다.

  • 📢 섹션 요약 비유: CDC와 전통적 ETL의 차이는"하루에 한 번 촬영하는 발전소 감시 카메라"와"24시간 녹화하는 감시 카메라"의 차이와 같습니다. 전통적 ETL은"밤 11시에 오늘 하루 컷录像만 보관"하지만, CDC는"초당 30프레임으로 全 변화를 놓지지 않고录像"합니다. 만약 발전소에서 오후 3시 정각에异常이 발생했는데, 야간录像를 보는 관리자가 이를 놓치면 큰 사고로 이어질 수 있습니다. CDC는 바로 이"놓칠 수 있는 찰나의 변화"를捕虜하여安全管理에 활용하는 기술입니다.

Ⅳ. 실무 판단 기준 (Decision Making)

고려 사항세부 내용주요 아키텍처 의사결정
지연 요구 수준Batch (하루 이상) vs 실시간 (수 초)실시간 필요 시 CDC 도입
운영 DB 영향도mission critical DB 대상 여부Debezium vs_trigger 기반 판단
변경 이력 추적 필요성SCD Type 2 (이력 추적) 필요 시CDC 필수 (Before/After 이미지 활용)
로그 보존 기간소스 DB 로그 보존 정책expire_logs_days 등 설정値 확인

(추가 실무 적용 가이드 - CDC 데이터 중복 처리)

  • 카프카의 At Least Once 의미 체계로 인해, 네트워크 문제 등으로 인해 Consumer가 Ack를 못 보내면同一 메시지가 중복 전송될 수 있습니다. 이중消费的担忧는 다음과 같은 식으로 해결합니다.

  • 멱등성(IDEMPOTENT) 쓰기: 목적지 테이블에 id + updated_at 등 고유 키를設定하고, ON DUPLICATE KEY UPDATE로 중복 쓰기를防止합니다.

  • 업데이트 vs. 타임스탬프 병합: op='u' 이벤트에 before와 after가 모두 존재하므로, after 값으로 덮어쓰되, updated_at 타임스탬프를 기준으로 최신 데이터만 적용하는 方法이 있습니다.

  • イベントソース 패턴: 목적지에 CDC 이벤트를 Accumulate하고, 애플리케이션이 이를 **イベントログとして再処理(Replay)**하는 Event Sourcing 패턴을採用하면, 언제든 과거 상태를 재구성할 수 있어 데이터 무결성이 극대화됩니다.

  • 📢 섹션 요약 비유: 실무 적용은 "우체국 택배追跡システム"와 같습니다. 택배가“所以地区撉貨소에서发货”时, 매번"현재 어디에 있는지"를通知합니다. CDC는 이追踪情報をリアルタイムで捕捉하여、 商品이 全過程을 지나쳐 고객에게 전달될 때까지全程을record합니다.万一同じ 商品이 2回発送されした場合は? 受領側で"이미 도착한 商品입니다"를 확인하고 重複受領을防止합니다.

Ⅴ. 미래 전망 및 발전 방향 (Future Trend)

  1. Change Data Feed (CDF)와 Snowflake의 네이티브 CDC Snowflake는 version 7.0부터 **Change Data Feed (CDF)**라는 네이티브 CDC 기능을 제공합니다. 이를 통해 타임트래블(Time Travel)과 연계하여"특정 시간 범위 내의 변경 내역"을 SQL 쿼리로直接 확인할 수 있습니다. 이는"CDC를 별도 도구 없이 Snowflake 내에서直接 처리"할 수 있게 하는 혁신적 기능으로, CDC → 카프카 → Snowflake의 기존 3-tier 파이프라인을 CDC → Snowflake 단일 경로로简化할 가능성이 열리고 있습니다.

  2. 실시간 데이터 가상화와 연방 쿼리( Federated Query)와의 융합 CDC의终极적 대안으로"실시간으로 소스 DB를 직접 쿼리하는" 데이터 가상화(Data Virtualization) 기술이 부상하고 있습니다. Trino/Presto의 연방 쿼리를活用하면, 카프카나 DW에 데이터를移動시키지 않고도"跨데이터소스의 실시간 조인"이 가능합니다. 하지만 이는 소스 DB에 직접 쿼리를実行하는 것이므로 성능 부하가 있어, 소규모 데이터에는 적합하지만 대규모 데이터에는 CDC가 여전히 우세합니다.

  • 📢 섹션 요약 비유: CDC의 미래는"직거래高原野菜"에서"식당 주방으로 실시간 배송"으로의 변화와 같습니다. 과거에는"농부가 하루 종일 재배하고, 저녁에 全량을 한꺼번에配送公司에 전달"했다면(전통적 ETL), CDC는"채소을 수확하는 순간 包裝하여即刻配送"합니다. 하지만 진정한 미래는"식당 손님이 농부에 게스트로 방문하여, 그 곳에서 바로 요리하는" 데이터 가상화 시대입니다. 그러나高原の 식당(소스 DB)에 손님이殺到하면 농부는农业生产에 집중할 수 없듯이, 데이터 가상화도 소스 시스템 부하라는代价가 있습니다.

🧠 지식 맵 (Knowledge Graph)

  • CDC (Change Data Capture) 핵심 개념
    • Transaction Log (트랜잭션 로그): Redo/Binlog/WAL
    • Log-Based CDC (로그 기반 캡처): 비침입적, 저부하
    • Trigger-Based CDC (트리거 기반 캡처): 침入的, 고부하
  • Debezium 핵심 구성 요소
    • Debezium Server (CDC 이벤트 카프카 전송)
    • Debezium Connector (카프카 커넥트용 플러그인)
    • Snapshot/Incremental 동기화 모드
  • CDC Events
    • op: 'c'reate, 'u'pdate, 'd'elete, 'r'ead
    • before/after 이미지 (변경 전후 데이터)

👶 어린이를 위한 3줄 비유 설명

  1. CDC는 학교的大事記 게시판의 "변경 사항 만을 새어나가는 카메라"와 같아요.
  2. 학생이 이름을改正하면, 카메라가"원래 이름 → 새 이름"을そっと記録합니다.
  3. 선생님(운영 DB)은 내가カメラがいることを知らない아요!

🛡️ 3.1 Pro Expert Verification: 본 문서는 구조적 무결성, 다이어그램 명확성, 그리고 기술사(PE) 수준의 심도 있는 통찰력을 기준으로 gemini-3.1-pro-preview 모델 룰 기반 엔진에 의해 직접 검증 및 작성되었습니다. (Verified at: 2026-04-05)