콘텐츠로 이동
SteveTechArcSteveTechArc Courses

지도는 결정이 아니다

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)

A road map spread on a table by a window, and outside, a single blank signpost at a fork in the lane pointing one way.
AI로 생성한 이미지

Data Architect 과정 6장인 마스터 데이터와 정체성의 모듈 4/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 매칭, 병합, 생존 규칙 · 다음: 권한 원천이 공유될 때

이 모듈이 답하는 질문: 통합 프로필은 골든 레코드와 같은 것일까요?

같은 고객이 세 시스템에 있습니다. Salesforce는 Daniel Reyes, d.reyes@example.com, Dallas를 압니다. 이커머스는 Dan Reyes, 같은 이메일, Dallas, TX를 압니다. 지원 시스템은 Daniel Reyes, 214-555-0100, Dallas를 압니다. Data 360이 셋 모두 같은 사람이라고 판단하고 통합 프로필을 만듭니다. 훌륭합니다. 골든 레코드가 생겼을까요? 꼭 그렇지는 않습니다. 레코드들이 함께 속한다는 건 압니다. 어느 원천이 진실을 소유하는지는 정하지 않았습니다. 사람들이 혼동하기 쉬운 부분입니다. ID 확인은 통합된 개인을 만들지만, 골든 레코드를 만들지는 않습니다. 그래서 저는 그 차이를 정면으로 가르칩니다.

통합 프로필은 지도다. 골든 레코드는 결정이다.

ID 확인은 “누구?”에 답한다

섹션 제목: “ID 확인은 “누구?”에 답한다 ”

ID 확인이 없으면 한 사람이 서로 끊긴 프로필들로 나타납니다. 마케팅은 하나를, 영업은 또 하나를, 서비스는 또 하나를 봅니다. Data 360은 그것들을 수집하고 ID 확인 규칙으로 어떤 것들이 함께 속하는지 정합니다. 그러면 이 레코드들은 같은 사람으로 보인다고 말할 수 있습니다. 그것이 정체성을 풉니다. 마스터 관리를 풀지는 않습니다.

그리고 통합 프로필은 원천으로 돌아가는 지도를 유지합니다. Salesforce 자체의 설명으로도 통합 프로필은 골든 레코드가 아닙니다. 키의 묶음이고, ID 연결 개체가 각 원천 레코드의 ID를 통합 프로필의 ID에 묶습니다(Data 360 Architecture (opens in a new tab)). 통합된 사람 10042는 Salesforce 연락처 003…, 이커머스 고객 EC-48372, 지원 고객 SUP-9128에 매핑됩니다. 원본은 사라지지 않습니다. 모듈 2의 레지스트리에 아주 가깝습니다.

통합 프로필은 원천으로 돌아가는 지도다 가운데에 키의 집합으로 설명된 통합 프로필 10042가 있습니다. 원천 레코드 세 개가 각각 ID 연결로 여기에 이어집니다. Salesforce에 남는 Salesforce 연락처 003…, 이커머스에 남는 이커머스 고객 EC-48372, 지원 시스템에 남는 지원 고객 SUP-9128입니다. 아래: ID 확인은 레코드를 연결할 뿐, 레코드를 옮기거나 바꾸거나 이기는 값을 고르지 않습니다. ID 연결 ID 연결 ID 연결 Salesforce 연락처 003… Salesforce에 남음 통합 프로필 10042 키의 집합 이커머스 고객 EC-48372 이커머스에 남음 지원 고객 SUP-9128 지원 시스템에 남음 ID 확인은 레코드를 연결합니다. 레코드를 옮기거나, 바꾸거나, 이기는 값을 고르지 않습니다. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

통합 프로필은 원천 정체성들로 돌아가는 지도다.

일치 규칙: 엄격함은 위험 결정이다

섹션 제목: “일치 규칙: 엄격함은 위험 결정이다 ”

Data 360은 누구를 통합할지 어떻게 정할까요? 일치 규칙입니다. 프로필들은 한 규칙의 모든 기준을 충족할 때 일치하고, 규칙이 여럿이면 어느 하나라도 일치하면 통합 프로필이 생깁니다. Salesforce 자체의 권고는 이렇습니다. 정확도를 위해서는 기준을 더 많이(더 구별되는 프로필), 통합을 위해서는 더 적게(Identity Resolution Match Rules (opens in a new tab)). 그러니 규칙에 기준을 더하면 더 엄격해지고, 대안 규칙을 더하면 프로필이 일치할 수 있는 길이 넓어집니다. ID 확인을 구성하는 것은 “매칭을 켜는 것”이 아닙니다. 이 프로필들이 한 사람이라고 말하기에 충분한 증거가 무엇인지 정의하는 것입니다.

매칭이 많을수록 자동으로 좋은 것은 아닙니다. 원천 프로필 1,000만 개가 통합 프로필 800만 개가 됩니다. 규칙을 느슨하게 하니 이제 600만 개입니다. 더 나아진 걸까요? 중복을 더 찾았을 수도 있습니다. 아니면 서로 다른 사람들을 합치기 시작했을 수도 있습니다. 숫자가 작다고 데이터가 더 좋다는 증거는 아닙니다. 목표는 가장 적은 프로필이 아니라 목적에 가장 잘 변호할 수 있는 정체성입니다. 그리고 각 기준에는 일치 방법이 있습니다. Exact, Exact Normalized, 또는 높음·중간·낮음 정밀도의 Fuzzy. 요점은 Salesforce 자신의 경고에 있습니다. 덜 정밀한 방법은 통합률을 높이지만 “원치 않는 매칭이 생길 수 있습니다.” (Fuzzy는 Account 필드에는 쓸 수 없고, 정규화된 값은 비교에만 쓰일 뿐 통합 프로필에 저장되지 않습니다. 모듈 3의 조화 단계가 작동하는 모습입니다. Identity Resolution Match Methods (opens in a new tab).) 방법이 느슨할수록 정체성 자체가 판단이 됩니다. 그것이 틀리면 페이지 개인화를 조금 잘못하는 걸로 끝날까요, 아니면 한 사람에게 다른 사람의 지원 이력을 보여 주거나 에이전트가 두 사람의 데이터로 행동하게 될까요?

그것이 제 입장입니다. 매칭의 엄격함은 위험 결정이다. 매칭 필드가 사람을 얼마나 고유하게 식별하는지, 그리고 잘못된 매칭의 비용이 얼마인지에 달려 있습니다. 섞이는 비용이 큰 곳에서는 의도적으로 과소 매칭하십시오. 한 사람에게 프로필 둘은 불편합니다. 두 사람을 담은 프로필 하나는 위험할 수 있습니다.

조정도 여전히 마스터 관리가 아니다

섹션 제목: “조정도 여전히 마스터 관리가 아니다 ”

프로필이 통합되어도 원천들은 여전히 다릅니다. Salesforce는 Dallas, 이커머스는 Plano, 지원은 Dallas라고 합니다. 통합 프로필은 무엇을 보여 줄까요? 조정 규칙이 정합니다. Last Updated, Most Frequent, Source Priority를 개체별로 설정하고 필드별로 재정의할 수 있습니다(Identity Resolution Reconciliation Rules (opens in a new tab)). 모듈 3의 생존 규칙처럼 들릴 겁니다.

여기서 팀들이 곤란해집니다. 통합 프로필이 Dallas를 보여 주자 누군가 “좋아요, Dallas가 우리의 골든 값이에요”라고 합니다. 속도를 늦추십시오. 이커머스는 여전히 Plano라고 합니다. Salesforce는 조정이 원천 데이터를 지우거나 바꾸지 않고 원천 시스템을 갱신하지도 않는다고 명시하며, 모든 애플리케이션을 위한 “최선의” 값을 고르기 위한 것도 아닙니다. 통합 프로필이 무엇을 보여 줄지만 정합니다(같은 출처). 표시는 권한이 아닙니다.

시험 포인트. Data 360 ID 확인이 어떻게 결정하고 표시하는지 알아 두십시오. 일치 규칙에서는 모든 기준이 일치해야 하고, 어느 한 규칙이라도 일치하면 프로필이 통합됩니다(정확성을 원하면 기준을 더, 통합을 원하면 덜). 세 가지 조정 규칙은 Last Updated, Most Frequent, Source Priority로, 개체별로 설정하고 필드별로 재정의할 수 있습니다. 그리고 조정은 원천 데이터를 바꾸지 않으며, 연락 지점은 조정되지 않습니다.

연락 지점은 이 점을 더 분명히 보여 줍니다. 한 사람에게 개인 이메일과 업무 이메일, 휴대폰과 집 전화가 있을 수 있고, 모두 정당합니다. Data 360은 연락 지점을 전혀 조정하지 않습니다. 모든 이메일과 전화가 통합 프로필에 남습니다(같은 출처). 때로는 여러 값이 그냥 진실입니다. “통합”이 모든 것에 값 하나를 뜻하지는 않습니다.

골든 레코드는 결정이다

섹션 제목: “골든 레코드는 결정이다 ”

실제 마스터 관리 요구사항과 비교해 보십시오. 비즈니스는 법적 이름의 기준 시스템이 ERP이고, 마스터 값은 “Oakline Logistics LLC”라고 말합니다. Salesforce, 청구, 서비스 모두 그것을 써야 하고, 하나가 다르면 마스터 관리 프로세스가 관리되는 값을 되돌려 보냅니다. 다른 아키텍처입니다. 하나의 뷰가 무엇을 보여 줄지 고르는 게 아니라, 이것이 기업이 쓰는 값이고, 참여하는 모든 시스템이 그것으로 수렴한다고 정하는 것입니다.

그러니까 통합 프로필은 정체성과 정보를 한데 모읍니다. 골든 레코드는 어떤 값이 권위 있는지에 대한 관리되는 결정입니다. 통합 프로필은 권위 있는 원천들로 조립한 훌륭한 고객 단일 뷰가 될 수 있습니다. 그렇다고 고객을 마스터로 관리하는 시스템이 되지는 않습니다.

통합 프로필은 지도이고, 골든 레코드는 결정이다 두 열입니다. 지도인 통합 프로필은 Data 360 ID 확인에서 나옵니다. 원천에서는 Salesforce가 Dallas, 이커머스가 Plano, 지원이 Dallas라고 합니다. 프로필은 조정 규칙에 따라 Dallas를 보여 줍니다. 그 후에도 이커머스는 여전히 Plano라고 하고, 원천으로는 아무것도 돌아가지 않습니다. 결정인 골든 레코드는 MDM 프로세스에서 나오며, 강조되어 있습니다. 법적 이름은 ERP가 소유하며 Oakline Logistics LLC입니다. 이 값은 Salesforce, 청구, 서비스로 되돌려 보내지고, 모든 시스템이 이 값으로 수렴합니다. 소유자는 지정된 비즈니스 오너입니다. 아래: 보여 주는 것은 권한 원천이 아닙니다. 우리는 데이터를 통합했습니까, 아니면 마스터로 관리했습니까? 통합 프로필: 지도 Data 360 ID 확인 원천 Salesforce: Dallas 이커머스: Plano 지원: Dallas 프로필에 표시 Dallas, 조정 규칙에 따라 그 후 이커머스는 여전히 Plano 원천으로 아무것도 돌아가지 않음 골든 레코드: 결정 MDM 프로세스 결정 법적 이름은 ERP가 소유 Oakline Logistics LLC 그다음 Salesforce, 청구, 서비스로 되돌려 보냄 모든 시스템이 이 값으로 수렴 소유자 지정된 비즈니스 오너 보여 주는 것은 권한 원천이 아닙니다. 우리는 데이터를 통합했습니까, 아니면 마스터로 관리했습니까? © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

통합 프로필은 지도다. 골든 레코드는 결정이다.

추적 가능성

섹션 제목: “추적 가능성 ”

통합 프로필이 Dallas라고 한다면, 그건 어디서 왔을까요? Salesforce, ERP, 이커머스? 최종 갱신, 최빈값, 원천 우선순위 중 무엇으로 골랐을까요? 그 출처는 감사, 개인정보, 문제 해결, 데이터 품질 수정, 에이전트의 결정에 중요하고, 무엇보다 수정이 어디서 이루어져야 하는지 아는 데 중요합니다. Dallas가 틀렸다면 조립된 뷰를 편집해도 원천은 고쳐지지 않습니다. 바뀌어야 할 레코드까지 거슬러 올라가려면 외부 ID, ID 연결, 계보 필드가 필요합니다.

세 가지 일에 세 가지 도구

섹션 제목: “세 가지 일에 세 가지 도구 ”

저는 이렇게 구분합니다.

  1. 중복 관리와 병합, Salesforce org 하나 안에서, 분명한 승자가 있고 중복이 더는 필요 없을 때(모듈 3).
  2. Data 360 ID 확인, 원천을 바꾸지 않고 원천들에 걸친 하나의 정체성과 단일 뷰를 위해. 레지스트리입니다.
  3. 전용 MDM 플랫폼, 값을 한 번 정하고 참여하는 모든 시스템에 되돌려 보내야 할 때. 공존 또는 중앙 집중입니다.
세 가지 일에 세 가지 도구 번호가 매겨진, 세 가지 일에 세 가지 도구입니다. 1, 병합, 중복 관리와 병합: 할 일은 한 org 안의 중복입니다. 중복을 레코드 하나로 합치고 나머지는 휴지통으로 갑니다. 이기는 쪽이 분명하고 중복이 필요 없을 때 사용합니다. 2, 연결, Data 360 ID 확인: 할 일은 원천 전반의 ID 하나입니다. 레코드를 통합 프로필로 연결하고 원천은 그대로 둡니다. 단일 뷰가 필요할 때 사용하며, 레지스트리에 가장 가깝습니다. 3, 마스터 관리, 전용 MDM 플랫폼: 할 일은 모든 곳에 관리되는 값 하나입니다. 마스터 값을 결정하고 모든 시스템에 되돌려 보냅니다. 모든 시스템이 수렴해야 할 때, 공존 또는 중앙 집중형 MDM으로 사용합니다. 아래: 병합, 연결, 마스터 관리. 지도가 필요할 때 MDM을 사지 마십시오. 1 병합 중복 관리와 병합 할 일 한 org 안의 중복 하는 일 레코드 하나로 합침 나머지는 휴지통으로 사용 시점 이기는 쪽이 분명할 때 중복이 필요 없을 때 2 연결 Data 360 ID 확인 할 일 원천 전반의 ID 하나 하는 일 레코드를 통합 프로필로 연결 원천은 그대로 유지 사용 시점 단일 뷰가 필요할 때 레지스트리에 가장 가까움 3 마스터 관리 전용 MDM 플랫폼 할 일 모든 곳에 관리되는 값 하나 하는 일 마스터 값을 결정 모든 시스템에 되돌려 보냄 사용 시점 모든 시스템이 수렴해야 할 때 공존 또는 중앙 집중형 병합, 연결, 마스터 관리. 지도가 필요할 때 MDM을 사지 마십시오. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

세 가지 일에 세 가지 도구: 병합, 연결, 마스터 관리.

지도가 필요할 때 MDM을 사지 마십시오. “서비스 상담원이 이 Salesforce 고객이 온라인에서 구매한 사람과 같은 사람이라는 걸 알게 하고 싶다”에는 중앙 집중형 MDM이 아니라 ID 확인과 결합된 맥락이 필요할 수 있습니다. “ERP, Salesforce, 이커머스, 청구가 모두 같은 관리되는 법적 이름을 써야 하고, 변경은 그 모두에 돌아가야 한다”는 다릅니다. 그것은 마스터 관리입니다. 첫 번째 문제가 있을 때 두 번째를 풀지 말고, 첫 번째를 풀었다고 두 번째가 풀린 척하지 마십시오.

하나의 정체성이 하나의 권한은 아니다

섹션 제목: “하나의 정체성이 하나의 권한은 아니다 ”

ID 확인은 이 레코드들이 한 사람이라고 말합니다. 그렇다고 원천 레코드 하나를 볼 수 있는 모든 사람이 통합 정체성에 붙은 모든 것을 볼 수 있다는 뜻은 아닙니다. 리테일 파트너는 자기가 보낸 배송을 볼 수 있고, 같은 수령인에게 간 다른 파트너의 배송은 그 파트너가 알 바가 아닙니다. 정체성 층이 그것들이 관련되어 있다는 걸 알더라도요. 정체성 그래프는 맞으면서 접근 설계는 틀릴 수 있습니다. 정체성을 통합한다고 보안 경계가 지워지지는 않습니다. 그래서 과잉 매칭이 개인정보 문제가 되고, Steve Trucking 체크포인트가 수령인 통합을 그토록 신중하게 다루는 것입니다. 누가 누구인지의 지도는 소유권도 접근도 부여하지 않습니다.

시험 너머: AI가 바꾸는 것. 에이전트에게는 행동할 대상인 하나의 정체성이 필요하고, 통합 프로필이 그것을 줍니다. 그것이 판돈을 양쪽으로 올립니다. 과잉 매칭은 이제 개인정보 사고입니다. 한 사람을 위해 다른 사람의 데이터로 행동하는 에이전트. 그리고 “고객을 갱신하는” 에이전트는 모듈 1의 기준 시스템 맵을 써서, 통합 프로필이 아니라 그 속성의 기록 시스템에 써야 합니다. 지도는 에이전트에게 그 사람이 누구인지 알려 주고, 권한 원천 모델은 변경이 어디에 속하는지 알려 줍니다.

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

섹션 제목: “아키텍트가 여기서 결정하는 것 ”
  • 프로필을 통합하기에 충분한 증거가 무엇이며, 잘못된 매칭의 비용이 엄격함을 어떻게 정하는지.
  • 어떤 조정 규칙이 통합 프로필에 보여 줄 것을 정하는지.
  • 필요한 것이 org 하나 안의 중복 정리인지, 원천들에 걸친 정체성인지, 진짜 기업 차원의 마스터 관리인지.
  • Data 360이 조정된 값을 보여 줄 때도 각 속성에 대해 어느 원천이 여전히 기준인지.
  • 통합 정체성이 보안, 개인정보, 출처, 에이전트의 행동과 어떻게 상호작용하는지.

Data 360은 이 프로필들이 함께 속한다고 말해 주고, 통합 정체성을 주고, 보여 줄 것을 조정하고, 모든 원천으로 돌아가는 연결을 유지할 수 있습니다. 엄청난 가치입니다. 하지만 Salesforce가 하나를, ERP가 다른 것을 말한다면, 누군가는 여전히 어느 시스템이 기업의 진실을 바꿀 수 있는지 정해야 합니다. 그러니 누군가 “통합 프로필이 있으니 골든 레코드가 있다”고 하면 물으십시오. 우리는 데이터를 통합했나, 아니면 마스터로 관리했나?

더 알아보기

섹션 제목: “더 알아보기 ”