1. 개념 요약

Resources: Unity 내장 방식으로, Assets/Resources 폴더에 에셋을 두면 런타임에 Resources.Load("경로")로 로드할 수 있다. 쉽게 사용 가능하지만, 모든 Resources 폴더 에셋이 빌드에 포함되어 빌드 크기와 메모리 사용량이 증가하고 시작 시간이 느려지며 메모리 관리가 어려운 단점이 있다.
AssetBundle: 에셋을 별도의 번들 파일로 묶는 시스템으로, DLC(다운로드 콘텐츠)나 플랫폼별 최적화 등에 사용된다. 에디터에서 BuildPipeline.BuildAssetBundles 등을 통해 플랫폼별 번들을 생성한 뒤, 런타임에 AssetBundle.LoadFromFile/UnityWebRequestAssetBundle 등으로 번들을 불러와 AssetBundle.LoadAsset(…) 또는 비동기 LoadAssetAsync로 개별 에셋을 로드한다. 필요한 시점에만 로드해 초기 설치 용량을 줄이고, 게임 배포 이후 리소스를 업데이트할 때 부분 교체가 가능하다는 장점이 있다. 다만 번들 관리와 빌드가 복잡하며 플랫폼별로 별도 빌드가 필요하고, 번들 내부에 스크립트(코드)를 포함할 수 없는 한계가 있다.
Addressables: Unity 2018~2019년경 도입된 새로운 에셋 관리 시스템으로, 에셋을 주소(주소키) 기반으로 관리하여 에디터 UI에서 에셋 그룹을 구성하고 빌드할 수 있다. 내부적으로는 AssetBundle을 사용하며, 의존성 관리와 캐싱이 자동화되어 편의성이 높다. Addressables.LoadAssetAsync("주소") 등의 API로 비동기 로드하며, 로드된 에셋은 참조 카운트로 관리하여 Addressables.Release 시 메모리를 해제한다.

2. 배경 지식

Resources 등장 배경: Unity 초창기에는 에셋 관리 수단이 제한적이었기 때문에, Resources 폴더를 활용해 런타임 로드를 지원했다. 그러나 이 방식은 모든 에셋이 빌드에 포함되고 시작 시 인덱스 구축 비용이 발생해 성능 부담이 크다는 한계가 있다. 특히 모바일 등 저사양 기기에서 대량의 Resources 에셋을 초기화하면 로딩 시간이 크게 늘어난다. Unity 매뉴얼도 Resources 방식은 성능 저하 위험 때문에 프로토타이핑이나 소규모 프로젝트처럼 임시 용도에만 권장한다고 언급한다.
AssetBundle 등장 배경: 프로젝트 규모가 커지고 에셋 변경 주기가 짧아지면서, 하나의 빌드에 모든 리소스를 포함하는 방식으로는 대응하기 힘들어졌다. AssetBundle은 이러한 문제를 해결하기 위해 도입되었으며, 사용자가 필요할 때만 리소스를 다운로드해 로드할 수 있어 초기 설치 용량을 줄이고 콘텐츠 업데이트를 용이하게 한다. 또한 플랫폼별로 최적화된 에셋을 제공하기 위해 빌드 타겟별 번들이 필요해졌는데, Unity는 각 플랫폼에 맞는 번들을 별도로 빌드해야 하는 제약을 두었다. AssetBundle도 의존성 관리와 번들 캐싱을 개발자가 직접 처리해야 하는 등의 어려움이 있다.
Addressables 등장 배경: AssetBundle 시스템의 복잡성을 완화하기 위해 Unity는 Addressables 패키지를 도입했다. Addressables은 기존 AssetBundle 개념 위에 빌드/의존성 관리를 자동화한 시스템으로, 에디터에서 에셋 그룹과 프로필을 설정하면 번들이 자동 생성된다. 이를 통해 개발자는 번들링 과정과 버전·캐싱 관리를 손쉽게 할 수 있게 되었다. Addressables는 에셋을 주소로 참조하므로, 로컬 파일뿐 아니라 원격 서버(CDN)에서도 동일한 주소로 에셋을 불러와 사용할 수 있다. 다만 새로운 시스템이므로 초기 학습 곡선이 있고, 기존 AssetBundle과의 차이로 일부 복잡한 구현에서는 조심해야 할 점이 있다.

3. 상세 설명

Resources 시스템: 위의 Resources 폴더에 에셋을 배치한 뒤 Resources.Load(path) 로드한다docs.unity3d.com. 이때 빌드 시 모든 Resources 에셋이 resources.assets 파일에 포함된다. 예를 들어 작은 텍스트 파일, 기본 텍스처, 간단한 프리팹 같은 간단한 리소스는 이 방식으로 빠르게 로드할 수 있다. 하지만 모든 에셋이 포함되므로 에셋 수가 늘어날수록 빌드 크기와 앱 시작 시간이 비선형적으로 증가한다. 예를 들어 수천 개의 에셋이 있으면 초기 인덱스 구축에 몇 초가 걸릴 수 있다. 메모리 해제를 위해서는 Object.Destroy(loadedObj) 후 Resources.UnloadUnusedAssets()를 호출해야 한다. Unity 매뉴얼에서는 Resources는 메모리 관리가 어렵고 빌드/스타트업 비용이 높다고 경고하며, 프로토타이핑이나 부트스트랩 용도로만 제한적으로 사용하길 권장한다.

AssetBundle 시스템: AssetBundle은 모델, 텍스처, 프리팹 등 다양한 에셋을 묶어 별도의 파일로 빌드하는 방식이다. 에디터에서는 BuildPipeline.BuildAssetBundles() 같은 API를 호출해 플랫폼별 번들을 생성한다. 번들 생성 시 의존하는 에셋을 함께 포함하거나 다른 번들과 참조를 맞춰주는 로직을 작성해야 한다. 런타임에는 AssetBundle.LoadFromFile(path) 또는 UnityWebRequestAssetBundle로 번들 파일을 로드한 뒤, AssetBundle.LoadAsset(name) 또는 LoadAssetAsync(name)로 특정 에셋을 읽어온다. 언로드 시 AssetBundle.Unload(true/false)를 사용하여 번들과 로드된 에셋의 메모리를 해제한다.

AssetBundle의 주요 장점은 필요한 에셋만 선택적으로 로드함으로써 초기 빌드 크기를 줄이고, 배포 후에도 일부 에셋만 교체하여 업데이트할 수 있다는 점이다. 예를 들어 모바일 게임에서 신규 캐릭터 리소스를 DLC 형태로 번들링해 원격으로 배포하면, 전체 앱을 다시 빌드하지 않고도 새 에셋을 제공할 수 있다.

반면 단점으로는 번들 빌드·관리의 복잡성이 있다. 각 플랫폼별로 번들을 별도 빌드해야 하고, 번들 간의 종속성 충돌(예: 두 번들이 같은 에셋을 참조하면 중복 로드)이 발생할 수 있다. 또한 AssetBundle은 스크립트나 어셈블리를 포함할 수 없어서, 코드 업데이트 수단으로는 사용이 불가능하다. Unity 매뉴얼도 AssetBundle을 사용할 때 의존성 관리와 로드 타이밍에 주의하라고 안내한다.

Addressables 시스템: Addressables은 에셋을 주소(Key) 로 관리하는 고수준 시스템이다. 개발자는 Window → Asset Management → Addressables → Groups 창에서 에셋을 Addressable로 표시하고 그룹을 구성한다. 에셋마다 문자열 주소가 자동 생성되며, 이를 통해 런타임에 에셋을 로드한다. 예를 들어 Addressables.LoadAssetAsync<GameObject>("EnemyPrefab")를 호출하면 해당 주소의 프리팹을 비동기 로드한다. Addressables는 내부적으로 번들 매니저와 콘텐츠 카탈로그를 사용하여, 주소와 실제 번들 파일을 매핑한다. 이 카탈로그 덕분에 에셋 위치(빌드 인클루드, 로컬 캐시, 원격 서버)를 신경 쓰지 않고 동일한 주소로 호출이 가능하다.

Addressables는 자동 의존성 관리와 참조 카운트를 제공한다. 즉, 메인 에셋만 로드해도 관련된 의존 에셋을 자동으로 로드하며, Addressables.Release(asset)을 호출하면 내부 참조 카운트가 감소해 더 이상 사용되지 않는 에셋을 해제한다. 이로써 메모리 해제 로직을 단순화할 수 있다. 또한 에디터 GUI에서 그룹, 레이블, 프로필 등을 설정할 수 있어, 동일 프로젝트 내에서 개발·테스트용 로컬 경로와 배포용 원격 URL을 손쉽게 전환할 수 있다.

Unity는 Addressables를 통해 빌드 시간 단축 및 CDN/DLC 활용과 같은 이점을 제공한다. 초기 빌드를 작게 유지하고, 수정된 에셋만 별도로 업데이트할 수 있어 반복 작업이 빨라진다. 반면 초기 설정이 다소 복잡하고, 내부적으로 에셋 관리가 추상화되어 있어 시스템의 동작을 완전히 이해하려면 학습이 필요하다. 그러나 대부분 프로젝트에서 Addressables 사용이 권장되며, Unity 매뉴얼도 Resources 대신 Addressables 및 AssetBundles 사용을 추천하고 있다.

항목	Resources	AssetBundle	Addressables
사용 형태	`Resources` 폴더에 직접 에셋 저장	에셋별로 번들 설정 후 외부 파일로 빌드	에디터 GUI 또는 코드로 주소(키) 기반 에셋 그룹 관리
빌드 방식	빌드 시 모든 `Resources` 폴더 에셋을 `resources.assets` 파일에 포함	`BuildPipeline.BuildAssetBundles` API 등으로 플랫폼별 번들 생성	Addressables 툴로 에셋 그룹 빌드(내부적으로 AssetBundle로 패키징)
로드 API	`Resources.Load("경로")` (동기) 또는 `Resources.LoadAsync`	`AssetBundle.LoadFromFile`, `UnityWebRequestAssetBundle`로 번들 로드 후 `LoadAsset`/`LoadAssetAsync`	`Addressables.LoadAssetAsync("주소")`, `AssetReference.InstantiateAsync` 등 (비동기)
의존성 관리	런타임 해제·메모리 관리 수동; 종속 에셋은 빌드 시 자동 포함	번들 간 의존성 수동 설정 필요(빌드시 정리할 수 있으나 런타임 언로드는 직접 `AssetBundle.Unload` 호출)	주소 로드시 관련 의존 에셋 자동 로드; 참조 카운트로 메모리 관리 자동화
메모리 관리	`Object.Destroy(loadedObj)` 후 `Resources.UnloadUnusedAssets()` 호출하여 해제	`AssetBundle.Unload(true/false)` 호출로 번들과 그 내부 에셋 메모리 해제	`Addressables.Release()`로 참조 해제(내부 참조 카운트에 따라 자동 해제)
장점	구현이 간단하고 별도 빌드 필요 없음	필요한 에셋만 로드하여 초기 용량 감소, DLC/원격 콘텐츠 지원	주소 기반 로드로 편리, 자동 캐시·의존성 관리, 그룹화로 효율적 빌드·배포 가능
단점	모든 에셋 빌드 포함으로 크기 증가, 시작 시간 지연, 메모리 관리 어려움	번들 빌드·관리 복잡, 플랫폼별 번들 필요, 스크립트 포함 불가	초기 학습 곡선 존재, 설정·디버깅 복잡, 번들 기반 빌드 필요성이 여전

(위 표에서 각 시스템의 특징과 장단점을 비교함)

적용 예시: 작은 게임이나 프로토타입에서는 간단한 설정만으로 사용할 수 있는 Resources를 빠르게 이용할 수 있다. 대규모 프로젝트나 콘텐츠 업데이트가 필요한 경우에는 AssetBundle이나 Addressables가 유리하다. 예를 들어 게임 출시 후 신규 챕터나 캐릭터를 추가할 때 AssetBundle로 번들링하여 원격 배포하면 앱 전체를 재배포하지 않아도 된다. Addressables는 이러한 작업을 더욱 쉽게 처리해주며, 에디터 내 GUI를 통해 그룹화・프로파일링할 수 있어 대규모 리소스 관리에 많이 사용된다.