# CMSLAB 데이터·시스템 아키텍처 — 인터뷰 반영 v0.2


> **최신 정렬:** [분류군→출시제품→실물 ITEM, MD 주문기준 판매추이, SCM 출고 이관](CMSLAB_제품계층·판매추이·SCM이관_판단근거_2026-09-09.md). 분류군은 가변 깊이이며 포장사양·채널 구성·LOT는 별도 축. 이관은 목표이며 완료되지 않음.

> 2026-09-09 · **Proposed / 내부 검토용**. 9/3~9/8 전사록과 9/9 제공 수기 메모·접근 현황에 근거한 설계안. 고객 승인, 기술 제품 선정, API 제공·가격·ERP 쓰기 권한 확정 문서가 아니다.

[회의·수기 근거 허브](../../03_실행관리/회의록/2026-09-09_인터뷰통합정리·수기메모/README.md) · [시각 검토 화면](CMSLAB_데이터·시스템아키텍처_검토.html) · [공통 마스터 CURRENT](CMSLAB_데이터아키텍처_마스터허브_CURRENT.md)

## 1. 전체 그림과 운영 원칙

**표준 데이터와 업무 규칙을 플랫폼에서 관리하고, ERP·WMS·채널은 각자의 업무 실행 정본으로 연결한다.** 비용 때문에 직접 연결하지 못해도 파일 수령부터 대상 시스템 입력용 Excel 생성·업로드 결과 대사까지 같은 데이터 계약으로 운영한다. API는 이 경로의 수집·전달 수단을 바꾸며, 상품 매핑·쿠폰·출고 검증 규칙을 새로 만들 필요가 없게 한다.

전사 플랫폼은 조회만 하는 DW와 계획·승인·정정 작업을 저장하는 운영 DB가 함께 필요하다. 두 역할은 논리적으로 구분하되 초기에는 고객이 운영할 수 있는 최소 구성으로 시작한다. 별도 DW, 메시지 브로커, 실시간 스트리밍 플랫폼 도입을 필수 전제로 두지 않는다. 기존 BigQuery는 글로벌EC 원천 후보이며 전사 DW 선정 근거가 아니다.

기존 ERP·WMS에서 이미 승인 후 자동 출고되는 경로는 연동 범위를 먼저 확인한다. 플랫폼의 신규 출고 파일 경로와 동시에 실행해 이중 출고가 생기지 않도록 요청별 실행 경로를 하나만 지정한다. 경영관리의 현재 출고 승인 책임을 설계만으로 SCM에 이관하지 않는다.

```mermaid
flowchart LR
  ERP[ERP-U 조회·다운로드] --> IN[수집 어댑터\n파일·읽기 DB·허용 API]
  WMS[가온·품고·HGLIS] --> IN
  CH[채널·광고·시트·문서] --> IN
  IN --> RAW[원본 저장\n파일 해시·기간·추출조건]
  RAW --> VAL[형식·중복·매핑 검증]
  VAL -->|오류| EX[예외 작업함\n담당자 수정·재검증]
  EX --> VAL
  VAL --> STD[공통 마스터·표준 사건\n유효기간·원천 계보]
  STD --> MART[매출·재고·품질·계획 마트]
  STD --> WORK[팀 업무표·승인]
  MART --> UI[역할별 BI·개인 분석]
  WORK --> OUT[승인 데이터 고정\n대상별 Excel 생성]
  OUT --> PERSON[담당자 업로드]
  PERSON --> TARGET[ERP·WMS·채널 실행]
  TARGET --> RESULT[접수결과·등록번호·재조회 대사]
  RESULT --> WORK
  WORK -.검증·계약 확보 후.-> API[공식 쓰기 어댑터]
  API -.-> TARGET
```

## 2. 데이터 처리 단계와 변경 권한은 두 개의 축

Raw→표준→업무 마트는 **가공 단계**, Frozen/Slush/Liquid는 **변경·공유 계약**이다. Raw=Frozen, 마트=Liquid처럼 일대일로 대응시키지 않는다. 민감도·열람 권한도 독립된 축이다.

| 구분 | 책임과 대상 | 변경 절차 | CMSLAB 예 |
|---|---|---|---|
| Frozen | 부서 사이에서 신뢰하는 공통 키·교환 스키마·공식 지표/규칙·승인 버전 | 변경 요청→영향 분석→업무/기술 검토→승인→효력일 발행→소비 부서 반영 확인 | ITEM 코드맵, 승인된 세트 구성, 납품 스키마, 확정월 매출 버전, 유효기간 정책 |
| Slush | 팀 구성원이 같은 데이터를 보고 협업하는 작업표 | 팀 오너 승인·동시수정 검사·이력. 공통 인터페이스 영향은 Frozen 변경 요청 | 판매계획 초안, 프로모션 일정, 공급계획, 매핑 예외 큐, QC 작성 중 기록 |
| Liquid | 개인 조회·조합·가설 분석 | 개인 버전·사용 원천/규칙 명시. 팀 공유/공식화는 승격 검토 | BM 출시제품 비교, 영업 개인 대시보드, 분석 코드·개인 에이전트 초안 |

Frozen은 모든 거래 행을 영구 수정불가로 묶는 뜻이 아니다. 사건은 계속 적재하고 과거 정정은 정정 이벤트 또는 새 버전으로 남긴다. 월 확정 버전은 보존하며 재개방 승인 후 새 close_version을 발행한다. 업무 상태 Draft/Approved와 Frozen/Slush 구분도 별도 필드다.

Liquid에서도 처방·원가·주문 개인정보 권한은 상속한다. Slush 사용자가 공통 item_id를 임의 변경하거나 개인 ROAS 산식으로 공식 KPI를 덮어쓰지 못하게 한다.

## 3. 원천·수집방식·갱신 목표

아래는 사용자 메모 기반 **초기 목표**이며 실제 수집 완료시각과 휴일 운영은 오너 협의 후 확정한다. 원천 값이 월말에 갱신된다면 5분마다 조회해도 일간 확정매출이 되지 않는다.

| 원천 | 우선 수집/인계 경로 | 초기 목표 | 제약·확인 항목 |
|---|---|---|---|
| ERP-U | 승인된 읽기 DB 추출, 불가하면 담당자 다운로드 | 출고 사건은 가능한 짧게, 재고 일 마감 대사, 회계매출 확정 후 | 접속/스키마/부하/수정삭제 표식 미확인. 쓰기 DB Insert를 기본안으로 두지 않음 |
| 가온·품고·HGLIS | 상세 다운로드 업로드 → 허용 API/정기 반출로 대체 | 일1회 스냅샷 기준, 출고요청·QC 상태는 업무 필요별 단축 | API 조회 가능성과 ERP 반영은 별도. LOT·예약·상태 범위 확인 |
| 올리브영 | 상세 매출·매입·재고 파일, 납품확인서 | 일간 실적; 월·수 발주 확인; 과거 정정 재수집 | API 미확인. 전사상 정규 납품 수·금과 구분. 일자×매장×상품 표본 확인 |
| 면세 5사 | 채널별 수불/누적 파일 + 약정가격 마스터 | 월마감 가공 우선, 가능한 원천만 일간 누적 | 롯데·신라·신세계·현대·HDC 계정/지점별 파일, 누적치 정정·누락일 |
| 다이소·보안제약 채널 | 담당자 상세 파일 업로드 | 현행 제공 주기 유지 후 단축 | OTP 우회 전제 제외. 실제 셀인·직영재고와 추정 가맹 셀아웃 구분 |
| 네이버·버티컬 | 주문·정산·쿠폰·광고 내역을 분리 수령 | 전일 기준 누적; 정산은 원천 공개 후 | 브랜드별 계정, 옵션/구성·세전 금액·차감 부호·월누적 구간 |
| 컬리·비마트·화해 직매입 | 발주/출고/인수·정산 파일 | 사건 발생/제공 시 + 일간 취합 | 미제공 셀아웃을 0으로 채우지 않음. 조회기간 제한 실측 |
| 공급·입고·판매계획 시트 | 시트 읽기 또는 버전 지정 업로드 | 변경 수집 가능한 범위 + 일 스냅샷 | 수령 TRUE가 자동 추출 권한 확보를 의미하지 않음 |
| 재경 도서관·손익·데일리·예산 | 파일 버전/기간 단위 수령 | 일 가마감과 월 확정 분리 | 원가 8~9영업일 메모는 공식 SLA 미확정 |
| 연구소·RM·CS | 원료/처방·QC·VOC 업로드 및 승인 이벤트 | 변경·판정 시; 통계 일간 후보 | 처방 비공개, QC 고정 양식·검토자 유지, AI 분류는 초안 |
| Brity·인터넷디스크·Drive | 승인 문서 식별자/파일·접근제어 연계 | 업무 승인/문서 변경 시 | 결재 정본은 기존 시스템 유지 후보; 계정/API 미확인 |
| BigQuery·해외EC·광고·GA4·시장정보·채권 | 기존 원천/제공 파일부터 인벤토리 연결 | 접근·업무 우선순위 확인 후 | 전사 통합 확장 후보. 미확인 API·권한·수집주기 확정 금지 |

각 화면에 원천 기준시각, 마지막 수령/검증/공개시각, 누락기간, 실제/추정 여부를 노출한다. 전체 채널을 일1회로 스케줄링하는 것만으로 일간 커버리지 달성으로 집계하지 않는다.

## 4. 공통 데이터 모델

표의 grain은 물리 DDL 이전 논리 설계다. 필드별 정본을 지정하며 ERP에 존재하지 않는 처방·유효기간을 ERP 정본이라고 선언하지 않는다.

| 객체 | 1행의 의미 / 핵심 키 | 주요 필드·관계 | 정본/오너 후보 |
|---|---|---|---|
| PRODUCT / ITEM | 개념 출시제품 / 실제 운영 품목 | product_id, item_id, 브랜드·용량·상태·출시일·담당 BM | BM 출시제품, SCM 품목코드; 승인자 확인 |
| ITEM_CODE_MAP | 원천·계정·상품/옵션코드·유효기간별 매핑 | source_id, account_id, source_code, option_code, item_id, valid_from/to | SCM+영업 채널 담당 |
| OFFER_COMPONENT | 채널 판매구성 버전의 구성품 1개 | offer_version_id, item_id, component_qty, 본품/증정 구분 | 영업/BM 검토; 출고 품목과 연결 |
| ALLOCATION_RULE | 구성 금액 배분 규칙 버전 | rule_id, basis, effective_at, rounding, approver | 영업·경영관리 협의 |
| WAREHOUSE / LOT | 창고 / 품목별 생산 LOT | source_lot_code, item_id, manufacturer, manufacture_at, expiry_at | 물류 실물·RM 품질 근거 |
| INVENTORY_SNAPSHOT | 원천·시각·품목·창고·LOT·상태·소유주별 수량 | qty, unit, snapshot_at, source_batch_id | WMS 실물과 ERP 장부를 각각 보존 |
| INVENTORY_EVENT / RESERVATION | 입출고·이동·조정 사건 / 요청별 예약 | event_id, order_line_id, qty, 상태, 대상창고, 품질보류 | SCM; ERP/WMS 등록 결과 연결 |
| ORDER_LINE / SHIPMENT_LINE | 원천 주문라인 / 실제 출고라인 | 채널계정, source_order_id, line_id, order_at, shipped_at, delivered_at | 원천 주문/물류 사실 |
| SALES_OBSERVATION | 제공 grain별 셀인/셀아웃/누적값 | observed_period, channel, store, item, qty, amount, actual_or_estimated, grain | 영업 원천. 상세 거래 없는 집계자료 별도 |
| SETTLEMENT_LINE / ACCOUNTING_SALES | 정산 명세행 / ERP 회계매출행 | settled_at, recognized_at, 공급가, VAT, seller_coupon, platform_coupon, fee, close_version | 채널 정산, 재경 확정 분리 |
| RETURN_EVENT | 반품/교환/취소 사건 | 원주문/출고/반송번호, 발생·수령·처리일, qty, 이유 | 물류·CS·재경 단계별 역할 |
| PRICE_TERM / COST_VERSION | 채널 약정 가격 / 원가 버전 | item, channel, currency, effective_from/to, 잠정/확정, cost_component | 공급단가 영업/재경, 제조원가 구매/BM 제한 |
| PROMOTION / AD_SPEND | 행사 대상품목·기간 / 광고집행 건 | price_tier, coupon_split, campaign, budget_owner, spend, attributed_sales | 채널 영업·MC, 귀속기간/산식 버전 |
| SALES_PLAN / SUPPLY_PLAN / BUDGET | 팀·기간·품목/채널·버전별 계획 | planned_qty/amount, forecast_version, approved_at, revision_reason | 팀 Slush 초안→공유 승인 버전 |
| MATERIAL / FORMULA_VERSION | 원료 식별 / 처방 버전 | 제조사·INCI·조성 식별, product, effective_from/to | 연구소; ERP 사급원료 코드맵 |
| FORMULA_COMPONENT / MATERIAL_PRICE | 처방버전 원료 함량 / 가격버전 | material_id, ratio, basis_mass, unit / unit_price, currency, effective_at | 연구소 함량, 구매 단가. 가격 변경이 처방 변경을 만들지 않음 |
| QC_DECISION / DOCUMENT_VERSION | LOT별 판정 / 문서 발행 버전 | 판정자·상태·승인시각, 제품/LOT, 파일 hash, 양식 version | RM 검토·승인 |
| VOC_CASE | 클레임 사건 1건 | case_id, item/lot, channel, issue_type, review_status, 발생일 | CS/RM. 제품 마스터 속성에 누적하지 않음 |
| MASTER_CHANGE / ACK | 변경 요청 / 소비 채널별 반영 확인 | request_id, affected_fields, effective_at, approver, recipient, ack_at | 필드 오너·각 채널 담당 |
| INGEST_BATCH / EXPORT_BATCH | 수령/추출 1회 / 대상 전달 1회 | 파일 hash, 기간·필터, schema/transform/rule version, 승인자, 합계, 결과 | IT 운영·업로드 담당 |

```mermaid
erDiagram
  TAXONOMY_NODE ||--o{ PRODUCT_CLASSIFICATION : classifies
  PRODUCT ||--o{ PRODUCT_CLASSIFICATION : classified
  PRODUCT ||--o{ ITEM : groups
  ITEM ||--o{ ITEM_CODE_MAP : maps
  ITEM ||--o{ OFFER_COMPONENT : contains
  ITEM ||--o{ LOT : identifies
  LOT ||--o{ INVENTORY_SNAPSHOT : observed
  LOT ||--o{ QC_DECISION : judged
  ITEM ||--o{ ORDER_LINE : sold
  ORDER_LINE ||--o{ SHIPMENT_LINE : fulfilled
  ORDER_LINE ||--o{ SETTLEMENT_LINK : reconciled
  SETTLEMENT_LINE ||--o{ SETTLEMENT_LINK : reconciled
  SHIPMENT_LINE ||--o{ RETURN_EVENT : returned
  ITEM ||--o{ VOC_CASE : reported
  FORMULA_VERSION ||--o{ FORMULA_COMPONENT : consists
  MATERIAL ||--o{ FORMULA_COMPONENT : used
  MATERIAL ||--o{ MATERIAL_PRICE : priced
  MASTER_CHANGE ||--o{ ACK : acknowledged
```

정산과 주문은 부분정산·여러 주문 묶음 때문에 1:1을 가정하지 않는다. `SETTLEMENT_LINK`에 연결 금액/수량을 두고 조인 증폭을 검증한다. 주문 키가 없는 채널 집계는 ORDER_LINE을 가짜 생성하지 않고 동일 기간·채널·품목 수준의 대사만 한다.

## 5. 규칙을 코드·버전으로 관리할 항목

| 규칙 | 입력과 처리 | 검증/미결 |
|---|---|---|
| 코드 매핑 | 원천 계정+상품+옵션+효력시각으로 ITEM/구성버전 탐색 | 같은 범위에 유효기간 겹침 금지; 미매핑·다중매핑은 격리 |
| 세트/증정품 | 구성품 출고수량 환산과 매출금액 배분을 별도 수행 | 1만원 주문이 구성품 각각 1만원으로 증폭되지 않음. 배분 합계=주문액, 잔액처리 규칙 |
| LOT 가용 | 물리재고·보류·예약·이동중을 원천 정의에 맞게 계산 | WMS 가용수량이 이미 예약 차감된 값인지 확인, 중복 차감 금지. QC 미확정은 자동 가용 승격 금지 |
| 유효기간 | 납품일·채널·계약의 잔존기간 규칙 적용 | 18개월 정상 메모, 1년/예외 구간은 실제 정책 확인. 예외 승인 기록 |
| 매출 날짜 | 주문·출고·인도·정산·회계 인식 사건을 분리 | 배송 정보 미확보는 증빙 결측. 기준 부재로 치환 금지 |
| 쿠폰/VAT | 원본 금액, 세전/세후, 업체/플랫폼 부담과 부호를 보존 | 지그재그 차감 설명은 표본 승인 전. 모든 채널에 1.1 나누기 금지; CJ 공급가 중복 세전처리 방지 |
| 상계 | 광고비·수수료·입금액·매출을 각 필드로 보존 | CJ 상계의 중복 차감과 ROAS 광고비 누락 검사 |
| 누적차분 | 동일 월·필터·채널·품목의 누적 snapshot 차분 | 월초 reset·과거 정정·누락일·주말 분배를 구분. 음수차분을 자동 0 처리하지 않음 |
| 수불 대사 | 기초/기말·입고·반송·이동·조정 동일 기간 비교 | 롯데 메모 부호와 다이소 12/출고 식은 C-02/C-03 해결 전 사용 금지 |
| 원료/처방 | 함량·질량·단위를 분리하고 유효버전으로 계산 | 함량 합계 허용오차·단위환산·연구소 승인. 가격 이력 별도 |
| 변경 전파 | 제품 변경→영향받는 채널·문서·상세페이지 목록→담당 확인 | 변경 건+수신 대상별 중복 알림 방지, 미확인 기한 후 재알림, 완료증빙 |

규칙 레지스트리는 `rule_id, version, inputs, expression/code_ref, effective_from/to, owner, approver, evidence_id, sample_result, status`를 갖는다. 금액 산식 예시는 현재 회계 자문/정책 확정이 아니라 인터뷰에서 검증할 규칙 목록이다.

## 6. Excel 인계도 끝까지 관리하는 시스템 경로

1. **수령**: 담당자가 원본 파일을 올리면 채널·계정·조회기간·조회조건·자료종류·원천 기준시각을 함께 저장한다. 파일명만으로 기간을 추정하지 않는다.
2. **검증**: 필수 열·자료형·날짜·단위·코드·중복을 검사한다. 정상행과 오류행, 원본합계·가공합계·제외사유를 보여준다. 원본 파일은 덮어쓰지 않는다.
3. **검토**: 예외 담당자가 매핑/규칙 변경을 요청한다. 승인된 규칙 버전으로 같은 원본을 재처리하고 결과 차이를 확인한다.
4. **승인·고정**: 업로드 대상 기간/채널/행과 규칙 버전, 승인자, 합계, export_batch_id를 고정한다. 승인 후 변경은 새 버전이다.
5. **생성**: 실제 ERP/WMS/채널 양식 버전에 맞는 입력용 Excel과 검토용 대사표를 분리 생성한다. 대상 시스템이 허용하지 않는 관리용 열은 입력 파일에 넣지 않고 별도 manifest로 연결한다. 원본 코드의 앞자리 0과 숫자/날짜 형식을 보존한다.
6. **업로드**: 담당자·다운로드시각·업로드시각·대상 시스템·결과 파일/접수번호를 기록한다. `파일 생성`을 `ERP 반영 완료`로 표시하지 않는다.
7. **결과 대사**: 대상 시스템의 등록번호/재조회로 건수·수량·금액을 확인한다. 성공·부분성공·실패·결과미확인을 구분한다. 부분성공은 확인된 실패행만 새 재시도 묶음으로 보낸다.

```mermaid
stateDiagram-v2
  [*] --> Received
  Received --> Validating
  Validating --> Exception: 오류
  Exception --> Validating: 수정 후 재검증
  Validating --> Review: 통과
  Review --> Approved: 담당 승인
  Approved --> Exported: 양식 생성
  Exported --> UploadPending
  UploadPending --> ResultUnknown: 결과 확인 전
  ResultUnknown --> Reconciled: 대상 재조회 일치
  ResultUnknown --> PartialFailure: 일부 등록 실패
  PartialFailure --> Review: 실패행만 재처리
  Reconciled --> [*]
```

멱등성은 파일 hash만으로 충분하지 않다. 같은 데이터가 다른 이름·정렬로 재업로드되거나 동일 주문이 다음 파일에 포함될 수 있다. 원천 업무키+계정+행 버전으로 중복을 검출하고, 대상 시스템이 외부키를 받지 못하면 이전 등록번호/조회 결과와 대사한다. 결과미확인 상태에서 자동 재전송하지 않는다. 삭제·정정은 원천 행을 제거하는 대신 취소/정정 링크로 남긴다.

## 7. 시스템 구성·운영 책임

| 구성요소 | 책임 | 초기 구현 경계 |
|---|---|---|
| 업무 웹·업로드 화면 | 수령, 예외 검토, 변경 요청, 승인, 결과 확인 | 화면에서 직접 산식/원본 DB 변경하지 않고 서비스 경유 |
| 인증·권한 서비스 | 조직/역할/도메인/열·행·반출 통제 | 원가·처방·개인정보에 동일 규칙을 API·Excel·개인 분석까지 적용 |
| 원본/문서 저장소 | 원본 파일·양식·QC 문서·해시·버전 보존 | 고객 소유 저장 위치 선정 필요. 외부 공개 링크를 정본으로 사용하지 않음 |
| 운영 RDB | 마스터, 변경승인, 팀계획, 예약 요청, 실행/업로드 상태 | 트랜잭션·동시수정 version 검사, 유효기간/참조 무결성 |
| 배치 실행기·작업자 | DB/파일/API 수집, 검증·변환·마트 갱신·Excel 출력 | 초기 정기 배치+작업상태 테이블. 실패 큐·재시도 상한·중복방지 |
| 분석 저장·공식 뷰 | 사건 이력·스냅샷·업무 마트·공통 지표 | 운영 입력과 읽기 부하 분리. 용량 실측 후 별도 DW 여부 결정 |
| 대상 어댑터 | 파일 포맷/허용 API, 접수결과 매핑 | 시스템별 스키마 버전, ERP/WMS 직접쓰기 개발은 별도 게이트 |
| 알림 | 수령지연·미매핑·대사차이·변경 미확인 안내 | 상태는 DB가 정본, 메일/Slack은 통지. 실제 채널 생성·메시지 발송은 이번 작업 범위 아님 |
| 관측·감사 | batch/run, freshness, 오류, 승인·조회/반출 이력 | 책임자·복구 절차·보존기간·백업 복원 확인 |

개발/검증/운영 환경을 분리하고 규칙·스키마 변경은 표본 재처리 차이 검토 후 배포한다. 비밀값은 별도 자격증명 저장소에서 관리하며 이 문서/접근 원장에는 상태·책임자·권한 범위만 둔다. 장애 시 마지막 성공 자료를 기준시각과 함께 표시하고, 미적재를 0으로 노출하지 않는다. 복구목표·백업주기·운영 지원시간은 IT 협의 후 수치화한다.

## 8. 역할과 권한 — 승인 전 후보

| 업무 | 작성/실행 후보 | 검토·승인 후보 | 공유 결과 |
|---|---|---|---|
| 제품/코드·리뉴얼 | BM 요청, SCM 코드/연결 | SCM·BM 필드 오너 | 전사 공개 속성·변경 일정 |
| 채널 매핑·프로모션 | 채널 MD·MC | 팀 오너, 공통 영향 시 SCM/경영관리 | 유효기간 있는 구성·일정·공급조건 |
| 출고·대사 | 영업 요청, SCM/물류 검토·실행 | 현재 경영관리 승인 경로 확인 | 승인·전달·실출고 상태 |
| 제조원가 | 구매·BM, 재경 확정원가 | 원가 권한 오너 | 허용된 사용자만 원가/구성 조회 |
| 처방·원료 | 연구소·구매(가격) | 연구소 검토·승인 | BM/RM에 승인 전성분/서류, 원처방은 제한 |
| QC·VOC | RM·CS | 품질 판정자/검토자 | LOT 가용판정, 비식별 통계 |
| 매출·손익·예산 | 영업·경영관리 | 재경·경영관리 | 주문/정산/가마감/확정 기준 분리 |
| 수집·운영 | IT/플랫폼 운영 | IT 보안·시스템 오너 | 실행상태·계보·권한 감사 |

## 9. 단계와 완료 기준

| 순서 | 범위 | 완료 증거 |
|---|---|---|
| P0 근거·접근/키 | 현재 원장, 같은 기간 원본/결과/업로드 양식, ITEM·채널·창고 키 | 계정 수령과 테스트 상태 분리; 승인 산식/양식 목록; C-01~C-05 담당 배정 |
| P1 공통 기반+효과 파일럿 | 가온/ERP 재고 대사, 올영 또는 네이버 대표 가공 1개, 면세 월마감 1개를 표본/부담 기준으로 선정 | 원본→가공→업로드파일→등록결과 대사 재현. 미매핑 격리. 중복/부분실패 시나리오 통과 |
| P2 확장 | 나머지 WMS·채널, 프로모션·계획, 원료/QC·VOC·제품변경 전파 | 공통키/규칙 재사용, 수작업시간·대사차이·수령지연 개선 측정 |
| P3 선택적 직접연동 | 비용 대비 효과가 큰 구간의 조회/쓰기 API | 지원 인터페이스·견적·오너·감사·재처리 승인; 파일 대체 경로 유지 |
| 별도 범위 판단 | 전사 ERP 교체, AI 처방/품질 자동판정, 개인 에이전트 확대, 자동 수요예측 | Phase 1 확대 합의 없이 구현 약속하지 않음 |

수요예측 고도화보다 판매계획·실제 출고·프로모션/가격·품절 이력·채널 커버리지를 먼저 확보한다. 광고 ROAS·공헌이익은 귀속기간·반품·쿠폰·비용 포함범위가 검증된 후 공식화한다. 재고회전일은 SCM이 사용하는 산식과 표본 결과를 기준으로 확정한다.

## 10. 검증 시나리오와 남은 결정

- 같은 주문의 재업로드/파일명 변경/정렬 변경: 등록 중복 없음.
- 세트 본품 2개+증정: 구성 수량은 맞고 매출액이 증폭되지 않음.
- 정산 부분성공 후 재시도: 이미 등록된 행 재전송 없음.
- 출고 파일 생성 뒤 재고/QC 변경: 승인 데이터 유효성 재검토, 오래된 파일 사용 식별.
- 과거 월 정정·누적 reset·누락일: 원본/기존 확정월 보존, 차이와 새 버전 표시.
- 예약/패킹/이동중: 동일 물량의 가용재고 중복 차감 없음.
- 영업 사용자의 원가/처방 조회·다운로드·개인 분석: 허용 범위 초과 접근 없음.
- 제품코드/패키지 변경: 관련 채널 통지와 확인 상태 추적, 실물 SKU 혼합 없음.

위 항목은 **향후 구현 인수 시나리오**이며 이번 문서 작업에서 시스템을 구축·시험했다는 의미가 아니다. 남은 결정은 고객 소유 배포환경, 실제 업로드 양식, 필드별 RACI, 가격/쿠폰/유효기간 규칙, 권한, 수집 시각, 직접연동 범위·비용이다.

## 11. 사용자 추가 정렬 — 제품 중심, ERP와 독립된 논리 모델

**2026-09-09 사용자 지시 반영:** 전 부서 공통 제품마스터를 먼저 설계하고, 채널별 업무 테이블을 파생시킨다. 포장·옵션 변경에도 제품의 본질이 유지되면 같은 출시제품으로 추적한다. LOT·SCM 관계는 테이블 수준에서 분리한다. ERP DB 조회권한이 확보되면 필요한 원천 필드와 객체만 매핑하고 조정하며, ERP 테이블 구조에 공통 모델을 종속시키지 않는다.

`ERP 준연동`은 운영 코드·사건과 추적 가능한 매핑/대사를 유지한다는 뜻이다. ERP가 모든 필드의 정본이거나 새 기준정보의 유일한 등록 장소라는 뜻이 아니다. 필드별 업무 오너와 원천 정본은 DB 확인 및 협의로 정한다.

### 11.1 제품 식별을 네 단계로 분리

| 개념 | 목적·키 | 변경 예와 처리 |
|---|---|---|
| 출시제품 `PRODUCT` | 장기 실적을 추적할 제품의 연속성, 안정적 product_id | 같은 주요 제품의 패키지 리뉴얼은 유지 후보. 대분류 카테고리와 별개이며 경계는 BM·SCM 합의 |
| 실물 품목 `ITEM` | 재고·수불·주문을 구분할 최소 운영 단위 item_id | 용량/색상/제형/판매단위 등 분리 기준에 따라 새 item. ERP 코드가 바뀌어도 자동 신규 family 생성하지 않음 |
| 실물 사양 `ITEM_REVISION` | 동일 품목의 포장·라벨·사양 유효버전 revision_id | 동일 ERP 코드로 신구 패키지가 공존하면 revision으로 구분, 품목 분리 필요 시 새 item과 family 연결 |
| 채널 판매상품 `CHANNEL_OFFER` | 채널·스토어·상품·옵션별 판매 단위 offer_id/version | 본품 2개+사은품 구성, 옵션·행사 변경은 offer_version/BOM 변경. 실물 item과 별개 |

연속성 판단을 자유 텍스트 컬럼 하나로 끝내지 않는다. `PRODUCT_ITEM_MEMBERSHIP(product_id, item_id, valid_from, valid_to, reason, approved_by)`와 `PRODUCT_RELATION(from_item_id, to_item_id, relation_type, effective_at)`를 둔다. 관계 유형은 `replaces / repackages / size_variant / formulation_change` 등 후보이며 사용 기준을 승인한다. 보고 시 **당시 분류**와 **현재 분류로 재집계**를 선택할 수 있도록 mapping_version을 남긴다. 한 분류 체계·시점에서 item의 대표 family가 중복되지 않게 한다.

공통 집계에서는 수량 단위도 명시한다. 50ml와 100ml를 같은 family로 분석하더라도 개수·표준용량 환산·금액은 별도 지표다. 서로 다른 실물 품목을 합산해 출고 가능 수량으로 제시하지 않는다. 카테고리/브랜드/라인/출시제품은 별도 차원으로 두며, 팀별 태그가 공통 hierarchy를 덮어쓰지 않게 한다.

### 11.2 BOM은 용도별로 분리

| 테이블 | 포함 내용 | 피해야 할 혼합 |
|---|---|---|
| `FORMULA_VERSION / FORMULA_COMPONENT` | 연구소 처방 원료·함량·적용기간·검토 | 채널 사은품 구성이나 판매가격과 혼합 금지. 권한 제한 |
| `PACKAGING_BOM_VERSION / PACKAGING_COMPONENT` | 내용물·병·펌프·박스·라벨 등 포장 구성, 수량/단위, revision_id | 원가 값 자체를 BOM 구성 PK로 사용하지 않음 |
| `SALES_BOM_VERSION / OFFER_COMPONENT` | 채널 옵션·세트의 item/revision·구성수량·본품/증정·효력기간 | 재고 없는 가상세트와 창고에서 사전 포장된 실물 세트를 구분 |
| `MATERIAL_PRICE / COST_VERSION` | 제조사/공급처별 단가·통화·효력일, 잠정/확정 | 단가변경만으로 처방/포장 BOM 버전을 바꾸지 않음 |

사전 포장된 세트는 별도 실물 item과 조립/해체 사건·구성품 소비 이력이 필요하다. 주문 시 분해 출고하는 가상세트는 offer BOM으로 수량을 펼친다. 두 경로를 동시에 차감하지 않는다. 구성비 변경 시 새 버전, 오기 정정 시 수정이력·소급 영향 검토를 남기며 효력기간 겹침을 막는다.

### 11.3 LOT·재고와 제품 버전 연결

- LOT 식별은 문자열 하나의 전사 유일성을 가정하지 않는다. `lot_id`와 원천·제조사·item·source_lot_code를 연결한다.
- `LOT_REVISION_ASSIGNMENT(lot_id, revision_id, evidence_id, status)`로 실제 포장/성분 버전을 연결한다. 연결 근거가 없으면 `unknown`으로 두고 제조일만으로 추정 확정하지 않는다.
- 같은 생산 LOT가 서로 다른 포장으로 나뉘면 `PACKAGING_RUN` 또는 `STOCK_UNIT`으로 분할 식별하고 item/revision/lot 관계를 명시한다. 단순 1 LOT=1 포장버전 가정을 피한다.
- 재고 grain은 필요에 따라 `원천×기준시각×창고×item×LOT×revision/포장단위×상태×소유주`다. 해당 필드가 원천에 없으면 결측 범위를 표시하고 얻지 못한 상세를 만들어내지 않는다.
- QC 판정은 LOT/검사대상과 판정버전, 예약은 주문/요청라인과 재고 배정, 이동중은 출발/도착 사건으로 분리한다. 제품 마스터에 `현재 재고`를 수정 가능한 속성으로 저장하지 않는다.

```mermaid
flowchart TD
  C[분류군: 가변 깊이] --> F[출시제품: 장기 추적] --> FM[출시제품 소속·변경 이력]
  FM --> I[ITEM: 실물 품목]
  I --> R[ITEM_REVISION: 포장·라벨 사양]
  R --> PB[포장 BOM 버전]
  I --> FO[처방 BOM 버전·제한 권한]
  O[채널 판매상품·옵션 버전] --> SB[판매구성 BOM]
  SB --> I
  SB -.특정 포장 지정.-> R
  I --> L[LOT·생산 이력]
  L --> PR[LOT-사양 배정·포장 작업]
  R --> PR
  PR --> S[재고 스냅샷·수불 사건]
  L --> Q[QC 판정]
  S --> RES[주문별 예약·배정]
  I --> CM[ERP·WMS·채널 코드맵]
```

### 11.4 채널별 파생 테이블

공통마스터 전체를 채널마다 복사해 수정하게 하지 않는다. 기본 뷰에 `CHANNEL_ITEM_EXTENSION(channel_id, account_id, item_id, offer_id, local_display_name, category_tag, owner, status)`를 연결한다. 채널 판매가·수수료·쿠폰정책은 효력일 있는 별도 테이블, 판매계획·행사는 Slush 업무 테이블이다. 팀별 컬럼 추가는 공통키/계약을 건드리지 않는 범위에서 허용하며 재사용 빈도가 높아진 속성은 공통 필드 승격을 검토한다.

전사 제품 변경은 해당 item/revision을 참조하는 채널 목록을 계산해 알린다. 영향 없음/상세페이지 수정/상품코드 변경/재고 분리 필요 등 조치 결과와 승인·완료를 기록한다. 원가·처방 민감필드는 채널 뷰에 복사하지 않는다.

### 11.5 ERP 조회권한 확보 후의 조정 절차

1. 실제 ERP 품목·BOM·창고·LOT·수주·출고·회계 테이블의 키/수정일/상태/코드 재사용을 표본으로 프로파일링한다.
2. 필드별 `ERP에서 가져옴 / 플랫폼 관리 / 계산 / 미확보`를 source-to-target 표에 표시한다.
3. ERP가 item_id 대신 운영 코드를 사용해도 코드맵으로 연결한다. ERP에 family/revision/처방이 없으면 플랫폼에서 관리한다.
4. 원천 구조가 예상과 다르면 어댑터·매핑을 우선 조정한다. 도메인 모델 변경이 필요한 경우 영향받는 채널 뷰·과거 집계·양식을 검토한 뒤 버전 변경한다.
5. ERP 입력에 필요한 최소 필드만 지원되는 업로드/API 경로로 전달한다. 플랫폼 모든 속성을 ERP로 밀어넣지 않는다.

### 11.6 합성 사례로 확인할 경계

`F-DEMO-01` 출시제품 아래 50ml 실물품목 `I-DEMO-01`의 구포장 R1과 신포장 R2가 공존하고, 100ml는 별도 `I-DEMO-02`로 둔다. 네이버 판매옵션 O1은 I-DEMO-01 2개+증정 I-DEMO-03 1개다. 패키지 변경에도 F-DEMO-01의 판매추이는 이어서 보되 실제 출고는 ITEM/LOT/사양 조건으로 고른다. 주문금액은 한 번만 반영하고 구성별 배분 합계를 대사한다. 이 식별자와 수량은 고객 실데이터가 아닌 **설계 설명용 합성 예시**다.


## 2026-09-11 커스텀 UI·팀 데이터자산 관리 확장

[기능·운영 설계](../구현준비/채널·팀검수/05_커스텀UI빌더_기획.md)와 [검수 화면](../../00_프로젝트작업실/24_채널·팀검수/custom-builder.html)을 기준으로 구체화한다. 사용자 자연어·파일과 승인된 ERP/DB 데이터셋을 조합하여 개인 표·차트·다운로드를 구성하고, 처리 정의는 SQL 뷰 또는 Pandas 레시피로 버전 관리한다. ERP는 읽기 원천이며 생성 뷰·테이블·결과는 플랫폼 저장소에 둔다.

Frozen/Slush/Liquid는 기존 변경·공유 계약을 유지한다. 개인 Liquid 정의를 팀 Slush로 공유하거나 공통 Frozen 계약으로 승격할 때 소유자, 원천 권한, 결합 키·입도, 검증 결과, 갱신 책임과 영향받는 화면을 확인한다. 팀별 관리 대상은 물리 테이블·뷰·레시피·결과 스냅샷이며 카탈로그와 원천 의존 관계로 연결한다. 계층을 변경해도 민감도와 행·열·내보내기 권한은 완화되지 않는다.

초기 경영진 대시보드 구축을 선행하며 빌더는 승인 데이터셋·정형 조합부터 단계 도입한다. 현재 검수 화면의 로컬 초안 저장은 서버 테이블 생성·LLM 실행·팀 공유 승인 구현을 의미하지 않는다.