# CMSLAB 원천별 갱신주기 근거표 CURRENT

> 기준일: 2026-09-09 (최신 조회 전략) / 기존 주기 관찰 2026-08-29  
> 목적: `원천에서 데이터가 바뀌는 주기`, `사람/시스템이 추출하는 주기`, `플랫폼에 보여야 하는 freshness`를 섞지 않고 관리한다.  
> 주의: 파일 생성시각과 파일 내부 날짜범위는 **제공된 샘플의 단서**이지 반복 운영주기의 확정 근거가 아니다.

<!-- CURRENT-INVENTORY-START -->
## 2026-09-09 최신 조회 경로·운영 경계

이 절이 최신 전략이다. 아래 8/29 주기 후보는 과거 검토 이력이며 승인 SLA가 아니다. 기존 부서가 가공한 제출 파일부터 등록·검증·축적하고 기존 API/자동화는 재사용하고 수집 공백은 파일로 보완하며 신규 RAW/API 자동화는 후속으로 둔다. 사이트 로그인·최신 메뉴를 이번에 테스트한 것은 아니다.

현업이 WMS/채널창고에서 먼저 집행하고 ERP에 뒤늦게 등록하는 경우가 있으므로 ERP를 최신 실물재고 정본으로 가정하지 않는다. 지연은 채널·업무별로 확인하며 전 채널에 같은 지연을 적용하지 않는다.

### 어디에서 무엇을 확인하나

| 원천 / 사이트 | 화면·파일 | 재고 범위 / 코드 grain | 조회·업무 담당 | 기준시각 / 현행 주기 | ERP 반영시점·차이 | 수집 가능 범위 / 미확인 | 근거 |
|---|---|---|---|---|---|---|---|
| 더존 ERP-U / URL 확인 필요<br>업무계정 URL 확인 필요 | 구매/자재 > 창고별재고현황2<br>재고자산수불부<br>ERP 창고 구분 내역.xls | ERP 논리 S/L·등록된 품목 수불/장부 재고<br>ERP S/L코드 | SCM 재고 대사·영업 조회. 등록/승인 담당은 별도 | 2026-09-09 근거정리;재고스냅샷시각별도<br>DB 읽기 성공. 운영 반영/증분 주기는 확정 전 | 일본 일부 월 등록 설명을 확인했다. 모든 채널이 같은 주기로 지연되는 것은 아니며 WMS/실물과 같은 기준시각으로 대사해야 한다. | ERP 화면/파일·DB 조회. 직접 쓰기·ERP 수정은 이번 범위 밖<br>소유자·물리 거점·논리 S/L은 별도 축이다. 화면 기능의 존재가 권한·실행 가능성의 증거는 아니다. | [stock_erp_sl](<../discovery/_materials/files/wms-data.md>) |
| [가온/한익스프레스 WMS](https://gaon.hanex.co.kr/)<br>사용자 제공/원천원장 URL;실로그인·최신메뉴 검증 안함 | 재고현황.xlsx<br>입고현황.xlsx<br>수주일보.xlsx | 물류센터/셀의 LOT·정상/불량·유효기간<br>센터×셀×상품×LOT×등급 | SCM·물류사. 영업은 납품 가능 여부·유효기간 확인 | 2026-09-09 근거정리;재고스냅샷시각별도<br>일일 다운로드·대사 설명;실제 추출시각미확인 | SCM인터뷰상ERP/WMS 반영 차이;정확한 채널별 지연미확정 | 현재 수령 Excel 표본·현업 다운로드. API 범위/비용 미검증<br>정확한 화면 메뉴 경로는 미확인. ERP 수량과 중복 합산 금지 | [stock_gaon](<../discovery/_materials/files/wms-data.md>) |
| [품고나우](https://seller.poomgo.com/)<br>사용자 제공/원천원장 URL;실로그인·최신메뉴 검증 안함 | 재고 > SKU별재고조회<br>SKU별재고조회.xlsx<br>입고목록.xlsx | 센터×SKU 총/가용/출고후예상·진열/창고/불용/입고<br>센터×SKU; 주문/합배송/송장×SKU | 네이버 운영·SCM·품고 | 2026-09-09 근거정리;재고스냅샷시각별도<br>일일 반영이면 충분하다는 요구. 실제 스케줄은 미확인 | 네이버 수기 ERP 처리 설명. 지연시간 실측 없음 | 수령 Excel·메뉴/다운로드 근거. API 구독과 ERP 반영은 별도<br>상태 간 합산 정의와 LOT별 재고 확인. 예상재고를 총재고에 가산하지 않음 | [stock_poomgo](<../discovery/_materials/files/wms-data.md>) [naver](<../discovery/_materials/files/sales-channel-samples-20260907.md>) |
| [HGLIS/현대글로비스](https://hglis.glovis.net/common/index.page)<br>사용자 제공/원천원장 URL;실로그인·최신메뉴 검증 안함 | 재고현황.xlsx<br>입고내역.xlsx<br>출고내역.xlsx | 센터×화주×SKU 재고/가용/보류/할당/이동IN·OUT/출고중<br>센터×화주×SKU; 업무흐름 설명 | 일본 채널·SCM·물류사. 개별 계정 담당은 미정 | 2026-09-09 근거정리;재고스냅샷시각별도<br>스냅샷 주기 미확인 | 일본 Qoo10/Rakuten 월 ERP 등록 설명. 이 파일의 모든 행에 적용되는지는 미확정 | 기존 Excel 수령. 물류 주문 데이터 재사용 후보<br>정확한 화면 메뉴 경로 미확인. 가용·할당·이동중의 중복 정의 확인 | [stock_hglis](<../discovery/_materials/files/wms-data.md>) [interview_japan](<../../03_실행관리/회의록/2026-09-09_데이터통합·관리전략_일본채널·Amazon/20_회의기록.md>) |
| 올리브영 채널 포털 / URL 확인 필요<br>업무계정 URL 확인 필요 | 매장별재고내역조회(사용자메모)<br>일별상품별사업장별실적조회(사용자메모)<br>전체매출파일의 매출비교 및 재고 시트 | 채널 오프/온라인센터·MFC·매장재고<br>일/월×상품×판매범위 | 올리브영 MD·SCM 수요/보충 협업 | 2026-09-09 근거정리;재고스냅샷시각별도<br>파일에 월/일 블록 존재. 포털 갱신시각 미확인 | ERP/GAON으로공급가능·유효기간이중확인설명;채널재고와본사재고같지않음 | 현업 가공 Excel부터 사용. 포털 전체 반출/API 미검증<br>채널 소유·본사 보유 여부 확인. 온/오프 중복 범위 구분 | [oy](<../discovery/_materials/files/sales-channel-samples-20260907.md>) |
| 면세점별 포털 / URL 확인 필요<br>업무계정 URL 확인 필요 | 각면세점 월수불/재고 다운로드<br>롯데/신라/신세계/HDC신라/현대 원본·가공본 | 사업자×점포×상품 월초/월말·입고/반송/판매/잔량<br>월×점포×ERP매핑상품/세트 | 면세 MD·거래처·재경, SCM 보충 협업 | 2026-09-09 근거정리;재고스냅샷시각별도<br>7월 월수불 표본. 실시간/일별 조회 범위는 사업자별 확인 | 월 정산 설명. ERP 반영시점과 물류 완료일은 별도 | 수령한 월 가공본 우선. 현행은 포털별 다운로드<br>소유·위탁·현지 거점 범위 확인. 통합 ERP 창고와 같은 실물의 중복 합산 금지 | [lotte](<../discovery/_materials/files/sales-channel-samples-20260907.md>) [shilla](<../discovery/_materials/files/sales-channel-samples-20260907.md>) [shinsegae](<../discovery/_materials/files/sales-channel-samples-20260907.md>) [hdc](<../discovery/_materials/files/sales-channel-samples-20260907.md>) [hyundai](<../discovery/_materials/files/sales-channel-samples-20260907.md>) |
| 다이소 포털 / URL 확인 필요<br>업무계정 URL 확인 필요 | 품목별 재고조회(메뉴명미확인) | 온라인/오프 직영 조회와 가맹점 미관측 범위 분리<br> | 다이소 MD·SCM 협업 | 2026-09-09 근거정리;재고스냅샷시각별도<br>전일 누적 조회 설명. 품목별 수동 조회·OTP 제약 | 채널별 ERP 지연 미확인 | 다운로드 가능한 가장 상세한 파일 요청. 현재 원본 미확보<br>가맹점 셀아웃·재고 추정을 관측 재고로 표시하지 않음 | 확인 필요 |
| 일본 Amazon Seller 운영화면 / URL 확인 필요<br>업무계정 URL 확인 필요 | FBA 재고<br>FBA 재고관리<br>담당자 재고 시뮬레이션(미수령) | 마켓플레이스위탁창고가용/입고예정·이동/처리중·30일배송량<br>업무흐름 설명; parent/child ASIN·SKU×통계 | 일본 Amazon 담당의 보충 판단, SCM의 본사 공급 실행/확정 협업 | 2026-09-09 근거정리;재고스냅샷시각별도<br>행사/보충 계획 갱신. 정확한 주기는 미확정 | 본사→Amazon 공급과 고객 배송 분리. 월 마감 인식 기준은 별도 | 두 보고서 다운로드→수기 시뮬레이션 설명. 파일 요청 필요<br>BusinessReport 판매 표본은 FBA 재고 원본이 아니다. 2~3주 리드타임은 현장 설명이며 SLA가 아니다. | [interview_japan](<../../03_실행관리/회의록/2026-09-09_데이터통합·관리전략_일본채널·Amazon/20_회의기록.md>) [amazon_jp](<../discovery/_materials/files/sales-channel-samples-20260907.md>) |
| 일본 오프라인 파트너 재고파일 / URL 확인 필요<br>업무계정 URL 확인 필요 | OFF파일 재고<br>재고(TESTER+B品)<br>재고(販促物) | JAN×良品/B품/테스터/판촉;소유/물리창고미확정<br>월×판매점×EDI;JAN×상태재고 | 일본 영업 수령·현지 파트너 설명, SCM 공급계획 참고 | 2026-09-09 근거정리;재고스냅샷시각별도<br>6월 납품자료와 함께 수령한 파일. 재고 기준일시는 미기재 | ERP/HGLIS 반영 관계 미확인 | 기존 파트너 가공파일 적재<br>세 시트 합산 금지. 제조사 열의 K-LABO를 소유자로 추정하지 않음 | [japan_off](<../discovery/_materials/files/sales-channel-samples-20260907.md>) |
| 글로벌 Amazon/TikTok/기타 해외창고 / URL 확인 필요<br>업무계정 URL 확인 필요 | Amazon 재고 관련 보고(정확메뉴미확인)<br>TikTok 창고·기타창고 현황(화면명미확인) | 마켓플레이스/해외물리창고·입고예정·이동중<br>업무흐름 설명 | GEC 보충 시기/수량 판단, SCM 공급 협업 | 2026-09-09 근거정리;재고스냅샷시각별도<br>수동 판단/시트 설명. 창고별 주기 미확인 | ERP 등록시점은 원천별 확인 필요 | 기존 시트와 창고별 보고를 먼저 요청. API 가능 범위별 검증<br>창고 개수는 발언이 바뀌어 고정하지 않음. ERP/채널센터와 같은 물량의 중복 방지 | [interview_gec](<../../03_실행관리/회의록/2026-09-09_전사데이터통합·자동화로드맵_이커머스수집한계/20_회의기록.md>) |
| 채널별 재고 조회 원천 확인 필요 / URL 확인 필요<br>업무계정 URL 확인 필요 | 화면명·실제 재고파일 미확인 | 본사/WMS/거래처/채널센터 중 관리 범위 확인<br> | 해당 MD·SCM | 2026-09-09 근거정리;재고스냅샷시각별도<br>미확인 | 미확인 | 현재 보고에 사용하는 원천/파일 위치 확인<br>파일·사이트 증거 없이 특정 WMS로 배정하지 않음 | 확인 필요 |
| 쿠팡 어드민 / URL 확인 필요<br>업무 계정 URL 확인 필요 | 발주리스트(수기메모)<br>현재재고 수량 다운로드(수기메모)<br>입고상세내역(수기메모)<br>일간종합성과지표/판매분석(수기메모) | 쿠팡 채널 재고/입고, 본사 ERP·한물류 공급가능 재고와 분리<br>채널 업무·API·쿠팡 출고/판매/정산 메모 | 채널 담당이 3PL에 직접 출고 요청한다는 수기 설명. 승인·등록 역할 별도 확인 | 2026-09-09 수기메모; 실제 파일·화면 미검증<br>주 2회 발주 설명. 재고 기준시각·포털 갱신 주기는 미확인 | ERP 창고별 재고와 한물류에서 SKU별 출고가능량을 비교한다는 메모. 실제 지연시간은 미확인 | 현재 쓰는 셀아웃 시트·월 정산파일부터 수령. 어드민 다운로드 자동화는 별도 확인<br>셀아웃 1년 이전 조회 제한은 수기 설명이며 공식 정책 미검증. GM/PPM/PMC 약어·산식 확정 전 지표 적용 금지 | [notes_0909](<../../03_실행관리/회의록/2026-09-09_인터뷰통합정리·수기메모/03_수기메모_추가원문_2026-09-09_01.txt>) |

### 기존 API·자동화와 파일 수집을 함께 사용

아래는 전사 설명/파일관찰/공식 API존재를 구분한 현황이며 고객 API권한과 응답필드를 이번에 테스트하지 않았다. 주문·광고 API가 있어도 WMS재고와 ERP등록까지 연결됐다는 뜻은 아니다. [전사·공식문서 근거](../discovery/_materials/files/channel-api-evidence-20260909.md)

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

### 쿠팡 추가 수기 근거 — 현행 수집과 과거 조회

[추가 수기 정리 N109·N110·N114](../../03_실행관리/회의록/2026-09-09_인터뷰통합정리·수기메모/20_수기메모_정리본.md)에 따르면 주2회 발주→ERP 창고/SKU 재고조회→한물류 가능수량 수기확인→3PL 메일→적재리스트 PPT→쿠팡 어드민 순서가 설명된다. 주2회는 발생빈도이며 평균 처리시간이 아니다. ERP 반영시점과 승인경로는 추가 확인한다.

셀아웃은 1년 조회제한 설명이 있고 셀인 입고상세와 현재재고 다운로드가 언급된다. 이는 사용자 수기 근거이며 최신 포털/API 정책을 검증한 결과가 아니다. 현재재고 다운로드를 주기별 스냅샷으로 보존하면 수집 이후 이력을 쌓을 수 있지만 과거 미수집 재고를 복구했다고 간주하지 않는다. 조회기간·수령일·스냅샷 기준시각과 업로드/검증완료를 기록한다.

### 통합 조회 모델과 통제

| 분리할 축 | 설계·조회 규칙 |
|---|---|
| 소유자·물리거점·시스템·논리창고 | `inventory_owner_id`, `physical_location_id`, `source_system`, `logical_sl_code`를 별도 관리한다. 운영 담당자와 법적/재고 소유자는 다른 값이며 확인 전 추정 등록하지 않는다. |
| 물품 식별 | 원천 화주/품목/바코드·옵션코드와 공통 ITEM을 효력기간으로 매핑한다. LOT·유효기간·QC는 원천이 제공하는 범위만 사용한다. |
| 같은 실물의 여러 관측 | ERP 장부/부서 S/L, WMS 물리재고, 채널센터/FBA 현지재고를 구분한다. 동일 실물재고를 ERP+WMS+채널 숫자로 더하지 않는다. 거점·소유자·품목·시점 중복 관계를 확인한다. |
| 상태 | 총재고·가용·예약/할당·보류/QC·packing·출고완료·이동중을 별도 의미로 둔다. 원천 정의가 중첩되면 가산하지 않는다. 원천 정의 없는 가용재고 산식을 임의 적용하지 않는다. |
| 시각·지연 | `snapshot_at`, 추출시각, 업로드시각, 원천 갱신시각, ERP 반영 확인시각을 분리한다. 마지막 입출고일은 재고 snapshot 시각이 아니다. ERP 미반영 차이와 실제 수량 오류를 별도 대사 상태로 둔다. |
| 출처·완료 표시 | 화면에 사이트/화면 또는 파일·시트·배치, 조회조건, 기준시각·지연·미수령을 표시한다. 업로드→파싱→검증→공개 완료를 구분하고 실패·미완료 배치를 최신 완료본으로 덮어쓰지 않는다. |
| 수집 우선순위 | API가 없으면 현업 다운로드·제출 파일부터 검증·축적한다. 누가 어느 조건으로 언제 추출하고 제출 완료를 확인하는지 정한다. 기존 자동화 결과는 재사용하고 신규 자동화는 후속으로 둔다. 수동 수집으로 실시간성을 약속하지 않는다. |
| 실행 권한 | 통합 조회와 재고락·예약·할당·가상창고·부서재고 분리/이동 실행은 별개다. ERP 기존 기능·설정·권한을 확인해 사용방법 안내·운영설계를 한다. ERP 자체 수정·확장은 이번 범위 밖이다. |
| 보장 한계 | 신규 플랫폼 내부 예약/락 표시나 AWS RDB 상태 변경만으로 ERP/WMS 실출고 잠금을 보장하지 않는다. ERP 기존 기능으로 불가능하면 조회·경고·업무절차로 남고 실행통제를 보장할 수 없다. |

위 조회표의 사실 정본은 [Discovery 채널·재고 원천 데이터](../discovery/channel-data-status.json)의 `inventory_sources`이며, 표는 [생성기](../../00_프로젝트작업실/99_생성도구/build_inventory_reference.py)로 갱신한다. 개별 셀을 이 문서에서 따로 수정하지 않는다.

<!-- CURRENT-INVENTORY-END -->

## 판정 라벨

- **확정(문서기록)**: 고객 제공 요구정의서·이메일에 명시된 AS-IS 기록. 실제 현재 운영은 워크스루로 재확인한다.
- **관찰**: 수령 파일의 행·날짜·컬럼에서 직접 확인한 사실. 주기를 자동으로 의미하지 않는다.
- **추정**: 문서와 표본을 함께 볼 때 가능성이 높지만 고객 확인이 필요하다.
- **제안**: 프로젝트가 목표로 삼을 초기 수집·freshness 기준. 접근방식과 비용 확인 후 확정한다.

## 원천별 주기와 제안

| 원천·객체 | AS-IS 근거 | 현재 판정 | 실제 운영주기 | Phase 1 제안 | 확인 질문·완료 기준 |
|---|---|---|---|---|---|
| 더존 ERP-U — 재고·수주·출고·창고이동 | 요구정의서 SCM 항목에 `ERP·WMS를 매일 아침 각각 다운로드`라고 기록 | 확정(문서기록) | 매일 아침 수기 추출로 보이나 실행시각·지연·실패·재실행은 미확인 | 업무 시작 전 1회 스냅샷을 기준선으로 두고, 마감/대사 필요 시 당일 재실행 허용. DB/API 가능 시 증분 전환 | 다운로드 메뉴·조건·담당자·완료시각·휴일 처리·재실행 방법 확인 |
| 한익스프레스 — 상품·수주·입고·LOT 재고 | 한익 파일 4종 수령. 수주·입고 데이터가 8/26~27까지 있으며, `이천 메인 WMS`와 한익의 동일성은 직접 명시되지 않음 | 관찰 + 추정 | 메인 WMS라면 위 `매일 아침` 범주일 가능성이 높으나 확정 불가 | 재고는 업무 시작 전 스냅샷 + 종료 후 대사, 입출고는 가능한 최소 주기(우선 1시간~반일 범위)로 실측 후 결정 | 이천 메인 WMS 여부, 추출 메뉴/API, snapshot 시각, 당일 정정·취소 반영 확인 |
| 품고 — SKU·재고·입고·주문 | 요구정의서에 품고 재고가 `자동(완전 실시간)`으로 기록. 제공 Excel에는 재고 snapshot 시각이 없음 | 확정(문서기록) + 관찰 | 원천 화면의 실시간성, ERP 반영 및 Excel 반출 지연은 미확인 | API/webhook 가능 시 플랫폼 freshness 15분 이내 후보. 파일만 가능하면 1시간 단위 또는 업무 핵심시각 배치로 별도 합의 | 자동의 의미(API/화면/시트), 지연, 삭제·취소, ERP 정산 반영, 장애 시 대체 파일 확인 |
| 현대글로비스 HGLIS/OMS — SKU·입고·재고·출고 | 요구정의서에 `반자동`, 가용/배정 구분 구현으로 기록. 8/27 생성 표본의 데이터는 객체별 8/26까지 포함 | 확정(문서기록) + 관찰 | 반자동의 구체 방식·주기는 미확인 | 초기에는 업무 시작 전 1회 + 필요 시 재실행; API/정기 반출 확인 후 1~4시간 freshness 후보 | OMS/HGLIS 관계, 일본 담당자, 다운로드 조건, 정정 반영, 개인정보 제외 추출 확인 |
| TODAY Google Sheet — ERP/WMS 대조·재고·출고·창고이동 | 파일명과 22개 시트, 요구정의서의 SCM 매일 아침 다운로드 기록 | 관찰 + 추정 | 일일 업무판으로 보이나 전체 갱신 완료시각과 일부 자동 연결 여부 미확인 | 원천 적재 완료 후 매일 1회 버전 보존. 수기 보정은 작성자·시각·사유 기록 | 어떤 탭을 누가 언제 붙여넣는지, 완료 선언과 재수정 cutoff 확인 |
| 입고정보 Google Sheet — 예정·실입고·LOT/EXP | 한익 실입고와 제상품/저장품 예정·완료 시트가 연결된 파일 수령 | 관찰 | 변경 발생 때마다 수기/수식 갱신 가능성이 있으나 주기 미확인 | 운영 중요도가 높아 30~60분 폴링 후보 또는 변경 이벤트 수집. 일일 종료 스냅샷 보존 | 입력자·완료상태·수정빈도·과거 스냅샷·IMPORTRANGE 지연 확인 |
| 판매계획 Google Sheets | 팀별 10개 파일과 통합 영업입력 파일 수령. 요구분석에는 롤링 갱신·이력 미보존 문제가 기록 | 확정(문서기록) + 관찰 | 정기 마감일과 수시 수정이 병존하는 것으로 추정 | 변경 수집 + 매일 스냅샷, 월별 기준선(version) 잠금 | 월 최초·수정·확정 시점, 승인자, 소급수정, 팀별 마감 차이 확인 |
| 도서관파일 — 통합매출 누계 | 2604·2605·2607 파일 수령, 누계형 이름과 월별 표본 존재 | 관찰 + 추정 | 월 누계/확정 성격으로 보이나 생성일·가마감·확정 cutoff 미확인 | 일간/가마감은 별도 원천으로 적재하고, 도서관파일은 월 확정 버전으로 잠금·대사 | 작성자, 월 가마감/확정일, 소급수정, 공통비·조정 반영 시점 확인 |
| WMS 품목/SKU 마스터 | 한익·품고·글로비스 각각 별도 마스터 파일 수령 | 관찰 | 거래보다 저빈도이나 신규·리뉴얼·단종 시 수시 변경 가능 | 변경 이벤트 우선. 불가하면 매일 전체 diff 후 효력일·승인·전파상태 보존 | 신규 ITEM 생성 주체, ERP 선/후행, 코드 전파 지연, 삭제 대신 종료일 사용 여부 확인 |

## 우선 결론

1. 현재 고객 문서로 **업무 주기를 말할 수 있는 것은 ERP/WMS의 매일 아침 취합과 품고의 실시간 기록 정도**다.
2. 한익·글로비스 Excel의 생성시각은 8/27 반출 사실만 말하며, 반복 스케줄을 확정하지 않는다.
3. `실시간`은 원천 화면, 수집 파이프라인, 표준화, 화면 노출 중 어느 구간인지 분리해야 한다.
4. 초기에는 무조건 실시간을 약속하지 않고 `업무 시작 전`, `당일 운영`, `월 확정` 세 등급으로 필요 freshness를 먼저 합의한다.
5. 모든 적재에는 `source_event_at`, `extracted_at`, `loaded_at`, `published_at`을 남겨 실제 지연을 측정한다.

## 인터뷰에서 바로 확인할 7문항

1. 원천 화면 숫자는 사건 발생 후 얼마 만에 바뀌는가?
2. 누가 어떤 필터로 언제 파일을 내려받는가?
3. 다운로드가 늦거나 실패하면 누가 어떻게 재실행하는가?
4. 당일 취소·반품·정정은 이전 행 수정인가, 별도 행 추가인가?
5. 업무에서 허용 가능한 가장 오래된 데이터는 몇 분/몇 시간/몇 일인가?
6. 하루 중 반드시 맞아야 하는 기준시각과 월 확정 cutoff는 언제인가?
7. 화면·Raw·표준·마트 중 어디까지 맞아야 업무 완료로 보는가?

## 근거

- 고객 요구정의서: `01_고객원본/2026-07-24_CMSLAB_요구정의서_고객원본.html`, SCM·부서별 데이터 현황
- 고객 이메일: `01_고객원본/2026-08-18_CMSLAB_고객이메일스레드_원본.pdf` — 범위·접근 방향은 있으나 WMS별 주기 확정 내용은 없음
- [고객 기준문서 재료 원장](../discovery/_materials/files/customer-basis-documents.md)
- [WMS 2차 전달 데이터 원장](../discovery/_materials/files/wms-data.md)
- [시스템·데이터 취합 원장](../discovery/03-systems.md)
- [Google Sheets 업무원장](../discovery/_materials/files/google-sheets-operations.md)

## 2026-09-09 인터뷰 보강

9/7~9/8 전사 및 사용자 메모는 일1회 기본 목표와 사건별 단축 필요를 분리한다. 이전 15분·1시간 후보는 승인 SLA가 아니며 우선 기본 목표로 확정하지 않는다. 올영 월·수는 발주 확인, 전사상 정규 납품은 수·금이다. MD 기능명은 주문기준 **판매추이**이며 정산/회계금액과 다르다. [원천별 최신 목표·쓰기 경계](CMSLAB_데이터·시스템아키텍처_인터뷰반영_2026-09-09_v0.2.md), [최신 사용자 정렬](CMSLAB_제품계층·판매추이·SCM이관_판단근거_2026-09-09.md).