# CMSLAB 데이터 아키텍처 · 공통 마스터 허브 CURRENT

> **2026-09-09 갱신:** [최신 데이터·시스템 설계 v0.2](CMSLAB_데이터·시스템아키텍처_인터뷰반영_2026-09-09_v0.2.md) · [3계층·판매추이·SCM 이관](CMSLAB_제품계층·판매추이·SCM이관_판단근거_2026-09-09.md) · [시각 검토](CMSLAB_데이터·시스템아키텍처_검토.html) 분류군→출시제품→실물 ITEM을 먼저 설계하고 ERP는 필요한 필드만 매핑한다. 파일 업로드/결과 대사, Frozen·Slush·Liquid 변경 계약, 채널 키·업로드 책임을 보강했다. 아래 v0.1은 출발점이며 충돌 시 최신 정렬을 따른다.

> 버전: v0.1 · 2026-08-29  
> 용도: 프로젝트 전체 구조와 인터뷰 누락을 점검하는 내부 기준안  
> 상태: **구조 가설** — CSP·제품·테이블·갱신 SLA·쓰기 권한을 확정한 문서가 아님

[시각 검토 화면](CMSLAB_데이터아키텍처_마스터허브_검토.html) · [전체 그림 SVG](CMSLAB_데이터아키텍처_마스터허브_v0.1.svg) · [원천별 갱신주기 근거표](CMSLAB_원천별_갱신주기_근거표_CURRENT.md) · [애플리케이션 IA 가설](../IA/CMSLAB_IA_가설_검토.html)

## 1. 이번 보강의 결론

- 기존 IA는 사용자가 수행할 업무와 메뉴를 묶은 **애플리케이션 IA 가설**로 유지한다.
- 프로젝트 전체 그림은 `원천 → Raw → 표준·마스터 → 업무 마트 → 화면·알림`의 **데이터 아키텍처**로 별도 관리한다.
- 제품·원료·BOM·LOT·창고·채널 등은 한 기능의 하위 메뉴가 아니라 모든 업무영역이 함께 사용하는 **횡단 공통 허브**로 둔다.
- ERP·WMS·채널 코드는 없애지 않고 원문 그대로 보존하며, 안정적인 표준 ITEM과 `ITEM_CODE_MAP`으로 연결한다.
- 상세 메뉴, 등록 위치, 승인자, ERP·WMS 쓰기 방식은 실제 업무 인터뷰와 권한 확인 후 확정한다.

## 2. 적용한 설계 원칙

| 원칙 | CMSLAB 적용 | 현재 결정 수준 |
|---|---|---|
| 사용자 목적에서 IA를 시작 | 메뉴는 조직도가 아니라 `조회·판단·조치·승인` 업무로 묶고 인터뷰 후 검증 | 방향 확정 |
| 원본과 파생을 분리 | 원천 형식을 Raw에 보존하고 표준화·중복제거·매핑은 다음 층에서 수행 | 방향 확정 |
| 공통 마스터를 명시적 허브로 관리 | 제품·원료·창고·채널·거래선을 업무 마트보다 앞에서 공통 적용 | 방향 확정 |
| 정본·오너·변경이력 추적 | 필드별 SoR 후보, 승인자, `valid_from/to`, 코드맵, 변경사유 기록 | 확인 필요 |
| 데이터 품질은 층별로 강화 | Raw 스키마·중복 확인 → 표준키 매핑 → 마트 대사·업무 규칙 확인 | 방향 확정 |
| 갱신주기는 업무 필요 기반 SLO로 정의 | 원천 변경주기·추출주기·플랫폼 freshness를 별도 기록 | 제안 |
| 계보·권한·실패 재처리를 횡단 통제 | 모든 원천과 마트에 owner, sensitivity, lineage, run status 적용 | 방향 확정 |

이 원칙은 특정 클라우드 제품을 선택한 것이 아니다. 구조 검증 뒤 고객 소유 환경과 운영역량에 맞는 구현수단을 선택한다.

## 3. 레이어 구조

| 레이어 | 역할 | CMSLAB 핵심 객체 | 완료 판단 |
|---|---|---|---|
| L0 원천 | 운영 시스템과 고객 작성 파일을 변경 없이 식별 | ERP, 한익, 품고, 글로비스, Google Sheets, 채널·광고, BigQuery | 시스템·객체·오너·추출방식 등록 |
| L1 Raw/ODS | 수령 원본과 추출 시점·스키마를 재현 가능하게 보존 | 원본 파일/테이블, `extracted_at`, `snapshot_at`, schema version | 재수집·재처리 가능, 원본 합계 보존 |
| L2 표준·통합 | 형식·단위·상태를 정리하고 원천키를 표준키에 연결 | 표준 ITEM, 코드맵, 창고·채널·상태·단위, 재고/입출고 표준 fact | 매핑률·중복·미매핑·유효기간 측정 |
| L3 업무 마트 | 승인된 업무기준으로 조회·대사 가능한 데이터 제공 | 재고·공급, 매출·마감·손익·계획, 마케팅, 품질, MI | 원천–마트 합계와 정책 산식 대사 |
| L4 서비스 | 사용자 목적별 조회·검토·승인·알림 제공 | 통합재고, 가마감, 판매계획, 광고효과, LOT/BOM 추적 | 역할별 시나리오·권한·KPI 검증 |

## 4. 전사 공통 마스터 허브

### 4.1 마스터 도메인

| 도메인 | 핵심 객체 | 연결 대상 | 우선 인터뷰 |
|---|---|---|---|
| 제품·상품 | `ITEM`, 제품/SKU, 세트·리뉴얼·단종, 바코드 | ERP·WMS·판매계획·매출·채널 | BM·SCM·재경 |
| 원료·구성 | `MATERIAL`, INCI, BOM, 제조사·공급처 | 연구소·RM·SCM·제품 | 연구개발·RM·SCM·BM |
| LOT·품질 | LOT, 제조·유통기한, 판정·보류·불량 | WMS·출고·VOC·품질문서 | RM·SCM·연구개발 |
| 물류 | 창고, 센터, 로케이션, 재고상태, 수량단위 | ERP·한익·품고·글로비스 | SCM·물류·재경 |
| 채널·거래 | 채널, 판매처, 거래선, 국가·법인 | 매출·계획·프로모션·광고 | 영업·사업·마케팅·재경 |
| 공통 참조 | 브랜드, 카테고리, 조직, 단위, 통화, 국가, 캘린더, 상태 | 모든 도메인 | 필드별 오너 확인 |

### 4.2 매핑·이력 객체

- `ITEM_CODE_MAP(source_system, source_code, item_id, valid_from, valid_to, status)`
- `WAREHOUSE_CODE_MAP(source_system, source_warehouse_code, warehouse_id, valid_from, valid_to)`
- `CHANNEL_CODE_MAP(source_system, source_channel_code, channel_id, valid_from, valid_to)`
- 변경요청·승인·반려·효력일·변경사유·전파상태
- 원천별 필드 오너, 업무 오너, 기술 오너, 민감도, 품질 규칙

### 4.3 쓰기 경계 가설

1. ERP `item_code`는 운영 정본 **후보**로 사용하되 ERP 품목 raw와 코드 결정권자 확인 전 확정하지 않는다.
2. 플랫폼은 표준 `item_id`, 원천 코드맵, 확장속성, 변경이력, 품질상태를 우선 관리한다.
3. WMS·채널의 자체 코드는 보존하고 표준 ITEM에 매핑한다.
4. 초기에는 `조회 → 매핑 추천 → 담당자 검토/승인 → 연결 또는 업로드`를 우선한다.
5. ERP·WMS 직접 쓰기와 자동 전파는 API·권한·감사·오류복구가 확인된 뒤 별도 결정한다.

## 5. 횡단 통제

| 통제 | 최소 기록 |
|---|---|
| 오너십·승인 | 업무 오너, 필드 오너, 기술 오너, 등록·수정·승인 권한 |
| 품질 | completeness, uniqueness, validity, consistency, 매핑률, 대사차이 |
| 보안 | 역할기반 접근, 개인정보·원료/처방 민감도, 반출·보존 규칙 |
| 계보 | source system/file/sheet, extracted/loaded time, transform version, downstream consumer |
| 운영 | 실행상태, freshness, 실패원인, 재처리자, 재실행 결과 |

## 6. 인터뷰 후 확정할 항목

- 제품·원료·창고·채널 마스터의 필드별 작성자·승인자·최종 결정자
- ERP 품목코드의 생성·변경·단종·리뉴얼·세트 처리 흐름
- 한익·품고·글로비스에 신규 품목이 등록되는 시점과 ERP 코드 전파 방식
- 원천별 실제 갱신·추출시각, 지연·누락·실패 처리와 필요한 freshness
- 창고이동·입고·출고·매출반영의 실제 키와 승인 순서
- 역할별 첫 화면, 조회·등록·수정·승인 범위와 내려받기 권한

## 7. 버전 계획

| 버전 | 게이트 | 반영 내용 |
|---|---|---|
| v0.1 | 현재 | 레이어·공통 마스터 도메인·쓰기 가드레일·주기 가설 |
| v0.2 | 제품·원료·재고 인터뷰 후 | SoR/SoE, 오너, 코드 생성·전파, 실제 주기·예외 |
| v0.5 | ITEM–재고–매출 표본 대사 후 | 물리 테이블 후보, 조인키, SCD/이력, 품질 규칙·SLO |
| v1.0 | MVP/UAT 전 | 권한, 실패 재처리, 운영 SLA, 승인된 화면 IA와 배포 구조 |

## 8. 공식 참고자료

- [GOV.UK Government Design Principles](https://www.gov.uk/guidance/government-design-principles): 사용자 요구에서 시작하고 데이터로 설계하며 반복 검증한다.
- [Microsoft Purview — Master data management](https://learn.microsoft.com/en-us/purview/data-governance-master-data-management): 중복 제거된 authoritative master/golden record를 거버넌스 기준으로 사용한다.
- [Microsoft Fabric — Medallion lakehouse architecture](https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture): 원본을 보존하고 Raw→표준화→업무용 데이터로 품질을 단계적으로 강화한다.
- [Google Cloud Dataflow — Plan your pipeline](https://docs.cloud.google.com/dataflow/docs/guides/plan-pipelines): freshness를 측정 가능한 SLO로 정의하고 end-to-end 지연을 본다.

## 9. 내부 근거

- [고객 기준문서 원장](../discovery/_materials/files/customer-basis-documents.md)
- [시스템·데이터 취합 원장](../discovery/03-systems.md)
- [WMS 2차 전달 원장](../discovery/_materials/files/wms-data.md)
- [재고·공급 프로세스 원장](../discovery/02-process/02-inventory-supply.md)
- [제품키 전파전략](../../03_실행관리/00_프로젝트작전실/작업중/제품원료재고_고객협의패키지/02_제품키_전파전략.html)