로봇 한 대 추가 = JSON 한 개, 코드 0줄

플랫폼의 가치를 한 문장으로 줄이면 이렇습니다. "어떤 로봇이든 명세(manifest) 한 장만 쓰면 시뮬레이션이 돈다." 새 로봇을 넣을 때마다 코드를 고쳐야 한다면, 그건 플랫폼이 아니라 일회성 데모입니다.

한 스키마, 일곱 카테고리

매니퓰레이터든, 사족보행 로봇이든, AMR이든, 드론이든 — 전부 같은 manifest 스키마로 표현됩니다. category(카테고리) 필드가 종류를 정하고, 종류별로 다른 세부 블록(팔 스펙·다리 스펙·드론 스펙 등)만 갈아 끼웁니다.

도식 렌더링 중…

• 공통 필드: 이름, 에셋(USD/URDF) 경로, 운동학(반경·휠베이스), 센서 목록 등
• 종류별 블록: 팔이면 관절·그리퍼, 다리면 보행 정책, 차량이면 조향·구동 방식

이 단일 추상화 덕분에, 카탈로그에서 "이 로봇"을 고르면 시뮬레이터가 그 manifest를 읽어 그대로 스폰합니다 — 종류마다 다른 코드 경로가 아니라요.

매니페스트는 대략 이런 모양입니다 — 사람이 읽고 쓰는 JSON 한 장.

{
  "name": "warehouse_amr_01",
  "category": "AMR",
  "asset": "robots/amr_01/amr_01.usd",
  "kinematics": { "drive": "differential", "radius_m": 0.30, "wheel_base_m": 0.45 },
  "sensors": ["lidar_2d", "imu", "camera_front"]
}

온보딩은 4단계 난이도

물론 모든 로봇이 똑같이 쉽진 않습니다. 난이도는 코드량이 아니라 "기존 핸들러를 재사용할 수 있는가" 로 갈립니다.

유형	예	작업
A	기존 구동 방식의 새 로봇	manifest만 (수 시간)
B	센서 구성이 특이	manifest + 센서 설정
C	새 구동 방식(옴니휠·홀로노믹)	핸들러 확장 필요
D	복합 로봇(팔+이동)	며칠

💡 대부분의 로봇은 유형 A — manifest JSON 한 장이면 끝납니다. 코드를 건드려야 하는 건 정말 새로운 구동 방식(예: 옴니휠)이 등장할 때뿐입니다.

약속이 새는 지점 — 정직하게

"코드 0줄"은 이상이고, 현실엔 새는 곳이 있습니다.

⚠️ 단일 팔 어댑터가 특정 로봇 외에서 silent fail하거나, manifest 스키마의 키가 도구별로 하드코딩돼 있거나, 복합 로봇(팔+그리퍼)이 별도 처리가 필요한 경우가 있습니다. 플랫폼의 약속은 어댑터 계층이 얼마나 정직하게 추상화돼 있는가에 달려 있고, 그 균열을 메우는 게 곧 플랫폼을 키우는 일입니다.

이 manifest가 바로, 다른 글에서 볼 RuntimeConfig·specs_json 같은 다른 데이터 계약들과 함께 "도메인 언어로 의도를 표현한다"는 설계 철학의 한 축입니다.

한 줄 정리

📌 어떤 로봇이든 manifest(JSON) 한 장으로 추가된다 — category가 종류를 정하고 종류별 블록만 갈아 끼우는 단일 추상화. 대부분은 코드 0줄(유형 A)이고, 새 구동 방식만 핸들러를 확장한다. 약속은 어댑터 계층의 정직성에 달려 있다.