속성마다 하나의 진실 원천

🌐 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)

AI로 생성한 이미지

AI로 번역했습니다. 아직 커뮤니티의 검토를 거치지 않았습니다. 영어로 읽기

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

이 모듈이 답하는 질문: “단일 진실 원천”은 실제로 무엇을 뜻할까요?

늘 듣는 말이 있습니다. “단일 진실 원천이 필요해요.” 좋습니다. 무엇에 대한? 고객? 충분히 구체적이지 않습니다. 계정 하나를 보십시오. 고객의 이름, 청구 주소, 신용 한도, 담당 영업 임원, 지원 등급, 마케팅 선호는 누가 소유합니까? 그 답들은 같은 시스템을 가리키지 않습니다. ERP가 법적 이름, 청구 주소, 신용 상태를, Salesforce가 관계 담당자와 영업 속성을, 다른 플랫폼이 동의를 통제할 수 있습니다. 그래서 누군가 “Salesforce가 고객에 대한 우리의 단일 진실 원천이에요”라고 하면 제 다음 질문은 이렇습니다. 어떤 진실이요?

진실은 속성에 속한다

마스터 데이터의 첫 번째 원칙은 이것입니다. 권한 원천은 레코드가 아니라 속성마다 정해진다. 계정이 Salesforce에 있어도 Salesforce가 그 모든 필드의 기준 시스템인 것은 아닐 수 있습니다. 레코드 하나의 필드 일곱 개, 권한 원천 둘:

속성	기준 시스템
법적 이름, 청구 주소, ERP 고객 ID, 신용 한도	ERP
담당 영업 임원, 전략 계정 플래그, 고객 성공 등급	Salesforce

레코드 하나, 진실은 분산되어 있습니다. 정상입니다. “기록 시스템 = Salesforce”로는 그것을 기술할 수 없습니다. 권한 원천 모델로는 할 수 있습니다.

만들어지고, 편집되고, 참조되는 곳, 그리고 얼마나 빨리?

마스터 데이터를 가르칠 때 저는 모든 중요한 데이터에 대해 같은 질문으로 계속 돌아옵니다. 어디서 만들어지는가, 어디서 편집되는가, 어디서 참조되는가, 그리고 변경 지연은 얼마인가? 이 질문들이 아키텍처를 빠르게 드러냅니다. (처음 세 가지는 4장에서 데이터의 종류를 분류하며 이미 만났습니다. 그 질문들이 진짜 일을 하는 곳은 여기입니다.)

자산을 예로 들어 보겠습니다. 한 고객이 자전거 세 대를 주문합니다. Salesforce에는 기회와 그 품목들이 있고, 주문은 ERP로 갑니다. ERP가 주문을 이행하고, 자산이 만들어지는 곳은 바로 거기입니다. 자전거 세 대, 일련번호 세 개가 Salesforce로 돌아옵니다. 몇 달 뒤 고객이 그중 한 대 때문에 전화하고, 지원팀은 케이스에서 그 자산을 참조합니다. 이제 누군가 속성 하나를 고쳐야 합니다. Salesforce가 어떤 속성을 편집해도 되고, 어떤 속성이 그것을 만든 ERP에 속할까요? 그리고 ERP가 하나를 바꾸면 Salesforce는 얼마나 빨리 알아야 할까요? 자산 하나, 질문 넷. 그리고 답은 필드마다 같지 않습니다.

법적 이름이 ERP에서 만들어지고 Salesforce에서 참조되는데, 영업 담당자가 그것이 틀렸다는 걸 알아차렸다고 합시다. Salesforce에서 고쳐야 할까요? 필드를 ERP가 소유한다면 사본을 바꿔도 아무것도 고쳐지지 않습니다. 잘해야 다음 동기화가 덮어쓰고, 최악이면 두 시스템이 이제 다르고 아무도 어느 쪽을 믿어야 할지 모릅니다. 비즈니스가 영업 담당자가 정정을 시작하기를 원한다면 이야기가 다릅니다. Salesforce가 경험을 제공하고, ERP에 요청을 보내고, ERP가 변경을 하거나 승인하고, 권위 있는 값이 돌아옵니다. Salesforce가 혼자 필드를 편집하게 두는 것과는 매우 다른 아키텍처입니다.

지연도 진실의 일부입니다. ERP가 오전 10시에 고객의 신용 상태를 바꿉니다. Salesforce는 매일 밤 동기화합니다. 오후 3시에 영업 담당자가 Salesforce를 봅니다. 값이 틀렸나요? 오래된 것입니다. 값이 1년에 한 번 바뀌고 하루 지연이 아무 비용도 없다면 야간 동기화로 충분합니다. 오늘 100만 달러짜리 주문을 받을지 결정하는 값이라면 아닙니다. 권한 원천은 진실이 어디서 오는지를 말하고, 지연은 다른 시스템이 그것이 바뀐 걸 얼마나 빨리 알아야 하는지를 말합니다. 두 개의 별개 결정입니다.

기록, 참여, 참조 시스템

4장의 어휘가 여기서 도움이 됩니다. 기록 시스템은 권위 있는 버전을 유지합니다. 참여 시스템은 사람들이 그것으로 일하는 곳입니다. 참조 시스템은 다른 시스템이 쓰지만 소유하지는 않는 데이터를 공급합니다. Salesforce는 고객 관계의 참여 시스템이면서, ERP는 법적·재무 속성의 기록 시스템으로 남을 수 있습니다. 그것은 아키텍처의 약점이 아니라 아키텍처 자체입니다. 실수는 다이어그램이 더 단순해 보이도록 한 시스템이 모든 것을 소유해야 하는 척하는 것입니다.

하이브리드 골든 레코드

그것이 “골든 레코드”의 뜻을 바꿉니다. 5장은 나쁜 데이터를 막는 이야기를 하며 이 개념을 소개했고, 여기서는 그것이 설계의 핵심입니다. 사람들은 모든 필드가 한곳에서 마스터로 관리되는 마법 같은 레코드 하나를 떠올립니다. 때로는 그것이 설계입니다. Salesforce에서 더 자주 보는 것은 하이브리드입니다. 계정의 일부는 다른 곳에서 마스터로 관리되어 복사되어 들어오고(법적 이름, ERP 고객 번호, 청구 주소, 신용 상태), 일부는 Salesforce에 필요해서만 존재합니다(담당 영업 임원, 기회 전략, 고객 성공 등급, 관계 메모). ERP 필드는 사람들이 쓸 수 있도록 들어옵니다. Salesforce 필드는 결코 돌아가지 않습니다. ERP는 그것에 관심이 없으니까요. 모두가 어느 것이 어느 것인지 아는 한 완전히 합리적입니다.

권한 원천을 보이게 하라

그래서 저는 외부 권한 원천을 스키마에서 분명하게 드러냅니다. SAP가 필드를 통제한다면 접두사를 붙입니다. sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. 4장의 erp_ 접두사와 같은 생각입니다. 그 권한이 구체적이고 안정적이면 시스템 이름을, 오늘의 공급업체보다 의미가 더 중요하면 일반적인 접두사를 쓰십시오. 요점은 6개월 뒤 모델을 읽는 누군가가 이것을 볼 수 있어야 한다는 것입니다. 이건 그냥 또 하나의 Salesforce 필드가 아니라, 다른 시스템이 이 값을 소유한다. 사람들이 연동을 거꾸로 분석해서 권한 원천을 다시 발견하게 만들지 마십시오.

기준 시스템 맵을 만들어라

중요한 마스터 데이터에 대해 저는 기준 시스템 맵을 원합니다. 핵심 속성마다 누가 만드는지, 누가 비즈니스 결정을 소유하는지, 어느 시스템이 기준 시스템인지, 누가 또는 무엇이 바꿀 수 있는지. 서로 다른 네 질문입니다.

속성	만드는 쪽	비즈니스 오너	기준 시스템	바꿀 수 있는 쪽
법적 이름	재무	재무	ERP	재무 프로세스
신용 한도	재무	재무	ERP	신용 팀
담당 영업 임원	영업 운영	영업	Salesforce	영업 관리자
지원 등급	서비스 운영	서비스	Salesforce	서비스 관리자
동의	고객	개인정보	동의 플랫폼	고객, 승인된 프로세스

비즈니스 오너와 기준 시스템이 같은 것이 아니라는 점에 주목하십시오. 시스템은 정책을 소유하지 않습니다. 사람이 소유합니다. 시스템은 결과를 저장하고 시행합니다. 다시 5장입니다. 오너는 정책을 정하고, 아키텍트는 그것을 시행한다.

Click to enlarge

고객 하나. 속성 여럿. 속성마다 권한 원천 하나.

권한 원천은 생명주기에 따라 바뀐다

영업 담당자가 ERP가 들어 본 적 없는 잠재 고객을 만나 Salesforce에 계정을 만듭니다. 그 시점에는 Salesforce가 이름, 주소, 연락처, 자격 평가의 기준 시스템입니다. 잠재 고객이 고객이 되고, ERP가 공식 고객을 만들어 고객 번호, 법적 이름, 청구 주소, 신용을 부여합니다. 권한 원천이 옮겨 갔습니다. Salesforce가 이전에 틀렸던 게 아닙니다. 생명주기가 바뀐 것입니다. 5장의 임시에서 관리됨으로 가는 패턴입니다. 전환 전에는 Salesforce가 잠재 고객을 소유하고, 전환 뒤에는 ERP가 관리되는 속성을 소유하며, Salesforce는 자기 속성을 계속 소유합니다. 그러니 “어느 시스템이 계정을 소유하나?”는 약한 질문입니다. 이렇게 물으십시오. 생명주기의 이 시점에, 어느 시스템이 이 속성을 소유하는가?

사본은 권위가 아니다

사람들이 늘 필요로 하니 ERP 데이터를 Salesforce에 복사합니다. 그러면 Salesforce는 편리한 로컬 사본이 되지 마스터가 되지는 않고, 아키텍처도 그에 맞게 동작해야 합니다. 사용자에게는 읽기 전용, 연동이 새로 고침, 출처 레이블, 요청을 통해서만 변경, 사본이 어긋나면 대사로 확인. 사본은 유용합니다. 권한 원천은 옮겨 가지 않았습니다.

신뢰에는 값 이상이 필요하다

“청구 주소: 123 Main Street.” 믿어야 할까요? 저는 신뢰 신호를 원합니다. 어디서 왔는지, 마지막으로 언제 확인됐는지, 어느 시스템이 공급했는지, 마지막으로 누가 또는 무엇이 바꿨는지. 사람인가, 연동인가, 에이전트인가? 이제 ERP는 123 Main Street, Salesforce는 125, 파트너 파일은 “123 Main St., Suite 200”이라고 합니다. 어느 것이 맞을까요? “가장 최근 것을 써요”라고 답하지 마십시오. 그럴 수도 있습니다. 하지만 “가장 최근”은 그 자체로 마지막에 바꾼 쪽이 이길 자격이 있다고 가정하는 규칙입니다. 맞을 수도, 끔찍할 수도 있습니다. 모듈 3에서 다룹니다. 신뢰는 채워진 필드를 찾는 데서가 아니라 권한 원천과 출처에서 나옵니다.

Steve Trucking: 누구의 진실인가?

리테일 파트너가 배송을 보내고, 그 거래 하나에 여러 진실이 숨어 있습니다. 파트너의 주문 참조는 파트너의 것입니다. Steve Trucking은 갱신을 매칭하려고 그것을 보관하지만 그 마스터가 되지는 않습니다. 배송 상태(도착, 배송 완료, 설치 완료, 예외)는 Steve Trucking의 것입니다. 파트너가 그것을 받지만, 상태를 받는다고 트럭에서 일어난 일의 기준이 되지는 않습니다. 그리고 수령인은 파트너의 고객입니다. Steve Trucking이 배송하려면 필요하니 파트너가 이름, 주소, 전화, 배송 메모를 공급합니다. 그렇다고 Steve Trucking이 그 사람의 정체성의 마스터가 되지는 않으며, 그 구분이 체크포인트에서 수령인 설계를 결정합니다.

Click to enlarge

배송 하나, 권한 원천 둘.

데이터가 있는 곳과 그 진실을 누가 소유하는지는 다른 질문입니다. Salesforce는 ERP 고객 번호를 소유하지 않으면서 가질 수 있고, Snowflake는 운영 마스터가 아니면서 배송 상태를 가질 수 있고, 고객 데이터 플랫폼은 모든 속성을 소유하지 않으면서 정체성을 통합할 수 있습니다. 에이전트는 셋 모두를 읽을 수 있고, 그렇다고 에이전트가 무엇이 참인지 정할 수 있는 것은 결코 아닙니다.

시험 너머: AI가 바꾸는 것. 에이전트는 속성별 권한 원천을 실행 규칙으로 바꿉니다. 사람은 잘못된 청구 주소를 보고 “이건 SAP에서 오는 거니 여기서 바꾸면 안 돼”라는 걸 압니다. “고객의 청구 주소를 갱신하라”는 지시를 받은 에이전트는 우리가 그렇게 설계하지 않는 한 모릅니다. 에이전트에게는 아키텍트가 가진 것과 같은 기준 시스템 맵이 필요합니다. 필드에 접근할 수 있다고 그 필드가 쓰기에 맞는 곳이 되지는 않습니다.

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

• 레코드 전체가 아니라 중요한 각 속성에 대해 어느 시스템이 기준 시스템인지.
• 각 속성이 어디서 만들어지고, 편집되고, 참조되며, 그 변경이 얼마나 빨리 전해져야 하는지.
• 각 속성의 정책을 누가 정하며, 어떤 사람, 연동, 에이전트가 그것을 바꿀 수 있는지.
• 외부 권한 원천이 모델에 어떻게 드러나는지: 이름 접두사, 권한, 연동 동작.
• 잠재 고객이 ERP 관리 고객이 되는 것처럼, 권한 원천이 생명주기에 따라 어떻게 옮겨 가는지.

단일 진실 원천은 org 하나, ERP 하나, MDM 플랫폼 하나, 거대한 레코드 하나를 뜻하지 않습니다. 관리되는 정보 하나하나에 대해 아키텍처가 권위 있는 값이 어디 있는지 말할 수 있고, 다른 모든 시스템이 그에 따라 어떻게 동작해야 하는지 안다는 뜻입니다. 단일 진실 원천이 아닙니다. 진실의 아키텍처입니다.

더 알아보기

• Salesforce Architects, Data 360 Architecture (opens in a new tab)(영어), 확인일 2026-10-14.