MDM #4. Self-Healing Master Data: 자동 수정이 아니라 통제된 복구 시스템을 설계하는 방법

마스터 데이터 품질관리는 오랫동안 사람이 중심이었습니다.

품질 Rule이 오류를 발견하면 Data Steward가 원인을 확인하고, 올바른 값을 찾은 뒤, 승인 절차를 거쳐 수정했습니다.

AI와 자동화 기술이 발전하면서 새로운 질문이 등장하고 있습니다.

“마스터 데이터 오류를
시스템이 스스로 찾아서
스스로 고칠 수 있는가?”

가능한 영역은 분명히 늘고 있습니다.

하지만 이 질문 자체가 조금 잘못되어 있습니다.

Enterprise MDM에서 더 중요한 질문은 다음입니다.

어떤 오류를 자동으로 수정해도 되는가?
어떤 Evidence가 있어야 하는가?
잘못 수정했을 때 어떻게 발견하고 되돌릴 것인가?
같은 오류가 다시 생기지 않도록 무엇을 바꿀 것인가?

Self-Healing Master Data의 핵심은 AI가 데이터를 마음대로 수정하는 것이 아닙니다. 오류를 더 빨리 발견하고, 근거가 충분한 변경만 통제된 방식으로 실행하며, 결과를 검증하고 필요하면 되돌리고, 같은 오류의 재발원인을 제거하는 것입니다.

이 글에서는 Self-Healing Master Data를 완전자율 데이터 관리가 아니라 Controlled Data Recovery Loop라는 관점에서 설계합니다.

1. Self-Healing Master Data를 다시 정의해야 한다

기존 글에서는 Self-Healing을 “오류가 생기기 전에 예방하고 생기면 즉시 자동치유하는 자율복구”로 정의했습니다.

이 표현은 방향성은 이해하기 쉽지만 실제 Enterprise 환경에서는 지나치게 강합니다.

보다 현실적인 정의는 다음과 같습니다.

Self-Healing Master Data

마스터 데이터 품질문제를 탐지하고,
원인과 영향을 분석하며,
신뢰할 수 있는 Evidence를 기반으로 수정안을 결정하고,
허용된 범위에서는 자동으로 복구하며,
수정 결과를 다시 검증하고,
오류 재발을 줄이도록 Rule·Process·Model을 개선하는 운영 패턴.

여기서 중요한 것은 자동화 수준이 오류 유형과 Business Risk에 따라 달라진다는 점입니다.

Self-Healing과 완전자율은 같은 뜻이 아니다

개념	설명	Enterprise MDM에서의 의미
Automated Validation	Rule로 오류 여부를 자동 판정	이미 널리 가능한 영역
Automated Derivation	명확한 Rule이나 Source를 이용해 값을 자동 산출	근거가 명확할 때 높은 자동화 가능
AI-Assisted Remediation	AI가 원인과 수정안을 제안	사람의 판단을 줄이거나 가속
Controlled Auto-Repair	정책상 허용된 저위험 Case를 자동수정	Self-Healing의 핵심 실행영역
Autonomous Governance	AI가 중요한 Business Rule과 Data Policy까지 독립적으로 결정	일반적인 목표로 삼기에는 부적절

2. Self-Healing은 반드시 실시간일 필요가 없다

기존 글에서는 “배치 처리 기반에서는 Self-Healing이 불가능하다”고 설명했습니다.

이 부분은 수정해야 합니다.

Self-Healing의 핵심은 처리 주기가 아니라 Detection과 Recovery Loop가 자동화·통제되어 있는가입니다.

업무 요구에 따라 다음 모두 가능할 수 있습니다.

Pattern	적합한 상황	예시
Transaction-Time	잘못된 데이터의 생성 자체를 즉시 차단해야 함	필수값·Reference Code 검증
Event-Driven	변경 직후 빠른 확인이 필요	Supplier Status 변경 검증
Micro-Batch	낮은 지연과 처리효율의 균형이 필요	대규모 Product Attribute 품질검사
Scheduled Batch	즉시성이 중요하지 않은 대량 검증	주기적 inactive record·hierarchy 검사

SAP MDG의 현재 Data Quality Management도 validation rule을 이용한 평가를 주기적으로 실행할 수 있으며, 오류를 분석하고 correction을 시작할 수 있도록 설계되어 있습니다.

SAP Help — Working with MDG, Data Quality Management

즉 “Self-Healing = Streaming”은 아닙니다.

Business Freshness Requirement가 처리방식을 결정해야 합니다.

3. 가장 중요한 변화: Detect–Heal 2단계가 아니라 7단계 Control Loop

자동수정을 안전하게 운영하려면 “오류 발견 → 바로 수정” 구조를 피해야 합니다.

1. DETECT
오류·이상징후 탐지

↓

2. DIAGNOSE
원인·영향·관련 Entity 분석

↓

3. RECOMMEND
수정후보와 Evidence 생성

↓

4. AUTHORIZE
Policy에 따라 자동실행 또는 승인요청

↓

5. REPAIR
변경·격리·복구 실행

↓

6. VERIFY
수정 후 데이터와 Downstream 영향 검증

↓

7. LEARN & PREVENT
재발원인 제거와 Rule·Model 개선

이 7단계 Controlled Healing Loop는 Digital Future & Strategy practitioner framework입니다.

4. Detect — 먼저 Signal과 Error를 구분한다

Quality Rule이 실패했다고 항상 데이터가 틀린 것은 아닙니다.

다음 가능성이 있습니다.

실제 데이터 오류,
허용된 Business Exception,
오래된 Validation Rule,
잘못된 Reference Data,
Source System 변경,
신규 Business Process,
Detection Model의 False Positive.

따라서 Self-Healing 시스템이 가장 먼저 해야 할 일은 무조건 수정하는 것이 아니라 신뢰할 수 있는 Issue를 식별하는 것입니다.

SAP MDG도 Validation Rule과 Data Quality KPI를 정의하고 평가 결과를 통해 오류영역과 가능한 원인을 분석한 뒤 correction을 시작하도록 구성합니다.

Detection Source는 여러 종류가 될 수 있다

Detection	예시
Deterministic Rule	Country Code가 허용 목록에 없음
Cross-Field Rule	Entity Type과 Tax Classification 조합 불일치
Reference Check	폐기된 Product Category 사용
Anomaly Detection	평소와 다른 대량속성 변경
Entity Resolution	기존 Supplier와 중복 가능성이 높은 신규 레코드
Consumer Feedback	ERP Transaction에서 Master 오류 발생

5. Diagnose — AI가 가장 유용할 수 있는 영역

실제 Data Steward 업무에서 많은 시간이 드는 것은 오류 자체를 찾는 것보다 왜 틀렸는지를 조사하는 과정입니다.

예를 들어 Supplier Country가 잘못되었다면 다음을 확인해야 할 수 있습니다.

누가 변경했는가?
어떤 Source에서 들어왔는가?
기존 값은 무엇이었는가?
외부 Authoritative Source는 무엇을 말하는가?
다른 시스템에서는 어떤 값인가?
이 값에 의존하는 Process는 무엇인가?

AI Agent와 LLM은 이러한 Evidence를 모으고 요약하는 과정에서 상당한 도움을 줄 수 있습니다.

하지만 LLM 자체가 Master Data의 authoritative source가 되는 것은 아닙니다.

Diagnosis Output은 “정답”보다 Evidence Package여야 한다

Issue
Supplier Country가 KR에서 SG로 변경됨

Current Value
SG

Previous Value
KR

Source Evidence
ERP A = KR / Procurement Portal = KR / Incoming File = SG

Change Origin
External File Interface

Business Impact
Tax and purchasing validation affected

Recommended Action
Restore KR and investigate source mapping

Confidence
Evidence strength based on approved sources — not merely an LLM score

6. Recommend — 수정값과 수정근거를 분리한다

AI 시스템이 다음과 같이 말하는 것은 충분하지 않습니다.

Recommended Country = KR
Confidence = 97%

왜 97%인지 알 수 없으면 실제 Governance에는 거의 도움이 되지 않습니다.

보다 중요한 것은 다음입니다.

Proposed Value: KR

Evidence:
Validated government registration source
+ Current procurement contract
+ Two internal authoritative systems

Conflicting Evidence:
One external interface file = SG

Recommended Policy:
Restore previous value and quarantine incoming mapping rule

Self-Healing의 신뢰성은 AI Confidence Score보다 Evidence Quality에 더 크게 좌우될 수 있습니다.

7. Authorize — 자동화 여부는 Confidence Percentage 하나로 결정하지 않는다

기존 글에서는 95% 이상은 자동처리, 80~94%는 사람 검토처럼 고정 Threshold를 사용했습니다.

이러한 숫자를 모든 Domain에 적용할 수는 없습니다.

동일한 99% Confidence라도:

제품 설명의 대소문자를 수정하는 것과
Supplier Legal Identity를 Merge하는 것과
Payment Block을 해제하는 것

은 위험도가 전혀 다릅니다.

Automation Decision Gate

Gate	질문
Evidence	수정값을 지지하는 Authoritative Source 또는 Deterministic Rule이 있는가?
Reversibility	잘못 수정됐을 때 원래 상태로 안전하게 돌아갈 수 있는가?
Blast Radius	몇 개 Process·System·Transaction이 영향을 받는가?
Business Criticality	재무·계약·Identity·Compliance·Safety에 영향을 주는가?
Conflict	Source들 사이에 상충된 Evidence가 존재하는가?
Accountability	결과에 책임질 Data Owner와 Escalation Path가 있는가?

Automation Decision Gate는 Digital Future & Strategy practitioner framework입니다.

8. 오류 유형보다 “Correction Characteristics”가 중요하다

Case	권장 처리	이유
Formatting	Rule 기반 Auto-Repair 가능	결정적이고 검증·복구가 쉬움
Authoritative Mapping	통제된 자동수정 가능	Target Value가 명확함
Missing Value	신뢰 가능한 Source가 있을 때만 자동보완	AI 추정으로 Master Fact를 만들어서는 안 됨
Duplicate Candidate	Evidence와 Impact에 따라 자동·검토 분리	False Merge 비용이 클 수 있음
Legal / Tax Identity	Authoritative Evidence + 강화된 승인	Identity와 거래에 직접 영향
Strategic Classification	Human Decision 중심	정답이 데이터 자체에 존재하지 않을 수 있음

즉 “형식 오류는 자동, Business Rule은 수동”처럼 단순 분류하는 것보다 Evidence, Reversibility와 Impact를 함께 평가하는 것이 더 정확합니다.

9. Repair에는 Update뿐 아니라 Quarantine도 포함된다

Self-Healing을 “잘못된 값을 올바른 값으로 변경한다”는 의미로만 보면 범위가 너무 좁습니다.

오류 상황에서 시스템이 취할 수 있는 Action은 여러 종류입니다.

CORRECT
잘못된 값을 수정

QUARANTINE
확신이 없을 때 전파 중단

REVERT
직전 정상 Version으로 복구

BLOCK
추가 Transaction 또는 변경 차단

ESCALATE
Owner / Steward에게 의사결정 요청

특히 수정값이 명확하지 않은 상황에서는 잘못된 자동수정보다 안전한 격리가 더 나은 Healing Action일 수 있습니다.

10. Verify — 수정했다고 끝난 것이 아니다

자동수정 시스템에서 가장 빠지기 쉬운 단계가 Verification입니다.

예를 들어 Country Code를 KR로 수정했다고 하더라도 확인해야 할 사항이 있습니다.

Validation Rule을 다시 통과했는가?
관련 Tax Attribute와 충돌하지 않는가?
ERP와 다른 Consumer에도 정상적으로 전달됐는가?
같은 오류가 Interface에서 다시 들어오지 않는가?
수정 이후 새로운 Business Exception이 발생하지 않았는가?

따라서 Healing 성공의 정의는:

Write Successful

이 아니라:

Correction Applied
+ Validation Passed
+ Consumer State Verified
+ No New Critical Exception

가 되어야 합니다.

11. Rollback은 Self-Healing의 선택기능이 아니다

자동화가 확대될수록 잘못된 수정이 발생할 가능성을 0으로 만들 수는 없습니다.

따라서 Self-Healing Architecture에서 중요한 것은 오류를 절대 내지 않는 것이 아니라 오류를 발견했을 때 안전하게 복구할 수 있는가입니다.

MDM에서 필요한 정보는 최소한 다음과 같습니다.

Previous State	변경 전 값
New State	자동수정 후 값
Evidence	왜 수정했는지
Policy	어떤 자동화 Rule이 허용했는지
Actor	사용자·Agent·Service Identity
Downstream State	어디까지 변경이 전파되었는지

SAP MDG의 현재 remediation 기능도 선택된 Master Data를 검증·수정하고 관련 Audit Trail을 표시할 수 있도록 제공합니다.

SAP Help — Manage Remediation Processes

12. Learn은 “AI가 스스로 Rule을 바꾼다”는 뜻이 아니다

기존 Self-Healing 개념에서 “학습”은 매력적이지만 위험하게 해석될 수 있습니다.

Steward가 수정결정을 내릴 때마다 AI가 즉시 학습하고 Production Rule을 자동변경하는 구조는 Governance 측면에서 문제가 될 수 있습니다.

더 안전한 구조는 다음과 같습니다.

Resolution History
↓
Pattern Discovery
↓
Candidate Rule / Model Change
↓
Offline Evaluation
↓
Owner Review
↓
Controlled Deployment
↓
Production Monitoring

SAP MDG의 Rule Mining 역시 Machine Learning을 사용해 새로운 Data Quality Rule 후보를 발견하지만, 발견된 Rule을 사람이 평가하고 Validation Rule로 반영하는 구조입니다.

SAP Help — Rule Mining and Data Quality Management

이것이 Enterprise Self-Healing에서 더 현실적인 Learning Model입니다.

13. 가장 높은 단계의 Healing은 Record Correction이 아니라 Root Cause Prevention이다

같은 오류를 매일 자동으로 고치고 있다면 시스템은 효율적으로 작동할 수 있습니다.

하지만 그것이 반드시 좋은 상태는 아닙니다.

예를 들어 매일 500개의 Product Record에서 잘못된 Unit Code를 자동으로 EA로 바꾸고 있다고 가정해 보겠습니다.

진짜 해결책은 매일 500건을 자동수정하는 것이 아니라:

Why Are 500 Wrong Records Created Every Day?

를 찾아내는 것입니다.

원인은 다음일 수 있습니다.

Source UI에 Validation이 없음,
Interface Mapping이 잘못됨,
Reference Data가 동기화되지 않음,
교육이 부족함,
Business Rule 자체가 오래됨.

Self-Healing의 3단계 가치

LEVEL 1 — RECOVER
잘못된 데이터를 정상상태로 복구

↓

LEVEL 2 — CONTAIN
오류가 Business Process로 확산되지 않도록 차단

↓

LEVEL 3 — PREVENT
오류를 만드는 Source Process 자체를 개선

가장 성숙한 Self-Healing은 자동수정 건수가 계속 증가하는 시스템이 아니라 같은 유형의 수정 필요성이 감소하는 시스템입니다.

14. Detailed Scenario — Supplier Country 오류

다음은 설명을 위한 가상 시나리오입니다.

Step 1 — Detect

Supplier A의 Country가 KR에서 SG로 변경되었습니다.

Rule Engine이 다음 충돌을 감지합니다.

Country = SG
Business Registration Country = KR
Tax Registration Country = KR

Step 2 — Diagnose

Agent가 Change History와 Source를 확인합니다.

Previous MDM Value = KR
ERP A = KR
Procurement Portal = KR
External Interface = SG
Last Change Source = External Interface

Step 3 — Recommend

Approved Authoritative Sources가 모두 KR을 지지한다는 Evidence를 생성합니다.

추천조치는:

Restore Country = KR
Quarantine incoming SG update
Open interface mapping issue

Step 4 — Authorize

Country 변경이 Tax Process에 영향을 줄 수 있으므로 해당 기업의 Policy에서는 자동실행 대신 Steward Approval을 요구한다고 가정합니다.

Step 5 — Repair

승인 후 Country를 KR로 복구합니다.

Step 6 — Verify

Validation Rule을 다시 실행하고 ERP·Procurement Consumer의 상태를 확인합니다.

Step 7 — Prevent

External Interface Mapping의 Root Cause를 수정합니다.

이 마지막 단계가 빠지면 동일 오류가 다음날 다시 들어옵니다.

15. Self-Healing Reference Architecture

SOURCE SYSTEMS
ERP · CRM · SCM · PIM · SaaS · External Sources

↓

CHANGE INTAKE
Transaction · API · Event · CDC · Batch

↓

DETECTION LAYER
Validation Rule · DQ Check · Anomaly · Entity Resolution

↓

EVIDENCE & CONTEXT
History · Provenance · Reference Data · Relationships · Lineage

↓

DECISION LAYER
Rules · AI Assistance · Policy · Risk Classification

↓

ACTION LAYER
Recommend · Approve · Repair · Quarantine · Revert · Escalate

↓

VERIFICATION
Re-Validate · Reconcile · Consumer Check

↓

FEEDBACK & PREVENTION
Root Cause · Rule Improvement · Model Evaluation · Process Change

이 Architecture에서 LLM은 여러 구성요소 중 하나일 뿐입니다.

Self-Healing의 핵심 Control은 오히려:

Authoritative Evidence,
Policy,
Versioning,
Approval,
Audit,
Verification,
Rollback

에 있습니다.

16. Data Steward Agent와 역할을 구분해야 한다

#3에서 다룬 Data Steward Agent는 여러 MDM 업무를 분석·추천·Routing하는 업무 주체에 가깝습니다.

Self-Healing은 그 Agent가 사용할 수 있는 하나의 Data Quality Control Loop입니다.

DATA STEWARD AGENT
Who analyzes and orchestrates work?

versus

SELF-HEALING CONTROL LOOP
How is a data defect safely recovered?

두 개념을 분리하면 #3과 #4의 중복도 줄어듭니다.

17. Entity Resolution과도 역할이 다르다

#5의 Entity Resolution은:

“이 두 레코드는 같은 실제 Entity인가?”

를 판단합니다.

Self-Healing은 더 넓은 문제를 다룹니다.

“이 Master State가 잘못되었는가?
그렇다면 어떻게 안전하게 복구할 것인가?”

Entity Resolution은 Self-Healing의 Detection 또는 Diagnosis 단계에서 사용될 수 있지만 두 개념은 동일하지 않습니다.

18. “전체 오류의 60~70% 자동화” 같은 목표를 두지 않는다

기존 글에서는 전체 Master Data 오류의 60~70%를 자동치유할 수 있다는 목표를 제시했습니다.

보편적으로 적용할 근거는 없습니다.

자동화 가능성은 다음에 따라 크게 달라집니다.

Domain,
오류 유형,
Authoritative Source 존재 여부,
Historical Resolution Quality,
Reversibility,
Business Impact,
Regulatory Requirement,
Risk Tolerance.

예를 들어 Product Description 표준화는 높은 자동화가 가능할 수 있지만 Supplier Legal Entity 변경은 거의 항상 더 강한 Governance가 필요할 수 있습니다.

따라서 Automation Rate 자체를 목표 KPI로 만들면 잘못된 Incentive를 만들 수 있습니다.

19. Self-Healing KPI도 바뀌어야 한다

Metric Family	측정 예시
Detection	False Positive, Missed Issue, Time to Detect
Decision Quality	Steward Approval / Rejection, Evidence Completeness
Correction	Successful Repair, Post-Repair Validation Failure
Recovery	Rollback Rate, Rollback Success, Downstream Recovery Time
Operations	Issue Backlog, Review Aging, Mean Time to Resolve
Prevention	Same-Defect Recurrence, Root-Cause Closure
Business	Downstream Exception, Rework, Data Freshness, Process Delay

가장 중요한 KPI는 Recurrence Rate일 수 있다

자동수정량이 계속 증가하는 것은 시스템이 좋아지고 있다는 뜻일 수도 있지만, Source Process가 계속 잘못된 데이터를 만들고 있다는 뜻일 수도 있습니다.

따라서 다음을 함께 봐야 합니다.

Healing Volume ↑

but

Same Error Recurrence ↓ ?

반복오류가 줄지 않는다면 Self-Healing이 Root Cause를 가리고 있을 가능성도 검토해야 합니다.

20. AI Risk Management를 Self-Healing에도 적용해야 한다

AI가 자동수정 또는 수정추천에 관여한다면 Data Quality 문제뿐 아니라 AI Risk Management 관점도 필요합니다.

NIST AI Risk Management Framework는 AI 시스템의 설계·개발·사용·평가 전반에서 Trustworthiness와 Risk를 관리할 수 있도록 voluntary framework를 제공합니다.

NIST — AI Risk Management Framework

NIST의 Generative AI Profile 역시 AI Lifecycle 전반에서 risk를 Govern, Map, Measure, Manage하는 접근을 제시합니다.

NIST — Generative AI Profile

이를 Self-Healing MDM에 적용하면 최소한 다음을 확인할 수 있습니다.

AI의 역할과 권한이 명확한가?
AI 제안의 정확도를 지속적으로 측정하는가?
학습·Prompt·Model 변경이 통제되는가?
중요 변경은 사람이 Challenge할 수 있는가?
자동수정 이력이 재현 가능한가?

21. 단계적 도입은 기간이 아니라 Exit Criteria로 운영한다

“1~3개월 탐지 → 3~6개월 추천 → 6~12개월 자동화”와 같은 고정기간을 모든 기업에 적용할 근거는 없습니다.

보다 안전한 방식은 Evidence Gate입니다.

Stage	목표	Exit Criteria 예시
Observe	수정 없이 탐지·분류·Baseline 확보	오류 Taxonomy와 Severity가 안정화
Recommend	AI/Rule이 수정안을 만들고 사람이 승인	Evidence와 Recommendation Quality를 측정 가능
Automate	저위험·가역적 Case 자동처리	Rollback·Monitoring·Owner가 검증됨
Expand	추가 Error Type과 Domain으로 확대	Post-Repair Defect와 Business Incident가 허용수준 내 안정
Prevent	Upstream Process 개선까지 연결	반복오류 자체가 지속적으로 감소

단계와 Exit Criteria는 Digital Future & Strategy practitioner framework이며 고정된 산업표준이나 기간모델이 아닙니다.

22. Self-Healing Readiness를 점검할 15가지 질문

1. 자동수정하려는 오류를 정확하게 정의할 수 있는가?

2. 오류와 허용된 Business Exception을 구분할 수 있는가?

3. 올바른 수정값을 제공할 Authoritative Source가 있는가?

4. Detection False Positive를 측정하고 있는가?

5. AI Recommendation과 실제 Evidence를 구분하고 있는가?

6. 자동화 Threshold가 외부 사례가 아니라 자사 검증데이터로 결정되었는가?

7. Correction의 Business Impact와 Blast Radius를 알고 있는가?

8. High-Risk Attribute에 Human Approval이 필요한 조건이 정의되어 있는가?

9. 자동수정 이전 상태를 보존하는가?

10. 잘못된 수정의 Rollback을 실제로 테스트했는가?

11. 수정 후 Downstream Consumer까지 검증하는가?

12. Agent·User·Service 중 누가 변경했는지 Audit 가능한가?

13. Feedback을 Production Rule에 반영하기 전 Offline Evaluation을 수행하는가?

14. 반복되는 오류의 Root Cause를 추적하는가?

15. 자동화율보다 Recurrence와 Business Exception 감소를 보고 있는가?

Self-Healing Master Data가 지향해야 할 것

Self-Healing Master Data를 “사람 없이 데이터가 스스로 완벽해지는 기술”로 이해하면 현실과 멀어집니다.

Enterprise Master Data에는 기술적으로 결정 가능한 오류도 있지만, 조직의 Business Policy와 책임 있는 판단이 필요한 문제가 함께 존재하기 때문입니다.

따라서 목표는:

Human-Free MDM

이 아니라:

EARLIER DETECTION
×
BETTER EVIDENCE
×
RISK-BASED AUTOMATION
×
REVERSIBLE CHANGE
×
POST-REPAIR VERIFICATION
×
ROOT-CAUSE PREVENTION
=
CONTROLLED SELF-HEALING

AI는 이 과정에서 매우 중요한 역할을 할 수 있습니다.

오류를 분류하고, Evidence를 모으고, 원인을 설명하고, 수정안을 제안하고, Workflow를 조정할 수 있습니다.

하지만 중요한 Master Data의 최종 신뢰성은 여전히:

Authoritative Source,
Business Rule,
Data Ownership,
Policy,
Auditability,
Reversibility

에 의해 만들어집니다.

Self-Healing의 성숙도를 평가할 때도 “몇 %를 자동수정했는가”보다 다음 질문이 더 중요합니다.

잘못된 데이터를 더 빨리 발견했는가?
잘못된 자동수정은 감소했는가?
수정 결과를 설명할 수 있는가?
문제가 생기면 안전하게 되돌릴 수 있는가?
Downstream까지 정상화되었는가?
그리고 같은 오류가 다시 생기는 빈도가 줄었는가?

Self-Healing의 최종 목적은 더 많은 오류를 자동으로 고치는 것이 아닙니다. 오류가 만들어지고 확산되고 반복되는 구조 자체를 점점 줄여 가는 것입니다.

Sources & Further Reading

Method Note
이 글은 Self-Healing Master Data를 완전자율 AI 기술이 아니라 통제된 Data Quality Recovery Operating Model로 정의합니다. SAP 공식 문서는 Validation Rule, Rule Mining, Data Quality Evaluation, Remediation 및 Audit 기능이 실제 MDM 제품에서 어떻게 구현될 수 있는지를 확인하기 위한 참고자료로 사용했습니다. NIST AI RMF는 AI가 자동수정 또는 수정추천에 사용될 때 Risk Management와 Lifecycle Control을 고려하기 위한 일반 프레임워크로 참조했습니다. 기존 글에 포함되어 있던 전체 오류 60~70% 자동화, 3~6개월 학습기간, 95% Auto-Merge Threshold, 65% 수작업 감소, 3일→4시간, 중복률 12%→2%, 발주오류 40% 감소 등의 미검증 일반화 수치는 제거했습니다. 7-Step Controlled Healing Loop, Automation Decision Gate, Recovery–Contain–Prevent Model과 Evidence-Gated Roadmap은 Digital Future & Strategy practitioner frameworks이며 특정 벤더 또는 산업의 공식 표준이 아닙니다.

Reviewed: September 2026

MDM Strategy Series

Part 1 — AI & Agentic MDM

MDM #3. 에이전틱 데이터 관리: Data Steward Agent의 역할과 미래
MDM #4. Self-Healing Master Data: 자동 수정이 아니라 통제된 복구 시스템을 설계하는 방법
MDM #5. 지식 그래프 기반 엔티티 해상도

Global English Companion

글로벌 독자를 위한 영문판에서는 Self-Healing Master Data의 기본 운영모델과 단계적 자동화 구조를 별도로 다룹니다.

MDM #4. Self-Healing Master Data: How AI Detects and Repairs Errors

영문판은 Detect–Diagnose–Heal–Learn 모델과 일반적인 자동화 통제를 설명하고, 본 한국어판은 Authorize·Verify·Rollback·Root-Cause Prevention까지 확장한 운영 통제모델에 더 초점을 둡니다.

이전 글: Data Steward Agent의 역할과 미래

다음 글: 지식 그래프 기반 엔티티 해상도