연결은 마스터 관리가 아니다
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: 데이터 아키텍트 되기. 이전: 데이터 품질과 거버넌스.
“단일 진실 원천이 필요해요.” 아키텍처에서 가장 많이 반복되고, 가장 덜 따져 보는 말 중 하나입니다. 무엇에 대한? 계정 하나를 보십시오. ERP가 법적 이름, 청구 주소, 신용 한도를 소유하고, Salesforce가 담당 영업 임원과 지원 등급을, 동의 플랫폼이 마케팅 선호를 소유할 수 있습니다. 레코드 하나에 권한 원천이 셋이고, 그건 정상입니다. 그래서 누군가 “Salesforce가 고객에 대한 우리의 단일 진실 원천이에요”라고 하면 제 다음 질문은 늘 이렇습니다. 어떤 진실이요?
이 장은 그 질문에 의도적으로 답하는 것에 관한 것입니다. 권한 원천은 속성 하나하나마다 정해집니다. 레코드를 연결하는 것은 마스터로 관리하는 것이 아닙니다. 그리고 Salesforce는 일마다 다른 도구를 줍니다. org 하나 안에서는 중복 관리와 병합, 원천들에 걸친 단일 뷰를 위해서는 Data 360 ID 확인, 값을 한 번 정해 모든 곳에 되돌려 보내야 할 때는 전용 MDM 플랫폼. 그리고 파트 1이 Steve Trucking에서 하나로 모이는 체크포인트 1로 끝납니다.
AI로 생성한 이미지입니다.
이 장의 입장들
섹션 제목: “이 장의 입장들 ”- 속성마다 진실이 하나. 각 데이터가 어디서 만들어지고, 편집되고, 참조되는지, 그리고 얼마나 빨리 변하는지 물어라.
sap_나erp_같은 시스템 접두사로 외부 권한 원천을 스키마에 드러내라. - 잠재 고객은 다르다. ERP가 알기 전에 Salesforce에 있고, ERP의 권한은 전환 뒤에 적용된다.
- Salesforce 프로젝트에서는 레지스트리가 표준이다. 그다음 통합과 공존이고, 순수 중앙 집중형 MDM은 드물다.
- 분명한 승자가 있을 때만 병합하라. 거슬러 올라가 추적해야 할 수 있다면 외부 적재에서 온 중복은 남겨 두라. 병합은 그 이력을 파괴한다. 그리고 하위 레코드에 무슨 일이 생길지 정하라. 옮기거나, 적재하지 않거나, 비활성 레코드에 남겨 두라.
- 통합 프로필은 지도이고, 골든 레코드는 결정이다. 사람들이 혼동하기 쉬운 부분이다. ID 확인은 통합된 개인을 만들지만, 골든 레코드를 만들지는 않는다.
- 매칭의 엄격함은 위험 결정이다. 섞이는 비용이 크다면 의도적으로 과소 매칭하라.
- 세 가지 일에 세 가지 도구: 병합, ID 확인, MDM.
- 계층은 마스터가 나뉜다. 가지마다 권한 원천을 정하라.
- “가장 어려운 건 양방향 연동이다.” 양방향 연동이 마스터 둘을 만들지는 않는다. 첫 충돌이 일어나기 전에 어떤 필드들이 하나의 트랜잭션으로 함께 움직이는지 정하라.
- 마스터 데이터를 보이게 하라. 편집 가능 여부를 정하는 것은 레코드 유형이 아니라, 이것이 마스터 데이터라고 말하는 필드(ERP의 키나 플래그)다.
- 우리는 ERP를 통제하지 않는다. 우리가 통제하는 것은 Salesforce에서 그것을 어떻게 나타내느냐다. 두 ERP에 있는 고객 하나는 계층, 동등 계정, 또는 ERP마다 하위 레코드를 둔 계정 하나로 나타내며, 고객사가 ERP들을 얼마나 잘 동기화하는지에 따라 정한다.
세 가지 일에 세 가지 도구
섹션 제목: “세 가지 일에 세 가지 도구 ”| 일 | 도구 | 원천에 하는 일 |
|---|---|---|
| 분명한 승자가 있는 org 내부 중복 | 중복 관리와 병합 | 레코드를 최대 셋까지 병합하고, 나머지는 휴지통으로 |
| 원천들에 걸친 하나의 정체성과 단일 뷰 | Data 360 ID 확인 | 연결하되 어느 것도 바꾸지 않음(레지스트리) |
| 관리되는 값 하나를 모든 시스템에 되돌려 보내기 | 전용 MDM 플랫폼 | 값을 정하고 배포함(공존 또는 중앙 집중) |
이 장의 길
섹션 제목: “이 장의 길 ”여섯 개 모듈과 도전 과제 하나, 각각 독립적으로 읽을 수 있습니다.
- 속성마다 하나의 진실 원천. 기준 시스템 맵, 하이브리드 골든 레코드, 신뢰 신호.
- 마스터 데이터를 관리하는 네 가지 방법. 레지스트리, 통합, 공존, 중앙 집중, 그리고 공통 모델이 공통 진실이 아닌 이유.
- 매칭, 병합, 생존 규칙. 잘못된 매칭의 비용, Salesforce 병합이 실제로 하는 일(그리고 하위 레코드에 일어나는 일), 그리고 신뢰에 관한 진술로서의 생존 규칙.
- 지도는 결정이 아니다. 일치 규칙과 일치 방법, 조정 규칙, 그리고 통합 프로필이 골든 레코드가 아닌 이유.
- 권한 원천이 공유될 때. 요청과 갱신, 루프와 충돌, 마스터가 나뉜 계층, 그리고 두 ERP에 있는 고객 하나.
- 체크포인트 1 도전 과제, 그다음 체크포인트 1: Steve Trucking, 내가 설계한다면. 도전 과제부터 하십시오. 파트 1 설계를 그리고 변호한 다음, 제 것과 비교하고, 4장의 랜드스케이프에서 무엇이 바뀌는지 보십시오.
다 읽었다면 장 학습 가이드로 스스로 점검하십시오. 시험 대비 체크리스트, 시험 너머의 습관, 알아야 할 용어, 그리고 몇 가지 질문이 있습니다. 파트 1을 마무리하며, 파트 1 학습 가이드가 여섯 장을 모두 묶어 줍니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 중요한 각 속성에 대해 어느 시스템이 기준 시스템인지, 그리고 그것이 모델에 어떻게 드러나는지.
- 각 데이터 영역에 어떤 마스터 관리 방식이 맞는지, 그리고 마스터 관리 층이 얼마나 많은 권한을 갖는지.
- 언제 병합하고 언제 연결할지, 그리고 각 생존 규칙을 누가 소유하는지.
- 매칭을 얼마나 엄격하게 할지, 잘못된 매칭의 비용에 따라.
- 양방향 데이터와 공유된 계층에 어디서 명시적 경계가 필요한지.
시험 너머: 에이전트에게는 행동할 대상인 하나의 정체성이 필요하고, 그것이 판돈을 양쪽으로 올립니다. 과잉 매칭은 개인정보 사고가 되고, “고객을 갱신하는” 에이전트는 통합 프로필이 아니라 각 속성의 기록 시스템에 써야 합니다. 각 모듈은 AI가 바꾸는 것으로 끝납니다.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce Architects, Data 360 Architecture (opens in a new tab)(영어), 확인일 2026-10-14.
- Salesforce 도움말, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab), Identity Resolution Reconciliation Rules (opens in a new tab)(영어), 확인일 2026-10-14.
다음: 파트 2는 규모를 위한 설계 *(coming soon)*로 시작합니다.