실전으로 배운 유니티 최적화

Introduction

최근 프로젝트에서 최적화 작업을 담당하게 되었습니다. 최적화가 처음이라 어디서부터 시작해야할지 아예 감이 안잡혔습니다…

이 글은 제가 직접 박치기하면서 배운 유니티 최적화 방법들을 정리한 글입니다. 제가 직접 박치기 하면서 “이 코드가 왜 CPU 사용량을 많이 잡아먹는지”, “왜 GC.Alloc을 유발하는지” 원인을 분석해보고, 해결책을 찾아가면서 느꼈던 점들을 중심으로 작성했습니다.

Unity Profiler

일단 성능 최적화하기 전에 어디에서 성능 병목이 발생하는지 측정하고 분석하는 과정이 필요합니다. 유니티 에디터에서는 자체적으로 제공하는 Unity Profiler를 통해 CPU, GPU, Memory 사용량을 측정하고 분석할 수 있습니다.

How to Use Unity Profiler

일단 유니티 에디터 상단 메뉴에서 Window > Analysis > Profiler를 클릭하여 프로파일러 창을 엽니다.

저는 일단 CPU 최적화를 중심적으로 살펴보기 위해 CPU Usage의 Scripts, Garbage Collector 카테고리만 켜두고 나머지는 껐습니다.

Custom Profiler Markers

유니티 프로파일러는 기본적으로 유니티 엔진의 콜백 함수들 (Start, Update, FixedUpdate 등) 만 분석해주기 때문에 어떤 함수가 문제인지 찾기 어렵습니다. 이럴때는 ProfilerMarker 을 사용하여 그 부분만 자세하게 분석할 수 있습니다.

1
using Unity.Profiling;
2
public sealed class TestProfilerMarker
3
{
4
    private void Update()
5
    {
6
        MyMethod1();
7
        MyMethod2();
8
    }
9

10
    private static readonly ProfilerMarker myMarker1 = new ProfilerMarker("MyCustomMarker1");
11
    private static readonly ProfilerMarker myMarker2 = new ProfilerMarker("MyCustomMarker2");
12

13
    // 첫번째 방법
14
    private void MyMethod1()
15
    {
16
        myMarker1.Begin();
17
        // 측정하고 싶은 코드
18
        myMarker1.End();
19
    }
20

21
    // 두번째 방법
22
    private void MyMethod2()
23
    {
24
        using (myMarker2.Auto())
25
        {
26
            // 측정하고 싶은 코드
27
        }
28
    }
29
}

CPU Optimization

이제 Unity Profiler를 사용하여 어디가 문제인지 확인했으니 본격적으로 CPU 최적화를 해보겠습니다. CPU 최적화를 하면 프레임이 잘 나와서 게임이 부드럽게 돌아가지만 메모리 사용량은 늘어납니다. 하지만 대부분 PC는 메모리는 충분히 크기 때문에 CPU 최적화를 우선적으로 하는 것이 좋습니다.

Dirty Flag Pattern

처음에 이걸 보고 ”?? 더러운 플래그 패턴??” 라고 생각했는데, 이 패턴은 변경할떄만 업데이트하는 디자인 패턴입니다. 저희는 개발자니 코드로 보여드리겠습니다.

1
using UnityEngine;
2
public class DirtyFlagExample : MonoBehaviour
3
{
4
    [SerializeField] private Text curLeftBulletText;
5

6
    public int curLeftBullet = 10;
7
    private int _prevBullet = -1;
8

9
    private void Update()
10
    {
11
        // 이 코드는 매 프레임마다 Text를 변경합니다.
12
        curLeftBulletText.text = curLeftBullet;
13

14
        // 이 코드는 변경 할때만 Text를 변경합니다.
15
        if (_prevBullet != curLeftBullet)  // 이전 값과 현재 값 비교
16
        {
17
            _prevBullet = curLeftBullet;
18
            curLeftBulletText.text = curLeftBullet.ToString();
19
        }
20
    }
21
}

코드로 보면 더티 플래그 패턴은 이전 값을 캐시하고 현재 값과 비교하여 변경되었을 때만 업데이트하는 방식입니다. 이를 통해 불필요한 업데이트를 줄여 CPU 사용량을 크게 줄일 수 있습니다.

1
using UnityEngine;
2
public class DirtyFlagExample : MonoBehaviour
3
{
4
    [SerializeField] private Text curLeftBulletText;
5

6
    public int curLeftBullet { get; private set; } = 10;
7

8
    public void SetCurLeftBullet(int newBullet)
9
    {
10
        if (curLeftBullet != newBullet) // 변경되었을 때만 업데이트
11
        {
12
            curLeftBullet = newBullet;
13
            curLeftBulletText.text = curLeftBullet.ToString();
14
        }
15
    }
16
}

Caching

캐싱 (Caching)은 데이터 가져오는 비용이 비쌀 경우, 한 번만 가져와서 변수에 저장(캐시) 하고 필요할때마다 캐시해둔 변수를 사용하는 방법입니다.

아까 설명한 더티 플래그 패턴은 불필요한 실행을 줄이는 패턴이라면 캐싱은 불필요한 탐색을 줄이는 패턴입니다. (물론 더티 플래그 패턴도 캐싱의 일종이긴 합니다)

Component Caching

유니티에서 가장 비용이 많이 드는 작업 중 하나는 GetComponent, FindObjectsByType, Camera.main 처럼 씬에 있는 모든 오브젝트를 탐색 하는 작업입니다.

특히 이 함수들을 Update, FixedUpdate 같은 자주 호출되는 함수에서 사용하면 성능에 큰 영향을 미칩니다.

따라서 이러한 함수들은 Awake 또는 Start에서 한 번만 호출하여 캐싱하는 것이 좋습니다. GetComponent를 예시로 설명해보겟습니다.

1
using UnityEngine;
2
public class CachingExample1 : MonoBehaviour
3
{
4
    private void Update()
5
    {
6
        GetComponent<Rigidbody>().AddForce(Vector3.up * 10f);
7
    }
8
}

1
using UnityEngine;
2
public class CachingExample2 : MonoBehaviour
3
{
4
    private Rigidbody _rb;
5

6
    private void Awake()
7
    {
8
        _rb = GetComponent<Rigidbody>();
9
    }
10

11
    private void Update()
12
    {
13
        _rb.AddForce(Vector3.up * 10f);
14
    }
15
}

C++ and C# bridge

유니티는 엔진의 핵심 기능을 담당하는 C++ (Native) 코드와, 우리가 작성하는 C# (Managed) 코드라는 두 개의 다른 환경으로 이루어져 있습니다.

이 두 환경이 소통할때마다 브릿지를 건너야 합니다. GetComponent, transform 같은 유니티 API를 호출할 때마다 이 브리지 오버헤드가 발생합니다. 따라서 캐시를 하여 브리지 오버헤드를 줄이는 것이 좋습니다.

1
using UnityEngine;
2
public class TransformCachingExample : MonoBehaviour
3
{
4
    private Transform _cachedTransform;
5

6
    private void Awake()
7
    {
8
        _cachedTransform = transform;
9
    }
10

11
    private void Update()
12
    {
13
        _cachedTransform.position += Vector3.up * Time.deltaTime;
14
    }
15
}

1
byte[] data = new byte[1024 * 1024];
2

3
// 1. GC가 이 객체를 이동하지 못하도록 PIN 설정
4
GCHandle handle = GCHandle.Alloc(data, GCHandleType.Pinned);
5

6
// 2. C++에 고정된 메모리 주소 전달
7
IntPtr ptr = handle.AddrOfPinnedObject();
8

9
// 3. C++ 작업 완료후 PIN 해제
10
handle.Free();

Animation Key Hashing

Animator에서 애니메이션 상태를 전환할 때 문자열 이름을 직접 사용하는 것은 성능에 좋지 않습니다.

Animator.SetTrigger("Run")이나 Animator.SetFloat("Speed", value)를 호출하면 다음 작업을 수행합니다.

1. “Run”또는 “Speed” 문자열을 받고
2. 해시(Hash) 연산을 수행하여 int 값으로 변환
3. 해시된 int 값을 사용하여 실제 파라미터 값을 변경

Update에서 Animator.SetFloat을 호출하는 경우, 문자열 해싱 작업이 매 프레임마다 발생하여 성능에 좋지 않습니다. 따라서 Animator.StringToHash를 사용하여 id를 캐싱하고 재사용하는 방법을 사용합니다.

1
private Animator _animator;
2

3
private void Awake()
4
{
5
    _animator = GetComponent<Animator>();
6
}
7

8
private void Update()
9
{
10
    float speed = Input.GetAxis("Vertical");
11
    _animator.SetFloat("Speed", speed); // 매 프레임마다 문자열 해싱 발생
12
}

1
private static readonly int SpeedHash = Animator.StringToHash("Speed");
2
private Animator _animator;
3

4
private void Awake()
5
{
6
    _animator = GetComponent<Animator>();
7
}
8

9
private void Update()
10
{
11
    float speed = Input.GetAxis("Vertical");
12
    _animator.SetFloat(_speedHash, speed); // 해시를 사용하여 성능 최적화
13
}

1
public static class AnimHash
2
{
3
    public static readonly int Speed = Animator.StringToHash("Speed");
4
    public static readonly int Jump = Animator.StringToHash("Jump");
5
    // 다른 해시들...
6
}

1
using UnityEngine;
2
using static AnimHash; // AnimHash 클래스의 정적 멤버를 직접 사용
3

4
public class AnimatorHashingExample3 : MonoBehaviour
5
{
6
    private Animator _animator;
7
    private void Awake()
8
    {
9
        _animator = GetComponent<Animator>();
10
    }
11

12
    private void Update()
13
    {
14
        float speedValue = Input.GetAxis("Vertical");
15
        _animator.SetFloat(Speed, speedValue);
16
    }
17
}

Distance Checks

Update나 FixedUpdate에서 두 오브젝트 간의 거리를 측정하는 것은 AI, 플레이어 감지, 트리거 등 많이 사용되는 로직입니다. 하지만 Vector3.Distance나 Vector2.Distance는 제곱근 연산이 포함되어 있어 비용이 많이 듭니다.

1
x_next = 0.5 * (x_current + n / x_current)
2

3
// √16을 구한다면:
4
초기값 x0 = 4
5
x1 = 0.5 * (4 + 16/4) = 4         // 정확!
6
x2 = 0.5 * (4 + 16/4) = 4
7

8
// √10을 구한다면:
9
초기값 x0 = 3
10
x1 = 0.5 * (3 + 10/3) = 3.1666...
11
x2 = 0.5 * (3.1666 + 10/3.1666) = 3.1623...
12
x3 = 0.5 * (3.1623 + 10/3.1623) = 3.1622...  // 거의 정확

따라서 Distance 대신 SqrMagnitude를 사용하여 제곱근 연산을 피하는 것이 좋습니다.

1
[SerializeField] private float _detectionRange = 5f;
2
private Transform _target;
3

4
private void Update()
5
{
6
    float distance = Vector3.Distance(transform.position, _target.position);
7
    if (distance < _detectionRange)
8
    {
9
        // 타겟 감지
10
    }
11
}

1
[SerializeField] private float _detectionRange = 5f;
2
private Transform _target;
3
private float _detectionRangeSqr;
4

5
private void Awake()
6
{
7
    _detectionRangeSqr = _detectionRange * _detectionRange;
8
}
9

10
private void Update()
11
{
12
    float sqrDistance = (transform.position - _target.position).sqrMagnitude;
13
    if (sqrDistance < _detectionRangeSqr)
14
    {
15
        // 타겟 감지
16
    }
17
}

C#‘s Null Checks

if (myObject == null) C#에서 null을 체크하는 이 코드는 유니티에서는 단순한 코드가 아닙니다.

유니티의 GameObject, Transform 등 UnityEngine.Object를 상속받는 객체들은 C#과 C++ 양쪽에 존재합니다. Destory(myObject)를 호출하면 C++ 객체는 파괴되지만 C# 래퍼 변수는 null이 아닙니다. 이 상태를 가짜 null(fake null) 이라고 부릅니다.

유니티에서는 == 연산자를 오버로딩(overloading)하여, if (myObject == null)을 실행하면 두가지를 검사합니다.

1. C# 객체가 실제로 null인지 (C# null 체크)
2. C++ 브릿지를 건너가서 C++ 객체가 파괴 되었는지 (유니티의 가짜 null 체크)

이 가짜 null 체크는 C++와 C#의 브릿지 오버헤드를 발생시키므로 성능에 좋지 않습니다. 따라서 만약 C# null인지 궁금할떄는 Object.ReferenceEquals(myObject, null) 또는 myObject is null 패턴을 사용하면 됩니다.

1
private static bool CompareBaseObjects(Object lhs, Object rhs)
2
{
3
    bool flag1 = (object) lhs == null;
4
    bool flag2 = (object) rhs == null;
5

6
    // 1. C# null 체크
7
    if (flag2 & flag1)
8
      return true;
9

10
    // 2. 가짜 null 체크
11
    if (flag2)
12
      return !Object.IsNativeObjectAlive(lhs);
13
    return flag1 ? !Object.IsNativeObjectAlive(rhs) : lhs.m_InstanceID == rhs.m_InstanceID;
14
}

Data Structures & Logic

어떤 자료구조를 선택하고 데이터를 어떻게 접근하느냐에 따라 CPU 캐시 적중률과 명령어 처리 속도가 크게 달라집니다.

Array vs List

List<T>는 내부적으로 배열을 감싸고 있습니다. 인덱서(’[]‘)를 통해 접근할때마다 함수 호출 비용과 유효성 검사가 발생합니다. 극한의 최적화가 필요한 Hot Path (매 프레임마다 실행되는 코드)에서는 Array를 사용하는것이 좋습니다.

Dictionary Key Optimization

struct를 Key로 쓸 때 IEquatable<T>를 구현하지 않으면 .NET은 기본 비교 방식(ValueType.Equals)을 사용합니다. 기본 비교 방식은 리플렉션(Reflection) 을 사용하여 성능이 느립니다.

이때 int, float 같은 Blittable 타입일떄는 비트 단위 비교(Bitwise)로 최적화를 시도하지만, 참조 타입(string 등)이 하나라도 섞이면 리플렉션(Reflection)으로 돌아갑니다. 게다가 최적화 여부와 상관없이 박싱(Boxing) 문제는 계속 발생합니다.

1
struct GridPos { public int x, y; }
2

3
// GetHashCode/Equals 미구현 시, 내부적으로 Reflection을 사용하여 비교함
4
Dictionary<GridPos, Item> items;

1
struct GridPos : IEquatable<GridPos>
2
{
3
    public int x, y;
4

5
    // 이 함수가 있어야 리플렉션을 안 쓰고 직접 비교함
6
    public bool Equals(GridPos other) => x == other.x && y == other.y;
7
    public override int GetHashCode() => HashCode.Combine(x, y);
8
}

Data Locality (Struct vs Class)

CPU는 메모리에서 데이터를 가져올때 하나씩 가져오지 않고 캐시 라인(cache line, 보통 64바이트) 단위로 가져옵니다. 이떄 우리가 사용할 데이터들이 메모리에 연속적으로 배치되어 있으면 캐시 적중률이 높아져 성능이 좋아집니다.

• Class Array

  배열에는 몬스터의 주소(참조)만 들어있습니다. 실제 데이터는 힙 메모리 여기저기에 흩어져 있어, 접근할 때마다 메모리 점프(Pointer Chasing)가 발생하고 캐싱 미스(Cache Miss)가 일어납니다.

• Struct Array

  데이터 자체가 배열 안에 연속적으로 꽉 차 있습니다. CPU 캐시에 매우 친화적입니다.

데이터 개수가 많고 자주 순회해야 한다면, Class 대신 Struct 배열을 사용하는것이 좋습니다.

1
// AoS: 일반적인 객체지향 방식 (캐시에 불필요한 필드도 로딩됨)
2
struct Enemy { public int hp, mp; public string name; public Vector3 position; }
3
Enemy[] enemies;
4

5
for (int i = 0; i < enemies.Length; i++)
6
{
7
    enemies[i].hp -= 10; // 매번 캐시 라인에 불필요한 필드도 로딩됨
8
}

1
// SoA: 데이터 지향 설계 (필요한 데이터만 캐시에 로딩됨)
2
int[] enemyHps;
3
int[] enemyMps;
4
string[] enemyNames;
5
Vector3[] enemyPositions;
6

7
for (int i = 0; i < enemyHps.Length; i++)
8
{
9
    enemyHps[i] -= 10;
10
}

1
struct BigData
2
{
3
    // 40바이트짜리 무거운 구조체
4
    int a, b, c, d, e, f, g, h, i, j;
5
}
6

7
// Bad: 값이 통째로 복사됨 (40바이트 복사 발생)
8
public void ProcessData(BigData data) { ... }
9

10
// Good: 참조만 전달됨 (포인터 크기만큼만 비용 발생, 복사 없음)
11
public void ProcessData(in BigData data) { ... }

Switch vs If-Else

분기가 많아질수록 switch는 if-else보다 성능이 매우 좋습니다.

1
switch (state)
2
{
3
    case 0: Run(); break;
4
    case 1: Jump(); break;
5
    case 2: Attack(); break;
6
    // ...
7
    case 100: Die(); break;
8
    // If-else 였다면 100번 비교해야 도달함
9
    // Switch는 O(1)로 즉시 실행
10
}

Sealed Class

C#의 virtual 메소드나 인터페이스 호출은 런타임에 가상 함수 테이블(vtable) 을 조회(Lookup)해야 하므로 일반 함수보다 느립니다. 더 이상 상속되지 않는 클래스라면 sealed을 붙이는것이 좋습니다.

sealed를 붙이면 유니티의 IL2CPP 컴파일러가 “이 함수는 오버라이딩 될 리 없다”고 판단하여 Devirtualization(가상화 제거) 및 Inlining(인라인) 최적화를 수행합니다.

1
// IL2CPP가 Move() 함수를 직접 호출(Direct Call)로 최적화함
2
public sealed class PlayerMovement : MonoBehaviour
3
{
4
    public void Move() { ... }
5
}

Memory (GC) Optimization

GC Alloc

GPU Optimization

Unity Engine Deep Dives

Afterword

이 글이 유니티 최적화에 관심있는 분들께 도움이 되었으면 좋겠습니다. 여기에 안 나온 최적화 팁이나, 더 좋은 방법이 있다면 유니티 최적화 토론에 공유해 주세요!

Sources:

• Main Illustration by 앣타 망가짐
• ZString
• UniTask
• Unity Documentation
• C# Documentation