CDP와 CRM 툴(Braze 등) 연동 시 중복 유저를 하나의 ID로 병합하는 매칭 원칙

신원 해석(Identity Resolution)은 서로 다른 기기·채널·세션에 흩어진 데이터를 한 사람으로 연결하는 과정이고, 이메일·전화번호처럼 정확한 식별자를 맞추는 결정론적 방식과 행동 신호로 추론하는 확률론적 방식으로 나뉩니다. 실무에서 먼저 정할 것은 이 중 어떤 키가 일치했을 때 동일인으로 확정할지의 순서입니다.

권장 순서는 사업자가 직접 발급하고 바뀌지 않는 값을 최상위에 두는 것입니다. 회원번호처럼 자사가 통제하는 불변 식별자가 1순위, 인증을 거친 전화번호나 이메일이 2순위, 기기 식별자나 쿠키는 보조 신호로 내려갑니다. 반대로 이메일을 최상위 키로 쓰면 가족 공용 계정이나 오타 입력 한 건에 프로필이 통째로 흔들립니다. 확률론적 매칭은 여러 행태정보를 결합해 특정 개인을 식별할 수 있게 되는 순간 개인정보에 해당한다는 개인정보보호위원회의 해석이 걸리므로, 도입 전에 법무 검토를 거치는 순서가 안전합니다.

같은 사람의 레코드 두 개에서 주소가 다르거나 마지막 구매일이 다르면 어느 값을 남길지 정해야 합니다. 이것을 생존 규칙이라고 부르며, 매칭 키 못지않게 사고가 자주 나는 지점입니다. Salesforce Data Cloud는 이 매칭과 정합 규칙을 룰셋이라는 형태로 관리하고, 그 결과를 통합 객체로 만들어 냅니다.

문제는 도구마다 기본 동작이 다르다는 점입니다. 그래서 순서를 뒤집어야 합니다. 도구를 켜고 기본값을 확인하는 것이 아니라, 자사 규칙을 먼저 문서로 정의한 뒤 도구의 기본값과 대조해 어긋나는 항목만 설정으로 덮는 방식입니다. 최소한 연락처, 주소, 마케팅 동의 상태, 등급 정보 네 가지는 어느 시스템의 값을 정본으로 볼지 미리 적어 두어야 합니다.

Braze 공식 문서에 따르면 SDK가 external_id 없이 처음 인식한 사용자에게는 기기별로 고유한 braze_id를 가진 익명 프로필이 만들어집니다. 이후 그 사용자가 기존 식별 프로필과 동일인으로 확인되면 익명 프로필은 고아 처리되고, 식별 프로필에 아직 없는 필드만 병합됩니다. 데이터가 충돌하는 경우에는 식별된 사용자 쪽 값이 유지됩니다.

이 규칙이 설계에 미치는 영향이 큽니다. 푸시 토큰과 메시지 발송 이력은 넘어오지만 커스텀 속성, 커스텀 이벤트, 구매 이력은 식별 프로필에 해당 필드가 없을 때만 병합됩니다. 즉 로그인 전에 담은 장바구니 속성이 식별 프로필에 이미 오래된 값으로 존재하면 새 값이 덮이지 않습니다. 로그인 직후 최신 값을 다시 한 번 명시적으로 쓰는 호출을 시나리오에 넣어 두면 이 공백을 메울 수 있습니다.

Braze 문서는 사용자를 고유하게 식별할 수 있기 전에 external_id를 부여하지 말라고 경고하고, 한번 식별한 사용자는 다시 익명으로 되돌릴 수 없다고 못 박습니다. 이메일 주소를 external_id로 쓰는 것에 대해서도 쉽게 추측 가능해 공격에 취약하다고 안내합니다.

되돌릴 수 없다는 점 때문에 이 결정은 사후 정정 비용이 가장 큰 항목입니다. 회원가입 완료나 로그인 성공처럼 신원이 확정되는 시점에만 부여하고, 이메일 입력 폼에 값을 넣은 시점 같은 중간 단계에서는 부여하지 않아야 합니다. 이메일과 전화번호는 별칭이나 매칭 키로만 쓰는 편이 안전합니다. 별칭은 라벨과 값의 쌍으로 동작하며, 하나의 라벨 안에서 값은 전체 사용자 기준으로 유일해야 하고 기존 식별자를 대체하는 것이 아니라 더해서 작동합니다.

병합 결과는 두 방향의 오류로 나타납니다. 서로 다른 사람이 한 프로필로 합쳐지는 과병합과, 같은 사람이 여러 프로필로 남는 미병합입니다. 이 중 되돌리기 어려운 쪽은 과병합입니다. 다른 사람의 구매 이력이 메시지에 노출되는 개인정보 사고로 직결되기 때문입니다. 그래서 초기에는 엄격한 기준에서 시작해 미병합을 감수하고, 이후 데이터를 보며 좁혀 나가는 순서를 권합니다.

점검 지표로는 프로필 비대화 신호를 함께 봅니다. Braze는 세션 500만 건 초과, 고유한 커스텀 이벤트 이름 2만 개 초과, 고유 상품명 2만 개 초과인 프로필을 차단하는데, 정상 사용자보다는 병합 사고나 스키마 실수를 잡아내는 지표로 유용합니다. 이벤트 이름에 상품명이나 주문번호 같은 가변 값을 끼워 넣으면 고유 이벤트 이름이 폭증하니, 가변 값은 이름이 아니라 속성으로 넣어야 합니다.