결론부터 말하겠습니다. 신규 창고 오픈에서 연동 테스트 시간은 절대 충분하지 않습니다. 유일한 질문은 그 시간을 고라이브 전에 쓰느냐, 아니면 고라이브 후에 쓰느냐입니다. 후에 쓴다는 건 고객센터 전화가 불이 나도록 걸려오는 가운데 쓴다는 뜻입니다. 저는 슬롯 배치 설계와 설비 시운전에 활주로의 80%를 쓰고 연동에는 일주일만 남긴 프로젝트를 너무 많이 봤습니다. 그러면 오픈 당일 WMS 업체, 운송사, 마켓플레이스는 서로 책임을 떠넘기고, 수백 개의 소포가 운송장 라벨 없이 포장 스테이션에 쌓입니다.
샌드박스는 소품이 아니다: 테스트 전에 환경을 먼저 정렬하라
2024년, 저는 고라이브 일주일 전 연동 테스트를 점검하기 위해 캘리포니아 온타리오에 있는 120,000평방피트 규모의 그린필드(신규 부지) 창고에 들어갔습니다. 샌드박스는 멋져 보였습니다. 주문이 들어가면 라벨이 나오고 출고가 확정되는, 경영진 앞에서 완벽한 데모였습니다. 오픈 당일은 다른 이야기가 펼쳐졌습니다. 샌드박스의 라벨 템플릿은 프로덕션에 설정된 것과 동일한 것이 아니었습니다. 프로덕션 템플릿에는 추적번호 필드에 여분의 체크디짓(검증 숫자) 규칙이 들어 있었습니다. 라벨은 인쇄됐지만 스캐너는 거부했고, 소포가 분류기 투입구에 쌓이면서 30분 동안 라인 전체가 멈춰 섰습니다.
교훈은 지루하고 구체적입니다. 샌드박스와 프로덕션 설정은 항목별로 일치해야 합니다. 라벨 템플릿, 프린터 모델과 드라이버, 운송사 계정, 서버 시간대입니다. 특히 운송사 계정에 주목하세요. 테스트 인증 정보와 프로덕션 인증 정보는 권한이 다른 경우가 잦습니다. 요금 비교와 라벨 인쇄는 가능하지만 추적 이벤트는 조회할 수 없는 테스트 계정을 본 적이 있습니다. 그 결과 추적 웹훅 경로는 오픈 당일까지 단 한 번도 테스트되지 않았습니다. 모든 불일치는 오픈 당일의 사고로 대기 중입니다. 테스트 시작 전에 샌드박스 대 프로덕션의 2열 체크리스트를 만들고, 모든 행에 체크될 때까지 시작하지 마세요.
샌드박스에 대해 한 가지 더. 장난감 같은 데이터가 아니라 프로덕션 모양의 데이터를 심으세요. 각각 1개씩인 5개 SKU로는 아무것도 드러나지 않습니다. 수천 개의 SKU, 실제 용적 중량, 실제로 사용할 운송사 서비스 코드, 아파트 동호수, 사서함, 가끔의 오타가 들어간 주소를 로드하세요. 제가 본 연동 버그 대부분은 로직 오류가 아니라 데이터 형태 오류였습니다. 장난감 데이터는 그 모든 것을 숨깁니다.
그리고 테스트 첫날에는 세 당사자 모두에게 실행 중인 API 버전을 적게 하세요. 운송사 API 문서는 1년에 서너 번 개정되고, 필드는 예고 없이 바뀌며, 샌드박스에서 테스트한 버전이 프로덕션에서 돌아가는 버전과 다를 수 있습니다. 저는 킥오프 회의에서 모든 사람이 프로덕션 버전 번호를 서면으로 확인하게 합니다. 나중에 책임 떠넘기기 일주일을 아껴줍니다.
해피 패스가 아닌, 지저분한 케이스를 테스트하라
정상 주문은 누구나 테스트합니다. 당신을 죽이는 건 예외 주문입니다. 그러니 테스트 계획은 예외를 중심으로 세우세요. 주소 누락이나 형식 오류, 과중량·과대 소포, 존재하지 않는 SKU, 마이너스 재고, 피킹 시작 후 취소, 여러 카톤으로 분할되는 하나의 주문, 하나로 합쳐지는 여러 주문입니다. 각각 최소 세 번씩 실행하고, 세 시스템(WMS, 마켓플레이스, 운송사) 모두에서 주문 상태가 일치하는지 확인하세요. 전형적인 실패는 삼자간 불일치입니다. 마켓플레이스는 '출고됨', WMS는 여전히 '피킹 대기', 고객센터 팀은 분노한 이메일로 처음 알게 됩니다.
ERP도 잊지 마세요. 구매 발주 입고 흐름(ASN 수신, 입고 전기, 재고 스냅샷 역동기화)은 별도의 테스트 패스를 받을 자격이 있습니다. 만년 단골은 기초 재고 대 기말 재고 불일치입니다. ERP는 500개를 받았다고 생각하는데 WMS는 480개를 세었고, 월말 마감이 법의학적 작업이 되기까지 아무도 정합하지 않습니다. 샌드박스에서 입고부터 실사까지 전체 사이클을 돌리고, 오픈 '후'가 아니라 '전'에 숫자를 정합하세요.
거의 매번 건너뛰는 카테고리가 두 가지 있습니다. 첫째, 피크 물량 주문입니다. 블랙프라이데이 일주일 전에 하루 20,000건의 주문을 스크립트로 샌드박스에 밀어 넣고, 속도 제한과 메시지 큐가 버티는지 지켜보세요. 테스트에서는 초당 10건이 멀쩡해 보이지만, 피크 때 초당 200건은 준비되지 않은 API를 납작하게 만듭니다. 저는 한두 번 본 게 아닙니다. 둘째, 반품입니다. 열 곳 중 아홉 곳의 그린필드 사이트는 오픈 전 샌드박스로 완전한 반품을 한 번도 돌리지 않으며, 반품 경로는 완전히 별개의 체인입니다. 마켓플레이스 반품 승인, WMS 입고, 검수, 적치(풋어웨이), 재고의 마켓플레이스 역기입입니다. 어느 한 링크라도 깨지면 반품은 공중에 멈춥니다. 오픈 후 첫 일주일의 반품이 테스트하지 않은 모든 틈을 폭로할 것입니다.
테스트의 매일은 정합으로 마무리하세요. 세 시스템(마켓플레이스, WMS, 운송사)에서 주문 상태를 내보내고, 같은 주문번호 배치가 모든 곳에서 일관된 상태를 보이는지 확인합니다. 정합 스크립트는 첫날 작성하고 자동으로 실행하세요. 눈으로 훑어보지 마세요. 모든 불일치는 내일의 최우선 버그입니다.
전환일: 앞으로 나아가는 계획보다, 되돌아가는 계획을 먼저 세워라
오픈 전에 롤백 기준선을 서면으로 정의하세요. 전환 후 2시간 이내에 출고 정확도가 설정된 하한선 아래로 떨어지거나, API 오류율이 임계값을 넘으면, 즉시 레거시 시스템이나 수동 주문으로 되돌립니다. 상황실 벽에 붙여 놓으세요. '상황 봐서' 같은 식으로 두지 마세요. 그 순간에는 그 판단을 내릴 여유가 아무에게도 없습니다. 미리 써 놓은 규칙을 실행할 수 있을 뿐입니다.
전환일에는 구 시스템을 따뜻하게 유지하세요. 구 시스템과 신 시스템을 반나절에서 하루 종일 병행 운영합니다. 주문은 양쪽으로 흐르고, 출고는 구 시스템에서 나가며, 신 시스템은 섀도 검증을 돕니다. 구체적으로는, 신 시스템이 인쇄하는 첫 50장의 라벨을 구 시스템 출력과 한 줄씩 비교하는 것입니다. 주소, 서비스 등급, 추적번호입니다. 실제 물량을 맡기기 전에요. 병행 운영은 하루 동안 인력을 두 배로 씁니다. 이를 건너뛰는 것은 오픈 당일의 수천 건 주문을 희망에 거는 것입니다. 나쁜 거래입니다.
그리고 야간 근무 인원을 배치하세요. 연동 장애는 전환 후 첫 심야 시간대에 집중됩니다. 개발, 창고 감독자, 고객센터 각각에 현장 또는 대기 인원을 한 명씩 두고, 하나의 그룹 채팅에 모아 연락처를 고정하세요. 장애가 난 뒤에 사람을 찾아 전화를 돌리기 시작하지 마세요.
당신의 샌드박스가 완전한 반품(마켓플레이스 반품 개시, WMS 입고, 검수, 적치, 재고 역기입)을 엔드투엔드로 돌린 게 언제였습니까? 날짜를 댈 수 없으면 전환을 일주일 미루세요. 연동 테스트에 '대충 됐다'는 없습니다. 프로덕션은 당신이 손댄 모든 모서리를 오픈 당일 하나씩 찾아낼 것입니다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
