Addressables 기본과 AssetReference

기본 패턴

[SerializeField] private AssetReferenceGameObject enemyRef;

설명

• Addressables는 "에셋을 어디에 두었는지"보다 "어떤 키로 요청할 것인지"를 기준으로 로드하게 만드는 시스템입니다. 그래서 직접 참조, Resources, 수동 AssetBundle보다 에셋 위치와 로드 방식을 더 느슨하게 분리할 수 있습니다.
• 핵심 mental model은 단순합니다. 에셋에 address나 label을 붙여 카탈로그에 등록하고, 런타임에는 그 키나 AssetReference로 비동기 로드를 요청합니다. 에셋이 로컬에 있든 원격에 있든 Addressables가 경로와 의존성을 해결합니다.
• AssetReference는 코드에 문자열 주소를 하드코딩하는 대신, 인스펙터에서 안전하게 Addressable asset을 연결하게 해 줍니다. 특히 프리팹, 스프라이트, 씬, VFX처럼 디자이너가 연결하는 자산에 잘 맞습니다.
• Addressables의 장점은 로드 유연성뿐 아니라 배포 전략입니다. 큰 프로젝트에서 콘텐츠를 묶음 단위로 교체하거나, DLC/패치/원격 다운로드 구조를 설계할 때 차이가 커집니다.
• 하지만 단순히 "새 시스템이라서" 쓰는 것은 좋지 않습니다. 모든 에셋을 무조건 Addressables로 돌리기보다, 직접 참조로 충분한지, 런타임 동적 로드가 필요한지, 메모리/배포 요구가 있는지 먼저 보는 편이 좋습니다.

다른 방식과 어떻게 다른가

• 직접 참조는 가장 단순하고 안전합니다. 씬 안에 항상 존재하고 런타임에 따로 떼어 로드할 필요가 없는 자산은 굳이 Addressables로 돌릴 이유가 없습니다.
• Resources는 빠르게 시작하기 쉬운 반면, 자산 경계와 메모리 수명주기가 흐려지기 쉽습니다. 큰 프로젝트에서는 어떤 자산이 왜 메모리에 있는지 추적하기 어렵다는 문제가 자주 생깁니다.
• AssetBundle은 저수준 제어가 가능하지만 직접 관리 부담이 큽니다. Addressables는 그 위에서 카탈로그, 의존성, 비동기 흐름을 더 일관되게 다루게 해 주는 상위 추상화라고 생각하면 이해가 쉽습니다.
• 즉 Addressables는 "무조건 더 좋은 로더"가 아니라, 자산을 런타임에 동적으로 다루고 배포 구조까지 포함해 관리해야 할 때 가치가 커지는 시스템입니다.
• 그래서 도입 판단은 늘 세 질문으로 정리됩니다. 이 자산이 런타임에 동적으로 필요해지는가, 배포 단위를 분리해야 하는가, 직접 참조로는 수명주기 관리가 불편한가.

빠른 정리

도입 판단

주의할 점