마스터 데이터를 관리하는 네 가지 방법
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장인 마스터 데이터와 정체성의 모듈 2/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 속성마다 하나의 진실 원천 · 다음: 매칭, 병합, 생존 규칙
이 모듈이 답하는 질문: 조직은 마스터 데이터를 어떻게 관리하며, 어떤 방식이 맞을까요?
모듈 1은 권한 원천이 속성 하나하나마다 정해진다고 했습니다. 이제 질문입니다. 그 속성들이 동시에 여러 시스템에 있으면 어떻게 할까요? 고객 정보가 Salesforce, ERP, 청구, 지원, 어쩌면 Data 360, 어쩌면 웨어하우스에 있고, 각자 자기 버전을 가지고 있습니다. 그것이 **마스터 데이터 관리(MDM)**가 풀려는 문제이고, MDM은 하나의 아키텍처가 아닙니다. 네 가지 패턴을 듣게 됩니다. 레지스트리, 통합, 공존, 중앙 집중. 제품 설정이 아닙니다. 하나의 질문에 대한 네 가지 답입니다. 마스터 관리 층은 얼마나 많은 권한을 갖는가?
제품이 아니라 문제에서 시작하라
섹션 제목: “제품이 아니라 문제에서 시작하라 ”사람들은 MDM이라는 말을 들으면 MDM 제품을 사러 다니기 시작합니다. 저는 문제에서 시작하겠습니다. 여러 레코드가 같은 고객이라는 걸 알기만 하면 되나? 분석을 위해 결합된 뷰 하나가 필요한가? 어떤 값이 권위 있는지 정해서 다른 시스템에 되돌려 보내야 하나? 아니면 모두를 위해 마스터 데이터를 만드는 중앙 시스템 하나를 원하나? 매우 다른 요구사항이고, 매우 다른 아키텍처입니다.
레지스트리: 누가 누구인지 알려 달라
섹션 제목: “레지스트리: 누가 누구인지 알려 달라 ”가장 가벼운 패턴입니다. 레지스트리는 원천을 대체하지 않습니다. ERP는 자기 고객을, Salesforce는 자기 계정을, 청구는 자기 고객을 유지하고, 레지스트리는 이 레코드들이 같은 엔터티를 나타낸다는 것을 알아냅니다. Salesforce 계정 001…, ERP 고객 SAP-43821, 청구 고객 BILL-9127은 한 고객에 속합니다. 원천은 제자리에 있고 덮어써지지 않습니다. 이제 “이 고객에 대해 우리가 아는 모든 것을 보여 줘”에 답이 있습니다.
하지만 레지스트리가 답하지 않는 것에 주목하십시오. Salesforce는 123 Main Street, ERP는 125, 청구는 “123 Main St., Suite 200”이라고 합니다. 레지스트리는 그것들이 함께 속한다는 걸 압니다. 어느 것이 바뀌어야 하는지는 정하지 않습니다. 연결은 마스터 관리가 아닙니다.
제 경험으로는 Salesforce 프로젝트에서는 레지스트리가 표준이고, 그다음 통합과 공존이며, 순수 중앙 집중형 MDM은 드뭅니다. 레지스트리가 흔한 것은 비침습적이기 때문입니다. 가치를 얻기 전에 모든 운영 시스템을 다시 설계할 필요가 없습니다. Salesforce는 하던 일을 계속하고, ERP도 하던 일을 계속하며, 정체성 층을 하나 더합니다. 모든 시스템에 “이제 당신은 고객 데이터를 통제하지 않고, 이 새 중앙 시스템이 통제한다”고 말하는 것보다 훨씬 작은 변화입니다.
레지스트리가 답하는 것: 어떤 레코드들이 같은 엔터티에 속하는가?
통합: 데이터를 한데 모아라
섹션 제목: “통합: 데이터를 한데 모아라 ”통합(consolidation)은 여러 원천의 데이터를 가져와 보고, 분석, 세분화, 고객 인텔리전스를 위한 중앙 표현으로 합칩니다. 익숙한 예가 웨어하우스입니다. Salesforce가 고객을, ERP가 재무를, 청구가 결제를 보내면, 비즈니스는 마침내 시스템 전반에 걸쳐 고객을 분석할 수 있습니다. 원천은 여전히 존재하고 여전히 권위 있을 수 있습니다. 방향이 중요합니다. 데이터는 통합 시스템으로 흘러들어가고, 그 시스템은 보통 마스터로 관리된 변경을 되돌려 보내지 않습니다. 운영상의 권한 원천이 되지 않으면서 고객의 더 나은 그림을 줍니다.
레지스트리와 통합은 헷갈리기 쉽습니다. 차이는 무엇을 중앙화하느냐입니다. 레지스트리는 정체성을 중앙화하고(“이것들은 함께 속한다”), 통합은 데이터를 더 많이 중앙화합니다(“속성을 모아서 쓸 수 있게 하자”). 어느 쪽도 “이 중앙 시스템이 이제 마스터이고 모든 애플리케이션이 그 값을 받아들여야 한다”고 말하지 않습니다.
통합은 원천에서 소유권을 빼앗지 않고 데이터를 한데 모은다.
공존: 정하고, 되돌려 보내라
섹션 제목: “공존: 정하고, 되돌려 보내라 ”공존(coexistence)에서는 마스터 관리 층이 실제 권한을 얻습니다. 데이터는 여전히 여러 운영 시스템에 있지만, MDM 프로세스가 마스터 값을 정해 되돌려 발행합니다. Salesforce, ERP, 청구가 각각 다른 법적 이름을 가지고 있으면, MDM 프로세스가 관리되는 이름을 정해 셋 모두에 배포합니다. 시스템들은 공존하지만, 마스터 값으로 수렴합니다.
훨씬 강한 형태의 MDM입니다. “이것들은 함께 속한다”가 아니라 **“이 속성에 대해 기업이 쓰는 값은 이것이다”**라고 말합니다. 그러려면 매칭 이상이 필요합니다. 비즈니스 규칙, 소유권, 생존 규칙, 양방향 연동, 오류 처리, 거버넌스. 누군가는 왜 한 값이 이기는지 정해야 하니까요.
공존은 레코드를 연결하기만 하지 않는다. 마스터 값을 정하고 되돌려 보낸다.
중앙 집중: 마스터가 진실을 만든다
섹션 제목: “중앙 집중: 마스터가 진실을 만든다 ”가장 강한 패턴입니다. 중앙 집중형 MDM에서는 관리되는 마스터 데이터가 중앙 마스터에서 만들어지고 유지되며 다른 모두에게 배포됩니다. 각 시스템이 자기 고객을 만들고 MDM이 나중에 맞추는 대신, 관리되는 고객을 마스터에서 만들고 그다음 Salesforce, ERP, 청구에 보냅니다. 매우 강한 거버넌스이고, 매우 큰 변화입니다. 기존 프로세스는 자기 고객을 만들고, 사용자에게는 자기 작업 흐름이 있고, 연동은 로컬 생성을 가정하며, 사업부들은 고객이 무엇인지조차 합의하지 못할 수 있습니다. 그래서 제가 보는 Salesforce 랜드스케이프에서 드뭅니다. 옳은 선택일 수 있습니다. 도구 하나 설치하는 것보다 훨씬 큰 결정입니다.
중앙 집중형 MDM은 생성과 권한 원천을 마스터로 옮긴다.
넷을 나란히
섹션 제목: “넷을 나란히 ”| 방식 | 무엇을 중앙화하는가 | 원천이 남는가? | 관리되는 값을 되돌려 보내는가? |
|---|---|---|---|
| 레지스트리 | 정체성과 연결 | 예 | 보통 아니요 |
| 통합 | 정체성과 결합된 데이터 | 예 | 보통 아니요 |
| 공존 | 정체성, 데이터, 마스터 결정 | 예 | 예 |
| 중앙 집중 | 생성과 권한 | 예, 소비자로서 | 예 |
표를 내려갈수록 마스터 관리 층이 더 많은 권한을 얻고, 보통 조직도 더 많이 바뀌어야 합니다.
시험 포인트. 네 가지 MDM 구현 방식을 알아 두십시오. 레지스트리(정체성을 연결하고, 원천은 자기 데이터를 유지), 통합(보통 분석을 위해 데이터를 한데 모음), 공존(마스터 값을 정하고 원천에 되돌려 게시), 중앙 집중(마스터가 데이터를 만들고, 원천은 그것을 소비).
그러니 “중앙 집중이 가장 성숙하니 모두 거기로 가야 한다”는 없습니다. 문제를 푸는 가장 가벼운 패턴을 고르십시오. 레코드들이 함께 속한다는 걸 알아야 하나요? 레지스트리를 생각하십시오. 분석을 위한 결합된 뷰? 통합. 여러 운영 시스템에 되돌려 동기화되는 관리되는 값? 공존. 모두를 위해 마스터 데이터를 만들고 통제하는 단일 프로세스? 중앙 집중.
Data 360은 어디에 맞는가?
섹션 제목: “Data 360은 어디에 맞는가? ”Data 360은 여러 원천에 걸쳐 통합 프로필을 만들고, MDM과 많이 비슷하게 들리며, 실제로 문제의 일부를 풉니다. 그 ID 확인은 원천 프로필들을 하나의 통합 정체성으로 매칭하고 원천 레코드로 돌아가는 연결을 유지합니다(Data 360 Architecture (opens in a new tab)). 그래서 레지스트리에 가장 가깝습니다. 통합 프로필에 조정된 값을 보여 줄 수도 있습니다. 하지만 그렇다고 원천을 다시 쓰는 중앙 집중형 골든 레코드 시스템이 되지는 않습니다. 통합된 뷰가 자동으로 마스터로 관리되는 기업 레코드는 아닙니다. 모듈 4가 전부 그 차이에 관한 것입니다.
공통 모델은 공통 진실이 아니다
섹션 제목: “공통 모델은 공통 진실이 아니다 ”표준(canonical) 데이터 모델이라는 말도 듣게 됩니다. Salesforce의 계정, ERP의 비즈니스 파트너, 청구의 고객이 모두 합의된 식별자와 속성을 가진 하나의 합의된 기업 개념, 고객에 매핑되어, 모든 연동이 다른 모든 시스템의 모양을 이해할 필요가 없습니다. Data 360의 데이터 모델은 원천들을 공통 개념으로 조화시키는 예입니다. 하지만 표준 모델은 **이것을 어떻게 일관되게 표현할까?**에 답합니다. MDM은 **시스템 전반에서 이것을 어떻게 식별하고, 관리하고, 마스터로 관리할까?**에 답합니다. 세 시스템을 하나의 고객 모양에 완벽하게 매핑해도 Salesforce는 여전히 123 Main Street, ERP는 125라고 합니다. 구조를 풀었지 권한 원천을 푼 게 아닙니다. 조화와 마스터 관리는 바꿔 쓸 수 없습니다.
하나의 비즈니스, 여러 패턴
섹션 제목: “하나의 비즈니스, 여러 패턴 ”그러니 “Steve Trucking에 MDM이 필요하다”는 요구사항이 아닙니다. 무엇에 대해? 리테일 파트너, 물류 센터, 배송팀, 트럭, 수령인은 권한 원천이 다른 서로 다른 영역입니다. 리테일 파트너는 Salesforce와 재무 ERP에서 관리되고, 트럭의 정체성은 FleetLink에서 오고, 수령인은 배송마다 파트너가 공급합니다. 영역마다 다른 패턴을 쓸 수 있고, 한 영역 안에서도 속성마다 권한 원천이 다를 수 있습니다. 그러니 다이어그램 한가운데 MDM이라는 상자를 그리고 해결했다고 하지 마십시오. 그 상자가 무엇을 하는지 물으십시오.
방식은 연동도 바꿉니다. 레지스트리에는 정체성 연결이, 통합에는 믿을 만한 유입 흐름이, 공존에는 양방향 데이터가, 중앙 집중에는 마스터로부터의 배포와 다른 시스템이 경쟁하는 진실을 만들지 못하게 막는 통제가 필요합니다. 권한이 커질수록 조율도 커지고 실패 처리도 커집니다. MDM이 법적 이름을 바꿨는데 ERP가 거부하면? 그래서 공존과 중앙 집중은 “기능이 더 많은 레지스트리”가 아닙니다. 다른 운영 책임을 집니다.
MDM은 비즈니스 결정이다
섹션 제목: “MDM은 비즈니스 결정이다 ”가장 중요한 점입니다. MDM은 근본적으로 기술 결정이 아닙니다. 권한 원천에 대한 결정입니다. 누가 고객을 만드는가, 누가 바꿀 수 있는가, 누가 어떤 값이 이길지 정하는가, 어떤 시스템이 그것을 받아들여야 하는가, 그들이 다르면 어떻게 되는가. 도구는 그 결정을 구현할 수 있지만, 조직이 그것에 합의하게 만들 수는 없습니다. 그래서 MDM 프로젝트는 훌륭한 기술을 갖고도 실패할 수 있습니다. 기술 팀은 매칭을 풀었는데, 비즈니스는 소유권을 끝내 풀지 못한 것입니다.
제가 어렵게 배운 일반적인 교훈입니다. 여러 시스템이 같은 데이터를 마스터로 관리할 때, Salesforce는 그들이 합의하지 않은 것을 맞춰 줄 수 없습니다. 회사가 ERP 두 개를 운영하면 저는 둘을 어떻게 동기화하는지 묻습니다. 그들이 못 한다면 Salesforce도 못 합니다. 그 이야기는 모듈 5에서 합니다(고객 하나, ERP 둘).
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 문제에 정체성 연결, 결합된 데이터, 되돌려 보내는 마스터 값, 중앙 생성 중 무엇이 필요한지.
- 기업 전체에 패턴 하나가 아니라, 각 데이터 영역에 어떤 패턴이 맞는지.
- 마스터 관리 층이 얼마나 많은 권한을 얻고, 어떤 시스템이 그 결정을 받아들여야 하는지.
- 조화와 권한 원천을 혼동하지 않으면서, 표준 모델이 필요한지.
- 선택한 패턴이 연동 방향, 소유권, 실패 처리를 어떻게 바꾸는지.
누군가 다이어그램에 MDM 상자를 넣으면 그것이 무엇을 하는지 물으십시오. 어떤 레코드가 함께 속하는지 아는가? 그 데이터를 결합하는가? 어떤 값이 이길지 정하는가? 그 결정을 되돌려 보내는가? 애초에 데이터를 만드는가? 그 답이 실제로 어떤 아키텍처를 가졌는지, 그리고 권한 원천이 어디 있는지 알려 줍니다.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce Architects, Data 360 Architecture (opens in a new tab)(영어), 확인일 2026-10-14.