# CMSLAB 데이터 아키텍처 — 시각화와 Mermaid 원문

> 2026-09-09 · Proposed · AWS RDB 우선. RDS PostgreSQL·S3·인증·배포 제품은 확정 전.

[브라우저에서 그림 열기](17_CURRENT_데이터아키텍처.html) — 인터넷/CDN 없이 SVG 표시, 상자별 설명·탭·확대·전체 인쇄 지원.

## 기존에 있던 자료

사용자가 기억한 기존 그림은 아래 두 문서일 가능성이 있다. 제품·BOM·LOT와 파일 흐름은 이미 그려져 있었고, 이번 통합 보기에 최신 AWS 방향을 추가했다. 기존 파일은 보존한다.

- [쿠팡 추가 수기·현재재고와 과거조회 범위](../03_실행관리/회의록/2026-09-09_인터뷰통합정리·수기메모/20_수기메모_정리본.md)
- [채널별 API·자동화·파일 근거](../04_분석설계/discovery/_materials/files/channel-api-evidence-20260909.md)
- [재고는 어디서 조회하나 · 원천·거점·기준시각](../04_분석설계/아키텍처/CMSLAB_원천별_갱신주기_근거표_CURRENT.md)
- [ERP DB 실측·샘플](19_ERP_DB_스키마·샘플_안내.md)
- [통합 데이터원천·접근정보 대장](14_CURRENT_데이터원천·접근정보.xlsx)
- [9/9 사용자 수령표 원문](../03_실행관리/회의록/2026-09-09_인터뷰통합정리·수기메모/03_데이터원천·수령현황_사용자제공.csv)
- [데이터·시스템 상세 설계](../04_분석설계/아키텍처/CMSLAB_데이터·시스템아키텍처_인터뷰반영_2026-09-09_v0.2.md)
- [기존 공통 마스터 허브](../04_분석설계/아키텍처/CMSLAB_데이터아키텍처_마스터허브_검토.html)
- [최신 제품계층·판매추이·SCM 판단](../04_분석설계/아키텍처/CMSLAB_제품계층·판매추이·SCM이관_판단근거_2026-09-09.md)
- [AWS 전환 상세](../04_분석설계/구현준비/ERP-Core/04_AWS-RDB_전환설계.md)
- [채널키·업로드 책임](../04_분석설계/아키텍처/CMSLAB_채널키연결·업로드책임_설계_2026-09-09.md)
- [현재 제품마스터](08_CURRENT_제품마스터_고객협의본.xlsx)

## 설계 해석

분류군 → 출시제품 → 실물 ITEM이 최소 골격이다. 포장 revision·판매구성 BOM·LOT/QC·재고는 별도 관계다. 그림은 논리 도메인과 연결을 나타내며 최종 물리 테이블·카디널리티·AWS 배포 자원 확정도가 아니다. 운영 원장과 분석 뷰를 구분하되 초기부터 별도 DW는 필수가 아니다.

Frozen/Slush/Liquid는 변경·공유 계약이다. Raw/표준/마트 처리 단계, 조회 권한, 승인 상태는 각각 별도 축이다. 원가·처방 권한은 개인 분석에도 상속된다.

MD는 주문기준 판매추이를 별도 조회한다. 실측 셀아웃 없는 채널은 추정·미수령을 표시하며 셀인/출고 추이를 고객 주문으로 바꾸어 부르지 않는다. SCM 출고 책임 이관은 예정 상태다.

## 최신 실행 경계

기존 부서 가공·제출 파일부터 등록·검증·축적해 경영진 대시보드를 만든다. 기존 API/자동화는 재사용하고 수집 공백은 파일로 보완하며 신규 RAW/API 자동화는 후속으로 둔다. 판매계획(목표·양식), 구매일 기준 판매추이(실적·주문내역), 실제 마감완료 정산내역(배송·취소·반품·쿠폰 반영)은 별도 축이다. 채널 기준일·확정상태를 보존하며 잠정 가마감을 완료정산으로 취급하거나 정산으로 주문실적을 덮어쓰지 않는다.

통합재고 조회는 원천 기준시각과 ERP-WMS 상태 매핑 확인이 필요하다. 락·예약·할당·가상창고·부서재고 분리/이동은 ERP 기존 기능·설정·권한을 확인하여 실행한다. ERP 사용방법 안내·운영설계는 가능하지만 ERP 자체 수정·확장은 범위 밖이다. 기능이 없으면 조회·경고·업무절차만으로 실출고 잠금을 보장할 수 없다. AWS 내부 업무원장 쓰기권한과 ERP 쓰기권한은 별개다.

ERP DB SELECT·스키마 조회 성공은 확인했지만 WMS/API 연동이나 ERP 쓰기 검증을 뜻하지 않는다. 아래 원천표는 당시 37행 수령표를 보존한다.

## 원천 수령표 해석

2026-09-09 사용자 수령표 기준입니다. FALSE는 해당 요청 항목의 수령 미완료이며, 관련 샘플 파일이 전혀 없다는 뜻은 아닙니다. TRUE도 계정 접속·자동 연동 검증 완료를 뜻하지 않습니다. 아래 화살표는 목표 수집 경로입니다.

그림에 없는 세부 도구·채널도 HTML의 전체 목록 또는 통합 접근정보 대장에서 확인한다. 사용자 수령표 37행은 별도 기준시점이며 포털 계정·고객 파일 표본·자동 연동 상태를 합쳐 하나의 완료 표시로 만들지 않는다.

| 종류 | 원천 | 9/9 사용자 표 | 계획 경로 |
|---|---|---|---|
| ERP | 더존 ERP-U, DB권한 | False | 읽기 DB 권한·스키마 확인 → 조회 추출 / 대안: 다운로드 파일 |
| WMS | 가온 | False | 담당자 상세 파일 → 허용 API·정기 반출 검토 |
| WMS | 품고나우 | False | 담당자 상세 파일 → 허용 API·정기 반출 검토 |
| WMS | HGLIS | False | 담당자 상세 파일 → 허용 API·정기 반출 검토 |
| 물류·재고 | 국군복지단 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 공급계획 | SCM 공급계획 마스터 | True | 수령 시트·파일 버전 → 읽기 연계 권한 확인 |
| 입고계획 | 구매 입고정보·영업 공유 시트 | True | 수령 시트·파일 버전 → 읽기 연계 권한 확인 |
| 재고 대사 | ERP-WMS 일일 대조 시트 | True | 수령 시트·파일 버전 → 읽기 연계 권한 확인 |
| 제품마스터 | SCM 기준 품목 분류 | True | 수령 시트·파일 버전 → 읽기 연계 권한 확인 |
| 판매계획·매출취합 | 채널별 판매계획 및 매출취합 | True | 수령 시트·파일 버전 → 읽기 연계 권한 확인 |
| 회계매출 | 도서관파일 | True | 수령 파일·문서 → 구조 검증 / 민감정보 권한 분리 |
| 데이터웨어하우스 | BigQuery | False | 기존 BigQuery 읽기 권한 확인; 전사 DW 채택과 별개 |
| 그룹웨어 | Brity | False | 승인 문서 참조·허용 파일 / 계정·API 확인 |
| 문서 저장소 | 인터넷디스크 | False | 승인 문서 참조·허용 파일 / 계정·API 확인 |
| 문서 저장소 | Google Drive | True | 제공 파일·폴더 범위 확인 → 읽기 / 수령 파일 |
| 판매채널 | 올리브영 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 판매채널 | 쿠팡 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 자사몰 | 카페24 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 자사몰 | 메이크샵 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 주문 통합 | 사방넷 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 채널 분석 | 라플라스 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 고객상담 | 채널톡 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 광고 | Meta Ads | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 광고 | Google Ads | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 웹분석 | GA4 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 판매채널 | Amazon | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 판매채널 | TikTok Shop | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 판매채널 | Qoo10 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 판매채널 | Rakuten | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 제품개발 | 신제품 코드 요청·제품정보 | True | 수령 파일·문서 → 구조 검증 / 민감정보 권한 분리 |
| 원료·처방 | 원료·전성분·BOM | True | 수령 파일·문서 → 구조 검증 / 민감정보 권한 분리 |
| LOT·품질 | 출하적부·성적서·COA | True | 수령 파일·문서 → 구조 검증 / 민감정보 권한 분리 |
| VOC | VOC 수기시트·리포트 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 채권 | 거래처별 매출·채권·Aging | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 시장정보 | 트렌디어 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 시장정보 | Kantar | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |
| 시장정보 | Helium 10 | False | 담당자 제공 상세 파일 우선 / API·접근 가능 여부 별도 확인 |

## 기존 API·자동화 재사용과 수집 공백

API 존재·고객 운영 설명·실제 접근 검증은 별개다. 기존 자동화와 제출 파일을 함께 사용하며 신규 자동화를 시작의 선행조건으로 두지 않는다.

| 채널·범위 | 현업 수집·운영 설명 | 수집 범위 / 공백 | 기존 재사용 / 파일 보완 | 접근 검증 |
|---|---|---|---|---|
| 글로벌 Amazon | 글로벌팀은 Make로 매출 데이터를 연동 중이라고 설명 | 미국/기타 국가 판매 지표. 주문·재고·광고 전체 수집 완료라는 뜻은 아님 / 광고 미연계 설명. 국가·계정·scope·성공 로그·FBA 상세 입고예정 범위 미검증 | 기존 Make 시나리오와 후단 시트를 먼저 받아 재사용 / 현재 보고용 시트를 먼저 적재 가능; API 재개발을 선행조건으로 두지 않음 | 이번 조사에서는 고객 계정/API 직접 호출 없음. 인터뷰 설명·수령 표본·공식 제품 문서를 구분한다. |
| 일본 Amazon | 일본 담당은 API를 아직 시도하지 않았다고 설명. 글로벌 Make 운영과 구별 | 수령 자료는 BusinessReport 스냅샷과 데일리 시작품 관련 시트; FBA 시뮬레이션 설명 / 일본 계정 API 권한/운영 로그·정산/재고 endpoint 미확인 | 글로벌의 기존 수집 방식을 일본 계정에 재사용할 수 있는지 먼저 확인 / 기존 일별 판매/FBA 보충 시뮬레이션 파일로 우선 적재 | 이번 조사에서는 고객 계정/API 직접 호출 없음. 인터뷰 설명·수령 표본·공식 제품 문서를 구분한다. |
| 일본 Qoo10 | 연결이 한 곳으로 제한되고 현재 물류와 연결됐다는 설명 | 현재 결제일 주문 반출·장바구니 중복 제거·복합 코드 분해·판매 수량 가공. API 실제 응답은 미수령 / 한 곳 제한은 고객 설명이며 현재 계약/정책 검증 아님. 글로비스의 총액/품목/주문키 재사용 가능성 미확정 | 현재 물류 연결을 유지하고 조회권한 추가 또는 기존 물류/수집 후단 재사용 검토 / 일간 가공 판매추이와 월 ERP 수주등록 직전 파일을 우선 수집 | 이번 조사에서는 고객 계정/API 직접 호출 없음. 인터뷰 설명·수령 표본·공식 제품 문서를 구분한다. |
| TikTok Shop 기본 주문·광고 | Make의 GMV Max 미지원 설명 뒤 별도 전달 시트에서 해결했다는 설명 | 샵 주문/ERP 구성품목, 일반 광고·GMV Max·가격 스냅샷 표본 / 모든 API/전체 이력/모든 컬럼 허용을 뜻하지 않음. 상품 분석 화면 6개월 제한은 해당 화면 설명 | 현재 TikTok 수집 코드·BigQuery VIEW·시트와 광고 경로를 먼저 재사용 / 기존 피벗·추출 결과를 1차 적재; 상세 원천 범위를 후속 확장 | 이번 조사에서는 고객 계정/API 직접 호출 없음. 인터뷰 설명·수령 표본·공식 제품 문서를 구분한다. |
| TikTok Shop Affiliate·크리에이터 귀속 | 샵 주문과 별도의 Affiliate 주문을 수동 반출해 Order ID로 결합 | 크리에이터 주문/매출·환불과 기본 주문의 매칭 후보 / Affiliate 직접 API의 현재 권한·최신 정책은 미확인. 일반 노출 시딩은 직접 주문 귀속 데이터가 아님 | 기존 수동 가공 결과와 주문 매칭 규칙을 재사용하고 API 범위 재확인 / Affiliate Center 등 실제 반출 파일과 Order ID를 연결; 화면명/기간/반품 상태 확인 | 이번 조사에서는 고객 계정/API 직접 호출 없음. 인터뷰 설명·수령 표본·공식 제품 문서를 구분한다. |
| 네이버 커머스API | 9/8 현업은 네이버와 외부 물류 연동 및 API 발급 미실행 정황을 설명. 대화가 품고/네이버를 오가므로 어느 키인지 확정하지 않음 | 품고 주문·배송 파일은 수령. 네이버 커머스API 직접 응답·고객 앱 권한은 미확인 / 네이버 커머스API 조회, 품고 재고/API, ERP 쓰기는 서로 다른 경로 | 기존 네이버↔물류 연동과 앱 등록 상태부터 확인 / 현재 영업 가공파일/품고 주문 결과로 시작; API 가능 범위는 병행 확인 | 이번 조사에서는 고객 계정/API 직접 호출 없음. 인터뷰 설명·수령 표본·공식 제품 문서를 구분한다. |
| 품고 API | 네이버와 품고 연동 설명. 플랫폼 직접 API 조회 성공은 확인 안 됨 | 품고 주문/재고/입고/SKU 실제 파일·메뉴 근거 존재 / 비용 발언은 추정. 네이버 키와 품고 키의 발급주체·조회 범위 구분 필요 | 품고 기존 연동·반출을 확인하고 재사용 / 대시보드에서 ERP용 파일 생성 후 사람이 올리는 차선 논의. ERP 반영 결과 확인 필요 | 이번 조사에서는 고객 계정/API 직접 호출 없음. 인터뷰 설명·수령 표본·공식 제품 문서를 구분한다. |
| Shopify | Amazon과 함께 기존 Make 수집 | 해외 자사몰 판매 후단 시트 / 고객 앱 scope·상세 컬럼·실행로그 미검증 | 기존 Make 시나리오/시트 재사용 / 기존 제출파일 또는 후단 데이터 우선 | 이번 조사에서는 고객 계정/API 직접 호출 없음. 인터뷰 설명·수령 표본·공식 제품 문서를 구분한다. |
| YesStyle | Tableau에서 파일 두 개 다운로드→시트→Slack 후단 자동화 설명 | 수령 파일은 기간 미표기 상품 판매 순위/수량 표본 / 현재 고객 접근권한·일괄 반출/자동조회 허용 범위 미확인 | 이미 있는 시트 적재/Slack 가공을 재사용 / BIS/Tableau 반출파일의 기간·상품키를 보강 | 이번 조사에서는 고객 계정/API 직접 호출 없음. 인터뷰 설명·수령 표본·공식 제품 문서를 구분한다. |
| SNS·Apify 기반 콘텐츠 지표 | 조회수·좋아요·댓글·공유 등 수기/Apify→시트 | 콘텐츠 지표; 댓글 원문 수집은 희망 범위 설명 / 모든 SNS 통합 수집·장기 안정성·직접 매출 귀속 보장 없음 | 기존 콘텐츠 목록·수집 도구/후단 시트 확인 / 운영 중인 가공 리포트 우선 | 이번 조사에서는 고객 계정/API 직접 호출 없음. 인터뷰 설명·수령 표본·공식 제품 문서를 구분한다. |

## 데이터 원천 지도

더존 ERP-U·세 WMS와 채널·시트·문서를 구분해 수집 경로를 봅니다. 계정/자료 수령 상태는 9/9 사용자 표 기준이며 실제 접속 성공과 별개입니다.

```mermaid
flowchart LR
  erp_u["더존 ERP-U<br/>품목·출고·수불·회계·채권<br/>9/9 DB SELECT·스키마 조회 성공<br/>기존 수령표 / WMS·API와 구분"]
  gaon["가온 WMS · 한익<br/>이천 메인 · 정상/불량 재고<br/>계정 수령 여부 재확인 필요<br/>상세 파일 → 허용 연계 검토"]
  poomgo["품고나우 WMS<br/>네이버 · 재고·주문·출고<br/>계정 전달 예정 / 수령 미완료<br/>상세 파일 → API 조건 확인"]
  hglis["HGLIS · 현대글로비스<br/>Qoo10 · Rakuten 물류<br/>계정 미수령<br/>상세 파일 → 정기 반출 검토"]
  domestic["국내 영업 채널<br/>올리브영·쿠팡·네이버 등<br/>채널 API와 WMS·ERP는 별도<br/>기존 자동화 + 제출 파일 보완"]
  global["해외 EC · 마케팅<br/>Amazon·Shopify: Make 활용 발언<br/>TikTok: 주문/광고와 귀속 분리<br/>일본 계정·채널별 범위는 별도"]
  sheets["Google Sheets · Excel<br/>SCM 공급·입고·재고 대사<br/>품목 분류·판매계획·매출취합<br/>재경 도서관파일 등 수령 표시"]
  docs["문서 · 품질 · 업무도구<br/>신제품·원료/BOM·COA·VOC<br/>Drive·Brity·인터넷디스크<br/>사방넷·자사몰·군납 등 별도"]
  ingest["기존 자동화 + 제출본 검증<br/>기존 수집 결과와 가공본 축적<br/>원천·기간·버전·확정상태 보존<br/>수집 공백은 파일 / 신규연계 후속"]
  canonical["공통 마스터 · 표준 사건<br/>제품키·매핑 / 판매 3축 분리<br/>재고는 원천 시각·상태 참조<br/>AWS 내부원장 → 경영진 조회"]
  erp_u -->|"DB / 파일"| ingest
  gaon -->|"파일 우선"| ingest
  poomgo -->|"파일 우선"| ingest
  hglis -->|"파일 우선"| ingest
  domestic -->|"파일 / 조회"| ingest
  global -->|"파일 / 조회"| ingest
  sheets -->|"파일 / 조회"| ingest
  docs -->|"파일 / 조회"| ingest
  ingest -->|"검증·공통 키 연결"| canonical
  classDef core fill:#FCEEEF,stroke:#AF272F,color:#25282B
  classDef candidate fill:#F6F7F8,stroke:#596168,stroke-dasharray:5 4,color:#25282B
  class ingest,canonical core
```

| 영역 | 설명 |
|---|---|
| 더존 ERP-U | 원래 9/9 사용자 수령표의 FALSE는 그대로 보존합니다. 이후 같은 날 SQL Server NEOE 메타데이터와 SELECT 읽기가 성공했습니다(3,359테이블). API 연동·ERP 쓰기·WMS 접근·계정의 모든 쓰기권한 부재 검증을 뜻하지 않습니다. |
| 가온 WMS · 한익 | 가온 WMS는 이천 메인 물류 재고 원천입니다. 사용자 표는 FALSE이며 아이디를 받은 것 같은지 확인 필요라고 기록했습니다. 접속·추출 권한과 기존 파일 표본은 구분합니다. LOT·유효기간·창고·상태·화주/품목코드를 확인합니다. |
| 품고나우 WMS | 9/9 표에는 계정을 넘겨주기로 했으나 수령 FALSE입니다. 조회 API 비용·범위와 ERP 등록은 별도 과제입니다. SKU·고객사 관리코드·옵션·주문행 참조를 제품키와 구별합니다. |
| HGLIS · 현대글로비스 | HGLIS는 큐텐·라쿠텐 관련 물류 원천입니다. 사용자 표는 계정 미수령입니다. 문서번호+행번호와 화주/품목코드를 보존하고, LOT을 제공하지 않는 재고 표본을 LOT 재고로 간주하지 않습니다. |
| 국내 영업 채널 | 기존 자동화와 제출 파일을 함께 사용합니다. 네이버 채널API·품고WMS 조회·ERP 쓰기는 별도 경로입니다. 추가 수기메모 N109/N110의 쿠팡 사례는 주2회 발주→ERP 창고/SKU 재고조회→한물류 가능수량 수기확인→3PL메일→적재리스트PPT→쿠팡어드민입니다. ERP 반영시점·승인경로는 추가 확인이며 주2회는 소요시간이 아닙니다. N114에는 셀아웃 1년 조회제한 설명, 셀인 입고상세와 현재재고 다운로드가 있습니다. 다운로드 보존으로 이후 이력을 쌓되 현재재고 파일로 과거시점 재고를 복원했다고 보지 않습니다. 고객 API·메뉴의 실제 접근 테스트는 미수행입니다. |
| 해외 EC · 마케팅 | 9/9 글로벌 EC 전사에는 Amazon·Shopify Make 수집과 TikTok 일부 수집이 설명됩니다. 일본 Amazon 수기 업무와 같은 계정·운영범위로 단정하지 않습니다. TikTok 기본 주문·광고와 어필리에이트 주문/귀속은 별도 접근이며 파일 매칭 공백을 보완합니다. API 고객 권한·필드·실행 테스트를 이번에 수행한 것은 아닙니다. |
| Google Sheets · Excel | 9/9 표의 공급계획·입고정보·재고 대조·SCM 품목분류·판매계획/매출취합·도서관파일은 TRUE입니다. 원본 버전·시트·기준시각을 보존합니다. 파일 수령은 API/계정 연계 성공을 뜻하지 않습니다. |
| 문서 · 품질 · 업무도구 | 신제품 정보·원료/처방·품질 문서와 Google Drive는 수령 TRUE 표시입니다. VOC·Brity·인터넷디스크·사방넷·카페24·메이크샵·국군복지단 등은 요청 항목 미완료입니다. 전체 37행 목록에서 구분합니다. 원가·처방·개인정보는 수집과 조회 모두 권한을 분리합니다. |
| 기존 자동화 + 제출본 검증 | 각 원천의 인터페이스를 공통 배치 계약으로 수용합니다. 원본 해시·source/account·추출조건·기준시각·수령시각·행 참조를 보존하고 중복·형식·단위·코드 매핑을 검증합니다. 그림의 모든 원천이 자동 연결되어 있다는 뜻은 아닙니다. |
| 공통 마스터 · 표준 사건 | ERP 장부/부서 S_L, WMS 물리 LOT/QC/가용/예약, 채널센터/FBA 현지재고를 분리합니다. 같은 실물재고의 여러 시스템 관측을 중복합산하지 않습니다. 소유자·거점·원천·품목/상태 코드·기준시각을 보존하고 출고완료·예약·packing·이동중을 구분합니다. ERP 미반영 시차를 곧바로 오류로 판정하지 않으며 출처 화면·지연·업로드 완료상태를 표시합니다. |

## 전체 데이터 흐름

먼저 부서별 가공·제출 파일을 등록·검증·축적해 경영진 조회를 만듭니다. 기존 자동화는 재사용하고, 미수집 RAW/API의 신규 자동화와 실행 연계는 후속 단계입니다.

```mermaid
flowchart LR
  source["부서 가공·제출 파일 우선<br/>판매계획·주문실적·마감정산<br/>기존 자동화 재사용 / 파일 보완"]
  raw["제출본 · 수령 배치<br/>파일 종류·기간·버전·확정상태<br/>원본·가공 출처·행 참조 보존"]
  validate["검증 · 표준화<br/>형식·중복·코드·단위·기간<br/>미매핑은 예외 작업함"]
  events["분리된 실적 · 업무 사건<br/>판매 3축 / 출고·재고 별도<br/>원천 기준일·확정상태 유지"]
  receipt["접수 · 반영 · 대사<br/>등록번호·행 결과·재조회<br/>응답 불명은 확인 대상으로"]
  exception["예외 작업함<br/>미매핑·중복·수량 불일치<br/>담당자 수정 → 재검증"]
  master["공통 마스터 · 규칙<br/>제품·채널키·창고·단위<br/>BOM·효력기간·승인 버전"]
  target["ERP · WMS 기존 기능<br/>예약·할당·이동은 기능 확인<br/>플랫폼 표시는 실잠금 아님"]
  output["후속: 승인본 · 대상 파일<br/>ERP 기존 양식·권한 확인<br/>업로드 담당·처리 결과 추적"]
  work["팀 검토 · 업무 절차<br/>매핑·계획·요청·승인 이력<br/>실행 연계는 범위 확인 후"]
  mart["경영진 · 부서 대시보드<br/>판매 3축을 구분해 조회<br/>재고는 시각·상태 대조 후"]
  salesplan["① 판매계획<br/>목표 · 계획 양식<br/>기간·팀·채널·제품·계획 버전"]
  salestrend["② 구매일 기준 판매추이<br/>실적 · 고객 주문내역<br/>구매일·주문행·취소/반품 이력"]
  settled["③ 마감완료 정산내역<br/>배송·취소·반품·쿠폰 반영<br/>채널 기준일·마감 확정상태"]
  source -->|"수령"| raw
  raw -->|"파싱"| validate
  validate -->|"검증 통과"| events
  validate -->|"오류"| exception
  exception -->|"재검증"| validate
  master -->|"기준 참조"| validate
  events -->|"목적별 집계"| mart
  events -->|"업무 사건"| work
  master -->|"공통 키·규칙"| work
  master -->|"분류·매핑"| mart
  work -->|"승인"| output
  output -->|"업로드"| target
  target -->|"결과 확인"| receipt
  receipt -->|"차이·실패"| exception
  salesplan -->|"독립 축 조회"| mart
  salestrend -->|"독립 축 조회"| mart
  settled -->|"독립 축 조회"| mart
  classDef core fill:#FCEEEF,stroke:#AF272F,color:#25282B
  classDef candidate fill:#F6F7F8,stroke:#596168,stroke-dasharray:5 4,color:#25282B
  class master,mart core
  class target,output candidate
```

| 영역 | 설명 |
|---|---|
| 부서 가공·제출 파일 우선 | 기존 부서가 가공해 제출하는 파일을 먼저 등록·검증·축적합니다. 미수령 자료와 미확정 파일은 상태로 표시합니다. 기존 API/자동화의 결과도 재사용합니다. 미수집 원천의 신규 자동화가 대시보드 착수의 선행조건은 아닙니다. |
| 제출본 · 수령 배치 | 원본 파일, source/account, batch_id, 파일 해시, 원본 행 참조를 보존합니다. 같은 파일 재수령과 정정 배치를 구분합니다. |
| 검증 · 표준화 | 상품·옵션·단위·효력기간을 공통 키에 연결합니다. 중복·누락·미매핑을 검증하고 임의 보정하지 않습니다. |
| 분리된 실적 · 업무 사건 | 판매계획, 구매일 기준 판매추이, 실제 마감완료 정산내역을 별도 원장 또는 논리 뷰로 유지합니다. 잠정 가마감과 마감완료 정산을 구분하며 완료 정산으로 주문실적을 덮어쓰지 않습니다. |
| 접수 · 반영 · 대사 | 파일 생성과 외부 반영은 다른 상태입니다. 접수번호·성공/실패 행·재조회 증거로 반영을 확인하고 부분 실패만 재처리합니다. |
| 예외 작업함 | 원본을 보존하며 보정 이력과 담당자를 남깁니다. 응답 불명 상태는 중복 출고 위험 때문에 자동 재전송하지 않습니다. |
| 공통 마스터 · 규칙 | 전사 공통 키와 교환 규칙을 관리합니다. 분류군→출시제품→ITEM을 중심으로 채널 구성·포장·LOT은 별도 관계로 둡니다. 원가·처방은 권한을 분리합니다. |
| ERP · WMS 기존 기능 | 재고락·예약·할당·가상창고·부서재고 분리/이동은 ERP 기존 기능에서 실행해야 할 수 있습니다. 기존 기능·설정·권한 확인 전 확정하지 않습니다. 이번 프로젝트는 ERP 사용방법 안내·운영설계는 가능하지만 ERP 자체 수정·확장은 범위 밖입니다. 불가능하면 조회·경고·업무절차로 남으며 실출고 통제를 보장하지 않습니다. |
| 후속: 승인본 · 대상 파일 | 승인된 데이터 버전으로 대상 시스템의 업로드 형식을 만듭니다. 실제 업로드 담당·대체 담당·접수 결과를 추적합니다. |
| 팀 검토 · 업무 절차 | 채널별 팀 테이블은 공통 제품을 참조합니다. 출고 책임의 SCM 이관은 목표이며, 권한·담당자·적용일은 미확정입니다. |
| 경영진 · 부서 대시보드 | 기존 제출 파일부터 경영진 대시보드로 연결합니다. 판매 3축의 기간·버전·커버리지를 명시합니다. 통합재고 조회는 원천 기준시각과 ERP-WMS 상태 매핑을 확인한 범위에서 제공하며 실출고 잠금 기능과 구분합니다. |
| ① 판매계획 | 판매계획은 목표와 제출 양식의 축입니다. 실적이나 정산으로 취급하지 않고 계획 버전과 적용 기간을 보존합니다. |
| ② 구매일 기준 판매추이 | 고객 구매일 기준 실적·주문내역을 사용합니다. 실제 마감완료 정산으로 이 원천을 덮어쓰지 않습니다. 주문 원천이 없으면 셀인/출고 추이 또는 미수령으로 표시합니다. |
| ③ 마감완료 정산내역 | 실제 마감완료 정산내역입니다. 배송·취소·반품·쿠폰 반영 여부와 채널 기준일·확정 상태를 보존합니다. 잠정 가마감은 별도 상태이며 완료정산으로 승격하지 않습니다. |

## 제품 · 채널 · LOT 관계

기본 3계층에 포장 사양·판매구성·실물 추적을 별도 축으로 연결합니다. 화살표는 논리적 관계이며 최종 ERD의 카디널리티 표기가 아닙니다.

```mermaid
flowchart LR
  taxonomy["분류군 · 가변 깊이<br/>TAXONOMY / CLASSIFICATION<br/>쿨링·선케어 등 분류 예시"]
  product["출시제품 정체성<br/>PRODUCT / product_id<br/>코드 변경을 넘어 추적"]
  item["실물 품목<br/>ITEM / item_id<br/>재고·출고·구매의 구분 단위"]
  revision["포장 · 라벨 사양<br/>ITEM_REVISION<br/>신·구 사양 공존 / 적용기간"]
  offer["채널 상품 · 옵션<br/>CHANNEL_OFFER<br/>채널·계정·옵션·기간"]
  salesbom["판매구성 BOM<br/>버전 + OFFER_COMPONENT<br/>본품·증정·수량·단위"]
  lot["LOT · 포장작업 · QC<br/>LOT / PACKAGING_RUN<br/>품목·사양 연결 증빙"]
  bom["포장 BOM / 처방<br/>PACKAGING_BOM / FORMULA<br/>원가·가격 이력은 별도"]
  keymap["외부 코드 연결<br/>원천 + 계정 + 코드 종류<br/>옵션·단위·유효기간"]
  orders["주문 · 거래 행 참조<br/>주문번호 + 실제 행 식별자<br/>주문·출고·정산 관계"]
  inventory["재고 관측 · 예약상태 참조<br/>ITEM × 창고 × LOT × 상태<br/>기준시각·상태 매핑 필요"]
  taxonomy -->|"분류 관계"| product
  product -->|"소속 이력"| item
  item -->|"사양 관계"| revision
  offer -->|"구성 버전"| salesbom
  salesbom -->|"구성 ITEM·수량"| item
  item -->|"실물 추적"| lot
  revision -->|"포장 사양 참조"| bom
  revision -. "작업·증빙으로 연결" .-> lot
  lot -->|"관측·배정"| inventory
  keymap -->|"offer 코드 연결"| offer
  keymap -->|"ITEM 코드 연결"| item
  orders -->|"주문 시점 매핑"| offer
  bom -. "승인 버전 참조" .-> lot
  classDef core fill:#FCEEEF,stroke:#AF272F,color:#25282B
  classDef candidate fill:#F6F7F8,stroke:#596168,stroke-dasharray:5 4,color:#25282B
  class product,item,keymap,inventory core
```

| 영역 | 설명 |
|---|---|
| 분류군 · 가변 깊이 | 분류 깊이는 고정하지 않습니다. 기능·제형 등 교차 분류는 별도 taxonomy 또는 관계로 관리합니다. 쿨링은 여러 출시제품을 포함하는 분류 예시입니다. |
| 출시제품 정체성 | 하나의 출시제품 정체성을 유지해 포장·채널별 품목코드가 달라도 판매추이를 묶습니다. 이름 유사성만으로 자동 통합하지 않습니다. |
| 실물 품목 | 실물 관리상 구분해야 하는 용량·단위·구성을 나타냅니다. 내부 ID와 ERP 코드는 독립입니다. ITEM 소속은 PRODUCT_ITEM_MEMBERSHIP 이력으로 관리합니다. |
| 포장 · 라벨 사양 | 포장 변경이 새 ITEM인지 같은 ITEM의 revision인지는 정책으로 판정합니다. LOT 번호만 보고 포장 사양을 추정하지 않습니다. |
| 채널 상품 · 옵션 | 하나의 채널 판매상품은 여러 실물 ITEM으로 구성될 수 있습니다. 가격·프로모션·채널 전용 속성은 전사 제품마스터에 중복 저장하지 않습니다. |
| 판매구성 BOM | 판매구성 1개에 포함되는 ITEM과 수량을 버전별로 보존합니다. 주문시점 구성으로 해석하고, 판매옵션 수량과 본품 환산수량을 구분합니다. |
| LOT · 포장작업 · QC | LOT와 포장작업·품질판정을 별도로 관리합니다. LOT 없는 원천 재고를 LOT별로 임의 배분하지 않습니다. 처방·내용물 LOT와 완제품 포장 관계는 증빙에 맞춰 정합니다. |
| 포장 BOM / 처방 | 포장 BOM과 처방 BOM은 목적·오너·공개 범위가 다릅니다. 이 상자는 도메인 묶음이며 하나의 테이블을 뜻하지 않습니다. 처방과 원가는 제한 권한으로 분리합니다. |
| 외부 코드 연결 | 제품코드·바코드·사용자 정의 코드를 ITEM 또는 CHANNEL_OFFER에 연결합니다. 주문번호/수주번호/행번호는 거래 연결키로 별도 관리합니다. |
| 주문 · 거래 행 참조 | 주문 식별자만으로 제품을 식별하지 않습니다. 원천 행은 당시 offer/ITEM 매핑과 연결하고, 주문건수를 구성품별로 펼쳐 중복 합산하지 않습니다. |
| 재고 관측 · 예약상태 참조 | 실물·예약·보류·가용재고는 원천의 정의와 기준시각을 맞춘 뒤 통합 조회합니다. 플랫폼 내부 예약표시가 ERP/WMS 실출고 잠금을 보장하지 않습니다. 예약/할당/가상창고/부서재고 이동은 ERP 기존 기능·설정·권한을 확인한 뒤 운영하며 ERP 자체 수정·확장은 범위 밖입니다. |

## AWS 시스템 구성

AWS RDB 우선. ERP Core의 UI를 활용하고 인증·쿼리·SQL 권한 경계는 새 백엔드에 맞춰 교체합니다.

```mermaid
flowchart LR
  user["부서별 사용자<br/>BM · 영업 · SCM · 재경<br/>역할·채널·필드 권한"]
  ui["ERP Core 기반 화면<br/>공통 표·트리·폼·앱 셸<br/>CMSLAB CI와 업무 상태"]
  session["서버 신원 · 세션<br/>검증된 외부 신원 → 내부 사용자<br/>조직·역할·비활성 상태 확인"]
  idp["SSO / 인증 제공자<br/>기존 SSO 또는 신규 IdP<br/>제품·운영 방식 미확정"]
  files["원본 · 출력 파일 저장<br/>S3 후보<br/>파일 권한·버전·보존기간"]
  worker["파일 등록 · 검증 · 대사<br/>기존 자동화 + 제출본 검증<br/>신규 연계는 후속 / 결과 이력"]
  service["업무 서비스 · 권한<br/>플랫폼 검증·승인·감사<br/>ERP 실행권한과 별도"]
  repo["Repository · 트랜잭션<br/>서버 SQL 접근 / 제한 계정<br/>ORM·migration 도구 미정"]
  db["AWS 업무 RDB<br/>RDS PostgreSQL 후보<br/>내부 업무원장·판매 3축·뷰"]
  external["더존 ERP / WMS · 외부 실행 경계<br/>ERP DB 읽기 성공 / WMS·API는 별도<br/>기존 기능·설정·권한 확인 → 담당자 실행<br/>ERP 자체 수정·확장 범위 밖"]
  user -->|"업무 사용"| ui
  ui -->|"요청"| session
  idp -->|"신원 검증"| session
  session -->|"검증된 actor"| service
  worker -->|"같은 업무 규칙"| service
  worker -->|"원본·출력"| files
  service -->|"파일 접근 통제"| files
  service -->|"인가된 작업"| repo
  repo -->|"조회·쓰기"| db
  external -. "허용 조회만" .-> worker
  classDef core fill:#FCEEEF,stroke:#AF272F,color:#25282B
  classDef candidate fill:#F6F7F8,stroke:#596168,stroke-dasharray:5 4,color:#25282B
  class service core
  class idp,files,db,external candidate
```

| 영역 | 설명 |
|---|---|
| 부서별 사용자 | 원가·처방·주문 개인정보는 역할에 맞게 제한합니다. 승인 권한과 업로드 담당은 구분하고 현행/이관 적용일을 관리합니다. |
| ERP Core 기반 화면 | 공통 컴포넌트를 재사용합니다. 제품·채널·LOT 도메인은 새로 구현해야 합니다. 브라우저는 DB 자격증명을 받지 않습니다. |
| 서버 신원 · 세션 | Supabase Auth/SSR 세션을 새 인증 흐름으로 교체합니다. UI 버튼 숨김 외에 Server Action/API에서 신원과 권한을 검증합니다. |
| SSO / 인증 제공자 | Cognito 등은 후보일 뿐 확정하지 않았습니다. 사용자 인증과 AWS RDB 접속 인증은 별도입니다. |
| 원본 · 출력 파일 저장 | 원본 Excel과 생성 파일을 보존하는 저장소 후보입니다. 다운로드 권한을 서버에서 검증하고 민감 파일을 일반 제품 조회 응답에 노출하지 않습니다. |
| 파일 등록 · 검증 · 대사 | 외부 ERP·WMS·채널에서 허용된 파일·조회 방식으로 수집합니다. 재시도·배치별 처리 결과·중복 방지를 업무 서비스와 공유합니다. |
| 업무 서비스 · 권한 | AWS 내부 제품·매핑·판매 3축·제출 상태·승인 이력을 관리합니다. 내부 상태 변경 권한은 ERP/WMS 재고 예약·출고 실행 권한이 아닙니다. ERP 사용방법 안내·운영설계와 ERP 자체 수정·확장 범위를 구분합니다. |
| Repository · 트랜잭션 | 기존 Supabase/PostgREST 쿼리를 이 경계로 교체합니다. 트랜잭션·정렬·페이지·권한·동시성 계약을 보존합니다. |
| AWS 업무 RDB | AWS RDB는 신규 플랫폼 내부 업무원장입니다. 여기에 쓰는 권한은 더존 ERP DB 쓰기권한과 무관합니다. 제출 파일·검증·매핑·승인·조회 상태를 관리하며 외부 재고 실잠금을 보장하지 않습니다. 엔진·버전은 미정입니다. |
| 더존 ERP / WMS · 외부 실행 경계 | ERP SELECT 성공은 API 연동·쓰기 검증과 다릅니다. 기존 기능으로 예약/할당/창고이동 등이 가능할 때 운영 절차와 사용자 안내를 설계합니다. 기능이 없다면 신규 플랫폼의 조회·경고만으로 실출고 잠금을 보장할 수 없습니다. |

## 수정·재생성

생성 정의: [build_architecture_view.py](99_생성도구/build_architecture_view.py). 하나의 노드·연결 정의에서 HTML/SVG와 Mermaid를 함께 만든다. HTML이나 이 Markdown만 직접 수정하면 재생성 때 덮어써진다. 단일 진입점 파일명은 유지하고 실제 설계 정본이 바뀌면 노드 설명·관계·근거를 함께 갱신한다.

```sh
python3 00_프로젝트작업실/99_생성도구/build_architecture_view.py
```