인지 직후 무엇을 먼저 멈춰야 하나

데이터가 빠진 상태에서도 자동화 시나리오는 계속 돕니다. 구매 이벤트가 들어오지 않으면 결제한 고객이 미구매로 판정돼 독촉 메시지가 나가고, 수신거부 이벤트가 빠지면 거부한 고객에게 발송이 계속됩니다. 후자는 데이터 문제가 아니라 정보통신망법 제50조 제2항 위반입니다.

그래서 복구 착수보다 먼저 발송을 멈춥니다. 중지 대상은 광고성 자동화 시나리오와 광고 매체로 나가는 오디언스 동기화이고, 배송·결제 안내 같은 정보성 발송은 유지하되 그 데이터가 영향받았는지 별도로 확인합니다. 중지 절차를 미리 문서로 만들어 두지 않으면 사고 당일에 어떤 시나리오를 꺼야 하는지 찾느라 시간을 씁니다.

재적재를 안전하게 하려면 무엇이 필요한가

백필을 돌릴 때 가장 흔한 2차 사고는 중복 집계입니다. 같은 구매 이벤트가 두 번 들어가면 누적 구매 횟수 조건이 통째로 틀어지고, 그 세그먼트로 이미 나간 발송은 되돌릴 수 없습니다.

이를 막는 조건은 멱등 처리입니다. 모든 이벤트에 고유 ID를 부여하고 같은 ID가 다시 들어오면 한 번으로 처리하는 구조여야 합니다. 메타 전환 API나 틱톡 이벤트 API처럼 클라이언트와 서버 신호를 병행 운영하는 구조에서도 이벤트 ID로 중복을 제거하는 것이 공식 권장 방식이며, 내부 파이프라인에도 같은 원리가 적용됩니다. 이 구조가 없다면 백필 전에 대상 기간의 데이터를 먼저 삭제하고 다시 넣는 방식을 택해야 하는데, 이 경우 삭제 범위를 잘못 잡으면 피해가 더 커지므로 사전에 대상 건수를 반드시 확인합니다.

복구 후 검증을 어떤 순서로 하나

첫 단계는 건수 대조입니다. 원본 시스템의 기간별 이벤트 건수와 CDP에 적재된 건수를 날짜 단위로 비교합니다. 여기서 차이가 남아 있으면 다음 단계로 넘어가지 않습니다. 제휴 마케팅에서 집계 전환수가 내부 주문 수와 5~10% 이상 차이 나면 추적 문제 신호로 보는 관행이 있는데, 복구 검증에서는 그보다 엄격하게 차이가 0에 가까운지를 확인해야 합니다.

두 번째는 표본 대조입니다. 고객 몇 명을 뽑아 원본 시스템의 이력과 CDP 프로필의 이력을 한 줄씩 맞춰 봅니다. 건수는 맞는데 순서나 속성이 어긋나는 경우가 여기서 잡힙니다. 세 번째는 세그먼트 인원 대조입니다. 주요 세그먼트의 인원을 장애 이전 값과 비교해 예상 범위 안에 들어왔는지 확인한 뒤에 발송을 재개합니다.

유실 기간의 발송 영향을 어떻게 정리하나

복구가 끝나도 유실 기간에 이미 나간 발송은 되돌릴 수 없습니다. 그래서 영향 범위를 별도로 정리해야 고객 응대와 내부 보고가 가능해집니다. 정리할 항목은 세 가지입니다. 잘못 발송된 건수와 대상, 발송되지 않았어야 할 유형인지 여부, 그리고 그 발송이 수신거부자에게 나갔는지입니다.

특히 세 번째는 성격이 다릅니다. 단순 오발송이 아니라 법 위반에 해당할 수 있으므로 건수와 시각을 정확히 기록하고 법무와 공유해야 합니다. 반대로 발송되었어야 하는데 나가지 않은 정보성 메시지가 있다면 뒤늦게라도 보낼지 판단해야 하는데, 시점이 지나 의미가 없어진 안내는 보내지 않는 편이 나은 경우도 있습니다.

재발 방지로 무엇을 남기나

사고 후에 남겨야 할 것은 원인 보고서보다 감시 장치입니다. 최소한 세 가지를 만들어 둡니다. 채널별 이벤트 유입량이 평소 대비 급감하면 알리는 알림, 원본과 CDP의 일일 건수 대조 리포트, 그리고 억제 조건 조회가 실패했을 때 발송을 보류하는 안전장치입니다.

개인정보 유출이 함께 발생한 경우에는 별도의 의무가 걸립니다. 개인정보 보호법 제34조와 시행령 제40조는 유출 등을 알게 된 때로부터 72시간 이내에 개인정보보호위원회 또는 한국인터넷진흥원에 신고하도록 규정하며, 구체적 내용을 다 확인하지 못했어도 확인된 사실부터 우선 신고하고 추가로 확인되는 대로 보완 신고해야 합니다. 기산점이 유출 사실을 알게 된 시점이므로 원인 규명을 기다리다 기한을 넘기지 않아야 합니다.