Unity 6.6, AssetBundles를 퇴역시키다: Slime Rancher 2 증분 빌드가 32분에서 3분으로
Unity가 6.6 버전에서 content directories를 내놓았다. 콘텐츠를 패키징하고 로드하는 새로운 방식으로, 엔진 개발진이 직접 AssetBundles의 대체물이라고 부르는 기능이다. 가장 큰 차이는 런타임이 이제 번들 전체가 아니라 개별 아티팩트를, 예컨대 특정 메시나 텍스처를 주소로 지정하고 로드하고 언로드한다는 점이다. 여러 팀이 수년간 그룹화 전략을 고민해 온 번들 구성은 더 이상 설계상의 결정 사항이 아니게 된다.
Unity가 제시한 수치는 실제 프로젝트에서 나온 것이다. Addressables에서 content directories로 이전한 Slime Rancher 2다. 증분 빌드는 32분 16초에서 3분 4초로, 클린 빌드는 58분 6초에서 37분 13초로 줄었다. 게임 빌드 용량은 4GB에서 2.88GB로 가벼워졌고, 로딩은 45초에서 30초로 약 3분의 1 빨라졌다. 측정은 M5 Max를 탑재한 MacBook Pro에서 Unity 6.6 Beta(6000.6.0b10)로 진행됐다.
왜 로딩 단위로서의 번들이 더 이상 맞지 않게 됐나
AssetBundle은 배포와 저장, 로딩의 나눌 수 없는 단위다. 의존성은 번들 수준에서 추적되고, 로드와 언로드도 통째로 해야 한다. 여기서 부수적인 작업이 모두 생겨난다. 에셋을 수작업으로 그룹에 배치하고, 의존성 사슬을 추적하고, 번들 사이에서 공용 리소스가 중복되는 문제와 씨름하는 일이다.
content directories는 구조가 다르다. Unity는 콘텐츠 주소 지정 저장소 방식을 사용한다. git의 바탕에 깔린 것과 같은 발상으로, 모든 콘텐츠 파일은 자기 내용의 해시로 이름이 붙고 주소가 지정된다. 중복 제거는 개발자의 과제에서 포맷의 속성으로 바뀐다. 다만 아티팩트끼리는 해시가 아니라 안정적인 식별자로 서로를 참조한다. 그러지 않으면 파일 하나를 고칠 때 사슬 전체의 해시가 연쇄적으로 바뀌기 때문이다. 식별자와 해시의 대응 관계는 빌드 매니페스트에 저장된다.
무엇을 빌드에 포함할지는 이제 에셋마다 표시를 다는 방식이 아니라 루트 에셋, 즉 평범한 ScriptableObject로 지정한다. 의존성은 자동으로 딸려 오며 번들이 아니라 개별 에셋 단위로 추적된다. 코드에는 Loadable<T>
타입이 생겼다. 엔진 수준의 로드 가능한 참조로, Loadable<Mesh> bodyMesh 형태의 필드를 선언한 뒤 bodyMesh.Load()를 호출하면 된다. 개별 에셋의 로드와 언로드는 동기 방식으로도, async/await를 통한 비동기 방식으로도 가능하다. Loadable이 참조하는 오브젝트는 빌드에는 들어가지만 요청되기 전까지 메모리에 올라가지 않는다. 로딩 자체는 읽기와 역직렬화 모두에서 완전히 비동기이며 플랫폼별 async API를 사용한다. 그 바탕에는 2022년 DOTS에 등장한 콘텐츠 파일 포맷이 깔려 있다.
이미 Addressables를 쓰고 있다면
Unity는 기존 프로젝트를 망가뜨리지 않았다. content directories는 Addressables 패키지와 호환되며, 이 패키지는 콘텐츠를 구성하는 인터페이스로 계속 남는다. 기존 프로젝트는 새 백엔드로 변환할 수 있다. Slime Rancher 2는 코드를 단 한 줄도 고치지 않고 이전했다. 변환 절차와 선택지 비교는 Addressables 문서에 설명돼 있다.
바뀌는 것은 애초에 무엇을 표시해야 하는가에 대한 접근법이다. Unity는 Loadable이 참조하는 에셋을 자동으로 빌드에 포함하고 중복도 알아서 제거하므로, 공용 의존성을 위해 별도의 번들을 만들 필요가 더는 없다. 문서는 프로젝트 전체에 루트 에셋을 하나만 만들 것을 권하며, 코드가 문자열 키로 많은 에셋을 로드한다면 루트를 여러 개 두는 대신 ScriptableObject를 에셋 목록으로 활용하라고 조언한다.
미리 알아둘 만한 제약
6.6에서 content directories는 로컬 콘텐츠, 즉 플레이어와 함께 배포되는 콘텐츠에서만 동작한다. 원격 전송과 설치 이후의 추가 다운로드에는 여전히 AssetBundles나 자체 메커니즘이 필요하다. 본격적인 무선 세분화 전송은 Unity 7 세대에서 제공하겠다고 Unity는 약속했으며, 자세한 내용은 2027년에 공개된다.
- BuildUsage
content directory는 런타임에 등록되며, 그 뒤부터 해당 에셋을 사용할 수 있다. 씬 역시 로드 가능한 참조를 통해 연결된다. 자세한 내용은 content directories에 관한 Unity 공식 문서에 설명돼 있다.
Unity는 왜 하필 지금 기반을 바꿔야 했나
content directories는 6.6의 개별 기능이라기보다 콘텐츠 스택 전체의 토대를 갈아 끼우는 일처럼 보인다. AssetBundle의 한계는 Addressables의 설계에서도 드러난다. 이 패키지를 다루는 작업의 상당 부분은 번들을 나눌 수 없다는 점을 보완하는 데 쓰였다. 기본 단위가 원자적으로 바뀌면 테크 아티스트와 빌드 엔지니어의 익숙한 작업 일부, 즉 그룹별 배치와 중복 사냥, 의존성 사슬의 수동 관리는 저절로 의미를 잃는다.
이 방향은 콘텐츠 주소 지정 저장소와 증분 빌드를 향한 업계 전반의 흐름과 맞아떨어진다. 같은 원리는 이미 오래전부터 버전 관리 시스템과 빌드 캐시에서 작동해 왔고, 큰 프로젝트에서는 무엇보다 반복 작업 시간에서 이득을 낸다. Slime Rancher 2 사례에서 증분 빌드가 10분의 1로 줄어든 것은 최종 빌드보다 수정과 확인을 반복하는 일상적 사이클에 영향을 준다. 팀이 근무 시간을 쏟는 지점이 바로 그곳이다.
그렇다고 Addressables가 사라지는 것은 아니다. 마이그레이션이 짜인 방식을 보면 이 패키지는 사용자 인터페이스로 남고, content directories가 그 아래 자리를 차지한다. Unity가 원격 전송을 Unity 7 세대의 새 기반에 묶어 둔 점을 감안하면, 이 백엔드로의 이전은 시간이 지나면서 콘텐츠의 세분화된 추가 다운로드를 위한 조건이 될 가능성이 크다. 오늘날 번들을 수작업으로 배치하며 굴러가는 프로젝트라면 변환을 미리 살펴보는 편이 좋다.
AssetBundles를 왜 이제야 퇴역시켰을까. Godot와 Unreal의 압박, Addressables에 쌓인 고충, John Riccitiello 퇴임 이후의 노선 변화 때문일까.