콘텐츠 디렉토리 소개

지금까지 Unity에서 게임 에셋을 패키징하는 권장 방식은 에셋 번들(asset bundle)을 사용하는 것이었습니다. Unity 6.6부터는 게임 콘텐츠를 정리하는 과정을 크게 개선할 수 있는 새로운 도구가 등장했습니다. 바로 콘텐츠 디렉토리(Content directories)입니다. 이 비디오에서는 콘텐츠 디렉토리가 무엇인지, 어떻게 에셋 패키징 프로세스를 개선하는지, 어떻게 시작하는지, 그리고 마지막으로 언제 에셋 번들을 사용하는 것이 적절한지를 배울 것입니다. 콘텐츠 디렉토리가 무엇인지 설명하기 전에, 먼저 일반적인 에셋 패키징과 우리가 이를 통해 해결하려는 문제들에 대해 간략하게 이야기해 보겠습니다.

게임을 만들 때 모든 게임 콘텐츠를 게임 시작 시 메모리에 로드하는 것은 보통 좋지 않은 생각입니다. 이는 메모리 사용량 증가와 긴 시작 시간으로 이어져 사용자 경험을 저하시킵니다. 이를 피하기 위해, 우리는 게임 콘텐츠를 분리하고 더 상세하게 패키징하여 필요한 순간에만 로드합니다. 예를 들어, 레벨로 나뉜 전형적인 플랫포머는 각 레벨이 시작되기 직전에 해당 레벨의 콘텐츠를 로드하고, 레벨이 완료되면 언로드(unload)합니다. 전통적인 격투 게임의 경우, 싸움에 참여하는 캐릭터들, 그들이 싸우는 아레나 등만 로드할 수 있습니다.

이를 위해 Unity 개발자들은 역사적으로 에셋 번들에 의존해 왔습니다. 에셋 번들은 에셋들을 그룹화한 아카이브 파일입니다. 일반적으로 에셋들은 링크(link)를 통해 연결됩니다. 저희 플랫포머 예시에서, 레벨에 사용된 모든 프리팹(prefab), 그들이 참조하는 모든 3D 모델, 텍스처, 머티리얼(material), 심지어 장면 파일 자체까지 —이 모든 것이 에셋 번들에 포함되어 필요할 때 로드될 수 있습니다. 하지만 대규모 게임에서는, 에셋들을 어떤 방식으로 번들로 구성해야 할지, 몇 개를 만들어야 할지, 에셋들을 어떻게 분배해야 할지, 그리고 언제 메모리에서 안전하게 언로드할 수 있을지 결정하기가 빠르게 어려워집니다.

예를 들어, 이전 플랫폼 게임 예시에서 나무 프리팹(prefab)이 여러 레벨에 사용되었다고 가정해 봅시다. 기본적으로 이 프리팹은 여러 번 패키징되어 해당 레벨별로 생성되는 각 번들(bundle)에 포함됩니다. 이와 마찬가지로, 그것이 사용하는 재질(material), 텍스처 등 모든 종속성(dependency)도 동일하게 처리됩니다. 이는 빌드 크기를 불필요하게 크게 만들 수 있습니다. 이를 방지하려면 개발자가 의식적으로 이 나무를 별도의 에셋 번들(asset bundle)로 패키징하기로 결정해야 합니다. 이렇게 하면 두 레벨 모두 거기서 그것을 로드할 수 있게 되며, 중복 문제가 사라집니다.

이러한 세밀한 관리(micromanagement)가 특정 규모의 프로젝트에서 얼마나 빠르게 감당하기 어려워질 수 있는지 이해하실 수 있을 것입니다. 이러한 문제를 해결하기 위해 Unity 6.6은 에셋 번들(asset bundle)의 대안으로 콘텐츠 카탈로그(content catalog)를 도입합니다. 간단히 말해, 콘텐츠 카탈로그는 빌드 프로세스의 결과물이며, 로드하는 데 필요한 정보를 담고 있는 매니페스트(manifest)와 함께 일련의 아티팩트(artifact) 형태를 띱니다. 콘텐츠 카탈로그는 콘텐츠 패키징 및 로딩에 대한 더 세분화된 접근 방식에 기반하고 있기 때문에, 에셋 패키지(asset package)보다 여러 가지 장점을 가지고 있습니다.

첫째, 최적의 파일 I/O 패턴을 사용하는 새로운 병렬 로딩 시스템 덕분에 에셋 로딩이 빠릅니다. 또한 전체 패키지를 로드하는 대신 필요한 개별 에셋만 로드하기 때문에 더 적은 RAM을 필요로 합니다. 이는 또한 이 에셋들이 패키지 자체를 언로드할 때까지 기다릴 필요 없이 개별적으로 언로드될 수 있다는 것을 의미합니다. 둘째, 콘텐츠 빌드가 일반적으로 더 빠릅니다. 왜냐하면 콘텐츠 카탈로그는 마지막 빌드 이후 어떤 콘텐츠가 변경되었는지 추적하고 해당 콘텐츠만 업데이트 및 재빌드하기 때문입니다.

또한 콘텐츠 디렉토리는 여러 프로세스를 통해 생성되기 때문에 내장된 에셋 중복 제거 시스템을 갖추고 있어 파일이 빌드에 다시 추가되는 것을 방지합니다. 이는 에셋 패키지에서 자주 발생하는 문제이며, 개발자가 이를 피하기 위해 적극적인 노력을 기울여야 하는 부분입니다. 반면 콘텐츠 디렉토리에서는 자동화가 이 작업을 처리해 줍니다. 이제 실제로 콘텐츠 카탈로그를 시작하는 방법을 빠르게 살펴보겠습니다. Unity 6.6 가이드에는 이미 새로운 시스템으로 전환할 때 복사하여 붙여넣을 수 있는 코드 예제가 포함된 광범위한 섹션이 있다는 점에 유의하십시오.

링크는 이 비디오의 설명란에 있습니다. 콘텐츠 카탈로그는 루트 에셋(root assets) 개념을 사용하여 어떤 콘텐츠를 패키징할지 결정합니다. 루트 에셋은 스크립터블 오브젝트(scriptable objects)여야 하지만, 사용자 정의 타입을 정의할 수도 있습니다. 거기서부터 루트 에셋이 참조하는 모든 것은 콘텐츠 빌드에 포함됩니다. 게임에 적합한 개수만큼 하나 이상의 루트 에셋을 할당할 수 있습니다. 이는 사실상 콘텐츠 배포 전략의 진입점입니다. 다음 단계는 콘텐츠를 조립하는 것입니다. 이를 위해 빌드 파이프라인(build pipeline)을 호출하는 에디터 스크립트에서 모든 루트 에셋 경로를 매개변수로 전달해야 합니다.

그러면 시스템이 종속성을 추적하고 콘텐츠를 수집합니다. 이제 콘텐츠 카탈로그가 생성되어 사용 준비가 완료됩니다. 게임이 실행되는 동안, 스크립트는 루트 에셋을 시작점으로 사용하여 참조된 모든 다른 에셋을 검색하고 온디맨드(on demand)로 로드할 수 있습니다. 종속성 구조를 계획할 때, 단순히 직접적인 링크만 가진 루트 에셋만을 제공하는 것은 비논리적입니다. 이렇게 할 경우, 시스템이 루트 에셋을 로드할 때 관련 모든 에셋이 메모리에 로드되어 원래 상태로 돌아가게 됩니다.

이를 위해 콘텐츠 카탈로그와 함께 에셋 링크를 지연 로딩(defer loading)할 수 있는 새로운 도구들이 있습니다. 이것이 바로 loadable 클래스이며, 모든 유형의 에셋에 사용될 수 있고, loadable scene ID 구조는 특히 씬(scene) 에셋을 위한 것입니다. 링크를 loadable로 지정하면, 콘텐츠 카탈로그가 생성될 때 해당 에셋과 그 의존성들이 콘텐츠 어셈블리(content assembly)에 추가됩니다. 만약 loadable이 MonoBehaviour나 Scriptable Object에 직렬화(serialized)된다면, 코드 또는 인스펙터에서 loadable에 대한 참조를 할당할 수 있습니다.

런타임 시에는 먼저 게임이 콘텐츠 디렉토리의 존재를 인식하고 그 루트 에셋들을 로드해야 합니다. 이를 위해 콘텐츠 다운로드 매니저(content download manager)를 사용하게 됩니다. 콘텐츠 디렉토리를 등록하고 해당 경로를 전달합니다. 이렇게 완료되면, 모든 로드된 루트 에셋을 쿼리할 수 있으며, 거기서부터 load 또는 load async를 호출하여 필요에 따라 에셋들을 로드함으로써 loadable을 얻어낼 수 있습니다. 게임이 이 에셋들을 다 사용하면, 메모리를 해제하기 위해 loadable 객체에 release를 호출합니다. 이것으로 모든 것이 끝납니다. 요약하자면, 콘텐츠 카탈로그의 경우 다음 단계들을 따라야 합니다.

첫째, 루트 에셋들을 정의하고 다른 모든 에셋들을 직접 링크(direct links) 또는 loadables를 사용하여 그들에게 연결합니다. 둘째, 스크립트를 사용하여 콘텐츠 디렉토리들을 생성합니다. 셋째, 해당 디렉토리를 런타임 시에 사용할 수 있도록 만듭니다. 넷째, 이제 패키징된 다른 모든 에셋들에 접근할 수 있습니다. 그리고 마지막으로, 시간이 되면 그것들을 해제(release)합니다. 이러한 일부 작업들은 콘텐츠 디렉토리 위에 Addressables 패키지를 사용하여 자동화할 수 있습니다. 사실, 프로젝트가 이미 Addressables를 사용하고 있다면, 콘텐츠 디렉토리로 전환하는 것은 간단하며 Addressables groups 창에서 직접 수행할 수 있습니다.

Addressables를 사용한 콘텐츠 카탈로그 구현 방법은 다른 영상에서 다룰 예정입니다. 하지만 새로운 프로젝트를 시작하는 경우, 직접 사용하는 것을 권장합니다. 이는 프로젝트의 요구 사항에 맞춰 데이터를 구조화할 수 있는 완전한 유연성을 제공하며, 콘텐츠 카탈로그 고유의 에셋을 활용할 수 있게 해줍니다. 빌드 시스템을 메인으로 마이그레이션 할지 결정할 때 알아야 할 가장 중요한 점은 버전 6.6부터는 로컬 콘텐츠만 지원한다는 것입니다. 즉, 콘텐츠를 원격으로 배포하거나 플레이어가 애플리케이션을 설치한 후 추가 자료를 다운로드하려면, 이 지점에서 새로운 자료를 배포하기 위한 자체 메커니즘을 만들거나, 여전히 에셋 번들(asset bundles)에 의존하면서 콘텐츠 디렉터리(content directories)를 사용해야 합니다.

이 영상 시청 시간이 지나면 내용이 변경될 수 있으므로, 이 문제에 대한 업데이트는 Unity 매뉴얼을 참조해 주십시오. 저희가 이 간략한 소개 영상을 즐겁게 보셨기를 바랍니다. 또한, 이 시스템에 대해 더 잘 이해하려면 이 주제에 관한 다른 영상들도 확인해 보세요. 이 과정이 게임 리소스 관리의 부담을 덜어드려 멋진 게임 제작에 집중하실 수 있기를 바랍니다.