[Unity] 런타임 로드 방식의 차이 (resource폴더, 어드레서블, 에셋번들)

 

Resource폴더 로드 vs 에셋 번들 vs 어드레서블

 

발표 내용 중 기술적 의사결정에서 어드레서블 대신 리로스 폴더 로드 방식을 선택한 이유에 대한 명확한 근거가 부족했다. 우리 조는 모바일이 아닌, 웹 PC 에서 유통할 계획이었기 때문에 데이터 양과 상관없이 쉬운 방식을 사용하면 좋을 것이라 생각했다. 하지만 차후 게임 확장성, 운영 안정성 면에서 데이터 로드 방식에 대해 다시 생각할 필요가 있었다. 어드레서블/에셋 번들이라는 선택지를 제대로 파악하지 않고 단순한 리소스 로드 방식을 선택한 것은 의사결정의 허점이 될 수 있다. 튜터님께서 질문하신 리소스 폴더 vs 에셋 번들 vs 어드레서블의 차이에 대한 공부의 필요성을 느꼈다.

 

 

Q) Resource폴더 로드 vs 에셋 번들 vs 어드레서블의 명확한 차이는?

1. 리소스 폴더 로드

유니티에서 제공하는 리소스 로드 폴더란, 리소스 폴더 안 파일의 경로로 접근하여 사용하는 방식이다.

사용하기에 편리하다는 장점이 있지만, 그만큼 단점도 많아 유니티에서도 권장하지 않는 방법이다.

빌드 시 함께 묶이므로 빌드 사이즈가 커져 앱 시작 시간이 길어진다. 에셋 이름을 통해 로드하므로 에셋 이름 변경이 어렵다. 빌드한 앱의 용량 자체에 영향을 끼친다.

 

2. 에셋 번들

에셋들을 하나로 묶어 압축 파일을 생성하는 개념으로, 생성된 에셋 번들은 네트워크를 통해 배포하고 런타임에 로드하여 사용된다. 빌드에 포함되지 않으므로 초기 인스톨 사이즈를 줄여 앱 시작 시간을 단축시킬 수 있다. 앱 설치 시 콘텐츠를 분리할 수 있어 라이브 앱에 정기적인 콘텐츠 업데이트(DLC, 패치 등)를 제공할 때 사용한다.

단, 치명적인 단점이 있는데 번들의 종속성 문제이다.

 

Asset A에 있는 개체가 Asset B에 있는 텍스처를 참조할 때, A를 로딩하기 전 B를 메모리로 로딩해야 한다. A가 로딩되기 전에 반드시 B가 로딩되어야 한다는 점에서 개발자는 에셋 관리에 더욱 신경써야 한다.

 

이러한 에셋 번들의 에셋 위치 지정, 빌드 및 로드와 관련하여 발생하는 문제들을 해결하기 위해 어드레서블이 탄생하게 되었다.

 

3. 어드레서블

어드레서블 에셋은 에셋에 주소를 지정하는 방식으로 주소(address)로 에셋을 쉽게 로드할 수 있는 방법을 제공한다. 에셋 번들의 단점을 보완하기 위해 등장했다. 에셋이 서버에만 올라가고 앱에 들어가지 않기 때문에 차후 게임 업데이트 시 유리하다. 리소스 변화에 따른 불필요한 재업로드를 방지하기 때문이다.

 

에셋 위치에 상관없이 참조가 가능하다. 즉, 로드할 대상이 되는 에셋과 에셋이 로드되는 위치 및 방식을 분리하는 것이다. 그래서 에셋을 로드하는 측에서는 에셋의 어드레스만 알면 되고 에셋의 실제 위치가 변경되어도 상관없다.

 

어드레서블을 이용하면 에셋 빌드와 배포를 단순화할 수 있다. 레퍼런스/리소스/에셋 번들 분리가 편리해지기 때문이다. 카테고리 분류 또한 가능한데, 이 때 카테고리는 하나의 그룹으로 묶이며 그룹 내 하나의 리소스만 사용하려 해도 그룹 전체를 다운로드하여야 사용이 가능하다. 

 

어드레서블은 에셋 번들에 비해 코드가 간단한 편이며 대규모 프로젝트에서 메모리를 효율적으로 관리하고 싶을 때, 서버에서 추가 에셋 다운로드가 필요할 때 유용하다.

공부자료 : Unity Documentation

https://docs.unity3d.com/kr/2018.4/Manual/ReducingFilesize.html

https://docs.unity3d.com/kr/2018.4/Manual/AssetBundles-Dependencies.html

 

 

중간발표 피드백

 

1.

동기화 관련해서 문제가 생겼다면, 버그 해결 수준에서 그치는 게 아니라 상위의 시스템 부분 (동기화를 위해 데이터를 쏘고 뿌려주는 부분)의 리빌딩이 필요할 수도 있다. 어쩌면 스크립트 일부의 오류가 아니라 전체 구조에서 고쳐야할 부분이 있지 않나 살펴볼 필요도 있다. 

기술 선택에 있어서 성능적인 부분만 바라볼 것이 아니라, 운영에 대한 부분도 고려하는 게 더 고차원적인 의사결정이다.

 

2.

네트워크 동기화 문제, 최적화 쪽에 강점을 둬서 프로젝트를 완성해도 괜찮을 거 같다.

동기화나 패키지 처리가 부족한 상태에서 포톤을 사용하면 어려운 점이 많다. 남은 시간 동안 포톤 관련된 잔버그를 처리하는데 보낼 것 같다. 특정 상태 변화가 클라이언트에 신속하게 전달될 수 있도록 하고, 게임이 끊겼을 때를 대비해서 리커넥션, 상태 복구 등 멀티 게임에서 고려할 점을 세심하게 챙기는 것도 좋은 경험일 것이다.