Amazon이 대규모 로봇 네트워크와 DeepFleet를 공개한 것은 플릿 수준 학습이 실제 물류 운영에 들어간 중요한 사례다. Amazon은 2025년 6월 30일 300개가 넘는 시설 네트워크에서 100만 번째 로봇을 배치했다고 발표했고, DeepFleet가 robot travel-time efficiency를 10% 개선한다고 설명했다. 두 수치는 회사 발표이며 active fleet·site별 unit·동시 제어 대수와 10%의 baseline·sample·site·기간·분산이 공개되지 않았고 독립 검증도 없다. 누적 100만 대를 하나의 모델이 실시간 중앙 제어하거나 모든 시설의 처리량이 10% 높아졌다는 뜻은 아니다.
실제 배치에서 깨지는 지점은 평균 이동시간 밖에 있다. 특정 통로에 robot이 몰리고, laden·unladen 속도가 달라지며, 우선 작업이 일반 작업을 굶기거나 map·goal 상태가 오래되면 tail delay와 deadlock이 생긴다. DeepFleet의 예측·추천과 WMS 작업 원본, 기존 scheduler·traffic manager, 각 로봇의 안전·저수준 제어를 분리하고, 실패 때 안전정지·재계획·사람 개입과 복구시간이 닫힐 때만 운영 개선으로 인정해야 한다.
DeepFleet의 공개 능력은 무엇이고 무엇은 아닌가
Amazon의 100만 번째 로봇·DeepFleet 공식 발표는 network 규모와 회사 평가 10%를 함께 제시한다. 2025년 6월 30일 회사 milestone이며 fleet denominator, 실험 설계, confidence interval·site별 결과와 외부 replication은 없다. 10%를 throughput·인건비·비용·안전 개선으로 바꾸지 않는다.
Amazon Science 기술 설명과 원 보고서는 DeepFleet를 robot-centric, robot-floor, image-floor, graph-floor의 네 representation·model family로 설명한다. 입력은 family에 따라 floor grid, robot 위치·방향·laden 상태, goal 또는 object 관계를 표현하고 traffic·future location을 예측하거나 downstream next action·state를 다룬다. 네 모델을 하나의 단일 거대 model이나 동일 production runtime으로 합치지 않는다.
DeepFleet는 perception·prediction·routing recommendation을 강화하는 모델군으로 읽을 수 있다. WMS inventory truth, task allocation, 기존 scheduler·traffic rule과 저수준 safety controller를 자동 대체한다는 공개 근거는 없다. 월드 모델과 로봇 제어의 차이처럼 미래 상태 예측이 좋아져도 최종 권한과 실제 행동 결과는 별도 계층에서 검증한다.
평균 이동시간보다 먼저 흔들어 볼 조건은 무엇인가
같은 floor와 정상 물량에서 평균만 비교하면 혼잡의 꼬리가 숨는다. 부하, robot 수, laden 비율, priority class와 aisle closure를 하나씩 바꾸고 동일 task set에서 baseline scheduler와 후보 모델을 비교한다. 각 조건은 map·model·traffic rule과 WMS snapshot version을 고정해 원인을 추적할 수 있어야 한다.
| 시험 변화 | 드러날 수 있는 실패 | 같이 남길 분모 |
|---|---|---|
| robot·task 부하 증가 | hotspot, queue 폭증, tail delay | active robot·task, floor·시간창과 p50·p95·최대 travel time |
| laden·unladen 혼합 | 속도·회전 제약 오판과 비효율 route | 상태별 이동·대기·완료와 재계획 횟수 |
| priority task 투입 | priority inversion, 일반 task starvation | class별 deadline miss·wait와 override |
| aisle·station 차단 | stale map, 우회 집중, deadlock | 차단 감지·반영·해소와 개입·복구시간 |
| 새 floor·site 이동 | 학습 분포 밖 geometry와 traffic pattern | site별 baseline, calibration·fine-tuning과 regression |
플릿 모델은 어떤 예외에서 잘못된 다음 상태를 만들 수 있나
첫 예외는 상태의 시간차다. robot 위치는 최신인데 goal·laden 상태나 station availability가 오래됐다면 예측은 그럴듯해도 실행 가능한 계획이 아니다. input timestamp와 freshness를 family별로 확인하고, stale state가 섞이면 추천을 보류하거나 기존 검증 경로로 돌린다. 자연어·raw camera가 네 family의 공통 필수 입력이라고 덧붙이지 않는다.
둘째는 집계가 소수 robot의 고통을 감추는 경우다. 전체 평균은 줄었지만 특정 priority나 구역이 오래 기다릴 수 있다. task class·floor zone·laden 상태별 분포, 최악 대기와 starvation을 본다. Vulcan과 Proteus의 역할 분담처럼 작업 종류가 다른 robot을 하나의 평균으로 묶지 않고 역할별 제약을 따로 둔다.
DeepFleet 원 보고서는 수십만 대 로봇의 movement data를 활용했다고 기술한다. 2025년 8월 12일 Amazon-affiliated 저자들이 공개한 primary report이며 exact robot·episode 수, site split·공개 dataset과 제3자 재현은 없다. 수십만을 100만 대 전체 corpus로 바꾸거나 training 규모가 모든 새 site의 일반화를 보장한다고 쓰지 않는다.
혼잡·deadlock이 생겼을 때 복구 가능성을 어떻게 판정할까
실패는 travel time이 늘어난 상태만이 아니다. task가 영원히 기다리거나 두 robot이 서로 길을 양보하지 못하고, 사람이 현장 queue를 수동으로 지워야 할 수 있다. 감지·안전정지·traffic 격리·재계획·업무 재개를 한 incident로 묶고, 모델 추천과 실제 fleet manager 행동을 구분한다.
| 실패 장면 | 허용할 복구 증거 | 복구로 세지 않을 상태 |
|---|---|---|
| congestion hotspot | 영향 zone 식별, 유입 조절·우회 후 queue와 tail delay 정상화 | 다른 통로로 혼잡만 이동 |
| deadlock | 안전한 정지·권한 있는 해소, stale task 제거와 재현 test | 현장 작업자가 원인 없이 queue를 삭제 |
| priority starvation | class별 wait 회복, 제한된 override와 감사 log | 긴 일반 task를 성공 분모에서 제외 |
| stale map·goal | version 불일치 감지, 추천 차단·갱신과 결과 재검증 | 낡은 plan을 실행한 뒤 사후 수정 |
| model·service 장애 | 승인된 fallback scheduler 전환, task·robot 상태 보존과 복귀 test | 안전 계층까지 model service와 함께 중단 |
구체 안전정지와 현장 복구 조작은 robot·시설의 제조사 지침과 승인된 운영절차가 정한다. 이 표는 실행 지시가 아니라 acceptance evidence다. 복구시간은 감지부터 업무 상태와 물리 queue가 다시 일치하고 제한 regression을 통과할 때까지 센다. robot이 다시 움직였다는 사실만으로 incident를 닫지 않는다.
10%보다 운영에 가까운 복구 지표는 무엇인가
운영 지표는 평균 travel time, tail delay, deadline miss, congestion duration과 intervention을 함께 둔다. failure가 발생하면 time-to-detect, safe-stop 또는 fallback 전환, deadlock 해소와 task backlog 정상화까지 나눈다. laden·unladen, zone·priority class별 분포를 보여 줘 한 집단의 악화를 전체 평균이 숨기지 못하게 한다.
prediction metric도 실제 결과와 분리한다. future location을 잘 맞혔어도 추천 route가 WMS priority·안전 제약과 충돌하거나 task completion이 나빠질 수 있다. offline score, shadow recommendation, 제한된 closed-loop pilot과 production acceptance를 단계로 나눈다. paper의 predictive score를 fulfillment throughput이나 무사고 증거로 바꾸지 않는다.
어떤 기록이 있어야 DeepFleet 확장을 승인할 수 있나
go/no-go는 foundation model이라는 이름이나 누적 fleet 크기가 아니라 제한 배치의 재현 가능한 결과로 정한다. baseline과 후보의 입력·권한을 맞추고 평균·tail·실패·복구를 같은 task set에서 비교한다. 다음 항목이 비어 있으면 더 많은 floor로 넓히지 않는다.
- active robot·task·site·time window와 baseline scheduler를 10% 같은 수치 옆에 공개한다.
- robot-centric·floor·image·graph family 중 실제 후보의 입력·출력·version과 권한을 특정한다.
- WMS truth, task allocator, traffic manager, model 추천과 low-level safety의 write 경계를 분리한다.
- 평균 travel time 외 p95·최대, congestion·deadlock, deadline miss와 class별 starvation을 센다.
- laden·unladen, zone·priority와 새 floor 변화에서 성능·intervention 분포를 다시 측정한다.
- stale state·aisle closure·service 장애에서 안전정지·fallback·복구와 backlog 정상화를 시험한다.
- offline prediction, shadow, 제한 closed loop와 production acceptance의 결과를 섞지 않는다.
- 모델·map·traffic rule 변경 뒤 같은 stress set을 회귀시험하고 실패 시 rollback을 검증한다.
독자가 이어서 묻는 질문
DeepFleet가 멈추거나 잘못된 경로를 추천하면 로봇 전체가 함께 멈추나요?
그렇게 설계됐다고 공개 자료가 말하지 않는다. 모델 service, fleet scheduler·traffic manager와 각 로봇의 안전·저수준 제어를 분리해야 한다. 장애 때는 승인된 fallback과 task·상태 보존, 안전정지·재계획·복귀 regression을 현장별로 시험한다. 구체 정지·복구 절차는 제조사 지침과 승인된 운영·위험성 평가가 정한다.
자료 마지막 확인: 2026년 8월 26일