Addressables 기본과 AssetReference

Quick Reference

기준: Unity 6.5에서 사용하는 Addressables 2.7.6. Addressables는 addressable asset을 key로 찾고, 필요한 dependency를 비동기로 로드하며, caller가 받은 operation handle의 reference를 release하는 시스템입니다.

자산을 가리키는 방법	잘 맞는 경우	주의할 점
직접 필드 참조	씬과 함께 항상 존재하고 별도 unload가 필요 없음	build·메모리 경계를 동적으로 제어하지 않습니다.
`AssetReference`	Inspector에서 addressable asset만 안전하게 연결	참조만 저장할 뿐, load/release는 별도 코드가 소유합니다.
address 문자열	데이터 테이블·서버 설정처럼 코드 밖 key가 필요	이름 변경·오타·중복 key를 관리해야 합니다.
label	같은 정책의 여러 asset을 batch load/preload	label 하나를 `LoadAssetAsync`에 넣으면 여러 대상 중 하나만 선택될 수 있습니다.

csharp

[SerializeField] private AssetReferenceGameObject enemyPrefab;

// AssetReference는 Inspector에 연결된 addressable key입니다.
// 실제 메모리 수명은 LoadAssetAsync/InstantiateAsync handle이 결정합니다.

식별과 배포 단위

Address는 개별 asset을 찾는 key이고, label은 여러 asset을 묶는 query key입니다. Group은 단순 폴더가 아니라 bundle packing, build/load path, content update restriction 같은 배포 정책을 공유하는 단위입니다. 서로 항상 같이 내려받고 같은 시점에 바뀌는 asset만 같은 group에 둡니다.

AssetReference는 MonoBehaviour나 ScriptableObject 필드에서 addressable asset을 고르게 해 줍니다. 일반 string보다 Inspector 연결이 안전하고, 특정 type 또는 label로 허용 asset을 제한할 수도 있습니다. 하지만 reference가 있다는 사실은 asset이 메모리에 있다는 뜻도, instance가 생성됐다는 뜻도 아닙니다.

Inspector/설정	하는 일	언제 바꾸는가	잘못되면
`Address`	runtime lookup key	데이터에서 단일 asset을 요청할 때	문자열 consumer가 예전 key를 계속 요청합니다.
`Label`	여러 asset의 query·preload 묶음	공통 preload/다운로드 정책이 있을 때	너무 넓으면 필요 없는 dependency까지 함께 로드합니다.
Group	bundle·path·update 정책	같은 배포 수명인 asset을 묶을 때	자주 바뀌는 asset이 큰 공용 bundle 재배포를 유발합니다.
`AssetReference` field	Inspector의 type-safe key	디자이너가 prefab·sprite·scene 등을 연결할 때	load/release owner를 만들지 않으면 handle 누수가 생깁니다.

도입 기준

씬이 살아 있는 동안만 쓰고 함께 build되는 HUD, player prefab처럼 단순한 asset은 직접 참조가 더 읽기 쉽습니다. 다운로드 가능한 콘텐츠, 선택형 skin, 큰 scene, runtime preload/unload, content update가 필요한 asset부터 Addressables로 분리합니다. Resources와 수동 AssetBundle의 장단점보다 먼저 "누가 언제 로드하고 마지막 사용자가 언제 release하는가"를 답할 수 있어야 합니다.

자주 틀리는 부분

증상	원인	수정 방향
Inspector에 reference를 넣었는데 object가 null	AssetReference는 자동 load하지 않습니다.	load operation의 완료 상태를 확인한 뒤 사용합니다.
label load가 기대와 다른 asset 하나만 반환	multi-asset label을 단일 asset API에 넘겼습니다.	`LoadAssetsAsync`와 결과·실패 정책을 씁니다.
asset 하나 변경 때 큰 다운로드가 생김	group이 배포 수명 대신 폴더 구조로 묶였습니다.	함께 배포할 asset만 group에 둡니다.
rename 뒤 런타임에서 key를 못 찾음	문자열 address consumer가 남았습니다.	AssetReference 또는 key 상수·검증을 사용합니다.
메모리 정책이 불명확	address와 handle을 같은 개념으로 봤습니다.	load caller와 release owner를 한 쌍으로 기록합니다.

Addressables의 핵심은 "어디에서 load할 수 있는가"보다 "누가 reference count를 하나 얻고 하나 돌려주는가"입니다. key 선택과 group 설계를 마쳤어도 handle 소유자가 없으면 런타임 메모리 계약은 완성되지 않습니다.

참고 링크

3 sources

Quick Reference

자산을 가리키는 방법	잘 맞는 경우	주의할 점
직접 필드 참조	씬과 함께 항상 존재하고 별도 unload가 필요 없음	build·메모리 경계를 동적으로 제어하지 않습니다.
`AssetReference`	Inspector에서 addressable asset만 안전하게 연결	참조만 저장할 뿐, load/release는 별도 코드가 소유합니다.
address 문자열	데이터 테이블·서버 설정처럼 코드 밖 key가 필요	이름 변경·오타·중복 key를 관리해야 합니다.
label	같은 정책의 여러 asset을 batch load/preload	label 하나를 `LoadAssetAsync`에 넣으면 여러 대상 중 하나만 선택될 수 있습니다.

csharp

[SerializeField] private AssetReferenceGameObject enemyPrefab;

// AssetReference는 Inspector에 연결된 addressable key입니다.
// 실제 메모리 수명은 LoadAssetAsync/InstantiateAsync handle이 결정합니다.

식별과 배포 단위

Inspector/설정	하는 일	언제 바꾸는가	잘못되면
`Address`	runtime lookup key	데이터에서 단일 asset을 요청할 때	문자열 consumer가 예전 key를 계속 요청합니다.
`Label`	여러 asset의 query·preload 묶음	공통 preload/다운로드 정책이 있을 때	너무 넓으면 필요 없는 dependency까지 함께 로드합니다.
Group	bundle·path·update 정책	같은 배포 수명인 asset을 묶을 때	자주 바뀌는 asset이 큰 공용 bundle 재배포를 유발합니다.
`AssetReference` field	Inspector의 type-safe key	디자이너가 prefab·sprite·scene 등을 연결할 때	load/release owner를 만들지 않으면 handle 누수가 생깁니다.

도입 기준

자주 틀리는 부분

증상	원인	수정 방향
Inspector에 reference를 넣었는데 object가 null	AssetReference는 자동 load하지 않습니다.	load operation의 완료 상태를 확인한 뒤 사용합니다.
label load가 기대와 다른 asset 하나만 반환	multi-asset label을 단일 asset API에 넘겼습니다.	`LoadAssetsAsync`와 결과·실패 정책을 씁니다.
asset 하나 변경 때 큰 다운로드가 생김	group이 배포 수명 대신 폴더 구조로 묶였습니다.	함께 배포할 asset만 group에 둡니다.
rename 뒤 런타임에서 key를 못 찾음	문자열 address consumer가 남았습니다.	AssetReference 또는 key 상수·검증을 사용합니다.
메모리 정책이 불명확	address와 handle을 같은 개념으로 봤습니다.	load caller와 release owner를 한 쌍으로 기록합니다.

Addressables 기본과 AssetReference

Quick Reference

식별과 배포 단위

도입 기준

자주 틀리는 부분

참고 링크

Opening reference

Addressables 기본과 AssetReference

Quick Reference

식별과 배포 단위

도입 기준

자주 틀리는 부분

참고 링크