Unity Addressables 순환 참조로 인한 에셋 번들 메모리 누수 원인과 해결 방법

🌐 English Abstract

This technical post explores memory leak issues and delayed asset release in Unity game development caused by circular references within the Addressable Asset System. It breaks down the internal reference counting mechanisms, implicit AssetBundle dependencies, and provides actionable troubleshooting steps using Memory Profiler and Event Viewer. Game developers will learn best practices for refactoring asset bundle structures, decoupling dynamic references, and optimizing runtime memory consumption.

유니티(Unity)의 어드레서블 에셋 시스템(Addressable Asset System)은 기존의 에셋 번들(AssetBundle) 관리 방식보다 훨씬 유연하고 고도화된 동적 리소스 로딩(Dynamic Resource Loading) 환경을 제공합니다. 그러나 대규모 프로젝트나 리소스 간의 관계가 복잡한 환경에서는 순환 참조(Circular Reference)로 인해 에셋 번들이 메모리에서 정상적으로 해제되지 않고 유휴 상태로 남아있는 메모리 누수(Memory Leak) 및 메모리 해제 지연(Delayed Unload) 현상이 빈번하게 발생합니다.

본 포스팅에서는 어드레서블의 내부 동작 원리인 참조 카운팅(Reference Counting) 메커니즘을 심도 있게 파헤치고, 순환 참조가 왜 메모리 해제를 방해하는지, 그리고 이를 진단하고 아키텍처적으로 해결하는 실무 트러블슈팅(Troubleshooting) 가이드를 제공합니다.

1. Unity Addressables의 참조 카운팅 메커니즘 이해

Addressables 시스템은 내부적으로 에셋과 에셋 번들의 생명주기(Lifecycle)를 관리하기 위해 참조 카운팅(Reference Count) 방식을 사용합니다. 개별 에셋을 로드할 때마다 해당 에셋이 속한 에셋 번들의 참조 카운터가 증가하고, 반대로 Addressables.Release() 또는 Addressables.ReleaseInstance()를 호출하면 참조 카운터가 감소합니다.

• 참조 카운트 = 0 (Reference Count zero): 에셋 번들에 속한 모든 에셋의 참조 카운트가 0에 도달하면, 내부적으로 AssetBundle.Unload(true) 또는 AssetBundle.Unload(false)가 실행되며 해당 번들이 메모리에서 해제됩니다.
• 의존성 그래프(Dependency Graph): 에셋 A가 에셋 B를 직간접적으로 참조하고 있다면, 에셋 A를 로드할 때 에셋 B가 포함된 번들까지 자동으로 함께 메모리에 로드됩니다.

암시적 의존성(Implicit Dependency)의 함정

개발자가 명시적으로 두 에셋을 연결하지 않더라도, 셰이더(Shader), 머티리얼(Material), 애니메이션 클립(Animation Clip) 등의 공통 에셋이 서로 다른 어드레서블 그룹(Addressable Group)에 분산되어 있을 경우 Unity 빌드 시스템은 암시적 의존성(Implicit Dependency)을 생성합니다. 이 구조에서 관계가 꼬이면 순환 참조가 형성됩니다.

2. 순환 참조(Circular Reference)가 메모리 누수를 일으키는 원인

순환 참조는 두 개 이상의 에셋 번들이 서로를 직간접적으로 참조하면서 참조 카운트가 영원히 0으로 떨어지지 않는 상태를 의미합니다.

⚠️ 대표적인 순환 참조 시나리오

1. Bundle A에 포함된 Prefab A가 Bundle B의 ScriptableObject B를 참조함 (Bundle A ➔ Bundle B 의존성 생성).
2. Bundle B에 포함된 Prefab B 또는 이벤트 리스너가 Bundle A의 Texture A를 참조함 (Bundle B ➔ Bundle A 의존성 생성).
3. 개발자가 Prefab A를 해제(Release)하여 Bundle A의 자체 참조 카운트를 낮추려고 하지만, Bundle B가 여전히 Bundle A를 의존하고 있으므로 Bundle A의 참조 카운터는 0이 되지 않습니다.

이러한 상태가 지속되면 Addressables.Release()를 명시적으로 호출해도 메인 메모리(RAM)와 VRAM에서 에셋 번들이 언로드되지 않는 메모리 해제 지연 및 누수 현상이 발생하게 됩니다.

3. 순환 참조 및 메모리 누수 진단 도구 (Troubleshooting Tools)

문제의 원인을 명확히 규명하기 위해 Unity에서 제공하는 표준 프로파일링 도구를 조합하여 추적해야 합니다.

① Addressables Event Viewer 활용

Unity 상단 메뉴의 Window > Asset Management > Addressables > Event Viewer를 통해 런타임 중 에셋의 참조 카운트 변동을 실시간으로 감시할 수 있습니다.

• 특정 씬(Scene)을 벗어나거나 UI 팝업을 닫았음에도 그래프에서 참조 카운트(Ref Count)가 0으로 떨어지지 않고 주황색/파란색 스트림이 유지되는 에셋 번들을 확인합니다.

② Unity Memory Profiler를 통한 메모리 스냅샷 비교

Memory Profiler package를 활용해 해제 전/후의 메모리 스냅샷(Snapshot)을 채취하고 'Diff' 기능을 실행합니다. AssetBundleData 및 ObjectHeader 섹션에서 남아있는 에셋들을 식별하고 GC Handle Reference 추적을 통해 참조 체인을 역추적(Backtracking)합니다.

③ Addressables Build Layout Report 분석

Addressables 설정에서 Debug Build Layout을 활성화하면 빌드 시 Library/com.unity.addressables/buildlayout.txt 또는 JSON 형태의 보고서가 생성됩니다. 각 번들이 어떤 묵시적 에셋을 포함하고 있는지, 어떤 번들과 의존관계를 맺고 있는지 시각적으로 파악할 수 있습니다.

4. 실무 해결 전략 및 아키텍처 리팩토링

순환 참조로 인한 메모리 누수를 해결하기 위해서는 단순 코딩 수정을 넘어 에셋 구조와 코드 간의 결합도(Coupling)를 낮추는 아키텍처적 리팩토링(Refactoring)이 필요합니다.

전략 1: 공유 에셋의 전용 그룹 분리 (Extract Shared Dependencies)

두 개 이상의 어드레서블 그룹에서 고유하게 참조하는 공통 리소스(공용 머티리얼, 아틀라스 텍스처, 사운드 에셋 등)를 별도의 'Shared_Assets' 전용 그룹으로 분리하세요.

기존 (문제 발생 구조):
Group A (Prefab A, Shared Material) leftrightarrow Group B (Prefab B, Shared Material)
👉 번들 간 암시적 순환 의존성 발생

---

개선 (분리된 구조):
Group A (Prefab A) ➔ Shared Group (Shared Material)
Group B (Prefab B) ➔ Shared Group (Shared Material)
👉 단방향 의존성으로 변경되어 순환 고리 차단

전략 2: 하드 참조를 약한 참조(Weak Reference)로 전환

C# 스크립트에서 [SerializeField] private GameObject targetPrefab;과 같이 직렬화된 직접 참조(Hard Reference)를 사용하는 대신, AssetReference 또는 어드레서블 Key(String/GUID)를 통한 지연 로딩(Lazy Loading) 방식을 적용합니다.

// Bad Case: 하드 참조로 인한 에셋 번들 간 강력한 결합 및 순환 참조 위험 public class CharacterUI : MonoBehaviour { [SerializeField] private GameObject detailInfoPrefab; // Direct Hard Reference! } // Good Case: AssetReference 또는 Key를 사용한 디커플링 (Decoupling) public class CharacterUI : MonoBehaviour { [SerializeField] private AssetReferenceGameObject detailInfoPrefabRef; public async Task LoadDetailWindowAsync() { // 필요 시점에 동적 로드 (단방향 생명주기 제어) AsyncOperationHandle handle = detailInfoPrefabRef.InstantiateAsync(); await handle.Task; } public void CloseDetailWindow(GameObject instance) { // 사용 완료 후 명시적 메모리 해제 Addressables.ReleaseInstance(instance); } }

전략 3: 이벤트 기반 아키텍처(Event-Driven Architecture) 적용

에셋 또는 스크립트 간의 직접적인 상호작용이 필요할 때는 C# Event, ScriptableObject 기반 Event Channel, 또는 의존성 역전 원칙(Dependency Inversion Principle)을 적용하여 에셋 간 물리적 연결 고리를 끊어냅니다.

전략 4: 에지 케이스(Edge Cases) 조치 - Resources.UnloadUnusedAssets 및 GC 강제 실행

간혹 Addressables의 참조 카운트가 0이 되었음에도 불구하고, C# 힙(Heap) 메모리에 남아있는 GC Object가 에셋의 Native C++ Object를 가리키고 있어 실제 Unload가 지연되는 에지 케이스가 존재합니다. 씬 전환 시점이나 메모리 정리 타이밍에 아래 코드를 적절히 조율하여 호출합니다.

public System.Collections.IEnumerator ForceUnloadUnusedMemory() { // 1. C# 힙 메모리의 사용되지 않는 가비지 수거 System.GC.Collect(); // 2. 비동기로 사용되지 않는 Native 에셋 완전히 언로드 AsyncOperation unloadOp = Resources.UnloadUnusedAssets(); yield return unloadOp; // 3. 필요 시 GC 재호출하여 깨끗한 힙 상태 유지 System.GC.Collect(); }

결론 및 권장 체크리스트 (Best Practices)

Unity Addressables를 이용한 동적 리소스 관리 시 메모리 누수를 방지하기 위해서는 설계 단계부터 에셋 간의 의존성 구조를 최적화해야 합니다. 아래 핵심 체크리스트를 정기적으로 검토하는 것을 권장합니다.

• [ ] 그룹 분리 규칙 확립: 자주 변경되는 에셋과 공통으로 사용되는 정적 에셋의 그룹을 명확히 구분했는가?
• [ ] Addressables Event Viewer 정기 점검: 핵심 콘텐트 로드/해제 주기에서 참조 카운터가 잔존하지 않는지 검증했는가?
• [ ] 하드 참조 최소화: Prefab 내에 다른 어드레서블 그룹 에셋에 대한 직접 [SerializeField] 참조가 존재하지 않는가?
• [ ] Release 쌍 일치: LoadAssetAsync 또는 InstantiateAsync 호출 횟수와 Release / ReleaseInstance 호출 횟수가 1:1로 일치하는가?

체계적인 메모리 프로파일링과 에셋 리팩토링 기법을 적용하면, 순환 참조로 인한 리소스 해제 지연을 완벽하게 예방하고 모바일 및 멀티플랫폼 환경에서 안정적인 프레임 유지와 메모리 최적화를 달성할 수 있습니다.