MDM #6. DX는 왜 데이터 단계에서 막히는가: 마스터 데이터가 만드는 숨은 병목

기업의 Digital Transformation은 새로운 시스템을 도입하는 것에서 시작되는 경우가 많습니다.

ERP를 교체하고, CRM을 통합하고, Data Platform을 구축하고, Digital Commerce를 확대하고, AI와 AI Agent를 업무에 연결합니다.

각 프로젝트는 서로 다른 기술과 목표를 갖고 있습니다.

하지만 실제 운영단계로 들어가면 놀랍도록 비슷한 질문이 반복됩니다.

“이 Supplier가 저 시스템의 Supplier와 같은 회사입니까?”

“CRM의 Customer와 ERP의 거래처를 어떤 기준으로 연결해야 합니까?”

“Product Category가 시스템마다 다른데 어느 것이 기준입니까?”

“AI Agent가 조회한 Supplier Status는 최신 정보입니까?”

“조직개편 이후 어느 조직 Hierarchy를 기준으로 실적을 집계해야 합니까?”

이 질문은 특정 애플리케이션의 문제가 아닙니다.

여러 시스템과 프로세스가 공통으로 사용하는 Business Entity의 Identity, Definition, Hierarchy, Status와 Ownership이 명확하지 않을 때 발생합니다.

바로 Master Data의 영역입니다.

Digital Transformation이 새로운 기능을 만드는 작업이라면, Master Data Management는 그 기능들이 같은 Customer, Supplier, Product, Material, Location과 Organization을 보고 있다고 믿을 수 있게 만드는 기반입니다.

그렇다고 모든 DX 실패의 원인이 Master Data라는 의미는 아닙니다.

Leadership, Operating Model, Process Design, Adoption, Architecture, Integration, Technical Debt, Skills 등 다양한 원인이 Digital Transformation의 성패에 영향을 줍니다.

Master Data는 그중 하나입니다.

다만 많은 Transformation에서 동시에 사용되기 때문에, 문제가 있을 경우 여러 프로젝트에 반복적으로 영향을 미치는 공통 Dependency가 될 수 있습니다.

먼저 바로잡아야 할 것: “DX의 70%가 실패한다”는 숫자

Digital Transformation과 관련해 가장 많이 인용되는 문장 중 하나가 다음입니다.

“Digital Transformation의 70%가 실패한다.”

하지만 이런 형태의 문장을 보편적인 산업 실패율처럼 사용하는 것은 신중해야 합니다.

McKinsey의 2018년 Global Survey에서는 Digital Transformation을 포함한 Transformation의 성공률이 낮게 나타났고, 성공한 기업이 공통적으로 Leadership, Capability Building, Empowerment, Tools, Communication과 같은 요소를 갖는다고 분석했습니다.

McKinsey — The Keys to a Successful Digital Transformation

또한 McKinsey의 Digital Banking 분석에서는 조사대상 은행 중 약 30%가 Digital Strategy를 성공적으로 구현했다고 응답했으며, 복잡한 Architecture, Data Management, Initiative 간 Dependency와 조직문제 등을 실행상의 난제로 제시합니다.

McKinsey — Why Most Digital Banking Transformations Fail

중요한 점은 어느 연구도 다음과 같이 결론 내리지 않는다는 것입니다.

“DX 실패의 70%는 Master Data 때문이다.”

따라서 이 글에서는 특정 실패율을 주장하지 않습니다.

대신 왜 Master Data가 여러 Transformation에서 반복적으로 병목이 되는지를 구조적으로 분석합니다.

1. Digital Transformation은 결국 Business Entity를 움직인다

DX 프로젝트를 기술 관점에서 보면 시스템과 플랫폼이 보입니다.

ERP
CRM
Commerce
Data Platform
AI
SCM

하지만 Business Process 관점에서 보면 다른 것이 보입니다.

CUSTOMER
SUPPLIER
PRODUCT
MATERIAL
LOCATION
ORGANIZATION
ASSET

예를 들어:

ERP Transformation은 Supplier·Customer·Material을 처리하고,
CRM Transformation은 Customer·Account·Contact를 처리하고,
SCM Transformation은 Supplier·Material·Location을 처리하며,
Digital Commerce는 Product·Customer·Location을 사용하고,
Analytics는 대부분의 Master Entity와 Hierarchy를 결합하며,
AI Agent는 이 Entity를 조회하고 때로는 관련 업무를 실행합니다.

시스템은 달라도 사용하는 Business Entity는 상당 부분 겹칩니다.

DX Architecture의 숨은 공통 Layer

DIGITAL EXPERIENCE
CRM · Commerce · Mobile · AI Agent

↓

BUSINESS PROCESS
Sales · Procurement · Supply Chain · Service · Finance

↓

BUSINESS ENTITY
Customer · Supplier · Product · Material · Location

↓

MASTER DATA CONTROL
Identity · Definition · Hierarchy · Quality · Ownership

↓

SYSTEM LANDSCAPE
ERP · CRM · PIM · SCM · SaaS · Data Platform

Digital Experience를 아무리 새롭게 설계해도 아래쪽 Business Entity가 일관되지 않으면 상위 서비스가 이를 반복해서 보정해야 합니다.

2. MDM의 핵심은 데이터를 한곳에 모으는 것이 아니다

Master Data Management를 “모든 Master Data를 하나의 Database로 통합하는 프로젝트”로 이해하면 지나치게 좁습니다.

SAP는 MDM을 여러 시스템에서 사용하는 고객, 공급업체, 제품, 자재, 자산 등 중요한 Business Data에 대해 신뢰 가능한 단일 관점을 만들고 유지하는 discipline, process, technology로 설명합니다.

SAP — What Is Master Data Management?

실제로 중요한 것은 다음 질문에 답하는 것입니다.

이 Entity는 무엇인가?
같은 Entity인지 어떻게 판단하는가?
Enterprise Identifier는 무엇인가?
어떤 Source가 어떤 Attribute에 authoritative한가?
어떤 Hierarchy가 기준인가?
누가 변경할 수 있는가?
변경된 정보가 소비 시스템에 어떻게 전달되는가?

3. ERP Transformation에서 Master Data 문제가 드러나는 방식

ERP Transformation은 Master Data Dependency가 가장 명확하게 나타나는 사례 중 하나입니다.

새 ERP의 Transaction Logic이 아무리 정확해도 다음이 잘못되어 있으면 업무에 영향을 줍니다.

Supplier Identity,
Customer / Business Partner Mapping,
Material Code,
Unit of Measure,
Plant와 Location,
Organization Assignment,
Product Hierarchy.

대표적인 패턴은:

LEGACY COMPLEXITY
↓
DATA MIGRATION
↓
NEW ERP
↓
SAME MASTER DATA PROBLEM

입니다.

기존 데이터를 그대로 이전하는 것은 Legacy Business Rule까지 그대로 이전하는 것일 수 있습니다.

이 문제는 별도의 글에서 SAP S/4HANA의 BP·CVI·Migration·Cutover 관점으로 구체적으로 다룹니다.

MDM #10. ERP 현대화에서 MDM이 실패하는 이유

4. CRM과 Customer 360의 가장 어려운 문제도 Identity다

Customer 360 프로젝트에서는 데이터를 많이 수집하는 것보다 동일 고객을 정확하게 연결하는 것이 더 어려울 수 있습니다.

한 고객이 다음과 같이 존재한다고 가정해 보겠습니다.

ERP Customer: C-10482
CRM Account: A-72911
E-commerce User: U-55491
Service Account: S-20983

이 네 레코드가 하나의 Person 또는 Organization을 나타내는지 결정하지 못하면 Channel 데이터를 모두 모아도 진정한 Customer View는 만들어지지 않습니다.

이때 필요한 것은 단순 Join이 아니라:

Identity Resolution,
Match Rule,
Source Crosswalk,
Golden / Authoritative Attribute,
Hierarchy,
Lifecycle Status

입니다.

5. Digital Commerce에서는 Product Master의 의미가 달라진다

전통적인 ERP Product 또는 Material Master는 거래에 필요한 정보가 중심입니다.

Digital Commerce에서는 소비자가 보는 정보가 추가됩니다.

Product Name,
Category,
Specification,
Variant,
Market Availability,
Digital Asset Relationship,
Channel-Specific Description.

ERP, PIM, Commerce Platform에서 Product Identity와 Category가 다르면 Channel별 Product View가 분리될 수 있습니다.

MDM이 모든 Commerce Content를 직접 관리할 필요는 없습니다.

대신:

Which Product Is This?
↓
Which Family / Variant Does It Belong To?
↓
Which Core Attributes Are Authoritative?

를 명확하게 하는 역할이 중요합니다.

6. Data Platform을 구축해도 Master Data 문제는 자동으로 해결되지 않는다

Data Lake, Lakehouse 또는 Enterprise Data Platform을 구축하면 모든 데이터를 한곳에서 분석할 수 있습니다.

하지만 물리적으로 데이터를 모으는 것과 Business Meaning을 통합하는 것은 다른 문제입니다.

예를 들어:

System A: Samsung Electronics
System B: SAMSUNG ELECTRONICS CO LTD
System C: SEC
System D: 005930

와 같은 레코드를 Data Lake에 저장했다고 해서 자동으로 같은 Business Entity가 되는 것은 아닙니다.

Data Platform은 데이터를 저장하고 처리합니다.

MDM은 어떤 레코드가 같은 Entity이며 어떤 Business Identity를 사용해야 하는지를 결정하는 데 기여합니다.

Analytics에서 자주 발생하는 문제는 “숫자”가 아니라 “분모”다

부서별 보고서에서 매출 숫자가 다른 원인이 계산식 때문이라고 생각하기 쉽습니다.

실제로는 다음처럼 Dimension이 다를 수 있습니다.

Product Hierarchy가 다름,
Customer Group이 다름,
Region Definition이 다름,
Organization Hierarchy가 다름,
Active Supplier 범위가 다름.

즉 동일 Transaction Data를 사용해도 Master / Reference Dimension이 다르면 결과가 달라집니다.

7. AI Agent에서는 Master Data 오류가 “조회 오류”에서 “행동 오류”로 바뀔 수 있다

전통적인 Analytics에서는 잘못된 Supplier 정보가 잘못된 Report를 만들 수 있습니다.

AI Agent가 Enterprise System을 호출하는 환경에서는 같은 문제가 업무 Action으로 이어질 수 있습니다.

예를 들어 Procurement Agent가:

User Request
↓
Resolve Supplier
↓
Check Status
↓
Retrieve Contract
↓
Prepare Purchase Action

을 수행한다고 가정해 보겠습니다.

첫 번째 Supplier Resolution이 잘못되면 이후 단계가 기술적으로 정상 실행되더라도 잘못된 Entity에 대한 결과를 만들 수 있습니다.

따라서 AI 시대의 Master Data에는 단순 Accuracy 외에도:

Stable Entity Identity,
Current Status,
Business Relationship,
Authoritative Source,
Freshness,
Governed Access

가 중요해집니다.

AI가 MDM을 대체하기보다, AI가 더 많은 Business Action을 수행할수록 신뢰 가능한 Business Entity가 중요해지는 이유입니다.

8. Transformation마다 필요한 Master Data가 다르다

Transformation	Critical Master	Typical Dependency	Risk if Unresolved
ERP	Supplier, Customer, Material, Organization	Identity, Code Mapping, Organization Extension	Migration 및 Transaction Exception
CRM / Customer 360	Customer, Account, Contact	Entity Resolution, Household / Account Hierarchy	Fragmented Customer View
Supply Chain	Supplier, Material, Location	Status, Sourcing Relationship, Location Identity	Planning 및 Procurement 오류
Digital Commerce	Product, Customer, Channel	Product Identity, Variant, Availability	Channel Inconsistency
Analytics	Customer, Product, Organization, Reference	Hierarchy와 Common Dimension	Conflicting Metrics
AI / Agentic AI	Use Case별 Business Entity	Identity, Context, Status, Authorization	Wrong-Entity Decision 또는 Action

9. DX 프로젝트가 반복해서 만드는 것이 있다: Master Data Debt

각 Digital Project가 자체적으로 Master Data 문제를 해결하면 단기적으로는 빠를 수 있습니다.

하지만 시간이 지나면 별도의 Identity, Mapping, Hierarchy와 Rule이 축적됩니다.

이를 이 글에서는 Master Data Debt라고 부르겠습니다.

Debt Type	증상
Identity Debt	동일 Customer·Supplier·Product를 프로젝트마다 다른 ID로 관리
Semantic Debt	Active, Premium, Strategic 같은 Business Term의 의미가 시스템마다 다름
Hierarchy Debt	조직·상품·거래선 Hierarchy가 시스템마다 독립적으로 진화
Mapping Debt	Point-to-Point Crosswalk와 Transformation Rule이 계속 증가
Ownership Debt	사용자는 많지만 표준과 품질의 최종 책임자는 없음
Synchronization Debt	시스템별 데이터 반영시점이 달라 어떤 값이 최신인지 알기 어려움

Master Data Debt 분류는 Digital Future & Strategy practitioner framework입니다.

10. 프로젝트별 Mapping이 늘어날수록 Enterprise Integration 비용도 누적된다

MDM이 없다면 각 시스템을 다음처럼 직접 연결할 수 있습니다.

ERP A ↔ CRM
ERP B ↔ CRM
ERP C ↔ Analytics
CRM ↔ Commerce
Commerce ↔ Data Platform

각 Integration은 다시 자체 Mapping Logic을 가질 수 있습니다.

예를 들어 Supplier Status가 시스템별로:

ERP A = A / B
ERP B = 01 / 09
Procurement = ACTIVE / BLOCKED
Analytics = TRUE / FALSE

라면 Interface마다 별도의 Mapping이 필요합니다.

Enterprise Standard를 정의하면 이러한 Mapping을 완전히 없앨 수 있는 것은 아니지만, 공통 의미를 중심으로 단순화할 수 있습니다.

11. 그렇다고 “Enterprise MDM부터 완성한 뒤 DX를 시작하자”도 잘못된 접근이다

Master Data가 중요하다고 해서 기업 전체의 Master Data를 완벽하게 정비할 때까지 Digital Transformation을 기다릴 필요는 없습니다.

그렇게 하면 MDM 자체가 새로운 병목이 됩니다.

더 현실적인 접근은 Transformation별로 Minimum Trusted Master를 정의하는 것입니다.

TRANSFORMATION USE CASE
↓
CRITICAL BUSINESS ENTITY
↓
MINIMUM TRUSTED ATTRIBUTES
↓
IDENTITY + QUALITY + OWNER
↓
GOVERNED INTERFACE
↓
USE CASE GO-LIVE

Minimum Trusted Master는 Digital Future & Strategy practitioner framework입니다.

Minimum Trusted Master의 여섯 가지 조건

1. Entity Definition	무엇을 Customer, Supplier, Product라고 부르는지 명확하다.
2. Stable Identity	소비 시스템이 동일 Entity를 일관되게 식별할 수 있다.
3. Critical Attributes	Use Case에 필요한 핵심속성과 authoritative source가 정해져 있다.
4. Quality Rule	Business Action 전에 반드시 확인할 품질기준이 있다.
5. Owner	정의·품질·예외를 결정할 책임자가 있다.
6. Delivery Contract	API·Event·Batch 등 소비자가 사용할 공급방식과 freshness가 정의되어 있다.

12. DX 프로젝트마다 Data Dependency Map을 만들어야 한다

기존 프로젝트 Dependency 관리에서는 시스템과 Interface가 중심입니다.

여기에 Master Data Dependency를 추가할 필요가 있습니다.

Use Case	Entity	Critical Attribute	Authority	Consumer	Owner
Supplier Risk Agent	Supplier	Legal ID, Status, Country	Enterprise Supplier Master	AI Agent	Procurement Data Owner
Customer 360	Customer	Identity, Relationship	Customer MDM	CRM / Analytics	Customer Owner

DX Data Dependency Map은 Digital Future & Strategy practitioner framework입니다.

13. Master Data Readiness는 Transformation Gate가 되어야 한다

DX Project가 Go-Live 준비도를 점검할 때 Application Test와 Interface Test만 보는 것은 충분하지 않을 수 있습니다.

중요한 Business Entity가 준비되었는지도 확인해야 합니다.

Entity Gate
Critical Business Entity와 Scope가 합의되었는가?

Identity Gate
중복·Cross-System ID 관계가 통제 가능한가?

Quality Gate
Business Critical Attribute가 필요한 수준을 충족하는가?

Ownership Gate
오류와 예외를 결정할 Owner가 있는가?

Distribution Gate
필요한 시스템에 적정 Freshness로 제공되는가?

Reconciliation Gate
Source와 Consumer가 동일 Business State를 보고 있는지 검증할 방법이 있는가?

이 Readiness Gate 역시 Digital Future & Strategy practitioner framework이며 공식 산업표준은 아닙니다.

14. Master Data 문제가 있는지 어떻게 측정할 것인가

DX 프로젝트에서 다음 지표를 Baseline으로 측정하면 Data Dependency를 보다 객관적으로 볼 수 있습니다.

Cross-System 동일 Entity Mapping 수,
Unresolved Duplicate Candidate,
Manual Mapping Rule 수,
Master Data 관련 Interface Exception,
Business User의 Data Rework 시간,
Critical Attribute Error,
Hierarchy Reconciliation 건수,
Master Data로 인한 UAT Defect,
Consumer별 Data Freshness 차이,
Data Owner 미지정 Critical Attribute.

이 수치를 모두 금액화할 필요는 없습니다.

먼저 Transformation에 실제로 어떤 부담을 만들고 있는지 보여주는 것이 중요합니다.

15. 모든 DX 문제를 MDM으로 해결하려 하지 말아야 한다

MDM의 역할을 과도하게 확대하면 다시 실패합니다.

문제	MDM이 주된 해법인가?
여러 시스템의 동일 Supplier를 연결하지 못함	가능성이 높음 — Entity Resolution / MDM 영역
한 애플리케이션 화면이 느림	아님 — Application Performance 문제
ERP Approval 단계가 너무 많음	주로 아님 — Process / Workflow Design 문제
Product 정의가 Channel마다 다름	부분적으로 해당 — Product Identity와 Core Semantics는 MDM/PIM 검토
AI가 문서를 잘못 요약함	반드시 아님 — Model, Retrieval, Evaluation 등 별도 문제 가능

MDM은 모든 Data Problem을 해결하는 플랫폼이 아닙니다.

특히 Transaction Data, Document Data, Model Quality, Process Design 등은 별도의 Governance와 Technology가 필요합니다.

16. MDM을 별도 인프라 프로젝트로 두는 것도 한계가 있다

반대 극단도 있습니다.

MDM을 모든 Transformation과 분리된 Enterprise Infrastructure Project로 운영하면 Business Priority와 연결되지 않을 수 있습니다.

더 효과적인 접근은:

TRANSFORMATION PORTFOLIO

ERP ───────┐
CRM ───────┤
AI ────────┤
Commerce ──┤ → SHARED MASTER DATA CAPABILITIES
Analytics ─┤
SCM ───────┘

처럼 MDM을 여러 Strategic Program이 재사용할 수 있는 공통 Capability로 보는 것입니다.

17. DX와 MDM의 투자순서는 Use Case가 결정해야 한다

모든 Master Domain을 먼저 정비하는 대신 투자순서를 Transformation Portfolio에서 역으로 도출할 수 있습니다.

STRATEGIC PROGRAM
↓
BUSINESS CAPABILITY
↓
CRITICAL MASTER ENTITY
↓
CURRENT DATA GAP
↓
MDM CAPABILITY INVESTMENT

예를 들어 향후 12개월의 중요한 프로그램이:

S/4HANA Transformation,
Supplier Risk Automation,
Procurement AI

라면 Supplier와 Material Master가 Customer MDM보다 먼저 투자대상이 될 수 있습니다.

반대로 CRM·Commerce·Customer AI가 핵심전략이라면 Customer Identity가 우선될 수 있습니다.

보편적으로 가장 먼저 해야 하는 Domain은 없습니다.

18. DX 프로그램이 확인해야 할 12가지 질문

1. 이 Transformation이 사용하는 핵심 Business Entity는 무엇인가?

2. 각 Entity에 Enterprise 수준의 안정적인 Identity가 존재하는가?

3. 동일 Entity가 여러 시스템에서 얼마나 다르게 표현되는가?

4. Critical Attribute의 authoritative source가 명확한가?

5. Product·Customer·Organization Hierarchy가 시스템마다 다르지 않은가?

6. Master Data 오류가 발생했을 때 최종 결정할 Owner가 있는가?

7. Project가 새로운 Local Master 또는 Mapping을 추가하면서 Master Data Debt를 만들고 있지는 않은가?

8. Data Platform에 데이터를 적재하는 것과 Business Identity를 통합하는 것을 혼동하고 있지 않은가?

9. Go-Live 전에 Minimum Trusted Master 수준을 정의했는가?

10. Consumer가 필요한 Freshness와 Distribution Pattern을 정의했는가?

11. AI가 사용하는 Entity Context와 사람이 사용하는 Master Data가 같은 Governance를 따르는가?

12. 이 프로젝트에서 만든 Master Capability를 다음 Transformation이 재사용할 수 있는가?

Digital Transformation의 데이터 기반을 다시 정의한다

Digital Transformation이 실패하는 원인은 다양합니다.

Leadership이 부족할 수도 있고, 잘못된 Process를 디지털화했을 수도 있으며, Architecture가 지나치게 복잡하거나 조직의 Adoption이 부족할 수도 있습니다.

따라서 Master Data를 DX 실패의 “진짜 단 하나의 원인”이라고 설명하는 것은 적절하지 않습니다.

하지만 Master Data에는 다른 문제와 구별되는 특징이 있습니다.

여러 Transformation이 같은 Master Data를 반복해서 사용한다는 것입니다.

ERP
CRM
SCM
COMMERCE
ANALYTICS
AI

↓ ALL DEPEND ON ↓

CUSTOMER · SUPPLIER · PRODUCT
MATERIAL · LOCATION · ORGANIZATION

따라서 Master Data가 불명확하면 각 Transformation Project가 자체적으로 문제를 해결합니다.

새로운 Mapping이 생기고, 새로운 Local Code가 생기고, 별도의 Customer View와 Supplier View가 만들어집니다.

하나의 프로젝트는 성공할 수 있습니다.

하지만 Enterprise 전체의 복잡도는 더 커질 수 있습니다.

MDM의 전략적 가치는 모든 데이터를 중앙화하는 데 있지 않습니다.

여러 Transformation이 공통으로 사용하는 Business Entity에 대해 재사용 가능한 Trust를 제공하는 데 있습니다.

Digital Transformation은 새로운 Technology를 도입하는 것으로 시작할 수 있습니다. 그러나 Enterprise Scale로 확장하려면 결국 “우리는 같은 Customer, Supplier, Product와 Organization을 보고 있는가?”라는 질문에 답해야 합니다.

Sources & Further Reading

Method Note
이 글은 Digital Transformation의 실패원인을 Master Data 하나로 설명하지 않습니다. McKinsey의 Digital Transformation 연구는 Transformation 성공률과 실행상의 다양한 조직·기술·운영요인을 설명하기 위한 참고자료이며, 해당 연구가 MDM을 Digital Transformation 실패의 주된 원인으로 규정한 것은 아닙니다. SAP와 IBM 자료는 Master Data Management의 역할과 Enterprise Business Entity의 일관성이라는 개념을 확인하기 위한 참고자료로 사용했습니다. Master Data Debt, Minimum Trusted Master, DX Data Dependency Map, Master Data Readiness Gate는 Digital Future & Strategy practitioner frameworks입니다. 산업 전체에 적용되는 공식 표준이나 통계모델이 아니며 기업별 Transformation Portfolio, Data Domain, Architecture 및 Risk에 맞게 조정해야 합니다.

Reviewed: September 2026

Global English Companion

글로벌 독자를 위한 영문판에서는 Digital Transformation과 Master Data의 관계를 별도로 다룹니다.

MDM #6. Why Digital Transformation Initiatives Struggle — The Hidden Role of Master Data

영문판은 글로벌 Transformation 관점의 개념 설명에 초점을 두고, 본 한국어판은 DX별 Master Data Dependency, Master Data Debt, Minimum Trusted Master와 Readiness Gate를 더 구체적으로 다룹니다.

다음 글: MDM 프로젝트는 왜 경영진의 지원을 받지 못하는가

Search This Blog

Digital Future & Strategy