15. Data Product 컨셉의 도입: 마스터 데이터를 제품처럼 관리하고 배포하라
마스터 데이터는 오랫동안 "IT 시스템이 관리하는 내부 자산"으로 취급받았습니다. 현업이 필요하면 IT에 요청하고, IT가 처리해서 넘겨주는 방식이었습니다. 이 모델은 느리고, 현업의 실제 니즈를 반영하기 어렵고, 책임이 모호합니다.
Data Product 컨셉은 이 패러다임을 바꿉니다. 마스터 데이터를 소프트웨어 제품처럼 설계하고, 소비자(현업·AI·분석 시스템)의 요구에 맞게 배포하며, 품질과 SLA를 보장하는 방식입니다. 이 글에서는 Data Product 컨셉이 무엇인지, MDM에서 어떻게 구현되는지, DPDS(Data Product Descriptor Specification) 표준의 역할, 그리고 실제 구현 방법을 정리합니다.
1. Data Product란 무엇인가
Data Product는 데이터를 소프트웨어 제품처럼 설계·제공·유지하는 접근법입니다. 데이터를 단순히 저장하고 조회하는 것이 아니라, 특정 소비자의 요구를 충족하도록 포장하고, 품질을 보증하며, 지속적으로 개선합니다.
| 소프트웨어 제품 | Data Product (마스터 데이터) |
|---|---|
| API로 기능 제공 | API로 마스터 데이터 제공 |
| 문서화된 스펙 | 데이터 스키마·계보·품질 SLA 문서화 |
| 버전 관리 | 마스터 데이터 버전·변경 이력 관리 |
| 제품 오너 (Product Owner) | 데이터 제품 오너 (Data Product Owner) |
| 사용자 피드백 반영 | 소비자(현업·AI) 요구 반영한 지속 개선 |
전통적인 MDM에서 마스터 데이터는 ERP·CRM 시스템에 종속된 "내부 테이블"이었습니다. Data Product 접근에서는 마스터 데이터가 자체적인 생애주기와 소유권을 가진 독립적인 제품이 됩니다.
2. 왜 마스터 데이터를 제품처럼 다뤄야 하는가
현재 대부분의 기업이 마스터 데이터를 "시스템 부속물"로 다루는 결과로 나타나는 문제들이 있습니다.
| 현재 문제 | 구체적 증상 |
|---|---|
| 소비자 중심 없음 | 마케팅 AI가 필요한 형태의 고객 마스터가 없어 별도로 데이터를 가공해야 합니다. "데이터는 있는데 쓸 수 있는 형태가 아니다"는 불만이 반복됩니다. |
| 품질 SLA 없음 | 공급업체 마스터의 완전성이 80%인지 95%인지 알 수 없습니다. 품질을 보장하는 주체도 없고, 보장 수준도 정의되지 않았습니다. |
| 발견 불가능 | 어떤 마스터 데이터가 있는지, 어디에 있는지, 어떻게 사용할 수 있는지 알 수 없습니다. 동일한 데이터를 여러 팀이 각자 따로 만들어 씁니다. |
| 계보 불투명 | 이 제품 코드가 어디서 왔는지, 어떤 시스템에서 사용되는지 알 수 없습니다. 오류 수정 시 영향 범위 파악이 불가능합니다. |
| 책임 분산 | 데이터 오류가 생겨도 "IT가 고쳐야 한다"와 "현업이 입력을 잘못한 것"이 서로 책임을 떠넘깁니다. |
Data Product 접근은 이 모든 문제를 해결합니다. 데이터를 제품처럼 다루면 소비자 중심 설계, 품질 SLA, 발견 가능성, 계보 추적, 명확한 책임이 자연스럽게 따라옵니다.
3. Data Product의 5가지 핵심 특성
Data Mesh의 제안자 Zhamak Dehghani는 Data Product의 핵심 특성을 다음과 같이 정의했습니다.
마스터 데이터 제품이 데이터 카탈로그에 등록되어 누구나 찾을 수 있어야 합니다. "고객 마스터 데이터가 어디 있나요?"라는 질문이 카탈로그 검색으로 즉시 해결됩니다. 메타데이터(스키마·갱신 주기·소유자·SLA)가 함께 제공됩니다.
마스터 데이터 제품에 고유한 주소(API 엔드포인트·URN)가 있어야 합니다. 어떤 시스템에서도 같은 주소로 동일한 데이터에 접근할 수 있습니다. ERP, AI 모델, 분석 플랫폼이 모두 같은 고객 마스터 API를 참조합니다.
정의된 품질 SLA를 충족함을 보증합니다. "이 데이터의 완전성은 95% 이상, 정확성은 99% 이상을 보장한다"는 약속이 있고, 실제 측정값이 공개됩니다. 소비자가 데이터의 품질을 신뢰하고 사용할 수 있습니다.
데이터 제품 자체에 사용 방법·스키마·계보·제약 조건이 포함됩니다. 외부 문서를 찾을 필요 없이 데이터 제품이 스스로 무엇인지 설명합니다.
표준 인터페이스(REST API·GraphQL·이벤트 스트림)와 공통 데이터 포맷을 사용하여 어떤 시스템과도 연동됩니다. 특정 플랫폼에 종속되지 않습니다.
4. 마스터 데이터 제품 설계 — 무엇을 포함해야 하는가
마스터 데이터를 Data Product로 설계할 때 포함해야 할 핵심 구성요소입니다.
| 구성요소 | 내용 | 예시 (고객 마스터 제품) |
|---|---|---|
| 제품 아이덴티티 | 고유 이름, 버전, 오너, 도메인 분류 | 이름: Customer-Master-v2, 오너: 마케팅본부, 도메인: Customer |
| 데이터 스키마 | 필드 정의, 데이터 타입, 필수 여부, 값 범위 | customer_id(필수), name, email, phone, segment_code 등 |
| 품질 SLA | 완전성·정확성·최신성 목표치 및 측정 주기 | 완전성 ≥95%, 정확성 ≥99%, 갱신 주기 ≤24시간 |
| 접근 인터페이스 | REST API 엔드포인트, 인증 방식, 사용 가능 쿼리 | GET /customers/{id}, 검색 API, 변경 이벤트 구독 |
| 데이터 계보 | 원천 시스템, 변환 로직, 연관 제품 | CRM → MDM 처리 → Customer-Master-v2 → AI 모델·분석 DW |
| 정책·제약 | 접근 권한, 개인정보 처리 기준, 보존 기간 | 마케팅 동의자만 마케팅 API 접근. GDPR 삭제 요청 처리 30일 |
| 이용 가이드 | 소비자를 위한 사용 방법, 예시 코드, FAQ | API 호출 예시, 세그먼트 코드 정의, 오류 처리 가이드 |
5. DPDS(Data Product Descriptor Specification) 표준
DPDS는 Data Product를 기계가 읽을 수 있는 형태로 표현하는 오픈 표준 스펙입니다. OpenAPI(REST API 스펙)가 API를 표준화하듯, DPDS는 Data Product를 표준화합니다.
- 자동화된 등록: DPDS 파일을 데이터 카탈로그에 등록하면 메타데이터가 자동으로 색인됩니다.
- 표준 계약: 마스터 데이터 제품을 소비하는 모든 시스템이 동일한 스펙 문서를 참조합니다.
- 거버넌스 자동화: DPDS에 정의된 정책을 정책 엔진이 자동으로 집행합니다.
- 계보 추적: DPDS의 연결 정보를 기반으로 데이터 계보를 자동으로 생성합니다.
{
"dataProductDescriptor": "1.0.0",
"info": {
"name": "customer-master",
"version": "2.1.0",
"domain": "Customer",
"owner": {
"team": "마케팅본부 데이터팀",
"contact": "customer-data@company.com"
}
},
"inputPorts": [...],
"outputPorts": [
{
"name": "customer-api",
"type": "REST",
"promises": {
"slo": {
"completeness": ">= 95%",
"accuracy": ">= 99%",
"freshness": "<= 24h"
}
}
}
],
"policies": {
"dataRetention": "계약 종료 + 5년",
"accessControl": "마케팅 동의자만 마케팅 API 접근"
}
}
6. MDM에서 Data Product 구현 방법
MDM에서 Data Product 컨셉을 실제로 구현하는 단계별 접근법입니다.
| 단계 | 작업 | 핵심 내용 |
|---|---|---|
| 1단계 | 소비자 발굴 | 마스터 데이터의 주요 소비자(AI 모델·분석 팀·ERP·마케팅 플랫폼)를 파악하고, 각 소비자가 필요로 하는 데이터 형태와 품질 수준을 인터뷰로 수집합니다. |
| 2단계 | 제품 설계 | 소비자 요구에 맞춘 데이터 스키마·API 인터페이스·품질 SLA를 설계합니다. 소비자별로 다른 형태의 API 엔드포인트를 제공할 수 있습니다. |
| 3단계 | DPDS 작성 | 설계된 Data Product를 DPDS 형식으로 문서화합니다. 데이터 카탈로그(Collibra·Alation·DataHub 등)에 등록합니다. |
| 4단계 | 품질 파이프라인 구축 | SLA 충족을 자동으로 모니터링하는 품질 파이프라인을 구축합니다. SLA 위반 시 알림이 발송됩니다. |
| 5단계 | 배포 및 운영 | API 게이트웨이를 통해 마스터 데이터 제품을 소비자에게 노출합니다. 이용 통계·품질 점수를 정기적으로 소비자와 공유합니다. |
| 6단계 | 피드백 루프 | 소비자 피드백을 수집하여 스키마·API·품질 기준을 지속적으로 개선합니다. 새로운 소비자 요구가 생기면 새 버전(v3.0)으로 확장합니다. |
7. Data Product와 Data Mesh의 관계
Data Product는 Data Mesh 아키텍처의 핵심 구성 단위입니다. 두 개념의 관계를 명확히 이해해야 합니다.
| 항목 | Data Mesh | Data Product |
|---|---|---|
| 정의 | 도메인별로 데이터를 분산 소유하고 관리하는 아키텍처 패러다임 | 데이터를 소비자 중심의 제품으로 패키징하는 단위 |
| 관계 | Data Mesh의 실행 단위가 Data Product | Data Mesh 없이도 독립적으로 도입 가능 |
| MDM과의 연관 | MDM 거버넌스가 Data Mesh의 "연합 거버넌스" 레이어 역할 | 마스터 데이터를 Data Product 형태로 제공하는 방식 |
Data Mesh가 도메인 자율성을 강조하면 "그럼 MDM이 필요 없어지는가?"라는 질문이 생깁니다. 아닙니다. Data Mesh에서 각 도메인이 자체 데이터를 관리하더라도, 도메인 간 공통 기준(고객 ID 체계, 코드 표준, 데이터 품질 기준)은 MDM이 제공합니다. MDM은 Data Mesh의 중앙 거버넌스 허브 역할을 합니다.
8. 도입 시 주요 고려사항
- 기술부터 시작하는 실수: DPDS·API·카탈로그 도구를 먼저 도입하려 합니다. 소비자 요구를 먼저 파악하고, 어떤 마스터 데이터를 제품으로 만들지 결정한 후에 기술을 선택해야 합니다.
- 모든 데이터를 한 번에 제품화: 고객·제품·자재·공급업체 모든 마스터를 동시에 Data Product로 전환하려 합니다. 비즈니스 임팩트가 가장 큰 단일 도메인부터 시작하십시오.
- 소비자 없는 제품 설계: IT와 데이터팀이 소비자 없이 "완벽한" Data Product를 설계합니다. 실제 소비자(AI 팀·마케팅·분석팀)가 처음부터 설계에 참여해야 합니다.
- SLA 없는 제품 출시: 품질 SLA 없이 마스터 데이터를 "제품"이라고 부르는 것은 이름만 바꾼 것입니다. SLA가 없으면 소비자가 신뢰하지 않습니다.
9. 정리
Data Product 컨셉은 MDM의 가장 중요한 진화 방향 중 하나입니다. 마스터 데이터를 IT 시스템의 부속물이 아닌 비즈니스 가치를 창출하는 자산으로 재정의합니다. 소비자 중심 설계, 품질 SLA 보증, 발견 가능성—이 세 가지가 갖춰질 때 마스터 데이터는 진정한 "제품"이 됩니다.
소비자가 필요할 때 신뢰하고 사용할 수 있도록
품질·문서·접근성을 보장한다는 약속입니다."
다음 글에서는 중앙 집중형 MDM과 분산 도메인 책임의 균형을 잡는 하이브리드 페더레이티드 MDM 모델을 다룹니다.
Part 4. Technical Deep-Dive — 아키텍처와 표준의 혁신
- Data Product 컨셉의 도입: 마스터 데이터를 제품처럼 관리하고 배포하라 (현재 글)
- 하이브리드 페더레이티드 모델: 중앙 거버넌스와 도메인 책임의 균형
- 실시간 데이터 패브릭: 배치 처리를 넘어 실시간 동기화의 시대로
- AI 에이전트 시대의 MDM API 전략: 데이터 연동 표준화의 최전선
- Dehghani, Z. (2022). Data Mesh: Delivering Data-Driven Value at Scale. O'Reilly Media.
- Data Product Specification (DPDS). (2023). Open Data Product Specification v2.1. https://github.com/opendataproducts
- Gartner. (2024). Data Products: The Next Evolution in Data Management. Gartner, Inc.
- Thoughtworks. (2023). Data Mesh: Principles and Logical Architecture. Thoughtworks Technology Radar.
- Collibra. (2024). Data Products in Practice: Enterprise Guide. Collibra NV.
- Databricks. (2024). Building Data Products on the Lakehouse. Databricks, Inc.
※ 이 블로그는 MDM, CIAM, DX, AX, AI 등 글로벌 IT 트렌드와 디지털 전략을 실무 전문가 관점에서 분석합니다.
댓글
댓글 쓰기