[Unity]Addressable asset 기본 개념

서론

 이 글은 유니티의 Addressable asset system의 기본 개념에 관련된 글입니다. 이전 글인 [Unity] Asset bundle 기본 개념과 이어지는 내용이며, Asset bundle의 제약사항을 Addressable asset system에서는 어떻게 개선되었는지가 주 내용입니다.  제가, The pinkfong company 재직 때 직접 작성한 사내 블로그 글을 개인 블로그로 옮긴 것입니다. 이 글은 다음과 같은 사전 지식이 있으면 훨씬 이해하기 편하며, 어느 정도 지식이 있다는 가정 하에 진행되어 일부 간략한 설명이나 생략되는 내용들이 있을 수 있습니다.

• Unity의 Asset 개념
• Unity의 예약 폴더인 Resources 폴더와 Resources.Load() 기능
• Unity의 Asset Bundle

참고 : Addressable asset system 공식 링크
https://docs.unity3d.com/Packages/com.unity.addressables@1.18/manual/index.html

---

기존 Asset bundle system과 다른 점은?

Asset Bundle만 사용하다가 Addressable asset을 도입하게 된 이유는 아래의 주요한 단점들 때문이었습니다.

위에서 말했듯, Addressable Asset = Asset Bundle + 관리 시스템이라고 정리할 수 있습니다. 그렇다면 Asset Bundle의 단점을 그대로 가지고 가는 게 아닌가? 하는 의문이 있을 수 있습니다. 관리 시스템이 붙으면서 생긴 구조가 이를 해결해주었습니다.

 

1. 번들 의존성 관리: Group과 Label (Key)

Group은 Bundle 단위입니다. Group 단위로 Bundle 이 생성됩니다.
Group 내 Asset에는 각각의 ID(Key) 와 같은 부류라는 GameObject의 Tag와 같은 개념인 Label을 기입할 수 있습니다. 이로 인하여 다음과 같이 구조가 변경되었습니다.

[그림1. 번들에서 Asset을 사용하기 위한 간단한 구현 흐름]

[그림2. Addressable asset의 번들 구조 도식화]

그림에서 비교되듯이, 구현 흐름이 간단해졌습니다. Addressable asset은 번들의 Download & Load 단계에서, 사용할 Asset들의 의존성(설계상 Label이나 Key로 제대로 기입되었다는 게 전제가 됩니다.)을 API에서 일괄 관리해줍니다. Label(Key) 관리만 해준다면 기존 Asset Bundle의 의존성에 의한 중복이나 수동 관리는 해결할 수 있었습니다.

 

2. 번들 버전 관리의 까다로움 : Catalog

Catalog란, Asset의 Address(Group, Label 정보 포함)와 Asset의 매핑 정보가 기재된 파일입니다. 이러한 Catalog 덕분에
1번의 단점 해결은 물론 번들 자체의 버전도 관리가 됩니다. Catalog는 Addressable의 번들과 함께 생성되는 녀석인데 Catalog의 버전이 붙어서 생성됩니다.

[그림3,4. Catalog에 기재된 번들을 읽는 구조 도식화]

 앱을 배포할 때 앱이 사용할 Catalog의 버전이 함께 기재되기 때문에, 저장소에 사용할 Catalog와 번들만 존재한다면 새롭게 배포하는 Catalog와 번들 때문에 문제가 생길 여지는 사라지게 됩니다.

[그림 5. Catalog 하위 호환성을 보장하는 방식]

3. 번들에 들어 있는 Asset Path 변경 공수 : Address (참조)

기존 번들의 Asset들은 Path가 통짜로 들어가서 외부 코드에서 사용하고 있을 때 Path 값을 똑같이 맞춰줘야 했습니다. 즉, 한쪽이 변경된다면 다른 쪽도 바꿔줘야 해서 번거로웠습니다. 번들의 Asset 이름만 변경되더라도 Path가 변경되기 때문에 생각보다 빈번하게 일어날 수 있는 일입니다.

 Addressable Asset의 이름에서 볼 수 있듯이 Address (참조) 방식을 사용합니다. 그렇다면 무엇을 참조하는 것이냐? 바로 Asset의 path입니다.

[그림 6. Address 를 이용한 Asset 참조]

 위 그림의 설명에서 볼 수 있듯이, Path 를 참조하는 값만 처음에 맞춰서 작업해 놓는다면 번들 내부의 Path 가 바뀌더라도 기존 번들 방식에서처럼 코드를 바꾸는 번거로움은 사라집니다.

---

마무리

이렇게 Asset bundle의 단점을 보완하면서 공수도 줄일 수 있기 때문에 Addressable Asset을 사용하는 이점이 있습니다. 또한 Unity에서도 Asset bundle에 대한 업데이트 대신 Addressable Asset을 대체 기술로 내세우고 있습니다. 기존에 이미 Asset bundle을 사용한다면 모르겠지만, 신규 프로젝트라면 Addressable asset system을 사용하는 게 좋지 않을까 싶습니다.

---

리소스 출처

[그림 1~6] : 직접 제작한 이미지 입니다.