Isaac Lab & Newton — Robot Learning Evolves

Chapter 3에서 본 Isaac Sim이 '로봇을 위한 시뮬레이터(디지털 트윈)'였다면, Isaac Lab은 그 시뮬레이터 위에서 실제로 로봇 정책(policy)을 학습시키는 프레임워크다. 둘의 관계는 게임 엔진과 게임의 관계에 가깝다 — Isaac Sim이 물리·렌더·센서를 제공하는 엔진이라면, Isaac Lab은 그 엔진 위에서 RL·IL 실험을 굴리는 '학습 하네스'다. three computers 프레임으로 보면 Isaac Lab은 정확히 시뮬레이션 컴퓨터(Omniverse/OVX) 위에서 DGX로 넘어갈 정책을 빚어내는 지점에 위치한다.

이 챕터의 핵심은 두 가지 진화다. 첫째는 계보의 통합이다. NVIDIA의 로봇 학습 도구는 Isaac Gym(Preview) → OmniIsaacGymEnvs → Orbit → Isaac Lab으로 이어지며 파편화되어 있었는데, 공식 문서가 못박듯 "Isaac Lab supersedes IsaacGymEnvs, OmniIsaacGymEnvs, and Orbit as the single robot learning framework for Isaac Sim" — 즉 Isaac Lab이 이 모든 것을 하나로 대체했다. 둘째는 물리 백엔드의 재편이다. 2026년 초 early access로 나온 Isaac Lab 3.0은 오랫동안 유일한 물리 엔진이던 PhysX 옆에 Newton이라는 새 백엔드를 나란히 세운다.

Newton은 단순한 물리 엔진 교체가 아니라 NVIDIA·Google DeepMind·Disney Research가 함께 만든 오픈소스 differentiable physics 엔진이며, 2025년 9월 Linux Foundation으로 기여되며 오픈 거버넌스로 넘어갔다. 이 챕터는 '왜 학습 프레임워크가 이렇게 여러 번 이름을 바꿨는가', '왜 이제 와서 새 물리 엔진이 필요한가', 그리고 'kit-less·factory pattern이라는 아키텍처 결정이 무엇을 가능하게 하는가'를 파고든다.

4.1 계보 — Isaac Gym에서 Isaac Lab까지, 왜 네 번이나 바뀌었나

NVIDIA 로봇 학습 도구의 계보는 겉으로 보면 어지럽지만, 각 단계마다 명확한 '해결하려던 문제'가 있다.

Isaac Gym(한글: 아이작 짐) = NVIDIA 최초의 GPU 병렬 물리 기반 RL 환경. Preview 릴리스로 공개되었고, 결정적으로 아직 Omniverse 기반이 아니었다. Isaac Gym이 증명한 것은 단 하나 — 수천 개의 로봇 환경을 GPU 한 장에서 동시에 시뮬레이션하면 RL 학습이 CPU 시대보다 수백 배 빨라진다는 것이다. 기존 RL은 CPU 시뮬레이터(MuJoCo 단일 인스턴스)에서 경험을 모으느라 병목이었는데, Isaac Gym은 물리·관측·보상 계산을 전부 GPU에 올려 CPU-GPU 왕복을 없앴다.

하지만 Isaac Gym은 독자적인 렌더·자산 파이프라인을 썼기에 Omniverse 생태계(OpenUSD, RTX 렌더, SimReady asset)와 단절되어 있었다. 그래서 나온 것이 OmniIsaacGymEnvs(Omniverse Isaac Gym Envs) — Isaac Gym의 병렬 학습 이점을 Omniverse/Isaac Sim 위로 옮긴 버전이다. 이제 학습 환경이 OpenUSD 씬과 RTX 렌더를 공유할 수 있게 됐다.

그다음 Orbit(오빗)은 환경 정의를 더 모듈화하고 재사용 가능한 task·sensor·asset 추상을 도입한 연구 프레임워크였다. 그리고 이 Orbit이 그대로 Isaac Lab으로 rename되었다 — 즉 Isaac Lab의 코드 뿌리는 Orbit이다. 최종적으로 NVIDIA는 파편화된 세 갈래(IsaacGymEnvs·OmniIsaacGymEnvs·Orbit)를 공식적으로 은퇴시키고 Isaac Lab 하나로 수렴시켰다. 계보를 한눈에 보면 다음과 같다.

이 흐름의 교훈은, NVIDIA가 '실험적 아이디어(GPU 병렬) → 생태계 통합(Omniverse) → 재사용 추상(Orbit) → 표준 프레임워크(Isaac Lab)'라는 성숙 곡선을 밟았다는 것이다.

4.2 Isaac Lab의 구조 — Manager 기반 환경과 RL/IL 어댑터

Isaac Lab(한글: 아이작 랩) = Isaac Sim 위에서 동작하는 로봇 학습 프레임워크로, RL(강화학습)과 IL(모방학습)을 위한 재사용 가능한 task·environment·asset을 제공한다. 핵심 설계 철학은 '환경 정의를 코드가 아니라 config로 조립한다'는 것이다.

Isaac Lab의 환경은 보통 여러 Manager의 조합으로 정의된다. observation manager(무엇을 관측할지), action manager(무엇을 제어할지), reward manager(무엇을 보상할지), termination manager(언제 에피소드를 끝낼지), event manager(도메인 randomization·리셋 이벤트)로 나뉜다. 사용자는 각 manager에 어떤 term을 넣을지 선언적으로 조립하며, 이 방식 덕분에 하나의 로봇 task를 살짝 바꿔 다른 실험으로 파생시키기가 쉽다. 이것이 Orbit에서 물려받은 '모듈화'의 실체다.

RL을 실제로 돌리려면 정책 최적화 알고리즘이 필요한데, Isaac Lab은 특정 라이브러리에 묶이지 않고 여러 RL 어댑터를 제공한다 — RSL-RL, skrl, Stable Baselines 3, RL Games. 같은 환경을 이 넷 중 어느 것으로도 학습시킬 수 있다는 뜻이다. 각 라이브러리는 PPO 등의 구현 디테일과 성숙도가 다르므로, 연구자는 벤치마크 재현이나 성능에 맞춰 골라 쓴다.

모방학습·데이터 수집 쪽도 두 컴포넌트로 갖춰져 있다. isaaclab_mimic = IL(모방학습)을 위한 데이터 증강·정책 학습 모듈로, 소수의 시연을 대량의 학습 궤적으로 불려주는 역할을 한다(이것이 뒤 챕터의 GR00T·합성 데이터 흐름과 이어진다). isaaclab_teleop = XR(VR 헤드셋 등) 원격조작으로 사람이 직접 로봇을 조종해 시연 데이터를 만드는 모듈이다. 즉 Isaac Lab 안에서 '사람 시연 수집(teleop) → 데이터 증강(mimic) → 정책 학습(RL/IL 어댑터)'이라는 전체 루프가 닫힌다.

정리하면 Isaac Lab은 '환경은 manager로 조립, 학습은 어댑터로 교체, 데이터는 teleop·mimic으로 확보'라는 세 축의 조립식 프레임워크다. 이 조립성이 다음 절에서 볼 백엔드 교체를 가능하게 하는 토대가 된다.

4.3 Newton — NVIDIA·DeepMind·Disney가 함께 만든 오픈 물리 엔진

Newton(한글: 뉴턴) = NVIDIA, Google DeepMind, Disney Research가 공동 개발한 오픈소스 GPU 가속 물리 엔진이다. 2025년 3월 GTC에서 발표되었고, 발표 무대에서 Disney의 Star Wars BDX droid가 Newton으로 구동되며 시연되었다. 이후 2025년 9월 29일 Linux Foundation에 기여되어 오픈 거버넌스 체제로 넘어갔다 — 즉 이제 Newton은 특정 벤더의 폐쇄 자산이 아니라 커뮤니티가 함께 발전시키는 표준 후보다.

Newton의 기술적 뿌리는 두 가지다. 첫째 NVIDIA Warp — 파이썬으로 GPU 커널을 작성하게 해주는 프레임워크로, 물리 계산을 GPU 네이티브로 표현한다. 둘째 OpenUSD — Chapter 2에서 본 공통 3D 데이터 층으로, Newton의 씬·자산이 Omniverse 생태계와 자연스럽게 호환된다. 이 조합 덕에 Newton은 Warp 위에서 물리를 '네이티브로' 표현하면서도 USD 씬을 그대로 먹을 수 있다.

하지만 Newton의 진짜 차별점은 differentiable physics(미분 가능 물리)다.

Differentiable physics(미분 가능 물리) = 시뮬레이션 전체를 하나의 미분 가능한 함수로 보고, 최종 결과(예: 로봇이 넘어졌는지)에 대한 gradient를 시뮬레이션을 거꾸로 타고 입력 파라미터(제어 신호, 물성치)까지 전파할 수 있는 물리 엔진.

왜 이게 중요한가? 전통적 RL은 물리를 블랙박스로 두고 '행동을 바꿔보고 보상이 오르면 채택'하는 방식이라 gradient 정보가 없어 샘플 효율이 낮다. 반면 미분 가능 물리에서는 '이 관절 토크를 조금 키우면 손끝 위치가 어느 방향으로 얼마나 움직이는지'를 gradient로 직접 계산할 수 있다. 개념적으로는 다음과 같다.

\[\frac{\partial \, \text{Loss}}{\partial \, \theta_{\text{control}}} = \frac{\partial \, \text{Loss}}{\partial \, s_T} \cdot \prod_{t} \frac{\partial \, s_{t+1}}{\partial \, s_t}\]

즉 최종 상태의 loss를 시간축을 따라 각 물리 스텝의 미분으로 역전파해 제어 파라미터까지 gradient를 흘린다. 이는 trajectory optimization·system identification·정밀 조작(dexterous manipulation) 학습에서 큰 이점이 된다. 여기에 Newton은 확장성 높은 multiphysics(강체·연체·천·유체 등 이질적 물리의 결합)를 지향해, Disney BDX droid처럼 복잡한 캐릭터 운동을 다룰 수 있다. 현재 버전은 Newton 1.0이다.

4.4 Isaac Lab 3.0 — kit-less와 factory pattern 백엔드

Newton이라는 새 물리 엔진이 생겼다고 해서, 사용자가 기존 코드를 전부 다시 짜야 한다면 아무도 쓰지 않을 것이다. Isaac Lab 3.0(2026년 초 early access)의 아키텍처 핵심은 바로 이 전환 비용을 없애는 데 있다.

첫째, kit-less(킷리스) 모드다.

Kit-less = Isaac Sim(내부적으로 Omniverse Kit 위에서 동작)을 통째로 설치하지 않고, Newton backend만으로 경량 실행·배치가 가능한 모드.

지금까지 Isaac Lab을 돌리려면 무거운 Isaac Sim/Kit 런타임 전체가 필요했다. RTX 렌더나 풍부한 GUI가 필요 없는 상황(예: 헤드리스 대량 학습, 경량 배치 환경)에서도 전체 스택을 짊어져야 했던 것이다. kit-less는 이 의존성을 끊어, Newton 물리와 최소한의 코어만으로 학습·롤아웃을 돌릴 수 있게 한다. 이는 클라우드에서 대량 병렬 학습을 띄우거나, 렌더가 필요 없는 물리 중심 실험을 저비용으로 굴릴 때 결정적이다.

둘째, factory pattern(팩토리 패턴) 백엔드 디스패치다. 핵심 아이디어는 '유저 코드는 물리 엔진을 몰라야 한다'는 것이다. 사용자가 '이 로봇 asset을, 이 센서를 만들어줘'라고 선언하면, Isaac Lab 3.0이 런타임에 이 요청을 선택된 backend(PhysX 또는 Newton)로 디스패치해 실제 객체를 생성한다. 결과적으로 유저의 task·env 코드는 backend가 무엇이든 그대로 불변이고, 백엔드 전환은 config 한 줄(sim.physics_backend를 physx↔newton)로 끝난다. 이것이 4.1의 '조립식 설계'가 물리 엔진 층까지 확장된 모습이다.

이 구조는 패키지 분할로 물리적으로 구현된다.

즉 코어(isaaclab)는 backend를 모른 채 팩토리 인터페이스만 알고, 실제 구현은 isaaclab_physx / isaaclab_newton이 각각 채운다. Isaac Lab 3.0 자체는 Newton 1.0을 기반으로 하며, 특히 dexterous(정밀 손 조작) task의 RL을 강화한 것이 이 릴리스의 초점이다 — 이는 앞 절의 differentiable physics 이점과 정확히 맞물린다.

4.5 PhysX vs Newton — 어느 백엔드를 언제 쓰는가

Isaac Lab 3.0이 두 backend를 나란히 두었다는 것은, 둘이 서로를 대체하는 게 아니라 상보적이라는 뜻이다. 각각의 성격을 이해해야 올바르게 고를 수 있다.

PhysX(피직스) = NVIDIA의 성숙한 상용 물리 엔진으로, Isaac Sim에 깊이 통합되어 있고 오랜 검증을 거친 안정적·기능 풍부한 기본 백엔드. 대부분의 로봇 시뮬레이션(관절 로봇, 마찰·접촉이 중요한 조작)에서 오랫동안 검증된 결과를 낸다. 반면 Isaac Sim/Kit 전체 런타임을 요구하고, 기본적으로 미분 가능하지 않다.

Newton(뉴턴) = Warp 네이티브·kit-less 실행 가능·differentiable을 강점으로 하는 새 백엔드. 경량 배치와 gradient 기반 최적화, 확장 multiphysics에 유리하지만, PhysX만큼의 오랜 실전 검증·기능 성숙도는 아직 쌓는 중이다.

실무 판단의 축은 대략 이렇다. (1) '검증된 안정성과 기존 자산 재사용이 최우선'이면 PhysX. (2) '헤드리스로 클라우드에서 초대량 병렬 학습을 저비용으로 굴리고 싶다'면 kit-less가 되는 Newton. (3) 'trajectory optimization이나 정밀 조작을 gradient로 풀고 싶다'면 differentiable한 Newton. (4) '오픈 거버넌스·커뮤니티 확장을 중시'하면 Newton.

중요한 것은, factory pattern 덕분에 이 선택이 되돌릴 수 있는 결정이 되었다는 점이다. 예전이라면 물리 엔진 교체가 프로젝트 재작성을 의미했지만, 이제는 같은 task 코드를 두 backend에서 돌려 결과를 대조하는 것 자체가 하나의 검증 방법이 된다. 이는 sim-to-real의 신뢰성(한 엔진의 특이한 접촉 처리에 정책이 overfit되지 않았는지)을 높이는 실질적 무기다.