Skip to content
Published on

CDC & 데이터 통합 2026 완벽 가이드 — Debezium 3 · Estuary · Flink CDC · Airbyte · Fivetran · Sling · Hightouch · Census · Sequin 심층 분석

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — "그래서 우리 데이터는 어디서 만나죠?"

2026년 어느 데이터 플랫폼 팀 회의.

PM: "신규 모델 학습용으로 결제 데이터 실시간 필요해요." DBA: "또요? 지난주에 추천팀도 똑같이 요청했는데요." 플랫폼: "Debezium에 토픽 하나 더 붙이면 되잖아요." DBA: "그 replication slot 다섯 개 이미 떠 있고 lag이 30분이에요."

이 짧은 대화에 2026년 데이터 통합의 모든 게 들어있다. OLTP는 진실의 원천이지만, 분석·AI·SaaS는 그 진실을 다른 형태로 원한다. 그 사이를 채우는 게 CDC(Change Data Capture)와 데이터 통합이다.

이 분야는 지난 5년간 폭발적으로 성숙했다. 한쪽에는 Debezium·Flink CDC 같은 오픈소스 진영이 있고, 다른 쪽에는 Fivetran·Airbyte·Estuary 같은 매니지드 SaaS가 있다. 그리고 그 위에 Hightouch·Census 같은 reverse ETL이 얹어졌고, Sling·Sequin 같은 가벼운 도구가 빈틈을 채운다.

이 글은 그 전체 지형을 정리한다. Debezium 3.0의 변화부터 Estuary Flow의 매니지드 야망, Flink CDC가 어떻게 ELT 도구로 진화했는지, Airbyte와 Fivetran의 본질 차이, Postgres logical replication과 MongoDB Change Streams 같은 DB 네이티브 메커니즘, outbox 패턴, 그리고 reverse ETL이 왜 별도 카테고리가 됐는지까지.

1장 · CDC 기본 — 로그 vs 트리거 vs 폴링

CDC는 "DB 변경을 감지해서 어딘가로 흘려보내는" 모든 행위다. 구현 방식은 세 가지뿐이다.

방식원리장점단점
PollingSELECT ... WHERE updated_at > ?가장 단순latency 큼, delete 불가, 부하
TriggerDB 트리거 → 별도 테이블에 기록모든 DB 지원트랜잭션 성능 저하
Log-basedWAL/binlog/redo 직접 읽기거의 zero overheadDB 권한·복잡도

2026년 진지한 CDC는 거의 다 log-based다. MySQL은 binlog, Postgres는 WAL(Write-Ahead Log) + logical replication, MongoDB는 oplog/Change Streams, SQL Server는 CDC table, Oracle은 redo log를 LogMiner나 XStream으로 읽는다.

폴링은 작은 시스템에 여전히 유효하다. 트리거는 변경 빈도가 매우 낮고 다른 옵션이 없을 때만 쓴다.

또 한 가지 축은 snapshot + incremental이다. CDC를 시작하는 시점에 테이블에 이미 1억 행이 있다면, 그걸 모두 읽은 다음(snapshot) 그 시점 이후의 변경을 따라가야(incremental) 한다. Debezium은 이걸 incremental snapshot으로, Flink CDC는 parallel snapshot으로 풀었다.

2장 · 왜 지금 CDC인가 — 4가지 사용처

CDC가 왜 갑자기 필수 인프라가 됐는가. 네 가지 use case가 동시에 폭발했기 때문이다.

  1. 실시간 분석 / Operational analytics — 매출 대시보드 5분 latency vs 24시간 batch.
  2. 마이크로서비스 통합 — service A의 DB 변경을 service B가 알아야 하는데 직접 API 호출은 결합도가 너무 높다. 이벤트 발행으로 분리.
  3. 감사 / Audit / 컴플라이언스 — 누가 언제 무엇을 바꿨는지 immutable log로 보관.
  4. AI 학습 데이터 / Feature store sync — 모델 학습 데이터셋, 벡터스토어, 추천 feature를 OLTP와 동기화.

특히 4번이 2024~2026년에 폭증했다. 모델은 더 자주 학습되고, RAG 시스템은 신선도 SLA를 요구한다. "어제 추가된 문서가 오늘 검색에 안 잡힙니다" 는 더 이상 용납되지 않는다.

이 모든 use case의 공통점은 OLTP를 건드리지 않으면서 변경을 전파해야 한다는 것. 그래서 log-based CDC다.

3장 · Debezium 3.0 (Red Hat, Apache 2.0) — Kafka Connect의 왕

Debezium은 사실상 오픈소스 CDC의 표준이다. Red Hat이 후원하고 Apache 2.0이다. 2025년 Debezium 3.0이 릴리스됐고, 2026년 현재 3.x 라인이 활발히 업데이트 중이다.

지원 DB:

  • MySQL, MariaDB
  • PostgreSQL (logical replication, pgoutput / decoderbufs / wal2json)
  • MongoDB (Change Streams, replica set 필수)
  • SQL Server (native CDC)
  • Oracle (LogMiner)
  • IBM Db2
  • Apache Cassandra
  • Vitess
  • Spanner (preview)

전통적으로 Debezium은 Kafka Connect 위에서 동작한다. JSON/Avro/Protobuf로 직렬화해서 Kafka 토픽에 던진다. 메시지 키는 PK, 값은 before/after/source/op 구조다.

{
  "before": { "id": 42, "email": "a@x.com" },
  "after":  { "id": 42, "email": "b@x.com" },
  "op": "u",
  "source": { "db": "shop", "table": "users", "lsn": 12345 },
  "ts_ms": 1731700000000
}

3.0 주요 변화:

  • Kafka 3.x / 4.0 호환 — share groups까지 활용 가능
  • Java 17+ 필수
  • Schema history 개선 — 토픽이 아닌 외부 스토리지 지원
  • Incremental snapshot 안정화 — 운영 중 새 테이블 추가가 무중단
  • Debezium UI — 별도 관리 콘솔

장점: 검증된 안정성, 큰 커뮤니티, 모든 주요 DB 지원. 단점: Kafka Connect 운영 복잡도, JVM 의존, 메모리 무겁다.

4장 · Debezium Server / Engine — 임베디드 모드

모든 팀이 Kafka Connect를 띄울 여유가 있는 건 아니다. Debezium은 두 가지 경량 모드를 제공한다.

Debezium Server — 독립 실행 가능한 컨테이너. Kafka 대신 다른 sink로 직접 보낼 수 있다.

  • Kinesis, Pub/Sub, Pulsar
  • EventHubs, Event Grid
  • HTTP, NATS, Redis Streams
  • 파일, S3
debezium:
  sink:
    type: pubsub
    pubsub:
      project.id: my-project
  source:
    connector.class: io.debezium.connector.postgresql.PostgresConnector
    database.hostname: pg.internal
    database.dbname: shop
    plugin.name: pgoutput
    slot.name: debezium
    publication.name: debezium_pub
    topic.prefix: shop

Debezium Engine — 자바 라이브러리로 임베드. 자기 앱 안에서 직접 CDC 이벤트를 받는다. 적은 트래픽, 단일 노드 use case에 적합. 단점은 HA가 없다는 것.

2026년에 Debezium Server는 "Kafka 없는 Debezium" 슬로건으로 인기를 끌고 있다. NATS JetStream이나 Redis Streams와의 조합이 특히 빠르다.

5장 · Estuary Flow — 매니지드 CDC SaaS

Estuary Flow는 2020년 창업한 매니지드 CDC + 통합 플랫폼이다. 2024~2025년에 빠르게 성장해서 Fivetran의 강력한 대안으로 자리잡았다.

특징:

  • 실시간 CDC — 평균 latency 100ms 이내 광고
  • 초당 백만 행 처리 사례 — 매우 큰 워크로드
  • Source 200+ / Destination 100+ — 빠르게 늘고 있음
  • 오픈소스 코어 (Flow는 Apache 2.0) + 매니지드 호스팅
  • Materializations — 데이터를 단순 복사하는 것이 아니라 sink 쪽에서 계속 업데이트되는 materialized view 개념

가격: 비용 단위가 GB 처리량 기반. Fivetran의 MAR(Monthly Active Rows)보다 예측 가능하다.

# flow.yaml
captures:
  shop/postgres:
    endpoint:
      connector:
        image: ghcr.io/estuary/source-postgres:dev
        config:
          address: pg.internal:5432
          database: shop
          user: estuary
    bindings:
      - resource:
          stream: public.users
          mode: Normal
        target: shop/users

materializations:
  shop/snowflake:
    endpoint:
      connector:
        image: ghcr.io/estuary/materialize-snowflake:dev
        config:
          account: xy12345.us-east-1
          database: ANALYTICS
          warehouse: COMPUTE_WH
    bindings:
      - source: shop/users
        resource: { table: USERS }

장점: 진짜 실시간, 예측 가능한 가격, 오픈소스 코어. 단점: 신생, ecosystem이 아직 Airbyte보다 작다.

6장 · Apache Flink CDC 3.x — Flink 위의 ELT

Flink CDC (구 Ververica CDC connectors)는 2024년 Apache 인큐베이션을 거쳐 Flink CDC 3.0 시점부터 완전한 ELT 파이프라인 도구로 진화했다. 단순 connector가 아니다.

핵심 개념:

  • Source — MySQL, Postgres, MongoDB, Oracle, SQL Server, TiDB, OceanBase
  • Sink — Doris, StarRocks, Iceberg, Paimon, Kafka, Elasticsearch
  • Pipeline — Source → Transformation → Sink를 단일 YAML로 정의
  • Schema evolution — 자동 ALTER TABLE 전파 (sink가 지원하는 경우)
  • Parallel snapshot — 큰 테이블을 chunk로 나눠 병렬 읽기. 1억 행 테이블도 한 시간 안에.
# pipeline.yaml
source:
  type: mysql
  hostname: mysql.internal
  username: flinkcdc
  password: ${MYSQL_PASS}
  tables: shop.\.*
  server-id: 5400-5404

sink:
  type: paimon
  catalog.properties.metastore: filesystem
  catalog.properties.warehouse: s3://lake/paimon

route:
  - source-table: shop.\.*
    sink-table: ods_shop.<>

pipeline:
  name: shop-to-paimon
  parallelism: 8

Flink CDC가 매력적인 이유는 lakehouse 통합이다. Iceberg와 Paimon으로 흘려보내면 Trino/Spark/Doris가 그대로 쿼리한다. Trino + Iceberg + Flink CDC는 2026년 modern data stack의 인기 조합.

7장 · Airbyte 1.x (Y Combinator W20) — 오픈소스 ELT 표준

Airbyte는 YC W20 출신으로, 2024년 1.0을 찍고 2026년 1.x 후반대다. 오픈소스 ELT 표준이 됐다.

특징:

  • 350+ 커넥터 — 거의 모든 SaaS와 DB
  • 오픈소스 (MIT/ELv2 혼합) + Cloud 매니지드
  • Airbyte Protocol — 누구나 새 커넥터를 표준 인터페이스로 만들 수 있음
  • CDK — Python/Java로 커스텀 커넥터 작성. low-code CDK도 있음
  • Embedded — 자기 제품 안에 Airbyte를 묶어서 쓰는 옵션

CDC 지원: MySQL, Postgres, MongoDB, SQL Server 등. 내부적으로 Debezium을 쓴다 (예전엔 Debezium Embedded, 현재는 Airbyte 자체 구현 / Debezium 혼용).

장점: 압도적 connector 수, 오픈소스, 자가 호스팅 가능. 단점: 실시간 CDC는 약하다 (배치/마이크로배치 중심), 운영이 가볍지는 않다.

2024년에는 매니지드 가격을 두고 한 차례 가격 인상 논란이 있었고, 2025년 들어 가격 모델이 다시 정리됐다. 자가 호스팅이 여전히 매력적인 이유.

8장 · Fivetran — 매니지드 ELT 왕좌

Fivetran은 매니지드 ELT의 대명사다. 클로즈드 소스, 가격이 비싸기로 악명 높지만, "그냥 돌아간다" 라는 운영적 안정감으로 시장을 지배했다.

특징:

  • 600+ 커넥터 — Salesforce, Hubspot, Stripe, Zendesk, NetSuite, Workday 등 SaaS는 거의 다
  • MAR 기반 가격 — Monthly Active Rows. 행이 한 번이라도 변경되면 카운트. 예측이 어렵다는 비판이 많음
  • HVR 인수 — 엔터프라이즈 CDC (Oracle, SAP HANA) 강화
  • dbt 통합 — Transformations 기능
  • Hubspot 인수 2023 — 마케팅 데이터 분야 확장 (사실 이건 Hubspot이 다른 곳을 인수한 거고, Fivetran은 별개)

2025~2026년 트렌드: 대기업은 여전히 Fivetran을 쓴다. 스타트업과 데이터 엔지니어링 팀은 Airbyte/Estuary/Sling으로 옮기는 중이다.

9장 · Stitch (Talend → Qlik) / Hevo / Meltano — 그 외 ELT

Stitch (Singer 기반, Talend가 인수 → Qlik이 Talend를 인수)는 2025년 EOL이 발표됐고, 사용자들은 Airbyte/Fivetran/Estuary로 이동했다. Singer 프로토콜은 오픈소스로 살아남았다.

Hevo Data — 인도 기반 ELT. 150+ 커넥터, 가격 경쟁력. 동남아·인도 시장에서 강세.

Meltano — GitLab에서 스핀아웃한 오픈소스 ELT. Singer 기반. CLI 중심에 dbt와 결합도가 높다. "ELT를 코드로" 철학이 강한 팀에 인기.

Rivery — 이스라엘 기반 ELT + 워크플로우 결합. 작지만 한정된 시장에서 사용.

이런 도구들의 공통점: SaaS 커넥터 풀이 핵심이고, CDC는 곁가지다.

10장 · Sling CLI — 빠른 로컬·CLI 통합

Sling은 단일 바이너리 CLI로 데이터를 옮기는 도구다. Go로 짜여 있어 매우 빠르고, 데이터 엔지니어가 즉석에서 쓸 수 있다.

# Postgres → Snowflake
sling run \
  --src-conn POSTGRES \
  --src-stream "public.users" \
  --tgt-conn SNOWFLAKE \
  --tgt-object "ANALYTICS.PUBLIC.USERS" \
  --mode full-refresh

특징:

  • 100+ DB / 클라우드 스토리지 지원
  • YAML로 파이프라인 정의 (replication.yaml)
  • Sling Cloud (매니지드) + OSS CLI
  • CDC는 incremental 모드로 지원 (binlog 기반 본격 CDC는 아님)

장점: 압도적으로 빠르다, 단순하다, 자가 호스팅이 자연스럽다. 단점: 본격 CDC는 없다, dbt 같은 transformation은 별도.

CI/CD 파이프라인에서 "이 DB에서 저 DB로 매일 한 번" 같은 use case에 압도적이다.

11장 · Sequin — Postgres → 어디든

Sequin은 Postgres CDC에 특화된 오픈소스 도구다. 핵심 메시지: "Postgres를 Kafka처럼 써라."

  • Postgres logical replication을 읽음
  • Sink: Kafka, Webhook (HTTP POST), Redis Streams, SQS, GCP Pub/Sub, NATS
  • Elixir로 짜여 있음 (BEAM VM의 동시성)
  • 매니지드 + 자가 호스팅 양쪽
# sequin.yaml
streams:
  - name: orders_stream
    source:
      type: postgres
      database: orders
      tables: ["public.orders", "public.order_items"]
    consumers:
      - name: webhook_to_shipping
        type: http_push
        endpoint: https://shipping.internal/webhook
        max_ack_pending: 100
      - name: kafka_to_warehouse
        type: kafka
        topic: orders-cdc
        bootstrap_servers: kafka.internal:9092

Sequin은 "Debezium은 너무 무겁고, Postgres 한 개만 쓰는데 Kafka까지 띄우긴 싫다" 는 팀에 강하다. 2024~2025년 사이 빠르게 성장했다.

12장 · Striim / Qlik Replicate / Oracle GoldenGate — 엔터프라이즈

엔터프라이즈에는 별도 시장이 있다.

Striim — 엔터프라이즈 streaming integration. SAP, Oracle, SQL Server, Mainframe까지 커버. 가격 비싸지만 대기업 표준.

Qlik Replicate (구 Attunity) — Qlik이 2019년 Attunity를 인수했다. Oracle, SQL Server, SAP HANA, DB2를 거의 다 지원. 금융권에서 자주 본다.

Oracle GoldenGate — Oracle CDC의 표준. Oracle에서 Oracle로의 replication이 본업이지만 heterogeneous도 지원. 가격은 무시무시하다.

IBM InfoSphere Data Replication (CDC) — 메인프레임 + Db2 환경.

SAP Data Services / SAP SLT — SAP 시스템 통합 전용.

스타트업에서는 거의 안 보이지만, 금융·통신·정부에서는 여전히 표준이다.

13장 · AWS DMS · GCP Datastream · Azure Data Factory — 클라우드 네이티브

3대 클라우드 모두 매니지드 CDC를 제공한다.

AWS DMS (Database Migration Service) — Oracle/SQL Server/MySQL/Postgres → RDS/Aurora/Redshift/S3로 마이그레이션 + 지속 CDC. "마이그레이션" 이름이지만 실제로는 CDC로 쓰는 케이스가 많다. 2024년 Serverless DMS가 GA.

AWS DMS + Kinesis Data Streams + Lambda — DMS가 Kinesis로 변경 이벤트를 던지고, Lambda가 처리하는 패턴.

GCP Datastream — Oracle/MySQL/Postgres/SQL Server → BigQuery/Cloud Storage. BigQuery로의 실시간 CDC가 본업. UI 한 번에 켜진다.

GCP Datastream + Dataflow — 데이터 흐름을 Dataflow(Flink/Beam)에서 가공해서 다시 BigQuery로.

Azure Data Factory + Synapse Link — Synapse Link for SQL/Dataverse/Cosmos DB는 OLTP → analytics를 한 클릭으로 연결한다. Synapse Link for Cosmos DB는 NoSQL과 분석을 mirror한다.

Azure Database Migration Service — DMS의 Azure 버전.

장점: 자기 클라우드에 잘 묶인다, 콘솔에서 클릭으로 끝난다. 단점: 멀티 클라우드 / 온프레미스가 섞이면 한계가 빨리 온다.

14장 · Postgres logical replication · MySQL binlog · MongoDB Change Streams

CDC의 근간은 DB가 제공하는 기능이다. 이 셋은 알아두는 게 좋다.

Postgres logical replication:

  • wal_level = logical 필요
  • max_replication_slots, max_wal_senders 설정
  • Publication / Subscription 모델
  • pgoutput (built-in), wal2json, decoderbufs (Debezium의 plugin)
  • Logical slot은 쌓이면 disk를 다 먹는다. 정상 운영에서는 컨슈머가 LSN을 진행시켜야 함
ALTER SYSTEM SET wal_level = logical;
SELECT pg_create_logical_replication_slot('debezium', 'pgoutput');
CREATE PUBLICATION dbz_pub FOR ALL TABLES;

함정: pg_repack, VACUUM FULL, 그리고 일부 ALTER TABLE은 logical replication과 충돌한다. 운영 중에 row가 안 흐르면 대부분 slot이 정체된 것이다.

MySQL binlog:

  • log_bin = ON, binlog_format = ROW
  • gtid_mode = ON 이 강력 권장 (장애 복구가 쉬워짐)
  • expire_logs_days 너무 짧으면 컨슈머가 못 따라잡았을 때 데이터 유실

MongoDB Change Streams:

  • Replica set이 필수. standalone에서는 못 씀
  • db.collection.watch() 로 구독
  • Resume token으로 재개

15장 · Reverse ETL — Hightouch · Census · Polytomic · Grouparoo

전통 ETL이 SaaS/DB → 웨어하우스라면, reverse ETL은 웨어하우스 → SaaS다. "데이터팀이 만든 모델 결과를 다시 영업/마케팅 도구로 보내야 한다" 는 요구가 폭증하면서 별도 카테고리가 됐다.

Hightouch — 리더. Snowflake/BigQuery/Databricks/Redshift → Salesforce/Hubspot/Iterable/Segment/광고 도구. SQL로 audience 정의, sync mode 다양 (upsert, mirror, update only).

Census — Hightouch의 가장 강한 경쟁자. 비슷한 포지셔닝, 가격으로 차별화 시도. Observability와 audit이 강점.

Polytomic — 좀 더 신생. AI/ML 모델 결과 sync를 강조.

Grouparoo — 오픈소스 reverse ETL이었지만 2022년 Airbyte가 인수했고 사실상 EOL. Airbyte가 reverse ETL을 흡수하는 시도였지만 시장에서는 별도 카테고리로 굳어졌다.

Workato — 좀 더 broader iPaaS. reverse ETL을 포함하지만 RPA/워크플로우 자동화가 본업.

2026년 reverse ETL의 큰 변화: AI 추천 결과를 운영 도구에 push 가 큰 use case가 됐다. 모델이 만든 lead score, 이탈 risk, NBA(next best action)를 Salesforce로 흘려보낸다.

16장 · dbt + 웨어하우스 — Transformation 레이어

CDC/ETL이 데이터를 옮기는 거라면, dbt는 옮긴 데이터를 변환한다. Modern Data Stack의 T(Transform)다.

  • dbt Core (오픈소스, Apache 2.0)
  • dbt Cloud (매니지드)
  • SQL로 모델 정의, jinja templating, 자동 lineage
  • 지원 웨어하우스: Snowflake, BigQuery, Databricks, Redshift, Postgres, DuckDB, Trino, Athena 등

Modern Data Stack 표준 흐름:

Source (Postgres, Salesforce, Stripe)
  → CDC/ELT (Airbyte/Fivetran/Estuary/Debezium)
  → Warehouse (Snowflake/BigQuery/Databricks)
  → Transform (dbt)
  → BI (Looker/Mode/Hex/Hex)
  → Reverse ETL (Hightouch/Census) → SaaS

2024년 dbt Labs가 SDF Labs 를 인수해서 SQL compiler를 강화했고, 2025~2026년에는 Fusion 엔진이 dbt Core 위에 얹어진다는 발표가 있었다.

17장 · 파이프라인 오케스트레이션 — Airflow · Dagster · Prefect · Mage · Kestra

CDC 자체는 stream이지만, 그 결과를 받아서 dbt를 돌리고 ML 학습을 트리거하는 건 batch/scheduled 작업이다. 오케스트레이터가 필요하다.

Apache Airflow — 사실상 표준. 2024년 Airflow 3.0이 큰 리팩토링과 함께 출시됐다. UI 개선, scheduler 분리, 더 나은 dynamic DAG.

Dagster — Software-defined assets 개념. 데이터 자산을 일급 객체로. modern DS 팀에서 인기 급상승.

Prefect — Python first, dynamic workflow. 가벼움.

Mage — UI 중심 ETL. 비개발자도 접근 가능.

Kestra — YAML 기반 오케스트레이션. 데이터 파이프라인 + 일반 자동화.

2026년 흐름: Dagster가 Airflow의 데이터 엔지니어링 시장을 잠식 중. Airflow는 여전히 가장 크지만, 새 프로젝트는 Dagster를 선택하는 비율이 늘었다.

18장 · Schema Registry — Confluent · Karapace · Apicurio

CDC 이벤트는 스키마가 진화한다. Avro/Protobuf/JSON Schema를 어디선가 관리해야 한다.

Confluent Schema Registry — Kafka 표준. 라이선스가 Community License (가짜 오픈소스 비판이 있음).

Karapace — Aiven이 만든 Apache 2.0 호환 Schema Registry. Confluent의 진짜 오픈소스 대안.

Apicurio Registry — Red Hat. Apache 2.0. Schema뿐 아니라 OpenAPI/AsyncAPI도 관리.

스키마 호환성 정책 (Confluent 기준):

  • BACKWARD — 새 schema가 오래된 데이터를 읽을 수 있어야
  • FORWARD — 오래된 schema가 새 데이터를 읽을 수 있어야
  • FULL — 양방향
  • NONE — 검사 안 함 (위험)

CDC 운영에서 자주 보는 사고: 누가 DB 컬럼을 drop했는데 schema registry가 BACKWARD 였고, 다운스트림이 깨졌다.

19장 · CDC 패턴 — Outbox · Transactional Outbox · Saga

CDC를 마이크로서비스 통합으로 쓸 때 가장 흔한 패턴들.

Outbox 패턴: 도메인 DB에 "outbox" 테이블을 두고, 비즈니스 트랜잭션과 같은 트랜잭션에서 이벤트를 outbox에 INSERT 한다. CDC가 outbox 테이블을 읽어서 메시지 브로커로 보낸다. at-least-once 발행이 보장되는 게 핵심.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
INSERT INTO outbox (aggregate_id, event_type, payload)
  VALUES (1, 'AccountDebited', '{"amount":100}');
COMMIT;

CDC는 outbox 테이블의 변경만 추적해서 Kafka로 전달한다. Debezium에는 outbox event router 가 내장돼 있다.

Transactional Outbox — 같은 개념. Eventuate.io 같은 라이브러리.

Saga 패턴 — 분산 트랜잭션 대안. 일련의 로컬 트랜잭션 + 보상 트랜잭션. CDC로 saga 단계 간 통신.

Change feed — DocumentDB, Cosmos DB, DynamoDB의 native change stream을 의미. CDC와 같은 개념.

Dual write 안티패턴 — DB에 쓰고 그 다음에 Kafka에 쓰는 코드. 둘 중 하나는 실패할 수 있다. 절대 피해야 함. outbox 패턴이 이 문제의 해답.

20장 · 신뢰성 — Exactly-once · Ordering · Schema evolution

CDC를 production에서 운영하면 결국 부딪히는 세 가지.

Exactly-once semantics:

  • Debezium은 기본적으로 at-least-once 다. 중복이 발생할 수 있음.
  • Kafka transactions (Kafka 3.x) + idempotent consumer로 실용적 exactly-once 달성 가능
  • Flink는 checkpoint + 2PC로 exactly-once 기본 지원

Ordering guarantees:

  • 같은 PK의 이벤트는 같은 파티션으로 가야 → producer가 key를 PK로 설정
  • 다른 PK 사이의 순서는 보장 X
  • Postgres logical replication은 단일 publication 내에서 commit 순서 보장

Schema evolution:

  • Avro + Confluent Schema Registry + BACKWARD compatibility가 표준
  • 컬럼 추가: 안전
  • 컬럼 삭제: 다운스트림 영향, 점진적 deprecate
  • 컬럼 타입 변경: 가장 위험, 새 컬럼 + 마이그레이션

21장 · CDC for AI — Feature store / Vector store sync

2024~2026년 가장 큰 use case 변화는 AI 학습/추론 데이터의 신선도다.

Feature store sync — Tecton, Feast, Hopsworks 같은 feature store는 OLTP/이벤트와 동기화돼야 한다. 실시간 feature(예: 최근 1시간 매출)는 CDC + Flink/Kafka Streams로 계산.

Vector store sync — RAG 시스템의 source of truth가 OLTP에 있다면 Pinecone/Weaviate/pgvector를 어떻게 업데이트하는가. CDC → embedding pipeline → vector store가 표준 구조.

LLM 학습 데이터 freshness SLA — "어제 추가된 문서는 오늘 검색에 나와야 한다" 같은 SLA. CDC가 핵심.

ML 모델 트레이닝 — batch CDC dump를 S3로 보내고 Spark/Ray로 학습.

이 영역은 2026년에 fastest growing. Estuary, Sequin, Striim 같은 회사들이 모두 "AI" 메시지로 마케팅한다.

22장 · 한국 사례 — 쿠팡 / 카카오 / 네이버 / 우아한형제들

쿠팡 — Kafka + Debezium 조합이 잘 알려진 사례. 주문/재고 변경을 Kafka로 흘려 멀티 마이크로서비스가 구독.

카카오 — 기술블로그에 Debezium + Kafka Connect 운영 사례가 다수. 카카오뱅크/카카오페이는 엄격한 CDC 운영.

네이버 — 자체 데이터 플랫폼에 binlog 기반 CDC 다수. NCloud의 데이터 통합 서비스도 있음.

우아한형제들 (배민) — Debezium 도입 후기 + 운영 노하우 기술블로그 다수.

NCsoft / 넥슨 — 게임 로그/세이브 데이터 CDC. Kafka + 자체 도구.

토스 — Pinpoint, Slack 통합처럼 토스 기술블로그에 CDC 글 산발. Postgres logical replication + 자체 컨슈머.

공통점: 대부분 Debezium + Kafka 자체 운영, Fivetran 같은 매니지드는 미국 본사가 있는 글로벌 SaaS에서 주로 사용.

23장 · 일본 사례 — Mercari · LINE · Cookpad · ZOZO

Mercari — ML 플랫폼에서 CDC가 핵심. Tech blog에 Debezium + GCP Pub/Sub 사례.

LINE (LY Corporation, 야후재팬 통합) — 데이터 엔지니어링 블로그에 Kafka + Debezium + Hadoop/Trino lakehouse 사례. PrivateMode CDC 운영 매우 큼.

Cookpad — 레시피 데이터 + 사용자 로그 CDC. Aurora + DMS + Redshift 조합.

ZOZO — 패션 EC. Snowflake로의 CDC를 Fivetran/자체 도구 혼용.

CyberAgent — 광고/게임/미디어 사업 다양. Kafka + Debezium 표준.

Recruit / Indeed — 데이터 플랫폼에 자체 CDC 인프라.

일본은 Snowflake/Databricks 도입이 가속화 중이고, 그에 따라 Airbyte/Fivetran 비중이 커지고 있다.

24장 · 의사결정 — 우리 팀은 뭘 쓸까

체크리스트:

  1. DB 한 개, 실시간 필요 X → Sling CLI + cron / dbt
  2. Postgres 한 개, 실시간 필요 → Sequin 또는 Debezium Server
  3. 여러 DB + Kafka 이미 있음 → Debezium + Kafka Connect
  4. Flink 이미 있음 or 한꺼번에 도입 → Flink CDC 3.x + Iceberg/Paimon
  5. SaaS 커넥터 많이 필요, 비용 OK → Fivetran
  6. SaaS 커넥터 많이 필요, 비용 ↓ → Airbyte (자가 호스팅 / Cloud)
  7. 매니지드 + 진짜 실시간 + 예측 가능 가격 → Estuary Flow
  8. OLTP 진실을 SaaS로 push → Hightouch / Census (reverse ETL)
  9. AWS만 쓴다 → AWS DMS + Kinesis
  10. GCP만 쓴다, BigQuery → GCP Datastream
  11. 엔터프라이즈 Oracle/SAP → Striim / Qlik Replicate / GoldenGate

핵심 안티패턴:

  • Dual write — DB와 Kafka에 둘 다 직접 쓰는 코드. 절대 금지. outbox 패턴 써라.
  • Polling으로 분 단위 lag — 운영 DB에 압박. log-based로 이행.
  • MAR 폭발 — Fivetran 청구서 보고 깜짝 놀라기 전에 가격 모델 시뮬레이션.
  • Schema BACKWARD 무시 — 컬럼 drop 한 번에 모든 다운스트림 다운.

25장 · 운영 노하우 — 자주 만나는 문제

Postgres logical slot이 안 줄어든다:

SELECT slot_name, active, restart_lsn, confirmed_flush_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots;

retained_wal이 GB로 늘면 컨슈머가 lag 됐거나 죽었다. 대응:

  1. 컨슈머 재기동
  2. 정 안 되면 slot 삭제 후 재생성 + initial snapshot 다시

Kafka 토픽 rebalance가 5분 걸린다: KIP-848 (next-gen consumer rebalance), Static membership(group.instance.id) 설정.

Debezium이 처음에 lag 폭발: snapshot 중. incremental.snapshot.chunk.size 조정, snapshot.fetch.size 조정. Flink CDC는 parallel snapshot으로 이 문제가 적다.

MySQL binlog가 너무 빨리 expire → 컨슈머 lag 때 데이터 유실. binlog_expire_logs_seconds 늘리거나, S3 archival 같은 솔루션.

Snowflake 비용 폭발 — CDC가 micro-batch로 들어가서 small file이 폭발. compaction 주기 조정 + warehouse 크기 조정. dbt incremental model로 정리.

에필로그 — 데이터는 옮기는 게 아니라 약속이다

2026년 CDC와 데이터 통합은 결국 **계약(contract)**의 문제로 수렴한다. Schema 진화, ordering, exactly-once, freshness SLA — 이 모두가 producer와 consumer 사이의 계약이다.

도구는 많다. Debezium도 좋고, Estuary도 좋고, Flink CDC도 좋고, Airbyte도 좋다. 하지만 잘못된 도구를 잘 운영하는 것보다 맞는 도구를 못 다루는 것이 더 흔한 실패다.

질문 순서:

  1. 이 데이터의 주인은 누구인가? — source of truth는 어디
  2. 누가, 얼마나 빠르게 봐야 하는가? — freshness SLA
  3. 재처리 가능한가? — 보존 기간, replay 비용
  4. schema는 어떻게 진화하는가? — 누가 계약 변경을 승인하나
  5. 사고는 어떻게 감지·복구하는가? — observability, lag 모니터링

이 다섯 개에 답을 가진 팀은 어떤 도구를 써도 잘 된다. 답을 못 가진 팀은 Fivetran 청구서를 보고서야 비로소 데이터 거버넌스를 시작한다.

CDC는 인프라가 아니라 데이터 계약의 표현이다. 그렇게 다루자.

참고 / References

  1. Debezium 공식 문서
  2. Debezium 3.0 Release Notes
  3. Debezium Server 가이드
  4. Estuary Flow Docs
  5. Apache Flink CDC
  6. Flink CDC 3.x Documentation
  7. Airbyte Documentation
  8. Airbyte Protocol Spec
  9. Fivetran Docs
  10. Sling Documentation
  11. Sequin Docs
  12. Meltano Hub
  13. Striim Platform
  14. Qlik Replicate
  15. Oracle GoldenGate
  16. AWS DMS Documentation
  17. GCP Datastream
  18. Azure Data Factory CDC
  19. Hightouch Documentation
  20. Census Documentation
  21. dbt Documentation
  22. Apache Airflow
  23. Dagster Docs
  24. Confluent Schema Registry
  25. Karapace OSS Schema Registry
  26. Apicurio Registry
  27. Postgres Logical Replication
  28. MongoDB Change Streams
  29. Outbox Pattern (microservices.io)
  30. Mercari Engineering Blog
Discuss on Twitter • View on GitHub