피크 시즌 전 WCS 부하 테스트: 과거 웨이브를 풀부하로 돌리는 현장 체크리스트

피크 시즌 한 달 전은 1년 중 가장 바쁜 시기다 — 장비를 설치하느라 바쁜 게 아니라, 창고를 돌며 묻느라 바쁘다: WCS 부하 테스트는 하셨나요? 열 명 중 여덟 명의 매니저가 했다고 한다. 그럼 어떻게 했냐고 묻는다. "평범한 웨이브를 돌렸습니다. 잘 됐어요." 그때마다 안전모를 벗고 싶어진다. 평범한 웨이브는 피크 부하의 일부분에 불과하다 — 아침 조깅으로 단거리 달리기를 평가하는 셈이다.

WCS 부하 테스트는 어렵지 않지만, 열 개 창고 중 아홉 개가 잘못한다. 체크리스트는 이거다.

먼저 분명히: WCS 부하 테스트가 실제로 압박하는 것

자동화를 모르는 독자를 위해 한 문장으로: WCS(Warehouse Control System)는 모든 자동화 장비의 지휘관이다. WMS가 "이 주문들을 출하하라"고 하면, WCS가 그걸 기계어로 번역한다 — 어느 컨베이어가 돌고, 어느 슈트로 박스가 가고, 어느 리프트가 몇 층으로 가는지. PLC는 분대장, WCS는 사령부다.

부하 테스트가 WCS 서버 CPU를 진짜로 압박하는 일은 없다 — 평상시 20%~30%로 놀고 있고, 그걸 풀로 돌리는 건 아무것도 증명하지 못한다. 몸무게만 재는 건강검진이다. 진짜 중요한 건 세 개의 라인이다:

첫째, WCS–WMS 메시지 채널. 피크 때 WMS는 초당 수백 개의 태스크를 WCS에 퍼붓는다. 큐가 소화를 못하면 장비는 놀고 있는데 태스크가 쌓인다 — 사령부 전화가 마비되고 최전선이 기다리는 거다.

둘째, PLC 스캔 사이클 — 신호 읽기, 로직 실행, 명령 전송의 고정 루프로, 보통 몇 밀리초에서 열 몇 밀리초다. 풀부하에서는 신호량이 폭발하고 사이클이 늘어나 장비 움직임이 "반 박자 늦어"지고 박스 간격이 틀어진다: 잼(막힘)은 이렇게 태어난다.

셋째, 네트워크 지터. WCS, PLC, 스캐너, HMI 패널이 전부 하나의 산업 네트워크에 매달려 있다. 피크 때 데이터 홍수가 밀려오면 스위치 포트가 가득 찬다: 패킷 손실, 재전송, 지연. 열받는 건 이 장애가 한가한 날에는 절대 안 나타난다는 거다 — 충분히 몰아붙이지 않는 부하 테스트는 절대 못 찾는다.

셋 중 어느 게 먼저 깨져도 증상은 똑같다: 전부 막힘. 하지만 근본 원인과 처방이 다르다. 그러니 "잘 돌아갔나요"만 묻지 말고 — 각 라인의 데이터를 따로 뽑아라.

작년 웨이브를 시험지로: 체크리스트

어떤 데이터를 쓰냐고? 내 답은 한결같다: 작년 피크의 실제 과거 웨이브를 무편집으로 재생하라. 합성 데이터는 무의식적으로 "그럴듯"해진다 — 그런데 실제 피크 데이터는 절대 그렇지 않다. 한 슈트에 욱여넣은 세 개의 히트 SKU, 출하 웨이브와 충돌하는 반품 웨이브, 한 존의 품절로 강제되는 태스크 재계획. 실제 웨이브 데이터의 말썽꾸러기들은 상상도 못 할 것들이다.

플레이북:

1단계, 목표를 정하라: 작년 피크의 1시간 최대 웨이브 물량 × 1.2. 사업부는 항상 "올해 20% 성장한다"고 한다 — 여유를 넣어라. 1.2배를 못 버티는 시스템은 피크 밤에 폭발한다.

2단계, 테스트 환경을 구축하라: 운영 환경과 격리하되 WCS, PLC 프로그램, 네트워크 토폴로지는 동일하게. "주문이 없을 때" 운영 환경에서 테스트하는 건 대죄다 — 운영을 풀부하로 돌릴 용기는 없잖나.

3단계, 웨이브를 재생하라: 압축된 타임라인으로 WMS 히스토리 인터페이스를 쓴다. 원래 지문을 살려둬라 — 봉우리와 골짜기, SKU 집중도, 예외 비율. 하나도 "예쁘게" 다듬지 마라.

4단계, 세 묶음의 숫자를 지켜봐라 — WCS 큐 깊이와 디스패치 지연, PLC 최대 스캔 사이클, 네트워크 포트 사용률과 패킷 손실. "막혔나"만 보는 건 몸무게만 재는 건강검진이다.

5단계, 충분히 오래 돌려라: 풀부하로 4시간 연속. 많은 장애는 만성이다 — 메모리 누수, 모터 열보호, 벨트 틀어짐 — 2~3시간째까지 안 보인다. 30분은 리허설이지 테스트가 아니다.

2024년 11월, 중국 동부의 의류 이커머스 창고. 그들의 "부하 테스트": 평상시 부하의 70%로 1시간, 그리고 멋진 보고서. 광군제(11월 11일) 새벽 1시, 메인 컨베이어 간선이 막혔다: PLC 스캔 사이클이 늘어져 분류 신호가 반 박자 늦게 도착했고 박스들이 추돌했다. 40명이 넘는 인원이 새벽 6시까지 수작업으로 전환했다. 그들 자체 사후 분석: 그날 밤의 손실로 제대로 된 부하 테스트 스무 번 값을 치를 수 있었다.

반대 사례: 2025년 8월, 블랙프라이데이를 준비하던 미국 서부 3PL은 작년 웨이브를 1.2배로 6시간 연속 재생했다. 4시간째에 진짜 문제가 나왔다: 소터의 슈트 할당 알고리즘이 풀부하에서 성능이 떨어졌다. 평상시에는 SKU가 분산돼 알고리즘이 버티지만, 피크 베스트셀러가 집중되면 같은 슈트에 박스가 쌓이고 꽉 차서야 알람이 운다. 이건 70% 부하에서는 절대 못 잡는다 — 티핑 포인트가 90% 근처에 있다. 가중치를 고치는 데 2주, 블랙프라이데이 밤은 깨끗하게 돌아갔다. 매니저는 그걸 그해 가장 잘 쓴 2주라고 했다.

합격/불합격 라인: 넘지 말아야 할 레드라인

고객에게 건네는 "생사" 표 — 레드라인 하나라도 넘으면 그날 밤은 잠 못 잔다:

사람들은 말한다: "잼 한 번은 정상이죠, 손으로 뚫으면 돼요." 피크 밤 인력 배치는 평범한 웨이브 기준으로 짜여 있다. 풀부하에서 잼 뚫으러 사람을 보내는 건 화재 현장에 도착해서 호스를 찾는 소방관 같은 거다.

부하 테스트가 보통 망가지는 지점

함정 하나: 테스트 환경이 "거의 비슷"하다. 펌웨어 버전 하나 다르고, 스위치 하나 빠지면 모든 결과가 플라시보다. 내가 본 최악: 테스트 환경이 3개월 전 WCS 백업으로 돌고 있었다. 테스트는 깨끗, 대축하 — 그러다 신버전 패치가 메시지 큐 타임아웃을 바꿨고, 가동 밤에 전부 무너졌다. 부하 테스트 전: 운영의 버전 번호를 전부 베껴서 하나씩 대조하라.

함정 둘: 장비는 테스트하는데 사람은 안 한다. WCS 알람, HMI 팝업, 예외 절차 — 피크 밤에는 사람이 그걸 다 클릭한다. 테스트 중에 장애를 주입하라 — 스캐너를 뽑고, 슈트 가득 참을 시뮬레이션하고 — 당직자가 5분 안에 매뉴얼대로 움직일 수 있는지 봐라. 장비는 쇠지만 사람은 굳는다. 새벽 3시 당직은 입사 두 달 된 애일 수 있다.

함정 셋, 가장 직관에 반하는 것: 가장 압박받는 링크가 먼저 깨진다는 보장은 없다. WCS는 소프트웨어다 — 압박 속에서는 "솔직"해서, 느려지거나 에러를 뱉는다. 교활한 건 "믿음직한" 이웃들이다: PLC, 스캐너, 스위치. 스캐너 인식률이 99.9%에서 97%로 떨어지는 건 속도로 보면 3포인트지만, 피크 물량에서는 재앙이다. 스위치 포트 사용률 90%는 한가한 날엔 괜찮지만, 버스트 트래픽에서는 즉시 패킷을 떨어뜨리기 시작한다. 내 트레이드오프 조언: 화력의 70%는 인터페이스와 경계에, 30%는 WCS 자체에 겨눠라. WCS 벤치마크 대회로 만들지 마라 — 벤더 영업사원들은 그걸 좋아하지만, 네 피크 밤에는 아무 소용없다.

한 가지 더 트레이드오프: 장비의 물리적 한계까지 밀어붙일까? 사업 피크의 1.2배에서 멈춰라. 지속 풀부하의 모터는 MTBF(평균 고장 간격)에 타격을 입는다 — 극단적인 한 번을 위해 장비 수명을 태우는 건 푼돈 아끼는 짓이다. 피크의 진짜 적은 절대 피크의 몇 분이 아니었다. 장시간 이어지는 고부하다. 부하 테스트는 지구력 레이스지 단거리가 아니다.

돈값 했는지는 단 하나의 숫자로 귀결된다

모든 대화는 똑같이 끝난다: 환경, 사람, 다운타임 — 값어치를 하는가? 아래 숫자는 가정이다 — 자기 숫자를 넣어라. 진짜인 건 공식이다:

피크가 시간당 1만 주문, 시간당 마진 6만 달러라고 하자. 2시간 잼이 나면 수작업 분류로 효율이 3분의 1 — 1만 4천 주문이 출하 시간을 놓친다. 환불, 악성 리뷰, 플랫폼 페널티, 40명의 잔업 수당: 한 번의 사고로 눈 깜짝할 새 수십만 위안이 탄다.

제대로 된 부하 테스트는? 격리 환경(많은 인테그레이터가 끼워준다)에 2~3명의 일주일 시간 — 수만 위안. 그러니 단 하나의 숫자로 귀결된다: 작년 피크의 1시간 최대 물량을 가져와 1.2를 곱하고, 네 시스템이 그걸 삼킬 수 있는지 물어라. 된다면 건물에서 가장 싼 보험이다. 안 된다면 "아낀" 1위안 1위안이 피크 밤 사고를 위한 크라우드펀딩이다.

피크 한 달 전, "부하 테스트를 해야 할까요" 묻는 건 그만둬라. 과거 웨이브는 준비됐나? 1.2배 목표를 보고서에 쓸 용기는 있나? 있다면 가서 몰아붙여라. 없다면 아직 시간은 있다.

Da Liu, 자동화 엔지니어 지음

영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.