WMS 교체의 가장 위험한 순간은 가동일 아침이 아닙니다. 그 직전의 조용한 몇 시간——데이터 동결 윈도우입니다. 구 시스템은 종료 수순에 들어갔고, 신 시스템은 아직 신뢰받지 못하는 구간이죠. 동결 시점을 잘못 잡으면, 가동 첫 주를 주문 출고가 아니라 재고 정합에 쓰게 됩니다.
소프트웨어 선정에 6개월, 구현에 4개월을 쏟아붓고는 동결 결정을 절환 직전 주에 미뤄둔 팀을 수없이 봤습니다. 결과는 매번 같습니다. 가동일 아침 구 시스템에 여전히 남아 있는 수백 건의 미완료 웨이브, 신 시스템에서 맞지 않는 재고, 불타는 고객 응대 큐. 2019년 폰태나의 3PL 프로젝트에서 가까이서 봤습니다. 한 번이면 충분했습니다.
동결은 하나의 선이 아니라 세 개의 리스트다
대부분 동결을 하나의 순간으로 상상합니다. 구 시스템이 멈추고 신 시스템이 시작되는. 하지만 실제로 동결 시점은 세 개의 리스트이며, 각각이 자기 스케줄대로 동결됩니다.
첫 번째 리스트는 마스터 데이터로, 가장 먼저 동결됩니다. 품목 마스터, 로케이션 마스터, 고객·벤더 마스터는 절환 2~3주 전에 잠가야 합니다. 논리는 간단합니다. 데이터 마이그레이션과 검증은 스냅샷을 기준으로 돌아가는데, 마스터가 계속 바뀌면 마이그레이션 스크립트는 끝나는 순간 바로 구식이 됩니다. 제 원칙은 이렇습니다. 마스터 동결 이후의 추가는 예외 프로세스를 통해서만——종이 양식, 제 서명, 그 다음 시스템 입력.
두 번째 리스트는 거래 잔액으로, 전날 밤에 동결됩니다. 재고 잔액 스냅샷, 미완료 판매 주문, 미완료 구매 주문과 입고, 보류 중인 재고 조정, 미완료 실사 태스크——이 모든 것을 절환 윈도우가 열리기 전에 '사진 찍듯이' 확정합니다. 사진이 찍힌 뒤에는 구 시스템의 해당 문서들은 마감할 수 있지만 신규 생성은 절대 안 됩니다.
세 번째 리스트는 진행 중 작업으로, 가장 지저분한 부분입니다. 피킹은 끝났지만 검품이 안 된 웨이브, 트레일러에 실렸지만 아직 출고되지 않은 주문, 하역이 안 된 트럭에 실려 있는 입고——이것들은 두 시스템을 가로지르고, 하나하나에 오너와 결정이 필요합니다. 제 철칙은 이렇습니다. 마감할 수 있는 건 다 마감한다. 예외만 신 시스템으로 가져가고, 모든 건에 절환 체크리스트에 명기된 오너의 서명이 붙습니다.
윈도우 길이는 달력이 아니라 주문량에서 계산한다
표준 동결 기간이란 건 없습니다. 하지만 계산하는 방법은 있습니다. 일일 주문량, 웨이브 리듬, 팀이 문서를 마감하는 속도에서 역산하세요.
먼저 절환 윈도우를 정하고, 거기서 동결 액션을 도출합니다. 하루 수천 건의 주문을 처리하는 이커머스 물류센터라면, 보통 물량이 적은 시간대를 통째로 하나——예컨대 토요일 밤 10시부터 일요일 아침 6시까지——달라고 합니다. 윈도우가 열리기 4~6시간 전에 새 웨이브 생성을 멈추고, 진행 중 웨이브가 자연스럽게 끝나도록 둡니다. 2시간 전에는 입고를 수기 로그로 전환합니다. 윈도우가 열리면 재고 스냅샷을 찍고 구 시스템의 쓰기 권한을 잠급니다.
절대 양보할 수 없는 조건 하나: 동결 전에 실사를 하라는 겁니다. 전면 실사가 아니라, 절환이 건드리는 고회전 로케이션만 전부 순환 실사합니다. 스냅샷을 찍고 나서 시스템 재고와 실제 재고 사이에 3포인트 격차가 발견돼 절환 전체가 일주일 밀린 프로젝트를 본 적이 있습니다. 실사는 동결의 전제 조건이지, 선택 사항이 아닙니다.
그리고 팀들이 잊는 게 하나 있습니다. 동결 윈도우를 미리 고객과 운송사에 알리는 겁니다. 특히 3PL이라면——동결 중에 고객이 긴급 주문을 넣으면, '그 시간대가 왜 암흑인지' 설명하는 표준 스크립트가 필요합니다. 전화가 울린 뒤에 쓰지 마세요.
병행 운영은 짧게——구 시스템은 미러지 파트너가 아니다
절환 후 두 시스템을 병행 운영할지는 영원한 논쟁거리입니다. 제 입장은 단호합니다. 예, 병행하되——구 시스템은 읽기 전용 백미러로만 남고, 두 번째 데이터 입력 창구가 되어서는 안 됩니다.
미러라는 건 구 시스템이 2~4주간 조회 접근을 유지한다는 뜻입니다. 고객 응대는 거기서 주문 이력을 조회하고, 재무는 거기서 정합하고, 절환 전 반품은 거기서 처리합니다. 하지만 모든 신규 거래는 신 시스템에 들어갑니다. 양쪽 시스템에 새 주문을 입력하는 건 제가 본 최악의 관행입니다——두 데이터셋은 사흘 만에 벌어지고, 정합은 악몽이 됩니다.
병행 기간은 2주로 제한하고, 길어도 한 달입니다. 한 달이 지나도 구 시스템 없이는 못 살겠다면, 신 시스템의 뭔가가 미완성이었다는 뜻입니다. 답은 병행을 무기한 연장하는 게 아니라 고치는 겁니다. 기간이 끝나면 구 시스템은 아카이브됩니다. 데이터베이스를 백업하고 봉인합니다.
롤백 계획은 종이에 쓰고——리허설하라
마지막으로 롤백입니다. 많은 프로젝트의 롤백 계획은 전문이 이렇습니다. '문제가 발생하면 구 시스템으로 복귀한다.' 그건 계획이 없는 거나 마찬가지입니다.
쓸 만한 롤백 계획에는 네 가지가 명시됩니다. 트리거(예: 핵심 출고 플로우가 2시간 이상 다운, 또는 주요 고객 주문이 완전 출고 불가), 단독 의사결정자(위원회가 아닌 한 사람, 보통 프로젝트 리드), 롤백 중 신 시스템에서 생성된 데이터의 처리(피킹 완료 주문, 인쇄된 라벨——무효화 또는 수기 환원), 그리고 롤백 훈련의 시점(제 요구사항: 절환 전 최소 한 번의 풀 리허설, 시간 측정 복원 포함).
롤백 계획에 대해 솔직히 말하겠습니다. 그 진짜 가치는 사용되는 데 있는 게 아닙니다. 절환일 전에 모든 '만약에'를 생각해 보게 강제한다는 데 있습니다. 진지하게 쓴 롤백 계획을 갖고 있던 프로젝트 중 제가 맡은 건 한 번도 롤백하지 않았습니다. 없었던 두 프로젝트는 한밤중에 저에게 전화했습니다.
이번 주에 절환 계획을 세우고 있다면, 오늘 밤 하나만 하세요. 미완료 주문 리스트를 뽑아 웨이브 스케줄과 겹쳐놓고, 계획된 동결 시점 전후 12시간 동안 '공중에 떠 있을' 주문이 정확히 몇 건인지 세는 겁니다. 그 숫자가 절환 계획 전체의 토대입니다. 모래 위에 지으면 그 위의 모든 게 위험해집니다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
