왜 식별자부터 손대야 하나

CDP의 핵심 산출물은 여러 시스템에 흩어진 데이터를 하나의 프로필로 합친 단일 고객 뷰입니다. 이 병합이 식별자를 기준으로 일어나므로, 식별자가 정리되지 않은 상태에서 다른 항목을 아무리 다듬어도 잘못 합쳐진 프로필 위에 깨끗한 값이 얹힐 뿐입니다.

식별자 정제에서 실제로 하는 일은 세 가지입니다. 표기 형식 통일, 명백한 오류 값 표시, 그리고 한 사람에게 여러 식별자가 붙어 있는 경우의 대표값 지정입니다. 이때 "010-0000-0000" 같은 자리 채우기 값이나 사내 테스트 계정이 남아 있는지도 함께 확인합니다. 이런 값은 그대로 두면 수백 명이 한 프로필로 묶이는 과병합의 원인이 됩니다.

동의·수신거부 상태를 2순위에 두는 이유

동의 데이터의 오류는 다른 항목과 성격이 다릅니다. 주소가 오래된 것은 배송 지연으로 끝나지만, 수신거부한 고객이 발송 대상에 남아 있는 것은 정보통신망법 제50조 제2항 위반입니다. 개인정보 보호법상 과징금의 현행 근거는 제64조의2로, 보호위원회는 전체 매출액의 100분의 3을 초과하지 않는 범위에서 과징금을 부과할 수 있습니다.

정제할 때 확인할 항목은 채널별 분리 여부, 목적별 분리 여부, 그리고 철회 이력의 보존 여부입니다. 이메일 동의로 문자를 보낼 수 없고, 개인정보 수집·이용 동의와 광고성 정보 수신동의는 별개 층위입니다. 필드가 하나로 뭉쳐 있다면 정제 단계에서 나누는 것이 CDP 도입 이후에 나누는 것보다 훨씬 쉽습니다. 철회 이력은 지우지 말고 남겨야 나중에 왜 이 고객이 제외됐는지 설명할 수 있습니다.

어떤 필드를 정제하지 않고 넘길 것인가

남은 필드를 모두 다듬으려 들면 프로젝트가 정제 단계에서 멈춥니다. 기준은 단순합니다. 지금 운영 중이거나 도입 직후 운영할 세그먼트 조건과 개인화 변수에 실제로 쓰이는 필드만 3순위로 올리고, 나머지는 그대로 적재한 뒤 필요해질 때 다듬습니다.

이 판단을 하려면 현재 쓰는 세그먼트 조건 목록이 있어야 합니다. 목록을 뽑아 보면 실제로는 예닐곱 개 필드만 반복해서 쓰이고 있는 경우가 많습니다. 반대로 목록에 없는데도 정제 요청이 올라온 필드는 "그 필드로 무슨 세그먼트를 만들 계획인가"를 되물어 확인하면 우선순위가 정리됩니다.

정본을 정하지 않은 정제가 왜 위험한가

같은 고객의 주소가 자사몰과 콜센터 시스템에서 다를 때, 어느 쪽을 남길지 정하지 않고 한쪽을 덮어쓰면 그 작업 자체가 데이터 손상입니다. 값이 충돌할 때 어느 쪽을 남길지 정하는 생존 규칙을 정제 착수 전에 문서로 만들어야 합니다.

도구의 기본 동작도 함께 확인합니다. Braze 공식 문서는 익명 프로필과 식별 프로필을 합칠 때 식별 프로필에 없는 필드만 병합하고 충돌 시 식별된 사용자 값을 유지한다고 명시하며, Salesforce Data Cloud는 매칭·정합 규칙을 룰셋으로 관리합니다. 도구마다 기본값이 다르므로 자사 규칙을 먼저 정의한 뒤 기본값과 대조해 어긋나는 항목만 설정으로 덮는 순서가 안전합니다.

정제 결과를 어떻게 되돌릴 수 있게 남기나

정제는 한 번에 끝나지 않고 규칙을 몇 차례 바꾸게 됩니다. 그래서 값을 지우거나 덮는 대신, 원본을 보관하고 판정 결과를 별도 필드로 표시하는 방식을 권합니다. 예를 들어 전화번호는 원본과 정규화 값을 함께 두고, 유효성 판정은 별도 플래그로 남깁니다.

작업 로그도 함께 남겨야 합니다. 언제 어떤 규칙으로 몇 건을 어떻게 바꿨는지 기록이 없으면, 세그먼트 인원이 갑자기 변했을 때 원인이 정제 때문인지 실제 고객 행동 변화인지 구분할 수 없습니다. 개인정보 보호법 제34조는 유출을 알게 된 때부터 72시간 이내 신고를 규정하는데, 사고 조사에서도 이 작업 로그가 있어야 영향 범위를 빠르게 특정할 수 있습니다.