MDM #8. 국내 기업 MDM 도입 실패의 7가지 패턴: 조기경보와 복구 전략

MDM 프로젝트는 어느 날 갑자기 실패하지 않습니다.

대부분의 경우 실패가 공식적으로 드러나기 훨씬 전부터 작은 신호가 나타납니다.

예를 들어 다음과 같은 말입니다.

“플랫폼부터 선정하고 표준은 나중에 정하죠.”

“이번 기회에 Customer, Supplier, Product, Material을 전부 같이 합시다.”

“현업은 바쁘니까 설계가 끝난 뒤 검토만 받으면 됩니다.”

“운영조직은 Go-Live 직전에 정하면 되지 않을까요?”

“ROI는 시스템이 안정화된 다음 측정하겠습니다.”

개별적으로 보면 반드시 잘못된 말은 아닐 수 있습니다.

하지만 여러 신호가 동시에 나타난다면 MDM 프로그램이 원래 해결하려던 Business Problem에서 멀어지고 있다는 의미일 수 있습니다.

따라서 더 유용한 질문은:

“이 MDM 프로젝트는 실패할 것인가?”

가 아니라:

“프로젝트가 잘못된 방향으로 가고 있다는 것을
우리는 얼마나 일찍 발견할 수 있는가?”

입니다.

MDM 실패를 예방하는 가장 좋은 방법은 실패 후 원인을 분석하는 것이 아니라, 실패가 구조화되기 전에 조기경보 신호를 찾아 방향을 수정하는 것입니다.

이 글에서는 국내 대기업 MDM 프로젝트에서 반복적으로 점검해야 할 7가지 구조적 실패 패턴을 증상 → 근본원인 → 조기경보 → 복구조치 → Recovery Gate 관점에서 분석합니다.

먼저 전제부터: 이 7가지는 통계적 실패율 모델이 아닙니다

MDM 프로젝트는 산업, 기업규모, 도메인, ERP 구조, 조직문화에 따라 매우 다릅니다.

따라서 “7개 중 5개에 해당하면 실패확률 80%”처럼 해석해서는 안 됩니다.

이 글의 목적은 실패확률을 계산하는 것이 아니라 구조적 위험을 조기에 찾아내는 것입니다.

Failure Pattern	핵심 문제	가장 먼저 나타나는 신호
1. Technology First	Business 목적보다 플랫폼이 앞섬	Vendor·Architecture 논의는 많은데 관리 대상 Entity와 Business Problem은 불명확
2. Big Bang	범위를 지나치게 크게 설정	모든 Domain·법인·시스템을 첫 Release에 포함
3. IT-Only	MDM을 IT 시스템 구축으로 정의	Business 참여가 검토·승인 수준에 머묾
4. Go-Live Syndrome	운영모델 없이 시스템만 Open	운영조직·Steward·품질관리 예산이 미정
5. Ownership Vacuum	최종 의사결정권자 부재	“이 데이터의 Owner가 누구인가?”에 여러 답이 나옴
6. Business-Free Design	현장 업무를 모르는 상태에서 표준 설계	현업 의견이 UAT 직전에 처음 등장
7. Value Blindness	성과를 입증할 Baseline 없음	KPI가 record count와 시스템 구축률에 집중

이 7개 유형은 Digital Future & Strategy practitioner diagnostic이며 산업 통계나 특정 컨설팅사의 공식 failure model이 아닙니다.

Pattern 1. Technology First — “솔루션부터 선정합시다”

어떻게 나타나는가

MDM 프로젝트의 첫 번째 중요한 산출물이 Business Problem이 아니라 RFP가 됩니다.

회의의 중심도 다음과 같이 흘러갑니다.

SaaS인가 On-Premises인가?
Matching Engine은 얼마나 좋은가?
Workflow 기능이 있는가?
AI 기능이 어느 정도인가?
어떤 벤더가 Gartner 평가가 높은가?

그런데 더 기본적인 질문에는 답이 없습니다.

어떤 Business Entity를 관리할 것인가?

현재 어떤 업무문제가 Master Data 때문에 발생하고 있는가?

어떤 속성이 Enterprise Standard가 되어야 하는가?

어떤 데이터는 MDM 대상에서 제외할 것인가?

왜 실패하는가

MDM Platform은 Business Rule을 만들어 주지 않습니다.

IBM도 MDM Strategy에서 어떤 데이터를 Master Data로 관리해야 하는지 결정하고, 이후 governance policy와 lifecycle process를 정의하는 것을 중요한 선행과제로 설명합니다.

Technology가 Strategy보다 앞서면 결국 Tool의 기능이 Data Model과 Process를 결정하게 됩니다.

조기경보

Vendor 비교표는 100페이지인데
“이 프로젝트가 해결할 Top 3 Business Problem”은 한 페이지에도 명확하지 않다.

복구조치

이미 플랫폼을 선정했더라도 프로젝트를 중단할 필요는 없습니다.

다만 기술구축 범위를 확대하기 전에 다음 연결고리를 다시 설정해야 합니다.

BUSINESS PROBLEM
↓
MASTER ENTITY
↓
CRITICAL ATTRIBUTE
↓
CONTROL / QUALITY REQUIREMENT
↓
MDM CAPABILITY
↓
TECHNOLOGY

Recovery Gate

다음 단계로 확장하기 전에 Sponsor와 주요 Data Owner가 최소한 다음에 합의해야 합니다.

“어떤 Master Domain을 어떤 Business Outcome을 위해 관리하는가?”

Pattern 2. Enterprise Big Bang — “이번에 전부 통합합시다”

어떻게 나타나는가

첫 번째 Release에 Customer, Supplier, Product, Material, Location, Organization 등 여러 Domain을 동시에 포함합니다.

여기에 여러 ERP, CRM, Legacy System, 해외법인까지 한꺼번에 연결하려고 합니다.

각 Domain은 다시 다음 문제를 갖고 있습니다.

Different Owner
+ Different Source Systems
+ Different Quality Rules
+ Different Workflow
+ Different Consumers
+ Different Regulatory Requirements

결국 하나의 MDM 프로젝트 안에 사실상 여러 Transformation Project가 만들어집니다.

근본원인

Big Bang의 원인은 단순 욕심만은 아닙니다.

“Enterprise MDM이라면 처음부터 Enterprise 전체를 해야 한다”는 생각이 강하게 작용합니다.

하지만 Enterprise Standard를 설계하는 것과 Enterprise 전체를 한 번에 구현하는 것은 다른 문제입니다.

조기경보

다음 세 가지가 동시에 나타나면 범위를 다시 봐야 합니다.

① Critical Path가 계속 늘어난다.

② Domain마다 “우리도 이번 Release에 반드시 포함해야 한다”고 요구한다.

③ 첫 Business Outcome보다 Platform Completion Date가 더 중요해진다.

복구조치

Domain을 무조건 하나만 선택하는 것이 정답은 아닙니다.

대신 독립적으로 가치를 증명할 수 있는 최소 범위를 찾아야 합니다.

평가 항목	질문
Business Impact	현재 반복되는 실제 업무문제가 있는가?
Ownership	의사결정을 내릴 Data Owner가 존재하는가?
Data Scope	Source와 Consumer 범위를 통제할 수 있는가?
Measurability	전후 성과를 비교할 Baseline을 만들 수 있는가?
Reuse	첫 구현이 다음 Domain 확장에 재사용 가능한가?

Recovery Gate

첫 범위는 “작다”가 아니라 완결되어야 합니다.

Data Create → Validate → Approve → Publish → Measure까지 하나의 운영 Cycle이 실제로 돌아가야 합니다.

Pattern 3. IT-Only MDM — “MDM은 데이터 시스템 프로젝트입니다”

어떻게 나타나는가

Project Manager, Architect, Developer, Data Engineer, Vendor Consultant는 모두 참여하지만 실제 Data Owner와 Process Owner의 참여는 제한적입니다.

Business는 주로:

요건 제출
→ 중간 결과 검토
→ UAT
→ Sign-off

역할을 수행합니다.

하지만 “같은 Customer인가?”, “어떤 Supplier status가 authoritative한가?” 같은 핵심 판단은 기술팀이 사실상 결정합니다.

왜 문제가 되는가

MDM에서 가장 중요한 결정은 기술결정만이 아닙니다.

IBM도 MDM을 technology, tools, processes가 결합된 포괄적 접근으로 설명하고, data model과 stewardship을 핵심요소로 제시합니다.

즉, MDM의 기술적 구현과 Business Accountability를 분리할 수 없습니다.

조기경보

“Business는 시간이 없으니 IT가 초안을 만들고 나중에 승인받읍시다.”

이 말이 반복되면 Business가 MDM의 공동 설계자가 아니라 고객으로 밀려나고 있을 가능성이 높습니다.

복구조치

Business가 모든 technical workshop에 참석할 필요는 없습니다.

대신 다음 Decision에는 반드시 Business Authority가 있어야 합니다.

Entity Definition
Attribute Ownership
Business Validation Rule
Approval Policy
Exception Policy
Business Quality Target

Recovery Gate

MDM Project Governance에 IT Sponsor뿐 아니라 실질적 권한을 가진 Business Sponsor와 Data Owner가 참여하고 있어야 합니다.

Pattern 4. Go-Live Syndrome — “Open하면 프로젝트는 끝납니다”

어떻게 나타나는가

구축기간에는 수십 명이 참여하지만 Go-Live 이후에는 소수 운영인력만 남습니다.

프로젝트 종료 전에 다음이 결정되지 않은 경우가 많습니다.

Data Steward 조직,
Quality Review Process,
Exception 관리,
Owner 변경관리,
품질 Rule 변경절차,
운영예산,
Business KPI.

왜 실패하는가

MDM은 일회성 cleansing project가 아닙니다.

새로운 Customer, Supplier, Product가 계속 생성되고 기존 데이터가 변경되며 Source System과 조직도 지속적으로 변합니다.

따라서 MDM은 지속적인 운영 capability입니다.

조기경보

Go-Live가 가까워졌는데도:

“운영조직은 기존 IT운영팀이 맡겠죠.”

라는 수준이라면 위험신호입니다.

복구조치

Build와 Run을 분리해서 설계해서는 안 됩니다.

DESIGN
Governance 포함
↓
BUILD
운영 Rule 포함
↓
GO-LIVE
Ownership 이미 활성화
↓
RUN
Quality · Issue · Exception · Improvement

Recovery Gate

Go-Live 전에 최소한 Owner, Steward, Issue Process, Quality KPI, Escalation, 운영예산이 승인되어야 합니다.

Pattern 5. Ownership Vacuum — “이 데이터는 여러 부서가 같이 관리합니다”

어떻게 나타나는가

Customer Master는 영업·마케팅·재무·서비스가 모두 사용합니다.

Supplier는 구매·재무·품질·Compliance가 사용합니다.

여러 조직이 사용한다는 이유로 아무도 최종 Owner가 되지 않는 문제가 발생합니다.

공동사용과 공동책임은 다릅니다

여러 조직이 데이터를 사용할 수 있지만 중요한 Decision에는 최종 권한이 필요합니다.

예를 들어:

Decision	누군가는 최종결정해야 함
두 Supplier를 하나의 Entity로 Merge할 것인가?	Yes
Supplier Legal Name의 authoritative source는 무엇인가?	Yes
어떤 Attribute가 Critical인가?	Yes
예외를 언제 허용할 것인가?	Yes

조기경보

데이터 오류가 발생했을 때
Ticket이 세 조직을 돌다가 다시 IT로 돌아온다.

복구조치

“Owner 한 명이 모든 Attribute를 관리한다”는 구조도 현실적이지 않습니다.

Entity Owner와 Attribute / Process Owner를 구분할 수 있습니다.

ENTITY OWNER
Core Identity / Lifecycle

+

ATTRIBUTE OWNER
Business-Specific Attributes

+

PROCESS OWNER
Upstream Creation / Change Process

+

STEWARD
Operational Governance

Recovery Gate

핵심 Domain에 대해 “누가 책임자인가?”보다 더 구체적으로 “어떤 Decision을 누가 최종 결정하는가?”가 문서화되어야 합니다.

Pattern 6. Business-Free Design — “현업은 나중에 검토하면 됩니다”

어떻게 나타나는가

컨설팅사와 IT가 Global Standard와 Target Data Model을 설계합니다.

관리자 몇 명이 중간 Review에 참여합니다.

실제 데이터를 생성·조회·수정하는 사용자는 UAT 단계에서 처음 결과를 봅니다.

그때 다음 의견이 쏟아집니다.

“이 필드는 실제로 사용하지 않습니다.”

“이 정보는 생성시점에 알 수 없습니다.”

“두 코드를 합치면 업무가 안 됩니다.”

“긴급 주문에서는 이 승인단계를 기다릴 수 없습니다.”

현업 참여는 요구사항 수집보다 넓습니다

실제 사용자는 다음 설계에 기여해야 합니다.

데이터가 실제로 생성되는 시점,
필드의 실제 의미,
예외 발생조건,
검색방법,
긴급처리,
업무에서 허용 가능한 Lead Time.

조기경보

UAT에서 “요건누락”보다 “업무를 잘못 이해했다”는 지적이 반복되면 설계단계의 Business Participation이 부족했다는 신호일 수 있습니다.

복구조치

모든 사용자를 설계회의에 넣을 필요는 없습니다.

대표적인 실제 Case를 사용해 설계를 검증하는 방식이 효과적입니다.

NORMAL CASE
+
EXCEPTION CASE
+
URGENT CASE
+
CROSS-DOMAIN CASE
=
BUSINESS VALIDATION

Recovery Gate

Target Process와 Data Standard가 관리자가 아니라 실제 practitioner의 대표 Case를 통과해야 합니다.

Pattern 7. Value Blindness — “데이터 품질이 좋아졌습니다”

어떻게 나타나는가

Go-Live 후 경영진이 질문합니다.

“그래서 무엇이 좋아졌습니까?”

MDM 팀은 다음과 같이 답합니다.

“Golden Record가 구축되었습니다.”
“중복 탐지기능이 생겼습니다.”
“Data Quality Dashboard를 만들었습니다.”

모두 의미 있는 결과입니다.

하지만 투자효과를 설명하기에는 부족할 수 있습니다.

Capability와 Outcome을 구분해야 합니다

Capability	Outcome
Duplicate Detection	중복 Supplier로 인한 Rework 감소
Validation Workflow	First-Time-Right 증가
Standard Attribute	Downstream Mapping 예외 감소
Automated Approval	Master Creation Lead Time 감소

조기경보

프로젝트 착수 시점에 Baseline이 없다면 이미 경고신호입니다.

Go-Live 이후 개선효과를 주장해도 비교기준이 없기 때문입니다.

복구조치

이미 구축이 진행 중이라면 가능한 시점부터 Baseline을 확보합니다.

예를 들면:

Duplicate 발생량
Master 생성 Lead Time
Rework 비율
First-Time-Right
Quality Exception
Manual Steward Effort
Consumer Incident

그리고 기술 KPI와 Business KPI를 연결합니다.

Recovery Gate

다음 투자 또는 Domain 확장 전에 최소 하나 이상의 Business Outcome 개선이 Baseline 대비 측정 가능해야 합니다.

7개 패턴은 서로 독립적으로 발생하지 않는다

실제 프로젝트에서는 하나의 문제가 다른 실패를 만들어냅니다.

Technology First
↓
Business 참여 부족
↓
Ownership 불명확
↓
Big Bang Scope
↓
운영모델 준비 지연
↓
Go-Live 이후 품질 재악화
↓
성과 입증 실패
↓
예산 및 신뢰 저하

따라서 하나의 증상만 고치는 것으로 충분하지 않을 수 있습니다.

예를 들어 Steward 인력만 늘려도 Data Owner의 Decision Rights가 없으면 중요한 Issue는 계속 적체될 수 있습니다.

실패 프로젝트를 복구할 때 무엇부터 해야 하는가

여러 Failure Pattern이 동시에 발견되었다면 모든 문제를 동시에 해결하려 하지 않는 것이 좋습니다.

복구 순서는 보통 다음 논리가 유용합니다.

1. STOP UNCONTROLLED EXPANSION
범위 추가를 일시적으로 통제

↓

2. RECONFIRM BUSINESS PURPOSE
MDM이 해결할 Business Problem 재확인

↓

3. ASSIGN DECISION RIGHTS
Owner와 핵심 Decision Authority 확정

↓

4. DEFINE MINIMUM OPERATING MODEL
Steward · Issue · Exception · Quality 운영정의

↓

5. ESTABLISH BASELINE
성과측정 기준 확보

↓

6. PROVE ONE END-TO-END OUTCOME
실제 Process에서 개선 입증

↓

7. RESUME SCALE
검증된 Pattern 기반 확장

이 순서는 고정된 산업표준이 아니라 구조적인 의존관계를 고려한 practitioner approach입니다.

MDM Recovery Board — 프로젝트 상태를 이렇게 보면 더 유용하다

영역	확인할 Evidence	경고 신호
Purpose	Business Problem / Target Outcome	Technology objective만 존재
Scope	Domain / Entity / System Boundary	계속 범위가 증가
Ownership	Decision Rights Matrix	Owner 이름만 있고 권한은 불명확
Business Adoption	실제 사용자 Test / Exception Case	현업 참여가 Sign-off 중심
Operations	Steward / Issue / Exception / KPI	Go-Live 후 운영모델이 미정
Value	Baseline / Benefit Owner / Outcome KPI	기술지표만 보고

MDM Recovery Board는 Digital Future & Strategy practitioner framework입니다.

AI와 Agentic MDM이 실패 패턴을 없애 주지는 않는다

AI는 MDM 실패를 해결할 수 있는 강력한 도구가 될 수 있습니다.

예를 들어 AI Agent가:

Duplicate 후보를 탐색하고,
품질오류를 분류하고,
누락속성을 제안하고,
Steward에게 Case를 Routing하고,
일부 반복검증을 자동화할 수 있습니다.

하지만 기존 Governance가 불명확하면 AI는 그 문제를 해결하기보다 확대할 수도 있습니다.

Owner가 불명확한 상태에서 AI에게 Merge 권한을 주거나, Business Rule이 합의되지 않은 상태에서 자동승인을 확대하면 속도만 빨라질 뿐입니다.

BAD GOVERNANCE
×
FASTER AUTOMATION
=
FASTER PROPAGATION OF BAD DECISIONS

Agentic MDM의 선행조건은 AI 기능이 아니라 명확한 Entity, Policy, Owner, Decision Rights와 Audit입니다.

MDM 프로그램을 점검할 14가지 질문

1. 플랫폼 이름을 빼고도 이 MDM 프로젝트의 Business Purpose를 설명할 수 있는가?

2. 첫 Release가 독립적인 Business Outcome을 만들 수 있는 범위인가?

3. Scope가 증가할 때 무엇을 제외할지 결정하는 기준이 있는가?

4. Business Sponsor가 실제 Decision Authority를 가지고 있는가?

5. Data Owner가 이름뿐 아니라 결정할 사안을 알고 있는가?

6. 현업 실무자가 Data Standard와 Workflow를 실제 Case로 검증했는가?

7. 예외 Process가 설계되어 있는가?

8. Go-Live 전에 Steward 운영모델이 활성화되는가?

9. 반복되는 Data Issue를 Root Cause까지 개선하는가?

10. 프로젝트 전 Baseline이 존재하는가?

11. Data Quality KPI가 Business Outcome과 연결되는가?

12. 첫 Domain의 성공을 증명하기 전에 다음 Domain을 확장하고 있지는 않은가?

13. AI 자동화의 권한경계와 Human Approval 조건이 명확한가?

14. 프로젝트가 종료되어도 MDM 운영체계가 계속 작동할 수 있는가?

MDM 실패의 본질

MDM 프로젝트가 실패하는 이유를 Technology 하나로 설명하기는 어렵습니다.

Matching Algorithm이 부족해서 실패할 수도 있고 Integration이 복잡해서 어려움을 겪을 수도 있습니다.

그러나 더 구조적인 문제는 대개 Technology 바깥에서 시작됩니다.

Strategy Without Scope
↓
Technology Without Ownership
↓
Standards Without Business Participation
↓
Go-Live Without Operations
↓
Investment Without Measurement

반대로 성공적인 MDM 프로그램은 모든 문제를 처음부터 완벽하게 해결하는 프로그램이 아닙니다.

중요한 것은 문제가 발견되었을 때 이를 수정할 수 있는 구조가 존재하는 것입니다.

명확한 Business Purpose가 있고, 의사결정권자가 있으며, 운영조직이 데이터를 지속적으로 관리하고, 결과를 측정한다면 기술적 문제는 개선할 수 있습니다.

하지만 이 구조가 없으면 좋은 MDM 플랫폼을 도입하더라도 시간이 지날수록 신뢰를 잃을 가능성이 높습니다.

MDM의 가장 큰 실패는 시스템 구축 실패가 아닙니다. 시스템은 정상적으로 동작하지만 현업이 다시 Excel과 기존 시스템을 더 신뢰하기 시작하는 상태입니다.

Sources & Further Reading

Method Note
이 글의 7가지 실패 패턴은 MDM 프로젝트를 조기에 점검하기 위한 Digital Future & Strategy practitioner diagnostic입니다. 특정 시장조사기관의 통계적 failure model이나 MDM 프로젝트 실패확률을 의미하지 않습니다. IBM, DAMA 및 Informatica의 공개 자료는 MDM이 technology뿐 아니라 governance, stewardship, data model, lifecycle process 및 business accountability를 필요로 한다는 외부 참고자료로 활용했습니다. Failure Pattern, Early Warning Signal, Recovery Gate, Recovery Sequence 및 MDM Recovery Board는 실무 적용을 위해 구성한 practitioner frameworks입니다. 기업별 프로젝트 범위, 조직구조, 데이터 도메인, 규제환경 및 delivery capacity에 맞춰 조정해야 합니다.

Reviewed: September 2026

Global English Companion

글로벌 독자를 위한 영문판에서는 동일한 7개 패턴을 Enterprise MDM 전반의 관점에서 별도로 설명합니다.

MDM #8. Seven Failure Patterns in Enterprise MDM Adoption

영문판은 글로벌 MDM adoption pattern을 설명하는 데 초점을 두고, 본 한국어판은 조기경보 신호와 실패 프로젝트의 Recovery Gate 및 복구순서를 보다 구체적으로 다룹니다.

다음 글: 한국 대기업 MDM 거버넌스의 현실