Content directories: Beyond the AssetBundle

오늘 Unity의 콘텐츠에 대해 약간 알아보기

Unity 2.1 이후로, 소박한 AssetBundle은 Player 바이너리 외부로 배포되는 Unity 콘텐츠의 기반이 되어 왔습니다. 지난 20년 동안 세계적인 대작들을 포함하여 엄청난 수의 게임들이 데이터 표현 방식으로 에셋 번들(AssetBundles)을 사용해 왔습니다.

기본적으로 각 에셋 번들은 배포, 저장 및 로딩을 위한 분할 불가능한 단위입니다. AssetBundle은 번들 수준에서 종속성을 추적하며, 효율성을 위해 함께 다운로드, 로드 및 언로드되어야 하는 더 큰 단일 모놀리식 단위(monolithic unit)를 형성합니다.

이러한 사양 때문에 제목이 에셋 번들 레이아웃을 정의하는 방식은 런타임 성능부터 다운로드 크기에 이르기까지 모든 것에 주요 요인입니다. 이는 AssetBundles를 직접 사용하든 Addressables 패키지를 통해 사용하든 사실입니다.

오늘 우리는 Unity 런타임에 대해 다른 이야기를 할 것입니다.

콘텐츠 디렉토리 소개

콘텐츠 디렉토리는 에셋 번들의 기반이 되는, 더 성능이 좋고, 더 세분화된 대체 기능입니다. 이들은 플레이어와 함께 배포되는 AssetBundles의 대안으로 Unity 6.6에서 오늘 이용 가능합니다. Unity 7 세대 동안 기술 스택은 전체적이고 세부적인 무선 전송(나중에 더 자세히 설명하겠습니다. 매우 멋집니다)을 처리하도록 확장될 것입니다.

에셋을 대규모 로드 가능한 단위로 베이킹하는 대신, 콘텐츠 디렉토리는 Unity 런타임에게 하드웨어 리소스를 완전히 활용하고 콘텐츠 중복 제거를 내재화하여 개별 아티팩트((메시, 텍스처 등))를 독립적으로 식별, 로드 및 언로드할 수 있는 기능을 제공합니다.

Unity 프로젝트에서 콘텐츠를 관리하는 것이 더 빨라진 빌드와 에셋 위치 및 AssetBundle 레이아웃에 대한 걱정이 줄어들어 그 어느 때보다 쉬워졌습니다.

당신이 구축하는 게임은 더 작고, 더 빠르며, 암시적으로 중복을 제거하고, 새로운 로드 가능한 참조 타입을 통해 전체 동적 메모리 관리에 접근할 수 있습니다. 플레이어와 함께 번들링된 콘텐츠에 Addressables를 사용하는 분들은 콘텐츠 디렉토리로 전환할 수 있으며, 이는 코드 변경 없이 가능합니다.

우리가 어떻게 이걸 만들었을까요? 파이프라인의 각 단계 내부를 살펴보겠습니다.

친숙한 기반: Build

2019년에 우리는 Unity 진지한 빌드 기반에 대해 무엇을 원하는지에 대해 논의하고 있었습니다. 모든 코어에서 병렬로 작동하고, 결정론적이며, 완전히 캐시되고, 머신 간에 빌드 데이터를 공유할 수 있는 것입니다. 알고 보니 저희 동료들 중 일부가 그 속성을 가진 API, 즉 에셋 임포트 프레임워크를 수년 동안 배포하고 있었던 것 같습니다.

그래서 콘텐츠 디렉토리 빌드 프로세스는 표준 에셋 임포터 프레임워크 내에서 실행됩니다. 각 에셋은 에셋 가져오기자에 의해 개별적으로 구축되며, 샌드박스화되고 프로세스 외부에서 실행됩니다. 빌드는 결정론적이며, 에셋 데이터베이스 캐싱, 모든 하드웨어 코어의 완전한 포화, 빠른 공유 빌드를 위한 네이티브 가속기 지원을 제공합니다.

이 빌드 시스템에 대해 들어본 것이 처음은 아닐 수 있습니다. 여러분 중 일부는 Unity 2023.1에서 살짝 언급했던 멀티 프로세스 빌드 파이프라인을 기억하실지도 모릅니다. 이것은 같은 기반입니다.

출력물은 매우 세부적인 아티팩트들의 느슨한 그룹, 이들 간의 종속성을 추적하는 작은 매니페스트, 그리고 빌드를 이전보다 훨씬 쉽게 이해할 수 있도록 하는 새로운 일련의 진단 파일입니다.

정말 간단합니다.

친숙한 기반: 주소 지정

콘텐츠 디렉토리를 빌드하고 아티팩트를 살펴보면, 각 아티팩트가 꽤 이상한 해시된 이름을 가지고 있다는 것을 알 수 있습니다.

c0152db4dd710be51b2decb997325f34.cf
f0a44ad4a4babd121543fd44032928e7.resS
4226b5c16a50dab6eff0f08dd1253d4b.resource

멋진 점은, 그것이 임의의 해시가 아니라는 것입니다. 대신, 콘텐츠 디렉토리 시스템은 Git 같은 기술에서 사용되는 동일한 콘텐츠 주소 지정 저장소 패턴을 사용합니다. 각 콘텐츠 파일은 내용의 해시로 이름이 지정되고 참조됩니다. 이 패턴은 Unity 런타임에 매우 유용한데, 네이티브 기능으로 콘텐츠를 암시적으로 중복 제거할 수 있게 해주기 때문입니다.

그렇다고 해도, 진정한 의존성 그래프를 가진 콘텐츠 주소 지정 가능 저장소는 높은 변경률의 위험이 있습니다. 두 아티팩트 사이의 가장 간단한 관계를 고려해 보십시오:

A → B

B와 B's 해시 변경 사항을 업데이트하세요. 안타깝게도 A가 B를 참조하기 때문에 A의 해시도 변경됩니다. 더 나쁜 것은 그것이 계층 전체로 파급된다는 것입니다.

대신, 아티팩트들은 콘텐츠 해시로 서로를 참조하는 것이 아니라 안정적인 ID를 통해 참조합니다. 빌드 매니페스트는 안정적인 ID를 콘텐츠 해시로 매핑하는 작은 조회 테이블을 유지합니다.

이것으로 런타임은 로드하는 데 필요한 모든 것을 갖추게 되었습니다!

친숙한 기반: Load

콘텐츠 디렉토리에서 우리는 매우 성능이 뛰어난 동적 로딩 시스템을 도입합니다.

콘텐츠 디렉토리가 마운트될 때, 로딩 시스템은 매니페스트를 읽고 아티팩트 간의 안정적인 ID 종속성을 해결합니다. 각 아티팩트를 완전히 독립적으로 로드하고 언로드할 수 있으며, 함께 위치한 아티팩트로부터의 오염이 전혀 없습니다 (에셋 번들 문제 기억하시죠 - 하나의 거대하고 분리할 수 없는 단위?) 사라짐.

DOTS 사용자들에게, 아티팩트의 기본 파일 형식도 꽤 익숙해 보일 수 있습니다. 콘텐츠 디렉토리는 2022년 DOTS에서 도입한 차세대 콘텐츠 파일 형식을 생성하고 로드하며, 4년 동안 멀티스레드 Entities 로딩을 구동했던 기술을 모든 에셋에 적용합니다.

이것은 읽기 및 역직렬화 작업 모두에서 완전히 비동기적인 로딩 시스템입니다. 이는 더 높은 로딩 대역폭과 플랫폼별 비동기 읽기 API의 활용을 의미합니다.

더욱 흥미롭게도, 콘텐츠 디렉토리 파운데이션은 Loadable라고 불리는 현대적인 로드 가능한 참조 타입을 Unity에 처음으로 가져올 수 있게 합니다.

Loadable bodyMesh;
bodyMesh.Load();

이것은 콘텐츠 디렉터리 기반 프로젝트를 위해 엔진에 직접 내장된 실제 로드 가능한 참조입니다. Loadable이 참조하는 객체는 빌드에 포함되지만, Loadable을 호출할 때까지 로드되지 않습니다. Coupling Loadables with the (매우) 익숙한 ScriptableObject 인터페이스를 사용하면 동적으로 로드되는 콘텐츠를 놀라울 정도로 빠르게 구성할 수 있습니다.

그것은 우리가 매우 기대하는 원칙입니다. 콘텐츠 디렉토리와 로드아블을 기반으로, Unity의 모든에셋은 캐릭터 생성기 조각부터 스트리밍 지형의 청크에 이르기까지, 에셋 번들 레이아웃이나 그룹 정의를 설계할 필요 없이 독립적으로 로드 및 언로드될 수 있는 단위가 될 수 있습니다.

Unity 대규모 게임을 만드는 것이 그 어느 때보다 쉬워졌습니다!

콘텐츠 디렉토리를 테스트에 투입하기: Slime Rancher 2

지난 몇 달 동안, 저희 파트너사 중 몇 군데가 게임으로 콘텐츠 디렉토리를 테스트할 수 있도록 친절하게 허락해 주었습니다.

예를 들어, 모노미 파크의 훌륭한 게임인 슬라임 랜처 2를 살펴보고, 콘텐츠 디렉터리로 전환함으로써 얻는 몇 가지 이점을 살펴보겠습니다. (슬라임 랜처가 스팀에서 이용 가능합니다!) 슬라임 랜처, 슬라임 랜처 2)

이 데이터는 MacBook Pro (M5 Max)에서 실행된 Unity 에디터 버전 Unity 6.6 Beta (6000.6.0b10)를 기반으로 합니다

멋진 점은 새로운 로딩 시스템의 이점이 사용자에게 즉시 보인다는 것입니다. 더 멋진 점은 Slime Rancher 2가 코드 변경 없이 콘텐츠 디렉토리로 전환된 기존 Addressables 프로젝트라는 것입니다.

Unity 생태계 전반의 게임들이 6.6에서 콘텐츠 디렉토리가 출시되면 무엇을 얻게 될지 솔직히 기대됩니다. 하지만 이것은 질문을 남깁니다. 원격 콘텐츠는 어떻습니까?

다음은 무엇인가: 원격 콘텐츠 전송

올해 Unite Seoul Roadmap Presentation에 참석하신 분들은 제이슨 맨이 다가오는 Unity 7 세대 동안 새로운 콘텐츠 디렉토리 기반이 원격 콘텐츠 전송을 훨씬 쉽게 만들 것이라고 언급했던 것을 기억하실 것입니다. 그것이 실제로 무엇을 의미하는지, 그리고 지금까지 논의한 내용들과 어떻게 연결되는지에 대해 간략하게 이야기해 봅시다.

요약하자면, 콘텐츠 디렉토리를 사용하면 아티팩트와 그 종속성을 고유하게 식별할 수 있는 작은 해시 기반 매니페스트를 갖게 됩니다. 질문은, 그 모든 유물들이 플레이어와 함께 배송되어야 하나요?

답은 단호한 거절입니다.

현대적인 HTTP 표준 덕분에 Unity 대량의 리소스 요청을 멀티플렉싱할 수 있게 되었습니다.

이를 콘텐츠 디렉토리 기반과 결합하면 런타임은 장치가 어떤 아티팩트를 누락했는지 정확히 파악하고, 해당 항목만 로컬 스토리지에 다운로드하여 로드할 수 있으며, 공존, 데이터 레이아웃 또는 종속 AssetBundle에 대해 걱정할 필요가 없습니다. 업데이트는 개별 아티팩트 수준에서 전파되며, 매니페스트가 콘텐츠 해시를 사용하여 작동하기 때문에 런타임은 어떤 아티팩트가 오래되었는지 저렴하게 알 수 있고 차이점만 가져올 수 있습니다.

이 근미래 Unity 런타임은 필요한 콘텐츠만 다운로드하여 개발 시간을 단축하고, 플레이어가 게임에 더 빨리 접속하게 하며, CDN 비용을 절감합니다.

저희는 2027년에 이 프로젝트에 대해 더 많이 공유할 예정입니다.

Unity 6.6에서 콘텐츠 디렉터리를 사용해 보세요

오늘 저희가 공유하는 것은 Unity 콘텐츠를 전반적으로 개편하기 위한 긴 여정의 첫 단계이며, 런타임 전반에 걸쳐 "기본 성능"을 구현하는 것입니다. 콘텐츠 디렉토리는 플레이어와 함께 배포되는 콘텐츠에 대해 6.6에서 사용할 수 있으며, Unity 7 세대에서 원격 콘텐츠를 처리하도록 확장될 예정입니다.

콘텐츠 디렉토리를 시작하려면 문서를 확인해 보시고, 피드백이 있으시면 연락해 주세요.

모노미 파크의 Friends 다시 한번 감사드립니다. 그들의 멋진 타이틀로 콘텐츠 디렉토리를 선보일 수 있도록 도와주셔서 감사합니다! (슬라임 랜처, 슬라임 랜처 2).