COOL LAB · 재고 운영

4거점 재고 흐름 원장 자동화 설계

"결론(재고 수량)"만 보이는 1단계를 폐기하고, 입고→출고→이동→재고가 한 줄로 읽히는 이벤트 원장으로 전환

2026-10-01 · 거점 API 조사 5건(각 2회 반박 검증) + 설계안 3개 · 심사 3회 종합 · 실측 근거: 플랜 S100 로그 922행, 비연동 시트, CJ 입고현황, 쿠팡 입고관리 캡처

1결론

사서 붙일 솔루션은 없고, 자체 구축이 유일한 길 — 단 재료는 이미 다 있다 로켓그로스 FC·N배송 FBN 재고를 가져오는 기성 솔루션(플레이오토·사방넷·셀메이트·샵링커·이카운트)은 없다. 전부 '내 재고 → 쇼핑몰 전송' 방향이고 로켓그로스는 상품 등록까지만 지원한다. 반면 4거점 모두 자기 거점의 거래 로그 또는 스냅샷을 이미 내보내고 있다. 이번 조사에서 플랜 로그 ↔ 비연동 시트 ↔ CJ 입고 ↔ 쿠팡 입고가 1개 단위까지 맞물리는 것을 확인했으므로, 원천 로그를 매일 읽어 하나의 원장에 쌓기만 하면 흐름이 복원된다.

구조

이벤트 원장

재고 = Σ이벤트. 스냅샷은 덮어쓰기 아닌 대사용

거점 수집

4 + 운송중

본사 · 플랜 · CJ→FBN · 쿠팡FC + TRANSIT 가상거점

사람 손

일 0~5분

미설명 변동 사유 선택 + 본사 1행 입력만

검증 게이트

+771 재현

7~9월 백필로 현 오차를 그대로 재현해야 다음 단계

2왜 지금 구조는 "결론만" 보이는가

쿨랩오피스 1단계는 매출보고서 판매량을 채널→거점 고정 매핑(네이버→CJ, 쿠팡→로켓, 자사몰→플랜)으로 차감한 추정치다. 입력이 판매량 하나뿐이라 아래가 전부 '유령 차이'로 쌓인다.

거점 이동 미기록 — 플랜→CJ·쿠팡 박스 출고(34·48배수)가 어느 거점에도 반영 안 됨
차감 거점 오류 — 리뷰작업 기간 N배송 불가로 네이버 주문 550개를 플랜에서 비연동 출고했는데 오피스는 CJ 차감 → 플랜 +569 / CJ −380. 연동 경로('스마트스토어(쿨랩)')로 플랜 배정된 건, 칫솔모 네이버 주문(플랜 보관)도 같은 유형
B2B·판매자배송 실배송·CS·체험단 — 매출보고서에 없거나 거점 정보가 없어 차감 누락
반품 재입고·불량 전환·반출 — 입력 경로 자체가 없음

즉 숫자가 틀린 게 아니라 모델이 흐름을 받을 자리가 없다. 판매량 차감 모델은 폐기하고, 재고를 '설명하는' 장부로 바꾼다.

3거점별 데이터 접근 조사 결과

거점	API로 되는 것	API로 안 되는 것	현실 수집 경로	접근 조건 · 주의
쿠팡 로켓그로스 FC partial	재고 요약 `rg/inventory/summaries` — SKU별 주문가능수량 + 최근 30일 판매수(분당 50회) 주문 `rg/orders` — 출고일 기준, 최대 30일	입고 · 반출 · 반품 복귀 · 불량 · 정산 API 없음. 재고도 '주문가능수량' 한 숫자뿐(입고 검수중·반출중 안 보임)	API 스냅샷 일 4회(계단 상승 = 입고 확정 시점) + WING 입고관리·반출관리 화면을 Playwright가 테이블로 읽기(엑셀 다운로드 불가 확인됨 — 캡처 판독 대체)	Open API 키는 판매자당 1개 — 연동업체(이지어드민) or 자체개발 택1. 현재 키가 이지어드민 연동이면 자체개발로 재발급(IP 최대 10개 등록, 이지어드민·이지싱크 IP 포함) 필요, 그 사이 플랜 쿠팡 주문수집 단절. 키 180일 만료(14일 전 재발급), 초당 5회 제한
플랜 3PL (이지어드민) 로그 완전	공식 API 있음(`api2.ezadmin.co.kr`, 재고·입출고 로그 조회)	API는 고객사(플랜) 서명 동의 + 세팅비 200만 + 월 20만(2026-01~) — SKU 10개 규모엔 과함	재고로그 .xls(HTML 테이블) 다운로드 — 이미 파서 검증 완료(922행, 행별 잔액 포함). Playwright 자동 로그인 → 일 1회 수집. 보조: '판매처재고동기화' 기능으로 플랜 가용재고가 카페24에 전송되므로 카페24 Admin API로 스냅샷 무스크래핑 조회 가능	플랜이 자동화 전용 화주 하부계정을 발급해야 함(보안로그인 동시접속 1개 — 없으면 플랜 담당자 세션이 끊김). reCAPTCHA v3·30분 세션·IP 제한. 약관 11조(결과물 외부 복제) → 플랜 서면 양해 필수
CJ LOIS eFLEXs (FBN 전환기) partial	화주용 Open API 프로그램 존재(개발자 포털, Developer Guide v9.3.0)	포털 접근은 영업사원→영업P팀 승인 후. 재고·입출고 이력이 제공 항목에 있는지 미확인, 항목 외 개발은 유상	포털 엑셀: 통합재고조회(가용/보류) · 입고 실적 현황 · 주문현황(15일) · 정산>고객매출확인. 전환기 한정이라 수동 드롭(주 2회)으로 최소 투자	FBN 전환 후 eFLEXs 화주 계정 유지 여부 미확인(네이버 답변 "CJ 센터 유지"와 별개). 10/1 기준 S100 9/23 68개 미입고·8/18 유령 EO 340 정리 필요
네이버 N배송 FBN (전환 후) partial	커머스API N배송 그룹 = SKU 마스터 4개(목록·조회·연결상품). 주문 상세 `skuMappings`(nsId·출고수량)로 주문→SKU 출고량 재구성. 채널상품 `stockQuantity`(판매가능 재고, 센터 실재고 아님)	SKU별 센터 재고·입고·반출·반품·물류비 API 없음 — 네이버 공식 답변 3회 명시(#2900·#3396·#3578), 2025-09부터 4차례 요청에도 변화 없음	★스마트스토어센터 > N배송 관리 > N배송 이용 > SKU·재고에 흐름 원장이 이미 있음: ① SKU별 재고수량(1분 갱신, 센터별 엑셀) ② 월별 재고 보관 내역(매일 05시 센터·SKU 총재고 = 일별 스냅샷 시계열) ③ 월별 재고 변동 내역 엑셀(요약: 변동 전 + 입고·반품입고·출고·반출·폐기·재고이관 + 조정 = 변동 후 / 상세: 일자별). 입고 신청·반출 조회·반품 조회·물류비 청구서(매월 9일) 메뉴	센터 자동 다운로드는 2단계 인증·자동화 탐지 리스크 → 주 1회 수동 투입 폴백 전제. 내스토어 앱 2RPS 고정. 물류사에 따라 반출·폐기·이관이 '재고조정'으로 뭉뚱그려질 수 있음(FAQ 16582). 전환 전후 엑셀 컬럼 상이(보관 재고수량·PLT/CELL은 FBN 전용)
본사 창고 시스템 없음	—		구글시트 '본사_원장' 탭 1개 — 생산입고 · 직접출고(B2B 직납·샘플) · 실사 3종만. 본사→플랜 이송은 플랜 '입고' 로그(메모 'M/D 입고')에서 자동 파생하므로 입력 불필요	입력 누락은 플랜 입고 로그가 먼저 발견돼 '본사 출고 미기재' 큐로 역유도. 실사 분기 1회
기성 솔루션 해당 없음	플레이오토(로켓그로스 '상품 기능만 제공')·넥스트엔진('재고/주문은 쿠팡 자체 관리')·사방넷(자체 창고 재고 내보내기용)·샵링커·셀메이트 — 로켓그로스·FBN 재고 수집 기능 전부 부재. 이카운트(월 4만+가입 20만)는 창고이동 전표·수불부가 있으나 수집은 어차피 자체 개발이라 이중 시스템. → 구독하지 않는다

4설계안 3개 심사 결과

관점을 달리한 설계 3개를 독립 생성하고 심사 3회(가시성·자동화·비용·유지·정확 50점). 3회 모두 A안(이벤트 원장) 승자 37/50 — 유일하게 실제 로그·시트를 실측해 분류 규칙을 세웠고, 심사자가 S100 로그 922행을 직접 재파싱해 규칙이 전부 맞음을 확인.

안	핵심	점수	치명 결함	가져온 것
A 이벤트 원장 채택	거점 로그 → append-only 원장, 재고=누적합, 이동=출발/도착 상태기계, 스냅샷=대사용	37	어댑터 10개 유지보수 부담(→ C의 공학 틀로 보완)	골격 전체
B 스냅샷 차분	스냅샷을 진실로, Δ를 로그→집계→이동→반품 순으로 분해	28~29	비연동 시트 미사용 → 플랜 출고 76%('쿨랩' 703행)의 목적·목적지 상실. 판매처 사전확률이 실데이터와 반대. 집계 고정 매핑(네이버→CJ)을 설명 엔진에 재도입 = 771 원인 재현	쿠팡 스냅샷 일 4회 슬롯(계단 Δ = 입고/반출), 반품 풀, 전사 보존식, N배송 보관내역=일별 시계열
C 파일 인박스	수집기↔파서를 파일 규약으로 분리, config·fixtures·멱등	33~35	이지어드민 API job 코드(in/out/retin…)를 .xls에 적용 — 실로그 작업값은 '배송·입고' 둘뿐이라 규칙 대부분 미발동, 박스 이동 한 건도 식별 못 함	인박스 파일명 규약, config.toml, tests/fixtures, sku_alias(grade A/B), inferred→confirmed 승격, 본사→플랜 파생

5채택 설계 — 구조

원칙 5개

재고 = Σ이벤트. 거점×SKU 잔액은 원장 누적합. 어떤 화면도 재고를 직접 쓰지 않는다. 음수 재고는 생길 수 없고 대신 '미설명 변동' 행이 생긴다
1차 소스는 그 거점이 스스로 남긴 로그. 플랜=이지어드민 로그+비연동 시트 / 쿠팡=rg/orders+스냅샷+WING 화면 / CJ=입고 실적·통합재고 → FBN=월별 변동내역+skuMappings / 본사=시트 1행. 일일 집계는 차감 소스가 아니라 대조 소스(5번째 검증)로 격하
이동은 출발·도착 분리 + TRANSIT 가상거점. 출발만 있으면 운송중에 머물고, 도착은 목적지 로그 또는 스냅샷 잔차로 확정. 8/18 'CJ 340 = 실제 쿠팡 고양1', 9/21 'CJ 68 미입고', C100 240→238이 상태(MISROUTED/OVERDUE/PARTIAL)로 자동 드러남
스냅샷은 대사용. 원장 vs 스냅샷 차이를 시차·운송중·반품재입고 순으로 자동 설명하고, 남는 것만 큐
사람은 예외만. 큐 사유 선택 + 본사 1행. 집계 _input.json(리뷰작업·B2B·반품등급)을 재사용해 이중 입력 없음. 리뷰 가배송은 원장에 올리지 않음(실물 미발송·플랜 송장 미출력 — 10/1 확정)

데이터 모델 (SQLite 1파일, 쿨랩오피스는 읽기 뷰로 접근)

테이블	역할	핵심 컬럼
`sku_master` + `sku_alias`	모든 시스템 ID를 바코드 하나로	바코드 · 박스입수(S100 34 · C100 48 · 쿨리 32 · 치카 32) · 이지어드민 상품코드(00007 등) · CJ 품목코드 · 쿠팡 옵션ID(로켓/판배 94986287594/반품등급 10개/이너쿨 결합) · 네이버 nsId · 집계 제품명. 미매핑 ID는 적재 안 하고 '매핑없음' 예외 1건
`hubs`	거점	HQ · PLAN · CJ(전환 전) · FBN(전환 후, 물류사 불문) · CP_FC(fc_name 속성: 인천14/고양1/동탄1) · TRANSIT · 버킷 GOOD/BAD/HOLD
`ledger_events`	append-only 원장(정정은 역분개)	일시 · 거점 · 버킷 · SKU · 타입(IN_PROD/IN_TRANSFER/OUT_TRANSFER/OUT_SALE/OUT_B2B/OUT_SAMPLE/IN_RETURN/WITHDRAW/DISPOSE/ADJ) · 수량(부호) · 상대거점 · 채널 · 근거(관리번호/orderId/시트행/입고ID) · confidence(confirmed/inferred/pending)
`transfers`	이동 상태기계	출발일·출발거점·목적지·FC명·보낸수량·도착일·확정수량·상태(SENT→RECEIVED/PARTIAL/OVERDUE/MISROUTED/DISPUTED)·송장
`snapshots`	거점 보고 재고	거점·SKU·일자·슬롯(쿠팡 00/06/12/18)·가용·보류·원본 JSON
`reconciliation`	대사 큐	거점·SKU·일자·차이·자동설명·상태(UNEXPLAINED→RESOLVED)·사유·결정자

플랜 로그 분류 규칙 (S100 922행 실측 — 심사자 재검증 통과)

로그 값	의미	이벤트
작업 '배송' · 판매처 '카페24 (쿨랩)'	자사몰 판매 출고	OUT_SALE(자사몰)
작업 '배송' · 판매처 '스마트스토어(쿨랩)'	네이버 연동 자동수집 = 일반배송·당일발송 라인(부속품). ⚠10/1 실측: 롱호스·노즐팁이 S100 본체 코드 00007로 오매핑돼 9/23 1·9/28 8개가 본체 재고에서 빠짐 → SKU는 이지어드민 상품코드가 아니라 '판매처 상품코드'(13293107919 롱호스·13293145187 노즐팁·13726170664 원형모·13463003273 타원모)로 판정	OUT_SALE(네이버) @PLAN, SKU=sku_alias(판매처 상품코드) — 본체 코드 불일치 시 '매핑경고' 큐
작업 '배송' · 판매처 '쿠팡(쿨랩)'	판매자배송 연동 출고(실배송)	OUT_SALE(쿠팡판배) @PLAN
작업 '배송' · 판매처 '쿨랩'	비연동 수동 등록 전부(76%) → 구글시트 '플랜 비연동 요청(3PL)'과 (출고일·상품·수량) 조인	시트 목적별: 쿠팡 입고건→OUT_TRANSFER→CP_FC(FC명) / CJ풀필먼트 입고→OUT_TRANSFER→CJ / 네이버 주문건→OUT_SALE(네이버) / 쿠팡 주문건→OUT_SALE(판배) / CS건→OUT_CS / 공구·납품·단체→OUT_B2B / 체험단·샘플·시딩→OUT_SAMPLE
같은 타임스탬프(±5초) 박스배수 행 N개	거점 이동 출발(예 9/21 17:10:40 34×7=238 → 시트 CJ 68 + 쿠팡 동탄1 170으로 분해)	OUT_TRANSFER → TRANSIT. 박스배수로 안 떨어지면 DISPUTED
작업 '입고' · 메모 'M/D 입고'	본사→플랜 도착	IN_TRANSFER @PLAN + 본사 OUT_TRANSFER 자동 파생
작업 '입고' · 메모 '반품입고'	반품 재입고(정상/불량은 '회수' 탭)	IN_RETURN
메모 'cs 배송취소'(음수)	역분개	원 이벤트 취소

이동 도착 확정 소스

플랜 박스출고

→

TRANSIT

→

쿠팡: 스냅샷 계단 상승 + WING 입고관리 '판매개시' 수량 (판매개시 0인 유령 EO는 무시)

CJ: 입고 실적 현황 (입고예정일·품목·수량)

FBN: 월별 변동내역 '입고' 행

플랜: '입고' 로그

매칭 키 우선순위: 송장번호 > (날짜창 · SKU · 수량 정확 일치) > (날짜창 · SKU · 박스배수 분해). 도착 윈도우: 쿠팡 10일(검수 3일 반영) · FBN 7일 · 플랜 5일. 윈도우 초과 → OVERDUE 큐.

대사 3단

소스 자체 검산 — 이지어드민 행별 '재고' 열 연속성(이전 잔액 ± 수량 = 현재), 시트 Σ vs 로그 '쿨랩' Σ(실측 2,842 vs 2,831), FBN 요약 A+B+C=D·상세합=요약
거점 대사 — 원장 잔액 vs 스냅샷. 자동 설명 순서: ① 결제일/출고일 시차 ② 운송중 도착 ③ 쿠팡 반품재입고(반품등급 SKU 판매 범위 내 양의 잔차) ④ N배송 05시 마감 시차 → 남는 것만 UNEXPLAINED 큐. 허용오차 플랜 0 · 쿠팡 ±2 · FBN ±3
집계 교차검증 — 원장 OUT_SALE(채널별) == 일일 집계 순실대수 → 집계 스킬의 5번째 검증으로 추가

화면 3종 (오피스 이식 전까지 output/재고흐름_YYYYMMDD.xlsx)

거점×SKU 매트릭스 — 본사 | 플랜 | CJ/FBN | 쿠팡FC(FC별) | 운송중 | 불량 | 합계. 각 셀 '원장 / 스냅샷 / 차이' 3단, 차이≠0 배지 → 큐로 드릴다운. 현 1단계 화면은 이걸로 대체
수불부 — 이지어드민 재고수불부와 같은 꼴을 4거점 통합: 일자 | 거점 | 이전재고 | 입고(생산/이동도착/반품) | 출고(판매-채널별/이동출발/B2B/CS/반출) | 조정 | 당시재고 | 근거 링크. "입고→출고→이동→재고"가 한 줄에 보이는 핵심 화면
이동 보드 + 대사 큐 — 운송중·지연·부분도착·오귀속 상단 정렬, 큐는 사유 선택 1열만

6구축 단계

이번 주 (10/2~10/8) — 외부 승인 대기와 무관하게 착수

MD 0.5일 + 사내 Claude 2일

① MD 확인 3건: WING>판매자정보>추가판매정보에서 Open API 키 연동방식(이지어드민 연동인지)·IP·만료일 / 플랜에 자동화 전용 화주 하부계정·IP 등록·자동 조회 서면 양해 요청 / FBN 전환 후 eFLEXs 계정 유지 여부·CJ 잔존재고 처리 방식 확인
② 스키마·config·sku_alias·box_qty 작성
③ 이지어드민 .xls 파서 + 비연동 시트 파서(본탭·회수·물류_운영) + classify(실측 규칙) + purpose_map
④ 7/1~9/30 백필 → '플랜 +771 · CJ −380' 재현 리포트 = 설계 검증 게이트. 통과 전엔 다음 단계 안 감
⑤ 본사_원장 탭 생성(생산입고·직접출고·실사 3종) + 초기 실사 1회

10/9~10/22 (S100 소진기, 재입고 전) — 엔진·뷰·쿠팡

사내 Claude 3.5일 + MD(키 발급·IP)

이동 상태기계·대사·큐·xlsx 뷰 3종·run_daily(06:30 스케줄러). 쿠팡 수집기 — 키 상태에 따라 (A) rg API 스냅샷 일 4회 + rg/orders 7일 롤링, 또는 (B) 키 전환 전까지 WING 화면 Playwright 읽기. CJ는 엑셀 수동 드롭 파서(주 2회). 백필 데이터로 8/18 MISROUTED·9/21 OVERDUE·C100 PARTIAL이 자동 검출되는지 확인

FBN 안착 후 — 네이버 거점·자동 다운로드

사내 Claude 3일 + MD(앱 등록·첫 엑셀 1회)

FBN 센터 엑셀 3종(SKU별 재고·월별 보관·월별 변동) 파서 + 커머스API 내스토어 앱(SKU 마스터·주문 skuMappings·GIFT_RECEIVED 보정). 이지어드민·센터 Playwright 자동 다운로드(headed + 영속 프로필로 2FA·캡차 재인증 최소화, 실패 시 '같은 파일 수동 투입' 폴백). 매월 5일 이후 FBN 전월 확정본 재수집

쿨랩오피스 통합 → 2주 병행 → 컷오버

오피스 담당 세션 2일 + MD 일 5분×10일

오피스: 고정 차감 로직·음수 재고 제거, 뷰 4개(v_stock_now·v_flow_daily·v_in_transit·v_queue_open) 화면화, 쓰기 3개(본사 입력·B2B 출고거점·큐 결정)만 허용. 2주간 구 재고와 병행하며 미설명 변동 주 2건 이하 달성 시 컷오버. 보고서검수 스킬에 '재고 원장 대조' 체크 추가

7사용자가 할 일

1회성

WING Open API 키 확인 → 이지어드민 연동 키면 플랜과 협의해 자체개발로 재발급(IP에 이지어드민·이지싱크 포함), 플랜 쿠팡 주문수집이 멈춰도 되는 시간대에
플랜 요청 3건: 자동화 전용 화주 하부계정(유저타입 전체/공급처) · 고정 IP 등록 · 로그 자동 추출 서면 양해(약관 11조). 가능하면 거점 이동 출고 시 시트 송장번호 기재 습관
커머스API 내스토어 앱에 상품/N배송·주문 그룹 추가, FBN 전환 완료 후 센터 엑셀 3종 1회 다운로드
본사 초기 실사 1회(S100·C100·치카·쿨리 블랙/화이트·부속, 정상/불량)
purpose_map 승인 — 시트 '목적' 문자열 20여 종의 분류
쿨랩오피스 세션에 스키마·뷰·쓰기 테이블 명세 전달

반복 (정상 운영 시 남는 전부)

대사 큐 사유 선택 — 일 0~5분. 플랜은 로그가 완전해 0건, 쿠팡 반품·반출일에만 발생 예상
본사 1행 — 공장 입고·직납·반품 판정 사건당 30초
전환기 수동 드롭 — CJ xlsx 주 2회, Playwright 승인 전 N배송 엑셀 주 2회(승인 후 0)
월 1회 30분 — 쿠팡 반출·반품 화면 보정, FBN 전월 확정본, 조정 사유 통계
반기 쿠팡 키 재발급 15분, 분기 실사

매일 반복되는 신규 수작업은 0건. 일일 집계는 기존 루틴 그대로.

8완전 자동이 끝내 안 되는 곳 · 리스크

구조적 한계 (API·파일 자체가 없음)

쿠팡 FC 내부 입고확정·반출·불량 전환·반품복귀 — API 없음, 엑셀 없음. 스냅샷 계단 역산 + WING 화면 읽기로 날짜 단위까지만. 같은 날 입고+반품재입고−반출이 겹치면 오귀속 가능 → 그날만 큐
본사 창고 — 시스템 없음. 입력 3종은 사람 몫
로그인 세션 — 네이버 2단계 인증·이지어드민 reCAPTCHA·WING 세션 만료는 자동 해결 불가 → 알림 + 같은 파일 수동 투입

운영 리스크

쿠팡 키 1개 제약 — 전환 못 하면 쿠팡 거점은 화면 읽기(주 1회)로 격하, 스냅샷 해상도 상실
이지어드민 비공식 경로 — 플랜 서면 양해 없이 운영 금지. 공식 API 전환은 플랜 동의+세팅비
FBN 전환 공백 — CJ 잔존재고 반출→재입고가 요구되면 2~3주 네이버 거점 데이터 공백. CJ·FBN 별도 거점 + 이동 매칭으로 흡수
집계는 결제일, 스냅샷은 출고일 — ±1일 이월 규칙 필요, 쿠팡 rg/orders엔 반품 음수 없음
박스배수 ≠ 항상 이동 — B2B 대량(우진상사 50)과 겹침 → 시트 목적이 최종 판정

9쿨랩오피스 담당 세션에 전달할 변경 요청 (요약)

구분	내용
그만두는 것	① 매출보고서 판매량 → 채널→거점 고정 매핑 차감 로직 전부 ② 음수 재고 표시(→ '미설명 변동' 배지) ③ 재고 수기 보정 화면(조정은 큐를 통해 사유 필수)
받는 것	inventory.sqlite 읽기 뷰 4개 — `v_stock_now`(거점×SKU 원장/스냅샷/차이·운송중) · `v_flow_daily`(수불부) · `v_in_transit`(이동 보드) · `v_queue_open`(큐). 화면은 뷰를 그대로 그리고 계산은 하지 않음(계산 주체는 원장 하나)
주는 것	① 본사 입력 폼(생산입고·직접출고·실사) ② B2B 수주 레코드에 '출고거점' 필드 1개 ③ 큐 결정(resolved_as) 저장 — 유일한 쓰기 경로, source=manual_adj·결정자 기록
계속 주는 것	매출보고서의 일·채널·제품 판매량, B2B 행, 리뷰작업 — 집계 `_input.json` 경유로 대조 기대값에 사용(오피스 쪽 추가 작업 없음)
이후 확장	재고 소진 예측·재발주 판단(거점 가용 ÷ 이동평균 판매), 거점별 물류비 원장(FBN 청구서·CJ 청구 xls·쿠팡 보관료)

다음 행동 ① 오늘: WING 추가판매정보 화면 1장 + 플랜에 하부계정 요청 메일 → 이 두 가지가 쿠팡·플랜 자동화의 전제
② 이번 주: 보유 로그·시트로 백필 → +771 재현 리포트(승인·회신 대기와 무관하게 진행 가능)
③ 재현 통과 시 1단계 착수. 미통과면 설계 수정 후 재시도 — 그 전엔 수집기 개발 안 함