결론부터 말하자면, AMR–WMS 통합에서 API를 작성하는 일은 전체 작업의 약 20%에 불과합니다. 나머지 80%는 운송 작업을 누가 생성하고, 차량 상태를 어느 계층이 받아갈지를 결정하는 일입니다.
저는 30회 이상의 WMS 가동을 리드했고, 그중 9건은 AMR 프로젝트였습니다. 그대로 복사해 쓸 수 있는 선정 규칙을 드립니다. 단일 벤더의 로봇이 10대 미만이면 WMS가 직접 구동하게 하세요. 10~50대, 단일 벤더라면 벤더의 RCS(로봇 제어 시스템)를 중간에 두세요. 50대 초과, 또는 혼합 벤더 플릿이라면 태스크 풀 계층을 구축하세요. 현장의 경험칙이지 표준은 아닙니다.
왜 "누가 작업을 만들고, 누가 상태를 받는가"로 귀결될까요? WMS는 비즈니스의 언어를 씁니다 — 어떤 주문, 어떤 로케이션, 어떤 화물인지. RCS는 차량의 언어를 씁니다 — 어떤 로봇이 비어 있는지, 어떤 통로가 막혔는지, 어떤 배터리가 다 되어 가는지. 통합은 둘 사이의 번역입니다. 잘못 번역하면 화물이 엉뚱한 곳으로 갑니다.
AMR–WMS 통합 세 가지 패턴 나란히 비교
| WMS 직접 구동 | RCS 중간 삽입 | 태스크 풀 방식 | |
|---|---|---|---|
| 작업을 누가 만드는가 | WMS가 각 로봇에 직접 작업 전송 | WMS가 업무 작업 전송, RCS가 차량 이동으로 분해 | 독립 오케스트레이션 서비스가 전부 배차 |
| 플릿 로직 담당 | WMS, 단순 규칙으로 | RCS 담당(경로 계획, 장애물 회피, 충전) | 태스크 풀 + 각 벤더 RCS |
| 상태 피드백 | 로봇 → WMS, 거친 입도 | 합의된 상태 세트로 RCS → WMS | 태스크 풀 집계 후 WMS에 보고 |
| 적합한 규모 | 10대 미만 | 10~50대, 단일 벤더 | 50대 이상, 또는 혼합 벤더 |
| 통합 공수 | 작음 | 중간 | 큼 |
| 최대 함정 | WMS는 차량을 모른다 — 교착 상태 | 상태 매핑 불일치 | 태스크 풀이 새로운 단일 장애점이 됨 |
| 표준 기간(현장 경험) | 2~4주 | 6~10주 | 3~6개월 |
패턴 1: WMS 직접 구동 — 인터페이스는 최소, 규모가 커지면 깨진다
동작 방식: WMS가 운송 작업(A에서 B로)을 각 로봇에 직접 할당하고, 로봇이 "완료"를 보고합니다.
어울리는 현장: 10대 미만의 고정 경로 파일럿 — 예컨대 입고에서 보관으로 두 개 레인에 풀 파렛을 옮기는 식입니다.
깨지는 현장: WMS는 로봇이 어디에 있는지, 배터리 잔량은 어떤지, 앞 통로가 막혔는지를 모릅니다. 2023년, 쑤저우의 한 3C 액세서리 창고 — 12,000제곱미터, 리프트형 AMR 18대가 레거시 WMS에 직결. 가동 2주차에 WMS가 40건이 넘는 작업을 한 번에 쏟아냈고, 6대 로봇이 통로 입구에서 엉켜 직원이 손으로 풀어내는 데 30분이 걸렸습니다. 더 교묘한 버그: WMS 작업에 작업 유형 필드가 없어 로봇이 입고와 보충을 구분하지 못했습니다 — 보충 파렛이 출고 도크로 가버렸습니다.
해결책: 중간에 얇은 작업 큐 서비스를 넣었습니다 — WMS는 작업을 던져 넣고, 서비스가 로봇 가용성·배터리·위치에 따라 배정합니다. 대가: 가동이 6주 지연됐습니다.
이 실패를 세 번 봤습니다. 직접 구동이 틀린 건 아닙니다 — 플릿이 작고, 경로가 단순하고, 작업 구성이 균일할 때만 안전할 뿐입니다.
패턴 2: 중간에 RCS — AMR–WMS 통합의 현재 주류
동작 방식: WMS는 업무 작업만 발행합니다("파렛 P123을 로케이션 A-01-02에서 도크 D3으로 이동"). RCS가 이를 차량 이동으로 분해하고, 로봇을 배정하고, 경로를 계획하고, 충전을 관리합니다. 상태는 합의된 계약에 따라 RCS에서 WMS로 돌아옵니다.
10~50대 단일 벤더라면 현재 가장 안정적인 선택입니다. WMS는 차량을 이해할 필요가 없고, RCS는 비즈니스를 이해할 필요가 없습니다.
하지만 거의 모두가 빠지는 함정이 있습니다. 상태 매핑입니다. 2024년, 광저우 난사의 한 크로스보더 이커머스 창고 — 포크형 AMR 32대, 2개 벤더, 2개 RCS 인스턴스, 위에 WMS 하나. 벤더 A의 RCS는 작업 상태를 세 가지만 보고했고(실행 중, 완료, 오류), 벤더 B는 아홉 가지였습니다. 벤더 A의 "일시정지"가 "완료"로 번역됐습니다 — 파렛이 아직 건물 중간에 있는데 WMS는 이미 입고 완료로 장부에 올렸습니다. 60파렛이 넘는 차이, 사이클 카운팅으로 하루 종일 맞췄습니다.
해결책: 통일 상태 매핑표입니다. 벤더 RCS가 어떤 상태를 내놓든 WMS에 닿기 전에 여덟 가지 표준 상태 — 대기, 실행 중, 일시정지, 오류, 완료, 취소, 타임아웃, 수동 개입 — 로 축소되어야 합니다. 표의 소유권은 WMS 팀, RCS 벤더는 준수, 계약 부속서로 들어갑니다. 이 실패를 세 번 봤습니다. 세 번째에는 서명 전에 계약에 써넣었습니다.
패턴 3: 태스크 풀 — 대규모·혼합 플릿을 위한 중장비
동작 방식: 독립적인 작업 오케스트레이션 서비스(태스크 풀)가 WMS와 각 벤더 RCS 사이에 앉습니다. WMS는 업무 작업을 던져 넣고, 풀이 벤더를 가로질러 배정해 전역 최적 배차를 수행하며, 상태는 풀이 집계한 뒤 WMS로 돌아옵니다.
어울리는 현장: 50대 이상, 또는 혼합 벤더 플릿을 확정한 창고입니다. 보상: 나중에 AMR 벤더를 바꿀 때 WMS는 건드리지 않고 풀의 드라이버만 바꾸면 됩니다.
대가: 태스크 풀 자체가 누군가 유지보수해야 할 새로운 시스템이자 단일 장애점입니다. 다운되면 현장 전체가 멈추므로 고가용성이 필요합니다. 통합과 테스트는 제 경험상 3~6개월이 걸립니다.
반직관적 진실: 개발은 절대 비싼 부분이 아니다
반직관적인 결론입니다. AMR 통합 프로젝트에서 API 개발은 보통 전체 공수의 5분의 1 정도입니다. 예산을 태우는 건 통합 테스트에서 비즈니스 로직이 맞지 않는다는 걸 발견하는 일입니다. 예: WMS는 "작업 완료"를 "화물 도착"으로 정의하고, RCS는 "로봇 도착"으로 정의합니다. 로봇이 도착해 완료를 보고하고, 화물은 아직 등에 얹힌 채입니다. 장부가 틀어집니다.
이런 문제는 요구사항 단계에서 질문 하나를 더하면 사라집니다. 통합 테스트 시점에 발견되면 WMS 팀, RCS 벤더, 현장 팀의 삼자 공방이 몇 주간 이어집니다. 제 방식: 계약서에 서명하기 전에 "완료"의 정의를 부속서에 넣고 양측이 서명합니다. 앞당긴 어색한 대화가 가동 전날의 고함보다 낫습니다.
사람들이 잊는 게 하나 더 있습니다. 충전 작업은 누가 발행할까요? RCS이지 WMS가 아닙니다 — WMS는 어떤 충전기가 차 있는지를 모릅니다. 한 프로젝트에서는 WMS가 배터리 부족 로봇을 스케줄에 따라 충전으로 보냈습니다 — 8대 로봇이 4대 충전기 앞에서 줄을 서는 동안 작업들이 타임아웃됐습니다. 충전은 RCS가 맡고, WMS는 타임아웃 알림만 받으면 됩니다.
가동 전날 체크리스트: 항목마다 체크
작업 배차:
- 모든 작업에 전역 고유 ID를 부여하고, 동일 ID의 재배차는 멱등이어야 합니다(정확히 한 번만 실행).
- 모든 작업에 작업 유형(입고 / 보충 / 출고 / 이동)을 부여합니다. RCS의 추측은 금지.
- 작업 타임아웃 값은 양측 합의로 정합니다. 타임아웃 시 WMS는 취소할 수 있고 RCS는 따라야 합니다.
- 로봇이 화물을 실은 채 작업이 취소되면 화물 처리에 대한 명시적 규칙이 있어야 합니다.
상태 피드백: 5. 여덟 상태 매핑표는 양측이 서명하고 계약에 첨부합니다. 6. RCS는 WMS에 하트비트를 보냅니다(초당 약 1회 또는 동등 수준). 하트비트가 ~30초를 초과해 멈추면 WMS가 알람을 울려야 합니다. 7. 실패한 상태 보고는 로컬에 캐시하고 재시도합니다 — 상태 누락 금지. 8. "수동 개입"은 반드시 보고해야 합니다 — 사람이 그 로봇을 운전 중임을 WMS가 알아야 합니다.
예외와 현장: 9. 충전 작업은 RCS가 발행합니다. WMS가 직접 충전을 지시하지 않습니다. 10. 비상 정지, 적재 이탈, 낙하물 이벤트는 합의된 시간 안에 WMS(또는 당직 전화)에 도달해야 합니다. 11. 수동 개입 후 작업 재개 여부는 사전에 작성된 규칙으로 결정합니다. 12. 네트워크 단절 시 로봇의 기본 동작(제자리 대기 vs 충전기로 복귀)은 미리 정합니다.
데이터 정합: 13. 로케이션 코드는 WMS와 RCS에서 완전히 동일해야 합니다 — 대소문자, 하이픈, 한 글자도 빠짐없이. 14. 파렛 바코드 규칙을 일치시킵니다. RCS가 스캔하는 코드는 WMS가 인식할 수 있어야 합니다. 15. 도크, 충전기, 스테이징 구역은 양 시스템에서 일대일로 대응하는 명칭을 씁니다.
부하 테스트: 16. 성수기 작업량의 1.5배를 4시간 연속으로 돌리고, 정체와 타임아웃 발생률을 관찰합니다. 17. 세 가지 장애 — RCS 다운, WMS 다운, 단일 로봇 고장 — 를 시뮬레이션하고 각각의 복구 절차를 밟습니다. 18. 장부와 현장을 대조합니다. 테스트 중 50개 파렛을 무작위로 골라 WMS 장부상 위치와 실제 위치가 일치해야 합니다.
체크리스트는 장식이 아닙니다 — 가동 전날 항목마다 체크하고 담당자가 서명합니다. 귀사 현장 특유의 항목은 위에 추가하세요.
Lin Xiao, WMS 구현 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
