파일럿은 성공했다. 롤아웃은 죽었다. 열 번 중 아홉 번은, 원인이 세 가지로 귀결된다.
이 영화는 너무 여러 번 봤다. 2023년, 나는 인디애나주 Plainfield 외곽의 3PL이 180,000평방피트 규모의 시설에서 AI 기반 피크 경로 최적화 도구를 파일럿 도입하는 일을 도왔다. 6주 후, 효율 개선 성과에 고객은 "언제 전 거점에 도입할 수 있냐"고 물었다. 창고가 열 개라 했다. 우리는 오하이오주의 두 번째 창고까지 갔다가 프로젝트가 완전히 멈춰 섰다. 그곳 피커들은 시스템의 경로 제안을 통째로 무시했다. 세 번째 거점은 시작조차 못 했고, 계약서의 롤아웃 조항은 먼지만 쌓인 채 놓여 있었다. 그 프로젝트가 가르쳐준 것을 나는 지금 모든 고객에게 말한다. 파일럿이 증명하는 것은 기술이 "돌아간다"는 것. 롤아웃이 시험하는 것은 그것이 "남의 건물에서도 살아남을 수 있는지"다.
사망 원인 하나: 파일럿 데이터는 온실에서 자랐다
파일럿 데이터는 결코 자연스럽지 않다. 당신의 파일럿을 떠올려보자. 벤더 엔지니어들이 몇 주씩 현장에 상주하지 않았는가? 누군가 예외 주문을 한 건씩 손으로 라벨링하지 않았는가? 피커들에게 "시스템 지시를 따르고 임의로 하지 마라"고 명시하지 않았는가? 사람은 지켜보고 있다는 걸 알면 다르게 행동한다. 데이터가 깨끗했던 건 현장 전체가 "모델 하우스"처럼 모범적으로 행동했기 때문이다.
그 과보호 데이터로 모델이 학습했다. 그런데 두 번째 창고에는 그런 돌봄이 전혀 없다. 스캔은 빠지고, 반품 사유는 아무거나 찍고, 슬로팅 변경은 이틀씩 기록이 안 된다. 같은 모델, 다른 밥상. 그리고 쇠퇴는 천천히 온다. 한 달째는 괜찮아 보이고, 세 달째에는 추천이 틀어지기 시작하고, 작업자는 신뢰를 잃고, 불신은 데이터를 더 악화시킨다. 늦기 전까지 아무도 눈치채지 못하는 죽음의 나선이다.
그래서 롤아웃의 첫걸음은 모든 신규 거점에서의 데이터 베이스라인 감사다. 사람을 2~4주간 그곳에 상주시키고, 아무것도 바꾸지 않는다. 그냥 관찰한다. 스캔 준수율, 마스터데이터 완성도, 예외 처리 속도. 파일럿 창고의 데이터 품질에 못 미치는 거점이 있으면, 먼저 데이터를 고치고 본 가동은 뒤로 미룬다. 이 시간과 돈은 건너뛸 수 없다. 건너뛰면 열 배로 치르게 된다.
사망 원인 둘: 모델은 두 번째 창고에서 향수병에 걸린다
둘 다 "창고"라 불리는 건물이 속은 전혀 다른 종일 수 있다. 우리의 Plainfield 파일럿은 SKU 프로파일이 집중된 풀케이스 피킹에 이동 경로도 고정돼 있었다. 오하이오 거점은 소포 EC를 다루며 SKU는 한 자릿수 차원으로 많았고, 웨이브 로직도 완전히 달랐다. 모델이 "학습"한 것은 거의 무용지물이었다.
차이는 세 층으로 쌓인다. 첫째는 상품과 주문 구성. 풀케이스 대 낱개, B2B 대 직접 판매——모델의 전제가 발밑에서 바뀐다. 둘째는 프로세스. 두 거점이 다 "피킹"이라 부르면서 한 곳은 put wall로 모아 재검증하고, 다른 곳은 tote에 바로 피킹한다. 절차가 바뀌면 모델의 제안 행동은 현실과 어긋나기 시작한다. 셋째, 가장 교활한 것은 시스템 버전이다. WMS 버전이 두 릴리스만 달라도 같은 "피킹 완료" 이벤트의 필드 의미와 타임스탬프 로직이 다를 수 있다. 인터페이스를 연결하면 데이터는 어긋난 채 도착한다.
지금의 내 규칙. 본 가동 전 신규 거점에서는 반드시 파일럿 거점 대비 편차 레지스터를 작성한다. 상품 프로파일, 주문 유형, 핵심 프로세스 절차, 시스템 버전과 인터페이스 필드를 항목별로. 차이가 큰 곳은 모델이 오기 전에 프로세스를 고치고 데이터 정의를 맞춘다. 모델이 우리의 엉망진창에 적응해주길 기대하면 안 된다. 못 한다. 그리고 철칙 하나. 롤아웃 기간 중 WMS와 인터페이스 버전 업그레이드는 동결한다. 내가 본 가장 억울한 실패는 롤아웃 중에 IT팀이 WMS를 업그레이드한 경우였다. 필드 정의 하나가 바뀌고 가동 중 세 거점의 모델이 동시에 깨졌다. 동결이 업그레이드 금지는 아니다. 업그레이드할 때마다 먼저 테스트 환경에서 모델 회귀 검증을 통과시킨다는 뜻이다.
신규 거점에는 섀도 기간도 둔다. 시스템은 추천을 내놓지만 판단을 넘겨받지는 않는다. 작업자는 평소대로 일한다. 2~4주간의 비교. 시스템 제안과 베테랑의 판단이 어디서 어긋나는지, 그 차이가 데이터 문제인지 아니면 모델이 이 건물을 진짜로 이해 못 한다는 증거인지. 섀도 데이터만이 전면 전환 결정의 유일한 정당한 근거다. 직감으로 결정하면 안 된다.
사망 원인 셋: 아무도 쓰려 하지 않고, 계산도 맞지 않는다
파일럿 기간에는 경영진이 앞장섰고, 벤더가 상주했고, 작업자도 호기심이 있었다. 롤아웃 기간은 어떤가. 신규 거점 매니저는 "이건 본사 프로젝트지 내 보너스가 아니야"라고 생각하고, 작업자는 "이것 때문에 스캔을 두 번 해야 하는데 왜 해야 하지?"라고 생각한다. AI 제안이 20년 베테랑의 직감과 부딪히면 베테랑이 이긴다. AI 편에는 아무도 없으니까.
기술과 함께 조직의 발판도 배달해야 한다. 각 롤아웃 거점에는 지명된 비즈니스 오너가 필요하다. 비즈니스,다. IT가 아니다. 그 사람의 분기 목표에 "AI 롤아웃 본 가동 및 파일럿 측정 수준으로 운영"이 들어가야 한다. 사람은 보너스 플랜에 들어 있는 것을 위해 싸운다. 그게 인간의 본성이다. 본성과 싸우지 마라.
그리고 파일럿 팀을 해산시키지 마라. 가장 흔한 실수. 파일럿이 성공하면 벤더 직원은 떠나고, 사내 프로젝트 팀은 해산되고, 각 거점은 복제 방법을 혼자 고민해야 한다. 대신 파일럿 팀을 복제 스쿼드로 전환하라. 편차 레지스터, 데이터 베이스라인 기준, 섀도 운영 플레이북을 들고 거점을 하나씩 돈다. 처음 세 거점은 전면 지원, 네 번째부터는 리뷰만, 일곱 번째 이후는 손을 뗀다. 이 속도를 서둘 수는 없다.
ROI 계산도 롤아웃 "후"가 아니라 롤아웃 "전"에 재무팀과 확정해야 한다. 파일럿 ROI는 대개 "이상적인 계산"이다. 인건비 절감은 세고, 구축 비용은 무시하고, 잘못된 추천으로 인한 재작업은 무시하고, 섀도 모드 중 이중 운영 인건비도 무시한다. 롤아웃 때 재무팀이 다 더하면 숫자가 얇아 보이고 프로젝트가 의심받는다. 차라리 먼저 스스로 정직하게 계산하라. 구축, 데이터 정비, 잘못된 추천으로 인한 오피킹 비용——전부 포함해서 거점당 상각한다. 얇지만 진짜고 복제 가능한 ROI는, 두껍지만 복제 불가능한 ROI를 매번 이긴다. 재무팀과 마주할 때는 벤더의 슬라이드가 아니라 자사 파일럿의 측정값을 써라.
그 파일럿을 다음 건물에 복사하기 전에, 이 체크리스트를 걸어보자. 거점의 데이터 베이스라인은 충족됐는가. 편차 레지스터는 작성됐는가. 시스템 버전은 동결됐는가. 섀도 기간은 예정됐는가. 롤아웃을 목표에 넣은 비즈니스 오너는 지명됐는가. 복제 스쿼드는 온전한가. ROI 산정 방법은 재무팀과 합의됐는가. 일곱 개 모두에 "예"라고 답할 수 없으면, 아직 아무것도 설치하지 마라. 파일럿에 한 번 이기는 건 운이다. 그 승리를 열 번 반복하는 게 진짜 실력이다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
