CMSLAB 채널 자동화 공수·일정 검토

기준일 2026-09-10. 남은 작업의 ROM(초기 계획 추정)이며 실측 작업시간·견적 확정·고객 승인 일정이 아니다. 기존 인터뷰·자료 프로파일링·ERP 조회 개통은 완료 근거로 활용하고 다시 처음부터 수행한 시간은 넣지 않았다. 아래 업무 이해는 남은 확인·워크스루·규칙 승인이다. 고객이 요청한 전체 사이클과 현재 제출파일 적재만 하는 축소 범위를 구분한다.

먼저 결론: 30개 채널의 실무 판단까지 자동화하는 범위를 4명·40영업일에 완료한다는 계획은 현재 근거로 지지하기 어렵다. 그러나 ‘최소 40일’이라는 보편 하한을 입증한 것도 아니다. 인원·고객 협조·완료 범위를 바꾸면 일정도 달라진다. 현재 자료는 병목의 성격을 보여주며, 아래 시간은 이를 계획 가정으로 수치화한 것이다.

1. 채널별 산정표

숫자는 수행팀 잔여 Person-hour이며 고객 참여 공수는 별도다. 단계 벡터는 이해 / 확보 / 분석 / 코드 / 규칙 / 개발 / 대조 / 예외 / UAT / 전환 순이다. Lead Time은 담당자 1개 작업열에 하루6시간을 배정하고 해당 채널의 대기를 순서대로 더한 영업일 추정으로, 포트폴리오 대기열·공통기반은 포함하지 않는다. 이를 30개 합산하지 않는다. 각 채널은 첫 계정/국가·대표 양식 및 검증 표본 범위가 기준이다. 국가·스토어·양식 수가 늘면 추가 산정한다.

30개 포트폴리오를 어떻게 정했는가

38개는 독립된 38개 계정이 아니라 채널·거래처군·국가군이 섞인 관리 항목이다. 위 [30안]은 사용자의 ‘약30개’ 가설을 계산하기 위한 대표 포트폴리오이며 고객이 승인한 대상이 아니다. 제휴몰, 메디컬 B2B, 일본 오프라인 납품, 계열사, 글로벌 B2B, 중국법인, 중국파트너·Tmall·대만, 일본 자사몰 8개는 묶음/독립범위 미확정 또는 별도 기능과 중복되어 비교안에서 제외했다. 군납·코스트코도 미확인이지만 이름이 특정된 판매 경로의 불확실성을 포함하려고 남겼다. 이는 유일한 선택이 아니며 마지막 8개를 단순 공짜로 처리한 것이 아니다. 38항목 전체 확장안도 별도로 계산한다. 글로벌 Amazon·국내 자사몰 역시 복수 계정 가능성이 있어 최종 분해가 필요하다.

A~E 판정

• A: 운영 자산의 권한·로그·범위·재실행이 확인된 재사용. 현재 확정 A 없음. 글로벌 Amazon·Shopify·TikTok은 제한 범위 A 후보다.
• B: 합의된 완성 파일의 자동 적재. 파일이 있다는 이유만으로 전체 업무를 B로 두지 않는다.
• C: 수집 구현과 개별 코드 대사. API/RPA 실제 가능 여부는 별도 게이트다.
• D: 여러 원천의 수량·금액·상태·시점을 대조하고 현업 판단을 규칙화한다.
• E: 업무·권한·의미·합의가 미확인. 본질적으로 고난도라는 확정이 아니라 견적 불확실성이다. E의 시간은 가예약이며 디스커버리 후 다시 산정한다.

2. 근거에서 드러나는 병목

근거: 채널 현황 정본(9/9), API·기존 자동수집 근거, 국내 원전·행번호 검토, 해외·메디컬 원전·행번호 검토. API 정책을 새로 실호출한 조사가 아니다.

3. 산정 전제와 단계별 시간

실제 인원·주당 투입률·키맨 가능시간은 미확인이다. 비교 기준은 수행팀4명: PM/업무분석1, 데이터·연동2, 화면·QA·운영1이며 동시 역할이므로 전문 QA 1명 추가를 숨겨 계산하지 않았다. 1·2명은 다역할 유연 배분으로 계산하며 전문성을 모두 갖춘다는 강한 전제다. 6명은 BA2/Data3/UI·QA1, 8명은2/4/2다. 따라서 6명 증원만으로 UI·QA 병목이 해소되지는 않는다.

1 Person-day=8 Person-hour. 일정 환산에는 1인당 하루6시간을 계획 작업에 사용할 수 있다고 가정한다. 나머지2시간은 일반 관리·중단 여유이며 채널 인터뷰·규칙회의·UAT는 6시간 내 명시 공수로 포함했다. 고객 인력 공수는 총량에 포함하되 수행팀 생산능력으로 나누지 않는다. 고객은 전 부서 합계 주40시간을 확보한다는 미확인 가정이다. 개인1명이 주40시간 붙는다는 뜻이 아니다.

고객 단계별 시간은 수행팀 단계 공수의 50/40/15/30/45/0/35/15/65/30%를 각 단계에서 올림한 계획값이다. 공통의 고객 참여는15%, 다른 기능은20%를 가정했다. 실제 참석인원×시간 및 검토시간이 확보되면 교체한다. 수행팀과 고객이 함께 회의하면 양쪽 Person-hour를 각각 센다.

AI/LLM 속도로 인터뷰·매핑합의·대사·UAT 시간을 할인하지 않았다. Optimistic의 비개발 감소는 자료가 명확하고 재작업이 적다는 가정이며 AI가 승인이나 검증을 대체한다는 가정이 아니다. 예외 수정은 대조 후 코드/매핑 재작업이고, 개발은 첫 구현이다. UAT는 고객 검증/재검증이며 공통 통합시험과 채널별 시나리오를 구분한다.

검증 범위는 우선 같은 기간의 원천/현업결과, 정상·취소·반품·증정/세트·기간경계·정정 사례를 확보하는 것이다. 데이터 범위와 건수·금액·수량 허용오차를 사전에 합의한다. 모든 역사 데이터 정리, 원천이 제공하지 않는 셀아웃 복원, ERP/WMS 자체 수정·무인쓰기·재고 락 구현은 제외한다. 계정 차단이나 계약상 불가이면 유한시간 안에 해결된다고 가정하지 않고 중단/파일 전환한다.

시간은 A~E 기준 프로파일에 채널별 추가 규칙·대사를 가산한 초기 분해다. 과거 작업 로그에 의한 회귀 견적은 아니다. 예를 들어 네이버는 옵션/코드4h·규칙4h·구현4h, Qoo10은 접근3h·코드6h·규칙6h·대조4h를 D 기본형에 추가했다. 상세 값은 estimate-model.json과 Excel에서 수정 가능하다. Pessimistic도 최대비용 보장이 아니며 미확인 계정·국가 수가 늘면 넘을 수 있다.

4. 공통 기반과 다른 기능 공수

공통 엔진은 한 번만 계산한다. 엔진에 입력할 채널별 코드·기간·수수료·구성 규칙과 고객 승인은 재사용하지 않는다. ERP 조회계정 개통과 스키마 목록을 재구축하지 않고 필요한 테이블·증분·업무 의미 검증만 공통으로 포함한다. 실행 코드의 운영 재사용이 입증되면 해당 공통 항목을 차감한다.

RPA 40h는 허용된 단순 다운로드 경로가 선정될 때의 조건부 기반이다. OTP 우회·캡차 회피·ERP 자동 입력을 포함하지 않는다. RPA를 채택하지 않으면 공통40h와 해당 채널 개발 차액을 제거한다.

이 추가액은 기존 ERP Core를 활용한 얕은 조회/입력 MVP 예산이다. 계약의 13개 기능 전체 상세 구현 견적이 아니다. 이미 만든 연구문서/정적 웹을 운영 시스템 구현 완료로 간주하지 않는다. 제품 마스터 엔진·3축 기본화면·공통 인계는 공통표에만 넣었다. 다른 기능의 상세 수용기준이 미확정이므로 전 프로젝트 고정 견적은 아직 불가능하다.

5. 실제 공수와 Calendar Lead Time

채널별 접근·규칙합의·기존결과 회신·UAT 예약 대기 기본값은 O=1/1/1/1일, B=4/3/3/3일, P=10/8/8/7일이다. E에는 각 대기당1/3/7일을 추가했고 Qoo10·다이소·무신사는 접근에1/3/5일을 추가했다. 모두 관측 평균이 아닌 가정이다. 이때 담당자가 권한 확인에 쓰는 작업시간은 별도다. 예컨대 업무2시간+회신4영업일은2시간 공수와4일 대기로 각각 기록한다.

포트폴리오 일정은 아래 근사식이다. 실제 자원 배정 WBS/CPM 계산 결과가 아니다.

작업일=max(수행팀 총h/(인원×6), 역할별h/(역할인원×6), 고객h/(고객주간h/5), 의존경로 모형)+계획예비일

의존경로 모형은 가장 긴 채널 단일 작업열 Lead Time+초기 공통게이트8/12/18일+마지막 통합게이트3/5/8일이다. 공통 구축과 Discovery는 겹칠 수 있어 보수적이다. 계획예비일3/8/20일은 의존관계 상세화 전 일정 여유이며 이미 포함한 권한/UAT 대기를 다시 합산한 값이 아니다. 월 마감 실사이클을 새로 기다려야 하면 기존 확정 표본 검증과 별도로 최대 약 한 마감 주기를 추가할 수 있다(실제 일수 미확인).

5.1 공통 기반 + 30개 채널 전체 사이클

5.2 위 범위 + 채널 외 최소 기능(전 프로젝트 계획안)

5.3 38개 관리항목 전체로 확장한 민감도

표의 소수점/정수는 계산 검증을 위한 것이며 그 정도의 견적 정확도를 뜻하지 않는다. 예를 들어 214일은 약210일 수준의 계획 추정이다. 주 단위는 공휴일·고객 휴가 미반영이므로 실제 달력 날짜로 약속할 수 없다.

5.4 인원·고객 가용시간 민감도

고객 가용시간 변화에 따른 Base 전 프로젝트 영업일(수행팀4명/8명):

인원을 늘려도 같은 버티컬 담당자·재경·SCM의 검토 대기열은 남는다. 고객40h/주는 전체 합계이므로 특정 키맨에게 집중되면 이 계산보다 늦어진다. 담당별 예약을 확인하지 못한 현재에는 정확한 확률이나 납기 보장을 붙이지 않는다.

5.5 필요한 인원

위 최소인원은 대기·역할 불균형·교육/조율을 무시한 산술 하한이다. 이 인원만 넣으면 가능하다는 의미가 아니다. 실제 필요한 규모는 더 크거나, 순차 합의 경로 때문에 인원 증원으로도 해당 기한을 만족하지 못할 수 있다. 현재 미확인30개에 이 규모를 한꺼번에 투입하는 것은 권고하지 않는다.

6. 40영업일 가설의 비판적 검증

방향에는 동의하되 수치의 보편성에는 동의하지 않는다. 원전은 복합키·세트/증정·쿠폰·날짜·재고 가용 판단과 부서 확인이 남아 있음을 보여준다. 이 때문에 코딩속도만으로 계산하는 것은 부적절하다. 그러나 비개발 시간에 높은 가정을 넣어 계산한 결과를 ‘현장에서 실제 병목 시간이 측정됐다’고 역으로 해석하면 순환논증이다.

• Base 30개 채널+공통 수행팀 공수는 3,928h다. 수행팀4명이40일×6h를 쓰면 960h이므로 이 모형에서는 약 4.1배의 차이가 난다. 다른 기능은 아직 넣지 않은 비교다.
• 대기·역할 병목을 전부 무시해도 3,928/24=약 164영업일이다. 계획 가정을 ±30% 흔들어도 약 115~213일의 총량 하한이다. 이는 신뢰구간이 아니라 민감도다.
• 40일보다 짧아질 수 있는 반례: 30개가 이미 합의된 최종파일이고 기존 엔진이 운영 중이며 채널당22h의 제한 적재만 필요하고 잔여 공통120h라면 수행팀780h다. 4명×6h 기준 총량33일로40일 안이 가능할 수 있다. 단, 고객 검증 슬롯과 준비된 표본이 있고 SKU/정산/재고 판단을 새로 자동화하지 않는 조건이다. 현재 모든 채널이 이 조건이라는 증거는 없다.
• 길어지는 구체 작업: Qoo10 구성 효력일과 물류연결, 일본 FBA 가용·입고예정, 올리브영 유효기간/납품가능, 쿠팡3PL 수기판단, 면세 공급가·수불, 지그재그 쿠폰 부호, 에이블리 누적차분, 재경 확정본 검증이다. 자료가 없는 E채널은 합의 자체가 시작 게이트다.
• AI가 모든 첫 개발 코드를 즉시 만들더라도 코드대사·규칙·기존결과 대조·고객 UAT와 운영책임은 사라지지 않는다. 첫 개발 시간을0으로 놓는 극단적 민감도 역시 계약상 완료를 보장하지 않는다.

7. 병렬화와 Critical Path

병렬화 가능한 일: 권한 요청과 파일 확보, 독립 채널의 프로파일링, 공통 프레임 구축과 인터뷰, 코드 목록 초안, 이미 승인된 규칙 구현, 다른 담당자의 UAT다. 공통 ETL·매핑·회귀검증 프레임은 한 번 만든다.

병렬화하기 어려운 일: 한 채널의 기준일/키 확정→규칙 승인→변환 결과 대조→UAT, 같은 담당자의 여러 채널 승인, 재경 마감 확정, SCM 가용재고 합의, 고객 앱 승인과 실제 권한 테스트다. 여러 개발자가 동시에 같은 미확정 규칙을 구현하면 대기 대신 재작업이 증가한다.

예상 임계경로: 범위·담당 확정 → 동일기간 원본/정답파일 확보 → SKU/구성·날짜·금액 정의 → 재경/SCM 합의 → 구현 → 차이분석/예외 수정 → 담당자 UAT → 운영인계. 공통 배포환경·최소 키 모델은 구현/적재 진입 게이트다. 어느 채널이 실제 임계경로인지는 접근 일자와 담당자 예약을 확인한 후 WBS에서 확정해야 한다. 현재는 E채널·Qoo10·쿠팡·FBA가 후보이며 확정 CPM이라고 부르지 않는다.

8. 현재 기간에 맞춘 권고 범위

기존 WBS 초안는 종료일12/23의 내부 초안이다. 9/10~12/23에는 주말만 제외하면75일이며 공휴일·휴가·월말 정비를 확정하지 못했다. 따라서 가용70영업일을 예산 가정으로 두었다(공휴일 실산정값 아님). 탑다운 작전계획의 조회 우선 전략을 적용한다.

권고안은 기본3경로 자동수집 재사용+8개 파일 어댑터+나머지27개 목록/기존그룹자료/설계로 제한한다. 다른 기능은 위 최소 MVP 중 광고 상세 조인과 F13 운영기능 개발64h(Base)를 후속으로 두며 기존 자료/조사 결과 조회는 유지한다. 재고 락·ERP 쓰기·전국가/전계정 자동화는 제외한다. Base68일은70일에 매우 근접하므로 3경로 권한 확인이 실패하면 파일로 전환하고 기능을 더 줄여야 한다. 현재 실제 인원이 미확인인 상태에서 완료를 확약할 수 없다.

① 현재 기간 내 현실적인 자동화 수

수행팀4명·고객 합계40h/주·권한 조기개통·제한 MVP 조건에서 기존 판매수집 경로3개 재사용 + 완성파일8개 채널 적재를 계획한다. 11개 채널의 정산·물류·실무판단 전체 자동화가 아니다. 전체 D수준 자동화 채널 수는 현재0개를 납기 약속 대상으로 두고, 첫 파일럿 검증 뒤 기존 범위를 교체하는 방식으로1건씩 확장한다. 인력이1~2명이면 이 권고안도 기간 초과이므로 조회/파일 범위를 더 축소해야 한다.

② 이번에 자동화할 경로

• 글로벌 Amazon: 기존 Make 판매 후단의 대표 국가/계정1개. 광고·FBA 의사결정·전체 정산 자동화는 제외.
• Shopify: 기존 Make의 대표 스토어 판매1경로. 실제 양식·로그가 없으면 파일 수용으로 전환.
• TikTok Shop: 이미 있는 기본 주문/판매 VIEW·시트1경로. Affiliate 귀속·GMV Max 재개발·전체 국가 확장은 제외.

셋 모두 A 확정이 아닌 재사용 후보다. 첫5영업일 내 담당·권한·현행로그·재실행·비교파일을 확인하고 재산정한다. 네이버 API는 추가 슬롯 후보이나 기본안에는 기존 보고 방식으로 둔다. 현재 품고 raw만 확인되어 완성파일22h 슬롯으로 간주하지 않았다. 가공파일4종이 확인된 국내 자사몰을 대표1양식 적재 후보로 우선한다. 네이버 완성 제출본이 확보되면 교체 여부를 재검토한다. 후보를 늘릴 때는 다른 작업을 빼는 명시적 교환이 필요하다.

③ 파일 수집 또는 기존 방식으로 수용

• 개별 적재·대사8개: 올리브영、롯데면세점、신라면세점、신세계면세점、HDC신라/아이파크、현대면세점、국내 자사몰、일본 Rakuten. 현업이 제출한 완성파일 대표1양식/1축부터다. 부서별3축 모두 확보·자동화했다고 표시하지 않는다.
• 기존 그룹/현업 제출 방식17개: 다이소、네이버、컬리、비마트、쿠팡、지그재그、무신사、에이블리、카카오쇼핑/톡스토어、화해、CJ온스타일、임직원몰、메디컬 B2B(클리닉·종병·대리점)、일본 Qoo10、일본 Amazon、일본 LOFT 판매、계열사. 기존 제출본에 해당 채널이 실제 포함되는지 확인한 범위만 조회하며 신규 개별수집기·독립대사 완료로 세지 않는다. 없으면 미확보로 표시한다.

④ 상세 분석/설계 후 Phase 2로 넘길 항목

제휴몰、엑스퍼트몰、일본 오프라인 납품、YesStyle、군납/국군복지단、코스트코、글로벌 B2B(국가별)、중국법인、중국파트너·Tmall·대만、일본 자사몰. 총10개 관리항목이다. 현재단계는 원천/담당/범위 확인과 설계 메모만이며 운영 파이프라인 완료가 아니다. 글로벌B2B·중국 등은 실제 계정/거래처로 분해해 재산정한다. 이와 별도로 쿠팡 발주/3PL 실행, 다이소 추정 셀아웃, 일본FBA 보충, Qoo10 동적세트·물류대사, TikTok Affiliate도 각 채널의 깊은 업무를 Phase2로 남긴다. 채널 전체 제외와 기능 깊이 제외를 구분한다.

⑤ 일정 초과 가능성이 큰 작업

확률을 계산할 과거 실적은 없으므로 정성 순위다. 1) 30개 모두의 수작업 판단을 동일 깊이로 구현하는 범위, 2) 쿠팡·Qoo10·FBA의 다중 원천/물류·예약 판단, 3) 기존 수집 범위를 넘는 Affiliate·광고·정산 결합, 4) 미확인 국가·거래처·스토어를 한 채널로 간주한 확장, 5) 한 명의 MD/재경/SCM 담당자에게 집중되는 대조·UAT, 6) ERP 변경·자동쓰기를 플랫폼 작업으로 흡수하는 경우다.

⑥ Scope / Time / Resource 조정

Scope를 먼저 줄이고 고객 검증 Resource를 확보한다. 판매3축의 완성파일 조회와 오류/미확보 표시를 첫 수용기준으로 고정한다. 전체채널 자동화가 필수라면 Time을 늘리고 역할별 수행인원·고객 검증시간을 함께 늘려야 한다. 개발자만 증원하는 방식은 권하지 않는다. 4명 기준 Base68일의 권고안도 여유가 작아, 첫2주 실측 후 Scope를 재조정한다.

9. 첫 2주에 추정을 실측으로 바꾸는 방법

첫5영업일: 후보3경로에 성공로그·scope·반복실행·담당자 결과를 확보하고 대표 파일2개(면세1, 국내 자사몰 또는 올리브영1)를 선정한다. 규칙이 가장 적은 성공사례만 고르지 말고 취소/정정/세트 사례도 포함한다. 다음5영업일: 같은기간 기존결과와 차이를 분석하고 고객 확인을 예약한다. 실제 작업 h와 요청→회신 대기를 따로 기록한다.

측정 항목은 단계별 수행팀 h/고객 h, 요청시각/회신시각, 코드 수/미매핑 수, 발견 규칙 수, 검증회수, 승인 대기, 양식·계정 수다. 채널별 재사용률은 코드 행수가 아니라 완료 조건을 충족한 작업묶음 비율로 본다. 2주 후 A후보 유지/파일전환/Phase2를 결정하고 현재 ROM을 갱신한다. 실패한 경로를 끝없이 붙잡지 않는다.

경영진/PM 공유용 5줄

1. 현재38개는 채널·국가·거래처군이 섞인 목록이며, 30개 전체 자동화는 개발 외 코드대사·규칙합의·UAT를 포함해야 합니다.
2. 계획 가정상30개+공통은 Base 수행팀3,928h로, 4명·40영업일의960h를 크게 초과합니다(실측 견적 아님).
3. 현재기간에는 기존 수집3경로 재사용과8개 채널 완성파일 적재를 우선하고, 나머지는 기존자료 수용·설계로 제한하는 안을 권고합니다.
4. 권고안은4명·고객합계40h/주 기준 Base약68영업일이며, 권한·담당자 검증 슬롯이 확보되지 않으면 범위를 더 줄여야 합니다.
5. 개발자 증원보다 범위 확정과 고객 검증시간 확보가 먼저이며, 첫2주 실측으로 공수·납기를 재산정해야 합니다.