Unity에서 프로젝트 규모가 커질수록 리소스 로딩, 메모리 관리, 업데이트 방식이 점점 더 복잡해진다.
이런 리소스들을 체계적으로 관리하기 위해 최근엔 Addressables을 표준처럼 사용하고 있다.
그래서 오늘은 Addressables의 내부 구조가 어떻게 되어 있는지, 어떤 흐름으로 리소스를 찾고 로딩하고 해제하는지 정리해보려고 한다.
[1. Addressables란?]
Unity는 Addressables을 다음과 같이 정의한다.
"주소 기반의 에셋 로딩 및 메모리 관리 시스템"
Addressables는 사실,
- 에셋 분류
- 의존성 분석
- AssetBundle 빌드
- Catalog 생성
- 에셋 로딩
- 참조 기반 언로드
이 모든 과정 전체를 관리하는 리소스 파이프라인이다.
즉, Addressables는 단순히 "주소로 로드하는 기능"이 아니라
"에셋 관리 전체를 자동화하는 시스템"이다.
[2. 왜 Addressables이 필요할까?]
Addressables이 나오기 전에는 크게 두 가지 방식이 있었다.
<1. Resources.Load()>
문제점:
- 빌드 시 Resources 폴더 전체가 통으로 포함됨
- 로딩 단위가 없어서 최적화 불가
- 메모리에서 언제 내려가는지 세밀하게 제어 불가능
<2. 수동 AssetBundle>
Resources.Load()보단 조금 더 고급 방식이었지만 사용자가 직접 해야 하는 일이 너무 많은 것이 문제였다.
- 어떤 에셋이 어떤 Bundle에 들어가는지 분류
- 의존성 있는 Bundle을 직접 고려해야 함
- 로딩 순서를 직접 관리
- 번들 해시/버전 관리
- 원격 업데이트 관리
하나라도 잘못하면 바로 로딩 오류가 생긴다...
Addressables는 이 모든 불편함을 해결해주기 위해 등장했다.
[3. Addressables의 핵심 원리]
Addressables는 내부적으로 아래 3단계를 통해 동작한다.
<1. Catalog 생성>
Addressables을 빌드하면 여러 파일이 생성되는데, 그중 catalog.json이 가장 중요하다.
Catalog에는 다음 정보가 모두 담겨 있다.
- 에셋의 주소
- 어떤 그룹에 속하는지
- 어떤 AssetBundle에 들어가는지
- 해당 번들의 의존성 목록
- 원격 경로 / 로컬 경로
- 번들 해시
즉, Catalog는 Addressables의 "두뇌"라고 보면 된다.
Addressables.LoadAssetAsync()가 호출되면
가장 먼저 Catalog에서 주소를 검색한다.
<2. AssetBundle 자동 빌드 + 의존성 분석>
Addressables는 내부적으로 여전히 AssetBundle을 사용한다.
하지만 수동 방식과 다른 점은 다음과 같다.
- 번들 분류 자동
- 의존성 분석 자동
- 중복 리소스 제거
- 업데이트 관리 자동화
예를 들어 프리팹 하나에 스프라이트 5개와 머티리얼 2개가 필요한 경우, Addressables는 의존성 트리를 자동으로 분석해서 필요한 번들을 함께 구성해준다.
사용자는 Bundle을 직접 고려할 필요가 없다.
<3. 로딩 및 참조 카운트 기반 메모리 관리>
Addressables.LoadAssetAsync()를 호출하면 아래 과정이 실행된다.
- Catalog에서 주소 검색
- 해당 에셋이 들어 있는 Bundle 탐색
- 의존성 Bundle을 먼저 로딩
- 필요한 Bundle이 메모리에 올라감
- 에셋 인스턴스 생성
- Release() 호출될 때 참조 카운트 감소
- 카운트 0 -> Bundle 언로드
즉, Addressables는 참조 카운트 기반 메모리 관리 시스템이다.
Release()를 안 하면 빌드가 커지고, 메모리 누수가 발생하는 이유도 이것 때문이다.
[4. Addressables의 장점]
정리해보면 Addressables의 핵심 장점은 다음과 같다.
- 자동 의존성 관리
복잡한 Bundle 구조를 신경 쓸 필요가 없다.- 메모리 최적화
필요한 순간에만 Bundle이 로딩되고, 참조가 끊기면 안전하게 언로드된다.- 빌드 크기 절감
중복 리소스 제거, 그룹 단위 관리 가능- 원격 업데이트 (Remote Catalog)
Catalog와 Bundle을 서버에 올려두고, 게임 실행 중에 업데이트 가능- 비동기 로딩 기본 제공
UI, 씬 전환, 사운드 등에서 자연스럽게 async 기반 설계 가능
[5. Addressables 사용 시 주의할 점]
- Release()를 반드시 호출해야 한다.
호출하지 않으면 메모리에서 Bundle이 내려가지 않는다.- Addressables 빌드해야 Catalog가 갱신된다.
프로젝트만 저장해도 Catalog는 변경되지 않는다.
반드시 Addressables Build -> Player Content Build 필요.- 그룹 설정이 프로젝트 성능에 큰 영향을 준다.
Bundle Packing Mode, Load Mode 등을 잘못 설정하면 오히려 비효율적이 될 수 있다.- Catalog 경로를 원격으로 설정할 때는 버전 관리 필수
해시 기반 버전 파일이 만약 누락되면 업데이트가 제대로 적용되지 않는다.
[6. 정리]
Addressables의 동작 원리를 한 문장으로 요약하면 다음과 같다.
"Catalog와 AssetBundle 빌드를 기반으로 주소 -> 의존성 -> 메모리 관리를 자동 처리하는 시스템"
단순한 주소 로딩 기능이 아닌 리소스 로딩 전체를 통제하는 완전한 관리 시스템이라고 할 수 있다.
