AEGLOSLAB 엔비디아 기술 스택

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

10.2 Omniverse II — Nucleus·RTX·커넥터

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

10.1에서 Omniverse의 앱 프레임워크(Kit·확장·앱)를 봤다. 이 장은 그 위에서 Omniverse를 협업 플랫폼으로 만드는 나머지 세 기둥 — Nucleus(실시간 협업·버전 서버), RTX(실시간 레이트레이싱 렌더), 커넥터(기존 DCC·CAD 도구 연결) — 를 판다. Kit이 "앱을 만드는 법"이라면, 이 셋은 "여러 도구·팀이 하나의 3D 씬을 실시간으로 공유하고, 포토리얼로 렌더하고, 기존 워크플로우와 연결하는 법" 이다. 디지털트윈(10.8)·합성데이터(10.5)·로봇 시뮬(9.11)의 협업·렌더 토대.

핵심 통찰: Omniverse의 협업 모델은 "파일을 주고받기"가 아니라 "하나의 살아있는 USD 씬을 여럿이 동시에 편집하기"다. 전통적 3D 협업은 파일을 export·이메일·머지하는 비동기·단절적 과정이다 — 누가 최신본인지 모르고, 도구마다 포맷이 달라 변환에서 깨진다. Omniverse는 정반대 — Nucleus가 USD 씬을 단일 진실원천(single source of truth)으로 호스팅하고, 커넥터가 Maya·Blender·CAD 등 이질적 도구를 그 USD에 라이브로 연결하며, RTX가 그 씬을 실시간 포토리얼로 렌더한다. 한 사람이 Maya에서 조명을 바꾸면 다른 사람의 화면에 즉시 반영된다 — 다도구·한 씬·실시간. 그 공통 언어가 USD(10.3)다.

배우는 것:

  • 세 기둥 — 협업(Nucleus)·렌더(RTX)·연결(커넥터)이 Kit(10.1) 위에서 무엇을 더하나.
  • Nucleus — USD 씬을 호스팅하는 단일 진실원천, 실시간 라이브 협업·버전·체크포인트·접근제어.
  • RTX 렌더링 — 실시간 레이트레이싱 vs 패스트레이싱(인터랙티브 vs 레퍼런스), MDL 물리 기반 머티리얼, 멀티 GPU.
  • 커넥터 — Maya·Blender·CAD 등 기존 도구를 USD로 잇는 라이브 싱크, USD를 교환 포맷으로.
  • 함께 — 다도구·한 씬·실시간이 디지털트윈(10.8)·합성데이터(10.5)·시뮬(9.11)을 어떻게 공급하나.

선수 지식: 10.1(Omniverse 플랫폼·Kit·확장)·9.11(RTX 센서·포토리얼 Sim2Real)·0.1(풀스택·협업). OpenUSD의 데이터 모델·컴포지션은 10.3·10.4(이 장은 USD를 "공유 씬"으로만), 디지털트윈은 10.8, 합성데이터는 10.5. 3D 협업·렌더링 기초 개념은 가정(BK-02).

정직: NVIDIA는 Omniverse의 협업·Nucleus 제품 구성·라이선스·배포 형태·명칭을 여러 번 재편했다(엔터프라이즈/개인·클라우드·온프렘 변화, 서비스 통폐합). 이 장은 "협업·렌더·연결이 무엇을·왜 하는가의 원리·구조"(단일 진실원천·라이브 싱크·실시간 vs 레퍼런스 렌더·USD 교환)를 가르치고, 구체 제품명·배포·라이선스·API·커넥터 지원 도구 목록은 "그 시점 공식 문서로 확인". RTX는 RTX GPU(워크스테이션/서버/클라우드 OVX) 가 필요하다(엣지 아님, 9.11). 코드·구성은 개념 골격이다.

10.2.2 세 기둥 — 협업·렌더·연결

10.1의 Kit(앱 프레임워크) 위에, Omniverse를 협업 플랫폼으로 완성하는 세 기둥을 큰 그림으로.

이질적 기존 도구들 USD 참조·구독 USD 참조·구독 USD 참조·구독 Maya Blender Revit/CAD 3ds Max 커넥터 USD로 번역·라이브 싱크 (① 연결) Nucleus — USD 씬 호스팅(단일 진실원천) (② 협업) 실시간 라이브 공유·버전·체크포인트·접근제어 Isaac Sim (9.11) 디지털트윈 (10.8) RTX 뷰어 RTX 실시간 레이트레이싱·패스트레이싱(포토리얼) (③ 렌더)

위는 10.1의 Kit 위에 선 Omniverse 협업 플랫폼이다 — 이질적 기존 도구들이 커넥터로 USD에 번역돼 Nucleus에 모이고, Isaac Sim·디지털트윈·RTX 뷰어가 그 USD를 참조하며, 뷰어가 RTX로 포토리얼 렌더한다.

  • ① 연결(커넥터): 팀은 이미 Maya·Blender·CAD를 쓴다. 커넥터가 이들을 USD로 번역해 Nucleus에 라이브 연결 — 도구를 버리지 않고 Omniverse에 합류(10.2.5).
  • ② 협업(Nucleus): USD 씬을 한 곳에 호스팅해 모두가 같은 진실원천을 본다. 한 사람의 변경이 실시간으로 다른 이에게(10.2.3).
  • ③ 렌더(RTX): 그 씬을 실시간 포토리얼로 렌더 — 협업 중 바로 보고, 디지털트윈 시각화·센서 시뮬(9.11)·합성데이터(10.5)에 쓴다(10.2.4).
  • USD가 접착제(10.3): 세 기둥 모두 USD로 돌아간다 — 커넥터가 USD로 번역, Nucleus가 USD를 호스팅, RTX가 USD를 렌더, 시뮬·트윈이 USD를 소비. 공통 데이터 모델이 다도구 협업을 가능케 한다.
  • 왜 이것이 가치인가: 영화·건축·제조·로봇이 모두 "여러 전문가·도구가 한 3D 자산을 함께" 만든다 — 전통적 파일 교환의 단절·변환 손실을 단일 USD 씬 + 실시간으로 푼다.

핵심: Kit(10.1) 위에 Nucleus(협업·단일 진실원천)·RTX(실시간 포토리얼 렌더)·커넥터(기존 도구 연결) 세 기둥이 Omniverse를 협업 플랫폼으로 완성한다. USD(10.3)가 공통 언어 — 커넥터가 번역, Nucleus가 호스팅, RTX가 렌더, 시뮬·트윈이 소비. "파일 주고받기"가 아니라 다도구·한 씬·실시간.

10.2.3 Nucleus — 단일 진실원천·실시간 협업

Nucleus는 Omniverse 협업의 백본 서버다 — USD 씬·에셋을 호스팅하고, 여럿이 동시에 실시간 편집하게 한다.

   Nucleus의 역할:

   · 호스팅(단일 진실원천) — USD 파일·에셋을 한 곳에. 모두가 같은 최신본 참조
   · 실시간 라이브 협업    — 여러 클라이언트(앱·사용자)가 같은 스테이지를 동시 편집
                            한 변경이 즉시 다른 이에게 전파(live sync)
   · 버전·체크포인트       — 변경 이력·되돌리기·스냅샷
   · 접근 제어·권한        — 누가 무엇을 보고 편집하나
   · publish/subscribe     — 클라이언트가 USD를 참조·구독, 변경 알림

   비교:
     전통: export → 파일 전송 → 머지 (비동기·단절·"누가 최신?"·변환 손실)
     Nucleus: 한 USD 씬을 모두가 실시간 공유 (동기·연속·단일 진실)
  • 단일 진실원천(single source of truth): 프로젝트의 USD 씬·에셋이 Nucleus 한 곳에 있어, 모두가 같은 최신본을 참조한다 — "내 로컬 사본 vs 네 사본"의 분기·충돌이 없다. 클라이언트(Isaac Sim·DCC·뷰어)는 Nucleus의 USD를 참조(reference, 10.4) 한다.
  • 실시간 라이브 협업: 여러 사용자·앱이 같은 스테이지를 동시에 편집하고, 한 변경이 즉시 전파된다(라이브 싱크). A가 Maya에서 조명을 옮기면 B의 Omniverse 화면에 바로 보인다. 게임의 멀티플레이처럼, 3D 씬 작성의 멀티플레이.
  • 버전·체크포인트·권한: 변경 이력·스냅샷·되돌리기, 접근 제어. 협업의 거버넌스.
  • 배포 형태(정직): 워크스테이션용·엔터프라이즈·클라우드 등 형태가 있고, NVIDIA가 이를 재편해 왔다 — 구체 제품·배포·라이선스는 시점 의존(확인 필요). 원리(단일 진실원천·라이브 싱크)는 유지.
  • USD가 전제(10.3): 라이브 협업이 되는 것은 씬이 USD라서다 — 레이어·참조(10.4)로 변경을 합성·구독할 수 있다. Nucleus는 "USD를 위한 실시간 협업 데이터베이스".

견해: Nucleus는 USD 씬의 단일 진실원천 + 실시간 협업 서버다 — "export·전송·머지"의 비동기·단절을 "한 씬을 모두가 실시간 공유"로 바꾼다(3D 작성의 멀티플레이). 단일 진실원천이라 분기·변환 손실이 없고, 라이브 싱크로 변경이 즉시 전파, 버전·권한으로 거버넌스. 이것이 되는 것은 씬이 USD(10.3·10.4) 라서. 제품 형태는 재편이 잦으니 시점 확인.

10.2.4 RTX 렌더링 — 실시간 레이트레이싱·MDL

RTX는 Omniverse의 렌더 엔진 — GPU 레이트레이싱으로 포토리얼 이미지를 실시간 만든다. 두 모드의 구분이 핵심이다.

   RTX 두 렌더 모드:

   ① RTX 실시간(Real-Time) — 래스터화 + 레이트레이싱 효과(반사·그림자·AO·GI 일부)
      · 인터랙티브(수십 fps), DLSS·디노이징으로 빠르게
      · 용도: 작성 중 뷰포트·협업·디지털트윈 운영 시각화·실시간 센서 sim
   ② RTX 패스트레이싱(Path-Traced) — 전역 조명 완전 시뮬(레퍼런스 품질)
      · 물리적으로 정확(빛 경로 적분), 느림(수렴에 시간)
      · 용도: 최종 포토리얼·정확도 중요한 합성데이터(10.5)·마케팅 렌더

   MDL(Material Definition Language):
      · 물리 기반 머티리얼의 이식 가능한 표준 정의(빛-재질 상호작용)
      · 도구·렌더러 간 일관된 재질 → 같은 머티리얼이 어디서나 같게
  • 실시간 vs 패스트레이싱(가장 중요한 구분): 실시간 모드는 래스터화에 레이트레이싱 효과를 더해 인터랙티브(작성·협업·운영 시각화·실시간 센서). 패스트레이싱은 빛 경로를 완전 적분해 물리적으로 정확하지만 느려 레퍼런스·최종 품질(정확한 합성데이터·마케팅). 용도가 모드를 정한다.
  • 왜 포토리얼이 중요한가: RTX 사실성이 ① Sim2Real(비전, 9.11) — 시뮬 영상이 실영상에 가까워 비전 모델 전이↑ ② 합성데이터(10.5) — 갭 작은 학습 데이터 ③ 디지털트윈(10.8) — 실물 같은 시각화·검토를 준다. RTX는 "보기 좋은 그림"이 아니라 갭을 좁히는 충실도.
  • MDL(머티리얼): 물리 기반 재질(금속·유리·천의 빛 반응)을 이식 가능하게 정의하는 표준 — 같은 MDL 머티리얼이 도구·렌더러를 옮겨도 일관. USD가 씬을, MDL이 재질을 표준화.
  • 멀티 GPU·디노이징: RTX는 여러 GPU로 렌더를 분산(고해상도·복잡 씬)하고, AI 디노이징·DLSS로 적은 샘플로 노이즈 없는 이미지(실시간성). 데이터 생성(10.5)은 GPU·해상도로 스케일.
  • 센서 시뮬과 직결(9.11): RTX가 카메라·LiDAR 센서(9.11.6)를 레이트레이싱으로 사실적으로 — 인지(9.7~9.9) 입력·합성데이터의 엔진.

견해: RTX의 핵심 구분은 실시간(인터랙티브·작성/협업/운영) vs 패스트레이싱(레퍼런스·정확·최종) 이다 — 용도로 고른다. 포토리얼리즘은 미관이 아니라 Sim2Real(9.11)·합성데이터(10.5)·디지털트윈(10.8)의 갭을 좁히는 충실도. MDL이 재질을 이식 가능하게 표준화(USD는 씬, MDL은 재질). 멀티 GPU·디노이징으로 스케일·실시간.

10.2.5 커넥터 — 기존 도구를 USD로 잇다

팀은 이미 Maya·Blender·CAD·Revit을 쓴다. 커넥터(connector) 는 이 이질적 도구를 USD/Omniverse에 연결해, 도구를 버리지 않고 협업에 합류시킨다.

커넥터 플러그인 Maya/Blender/Revit/ CAD (네이티브 포맷) Nucleus의 USD 씬 (USD) ① export/import: 네이티브 ↔ USD 변환 ② 라이브 싱크: 네이티브 편집 → USD에 실시간 반영 (양방향 가능)

라이브 싱크 덕에 "Maya에서 모델을 옮기면 Omniverse 뷰에 즉시" 반영된다 — 도구는 그대로 두고 씬만 공유한다. USD가 교환 포맷(interchange) 이다 — 각 도구의 네이티브 포맷을 USD로 번역해 모든 도구가 USD로 만난다(USD는 오픈 표준 10.3 — 점점 더 많은 도구가 네이티브 지원).

  • 기존 워크플로우 보존: 커넥터의 핵심 가치는 도구를 바꾸라고 강요하지 않는 것 — 아티스트는 Maya에서, 엔지니어는 CAD에서 계속 일하되, 결과가 USD로 한 씬에 모인다. 전환 비용 없이 협업 합류.
  • 라이브 싱크: 단순 export가 아니라 실시간 연동 — 네이티브 도구에서 편집하면 Nucleus의 USD에 즉시 반영(10.2.3 라이브 협업과 맞물림). "Maya에서 조명, Omniverse에서 즉시 본다".
  • USD가 교환 포맷(10.3): 각 도구의 다른 포맷을 USD로 번역해 모두가 USD에서 만난다 — N개 도구를 N² 변환기로 잇는 대신 USD 허브로. USD가 오픈 표준이라 점점 많은 도구가 USD를 네이티브 지원(커넥터 없이도)하는 추세(정직: 지원 범위는 도구·버전 의존).
  • CAD·BIM·미디어 등 도메인: 제조(CAD)·건축(Revit/BIM)·미디어(Maya/Houdini)·디자인(SketchUp) — 도메인마다 커넥터로 USD 합류 → 디지털트윈(10.8)·시뮬에 그 자산을.
  • 한계(정직): 모든 도구·기능이 완벽히 USD로 변환되진 않는다 — 도구별 고유 기능·표현은 손실·근사될 수 있다(지원 매트릭스 확인). USD 네이티브 지원이 늘며 개선 중.

견해: 커넥터는 "기존 도구를 버리지 않고 USD/Omniverse에 라이브로 잇는" 다리다 — 아티스트는 Maya, 엔지니어는 CAD를 계속 쓰되 결과가 한 USD 씬에 실시간으로 모인다. USD가 교환 허브(N² 변환 대신 USD 중심)이고, 오픈 표준이라 네이티브 지원이 느는 추세. 단 변환은 완벽하지 않으니(고유 기능 손실) 지원 범위를 확인. 전환 비용 없는 협업 합류가 핵심 가치.

10.2.6 셋이 함께 — 다도구·한 씬·실시간

세 기둥이 합쳐지면 "여러 전문가·도구가 하나의 살아있는 씬을 함께 만들고 보는" 워크플로우가 된다.

① 연결 CAD 엔지니어: 작업 셀·기계 → 커넥터로 USD 아티스트: 환경·재질(Blender/Maya) → 커넥터로 USD ② 협업 모두 Nucleus의 한 USD 씬에 라이브 합류, 동시 편집· 즉시 전파 ③ 렌더 RTX 실시간 포토리얼 검토(설계 리뷰), 패스트레이싱으로 최종 ④ 시뮬 Isaac Sim(9.11)이 같은 USD를 열어 로봇·물리·센서 추가 ⑤ 학습/검증 합성데이터(10.5)·RL(9.13)·SIL(9.12) ⑥ 운영 디지털트윈(10.8)으로 실라인과 연동·모니터· what-if

집계 워크플로우(예: 로봇 작업 셀 디지털트윈 10.8)에서 한 USD 씬이 설계→시뮬→학습→운영을 관통한다(10.3 USD가 접착제).

  • USD가 전 과정을 관통: 설계(CAD/DCC)·협업(Nucleus)·렌더(RTX)·시뮬(Isaac Sim)·학습(합성데이터·RL)·운영(트윈)이 같은 USD 씬을 공유·발전시킨다 — 단계마다 변환·재작업 없이. USD(10.3·10.4)가 모든 단계의 공통 데이터.
  • 실시간 협업의 실익: 설계 리뷰를 포토리얼로 함께 보며 즉시 수정(원격·다도구), 변경이 시뮬·트윈에 바로 반영. 비동기 파일 교환의 며칠 루프가 실시간으로.
  • 로봇·산업 맥락(10.8): 공장·물류·로봇 셀을 가상으로 짓고(다도구), 그 위에서 로봇을 학습·검증(9.11~9.14)하고, 실라인과 연동해 운영(디지털트윈) — Omniverse 협업·렌더가 그 토대.
  • 자율주행도(8.15): DRIVE Sim이 Omniverse(USD·RTX) 기반으로 도시·센서를 시뮬 — 같은 플랫폼이 도메인을 넘나든다.

견해: 세 기둥이 합쳐지면 "다도구·한 씬·실시간" — CAD·DCC가 커넥터로 USD에 모이고, Nucleus가 단일 진실원천으로 실시간 협업시키고, RTX가 포토리얼로 렌더하고, Isaac Sim·트윈이 같은 USD를 소비한다. USD(10.3)가 설계→시뮬→학습→운영을 관통하는 접착제. 비동기 파일 교환을 실시간 공동 작성으로 바꾸는 것 — 디지털트윈(10.8)·로봇 개발의 협업 토대.

10.2.7 워크스루 — 협업·렌더 파이프라인

협업·렌더를 "연결→공유→렌더" 흐름으로 개념 골격에서 본다(제품·UI는 릴리스 의존).

   ① 연결: 기존 도구를 USD로
     · DCC(Maya/Blender)에 Omniverse 커넥터 설치 → 라이브 싱크 켜기
     · 또는 USD로 export → Nucleus에 업로드
     · CAD/Revit도 커넥터로 USD 변환·합류

   ② 협업: Nucleus에 씬 두고 참조
     · Nucleus 서버에 프로젝트 USD 호스팅(단일 진실원천)
     · 클라이언트(Isaac Sim·뷰어·DCC)가 omniverse://server/proj/scene.usd 참조
     · 여러 사용자 동시 접속 → 라이브 편집·변경 전파(10.2.3)
# Kit/Isaac Sim에서 Nucleus의 USD 참조(개념 — API·URL은 릴리스 확인)
import omni.usd
from omni.isaac.core.utils.stage import add_reference_to_stage
# Nucleus 경로(omniverse:// 스킴)의 공유 USD를 현재 스테이지에 참조(10.4)
add_reference_to_stage(
    usd_path="omniverse://my-nucleus/Projects/cell/workcell.usd",   # 단일 진실원천
    prim_path="/World/WorkCell")
# → 다른 팀원이 Nucleus의 workcell.usd를 바꾸면 이 참조에 반영(라이브)
   ③ 렌더: RTX 모드 선택
     · 작성·협업·실시간 센서(9.11) → RTX 실시간(인터랙티브·DLSS)
     · 최종 포토리얼·정확 합성데이터(10.5) → RTX 패스트레이싱(레퍼런스)
     · 머티리얼은 MDL로(이식 가능·물리 기반)
     · 멀티 GPU로 고해상도·대량 렌더 분산
   체크포인트:
     · Nucleus 참조가 최신인가(다른 팀원 변경 반영) → 라이브 싱크 상태
     · 실시간/패스트레이싱을 용도에 맞게(인터랙티브 vs 정확) 선택했나
     · 커넥터 변환에서 누락된 고유 기능 없나(지원 매트릭스, 10.2.5)
  • omniverse:// 스킴: Nucleus의 자산은 omniverse://server/path URL로 참조한다 — 로컬 파일처럼 쓰되 공유·실시간. 시뮬·트윈이 이 URL로 단일 진실원천을 연다.
  • 모드 선택이 핵심(10.2.4): 인터랙티브 작업·실시간 센서는 실시간 모드, 정확한 최종·합성데이터는 패스트레이싱. 둘을 혼동하면 느리거나(작성에 패스트레이싱) 부정확(정확 데이터에 실시간).
  • 헤드리스 렌더(10.1): 합성데이터·배치 렌더는 헤드리스 Kit 앱(UI 없이)으로 클라우드·렌더팜에서 대량(10.5).
  • 정직: 협업·Nucleus·커넥터 구성은 제품 재편이 잦으니, 실제 설치·URL·라이선스는 그 시점 문서로.

견해: 파이프라인은 연결(커넥터로 USD)→공유(Nucleus 참조, omniverse:// 단일 진실원천)→렌더(RTX 모드 선택·MDL) 다. 체크포인트는 ① Nucleus 참조가 최신인가(라이브 싱크) ② RTX 모드가 용도에 맞나(실시간 vs 패스트레이싱) ③ 커넥터 변환 손실 없나. 배치 렌더는 헤드리스(10.1·10.5). 제품 구성은 재편이 잦으니 시점 확인.

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

  • [ ] Nucleus·RTX·커넥터가 Kit(10.1) 위에서 협업·렌더·연결을 더해 Omniverse를 협업 플랫폼으로 완성함을 안다.
  • [ ] Nucleus가 USD 씬의 단일 진실원천 + 실시간 라이브 협업(버전·권한)이고 "파일 교환"과 다름을 안다.
  • [ ] RTX의 실시간(인터랙티브) vs 패스트레이싱(레퍼런스) 구분과 용도, MDL(이식 가능 머티리얼)을 안다.
  • [ ] 포토리얼리즘이 Sim2Real(9.11)·합성데이터(10.5)·디지털트윈(10.8) 의 갭을 좁히는 충실도임을 안다.
  • [ ] 커넥터가 기존 도구(Maya·CAD)를 USD로 라이브 싱크해 전환 비용 없이 협업 합류시킴을 안다.
  • [ ] 세 기둥 + USD(10.3) 가 설계→시뮬→학습→운영을 관통하는 다도구·한 씬·실시간을 만듦을 안다.

증상→의심: 변경이 협업자에게 안 보임 → Nucleus 라이브 싱크·참조 최신화·연결 상태 → 재연결·참조 갱신. 렌더가 느림 → 작성에 패스트레이싱 사용 → 실시간 모드(인터랙티브)로. 렌더가 부정확/노이즈 → 합성데이터에 실시간 모드·수렴 부족 → 패스트레이싱·샘플↑(10.5). 머티리얼이 도구 옮기니 다름 → MDL 미사용·변환 손실 → MDL 표준 머티리얼. 커넥터 변환에 누락 → 도구 고유 기능 미지원 → 지원 매트릭스·USD 네이티브. Jetson서 RTX 안 됨 → RTX 워크스테이션/OVX(9.11). 누가 최신본? → 단일 진실원천(Nucleus) 안 쓰고 파일 사본 → Nucleus 참조로 통일.

10.2.9 트레이드오프·대안

결정트레이드오프
Nucleus 단일 진실원천 vs 파일 교환실시간·단일·협업 vs 단순·오프라인·도구 독립
RTX 실시간 vs 패스트레이싱인터랙티브·빠름 vs 물리 정확·레퍼런스(느림)
커넥터 라이브 싱크 vs 일회 export실시간 협업 vs 단순·단발 변환
USD 네이티브 vs 커넥터 변환손실 없음·미래 vs 기존 도구 즉시 합류
MDL vs 도구별 머티리얼이식·일관 vs 도구 친숙
Omniverse 협업 vs Perforce/git-lfs+DCC실시간 3D 협업·USD vs 친숙한 버전관리·범용

견해: 여러 도구·팀이 하나의 3D 씬을 실시간 공동 작성(디지털트윈·대규모 씬) 하려면 Nucleus + 커넥터 + RTX가 강하다 — 단일 진실원천·라이브 싱크·포토리얼이 비동기 파일 교환의 단절을 없앤다. 단 인프라(Nucleus 서버)·학습 곡선·라이선스가 들고, 단순·소규모·오프라인 작업엔 과할 수 있다. RTX 모드는 용도로(작성/운영=실시간, 정확 데이터/최종=패스트레이싱). 기존 도구는 커넥터로 즉시 합류하되, 장기엔 USD 네이티브 지원이 손실 없이 낫다. 일반 버전관리(Perforce·git-lfs)에 익숙하고 실시간 3D 협업이 불필요하면 그쪽이 단순.

비엔비디아 정직: 3D 협업·렌더·교환의 대안은 많다 — 버전/자산 관리(Perforce·git-lfs·Shotgun/ShotGrid), 렌더러(Arnold·V-Ray·Redshift·Unreal/Unity 실시간·Blender Cycles/EEVEE), 교환 포맷(USD 자체는 오픈 표준 10.3·이전엔 FBX·Alembic). Omniverse의 차별점은 USD 네이티브 실시간 협업(Nucleus)·RTX 실시간 레이트레이싱·MDL·커넥터 생태계·시뮬/디지털트윈(9.11~10.8) 통합이다. 순수 렌더 품질·게임 파이프라인·기존 자산관리에 만족하면 대안이 나을 수 있다 — USD 실시간 협업·산업 디지털트윈·로봇 시뮬 통합이 핵심이면 Omniverse. 제품·라이선스·명칭은 재편이 잦으니 그 시점 확인.

10.2.10 흔한 함정

  • 파일 사본으로 협업. "누가 최신?"·변환 손실·분기 → Nucleus 단일 진실원천·참조(10.2.3).
  • 작성에 패스트레이싱. 인터랙티브가 느려 작업 답답 → RTX 실시간 모드(작성·협업).
  • 정확 데이터에 실시간 모드. 합성데이터(10.5)가 부정확·노이즈 → 패스트레이싱·수렴.
  • MDL 미사용. 도구·렌더러 옮기면 머티리얼 달라짐 → MDL 표준 머티리얼(이식).
  • 커넥터 변환 맹신. 도구 고유 기능이 USD로 손실·근사 → 지원 매트릭스 확인·USD 네이티브 고려(10.2.5).
  • 라이브 싱크 연결 끊김 무시. 변경이 전파 안 됨 → 연결·참조 최신 확인.
  • 포토리얼을 미관으로만 봄. RTX 충실도는 Sim2Real·합성데이터·트윈의 갭 축소(9.11·10.5·10.8) → 충실도에 투자.
  • Jetson서 RTX 시도. RTX 워크스테이션/서버/OVX(9.11) → 엣지 아님.
  • 제품 구성·라이선스 가정. Omniverse 협업·Nucleus 재편 잦음 → 그 시점 확인(정직).
  • 멀티 GPU·헤드리스 안 씀. 대량 렌더·데이터를 단일·GUI로 느리게 → 멀티 GPU·헤드리스 배치(10.1·10.5).

10.2.11 연습문제

연습 1 (Nucleus). Nucleus의 "단일 진실원천·실시간 협업"이 전통적 파일 교환과 무엇이 다른지 설명하고, 이것이 가능한 이유가 왜 USD(10.3)와 관련되는지 답하라.

정답

전통 파일 교환의 문제: 3D 협업을 export→파일 전송(이메일·드라이브)→머지로 하면 ① 비동기·단절 — 누군가 작업하는 동안 다른 이는 옛 사본을 봄 ② "누가 최신?" — 사본이 여럿이라 진실원천 불명, 분기·충돌 ③ 변환 손실 — 도구마다 포맷이 달라 FBX 등으로 변환하며 데이터 깨짐 ④ 느린 루프 — 변경 반영에 며칠. Nucleus의 차이: ① 단일 진실원천(single source of truth) — 프로젝트 USD 씬·에셋이 Nucleus 한 곳에, 모두가 같은 최신본을 참조(로컬 사본 분기 없음). ② 실시간 라이브 협업 — 여러 사용자·앱이 같은 스테이지를 동시 편집하고 변경이 즉시 전파(A가 조명 옮기면 B 화면에 바로). 게임 멀티플레이처럼 3D 작성의 멀티플레이. ③ 버전·체크포인트·권한 — 이력·되돌리기·접근 제어로 거버넌스. 즉 "export·전송·머지"의 단절을 "한 씬을 모두가 실시간 공유"로. 왜 USD와 관련되나: 라이브 협업·단일 진실원천이 되는 것은 씬이 USD(10.3·10.4) 라서다 — ① USD는 레이어·참조(10.4) 로 씬을 합성하므로, 여러 출처의 변경을 비파괴적으로 겹치고 구독할 수 있다(한 사람 변경이 다른 레이어를 안 깸). ② USD는 참조(reference) 로 Nucleus의 공유 자산을 가리키니, 자산이 바뀌면 참조에 반영(라이브). ③ USD가 공통 데이터 모델이라 다른 도구(커넥터)가 같은 씬에 합류 가능. 즉 Nucleus는 "USD를 위한 실시간 협업 데이터베이스" — USD의 비파괴적 합성·참조 구조가 동시 편집·단일 진실원천을 가능케 한다. USD 없이는 이런 협업이 안 된다(포맷이 제각각이면 실시간 합성 불가). 정직: Nucleus 제품 형태는 재편이 잦으니 시점 확인.

연습 2 (RTX 모드). RTX 실시간 모드와 패스트레이싱 모드의 차이를 설명하고, 각각을 (a) 작성·협업 (b) 실시간 센서 시뮬(9.11) (c) 정확한 합성데이터(10.5) (d) 최종 마케팅 렌더에 어떻게 배정할지 답하라.

정답

차이: RTX 실시간(Real-Time) — 래스터화 + 레이트레이싱 효과(반사·그림자·AO·일부 전역조명)를 인터랙티브(수십 fps)하게, DLSS·AI 디노이징으로 빠르게. 충분히 사실적이되 물리적으로 완전하진 않음. RTX 패스트레이싱(Path-Traced) — 빛 경로를 완전 적분(전역 조명 정확)해 물리적으로 정확(레퍼런스 품질), 대신 느림(수렴에 많은 샘플·시간). 배정: (a) 작성·협업 → 실시간 — 인터랙티브해야 뷰포트에서 즉시 보며 작업·협업(10.2.3). 패스트레이싱은 너무 느려 작업 답답. (b) 실시간 센서 시뮬(9.11) → 실시간 — 로봇이 실시간으로 센서 입력을 받아야(SIL 9.12·인지 9.7~9.9), 프레임률이 중요. 단 비전 학습 충실도가 핵심이면 실시간 모드라도 사실성·노이즈 모델 신경. (c) 정확한 합성데이터(10.5) → 패스트레이싱(또는 고품질 실시간) — 학습 데이터의 사실성이 Sim2Real 갭을 정하니(9.11·10.5), 정확한 전역조명·그림자·반사가 중요하면 패스트레이싱. 대량이라 멀티 GPU·헤드리스 배치(10.1). 속도↔품질 균형으로 실시간을 쓰기도(데이터량이 많고 약간의 갭 허용 시). (d) 최종 마케팅 렌더 → 패스트레이싱 — 최고 포토리얼·정확이 목적, 인터랙티브 불필요, 시간 들여 수렴. 원리: 인터랙티브·실시간성이 필요(작성·운영·센서)하면 실시간, 물리 정확·최종 품질(정확 데이터·마케팅)이면 패스트레이싱. 혼동하면 작성이 느리거나(패스트레이싱 오용) 데이터가 부정확(실시간 오용). 머티리얼은 둘 다 MDL로 일관. 멀티 GPU·디노이징으로 양쪽 스케일·속도.

연습 3 (커넥터). 커넥터가 무엇이고 라이브 싱크가 어떻게 동작하는지 설명하고, 커넥터가 USD를 교환 허브로 쓰는 것이 N개 도구를 잇는 데 왜 유리하며 그 한계는 무엇인지 답하라.

정답

커넥터: Maya·Blender·3ds Max·Revit·CAD 등 이질적 기존 도구를 USD/Omniverse(Nucleus)에 연결하는 플러그인. 핵심 가치는 도구를 바꾸라고 강요하지 않는 것 — 아티스트는 Maya, 엔지니어는 CAD를 계속 쓰되 결과가 한 USD 씬에 모인다(전환 비용 없는 합류). 라이브 싱크 동작: 단순 export(일회 변환)를 넘어 실시간 양방향 연동 — 네이티브 도구에서 편집(모델 이동·조명 변경)하면 그 변경이 USD로 번역되어 Nucleus 씬에 즉시 반영(10.2.3 라이브 협업과 맞물림). "Maya에서 조명, Omniverse에서 즉시 본다". 도구의 네이티브 변경 ↔ USD 표현을 실시간 매핑. USD 교환 허브의 유리함: N개 도구를 서로 잇는다면, 쌍별 변환기는 N×(N-1) ≈ N²개 필요(Maya↔Blender, Maya↔CAD, Blender↔CAD…). 대신 USD를 허브로 두면 각 도구가 USD와의 변환 1개만 — N개 변환기(각 도구↔USD)로 충분. 새 도구가 와도 USD 변환 하나만 추가하면 모든 도구와 연결. 게다가 USD는 오픈 표준(10.3) 이라 점점 많은 도구가 네이티브 지원(커넥터 없이 USD 직접 읽고 씀)하는 추세 → 변환조차 불필요해지는 방향. 한계: ① 변환 손실 — 모든 도구의 고유 기능·표현이 USD로 완벽 매핑되진 않음(도구 특유의 절차·셰이더·리깅이 손실·근사). 지원 매트릭스 확인. ② 지원 범위 — 커넥터가 모든 도구·버전·기능을 다 지원하진 않음(릴리스 의존). ③ 라이브 싱크 복잡도 — 양방향 실시간은 충돌·성능 이슈 가능. ④ 네이티브 지원이 늘며 개선 중이나 아직 도구별 격차. 요지: 커넥터는 전환 비용 없이 기존 도구를 USD 허브로 잇는 다리이고, USD 허브가 N² 변환을 N으로 줄인다 — 단 변환 손실·지원 범위는 확인 필요. USD 네이티브 지원이 장기 해법.

연습 4 (집계 워크플로우). 로봇 작업 셀 디지털트윈을 만든다고 할 때, 세 기둥(Nucleus·RTX·커넥터)과 USD가 설계→시뮬→학습→운영을 어떻게 관통하는지 단계로 설계하라.

정답

단계 설계: ① 연결(커넥터) — CAD 엔지니어가 작업 셀 구조·기계·로봇을 CAD에서 설계 → 커넥터로 USD 변환·Nucleus 합류. 아티스트가 환경·바닥·재질을 Blender/Maya에서 → 커넥터로 USD. 각 전문가가 익숙한 도구로, 결과는 한 USD 씬. ② 협업(Nucleus) — 모두 Nucleus의 한 USD 작업 셀 씬에 라이브 합류, 동시 편집·즉시 전파(10.2.3). 설계 리뷰를 원격·다도구로 함께. 버전·권한으로 관리. ③ 렌더(RTX) — 실시간 모드로 설계 리뷰를 포토리얼로 함께 보며 수정, 필요시 패스트레이싱으로 정확한 검토 렌더. MDL 머티리얼로 일관. ④ 시뮬(Isaac Sim 9.11) — 같은 USD 씬을 Isaac Sim이 열어 로봇 아티큘레이션·PhysX 물리·RTX 센서를 추가 → 로봇이 작업 셀에서 움직이는 시뮬. ⑤ 학습/검증 — 합성데이터(10.5) 로 인지 모델 학습, RL(9.13·9.14) 로 매니퓰레이션·이동 정책, SIL(9.12) 로 Isaac ROS 스택(9.7~9.10) 검증 — 모두 같은 USD 씬 위에서. ⑥ 운영(디지털트윈 10.8) — 완성된 트윈을 실라인과 연동(센서·상태)해 모니터·이상 감지·what-if(레이아웃 변경 시뮬). USD가 관통: 설계(CAD/DCC)·협업(Nucleus)·렌더(RTX)·시뮬(Isaac Sim)·학습(데이터/RL)·운영(트윈)이 모두 같은 USD 씬(10.3·10.4) 을 공유·발전 — 단계마다 변환·재작업 없이 한 자산이 흐른다. CAD 설계 변경이 시뮬·트윈에 바로 반영(라이브). 가치: 비동기 파일 교환의 며칠 루프가 실시간 공동 작성으로, 설계가 곧 시뮬·학습·운영의 입력 → 빠른 반복·일관성. 자율주행 DRIVE Sim(8.15)도 같은 Omniverse(USD·RTX) 기반 — 도메인을 넘나드는 플랫폼. 정직: 제품 구성은 시점 확인, 커넥터 변환 손실 주의.

연습 5 (포토리얼리즘의 의미). RTX 포토리얼리즘이 "보기 좋은 그림"을 넘어 Sim2Real(9.11)·합성데이터(10.5)·디지털트윈(10.8)에 왜 중요한지, MDL이 그 일관성에 어떻게 기여하는지 답하라.

정답

포토리얼리즘이 미관을 넘는 이유: ① Sim2Real(비전, 9.11) — 시뮬로 학습한 비전 모델(인지 9.7~9.9)이 실세계서 작동하려면 시뮬 영상이 실영상과 닮아야 한다. RTX의 전역 조명·그림자·반사·물리 기반 재질이 사실적 영상을 만들어 갭을 좁힌다 → 전이 확률↑. 비현실 렌더면 모델이 시뮬 특유 외형에 과적합해 실세계서 취약. ② 합성데이터(10.5) — 시뮬이 만든 학습 데이터의 사실성이 그 데이터의 유용성을 정한다. 갭 큰 비현실 데이터로 학습하면 실세계 실패 → 정확한 전역조명·재질·센서 노이즈가 갭 작은 데이터를 만든다(특히 패스트레이싱). ③ 디지털트윈(10.8) — 트윈이 실물 같은 시각화로 설계 검토·운영 모니터·what-if를 신뢰성 있게 하려면 포토리얼이 필요(실물과 시각적 일치). 즉 RTX 충실도는 "보기 좋음"이 아니라 현실과의 거리(갭)를 줄이는 도구 — 갭이 학습·검증·검토의 신뢰성을 정한다. MDL의 기여: 포토리얼리즘은 재질의 빛 반응(금속의 반사, 유리의 굴절, 천의 산란)이 사실적이어야 완성된다. MDL(Material Definition Language) 은 이 물리 기반 재질을 이식 가능한 표준으로 정의 → ① 도구·렌더러 간 일관 — 같은 MDL 머티리얼이 Maya·Isaac Sim·뷰어 어디서나 같게 보임(10.2.5 커넥터로 도구를 옮겨도 재질 유지). ② 물리 기반 — 임의 셰이더가 아니라 실제 빛-재질 상호작용을 모델링해 사실적·예측 가능. ③ 재현성 — 합성데이터(10.5)·트윈(10.8)에서 재질이 일관되어야 데이터·시각화가 신뢰 가능. 즉 USD가 씬을, MDL이 재질을 표준화해, 포토리얼리즘이 도구·단계를 넘어 일관되게 유지된다 — 갭 축소가 한 도구에서만이 아니라 전 파이프라인에서. 정직: 포토리얼이 갭을 좁히되 없애진 못함(센서 노이즈·도메인 랜덤화 9.14도 필요), MDL 지원은 도구·버전 의존.

10.2.12 요약 · 다음 장

  • 세 기둥(Kit 10.1 위): Nucleus(협업)·RTX(렌더)·커넥터(연결)가 Omniverse를 협업 플랫폼으로 완성. USD(10.3)가 공통 언어.
  • Nucleus: USD 씬의 단일 진실원천 + 실시간 라이브 협업(버전·권한). "export·전송·머지"를 "한 씬을 모두가 실시간 공유"로. USD의 레이어·참조(10.4)가 이를 가능케.
  • RTX: 실시간(인터랙티브 — 작성·협업·센서) vs 패스트레이싱(레퍼런스 — 정확·최종). MDL(이식 가능 물리 기반 머티리얼). 포토리얼은 미관이 아니라 Sim2Real·합성데이터·트윈의 갭 축소 충실도(9.11·10.5·10.8).
  • 커넥터: 기존 도구(Maya·CAD)를 USD로 라이브 싱크 — 전환 비용 없이 협업 합류. USD 교환 허브(N² 변환 대신 N), 단 변환 손실·지원 범위 확인. USD 네이티브가 장기 해법.
  • 함께: 다도구·한 씬·실시간 → USD가 설계→시뮬→학습→운영 관통(디지털트윈 10.8·DRIVE Sim 8.15). 정직: 제품·라이선스 재편 잦음(확인), RTX는 워크스테이션/OVX(엣지 아님).

다음 장: 10.3 OpenUSD I — Stage·Prim·Layer. Omniverse의 모든 것(Kit·Nucleus·커넥터·시뮬)이 USD 위에 선다고 했다 — 이제 그 USD 자체의 데이터 모델로 내려간다. 씬을 담는 스테이지(Stage), 객체인 프림(Prim)·속성, 그리고 비파괴적 합성의 단위 레이어(Layer). Omniverse·Isaac Sim·디지털트윈이 왜 USD 위에 서는지를 데이터 모델의 기초부터.