KiTFOx's Notepad 📝

1. Garbage Collection(GC)이란?

GC는 더 이상 사용되지 않는 메모리를 자동으로 회수해주는 기능
C#, Java 같은 관리형 언어 에서 제공됨

기본 개념
- 힙(Heap) 영역에 할당된 객체 중 더 이상 참조되지 않는 객체를 찾아서 메모리를 회수함
- 수동 해제가 필요 없는 대신, GC 타이밍에 따라 성능 저하 발생 가능

2. GC 동작 방식 (C# 기준)

Mark and Sweep 방식
1. Mark : 루트(Root) 객체에서 시작해 참조 가능한 객체를 모두 “살아있다”고 표시
2. Sweep : 표시되지 않은 객체는 메모리에서 제거

세대별 관리(Generational GC)
- Generation 0 : 새로 생성된 객체 (빠르게 수거)
- Generation 1 : 조금 오래된 객체
- Generation 2 : 오래 살아남은 객체 (GC 대상에서 제외되기 쉬움)
-> 대부분의 GC는 Gen 0 대상이 많고, Gen 2는 잘 안 지워짐

GC Alloc

매 프레임마다 힙 메모리를 할당하는 코드가 있을 경우, GC가 자주 발생하면서 성능 저하 유발
GC가 실행되는 순간 Stop-the-world(잠깐의 멈춤)이 발생


GC 발생 예시

void Update() {
    string msg = "Score: " + score; // 매 프레임마다 새 string 생성 → GC Alloc
}

Unity에서 자주 발생하는 GC 원인

1. string 연결 : 문자열은 불변(immutable) 객체라 새로 만들어짐
2. List<T>.Add() : 내부 배열이 넘치면 새로운 배열 생성
3. foreach : IEnumerator 박싱 발생 가능
4. LINQ 사용 : 무조건 힙 할당 발생
5. 이벤트 핸들러에 람다 등록 후 해제 안함 : 메모리 누수 위험

4. GC 최소화 전략

(1) 객체 풀링 (Object Pooling)

- 자주 생성/제거되는 객체는 풀로 관리
- 예 : 총알, 이펙트, UI 토스트 등
Unity에서는 UnityEngine.Pool.ObjectPool<T> 사용 가능

(2) 구조체 사용 및 값 타입 활용

- 클래스 대신 struct 사용 (힙 할당 피함)
- 단, 구조체는 복사 비용 있으니 신중하게 사용

(3) StringBuilder 활용

(4) NativeArray, Job System 사용

- Unity DOTS 환경에서는 GC 없는 데이터 구조 사용 가능
- NativeArray, NativeList 등은 GC 발생 없이 작업 가능

5. Unity에서 GC 모니터링 팁

- Profiler -> Memory -> GC Alloc 확인
- Deep Profiling 을 켜면 어떤 코드에서 GC가 발생했는지 추적 가능
- Profiler.BeginSample("Tag")으로 수동 태깅 가능

1. 캐시란?

CPU는 매우 빠르지만, RAM은 상대적으로 느림
그래서 CPU와 RAM 사이에 작은 고속 메모리인 “캐시(Cache)"가 존재함
- L1,L2,L3 캐시 : 점점 느리지만 크기는 커짐
- CPU가 데이터를 요청할 때:
  - 캐시에 있으면 -> Cache Hit (빠름)
  - 없으면 -> Cache Miss (느림, RAM까지 내려감)

2. Cache Hit vs Cache Miss

- Cache Hit : CPU가 찾는 데이터가 캐시에 이미 존재 : 빠름 (수 ns)
- Cache Miss : CPU가 찾는 데이터가 캐시에 없음 -> RAM에서 가져옴 (수십~수백 ns)

3. Spatial & Temporal Locality (지역성)

CPU 캐시는 지역성(Locality)을 기반으로 작동함
- Temporal Locality (시간적 지역성):
  - 최근 사용한 데이터는 또 사용할 가능성 높음
- Spatial Locality (공간적 지역성):
  - 인접한 데이터도 같이 사용할 가능성 높음
그래서 CPU는 데이터를 불러올 때, 근처 메모리 덩어리(=Cache Line) 전체를 미리 불러옴 (보통 한 cache line은 64바이트)

4. 캐시 미스가 발생하는 경우

- 불연속 메모리 접근
- 무작위 포인터 접근
- 큰 구조체를 지나치게 복사
- 다중 쓰레드에서 동일한 캐시라인 접근 (false sharing)

5. Unity/ECS 관점에서

ECS + Chunk 구조는 이 문제를 해결하기 위해 디자인됨
- Chunk는 데이터가 연속된 메모리에 저장됨
- 따라서 for-loop로 순회할 때 Cache Hit가 극대화
- 반대로, GameOjbect + MonoBehaviour는 각 데이터가 산발적으로 메모리에 있음 -> Cache Miss 자주 발생

6. 예시 코드 비교 (Cache Friendly vs Cache Unfriendly)

[Cache Unfriendly]

class Unit {
    public float posX, posY, velX, velY;
}

Unit[] units = new Unit[100000];

for (int i = 0; i < units.Length; i++) {
    units[i].posX += units[i].velX;
}

-> 각 Unit이 메모리 상 흩어져 있어 캐시 미스 발생

[Cache Friendly - ECS 스타일]

struct Position { public float x, y; }
struct Velocity { public float x, y; }

NativeArray<Position> positions;
NativeArray<Velocity> velocities;

for (int i = 0; i < positions.Length; i++) {
    positions[i].x += velocities[i].x;
}

-> 연속된 메모리, 캐시 히트율 높음

- CPU 캐시는 RAM보다 빠른 중간 저장소
- Cache Hit = 빠르게 데이터 처리 가능
- Cache Miss = RAM 접근 -> 느려짐
- 연속된 메모리 접근 & 지역성 고려가 핵심
- Unity ECS는 캐시 최적화를 위해 설계됨

멀티스레딩 성능 최적화 : False Sharing과 Data Alignment 이해하기

1. False Sharing (가짜 공유)

멀티스레딩 환경에서 두 개 이상의 스레드가 서로 다른 데이터를 접근한다고 해도, 그 데이터들이 같은 캐시 라인(Cache Line)에 존재하면 문제가 생길 수 있음
왜 문제가 되는가?
- CPU는 데이터를 캐시 라인 단위(64바이트 등)로 불러옴
- 스레드 A가 변수 a를 수정 -> 같은 캐시 라인에 있는 스레드 B의 변수 b도 불필요하게 무효화됨
- 그 결과, CPU는 캐시를 계속 동기화(sync)해야 하며, 성능 저하로 이어짐

예시

public class SharedData
{
    public int a; // Thread 1 사용
    public int b; // Thread 2 사용
}

- a와 b는 서로 다른 쓰레드가 사용하지만, 같은 64바이트 정도)에 들어가 있을 확률이 높음
- Thread 1이 a를 수정 -> CPU는 a가 있는 캐시 라인을 다른 코어와 동기화해야 함
- 그 결과 Thread 2도 b에 접근할 때 불필요하게 캐시 미스나 성능 저하 발생

해결 방법:
- 캐시 라인 패딩(Padding)을 넣어서 분리시킴
데이터를 서로 다른 캐시라인에 배치하는 것

[StructLayout(LayoutKind.Explicit, Size = 128)] // 64바이트 이상으로 분리
public struct PaddedInt
{
    [FieldOffset(64)] public int value;
}

- StructLayout을 이용해 데이터를 인위적으로 띄워서 false sharing 방지
- Unity에서도 비슷한 방식의 캐시 라인 패딩 기법이 사용됨

또는 Unity의 Burst/Jobs에서는:

[StructLayout(LayoutKind.Sequential)]
public struct Counter1 : IJob
{
    [NativeDisableParallelForRestriction]
    public NativeArray<int> array;

    public void Execute()
    {
        array[0]++;
    }
}

-> NativeArray<int>에선 false sharing이 날 수 있으니 index마다 64바이트 정도 띄워서 접근하거나 NativeArray<CustomPaddedStruct>를 사용

2. Data Alignment (데이터 정렬)

정의:
CPU는 데이터가 특정 바이트 단위로 정렬되어 있어야 효율적으로 접근 가능
잘 정렬된 데이터는 한 번에 읽을 수 있음, 그렇지 않으면 여러 번 읽거나 느려짐

struct A {
    byte a;
    int b;
}

- 위 구조체에서 byte a는 1바이트지만, int b는 4바이트 정렬이 필요함 -> 사이에 3바이트 패딩이 자동 삽입 됨

Unity에서 주의할 점:

- IComponentData 구조체는 가능한 한 4,8,16바이트 단위로 정렬하는 게 좋음
- float3는 16바이트 정렬됨 -> 뒤에 int가 오면 불필요한 정렬비용 발생 가능

정렬 최적화

// 나쁜 예
struct Bad {
    public int a;
    public byte b;
    public float3 c;
}

// 좋은 예
struct Good {
    public float3 c;
    public int a;
    public byte b;
}

1. 메모리 모델이란?

멀티쓰레드 환경에서 메모리에 접근할 때의 규칙과 보장 범위를 정의한 것
- 우리가 x = 10 같은 코드를 쓴다고 해도, 실제 실행 순서나 읽는 값은 CPU, 컴파일러, 메모리 최적화에 의해 달라질 수 있음
-> 언제 어떤 값이 보장되는지? -> 메모리 모델이 이걸 정의해서 줌

2. 왜 중요한가?

멀티코어 CPU에서는 각 코어마다 캐시가 있음
-> 변수 값을 바로 RAM에서 읽지 않고, 자기 캐시에서 읽고 쓸 수 있음
-> 그러면 문제가 생김:
A 코어가 x=10 했는데, B 코어는 x가 0인줄 알고 잘못된 계산을 할 수 있음

3. Cache Coherency (캐시 일관성)

멀티코어 CPU는 코어들 간 캐시의 값을 동기화해야 함
-> 이걸 캐시 일관성(coherency)라고 함

대표적인 프로토콜 : MESI (Modified, Exclusive, Shared, Invalid)
-> 각 캐시 라인이 어떤 상태인지 추적해서
-> 값이 변경되면 다른 코어들에게 알림 (Invalidation)

4. CPU/컴파일러의 명령어 재배치 문제

- CPU나 컴파일러는 성능을 위해 명령어 순서를 바꾸기도 함
- a = 1; b = 2; -> 실제로는 b = 2; a = 1; 이 먼저 실행될 수도 있음
- 단일 쓰레드에선 문제 없지만, 멀티쓰레드에선 Race Condition 발생 가능

5. 해결 방법: 메모리 배리어 & volatile

5-1. Memory Barrier (메모리 장벽)

- CPU가 명령어 순서 재배치를 하지 않도록 막는 명령
- 종류
  - Load Barrier: 읽기 순서 고정
  - Store Barrier: 쓰기 순서 고정
  - Full Barrier: 읽기/쓰기 모두 순서 고정

5-2. volatile 키워드 (C#)

- 변수에 volatile을 붙이면:
  - 항상 메인 메모리에서 읽고 씀
  - CPU 캐시/컴파일러 최적화 방지
  - 단점 : 완전한 동기화는 안 됨 (lock은 아님)

6. .NET 메모리 모델 요약

- C#의 lock, Interlocked, volatile은 모두 메모리 모델 보장을 기반으로 동작
- lock은 내부적으로 Memory Barrier가 포함됨 -> 안정적
- Interlocked도 원자적(더이상 쪼갤수 없는) 연산 + 메모리 베리어를 자동 삽입

7. Unity에서는?

- Unity는 기본적으로 메인 스레드에서 모든 API 동작이 이루어짐
- 하지만 Job System, Burst, NativeArray 같은 구조를 사용할 땐:
  - 메모리 접근 순서와 캐시 동기화에 신경 써야 함
  - Unity의 Jobs.WithReadOnly(), NativeContatiner 특성은 메모리 일관성을 위한 힌트 역할을 함

Burst Compiler란?
요약
C# 코드를 네이티브 머신코드로 컴파일해주는 Unity 전용 고속 컴파일러
특징
- JIT이 아니라 AOT (Ahead of Time) 방식
- 일반 C# 코드보다 수십 배 빠를 수 있음
- SIMD(벡터 명령어)와 CPU 캐시 최적화를 적극 사용
- Unity Editor에서는 Burst가 적용된 함수는 즉시 확인 가능

[BurstCompile]
public struct MyJob : IJob
{
    public void Execute()
    {
        // 고속 실행 코드
    }
}

장점
- CPU 명령 최적화
- 메모리 접근 최소화
- 쓰레드 안전 보장

Job System이란?

요약
Unity가 제공하는 멀티스레딩 작업 시스템
-> 메인 스레드를 막지 않고, 여러 작업을 동시에 실행 가능
기본 개념
- IJob : 단일 작업 (작업 단위)
- IJobParallelFor : 병렬 반복 (for 루프를 다중 코어에 분산)
- IJobChunk : ECS에서 쓰는 대용량 처리용 Job


장점
- 메인 스레드 해방
- Unity가 자동으로 작업을 쓰레드풀에 분배
- Burst + Job 조합으로 엄청난 성능 확보 가능

NativeArray란?

요약
Unity의 메모리 효율적인 배열 구조체
C#의 List<T>, Array보다 빠르고 버스트/잡 시스템에 최적화됨
특징
- GC가 발생하지 않음
- 연속된 메모리 -> CPU 캐시 친화적
- 반드시 Dispose()로 수동 메모리 해제 필요

Unity DOTS 생태계 요약

- ECS : 구조 자체를 데이터 지향적으로
- Job System : 다중 작업 스케줄링
- Burst Compiler : 실행 성능 극대화
- Native Collections : GC 없는 구조

Unity DOTS 전체 개념 요약

DOTS는 Data-Oriente Technology Stack의 약자
목표는 수십만 개 오브젝트도 부드럽게 처리하는 것

ECS 구조 핵심 정리

ECS는 OOP와 반대되는 개념
Entity에 데이터만 부착
시스템(System)이 모든 엔티티 순회 처리
순차적 데이터 중심 (캐시 친화적)

public struct Position : IComponentData {
    public float3 Value;
}

public struct Velocity : IComponentData {
    public float3 Value;
}

public partial class MoveSystem : SystemBase {
    protected override void OnUpdate() {
        float dt = Time.DeltaTime;
        Entities
            .ForEach((ref Position pos, in Velocity vel) =>
            {
                pos.Value += vel.Value * dt;
            }).ScheduleParallel(); // Job + Burst 적용 가능
    }
}

Chunk 구조

ECS는 내부적으로 동일한 Archetype (컴포넌트 조합)의 엔티티들을 Chunk라는 덩어리에 저장함
- 하나의 Chunk = 수십 개 ~ 수백 개 엔티티
- 메모리 연속 = CPU 캐시에 완전 최적화
- System은 Chunk 단위로 데이터를 순회함

Transform, Velocity, Health가 같이 있는 Entity는 같은 메모리 블록에 정렬됨

Job + Burst가 붙으면 생기는 일

- SystemBase의 .ScheduleParallel()은 내부적으로 Job을 생성함
- 이 Job은 Burst로 컴파일되면 네이티브 SIMD 명령어로 최적화돼서, 수백 개 엔티티를 한 번에 밀어냄 -> 엄청 빠름

최적화 요령

- IComponentData만 사용 : 참조형보다 value형 구조체 사용
- SharedComponentData는 신중하게 사용 : Chunk 분할을 유발하므로
- Archetype 조합 최소화 : Chunk 파편화를 방지
- System은 ScheduleParallel 우선 사용 : 병렬 처리 효율 증가
- NativeArray에 BurstCompile 적용 : 연산 성능 극대화
- math 라이브러리 적극 활용 : float3, dot, normalize 등 SIMD 최적화됨

DOTS 흐름 예시

1. 엔티티 생성
2. System이 모든 Entity 순회
3. 컴포넌트 조합에 따라 Chunk 단위로 순회
4. Job System이 쓰레드로 분산 처리
5. Burst가 내부 연산을 SIMD 기반으로 고속 실행

개발자가 신경 써야 할 부분

- 구조체로 설계 (참조 지양)
- 컴포넌트 조합을 일정하게 유지
- NativeArray, NativeList 사용 시 Dispose 처리
- 스레드 세이프한 Job 설계
- Debug 로그 사용 시 Burst 성능 저하 주의

1. 경쟁조건이란?

두 개 이상의 쓰레드가 공유 자원(예: 변수, 리스트 등)에 동시에 접근하려 할 때, 실행 순서에 따라 결과가 달라지는 문제

예시

int counter = 0;

Thread t1 = new Thread(()=> {
	for(int i=0; i<1000; i++) counter++;
});

Thread t2 = new Thread(()=> {
	for(int i=0; i<1000; i++) counter++;
});

t1.Start();
t2.Start();

기대값은 2000이지만, 실제로는 1500 ~ 2000 사이의 값이 나올 수도 있음
원자적(atomic) 연산이 아니기 때문

원자적(atomic) 연산이란?

하나의 연산이 “더 이상 쪼갤 수 없는 단위”로 수행되는 것
- 실행 중 다른 쓰레드가 끼어들 수 없고,
- 반드시 전부 성공하거나, 전부 실패함. 중간 상태가 없음
즉, “한 번에 딱 처리된다” 라고 생각하면 됨

왜 counter++는 원자적이지 않은가?

counter++는 3단계로 나뉘는 연산임
1. counter 값을 읽음 (read)
2. 값에 1을 더함 (add)
3. 결과를 다시 저장함 (write)
-> 이 중간에 다른 쓰레드가 counter 값을 바꿔버릴 수 있음
-> 그래서 멀티쓰레드 환경에선 의도한 값이 나오지 않을 수 있음

2. 크리티컬 섹션(Critical Section)

정의
경쟁 조건이 발생할 수 있는 코드 블럭
-> 반드시 하나의 쓰레드만 실행해야 안전함

3. 동기화 기법들

3-1. Mutex (Mutual Exclusion)

- 프로세스 간 또는 쓰레드 간 락을 걸기 위한 방식
- 한 번에 하나의 쓰레드만 뮤텍스를 소유 가능

3-2. Monitor / lock (C#에서 가장 흔함)

- 내부적으로는 Monitor.Enter/Exit 기반
- lock은 쓰기 편하고 스코프 기반 해제가 보장돼서 안전함

class Counter
{
    private int _count = 0;
    private readonly object _lock = new object();

    public void Increment()
    {
        lock (_lock)
        {
            _count++;
        }
    }

    public int GetValue()
    {
        lock (_lock)
        {
            return _count;
        }
    }
}

3-3. Semaphore

- 뮤텍스는 한 번에 1개 쓰레드만 들어올 수 있지만,
- 세마포어는 동시 허용 수 제한이 있음 (예: 동시에 3개까지 진입 허용)

3-4. SpinLock

- Lock을 걸 때, 스레드가 대기 상태로 멈추는 대신 계속 루프를 돌면서 확인하는 방식
- CPU 낭비가 있지만, 짧은 락 구간에서 빠른 반응성이 있음

4. 데드락(Deadlock)이란?

두 개 이상의 쓰레드가 서로 상대방의 락을 기다리는 상태에서 빠져나오지 못하는 문제

예시
- Thread A가 Lock1을 잡고 Lock2를 기다리고,
- Thread B가 Lock2를 잡고 Lock1을 기다리는 경우 -> 둘 다 멈춤

예방 방법:
- 항상 락을 고정된 순서로 획득
- 타임아웃 설정으로 탈출 가능하게 설계

5. Unity에서는?

Unity는 메인 스레드 중심 구조이지만,
- Job System + Burst를 쓰거나
- Task, ThreadPool, BackgroundWorker 등을 사용할 때는 경쟁 조건 주의 필요
Unity의 NativeArray는 스레드 안정하지 않음 -> NativeQueue 같은 구졸를 사용하거나 Job System 내에서만 접근해야 함

CPU와 메모리 사이의 속도 차이를 줄이기 위해 도입된 것이 캐시(Cache)
게임처럼 연산이 많은 환경에서는 캐시의 활용이 성능에 엄청난 영향을 줌

1. 왜 캐시가 필요할까?

- CPU는 엄청 빠름
- RAM(메인 메모리)은 상대적으로 느림
- 매번 RAM에 접근하면 성능 저하 발생
-> 그래서 CPU 근처에 더 빠르고 작은 기억장치인 캐시를 둬서 성능을 높임

2. 캐시 메모리 계층 구조

보통 캐시는 L1 -> L2 -> L3 순서로 구성됨
계층 / 위치 / 크기 / 속도 / 역할
L1 / CPU 내부 / 적음(수십 KB) / 가장 빠름 / 현재 실행 중인 명령과 데이터를 저장
L2 / CPU 내부 or 외부 / 수백 KB~MB / L1보다 느림 / L1에서 못 찾을 때 사용
L3 / CPU 외부 (공유) / 수 MB / L2보다 느림 / 모든 코어가 공유

* RAM은 캐시 미스가 났을 때 접근하는 주 기억장치

3. 캐시 히트 vs 캐시 미스

- 캐시 히트 (Cache Hit)
-> 원하는 데이터가 캐시에 있음 -> 빠르게 접근 가능
- 캐시 미스 (Cache Miss)
-> 캐시에 데이터 없음 -> RAM 접근 -> 속도 느림

게임에서 캐시 미스가 잦으면
- FPS 하락
- 입력 지연
- 물리 연산 느려짐

4. 캐시 친화적인 코드 작성하기 (Cache-Friendly)

CPU는 데이터를 연속된 메모리에서 가져오는 것을 좋아함

구조체 설계 팁
- SoA (Structure of Arrays) -> 캐시 효율 높음
- AoS (Array of Structures) -> 비효율적일 수 있음

5. 게임 개발에서 캐시 활용 예시

- Physics Simulation : 충돌 판정 계산 시 캐시 효율이 중요
- Animation : 본 정보와 트랜스폼 연산을 빠르게 가져와야 함
- AI Pathfinding : 노드 그래프 탐색 시 캐시 최적화
- Rendering : 버텍스, 텍스처 데이터 캐싱

Unity ECS(Entity Component System)

1. 일반적인 OOP 방식의 문제점 (MonoBehaviour 중심)

Unity의 전통적인 방식은 OOP(Object-Oriented Programming)를 따르고 있음
이 객체들이 메모리에 흩어져 있음 (메모리 주소가 불연속적)
CPU캐시 미스 증가

2. CPU 캐시는 어떻게 동작하나?

CPU는 데이터를 메인 메모리(RAM)에서 직접 읽기보다, L1~L3 캐시에 미리 가져와서 사용함
데이터를 연속된 주소(메모리 블록)로 가져오기 때문에, 캐시에 들어가는 데이터는 보통 64바이트 단위로 묶여서 처리가 됨 (캐시 라인 단위)
따라서 연속된 데이터 구죌수록 캐시 적중률(Cache Hit Rate)이 높음

3. Unity ECS의 구조: SoA (Structure of Arrays)

Unity ECS는 데이터를 SoA (Structure of Arrays) 방식으로 저장함
즉, 컴포넌트 데이터를 하나의 큰 배열처럼 메모리에 연속적으로 저장함
Entity마다 컴포넌트들을 가지며, 이 데이터들은 Chunk라는 단위로 연속된 메모리에 저장됨
1Chunk = 여러 Entity의 동일한 컴포넌트 데이터를 정렬된 배열 형태로 보관
Chunk는 ECS 내부에서 컴포넌트 데이터를 저장하는 고정 크기의 메모리 블록
ECS는 모든 Entity의 데이터를 개별적으로 관리하지 않고, 비슷한 구성의 Entity들을 묶어서 Chunk에 저장함
Chunk 하나는 보통 16KB 크기로 고정되어 있음 (Unity 기본 설정 기준)
Chunk는 같은 Archetype(Entity 구조)를 가진 Entity들을 담는 컨테이너
하나의 Chunk에 담긴 Entity들은 같은 컴포넌트를 같은 순서로 갖고 있음
이렇게 하면 메모리에 연속적으로 정렬된 데이터 구조가 생기고, CPU 캐시 효율이 극대화 됨
“CPU 캐시를 고려한 물리적 정렬 방식”

이 구조가 왜 빠른가?
연속된 배열 순회 -> 캐시 히트 -> 벡터화 기능 (SIMD) -> 초고속 처리

4. Burst Compiler와 함께 작동할 때

ECS는 단순히 데이터 구조만 개선한 게 아니라, Burst Compiler와 조합되면 성능이 극적으로 향상됨
Burst는 Low-level CPU 최적화를 자동으로 해줌
연속된 데이터를 대상으로 SIMD(Vectorization) 최적화도 적용
캐시 히트를 활용하여 루프를 효율적으로 인라인화 & 파이프라인화

게임 개발에서 메모리 관리가 제대로 안되면?

- 프레임 드랍
- 메모리 누수
- 게임 크래시
그래서 게임 엔진들은 메모리를 효율적으로 사용하기 위한 다양한 최적화 기법을 적용하고 있음

1. 동적 할당과 정적 할당

정적 할당(Static Allocation)
- 컴파일 시간(빌드 시점)에 메모리 크기가 결정됨
- 예시 : 글로벌 변수, 정적 변수, 스택 변수

동적 할당(Dynamic Allocation)
- 실행 중(Run-time) 필요한 만큼 메모리를 할당
- 예시 : new(C++), malloc()(C), Instantiate()(Unity)

게임 개발에서 중요한 이유
- 동적 할당을 너무 많이 하면 프레임마다 메모리 할당/해제가 발생 -> 성능 저하
- 해결책 : 메모리 풀(Memory Pool) 활용 (자주 사용하는 객체를 미리 할당해둠)

2. 스택(Stack) vs. 힙(Heap) 메모리

스택 메모리(Stack)
- 함수 호출 시 자동 할당되는 메모리 공간
- 할당/해제 속도가 빠름
- 단점 : 크기가 한정적이고, 너무 많이 쓰면 스택 오버플로우(Stack Overflow) 발생

힙 메모리(Heap)
- new/malloc()로 동적 할당한 메모리
- 자유롭게 크기를 조절 가능
- 단점 : 할당/해제 비용이 크고, 메모리 단편화(Fragmentation) 발생 가능

게임 개발에서 중요한 이유
- 실시간 게임에서는 힙 할당을 최소화해야 성능 저하를 막을 수 있음
- 메모리 관리 기법 : 오브젝트 풀링(Object Pooling) 활용

3. 메모리 누수 (Memory Leak)

메모리 누수란?
- 할당된 메모리를 해제하지 않아서 점점 메모리가 증가하는 현상
- 일정 시간이 지나면 RAM이 부족해서 게임이 크래시될 수 있음

게임 개발에서 흔한 메모리 누수 사례
- new로 할당하고 delete를 호출하지 않음 (C++)
- Unity에서 GameObject.Destroy()를 호출하지 않고 참조를 남겨둠
- Unreal Engine에서 UObject가 적절히 관리되지 않음

예제(C++ 메모리 누수 발생 코드)

void Function(){
	Data* data = new Data();	//동적 할당
	//해제하지 않으면 메모리 누수 발생
}

해결 방법
- 스마트 포인터(Smart Pointer) 사용 (C++)
  - std::unique_ptr,std::shared_ptr
- Garbage Collector(GC) 최적화 (C#/Unity,UE4)
  - Resources.UnloadUnusedAssets() 사용
- 메모리 풀링(Object Pooling) 활용

4. 메모리 단편화 (Memory Fragmentation)

메모리 단편화란?
- 여러 개의 작은 메모리 블록이 파편처럼 흩어져 있어서 큰 메모리를 할당하지 못하는 문제
- 실시간 게임에서는 힙 메모리 단편화가 발생하면 큰 오브젝트 로딩이 어려워질 수 있음

게임에서 단편화를 줄이는 방법
- 메모리 풀링(Memory Pooling) : 자주 사용하는 객체를 미리 할당
- 연속된 메모리 사용(Array vs. Linked List)
  - 배열은 연속된 공간을 사용하므로 캐시 효율이 좋음
- 정적 할당 우선 사용

5. 메모리 최적화 기법 (게임 개발 적용)

오브젝트 풀링(Object Pooling)
- 자주 사용하는 객체를 미리 할당해두고, 재사용하는 기법
- 예시 : 총알, 적 캐릭터, 이펙트

데이터 레이아웃 최적화(Cache-Friendly Design)
- 연속된 메모리 구조를 사용해서 CPU 캐시 미스를 줄임
- 예시 : SoA(Structure of Arrays) vs. AoS(Array of Structures)

리소스 스트리밍(Texture Streaming, Level Streaming)
- 필요할 때만 데이터를 로드해서 메모리를 절약
- Unreal Engine, Unity는 비동기 로딩(Async Loading)을 제공

정적 할당(Static Allocation) 활용
- 게임 시작 시 한 번 할당하고 끝까지 유지
- 물리적으로 변하지 않는 오브젝트에 적합

가비지 컬렉션(Garbage Collection) 관리
- Unity: GC.Collect() 호출 최소화
- Unreal Engine: Garbage Collection이 자동으로 작동하므로 메모리 사용량 확인 필수