매칭, 병합, 생존 규칙

28개 언어로도 제공

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Two nearly identical brass keys side by side on a locksmith's bench, a loupe and a padlock beside them to compare the cuts. — AI로 생성한 이미지

Data Architect 과정 6장인 마스터 데이터와 정체성의 모듈 3/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 마스터 데이터를 관리하는 네 가지 방법 · 다음: 지도는 결정이 아니다

이 모듈이 답하는 질문: 중복을 어떻게 찾고, 어떤 값이 살아남을지 어떻게 정할까요?

Salesforce에 연락처가 둘 있습니다. Daniel Reyes, Dallas, d.reyes@example.com, 그리고 Dan Reyes, Dallas, d.reyes@example.com. 같은 사람일까요? 아마도요. 병합해야 할까요? 그건 다른 질문입니다. 그리고 병합한다면 어떤 전화번호, 주소, 직함이 살아남을까요? 또 다른 질문입니다. 아키텍트는 세 결정을 분리해 두어야 합니다.

매칭: 이 레코드들이 같은 것을 나타내는가?
병합: 하나의 레코드가 되어야 하는가?
생존 규칙(survivorship): 데이터를 합친다면 어떤 값이 이기는가?

매칭이 먼저다

3장에서 Salesforce의 중복 규칙과 일치 규칙을 다뤘으니 메커니즘은 다시 가르치지 않겠습니다. 아키텍처 질문은 **이것들이 같을 수도 있다고 말할 만큼 강한 증거는 무엇인가?**입니다. 사람이라면 이메일, 전화, 이름과 주소, 고객 번호, 그 조합. 회사라면 법적 이름, 사업자 번호, ERP 고객 ID, 주소, 웹 도메인. “Salesforce가 이 필드들을 비교할 수 있나?”가 아니라 “어떤 조합이 행동할 만큼의 확신을 주나?”입니다.

그리고 정확히 같다고 확실한 것은 아닙니다. 공유된 이메일은 강한 신호이지 증거가 아닙니다. 가족은 주소를 공유하고, 기업은 purchasing@company.com을 쓰고, 전화번호는 가구에 속하고, 이름과 주소는 고유하지 않으며, 강한 식별자도 재사용되고, 잘못 입력되고, 재활용됩니다. 매칭은 문자열 비교가 아닙니다. 정체성에 관한 진술입니다.

틀렸을 때의 비용

이걸 가르칠 때 저는 영역을 바꿉니다. 자동차 마케팅 데이터에서 Daniel Reyes 두 명을 같은 사람이라고 잘못 판단해, 엉뚱한 사람이 SUV 판촉을 받습니다. 좋지는 않지만 위험은 낮습니다. 이제 같은 잘못된 매칭을 의료 데이터에서 해 보십시오. 두 다른 사람의 진료 이력이 합쳐집니다. 같은 매칭 오류, 전혀 다른 결과. 그래서 보편적인 “좋은” 매칭 임계값은 없습니다. 때로는 매칭을 놓치는 것이 더 큰 위험이고, 때로는 같지 않은 두 사람을 합치는 것이 더 큰 위험입니다. 잘못된 매칭의 비용이 큰 곳에서는 저는 의도적으로 과소 매칭합니다.

조화하고, 매칭하고, 그다음 통합하라

매칭은 데이터의 모양에도 달려 있습니다. AZ, Arizona, Ariz.. 6025550198, (602) 555-0198, +1 602 555 0198. 조화(harmonization)는 값을 비교 가능하게 만듭니다. 표준 형식, 정규화한 약어, 매핑한 코드. 그다음 매칭합니다. 레코드들이 함께 속한다는 게 알려진 뒤에야 그 정보를 하나의 표현으로 통합합니다. 조화는 매칭이 아니고, 매칭은 병합이 아니며, 통합이 반드시 마스터 관리인 것도 아닙니다.

Click to enlarge

정체성 결정은 단계별로 이루어진다.

매칭이 병합을 요구하지는 않는다

이 장에서 가장 중요한 구분 중 하나입니다. 두 옛 시스템에서 온 고객 레코드 둘이 같은 회사라고 확신합니다. 병합해야 할까요? 아닙니다. 각각 원천 시스템의 정체성을 담고 있을 수 있고, 과거 거래가 각각을 가리킬 수 있고, 감사인이 추적 기록을 필요로 할 수 있고, 아직 마이그레이션 중일 수 있고, 옛 시스템이 정확히 무엇을 말했는지 알아야 할 수 있습니다. 두 레코드가 같은 것이라는 걸 안다고 그것들을 하나로 접어야 하는 건 아닙니다. 연결할 수 있고, 그것이 더 안전한 아키텍처인 경우가 많습니다.

제 병합 규칙: 분명한 승자

제 입장은 이렇습니다. 분명한 승자가 있고 중복에 보관할 필요가 있는 것이 아무것도 없을 때만 병합하라. 영업 담당자가 어제 중복 계정을 만들었고, 원본이 분명히 확립된 레코드입니다. 좋은 병합 후보입니다. 이제 바꿔 봅시다. 레거시 시스템에서 고객을 가져왔고, 그 시스템의 ID, 더 오래된 값, 어쩌면 거기 연결된 거래나 감사 요건이 있습니다. 저는 훨씬 조심스러워집니다. 더 오래된 값으로 거슬러 올라가 추적해야 할 수 있다면 외부 적재에서 온 중복은 남겨 두십시오. 병합은 그 이력을 파괴하니까요.

Salesforce 병합이 실제로 하는 일

연결은 “이것들은 함께 속한다”고 말합니다. 병합은 “이것들은 이제 하나다”라고 말하고, Salesforce에서 그것은 실제 변경입니다. 계정의 경우 레코드를 최대 셋까지 선택하고 하나를 기본 레코드로 고릅니다. 다른 레코드의 어떤 필드 값을 남길지 고르며, 숨겨진 필드와 읽기 전용 필드는 기본 레코드에서 옵니다. 병합된 레코드는 어느 것이 기본이든 가장 오래된 레코드의 생성자와 생성일을 유지합니다. 기본이 아닌 레코드는 휴지통으로 갑니다. 활동 같은 관련 레코드는 예외를 빼고 병합된 레코드로 옮겨 갑니다. Lightning에서 병합은 중복 규칙이 감지한 중복에 대해 작동합니다. 그리고 개인 계정의 경우 연락 지점 개체는 병합을 지원하지 않아 그 관계가 사라집니다(Considerations for Merging Duplicate Accounts (opens in a new tab), Merge Duplicate Accounts in Lightning Experience (opens in a new tab)).

시험 포인트. Salesforce 계정 병합이 무엇을 하는지 알아 두십시오. 레코드 최대 세 개, 숨겨진 필드와 읽기 전용 필드가 유지되는 주 레코드 하나, 어느 것이 주 레코드든 유지되는 가장 오래된 레코드의 Created By와 Created Date, 휴지통으로 가는 나머지 레코드, 그리고 개인 계정에서는 연락 지점 개체가 병합되지 않음.

결정하는 데 모든 예외 상황을 알 필요는 없습니다. 결과를 알아야 합니다. 병합 뒤에는 시작했던 독립된 레코드들이 사라진다. 1장의 가역성 테스트가 적용됩니다. 연결은 되돌리기 쉽고, 병합은 그렇지 않습니다. 그리고 고객은 혼자 있는 경우가 드뭅니다. 연락처, 케이스, 기회, 파일, 동의 레코드, 사용자 정의 하위 레코드, 외부 ID, 연동 참조. 상위를 병합하기 전에 거기 붙은 모든 것에 무슨 일이 생기는지 이해하십시오. 적재와 함께 중복이 들어오면 저는 팀에 하위 레코드에 대한 세 가지 선택지를 줍니다. 살아남는 레코드로 옮기기, 아무도 필요로 하지 않는다면 아예 적재하지 않기, 또는 다른 레코드에 비활성으로 표시해 남겨 두기. 그러면 검색에는 여전히 나타납니다. 첫 번째는 병합이 대신 해 주는 일입니다. 나머지 둘은 흔적을 남기고, 흔히 그것이 핵심입니다.

생존 규칙: 어떤 값이 이기는가?

레코드들은 함께 속하지만 서로 다릅니다. Salesforce와 청구는 602-555-0100, ERP는 602-555-0188이라고 합니다. 생존 규칙이 승자를 고릅니다. 흔한 것들은 가장 최근(마지막 갱신), 가장 빈번(가장 많은 원천이 동의하는 값), 원천 우선순위(이 원천을 저 원천보다 믿음)이고, 조합, 임계값, 가중치, 비즈니스 고유 규칙도 있습니다. 어느 것도 본질적으로 옳지 않습니다.

“가장 최근”은 기술 설정이 아닙니다. 신뢰에 관한 진술입니다. 시스템들이 다르면 가장 새로운 값이 맞을 가능성이 더 높다. 휴대폰 번호라면 합리적입니다. 법적 이름이라면 끔찍합니다. ERP가 소유한다면 누가 5분 전에 Salesforce 사본을 바꿨든 상관없습니다. “가장 빈번”은 일치가 증거라고 가정하지만, 오래된 하류 사본 셋이 기록 원천을 다수결로 이기지는 못합니다. “원천 우선순위”는 그것을 분명히 말합니다. 우리는 이 원천을 더 믿는다. 그래서 생존 규칙은 아키텍처와 거버넌스에 속하고, 모든 규칙에는 오너가 필요합니다. 가장 새로운 주소가 이긴다고, 또는 ERP가 Salesforce보다 앞선다고 누가 정했습니까?

모듈 1의 기준 시스템 맵이 이미 신용 한도는 ERP가 소유한다고 말한다면 생존 규칙은 쉽습니다. ERP가 이기고, 영리한 점수 계산은 필요 없습니다. 어려운 경우는 권한이 공유되거나, 불분명하거나, 마스터 하나가 아니라 증거에 기반한 속성입니다. 생존 규칙이 제 몫을 하는 곳이 거기입니다.

Click to enlarge

생존 규칙은 신뢰에 관한 진술이다.

임계값, 검토, 보강

어떤 매칭은 증거에 가중치를 둡니다. 고객 ID 일치는 매우 강하고, 이메일은 강하고, 전화는 중간, 비슷한 이름은 약하고, 비슷한 주소는 보조. 어떤 점수 위로는 매칭, 다른 점수 아래로는 다름, 그 사이는 사람이 검토합니다. 알고리즘이 교훈은 아닙니다. 임계값은 오류에 대한 허용치이고, 비즈니스 위험을 따라야 합니다. 그리고 증거가 질문을 던지기만 하고 답을 주지 못할 때 시스템이 안다고 가장하지 마십시오. 검토로 보내십시오. 더 느리지만 괜찮습니다. 서로 다른 두 고객을 자신 있게 병합하는 자동화는 가치가 없습니다.

보강(enrichment)은 출처에 관한 질문을 또 하나 더합니다. 우편 참조 데이터, 업종 코드, 기업 정보, 외부 위험 점수는 마스터 데이터를 개선하지만, 각 값은 어디서 왔고, 얼마나 믿을 만하고 최신이며, 이 목적에 써도 되고, 개인정보가 담겨 있나요? 데이터 제공업체가 준 “업종 = 운송”은 고객이 직접 말해 준 것과 같지 않습니다. 그 구분을 유지하십시오.

Steve Trucking: 비슷하다고 같은 것은 아니다

두 리테일 파트너가 같은 전화번호로 John Smith, 123 Main Street, Columbus에게 배송을 보냅니다. 같은 사람일까요? 아마도요. Steve Trucking이 그들을 통합해야 할까요? 그들이 누구의 것인지 기억하십시오. 그 수령인들은 파트너들의 고객이고, 한 파트너는 다른 파트너의 수령인을 절대 봐서는 안 됩니다. 잘못된 매칭은 그 경계를 넘어 데이터를 섞을 것입니다. 갑자기 데이터 품질 질문이 아니라 개인정보와 격리의 질문이 되고, 그래서 임계값이 결과에 달려 있는 것입니다. 결정은 체크포인트에서 합니다. 지금은 이것만. 매칭의 편리함이 비즈니스 결정을 내리게 두지 마십시오.

때로는 지저분함을 남기는 것이 무언가를 알려 줍니다. 이 레코드는 옛 시스템에서, 저것은 Salesforce에서, 이것은 인수한 회사에서 왔습니다. 그 ID들, 그 이력, 그리고 그것들이 서로 달랐다는 사실 자체가 모두 중요할 수 있습니다. 깨끗한 데이터는 가치가 있습니다. 추적 가능성도 그렇습니다. 그 용도에 무엇이 더 중요한지는 아키텍트가 정합니다.

시험 너머: AI가 바꾸는 것. 나쁜 매칭은 예전엔 이메일 두 통이나 둘로 갈라진 서비스 이력을 뜻했습니다. 이제 에이전트는 고객이라고 생각하는 대상을 찾아 그 주문, 케이스, 주소, 메모를 가져옵니다. 두 사람이 잘못 매칭되었다면 한 사람의 정보로 다른 사람을 위해 행동할 수 있습니다. 매칭 결정은 보안 경계의 일부가 되었고, 섞이는 비용이 큰 곳에서는 더 엄격한 매칭이 더 안전한 설계입니다.

아키텍트가 여기서 결정하는 것

각 데이터 영역에서 가능한 중복을 표시하기에 충분한 증거는 무엇인지.
확인된 매칭이 병합, 연결, 사람의 검토 중 무엇이 될지.
불일치에서 어떤 값이 살아남으며, 각 생존 규칙을 누가 소유하는지.
비즈니스가 놓친 매칭의 위험에 비해 잘못된 매칭의 위험을 얼마나 감수할 수 있는지.
어떤 병합이든 하기 전에 어떤 원천 정체성, 이력, 관련 레코드를 보존해야 하는지.

신중하게 매칭하고, 의도적으로 병합하고, 생존 규칙을 의식적으로 고르십시오. 잘못된 고객들을 합쳐서 얻은 깨끗한 고객 레코드는 별 가치가 없습니다.

더 알아보기

Salesforce 도움말, Considerations for Merging Duplicate Accounts (opens in a new tab), Merge Duplicate Accounts in Lightning Experience (opens in a new tab)(영어), 확인일 2026-10-14.
Salesforce 도움말, Things to Know About Duplicate Rules (opens in a new tab)(영어), 확인일 2026-10-14.