운영 DB의 주문 데이터를 분석 대시보드로 보내기로 했습니다. 처음에 전체 테이블을 복사하고, 그 뒤부터 변경된 행만 옮기면 쉬워 보입니다. 하지만 전체 복사가 도는 동안 주문이 수정되면 어느 시점의 값이 분석 DB에 남아야 할까요? 이 경계를 정의하지 않으면 누락이나 되돌아간 값이 생깁니다. CDC(Change Data Capture)는 데이터베이스의 변경 기록을 읽어 후속 시스템에 전달하는 방식이지만, 핵심은 도구 설치보다 초기 상태와 변경 스트림을 끊김 없이 잇는 운영 설계입니다.
초기 복사와 변경 로그의 기준점을 연결한다
CDC를 시작할 때 대상에는 기존 행이 없습니다. 먼저 일관된 스냅샷으로 기준 상태를 만들고, 그 스냅샷이 가리키는 로그 위치부터 생성·수정·삭제 이벤트를 적용합니다. 단순히 테이블을 전부 읽은 뒤 ‘지금부터 로그를 보자’라고 하면 읽는 동안의 변경이 빠집니다. 반대로 로그를 너무 이른 위치에서 무작정 적용하면 중복될 수 있습니다. Debezium MySQL 커넥터 문서는 초기 스냅샷과 binlog 위치를 연결한 뒤 변경을 계속 읽는 과정을 설명합니다. 실제 설정은 사용하는 DB와 커넥터 버전, 잠금 정책에 맞춰 확인해야 합니다.
스냅샷 대상 테이블과 열을 정할 때 개인정보와 대용량 컬럼을 무턱대고 복제하지 않습니다. 분석에 꼭 필요한 필드만 선별하고, 고객사별 접근 경계를 대상 시스템에서도 유지합니다. 소스 DB의 기본 키는 대상에서 변경 이벤트를 적용할 기준이 되므로 누락되면 재처리와 삭제 반영이 어려워집니다. 처음 전체 복사가 오래 걸리는 대형 테이블은 청크 크기와 소스 부하, 로그 보존 기간을 함께 고려합니다. 초기 복사 때문에 운영 DB의 응답이 느려지는지 별도 지표로 관찰해야 합니다.
대상 소비자는 중복과 순서에 견뎌야 한다
전송 시스템이 재시작하면 같은 변경 이벤트를 다시 받을 수 있습니다. 따라서 대상에는 기본 키를 기준으로 멱등하게 덮어쓰거나 이벤트 식별자·버전을 비교해 이미 반영한 변경을 건너뛰는 규칙이 필요합니다. 삭제 이벤트를 무시하면 운영 DB에는 없는 고객 정보가 분석 시스템에 계속 남습니다. 논리 삭제 컬럼을 사용하는 서비스라면 물리 삭제와 상태 변경의 의미를 구분해야 합니다. 여러 테이블을 합쳐 하나의 화면을 만들 때는 각 테이블의 업데이트 시점이 잠시 다를 수 있으므로 조회 결과의 최신성 표시도 고려합니다.
스키마가 바뀌는 순간도 위험합니다. 소스에 열이 추가되거나 타입이 바뀌면 커넥터, 메시지 직렬화, 대상 테이블, 대시보드 쿼리가 각각 어떤 동작을 하는지 확인해야 합니다. 모든 변경을 하나의 거대한 배포로 묶기보다 소비자가 구형·신형 이벤트를 잠시 함께 읽을 수 있게 하는 이행 기간을 둡니다. 이벤트에는 처리 시각뿐 아니라 소스에서 발생한 시각을 보존해야 지연을 측정할 수 있습니다. 처리 지연이 작아 보여도 특정 테이블 이벤트가 멈췄다면 실제 데이터는 오래됐을 수 있습니다.
주문과 주문 항목처럼 여러 테이블이 하나의 업무 사실을 구성한다면 단일 행 이벤트만 보고 ‘주문이 완성됐다’고 판단하지 않도록 주의합니다. 트랜잭션 경계나 소스의 상태 변경 규칙을 반영해 최종 집계 시점을 정하고, 분석 화면에 잠시 불완전한 합계가 보일 수 있는지 계약합니다. 데이터 파이프라인의 지연 허용 범위를 고객과 합의하면 실시간이라는 모호한 약속보다 장애 판단이 쉬워집니다.
재시작 뒤에는 ‘돌아왔다’가 아니라 ‘맞다’를 확인한다
커넥터가 멈췄다가 저장한 위치에서 재개하려면 해당 로그가 아직 남아 있어야 합니다. 로그가 이미 정리됐다면 단순 재시작이 아니라 새 스냅샷이나 복구 절차가 필요합니다. 운영자는 마지막 수신 위치와 시간, 소비자 적용 지연, 오류 이벤트, 대상의 행 수·합계 대사 결과를 함께 봐야 합니다. 합계만 맞아도 일부 행은 다를 수 있으므로 중요한 고객·날짜 구간을 표본 검증합니다. 테스트에는 스냅샷 도중 수정, 연속 수정, 삭제, 커넥터 재시작, 로그 보존 초과, 스키마 변경을 포함하세요. CDC의 완료 기준은 이벤트가 흐른다는 사실이 아니라 대상 데이터가 소스의 약속한 시점과 의미에 맞는가입니다.
