참고 자료

Physical AI·AgentCore·제어의 경계

Robot Atlas는 한국어 작업 계획을 물리 시뮬레이션과 연결하는 실습입니다. AI가 작업 순서를 정하고, 제어기가 관절을 움직이며, 물리 엔진이 실제 접촉과 움직임을 계산합니다. 이 세 역할의 근거를 각각 확인해야 시연의 범위를 정확히 설명할 수 있습니다.

입력에서 결과까지

순서 실제 동작 주요 코드
1 알려진 상자·시나리오·목적지 목록과 사용자 지시 제공 shared/contracts.ts, server/planner.ts
2 scenario, summary, actions로 된 후보 계획 생성 규칙 플래너 또는 Bedrock
3 허용 필드·물체·중복·목적지 관계 검사 shared/plans.ts
4 같은 세션이 가진 계획 ID로 새 배치 실행 요청 server/app.ts, server/plan-vault.ts
5 물체 상태를 읽고 경유점·역기구학·관절 위치 서보로 제어 simulation/controller.py, simulation/runtime.py
6 접촉·마찰·중력에 따라 로봇과 자유 물체의 상태 적분 MuJoCo
7 집기 또는 수평 밀기, 최종 분리·지지·안정성 검증과 기록 재생 simulation/runtime.py, server/, src/

현재 플래너에는 시나리오 도구 목록을 제공합니다. 카메라 영상으로 상자를 검출하거나 매 제어 주기마다 이미지를 보고 토크를 생성하지 않습니다. 제어기가 사용하는 물체 위치는 시뮬레이터가 제공하는 상태입니다. 새 배치의 상자 위치·회전·질량은 제한된 범위에서 seed로 달라집니다.

무엇을 AI라고 부르는가

영역 핵심 과정에서 사용 정확한 설명
고수준 작업 계획 실제 Bedrock 연결 시 사용 한국어 지시를 허용된 물체·목적지·순서로 변환
규칙 기반 계획 02–03장 문자열 규칙으로 작업 선택, provider: "rules"로 표시
저수준 제어 사용 역기구학, 경유점, 관절 위치 서보로 구성한 제어 알고리즘
접촉 물리 사용 MuJoCo의 중력·마찰·접촉에 의한 실제 시뮬레이션
학습된 운동 정책 사용하지 않음 provenance.learning: "none"
카메라 인식·VLA 사용하지 않음 알려진 물체 목록과 시뮬레이터 상태 사용
실물 로봇·sim-to-real 검증하지 않음 하드웨어 명령 전송과 실제 장비 실험 없음

발표에서는 “언어로 만든 계획을 물리 엔진에서 실행하고 검증했다”고 설명합니다. “강화학습으로 로봇이 집는 방법을 배웠다”거나 “실물 로봇 제어를 검증했다”는 설명은 이번 결과의 범위를 벗어납니다.

동일한 제어 알고리즘을 사용하지만 서로 다른 CPU·라이브러리 환경에서 모든 부동소수점 값이 비트 단위로 같다고 약속하지 않습니다. 물리 검사와 오차 기준으로 결과를 비교합니다.

상자는 어떻게 움직이는가

시작 시 배치한 상자는 자유 물체입니다. 실행 중에는 MuJoCo의 mj_step과 물리 접촉으로 상태가 진행됩니다. 그리퍼가 양쪽에서 상자를 잡고, 마찰이 하중을 전달하며, 손을 벌리면 놓입니다. Part 3의 밀기에서는 닫힌 손가락을 접촉면으로 사용해 상자를 수평으로 밀며, 들어 올린 뒤 옮기는 동작으로 대체하지 않습니다. 브라우저는 그 결과의 body pose를 재생합니다.

그리퍼에 상자를 붙이는 제약, 실행 중 자유 물체 좌표 덮어쓰기, 미리 정한 키프레임만으로 이동시키는 방식은 이 실습의 성공 근거가 될 수 없습니다. 좌표를 초기화하는 코드, 역기구학용 별도 계산 상태, 실제 동역학 상태를 구분해서 읽습니다.

성공 판정에는 다음 근거가 필요합니다.

  • 집기: 실제 들어 올림과 두 손가락의 하중 접촉
  • 밀기: 실제 손가락 접촉과 수평 이동, 들어 올리지 않은 기록
  • 목표 중심과의 오차, 손과의 분리
  • 탁자 또는 아래 상자의 지지 접촉; 피라미드 위 상자는 두 받침 모두 확인
  • 직립, 낮은 속도, 정착 구간의 작은 위치 변화
  • 정상적인 물리 solver 상태

metrics.positionError는 미터 단위의 최대 최종 중심 오차입니다. 마지막 위치만 맞아도 충분한 것은 아닙니다. 02장의 힘 0 실패, 회귀 검사의 마찰 0과 놓은 뒤 외력 실험이 이 차이를 확인합니다.

이 프로젝트에서 AgentCore Runtime의 용도

핵심 과정의 경로는 로컬 Node API → Bedrock Converse → 후보 검증입니다. AWS 심화에서는 Node API → 전용 AgentCore Runtime → Bedrock Converse → 후보 검증을 사용합니다. Runtime은 agent/의 Python 작업 플래너를 실행하는 위치입니다. MuJoCo 물리 계산은 ECS Fargate의 시뮬레이터에서 수행하는 별도 작업입니다.

Runtime을 분리하면 플래너 코드·모델 호출 권한·배포 수명을 웹 API와 독립적으로 다룰 수 있습니다. 여러 클라이언트가 같은 계획 인터페이스를 사용하도록 확장할 때도 실행 경계를 분명하게 둘 수 있습니다. 이점이 필요한지는 서비스 구조와 운영 요구에 따라 판단합니다. 작은 로컬 데모는 직접 Bedrock 호출만으로도 계획 경로를 검증할 수 있습니다.

설정 우선순위는 코드에 명시되어 있습니다.

  1. AGENTCORE_RUNTIME_ARN이 있으면 agentcore
  2. Runtime ARN 없이 MODEL_ID가 있으면 bedrock
  3. 둘 다 없으면 명시적인 rules

클라우드 모드에서 호출이 실패해도 규칙 계획으로 자동 대체하지 않습니다. 핵심 과정은 AgentCore 자원을 만들지 않으며, 프로젝트의 기존 플래너 경로만으로 별도 AgentCore Gateway·Memory까지 사용한다고 설명하지 않습니다.

Runtime이 있으면 느려질 수 있는가

호출 경로와 실행 환경 준비가 추가되므로 지연이 증가할 수 있습니다. 실제 시간에는 모델 추론, 요청 크기, 서비스·네트워크 상태, 첫 요청의 준비 비용도 영향을 줍니다. Runtime이 있다는 사실만으로 항상 느리거나 항상 빠르다고 결론 내리지 않습니다.

현재 API는 완성된 후보 JSON을 받은 뒤 검증하고 반환합니다. 스트리밍 UI나 제어 주기 단축 기능이 Runtime 도입만으로 생기지는 않습니다. 비교 실험에서는 같은 모델·프롬프트·리전·동시성으로 첫 호출과 반복 호출을 구분하고 여러 표본의 분포를 기록합니다. 04장의 planSeconds는 직접 호출 경로의 전체 계획 지연이며 AgentCore만의 지연 측정값이 아닙니다.

Isaac Sim은 어디에 추가되는가

Isaac Sim은 별도의 시뮬레이션·GPU 심화 트랙입니다. 사용자가 지정한 확장 대상은 현재 계정의 기존 VPC, gpu-cluster-01 EKS Auto Mode, Private GPU Spot 배치입니다. g6e/g7e 후보, 장면에 필요한 VRAM, 이미지·자산·셰이더 준비, 중단 후 다른 Spot에서 재개하는 절차는 그 트랙에서 따로 확인합니다.

웹의 시뮬레이션 기록 엔진 선택은 MuJoCo 기록과 실제 Isaac Sim 기록을 바꿔 재생합니다. 이는 저장된 위치·접촉·검증 결과를 읽는 기능입니다. GPU가 없는 참가자 환경에서도 포함된 Isaac 기록을 볼 수 있지만, 그 참가자의 환경에서 새 GPU 작업을 실행했다는 뜻은 아닙니다. 새 계산은 별도의 작업 계획과 실행 버튼을 통해 시작합니다.

핵심 과정의 MuJoCo 통과 결과로 다음을 주장할 수는 없습니다.

  • Isaac Sim 컨테이너·드라이버·RTX 렌더러의 실제 호환성
  • 대상 리전·계정에서의 GPU Spot 확보 또는 특정 가격
  • 체크포인트 재개와 중단 시 데이터 보존
  • 대화형 스트리밍 세션의 연속성

새 노드나 Pod가 준비되었다는 상태와 실제 장면이 로드되어 물리·렌더링이 동작하는 상태도 별도로 검증해야 합니다. 가격·가용성·복구 시간은 측정 시점을 함께 기록합니다.

실행 화면의 단계별 시간은 다음처럼 읽습니다.

표시 포함하는 시간
GPU 노드·컨테이너 준비 작업 접수 후 GPU를 배치하고 작업자를 시작할 때까지
캐시 복원·Isaac 초기화 작업자 시작 후 캐시와 장면·RTX 렌더러를 준비할 때까지
물리 계산·결과 저장 렌더러 준비 후 실제 물리 작업과 결과 저장을 마칠 때까지

이 시간은 재생 슬라이더의 시뮬레이션 시간과 다릅니다. Spot 교체로 실행 시도가 늘어나면 이전 시도의 작업 시간이 포함된 구간을 따로 표시합니다. 초기화 캐시는 다음 실행의 준비를 줄이지만 새 GPU 노드를 준비하는 시간을 없애지는 않습니다.

근거를 찾을 때

코드가 포함된 실습 소스에서는 shared/, server/, simulation/, agent/를 확인합니다. 오프라인 교재에는 전체 실행 소스나 참가자 결과가 포함되어 있다고 가정하지 않습니다. 공식 API의 현재 지원 범위는 아래 문서를 참고하고, 계정 접근은 실제 호출로 확인합니다.

관련 실습: 02. 물리 성공과 실패 · 04. 실제 모델 연결