SCM 삭제 이벤트 검수에서 지운 항목의 재등장을 막는 법
SCM 조회 사본에서 삭제한 항목이 재처리 뒤 다시 나타날 때, 원천 삭제와 부분 목록의 누락을 구분하고 마지막 순번을 보존하는 법을 가상 검수표로 살펴봅니다.
이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스
2026-11-04 기준, SCM 조회 사본은 원천의 명시적 삭제 신호를 처리하고 마지막 순번을 남깁니다. 부분 목록에서 빠진 항목은 확인 전 보류합니다.
품목이 원천에서 제거됐는데, 실패한 연동 작업을 다시 돌리자 옛 품목이 운영 화면에 나타났다고 가정해 보겠습니다. 조회 사본의 행을 지우면서 마지막 삭제 순서도 잃어버리면, 뒤늦게 온 옛 수정과 새 등록을 구분하기 어렵습니다. 검수 범위는 조회 사본입니다. 원장과 감사 기록에는 별도 보존 정책을 적용합니다.
어떤 신호를 받았을 때 조회에서 제외하나요?#
원천이 계약한 삭제 신호를 보내면 대상 키를 확인하고 사본에서 제외합니다. 단종이나 거래 취소가 업무 상태로 전달된다면 그 상태를 보존하고 조회 조건을 적용합니다. 페이지 누락이나 접근 범위 변경이 의심되면 현재 상태를 확인할 때까지 기존 사본을 유지하고 최신성에 보류 표시를 붙입니다.
| 수신 신호 | 먼저 확인할 근거 | 사본의 기대 동작 |
|---|---|---|
| 명시 삭제 | 원천 식별 키와 비교 가능한 순서 | 조회에서 제외하고 마지막 삭제 근거 보존 |
| 단종·취소 상태 | 상태 코드와 집계 규칙 | 상태와 이력을 보존하고 화면 조건 적용 |
| 일부 목록에 키가 없음 | 페이지 완료, 필터, 권한 | 사본 유지, 최신성 확인 대기 |
| 완전 스냅샷에 키가 없음 | 같은 범위의 완전성과 변경 스트림 경계 | 원천 대사 후 사본에서 제외할지 판정 |
수집 자체가 끊긴 문제는 SCM 증분 수집 검수에서 별도로 다룹니다.
삭제 이벤트와 로그의 삭제 표식은 어떻게 다른가요?#
변경 데이터 캡처인 CDC는 원천의 데이터 변경을 전달하는 방식입니다. Debezium 3.7의 PostgreSQL 커넥터에서 변환 전 삭제 이벤트의 값에는 op가 d, after가 null로 들어갑니다. 설정에 따라 같은 키에 값 전체가 null인 tombstone이 뒤따릅니다. 삭제 이벤트의 after 필드와 메시지 값 전체는 수신 단계에서 구분해야 합니다. Debezium 3.7 PostgreSQL 커넥터 문서, 2026년 9월 29일 3.7.0.Final 발표.
Kafka의 로그 압축은 키별로 오래된 메시지를 정리합니다. 이 설정이 적용된 토픽에서는 tombstone도 보존 기간이 지나 정리될 수 있습니다. 소비 지연이나 장기 복구가 그 범위를 넘어가면 예전 사본을 그대로 사용하기 전에 원천과 대사해야 합니다. 토픽 보존 설정과 조회 사본이 마지막 삭제를 기억하는 기간은 각각 검수합니다. Kafka 4.3 설계 문서, 2026년 10월 23일 4.3.2 발표.
다른 커넥터나 메시지 변환을 쓰면 최종 소비자가 받는 신호를 표본으로 확인합니다. 필드 하나의 비움이나 누락은 별도의 계약을 따릅니다. 삭제·비움·유지의 차이는 SCM 부분 갱신의 null 계약에서 설명합니다.
재처리 표본에서 무엇을 대조하나요?#
아래는 한 원천의 같은 품목 키에만 순번을 비교하는 가상 계약입니다. 실제 이벤트는 원천이 같은 키의 순서를 판정할 수 있는 식별자나 위치를 제공해야 합니다. 이 숫자는 Kafka 오프셋이나 DB 로그 위치의 규칙을 대신하지 않습니다.
품목 키 item-a
정상 처리 18 UPDATE 조회 사본 갱신
정상 처리 19 DELETE 조회 제외, 마지막 19와 삭제 상태 보존
지연 도착 17 UPDATE 마지막 19보다 오래되어 건너뜀
재전송 19 DELETE 동일 사건이면 기존 결과 유지
새 등록 20 CREATE 원천에서 재등록이 확인되면 사본 복구마지막 순서와 삭제 상태는 조회용 행과 함께 원자적으로 갱신하거나, 중단 뒤 재실행해도 두 기록이 같은 상태로 돌아오게 설계합니다. 동일 순번에 내용이 다른 입력은 중복으로 단정하지 말고 보류합니다. 아래는 검수 담당자가 재처리 후 확인할 결과입니다.
| 가상 인수 표본 | 사본의 기대 결과 | 남길 증거 |
|---|---|---|
| 삭제 뒤 옛 수정 도착 | 삭제 유지 | 마지막 삭제 순번과 거절 근거 |
| 동일 삭제 재전송 | 삭제 유지 | 같은 사건 식별자와 재처리 결과 |
| 삭제 중간에 작업 중단 | 재실행 뒤 조회 제외 | 사본과 마지막 상태의 일치 |
| 이후 등록이 원천에서 확인됨 | 재등록 반영 | 같은 범위의 새 순번과 등록 근거 |
| 오래된 사본에 삭제 근거가 없음 | 원천 대사 전 복구 보류 | 스냅샷 범위와 다시 읽을 기준 위치 |
삭제 근거를 언제까지 남겨야 하나요?#
재시도, 백업 복구, 지연 소비로 과거 입력이 들어올 수 있는 범위를 정하고 그 범위에서 필요한 최소 삭제 근거를 유지합니다. 복구에 필요한 삭제 표식의 보존 기간이 지났다면 권한과 범위가 확인된 원천 스냅샷으로 새 사본을 만들고, 일치하는 변경 스트림 위치부터 연결하는 방법을 검토합니다. 필요한 범위가 짧고 원천의 전체 목록을 매번 확실히 검증할 수 있다면 CDC 없이 사본을 교체하는 방식도 비교할 수 있습니다.
알파카랩스의 공개 서비스는 원천과 화면의 대사, 누락·지연 표시, 실패 재처리의 검수 범위를 협의한다고 설명합니다. 2026년 11월 4일 확인한 자사 제공 범위입니다. 실제 삭제 신호와 복구 방식은 원천의 계약을 확인한 뒤 정합니다. SCM 운영대시보드 개발, 업무 자동화·API 연동.
SCM 삭제 이벤트 검수 FAQ#
목록에서 사라지면 조회 사본도 지워야 하나요?
일부 페이지나 필터된 목록에서 보이지 않으면 삭제를 확정할 수 없습니다. 명시 삭제 신호가 있는지 확인합니다. 전체 범위가 증명된 스냅샷으로 대사할 때는 시점과 변경 스트림의 경계도 맞춥니다.
Debezium의 after가 null이면 Kafka tombstone인가요?
Debezium의 변환 전 삭제 이벤트는 after 필드가 null이어도 메시지 값에 연산 정보가 남습니다. Kafka tombstone은 같은 키에 대해 메시지 값 전체가 null인 별도 표식입니다. 실제 소비자는 설정과 변환 뒤 형식을 확인해야 합니다.
삭제 표식을 받으면 주문 원장도 지워야 하나요?
이 글의 적용 범위는 운영 조회 사본입니다. 주문 취소나 회계·감사 기록의 처리는 원천 업무 계약과 보존 정책을 따릅니다. 같은 이벤트를 모든 저장소의 삭제 명령으로 전달하지 않습니다.
삭제 이후 같은 키로 다시 들어오면 어떻게 처리하나요?
가상 예시처럼 새 등록이 허용되는 키는 비교 가능한 최신 순서와 원천의 등록 근거를 확인한 뒤 반영합니다. 키가 다른 개체에 재사용되거나 순서가 불명확하면 개체 구분과 원천 상태를 확인할 때까지 보류합니다.
tombstone만 오래 보관하면 재등장을 막을 수 있나요?
로그의 보존 설정은 소비자가 표식을 읽을 수 있는 범위에 영향을 줍니다. 조회 사본에서 과거 입력을 거절할 근거도 별도로 유지하거나 복구 과정에서 다시 구성해야 합니다. 복구 범위가 표식 보존을 넘어가면 원천 대사를 먼저 합니다.
삭제 재처리 인수표 협의#
민감정보를 뺀 원천 키와 삭제·지연 입력 표본, 화면에서 기대하는 상태를 준비하세요. 자료를 확인한 뒤 삭제·보류·복구의 인수표 초안 범위와 소요 시간을 협의합니다.
삭제·보류·복구를 가르는 인수표 범위를 정합니다
비식별 키와 재처리 표본으로 기대 결과와 검수 항목을 협의합니다. 자료 확인 뒤 소요 시간을 정합니다.
SCM 삭제 재처리 검수 범위 협의