Unity 3D 대규모 씬 환경에서 Addressables 비동기 로딩 시 발생하는 GC 스파이크 및 프레임 스터터링 최적화 가이드

🌐 English Abstract

This article provides a deep technical analysis of Garbage Collection (GC) spikes and frame stuttering during asynchronous asset loading with Unity Addressables in large-scale 3D scenes. It covers the root causes within Unity's Managed Heap and Main Thread operation, profiling methodologies using Unity Profiler, and practical zero-allocation optimization techniques. Developers will learn actionable solutions including LZ4 compression tuning, custom UniTask wrapper implementation, and pre-allocated object pooling strategies for seamless performance.

유니티(Unity 3D) 엔진에서 대규모 씬(Large-scale Scene)이나 오픈 월드 환경을 개발할 때, 에셋 관리 및 메모리 최적화를 위해 어드레스블 에셋 시스템(Addressable Asset System)을 도입하는 것은 현재 업계 표준으로 자리 잡았습니다. 그러나 많은 개발진이 비동기 로딩 API인 Addressables.LoadAssetAsync 또는 Addressables.InstantiateAsync를 채택했음에도 불구하고, 실시간 게임플레이 도중 심각한 프레임 스터터링(Frame Stuttering)과 GC 스파이크(Garbage Collector Spikes) 현상을 겪곤 합니다.

분명 '비동기(Asynchronous)'로 로딩을 처리하도록 코드를 작성했음에도 불구하고 왜 메인 스레드(Main Thread)가 멈추고 화면이 튀는 현상이 발생할까요? 본 포스팅에서는 비동기 에셋 로딩 동작 과정에서 일어나는 유니티 내부 메커니즘을 심도 있게 파헤치고, 프로파일링 진단법부터 현업에서 즉시 적용 가능한 실전 최적화 기법까지 완벽히 다룹니다.

1. Addressables 비동기 로딩 중 GC 스파이크가 발생하는 내부 메커니즘

"비동기 로딩을 사용하면 메인 스레드 연산과 무관하게 백그라운드 스레드(Background Thread)에서 모든 처리가 완료될 것이다"라는 생각은 대표적인 오해입니다. 유니티의 C# 관리형 힙(Managed Heap) 영역과 렌더링 파이프라인의 핵심 작업은 여전히 메인 스레드에서 직렬화(Serialization)되어 실행되기 때문입니다.

가. 비동기 작업 중 메인 스레드 블로킹(Main Thread Blocking) 원인

어드레스블이 에셋 묶음(AssetBundle)을 로드할 때 백그라운드 스레드에서는 디스크 I/O와 에셋 데이터의 압축 해제(Decompression) 작업이 일어납니다. 하지만 압축 해제된 바이너리 데이터를 바탕으로 실제 유니티 엔진 내부의 C++ 에셋 객체(Mesh, Texture, Material 등)를 생성하고 메인 스레드의 렌더링 파이프라인에 등록하는 작업(Integration Phase)은 반드시 메인 스레드에서 이루어집니다. 이 작업이 단일 프레임에 과도하게 몰리면 메인 스레드 점유 시간이 길어져 프레임 드랍이 발생합니다.

나. 관리형 메모리 할당(Managed Memory Allocation)과 GC 탭

비동기 로딩을 호출하는 과정에서 발생하는 Garbage(가비지)는 크게 세 가지 요인에서 기인합니다:

• C# Task 및 AsyncOperationHandle 박싱(Boxing): AsyncOperationHandle을 제네릭 구조체 형태로 다루거나 Task / Coroutine으로 변환(Awaiting)하는 과정에서 힙 할당이 발생합니다.
• 문자열 기반 키(String-based Address Keys) 검색: 에셋 주소값을 string으로 전달할 때 발생하는 런타임 문자열 할당 및 딕셔너리(Dictionary) 해시 탐색 오버헤드입니다.
• 내부 콜백(Callback) 매개변수 캡처: 비동기 작업 완료 시 실행할 람다식(Lambda Expression)이나 이벤트 핸들러가 외부 변수를 캡처할 때 익명 클래스 객체가 힙에 생성됩니다.

이러한 미세한 메모리 할당들이 대규모 씬 전환이나 대량의 에셋(예: 프리팹 50개 동시 로딩) 처리 시 순간적으로 수 메가바이트(MB) 단위로 누적되며, 결국 유니티의 점진적 가비지 컬렉터(Incremental GC)마저 제어할 수 없는 거대한 GC 스파이크를 촉발하게 됩니다.

2. Profiler를 활용한 병목 지점 진단 및 측정

문제 해결을 위해서는 정확한 측정(Measurement)이 선행되어야 합니다. 유니티 프로파일러(Unity Profiler)와 에셋 프로파일링 도구를 사용하여 스터터링의 주범을 추적하는 방법입니다.

가. Unity Profiler 핵심 샘플러 Marker 확인

프로파일러의 CPU Usage 모듈에서 Hierarchy 뷰를 GC Alloc 기준으로 정렬한 뒤 다음 마커(Marker)들을 추적해야 합니다:

• AssetBundleRequest.GetResult / AwakeFromLoad: 에셋 직렬화 데이터를 해제하고 메인 스레드에 객체를 생성할 때 발생하는 병목입니다. 이 수치가 높다면 에셋 단위 분괄(Granularity)이 잘못되었거나 단일 프레임에 너무 많은 에셋을 로드하고 있음을 뜻합니다.
• GC.Collect: 메모리 할당 한계를 초과하여 가비지 컬렉터가 동기적으로 실행되었음을 알리는 신호입니다.
• UpdateAllProviders: Addressables 리소스 관리 시스템 내부에서 릴리스(Release) 상태 및 종속성(Dependency)을 갱신할 때 발생하는 힙 할당 지점입니다.

나. Profile Analyzer를 이용한 프레임 간 격차 비교

단일 프레임 분석만으로 부족할 경우, 유니티 패키지 매니저의 Profile Analyzer를 활용해 로딩 전/후 300프레임 간의 Mean Time(평균 시간)과 Max Time(최대 시간)을 비교합니다. 로딩 중 프레임 타임이 16.6ms(60fps 기준)를 넘어서는 구간의 GC Alloc 발생 횟수와 힙 메모리 급증 지점을 시각적으로 검증할 수 있습니다.

3. GC 스파이크 및 스터터링 해결을 위한 4단계 최적화 솔루션

단계 1: AssetBundle 압축 옵션 및 로딩 버퍼 조정 (LZ4 vs LZMA)

어드레스블 빌드 설정(Addressable Asset Group Settings)에서 기본 압축 방식을 최적화해야 합니다. 기본값인 LZMA 압축은 압축률이 높지만 런타임에 전체 묶음을 메인 스레드 메모리에 풀어야 하므로 프레임 드랍의 주원인이 됩니다.

• LZ4 압축 적용: 청크 기반(Chunk-based) 압축 방식인 LZ4를 적용하면 에셋을 필요한 부분만 실시간으로 압축 해제하므로 로딩 스파이크를 획기적으로 줄일 수 있습니다.
• AssetBundle 로딩 버퍼(Loading Buffer) 최적화: QualitySettings.asyncUploadBufferSize를 기본값(4MB 또는 16MB)에서 64MB 이상으로 크게 늘려줍니다. 이 버퍼는 텍스처와 메시 데이터를 CPU 메모리를 거치지 않고 디스크에서 GPU VRAM으로 직접 이관(Async Upload Pipeline)하는 통로 역할을 수행하여 메인 스레드 병목을 제거합니다.

단계 2: GC-Free C# Async Architecture (UniTask 도입)

유니티 기본 Task나 Coroutine(YieldInstruction)은 비동기 호출 시마다 힙 객체를 할당합니다. 성능 최적화를 위해 UniTask 라이브러리를 도입하고 AsyncOperationHandle의 직접적인 Task 변환을 지양해야 합니다.

단계 3: 프레임 버짓팅(Frame Budgeting) 기반 비동기 큐 구현

대규모 씬의 프리팹 100개를 동시에 Addressables.InstantiateAsync로 호출하면 비동기 작업이라 하더라도 동일 프레임에 메인 스레드 인스턴스화 작업이 쏠리게 됩니다. 이를 방지하기 위해 프레임당 시간 예산(예: 프레임당 최대 3ms)을 설정하고 작업을 분산시키는 작업 큐(Task Queue)를 적용해야 합니다.

단계 4: Pre-Warming과 객체 풀링(Object Pooling)의 고도화 결합

어드레스블을 통해 에셋을 로드(LoadAssetAsync)한 후 InstantiateAsync를 직접 매번 호출하는 대신, 씬 진입 전 Pre-load 단계에서 에셋의 원본 핸들만 메모리에 띄워두고(Pre-warming), 런타임 생성을 유니티의 UnityEngine.Pool 기반 오브젝트 풀과 연동하는 패턴으로 전환해야 합니다.

4. 실무용 고성능 비동기 에셋 로더 코드 예제

아래 예제 코드는 C#의 힙 할당을 극단적으로 줄이면서(Zero-Allocation 지향), UniTask와 프레임 버짓팅 방식을 조합하여 어드레스블 에셋을 안전하게 비동기 로딩하는 실무형 래퍼(Wrapper) 구현체입니다.

using System.Collections.Generic;
using Cysharp.Threading.Tasks;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;

public class ZeroAllocAddressableLoader : MonoBehaviour
{
    // 에셋 핸들 캐싱을 통한 재로딩 시 GC 및 I/O 발생 방지
    private readonly Dictionary<string, AsyncOperationHandle> _handleCache 
        = new Dictionary<string, AsyncOperationHandle>(128);

    /// <summary>
    /// GC Alloc을 최소화한 안전한 비동기 에셋 로딩
    /// </summary>
    public async UniTask<T> LoadAssetZeroAlloc<T>(string addressKey) where T : UnityEngine.Object
    {
        // 1. 이미 캐시된 핸들이 존재하는지 확인 (메모리 낭비 및 중복 로드 방지)
        if (_handleCache.TryGetValue(addressKey, out var cachedHandle))
        {
            if (cachedHandle.IsValid())
            {
                return (T)cachedHandle.Result;
            }
            _handleCache.Remove(addressKey);
        }

        // 2. 비동기 로드 시작 (AssetReference 대신 내부 문자열 키 직접 이용)
        AsyncOperationHandle<T> handle = Addressables.LoadAssetAsync<T>(addressKey);

        // 3. UniTask를 활용하여 힙 할당(Task 객체 생성) 없이 await 처리
        await handle.ToUniTask(PlayerLoopTiming.Update);

        if (handle.Status == AsyncOperationStatus.Succeeded)
        {
            _handleCache[addressKey] = handle;
            return handle.Result;
        }

        Debug.LogError($"[AddressableLoader] 에셋 로드 실패: {addressKey}");
        if (handle.IsValid())
        {
            Addressables.Release(handle);
        }
        return null;
    }

    /// <summary>
    /// 프레임 스터터링 방지를 위한 큐 기반 분산 인스턴스화 예시
    /// </summary>
    public async UniTask BatchInstantiateWithBudget(List<string> keys, float maxFrameTimeMs = 3.0f)
    {
        float frameBudgetSec = maxFrameTimeMs / 1000.0f;

        for (int i = 0; i < keys.Count; i++)
        {
            float startTime = Time.realtimeSinceStartup;

            // 에셋 로드
            GameObject prefab = await LoadAssetZeroAlloc<GameObject>(keys[i]);
            if (prefab != null)
            {
                Instantiate(prefab);
            }

            // 현재 프레임 소요 시간이 설정된 예산(Frame Budget)을 초과하면 다음 프레임으로 대기 이관
            if (Time.realtimeSinceStartup - startTime > frameBudgetSec)
            {
                await UniTask.Yield(PlayerLoopTiming.Update);
            }
        }
    }

    private void OnDestroy()
    {
        // 핸들 해제 메모리 누수 방지
        foreach (var handle in _handleCache.Values)
        {
            if (handle.IsValid())
            {
                Addressables.Release(handle);
            }
        }
        _handleCache.Clear();
    }
}


5. 대규모 심리스 맵 적용 시 엣지 케이스(Edge Cases) 대응

가. 중복 에셋 번들(Duplicate Bundles)과 무분별한 메모리 팽창
서로 다른 어드레스블 그룹에 동일한 머티리얼(Material)이나 텍스처 에셋이 참조되어 있는 경우, 유니티는 에셋 번들을 빌드할 때 해당 에셋을 각 번들에 중복으로 포함시켜 버립니다. 이로 인해 메모리가 이중으로 낭비되고 런타임 로딩 시간이 늘어나게 됩니다.
해결책: Addressables Window의 Analyze Tool을 반드시 주기적으로 실행하여 "Check Duplicate Bundle Dependencies" 규칙을 검사해야 합니다. 공통으로 참조되는 에셋들은 별도의 Shared_Assets 그룹으로 추출하여 단일 번들로 묶이도록 종속성을 격리해야 합니다.

나. 저사양 모바일 기기에서의 Incremental GC 한계
유니티의 점진적 가비지 컬렉터(Incremental GC)는 GC 실행 시간을 여러 프레임으로 분산시켜 주지만, 순간적인 힙 할당 크기가 한 프레임의 Incremental GC 허용 범위를 넘어서면 강제 동기(Synchronous) GC로 전환됩니다. 특히 저사양 모바일 기기(Android RAM 4GB 이하 등)에서는 이 스파이크가 50ms~100ms 이상의 멈춤 현상으로 직결됩니다.
따라서 대규모 씬 이동 전 System.GC.Collect() 및 Resources.UnloadUnusedAssets()를 로딩 화면(Loading Screen)과 같은 안전한 연출 구간에서 명시적으로 선제 호출하여, 게임플레이 도중 자동 GC가 터지지 않도록 여유 힙 메모리를 확보하는 전략이 필요합니다.











6. 결론 및 요약

Addressables 시스템을 활용한 비동기 에셋 로딩은 대규모 유니티 프로젝트의 필수요소이지만, 단순히 async/await 키워드를 사용하는 것만으로는 프레임 스터터링과 GC 스파이크로부터 자유로울 수 없습니다.


    
에셋 압축 및 전송 버퍼 최적화: LZ4 압축 방식을 사용하고 asyncUploadBufferSize를 최소 64MB 이상으로 확보하여 GPU 이관 병목을 줄입니다.
    
C# 메모리 할당 최소화: UniTask와 struct 기반 핸들을 활용하고 람다식 매개변수 캡처 및 문자열 키 할당을 방지합니다.
    
프레임 예산(Frame Budgeting) 분산: Instantiate 연산이 단일 프레임에 과도하게 쏠리지 않도록 큐(Queue) 시스템으로 이관합니다.
    
중복 종속성 지속 분석: Analyze Tool을 활용해 묶음 간 중복 리소스를 제거하고 사전 로딩(Pre-warming) 기법을 구조화합니다.


이러한 최적화 아키텍처를 프로젝트 초기에 정립해 둔다면, 대규모 심리스 3D 환경에서도 60 FPS를 안정적으로 유지하는 고성능 모바일 및 PC 게임을 성공적으로 구축할 수 있을 것입니다.