현대의 디지털 콘텐츠 제작, 특히 3D 그래픽 분야는 기하급수적으로 증가하는 복잡성과의 끊임없는 싸움입니다. 이 복잡성은 단순히 폴리곤 수의 증가를 넘어, 수많은 아티스트와 부서가 각기 다른 전문 소프트웨어를 사용하여 하나의 결과물을 향해 협업하는 과정에서 발생하는 데이터의 파편화, 워크플로우의 비효율성, 그리고 창의적 반복 작업의 제약이라는 근본적인 문제에서 비롯됩니다. 픽사 애니메이션 스튜디오(Pixar Animation Studios)의 Universal Scene Description(USD)은 이러한 문제에 대한 표면적인 해결책이 아닌, 3D 파이프라인의 근본적인 패러다임을 재정의하려는 전략적 시도에서 탄생했습니다. 이 파트에서는 USD가 단순한 파일 형식을 넘어, 제작 파이프라인의 시스템적 붕괴 위기 속에서 탄생할 수밖에 없었던 배경과 그 핵심 철학을 심도 있게 분석합니다.
USD가 등장하기 이전의 3D 제작 파이프라인은 파편화된 생태계로 특징지어졌습니다. 모델링, 애니메이션, 셰이딩, 라이팅, 렌더링 등 각 공정마다 최적화된 디지털 콘텐츠 제작(DCC, Digital Content Creation) 도구들이 사용되었고, 이들은 각기 고유의 데이터 모델과 독점적인 파일 형식을 기반으로 작동했습니다. 이러한 환경에서 스튜디오들은 애플리케이션 간에 데이터를 이동시키는 문제로 수십 년간 어려움을 겪었습니다. 데이터의 상호 운용성 부재는 스튜디오들이 커스텀 도구를 포함한 정교한 파이프라인을 구축하여 데이터 변환을 관리하게 만들었지만, 이는 근본적인 해결책이 되지 못했습니다.
이 문제의 심각성이 극명하게 드러난 결정적 계기는 2012년 개봉한 픽사의 장편 애니메이션 <메리다와 마법의="" 숲="">(*Brave*)의 제작 과정이었습니다.1 이 프로젝트를 통해 픽사는 기존의 씬 기술(scene description)이 감당할 수 없을 정도로 복잡해졌음을 인지하고, 근본적인 해결책의 필요성을 절감했습니다.1 당시 파이프라인은 너무 많은 API와 파일 형식으로 인해 압도적인 복잡성에 직면해 있었습니다.
문제의 본질은 단순히 ‘통합 파일 형식’의 부재가 아니었습니다. OBJ나 FBX와 같은 전통적인 교환 포맷들은 정적인 에셋(asset)을 한 애플리케이션에서 다른 애플리케이션으로 옮기는 데는 충분했지만, 동적이고 협업적인 씬을 구성하는 복잡한 관계, 오버라이드(override), 베리에이션(variation)을 기술할 수 있는 ‘어휘’가 부족했습니다. 즉, 위기는 데이터 인코딩의 문제가 아니라, 씬의 의미론적 표현(semantic expression)의 실패였습니다.
이러한 상황을 단계적으로 분석해 보면 문제의 구조가 명확해집니다. 첫째, 스튜디오는 다수의 전문 DCC 도구를 사용합니다. 둘째, 각 도구는 특정 작업에 최적화된 자체 내부 데이터 표현 방식을 가집니다. 셋째, 이들 간에 데이터를 이동시키기 위해서는 원본 데이터와의 실시간 연결이 끊어지는 ‘베이크 다운(baked-down)’된, 즉 정보 손실이 발생하는 교환 포맷을 사용해야만 했습니다. 이는 창의적인 반복 작업을 심각하게 저해하는 요인이었습니다. 넷째, <메리다와 마법의="" 숲="">처럼 씬의 기하학적, 조직적 복잡성이 증가함에 따라, 이렇게 파편화되고 베이크된 조각들을 모아 최종 씬을 조립하는 과정은 엄청난 '조정(wrangling)' 작업을 요구했습니다.
결론적으로 픽사는 더 나은 교환 포맷이 아닌, 모든 애플리케이션이 원본 데이터 구조를 파괴하지 않고 이해할 수 있는 ‘공통의 실시간 씬 기술 프레임워크’가 필요하다는 결론에 도달했습니다. 이것이 바로 USD가 ‘파일 형식’에서 ‘씬 기술 프레임워크’로 도약하는 근본적인 개념적 전환점이었습니다.
픽사는 USD를 개발하면서 세 가지 핵심 목표를 설정했으며, 이는 오늘날까지 USD의 기본 설계 철학으로 자리 잡고 있습니다.
subLayers 연산자를 통해 구현됩니다. 물론 모델링 아티스트가 약한 레이어에서 지오메트리 토폴로지를 변경했을 때 강한 레이어의 셰이딩 데이터가 자동으로 조정되는 마법 같은 해결책은 아니지만, 각 아티스트가 다른 사람의 작업을 지우거나 편집하지 않고 독립적으로 작업할 수 있게 해주며, 작업 내역에 대한 명확한 감사를 용이하게 합니다.이 세 가지 기둥은 독립적이지 않고 서로 깊이 연관되어 선순환 구조를 형성합니다. 공통 언어(기둥 1)는 협업을 위한 레이어링 시스템(기둥 2)을 가능하게 합니다. 그리고 고성능 아키텍처(기둥 3)는 이러한 레이어들의 실시간 구성(composition)을 실제 프로덕션 환경에서 실용적으로 만들어줍니다. 만약 성능이 뒷받침되지 않는다면, 비파괴적인 협업 모델은 너무 느려서 쓸모가 없게 되고, 아티스트들은 결국 더 느린 베이크 다운 워크플로우로 회귀하여 USD의 근본적인 목적을 무너뜨릴 것입니다.
이러한 상호 의존성은 다음과 같이 설명할 수 있습니다. 협업은 여러 아티스트의 ‘의견(opinion)’이 공존할 수 있는 시스템, 즉 레이어링 시스템을 필요로 합니다. 레이어링 시스템이 작동하려면, 레이어에 담기는 데이터(예: 트랜스폼, 재질 바인딩)를 기술하는 공통된 방법, 즉 ‘공통 언어’가 있어야 합니다. 실제 프로덕션에서 최종 씬은 수백, 수천 개의 레이어로 구성될 수 있습니다. 이 모든 파일을 읽고 각 의견을 실시간으로 해석하여 최종 ‘구성된’ 씬을 평가하는 것은 엄청난 계산 부하를 유발합니다. 만약 이 평가가 느리다면, 아티스트가 오브젝트 하나를 움직였을 때 뷰포트가 업데이트되기까지 수 분을 기다려야 할 것이고, 이는 창의적인 피드백 루프를 파괴합니다. 따라서 성능은 USD의 단순한 ‘기능’이 아니라, 협업적이고 비파괴적인 전체 패러다임을 가능하게 하는 ‘핵심 기술’입니다. 이 인과 관계야말로 USD의 전략적 탁월함의 정수라 할 수 있습니다.
USD는 픽사 내부 도구에서 시작하여 전 세계적인 오픈 소스 프로젝트로 전환되는 전략적 변화를 겪었습니다. 2016년, 픽사는 USD를 오픈 소스 코드로 공개하여 시각 효과(VFX) 및 애니메이션 산업의 표준이 될 수 있는 길을 열었습니다. 픽사는 모든 스튜디오가 동일한 복잡성 관리 문제에 직면하고 있으며, USD를 오픈 소스로 만들면 다른 주체들이 이를 개선하고 그 혜택을 모두와 공유할 수 있는 확장 가능한 형식이 될 것이라고 인식했습니다.
이러한 전략의 정점은 2023년 8월 1일, 픽사, 어도비(Adobe), 애플(Apple), 오토데스크(Autodesk), 엔비디아(NVIDIA)가 리눅스 재단(Linux Foundation)의 공동 개발 재단(JDF, Joint Development Foundation)과 함께 Alliance for OpenUSD(AOUSD)를 결성한 것입니다.1 AOUSD의 목표는 OpenUSD의 지속적인 개발, 진화, 표준화를 촉진하여 대규모 3D 프로젝트를 보다 관리하기 쉽고 효율적이며 창의적으로 만드는 것입니다.
AOUSD의 결성은 채택에 의해 주도되는 사실상의 표준(de facto standardization)에서 공식적인 명세에 의해 주도되는 법적인 표준(de jure standardization)으로의 전략적 전환을 의미합니다. 이는 장기적인 안정성을 위한 매우 중요한 단계이며, 소프트웨어 공급업체들이 겪었던 ‘빠르게 움직이는 목표물(fast-moving target)’ 문제를 해결하기 위한 것입니다. 이는 USD가 ‘픽사의 기술’에서 HTML이나 PDF와 같은 공공 유틸리티로 성숙하고 있음을 시사합니다.
이러한 전환의 배경을 살펴보면, 2016년 USD가 오픈 소스화된 이후 스튜디오와 소프트웨어 공급업체들은 놀라운 속도로 이를 채택하기 시작했습니다. 하지만 USD는 픽사 내부에서 여전히 활발하게 개발 중이었기 때문에, 안정적인 지원을 구현하려는 공급업체들에게는 ‘빠르게 움직이는 목표물’이었습니다. 이는 생태계에 마찰과 불확실성을 야기했습니다. 동시에 애플(AR), 엔비디아(실시간 협업) 등 주요 산업 플레이어들은 각자의 전략적 목표를 위해 USD의 엄청난 가치를 인식했습니다. 이들이 장기적이고 안정적인 상호 운용성을 확보하기 위해서는 끊임없이 진화하는 코드베이스가 아닌, 고정되고 신뢰할 수 있는 명세가 필요했습니다.
결론적으로, AOUSD는 바로 이 공식적인, 문서화된 명세를 만들기 위해 설립되었습니다. 이는 공급업체들의 안정성에 대한 요구를 충족시키는 동시에, 픽사가 내부적으로 혁신을 계속할 수 있도록 합니다. 즉, 안정적인 공개 표준과 최첨단 내부 구현을 분리하는 거버넌스 모델을 통해 전체 생태계가 견고한 기반 위에서 성장할 수 있도록 보장하는 것입니다.
이 파트는 USD의 기술적 핵심을 해부하여, 씬 그래프, 컴포지션 엔진, 렌더링 아키텍처 등 USD가 ‘어떻게’ 작동하는지에 대한 세분화되고 전문적인 설명을 제공합니다. 이 구성 요소들은 USD가 단순한 데이터 컨테이너를 넘어 동적인 씬을 기술하고 조작하는 강력한 프레임워크로 기능하게 하는 원동력입니다.
USD 씬은 프림(Prim, Primitive) 이라는 기본 객체들의 계층 구조로 이루어져 있습니다. 프림은 USD 씬의 기본 구성 단위로, 지오메트리, 카메라, 조명, 셰이더 등 씬을 구성하는 모든 것이 될 수 있습니다.
프림은 프로퍼티(Properties) 를 포함하며, 이는 두 가지 형태로 나뉩니다:
points)나 색상(color) 등이 여기에 해당합니다.프림과 프로퍼티는 모두 시간에 따라 변하지 않는 메타데이터(Metadata) 를 가질 수 있습니다. 메타데이터는 씬 데이터 자체보다는 파이프라인에서의 데이터 처리 방식을 제어하는 데 사용됩니다. 예를 들어, kind 메타데이터는 프림의 종류(예: 모델, 컴포넌트)를 정의하고, assetInfo는 에셋에 대한 정보를 담습니다.
이렇게 구성된 모든 레이어와 컴포지션 아크가 해석되어 최종적으로 생성된 씬은 스테이지(Stage) 라는 압축되고 고성능인 런타임 객체로 표현됩니다. 스테이지는 USD 씬의 실시간 뷰이며, 이를 통해 씬 데이터를 조회하고 편집할 수 있습니다.
어트리뷰트, 릴레이션십, 메타데이터의 구분은 USD의 핵심적인 설계 결정 사항입니다. 이는 ‘객체가 무엇인지(어트리뷰트)’와 ‘다른 객체와 어떻게 관련되는지(릴레이션십)’, 그리고 ‘파이프라인에서 어떻게 취급되어야 하는지(메타데이터)’를 명확하게 분리합니다. 이 분리는 컴포지션 엔진의 작동에 매우 중요합니다. 예를 들어, 모델링 부서는 지오메트리 어트리뷰트를 정의하고, 셰이딩 부서는 재질에 대한 릴레이션십을 비파괴적으로 추가하며, 레이아웃 부서는 해당 객체를 ‘캐릭터’로 분류하기 위한 메타데이터를 추가할 수 있습니다. 이 모든 작업이 동일한 데이터 블록을 수정하지 않고 이루어집니다.
전통적인 포맷은 이 모든 정보를 하나로 묶어 처리했을 수 있습니다. 하지만 USD는 데이터를 명시적으로 분리함으로써, 여러 부서가 동일한 프림에 대해 각기 다른 특정 프로퍼티에 자신의 ‘의견’을 충돌 없이 기여할 수 있게 합니다. 컴포지션 엔진은 이렇게 분리된 의견들을 깔끔하게 레이어링할 수 있으며, 이것이 바로 비파괴적 협업 워크플로우의 기반이 됩니다.
컴포지션 엔진은 USD의 가장 강력하고 독창적인 기능으로, 여러 소스로부터 씬 기술을 결합하여 하나의 통합된 뷰를 제공합니다. 이 엔진 덕분에 비파괴적 편집, 동시 협업, 대규모 씬 조립과 같은 USD의 핵심적인 장점들이 가능해집니다.
USD 씬은 여러 개의 Sdf.Layer 파일(.usd, .usda, .usdc)이 쌓여서 만들어집니다. 각 레이어는 씬에 포함된 프림들의 프로퍼티 값에 대한 ‘의견(opinion)’을 담고 있습니다. 이 레이어들이 합성(compose)될 때, 스택의 더 높은 곳에 위치한, 즉 더 ‘강한(stronger)’ 레이어의 의견이 더 낮은 곳의 ‘약한(weaker)’ 레이어의 의견을 덮어쓰게 됩니다. 이것이 바로 비파괴적 편집의 근본적인 메커니즘입니다. 아티스트나 부서는 베이스 데이터를 직접 수정하는 대신, 새로운 레이어에 변경 사항(의견)을 추가함으로써 작업합니다. 이로 인해 원본 데이터는 손상되지 않으며, 언제든지 특정 레이어를 켜거나 끔으로써 변경 사항을 적용하거나 되돌릴 수 있습니다.
컴포지션은 단순히 레이어를 쌓는 것을 넘어, ‘컴포지션 아크(Composition Arcs)’라 불리는 다양한 연산자 집합에 의해 구동됩니다. 각 아크는 씬을 구성하는 데 있어 고유한 목적과 규칙을 가집니다.
shot.usd) 파일이 레이아웃 부서의 layout.usd와 세트 드레싱 부서의 set.usd를 서브레이어로 포함할 수 있습니다.VariantSet은 ‘shadingVariant’와 같이 변형의 축을 정의하는 이름이고, Variant는 ‘Red’나 ‘Blue’처럼 해당 세트 내의 특정 선택지입니다.3 이를 통해 아티스트는 씬 컨텍스트에 맞게 에셋의 상태를 동적으로 전환할 수 있습니다.Inherits는 프림이 다른 ‘클래스’ 프림으로부터 의견을 상속받게 하여, 여러 객체에 걸쳐 대량의 편집을 적용할 수 있게 합니다. Specializes는 가장 약한 아크로, 다른 모든 의견에 의해 쉽게 덮어쓰일 수 있는 ‘기본값’ 또는 ‘템플릿’ 값을 제공하는 데 사용됩니다.모든 컴포지션 아크로부터 들어오는 수많은 의견들의 최종 결과는 LIVRPS라는 고정되고 결정론적인 알고리즘에 의해 결정됩니다: Local -> Inherits -> Variants -> References -> Payloads -> Specializes. 이 목록의 앞쪽에 있는 아크에서 온 의견일수록 ‘더 강하며’ 충돌이 발생했을 때 우선권을 갖습니다. 이 규칙은 USD의 ‘마법’과도 같아서, 아무리 복잡한 컴포지션이라도 그 결과는 항상 예측 가능하게 만듭니다.
LIVRPS 규칙의 엄격함은 예측 가능성을 보장하는 동시에, 파이프라인 설계에 있어 정교한 해결책을 요구하는 특정 과제를 만들어냅니다. </root> 프림 패턴은 이 고정된 강도 순서를 조작하기 위해 개발된, 직관적이지는 않지만 필수적인 기술의 대표적인 예입니다. 이는 고급 USD 사용이 단순히 규칙을 따르는 것을 넘어, 그 규칙 내에서 원하는 결과를 얻기 위해 데이터를 구조화할 수 있을 만큼 규칙을 깊이 이해하는 것을 포함함을 보여줍니다.
이 과정을 단계적으로 살펴보면, LIVRPS 규칙에 따르면 서브레이어에서 온 로컬 의견(Local Opinions)이 레퍼런스된 의견(Referenced Opinions)보다 강합니다. 일반적인 파이프라인에서는 shot.usd 파일이 layout.usd 파일을 서브레이어로 포함할 수 있습니다. 만약 layout.usd가 특정 에셋을 레퍼런스한다면, layout.usd 내의 모든 의견은 해당 레퍼런스에 대해 로컬 의견으로 간주됩니다. 그런데 만약 shot.usd 레이어에 있는 다른 레퍼런스가 layout.usd에 있는 의견보다 더 강하게 적용되기를 원한다면 어떻게 해야 할까요? LIVRPS 규칙 때문에 layout.usd가 서브레이어인 한 이는 어렵습니다.
</root> 트릭이 이 문제를 해결합니다. layout.usd를 서브레이어로 포함하는 대신, 그 파일의 최상위 <root> 프림을 레퍼런스합니다. 이렇게 하면 layout.usd의 의견들은 레퍼런스 아크를 통해 들어오게 되며, 이는 shot.usd의 다른 로컬 의견이나 레퍼런스보다 약해집니다.
이는 파이프라인 아키텍처에 대한 심오한 함의를 드러냅니다. subLayers와 references 사이의 선택은 단순히 의미론적인 것이 아니라, 강도 계층 구조에 대한 전략적 결정입니다. LIVRPS 규칙은 파이프라인 설계자들이 오버라이드가 씬 전체에 어떻게 전파될지를 제어하기 위해 레이어 스택을 어떻게 구조화할지 신중하게 생각하도록 강제합니다. </root>와 같은 패턴의 존재는 이 시스템이 이러한 의도적인 조작을 허용할 만큼 강력하다는 것을 보여줍니다.
아래 표는 LIVRPS 컴포지션 아크 계층 구조를 요약한 것입니다.
| 강도 순서 (Strength Order) | 아크 이름 (Arc Name) | 주 목적 (Primary Purpose) | 주요 특징 (Key Characteristics) | 표준 사용 사례 (Canonical Use Case) |
|---|---|---|---|---|
| 1 (가장 강함) | Local (via subLayers) |
씬/에셋의 기본 레이어 구성 | 다른 레이어들을 병합하여 단일 레이어 스택 형성. 리스트 편집 가능. | 여러 부서가 하나의 샷에서 동시에 작업 (예: 레이아웃, 애니메이션, FX 부서가 각자의 레이어에서 작업) |
| 2 | Inherits | 클래스 기반의 대량 오버라이드 | 여러 프림에 걸쳐 공통 속성을 일괄 적용. 인스턴스화 가능성을 유지하면서 편집 가능. | 숲 장면에 있는 모든 ‘OakTree’ 에셋의 모양을 한 번에 변경 |
| 3 | Variants | 단일 에셋 내의 다중 표현 관리 | 사용자가 정의된 변형 세트(VariantSet) 내에서 특정 변형(Variant)을 선택하여 전환. | 캐릭터 의상의 색상 변경, 지오메트리의 LOD(Level of Detail) 전환 |
| 4 | References | 씬 조립 및 에셋 재사용 | 외부 USD 파일을 씬으로 가져와 구성. 참조된 콘텐츠는 캡슐화되어 로컬 오버라이드가 더 강함. | 라이브러리에서 캐릭터, 소품, 환경 에셋을 가져와 샷을 구성 |
| 5 | Payloads | 대용량 데이터의 지연 로딩(Lazy Loading) | 레퍼런스와 유사하지만, 명시적으로 로드하기 전까지는 씬에서 제외됨. 성능 최적화에 필수적. | 고해상도 지오메트리나 텍스처를 포함하는 무거운 에셋을 초기 로드 시 제외 |
| 6 (가장 약함) | Specializes | 기본값 또는 템플릿 값 제공 | 다른 모든 아크에 의해 쉽게 오버라이드될 수 있는 기초 값을 설정. | 모든 ‘Vehicle’ 에셋에 대한 기본 재질 또는 물리 속성을 정의 |
하이드라(Hydra)는 USD의 이미징 프레임워크로, 씬 기술(scene description)을 렌더링 백엔드로부터 분리(decouple)하기 위해 설계되었습니다. 이는 USD의 ‘공통 언어’라는 약속을 시각적 영역에서 실질적으로 구현하는 핵심 기술입니다. 하이드라 아키텍처는 전통적인 ‘일대일’ 모델(하나의 애플리케이션이 자신만의 뷰포트 렌더러를 갖는)에서 벗어나, ‘다대다’ 파이프라인을 가능하게 하는 패러다임 전환을 이룹니다.
이 아키텍처는 세 가지 핵심 추상화 요소를 기반으로 합니다:
씬 델리게이트 (Scene Delegate / HdSceneDelegate): 소스 씬 그래프(USD 스테이지나 다른 애플리케이션의 내부 씬 등)로부터 데이터를 ‘가져와서(pulls)’ 하이드라가 이해할 수 있는 형태로 변환하는 인터페이스입니다. 오픈 소스 배포판에는 USD 스테이지를 위한 씬 델리게이트인 UsdImaging이 포함되어 있습니다.
렌더 델리게이트 (Render Delegate / HdRenderDelegate): 씬 델리게이트로부터 데이터를 받아 특정 렌더링 백엔드(예: OpenGL, Vulkan, Arnold, RenderMan 등)를 위한 렌더링 명령어로 변환하는 인터페이스입니다. 하이드라는 픽사의 실시간 래스터라이저인 HdStorm, 인텔의 레이 트레이싱 라이브러리를 사용하는 HdEmbree 등을 기본으로 제공하며, 다른 렌더러들도 플러그인 형태로 쉽게 추가할 수 있습니다.4
렌더 인덱스 (Render Index / HdRenderIndex): 하나 이상의 씬 델리게이트를 하나의 렌더 델리게이트에 연결하는 중앙 관리자 역할을 합니다. 씬에서 무엇이 변경되었는지 추적하고, 필요한 데이터만 다시 동기화하고 다시 그리도록 보장하여 고성능을 유지합니다.4 뷰포트(
usdview)에서는 현재 선택된 프림을 노란색으로 강조 표시하는 등의 시각적 피드백도 관리합니다.
이러한 구조 덕분에, 씬 델리게이트만 있다면 어떤 씬 그래프든, 렌더 델리게이트만 있다면 어떤 렌더러든 하이드라 생태계에 통합될 수 있습니다. 예를 들어, Houdini의 Solaris 환경이 Karma, RenderMan, Arnold 렌더러를 동일한 뷰포트에서 원활하게 전환할 수 있는 이유는 Solaris가 하이드라 기반 환경이기 때문입니다. 하이드라가 보편적인 어댑터 역할을 하여 전례 없는 렌더러 상호 운용성과 파이프라인 초기 단계에서의 룩뎁(look-dev) 일관성을 제공하는 것입니다.
최근 하이드라는 하이드라 2.0으로 진화하고 있습니다. 기존의 HdSceneDelegate API는 HdSceneIndex라는 새로운 API로 대체되고 있습니다. 이 새로운 아키텍처는 렌더러가 ‘플래튼(flatten)’되지 않은, 즉 컴포지션 이전의 원시 씬 데이터에 접근하는 등 더 큰 유연성을 제공하여, 동적 값 해석과 같은 고급 기능을 가능하게 합니다.
이 파트에서는 이론에서 실천으로 초점을 옮겨, USD가 실제 프로덕션 환경에서 어떻게 구현되고 있는지, 도입 과정에서의 도전 과제는 무엇인지, 그리고 기존의 확립된 포맷들과 비교하여 어떤 위치를 차지하는지를 분석합니다. USD의 잠재력은 그것이 다양한 소프트웨어와 워크플로우에 얼마나 깊이, 그리고 효과적으로 통합되는지에 따라 결정됩니다.
USD의 채택은 소프트웨어 공급업체마다 다른 수준의 성숙도를 보입니다. 이는 각 애플리케이션의 아키텍처 철학과 USD의 핵심 원칙이 얼마나 잘 부합하는지를 반영합니다.
exportSkin, exportVisibility 등 다양한 플래그를 통해 가져오기/내보내기 동작을 제어할 수 있지만, 특정 데이터 유형의 완전한 왕복(round-trip) 지원이나 복잡한 애니메이션 지원에는 여전히 한계가 존재합니다.7이처럼 USD 통합의 성숙도는 ‘깊은 통합’(Houdini/Solaris), ‘실시간 연결’(Unreal), ‘포맷 교환’(Blender)의 스펙트럼을 형성합니다. 각 DCC에서의 USD 지원 수준은 단순히 개발 자원의 문제가 아니라, USD의 핵심 철학(외부 컴포지션)이 해당 애플리케이션의 고유한 아키텍처 철학과 얼마나 잘 조화되는지를 반영하는 결과입니다. 아래 표는 주요 콘텐츠 제작 도구에서의 USD 통합 현황을 요약한 것입니다.
| 소프트웨어 (Software) | 통합 수준 (Integration Level) | 씬 저작/조립 (Scene Authoring/Assembly) | 하이드라 뷰포트 지원 (Hydra Viewport Support) | 주요 강점 / 한계점 (Key Strengths / Limitations) |
|---|---|---|---|---|
| Houdini (Solaris) | 깊은/네이티브 (Deep/Native) | 매우 강력함 (노드 기반 LOPs) | 완벽 지원 (Karma, RenderMan, Arnold 등) | 강점: 절차적, 비파괴적 워크플로우의 정점. 모든 USD 기능을 완벽하게 제어. 한계점: 학습 곡선이 가파름. |
| Autodesk Maya | 플러그인 기반 (Plugin-based) | 지원 (USD Layer Editor) | 지원 (Arnold 등) | 강점: 기존 Maya 워크플로우와 통합. USD와 네이티브 데이터 공존. 한계점: 일부 데이터의 왕복(round-trip)이 완벽하지 않음. |
| Unreal Engine | 실시간 연결 (Live Link) | 제한적 (USD Stage Editor) | N/A (자체 렌더링 엔진 사용) | 강점: 가상 프로덕션을 위한 실시간, 비파괴적 워크플로우. 대규모 씬의 효율적 처리. 한계점: 엔진 내에서의 직접적인 씬 저작 기능은 제한적. |
| Blender | 가져오기/내보내기 (Import/Export) | 미지원 | 제한적 (Hydra Storm 플러그인 존재) | 강점: 기본적인 에셋 교환 가능. 오픈 소스 생태계. 한계점: 레이어, 베리언트 등 고급 기능 지원 미흡. 파이프라인 통합 수준이 낮음. |
USD, Alembic, FBX, glTF는 3D 데이터 포맷 생태계에서 각기 다른 역할을 수행하며, 이들을 단순 경쟁 관계로 보는 것은 오해를 낳을 수 있습니다. 각 포맷은 디지털 콘텐츠 수명 주기의 특정 단계에 최적화되어 있으며, USD는 그 여러 단계를 아우를 수 있는 다재다능함으로 인해 기존의 경계를 허물고 있습니다.
이 네 가지 포맷은 서로를 대체하는 경쟁자가 아니라, 디지털 콘텐츠 수명 주기의 각기 다른, 때로는 겹치는 영역을 차지하는 도구 모음으로 이해하는 것이 더 정확합니다. 일반적인 파이프라인은 저작(USD) –» 캐싱(Alembic/USD) –» 교환(FBX/USD) –» 전송(glTF/USDZ) 의 흐름을 따를 수 있습니다. 혼란이 발생하는 이유는 USD가 이 수명 주기의 여러 단계에서 역할을 수행할 수 있을 만큼 다재다능하기 때문입니다. 현재의 주요 추세는 USD가 더 우수한 캐시 포맷으로서 Alembic의 역할을, 더 현대적인 교환 포맷으로서 FBX의 역할을 점차 잠식하고 있다는 것입니다. glTF와의 관계는 AOUSD와 크로노스 그룹 간의 협력 관계 수립에서 알 수 있듯이, 경쟁보다는 보완에 가깝습니다. 즉, 파이프라인에서 USD로 저작한 후 최종 결과물을 glTF로 내보내 웹에 배포하는 워크플로우가 점차 보편화될 것입니다.
아래 표는 주요 3D 교환 포맷들을 비교 분석한 것입니다.
| 기능 (Feature) | Universal Scene Description (USD) | Alembic (.abc) | FBX (.fbx) | glTF (.gltf/.glb) |
|---|---|---|---|---|
| 씬 구성 (Scene Composition) | 매우 강력함 (레이어, 레퍼런스, 페이로드 등) | 미지원 (지오메트리 캐시만 저장) | 제한적 (계층 구조 지원) | 지원 (씬 그래프, 노드 기반) |
| 비파괴 편집 (Non-Destructive Editing) | 핵심 기능 (LIVRPS 규칙 기반 오버라이드) | 미지원 | 미지원 | 미지원 |
| 애니메이션 데이터 (Animation Data) | 지원 (시간 샘플링, 스켈레톤, 블렌드 셰이프) | 지원 (정점 캐시, 트랜스폼) | 강력하게 지원 (스켈레톤, 키프레임) | 지원 (스켈레톤, 키프레임) |
| 재질/셰이딩 모델 (Material/Shading) | 확장 가능 (UsdPreviewSurface, MaterialX) | 미지원 | 지원 (기본 재질, 셰이더) | 강력하게 지원 (PBR 기반) |
| 주 사용 목적 (Primary Use Case) | 저작(Authoring), 교환(Interchange), 캐시(Cache) | 캐시(Cache) | 교환(Interchange) | 전송(Delivery) |
| 개방형 표준 (Open Standard) | 예 (AOUSD에 의해 표준화 진행 중) | 예 (오픈 소스) | 아니요 (독점 포맷) | 예 (크로노스 그룹) |
이 마지막 파트에서는 USD의 미래를 조망하며, 그 발전을 주도하는 전략적 이니셔티브와 메타버스 및 산업 디지털화의 기본 프로토콜이 될 잠재력을 분석합니다. USD의 기술적 우수성을 넘어, 그것이 산업 표준으로 자리 잡기 위한 거버넌스, 로드맵, 그리고 생태계 협력의 중요성을 탐구합니다.
Alliance for OpenUSD(AOUSD)는 2023년 8월, 픽사, 어도비, 애플, 오토데스크, 엔비디아라는 3D 산업의 거물들이 창립 멤버로 참여하여 리눅스 재단의 공동 개발 재단(JDF) 산하에 설립된 비영리 단체입니다.1 AOUSD의 핵심 임무는 OpenUSD의 표준화, 개발, 진화, 그리고 성장을 촉진하는 것입니다.
그 목표는 단순히 파일 형식을 유지하는 것을 넘어, 다양한 소프트웨어와 플랫폼에서 USD 데이터가 예측 가능하고 일관되게 작동하도록 보장하는 공식적인 문서화된 명세(written specification) 를 제공하는 데 있습니다. 이 명세는 다른 표준화 기구가 자신들의 기술 이니셔티브를 지원하기 위해 OpenUSD를 참조할 수 있는 안정적인 기반을 마련해 줄 것입니다.
AOUSD는 운영 위원회(steering committee)의 감독 아래, 핵심 명세, 재질, 지오메트리, 물리 등 특정 영역에 초점을 맞춘 여러 워킹 그룹(Working Groups)을 통해 운영됩니다. 이러한 구조는 기술적, 비즈니스적, 커뮤니티 리더들이 협력하여 OpenUSD 기술 스택의 미래 기능과 방향을 결정하고, 3D 세계가 어떻게 기술되고 상호작용할지에 대한 핵심 기능의 구조를 정의하는 체계적인 프로세스를 보장합니다.
AOUSD의 2년 로드맵의 중심에는 공식적인 다중 파트 핵심 명세(Core Specification) 의 작성이 있습니다. 2025년 3분기경 최종 비준을 목표로 하는 이 로드맵은, USD의 가장 근본적이고 낮은 수준의 측면에 먼저 초점을 맞추는 전략을 취하고 있습니다. 이는 마치 집을 지을 때 장식을 하기 전에 기초부터 튼튼히 다지는 것과 같습니다. 이 ‘레이어 케이크(layer cake)’ 접근 방식은, 표준이 관리 불가능한 거대한 덩어리가 되는 것을 방지하고, 각기 다른 도메인이 자신만의 속도로 발전할 수 있도록 합니다.
로드맵은 다섯 가지 핵심 영역으로 구성됩니다:
PcpMuseum 테스트 케이스를 기반으로, LIVRPS 컴포지션 아크가 작동하는 방식에 대한 규범적인 명세를 제공합니다.이러한 로드맵의 체계적인 접근은 상호 운용성의 근본적인 문제를 해결하려는 의도를 명확히 보여줍니다. 상호 운용성은 두 개의 다른 구현체가 동일한 파일을 다르게 해석할 때 깨집니다. 예를 들어, .usdc 파일의 바이트 레이아웃이나 reference와 inherit의 강도 순서에 대해 서로 다른 해석을 한다면 데이터는 망가질 것입니다. 따라서 가장 먼저 표준화해야 할 가장 중요한 것은 파일 형식 자체와 컴포지션 엔진의 규칙(LIVRPS)입니다. 이것이 바로 ‘핵심 명세’의 역할입니다. 표준 재질 모델과 같은 고수준 개념도 상호 운용성에 필요하지만, 이는 핵심 명세가 안정적이라는 전제 하에 구축될 수 있습니다. 즉, 저장된 파일을 읽는 방법에 대한 합의 없이는 표준 재질을 정의할 수 없습니다. 이처럼 로드맵은 기초를 먼저 다지는 하향식 접근 방식을 통해, 결과적으로 만들어질 표준이 진정으로 견고하고 다양한 공급업체와 애플리케이션에서 신뢰성 있게 구현될 수 있도록 보장합니다.
AOUSD의 비전은 핵심 명세를 넘어, USD를 3D 데이터의 모든 형태를 아우르는 중심 허브로 만드는 데 있습니다. 이는 도메인 특화 워킹 그룹의 설립과 다른 표준화 기구와의 협력을 통해 구체화되고 있습니다.
재질(Materials), 지오메트리(Geometry), 물리(Physics) 와 같은 전문 워킹 그룹의 출범은, 미디어 및 엔터테인먼트를 넘어 다른 산업 분야에 필요한 표준 스키마를 정의하려는 AOUSD의 의지를 보여줍니다. 예를 들어, 물리 워킹 그룹은 강체(rigid-body) 물리 명세 수립을 시작으로, 변형체 및 연체(deformable and soft-body) 물리 영역으로 확장할 계획입니다. 이는 다양한 시뮬레이션 시스템이 공통된 USD 표현을 통해 상호 운용될 수 있는 표준화된 프레임워크를 만드는 것을 목표로 합니다.
더 나아가, AOUSD는 다른 표준화 기구와의 협력 관계를 구축하고 있습니다. 가장 주목할 만한 것은 크로노스 그룹(Khronos Group) 과의 협력입니다. 이 협력은 3D 씬 구성 및 저작을 위한 OpenUSD와, 웹을 포함한 다양한 플랫폼에서의 효율적인 전송 및 로딩을 위한 3D 에셋 표준인 glTF 간의 정렬과 상호 운용성을 극대화하는 것을 목표로 합니다.
이러한 움직임은 AOUSD가 실행하는 이중 전략을 명확히 보여줍니다: (1) 핵심 언어(Core Spec)를 공고히 하고, (2) 각기 다른 산업에 필요한 도메인 특화 어휘(스키마)를 구축하는 것입니다. 이 전략은 OpenUSD를 다른 전문 데이터 포맷과 표준을 포함하고 조율할 수 있는 ‘상위 구조(super-structure)’ 또는 ‘메타 표준(meta-standard)’으로 자리매김하게 합니다. 이는 USD가 미디어 및 엔터테인먼트 산업을 넘어 산업용 디지털 트윈, 건축, 제조, 그리고 웹을 위한 기술 언어가 되어, 궁극적으로 ‘3D의 HTML’이라는 비전을 실현하는 경로입니다.
이러한 비전은 에픽게임즈(Epic Games), 유니티(Unity)와 같은 게임 엔진 개발사, 사이드FX(SideFX), 파운드리(Foundry)와 같은 VFX 툴 개발사, 그리고 이케아(IKEA), 메타(Meta)와 같은 기업들이 AOUSD에 합류하면서 더욱 힘을 얻고 있습니다. 이처럼 광범위한 산업 참여는 OpenUSD가 진정한 범용 표준으로 나아가고 있음을 증명합니다.
Universal Scene Description(USD)은 픽사의 내부적인 필요에서 출발하여, 3D 콘텐츠 제작의 근본적인 복잡성을 해결하는 산업 전반의 패러다임 전환을 이끌고 있다. 단순한 파일 형식을 넘어, USD는 비파괴적 레이어링, 컴포지션 아크, 그리고 플러그형 렌더링 아키텍처(Hydra) 라는 강력한 개념들을 통해 데이터의 파편화를 극복하고 전례 없는 수준의 협업과 반복 작업을 가능하게 하는 정교한 씬 기술 프레임워크이다.
본 보고서의 분석을 통해, USD의 성공은 세 가지 핵심 철학-공통 언어, 동시 협업, 성능 극대화-의 유기적인 결합에 기인함을 확인했다. 특히, 고성능 아키텍처는 실시간으로 복잡한 씬을 구성하고 시각화하는 것을 실용적으로 만들어, 비파괴적이고 협업적인 워크플로우를 뒷받침하는 결정적인 역할을 한다.
USD의 생태계 통합은 Houdini의 Solaris와 같은 깊이 있는 네이티브 구현부터 Unreal Engine의 실시간 연결, 그리고 Blender의 점진적인 파일 교환 지원에 이르기까지 다양한 성숙도를 보인다. 이는 각 소프트웨어의 아키텍처 철학이 USD의 분산적이고 구성적인 모델과 어떻게 상호작용하는지를 보여주는 흥미로운 사례 연구이다. 또한, Alembic, FBX, glTF와 같은 기존 포맷들과의 비교는 USD가 특정 역할을 대체하기보다는, 저작에서부터 최종 전송에 이르는 전체 디지털 콘텐츠 수명 주기를 아우르는 ‘메타 포맷’으로서의 잠재력을 가지고 있음을 시사한다.
미래를 내다볼 때, Alliance for OpenUSD (AOUSD) 의 설립은 USD가 ‘픽사의 기술’에서 진정한 공공 유틸리티로 전환되는 중대한 전환점이다. 2025년을 목표로 하는 핵심 명세 로드맵은 안정적이고 예측 가능한 표준을 제공함으로써, 더 넓은 산업 채택을 위한 견고한 기반을 마련하고 있다. 재질, 지오메트리, 물리 등 도메인 특화 워킹 그룹의 활동과 크로노스 그룹과의 협력은 USD가 미디어 및 엔터테인먼트를 넘어 산업용 디지털 트윈, 건축, 그리고 웹을 위한 보편적인 기술 언어, 즉 ‘3D의 HTML’이 되고자 하는 거대한 비전을 향해 나아가고 있음을 명백히 보여준다.
결론적으로, USD는 기술적 혁신과 전략적 개방성이 결합될 때 얼마나 강력한 시너지를 낼 수 있는지를 증명하는 사례이다. 앞으로 수년간 AOUSD를 중심으로 이루어질 표준화 작업과 생태계 확장은 3D 데이터가 생성, 공유, 경험되는 방식을 근본적으로 변화시킬 것이며, 모든 산업 분야에서 상호 운용 가능한 3D 세계의 초석이 될 것이다.
| Universal Scene Description | OpenUSD - Autodesk, accessed July 10, 2025, https://www.autodesk.com/solutions/universal-scene-description |
| Universal Scene Description (USD) in Unreal Engine | Unreal …, accessed July 10, 2025, https://dev.epicgames.com/documentation/en-us/unreal-engine/universal-scene-description-usd-in-unreal-engine |
| USD Stage Editor Quick Start in Unreal Engine | Unreal Engine 5.6 …, accessed July 10, 2025, https://dev.epicgames.com/documentation/en-us/unreal-engine/usd-stage-editor-quick-start-in-unreal-engine |