2024년 가을, 나는 캘리포니아 미라로마에 있는 전자상거래 창고의 WMS 데모에 참관했다. 영업 담당자는 꼬박 1시간을 떠들었다. 지능형 웨이브 최적화, 디지털 트윈, 없는 게 없었다. 사장은 고개를 끄덕였다. IT 매니저는 노트 3페이지를 채웠다.
나는 손을 들었다. "잠깐. 오늘 반드시 출고해야 하는 핵심 고객의 긴급 오더가 있습니다. 방금 릴리스한 웨이브에 넣어 주세요. 라이브로 부탁합니다."
데모 전문가는 3초간 굳었다가 메뉴를 뒤지기 시작했고, 2분 동안 클릭을 하더니 마침내 미소를 지었다. "긴급 오더는 당연히 지원합니다. 오늘 데모 환경에는 설정이 안 되어 있을 뿐입니다."
5초간의 침묵. 사장은 노트를 덮었다.
그 장면이 반복되는 걸 셀 수 없을 만큼 봤다. 슬라이드에서는 눈이 부시다가, 실제 창고 시나리오가 나오자마자 무력해진다. 수년에 걸쳐 열두 번 넘는 WMS 선정을 지켜본 끝에, 나는 하나의 뼈아픈 교훈을 얻었다. 기능 체크리스트는 벤더의 게임이며, 모든 체크박스에는 이미 체크가 되어 있다. 진짜 시나리오를 건네주고 라이브로 실연하게 만들면, 그건 당신의 게임이다. 열 곳 중 아홉 곳은 세 번째 시나리오에서 땀을 흘리기 시작한다.
나의 정석 방법은 이렇다. 데모 1주일 전, 실제 운영에서 뽑아 쓴 시나리오 5개를 벤더에게 보낸다. 데이터는 마스킹하고, 로직은 진짜다. 데모 당일에는 슬라이드 금지. 모든 건 시스템 안에서 라이브로 한다. "이 기능이 있습니까?"라고 묻지 않는다. 마우스 클릭 횟수를 세고, 몇 개 화면을 오가는지 보고, 예외가 실제로 알림을 띄우는지 확인한다. WMS는 하루에 수천 번씩 만진다. 작업당 클릭 3번이면 연간 수십만 번의 낭비 동작이다.
"긴급 오더를 라이브 웨이브에 넣어라. 지금 당장."
시나리오는 단순하다. 웨이브는 릴리스되었고, 피커들은 RF 건을 들고 통로를 걷고 있다. 그때 고객서비스에서 전화가 온다. 핵심 고객의 오더가 오늘 출고되어야 하니, 지금 웨이브에 끼워 넣어 달라는 것이다.
봐야 할 세 가지. 릴리스된 웨이브에 오더를 주입할 수 있는지. 새 작업이 피커의 핸드헬드에 실시간으로 뜨는지, 아니면 다음 웨이브까지 기다리는지. 절반쯤 피킹된 웨이브가 엉망이 되지는 않는지.
전형적인 실패 답변: "긴급 오더는 지원합니다만, 현재 웨이브를 닫고 다시 만드는 게 필요합니다." 즉시 탈락이다. 실제 창고에서는 웨이브를 그렇게 닫을 수 없다. 피크 시즌에 하루 수천 건의 오더를 처리하는데 웨이브를 닫으면 피킹 라인 전체가 30분 멈춘다. 더 교묘한 실패도 있다. 오더 주입은 잘 되는데, 슈퍼바이저가 무전으로 일일이 통보할 때까지 피커의 건에는 아무것도 안 뜬다. 그들의 "실시간"이 슬라이드 안에만 있다는 증거다.
혼합 팔레트 반품은 시스템이 죽는 곳이다
출고에서는 모든 WMS가 화려해 보인다. 반품은 거짓말 탐지기다. 시나리오: 혼합 팔레트 하나가 반품되어 온다. 재판매 가능한 것, 포장이 찌그러져 폐기행인 것, 오출고되어 반품과 함께 돌아온 카톤 2개.
봐야 할 것. 반품 접수 한 번에 QC 작업이 한 단계로 자동 생성되는지. QC의 "폐기" 판정이 재입력 없이 폐기 흐름과 재고 조정을 발동하는지. 오출고 카톤이 원래 출고 오더와 연결되어 대체 출고를 일으킬 수 있는지.
많은 시스템의 반품 모듈은 "반품을 입력할 수 있습니다" 수준이다. QC는 종이, 폐기는 스프레드시트로 집계한다. 2023년, 나는 폰타나의 3PL이 피크 시즌에 반품 구역을 꼬박 2주간 쌓아 두는 걸 봤다. 겨우 치웠더니 대부분은 그대로 폐기행이었다. 사장은 팔레트들이 줄줄이 폐기되는 걸 지켜보며 얼굴이 파랗게 질렸다. 반품 처리 하나에 화면 3개와 "이 품목을 폐기"라는 자유 입력 메모란이 필요한 데모는 탈락이다. 반품 담당자는 그 메모란을 절대 채우지 않는다. 영원히 비어 있을 것이다.
슬롯 이동과 창고 간 이동: 가짜 다창고의 정체를 폭로하다
피크 시즌 전, 잘 나가는 SKU는 상단에서 골든 피킹 존으로 내려온다. 시나리오 1: 200개 로케이션의 이동 작업을 일괄 생성한다. 시스템이 한 번에 처리할 수 있는지, 이동 중 재고가 '이동 중'으로 보이는지 아니면 그냥 동결되는지, 이동 작업이 피커의 작업 구역별로 자동 배정되는지.
시나리오 2가 킬러다. 창고 A는 부족하고 창고 B에 재고가 있다. B에서 A로 200케이스를 이동한다. 다창고 지원을 자랑하는 시스템 중 상당수는 이를 B의 출고 오더 + A의 입고 오더로 처리하고, 그 사이 하루 이틀 동안 재고가 허공으로 사라진다. 장부 재고와 실재고는 영원히 맞지 않는다. 나는 바로 여기서 죽은 프로젝트를 경험했다. 월말 차이가 너무 커서 재무가 승인을 거부했고, 팀은 3일 동안 사이클 카운팅에 매달렸다.
진짜 다창고 아키텍처는 이를 하나의 문서 흐름으로 이동시키고, 이동 중 재고가 처음부터 끝까지 보인다. 데모에서는 그냥 세어라. 화면 몇 개인지, 문서 번호 몇 개인지, 서로 연결되는지. 연결 안 된 문서가 2개를 넘으면 가짜 다창고다.
키보드를 악당에게 넘겨라
마지막 시나리오는 내 최애다. 피커 권한만 있는 계정을 만들고, 재고 조정 전송, 원가 리포트 열람, 확정된 출고 오더 삭제를 시도한다.
확인할 세 가지. 권한이 버튼과 필드 수준까지 내려가는지. 권한 없는 행동이 오류로 막히는지, 아니면 조용히 통과되는지. 누가 무엇을 언제 시도했는지 기록하는 감사 로그가 있는지.
전형적인 회피는 "권한은 완전히 설정 가능합니다." 설정 가능과 존재는 다르다. 하나를 지금 당장 라이브로 설정해 보라고 해라. 못하면 없는 거다. 내가 본 최악은 역할이 딱 2개, 관리자와 작업자였다. 작업자는 오더를 삭제하고, 재고를 조정하고, 모든 원가 리포트를 읽을 수 있었다. 영업 담당자는 어깨를 으쓱했다. "작은 회사는 그렇게 세분화할 필요가 없습니다." 오늘은 작은 회사다. 3년 후, 창고가 4개가 되면? 그때 시스템을 갈아타는 비용은 울고 싶을 만큼 나온다.
시나리오 5개를 마치면 후보의 70에서 80퍼센트는 탈락한다. 남은 곳과 가격, 일정, 서비스를 협상해라. 기반은 검증되었으니 크게 망할 일은 없다.
하지만 솔직히, 어떤 벤더를 고르는가보다 더 중요한 게 있다. 그리고 그건 늘 간과된다. 이 5개의 시나리오를 애초에 누가 썼는가 하는 것이다.
너무 많이 봤다. IT가 선정을 주도하고, 테스트는 API, 아키텍처, 싱글 사인온을 커버하는데, 현장의 진짜 고통은 하나도 들어가지 않는다. 고라이브 날, IT는 승인한다. 피커들은 통로에서 욕을 한다. 긴급 오더는 주입 안 되고, 반품은 종이로 돌고, 이동은 스프레드시트로 돈다. IT가 물은 질문은 현장에서 하나도 의미가 없었다.
그래서 남기고 싶은 질문은 이거다. 다음에 당신 회사가 WMS를 고를 때, 시험 문제를 쓰는 건 누구인가? 문제를 쓰는 자가, 사게 될 시스템을 정하기 때문이다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
