제10부 시뮬레이션·디지털트윈·피지컬 AI

10.1 Omniverse I — Kit·확장·앱

10.1.1 이 장에서 배우는 것 / 선수 지식

9.11에서 Isaac Sim이 "Omniverse Kit 위, OpenUSD·RTX·PhysX를 묶은 로보틱스 앱"이라 했고, 그 플랫폼 설명을 제10부로 미뤘다. 이 장이 그 미뤄둔 토대 — Omniverse 플랫폼의 핵심 — 을 판다. Omniverse는 하나의 프로그램이 아니라 3D 애플리케이션·디지털트윈을 만드는 플랫폼이고, 그 핵심이 앱 프레임워크 Kit과 모듈 단위 확장(extension) 이다. Isaac Sim·Isaac Lab(9.11~9.14)·USD Composer·디지털트윈(10.8)이 모두 같은 Kit 위에 확장을 다르게 조합한 앱임을 이해하면, NVIDIA의 시뮬레이션·3D 스택 전체가 한 그림으로 파악된다.

핵심 통찰: Omniverse는 "앱"이 아니라 "앱을 만드는 레고 시스템"이다. 전통적 3D 도구(모놀리식 앱)는 렌더러·물리·UI가 하나로 묶여 있어 재사용·조합이 어렵다. Omniverse는 정반대 — 작은 Kit 커널 + 수많은 확장(extension) 으로, 렌더러도·물리도·USD도·UI도·심지어 로봇 시뮬도 전부 확장이다. "앱"이란 어떤 확장들을 켤지 선언한 묶음(.kit 파일) 일 뿐이다. 그래서 Isaac Sim = Kit + 로보틱스 확장, 디지털트윈 앱 = Kit + 산업 확장, 내가 만든 도구 = Kit + 내 확장. 모듈성·재사용·조합이 Omniverse의 본질이고, 이것이 같은 RTX·PhysX·USD를 온갖 앱·도메인이 공유하게 한다.

배우는 것:

• Omniverse = 플랫폼 — 앱이 아니라 3D 앱·디지털트윈을 만드는 토대(OpenUSD·RTX·PhysX + 모듈 프레임워크).
• Kit — 모든 Omniverse 앱의 런타임·SDK, 마이크로커널 + 확장 구조.
• 확장(extension) — 모듈성의 단위, extension.toml·핫리로드·의존성·레지스트리. "모든 것이 확장".
• 앱 = 확장 묶음 — .kit 선언, 헤드리스(배치·클라우드)·커스텀 앱·마이크로서비스.
• OmniGraph·Python — 확장 위에서 노드 그래프·스크립팅으로 프로그래밍(9.11·9.12 연결).

선수 지식: 9.11(Isaac Sim 지형·이 장이 그 토대)·9.12(OmniGraph/ROS 브리지·Python)·0.1(3개의 컴퓨터·풀스택). OpenUSD의 데이터 모델 깊이는 10.3·10.4, Nucleus(협업)·RTX 렌더·커넥터는 10.2, 디지털트윈은 10.8. 소프트웨어 모듈·플러그인 아키텍처 개념은 가정(BK-02).

정직: Omniverse는 NVIDIA가 포지셔닝·브랜딩·라이선스·구성요소 명칭을 여러 번 바꿔 온 플랫폼이다(앱 명칭 변경 — 예: "Create" → "USD Composer", 엔터프라이즈/개인 라이선스·배포 형태 변화). 확장명·Kit 버전·API·앱 구성은 릴리스 의존이 매우 크다. 이 장은 "플랫폼·Kit·확장·앱의 구조와 왜 모듈식인가의 원리"를 가르치고, 구체 확장명·API·메뉴·라이선스는 "그 시점 공식 문서로 확인". 코드(extension.toml·.kit)는 개념 골격이다. Omniverse는 RTX GPU(워크스테이션/서버/클라우드 OVX) 에서 실행되고 엣지(Jetson)가 아니다(9.11).

10.1.2 Omniverse란 무엇인가 — 앱이 아니라 플랫폼

"Omniverse를 켠다"는 말은 부정확하다 — Omniverse는 켜는 프로그램이 아니라 플랫폼이다.

흔한 오해 vs 실제: ✗ 'Omniverse = 3D 시뮬레이터 앱 하나' / ✓ 'Omniverse = 3D 앱·디지털트윈을 만들고·연결하고·시뮬하는 플랫폼'.

• 플랫폼의 의미: Omniverse는 3D 세계를 만들고(author)·연결하고(connect, 10.2 커넥터)·시뮬하고(PhysX·RTX)·협업하는(Nucleus) 토대다. 그 위에서 누구나 앱·도구·디지털트윈(10.8)을 만든다 — Isaac Sim도 그중 하나.
• 왜 플랫폼인가(모놀리식의 한계): 전통 3D 앱(렌더러·물리·UI가 하나의 묶음)은 ① 다른 앱이 그 렌더러·물리를 재사용 못 함 ② 기능을 조합·교체 어려움 ③ 도메인마다 처음부터 만들어야. Omniverse는 이를 모듈(확장) 로 분해해 재사용·조합을 연다.
• OpenUSD가 공통 언어(10.3): 모든 앱이 USD로 씬을 주고받아, 서로 다른 도구(DCC·시뮬·렌더)가 같은 씬을 공유한다 — Omniverse의 상호운용성 핵심(10.2 커넥터·10.4 컴포지션).
• NVIDIA 풀스택과의 자리(0.1): Omniverse는 "3개의 컴퓨터" 중 시뮬레이션·디지털트윈 축의 플랫폼이다 — 로봇·공장·도시를 가상으로 만들어 학습(9.13)·검증(9.12)·운영(10.8)한다.

핵심: Omniverse는 켜는 앱이 아니라, 3D 앱·디지털트윈을 만들고·연결하고·시뮬하는 플랫폼이다 — OpenUSD(공통 데이터)·RTX(렌더)·PhysX(물리)·Kit(프레임워크)·Nucleus(협업)를 묶는다. 모놀리식 3D 앱과 달리 모듈(확장)로 재사용·조합을 연다. Isaac Sim·Lab·디지털트윈이 모두 이 플랫폼 위의 앱. 0.1의 시뮬레이션 축.

10.1.3 Kit — 모든 Omniverse 앱의 토대

Omniverse Kit은 Omniverse 앱이 서는 런타임·SDK다 — 모든 앱(Isaac Sim 포함)이 Kit 위에 선다.

Kit의 구조(마이크로커널 + 확장, 위에서 아래로):

• 마이크로커널 철학: Kit 커널 자체는 작다 — 확장을 로드하고, USD 스테이지를 들고, 이벤트 루프(매 프레임)를 실행하고, 설정을 관리하는 최소 핵. 나머지 모든 기능은 확장으로 추가한다(렌더러·물리·UI도).
• "모든 것이 확장": RTX 렌더러도 확장, USD 런타임 연동도 확장, PhysX도 확장, UI도 확장, 로봇 시뮬도 확장. Kit은 이들을 조합한다. 그래서 같은 Kit에 다른 확장 세트 = 다른 앱.
• 무엇을 제공하나: USD 스테이지 런타임, RTX 렌더 연동, 이벤트·업데이트 루프, 설정 시스템(carb), Python 스크립팅 런타임(omni.kit), UI 프레임워크(omni.ui), 확장 관리자·레지스트리. 앱 개발자는 이 위에서 확장만 조합·작성.
• Kit 실행파일: kit 실행파일에 .kit 앱 파일(어떤 확장을 켤지, 10.1.5)을 주면 그 앱이 뜬다 — ./kit my_app.kit. Isaac Sim도 내부적으로 Kit + Isaac 확장 묶음.

핵심: Kit은 모든 Omniverse 앱의 런타임이고 마이크로커널 + 확장 구조다 — 작은 커널(확장 로더·USD·이벤트 루프·설정)에 모든 기능(렌더·물리·UI·시뮬)을 확장으로 추가한다. "모든 것이 확장"이라, 같은 Kit에 다른 확장 세트를 조합하면 다른 앱(Isaac Sim·디지털트윈·커스텀). kit 실행파일 + .kit 앱 파일이 진입점.

10.1.4 확장(extension) — 모듈성의 단위

확장(extension) 은 Omniverse 모듈성의 기본 단위다 — 버전이 매겨진, (런타임에) 켜고 끌 수 있는 기능 묶음.

확장의 구조(개념 — 구체 키는 릴리스 의존):

# extension.toml(골격)
[package]
version = "1.0.0"
title = "My Tool"
[dependencies]
"omni.usd" = {}            # 다른 확장에 의존(자동 해결·로드)
"omni.ui" = {}
[[python.module]]
name = "my.company.tool"   # 로드할 파이썬 모듈

# extension.py — 확장의 수명주기
import omni.ext
class MyToolExtension(omni.ext.IExt):
    def on_startup(self, ext_id):     # 확장이 켜질 때(앱 시작·수동 활성)
        # UI·OmniGraph 노드·구독 등록, USD 스테이지 조작 …
        pass
    def on_shutdown(self):            # 확장이 꺼질 때(정리)
        pass

• 버전·의존성: 각 확장은 버전을 갖고 다른 확장에 의존성을 선언한다([dependencies]). Kit이 의존성을 자동 해결·로드 — my.tool을 켜면 필요한 omni.usd·omni.ui가 따라 켜진다(패키지 매니저처럼).
• 핫리로드(개발 핵심): 확장은 런타임에 켜고·끄고·다시 로드할 수 있다 — 앱을 재시작 없이 코드를 고쳐 즉시 반영(개발 반복↑). Kit의 확장 관리자(UI)나 설정으로 활성/비활성.
• 레지스트리·검색 경로: 확장은 레지스트리(NVIDIA·서드파티)나 로컬 검색 경로에서 찾아 설치·로드. 생태계의 확장을 가져다 쓰거나(10.2 커넥터 등) 내 것을 배포.
• 수명주기: on_startup(켜질 때 — UI·노드·구독 등록)·on_shutdown(꺼질 때 — 정리). 이 안에서 USD 스테이지 조작·OmniGraph 노드·UI를 등록.
• Isaac Sim = 확장 묶음: Isaac Sim의 로봇 임포트·센서·ROS 브리지(9.12)·Lab(9.13)이 전부 isaac.*·omni.* 확장이다. 켜고 끄며 기능을 구성.

견해: 확장은 버전·의존성을 가진, 핫리로드되는 기능 모듈이다 — extension.toml(메타·의존)+ Python/C++(on_startup/on_shutdown). Kit이 의존성을 자동 해결하고 런타임 핫리로드로 개발을 빠르게. "모든 것이 확장"이라 Isaac Sim의 모든 기능(임포트·센서·ROS·Lab)도 확장 — 켜고 끄며 앱을 구성한다. 패키지 매니저 + 플러그인 시스템의 3D판.

10.1.5 앱 = 확장 묶음

Omniverse에서 "앱"이란 어떤 확장들을 켤지 선언한 묶음이다 — 코드 묶음이 아니라 구성(configuration).

.kit 앱 파일(개념 골격 — 키는 릴리스 의존):

# my_app.kit
[package]
title = "My Robotics App"
[dependencies]                    # 이 앱이 켤 확장들
"omni.kit.uiapp" = {}             # 기본 UI 셸
"omni.usd" = {}
"omni.kit.renderer.core" = {}     # RTX 렌더
"omni.physx" = {}                 # 물리
"isaac.sim.core" = {}             # (예) 로봇 시뮬 확장
"my.company.tool" = {}            # 내 확장
[settings]                        # 앱 설정(렌더·해상도·헤드리스 등)
app.window.title = "My Robotics App"

실행: ./kit my_app.kit

• 선언적 앱: .kit 파일은 "이 확장들을 이 설정으로 켜라" 는 선언이다. Isaac Sim·USD Composer도 각자의 .kit(또는 동등 구성)으로 정의된 확장 묶음. 앱 = 큐레이션된 확장 세트.
• 커스텀 앱: 내 도구·워크플로우에 맞춰 필요한 확장만 묶어 나만의 앱을 만든다 — 대형 풀 에디터 대신 경량 전용 앱(예: 로봇 셋업 전용, 데이터 생성 전용).
• 헤드리스(배치·클라우드): UI 확장을 빼고 --headless(또는 설정)로 GUI 없는 앱 — 서버·클라우드(OVX)에서 대량 배치. 9.12(합성데이터 생성)·9.13(병렬 학습)가 이렇게 실행된다. UI는 확장이라 빼면 그만.
• 마이크로서비스(Kit as a service): Kit 앱을 서비스로 기동해 API로 호출(렌더·시뮬·데이터 생성을 마이크로서비스로). 클라우드에서 스케일. 모듈성이 서비스화를 쉽게.
• 재현성·배포: 앱이 확장 목록·버전으로 정의되니, 같은 .kit = 같은 앱(확장 버전 고정 시) — 팀·CI에서 재현. 확장 버전 충돌은 주의(함정).

견해: Omniverse "앱"은 코드가 아니라 .kit로 선언한 확장 묶음이다 — Isaac Sim도, 내 커스텀 도구도, 헤드리스 배치 잡도, 마이크로서비스도 확장을 다르게 조합한 것. UI조차 확장이라 빼면 헤드리스(9.12·9.13 클라우드 배치). 대형 풀 에디터 대신 전용 경량 앱을 조립할 수 있는 것이 모듈성의 실익. 같은 .kit = 재현 가능한 앱.

10.1.6 OmniGraph·Python — 확장 위에서 프로그래밍

Kit 앱을 자동화·확장하는 두 길: Python 스크립팅과 OmniGraph(노드 그래프).

두 프로그래밍 모델:

• Python(명령형): omni.usd(스테이지)·omni.kit(앱)·omni.ui(UI)·도메인 API로 무엇이든 스크립트. 9.11·9.12의 시뮬 루프·데이터 생성이 이것. 확장 안(on_startup)에서 등록하거나 독립 스크립트로 배치 실행.
• OmniGraph(데이터플로): 노드를 이어 매 프레임 실행되는 계산 그래프. ROS 브리지(9.12)·센서·로봇 행동·이벤트 반응을 시각적·선언적으로 배선("On Playback Tick → Publish Camera"). ROS 2 launch가 노드를 잇듯, OmniGraph가 시뮬 내부를 잇는다.
• 둘의 분담: 복잡한 절차·배치·외부 연동은 Python, 매 프레임 데이터 흐름·반응·시각적 배선은 OmniGraph. 둘을 섞어 쓴다(OmniGraph 노드를 Python으로 커스텀 작성도).
• 확장으로 패키징: 만든 Python 로직·OmniGraph 노드·UI를 확장으로 묶으면 재사용·배포·핫리로드(10.1.4) — "내 도구"가 된다.
• UI(omni.ui): 커스텀 패널·버튼·뷰를 omni.ui로 — 확장의 on_startup에서 등록. 도구에 UI를 붙이는 길.

견해: Kit 앱은 Python(명령형 — 스테이지·배치·커스텀) 과 OmniGraph(데이터플로 — 매 프레임 흐름·반응·ROS 브리지 9.12) 로 프로그래밍한다. 복잡 절차·배치는 Python, 프레임별 데이터 흐름은 OmniGraph. 만든 것을 확장으로 패키징하면 재사용·핫리로드·배포되는 "내 도구". 9.11·9.12의 실습이 이 두 모델 위에서 실행됐다.

10.1.7 워크스루 — Kit 앱 구조와 확장 만들기

플랫폼을 "구조를 읽고 최소 확장을 만드는" 흐름으로 익힌다(개념 골격).

# ① Kit 앱 구조 들여다보기(Isaac Sim도 Kit 앱)
#   - kit 실행파일 + .kit 앱 파일 + 확장 폴더들
ls .../kit                      # kit 실행파일
cat .../apps/my_app.kit         # [dependencies]에 켤 확장 목록(10.1.5)
#   - 확장 검색 경로(로컬·레지스트리)에서 확장을 찾아 로드

# ② 빈 커스텀 앱 기동(최소 확장만)
./kit my_minimal.kit            # uiapp + usd + renderer 정도만 → 경량 셸

# ③ 확장 관리자에서 핫리로드(개발)
#   - UI: Window > Extensions → 검색·활성/비활성·자동 리로드 토글
#   - 내 확장 검색 경로 추가 → 켜기 → 코드 수정 → 자동 반영(10.1.4)

# ④ 최소 확장 만들기: 스테이지에 큐브 추가하는 버튼(개념 — API 릴리스 확인)
# config/extension.toml
#   [dependencies] "omni.usd"={} "omni.ui"={}
#   [[python.module]] name="my.company.tool"
import omni.ext, omni.ui, omni.usd
from pxr import UsdGeom

class MyToolExtension(omni.ext.IExt):
    def on_startup(self, ext_id):
        self._window = omni.ui.Window("My Tool", width=200, height=80)
        with self._window.frame:
            omni.ui.Button("Add Cube", clicked_fn=self._add_cube)

    def _add_cube(self):
        stage = omni.usd.get_context().get_stage()      # 현재 USD 스테이지(10.3)
        UsdGeom.Cube.Define(stage, "/World/MyCube")      # 프림 추가

    def on_shutdown(self):
        self._window = None

체크포인트:

• my_app.kit의 [dependencies]를 줄이면 더 경량 앱(헤드리스면 UI 확장 제거)
• 확장을 켜면 의존성(omni.usd·omni.ui)이 자동으로 따라 켜짐(10.1.4)
• 코드 수정 → 핫리로드 → 재시작 없이 버튼 동작 갱신(개발 반복↑)
• 이 확장이 곧 "내 도구" — 재사용·배포·다른 앱에 포함 가능
• 읽는 법: Isaac Sim을 "거대한 앱"이 아니라 *"Kit + isaac. 확장 묶음"** 으로 보면, 그 기능(임포트·센서·ROS·Lab)이 어떤 확장인지·켜고 끌 수 있는지 보인다. 문제 해결도 "어느 확장이 담당하나"로.
• 경량으로 시작: 풀 에디터는 부하가 크다 — 필요한 확장만 켠 최소 앱으로 시작해 점증(헤드리스 배치는 더 경량으로).
• 확장이 곧 자산: 만든 도구를 확장으로 묶으면 Isaac Sim에도·내 커스텀 앱에도·디지털트윈(10.8)에도 재사용 — 한 번 만들어 여러 앱에.

견해: 실습의 핵심은 ① Isaac Sim을 Kit + 확장 묶음으로 읽기(.kit의 의존성 목록) ② 최소 앱으로 경량으로 시작 ③ 확장 하나(버튼+스테이지 조작)를 만들어 핫리로드로 반복 ④ 그 확장을 재사용 자산으로. 플랫폼을 "조립·확장"의 눈으로 보면 NVIDIA 시뮬 스택 전체(9.11~9.14·10.8)가 같은 구조로 보인다.

10.1.8 중간 점검 (체크포인트)

• [ ] Omniverse가 앱이 아니라 플랫폼(OpenUSD·RTX·PhysX·Kit·Nucleus)이고, Isaac Sim·Lab·디지털트윈이 그 위의 앱임을 안다.
• [ ] Kit이 모든 앱의 런타임이며 마이크로커널 + 확장("모든 것이 확장") 구조임을 안다.
• [ ] 확장이 버전·의존성·핫리로드되는 기능 단위이고, extension.toml·on_startup/shutdown 구조임을 안다.
• [ ] 앱 = .kit로 선언한 확장 묶음이고, UI를 빼면 헤드리스(배치·클라우드, 9.12·9.13)임을 안다.
• [ ] Python(명령형)·OmniGraph(데이터플로) 두 프로그래밍 모델과 그 분담(9.11·9.12 연결)을 안다.
• [ ] Isaac Sim을 *Kit + isaac. 확장 묶음**으로 읽고, 커스텀 도구를 확장으로 만들 수 있음을 안다.

증상→의심: 확장이 안 켜짐 → 의존성 미해결·검색 경로·버전 충돌 → extension.toml 의존·레지스트리·경로 확인. 앱이 고부하·느림 → 불필요 확장 다수·풀 에디터 → 최소 .kit·헤드리스(UI 제거). 코드 수정이 반영 안 됨 → 핫리로드 비활성 → 확장 관리자 자동 리로드·재활성. 헤드리스인데 UI 에러 → UI 확장이 켜짐 → 의존성에서 제거. API가 문서와 다름 → Kit/확장 버전 차이 → 그 버전 문서(릴리스 의존). Jetson서 Omniverse 안 됨 → RTX 워크스테이션/서버/OVX 대상(9.11). 확장 버전 충돌 → 의존 버전 핀·호환 확인.

10.1.9 트레이드오프·대안

견해: 3D 앱·디지털트윈·시뮬을 NVIDIA 스택(USD·RTX·PhysX·Isaac)으로 만들고 조합·확장하려면 Omniverse(Kit)가 강하다 — 모듈성·재사용·헤드리스 스케일·생태계. 단 모놀리식 도구보다 학습 곡선이 가파르고(확장·Kit·USD 개념), 단순 작업엔 과할 수 있다. 배치·클라우드(데이터·학습)는 헤드리스, 대화형 작성은 GUI, 임시는 스크립트·재사용은 확장. 게임·전통 DCC 성숙도·커뮤니티는 Unreal·Unity·Blender가 앞설 수 있으나, USD 중심 상호운용·실시간 협업·물리/렌더 시뮬·디지털트윈(10.8)·Isaac 통합이 필요하면 Omniverse.

비엔비디아 정직: 3D 플랫폼·엔진은 여럿이다 — Unreal Engine·Unity(게임·실시간 3D 성숙·거대 생태계), Blender(오픈소스 DCC), 그리고 OpenUSD 자체는 Pixar 발 오픈 표준(10.3)이라 Omniverse 전유물이 아니다(여러 도구가 USD 지원). Omniverse의 차별점은 Kit 확장 모듈성·RTX 실시간 레이트레이싱·Nucleus 실시간 협업(10.2)·PhysX·Isaac(로봇)·디지털트윈·USD 네이티브 통합이다. 게임·시각화 중심이면 Unreal·Unity가, 오픈·경량이면 Blender가 나을 수 있다 — USD 협업·산업 디지털트윈·로봇 시뮬·NVIDIA 스택이 핵심이면 Omniverse. 플랫폼 명칭·구성·라이선스는 변동이 크니 그 시점 확인.

10.1.10 흔한 함정

• Omniverse를 단일 앱으로 오해. 플랫폼임을 모르면 Isaac Sim·Lab·트윈의 관계가 안 보임 → "Kit + 확장 묶음" 관점(10.1.2·10.1.3).
• 풀 에디터로 모든 것을. 부하가 크고 느림 → 최소 .kit·헤드리스(필요 확장만, 10.1.5).
• 확장 의존성·버전 무시. 안 켜지거나 충돌 → extension.toml 의존·버전 핀·레지스트리/검색 경로 확인.
• 핫리로드 안 씀. 매번 재시작으로 개발 느림 → 확장 관리자 자동 리로드(10.1.4).
• 헤드리스에 UI 확장 포함. 배치서 UI 에러·낭비 → 의존성에서 UI 제거.
• Python vs OmniGraph 오용. 매 프레임 흐름을 Python 폴링으로·복잡 절차를 그래프로 → 용도 분담(10.1.6).
• 일회성 스크립트 남발. 재사용·배포 안 됨 → 확장으로 자산화.
• 버전 불문 API 복붙. Kit·확장 API가 릴리스마다 변함 → 그 버전 문서.
• Jetson서 시뮬 시도. Omniverse는 RTX 워크스테이션/서버/OVX(9.11) → 엣지는 배포 대상.
• 라이선스·명칭 가정. 포지셔닝·라이선스 변동 큼 → 공식 확인(정직).

10.1.11 연습문제

연습 1 (플랫폼 vs 앱). "Omniverse는 앱이 아니라 플랫폼"이라는 말의 의미를 모놀리식 앱과 대비해 설명하고, Isaac Sim·Isaac Lab·디지털트윈이 그 안에서 무엇인지 답하라.

연습 2 (Kit·확장). Kit의 마이크로커널 구조와 "모든 것이 확장"의 의미를 설명하고, 확장의 버전·의존성·핫리로드가 개발에 주는 이점을 답하라.

연습 3 (앱 = 확장 묶음). "앱 = .kit로 선언한 확장 묶음"의 의미를 설명하고, 헤드리스 앱·커스텀 앱·마이크로서비스를 각각 어떻게 구성하며 왜 유용한지 답하라.

연습 4 (확장 만들기). 로봇 USD를 한 클릭으로 임포트·배치하는 커스텀 도구를 확장으로 만든다면, extension.toml·수명주기·Python/OmniGraph·UI를 어떻게 구성할지 설계하라.

연습 5 (플랫폼 선택). Omniverse를 Unreal·Unity·Blender 같은 대안과 비교해, 어떤 경우에 Omniverse를 택하고 어떤 경우에 대안이 나은지, OpenUSD가 Omniverse 전유물이 아니라는 점과 함께 답하라.

10.1.12 요약 · 다음 장

• Omniverse = 플랫폼(앱 아님): OpenUSD(10.3)·RTX·PhysX·Kit·Nucleus(10.2)를 묶어 3D 앱·디지털트윈을 만드는 토대. Isaac Sim·Lab(9.11~9.14)·트윈(10.8)이 그 위의 앱. 0.1 시뮬레이션 축.
• Kit: 모든 앱의 런타임, 마이크로커널 + 확장("모든 것이 확장" — 렌더·물리·UI·시뮬도). kit + .kit 앱 파일이 진입점.
• 확장(extension): 버전·의존성·핫리로드되는 기능 단위(extension.toml·on_startup/shutdown). 의존성 자동 해결, 런타임 리로드로 빠른 개발. Isaac Sim도 isaac.* 확장 묶음.
• 앱 = 확장 묶음: .kit로 선언. UI 빼면 헤드리스(배치·클라우드, 9.12·9.13), 필요한 확장만 = 커스텀 경량 앱, 서비스화 = 마이크로서비스.
• 프로그래밍: Python(명령형·배치·커스텀) + OmniGraph(프레임별 데이터플로·ROS 브리지 9.12), 확장으로 패키징해 재사용. 정직: 명칭·API·라이선스 변동 큼(확인), RTX GPU(엣지 아님), USD는 오픈 표준(전유물 아님).

다음 장: 10.2 Omniverse II — Nucleus·RTX·커넥터. Kit·확장(앱 구조)을 봤으니, 이제 Omniverse의 나머지 세 기둥 — 실시간 협업·버전 서버 Nucleus, RTX 렌더링(실시간 레이트레이싱·MDL 머티리얼), 그리고 다른 도구(DCC·CAD)를 잇는 커넥터 — 를 본다. 어떻게 여러 도구·팀이 한 USD 씬을 실시간 공유하고, 포토리얼로 렌더하고, 기존 워크플로우와 연결하는지. 플랫폼의 협업·렌더·연결 계층으로.