질문 하나: 새벽 2 a.m.에 머지에서 소포가 걸리고, 스캐너가 판독을 놓치기 시작하고, 누군가 비상정지 버튼을 눌렀다――이 모든 게 같은 한 시간 안에 일어난다면, 여러분의 WCS는 어떻게 반응할까요? 솔직한 답이 "본가동 당일에 알게 될 겁니다"라면 계속 읽으세요. 저는 그날 그 건물에 있었습니다. 수십 명의 사람들이 그냥… 멈춰 버린 컨베이어를 멍하니 바라보고 있었습니다. WCS는 한 가지를 말하고, WMS는 다른 것을 말했고, 프로젝트 매니저의 얼굴이 모든 걸 말해 주었습니다.
그 재앙들 중 거의 대부분은 피할 수 있었습니다. 이 방법에는 화려하지 않은 이름이 있습니다――가상 시운전. 말 그대로입니다: 철골이 올라가기 전에, 실제 WCS가 설비가 이미 존재한다고 믿게 만들고, 가혹하게 돌립니다. 주문을 돌리고, 고장을 내고, 로직을 고칩니다. 가상 환경에서 깨뜨리는 건 공짜입니다. 현장에서 깨뜨리면 매 분마다 돈이 나갑니다.
실제로 테스트하는 것
한 문장으로: 소프트웨어가 컨베이어와 소터 시스템 전체를 모델링하고, 실제 WCS가 연결되어 돌립니다. 시뮬레이션은 설계대로 라인을 구축합니다――길이, 다이버트 슈트 개수, 스캐너 위치, 리젝트 레인 위치. 그리고 WCS는 현장에서처럼 정확히 명령을 내립니다. 모델은 물리에 따라 응답합니다: 소포 무게, 벨트 속도, 흐름이 밀릴 때 일어나는 일.
사람들이 계속 헷갈리는 구분이 있습니다: 시뮬레이션은 가상 위의 가상으로, 프로세스 로직 검증에 유용합니다. 에뮬레이션은 실제 WCS가 가상 설비를 구동하는 것으로, 바로 이것이 제어 로직을 검증합니다. 본가동 전에는 에뮬레이션이 필요합니다――그리고 테스트 대상 WCS는 본가동에 나갈 것과 정확히 같은 빌드여야 하며, 코드 한 줄도 달라서는 안 됩니다. 데모 빌드에서 그린 테스트를 받은 뒤 본가동 빌드로 교체하는 건 낭비입니다.
저는 에뮬레이션 환경이 설비 출하 후가 아니라 공장 인수 테스트 단계에서 구축되어야 한다고 주장합니다. 현장에서 철골이 올라가기 시작하면 일정 압박이 시운전을 계획의 3분의 1로 압축하고, 해결되지 않은 모든 문제는 본가동 당일까지 따라옵니다. 공장에서는 로직이 틀리면 엔지니어가 홈그라운드에서 PLC 코드나 WCS 로직을 고칩니다. 현장에서는 크레인, 비계, 안전 담당자에게 둘러싸여 그걸 해야 합니다――코드 한 줄을 바꾸는 심리적 비용이 완전히 다릅니다.
고장 주입: 일부러 최악의 경우로 테스트하세요
깨끗한 주문 만 개보다 추한 주문 백 개에서 더 많이 배웁니다. 가상 시운전의 가장 큰 가치는 결과 없는 파괴 공작입니다. 가동 중인 소터를 일부러 걸리게 하시겠습니까? 가상 세계에서는 하루 종일 걸리게 하고 클릭 한 번으로 리셋하면 됩니다.
제 필수 고장 목록은 이렇습니다. 걸림: 다이버트 슈트, 경사면, 머지를――한 번에 하나씩――막고, WCS가 얼마나 빨리 감지하는지, 알람이 정확한지, 복구 시퀀스가 실제로 작동하는지 봅니다. 스캔 실패: 연속 노리드, 손상된 바코드, 똑같이 생긴 소포 두 개 연속――리젝트 로직이 문제 소포를 깨끗이 배출하는지, 아니면 영원히 재순환시키는지? 영원히 재순환하는 불량품은 가장 멍청한 고장 모드입니다. 불량품 하나가 라인 전체 처리량을 끌어내릴 수 있습니다. 비상정지: 무작위 순간에 누릅니다――정지 시퀀스가 맞는지, 복구 시 주문 상태가 보존되는지, 벨트 구간에 소포가 "잊혀진" 채 있지 않은지? 네트워크 단절: WCS–WMS 링크를 몇 분간 끊습니다――메시지가 유실되는지 큐에 쌓이는지, 두 시스템이 이후에 정합되는지?
각 고장 카테고리 후에는 벤더에게 세 가지를 요구합니다: 그 시점의 시스템 로그, WCS 알람 기록, 복구에 걸린 시간. 이게 본가동 트러블슈팅을 위한 진료 차트입니다. 이런 차트가 없는 프로젝트는 뭔가 고장 날 때마다 처음부터 다시 진단합니다――추측 한 번당 30분의 다운타임입니다.
WCS–WMS 인터페이스가 프로젝트를 죽이는 곳입니다
자동화 실패의 절반은 설비입니다. 나머지 절반은 인터페이스입니다. WCS는 기계를 움직이고, WMS는 주문과 재고를 소유하며, 메시지로 정합합니다. 인터페이스가 거짓말을 하면 현장도 같이 거짓말을 합니다: WMS는 주문을 보냈다고 생각하고, WCS는 절대 도착하지 않았다고 말합니다. 분류는 끝났는데 재고는 절대 차감되지 않습니다. 네트워크가 한순간 끊기면 양쪽이 각자 장부를 유지합니다.
인터페이스는 최악의 경우로, 세 부분으로 테스트합니다. 첫째, 메시지 정합: 배치 실행 후 주문 상태, 피스 수, 분류 결과를 두 시스템 간에 한 줄씩 맞춥니다. 단 한 줄도 달라서는 안 됩니다――그리고 주의: 합계가 아니라 한 줄씩입니다. 행이 뒤섞였는데 합계만 맞는 건 더 나쁘고 더 교활한 문제입니다. 둘째, 하트비트와 재연결: 네트워크 지터를 시뮬레이션하고 재연결 시 유실된 메시지가 있는지, 재시도로 이중 분류가 발생하는지 봅니다. 이중 분류는 가장 비싼 인터페이스 버그입니다: 한 주문이 두 번 분류되고, 고객은 소포를 두 개 받고, 반품과 고객 서비스 비용이 즉시 따라옵니다. 셋째, 엣지 케이스 주문: 초대형, 과중량, 다중 피스, 진행 중 취소――WMS가 반드시 보낼 "이상한 주문"입니다. 정상 주문은 어디서든 돕니다. 이상한 주문이 진짜 테스트입니다.
인수 기준은 계약서에 들어가야 합니다
가상 시운전은 "돌아가니까 출하하자"가 아닙니다. 인수 기준은 서명할 때 계약서에 넣습니다. 제 기준은 세 줄이고, 세 개 다 없으면 서명하지 않습니다.
첫째, 무인 연속 가동. 설계 처리량으로 인간 개입 없이 에뮬레이션을 돌립니다――저는 최소 8시간을 요구합니다. 이건 속이기 가장 쉬운 조항입니다: 벤더들은 오퍼레이터가 어슬렁거리며 구출 준비를 하는 "연속 가동"을 좋아합니다. 그건 무인이 아닙니다. 제 규칙: 테스트 중 오퍼레이터는 봐도 되지만 만지면 안 됩니다. 한 번 만지면 시계가 리셋됩니다. 가혹합니까? 물론이죠. 본가동 당일에는 리셋이 없고, 성수기 주문은 여러분을 기다려 주지 않습니다.
둘째, 분류 정확도. 잘못된 슈트, 놓친 다이버트, 배출되지 않은 예외――모두 오류로 셉니다. 허용률은 숫자로 계약서에 넣고, 비즈니스 허용 한도에 맞게 정합니다. "최대한 정확하게"는 표준이 아닙니다. 숫자가 없는 표준은 표준이 아닙니다.
셋째, 고장 복구 시간. 걸림 알람부터 정상 가동 복귀까지의 최대 허용 시간――초과하면 탈락입니다. 이 조항은 운영팀을 위한 것입니다: 본가동 후 새벽 2 a.m.에 알람이 울리면 당직자는 이게 얼마나 걸려야 하는지, 언제 에스컬레이션해야 하는지를 알아야 합니다. 가상 시운전에서 측정한 복구 시간은 그 조항의 근거가 됩니다.
가상 시운전은 보통 전체 프로젝트 시간의 5~10%를 씁니다. 비용으로 보이지만, 사실 지금까지 구매한 가장 저렴한 리스크 헤지입니다. 현장 시운전 하루――인건비, 양중, 멈춘 라인――로 수십만 건의 가상 주문을 삽니다. 이걸 기억하세요: 가상 환경에서 저지르지 않은 모든 실수는 본가동 당일에 이자 붙어서 돌아옵니다.
마지막 질문입니다: 가상 시운전은 벤더의 아이디어였나요, 아니면 여러분이 요구했나요? 벤더의 아이디어였다면――축하합니다. 올바른 공급업체를 선택하셨습니다. 여러분의 요구였다면――지금 당장 요청하세요. 철골이 아직 올라가지 않았다면 아직 시간은 있습니다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
