MDM 골든 레코드 설계: 중복 고객 식별과 잘못된 병합 복구

1장. 전화번호가 같아서 합쳤더니 가족의 주문이 한 사람 것이 되었다#

CRM에 다음 고객이 있습니다.

C-17
이하늘
010-1111-2222
서울

쇼핑몰에도 다음 고객이 있습니다.

S-82
이하늘
010-1111-2222
부산

이름과 전화번호가 같습니다.

시스템은 두 레코드를 같은 사람으로 판단하고 하나의 고객으로 합쳤습니다.

그 결과:

CRM 상담 이력

+

쇼핑몰 주문 이력

이 모두 하나의 고객 아래로 모였습니다.

그런데 나중에 확인해 보니 두 사람은 가족이었고 같은 휴대전화 번호를 공동 연락처로 사용하고 있었습니다.

고객 통합은 성공한 것처럼 보였지만 실제로는 두 사람의 개인정보와 주문 이력을 섞어버렸습니다.

이것이 오병합입니다.

2장. 반대로 같은 사람을 둘로 남기는 문제도 있다#

이번에는 한 고객이 휴대전화 번호를 변경했다고 하겠습니다.

기존 CRM:

김가람
010-1111-2222

새 쇼핑몰 계정:

김가람
010-9999-0000

전화번호가 다릅니다.

시스템이 전화번호 일치만 이용한다면 두 고객을 서로 다른 사람으로 남길 수 있습니다.

실제로는 한 사람인데 고객 수가 두 명으로 계산됩니다.

실제 고객
1명

시스템 고객
2명

이것은 미병합 문제입니다.

MDM에서는 오병합과 미병합을 함께 관리해야 합니다.

3장. MDM은 단순한 중복 제거 도구가 아니다#

MDM은 Master Data Management의 약자입니다.

고객·상품·거래처·조직처럼 여러 시스템에서 공통으로 사용하는 핵심 기준 데이터를 식별하고 관리하는 체계입니다.

고객 MDM이라면 대략 다음 흐름을 다룹니다.

flowchart LR
    A["CRM 고객"] --> M["고객 식별·매칭"]
    B["쇼핑몰 고객"] --> M
    C["상담 고객"] --> M
    M --> G["골든 레코드"]
    G --> D["분석·CRM·고객센터 등"]

핵심은 단순히 여러 행을 하나로 합치는 것이 아닙니다.

다음 세 문제를 분리해서 해결해야 합니다.

1. 같은 사람인가?

2. 같은 사람이라면 어떤 값을 대표값으로 사용할 것인가?

3. 잘못 판단했을 때 어떻게 원래 상태로 되돌릴 것인가?

4장. 동일인 판단과 대표값 선택은 반드시 분리해야 한다#

세 원천에 다음 데이터가 있습니다.

원천	원천 ID	이름	휴대전화	주소	수정 시각
CRM	C-7	김가람	010-1111-2222	서울	9월 1일
쇼핑몰	U-82	김가람	010-1111-2222	부산	9월 5일
상담	K-19	김가람	010-9999-0000	서울	9월 6일

이 데이터를 보면 두 종류의 질문이 생깁니다.

첫 번째:

C-7, U-82, K-19는 같은 사람인가?

두 번째:

같은 사람이라면 현재 전화번호와 주소는 무엇인가?

첫 번째는 매칭 문제입니다.

두 번째는 서바이버십 문제입니다.

이 둘을 한 번에 처리하면 오류 원인을 찾기 어려워집니다.

5장. 가장 먼저 해야 할 일은 고객을 합치는 것이 아니라 후보를 찾는 것이다#

예를 들어 이름과 전화번호가 같은 레코드가 있다고 하겠습니다.

CRM C-7
김가람
010-1111-2222

쇼핑몰 U-82
김가람
010-1111-2222

이 정보를 보고 바로:

동일인 확정

으로 처리하지 않고 먼저:

동일인 후보

로 둘 수 있습니다.

이 단계에서 추가 증거를 확인합니다.

본인 인증 ID

가입 이메일

생년월일

주소

고객이 직접 확인한 연락처

계정 연동 기록

여러 근거가 일치하면 병합 신뢰도를 높일 수 있습니다.

6장. 이름은 강한 식별자처럼 보이지만 그렇지 않다#

이름:

김가람

이 같다고 하겠습니다.

하지만 동명이인은 얼마든지 존재합니다.

따라서:

이름 동일
=
동일인

이라고 판단하면 안 됩니다.

이름은 후보를 줄이는 정보로는 유용하지만 단독 확정 근거로 사용하기에는 위험할 수 있습니다.

7장. 전화번호도 완벽한 식별자는 아니다#

전화번호는 이름보다 강한 단서처럼 보입니다.

하지만 다음 상황이 있습니다.

가족 공동 번호

법인 대표 번호

고객센터 번호

휴대전화 번호 재사용

사용자 번호 변경

즉:

전화번호 동일
→ 서로 다른 사람일 수 있음

이고:

전화번호 다름
→ 같은 사람일 수 있음

입니다.

8장. 이메일도 동일한 문제가 있다#

이메일 주소도 강한 후보 식별자입니다.

하지만:

회사 공용 계정

가족 공용 계정

오래된 이메일

이메일 변경

같은 상황이 있습니다.

따라서 MDM에서 중요한 것은 하나의 필드가 아니라 여러 증거의 조합입니다.

9장. 매칭 규칙을 단계별로 나눌 수 있다#

예를 들어 다음처럼 운영할 수 있습니다.

자동 병합#

검증된 공통 고객 ID 일치
+
본인 인증 정보 일치

처럼 매우 강한 증거가 있는 경우입니다.

후보 검토#

이름 일치
+
전화번호 일치
+
주소 불일치

처럼 동일인 가능성은 높지만 오병합 위험도 있는 경우입니다.

병합 금지#

확정된 서로 다른 본인 인증 ID

처럼 같은 사람일 수 없는 증거가 있는 경우입니다.

10장. 자동 병합 기준과 수동 검토 기준을 분리하자#

예를 들어:

조건	처리
공통 본인 인증 ID 일치	자동 병합
이름+전화 일치, 주소도 일치	높은 신뢰 후보
이름+전화 일치, 주소 충돌	수동 검토
이름만 일치	낮은 신뢰 후보
확정된 다른 본인 인증 ID	병합 금지

이런 규칙을 운영 정책으로 남겨야 합니다.

11장. 퍼지 매칭은 후보를 찾는 도구다#

이름이 다음처럼 저장될 수 있습니다.

김가람

김 가람

Kim Garam

Garam Kim

단순 문자열 비교로는 서로 다른 값입니다.

편집 거리, 발음 유사도, 토큰 비교 같은 기법을 이용해 비슷한 값을 찾을 수 있습니다.

하지만:

유사도 95%

라고 해서 동일인이라는 뜻은 아닙니다.

유사도는 어디까지나 검토 후보를 만드는 점수입니다.

12장. 매칭 점수와 동일인 확정을 혼동하면 안 된다#

예를 들어:

이름 유사도
0.95

주소 유사도
0.80

전화 일치
YES

라고 하겠습니다.

이를 계산해:

match_score = 0.92

를 만들 수 있습니다.

그러나:

0.92
=
동일인 확률 92%

라고 단정할 수는 없습니다.

점수는 모델과 규칙이 만든 내부 판단 값입니다.

확률로 해석하려면 별도 검증이 필요합니다.

13장. 매칭 전에 데이터 정규화가 필요할 수 있다#

같은 전화번호가 다음처럼 저장되어 있을 수 있습니다.

010-1111-2222

01011112222

+82-10-1111-2222

표현이 다릅니다.

비교 전 표준화를 할 수 있습니다.

예:

국가 코드 분리

구분 문자 제거

국내 번호 규칙 적용

같은 처리를 수행합니다.

14장. 주소도 그대로 비교하면 같은 주소를 다르게 판단할 수 있다#

예:

서울특별시 강남구 테헤란로 10

서울 강남구 테헤란로10

서울특별시 강남구 테헤란로 10번지

실제로 같은 위치일 수 있습니다.

주소 정제와 표준화가 후보 탐지 정확도를 높일 수 있습니다.

하지만 주소 표준화가 동일인 여부를 보장하는 것은 아닙니다.

15장. 고객 병합에는 오병합과 미병합이라는 두 종류의 비용이 있다#

오병합#

서로 다른 두 사람을 하나로 합칩니다.

영향:

다른 사람의 주문 노출

개인정보 혼합

잘못된 마케팅

고객센터 오판

미병합#

같은 사람을 여러 고객으로 남깁니다.

영향:

고객 수 과대 집계

구매 이력 분산

중복 쿠폰

고객 분석 왜곡

둘 다 문제지만 일반적으로 개인정보와 거래 정보가 섞이는 오병합은 매우 큰 위험을 만들 수 있습니다.

16장. 정확도를 하나의 ‘매칭률’로만 보고하면 위험하다#

실제 동일인 쌍이 100개 있다고 하겠습니다.

자동 시스템이 동일인 후보를 80쌍 찾았습니다.

그중 실제 같은 사람이 72쌍입니다.

그러면:

True Positive
72

잘못 제안한 쌍:

False Positive
8

놓친 동일인:

False Negative
28

입니다.

17장. 매칭 정밀도를 계산해 보자#

자동으로 동일인이라고 제안한 80쌍 가운데 실제 동일인은 72쌍입니다.

Precision
=
72 / 80
=
90%

입니다.

즉 자동 제안한 10쌍 중 약 9쌍이 실제 동일인입니다.

18장. 재현율을 계산하면 다른 모습이 보인다#

실제 동일인 쌍은 100개입니다.

그중 시스템이 찾아낸 것은 72개입니다.

Recall
=
72 / 100
=
72%

입니다.

정밀도 90%만 보면 매우 좋아 보이지만 실제 동일인의 28%는 놓쳤습니다.

19장. 임계값을 높이면 오병합은 줄지만 미병합이 늘 수 있다#

자동 병합 기준을 매우 엄격하게 설정한다고 하겠습니다.

점수 0.99 이상만 자동 병합

오병합은 줄어들 가능성이 있습니다.

하지만 실제 같은 사람도 조건을 만족하지 못해 분리 상태로 남을 수 있습니다.

반대로 기준을 낮추면 더 많은 동일인을 찾지만 오병합 위험이 커질 수 있습니다.

높은 threshold
→ Precision ↑
→ Recall ↓ 가능

낮은 threshold
→ Recall ↑
→ Precision ↓ 가능

업무 비용에 따라 균형을 정해야 합니다.

20장. 골든 레코드는 단순히 가장 좋은 행 하나를 고르는 것이 아니다#

세 원천이 있습니다.

CRM

쇼핑몰

상담

골든 레코드를:

가장 최근 행 하나

로 정하면 매우 간단합니다.

하지만 속성별 신뢰도가 다를 수 있습니다.

예:

이름
→ CRM에서 본인 인증

주소
→ 쇼핑몰 배송 검증

전화
→ 상담 과정에서 고객이 직접 확인

따라서 골든 레코드는 여러 원천의 속성을 조합해서 만들 수 있습니다.

21장. 이것이 서바이버십 규칙이다#

서바이버십은 여러 후보 값 가운데 어떤 값이 대표값으로 살아남을지를 결정하는 규칙입니다.

예:

속성	규칙
이름	본인 인증 원천 우선
전화	고객 인증된 최신 번호
주소	배송 검증된 최신 주소
생년월일	신원 인증 원천만 허용
이메일	최근 본인 확인 값

모든 열에 같은 기준을 적용할 필요는 없습니다.

22장. “최신값 우선”만 사용하면 틀릴 수 있다#

앞의 데이터에서:

CRM
주소 서울
9월 1일

쇼핑몰
주소 부산
9월 5일

상담
주소 서울
9월 6일

입니다.

단순히 가장 최근 행을 고르면:

서울

이 됩니다.

하지만 상담 시스템의 9월 6일 변경은 전화번호만 확인하면서 행 수정 시각이 갱신된 것일 수 있습니다.

주소 자체를 확인한 것은 쇼핑몰의 9월 5일 부산입니다.

23장. 행 수정 시각과 속성 검증 시각은 다르다#

따라서 다음처럼 속성별 정보를 저장할 수 있습니다.

address = 부산

address_source = 쇼핑몰

address_verified_at = 2026-09-05

address_verification = 배송 검증

전화번호는 별도로:

phone = 010-9999-0000

phone_source = 상담

phone_verified_at = 2026-09-06

처럼 관리할 수 있습니다.

24장. 골든 레코드는 값뿐 아니라 근거를 가져야 한다#

좋은 골든 레코드는 다음처럼 단순하지 않습니다.

이름 = 김가람
주소 = 부산
전화 = 010-9999-0000

다음 정보까지 설명할 수 있어야 합니다.

어느 원천에서 가져왔는가?

언제 검증됐는가?

어떤 규칙이 선택했는가?

누가 승인했는가?

그래야 고객 문의가 들어왔을 때 이유를 설명할 수 있습니다.

25장. 골든 레코드 구조를 개념적으로 그려보면#

erDiagram
    GOLDEN_CUSTOMER ||--o{ SOURCE_CUSTOMER_MAP : links
    GOLDEN_CUSTOMER ||--o{ ATTRIBUTE_PROVENANCE : explains

    GOLDEN_CUSTOMER {
        string golden_id PK
        string display_name
        string phone
        string address
        string status
    }

    SOURCE_CUSTOMER_MAP {
        string golden_id FK
        string source_system
        string source_customer_id
        string match_rule_version
        string match_status
    }

    ATTRIBUTE_PROVENANCE {
        string golden_id FK
        string attribute_name
        string source_system
        string source_customer_id
        string selected_value
        timestamp verified_at
    }

핵심은 원천 ID와 선택 근거를 잃지 않는 것입니다.

26장. 원천 고객 ID를 삭제하면 되돌리기 어려워진다#

CRM 고객:

C-7

쇼핑몰 고객:

U-82

상담 고객:

K-19

을 골든 고객:

M-41

로 통합했다고 하겠습니다.

원천 ID를 없애고 모든 시스템을 M-41로 바꿔버리면 오병합 발견 시 원래 관계를 복원하기 어려워집니다.

27장. 원천과 골든 ID의 매핑을 보존하자#

예:

golden_id	source_system	source_customer_id
M-41	CRM	C-7
M-41	SHOP	U-82
M-41	CALL	K-19

여기에:

match_rule_version

evidence

approved_by

valid_from

valid_to

같은 정보를 추가할 수 있습니다.

28장. 매칭 규칙 버전을 남겨야 하는 이유#

2026년 1월 규칙:

이름 + 전화 완전 일치
→ 자동 병합

으로 운영했습니다.

오병합이 너무 많이 발생해 2026년 6월부터:

이름 + 전화
+
본인 인증 또는 추가 근거

가 필요하도록 변경했다고 하겠습니다.

병합 기록에 규칙 버전이 없으면 과거 고객이 왜 병합됐는지 알기 어렵습니다.

29장. 판단 증거도 기록해야 한다#

예:

C-17 ↔ S-82

후보의 증거:

이름 일치

전화 일치

주소 불일치

본인 인증 미확인

결정:

보류

이런 기록이 있으면 나중에 규칙을 바꿀 때 다시 검토할 수 있습니다.

30장. 현재 주소와 과거 배송지는 전혀 다른 데이터다#

현재 고객 주소:

부산

으로 변경됐습니다.

그렇다고 6개월 전 주문 배송지를:

서울
→ 부산

으로 바꾸면 안 됩니다.

과거 배송지는 당시 거래 사실입니다.

즉:

고객 마스터 현재 주소

와:

주문 당시 배송지

는 다른 데이터입니다.

31장. 마스터 데이터 업데이트가 거래 이력을 다시 쓰면 안 된다#

고객 전화번호도 마찬가지입니다.

현재 번호:

010-9999-0000

과거 주문 당시 연락처:

010-1111-2222

가 다를 수 있습니다.

주문 영수증이나 배송 이력에서 어떤 값을 보여줄 것인지 업무적으로 정해야 합니다.

MDM은 과거 거래 데이터를 무조건 최신 마스터값으로 덮어쓰는 시스템이 아닙니다.

32장. 고객 정보 하나에도 현재값과 역사값이 함께 존재한다#

다음처럼 생각할 수 있습니다.

현재 고객 연락처
→ 고객 마스터

주문 당시 연락처
→ 주문 스냅샷

주소 변경 이력
→ 고객 주소 이력

각각 사용 목적이 다릅니다.

마스터와 거래 이력을 구분하지 않으면 골든 레코드를 만들수록 과거 사실이 왜곡될 수 있습니다.

33장. 고객을 합치기 전에 거래 데이터의 연결 방식을 확인해야 한다#

C-17과 S-82를 M-41로 합쳤다고 하겠습니다.

CRM 상담은 C-17을 참조합니다.

쇼핑몰 주문은 S-82를 참조합니다.

통합 조회에서는 두 이력을 M-41 아래에서 보여줄 수 있습니다.

하지만 원천 주문의 고객 ID 자체를 모두 M-41로 물리적으로 변경할 필요는 없을 수 있습니다.

원천 식별자를 유지하면서 매핑을 통해 통합하는 편이 복구에 유리할 수 있습니다.

34장. MDM 구현 스타일은 수정 권한과 전파 방향을 결정한다#

대표적으로 네 가지 스타일을 설명할 수 있습니다.

Registry

Consolidation

Coexistence

Centralized Transaction

중요한 것은 이름보다:

중앙에서 무엇을 저장하는가?

누가 수정 권한을 가지는가?

변경이 어느 방향으로 전달되는가?

입니다.

35장. Registry 방식은 연결 인덱스를 중심으로 한다#

예:

CRM C-7
↘
 M-41
↗
SHOP U-82

중앙에서는:

두 ID가 같은 고객이다.

라는 연결 정보를 관리합니다.

실제 고객 상세값은 원천에서 읽을 수 있습니다.

장점:

원천 변경이 적음

통합 조회부터 시작하기 쉬움

단점:

원천 데이터 품질 문제는 그대로 남음

입니다.

36장. Consolidation 방식은 통합본을 만든다#

여러 원천에서 주기적으로 데이터를 수집합니다.

flowchart LR
    C["CRM"] --> H["통합 MDM"]
    S["쇼핑몰"] --> H
    K["상담"] --> H
    H --> A["분석·리포트"]

통합본은 분석에 유용할 수 있습니다.

다만 원천 변경이 다음 배치까지 반영되지 않을 수 있습니다.

37장. Coexistence 방식은 골든 값을 원천으로 되돌려 보낸다#

고객이 쇼핑몰에서 주소를 부산으로 수정했다고 하겠습니다.

MDM에서 이를 검증한 뒤 CRM에도 부산을 반영할 수 있습니다.

쇼핑몰
↓
MDM
↓
CRM

하지만 동시에 CRM에서 오래된 서울 값이 다시 들어오면 충돌합니다.

따라서:

누가 주소를 수정할 권한이 있는가?

버전은 무엇인가?

오래된 업데이트는 어떻게 막는가?

를 정해야 합니다.

38장. 중앙 거래 방식은 마스터 변경을 허브가 통제한다#

고객 생성과 수정 자체를 중앙 MDM을 통해 수행합니다.

flowchart TD
    A["고객 생성·변경 요청"] --> H["MDM Hub"]
    H --> C["CRM"]
    H --> S["쇼핑몰"]
    H --> K["상담"]

일관된 규칙을 적용하기 쉽습니다.

하지만 MDM 허브가 업무 처리 경로의 핵심 시스템이 됩니다.

가용성과 응답시간 요구도 높아집니다.

39장. 네 구현 스타일을 비교하면#

방식	중앙에 있는 것	주요 용도
Registry	연결 정보	통합 조회
Consolidation	복사·정제된 통합본	분석·보고
Coexistence	골든 레코드 + 동기화	여러 시스템 간 값 통일
Centralized Transaction	기준 데이터의 생성·변경	중앙 통제

실제 제품은 이 구분을 혼합해서 사용할 수도 있습니다.

40장. MDM에서 가장 까다로운 작업은 오병합 복구다#

C-17과 S-82를 M-41로 합쳤습니다.

며칠 뒤 실제로는 다른 사람이라는 사실이 확인됐습니다.

이미 다음 시스템으로 M-41이 전파되었습니다.

CRM

쇼핑몰

상담

데이터 웨어하우스

마케팅 시스템

단순히 M-41 행을 삭제한다고 문제가 해결되지 않습니다.

41장. 잘못 병합한 고객을 분리하는 첫 단계는 원천 연결을 복원하는 것이다#

기존:

M-41
├─ CRM C-17
└─ SHOP S-82

복구 후:

M-41
└─ CRM C-17

M-97
└─ SHOP S-82

처럼 분리할 수 있습니다.

어떤 원천 레코드가 어느 사람 것인지 다시 판정해야 합니다.

42장. 거래 데이터도 어느 원천 고객에서 왔는지 알아야 한다#

쇼핑몰 주문 O100은:

source_customer_id = S-82

에서 생성됐다고 하겠습니다.

CRM 상담 H200은:

source_customer_id = C-17

에서 발생했습니다.

원천 ID를 보존했다면 병합을 해제한 뒤:

O100
→ M-97

H200
→ M-41

로 다시 연결할 수 있습니다.

43장. 골든 ID만 저장했다면 분리 복구가 어려워진다#

모든 거래에서 원천 ID를 삭제하고:

customer_id = M-41

만 남겼다고 하겠습니다.

이제 M-41을 둘로 분리해야 합니다.

각 주문이 원래 C-17에서 왔는지 S-82에서 왔는지 알 수 없습니다.

결국 사람이 거래를 다시 조사해야 할 수 있습니다.

그래서 계보가 중요합니다.

44장. 잘못된 병합의 영향 범위를 먼저 계산해야 한다#

M-41이 다음 데이터를 연결하고 있다고 하겠습니다.

주문 1,240건

상담 98건

마케팅 발송 37건

쿠폰 사용 12건

오병합을 해제할 때는 단순 고객 행 하나가 아니라 이 연결 전체를 분석해야 합니다.

45장. 오병합 복구 절차를 정리하면#

flowchart TD
    A["오병합 발견"] --> B["기존 병합 근거 보존"]
    B --> C["원천 고객 다시 식별"]
    C --> D["골든 ID 분리"]
    D --> E["원천 ID 매핑 재연결"]
    E --> F["주문·상담 소속 재분류"]
    F --> G["파생 분석·캠페인 재계산"]
    G --> H["검증 후 완료"]

이 절차를 미리 설계해야 실제 사고에서 대응할 수 있습니다.

46장. 잘못된 병합 기록 자체도 삭제하지 않는 편이 좋다#

오류라고 해서 기록을 완전히 지우면 나중에 같은 규칙이 같은 실수를 반복할 수 있습니다.

예:

2026-09-10

C-17 ↔ S-82

rule = NAME_PHONE_EXACT_V1

결정 = MERGED

이후:

2026-09-15

결정 = SPLIT

사유 = FAMILY_SHARED_PHONE

처럼 판단 이력을 남길 수 있습니다.

47장. 다시 자동 병합되지 않게 차단 규칙이 필요할 수 있다#

두 고객을 사람이 어렵게 분리했습니다.

그런데 다음날 야간 자동 매칭이 다시:

이름 동일

전화 동일

을 보고 또 합쳐버리면 문제가 반복됩니다.

따라서:

C-17
와
S-82

자동 병합 금지

같은 예외 관계를 저장할 수 있습니다.

48장. 공유 연락처라는 사실 자체를 별도 정보로 관리할 수도 있다#

두 고객이 가족 공용 전화번호를 사용한다면:

고객 A
→ 전화번호 P

고객 B
→ 전화번호 P

관계를 유지하면서:

shared_contact = true

같은 의미를 관리할 수 있습니다.

이렇게 하면 같은 번호라는 이유만으로 다시 병합하는 것을 방지하기 쉽습니다.

49장. 골든 레코드도 단일 행만으로 표현할 필요는 없다#

고객이 여러 전화번호를 가지고 있을 수 있습니다.

현재 휴대전화

업무용 전화

과거 전화번호

주소도:

현재 거주지

기본 배송지

회사 주소

처럼 여러 값이 존재할 수 있습니다.

골든 레코드가 하나라고 해서 모든 속성이 반드시 하나의 값만 가져야 하는 것은 아닙니다.

50장. 대표값과 다중값을 구분해야 한다#

예:

primary_phone
→ 대표 연락 번호

phones
→ 고객이 보유한 전체 유효 번호

또는:

primary_address
→ 기본 주소

addresses
→ 배송지 목록

처럼 설계할 수 있습니다.

대표값 하나만 남기면 정보 손실이 발생할 수 있습니다.

51장. MDM에서 삭제도 단순 DELETE로 처리하기 어려울 수 있다#

고객이 탈퇴했다고 하겠습니다.

업무상:

로그인 계정 제거

가 필요합니다.

하지만 주문 기록은 법적·회계적 이유로 일정 기간 보존해야 할 수 있습니다.

또 MDM 매칭 이력도 감사나 오류 복구에 필요할 수 있습니다.

따라서:

계정 활성 상태

개인정보 보존 정책

거래 보존 정책

매칭 이력 보존

을 구분해야 합니다.

52장. 골든 레코드의 값이 모든 시스템으로 즉시 전파될 필요는 없다#

현재 주소가 부산으로 확정됐다고 하겠습니다.

CRM은 즉시 바꿔야 할 수 있습니다.

하지만 과거 주문 테이블에는 변경하지 않아야 합니다.

마케팅 분석 시스템은 다음 배치에 반영해도 될 수 있습니다.

즉 시스템마다:

실시간 전파

배치 전파

전파 금지

가 달라질 수 있습니다.

53장. 배포 실패도 MDM 품질 지표다#

MDM에서는 골든 값을 잘 계산했는데 CRM 전달이 실패했다고 하겠습니다.

골든:

주소 = 부산

CRM:

주소 = 서울

이면 사용자는 여전히 오래된 주소를 볼 수 있습니다.

따라서 골든 레코드 품질뿐 아니라:

전파 성공률

전파 지연

동기화 실패 건수

도 운영 지표로 볼 수 있습니다.

54장. MDM 운영 지표를 더 구체적으로 만들면#

다음과 같은 지표를 사용할 수 있습니다.

자동 병합 정밀도

자동 병합 재현율

수동 검토 대기 건수

오병합 신고 건수

평균 병합 해제 시간

출처 없는 골든 속성 수

전파 실패율

전파 지연 시간

단순히:

고객 95% 통합 완료

만 보고하는 것보다 훨씬 많은 정보를 줍니다.

55장. 고객 통합률이 높다고 품질이 좋은 것은 아니다#

고객 100만 명 가운데 99만 명을 자동 병합했다고 하겠습니다.

통합률 99%

매우 좋아 보입니다.

하지만 그중 1%가 오병합이면:

9,900건

입니다.

개인정보와 주문 이력을 섞는 사고가 거의 1만 건 발생할 수 있습니다.

따라서 통합률만으로 MDM 성능을 평가하면 위험합니다.

56장. 오병합 비용과 미병합 비용을 따로 측정해야 한다#

예:

오병합 비용#

잘못된 주문 연결

개인정보 노출

고객 불만

법적 문제

미병합 비용#

중복 쿠폰

고객 수 과대 계산

마케팅 중복 발송

고객 가치 분석 오류

업무에서는 두 비용의 크기가 다를 수 있습니다.

따라서 자동 병합 임계값도 업무에 따라 달라질 수 있습니다.

57장. 개인정보가 많다고 매칭 정확도가 무조건 좋아지는 것도 아니다#

매칭 정확도를 높이겠다는 이유로 모든 개인정보를 한곳에 모으면 보안·법적 위험도 증가합니다.

MDM에서는:

정말 필요한 식별 정보인가?

해시나 토큰으로 비교할 수 있는가?

누가 원문을 볼 수 있는가?

얼마나 오래 보관하는가?

도 함께 검토해야 합니다.

정확성만이 유일한 설계 목표는 아닙니다.

58장. 데이터 계보는 골든 레코드의 신뢰를 만든다#

골든 고객 M-41의 전화가:

010-9999-0000

이라고 하겠습니다.

사용자가 묻습니다.

왜 이 번호가 대표 전화입니까?

시스템이 다음처럼 답할 수 있어야 합니다.

원천
상담 K-19

확인 시각
9월 6일

검증 방식
본인 확인

적용 규칙
PHONE_VERIFIED_LATEST_V2

이것이 골든 레코드의 설명 가능성입니다.

59장. 마스터 데이터 변경 이력도 시간축이 필요하다#

현재 주소만 저장하면 과거에 어떤 주소였는지 알 수 없습니다.

예:

서울
2025-01-01 ~ 2026-09-04

부산
2026-09-05 ~ 현재

처럼 유효기간을 관리할 수 있습니다.

그러면 특정 시점의 고객 상태를 재구성할 수 있습니다.

60장. 속성 이력과 원천 이력은 둘 다 필요할 수 있다#

주소가 부산으로 변경됐습니다.

다음 두 질문은 다릅니다.

언제 부산 주소가 유효해졌는가?

언제 쇼핑몰이 부산 주소를 전달했는가?

하나는 업무 유효 시각입니다.

다른 하나는 시스템 수신 시각입니다.

데이터 계보에서는 둘을 구분하는 것이 유용할 수 있습니다.

61장. 동일인 여부가 불확실하면 억지로 골든 값을 만들지 않아도 된다#

상담 K-19가 C-7과 같은 사람인지 확신할 수 없다고 하겠습니다.

그런데 시스템이 무조건 모든 고객을 하나의 골든 레코드에 연결하도록 요구하면 잘못된 병합 가능성이 커집니다.

다음과 같은 상태를 둘 수 있습니다.

MATCHED

REVIEW_REQUIRED

REJECTED

SPLIT

확신이 없다는 사실도 데이터입니다.

62장. 병합 대기 상태에서는 거래까지 섞지 않는 것이 중요하다#

C-17과 S-82가 후보라고 하겠습니다.

아직 승인되지 않았습니다.

그런데 분석 시스템이 후보 단계부터 주문을 하나의 고객으로 묶는다면 실제 오병합과 비슷한 결과가 생깁니다.

따라서:

candidate match

와:

approved match

를 구분해야 합니다.

63장. MDM 전체 흐름을 정리하면#

flowchart TD
    A["원천 고객 수집"] --> B["정규화"]
    B --> C["후보 생성"]
    C --> D["매칭 점수·규칙"]
    D --> E{"자동 확정 가능?"}
    E -->|예| F["골든 ID 연결"]
    E -->|아니오| G["수동 검토"]
    G --> F
    F --> H["속성별 서바이버십"]
    H --> I["골든 레코드"]
    I --> J["다른 시스템 배포"]
    J --> K["품질·계보·오병합 모니터링"]

각 단계가 서로 다른 책임을 가집니다.

64장. 잘못된 병합까지 포함한 운영 흐름#

flowchart TD
    A["골든 고객 사용 중"] --> B["오병합 신고"]
    B --> C["병합 근거 확인"]
    C --> D["원천 ID 재판정"]
    D --> E["골든 고객 분리"]
    E --> F["주문·상담 연결 복원"]
    F --> G["파생 데이터 재계산"]
    G --> H["재병합 차단 규칙"]
    H --> I["감사 기록 보존"]

MDM의 완성도는 병합 기능보다 잘못된 병합을 안전하게 해제하는 능력에서 드러날 수 있습니다.

65장. MDM 설계 체크리스트#

마스터 데이터의 실세계 대상은 무엇인가?
동일인을 확정할 강한 식별자는 무엇인가?
공유되거나 재사용될 수 있는 식별자는 무엇인가?
후보 매칭과 확정 병합을 구분하는가?
자동 병합 조건은 무엇인가?
수동 검토 조건은 무엇인가?
병합 금지 조건은 무엇인가?
매칭 규칙 버전을 기록하는가?
각 병합의 증거를 저장하는가?
골든 속성별 원천을 기록하는가?
행 최신성과 속성 검증 시각을 구분하는가?
현재 마스터와 과거 거래 스냅샷을 구분하는가?
원천 ID를 삭제하지 않는가?
오병합을 해제할 수 있는가?
주문·상담 등 파생 연결을 복원할 수 있는가?
같은 두 고객이 다시 자동 병합되지 않게 할 수 있는가?
전파 실패와 지연을 모니터링하는가?
정밀도와 재현율을 별도로 측정하는가?
개인정보 접근 권한과 보존 기간을 관리하는가?
골든 값의 선택 이유를 설명할 수 있는가?

66장. 핵심 정리#

MDM의 목적은 여러 시스템의 고객 정보를 단순히 한 행으로 합치는 것이 아닙니다.

가장 먼저 해결해야 할 문제는:

서로 다른 레코드가 실제로 같은 사람을 의미하는가?

입니다.

이름과 전화번호가 같아도 가족의 공용 연락처일 수 있습니다.

반대로 전화번호가 달라도 번호를 바꾼 같은 고객일 수 있습니다.

따라서:

값이 같다
=
동일인

이라는 공식은 성립하지 않습니다.

매칭이 끝난 뒤에는 두 번째 질문이 있습니다.

여러 원천 값 가운데 어떤 값을 대표값으로 사용할 것인가?

이때 모든 속성에:

가장 최근 행

이라는 하나의 규칙을 적용하면 안 됩니다.

주소는 배송 검증 원천을 사용할 수 있고, 전화번호는 고객이 직접 인증한 원천을 사용할 수 있습니다.

즉 서바이버십은 속성별로 달라질 수 있습니다.

그리고 골든 레코드는 값만 보존해서는 부족합니다.

source_system

source_customer_id

match_rule_version

evidence

verified_at

approved_by

같은 계보가 있어야 왜 이 값이 선택됐는지 설명할 수 있습니다.

MDM에서 특히 중요한 것은 오병합 복구입니다.

두 고객 병합
↓
잘못된 병합 발견
↓
원천 ID 분리
↓
골든 ID 분리
↓
주문·상담 연결 복원
↓
파생 분석 재계산

이 과정이 가능하려면 원천 고객 ID와 거래의 출처를 삭제하지 않아야 합니다.

마지막으로 MDM 품질을:

통합률 95%

같은 숫자 하나로 평가하면 부족합니다.

최소한:

Precision

Recall

오병합 수

미병합 수

수동 검토 대기

병합 해제 시간

전파 실패율

을 함께 봐야 합니다.

좋은 골든 레코드는 가장 많은 정보를 한 행에 모은 결과가 아닙니다.

같은 대상을 식별한 근거, 각 값을 선택한 이유, 원천으로 거슬러 올라갈 계보, 잘못 합쳤을 때 다시 분리할 경로를 가진 기준 기록입니다.

MDM을 설계할 때 가장 중요한 질문은 두 가지입니다.

왜 이 두 고객을 같은 사람이라고 판단했는가?

그리고:

그 판단이 틀렸다는 것이 확인되면 주문과 상담 이력까지 원래 고객에게 되돌릴 수 있는가?

이 두 질문에 답할 수 있어야 골든 레코드가 단순한 통합 테이블을 넘어 실제 운영에서 신뢰할 수 있는 마스터 데이터가 됩니다.

MDM 골든 레코드 설계: 중복 고객 식별과 잘못된 병합 복구

1장. 전화번호가 같아서 합쳤더니 가족의 주문이 한 사람 것이 되었다#

2장. 반대로 같은 사람을 둘로 남기는 문제도 있다#

3장. MDM은 단순한 중복 제거 도구가 아니다#

4장. 동일인 판단과 대표값 선택은 반드시 분리해야 한다#

5장. 가장 먼저 해야 할 일은 고객을 합치는 것이 아니라 후보를 찾는 것이다#

6장. 이름은 강한 식별자처럼 보이지만 그렇지 않다#

7장. 전화번호도 완벽한 식별자는 아니다#

8장. 이메일도 동일한 문제가 있다#

9장. 매칭 규칙을 단계별로 나눌 수 있다#

자동 병합#

후보 검토#

병합 금지#

10장. 자동 병합 기준과 수동 검토 기준을 분리하자#

11장. 퍼지 매칭은 후보를 찾는 도구다#

12장. 매칭 점수와 동일인 확정을 혼동하면 안 된다#

13장. 매칭 전에 데이터 정규화가 필요할 수 있다#

14장. 주소도 그대로 비교하면 같은 주소를 다르게 판단할 수 있다#

15장. 고객 병합에는 오병합과 미병합이라는 두 종류의 비용이 있다#

오병합#

미병합#

16장. 정확도를 하나의 ‘매칭률’로만 보고하면 위험하다#

17장. 매칭 정밀도를 계산해 보자#

18장. 재현율을 계산하면 다른 모습이 보인다#

19장. 임계값을 높이면 오병합은 줄지만 미병합이 늘 수 있다#

20장. 골든 레코드는 단순히 가장 좋은 행 하나를 고르는 것이 아니다#

21장. 이것이 서바이버십 규칙이다#

22장. “최신값 우선”만 사용하면 틀릴 수 있다#

23장. 행 수정 시각과 속성 검증 시각은 다르다#

24장. 골든 레코드는 값뿐 아니라 근거를 가져야 한다#

25장. 골든 레코드 구조를 개념적으로 그려보면#

26장. 원천 고객 ID를 삭제하면 되돌리기 어려워진다#

27장. 원천과 골든 ID의 매핑을 보존하자#

28장. 매칭 규칙 버전을 남겨야 하는 이유#

29장. 판단 증거도 기록해야 한다#

30장. 현재 주소와 과거 배송지는 전혀 다른 데이터다#

31장. 마스터 데이터 업데이트가 거래 이력을 다시 쓰면 안 된다#

32장. 고객 정보 하나에도 현재값과 역사값이 함께 존재한다#

33장. 고객을 합치기 전에 거래 데이터의 연결 방식을 확인해야 한다#

34장. MDM 구현 스타일은 수정 권한과 전파 방향을 결정한다#

35장. Registry 방식은 연결 인덱스를 중심으로 한다#

36장. Consolidation 방식은 통합본을 만든다#

37장. Coexistence 방식은 골든 값을 원천으로 되돌려 보낸다#

38장. 중앙 거래 방식은 마스터 변경을 허브가 통제한다#

39장. 네 구현 스타일을 비교하면#

40장. MDM에서 가장 까다로운 작업은 오병합 복구다#

41장. 잘못 병합한 고객을 분리하는 첫 단계는 원천 연결을 복원하는 것이다#

42장. 거래 데이터도 어느 원천 고객에서 왔는지 알아야 한다#

43장. 골든 ID만 저장했다면 분리 복구가 어려워진다#

44장. 잘못된 병합의 영향 범위를 먼저 계산해야 한다#

45장. 오병합 복구 절차를 정리하면#

46장. 잘못된 병합 기록 자체도 삭제하지 않는 편이 좋다#

47장. 다시 자동 병합되지 않게 차단 규칙이 필요할 수 있다#

48장. 공유 연락처라는 사실 자체를 별도 정보로 관리할 수도 있다#

49장. 골든 레코드도 단일 행만으로 표현할 필요는 없다#

50장. 대표값과 다중값을 구분해야 한다#

51장. MDM에서 삭제도 단순 DELETE로 처리하기 어려울 수 있다#

52장. 골든 레코드의 값이 모든 시스템으로 즉시 전파될 필요는 없다#

53장. 배포 실패도 MDM 품질 지표다#

54장. MDM 운영 지표를 더 구체적으로 만들면#

55장. 고객 통합률이 높다고 품질이 좋은 것은 아니다#

56장. 오병합 비용과 미병합 비용을 따로 측정해야 한다#

오병합 비용#

미병합 비용#

57장. 개인정보가 많다고 매칭 정확도가 무조건 좋아지는 것도 아니다#

58장. 데이터 계보는 골든 레코드의 신뢰를 만든다#

59장. 마스터 데이터 변경 이력도 시간축이 필요하다#

60장. 속성 이력과 원천 이력은 둘 다 필요할 수 있다#

61장. 동일인 여부가 불확실하면 억지로 골든 값을 만들지 않아도 된다#

62장. 병합 대기 상태에서는 거래까지 섞지 않는 것이 중요하다#

63장. MDM 전체 흐름을 정리하면#

64장. 잘못된 병합까지 포함한 운영 흐름#

65장. MDM 설계 체크리스트#

66장. 핵심 정리#

이 페이지의 목차