9. AI-Ready를 위한 MDM 아키텍처 진화: MDM 1.0에서 MDM 2.0으로
- MDM 2.0은 기존 MDM 시스템을 버리는 것이 아닙니다. 4개의 AI-Ready 레이어를 추가하여 AI 에이전트가 즉시 소비할 수 있는 형태로 진화하는 것입니다
- MDM 2.0의 핵심은 AI-Ready API 게이트웨이입니다. SAP MDG든 Oracle MDM이든 플랫폼에 관계없이 AI 에이전트가 표준화된 방식으로 마스터 데이터에 접근할 수 있게 합니다
- MDM 2.0으로의 전환에서 가장 흔한 실수는 전체 MDM을 한 번에 전환하려는 것입니다. AI-Ready가 가장 시급한 도메인부터 점진적으로 전환해야 합니다
"MDM을 AI-Ready 상태로 만들어야 한다는 것은 알겠습니다. 그런데 지금 SAP S/4HANA에 수십 억을 투자해 구축한 MDM을 다 바꿔야 합니까?" AI-Ready 전환을 논의할 때 CIO가 가장 먼저 묻는 질문입니다.
답은 "아니요"입니다. MDM 2.0은 기존 MDM을 대체하는 것이 아닙니다. 기존 MDM(SAP MDG·Oracle MDM·Informatica MDM)을 중심에 두고, AI 에이전트가 즉시 소비할 수 있도록 4개의 AI-Ready 레이어를 추가하는 진화입니다.
이번 편에서는 MDM 1.0과 MDM 2.0의 아키텍처적 차이, 4개 AI-Ready 레이어의 설계 방법, SAP 환경에서의 MDM 2.0 구현 경로, 그리고 MDM 2.0으로의 점진적 전환 전략을 완전히 분석합니다.
- MDM 1.0의 구조와 AI-Ready 관점의 한계
- MDM 2.0의 정의와 4개 AI-Ready 레이어
- 레이어 1 — AI-Ready API 게이트웨이 설계
- 레이어 2 — 마스터 데이터 벡터화 파이프라인
- 레이어 3 — MDM 피처 추출 파이프라인
- 레이어 4 — AI-Ready 품질 자동화 레이어
- MDM 2.0 데이터 흐름 설계: 읽기·쓰기·스트리밍
- SAP 환경 MDM 2.0 구현: 3가지 경로
- MDM 아키텍처 패턴: Hub·Registry·Hybrid의 AI-Ready 전환
- MDM 2.0 점진적 전환 로드맵
- 전략 리더십·현장 실무 관점
1. MDM 1.0의 구조와 AI-Ready 관점의 한계
MDM 1.0은 2000년대~2010년대에 정립된 전통적 마스터 데이터 관리 아키텍처입니다. ERP 시스템의 마스터 데이터를 통합·관리하고 품질을 유지하는 데 탁월하지만, AI 에이전트 시대에는 구조적 한계를 드러냅니다.
MDM 1.0 표준 아키텍처:
↓ ETL 배치 (일·주 단위)
MDM 허브 (SAP MDG·Informatica MDM·Oracle MDM)
↓ 마스터 데이터 관리 (품질·거버넌스·스튜어드십)
↓ 배치 또는 API 발행 (운영 시스템에 동기화)
운영 시스템 (ERP·CRM·SCM) + DW·리포팅
MDM 1.0의 AI-Ready 관점 5가지 한계:
| 한계 항목 | MDM 1.0의 현실 | AI 에이전트가 요구하는 것 | AI-Ready 영향 |
|---|---|---|---|
| ① 배치 기반 동기화 | 일·주 단위 배치 처리. 마스터 데이터 변경이 수 시간~수 일 후 반영 | 즉각적 실시간 데이터. AI 에이전트가 항상 최신 데이터 소비 필요 | AI가 오래된 재고·가격·납기로 잘못된 결정 |
| ② AI 비친화적 접근 방식 | SQL·배치 API·사람이 읽는 UI. AI 에이전트용 표준 인터페이스 없음 | Tool Use API: AI 에이전트가 함수 호출로 즉시 접근하는 표준 인터페이스 | AI 에이전트가 MDM 데이터에 직접 접근 불가 |
| ③ 비정형 데이터 미통합 | 정형 데이터(코드·숫자·날짜) 위주. 텍스트·이미지·문서 MDM 외부 | 비정형 데이터의 벡터화·임베딩 필요. RAG AI-Ready 연결 필요 | AI가 제품 설명·공급업체 리뷰·계약 조항 소비 불가 |
| ④ AI-Ready 품질 기준 미적용 | 전통 DQ(정확성·완전성·일관성). AI-Ready 특화 기준(편향·다양성·계보) 없음 | 12차원 AI-Ready 품질 기준 충족. 편향·레이블·출처 추적 관리 | AI가 AI-Ready 미충족 데이터로 편향 결정 생성 |
| ⑤ 피처 추출 기능 없음 | 원본 마스터 데이터만 저장. AI 모델이 사용하는 파생 피처 생성 불가 | MDM 데이터에서 AI 피처 자동 추출·피처 스토어 공급 | 팀마다 동일 피처를 중복 계산. Training-Serving Skew 발생 |
"MDM 1.0은 ERP 시대의 걸작이었다. 그러나 AI 에이전트 시대에는 설계 당시 상정하지 않은 소비자(AI)가 등장했다. MDM 1.0의 한계는 MDM 플랫폼의 문제가 아니다. AI 에이전트가 소비할 수 있는 4개의 레이어가 없다는 아키텍처의 문제다. SAP MDG는 여전히 최고의 MDM 플랫폼이다. 다만 그 위에 AI-Ready 레이어를 쌓아야 한다."
— SAP AI-Ready Architecture Whitepaper, 2026
2. MDM 2.0의 정의와 4개 AI-Ready 레이어
MDM 2.0은 기존 MDM 시스템(MDM 1.0 핵심)을 유지하면서 AI 에이전트가 즉시 소비할 수 있는 4개 레이어를 추가한 확장 아키텍처입니다.
AI 에이전트·LLM·ML 모델 (소비자)
↕ Tool Use API 호출 / 벡터 검색 / 피처 조회
Layer 4 — AI-Ready 품질 자동화 레이어
(12차원 DQ 실시간 모니터링·AI 파이프라인 게이트)
Layer 3 — MDM 피처 추출 파이프라인
(MDM → 피처 스토어 자동 피처 추출·갱신)
Layer 2 — 마스터 데이터 벡터화 파이프라인
(MDM 비정형 데이터 → 벡터 DB 자동 임베딩)
Layer 1 — AI-Ready API 게이트웨이
(Tool Use 표준 API·인증·권한·감사 로그)
MDM 1.0 핵심 (유지)
SAP MDG / Oracle MDM / Informatica MDM
(마스터 데이터 품질·거버넌스·스튜어드십)
↑ CDC (변경 데이터 캡처) 실시간 연동
데이터 소스 (ERP·CRM·SCM·레거시)
| 레이어 | 명칭 | 역할 | 핵심 기술 | 구현 우선순위 |
|---|---|---|---|---|
| Layer 1 | AI-Ready API 게이트웨이 | AI 에이전트의 MDM 접근을 위한 표준 인터페이스. 인증·권한·로그·HITL 통합 | REST API / OData / GraphQL + API Gateway | 🔴 1순위 (모든 AI 연결의 기반) |
| Layer 2 | 벡터화 파이프라인 | MDM 비정형 데이터(설명·문서·리뷰)를 자동으로 벡터화하여 AI-Ready RAG 연결 | 임베딩 모델 + 벡터 DB (Weaviate·pgvector) | 🟠 2순위 (RAG 필요 시) |
| Layer 3 | 피처 추출 파이프라인 | MDM 원본 데이터에서 AI 모델 학습·추론에 최적화된 피처를 자동 추출하여 피처 스토어 공급 | Apache Spark·Flink + Feast·Tecton | 🟡 3순위 (ML 모델 사용 시) |
| Layer 4 | AI-Ready 품질 자동화 | 12차원 DQ 실시간 모니터링. 기준 미달 데이터의 AI 파이프라인 자동 차단 | Great Expectations + Fairlearn + WhyLabs | 🟡 3순위 (품질 보증) |
3. 레이어 1 — AI-Ready API 게이트웨이 설계
AI-Ready API 게이트웨이는 MDM 2.0의 가장 핵심 레이어입니다. SAP MDG든 Oracle MDM이든 플랫폼에 관계없이 AI 에이전트가 표준화된 방식으로 마스터 데이터에 접근하는 단일 진입점을 제공합니다.
AI-Ready API 게이트웨이의 5가지 핵심 기능:
역할: AI 에이전트가 MDM 데이터에 접근하는 표준 함수를 중앙에서 관리합니다. 각 팀이 제각각 MDM 연동 코드를 작성하는 혼란을 제거합니다.
표준 함수 설계 예시:
get_material_info(material_id, fields) → 자재 기본 정보 조회
get_inventory_level(material_id, plant) → 실시간 재고 조회
get_supplier_risk_score(supplier_id) → 공급업체 리스크 점수
get_customer_profile(customer_id) → 고객 AI-Ready 프로파일
// 쓰기 함수 (HITL 필수)
create_purchase_order(material_id, qty, supplier_id) → 발주 생성
update_customer_segment(customer_id, segment) → 고객 세그먼트 변경
flag_supplier_risk(supplier_id, risk_level, reason) → 공급업체 위험 표시
역할: AI 에이전트별로 접근할 수 있는 MDM 도메인·함수·데이터 범위를 세밀하게 제어합니다. "최소 권한 원칙(Least Privilege)"을 AI 에이전트에 적용합니다.
권한 설계 원칙:
- 고객 응대 AI: 고객 MDM 읽기만. 자재·공급업체 MDM 접근 불가
- 구매 AI: 자재·공급업체 MDM 읽기 + 소액 발주 함수만
- SCM 리스크 AI: 공급업체 MDM 읽기 + 리스크 플래그 쓰기
역할: AI 에이전트의 MDM 대량 호출이 운영 시스템에 부하를 주지 않도록 API 호출 속도를 제한합니다.
설계 기준: 에이전트별 초당 요청 수(RPS) 제한 설정. 비정상적 대량 스캔(가능한 API 침해 시도) 자동 차단. 피크 타임 캐싱으로 MDM 시스템 직접 호출 최소화.
역할: 쓰기 함수 호출 시 자동으로 HITL 프로세스를 실행합니다. AI 에이전트의 제안을 인간 담당자에게 전달하고 승인·거절·수정 응답을 처리합니다.
통합 채널: Slack/Teams 봇 알림 + 원클릭 승인/거절. 타임아웃 자동 취소 (4~8시간). 모든 HITL 이력 감사 로그 자동 기록.
역할: AI 에이전트의 모든 MDM 접근 이력을 변경 불가능한 감사 로그에 자동 기록합니다. EU AI Act Article 12 요건 충족.
기록 항목: 요청 시각·AI 에이전트 ID·호출 함수·입력 파라미터·MDM 응답·HITL 처리 결과·사용자 ID
SAP 환경 AI-Ready API 게이트웨이 구현 방법:
SAP MDG OData 서비스 활성화
↓ SAP Integration Suite API Management (게이트웨이 역할)
↓ 인증(SAP BTP), 속도 제한, 감사 로그
↓ Tool Use 표준 함수로 래핑
AI 에이전트 (Azure OpenAI·Claude·SAP Joule)
직접 REST API 경로 (비 SAP 기업):
MDM 시스템 → REST API 개발 (Python FastAPI / Node.js)
↓ Kong / AWS API Gateway / Azure API Management
↓ OAuth 2.0 인증 + Rate Limiting
AI 에이전트
4. 레이어 2 — 마스터 데이터 벡터화 파이프라인
MDM 2.0의 두 번째 레이어는 마스터 데이터에 포함된 비정형 데이터(텍스트·설명·문서)를 자동으로 벡터화하여 AI-Ready RAG 검색에 활용하는 파이프라인입니다.
도메인별 벡터화 대상 데이터:
| MDM 도메인 | 벡터화 대상 속성 | AI-Ready 활용 | 임베딩 모델 권장 |
|---|---|---|---|
| 자재 MDM | 자재 설명(Description), 기술 스펙 문서, 규격서 텍스트 | 대체 자재 검색 AI, 자재 중복 탐지 AI, 구매 챗봇 | 한영 혼용: text-embedding-3-large 또는 BGE-M3 |
| 공급업체 MDM | 공급업체 소개, 제공 서비스 설명, 계약 조항, 품질 인증 문서 | 공급업체 매칭 AI, RFQ 자동화 AI, 리스크 분석 AI | 한국어: HyperCLOVA X Embedding |
| 고객 MDM | 고객 문의 이력, 민원 내용, 상담 기록, 리뷰 텍스트 | 고객 응대 AI, 감정 분석 AI, VOC 분류 AI | 한국어: KoSimCSE-roberta 또는 Ko-Electra |
| 제품 MDM | 제품 설명, 사용 매뉴얼, FAQ, 기술 문서, 이미지 | 제품 추천 AI, 기술 지원 AI, 유사 제품 검색 | 멀티모달: text+image → CLIP 또는 Gemini Multimodal |
| 직원 MDM | 직무 설명, 업무 이력, 기술 역량 텍스트, 프로젝트 설명 | 인재 매칭 AI, 팀 구성 AI, 교육 추천 AI | 한국어: BGE-M3 또는 Ko-Electra |
마스터 데이터 벡터화 파이프라인 설계:
MDM 데이터 전체 추출 → 텍스트 전처리 (클렌징·정규화)
→ 청킹 전략 적용 (도메인별 최적 청킹)
→ 임베딩 모델 일괄 적용 (한국어 특화 모델)
→ 벡터 DB 적재 (메타데이터 포함: 도메인·ID·날짜·접근 권한)
CDC 기반 증분 임베딩 (상시 운영):
MDM 데이터 변경 감지 (CDC — Debezium)
→ 변경된 레코드만 선택적 재임베딩
→ 기존 벡터 DB의 해당 벡터 갱신
→ 삭제된 마스터 데이터 → 벡터 DB에서도 즉시 삭제
- 접근 권한 메타데이터 필수: 직원 급여 정보가 벡터화되면 권한 없는 AI 에이전트가 접근할 수 있습니다. 벡터 DB에 메타데이터 필터로 접근 권한을 반드시 연동합니다
- 삭제 동기화 필수: MDM에서 삭제된 마스터 데이터가 벡터 DB에 남아있으면 AI가 폐기된 정보를 기반으로 결정합니다. MDM 삭제 → 벡터 DB 즉시 삭제 파이프라인이 필수입니다
- 버전 관리: 임베딩 모델을 변경할 경우 전체 재임베딩이 필요합니다. 모델 버전을 메타데이터에 기록하여 관리합니다
5. 레이어 3 — MDM 피처 추출 파이프라인
MDM 원본 데이터는 그 자체로는 AI ML 모델이 바로 학습·추론에 사용하기 어렵습니다. MDM 데이터에서 AI 모델에 최적화된 피처를 자동으로 추출하여 피처 스토어에 공급하는 파이프라인이 레이어 3입니다.
MDM 도메인별 핵심 피처 추출 설계:
| MDM 도메인 | 원본 MDM 데이터 | 추출되는 AI-Ready 피처 | 갱신 주기 | 활용 AI |
|---|---|---|---|---|
| 고객 MDM | 구매 이력, 문의 기록, 결제 방식, 접속 디바이스 | 구매_빈도_30일, 구매_빈도_90일, 선호_카테고리_벡터, 이탈_위험_점수, 생애_가치(LTV), 마지막_구매_이후_일수 | 일간 | 이탈 예측, 추천, 심사 |
| 자재 MDM | 입출고 이력, 발주 이력, 수요 이력 | 재고_회전율_월, 수요_계절성_지수, 리드타임_변동성, 안전재고_적정성_점수, 대체자재_유사도_벡터 | 일간 | 수요 예측, 발주, 재고 최적화 |
| 공급업체 MDM | 납기 이력, 품질 이력, 재무 현황 | 납기_신뢰도_12개월, 품질_안정성_지수, 리스크_종합_등급, 용량_활용률, 지정학적_리스크_점수 | 주간 | SCM 리스크, 공급업체 평가 |
| 금융 거래 MDM | 거래 시간·금액·위치·디바이스 | 거래_패턴_이상도, 접속_기기_변동성, 거래_시간_이상도, 연속_실패_횟수, 새_수취인_비율 | 실시간 | 사기 탐지 |
MDM → 피처 스토어 파이프라인 아키텍처:
↓ CDC (Debezium) — 변경 감지
Apache Kafka (스트리밍 버스)
↓
Apache Spark / Flink (피처 변환 엔진)
피처 정의: customer_purchase_frequency_30d = COUNT(orders WHERE date ≥ NOW()-30d)
↓
오프라인 피처 스토어 (S3 / Delta Lake) — 학습용
온라인 피처 스토어 (Redis / DynamoDB) — 실시간 추론용
↓
AI 에이전트·ML 모델이 일관된 피처로 학습·추론
6. 레이어 4 — AI-Ready 품질 자동화 레이어
레이어 4는 MDM에서 AI 파이프라인으로 진입하는 데이터의 AI-Ready 품질을 자동으로 검증하는 게이트입니다. 기준 미달 데이터가 AI 에이전트에 도달하기 전에 차단합니다.
MDM 데이터 변경 발생
↓ Layer 4 품질 게이트 진입
검증 1: 완전성 (필수 속성 완전성 98% 이상?)
검증 2: 유일성 (중복 레코드 없음?)
검증 3: AI-Ready 형식 (벡터화 가능 형식?)
검증 4: AI 소비 최신성 (SLA 지연 시간 이내?)
↓ 모든 검증 합격
AI 파이프라인 진입 허가 → Layer 1·2·3으로 전달
↓ 하나라도 불합격
AI 파이프라인 진입 차단 → 스튜어드 알림 → 원인 코드 기록
7. MDM 2.0 데이터 흐름 설계: 읽기·쓰기·스트리밍
MDM 2.0에서 데이터는 목적에 따라 세 가지 방식으로 흐릅니다. 각 방식의 설계가 AI-Ready 성능을 결정합니다.
| 흐름 유형 | 방향 | AI-Ready 목적 | HITL 요건 | 기술 구현 |
|---|---|---|---|---|
| 읽기 (Read) | MDM → AI 에이전트 | AI 에이전트의 자율적 MDM 조회. 발주 판단·고객 서비스·리스크 분석 | HITL 불필요. AI 자동 실행 | Layer 1 API 동기 호출. 응답 P99 ≤ 500ms |
| 쓰기 (Write) | AI 에이전트 → MDM | AI의 MDM 데이터 변경 제안. 발주 생성·마스터 수정·리스크 플래그 | 🔴 HITL 필수. AI 제안 → 인간 승인 → MDM 반영 | Layer 1 API 비동기 HITL. 타임아웃 자동 취소 |
| 스트리밍 (Streaming) | MDM → AI 파이프라인 (상시) | MDM 변경을 AI 파이프라인에 실시간 전파. 벡터 DB·피처 스토어 즉시 갱신 | HITL 불필요. 자동 파이프라인 | CDC (Debezium) → Kafka → Layer 2·3 자동 갱신 |
8. SAP 환경 MDM 2.0 구현: 3가지 경로
국내 대기업 70% 이상이 SAP S/4HANA를 사용합니다. SAP 환경에서 MDM 2.0을 구현하는 3가지 현실적 경로를 분석합니다.
특징: SAP가 2026년 공식 출시한 AI-Ready MDM 통합 플랫폼. SAP S/4HANA의 마스터 데이터를 AI-Ready 상태로 자동 변환. SAP Joule AI 에이전트와 직접 연동.
MDM 2.0 레이어 지원:
- Layer 1: SAP API Management를 통한 Tool Use API 자동 생성
- Layer 2: SAP 내장 임베딩으로 마스터 데이터 자동 벡터화
- Layer 3: SAP Datasphere 기반 피처 추출 파이프라인
- Layer 4: SAP Data Quality Management 연동
장점: SAP 생태계 내 최소 통합 작업. 기존 SAP 계약 기반 추가 라이선스.
단점: SAP 외부 AI 플랫폼(Azure OpenAI·Claude) 연동 시 추가 작업. 높은 라이선스 비용.
특징: SAP MDG는 유지하고, SAP Integration Suite가 API 게이트웨이 역할. 벡터 DB·피처 스토어·품질 레이어는 외부 오픈소스 또는 클라우드로 구현.
MDM 2.0 레이어 구현:
- Layer 1: SAP Integration Suite API Management (OData → REST API 변환)
- Layer 2: Weaviate 또는 pgvector (SAP 외부 벡터 DB)
- Layer 3: Feast (오픈소스 피처 스토어)
- Layer 4: Great Expectations + Fairlearn
장점: 벤더 독립적. SAP Business Data Cloud보다 낮은 비용. 외부 AI 플랫폼 자유롭게 선택.
단점: 통합 복잡도 높음. SAP와 외부 시스템 간 동기화 관리 필요.
특징: Microsoft Fabric이 SAP MDG 데이터를 AI-Ready 상태로 수집·변환. Azure AI Search가 벡터 DB, Azure ML이 피처 스토어, Microsoft Purview가 거버넌스.
MDM 2.0 레이어 구현:
- Layer 1: Azure API Management (SAP MDG OData → Azure AI-Ready API)
- Layer 2: Azure AI Search (벡터 DB + 하이브리드 검색)
- Layer 3: Azure ML Feature Store + Microsoft Fabric
- Layer 4: Microsoft Purview (거버넌스·계보·DQ)
장점: Microsoft 365·Teams·Copilot과 완벽 통합. 국내 도입 1위 플랫폼 생태계.
단점: Microsoft 생태계 종속성. SAP-Microsoft 라이선스 비용 중복.
| 비교 항목 | 경로 1 (SAP BDC) | 경로 2 (SAP IS + 오픈소스) | 경로 3 (Microsoft Fabric) |
|---|---|---|---|
| 구현 복잡도 | 낮음 (SAP 원스톱) | 높음 (다중 통합) | 중간 |
| 라이선스 비용 | 높음 | 중간 (오픈소스 활용) | 중간~높음 |
| 벤더 독립성 | 낮음 (SAP 종속) | 높음 | 중간 (MS 종속) |
| AI 플랫폼 유연성 | SAP Joule 중심 | 모든 AI 자유 선택 | Copilot·Azure OpenAI 중심 |
| 국내 대기업 권장 | SAP 헤비유저 | SAP + 외부 AI 병행 | Microsoft 365 기반 |
9. MDM 아키텍처 패턴: Hub·Registry·Hybrid의 AI-Ready 전환
MDM 1.0에는 3가지 주요 아키텍처 패턴이 있습니다. 각 패턴의 AI-Ready 전환 접근법이 다릅니다.
| MDM 패턴 | 특징 | AI-Ready 장점 | AI-Ready 과제 | 전환 전략 |
|---|---|---|---|---|
| 허브 (Hub) 스타일 | MDM 허브가 마스터 데이터 단일 보관. 운영 시스템에 동기화 배포 | 단일 데이터 소스로 AI-Ready API 구현 단순. SSOT 보장 | 허브가 실시간 AI 요청의 병목. CDC 구현 필요 | 허브 위에 AI-Ready API Layer 직접 추가. 읽기 캐싱 레이어 구현 |
| 레지스트리 (Registry) 스타일 | 마스터 데이터는 각 운영 시스템에 분산. MDM은 참조·색인만 관리 | 실시간 원본 시스템 직접 접근 가능. 지연 최소화 | SSOT 없어 AI-Ready API 복잡. 여러 시스템 조합 필요 | 레지스트리에 SSOT 골든 레코드 레이어 추가 후 AI-Ready API 구현 |
| 하이브리드 | 핵심 도메인은 허브, 비핵심은 레지스트리 | 도메인별 AI-Ready 최적화 가능 | 아키텍처 복잡성. 도메인별 다른 AI-Ready 접근 필요 | 허브 도메인 먼저 AI-Ready 전환. 레지스트리 도메인은 별도 전략 |
10. MDM 2.0 점진적 전환 로드맵
MDM 2.0 전환은 단계적으로 진행해야 합니다. AI-Ready가 가장 시급한 도메인부터 시작하여 성공 경험을 쌓고 확장합니다.
| 단계 | 기간 | 핵심 과제 | 완료 기준 | 예상 AI-Ready 효과 |
|---|---|---|---|---|
| 1단계 Layer 1 구축 |
1~3개월 | 우선순위 MDM 도메인(자재)에 AI-Ready API 게이트웨이 구축. 읽기 전용 Tool Use 함수 5~10개 구현 | 자재 MDM API 응답 P99 ≤ 500ms. AI 에이전트 파일럿 연결 성공 | 첫 AI 에이전트 MDM 연결 가능 |
| 2단계 Layer 2 구축 |
3~6개월 | 자재·공급업체 MDM 텍스트 데이터 벡터화. 벡터 DB 구축. CDC 기반 자동 임베딩 갱신 | 자재 설명 RAG 검색 정확도 80%+. CDC 실시간 갱신 구현 | 대체 자재 검색 AI, 공급업체 매칭 AI 가능 |
| 3단계 Layer 3 구축 |
6~9개월 | 주요 MDM 도메인 피처 추출 파이프라인. 피처 스토어 구축. AI 모델 학습·추론 통일 | 피처 스토어 운영. Training-Serving Skew 제거 확인 | 수요 예측·이탈 예측·리스크 평가 AI 정확도 향상 |
| 4단계 Layer 4 + 전사 확장 |
9~18개월 | AI-Ready 품질 자동화 레이어. 전 MDM 도메인으로 MDM 2.0 확장. HITL 쓰기 함수 구현 | 12차원 DQ 자동 모니터링 가동. 전 도메인 MDM 2.0 전환 완료 | 완전한 MDM 2.0. Multi-Agent AI-Ready 운영 가능 |
11. 전략 리더십·현장 실무 관점
[전략 리더십 관점]
"MDM 2.0 전환 투자를 이사회에 설명할 때 핵심 메시지는 '기존 SAP MDG 투자를 보호하면서 AI-Ready를 달성한다'다. 기존 MDM을 버리는 것이 아니라, 그 위에 AI가 즉시 소비할 수 있는 4개 레이어를 추가한다. 이것이 MDM 2.0의 본질이다. Layer 1(API 게이트웨이)만 구축해도 첫 AI 에이전트를 MDM에 연결할 수 있다. 3개월·3억 원 투자로 시작할 수 있는 점진적 여정이다."
— Deloitte MDM 2.0 Architecture Practice, 2026
[현장 실무 관점]
MDM 2.0 전환의 첫 번째 실무 행동은 Layer 1 — SAP MDG OData API 활성화입니다. SAP MDG를 사용하는 기업은 이미 OData API가 내장되어 있습니다. 이것을 활성화하고 SAP Integration Suite로 래핑하면 첫 번째 AI-Ready Tool Use API를 2~4주 내에 구현할 수 있습니다.
다음 주 시작할 수 있는 MDM 2.0 첫 번째 행동:
☐ SAP Integration Suite API Management 설정 (인증·권한·속도 제한)
☐ get_material_info() 첫 번째 Tool Use 함수 정의 문서 작성
☐ Postman으로 API 호출 테스트 (재고·단가·리드타임 반환 확인)
☐ AI 에이전트 파일럿 환경에서 첫 Tool Use 호출 테스트
수십 억을 투자한 SAP MDG 위에
4개의 AI-Ready 레이어를 쌓는 것입니다.
Layer 1(API 게이트웨이)을 시작으로
점진적으로 Layer 2·3·4를 추가합니다.
이 진화가 MDM 1.0을
AI 에이전트의 최고 연료 공급 체계로
탈바꿈시킵니다."
- SAP. (2026). SAP Business Data Cloud: AI-Ready MDM for the Agentic Enterprise. SAP SE.
- Gartner. (2026). MDM 2.0: Redesigning Master Data Architecture for AI Agents. Gartner, Inc.
- Deloitte Insights. (2026). MDM Architecture Evolution: From MDM 1.0 to AI-Ready MDM 2.0. Deloitte.
- McKinsey Digital. (2026). Building AI-Ready MDM: The Four-Layer Architecture. McKinsey & Company.
- PwC Korea. (2026). SAP 환경 MDM 2.0 구현 경로 분석. PwC Korea.
- BCG. (2026). The AI-Ready MDM Architecture: From Theory to Practice. BCG Henderson Institute.
- Informatica. (2026). MDM for AI: Connecting Master Data to AI Agents. Informatica Corp.
- Reltio. (2026). Cloud-Native MDM: API-First AI-Ready Architecture. Reltio Inc.
- Microsoft. (2026). SAP + Microsoft Fabric: AI-Ready MDM Integration Guide. Microsoft.
- Debezium Project. (2026). Change Data Capture for AI-Ready MDM Streaming. Red Hat / Community.
- Apache Software Foundation. (2026). Kafka + Flink for Real-Time AI-Ready MDM Pipelines.
- DAMA International. (2017). DAMA-DMBOK 2nd Edition: Master Data Management Architecture.
Part 3. MDM과 AI-Ready (7~11편)
- MDM이 AI-Ready의 선행조건인 이유
- AI-Ready를 위한 마스터 데이터 품질 기준 재설계
- AI-Ready를 위한 MDM 아키텍처 진화 (현재 글)
- 도메인별 마스터 데이터 AI-Ready 전략 (예정)
- MDM과 AI 에이전트 AI-Ready 연동 실전 설계 (예정)
※ 본 시리즈는 AI 시대 데이터 전략·MDM·AI 거버넌스를 글로벌 컨설팅 보고서와 국내 대기업 현장 전문가 관점에서 심층 분석합니다.
댓글
댓글 쓰기