Sim-to-Real & the NVIDIA Physical AI Stack

지금까지 우리는 COMPASS를 시뮬레이션 안에서 완성했다. IL로 mobility prior를 심고(Ch2~3), residual RL로 embodiment에 적응시키고(Ch4), distillation으로 하나의 generalist로 통합했다(Ch5~6). 그러나 로봇 논문의 진짜 시험은 시뮬레이터 밖 — 실제 복도, 실제 창고, 실제 조명 아래 — 에서 정책이 작동하는가다. 이 챕터는 그 마지막 관문인 sim-to-real transfer를 다루며, COMPASS가 왜 처음부터 이 관문을 통과하도록 설계되었는지를 밝힌다.

핵심 주장은 두 가지다. 첫째, vision-based navigation의 sim-to-real gap은 dynamics gap보다 rendering domain gap이 지배한다 — 즉 물리가 아니라 '픽셀이 얼마나 진짜 같은가'가 병목이다. COMPASS 논문 스스로 Isaac Lab에서 Carter 성능이 원 X-Mobility보다 하락했음을 인정하며, 그 원인을 route 단순화와 image rendering quality 변화로 지목한다. 이 정직한 자기 진단이 이 챕터의 출발점이다.

둘째, COMPASS는 고립된 논문이 아니라 NVIDIA의 Physical AI 스택(R²D²) 안의 한 부품이다. MobilityGen이 대규모 합성 motion 데이터를 만들고, COMPASS가 그 위에서 mobility를 학습하며, TensorRT로 컴파일되어 Jetson Orin/Thor에 배치되고, 나아가 GR00T N 같은 humanoid VLA foundation model의 synthetic data 생성기로도 위치한다. 이 챕터는 개별 기법을 넘어, COMPASS가 어떤 생태계적 역할을 수행하는지 — 그리고 그 역할이 sim-to-real이라는 난제를 어떻게 시스템 수준에서 우회하는지 — 를 조망한다.

왜 vision-based navigation의 sim-to-real은 특히 어려운가

Sim-to-real gap(심투리얼 격차) = 시뮬레이터에서 학습한 정책이 실제 로봇에 배치될 때 성능이 하락하는 현상. 원인은 시뮬레이션과 현실 사이의 모든 불일치다.

전통적 로봇 학습에서 이 gap의 주범은 dynamics gap이었다 — 마찰계수, 관성, actuator 지연, 접촉 물리가 실제와 다르다. state-based(관절 각도·속도를 직접 입력) 정책에서는 이 물리 불일치가 지배적이라, domain randomization으로 마찰·질량을 흔들어 강건하게 만드는 것이 표준 처방이었다.

그러나 COMPASS는 image를 입력받는 vision-based navigation 정책이다. 여기서는 병목이 물리에서 픽셀로 옮겨간다. 정책이 실제로 보는 것은 카메라 이미지이고, 시뮬레이터의 렌더링된 이미지와 실제 카메라 이미지 사이에는 텍스처·조명·그림자·반사·노이즈·모션블러의 미묘한 차이가 존재한다. 이 차이가 곧 rendering domain gap(렌더링 도메인 격차)이다 — dynamics가 완벽해도 픽셀 분포가 다르면 latent state 인코더가 out-of-distribution 입력을 만나 붕괴한다.

이 관점 전환이 이 챕터 전체를 관통한다. COMPASS가 X-Mobility의 latent world model을 backbone으로 쓰는 것 자체가 부분적 방어책이다 — 원시 픽셀 대신 압축된 latent state에서 정책이 동작하므로, 렌더링 차이가 latent 공간에서 흡수될 여지가 생긴다. 그러나 latent 인코더 자체가 sim 픽셀로 학습되었다면 그 방어는 불완전하며, 여기서 뒤에 볼 개선 방향(다양한 rendering condition을 latent state 학습에 노출)과 Real2Sim이 등장한다.

COMPASS가 인정한 rendering gap — Carter 성능 하락의 정직한 진단

sim-to-real을 다루는 대부분의 논문은 '우리 정책이 실제 로봇에서 잘 돌았다'는 성공 데모로 끝난다. COMPASS의 서술이 값진 이유는 그 반대 — 자기 파이프라인이 어디서 성능을 잃었는지를 명시하기 때문이다.

COMPASS는 원래의 X-Mobility가 학습·평가되던 환경과 다른 Isaac Lab 환경에서 Carter를 재평가했을 때, Carter 성능이 원 X-Mobility 대비 하락했음을 인정한다. 원인으로 두 가지를 지목한다. 첫째는 route의 단순화 — 평가에 쓰인 경로가 원 설정보다 단순해지면서 정책이 학습한 분포와 어긋났다. 둘째, 그리고 더 중요한 것은 image rendering quality의 변화다. 같은 물리·같은 로봇이라도 렌더러가 만들어내는 픽셀의 질감이 달라지면, 앞 절에서 말한 rendering domain gap이 sim-내부에서조차 발생한다.

이 사실은 sim-to-real gap이 '시뮬레이션 대 현실'만의 문제가 아니라 '렌더링 조건 대 렌더링 조건'의 문제임을 폭로한다. 즉 sim → real 전이가 아니라 sim(rendering A) → sim(rendering B) 전이에서조차 gap이 나타난다. 이는 gap의 본질이 물리적 현실성이 아니라 정책이 보는 이미지 분포의 이동(distribution shift)임을 보여준다 — Chapter 3에서 배운 covariate shift가 픽셀 도메인으로 재등장한 것이다.

COMPASS가 제시하는 개선 방향은 여기서 자연스럽게 도출된다. 다양한 rendering condition을 latent state 학습 단계에 노출시키는 것이다. world model 인코더가 하나의 렌더링 스타일이 아니라 조명·텍스처·렌더 품질이 광범위하게 흔들린 이미지들을 보고 latent를 학습하면, latent 표현이 렌더링 세부에 불변(invariant)해진다. 이것이 vision domain randomization의 latent-space 버전이며, 다음 절의 domain randomization 코드와 직접 연결된다.

이 진단이 주는 연구적 교훈은 크다. cross-embodiment mobility의 다음 병목은 새 RL 알고리즘이 아니라 인코더의 rendering-invariance라는 것이다. morphology gap(Ch4~7)을 residual RL로 넘었듯이, rendering gap은 latent 학습의 시각적 다양성으로 넘어야 한다.

MobilityGen → COMPASS → Jetson — R²D² Physical AI 파이프라인

COMPASS를 개별 논문이 아니라 생태계의 부품으로 보면 그 설계 결정들이 비로소 이해된다. NVIDIA의 R²D²(Robotics Research & Development Digest, 2025.04)는 sim-centric robotics를 위한 워크플로우 제품군으로, 세 축을 엮는다.

• MobilityGen — Isaac Sim 기반의 대규모 synthetic motion dataset 생성기(SDG, synthetic data generation). cross-embodiment·cross-environment로 로봇의 이동 궤적·센서 관측을 대량 합성한다. COMPASS의 IL·distillation 데이터의 원천이 될 수 있는 층이다.

• COMPASS — 그 데이터 위에서 cross-embodiment mobility를 학습하고(IL → residual RL → distillation), Isaac Lab에서 fine-tuning하며, zero-shot sim2real로 배치되는 mobility 학습 스택.

• HOVER — humanoid whole-body controller로, 여러 제어 모드를 하나로 통합한다. COMPASS의 mobility 명령을 실제 humanoid 관절 제어로 실현하는 하위 층에 해당한다(Ch6의 joint controller 계층과 같은 자리).

전체 파이프라인은 하나의 방향으로 흐른다. MobilityGen SDG(합성 데이터 생성) → COMPASS mobility 학습(+Isaac Lab fine-tuning) → Jetson Orin/Thor 배치. 이 흐름의 아름다움은 각 단계가 앞 단계의 산출물을 소비한다는 데 있다 — 합성 데이터가 학습을 먹이고, 학습된 정책이 엣지 하드웨어로 흘러 나간다. 사람이 실제 로봇으로 데이터를 모으는 병목이 SDG로 대체되고, 실배치의 병목이 TensorRT 컴파일로 해소된다.

이 sim-centric 접근의 전략적 베팅은 명확하다. 현실 데이터 수집은 느리고 비싸며 위험하지만, 시뮬레이션 데이터는 빠르고 싸며 무한히 다양화할 수 있다는 것. rendering gap(앞 절)이라는 대가를 치르는 대신, 데이터 규모·다양성·라벨 완전성(ground-truth pose·depth·segmentation을 공짜로 얻음)을 취한다. Chapter 10에서 볼 '대규모 데이터 foundation model' 패러다임과 대비되는, COMPASS가 속한 '구조적 분리 + sim 데이터' 패러다임의 정체성이 여기서 확립된다.

그리고 이 파이프라인이 겨냥하는 하드웨어가 Jetson Orin(현세대)과 Thor(차세대)라는 점은, 처음부터 배치를 전제로 설계되었음을 말한다 — 다음 절이 그 배치 제약을 정량화한다.

Cosmos와의 관계 — 렌더링 갭을 메우는 World Foundation Model

COMPASS를 공부할 때 가장 자주 혼동되는 지점이 NVIDIA Cosmos와의 관계다. 결론부터 말하면 둘은 경쟁 관계가 아니라 생산자–소비자 관계다. Cosmos는 데이터와 world model을 공급하는 상류(upstream) 기반 모델이고, COMPASS는 그 데이터를 소비해 학습되는 하류(downstream) 정책이다.

Cosmos(코스모스) = Physical AI를 위한 World Foundation Model(WFM) 플랫폼이다 (Cosmos WFM Platform, arXiv:2501.03575, 2025.01). 크게 세 갈래로 나뉜다.

• Cosmos-Predict — 미래 영상·상태를 생성하는 예측형 WFM
• Cosmos-Transfer — sim 렌더 영상에 실사(photorealistic) diffusion augmentation을 입히는 변환 모델
• Cosmos-Reason — 물리·공간 관계에 대한 추론

이 중 COMPASS와 직접 맞물리는 것은 Cosmos-Transfer다. NVIDIA가 공개한 COMPASS mobility 워크플로우는 명시적으로 Isaac Sim + Cosmos-Transfer로 synthetic data 생성 → Isaac Lab에서 post-training → Jetson Orin/Thor 배치로 흐른다. 즉 Cosmos는 COMPASS 학습 파이프라인의 데이터 생성 단계에 꽂힌다.

왜 하필 Cosmos-Transfer인가? 바로 앞 절에서 본 rendering domain gap 때문이다. COMPASS 논문은 Isaac Lab의 rendering 품질 차이로 Carter 성능이 하락했다고 정직하게 인정하며, 처방으로 "다양한 rendering condition에 노출"을 제시했다. Cosmos-Transfer는 정확히 그 처방을 자동화한다 — LLM 프롬프트로 조명·텍스처·재질·날씨를 바꿔가며 하나의 sim 궤적을 수십 개의 실사풍 변형으로 증강한다. 그 결과 COMPASS의 world model이 학습하는 latent 표현이 특정 렌더러의 인공적 특질에 과적합되지 않게 된다.

스택에서의 위치를 정리하면 다음과 같다.

여기서 반드시 짚어야 할 함정이 하나 있다. 이 코스에서 "world model"이라는 단어가 두 번, 서로 다른 층위로 등장한다는 점이다.

COMPASS도 분명히 world model을 쓰지만(2장에서 다룬 자체 소형 RSSM), 그것은 Cosmos가 아니다. Cosmos는 COMPASS 바깥에서 학습 데이터를 만들어 주는 별개의 대형 WFM이다. 같은 단어지만 규모와 역할이 완전히 다르므로, 논문이나 블로그에서 두 world model을 뒤섞지 않도록 주의해야 한다.

정리하면 Cosmos와 COMPASS는 NVIDIA Physical AI 스택의 두 톱니바퀴다. Cosmos가 렌더링 갭을 메운 다양한 데이터를 만들고, COMPASS가 그 데이터로 cross-embodiment 정책을 빚는다. 8장의 generative policy가 "정책의 출력 분포"를 넓히는 이야기였다면, Cosmos는 "정책의 입력 데이터 분포"를 넓히는 축이다 — 결국 둘 다 generalization을 위한 분포 확장이라는 점에서 같은 목적을 향한다.

Real2Sim으로 gap을 되돌리기 — VR-Robo와 environment semantic

rendering gap을 줄이는 두 방향이 있다. 하나는 sim을 더 다양하게(domain randomization) 만들어 real을 그 다양성 안에 포함시키는 것이고, 다른 하나는 아예 real을 sim 안으로 복원해 gap 자체를 없애는 것이다. 후자가 Real2Sim(리얼투심) 접근이다.

Real2Sim = 실제 환경을 3D 재구성해 시뮬레이터 안에 디지털 복제본(digital twin)을 만들고, 그 복제본에서 정책을 학습·평가하는 프레임워크. 정책이 학습에서 보는 픽셀과 배치에서 보는 픽셀이 같은 실제 장면에서 유래하므로 rendering gap이 근본적으로 축소된다.

VR-Robo(2025.02, "real-to-sim-to-real framework for visual robot navigation and locomotion")가 이 방향의 대표다. 이름 그대로 real → sim → real의 3단 루프를 돈다. 실제 환경을 촬영해 photorealistic한 sim 장면으로 복원하고(real2sim), 그 안에서 visual navigation·locomotion 정책을 학습한 뒤(sim), 실제 로봇으로 되돌린다(sim2real). 핵심은 복원된 sim의 렌더링이 실제 장면의 시각적 통계를 그대로 담고 있어, 정책의 vision 인코더가 배치 환경과 일치하는 분포에서 학습된다는 점이다.

COMPASS 논문은 자신의 RL fine-tuning이 environment의 semantic을 이해하는 방향으로 확장되면, Real2Sim 지원이 있을 때 Sim2Real gap을 더 좁힐 수 있다고 언급한다. 이 연결이 미묘하지만 중요하다. COMPASS의 residual RL(Ch4)이 단순히 충돌 회피를 넘어 '이곳은 좁은 복도', '저것은 통과 가능한 선반 밑'처럼 환경의 의미를 latent에 반영하도록 학습되면, Real2Sim으로 복원된 실제 장면에서 그 semantic 이해가 배치로 그대로 전이된다. 즉 Real2Sim은 픽셀 gap을 줄이고, semantic-aware RL은 그 위에서 의미 gap을 줄이는 상보적 관계다.

두 접근을 비교하면 트레이드오프가 드러난다. domain randomization은 임의의 새 환경에 대비하는 범용 강건성을 주지만 특정 환경에 최적은 아니다. Real2Sim은 특정 배치 환경에 대한 gap을 거의 제거하지만, 그 환경을 미리 스캔·복원해야 하므로 확장성이 제한된다. 실전에서는 둘을 결합한다 — Real2Sim으로 base 장면을 복원하고 그 위에 조명·텍스처 randomization을 얹어, '정확한 배치 환경 + 그 주변 변동'을 함께 학습한다.

엣지 배치의 물리학 — TensorRT, latency, 그리고 경량성의 대가

sim-to-real의 마지막 1미터는 소프트웨어가 실제 로봇의 컴퓨터에서 실시간으로 도는가다. 아무리 정확한 정책도 제어 주기 안에 추론을 못 끝내면 무용하다. COMPASS는 이 제약을 정량적으로 통과한다.

배치 스택은 TensorRT on AGX Jetson Orin이다. TensorRT는 NVIDIA의 추론 최적화 컴파일러로, 학습된 네트워크를 특정 GPU에 맞춰 layer fusion·precision calibration(FP16/INT8)·kernel auto-tuning으로 재컴파일한다. 그 결과 실측 지표는 다음과 같다.

이 숫자를 읽는 법이 이 절의 핵심이다. 첫째, P50(29.3ms)과 P95(29.4ms)가 거의 같다 — 이 0.1ms 차이가 뜻하는 바는 latency 분산이 극히 작다는 것이다. 실시간 제어에서는 평균 지연보다 최악 지연(tail latency)이 중요하다. 제어 루프가 33ms(30Hz) 주기라면, P95가 29.4ms라는 것은 거의 모든 추론이 데드라인을 지킨다는 뜻이다. tail이 튀면 로봇이 순간적으로 눈이 머는 것과 같으므로, 이 낮은 분산은 안전성과 직결된다.

둘째, 422MB라는 메모리 풋프린트는 Jetson Orin의 공유 메모리 예산 안에서 다른 프로세스(perception, locomotion controller, logging)와 공존할 수 있는 크기다. 이 경량성은 우연이 아니라 Chapter 5~6의 설계 결정에서 나왔다 — 배치 시 무거운 X-Mobility backbone은 유지하되 여러 embodiment의 specialist들을 하나의 distilled generalist 정책으로 교체함으로써, 배치 스택을 경량으로 유지한다. specialist를 embodiment 수만큼 싣는 대신 하나의 조건부 정책만 싣는 것이다.

여기에 경량성의 대가라는 긴장도 있다. distillation은 성능을 유지하면서 크기를 줄이지만(Ch5), rendering gap에 대한 강건성까지 자동으로 주지는 않는다. 즉 이 챕터의 두 축 — rendering gap(정확성)과 edge latency(효율성) — 은 부분적으로 상충한다. gap을 줄이려 인코더에 더 많은 rendering 다양성을 학습시키면 모델이 커질 수 있고, 커지면 latency·메모리 예산을 압박한다. COMPASS의 30ms/422MB는 이 저울에서 '충분히 정확하되 확실히 배치 가능한' 지점을 택한 결과다.

마지막으로 이 배치 프로필이 Chapter 10의 패러다임 대비를 예고한다. COMPASS류 구조적 분리는 바로 이 경량 배치를 얻기 위해 sim 데이터와 distillation을 택했다. 반대로 수십억 파라미터의 navigation foundation model(NavFoM 등)은 범용성을 얻지만 이런 30ms/422MB 엣지 배치는 어렵다 — 배치 제약이 곧 패러다임 선택의 압력임을 이 숫자들이 증언한다.