‘3번 구역의 빈 카트를 먼저 옮겨 줘’라는 말이 들어오면 시스템은 사람의 문장을 바로 바퀴 명령으로 바꾸면 안 된다. 지시의 대상·출발지·목적지·deadline·priority를 구조화하고, WMS의 inventory truth와 현재 로봇·통로 상태를 대조한 뒤, fleet 계층이 실행 가능한 task를 만들어 Proteus에 전달해야 한다. Amazon은 차세대 Proteus가 자연어 assignment에서 priority·route·timing을 정하도록 설계했다고 밝혔지만 parser, 모델, 정확도, WMS write authority와 모호성 처리 방식은 공개하지 않았다. 자연어는 무제한 제어권이 아니라 검증해야 할 상위 작업 입력이다.
자연어 지시가 맡는 범위는 어디까지인가
Amazon의 2026년 6월 4일 공식 발표는 차세대 Proteus에 자연어로 작업을 배정하고 로봇이 priority, route와 timing을 정하도록 설계했다고 설명한다. 명령 수·언어·accuracy·latency·exception rate와 독립 검증은 공개되지 않았다. 어떤 자연어든 이해해 최적 경로를 보장한다는 뜻으로 확대하지 않는다.
발표가 말하는 것은 작업 수준의 assignment다. 현재 위치에서 어느 통로를 지나 얼마의 속도로 모터를 구동할지는 localization, traffic management, motion control과 안전 계층이 다룬다. 언어 모델이 상위 의도를 해석하더라도 금지 구역, robot capacity, 사람 접근과 비상정지 같은 제약을 우회해서는 안 된다. WMS 승인 없이 재고·주문의 원본을 바꾸는 권한도 공개 자료에서 확인되지 않는다.
버전과 배치 상태도 나눈다. Amazon은 기존 Proteus가 미국 25개 fulfillment center에 배치됐다고 밝혔지만 차세대 자연어 버전은 2026년 6월 4일 발표 당시 lab pilot이었다. 기존·차세대 fleet unit와 작업량 분모, 독립 검증은 없다. 25개 site를 자연어 기능이 이미 운영 중인 live site 수로 옮겨 쓰지 않는다. Vulcan과 기존 Proteus의 역할도 차세대 기능과 구분한다.
사람의 말과 현장 상태가 처음 만나는 지점은 어디인가
자연어만으로는 작업을 특정할 수 없다. ‘저 카트’가 어느 asset ID인지, ‘먼저’가 어떤 주문보다 높은 priority인지, ‘점심 전에’가 어느 clock의 deadline인지 현장 데이터와 맞춰야 한다. 사용자 identity·role, 작업 구역, inventory·cart 상태와 robot availability가 입력의 일부가 된다. 음성이라면 인식 결과와 원음 신뢰도, text라면 수정·확인 이력도 사건에 묶는다.
모호한 대상, 존재하지 않는 위치와 상충하는 deadline은 추측해서 실행하지 않는다. clarification을 요청할지, 거부할지, 승인된 fallback queue로 보낼지 작업 위험과 권한에 맞춰 정한다. 그 정책은 Amazon이 공개한 내부 구현이 아니라 현장 검수 질문이다. 사람마다 쓰는 별칭과 WMS 공식 명칭을 연결하는 dictionary도 version과 승인자를 남겨야 한다.
Amazon Science의 Proteus HRI 원 연구는 2026년 17명의 warehouse worker와 3명의 manager, 총 20명이 참여한 6개 bodystorming session을 다룬다. 이는 현장 interaction scenario를 탐색한 primary design study이며 자연어 모델 accuracy·latency 또는 안전 인증의 benchmark가 아니다. 참가자·session 분모와 연구 범위 안에서만 사용한다.
해석 모델은 말의 뜻을 어떤 작업 계약으로 바꿔야 하나
모델 출력은 자유문장이 아니라 검증 가능한 task proposal이어야 한다. intent, object·asset ID, pickup·dropoff, priority, earliest start·deadline, 요청자와 confidence 또는 clarification 상태를 분리한다. 각 필드는 WMS·facility map·fleet rule과 대조한 뒤 승인된다. 이 구조는 공개 기능에서 도출한 reference architecture이며 Amazon의 실제 schema나 사용 모델을 재구성한 것이 아니다.
| 판단 구간 | 시간과 상태를 남길 지점 | 늦거나 불명확할 때의 경계 |
|---|---|---|
| 지시 접수 | 요청 시각, 사용자·채널, 원문과 수정 이력 | 낡은 요청과 중복 요청을 새 명령으로 실행하지 않음 |
| 의도 구조화 | 해석 시작·종료, schema version, 대상·priority·deadline | 필수 field가 없거나 confidence가 낮으면 확인·거부 |
| 현장 사실 대조 | WMS snapshot, map·robot 상태의 조회 시각 | stale inventory·금지 구역·상충 task이면 승인하지 않음 |
| 플릿 계획 | 선택 robot, route·traffic version, 예정 start·finish | priority inversion·deadlock 위험이면 재계획 또는 보류 |
| 장치 실행 | task 수신·수락·완료, safety 수정·거부와 최종 결과 | deadline을 넘긴 행동이 뒤늦게 queue에서 실행되지 않음 |
우선순위·경로·시간은 어느 제어 계층에서 승인돼야 하나
priority는 단어의 강도만으로 정하지 않는다. 주문·작업 등급, 요청자의 권한, robot capacity와 기존 queue를 대조한다. route는 facility map, 일방통행·금지 구역, congestion과 사람 공유 구역을 반영하고, timing은 deadline과 이동 가능 시간·충전 상태를 함께 본다. 서로 충돌하면 모델이 임의로 업무 규칙을 바꾸기보다 WMS·fleet policy의 승인 순서를 따른다.
경로 추천과 실행 가능한 궤적도 다르다. 모션 플래닝과 궤적 최적화의 차이처럼 상위 route는 통로와 waypoint를 고를 수 있지만 실제 속도·가속도·회피와 정지는 장치 제어기가 현재 센서 상태로 계산한다. 자연어 계층이 low-level safety controller나 traffic interlock을 덮어쓰지 못하도록 write 권한을 기술적으로 분리한다.
취소와 override도 같은 interface에 둔다. 사용자가 ‘아니, 그 카트 말고’라고 수정했을 때 이전 task가 어디까지 실행됐는지 확인하고 새 task와 원자적으로 전환해야 한다. 이미 적재한 물체를 단순 취소로 사라지게 만들 수 없다. 물리 상태와 WMS 상태가 다시 일치하기 전에는 완료를 반환하지 않고 승인된 운영자에게 exception을 넘긴다.
Proteus가 움직이는 동안 모델과 하드웨어의 권한은 어떻게 갈라지나
Proteus가 task를 받으면 onboard localization·perception과 fleet traffic 계층이 현재 상태를 갱신하고, motion controller가 장치 한계 안에서 실행한다. 자연어 해석이 정상이어도 통로가 막히거나 센서 신뢰도가 낮아지면 감속·정지·재계획해야 한다. 상위 모델이 성공을 예상했다는 이유로 하드웨어의 안전 거부를 오류로 지우면 안 된다.
Amazon은 차세대 Proteus를 2027년 상반기 Europe 현장에 배치할 계획이라고 2026년 6월 4일 밝혔다. 이는 site·unit·acceptance gate 분모가 없는 미래 계획이며 2026년 8월 26일 현재 production 배치 완료나 확정 일정이 아니고 독립 검증도 없다. lab pilot에서 hardware interface와 사람 공유 구역을 검증한 뒤 단계적으로 넓혀야 한다는 읽기까지만 가능하다.
무슨 로그가 있어야 말의 오해와 실행 실패를 구분할 수 있나
결과가 틀렸을 때 원문, structured task, WMS 대조, fleet plan과 robot 실행을 한 event ID로 따라가야 한다. ‘언어 모델이 틀렸다’고 뭉뚱그리면 stale inventory, 잘못된 map, priority rule 충돌과 장치 정지를 구분할 수 없다. 개인 음성·작업 정보의 보존 범위와 접근 권한도 현장 정책에 맞춰 제한한다.
| 계층 | 계산·권한의 범위 | 검수할 증거 |
|---|---|---|
| 언어 해석 | 의도·대상·priority·시간 proposal 생성 | 원문, schema·model version, clarification·reject 결과 |
| 업무 시스템 | inventory·order truth와 작업 승인 | 조회 snapshot, 승인자, 수정·취소와 conflict 이유 |
| 플릿 계획 | robot 선택, route·traffic·queue 조정 | 후보·선택 이유, replan, priority inversion·deadlock event |
| 로봇 제어 | 센서 기반 궤적·속도·정지와 safety override | 수신·적용 시각, 거부·정지·개입과 실제 위치 |
| 운영 피드백 | 완료·부분 성공·오류를 원본 task에 반환 | end-to-end 결과, 사람 override와 복구 완료 시각 |
현장 통합시험은 어떤 문장부터 시작해야 하나
- 같은 의도를 다른 표현·언어 습관으로 지시해 대상·목적지·priority가 일관되게 구조화되는지 본다.
- 존재하지 않거나 여러 개로 해석되는 asset을 주어 clarification·reject가 실행보다 앞서는지 확인한다.
- WMS inventory와 사람 지시가 충돌할 때 원본 기록을 임의로 덮어쓰지 않는지 검증한다.
- 두 긴급 지시가 겹칠 때 priority inversion, starvation과 승인자 override를 사건으로 남긴다.
- route가 막히거나 map이 오래됐을 때 재계획·보류·안전정지가 task 원본에 연결되는지 살핀다.
- 이동 중 취소·수정에서 이전 queue가 뒤늦게 실행되지 않고 물리·디지털 상태가 맞는지 확인한다.
- 모델·schema·WMS·map·robot version을 바꾼 뒤 같은 시험 세트로 regression을 수행한다.
- 이해율과 함께 wrong target, intervention, safety 거부, tail latency와 end-to-end 성공을 보고한다.
Amazon의 로봇 배치 절차 설명은 작은 process path에서 시작해 더 많은 path·site로 넓히고 employee feedback을 반영한다고 밝힌다. 차세대 Proteus의 구체 gate·threshold를 공개한 자료는 아니다. 이 원칙에 따라 자연어 지시도 제한된 task vocabulary와 승인 경로에서 시작해 실패 분포가 설명될 때만 범위를 넓힌다.
독자가 이어서 묻는 질문
Proteus가 자연어를 이해하면 처음 듣는 모든 창고 지시도 처리할 수 있나요?
그렇게 볼 근거는 없다. Amazon은 priority·route·timing을 다루는 기능을 발표했지만 명령·언어·정확도·예외 분모를 공개하지 않았다. 새로운 표현이 기존 asset·zone·task schema에 안전하게 연결되는지, 모호하면 확인·거부하는지, WMS와 route 제약을 통과하는지 현장별로 반복 검증해야 한다.
자료 마지막 확인: 2026년 8월 26일