결론부터 말하겠습니다. WMS나 OMS 업그레이드가 삐끗할 때, 시스템 자체가 문제인 경우는 거의 없습니다. 문제는 프로젝트 계획에 아무도 넣지 않은 서드파티 연동입니다.
2024년에 저는 California주 Ontario에 있는 120,000제곱피트 규모의 3PL 시설에서, 교과서에 나올 법한 업그레이드 재난이 벌어지는 모습을 지켜봤습니다. 그 창고는 거의 10년 동안 써 온 WMS 버전에서 벗어나려던 중이었습니다. 프로젝트 팀은 3개월을 준비에 쏟았습니다. 데이터 마이그레이션 리허설, 사용자 교육, 피킹 경로 워크스루, 없는 게 없었죠. 가동일은 월요일 오전 8시. 9시쯤 되자 전화가 쉴 새 없이 울렸습니다. 운송사 라벨 API가 일제히 멈췄고, 수천 장의 운송 라벨이 인쇄 대기열에 갇혔고, 피커들은 RF 스캐너를 든 채 할 일 없이 서 있었습니다. 나중에 원인을 찾고 보니 거의 황당했습니다. 새 릴리스에서 출하 확정 페이로드의 한 필드가 선택에서 필수로 바뀌었고, 운송사의 전자 라벨 서비스와 통신하는 미들웨어는 5년 전에 이미 퇴사한 엔지니어가 작성한 것이었습니다. 업그레이드 계획의 그 누구도 그 코드가 존재한다는 걸 몰랐습니다.
어디를 봐야 할지 알았다면, 10분이면 고칠 일이었습니다.
건드리기 전에 목록부터 만들기
업그레이드가 시작되기 전, 저는 팀에 딱 한 가지를 먼저 시킵니다. 모든 서드파티 연동을 예외 없이 한 장의 목록표로 정리하는 겁니다. 항목은 단순합니다. 연동 이름, 상대방(어느 운송사, 어느 마켓플레이스, 어느 ERP·TMS인지), 프로토콜, 코드 책임자, 마지막 성공 호출 시점, 그리고 고장 났을 때 호출할 담당자.
'마지막 성공 호출' 항목이야말로 시체가 묻힌 곳입니다. 서류상으로는 살아 있는 것처럼 보이지만 실질적으로는 죽은 연동이 수두룩합니다. 3년 전 소규모 운송사의 반품 콜백, 아무도 들여다보지 않는 재무용 야간 정산 파일 같은 것들. 업그레이드 때 가장 위험한 것은 매 분 돌아가는 연동이 아니라, 반쯤 잊힌 연동입니다. 아무도 기억하지 못하고, 테스트 계획에도 들어 있지 않은데, 새벽 2시의 어느 cron 작업은 여전히 호출하고 있죠.
이 목록을 만드는 데는 거칠지만 잔인하게 효과적인 꼼수가 있습니다. 운영 로그에서 최근 90일간의 아웃바운드 연동 호출을 뽑아내 손으로 만든 목록과 대조하는 겁니다. 맞지 않는 것은 거의 확실히 놓친 것입니다. Ontario 창고가 사후 분석에서 이 작업을 해봤더니, 아무도 기억하지 못하던 연동이 세 개 더 나왔습니다.
다음은 문서 문제입니다. 벤더 API 문서가 실제 가동 코드와 일치하는 경우는 운이 좋아야 절반 정도입니다. 문서를 믿지 말고 패킷 캡처를 믿으세요. 업그레이드 전에 핵심 연동(라벨 생성, 출하 확정 콜백, 재고 동기화)을 골라 각각의 실제 요청-응답 사이클을 필드 단위로 하나씩 기록합니다. 하루도 안 걸리고, '문서에는 된다던데요'식의 놀람은 대부분 사라집니다.
창고를 한 번의 전환에 걸지 마세요
연동 호환성에 대한 제 입장은 단순합니다. 빅뱅 전환(big-bang cutover)은 절대 믿지 않습니다. 아무리 성숙한 WMS라도 메이저 릴리스에서 필드 규칙, 인증 방식, 응답 포맷을 바꿀 수 있습니다. 릴리스 노트에 '하위 호환'이라고 적혀 있으면 제가 직접 테스트할 때까지는 마케팅 문구로 봅니다.
신뢰할 수 있는 접근법은 세 부분으로 이뤄져 있고, 하나라도 건너뛰면 문제를 자초하는 겁니다. 샌드박스 연동 테스트, 단계적 롤아웃, 그리고 실제로 작동하는 롤백 계획.
샌드박스 테스트는 테스트 환경을 두 번 클릭하는 게 아닙니다. 실제 업무 트래픽을 재생해야 합니다. 운영 주문을 가져와 민감 데이터를 제거하고, 하루치 업무량을 샌드박스에 쏟아넣는 겁니다. 라벨이 인쇄되는지, ERP 콜백이 성공하는지, 추적 번호가 마켓플레이스에 동기화되는지 봅니다. 트래픽량이 너무 적으면 문제는 숨어 있습니다. 저는 최소 하루치 재생량을 고집합니다. 성수기 창고라면 그 두 배로.
단계적 롤아웃은 인내와 지구력의 시험입니다. 주문량의 10%를 새 버전에 흘려보내고, 반나절 지켜본 뒤 점차 늘립니다. 느리다고 싫어하는 사람들도 있습니다. '밤샘 전환 창으로 한 번에 다 넘기는 게 깔끔하다'고. 깔끔하긴 하죠. 연동 하나가 깨져서 건물 전체가 멈출 때까지는. 단계적 롤아웃의 추가 노동은 시설 전체 정지 한 번에 비하면 아무것도 아닙니다.
그리고 대부분의 롤백 계획은 허구입니다. 진짜 계획은 세 가지 질문에 답합니다. 데이터는 어떻게 되돌리는가(신버전이 만든 문서를 구버전이 받아줄까?), 연동은 어떻게 되돌리는가(되돌릴 때 상대방이 콜백을 이중으로 쏘지 않을까?), 그리고 누가 결정할 수 있는가(새벽 3시에 뭔가 이상해 보일 때, 승인 세 단계를 거치지 않고 '롤백'이라고 말할 권한은 누구에게 있는가?). 세 가지에 답할 수 없으면 그 계획은 종이에 불과합니다.
가동 당일에는 서버 CPU를 보지 마세요. 연동의 생체 신호를 봐야 합니다. 핵심 연동별 성공률, 응답 시간, 오류 코드 분포. 성공률에 걸어둔 단순한 알림 하나로 연동 장애의 10개 중 9개는 첫 사용자 항의가 도착하기 훨씬 전에 잡아냅니다.
그리고 대부분의 팀이 건너뛰는 부분이 옵니다. 가동 후 일주일간의 관찰 창입니다. 연동 장애의 절반은 지연돼서 옵니다. 월말 재무 정산 배치는 한 달에 한 번만 돕니다. 업그레이드 후 수 주 뒤에야 발화해서, 업그레이드 후 첫 실행에 실패할 수도 있죠. 마켓플레이스 재고 동기화는 평소량에서는 멀쩡해 보이다가, 프로모션으로 트래픽이 급증할 때만 깨집니다. 제 규칙은 단순합니다. 가동 후 첫 주에는 매일 아침 10분씩 연동 성공률 보고서를 확인하고, 빈도가 낮은 작업에 특히 신경 씁니다. 제대로 돌았는지, 오류는 없었는지. 둘째 주에는 이틀에 한 번으로 완화하고, 깨끗한 한 달이 지나야 비로소 업그레이드를 진짜 완료라고 부릅니다.
수용 기준은 업그레이드 뒤가 아니라 전에 씁니다. 제 기준은 세 개의 엄격한 라인입니다. 핵심 연동 성공률이 업그레이드 전 주 평균 이상일 것, 라벨 인쇄부터 출하 확정까지의 엔드투엔드 흐름에 눈에 띄는 지체가 없을 것, 그리고 첫 주 동안 연동 장애로 인한 수작업 재작업이 제로일 것. 하나라도 놓치면 아직 마무리가 안 된 게 있는 겁니다. 샴페인은 아직 이릅니다.
마지막으로 언급할 만한 트레이드오프가 하나 더 있습니다. 일부 레거시 연동은 또 땜질하는 게 아니라 업그레이드 때 다시 써야 합니다. 역대 수정이 일곱 겹으로 쌓인 미들웨어는 아무도 손대려 하지 않습니다. 업그레이드는 그 기술 부채를 한 번에 갚는 드물고 정당한 핑계입니다. 프로젝트 일정에 2~3주를 더 쓰지만, 숙면을 취할 밤들을 몇 년 치 삽니다. 장기 시야로 계산하세요.
내일 당장 할 수 있는 한 가지. WMS 관리 콘솔에 로그인해서 최근 90일간 호출된 모든 외부 연동을 내보내세요. 보관 중인 연동 문서와 대조합니다. 맞지 않는 것이 다음 업그레이드에서 폭발할 가능성이 가장 높은 지점입니다. 이름을 적어두세요. 그것이 여러분의 호환성 체크리스트 첫 줄입니다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
