MDM #3. Data Steward Agent 설계: AI에게 어떤 MDM 업무와 권한을 맡길 것인가
Data Steward는 Master Data Management에서 가장 중요한 역할 중 하나입니다.
중복 후보를 검토하고, 잘못된 속성을 확인하고, Change Request를 처리하고, Business Rule을 적용하며, 데이터 오류의 원인을 추적합니다.
하지만 모든 Steward 업무가 같은 종류의 판단을 요구하는 것은 아닙니다.
어떤 업무는 명확한 Rule에 따라 반복됩니다.
어떤 업무는 여러 Source와 History를 조사해야 합니다.
또 어떤 업무는 Supplier를 하나로 Merge할 것인지, 새로운 Enterprise Standard를 허용할 것인지처럼 Business 책임자가 판단해야 합니다.
AI Agent가 MDM에 들어오면서 중요한 질문은 따라서 다음이 아닙니다.
더 중요한 질문은:
Agent는 어떤 Evidence를 사용할 수 있는가?
어떤 Tool을 실행할 수 있는가?
어디까지 자동실행하고 어디서 사람에게 넘길 것인가?
그리고 모든 판단을 나중에 재구성할 수 있는가?
입니다.
Agentic MDM의 핵심은 사람을 없애는 것이 아니라, 사람과 Agent 사이의 Decision Rights를 다시 설계하는 것입니다.
1. Agentic Data Management는 아직 하나의 표준제품 개념이 아니다
Agentic Data Management라는 용어는 빠르게 확산되고 있지만, 모든 벤더와 기관이 동일하게 정의하는 공식 산업표준은 아닙니다.
2026년 현재 실제 제품과 Roadmap에서는 MDM 및 Data Management에 AI Agent가 직접 참여하는 방향이 분명하게 나타나고 있습니다.
예를 들어 Reltio AgentFlow는 AI Agent가 Live Master Data를 조회·검증·관리하고, 허용된 Tool을 통해 Search, Match, Merge 등의 Action을 수행하는 구조를 제공합니다.
Reltio 문서에 따르면 이러한 Agent Action은 사용자의 RBAC, Attribute Masking 및 Audit Policy를 따르며 Tool Call도 기록됩니다.
Informatica from Salesforce 역시 2026년 5월 Agentic Multidomain MDM과 Data Steward Agent를 발표했으며, Data Quality Issue와 Record Matching 같은 Stewardship 업무 자동화를 주요 방향으로 제시했습니다.
다만 해당 발표에서 Agentic Multidomain MDM과 Data Steward Agent의 Availability는 Q4 2026으로 명시되어 있습니다.
Informatica from Salesforce — Agentic Data Management Announcement
따라서 현 시점에서는:
=
Emerging Operating Pattern
not
One Universal Product Architecture
로 이해하는 것이 적절합니다.
2. Data Steward Agent는 Chatbot이 아니다
MDM 화면에 Chat UI를 추가했다고 Data Steward Agent가 되는 것은 아닙니다.
Agent가 Stewardship 업무를 실제로 수행하려면 최소한 네 가지 능력이 필요합니다.
| Capability | 의미 |
|---|---|
| Context | Entity, Attribute, History, Provenance, Quality Rule과 Business Policy를 이해할 수 있어야 한다. |
| Reasoning | 문제를 분석하고 가능한 조치와 Evidence를 정리할 수 있어야 한다. |
| Tools | Search, Validate, Create Change Request, Match, Merge 등 허용된 MDM Capability를 호출할 수 있어야 한다. |
| Authority | 어떤 Tool을 어떤 Entity·Attribute에 어떤 조건에서 사용할 수 있는지 Policy가 정의되어야 한다. |
즉 Agentic MDM은:
+ Enterprise Context
+ Governed MDM Tools
+ Explicit Authority
+ Human Escalation
+ Audit
의 조합으로 보는 편이 더 정확합니다.
3. Data Steward Agent의 첫 번째 역할은 “판단”보다 “조사”다
Steward 업무에서 많은 시간이 소요되는 부분은 최종 버튼을 누르는 순간이 아닙니다.
결정을 내리기 위해 Evidence를 찾는 과정입니다.
예를 들어 Supplier Duplicate Candidate를 검토한다고 가정해 보겠습니다.
사람은 다음을 확인할 수 있습니다.
- 두 레코드의 Legal Name,
- 사업자 또는 Tax Identifier,
- Address,
- Parent Company,
- Source System,
- 기존 Match History,
- Contract와 Purchase History,
- 과거 Merge/Unmerge 기록.
Agent는 이러한 Evidence 수집과 비교를 빠르게 수행할 수 있습니다.
Find Data
→ Compare Sources
→ Investigate History
→ Interpret Evidence
→ Decide
AGENT-ASSISTED MODEL
Agent Collects & Organizes Evidence
→ Human Reviews Material Evidence
→ Human or Policy Decides
초기 Agentic MDM에서 가장 안전하면서도 가치가 큰 자동화 영역은 이런 Investigation Compression일 수 있습니다.
4. Data Steward Agent가 수행할 수 있는 일
Agent에게 맡길 수 있는 Stewardship 업무는 여러 단계로 나눌 수 있습니다.
① Quality Investigation
Quality Rule 실패건을 조사해:
- 어떤 Rule이 실패했는지,
- 언제부터 발생했는지,
- 어떤 Source에서 유입됐는지,
- 유사 Issue가 과거에 있었는지
정리할 수 있습니다.
SAP MDG의 현재 Data Quality Management도 Validation Rule 평가, 오류영역 분석, Correction Initiation을 지원하며 Rule Mining은 ML로 잠재적인 새로운 Validation Rule을 제안할 수 있습니다.
SAP — MDG Data Quality Management
② Potential Match Investigation
Agent가 Candidate Pair의:
Legal Identifier
Address
Relationships
Source Evidence
Historical Decisions
를 비교해 Steward에게 Decision Package를 제공할 수 있습니다.
다만 “AI Confidence 95%이므로 자동 Merge” 같은 보편 규칙은 적절하지 않습니다.
False Merge의 Business Impact가 Domain마다 다르기 때문입니다.
③ Change Request Preparation
사용자의 자연어 요청을 분석해:
- 대상 Entity 확인,
- 변경할 Attribute 파악,
- 필수 Evidence 수집,
- Validation 실행,
- Change Request 초안 생성
까지 수행할 수 있습니다.
이 경우 Agent가 직접 Master를 수정하지 않아도 Steward 업무시간을 상당 부분 줄일 수 있습니다.
④ Approval Routing
Agent는 Change Type, Attribute Criticality, Region, Data Owner와 Policy를 확인해 적절한 승인 경로를 추천하거나 구성할 수 있습니다.
SAP MDG의 Rule-Based Workflow도 현재 Step, Action, Priority와 Rule을 기반으로 다음 Workflow Step과 Processor를 결정할 수 있습니다.
Agent의 역할은 이러한 deterministic workflow를 없애는 것이 아니라 복잡한 Case에서 Context를 추가하고 Routing 판단을 보조하는 쪽이 더 적절할 수 있습니다.
⑤ Policy and Rule Analysis
반복적으로 발생하는 Steward Decision을 분석해:
- 새로운 Validation Rule 후보,
- 불필요한 Approval Step,
- 반복 Exception,
- Root Cause Pattern
을 제안할 수 있습니다.
다만 Agent가 Enterprise Policy를 독립적으로 바꾸는 것은 다른 문제입니다.
5. Agent의 권한을 Confidence Score 하나로 결정하면 안 된다
기존 Agentic MDM 설계에서는 다음과 같은 구조가 매력적으로 보입니다.
80~94% → 실행 후 검토
60~79% → 사전승인
60% 미만 → Human
그러나 이 구조에는 중요한 문제가 있습니다.
Confidence가 높다는 것과 실행해도 안전하다는 것은 같은 의미가 아닙니다.
다음 두 사례를 비교해 보겠습니다.
| Action | AI Confidence | Business Risk |
|---|---|---|
| Product Description의 공백 정규화 | 99% | 낮고 가역적 |
| 두 Supplier Legal Entity Merge | 99% | 계약·지급·Risk·Compliance에 큰 영향 가능 |
같은 Confidence라도 허용되는 Action은 달라야 합니다.
Agent Authority는 다차원적으로 결정해야 한다
Evidence Strength
×
Action Risk
×
Reversibility
×
Entity / Attribute Criticality
×
Blast Radius
×
User / Agent Permission
×
Policy
=
Allowed Action
이 Agent Authority Model은 Digital Future & Strategy practitioner framework입니다.
6. 권한을 5단계로 나누면 설계가 쉬워진다
| Level | Agent 역할 | 예시 |
|---|---|---|
| 1. Observe | 조회·분석만 가능 | Quality Issue 분석, Duplicate Candidate 조사 |
| 2. Recommend | 사람에게 Action 추천 | “두 Supplier는 동일 후보이며 Legal ID가 일치합니다.” |
| 3. Prepare | 실행 가능한 Transaction 초안 생성 | Change Request 생성, Merge Proposal 준비 |
| 4. Execute | Policy가 허용한 저위험 Action 실행 | 검증된 Reference Code 자동보정 |
| 5. High-Impact Execute | 중요 Business State 변경 | Legal Entity Merge, Critical Status 변경 — 일반적으로 강화된 승인 필요 |
핵심은 Agent마다 하나의 고정 권한을 주는 것이 아닙니다.
동일 Agent도 Action Type에 따라 다른 Authority Level을 가질 수 있습니다.
7. Agent는 사람의 권한을 그대로 상속해서는 안 된다
사용자가 Supplier Master를 수정할 권한이 있다고 해서 사용자를 대신하는 Agent가 모든 Supplier Attribute를 자유롭게 변경할 수 있어야 하는 것은 아닙니다.
사람과 Agent의 권한모델은 구분할 필요가 있습니다.
What may this person do?
×
AGENT AUTHORITY
What may this agent do on the person's behalf?
×
RESOURCE POLICY
Which entity / attribute / action is allowed?
=
EFFECTIVE PERMISSION
Reltio AgentFlow의 현재 문서에서도 Agent는 사용자 Access Level 안에서만 Approved Tool을 사용할 수 있고, 모든 Tool Call은 Access-Controlled 및 Logged 된다고 설명합니다.
Reltio — AgentFlow Security and Governed Tools
8. Data Steward Agent에게 Raw Database 권한을 주지 않는다
Agentic MDM Architecture에서 중요한 설계원칙 중 하나는 Agent가 MDM Database를 직접 수정하지 않도록 하는 것입니다.
Agent는 Governed Business Capability를 호출해야 합니다.
↓
GOVERNED TOOL / API
↓
AUTHORIZATION & POLICY
↓
MDM BUSINESS OPERATION
↓
MASTER DATA
예를 들어 다음 Tool은 위험합니다.
보다 안전한 Tool은 다음과 같이 Business Meaning과 Side Effect가 제한됩니다.
propose_supplier_address_change()
create_supplier_change_request()
get_potential_supplier_matches()
propose_supplier_merge()
Tool 자체가 Governance Boundary가 되는 것입니다.
9. Agent Tool에는 Contract가 필요하다
Agent가 사용할 수 있다는 이유만으로 API를 그대로 Tool로 노출해서는 안 됩니다.
각 Tool에는 최소한 다음이 정의되어야 합니다.
| Purpose | 무엇을 위한 Tool인가? |
| Input | 어떤 입력을 허용하는가? |
| Output | 어떤 Evidence와 Result를 반환하는가? |
| Authority | 어떤 Role/Agent가 실행 가능한가? |
| Precondition | 실행 전에 무엇이 충족돼야 하는가? |
| Side Effect | Master Data가 실제로 변경되는가? |
| Reversibility | 실행결과를 되돌릴 수 있는가? |
| Escalation | Agent가 결정하지 못하면 누구에게 넘기는가? |
Agent Tool Contract는 Digital Future & Strategy practitioner framework입니다.
10. Human-in-the-Loop보다 Human-at-the-Right-Decision이 중요하다
모든 Agent Action을 사람이 승인하면 안전해 보일 수 있습니다.
하지만 수천 건의 단순 Case까지 사람이 승인하면 AI를 도입해도 기존 병목이 사라지지 않습니다.
반대로 모든 것을 자동화하면 중요한 Business Decision까지 Agent에게 넘어갈 수 있습니다.
따라서 Human-in-the-Loop를 일률적으로 적용하기보다 Decision Type을 나누는 편이 좋습니다.
| Decision Type | Agent | Human |
|---|---|---|
| Deterministic Validation | 검증·자동처리 가능 | 정책설계 및 예외관리 |
| Evidence Gathering | 주도 | 필요 시 검토 |
| Ambiguous Match | 후보와 Evidence 제시 | 판단 |
| Critical Entity Merge | 분석·준비 | 승인 또는 최종결정 |
| Policy Change | Pattern 분석·추천 | Data Owner / Governance가 결정 |
11. Data Owner, Human Steward, Agent의 역할을 구분한다
Defines Business Authority
↓
HUMAN DATA STEWARD
Handles Judgment, Exceptions and Governance Operations
↓
DATA STEWARD AGENT
Investigates, Recommends, Prepares and Executes Allowed Actions
↓
MDM PLATFORM
Enforces Workflow, Validation, Authorization and Audit
Agent가 추가된다고 Data Owner가 사라지지 않습니다.
오히려 Agent가 자동으로 실행할 수 있는 범위를 Data Owner와 Governance가 더 명확하게 정해야 합니다.
12. Data Steward Agent의 가장 중요한 기능은 Escalation일 수 있다
Agent의 수준을 판단할 때 “얼마나 많은 일을 자동으로 처리하는가”만 보면 위험합니다.
좋은 Agent는 언제 행동하지 말아야 하는지도 알아야 합니다.
다음 상황에서는 Escalation을 고려할 수 있습니다.
Unknown Business Rule
High-Impact Merge
New Exception Pattern
Missing Required Evidence
Critical Attribute Change
Policy or Model Out-of-Scope
Agent가 확신이 없을 때 스스로 해결하는 것보다 사람에게 올바른 Context와 함께 넘기는 것이 더 높은 수준의 Agentic Behavior일 수 있습니다.
13. Escalation에는 “작업기록”이 함께 넘어가야 한다
Agent가 단순히:
라고 하면 Human Steward는 다시 처음부터 조사해야 합니다.
Agentic Stewardship의 가치는 Handoff Package에서 나옵니다.
Supplier Duplicate Candidate
Entities
SUP-001827 / SUP-009412
Evidence Reviewed
Name · Legal ID · Address · Parent Relationship · Source History
Supporting Evidence
Name normalized match / same address / same web domain
Conflicting Evidence
Different Legal Registration ID
Actions Already Performed
No write operation
Recommended Next Action
Verify legal-entity relationship before merge
Policy Reason for Escalation
Conflicting legal identifier
이렇게 해야 Agent가 실제로 Human Workload를 줄입니다.
14. 모든 Agent Action에는 Work Record가 필요하다
전통적인 System Log만으로는 Agent Decision을 충분히 설명하기 어려울 수 있습니다.
다음 정보를 하나의 Agent Work Record로 연결하는 것이 유용합니다.
| Case ID | 어떤 업무 Case인가 |
| User Identity | 누구를 대신해 업무했는가 |
| Agent Identity | 어떤 Agent와 Version이 실행했는가 |
| Objective | 어떤 목표를 받았는가 |
| Evidence Accessed | 어떤 Entity, Source, History를 참고했는가 |
| Tools Called | 어떤 API/Tool을 어떤 순서로 실행했는가 |
| Policy Decision | 왜 Action이 허용 또는 차단됐는가 |
| Action | 실제 어떤 변경이 발생했는가 |
| Result | 성공·실패·Escalation 여부 |
| Human Decision | 사람이 개입했다면 최종 판단은 무엇이었는가 |
Agent Work Record는 Digital Future & Strategy practitioner framework입니다.
Reltio의 현재 AgentFlow 문서에서도 Agent Tool Call과 Write Operation은 Logged되고 User Attribution이 남도록 설계되어 있습니다.
15. Agent의 “Reasoning” 전체를 저장하는 것과 Audit Evidence는 다르다
Agentic System의 Audit을 위해 내부 추론 전체를 그대로 저장해야 한다고 가정할 필요는 없습니다.
실무적으로 중요한 것은 업무 판단을 재구성할 수 있는 Material Evidence와 Decision Record입니다.
예를 들어 다음이면 충분할 수 있습니다.
+ Evidence Used
+ Rules / Policy Applied
+ Tool Calls
+ Recommended Action
+ Final Action
+ Human Override
+ Result
이를 통해 나중에 “왜 이 Supplier가 Merge되었는가?”를 설명할 수 있어야 합니다.
16. Data Steward Agent의 Architecture
↓
DATA STEWARD AGENT
Goal · Context · Planning
↓
AGENT POLICY & AUTHORIZATION
Identity · Delegation · Resource · Action · Risk
↓
GOVERNED TOOLS
Search · Validate · Match · Propose · Create CR · Merge
↓
MDM SERVICES
Entity · Quality · Workflow · Hierarchy · Audit
↓
MASTER DATA SYSTEM OF RECORD
──────────────
HUMAN STEWARD / DATA OWNER
Exception · Approval · Policy · High-Impact Decision
이 구조에서 LLM은 Agent의 Reasoning Component일 수 있지만 권한의 근원은 아닙니다.
권한은 Enterprise Policy와 Identity System에서 나와야 합니다.
17. MCP는 Agentic MDM의 Governance를 자동으로 해결하지 않는다
2026년 Agentic Data Architecture에서 Model Context Protocol(MCP)은 중요한 Interface Pattern으로 자리 잡고 있습니다.
Reltio AgentFlow도 MCP Server를 통해 Agent가 Governed Tool을 사용할 수 있도록 하고 있습니다.
하지만 MCP 자체가 다음을 결정해 주지는 않습니다.
Which Attribute May the Agent Change?
Which Merge Requires Approval?
What Is the Data Owner's Policy?
What Evidence Is Sufficient?
MCP는 Tool과 Agent 사이의 상호작용 표준화에 기여할 수 있지만, MDM의 Entity Policy와 Governance를 대신하지 않습니다.
18. Agent가 사용할 Context를 무제한으로 주지 않는다
Agent에게 “모든 Enterprise Data를 읽게 하면 더 똑똑해진다”는 접근도 적절하지 않습니다.
최소 필요 Context만 제공하는 것이 좋습니다.
예를 들어 Supplier Duplicate Case에 필요한 Context는:
- 두 Entity의 Master Profile,
- Identity Attribute,
- 관련 Source Crosswalk,
- Match History,
- 필요한 Relationship,
- 적용되는 Match Policy
일 수 있습니다.
다른 Supplier의 금융정보나 무관한 Customer Data까지 노출할 이유는 없습니다.
19. Agentic MDM에서 Human Steward의 역할은 사라지지 않는다
Human Steward의 업무는 Record-by-Record Processing에서 더 높은 수준으로 이동할 가능성이 있습니다.
| 기존 중심업무 | Agentic MDM에서 강화되는 업무 |
|---|---|
| 반복적인 Validation 확인 | Validation Policy 설계 및 예외 검토 |
| 단순 Candidate 조사 | 복잡한 Entity·Relationship 판단 |
| Change Request Routing | Routing Policy와 Decision Rights 관리 |
| 반복 오류수정 | Root Cause와 Upstream Process 개선 |
| 수동 데이터 조회 | Agent Output Review와 New Exception Pattern 분석 |
Steward 역할이 없어지는 것이 아니라 정책·예외·판단·개선 중심으로 이동하는 것입니다.
20. Data Owner의 역할은 오히려 더 중요해진다
Agent에게 자동화 권한을 부여하려면 누군가는 다음을 결정해야 합니다.
- 어떤 Attribute가 Critical한가?
- 어떤 Source가 Authoritative한가?
- 어떤 Change를 자동실행할 수 있는가?
- 어떤 Exception은 반드시 사람이 판단해야 하는가?
- 잘못된 자동Action의 Risk를 어느 수준까지 허용할 것인가?
이것은 Agent가 결정할 문제가 아니라 Data Owner와 Governance가 결정해야 할 문제입니다.
21. Agentic Workflow의 예: 신규 Supplier Request
다음은 설명을 위한 가상 사례입니다.
Step 1 — Request
사용자가 신규 Supplier 등록을 요청합니다.
Step 2 — Agent Observation
Agent가 입력된 Legal Name, Registration ID, Country, Address와 필수속성을 확인합니다.
Step 3 — Existing Entity Search
MDM 검색 Tool과 Entity Resolution 서비스를 이용해 Existing Supplier Candidate를 확인합니다.
Step 4 — Evidence Package
Name: Similar
Registration ID: Same
Address: Similar
Source: ERP A + Procurement Platform
Relationship: Same legal entity candidate
Step 5 — Policy Evaluation
Policy가 동일한 검증된 Registration ID를 강한 Identity Evidence로 사용한다고 가정합니다.
Step 6 — Agent Action
Agent는 신규 Supplier 생성 대신 기존 Supplier Extension을 추천하고 Change Request 초안을 만듭니다.
Step 7 — Human Decision
새 Purchasing Organization 추가가 필요한 경우 담당 Steward 또는 Owner가 Extension을 승인합니다.
Step 8 — Execution
MDM Workflow가 승인된 변경을 적용하고 Downstream System에 배포합니다.
Step 9 — Audit
Case ID, Agent, User, Evidence, Tool Call, Approval과 Result가 연결되어 저장됩니다.
22. Agentic MDM의 성공 KPI를 “자동화율” 하나로 두지 않는다
기존 Agentic MDM 담론에서는 자동화율이 가장 눈에 띄는 KPI가 되기 쉽습니다.
하지만 자동화율이 높아도 잘못된 판단이 늘면 성공이 아닙니다.
| Metric Family | 측정 예시 |
|---|---|
| Efficiency | Case Lead Time, Steward Touch Time, Backlog Aging |
| Decision Quality | Agent Recommendation Acceptance, Override, False Action |
| Automation | Policy-Approved Auto-Execution Rate |
| Safety | Unauthorized Attempt, Rollback, Critical Incorrect Action |
| Governance | Audit Completeness, Escalation Compliance, Policy Exception |
| Business | First-Time-Right, Downstream Exception, Master Creation Lead Time |
23. Automation Rate보다 Human Touch Reduction을 보는 것이 나을 때도 있다
Agent가 최종 Action을 직접 실행하지 않아도 큰 가치가 있을 수 있습니다.
예를 들어 기존 Steward Case가:
+ 5분 비교
+ 2분 결정
이었다면 Agent가 조사와 비교를 수행하고 사람은 2분 판단만 할 수 있습니다.
이 경우 Auto-Execution Rate는 0%여도 Steward Workload는 크게 달라질 수 있습니다.
따라서 Agentic MDM의 초기 KPI로:
Human Touch Time
Decision Lead Time
Backlog Reduction
을 측정하는 것이 더 현실적일 수 있습니다.
24. Agent 성능은 Production 전용 평가가 아니라 별도 Evaluation Set으로 검증한다
Agent에게 Production 권한을 주기 전에 과거 실제 Steward Case를 이용해 평가할 수 있습니다.
↓
Known Human Decisions
↓
Agent Recommendation
↓
Compare
↓
Error / Override / Escalation Analysis
특히 다음을 분리해서 측정해야 합니다.
- Agent가 맞게 결정한 Case,
- Agent가 틀리게 추천한 Case,
- Agent가 제대로 Escalate한 Case,
- Agent가 Escalate했어야 하지만 행동한 Case.
마지막 유형은 단순 정확도보다 중요할 수 있습니다.
25. NIST AI Risk Management 관점도 함께 적용할 수 있다
Data Steward Agent는 Master Data를 조회만 하는 AI보다 Risk가 높을 수 있습니다.
실제 Master State를 변경할 수 있기 때문입니다.
NIST AI Risk Management Framework는 AI Risk를 전 Lifecycle에서 관리하기 위한 voluntary framework를 제공하며, 현재 AI RMF 1.0은 개정 작업이 진행 중입니다.
NIST는 또한 2026년 AI-enabled capabilities와 AI Agent를 포함하는 Critical Infrastructure용 Trustworthy AI Profile 개발을 시작했습니다.
NIST — AI Risk Management Framework
Agentic MDM에도 다음 질문을 적용할 수 있습니다.
What can go wrong?
How is performance measured?
Who monitors it?
How is human oversight applied?
How can harmful behavior be stopped?
26. 단계적 도입은 “Read-Only → Write” 순서가 유용하다
처음부터 Agent에게 Production Write 권한을 주는 대신 Capability를 단계적으로 확장할 수 있습니다.
| Stage | Agent Capability | Exit Evidence |
|---|---|---|
| Observe | Search·Analysis·Case Summary | Evidence accuracy와 access control 검증 |
| Recommend | Correction·Match·Routing 추천 | Human acceptance/override 패턴 안정화 |
| Prepare | Change Request·Merge Proposal 생성 | Prepared transaction의 정확성과 completeness 검증 |
| Execute | 저위험·가역 Action 실행 | Error·Rollback·Policy violation이 허용범위 내 안정 |
| Expand | 추가 Domain·Action으로 권한 확대 | Domain-specific evaluation과 Owner 승인 완료 |
이 도입단계는 Digital Future & Strategy practitioner framework이며 고정된 일정이나 산업표준이 아닙니다.
27. Agentic MDM에서는 SoD도 다시 봐야 한다
기존 MDM에서는 요청자와 승인자를 분리하는 Segregation of Duties가 적용될 수 있습니다.
Agent가 등장하면 새로운 질문이 생깁니다.
하나의 Agent가:
→ Correction Recommendation
→ Approval Decision
→ Production Execution
까지 모두 수행해도 되는가?
High-Risk Process라면 기능을 분리할 수 있습니다.
Detect / Investigate / Recommend
↓
POLICY / APPROVAL
Human or Separate Control
↓
EXECUTION SERVICE
Governed Transaction
Agentic Architecture에서도 기존 Control Principle이 사라지는 것은 아닙니다.
28. Agent가 틀렸을 때 책임주체를 사전에 정한다
AI가 추천했고 사람이 승인했다면 누가 책임지는가?
Agent가 Policy 안에서 자동수정했지만 결과가 잘못됐다면 누가 Issue Owner인가?
이 질문을 Incident가 발생한 뒤 논의해서는 안 됩니다.
최소한 다음은 미리 정해야 합니다.
| Policy Owner | 자동화 허용정책 책임 |
| Data Owner | Domain Business Decision 책임 |
| Agent Product Owner | Agent 성능·배포·Evaluation 책임 |
| Platform Owner | Tool·Security·Runtime Control 책임 |
| Incident Owner | 오류발생 시 Containment와 Recovery 책임 |
29. Data Steward Agent 도입 전에 확인할 15가지 질문
1. Agent가 해결하려는 실제 Steward 업무가 무엇인가?
2. Agent가 없어도 Rule-Based Automation으로 해결 가능한 업무는 무엇인가?
3. Agent가 참고해야 할 Authoritative Context가 정의되어 있는가?
4. Agent가 사용할 Tool이 Business Capability 단위로 제한되어 있는가?
5. Agent와 User Identity를 Audit에서 구분할 수 있는가?
6. Agent가 접근할 수 있는 Domain·Entity·Attribute가 제한되는가?
7. Confidence가 아니라 Action Risk를 권한 결정에 반영하는가?
8. High-Impact Action에 Human Approval 또는 별도 Control이 있는가?
9. Agent가 판단을 포기하고 Escalate해야 하는 조건이 정의되어 있는가?
10. Escalation 시 Evidence Package가 함께 전달되는가?
11. 모든 Tool Call과 Write Action을 추적할 수 있는가?
12. Production 전 Historical Case로 Agent를 평가했는가?
13. Agent Recommendation Override를 학습용 Evidence로 관리하는가?
14. Agent 오류 발생 시 Rollback과 Incident Response가 가능한가?
15. 자동화율이 아니라 Decision Quality와 Business Outcome도 측정하는가?
Data Steward의 미래: Replacement가 아니라 Control Design으로 이동한다
Data Steward Agent가 발전하면 사람이 직접 처리하는 반복작업은 줄어들 가능성이 높습니다.
그러나 이것을 단순히:
→
AI Agent
로 보는 것은 너무 단순합니다.
보다 현실적인 변화는:
↓
EXCEPTION JUDGMENT
↓
POLICY DESIGN
↓
AGENT SUPERVISION
↓
ROOT-CAUSE IMPROVEMENT
로 볼 수 있습니다.
사람은 더 적은 Case를 직접 처리할 수 있습니다.
하지만 남는 Case는 더 어려울 수 있습니다.
그리고 사람이 새롭게 해야 하는 일도 생깁니다.
어떤 Action을 Agent가 실행할 수 있는지 정하고, Agent가 잘못 판단하는 Pattern을 찾아내고, Policy와 Tool을 개선하며, 새로운 Exception을 Governance Rule로 바꾸는 일입니다.
Agentic Data Management의 핵심
Data Steward Agent의 가장 중요한 능력은 많은 Master Record를 자동으로 변경하는 것이 아닙니다.
좋은 Agent는:
×
RIGHT TOOL
×
RIGHT AUTHORITY
×
RIGHT EVIDENCE
×
RIGHT ESCALATION
×
COMPLETE AUDIT
=
TRUSTED DATA STEWARD AGENT
를 갖춰야 합니다.
MDM에서 AI Agent를 가장 안전하게 도입하는 방법은 처음부터 사람을 대체하려는 것이 아닙니다.
먼저 Agent에게 조사와 Evidence 수집을 맡깁니다.
그 다음 추천과 Change Request 준비를 맡깁니다.
검증된 저위험 업무에서만 실행권한을 확대합니다.
그리고 중요한 Business Decision에서는 Human Steward와 Data Owner가 계속 책임을 갖습니다.
Agentic MDM의 성숙도는 사람이 몇 명 줄었는가로 판단해서는 안 됩니다. Agent가 더 많은 업무를 처리하면서도 중요한 Master Data Decision의 권한, Evidence, 책임과 Audit가 더 명확해졌는가로 판단해야 합니다.
Sources & Further Reading
- Reltio — AgentFlow Overview
- Informatica from Salesforce — Agentic Multidomain MDM and Data Steward Agent Announcement
- SAP — MDG Data Quality Management
- SAP — Rule Mining
- SAP — Rule-Based Workflow
- NIST — AI Risk Management Framework
- NIST — AI RMF Generative AI Profile
이 글에서 Agentic Data Management와 Data Steward Agent는 하나의 확정된 산업표준 제품범주가 아니라 AI Agent가 Master Data Stewardship 업무에 참여하는 emerging operating pattern으로 사용했습니다. Reltio AgentFlow는 2026년 8월 기준 실제 제품 문서를 통해 governed tools, RBAC, attribute masking 및 audit 기반의 agentic stewardship 구현사례를 확인하는 데 사용했습니다. Informatica from Salesforce의 Data Steward Agent와 Agentic Multidomain MDM은 2026년 5월 발표자료에 포함되어 있으나 발표 당시 Availability가 Q4 2026으로 명시되어 있으므로 현재 구현사례와 향후 제품방향을 구분해야 합니다. SAP MDG 자료는 Rule Mining, Data Quality Management 및 Rule-Based Workflow를 통해 AI-assisted stewardship과 deterministic governance가 함께 사용될 수 있음을 보여주는 참고사례입니다. Agent Authority Model, five-level authority ladder, Agent Tool Contract, Agent Work Record, evaluation model 및 staged adoption model은 Digital Future & Strategy practitioner frameworks이며 벤더 공식표준이 아닙니다. 기존 글에 포함된 60~70% 업무자동화, 80~90% 오류자동처리, 95% auto-merge threshold, 85% 표준화 자동처리 및 40~60% 승인시간 단축 등의 보편적 수치는 검증가능한 출처가 부족해 제거했습니다.
Reviewed: September 2026
MDM Strategy Series
Part 1 — AI & Agentic MDM
MDM #2. AI-Ready Data: 고품질 마스터 데이터 필요성
MDM #3. Data Steward Agent 설계: AI에게 어떤 MDM 업무와 권한을 맡길 것인가
MDM #4. Self-Healing Master Data: 자동 수정이 아니라 통제된 복구 시스템을 설계하는 방법
MDM #5. 지식 그래프 기반 엔티티 해상도
Global English Companion
글로벌 독자를 위한 영문판은 아래 글에서 Data Steward Agent의 역할과 Human–AI 책임분담을 다룹니다.
MDM #3. The Core of Agentic Data Management: The Role and Future of the Data Steward Agent
본 한국어판은 단순 번역이 아니라 Agent Authority, governed tools, work record, escalation package, evaluation 및 production control에 더 초점을 둡니다.
이전 글: AI-Ready Data
다음 글: Self-Healing Master Data
Comments
Post a Comment