Brain539. 마스터 데이터 관리 (MDM - Master Data Management)
⚠️ 이 문서는 영업팀은 고객을 '거래처'라고 부르고 마케팅팀은 '회원'이라고 부르며 서로 다른 기준으로 데이터를 쌓다가 나중에 통계가 전혀 안 맞는 대참사를 막기 위해, **회사 전체에서 사용하는 가장 핵심적이고 변하지 않는 기준 데이터(마스터 데이터)를 100% 일치하도록 중앙에서 통제하는 'MDM 체계'**를 다룹니다.
핵심 인사이트 (3줄 요약)
- 본질: 고객, 상품, 직원처럼 회사의 비즈니스를 굴러가게 하는 '가장 중요한 뼈대 명사들(마스터 데이터)'을 전사적으로 통일하여 단일 진실 공급원(SSOT)을 만드는 기술과 프로세스다.
- 해결하는 문제: A 시스템의 '홍길동'과 B 시스템의 '홍길동'이 동일 인물인지 컴퓨터는 모른다. 이 데이터의 사일로(Silo)와 파편화를 해결하여 중복을 배제한다.
- 가치: MDM이 안 되어 있으면 데이터 웨어하우스(DW)에 백날 데이터를 부어봤자 조인(JOIN)이 불가능해서 통계를 낼 수 없는 쓰레기장(GIGO)이 된다.
Ⅰ. 개요: 누가 진짜 홍길동인가? (Context & Necessity)
우리 회사에 쇼핑몰 앱과 오프라인 매장이 있다.
- 쇼핑몰 DB:
고객ID: A100,이름: 홍길동,번호: 010-1234 - 오프라인 DB:
고객번호: 999,고객명: 홍길동,번호: 0101234
사장님이 "홍길동 고객이 우리 회사에서 온오프라인 합쳐서 총 얼마 썼는지 뽑아봐!"라고 지시했다. 데이터 분석가는 멘붕에 빠진다. 쇼핑몰의 A100과 오프라인의 999가 같은 사람인지 조인(JOIN)할 키(Key)가 없기 때문이다. 이름과 번호로 억지로 조인하려 해도 텍스트 포맷이 달라서 매칭이 안 된다.
이 끔찍한 데이터 파편화를 막기 위해, 회사 중앙에 '진짜 마스터 고객 테이블'을 하나 딱 만들고, 모든 부서가 무조건 이 테이블의 고객ID를 가져다 쓰게 통제하는 것이 바로 **MDM(마스터 데이터 관리)**이다.
📢 섹션 요약 비유: MDM은 국가의 **'주민등록 시스템'**과 같습니다. 병원, 은행, 학교가 각자 마음대로 사람에게 번호를 부여하면 이 사람이 그 사람인지 알 길이 없죠. 하지만 국가가 '주민등록번호'라는 마스터 데이터를 발급하고 모두가 이걸 쓰게 강제하면, 세상 모든 시스템에서 이 사람의 기록을 한 번에 통합해서(JOIN) 조회할 수 있습니다.
Ⅱ. 마스터 데이터(Master Data)의 특징 ★
일반적인 거래 데이터(Transaction Data)와 마스터 데이터를 구분하는 것은 시험 단골 문제다.
1. 트랜잭션 데이터 (영수증)
- 성격: '사건(Event)'이다.
- 특징: 수명이 짧고, 데이터양이 무한대로 폭발적으로 늘어난다. (예:
결제내역,접속로그) - 변경: 한 번 발생하면 다시는 수정(
UPDATE)될 일이 거의 없다.
2. 마스터 데이터 (명부)
- 성격: '주체(Entity)'이자 '기준'이다.
- 특징: 데이터양이 적고(회원 수, 상품 수 등), 한 번 만들어지면 잘 안 바뀐다. (예:
고객,상품,매장,부서) - 변경: 트랜잭션 데이터가 쌓일 때 반드시 참조(JOIN)되는 뼈대가 되며, 이 마스터 데이터가 고쳐지면 전사의 모든 쿼리가 영향을 받는다.
Ⅲ. 실무 아키텍처: MDM 구축의 3단계
MDM을 구축하는 것은 기술 20%, 사내 정치 80%의 험난한 과정이다.
- 데이터 정제 (Cleansing) & 식별
- 사방에 흩어진 데이터에서 쓰레기(오타, 띄어쓰기 오류)를 씻어낸다.
- A 시스템의 '홍길동'과 B 시스템의 '홍길동'이 동일인인지 알고리즘(이름+전화번호+주소 매칭)으로 찾아낸다.
- 골든 레코드 (Golden Record) 생성
- 중복된 데이터 중 "이게 가장 정확하고 믿을 수 있는 진짜 데이터야!"라고 선언한 최종 마스터 데이터를 만들어 중앙 MDM 허브에 저장한다.
- 동기화 (Synchronization)
- 골든 레코드가 만들어지면, 이를 다시 A 시스템과 B 시스템으로 쏴주거나(Push), 각 시스템이 알아서 조회(Pull)해가게 만들어서 회사 전체의 데이터를 강제로 똑같이 맞춘다.
┌──────────────────────────────────────────────────────────────┐
│ MDM (마스터 데이터 관리) 아키텍처 통합 과정 시각화 │
├──────────────────────────────────────────────────────────────┤
│ │
│ [ 💔 사일로 (Silo) 현상: 파편화된 데이터 ] │
│ 영업팀: "아이폰15" (코드: A) │
│ 물류팀: "iPhone 15" (코드: B) │
│ │ (이대로면 엑셀 합칠 때 지옥도 펼쳐짐) │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ 🏭 MDM 허브 (정제 및 통합 과정) │ │
│ │ - 알고리즘: "이거 두 개 똑같은 상품이네? 하나로 합쳐!" │ │
│ │ - 🌟 골든 레코드 생성: [통합코드: P01, 표준명: "iPhone 15"] │ │
│ └───────┬──────────────────────────────────────────────────┘ │
│ │ │
│ ▼ (전사 동기화 배포) │
│ [ 🤝 단일 진실 공급원 (SSOT) 달성 ] │
│ 영업팀: "우리도 P01 쓸게!" / 물류팀: "우리도 P01 쓸게!" │
│ │
│ ★ 결과: 사장님이 P01로 매출을 뽑으면 0.1초 만에 전사 통계가 완벽하게 합쳐짐! │
└──────────────────────────────────────────────────────────────┘
Ⅳ. 결론
"데이터의 뼈대가 썩으면, 어떤 인공지능도 살려낼 수 없다." 수십억 원을 들여 으리으리한 데이터 웨어하우스(DW)와 데이터 레이크(Data Lake)를 구축하고 그 위에 화려한 AI 모델을 돌리는 기업들이 많다. 하지만 그 기업들의 데이터 프로젝트가 실패하는 가장 큰 이유는 바로 이 'MDM'이라는 기초 공사를 무시했기 때문이다. 부서마다 '활성 고객'의 정의가 다르고 '상품 코드'가 일치하지 않으면, 조인(JOIN)된 데이터는 무조건 틀린 값을 뱉어낸다. MDM은 가장 지루하고 티 안 나는 노가다 작업이지만, 회사의 모든 데이터를 하나의 거대한 생명체로 연결해 주는 '척추'이자 '신경망'이다.
📌 관련 개념 맵
- 관련 체계: Data Governance (데이터 거버넌스 - 503번 문서)
- 보조 기술: Data Catalog (메타데이터 사전), Data Lineage (502번 문서)
- 궁극적 목표: SSOT (Single Source of Truth - 단일 진실 공급원)
- 대척점 용어: Data Silo (데이터 사일로 - 각 부서가 데이터를 꽁꽁 숨겨두고 안 합치는 현상)
👶 어린이를 위한 3줄 비유 설명
- 집에 시계가 3개 있는데, 거실 시계는 12시, 내 방 시계는 12시 5분, 주방 시계는 11시 55분을 가리키고 있어요. (파편화된 데이터)
- 엄마가 "지금 몇 시야?" 물어보면 가족들이 다 다른 대답을 해서 혼란스럽겠죠?
- MDM은 9시 뉴스의 '뚜- 뚜- 뚜- 삐!' 하는 표준 시보와 같아요. 온 가족이 그 시보(마스터 데이터)를 듣고 집안의 모든 시계를 12시 정각(골든 레코드)으로 똑같이 맞추는 작업이랍니다!