인트로
지금까지 클라이언트 단에서 사용하는 에셋들을 최적화하고 관리하는 방법들에 대해 알아보았다. 이제는 클라이언트만의 영역을 넘어 외부 서버에서 게임 에셋을 다운로드 하여 사용하는 패치 시스템에 대한 내용을 정리해 볼 것이다. 이번 편에서는 어드레서블 에셋과 AWS를 이용한 게임의 에셋 패치 시스템에 대한 내용을 다룬다. 관련 내용은 이전 글에서도 설명하였으니 이 글을 보기 전에 같이 보고오면 좋을 것이다.
라이브-게임-에셋-관리-개선기-1.어드레서블-에셋-도입
1부. 어드레서블 에셋 도입
2부. 메모리 사용 구조 개선 / 리소스 최적화
번외1. 리소스 최적화 기법
3부. DLC를 통한 패치 시스템 <- 현재 글
에셋 패치 시스템이 필요한 이유
DLC를 통한 패치 시스템이 모바일 프로젝트의 에셋 관리에서 가장 핵심적인 부분이 될 가능성이 높다. 이미 패치 시스템이 도입된 다른 게임들을 예시로 그 이유를 알아보자.
1. 에셋 메타데이터
"출처: UniteSeoul2018 - 에셋번들 실전 가이드 (AssetBundle Best Practices)"
기존의 방식대로 프로젝트 빌드에 모든 에셋을 포함시키면 일어나는 문제 중 하나가 Lookup Table과 프로젝트 로드에 필요한 에셋 메타데이터의 크기가 비대해진다는 것이다. 관련 데이터 파일들은 생각보다 무겁고, Lookup Table은 트리 구조(플랫폼에 따라 RB트리, BST)로 되어있는데 모든 에셋을 로드하기 위해 nlogn의 복잡도를 가지기 때문에 이를 로드하기 위한 시간이 생각보다 오래 걸릴 수 있다. 이 작업은 특히 디바이스의 사양이 낮은 모바일에 치명적으로 작용할 수 있다.
이를 에셋번들로 분리함으로써 번들마다 별도의 테이블을 갖게 만들고, 필요한 순간 비동기적으로 로드해서 사용하게 한다면 앱 실행시 에셋을 로드하는 부담을 크게 줄일 수 있게 된다.
2. 패치시스템 + 앱 용량 줄이기
"게임 프린세스 커넥트! Re:Dive 추가 다운로드 팝업"
위 게임은 내가 몰래 숨어서 플레이하고 있는 미소녀 수집형 게임인 '프리코네'의 업데이트 팝업이다. 2024년 4월 18일 기준, iOS 앱스토어에 업로드 된 이 게임의 기본 크기는 290.1MB 이정도는 '일반적인 서비스 어플'들보다 약간 큰 정도이다. 하지만 게임을 실제로 플레이하기 위해서는 추가적으로 10.73GB의 데이터를 다운로드 받아야 한다.
이처럼 대부분의 모바일 게임들은 실제 앱스토어에는 앱을 구동시키기 위한 코드와 최소한의 에셋들만 포함되어있는 빌드파일을 올려놓고, 대부분의 핵심 에셋들은 별도로 다운받는 구조로 제작되어 있다. 위에 예시로 든 프리코네의 경우, 신규 캐릭터 획득시마다 그 캐릭터와 관련된 리소스나 게임 스토리를 보기 위한 리소스도 필요시마다 추가로 다운로드 하고 있어 실제로 게임 플레이를 하면서 다운받는 리소스의 양은 훨씬 많아질 수 있다.
이렇게 외부에서 리소스를 다운 받는 이유는 다음과 같다.
- 앱 스토어에서 보이는 앱 용량이 진입장벽으로 느껴질 수 있다.
- 안드로이드는 apk로 앱을 업로드 시 150MB 이하로 유지해야 하는 전통이 있었다.
- 그리고 패치 시스템을 이용하면 번거로운 앱 심사 과정을 회피하고 업데이트를 할 수 있다
사실 개인적인 입장에서는 3번이 핵심이라고 생각한다. 게임개발을 하다 보면 추가로 빌드 과정을 진행하는 것도 엄청난 일이며 이를 앱스토어에 심사받고 정해진 기간까지 심사가 통과할지 기도하는 일도 회사 팀원들의 마음을 힘들게 한다. 이 과정은 많은 시간과 정성이 필요하며, 때로는 예상치 못한 심사 지연이나 거절 사유를 해결하기 위해 추가적인 노력(과 야근)이 필요할 수 있다.
앱 패치 심사
애플의 앱스토어 심사는 구글 마켓에 비해
까다롭고 오래 걸리는 것으로 유명합니다.
몇 시간 정도 걸리는 안드로이드 심사와 달리
애플 앱 심사는 약 일주일 정도 걸리는데요.
일주일을 기다린 앱 심사 결과가
거부(reject)면 재심사까지 더해 약 2주일,
한번 더 reject되면 3주까지 늘어나기도 하죠.
그렇기에 앱스토어 심사를 가장 빨리 통과하는
방법은 거부(reject)당하지 않는 거죠.
- 디스이즈게임, [카드뉴스] 거부를 거부한다! 앱스토어 심사에서 리젝당하지 않는 법https://www.thisisgame.com/webzine/nboard/257/?n=61254?n
모바일게임을 만들고 앱 마켓에 등록하기 위해서는 필수적으로 심사 과정을 거쳐야 한다. 앱 심사는 대부분 첫 심사가 매우 까다롭고 이후 심사는 상대적으로 너그럽게 진행되는 편인 것 같다. 하지만 첫 심사가 아니라고 방심하면은 안 된다. 앱 심사 거절은 언제 어디서 일어날지 모른다.
만약 코드 수정이 아닌 단순 리소스 수정이라면, 위와 같은 패치 시스템을 이용해서 앱 심사를 우회하고 바로 유저들에게 콘텐츠 업데이트를 할 수 있다. 한번 DLC 업데이트에 익숙해지고 나면, 단순 리소스 수정 같은 일로 하루 이상의 딜레이를 가질 수 있는 앱 심사 과정을 거쳐야 하는 것이 매우 번거로운 일로 느껴질 수 있을 것이다.
적용사례
에셋을 패치 하려면 유저들이 앱 실행 중 항상 접근할 수 있는 웹 서버에 사용할 에셋들을 업로드해야 한다. 나는 회사에서 사용 중인 AWS S3 버킷에 에셋을 업로드하고 게임에서 이를 로드해서 사용해보는 테스트를 하였다.
(위 영상에서 '바로 로드 안됨'이라고 나오는 부분의 문제는 해결했는데, 어이없게도 에셋 로드를 하고 로드가 완료되는 걸 기다리지 않고 오브젝트를 생성하고 있었다.)
위 어드레서블의 장점에서 'Remote'로 에셋을 저장해주는 세팅을 하면 에셋이 원격 저장소에 저장된다고 말했다. 위 영상이 바로 ActorPrefab 그룹을 Remote에 저장되도록 세팅하고 그 에셋들을 s 3원격 저장소에 올려서 사용하는 영상이다. 영상을 보면 알 수 있듯이, 어드레서블에서 제공해주는 기능만을 이용하면 프로젝트의 외딴곳에 에셋이 빌드되고 이를 수동으로 손으로 옮겨서 S3 버킷에 업로드해주는걸 볼 수 있을 것이다.
또한 현재 클라이언트에 있는 에셋이 최신 에셋인지 파악하기 위해 해시 값들을 관리해야 하고, 이러한 해시 값을 관리해주는 카탈로그 개념에 대해 인지하고 있어야 한다. 이에 대한 경험과 자세한 설명들은 추후 DLC를 통한 패치 시스템에 대한 글을 쓸 때 다뤄보려고 했으나..
적용 중단
다양한 이유로 해당 작업이 중단되었다. 내부 판단으로 굳이 패치시스템까지 적용할 필요가 없다는 결론이 났다. 해당 작업을 위해 리서치한 내용들이 있었는데 이 내용들은 다음 기회에 따로 다뤄보도록 하겠다.
- S3에서 에셋 관리 전략
- 프로젝트에서의 에셋 관리 전략
- 에셋 그룹화 및 번들 패킹 전략
- CloudFront와 캐시무효화
끝
드디어 첫 글을 작성한 2024년 7월부터 2025년 3월까지, 긴 시간동안 나태함에 빠져 빠르게 진행하지 못했던 라이브 게임 에셋 관리 개선기에 대한 글 시리즈 작성을 마무리 하였다. 결국 첫 글에서 약속했던 패치시스템을 적용하는 모습은 보여주진 못했지만 지금도 다양한 일을 진행하고 있다. 다음에 재미있는 주제로 새로운 시리즈를 연재할 수 있게 다양한 시도를 하면서 개발자 생활을 이어나가야겠다.
