Digit와 AMR 연동 계약에서 사양표보다 먼저 물을 것은 ‘누가 다음 작업을 소유하는가’다. WMS가 tote 이동 의도를 만들고 Arc가 workflow를 조정하며 AMR가 운반하고 Digit가 집어 conveyor에 놓는다면, AMR 도착과 Digit 파지 사이의 책임 전환 시점을 한 사건으로 고정해야 한다. Arc가 MiR·Zebra Robotics AMR과 통신한다는 Agility 발표는 연결 가능성을 보여 줄 뿐, WMS의 기록권한·AMR의 저수준 주행·안전 제어까지 Arc가 대신한다는 뜻은 아니다. 파일럿은 정상 인계보다 timeout, 잘못된 tote, downstream 적체와 한 장비 정지 때 어느 계층이 취소·재배차·복구를 승인하는지 검증해야 한다.
Digit와 AMR가 함께 맡을 작업을 어디서 시작하고 끝낼까
첫 파일럿은 ‘토트를 옮긴다’가 아니라 상태가 명확한 한 흐름으로 자른다. 예를 들어 WMS가 특정 tote를 요청하고 AMR가 handoff 위치까지 운반한 뒤, Digit가 집어 conveyor에 놓고 완료를 반환하는 장면이다. pickup·handoff·dropoff 위치, tote와 task 식별자, 시작·완료 판정과 취소 권한을 먼저 정한다.
Agility가 공개한 GXO workflow 설명에서는 AMR가 tote를 가져오고 Digit가 conveyor로 옮긴다. downstream이 막히면 tote를 옆에 임시 적치했다가 흐름이 회복된 뒤 재개한다고 회사가 서술한다. 게시일, AMR vendor, fleet 규모, task 수와 intervention 분모는 공개되지 않았고 독립 검증도 없다. 이 사례를 모든 Arc 설치의 표준 state machine으로 복사하지 않는다.
작업 경계에는 물리 상태와 디지털 상태를 함께 넣는다. tote가 handoff zone에 있어도 WMS가 취소했다면 집어서는 안 되고, 완료 메시지가 먼저 왔어도 gripper가 tote를 놓지 못했다면 다음 작업을 열어서는 안 된다. KUKA AMP의 로봇·AMR 운영 계층과 마찬가지로 상위 orchestration, 장치 실행과 안전 권한을 하나의 ‘AI가 알아서’라는 표현으로 합치지 않는다.
현장 시스템은 어떤 기록과 권한을 준비해야 하나
준비도는 API가 존재하는지만 보는 항목이 아니다. 어느 시스템이 task·inventory·robot 상태의 system of record인지, clock과 식별자가 맞는지, 중복 메시지와 늦은 응답을 어떻게 구분하는지 확인한다. WMS·WES·MES가 여러 개라면 같은 tote에 상충하는 우선순위를 만들지 않도록 최종 승인 주체를 한 곳에 둔다.
| 계층 | 파일럿 전 확인할 책임 | 준비되지 않은 신호 |
|---|---|---|
| WMS·WES·MES | task·tote·목적지·priority의 원본과 취소 승인 | 같은 task가 여러 ID로 재발행되거나 inventory 상태가 엇갈림 |
| Arc workflow | Digit 상태·작업 순서·AMR 호출과 상위 시스템 결과 연결 | retry가 새 작업인지 중복인지 추적할 사건 ID가 없음 |
| AMR platform | 배차·경로·traffic·도착 상태와 자체 안전 제어 | 도착 메시지와 실제 handoff 자세의 판정이 다름 |
| Digit 제어 | 파지·이송·놓기·기권·안전정지와 작업 결과 | 부분 성공이나 사람 개입이 완료로만 기록됨 |
| 현장 운영 | blocked tote·장비 정지·수동 복구의 승인자와 인계 기록 | 오류가 나면 담당자가 구두로만 순서를 다시 정함 |
Agility의 Arc 출시 설명은 facility mapping, workflow 정의, fleet 운영·troubleshooting과 WMS·WES·MES API를 기능 범위로 제시한다. 2024년 3월 11일 공급사 발표이며 API version·latency·availability·KPI 산식과 고객 acceptance는 공개되지 않았다. 기능 이름을 즉시 plug-and-play 호환성으로 바꾸지 않는다.
파일럿에서는 정상 흐름보다 어떤 예외를 먼저 만들까
정상 handoff만 반복하면 네 계층이 동시에 멈추지 않는 한 문제가 드러나지 않는다. 파일럿은 안전 담당과 integrator가 승인한 시험 범위 안에서 상태 불일치를 재현한다. 목적은 현장 작업자에게 복구 조작법을 가르치는 것이 아니라, 시스템이 안전한 상태로 전환하고 승인된 책임자에게 정확한 원인을 전달하는지 확인하는 데 있다.
- AMR가 늦게 도착하거나 잘못된 handoff 위치에 섰을 때 task가 자동 완료되지 않는지 본다.
- tote ID와 WMS 요청이 다를 때 Digit가 파지를 거부하고 오류가 원본 task에 연결되는지 확인한다.
- downstream conveyor가 blocked일 때 임시 상태·대기시간·재개 승인자가 기록되는지 살핀다.
- 동일 task 메시지가 재전송돼도 두 로봇이 중복 작업하지 않는 idempotency를 시험한다.
- AMR 또는 Digit가 기권·정지했을 때 다른 장비가 점유 구역과 작업물을 넘겨받지 않는지 검증한다.
- WMS 취소가 이동 중 도착했을 때 취소·완료·수동 검토 중 어느 상태로 닫히는지 합의한다.
- 네트워크·clock·event log가 일부 끊겨도 원본 작업과 물리 tote를 다시 맞출 수 있는지 확인한다.
- 사람 개입 후 재개할 때 이전 명령이 queue에서 뒤늦게 실행되지 않는지 승인된 시험으로 점검한다.
각 예외는 task ID, tote ID, robot ID, 위치, 명령·수신·실행 시각과 최종 판정을 하나로 묶는다. 실제 Arc API field나 기본 timeout 값은 공개되지 않았으므로 이 목록을 제품 구현 사실로 쓰지 않는다. 파일럿 계약에 필요한 질문이며, 구체 안전정지·에너지 격리와 복구 절차는 제조사 지침·현장 위험성 평가와 승인된 integrator가 정한다.
인계 성공은 처리량 말고 무엇으로 판정해야 하나
전체 처리량만 보면 빠른 로봇 뒤에 대기와 수동 정리가 숨어 버린다. AMR 도착부터 Digit 파지까지의 handoff wait, blocked 시간, wrong-tote 거부, intervention과 deadlock 회복을 별도 사건으로 센다. 완료된 tote의 품질과 WMS inventory 반영까지 맞아야 end-to-end 성공이다. AMR와 Digit의 장치 성공률을 곱해 전체 성공률을 추정하지 않는다.
| 합격 축 | 같은 분모로 남길 값 | 통과로 보지 않을 사례 |
|---|---|---|
| 작업 완결성 | 요청 task, 올바른 tote, 목적지와 WMS 최종 상태 | 물리 이동은 끝났지만 inventory가 틀림 |
| 인계 품질 | handoff 대기, 위치 오차, retry·cancel·duplicate | 재시도를 숨기고 마지막 성공만 집계 |
| 예외 복구 | blocked·기권·정지에서 감지부터 승인된 재개까지의 시간 | 작업자가 즉석 판단으로 오류를 지움 |
| 사람 부담 | intervention 유형·시간·담당자와 처리한 task 수 | 개입을 정비나 정상 운영으로 분류해 제외 |
| 안전·품질 | safety 수정·거부, tote 손상, 잘못된 적치와 near miss | throughput이 높다는 이유로 사건을 상쇄 |
Agility는 GXO Flowery Branch에서 Digit가 10만 개 넘는 tote를 옮겼다고 2025년 11월 20일 발표했다. 집계 시작·종료일, fleet 크기, 전체 attempt·성공·개입·운영시간과 AMR 연계 비중은 공개되지 않았고 독립 검증도 없다. 누적 규모의 신호로만 사용하며 성공률·시간당 처리량·ROI나 무인 운영의 증거로 환산하지 않는다.
장애가 두 로봇 사이에 걸렸을 때 누가 복구를 이끌까
지원 책임은 vendor별 ticket으로만 나누면 빈틈이 생긴다. WMS에는 task가 열려 있고 Arc에는 AMR 도착이 기록됐지만 Digit는 tote를 잡지 못한 사건처럼, 경계에서 생긴 장애를 한 owner가 끝까지 추적해야 한다. 최초 분류 담당, log 수집 범위, 원격진단 권한, 현장 출동과 재수용시험 승인자를 계약에 명시한다.
Arc가 uptime·throughput·mean time between incidents를 보여 준다는 공급사 설명은 운영 가시성의 출발점이다. 공개 자료에는 KPI 산식·측정 창·목표값과 고객별 결과가 없다. 사건마다 WMS 요청, Arc workflow, AMR 상태, Digit 행동과 안전 제어기의 수정·거부를 같은 clock으로 읽을 수 있는지 파일럿에서 확인한다. 한 dashboard 수치가 다른 vendor의 원본 log를 대체하게 두지 않는다.
복구 완료는 로봇이 다시 움직인 시점이 아니다. 점유 구역이 안전하게 정리되고, tote와 inventory 상태가 일치하며, queue에 남은 낡은 명령이 제거되고, 같은 결함을 재현한 제한 시험을 통과한 때다. 현장 작업자에게 센서 우회나 위험 구역 진입을 권하지 않는다. 승인된 절차를 호출할 조건과 복구 뒤 업무를 다시 인계할 권한만 시스템 계약으로 남긴다.
어느 증거가 쌓여야 한 셀에서 여러 구역으로 넓힐까
확장 결정은 정상 작업량보다 예외의 반복 가능성에서 나온다. 같은 task·tote 정의로 교대와 부하를 바꾸고, AMR와 Digit 버전이 달라져도 소유권 전환과 로그가 유지되는지 본다. blocked·wrong tote·duplicate·한 장비 정지에서 안전한 결과와 복구시간이 정해진 범위에 들어와야 다음 구역을 연다. 구체 임계값은 현장 baseline과 위험성 평가에서 정한다.
Agility는 2025년 3월 31일 공식 발표에서 Arc가 MiR·Zebra Robotics AMR을 호출·배차하고 각 플랫폼과 통신한다고 밝혔다. 지원 model·site·작업 수, protocol, 실시간 성능과 제3자 acceptance는 공개하지 않았다. 연동 존재는 확장 후보를 넓히지만 모든 vendor·version의 즉시 호환을 보장하지 않는다.
새 구역은 기존 셀의 설정을 복사하는 대신 interface contract를 재검증한다. 통로·handoff 자세·tote와 conveyor가 달라지면 로봇 사양뿐 아니라 task ownership이 흔들릴 수 있다. AgiBot A3의 작업환경·손 옵션처럼 몸체와 말단장치 차이를 확인하되, 제품 비교보다 WMS 결과까지 닫힌 end-to-end acceptance를 확장 승인 기준으로 삼는다.
독자가 이어서 묻는 질문
Digit–AMR 파일럿은 몇 주면 충분한가요?
보편 기간은 없다. 작업 빈도와 rare exception이 나타날 기회, 교대·부하·tote variation, maintenance와 지원 응답을 모두 관찰할 만큼 길어야 한다. 달력 주수보다 사전에 정한 정상·blocked·wrong tote·duplicate·장비 정지 trial이 모두 실행됐고, 복구 뒤 재수용시험까지 끝났는지를 종료 조건으로 둔다.
한 셀의 처리량이 목표를 넘으면 바로 다른 구역으로 확대해도 되나요?
처리량만으로는 부족하다. task·inventory 일치, handoff 대기, intervention, 안전 거부, 손상과 예외 복구를 같은 분모에서 봐야 한다. 새 구역의 WMS·AMR version, 통로·handoff·tote 조건이 다르면 interface와 위험성 평가를 다시 확인하고 제한된 범위부터 단계적으로 연다.
자료 마지막 확인: 2026년 8월 26일