CDC로 설계하는 실시간 데이터 변경 전파 파이프라인

변경만 흘려보내는 데이터 파이프라인

Change Data Capture(CDC)는 데이터베이스에서 발생한 Insert, Update, Delete 변경 이벤트를 찾아 추출하고 전파해 데이터 전송, 공유, 동기화, 감사를 자동화하는 기술 또는 설계 패턴이다. 배치 중심 데이터 이동의 한계를 줄이고 실시간 또는 근접실시간 동기화를 구성할 때 사용한다.

CDC의 범위는 변경을 포착하는 단계에만 그치지 않는다. Capture 이후 Enrich/Serialize를 통한 포맷 표준화, Transport를 통한 전달, Apply/Sink를 통한 대상 시스템 반영까지 전체 흐름이 대상이다. 구현 지점도 스토리지 하드웨어와 WAL 또는 로그 계층, DB 트리거, 애플리케이션 이벤트 발행, 행 단위 Timestamp·Version·Status 표식까지 넓다. 하나의 정보시스템 안에서도 목적에 따라 여러 CDC 메커니즘을 함께 운영할 수 있다.

전달은 소스가 이벤트를 내보내는 Push 방식과 소비자가 필요할 때 가져가는 Pull 방식으로 나뉘며, 둘을 결합한 구성도 가능하다.

지연과 정합성 사이에서 결정할 문제

트랜잭션 커밋과 거의 동시에 처리하거나 수초 단위 지연 SLA를 두는 경우가 많다. 마이크로배치와 스트리밍을 혼합할 수도 있으며, 이때 지연과 처리량의 트레이드오프를 관리해야 한다.

행 표식 기반 방식은 단순하고 저부하 특성이 있지만 애플리케이션 규율이 필요하다. 트리거는 정합성에 강점이 있으나 시스템 관리가 복잡해지고 확장성이 낮아질 수 있다. redo/WAL 로그를 읽는 Log Scanner는 고성능·고정합 구현에 적합하지만 환경 제약이 있고 운영 난이도는 중간 수준이다.

Push는 낮은 지연을 얻는 대신 백프레셔, 재시도, 스로틀링 설계가 중요하다. Pull은 소비자가 제어할 수 있지만 폴링 비용과 지연이 늘어날 수 있어 캐시와 체크포인트 설계가 필요하다.

어느 방식을 쓰더라도 트랜잭션 경계와 커밋 순서를 보존하고, 재처리와 멱등성을 보장해야 한다. 이를 위해 오프셋 또는 LSN 체크포인트, DLQ(사망 큐), 재시도 정책, 스키마 진화 관리가 함께 필요하다.

캡처부터 싱크까지의 흐름

⤢✕

소스 트랜잭션이 커밋되면 WAL/Redo/Undo 로그를 읽거나 트리거·애플리케이션 이벤트를 통해 변경이 발생한다. 초기 적재(Full Snapshot)와 변경 스트림을 병행할 전략도 이 시점에 정한다.

변경 추출 단계에서는 LSN/SCN 기반으로 순서를 보존하고, before/after와 op type: I/U/D 같은 스키마 메타데이터를 포함한다. 이후 메시지 큐가 전송과 완충을 맡으며, 배압 관리, 재시도와 지수 백오프, 멱등 키 부여가 이어진다. 변환 과정에서는 AVRO/JSON/Protobuf 호환성, PII 마스킹, 파티셔닝을 고려한다.

싱크는 Upsert/Merge와 Soft/Hard delete 전파, 트랜잭션적 커밋을 수행한다. 싱크가 성공한 뒤 체크포인트에 오프셋을 저장하고, 정확히 한 번 효과는 멱등 처리로 달성한다. 역직렬화 실패는 DLQ로 옮긴 뒤 알리고 스키마 롤아웃을 조정한다. 싱크 쓰기 실패는 지수 백오프로 재시도하며, 부분 실패에서는 멱등 Upsert가 보장되어야 한다. 스로틀링이나 배압이 발생하면 캡처 레이트를 조정하고 파티션 리밸런싱을 수행한다.

캡처 방식별 특성

구현 기법	성능	확장성	일관성	안정성	운영 편의
Time Stamp on Rows	높음	높음	중간	중간	높음
Version Numbers on Rows	높음	높음	높음	중간	중간
Status on Rows	높음	높음	낮음	중간	중간
Time/Version/Status 복합	중간	중간	높음	중간	중간
Triggers on Tables	낮음	낮음	높음	중간	낮음
Event Programming(앱)	중간	중간	중간	중간	낮음
Log Scanner on Database	높음	높음	높음	높음	중간

트리거는 변경 관리와 릴리즈·스키마 수정이 어려워지고 확장성이 감소할 수 있다. 행 표식은 삭제 전파가 어려워 Soft delete 설계가 필요하며, 애플리케이션이 정한 규율을 지키지 않으면 변경 누락 위험이 있다. Log Scanner는 소스 부하를 최소화하고 커밋 순서를 보존하지만 DB·엔진 권한과 인프라 요구가 늘어난다.

운영 조건을 설계에 반영하는 방법

먼저 지연 SLA, 원자성·순서·중복 허용을 포함한 데이터 정합성 수준, 처리량 목표를 정한다. OLAP, 검색, 캐시, 레플리카 중 어떤 싱크를 둘지와 Upsert/Merge/Delete 적용 방식도 함께 결정한다.

소스에서는 트랜잭션 특성, PK/UK 유무, 삭제 처리 방식, 스키마 진화 빈도, DB 엔진 기능을 확인한다. 고정합과 저부하가 필요한 경우 로그 기반 방식을 우선하고, 단순 요건이나 DB 제약이 있으면 행 표식 또는 이벤트 프로그래밍을 보조적으로 선택한다. 규제·감사 요구가 강한 테이블에는 트리거를 제한적으로 적용한다.

근실시간 미션 크리티컬 워크로드와 이벤트 드리븐 아키텍처에는 Push가 맞고, 소비자 제어와 격리가 필요하거나 간헐적 동기화·오프피크 처리가 필요한 경우에는 Pull을 검토한다.

초기 적재는 Consistent Snapshot을 수행한 뒤 특정 LSN부터 스트리밍에 접속하고, 스냅샷 완료 시점과 스트림을 병합하는 방식으로 구성한다. 이벤트 키는 (PK, op_ts/version/LSN) 조합으로 두고 싱크에서 Upsert 멱등 처리를 수행한다. 오프셋은 싱크 커밋 이후에 저장해야 재시작 시 정확한 재처리가 가능하다.

스키마 진화에는 Schema Registry를 도입하고 하위 호환을 우선하며, 롤링 배포는 Producer→Consumer 순서를 따른다. 운영에서는 지연(P99), 처리량, DLQ 비율, 소스 부하, 체크포인트 랙을 수집한다. 범위 재플레이, 필터링, 리드라이브 같은 재처리 도구와 백프레셔 자동 완화도 준비한다. 최소 권한 원칙, PII 암호화·마스킹, 토픽·스트림 레벨 ACL, 감사 로그 보존 정책은 보안과 거버넌스의 기본 조건이다.

CDC가 연결하는 대상 시스템

데이터 레이크와 웨어하우스에서는 소스 RDB의 변경을 Kafka/Debezium을 거쳐 S3/GCS로 보내고 Lakehouse/BigQuery/Snowflake Merge에 반영할 수 있다. 배치 윈도우를 없애고 대시보드 신선도를 높이는 구성이다.

주문·상품 변경은 Elasticsearch 인덱스와 Redis 캐시 최신화에도 사용된다. TTL과 부분 무효화를 병행하고, 장애 시 재색인과 리드라이브 경로를 미리 정의해야 한다.

마이크로서비스 간에는 경계 컨텍스트의 읽기 전용 모델(CQRS)을 구성하고 이벤트 사가와 조합할 수 있다. 내부 이벤트와 CDC 이벤트가 중복되지 않도록 소스오브트루스를 명확히 해야 한다.

원격 리전으로 변경 스트림을 전파하는 재해 복구와 읽기 레플리카 구성에서는 RPO 수 초 수준을 달성할 수 있다. 네트워크가 끊긴 경우에는 버퍼링과 재전송 정책으로 데이터 유실을 막는다. 변경 이력 아카이브, 필드 수준 추적, 변경자·사유 메타데이터를 포함한 감사·규제 컴플라이언스에도 적용할 수 있다.

데이터 신선도와 운영 효과

환경·부하에 따라 P95 지연 15초 수준의 데이터 신선도를 달성할 수 있다. 로그 기반 CDC는 폴링·배치 대비 CPU I/O 3070% 감소 관측 사례가 있으며, 야간 배치를 80% 이상 축소하고 대시보드 업데이트 주기를 분 단위로 전환할 수 있다. RPO 수 초와 RTO 분 단위 목표도 가능하다.

이런 구성은 실시간 의사결정 체계와 데이터 제품화를 가속하고, 변경 이력의 투명성·거버넌스·스키마 진화 대응력을 높인다. 핵심은 커밋된 변경을 순서 있게 포착하고 멱등적으로 전파·적용하는 데 있다. 로그 기반 방식을 주축으로 행 표식, 애플리케이션 이벤트, 트리거를 조합할 수 있으며, 표준 포맷·오프셋 관리·DLQ 운용으로 다수 CDC 메커니즘의 운영 복잡도를 제어한다.