핵심부터 말하자. 창고를 멈추지 않고 WMS를 업그레이드하는 것은 충분히 가능하다——하지만 운과는 아무 상관이 없다. 업그레이드 전날 밤까지 세 가지를 확정해 둬야 한다：정말로 되돌아갈 수 있는 스냅샷, 리스크가 가장 낮은 사이트부터 가장 높은 사이트까지 진행하는 전개 순서, 그리고 약 4시간 걸려 하나씩 확인하는 업그레이드 후 검증 체크리스트. 이 중 하나라도 빠지면 그건 도박이다. 나는 그 도박이 망가지는 걸 세 번 봤고, 그 대가는 매번 '멈춰 선 출하 도크'였다.
시작하기 전에 하나만 분명히 하자. 이건 WMS——주문, 재고, 작업 배분을 운영하는 창고관리시스템 이야기다. PLC 신호로 컨베이어와 크레인을 구동하는 WCS(창고제어시스템)가 아니다. WCS 업그레이드는 장비를 멈추고, WMS 업그레이드는 정보 흐름을 멈춘다. 계획이 다르고, 섞으면 안 된다.
WMS 업그레이드를 망치는 건 신기능이 아니다——주변기기다
30개가 넘는 구축·업그레이드 프로젝트를 거치며, 신기능 때문에 실패한 업그레이드는 한 손으로 셀 수 있다. 내가 본 실제 실패는 전부 같은 세 가지 주변기기에서 나왔다: RF 스캐너, 라벨 템플릿, 그리고 외부 연동. 죽은 스캐너, 인쇄되지 않는 라벨, 침묵하는 EDI 연결——그게 창고 정지다.
실제 사례. 2023년, 캘리포니아 인랜드 엠파이어에서 120,000평방피트 시설을 운영하는 한 3PL이 마이너 버전 업그레이드를 했다. 업그레이드 자체는 40분이 걸렸고, IT팀은 그룹 채팅에 "업그레이드 완료"라고 올렸다. 다음 날 아침 6시, 출근한 피커들은 RF 건의 작업 화면이 어긋나 있는 걸 발견했다——새 릴리스에서 필드 길이가 바뀌었고, 구형 스캐너 클라이언트가 그걸 해석하지 못한 것이다. 400대가 넘는 기기를 오전 6시부터 정오까지 한 대씩 다시 설치. 반나절 동안 웨이브 하나도 릴리스하지 못했다. 고객사 대표는 도크에 서서 트럭 행렬을 지켜봤다. 그 얼굴이 지금도 잊히지 않는다.
교훈은 한 문장이다: 업그레이드 밤에는 RF 건, 프린터, 연동 검증에 업그레이드 자체와 같은 무게를 둬야 한다. 이게 내가 세 번 본 함정이고, 매번 이야기는 같다——"업그레이드는 성공했는데 창고가 멈췄다."
전날 밤 체크리스트: 먼저 세 가지 보험을 들어라
보험 하나: 완전한 스냅샷. 데이터베이스 백업은 기본이다. 여기에 모든 설정을 내보내 둬야 한다——웨이브 전략, 로케이션 넘버링 규칙, 라벨 템플릿, 사용자 권한, 연동 매핑. 데이터 스냅샷과 설정 스냅샷은 다른 것이다. 데이터는 백업에서 복원할 수 있지만, 잘못 설정된 전략을 고치는 데는 더 오래 걸린다.
보험 둘: 반쯤 잠든 상태에서도 실행할 수 있을 정도로 잘 쓰인 롤백 계획. 쓸 만한 롤백 계획은 세 가지 질문에 답한다: 누가 롤백을 지시하는지("프로젝트 매니저"가 아니라 이름으로); 어느 시점으로 돌아가는지(스냅샷 타임스탬프); 롤백에 얼마나 걸리는지(너의 RTO). 우리의 철칙: 전날 밤 팀 전원이 탁상 훈련처럼 롤백 절차를 훑는다. 아무도 리허설하지 않은 계획은 계획이 없는 것과 같다.
보험 셋: 다운타임 자체에 대한 업무적 대체 수단. 미리 인쇄해 둔 종이 피킹 시트, 충전된 오프라인 스캐너, 현장에 붙여 둔 긴급 연락처 목록. 롤백하게 되면 창고는 30분 안에 수작업 모드로 전환해야 한다——이건 벤더의 약속이 아니라 우리의 내부 프로젝트 표준이다. 너의 계획서에 써 둬라.
RTO와 RPO에 대해서는 정확히 말하겠다. 얼마나 빨리 롤백할 수 있는지, 얼마나 많은 데이터 손실을 감당할 수 있는지는 스냅샷을 어떻게 찍느냐에 달렸다——벤더 SLA가 뭐라고 하든 관계없다. 경험칙: 업그레이드 시작 직전에 완전한 스냅샷을 찍고, 롤백 RTO는 2시간 이내, RPO는 데이터 손실 제로(스냅샷 이후에 생긴 것은 종이 기록에서 다시 입력)를 목표로 한다. 이게 안 되면 성수기에 업그레이드를 잡지 마라.
다중 사이트 전개 순서
다중 사이트 고객의 경우, 전개 순서는 이렇다:
| 웨이브 | 어느 사이트부터 | 왜 | 관찰 기간 |
|---|---|---|---|
| 1 | 테스트 사이트 / 섀도우 환경 | 터져도 업무는 눈치채지 못한다 | 최소 한 웨이브 사이클 전체 |
| 2 | 물량이 가장 적은 사이트 | 실제 업무 검증, 리스크는 통제 | 24시간 |
| 3 | 중간 물량 사이트 | 검증 샘플 확대 | 48시간 |
| 4 | 플래그십 / 최대 물량 사이트 | 마지막에 건드린다 | 풀 현장 감시 |
철칙: 이전 웨이브의 검증 체크리스트가 전부 녹색이 되기 전에는 다음 웨이브를 시작하지 않는다. 웨이브 1이 "괜찮아 보인다"며 웨이브 2를 병행 시작하고, 천천히 번지는 버그가 터져 두 사이트가 함께 내려가는——이 함정을 나는 세 번 봤다.
다운타임 윈도우 일정 잡기: IT가 아니라 업무에 맞춰라
유지보수 윈도우는 IT의 기술적 창이 아니다. 업무가 감당할 수 있는 창이다. 세 단계:
- 먼저 물량 곡선을 읽는다. 최근 7일 슬라이딩 윈도우에서 물량이 가장 적은 밤을 찾는다. 3PL이라면 보통 일요일 새벽, 이커머스 사이트라면 프로모션 캘린더를 확인하고 세일 전후 72시간 이내는 피한다.
- 그다음 계산한다. 정직하게 계산한 하나의 숫자: 다운타임 1시간이 얼마짜리냐. 일일 주문량 ÷ 24 × 주문당 마진 × 다운타임 시간, 여기에 복구 초과 근무비와 SLA 패널티를 더한다. 너의 숫자로. 이 숫자가 윈도우를 따낼 때의 지렛대이자, 벤더와 보상금을 협상할 무기다.
- 마지막으로 롤백 발동 라인을 정한다. 업그레이드 시작 후 X시간이 지나도 핵심 기능이 복구되지 않으면 자동 롤백——"15분만 더"는 금지. X는 계획서에 쓰고, 그날 밤은 누구도 바꾸지 못한다.
역설적인 관점 하나: 대부분의 팀은 "제로 다운타임"을 쫓다가 이중 쓰기 블루-그린 배포를 짜면서 복잡도를 두 배로 만든다. 30개가 넘는 프로젝트를 거친 내 판단——90%의 창고에게는 잘 계획된 2~4시간짜리 야간 윈도우가 제로 다운타임 아키텍처보다 싸고 안전하다. "멈추지 않음"의 복잡함 자체가 가장 큰 리스크다. 트레이드오프를 똑바로 세워라: 필요한 건 "업무가 멈추지 않는 것"이지 "시스템이 멈추지 않는 것"이 아니다. 창고는 종이 피킹 시트로 2시간 버틸 수 있다. 아무도 고칠 수 없는 "제로 다운타임" 업그레이드는 버티지 못한다.
업그레이드 후 4시간 검증: 스캐너, 라벨, 연동
아직 승리는 선언하지 마라. 4시간 안에 이 리스트를 항목별로 처리하라:
- RF 스캐너: 현장의 모든 모델별로 최소 3대씩, 입고 → 적치(putaway) → 피킹 → 검수 풀 플로우를 돌린다. 구형 기기에서는 화면 필드 어긋남을 주의한다.
- 라벨 템플릿: 출하 라벨, 카톤 라벨, 피킹 시트를 각각 10장씩 인쇄하고 모든 바코드를 스캔해 가독성을 확인한다. 템플릿 어긋남은 업그레이드 후 버그 중 가장 흔하다.
- 연동: EDI, 마켓플레이스, ERP, TMS 각 연결마다 최소 1건씩 엔드투엔드 주문을 흘린다. "연결됐다"가 "맞다"는 아니다——매번 주문번호, 수량, 주소를 검증한다.
- 웨이브 전략: 실제 웨이브를 1건 릴리스하고 배분 로직이 바뀌지 않았음을 확인한다. 잘못 설정된 전략은 에러를 뱉지 않고 조용히 잘못 배분한다.
- 권한: 서로 다른 5개 역할로 로그인해 메뉴와 권한이 업그레이드를 버텼는지 확인한다.
강제 SaaS 업그레이드: 일시정지 버튼은 없다
온프레미스 WMS 업그레이드는 너의 일정대로 간다. 클라우드(SaaS) WMS는 다르다. 유지보수 윈도우와 강제 패치 푸시는 벤더의 달력을 따르고, 너는 준비할 수 있을 뿐——없어지길 바랄 수는 없다.
이건 기우가 아니다. isdown.app의 공개 상태 추적에 따르면, 클라우드 WMS 업체 Ongoing Warehouse의 경우: 2026년 2월 24일의 시스템 장애는 약 4시간, 2026년 6월 25일의 대규모 서비스 장애는 약 5시간 이어졌고, 최근 90일간의 인시던트 중앙값은 4시간 33분이었다. 즉 클라우드 WMS가 1년에 몇 번씩 몇 시간씩 내려가는 건 기록에 남는 일상——블랙스완이 아니다.
그래서 SaaS WMS 고객에게는 내 체크리스트에 항상 세 줄이 추가된다. 하나: 벤더의 상태 페이지와 유지보수 공지를 구독하고, 업그레이드 밤 전후 72시간 안에 벤더 측 유지보수가 없는지 확인한다. 둘: 벤더 귀책 장애에 대한 보상과 통지 의무를 계약에 넣는다——구두 약속은 무효다. 셋: 오프라인 대체 수단을 항상 준비한다. 클라우드 WMS가 내려가면 로컬 스냅샷조차 찍을 수 없다. 종이 서류와 오프라인 절차가 너의 유일한 구명보트다.
마지막으로
가장 위험한 업그레이드는 메이저 릴리스가 아니다. "작은 패치야, 테스트 불필요, 바로 프로덕션"이다. 내가 본 세 번의 폭발 중 두 번은 작은 패치였다. 이걸 기억하라: 자기 전에 전날 밤 체크리스트를 끝내고, 검증 리스트가 전부 녹색이 되기 전에는 성공을 선언하지 마라. 내일부터 쓸 수 있는 것: 이 글의 체크리스트를 인쇄해 다음 업그레이드 밤 전에 항목별로 체크해 가라. 30개가 넘는 프로젝트를 통틀어 가장 싼 리스크 투자다.
Lin Xiao, WMS 구현 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
