솔직히 말하자면, AS/RS 프로젝트 10건 중 9건은 스태커 크레인이나 랙 정밀도에서 실패하는 게 아닙니다. 무너지는 건 중간 계층, 바로 WCS입니다. 설비는 샀고, WMS는 이미 있습니다. 그런데 둘은 같은 언어를 말하지 못해서 사이에 번역자가 필요합니다. 그 번역자가 엉망이면 AS/RS가 빨리 돌수록 혼란도 빨리 퍼집니다. 이 이야기에는 두 가지 측면이 있습니다. 하나는 기술 통합——메시지를 흐르게 하는 것. 다른 하나는 문제가 생겼을 때 누가 지휘권을 쥐느냐는 것——그리고 진짜로 목숨을 앗아가는 건 이쪽입니다.

결론부터 말씀드리면: WMS는 두뇌, WCS는 소뇌, AS/RS는 손과 발입니다. 통합이란 "연결"하는 게 아닙니다——"재고의 진실"과 "작업 상태"의 의미에 세 계층이 합의하는 것입니다. 합의하지 못하면 매끄럽게 흐르는 메시지는 시한폭탄에 불과합니다.

AS/RS와 WMS가 실제로 "대화하는" 방식: 3계층 역할 분담

먼저 역할 분담을 명확히 합시다:

계층 담당 입력 출력 고전적인 고장 모드
WMS(두뇌) 업무 작업: 어떤 주문을 먼저 피킹할지, 어떤 보충을 먼저 돌릴지, 웨이브를 언제 해제할지 주문, 웨이브 전략 작업 지시: 작업 ID, 파렛트 ID, 출발·도착 스테이션, 우선순위 작업은 나가는데 설비 쪽에서는 아무 일도 안 일어남
WCS(소뇌) 설비 동작: 업무 작업을 크레인 지시로 번역 WMS의 작업 지시 구체적인 동작 명령: 통로, 스테이션, 파렛트 ID 조용히 죽고, 작업이 쌓임
AS/RS(손) 실행과 확인 응답 WCS의 동작 명령 결과: 성공, 실패, 실패 사유 코드 피킹이 실패했는데 사유를 읽을 사람이 없음

왕복 흐름: WMS가 작업을 발행합니다——작업 ID, 파렛트 ID(또는 LPN), 출발·도착 스테이션, 우선순위. WCS는 이를 큐에 넣고 설비에 할당합니다. 설비가 완료되면 WCS가 결과를 돌려줍니다: 성공, 실패, 사유 코드. 대부분의 문제를 일으키는 세 가지 디테일이 있습니다. 첫째, 타임아웃 시 재시도 소유권은 반드시 어느 한쪽——양쪽도, 어느 쪽도 안 됩니다. 둘째, 같은 작업 ID는 멱등성을 가져야 합니다——네트워크가 끊기고 메시지가 두 번 나가도 크레인이 두 번 실행하면 안 됩니다. 셋째, WMS의 장부 재고와 WCS의 실물 재고는 같은 정의를 써야 합니다——WMS가 "재고 있음"이라고 부르는 파렛트는 WCS가 실제로 찾을 수 있어야 합니다. 이 세 가지는 통합 테스트 시작 전에 문서로 확정합니다.

선정 단계에 묻혀 있는 지뢰가 하나 있습니다: 재고의 진실은 누구 것인가? WMS는 "내가 장부다, 장부가 옳다"고 말합니다. WCS는 "내가 실물을 쥐고 있다, 실물이 옳다"고 말합니다. 가장 흔한 다툼은 "이송 중" 상태——이미 랙에서 꺼내져 컨베이어 위를 이동 중인 파렛트를 두고 벌어집니다. WCS는 "보관 중 아님"으로 봅니다. WMS는 "재고 있음·할당 가능"으로 계속 봅니다. 그러다 긴급 주문이 들어오면 WMS가 그 파렛트를 다른 작업에 할당하고, 크레인이 스테이션으로 가서 헛손질을 합니다. 이 정의를 고라이브 전에 확정하지 않으면 매일 다투게 됩니다. 제 입장은 간단합니다: 물리적 현실이 이깁니다. WMS의 "재고 있음·할당 가능"은 WCS의 이송 중 수량을 제외해야 합니다. 인터페이스 계약서에 쓰고 논쟁은 끝입니다.

통합 테스트가 해피 패스만 커버하는 프로젝트를 저는 너무 많이 봤습니다: 작업 발행, 설비 실행, 확인 성공, 모두 박수. 그리고 고라이브 첫 주부터 교훈이 시작됩니다.

너무 많이 봐 온 고전적인 참사 3가지

참사 하나: WCS가 죽었는데 WMS는 계속 작업을 발행한다. 한 사업장의 성수기 전 통합 중 한밤중에 WCS 서버가 약 10분간 재시작했습니다. WMS는 눈치채지 못하고 수백 건의 작업을 계속 발행했습니다. WCS가 복귀하자 쌓인 작업이 한꺼번에 설비로 밀려들고 순서는 무너졌습니다——일상 보충 작업 뒤에 긴급 주문이 묻혔습니다. 작업 큐 정리에 낮 근무 하루가 통째로 들었습니다. 사후 분석에서 찾은 근본 원인: 하트비트 간격이 너무 길게 설정되어 완전한 재시작이 감지되지 않은 것입니다.

참사 둘: 재고 대사의 정의가 전쟁 상태. WMS 장부는 파렛트가 AS/RS A존에 있다고 했습니다. WCS는 그것이 일주일 전에 비정상적으로 수작업 구역으로 내려왔고, 복귀 메시지가 네트워크 흔들림에서 사라졌다고 했습니다. 그래서 시스템은 "재고 있음", 설비는 "없음"이라고 하고, 피킹 작업은 스테이션에서 아무것도 기다리지 못한 채 기다렸습니다. 더 나쁜 점: 이런 장부와 실물의 괴리는 수작업 사이클 카운트로는 쫓을 수 없습니다——AS/RS의 하루 파렛트 처리량을 세는 데 수작업으로 한 달이 걸립니다. 결국 WCS 실물 스냅샷과 WMS 장부를 파렛트 단위로 대조하며, 잃어버린 파렛트가 하나도 남지 않을 때까지 계속했습니다.

참사 셋: 아무도 처리하지 않는 예외 확인. 크레인이 "피킹 실패"를 보고합니다. WCS는 이를 범용 오류 코드로 바꿔 WMS에 던집니다. WMS 인터페이스 프로그램은 코드를 인식하지 못하고 버립니다. 작업은 성공도 실패도 아닙니다——그냥 붕 뜹니다. 오퍼레이터는 오지 않는 상품을 기다리며 화면을 쳐다보고, IT를 부르면 IT는 시스템에 "발행됨"으로 표시된다고 합니다. 세 당사자가 서로 쳐다보기만 합니다. 근본 원인은 어이없을 정도였습니다: 오류 코드 표를 인테그레이터가 대충 정의했고, WMS 측은 한 번도 매핑하지 않은 것입니다.

상식에 반하는 관점 하나: 자동화될수록 다운그레이드 계획에 대한 의존도는 커집니다. AS/RS면 안심하고 잔다고 생각하는 사람이 있습니다. 반대입니다——AS/RS의 가장 큰 리스크는 설비 고장이 아니라 설비가 고장 나지 않았다고 시스템이 믿는 것입니다. 고장 난 크레인은 보입니다. 잃어버린 메시지는 보이지 않습니다.

대부분이 놓치는 디테일 하나 더: 작업 우선순위. WMS의 "긴급 주문 우선"은 WCS 계층에서 번역되면서 단순한 새치기가 됩니다——실행 중인 작업은 계속 중단되고, 크레인 공주행률이 치솟습니다. 긴급 주문은 빨라지고 전체 처리량은 나빠집니다. 우선순위 전략은 두 계층에서 함께 설계해야 합니다: WMS가 업무 우선순위를 정하고, WCS가 실행 배치를 정하고, 각자 자기 영역을 지킵니다. WMS가 설비를 직접 지휘하는 프로젝트는 전부 혼란으로 끝납니다.

AS/RS와 WMS가 계속 대화하게 하는 4가지 철칙

첫째, 인터페이스 계약이 무엇보다 먼저. 통합 테스트 전에 작업 상태 기계를 맞춥니다: 발행됨, 실행 중, 성공, 실패, 예외 보류——다섯 개 상태, 하나도 빠지면 안 됩니다. 누가 어떤 전이를 할 수 있는지, 어느 정도 타임아웃이 실패인지——문서로. 재시도 소유권은 반드시 어느 한쪽. 멱등 키는 체인 전체를 흘러야 합니다. 오류 코드 표는 양쪽에서 한 줄씩 매핑해야 합니다——"범용 오류" 같은 코드의 존재는 허용되지 않습니다.

둘째, 다운그레이드 계획. WCS가 죽으면 어떻게 됩니까? WMS는 발행을 즉시 멈출 수 있어야 하고, 진행 중인 작업은 목록으로 내보내 수작업으로 처리할 수 있어야 합니다. 다운그레이드는 "IT가 고치길 기다린다"가 아닙니다——실제로 리허설한 전환 절차입니다. 한 번도 리허설하지 않은 계획은 계획이 아닙니다. 제 고객 인수 기준에는 항상 한 줄이 들어갑니다: WCS를 10분간 끊어라. 복구 후 작업과 재고는 맞아떨어져야 한다. 안 맞으면 최종 대금을 보류한다.

셋째, 대사. 매 시프트마다 WMS와 WCS는 대사합니다: 장부 재고와 물리 로케이션 대조. 차이는 장부를 손으로 고쳐서 맞추지 않습니다——예외 프로세스를 통합니다: 파렛트가 어디로 갔는지, 메시지가 어디서 사라졌는지 찾고, 그다음 조정합니다. 장부는 틀려도 되지만, 흔적을 남기며 틀려야 합니다. 손으로 고치면 순간은 시원합니다. 대사 시간에는 창고 전체가 웁니다.

넷째, 통합 체크리스트. 메시지 스트레스 테스트, 네트워크 장애 훈련, 각 오류 코드의 전체 커버리지 테스트——어느 것도 선택이 아닙니다. 특히 장애 훈련: WCS와 WMS 사이의 네트워크 케이블을 10분간 뽑고, 복구 후 작업과 재고가 여전히 맞는지 확인합니다. 맞으면 그 프로젝트는 진짜로 연결된 것입니다. "통합 테스트 중에는 다 잘 됐는데"로 죽는 프로젝트가 너무 많습니다——통합 테스트 중에 네트워크가 안정적이었던 건 당연합니다. "불안정하다"가 어떤 것인지 본 적이 없을 뿐입니다.

지금 공급업체를 고르고 있는 분들께, 계약 전 인테그레이터에게 물어볼 세 가지 질문: 하나, WCS가 죽었을 때 WMS가 발행을 자동 중단할 수 있고, 진행 중인 작업 목록을 클릭 한 번으로 내보낼 수 있습니까? 둘, 오류 코드 표가 WMS에 한 줄씩 매핑되어 있습니까, 아니면 아무도 책임지지 않는 모호한 코드가 있습니까? 셋, 시프트 단위 장부·실물 대사가 자동으로 돕니까, 아니면 누군가 기억하는 데 의존합니까? 세 가지 중 하나라도 답하지 못하면 구현은 추가 비용이 듭니다——아마가 아니라, 확실합니다.

다음에 인테그레이터가 "인터페이스는 다 연결되었습니다"라고 하면 한 가지 질문하세요: WCS가 네트워크를 10분간 잃어도 재고는 맞습니까?

Lao Mi, 공급망 베테랑(20년) 지음

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