16. 하이브리드 페더레이티드 모델: 중앙 거버넌스와 도메인 책임의 균형
MDM의 가장 오래된 딜레마가 있습니다. 중앙에서 모든 마스터 데이터를 통제하면 일관성은 높아지지만 현업이 따라오지 않습니다. 반대로 각 도메인이 자율적으로 관리하면 현업 참여는 늘지만 데이터 표준이 흐트러집니다. 완전한 중앙화도, 완전한 분산화도 답이 아닙니다.
하이브리드 페더레이티드 MDM 모델은 이 딜레마에 대한 현실적인 해답입니다. 정책과 표준은 중앙에서 정의하고, 데이터 운영과 책임은 도메인에서 담당합니다. 이 글에서는 하이브리드 페더레이티드 모델의 개념·구조·설계 원칙·구현 방법, 그리고 대기업 환경에서의 현실적인 적용 전략을 정리합니다.
1. MDM 거버넌스 모델의 3가지 유형
MDM 거버넌스 모델은 크게 세 가지로 분류됩니다. 각 모델의 특성을 이해하는 것이 하이브리드 모델을 선택하는 이유를 이해하는 출발점입니다.
| 모델 | 구조 | 강점 | 한계 |
|---|---|---|---|
| 완전 중앙화 (Centralized) |
단일 MDM 팀이 모든 마스터 데이터 생성·수정·배포를 통제 | 높은 일관성, 표준 적용 용이, 단일 진실의 원천 | 현업 병목, 느린 처리 속도, 비즈니스 맥락 부족, 확장 어려움 |
| 완전 분산화 (Decentralized) |
각 사업부·도메인이 독립적으로 마스터 데이터 관리 | 현업 참여 높음, 도메인 맥락 반영, 빠른 처리 | 데이터 불일치, 표준 붕괴, 중복 발생, 그룹 단위 통합 불가 |
| 하이브리드 페더레이티드 (Hybrid Federated) |
표준·정책은 중앙 정의, 운영·책임은 도메인 수행 | 일관성 + 현업 참여 균형. 확장 가능. 도메인 자율성 보장 | 설계 복잡도 높음. 중앙-도메인 인터페이스 명확히 정의 필요 |
2. 중앙화 모델의 한계
완전 중앙화 MDM 모델이 왜 대기업 현장에서 실패하는지 구체적으로 살펴봅니다.
모든 마스터 데이터 변경이 중앙 MDM 팀을 통과해야 합니다. 중앙팀은 5명인데 하루 200건의 변경 요청이 들어옵니다. 처리 대기 기간이 2주로 늘어납니다. 현업은 "MDM이 비즈니스를 막는다"고 불평합니다.
중앙 MDM 팀은 IT 전문가입니다. "이 공급업체를 왜 별도 코드로 분리해야 하는가"에 대한 비즈니스 이유를 알지 못합니다. 비즈니스 맥락 없이 데이터 표준만 강요하는 결과가 됩니다.
사업 규모가 커질수록 마스터 데이터 변경 요청도 증가합니다. 중앙 팀을 계속 늘릴 수는 없습니다. 결국 중앙화 모델은 규모 확장에 비례해 병목이 심화됩니다.
3. 완전 분산 모델의 한계
반대로 완전 분산 모델도 심각한 문제를 야기합니다.
구매팀의 공급업체 분류 기준과 영업팀의 거래처 분류 기준이 달라집니다. 6개월 후 전사 공급업체 분석이 불가능합니다. "팀마다 다른 숫자"가 의사결정을 마비시킵니다.
각 도메인이 독립적으로 마스터 데이터를 생성하면 동일한 공급업체가 구매팀에서는 "삼성전자", 영업팀에서는 "Samsung Electronics"로 따로 등록됩니다. MDM을 도입하지 않은 것과 같은 결과가 됩니다.
계열사 간 자재 공유, 그룹 통합 구매, 전사 ESG 보고가 불가능해집니다. 도메인별 분산된 마스터 데이터로는 그룹 수준의 전략적 의사결정을 지원할 수 없습니다.
4. 하이브리드 페더레이티드 모델이란
하이브리드 페더레이티드 모델은 "무엇을 중앙에서 하고, 무엇을 도메인에서 할 것인가"를 명확히 분리하는 구조입니다.
| 중앙 거버넌스 담당 | 도메인 담당 |
|---|---|
| 마스터 데이터 표준 정의 | 표준에 따른 데이터 입력·수정 |
| 코드 체계·분류 기준 | 도메인 특화 속성 추가 |
| 품질 기준선(SLA) 설정 | 품질 목표 달성 책임 |
| 거버넌스 정책·프로세스 | 일상적인 변경 요청 처리 |
| 도메인 간 데이터 통합 규칙 | 도메인 내 데이터 의사결정 |
이 분리가 명확할수록 중앙의 병목이 줄어들고 도메인의 자율성이 높아집니다. 동시에 전사 데이터 일관성은 중앙 표준이 보장합니다.
5. 중앙 거버넌스 레이어 — 무엇을 중앙에서 담당하는가
중앙 거버넌스는 "모든 것을 통제"하는 것이 아니라 "공통 기반을 제공"하는 역할입니다.
| 중앙 거버넌스 영역 | 구체적 내용 |
|---|---|
| 마스터 데이터 표준 | 전사 공통으로 사용할 코드 체계, 분류 기준, 필드 정의, 값 목록(Reference Data) 관리. 예: 전사 공통 국가 코드, 통화 코드, 사업부 코드 표준 |
| 품질 기준 및 측정 체계 | 도메인별 최소 품질 기준선(SLA) 정의. 전사 품질 대시보드 운영. 도메인별 품질 점수 측정 및 공개 |
| 거버넌스 정책 | 마스터 데이터 생성·변경·폐기 기준. 승인 프로세스 프레임워크. 예외 처리 기준. 규제 컴플라이언스 정책 |
| 도메인 간 통합 규칙 | 도메인 간 엔티티 관계 정의(고객 ↔ 계약, 자재 ↔ 공급업체). 크로스 도메인 엔티티 해상도 기준. 통합 ID 체계 관리 |
| 거버넌스 위원회 운영 | 전사 데이터 거버넌스 위원회 소집·운영. 표준 변경 심의. 도메인 간 분쟁 조정 |
| 데이터 카탈로그 | 전사 마스터 데이터 제품 카탈로그 운영. 도메인별 Data Product 등록·관리 |
하이브리드 모델에서 중앙 거버넌스 팀은 "정책 설계자"이지 "데이터 처리자"가 아닙니다. MAU 100만 기준 중앙팀 3~7명이 적정하며, 이 팀은 표준 개발·위원회 운영·품질 모니터링에 집중하고 일상적인 데이터 변경은 도메인이 처리합니다.
6. 도메인 책임 레이어 — 무엇을 도메인에서 담당하는가
도메인은 중앙이 정한 표준 안에서 자율적으로 운영합니다.
| 도메인 책임 영역 | 구체적 내용 |
|---|---|
| 도메인 데이터 오너십 | 해당 도메인 마스터 데이터의 품질·완전성에 대한 책임. 도메인 Data Product Owner 역할 수행 |
| 일상적 데이터 관리 | 중앙 표준 범위 내에서의 마스터 데이터 신규 등록·수정·폐기. 도메인 특화 속성(전중앙 표준 + 도메인 확장 속성) 관리 |
| 도메인 특화 규칙 | 중앙 표준을 준수하면서 도메인 특화 비즈니스 규칙 추가. 예: 구매 도메인의 공급업체 평가 기준, 마케팅 도메인의 고객 세그먼트 분류 |
| 품질 목표 달성 | 중앙이 설정한 품질 SLA 목표를 달성하기 위한 도메인 내부 개선 활동. 품질 점수 분기별 중앙 보고 |
| 소비자 지원 | 해당 도메인 Data Product를 사용하는 소비자(AI 팀·분석팀) 지원 및 피드백 수집 |
7. 중앙-도메인 인터페이스 설계
하이브리드 모델의 성패는 중앙과 도메인 사이의 인터페이스가 얼마나 명확하게 설계되었는가에 달려 있습니다.
도메인이 표준 변경이 필요하면 거버넌스 위원회에 공식 요청합니다. 위원회는 전체 도메인에 미치는 영향을 검토 후 승인·거절·수정을 결정합니다. 승인된 변경은 모든 도메인에 동시 적용됩니다.
중앙 공통 속성(모든 도메인이 공유하는 필드)과 도메인 확장 속성(해당 도메인만 사용하는 추가 필드)을 구분합니다. 도메인은 중앙 공통 속성은 반드시 준수하고, 확장 속성은 자유롭게 추가할 수 있습니다.
예시: 공급업체 마스터의 공통 속성(사업자번호·법인명·국가코드)은 전사 표준. 구매 도메인 확장 속성(납기 신뢰도·환경 인증)은 구매팀만 사용.
도메인이 스스로 처리할 수 있는 범위와 중앙에 에스컬레이션해야 하는 경우를 사전에 정의합니다. 예: "도메인 내 데이터 수정은 도메인 스튜어드 처리. 타 도메인에 영향을 주는 변경은 반드시 중앙 승인".
도메인은 월 1회 품질 점수를 중앙에 보고합니다. 중앙은 전체 도메인의 품질 현황을 통합 대시보드로 공개합니다. 품질 SLA 미달 도메인은 개선 계획을 제출합니다.
8. 한국 대기업 환경에서의 적용 전략
한국 대기업의 그룹사 구조, 잦은 조직 개편, 계열사 간 데이터 공유 민감성을 고려한 현실적 적용 전략입니다.
| 한국 기업 특성 | 과제 | 하이브리드 모델 적용 |
|---|---|---|
| 그룹사 복합 구조 | 지주사·계열사 간 표준 통일 vs 계열사 자율성 충돌 | 그룹 공통 표준은 지주사 주도, 계열사별 확장 속성은 자율 |
| 잦은 조직 개편 | 조직 개편마다 도메인 오너십 재설정 필요 | 역할 기반 오너십(직책 연동)으로 개편 시 자동 이전 |
| 사업부 간 경쟁 | 데이터 공유를 경쟁 우위 포기로 인식 | 공유 데이터와 도메인 전용 데이터를 명확히 분리. 전용 데이터는 공유 강제 안 함 |
| SAP ERP 중심 | SAP MDG의 중앙화 성격과 페더레이티드 모델 충돌 | SAP MDG를 중앙 거버넌스 엔진으로, 도메인은 SAP MDG API로 접근하는 레이어 설계 |
| 단기 성과 압박 | 하이브리드 모델 구축에 1~2년 필요. 경영진 인내 부족 | 첫 3개월에 1개 도메인 Quick Win 달성으로 경영진 신뢰 확보 후 확장 |
9. 하이브리드 모델 성숙도 단계
| 단계 | 기간 | 핵심 작업 | 성공 지표 |
|---|---|---|---|
| 1단계 기반 구축 |
3~6개월 | 1개 도메인(공급업체 또는 고객) 파일럿. 중앙 표준 초안 작성. 도메인 오너 지정 | 파일럿 도메인 품질 점수 측정 시작 |
| 2단계 프레임워크 정립 |
6~12개월 | 거버넌스 위원회 공식 발족. 중앙-도메인 인터페이스 프로세스 확정. 품질 보고 체계 가동 | 위원회 정기 운영, 도메인별 월간 품질 보고 |
| 3단계 전체 도메인 확장 |
12~24개월 | 전체 마스터 도메인으로 하이브리드 모델 확장. Data Product 형태로 배포 시작 | 전 도메인 품질 SLA 준수율 80% 이상 |
| 4단계 AI 통합 |
24개월~ | Agentic MDM과 하이브리드 거버넌스 결합. AI가 도메인 수준 운영 일부 자동화 | 중앙 에스컬레이션 건수 50% 감소 |
10. 정리
하이브리드 페더레이티드 모델은 MDM의 영원한 딜레마—중앙화 vs 분산화—에 대한 현실적인 해답입니다. 완벽한 통제도, 완전한 자율도 아닌, 표준의 중앙화와 운영의 분산화라는 균형이 핵심입니다.
도메인은 그 규칙 안에서 최선을 다해 플레이합니다.
이것이 하이브리드 페더레이티드 MDM의 본질입니다."
다음 글에서는 배치 처리 기반 MDM의 한계를 극복하는 실시간 데이터 패브릭 아키텍처를 살펴봅니다.
Part 4. Technical Deep-Dive — 아키텍처와 표준의 혁신
- Data Product 컨셉의 도입: 마스터 데이터를 제품처럼 관리하고 배포하라
- 하이브리드 페더레이티드 모델: 중앙 거버넌스와 도메인 책임의 균형 (현재 글)
- 실시간 데이터 패브릭: 배치 처리를 넘어 실시간 동기화의 시대로
- AI 에이전트 시대의 MDM API 전략: 데이터 연동 표준화의 최전선
- DAMA International. (2017). DAMA-DMBOK, 2nd Edition: Chapter 3 — Data Governance. Technics Publications.
- Dehghani, Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale, Chapter 4: Federated Computational Governance. O'Reilly Media.
- Gartner. (2024). Federated Data Governance: Best Practices for Distributed Organizations. Gartner Research.
- Loshin, D. (2009). Master Data Management, Chapter 5: MDM Governance Models. Morgan Kaufmann.
- Forrester Research. (2024). Federated vs. Centralized Data Management: A Comparative Analysis. Forrester Research.
- 한국데이터산업진흥원. (2024). 데이터 거버넌스 체계 구축 안내서. 한국데이터산업진흥원.
※ 이 블로그는 MDM, CIAM, DX, AX, AI 등 글로벌 IT 트렌드와 디지털 전략을 실무 전문가 관점에서 분석합니다.
댓글
댓글 쓰기