마스터 데이터와 정체성
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)
Data Architect 과정 6장의 학습 가이드입니다. 체크포인트 1 풀이를 포함해 먼저 여섯 개 모듈을 읽으십시오. 이 페이지는 무엇이 남았는지 점검하도록 돕습니다.
이 학습 가이드에 대해. 이 과정 자체의 내용과 Salesforce가 공개한 시험 가이드의 목표 목록만으로 만들었습니다. 실제 시험 문제를 바탕으로 한 적은 결코 없으며, 시험에 무엇이 나오는지 안다고 주장하지도 않습니다. 시험을 치렀다면 문제를 보내지 말아 주십시오. 자격 인증 계약이 공유를 금지하며, 어차피 답을 외우는 것은 아키텍트가 되는 잘못된 방법입니다.
이 장은 시험의 Master Data Management 영역(5%)과 Salesforce Data Management의 고객 단일 뷰를 맡습니다. 비중으로는 작은 영역이지만, 그 아이디어들(권한 원천, 매칭, 생존 규칙)은 다른 많은 시나리오 안에 나타납니다. 플랫폼 숫자는 바뀌니, 기대기 전에 현재 숫자를 확인하십시오.
시험 대비
섹션 제목: “시험 대비 ”하나씩 체크하십시오. 각 항목은 그것을 가르치는 곳으로 연결됩니다.
MDM-2: 골든 레코드와 진실의 시스템
- 권한 원천은 레코드가 아니라 속성마다 정해진다는 것을 압니다. 계정 하나에 ERP가 마스터인 필드와 Salesforce가 마스터인 필드가 함께 있을 수 있습니다. (진실은 속성에 속한다)
- 각 속성이 어디서 만들어지고, 편집되고, 참조되는지, 그리고 변경 속도를 묻습니다. (만들어지고, 편집되고, 참조되는 곳, 그리고 얼마나 빨리?)
- 기준 시스템 맵을 만들 수 있고, 비즈니스 오너와 기준 시스템이 같은 것이 아님을 압니다. (기준 시스템 맵을 만들어라)
- 권한 원천이 생명주기에 따라 바뀔 수 있고(Salesforce의 잠재 고객이 ERP가 관리하는 고객이 됨), 사본은 권위가 아니라는 것을 압니다. (권한 원천은 생명주기에 따라 바뀐다, 사본은 권위가 아니다)
MDM-1: MDM 기법
- 시험 포인트: 네 가지 MDM 구현 방식, 즉 레지스트리, 통합, 공존, 중앙 집중을 압니다. 각각이 무엇을 중앙에 모으는지, 값을 되돌려 보내는지까지. (넷을 나란히)
- 네 가지 MDM 방식, 레지스트리, 통합, 공존, 중앙 집중을 구별하고, 문제를 푸는 가장 가벼운 것을 고를 수 있습니다. (넷을 나란히)
- 표준(canonical) 데이터 모델은 구조를 조화시키지만 권한 원천을 정하지는 않는다는 것을 압니다. (공통 모델은 공통 진실이 아니다)
- 순서를 압니다. 조화하고, 매칭하고, 그다음 통합한다. (조화하고, 매칭하고, 그다음 통합하라)
- 임계값은 오류에 대한 허용도를 반영하고, 보강에는 출처가 필요하다는 것을 압니다. (임계값, 검토, 보강)
- 시험 포인트: 계층 관리를 압니다. 상위 계정이 계층을 만들고(Lightning 보기는 개인 계정 없이 최대 2,000개 계정을 보여 줌), 계층은 흔히 마스터가 나뉘어 있으며, 한 회사에 유효한 계층이 여러 개 있을 수 있습니다. (계층도 마스터 데이터다, 하나의 계층, 여러 마스터)
MDM-3: 이기는 속성 고르기
- 매칭, 병합, 생존 규칙을 구분합니다. (매칭, 병합, 생존 규칙)
- 생존 규칙, 가장 최근, 가장 빈번, 원천 우선순위를 알고, 모든 규칙에 오너가 필요하다는 것을 압니다. (생존 규칙: 어떤 값이 이기는가?)
- 매칭이 병합을 요구하지 않는다는 것을 알고, 분명한 승자가 있을 때만 병합하며, 하위 레코드에 무슨 일이 생길지 먼저 정합니다. (매칭이 병합을 요구하지는 않는다, 제 병합 규칙: 분명한 승자)
- 시험 포인트: Salesforce 계정 병합이 무엇을 하는지 압니다. 최대 레코드 세 개, 주 레코드 하나, 가장 오래된 Created By와 Created Date 유지, 나머지는 휴지통으로, 개인 계정의 연락 지점 개체는 병합되지 않음. (Salesforce 병합이 실제로 하는 일)
SDM-3: 고객 단일 뷰
- Data 360 ID 확인이 원천 프로필들을 통합 프로필로 연결하고 원천으로 돌아가는 연결을 유지한다는 것, 즉 레지스트리에 가장 가깝다는 것을 압니다. (ID 확인은 “누구?”에 답한다)
- 시험 포인트: Data 360 일치 규칙을 압니다. 한 규칙 안의 모든 기준이 일치해야 하고, 규칙은 어느 하나만 일치해도 됩니다. 정확성을 원하면 기준을 더, 통합을 원하면 덜. (일치 규칙)
- 일치 방법(Exact, Exact Normalized, 세 가지 정밀도의 Fuzzy)을 압니다. 덜 정밀한 방법은 통합률을 높이고, 잘못된 매칭의 위험도 높입니다. (일치 규칙)
- 시험 포인트: 조정 규칙(Last Updated, Most Frequent, Source Priority)이 통합 프로필이 보여 줄 것을 정하지만 원천을 바꾸지는 않으며, 연락 지점은 조정되지 않는다는 것을 압니다. (조정도 여전히 마스터 관리가 아니다)
- 일에 맞게 중복 관리, ID 확인, 전용 MDM 플랫폼 중에서 고를 수 있습니다. (세 가지 일에 세 가지 도구)
MDM-4와 양방향 데이터
- 양방향 데이터가 마스터가 둘이라는 뜻이 아님을 압니다. ERP가 소유한 필드를 Salesforce에서 편집하는 것은 요청이므로, 대기 상태를 둔 요청 → 검증 → 수락 → 게시로 설계합니다. (양방향 데이터가 마스터가 둘이라는 뜻은 아니다, 마스터가 거절할 때)
- 루프와 충돌을 피하는 법을 압니다. 변경을 일으킨 것과 그 메아리를 구별하고, 어떤 필드들이 하나의 트랜잭션으로 함께 움직이는지 정합니다. (루프와 충돌)
- 두 ERP에 있는 고객 하나에 대해, 고객사가 ERP들을 얼마나 잘 동기화하는지에 따라 계층, 동등 계정, 또는 ERP마다 하위 레코드를 둔 계정 하나 중에서 고를 수 있습니다. (고객 하나, ERP 둘, ERP들을 어떻게 동기화하는지 물어라)
체크포인트 1: 파트 1을 하나로 엮기
- 시험 포인트: 어떤 외부 라이선스가 표준 공유를 지니는지 압니다. Customer Community Plus와 Partner Community이며, 둘 다 외부 사용자에게 역할이 필요합니다. Customer Community는 공유 세트를 씁니다. (누가 무엇을 보고, 누구에게 라이선스가 필요한가)
시험 너머
섹션 제목: “시험 너머 ”시험은 바닥이지 천장이 아닙니다. 이것들은 시험 문제가 묻든 말든 아키텍트에게 필요한, 이 장의 습관입니다.
- “단일 진실 원천”: 어떤 진실? 레코드 하나가 아니라 진실의 아키텍처입니다.
- 스키마에서 권한 원천을 보이게 하라. 다른 시스템이 소유한 필드에는 접두사를.
- 신뢰에는 값 이상이 필요하다: 원천, 마지막 확인 시점, 누가 바꿨는지.
- MDM 제품이 아니라 문제에서 시작하라. MDM은 권한 원천에 대한 비즈니스 결정이다.
- 연결은 마스터 관리가 아니다.
- 잘못된 매칭의 비용이 큰 곳에서는 의도적으로 과소 매칭하라.
- 거슬러 올라가 추적해야 할 수 있다면 외부 적재에서 온 중복은 남겨 두라.
- 통합 프로필은 지도다. 골든 레코드는 결정이다.
- 표시는 권한이 아니다.
- 정체성을 통합한다고 보안 경계가 지워지지는 않는다.
- 가장 어려운 건 양방향 연동이다. 공유된 권한 원천이 아니라 모호한 권한 원천이 문제다.
- 거절된 요청이 경쟁하는 진실이 되게 두지 마라.
- 편집 가능 여부를 정하는 것은 레코드 유형이 아니라 이것이 마스터 데이터라고 말하는 필드다.
- 우리는 ERP를 통제하지 않는다. 우리가 통제하는 것은 Salesforce에서 그것을 어떻게 나타내느냐다.
알아야 할 용어
섹션 제목: “알아야 할 용어 ”| 용어 | 한 줄 설명 |
|---|---|
| 마스터 데이터 관리(MDM) | 시스템들에 걸쳐 핵심 데이터의 권위 있는 정체성과 값을 세우고 관리하는 것 |
| 기준 시스템 맵(authority map) | 속성마다: 누가 만들고, 누가 결정을 소유하고, 어느 시스템이 기준이며, 누가 바꿀 수 있는지 |
| 골든 레코드 | 어떤 값이 권위 있는지에 대한 관리되는 결정 |
| 하이브리드 골든 레코드 | 일부 속성은 다른 곳에서 마스터로 관리되어 복사되어 오고, 일부는 로컬에서 소유하는 레코드 |
| 레지스트리 | 원천을 바꾸지 않고 레코드들을 같은 엔터티로 연결하는 MDM |
| 통합(consolidation) | 보통 분석을 위해, 되돌려 보내지 않고 데이터를 중앙에서 합치는 MDM |
| 공존 | 마스터 값을 정하고 원천들에 되돌려 게시하는 MDM |
| 중앙 집중형 MDM | 관리되는 데이터가 마스터에서 만들어져 배포되는 MDM |
| 표준(canonical) 데이터 모델 | 한 개념에 대해 합의된 기업 차원의 형태로, 시스템들을 서로 매핑하는 데 쓰임 |
| 조화(harmonization) | 값을 비교 가능하게 만드는 것: 표준 형식, 코드, 약어 |
| 매칭 | 레코드들이 같은 대상을 나타내는지 정하는 것 |
| 생존 규칙(survivorship) | 원천들이 서로 다를 때 어떤 값이 이기는지에 대한 규칙 |
| 주 레코드(principal record) | Salesforce 병합에서 살아남아 자신의 숨겨진 필드와 읽기 전용 필드를 유지하는 레코드 |
| 일치 방법(match method) | Data 360 일치 기준이 값을 비교하는 방식: exact, exact normalized, fuzzy |
| ID 확인(identity resolution) | 원천 프로필들을 통합 프로필로 매칭하는 Data 360의 기능 |
| 통합 프로필 | 한 사람이나 회사를 나타내는 원천 레코드들을 연결하는 키의 묶음 |
| 조정 규칙 | 통합 프로필이 어떤 값을 보여 줄지에 대한 Data 360 규칙 |
| 마스터가 나뉜 계층 | 가지마다 다른 시스템이 소유하는 계층 |
스스로 점검하기
섹션 제목: “스스로 점검하기 ”과정의 스타일로 쓴 짧은 시나리오입니다. 열어 보기 전에 답을 정하십시오.
1. “Salesforce가 고객에 대한 우리의 단일 진실 원천입니다.” 무엇을 묻겠습니까?
어떤 진실인가요? 권한 원천은 속성마다 정해집니다. ERP가 법적 이름, 청구 주소, 신용 한도를 소유하고 Salesforce가 담당 영업 임원과 지원 등급을 소유할 수 있습니다. 기준 시스템 맵을 만드십시오. 진실은 속성에 속한다를 다시 읽으십시오.
2. 서비스 상담원이 Salesforce 연락처가 온라인에서 구매한 사람과 같은 사람이라는 걸 알아야 합니다. 시스템이 바뀔 필요는 아무에게도 없습니다. 어떤 MDM 방식일까요?
레지스트리입니다. 원천을 바꾸지 않고 레코드들을 하나의 정체성으로 연결하는 것으로, Data 360 ID 확인이 하는 일입니다. 문제를 푸는 가장 가벼운 패턴을 고르십시오. 레지스트리: 누가 누구인지 알려 달라를 다시 읽으십시오.
3. 생존 규칙이 모든 필드에 “가장 최근 값이 이긴다”로 설정되어 있습니다. 누군가 ERP가 소유한 법적 이름의 Salesforce 사본을 바꿉니다. 무슨 일이 일어나고, 무엇이 잘못되었을까요?
가장 새로운 값이 이기고, 사본이 권한 원천을 덮어씁니다. “가장 최근”은 신뢰에 대한 진술로, 어떤 속성(휴대폰 번호)에는 맞고 어떤 속성에는 맞지 않습니다. 기준 시스템 맵이 ERP가 그 필드를 소유한다고 하면 ERP가 이깁니다. 생존 규칙: 어떤 값이 이기는가?를 다시 읽으십시오.
4. 레거시 고객 레코드를 가져왔더니 기존 계정과 일치합니다. 병합할까요?
신중하십시오. 매칭이 병합을 요구하지는 않으며, 병합은 추적에 필요할 수 있는 레거시 ID와 이전 값을 파괴합니다. 분명한 승자가 있고 중복이 필요한 것을 아무것도 더하지 않는 경우가 아니라면 연결하십시오. 제 병합 규칙: 분명한 승자를 다시 읽으십시오.
5. Data 360의 통합 프로필이 Dallas를 보여 줍니다. 팀은 이제 Dallas가 모든 시스템의 골든 값이라고 합니다. 그럴까요?
아닙니다. 조정은 통합 프로필이 보여 줄 것을 정할 뿐, 원천을 바꾸거나 마스터 관리 결정을 내리지 않습니다. 모든 시스템이 관리되는 값 하나를 써야 한다면, 그것은 오너가 있는 공존 또는 중앙 집중형 MDM입니다. 조정도 여전히 마스터 관리가 아니다를 다시 읽으십시오.
6. 의료 기록 매칭과 마케팅 기록 매칭: 같은 규칙일까요?
아닙니다. 마케팅에서 잘못된 매칭은 엉뚱한 제안을 보내지만, 의료 데이터에서는 두 사람의 이력을 합칩니다. 틀렸을 때의 비용으로 엄격함을 정하고, 섞이는 비용이 큰 곳에서는 의도적으로 과소 매칭하십시오. 틀렸을 때의 비용을 다시 읽으십시오.
7. 영업 담당자들이 ERP가 소유한 청구 주소를 Salesforce에서 갱신하고 싶어 합니다. 어떻게 설계하겠습니까?
편집이 아니라 요청으로 설계합니다. Salesforce가 제안 값을 보내고, ERP가 검증하고 수락한 뒤 권위 있는 값을 돌려 게시합니다. 그때까지 대기 상태를 유지하고, 거절, 충돌, 메아리를 처리하십시오. 양방향 데이터가 마스터가 둘이라는 뜻은 아니다를 다시 읽으십시오.
8. Steve Trucking에서 같은 John Smith가 두 리테일 파트너의 배송 목록에 나타납니다. 통합할까요?
아니요, 의도적으로 하지 않습니다. 각 파트너는 다른 파트너의 수령인을 결코 보아서는 안 되고, 통합 정체성이 정보가 새는 다리입니다. 섞이는 비용이 큰 곳에서는 의도적으로 과소 매칭하십시오. 파트너가 반복 수령인 인식을 원한다면 그 파트너로만 범위를 한정하십시오. 파트너를 넘어 수령인을 통합할 것인가?를 다시 읽으십시오.
9. 영업 담당자가 ERP가 소유한 주소의 새 도로명을 보내는데, 같은 순간 ERP에서 누군가 도시를 바꿉니다. 무엇을 결정하겠습니까?
주소가 하나의 트랜잭션으로 움직이는지입니다. 그렇다면 필드들은 모두 함께 가거나 아무것도 가지 않으며, 그사이 주소가 바뀌었으므로 요청은 거절됩니다. 첫 충돌 전에 그것을 정하고, 요청은 ERP의 값을 바꾸는 것이 아니라 바꿔 달라고 요청하는 것임을 기억하십시오. 루프와 충돌을 다시 읽으십시오.
10. 한 고객사에 두 ERP에 걸쳐 있는 고객이 하나 있고, 아무도 두 레코드를 동기화하지 않습니다. 영업은 계정 하나를 원합니다. 무엇을 권하겠습니까?
계정 하나는 아닙니다. 자기 ERP에서도 레코드를 동기화하지 못한다면 Salesforce가 대신 해 줄 수 없습니다. 동등 계정이나 계층으로 나타내고, 영업이 이미 아는 구조를 보여 주십시오. ERP마다 하위 레코드를 둔 계정 하나는 공유 값을 동기화하는 고객사여야 가능합니다. ERP들을 어떻게 동기화하는지 물어라를 다시 읽으십시오.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-09-25): 공식 목표 목록과 그 비중. 시험을 예약하기 전에 항상 최신 버전을 확인하십시오.
- 각 모듈의 더 알아보기 섹션에는 그 사실의 근거가 된 Salesforce 문서가 확인 날짜와 함께 나와 있습니다.