Hepari's Blog

[PCG] 4. HISM 기반 3D 렌더링 및 은면 제거

Tue, 23 Jun 2026 00:00:00 GMT

지난 5월, 2D Grid 배열을 활용하여 방+복도 데이터를 메모리에 올렸다. 하지만 지금까지 뷰포트에 띄운 DrawDebugSolidBox는 실제 게임에서 사용할 수 없는 에디터 전용 시각화 도구이다.

이번에는 이 n만 개의 데이터 배열을 바탕으로 실제 3D Static Mesh를 월드에 배치하되, Draw Call 문제를 방지하기 위해 HISM 컴포넌트와 은면 제거 알고리즘을 도입하여 렌더링을 최적화해 보았다.

1. Actor 스폰의 Draw Call 병목

100m x 100m 크기의 맵은 1m 단위 타일(여기서는 기본 제공되는 Cube) 10,000개로 이루어진다. 만약 이 타일마다 일반적인 AStaticMeshActor를 1만 개 스폰한다면 어떻게 될까?

CPU는 GPU에게 "1번 큐브 그려라", "2번 큐브 그려라" 하며 1만 번의 렌더링 명령(Draw Call)을 내리게 되고, 이는 CPU 병목 현상으로 이어지며 컴퓨터의 성능과 맵 크기에 따라 엔진이 튕길 수 있다.

2. HISM을 활용한 하드웨어 인스턴싱

이를 해결하기 위해 HISM(Hierarchical Instanced Static Mesh) 컴포넌트를 사용했다. HISM은 동일한 메쉬 1만 개를 그릴 때, 메쉬 원본 데이터 1개와 1만 개의 좌표(Transform) 배열만 GPU로 넘겨 단 1회의 드로우콜로 렌더링을 끝내는 최적화 기법이다.

ISM과 달리 계층적(Hierarchical) 구조를 가져, 시야 밖의 인스턴스를 통째로 Frustum Culling하거나 거리별 LOD 적용이 가능하다는 장점이 있어 거대 맵 생성에 유용하다.

3. 에디터 타임 메모리 관리 (`ClearInstances`)

PCG 툴은 에디터의 디테일 패널에서 Seed 값을 변경(OnConstruction)할 때마다 맵을 실시간으로 다시 생성한다. 이때 기존 메쉬 데이터를 지우지 않고 인스턴스를 계속 추가하면 에디터의 메모리가 쌓인다.

이를 방지하기 위해 렌더링 루프 시작 전, 이전 맵의 찌꺼기 데이터를 확실하게 비워주는 생명주기(Lifecycle) 관리를 적용했다.

// 에디터 블루프린트에서 설정한 메쉬 할당 및 기존 인스턴스 초기화
RoomFloorHISM->SetStaticMesh(RoomFloorMesh);
RoomFloorHISM->ClearInstances();

// 복도 및 벽 HISM도 동일하게 ClearInstances() 호출...

4. 인접 타일 검사를 통한 은면 제거 (Culling)

1만 개의 타일 중, 플레이어가 걸어 다니는 방과 복도를 제외한 7~8천 개의 잉여 타일은 그냥 두툼한 벽으로 남는다. 이 벽 타일마다 모두 메쉬를 생성하면 보이지 않는 맵 외곽과 땅속 허공까지 수천 개의 큐브가 렌더링되는 메모리 낭비가 발생한다.

따라서 **"상하좌우 4방향 중 바닥이 단 하나라도 있는 벽(노출된 벽)만 렌더링한다"**는 은면 제거(Hidden Surface Removal) 로직을 추가했다.

bool bShouldRenderWall = false;

// 4방향 탐색
for (int i = 0; i < 4; ++i)
{
    int32 nx = X + Dx[i];
    int32 ny = Y + Dy[i];
    
    if (IsValidGridPosition(nx, ny))
    {
        int32 nIndex = Get1DIndex(nx, ny);
        // 내 주변에 방이나 복도(바닥)가 있는가?
        if (GridMap[nIndex] != ETileType::Wall)
        {
            bShouldRenderWall = true; // 노출된 벽이므로 렌더링 승인
            break; 
        }
    }
}

// 렌더링 승인이 떨어진 벽만 Z축으로 올려서 HISM에 추가
if (bShouldRenderWall)
{
    FTransform WallTransform(FRotator::ZeroRotator, Position + FVector(0, 0, TileSize), FVector(1.0f));
    WallHISM->AddInstance(WallTransform);
}

5. 결과 시각화 및 다음 목표

위 이미지는 1M Cube 메쉬가 HISM으로 생성된 결과이다. 언리얼 콘솔로 stat rhi 확인 결과, 1만 개의 공간을 렌더링할때 DrawPrimitive Calls가 3회(방, 복도, 벽)만 실행되고 60프레임 이상을 안정적으로 유지한다. 지하에서 맵을 올려다보면 내부 벽면만 생성되고 맵 외곽의 불필요한 메쉬는 Culling 된 것을 확인할 수 있다.

이제 최적화된 3D 렌더링 뼈대가 완성되었다. 다음 달에는 벽변과 바닥에 비트마스킹, 푸아송 디스크 샘플링 등으로 프롭을 자연스럽게 배치해볼 것이다.

[PCG] 3. 2D Grid 메모리 최적화 및 A* 기반 타일 맵 생성

Wed, 03 Jun 2026 00:00:00 GMT

지난 4월, 언리얼 엔진으로 데이터 구조체를 이식하고 MST를 활용하여 방과 방을 잇는 논리적 그래프(선)를 시각화했다. 하지만 선은 캐릭터가 걸어 다닐 수 있는 물리적 공간이 아니다.

이번에는 100m x 100m의 공간을 1m 크기의 타일들로 쪼개어 메모리에 올리고, A* 알고리즘을 통해 논리적 선을 실제 타일 복도로 변환하는 과정을 구현해보았다.

1. 논리적 선(Vector)에서 물리적 면(Grid)로

기존에 구한 데이터는 두 방의 중심점을 잇는 좌표로, 이를 실제 던전으로 렌더링하려면 타일 맵 데이터로 변환해야 한다.

가장 먼저 타일의 상태를 정의할 열거형을 만들었다.

Wall: 파내지 않은 꽉 찬 벽
RoomFloor: 방의 바닥
CorridorFloor: 복도의 바닥

2. 1차원 배열을 활용한 2D Grid 메모리 최적화

2D 타일 맵을 구현할 때 흔히 TArray<TArray<uint8>> 형태의 2차원 배열을 떠올리기 쉽다. 하지만 이는 메모리가 연속적으로 할당되지 않아 CPU 캐시 지역성(Cache Locality)이 떨어져 병목의 원인이 된다.

대신 1차원 배열을 2차원처럼 다루는 방식으로 메모리 파편화를 방지했다.

// 2D 맵 데이터를 담을 1차원 배열 (캐시 최적화)
TArray<ETileType> GridMap;
int32 GridSizeX;
int32 GridSizeY;

// 2D(X,Y) -> 1D 인덱스로 변환하는 인라인 함수
// inline대신 FORCEINLINE 사용 (MSVC의 __forceinline 등으로 강제로 인라인화할 것을 명령)
FORCEINLINE int32 Get1DIndex(int32 X, int32 Y) const
{
    return Y * GridSizeX + X;
}

생성된 모든 Room 데이터의 영역을 1m 단위 타일 좌표로 변환하고, 이 1차원 GridMap 배열의 해당 인덱스들을 ETileType::RoomFloor로 덮어씌워 방을 파냈다.

3. A* 길찾기를 이용한 복도 생성

방을 모두 파낸 후, 4월에 구했던 MST Corridors 배열을 순회하며 A*로 탐색했다.

이때 매번 노드를 new로 할당하면 GC 부하와 메모리 릭이 발생할 수 있으므로, 언리얼의 TUniquePtr와 TMap을 컨테이너로 메모리 소유권을 관리했다. 또한, 성능이 중요한 닫힌 목록(ClosedList)은 2차원 맵 크기와 동일한 1차원 TArray<bool>로 할당하여 탐색시 O(1) 시간복잡도를 유도한다.

4. A* 가중치를 이용한 우회 경로 (Soft Constraint)

단순하게 A* 알고리즘 적용 시 최단 거리를 찾기 위해 복도가 방을 항상 뚫고 직진해버린다. 방의 모양이 훼손되지 않도록 탐색 중 바로 옆 타일이 RoomFloor일 경우 가중치(현재, +500점)를 부여하는 부드러운 제약(Soft Constraint) 방식을 적용했다.

int32 MoveCost = 10; // 평지 이동 기본 비용

// [가중치] 방을 피해서 돌아가도록 가중치 부여
if (GridMap[NeighborIndex] == ETileType::RoomFloor)
{
    // 도착지가 남의 방 내부에 있는 경우가 아니라면 가중치
    if (!(NeighborX == TargetX && NeighborY == TargetY))
    {
        MoveCost += 500;
    }
}

int32 NewG = CurrentNode->G + MoveCost;

위 결과로 A* 알고리즘은 가중치를 받으면서 방을 뚫는 경우는 거의 없어지고, 대부분 방의 외각 벽을 따라 우회하는 경로를 찾게 된다.

5. 결과 시각화 및 다음 목표

위 이미지는 타일 렌더링 결과로, 초록색 타일은 방(Room)을, 노란색 타일은 방을 우회하며 이어진 복도(A* Corridor)를 나타낸다.

기존에 호출하던 DrawDebugLine 기반의 렌더링 함수를 지우고, GridMap 전체를 순회하며 바닥 타일에 DrawDebugSolidBox를 그리는 함수로 교체했다.

다음은 HISM(Hierarchical Instanced Static Mesh) 컴포넌트를 활용해 위 사진과 같이 3D 스태틱 메쉬로 교체하고, Draw Call 최적화에 대해 알아보자.

[PCG] 2. 언리얼 엔진 이식 및 MST 기반 그래프 생성

Mon, 04 May 2026 00:00:00 GMT

지난 3월, C++ 콘솔 환경에서 BSP 공간 분할과 데이터 구조를 테스트했다. 이번에는 해당 구조체를 언리얼 환경으로 이식하고, 단순 트리 구조였던 복도 연결을 MST를 이용해 그래프로 연결해보았다.

1. 언리얼 C++ 메모리 및 난수 엔진 이식

이전 C++ 콘솔 프로젝트에서 중요했던 RAII패턴(스마트 포인터), 결정론 보장, 구조체를 언리얼 환경에 맞게 수정해서 이식해야한다.

RAII 패턴과 언리얼 GC
UObject GC 시스템이 아닌, 언리얼 Core 라이브러리(TArray TUniquePtr)를 활용해 데이터 계층의 메모리를 직접 제어 가능하게 설계해야한다.

std::unique_ptr -> TUniquePtr
std::vector -> TArray

결정론 보장
상대적으로 무거운 C++의 메르센 트위스터 방식에서 언리얼이 제공하는 난수 구조체로 교체했다. 이제 재귀 함수가 호출될때마다 난수 엔진을 재생성하지 않고, 진입점(OnConstruction)에서 FRandomStream을 Seed로 초기화하고 참조로 넘긴다.

std::mt19937 -> FRandomStream

네임스페이스 충돌 해결
UE 라이브러리에 FEdge와 충돌이 발생하여 간선 구조체의 이름을 수정했다.

FEdge -> FRoomEdge

2. OnConstruction과 DrawDebug를 활용한 데이터 시각화

정상적으로 로직이 이식되었는지 확인하기 위해, DrawDebug 함수를 만들었다.

APCGGenerator 액터의 OnConstruction 함수를 오버라이드하여, 에디터 디테일 패널의 변수를 바꾸면 뷰포트의 맵 형태가 실시간으로 수정되도록 하였다.

3. BSP 통로의 한계 & 그래프 도입

기존 BSP 트리 구조만으로 방을 연결하면, 몇가지 거슬리는 점이 생긴다.

물리적으로 바로 옆에 있는 방이라도, 트리상 멀리 떨어져 있다면 빙 돌아서 가야한다.
사이클이 없어, 무조건 한번 왔던 길로만 되돌아 갈 수 있다.

이를 해결하기 위해, 방과 방 사이를 트리 계층과 무관하게 최단 거리로 잇는 MST를 도입했다.

4. Union-Find와 Kruskal 기반 MST 구현

가장 먼저 두 방이 이미 연결되었는지 판별하여 사이클을 막아주는 분리 집합 클래스 FUnionFind를 구현했다. 이때 탐색 최적화를 위해 경로 압축(Path Compression)을 적용하여 Find 연산 시간을 $O(\alpha(N))$으로 줄였다.

백준에서 문제를 풀때와는 다르게 Union by Rank 최적화는 생략하였다.

struct FUnionFind
{
    TMap<FBSPNode*, FBSPNode*> Parent;

    // 경로 압축(Path Compression)이 적용된 Find
    FBSPNode* Find(FBSPNode* Node)
    {
        if (Parent[Node] == Node) return Node;
        return Parent[Node] = Find(Parent[Node]); 
    }
    // ... Union 함수 생략
};

이후 모든 말단 노드(Room) 간의 거리를 계산하여 정렬한 뒤, 크루스칼로 MST를 추출했다.

5. 순환로 생성

MST로 생성한 그래프는 사이클이 없어, BSP와 마찬가지로 왔던길로만 되돌아 갈 수 있다. 따라서 크루스칼 알고리즘 진행 중에 사이클을 형성하여 버려지는 간선 중 15%를 무작위(FRandomStream)로 부활시켜 맵에 Loop를 추가하였다.

단, 맵의 끝과 끝에 노드가 다이렉트로 연결되는 교차 간선을 막기위해, MaxLoopDistance (맵 전체 폭의 15%) 거리 제한을 두었다.

if (DSU.Union(Edge.NodeA, Edge.NodeB))
{
    // 사이클이 없으면 메인 뼈대 (빨간선)
    Corridors.Emplace(X1, Y1, X2, Y2, false);
}
else
{
    // 사이클이 발생하더라도, 거리가 짧은 간선은 15% 확률로 Loop로 부활 (파란선)
    if (Edge.Distance < MaxLoopDistance && RNG.FRand() < 0.15f)
    {
        Corridors.Emplace(X1, Y1, X2, Y2, true); 
    }
}

6. 결과 시각화 및 다음 목표

위 이미지는 107번 시드로, 빨간선은 메인 뼈대 파란선은 Loop이다.

상세한 코드는 깃허브 링크에서 확인 가능하다.

다음으로는 그래프를 기반으로 실제 물리적 배치를 위한 배열 최적화와 A* 길찾기 등을 구현해볼것이다.

[UE5] 0-1. 개발 환경 구축부터 네트워크 세션 기초 설계까지

Fri, 03 Apr 2026 00:00:00 GMT

언리얼 프로젝트를 본격적으로 개발하기 전, 데디케이티드 서버 구조를 상정하고 GAS를 적용한 초기 환경 구축부터 다중 접속을 위한 네트워크 세션 설계까지의 과정을 정리했다.

1. 데디케이티드 서버 빌드 타겟과 로그 설정

언리얼 엔진의 기본 템플릿은 에디터와 클라이언트 빌드만 제공한다. 서버 전용 로직을 검증하기 위해 별도의 .Target.cs 설정이 필요하다.

일반적으로 Shipping 빌드에서는 성능 최적화를 위해 모든 로그가 제거된다. 하지만 데디케이티드 서버 운영 중 발생하는 예외 상황을 추적하기 위해서는 로그가 필요하므로, 서버 타겟 설정에서 명시적으로 로그를 활성화해야 한다.

// CoopGameServer.Target.cs
public class CoopGameServerTarget : TargetRules
{
    public CoopGameServerTarget(TargetInfo Target) : base(Target)
    {
        Type = TargetType.Server; // 타입 Server로 변경
        DefaultBuildSettings = BuildSettingsVersion.V6;
        IncludeOrderVersion = EngineIncludeOrderVersion.Unreal5_7;

        ExtraModuleNames.Add("CoopGame");

        // 1. 서버는 당연히 Development빌드가 아니라 Shipping빌드를 한다.
        // 2. Shipping빌드는 로그가 남지 않아 디버깅이 어렵다.
        // 3. 그래서 Shipping빌드에서도 로그가 남도록 설정한다.
        bUseLoggingInShipping = true;
    }
}

타겟 파일을 추가하거나 수정했을 때는 반드시 .uproject 파일 우클릭 후 Generate Visual Studio project files를 실행해야 프로젝트 탐색기에 정상적으로 반영된다.

2. 버전 관리 시스템 (Git) 환경 설정

협업 및 버전 관리를 위해 .gitignore와 .gitattributes를 설정한다.

.gitignore 설정

# Unreal Engine
Binaries/
Build/
DerivedDataCache/
Intermediate/
Saved/
*.VC.db
*.opensdf
*.opendb
*.sdf
*.sln
*.suo
*.xcodeproj
*.xcworkspace

# 단, 이것들은 추적
!Config/
!Content/
!Source/
!Plugins/
!*.uproject

# Visual Studio
# .sln은 Generate Visual Studio project files로 언제든 재생성 가능하므로 추적할 필요 없다.
.vs/
*.sln
*.suo
*.user
*.userosscache
*.sln.docstates
*.VC.db
*.VC.VC.opendb

# Visual Studio Code
.vscode/

# Rider (혹시 나중에 쓸 경우 대비)
.idea/

LFS (.gitattributes)

*.uasset filter=lfs diff=lfs merge=lfs -text
*.umap filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.jpg filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.ttf filter=lfs diff=lfs merge=lfs -text

3. GAS(Gameplay Ability System) 디버깅 환경

콘솔 창(~)에서 ShowDebug AbilitySystem 명령어를 입력했을 때, 현재 캐릭터가 가진 태그, 이펙트, Attribute(체력, 마나 등)을 오버레이로 확인하기 위해 DefaultGame.ini에 다음 설정을 추가한다.

; 콘솔 창(~ 키 입력)열고, "ShowDebug abilitysystem" 입력
; 화면에 GAS 관련 정보 (현재 가진 태그, 이펙트, 체력, 마나 등 Attribute) 오버레이 표시
[/Script/GameplayAbilities.AbilitySystemGlobals]
bUseDebugTargetFromHud=true

4. Enhanced Input: WASD 이동 로직 재구성

UE5의 Enhanced Input은 유연하지만, 2D Axis 기반의 입력 처리 시 축 변환(Swizzle)과 반전(Negate)의 개념을 정확히 적용해야 한다.

엔진은 기본적으로 모든 입력을 '오른쪽(X+)' 기준으로 받는다. 따라서 IA_Move (Axis2D) 액션 하나로 방향을 제어하려면 다음과 같은 Modifiers 세팅이 필요하다.

W (위): Swizzle Input Axis Values (입력을 Y축으로 변환, 이때 XYZ -> YXZ 설정 필요)
S (아래): Swizzle Input Axis Values + Negate (Y축으로 변환, 이때 XYZ -> YXZ 설정 필요. 그 후 반전)
D (오른쪽): 모디파이어 없음 (기본 X축 양수)
A (왼쪽): Negate (X축 반전)

5. C++ 플레이어 캐릭터 클래스 설계

기본 템플릿의 BP_ThirdPersonCharacter 블루프린트를 재사용하거나 에셋 경로를 하드코딩하는 대신, BP가 상속받는 기반이 되는 C++ 기반 클래스(ACoopGameCharacter)를 직접 구현하여 로직과 시각적 에셋을 분리한다.

카메라 세팅, 이동 컴포넌트 처리, Enhanced Input의 IMC(Input Mapping Context) 바인딩과 같은 로직은 C++에서 담당하고,

이를 상속받은 BP에서는 메쉬나 애니메이션 블루프린트(AnimBP) 등 시각적 에셋만 할당하여 로직과 에셋을 분리한다.

새로운 입력(단축키, 액션 등) 추가 프로세스

IA 에셋 생성: 에디터에서 IA_Jump 등의 Input Action 에셋 생성.
IMC 매핑: IMC_Default에 IA를 추가하고 입력 키 매핑 (필요시 Modifiers/Triggers 세팅).
.h 변수 노출: 헤더 파일에서 UPROPERTY를 사용해 BP에 에셋을 연결할 슬롯 생성.
.cpp 바인딩 및 구현: 소스 파일에 동작 함수를 구현하고 BindAction으로 IA와 매핑.
BP 할당: C++을 상속받은 BP를 열고 노출된 슬롯에 IMC와 IA 에셋 할당.

이때 클래스 헤더에 에셋 참조를 선언할 때 사용하는 UPROPERTY 매크로는 에디터에 변수를 노출하고 직렬화하기 위해 필수적이다. (유니티의 [SerializeField] 특성(Attribute)와 유사하다. 인스펙터(디테일 패널)에 변수를 노출하고 값을 직렬화하여 저장할 수 있게 해준다.)

참고로 괄호 안에 EditAnywhere 같은 지정자(Specifier)를 넣지 않고 빈 UPROPERTY()만 선언하면 BP나 에디터에 노출되지 않는다. (GC에 의해 임의로 제거될 수도 있다는걸 조심하자)

UPROPERTY(EditAnywhere, Category = "Input")
class UInputMappingContext* DefaultMappingContext;

6. 언리얼 엔진 네트워크 모델 이해

기본적인 개발 환경과 로컬 캐릭터 제어 구조가 잡혔다면, 다음은 다중 접속을 위한 네트워크 설계다. 이를 위해 언리얼의 리플리케이션(Replication) 개념을 짚고 넘어가자

서버-클라이언트 구조

[Dedicated Server]: 게임 로직의 모든 권위(Authority)를 가진다. 화면을 렌더링하지 않으며, 게임 상태만 관리하고 이를 클라이언트에 복제(Replicate)한다.
[Client]: 플레이어의 입력을 서버로 전송하고, 서버로부터 받은 상태를 화면에 렌더링하는 역할만 수행한다.

Actor의 3가지 네트워크 역할 (Role)

Role	설명	위치
ROLE_Authority	이 Actor의 실제 주인. 핵심 로직의 실행 권한을 가짐.	서버
ROLE_AutonomousProxy	로컬 플레이어가 직접 조종하는 Actor.	클라이언트 (본인)
ROLE_SimulatedProxy	다른 플레이어의 Actor를 복제해서 보여주는 형태.	클라이언트 (타인)

권한 분리 예시

// 서버에서만 실행해야 하는 로직 (데미지 처리, 아이템 드롭 등)
if (HasAuthority()) { ... }

// 로컬 플레이어에서만 실행해야 하는 로직 (카메라 효과, HUD 등 UI 처리)
if (IsLocallyControlled()) { ... }

7. 주요 프레임워크 클래스 설계

네트워크 상에서 각 클래스가 어디에 존재하고 무슨 역할을 하는지 정의한다.

클래스	존재 위치	역할
AGameMode	서버 전용	게임 룰, 플레이어 입장/퇴장, 캐릭터 스폰 제어
AGameState	서버 + 전체 클라이언트	게임 전체의 상태 (타이머, 팀 점수, 접속자 수 등)
APlayerState	서버 + 전체 클라이언트	개별 플레이어의 상태 (HP, 닉네임, 킬/데스 등)
APlayerController	서버 + 해당 클라이언트	입력 처리 및 클라이언트-서버 간의 통신(RPC) 창구

C++ 클래스 구현

1. CoopGameMode (부모: AGameModeBase) 플레이어의 접속 및 퇴장 로그를 서버에 기록한다.

// CoopGameMode.cpp
#include "Core/CoopGameMode.h"
#include "Core/CoopGameState.h"
#include "Core/CoopPlayerState.h"

ACoopGameMode::ACoopGameMode()
{
    GameStateClass = ACoopGameState::StaticClass();
    PlayerStateClass = ACoopPlayerState::StaticClass();
}

void ACoopGameMode::PostLogin(APlayerController* NewPlayer)
{
    Super::PostLogin(NewPlayer);
    UE_LOG(LogTemp, Log, TEXT("Player Joined: %s"), *NewPlayer->GetName());
}

void ACoopGameMode::Logout(AController* Exiting)
{
    Super::Logout(Exiting);
    UE_LOG(LogTemp, Log, TEXT("Player Left: %s"), *Exiting->GetName());
}

2. CoopGameState (부모: AGameStateBase) 접속 중인 플레이어 수를 서버 권위로 관리하고 클라이언트에 복제한다.

// CoopGameState.h
UPROPERTY(Replicated, BlueprintReadOnly, Category = "Game")
int32 ConnectedPlayerCount;

// CoopGameState.cpp
void ACoopGameState::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const
{
    Super::GetLifetimeReplicatedProps(OutLifetimeProps);
    DOREPLIFETIME(ACoopGameState, ConnectedPlayerCount);
}

3. CoopPlayerState (부모: APlayerState) 추후 GAS와 연동될 플레이어의 생존 여부 등을 관리한다.

// CoopPlayerState.h
UPROPERTY(Replicated, BlueprintReadOnly, Category = "Player")
bool bIsAlive;

// CoopPlayerState.cpp
void ACoopPlayerState::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const
{
    Super::GetLifetimeReplicatedProps(OutLifetimeProps);
    DOREPLIFETIME(ACoopPlayerState, bIsAlive);
}

DefaultGame.ini 등록

[/Script/EngineSettings.GameMapsSettings]
GlobalDefaultGameMode=/Script/CoopGame.CoopGameMode

8. 온라인 서브시스템 (OSS) 및 세션 구현

현재는 로컬 LAN 테스트를 위해 NULL 서브시스템을 사용하며, 추후 Steam OSS로 교체할 수 있는 구조로 설계한다. (에디터 Plugins에서 Online Subsystem 및 Online Subsystem Utils 활성화 필수)

DefaultEngine.ini 설정

[OnlineSubsystem]
DefaultPlatformService=NULL

[OnlineSubsystemNULL]
bEnabled=true

[/Script/Engine.GameEngine]
+NetDriverDefinitions=(DefName="GameNetDriver",DriverClassName="OnlineSubsystemUtils.IpNetDriver",DriverClassNameFallback="OnlineSubsystemUtils.IpNetDriver")

GameInstance를 활용한 세션 관리

세션 로직은 씬 전환(Level Travel) 시에도 파괴되지 않고 유지되는 UGameInstance에 구현하는 것이 안정적이다.

CoopGameInstance.cpp (주요 로직 요약)

// 세션 생성
void UCoopGameInstance::CreateCoopSession(int32 MaxPlayers)
{
    // ... OSS 인터페이스 획득 생략 ...
    FOnlineSessionSettings SessionSettings;
    SessionSettings.bIsLANMatch = true; // NULL OSS 기준
    SessionSettings.NumPublicConnections = MaxPlayers;
    SessionSettings.bShouldAdvertise = true;
    
    SessionInterface->CreateSession(0, COOP_SESSION_NAME, SessionSettings);
}

// 세션 생성 성공 시 데디서버 레벨로 이동
void UCoopGameInstance::OnCreateSessionComplete(FName SessionName, bool bWasSuccessful)
{
    if (bWasSuccessful) {
        GetWorld()->ServerTravel("/Game/Levels/L_GameMap?listen");
    }
}

// 세션 참가 성공 시 클라이언트 이동
void UCoopGameInstance::OnJoinSessionComplete(FName SessionName, EOnJoinSessionCompleteResult::Type Result)
{
    if (Result == EOnJoinSessionCompleteResult::Success) {
        APlayerController* PC = GetFirstLocalPlayerController();
        FString TravelURL;
        if (SessionInterface->GetResolvedConnectString(SessionName, TravelURL)) {
            PC->ClientTravel(TravelURL, ETravelType::TRAVEL_Absolute);
        }
    }
}

9. 접속 테스트 및 검증

작성된 코드가 데디서버 환경에서 정상적으로 동작하는지 확인한다.

방법 1: 에디터 내 테스트 (PIE)

설정: Play As Listen Server, Number of Players: 2+
결과: 클라이언트 창이 2개 이상 생성되며 캐릭터가 동일 맵에서 동기화되는지 확인.

방법 2: 커맨드라인 데디서버 테스트

서버 실행

"UnrealEditor.exe" "[프로젝트경로]/CoopGame.uproject" /Game/Levels/L_GameMap -server -log

클라이언트 실행

"UnrealEditor.exe" "[프로젝트경로]/CoopGame.uproject" 127.0.0.1 -game -log

결과: 서버 터미널에 Player Joined 로그가 정상적으로 출력되는지 확인.

[PCG] 1. C++ 콘솔 기반 BSP 알고리즘 테스트

Tue, 24 Mar 2026 00:00:00 GMT

절차적 월드 생성(PCG) 시스템을 언리얼 엔진에 구현하기에 앞서, C++ 콘솔 환경에서 표준 라이브러리와 알고리즘만으로 격자형 맵을 시각화하는 테스트를 진행했다.

1. BSP 트리 구조체 설계

맵을 이진 공간 분할(BSP; Binary Space Partitioning)로 쪼개는 과정에서 생성되는 노드들은 메모리 관리를 용이하게 하기 위해 모던 C++의 std::unique_ptr를 활용하여 설계했다. (추후 언리얼 엔진으로 이식할 때 TUniquePtr로 대체할 예정이다.)

struct FBSPNode
{
    FRect Area; // 할당된 전체 구역
    FRect Room; // 구역 내에 파내어질 실제 방 공간
    
    // 부모 노드 소멸 시 하위 트리의 모든 메모리가 자동 해제됨
    std::unique_ptr<FBSPNode> LeftChild;
    std::unique_ptr<FBSPNode> RightChild;
    // ...
};

이러한 RAII 패턴을 통해, 월드를 리셋할 때 최상단 Root 노드만 날려주면되는 안전한 구조가된다.

2. 결정론(Determinism) 보장과 난수 엔진 초기화 병목 해결

특정 Seed 값을 입력하면 언제나 100% 동일한 월드가 생성되는걸 본 적이 있을것이다. 이런걸 결정론 보장이라고 한다.

초기 구현에서는 방의 크기나 패딩(Padding)을 연산하는 재귀 함수 내부에서 매번 난수 엔진을 생성하게 구현하였는데...

// [개선 전] 호출마다 난수 엔진 생성 -> 결정론 보장 불가 및 CPU 병목 발생
std::random_device RandomDevice;
std::mt19937 Generator(RandomDevice()); 
int PaddingX = padX(Generator);

std::mt19937은 내부 상태가 2KB로 상대적으로 무거운편이다. 이를 재귀적으로 생성하면 오버헤드가 발생한다. 더 큰 문제로는 random_device를 매번 참조하므로 Seed 고정 자체가 불가능해진다.

이를 해결하기 위해 프로그램 진입점 main에서 1개의 전역 RNG 객체를 Seed 값과 함께 초기화하고, 모든 함수에 std::mt19937& RNG참조로 전달하도록 코드를 수정하였다.

3. 생성 함수 분리 (결합도 줄이기)

하나의 재귀 함수 내부에서 공간 분할, 방 생성, 경로 연결을 모두 처리하면 코드의 결합도가 지나치게 높아지고 유지보수가 어려워진다. 월드 생성을 3단계로 함수를 분리하였다.

GenerateBSPTree (공간 분할): Area를 기준으로 맵을 끝까지 쪼갠다.
GenerateRooms (방 파내기): 더 이상 쪼개지지 않은 말단 노드(Leaf)를 찾아, Area 내부에 Padding을 적용한 Room을 생성한다.
GenerateCorridors (경로 연결): 방과 방 사이를 잇는 FCorridor 복도 데이터를 추가한다.

경로 연결을 위해 방 데이터가 기록된 무작위 Leaf Node를 재귀적으로 탐색해 반환하는 헬퍼 함수 GetRandomLeaf도 구현하였다.

FBSPNode* LeftLeaf = GetRandomLeaf(Node->LeftChild.get(), RNG);
FBSPNode* RightLeaf = GetRandomLeaf(Node->RightChild.get(), RNG);

if (LeftLeaf && RightLeaf) 
{
    // 임시 객체 생성 비용 최소화를 위해 push_back 대신 emplace_back 사용
    OutCorridors.emplace_back(LeftCenterX, LeftCenterY, RightCenterX, LeftCenterY);
}

4. 결과 시각화 및 다음 목표

생성 과정 gif

점선(.)은 쪼개진 Area 구역을, 실선(#, +)은 실제 파내어진 Room 공간을, 별표(*)는 방과 방을 잇는 통로를 의미한다. 모든 방이 끊김 없이 연결된 것을 확인할 수 있다.

상세한 코드는 깃허브 링크에서 확인 가능하다.
BSPNode.h
main.cpp

다음으로는 콘솔에서 테스트한 BSP 구조체를 UE5 환경에 이식해볼 것이다. TUniquePtr를 적용하고, 액터 스폰 대신 디버깅 라인을 활용해 3D 시각화 테스트를 진행할 예정이다.

다수의 StaticMesh 컴포넌트 배치시의 부하 원인 (Draw Call)

Fri, 27 Feb 2026 00:00:00 GMT

언리얼 엔진 C++ 개발 중 동일한 UStaticMesh를 사용하는 컴포넌트(예: 분수대, 총알 등)를 월드에 수십, 수백 개 배치할 때 발생하는 시스템 부하의 원인에 대해 찾아보고 정리해보았다.

흔히 직관적으로 "화면에 그려지는 개수가 많아지니 데이터가 복사되어 메모리 부하가 클 것"이라고 오해하지만, 실제 게임 엔진의 병목 지점은 완전히 다른 곳에 있다.

1. 메모리 관점: 복사가 아닌 '참조' (Flyweight Pattern)

월드에 동일한 액터를 100개 배치한다고 해서 형태를 구성하는 메시 데이터(버텍스, 인덱스, UV 등)가 메모리에 100번 복사되지 않는다. 현대 게임 엔진은 플라이웨이트 패턴(Flyweight Pattern)을 기반으로 리소스를 관리한다.

시스템 RAM (CPU 영역): 엔진 초기화 시 원본 UStaticMesh 데이터는 단 한 번만 로드된다. 각 컴포넌트(UStaticMeshComponent)는 이 원본 데이터의 메모리 주소를 가리키는 포인터만을 소유한다.
VRAM (GPU 영역): 렌더링을 위해 그래픽 카드로 데이터가 넘어갈 때도 마찬가지다. 메시의 버텍스 정보는 GPU 메모리의 버텍스 버퍼(Vertex Buffer)에 딱 한 번만 올라간다.

결과적으로 인스턴스가 아무리 늘어나도 동일한 데이터를 재참조할 뿐이므로, 데이터 '복사'로 인한 메모리 오버헤드는 0에 가깝다.

2. 렌더링 관점: 진짜 부하의 원인은 '드로우 콜(Draw Call)'

메모리 복사 부하가 없다면 왜 객체를 많이 그릴수록 프레임이 떨어질까? 부하의 핵심은 데이터의 크기가 아니라 명령의 횟수에 있다.

CPU가 GPU에게 "이 메시를 그려라"라고 명령을 내리는 과정을 드로우 콜(Draw Call) 이라고 한다.

CPU -> GPU

CPU가 렌더링할 객체의 월드 트랜스폼(위치, 회전, 스케일)을 계산한다.
GPU에게 렌더링 상태 변경(머티리얼, 쉐이더 설정 등)을 지시한다.
GPU에게 그리기(Draw) 명령을 보낸다.

이 과정에서 CPU와 GPU 사이의 통신 비용(Context Switching)이 발생한다. 화면에 그릴 객체가 수백 개로 늘어나면 이 통신 횟수 자체가 기하급수적으로 증가한다. 결국 CPU는 명령을 보내느라 과부하가 걸리고, GPU는 이전 명령을 처리하고 다음 명령을 기다리며 노는(Idle) 병목 현상이 발생한다. 부하는 그리는 행위(연산) 그 자체와 명령 하달 과정에서 발생한다.

3. 최적화 기법: 하드웨어 인스턴싱 (Hardware Instancing)

엔진은 드로우 콜 병목을 해결하기 위해 하드웨어 인스턴싱이라는 최적화 기법을 사용한다.

기존 방식: 100개의 분수대를 그리기 위해 CPU가 GPU에게 100번의 드로우 콜을 보냄.
인스턴싱 방식: 버텍스 정보는 1번만 참조하되, 100개의 분수대 위치 정보(Transform Matrix)를 배열로 묶어 GPU에 전달. CPU는 "이 1개의 버텍스 데이터를 사용해서, 여기 전달한 100개의 위치에 한 번에 그려라"라는 단일 명령(1 Draw Call)을 내림.

이를 통해 CPU의 오버헤드를 극적으로 줄이고, GPU의 연산 유닛(ALU)을 효율적으로 점유하여 렌더링을 수행할 수 있다.

4. C++ 생성자 코드와의 연관성

// 컴포넌트 생성 및 에셋 참조
Body = CreateDefaultSubobject<UStaticMeshComponent>(TEXT("Body"));
static ConstructorHelpers::FObjectFinder<UStaticMesh> BodyMeshRef(TEXT("경로"));
if (BodyMeshRef.Succeeded())
{
	Body->SetStaticMesh(BodyMeshRef.Object);
}

위의 C++ 코드는 단순히 컴포넌트를 만들고 에셋을 끼워 넣는 과정처럼 보이지만, 엔진 구조적으로는 CDO(Class Default Object) 를 구성하는 단계다.

런타임에 동적으로 에셋을 복사해오는 것이 아니라, 엔진 초기화 단계에서 ConstructorHelpers를 통해 에셋을 단 한 번 메모리에 적재해 CDO를 완성한다. 이후 게임 내에서 스폰되는 모든 해당 클래스의 인스턴스들은 이 CDO에 적재된 에셋의 주소값만을 안전하게 참조(Reference)하도록 설계되어 있다.

5. 심화: 하이폴리곤 메시 자체의 크기는 부하를 주지 않는가?

앞서 설명한 내용이 CPU와 GPU 간의 통신 병목(Draw Call)에 대한 것이라면, 메시 자체가 가진 버텍스 수(5만~10만 개 이상의 하이폴리곤)는 GPU 내부의 연산 병목을 유발한다. 메모리(VRAM)에 한 번만 올라가서 공유되더라도, 매 프레임 이를 처리하는 연산량은 정직하게 버텍스 수에 비례하기 때문이다.

5-1. 버텍스 쉐이더(Vertex Shader) 연산

GPU는 렌더링할 때 메시에 포함된 모든 버텍스의 화면상 위치를 계산(Transform)해야 한다. 버텍스가 10만 개라면, 화면에 1번 그릴 때마다 GPU 연산 유닛(ALU)이 10만 번의 버텍스 쉐이더 프로그램을 실행해야 한다. 여러 개를 배치하면 이 연산량은 배로 늘어난다.

5-2. USkeletalMesh의 스키닝(Skinning) 비용

정적인 UStaticMesh와 달리, 애니메이션이 들어간 하이폴리곤 캐릭터의 USkeletalMesh는 높은 부하를 유발한다. 매 프레임 캐릭터가 움직일 때마다 10만 개의 버텍스는 자신과 연결된 뼈대(Bone)의 가중치(Weight)를 바탕으로 위치를 재계산해야 한다. 이 행렬 곱셈 연산이 GPU에 큰 부하를 가한다.

5-3. 쿼드 오버드로우(Quad Overdraw)와 마이크로 트라이앵글(Micro-triangle)

하이폴리곤 메시는 화면에 작게 표시될 때 1픽셀보다 Micro-triangle들을 무수히 만들어낸다. GPU는 픽셀을 칠할 때 2x2(Quad) 단위로 병렬 처리하는데, 삼각형이 너무 조밀하면 실제 그릴 필요가 없는 픽셀까지 연산에 포함되어 렌더링 효율이 급락한다.

5-4. 언리얼 엔진의 해결책

이러한 GPU 연산 부하를 막기 위해 엔진은 다음과 같은 기술을 사용한다.

StaticMesh: 언리얼 엔진 5의 나나이트(Nanite) 기술을 통해 화면에 보이는 픽셀 수준으로 폴리곤을 실시간 병합/분할하여 버텍스 연산 부하를 최적화한다.

SkeletalMesh (캐릭터): 뼈대 애니메이션 연산 때문에 나나이트 적용이 까다롭다. 따라서 거리에 따라 폴리곤 수를 강제로 줄여 연산량을 통제하는 LOD(Level of Detail) 적용이 필수적이다.

6. 정리

메시는 복사되지 않고 한 번만 로드되어 참조된다. (메모리 최적화)
다수의 StaticMesh배치시에 발생하는 부하 --> ~X 데이터 복사로 인한 메모리 부하? X~ , 반복 연산과 드로우 콜 오버헤드
하이폴리곤 USkeletalMesh에 발생하는 부하 --> GPU 내부의 버텍스 쉐이더 및 스키닝 연산 병목과 나나이트 적용의 어려움(Quad Overdraw)

6. Reference

GPU Performance for Game Artists (FragmentBuffer)
- 렌더링 파이프라인(Draw Call, Vertex/Pixel Shader)과 메모리 대역폭이 실제 게임 에셋(Mesh, Texture)에 어떤 방식으로 병목을 일으키는지 상세히 풀어낸 아티클입니다.

[UE5/System] 언리얼 엔진 데이터 관리 및 시스템 구조

Sat, 14 Feb 2026 00:00:00 GMT

언리얼 엔진의 데이터 저장 방식부터 모듈 시스템까지 묶어서 정리하였다.

1. 직렬화 (Serialization)

언리얼에서 UObject의 데이터를 저장하고 불러들이는 기본 원리이다.

1.1 직렬화와 언리얼의 방식

직렬화(Serialization): 메모리 상의 오브젝트를 디스크 저장이나 네트워크 전송이 가능한 바이트 스트림(Byte Stream)으로 변환하는 과정이다. 역직렬화(Deserialization)는 그 반대다.
언리얼의 구현: 언리얼은 FArchive 클래스와 시프트 연산자(<<)를 재정의하여 사용한다.
저장과 로딩 모두 Ar << Data 하나의 코드로 통일하여 작성한다. (아카이브 내부 상태인 IsLoading(), IsSaving()이 방향을 결정함)

1.2 실습: 일반 C++ 구조체 직렬화

가장 기초적인 단계로 일반 구조체를 파일로 입출력하는 방법이다.

struct FStudentData
{
    int32 Order = -1;
    FString Name = TEXT("기본이름");

    // 직렬화를 위한 연산자 오버로딩 (FArchive 통로 약속)
    friend FArchive& operator<<(FArchive& Ar, FStudentData& InData)
    {
        Ar << InData.Order;
        Ar << InData.Name;
        return Ar;
    }
};

// 파일 저장 예시
const FString RawDataAbsolutePath = FPaths::Combine(*SavedDir, TEXT("RawData.bin"));
FStudentData RawDataSrc(16, TEXT("홍길동"));

FArchive* FileWriterAr = IFileManager::Get().CreateFileWriter(*RawDataAbsolutePath);
if (FileWriterAr)
{
    *FileWriterAr << RawDataSrc; // 오버로딩된 operator<< 호출
    FileWriterAr->Close();
    delete FileWriterAr;
}

1.3 실습: UObject 직렬화 (2단계 방식)

UObject는 자체적으로 Serialize 함수를 가진다. 보통 객체를 메모리 버퍼로 먼저 변환한 뒤, 그 버퍼를 파일로 저장하는 2단계 방식을 주로 사용한다.

// 1. 객체를 메모리(Buffer)에 쓰기
TArray<uint8> BufferArray;
FMemoryWriter MemoryWriterAr(BufferArray); 
StudentSrc->Serialize(MemoryWriterAr); 

// 2. 메모리를 파일에 쓰기 (TUniquePtr 활용으로 자동 메모리 해제)
if (TUniquePtr<FArchive> FileWriterAr = TUniquePtr<FArchive>(IFileManager::Get().CreateFileWriter(*ObjectPath)))
{
    *FileWriterAr << BufferArray; 
    FileWriterAr->Close();
}

JSON 직렬화 팁 JSON 포맷을 사용하려면 Build.cs에 반드시 "Json", "JsonUtilities" 모듈을 추가해야 한다.

흐름: [UObject] <-> (Converter) <-> [FJsonObject] <-> (Serializer) <-> [String]

2. 패키지(Package)와 에셋(Asset)

직렬화된 데이터를 에디터가 인식할 수 있는 .uasset 형태로 관리하는 구조이다.

2.1 패키지와 에셋의 관계

패키지 (UPackage): 여러 언리얼 오브젝트를 포장하는 최상위 오브젝트이다.
에셋 (Asset): 패키 내부에 포함된 오브젝트 중 에디터 콘텐츠 브라우저에 노출되는 메인 오브젝트이다.
일반적으로 1개의 패키지는 1개의 에셋을 가진다.

2.2 오브젝트 패스와 에셋 로딩 전략

에셋은 메모리 관리를 위해 고유한 경로인 오브젝트 패스 (Object Path)로 관리된다.

형식: 패키지명.에셋명 (예: /Game/Student.TopStudent)

메모리 부하를 줄이기 위해 필요한 시점에 로딩하는 전략을 사용한다.

생성자 로딩 (ConstructorHelpers): 클래스 생성자에서 미리 로드. (에러 시 크래시 주의)
동기 로딩 (LoadObject): 런타임에 즉시 로드. (프레임 드랍 유발 가능)
비동기 로딩 (StreamableManager): 백그라운드에서 로딩 후 콜백 실행. (대규모 게임 필수)

// 비동기 로딩 예시
FStreamableManager StreamableManager;
const FString Path = TEXT("/Game/Student.TopStudent");

StreamableManager.RequestAsyncLoad(Path, [&]() 
{
    // 로딩 완료 후 실행될 람다
});

3. 모듈(Module)과 플러그인(Plugin)

저장된 데이터와 작성된 코드들이 실제로 어떻게 엔진에서 뭉쳐서 돌아가는지에 대한 구조이다.

3.1 C++ 프로젝트와 모듈

언리얼 엔진의 모든 소스 코드는 모듈(Module) 단위로 구성된다.

블루프린트 프로젝트는 엔진 기본 모듈만 사용하지만, C++ 프로젝트는 개발자가 직접 작성한 커스텀 C++ 모듈을 엔진에 추가하여 작동하는 원리이다.
컴파일 결과물은 에디터용 빌드 시 DLL 동적 라이브러리 형태로 생성된다.

3.2 UBT (Unreal Build Tool)

언리얼은 멀티 플랫폼 빌드를 위해 Visual Studio에 종속되지 않고 자체적인 UBT (C# 프로그램)를 사용한다.

이를 위해 두 가지 중요한 C# 설정 파일이 필요하다.

.Target.cs (타겟 설정): 게임/에디터 등 전체 솔루션의 빌드 환경 설정.
.Build.cs (모듈 설정): 특정 모듈의 의존성(위의 JSON 모듈 추가 등) 설정.

[UE 5.7 기준 Editor 타겟 파일 예시]

using UnrealBuildTool;
using System.Collections.Generic;

public class UnrealBuildSystemEditorTarget : TargetRules
{
    public UnrealBuildSystemEditorTarget(TargetInfo Target) : base(Target)
    {
        Type = TargetType.Editor;
        DefaultBuildSettings = BuildSettingsVersion.V6;
        IncludeOrderVersion = EngineIncludeOrderVersion.Unreal5_7;
        CppStandard = CppStandardVersion.Cpp20; // C++20 지원
        
        bOverrideBuildEnvironment = true; 
        ExtraModuleNames.AddRange(new string[] { "UnrealBuildSystem" });
    }
}

요약 (System Architecture Flow)

코드 (Module): .Build.cs와 .Target.cs를 통해 C++ 코드를 UBT가 DLL 모듈로 컴파일한다.
데이터 생성 (Serialization): 컴파일된 코드가 실행되며 FArchive를 통해 데이터를 직렬화한다.
포장 및 관리 (Package & Asset): 직렬화된 데이터는 UPackage로 묶여 콘텐츠 브라우저에 .uasset으로 노출되며, 오브젝트 패스를 통해 효율적으로 로드된다.

[Algorithm] Permutation Cycle Decomposition

Wed, 11 Feb 2026 00:00:00 GMT

개념

알고리즘 문제에서 배열을 정렬하기 위해 필요한 최소 교환 횟수를 묻는다면, 높은 확률로 순열 사이클 분할 문제이다.

$N$개의 원소로 이루어진 순열
현재 인덱스($i$)와 그 위치에 있는 값($A[i]$)을 간선으로 연결하면($i \rightarrow A[i]$)
배열은 서로 겹치지 않는 여러 개의 사이클(Cycle)로 분해된다.

이것을 순열 사이클 분할(Permutation Cycle Decomposition)이라고 한다.

예시

아래와 같은 배열이 있다고 가졍해보자.

$$N = 5, \quad Arr = { 2, 4, 5, 1, 3 }$$

1-based index ($i$)	1	2	3	4	5
값 ($A[i]$)	2	4	5	1	3

이 관계를 그래프로 따라가 보면 2개의 독립적인 사이클이 만들어진다.

Cycle 1: $1 \rightarrow 2 \rightarrow 4 \rightarrow 1$ (길이 3)
Cycle 2: $3 \rightarrow 5 \rightarrow 3$ (길이 2)

최소 교환 횟수 공식

순열 사이클 분할을 이용하면 배열을 정렬하는 데 필요한 최소 교환 횟수를 구할 수 있다.

$$\text{최소 교환 횟수} = N - (\text{사이클의 개수})$$

왜 이런 공식이 나올까?

길이가 1인 사이클: 이미 제자리에 있는 원소이므로, 교환이 필요 없다. (0회)
길이가 $K$인 사이클: $K$개의 원소가 서로 자리를 바꾸며 얽혀 있다. 이를 모두 제자리로 보내려면 $K-1$번의 교환이 필요하다.

전체 $N$개의 노드가 $C$개의 사이클로 분할되어 있고, 각 사이클의 길이를 $L_1, L_2, \dots, L_C$라고 할때, 전체 교환 횟수는 각 사이클을 정렬하는 횟수의 합이다.

$$\begin{aligned} \text{Total Swaps} &= \sum_{i=1}^{C} (L_i - 1) \ &= \sum_{i=1}^{C} L_i - \sum_{i=1}^{C} 1 \ &= N - C \end{aligned}$$

위의 예시 ${ 2, 4, 5, 1, 3 }$에 적용해 보면:

전체 노드 개수 $N$ = 5
사이클의 개수 $C$ = 2
최소 교환 횟수 = $5 - 2 = 3$번

예제

메인 로직

DFS나 BFS로 미방문 노드 사이클을 탐색하고, 그 횟수를 카운팅한다.

#include <iostream>
#include <vector>
using namespace std;
const int INF = 0x3f3f3f3f;

int n;
int arr[INF];
bool vis[INF];

int main()
{
    int cnt = 0;

    for (int i = 1; i <= n; i++)
    {
        // // 미 방문 노드 발견 (새로운 사이클 발견)
        if (!vis[i])
        {
            cnt++;
            int cur = i;

            // DFS
            while (!vis[cur])
            {
                vis[cur] = true;
                cur = arr[cur]; // 다음 노드로 이동
            }
        }
    }

    // n - 사이클 개수
    cout << n - cnt;
}

연습 문제 - BOJ 10451 순열 사이클

순열 사이클의 수를 출력하는 문제다.

#include <iostream>
#include <vector>
using namespace std;

int main()
{
    int t; cin >> t;
    while (t--)
    {
        int n; cin >> n;
        vector<int> vec(n + 1);
        for (int i = 1; i <= n; i++)
            cin >> vec[i];

        int cnt = 0;
        vector<bool> vis(n + 1, false);
        for (int i = 1; i <= n; i++)
        {
            // 사이클 찾았음
            if (vis[i] == false)
            {
                cnt += 1;
                int cur = i;

                // DFS
                while (vis[cur] == false)
                {
                    vis[cur] = true;
                    cur = vec[cur];
                }
            }
        }
        cout << cnt << '\n';
    }
}

연습 문제 - BOJ 34078 벨과 와이즈의 가게 홍보

내림차순 케이스를 조심하자..

#include <iostream>
#include <algorithm>
#include <vector>
using namespace std;

int main()
{
    int n; cin >> n;
    vector<int> vec(n + 1, 0);
    for (int i = 1; i <= n; i++)
        cin >> vec[i];

    // 웅나 수 = n탐색 돌리기
    // 웅나 시간 = n - 사이클의 수

    int cnt1 = 0;
    vector<bool> vis(n + 1, false);
    for (int i = 1; i <= n; i++)
    {
        if (vis[i] == false)
        {
            int cur = i;
            cnt1 += 1; // 사이클 시작점 발 견
            while (vis[cur] == false)
            {
                vis[cur] = true;
                cur = vec[cur];
            }
        }
    }

    // 내림차순 검사 { 4 3 2 1 } 케이스
    int cnt2 = 0;
    vis.assign(n + 1, false);
    for (int i = 1; i <= n; i++)
    {
        if (vis[i] == false)
        {
            int cur = i;
            cnt2 += 1; // 사이클 시작점 발 견
            while (vis[cur] == false)
            {
                vis[cur] = true;
                cur = vec[n - cur + 1];
            }
        }
    }
	
	// 모든 웅나의 키는 다르므로, n-2
    cout << n - 2 << ' ' << n - max(cnt1, cnt2);

}

[UE5/Data] 12. UE GC & FGCObject

Wed, 11 Feb 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

C++ 언어 메모리 관리의 문제점과 GC

잘못된 포인터 사용 예시
- 메모리 누수 (Leak) : new <-> delete 짝을 못 맞춤. 힙에 메모리가 그대로 남음
- 허상 포인터 (Dangling Pointer) : 이미 해제하여 무효화된 오브젝트의 주소를 가리키는 포인터
- 와일드 포인터 (Wild Pointer) : 값이 초기화되지 않아 엉뚱한 주소를 가리키는 포인터

GC 시스템

동적으로 생성된 모든 오브젝트 정보를 모아둔 저장소를 사용해 사용되지 않는 메모리를 추적
마크-스윕(Mark-Sweep) 방식
- GCCycle 기본값 60초
병렬처리, 클러스터링 - 성능 향상을 위함

GC를 위한 객체 저장소

GUObjectArray: 관리되는 모든 UObject 정보를 저장하는 전역 변수
- <Object, Flag> 구조로 관리
각 요소에는 플래그(Flag)가 설정
- Garbage Flag : 참조가 없어 회수 예정
- RootSet Flag : 참조가 없어도 회수X (특별한 오브젝트)

GC의 메모리 회수

지정된 시간에 따라 주기적으로 메모리 회수 (기본 값 60초)
Garbage Flag로 설정된 오브젝트를 파악하고 메모리를 안전하게 회수
Garbage Flag는 수동으로 설정 X, 시스템이 알아서 설정함

한 번 생성된 언리얼 오브젝트는 바로 삭제가 불가능함. Delete 키워드로 삭제하는 게 아님, 레퍼런스 정보를 없애는 것으로 GC가 자동으로 메모리를 회수하도록 설정

RootSet Flag 설정

AddToRoot 함수를 호출해 루트셋 플래그를 설정하면 최초 탐색 목록으로 설정됨
- RootSet으로 설정된 언리얼 오브젝트는 메모리 회수로부터 보호받음
RemoveFromRoot 함수를 호출해 루트셋 플래그를 제거할 수 있음

콘텐츠를 만들 때 권장하는 방식은 아님

언리얼 오브젝트를 통한 포인터 문제의 해결

메모리 누수 문제
- GC를 통해 자동 해결
- C++ 오브젝트는 직접 신경 써야 함 (or 스마트 포인터 사용)
댕글링 포인터 문제
- 탐지를 위한 함수 제공 ::IsValid()
- C++ 오브젝트는 직접 신경 써야 함 (or 스마트 포인터 사용)
와일드 포인터 문제
- UPROPERTY 속성을 지정하면 자동으로 nullptr로 초기화해 줌
- C++ 오브젝트의 포인터는 직접 nullptr로 초기화 필요 (or 스마트 포인터 사용)

회수되지 않는 언리얼 오브젝트

언리얼 엔진 방식으로 참조를 설정한 언리얼 오브젝트
- UPROPERTY로 참조된 언리얼 오브젝트 (대부분 이걸 사용)
- AddReferencedObjects 함수를 통해 참조를 설정한 오브젝트
RootSet으로 지정된 언리얼 오브젝트

오브젝트 포인터는 가급적 UPROPERTY로 선언하고, 메모리는 가비지 컬렉터가 자동으로 관리하도록 위임한다.

일반 클래스에서 언리얼 오브젝트를 관리하는 경우?

UPROPERTY를 사용하지 못하는 일반 C++ 클래스가 언리얼 오브젝트를 관리해야 하는 경우
FGCObject 클래스를 상속받은 후 AddReferencedObjects 함수를 구현한다
함수 구현부에서 관리할 언리얼 오브젝트를 추가해 줌

아래 실습에서 직접 사용해보자.

언리얼 오브젝트의 관리 원칙

생성된 언리얼 오브젝트를 유지하기 위해 레퍼런스 참조 방법을 설계할 것
- 언리얼 오브젝트 내의 언리얼 오브젝트 : UPROPERTY 사용
- 일반 C++ 내의 언리얼 오브젝트 : FGCObject의 상속 후 구현
생성된 언리얼 오브젝트는 강제로 지우려 하지 말 것
- 참조를 끊는다는 생각으로 설계
- GC에게 회수를 재촉 가능 (ForceGarbageCollection 함수)
- 콘텐츠 제작에서 Destroy 함수를 사용할 수 있으나, 결국 내부 동작은 똑같음 (GC 위임)

실습

GC 테스트 환경 제작

프로젝트 설정에서 GCCycle 시간을 3초로 단축 설정
새로운 GameInstance의 두 함수를 오버라이드
- Init: 어플리케이션이 초기화될 때 호출
- Shutdown: 어플리케이션이 종료될 때 호출
테스트 시나리오
- 플레이 버튼을 누를 때 Init 함수에서 오브젝트를 생성
- 3초 이상 대기해 GC 발동
- 플레이 중지를 눌러 Shutdown 함수에서 생성한 오브젝트의 유효성을 확인

실습 1. UObject의 UPROPERTY() 유무 차이

MyGameInstance.h

private:
	TObjectPtr<class UStudent> NonPropStudent;
	
	UPROPERTY()
	TObjectPtr<class UStudent> PropStudent;
};

MyGameInstance.cpp

NonPropStudent = NewObject<UStudent>(); // UPROPERTY() X

PropStudent = NewObject<UStudent>(); // UPROPERTY() O

댕글링 포인터 문제 발생. (UPROPERTY가 없어 GC가 정리)

LogTemp: NonPropStudent - 널 포인터가 아닌 언리얼 오브젝트
LogTemp: NonPropStudent - 유효하지 않은 언리얼 오브젝트

LogTemp: PropStudent - 널 포인터가 아닌 언리얼 오브젝트
LogTemp: PropStudent - 유효한 언리얼 오브젝트

실습 2. TArray<TPtr*> UPROPERTY() 유무 차이

MyGameInstance.h

TArray<TObjectPtr<class UStudent>> NonPropStudents;

UPROPERTY()
TArray<TObjectPtr<class UStudent>> PropStudents;

MyGameInstance.cpp

// 실습 2
NonPropStudents.Add(NewObject<UStudent>());

PropStudents.Add(NewObject<UStudent>());

UPROPERTY()가 없을 경우 배열 내부에 Ptr에 댕글링 포인터 발생 (GC 정리)

LogTemp: NonPropStudents[0] - 널 포인터가 아닌 언리얼 오브젝트
LogTemp: NonPropStudents[0] - 유효하지 않은 언리얼 오브젝트

LogTemp: PropStudents[0] - 널 포인터가 아닌 언리얼 오브젝트
LogTemp: PropStudents[0] - 유효한 언리얼 오브젝트

실습 3. 일반 C++ 객체 안에 있는 UObject

MyGameInstance.h

class FStudentManager* StudentManager = nullptr;

MyGameInstance.cpp

// 실습 3
// Manager는 일반 C++ 객체
// 안에 있는 UObject를 관리할 수 있는 능력이 전혀 없음
// 이 클래스는 UProperty 같은 걸 쓸 수 없기 때문에
// GC가 발동되면 안에 있는 UObject가 가비지 컬렉션 대상이 되어버림
StudentManager = new FStudentManager(NewObject<UStudent>());

댕글링 포인터 발생 (C++ 내부 객체를 GC가 정리)

LogTemp: StudentInManager - 널 포인터가 아닌 언리얼 오브젝트
LogTemp: StudentInManager - 유효하지 않은 언리얼 오브젝트

실습 4. FGCObject로 C++ 객체 내부 보호

FGCObject를 상속받고 다음 2개의 함수를 구현해야 한다.

GCObject.h

virtual void AddReferencedObjects( FReferenceCollector& Collector ) = 0;

/** Overload this method to report a name for your referencer */
virtual FString GetReferencerName() const = 0;

아래와 같이 먼저 상속을 받은 후

StudentManager.h

class UNREALMEMORY_API FStudentManager : public FGCObject
{
public:
	FStudentManager(class UStudent* InStudent) : SafeStudent(InStudent) {}
	
	// 함수 오버라이드 1 
	virtual void AddReferencedObjects(FReferenceCollector& Collector) override;
	
	// 함수 오버라이드 2
	virtual FString GetReferencerName() const override
	{
		return TEXT("FStudentManager");
	}
	
private:
	class UStudent* SafeStudent = nullptr;
};

AddReferencedObjects를 마저 구현한다: AddReferencedObject(UStudent*)

StudentManager.cpp

#include "StudentManager.h"
#include "Student.h"

void FStudentManager::AddReferencedObjects(FReferenceCollector& Collector)
{
	if (SafeStudent->IsValidLowLevel())
	{
		Collector.AddReferencedObject(SafeStudent);
	}
}

정리

1. C++ 메모리 관리의 한계와 GC의 필요성

문제점: C++의 수동 메모리 관리는 누수(Leak), 댕글링 포인터(Dangling), 와일드 포인터(Wild) 등의 치명적인 오류를 유발하기 쉽다.
해결책: 언리얼 엔진은 가비지 컬렉션(GC) 시스템을 도입하여 사용되지 않는 메모리를 자동으로 회수하고, 포인터의 유효성을 관리한다.

2. GC(Garbage Collection)의 동작 원리

Mark-Sweep 방식: 지정된 주기(기본 60초)마다 어플리케이션을 일시 정지하고 메모리를 검사한다.
RootSet: GC의 시작점. 여기에 등록된 객체와, 그 객체가 참조하는 모든 객체는 '사용 중'으로 간주하여 회수하지 않는다.
회수 대상: RootSet에서 도달할 수 없는(Unreachable) 객체는 가비지(Garbage)로 간주하여 메모리를 해제한다.

3. 언리얼 오브젝트(UObject) 보호 방법

GC가 멀쩡한 오브젝트를 회수해가지 않도록 '참조'를 명확히 해야 한다.

언리얼 오브젝트 내부: 멤버 변수 포인터에 반드시 UPROPERTY() 매크로를 붙인다. (가장 권장됨)
일반 C++ 클래스 내부: FGCObject를 상속받고 AddReferencedObjects 함수를 오버라이드하여 참조를 알린다.
특수 상황: AddToRoot 함수로 강제 보호할 수 있으나, 관리가 어려워 권장하지 않는다.

4. 안전한 언리얼 코딩 표준

선언: UObject를 가리키는 모든 포인터는 TObjectPtr<T>와 UPROPERTY()를 조합하여 선언한다.
- 자동 초기화(nullptr), 댕글링 포인터 감지, 참조 카운팅이 자동으로 처리된다.
생성: new 대신 NewObject<T>()를 사용한다.
소멸: delete를 절대 직접 호출하지 않는다.
- 필요 없다면 nullptr를 대입해 참조를 끊거나, ConditionalBeginDestroy() 등을 사용해 GC에게 처리를 위임한다.
검증: 포인터 사용 전 IsValid() 또는 ::IsValid()로 유효성을 검증하는 습관을 들인다.

실제로 코딩할때..

1. UPROPERTY() 필수

UObject 상속 클래스의 멤버 변수 포인터를 선언할 때 UPROPERTY() 매크로를 잊지 말자.
- 이걸 빼먹으면 GC가 마음대로 메모리를 회수해간다.

2. NewObject<T>() 사용

UObject를 생성할 때 습관적으로 C++의 new를 쓰지 말고, 반드시 NewObject<T>()를 사용하자.
- new로 만든 UObject는 GC의 보호를 전혀 받지 못한다.

3. IsValid() 습관화

포인터 변수에 접근(->)하기 전, IsValid() 혹은 ::IsValid()로 유효성을 체크하는 습관을 가지자.

4. 일반 클래스는 조심 (FGCObject)

일반 C++ 클래스(구조체, 매니저 등)에 UObject 포인터를 멤버로 넣어야 한다면 FGCObject 상속을 고려하자.
- 일반 클래스는 UPROPERTY를 못 쓴다. 그냥 두면 댕글링 포인터가 되어버린다.

5. Destroy()의 GC 시차

Actor->Destroy()를 호출했다고 해서 그 즉시 메모리가 null이 되는 게 아님을 기억하자.
- GC가 돌기 전까지는 삭제 대기(Pending Kill) 상태로 메모리에 남아있다. 이 시차를 조심하자.

[UE5/Data] 11. UStruct & Map

Tue, 10 Feb 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

UStruct (언리얼 구조체)

여러 변수를 하나의 묶음으로 관리할 수 있게 해주는 사용자 정의 데이터 타입.

특징

경량 객체: 데이터 저장 및 전송에 특화되어 있으며, UObject보다 가볍다.
명명 규칙: 언리얼 구조체의 이름은 접두사 F로 시작 (예: FStudentData).
리플렉션 지원 (GENERATED_BODY)
- 엔진 내부적으로는 UScriptStruct 클래스로 구현
제약 사항
- UPROPERTY()를 통해 변수(속성)는 리플렉션에 노출 가능
- 단, UFUNCTION() 매크로는 사용X (블루프린트에서 호출 가능한 함수 생성 불가). C++ 멤버 함수 자체는 생성 가능
메모리 관리
- UObject와 달리 가비지 컬렉터(GC)의 자동 관리를 받지 않는다.
- 주로 스택(Stack)에 할당하거나, 다른 클래스의 멤버 변수로 포함되어 사용
- NewObject<T>() API를 사용할 수 없으며, new 연산자나 스택 할당을 사용

내부 구조 (리플렉션 계층)

UStruct는 UField를 상속
내부에 UField* Next 포인터 등을 통해 구조체 안에 정의된 속성(Property)들을 리스트 형태로 연결하여 관리 (위 그림에 포함(composition)관계)
비교: UClass는 함수(UFunction) 정보까지 포함하지만, UScriptStruct는 데이터만

실습 코드

구조체 & TArray 활용

MyGameInstance.h : 배열로 구조체 관리 예제

#pragma once
#include "CoreMinimal.h"
#include "Engine/GameInstance.h"
#include "MyGameInstance.generated.h"

// 1. 구조체 선언
USTRUCT()
struct FStudentData
{
	GENERATED_BODY()
	
	// 기본 생성자 (리플렉션시 필요)
	FStudentData()
	{
		Name = TEXT("기본이름");
		Order = -1;
	}
	
	// 임의 생성자
	FStudentData(FString InName, int32 InOrder) : Name(InName), Order(InOrder) {}

	UPROPERTY()
	FString Name;

	UPROPERTY()
	int32 Order;
};

// 2. 클래스 선언
UCLASS()
class UNREALCONTAINER_API UMyGameInstance : public UGameInstance
{
	GENERATED_BODY()

public:
	virtual void Init() override;

private:
	// 일반 구조체 배열 (GC관리 대상 아님)
	TArray<FStudentData> StudentsData;
	
	// 언리얼 오브젝트 포인터 배열
	// TArray 내부에서 포인터를 관리할때는 UPROPERTY() 매크로 필수
	// 없으면, GC가 참조 인식을 못해 객체를 삭제함 (Dangling Pointer - 크래시!)
	UPROPERTY() 
	TArray<TObjectPtr<class UStudent>> Students;
};

TArray 사용 시 주의사항

일반 C++ 타입 / 구조체 (FStudentData)
- TArray가 값 자체를 복사해서 들고 있으므로 UPROPERTY()가 없어도 동작에 치명적인 문제 없음 (직렬화 제외)
언리얼 오브젝트 포인터 (TArray<UObject*>)
- UPROPERTY() 매크로 필요

TMap

STL map vs TMap

특징	std::map (C++ STL)	TMap (Unreal)
자료구조	이진 트리 (Binary Tree)	해시 테이블 (Hash Table)
유사 STL	-	`std::unordered_map`과 유사
정렬	Key 기준 자동 정렬됨	정렬되지 않음 (입력 순서 보장 X)
메모리	노드 기반 (메모리 파편화 가능성)	희소 배열 (Sparse Array) 기반
성능	검색/삽입/삭제: $O(\log N)$	검색/삽입/삭제: 평균 $O(1)$

TMap 구조 및 특징

Key-Value 쌍 Key와 Value의 튜플 데이터(TPair<Key, Value>)를 관리
희소 배열 구조
- 데이터 삭제 시 메모리를 재할당(Realloc)하거나 당겨오지 않고, 해당 자리를 '비어있음'으로 표시
- 이 덕분에 STL보다 **캐시 적중률(Cache Locality)**이 높고 순회 속도가 빠름
TMultiMap 중복된 Key를 허용해야 할 경우 사용 (TMap은 Key 중복 불가능, 덮어씌워짐)

선언 및 사용

// Key: int32, Value: FString
TMap<int32, FString> StudentMap;

// 데이터 추가 (기존 Key가 있으면 덮어씀)
StudentMap.Add(1, TEXT("이름1"));
StudentMap.Emplace(2, TEXT("이름2"));

TMap이나 TSet의 Key로 커스텀 구조체(FStruct)를 쓰려면 전역 함수 GetTypeHash를 반드시 오버로딩

시간복잡도 비교

구분	TArray (동적 배열)	TSet / TMap (해시 테이블)
인덱스 접근	$O(1)$	불가능
검색 (Find)	$O(N)$	평균 $O(1)$
삽입 (Add/Emplace)	$O(N)$	평균 $O(1)$
삭제 (Remove)	$O(N)$	평균 $O(1)$
메모리 특징	연속된 메모리 (빈틈 없음)	희소 배열 (중간에 빈틈 존재)
	순차 접근/순회에 유리	빠른 검색에 유리

[UE5/Data] 10. TArray & TSet

Mon, 09 Feb 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

강의 목표

언리얼 대표 컨테이너 라이브러리 TArray, TSet의 내부 구조 이해
각 컨테이너의 장단점 파악, 알맞게 활용하는 방법 학습

언리얼 C++ 주요 컨테이너 라이브러리

Set과 Map은 C++ STL과 내부 구현 방식이 다르다.

STL	UCL	특징
vector	TArray	순차적, 가장 빠름
set	TSet	중복 허용 X, 빠른 검색
map	TMap	키-값 쌍, 빠른 검색

TArray

공식 문서: TArray

가변 배열(Dynamic Array) 자료 구조이다.

STL의 vector와 동작 원리가 유사하다.
게임 제작에서 가장 효율적인 컨테이너이다.
- 데이터가 메모리에 연속적으로 위치해 캐시 지역성(Locality) 효율이 매우 높다.
- 임의 데이터 접근(Random Access)이 빠르다. O(1)
- 요소 순회 속도가 가장 빠르다. O(N)
맨 끝에 데이터를 추가하는 것은 가볍다. (Amortized Constant)
단점
- 중간 요소의 추가/삭제는 뒤의 요소들을 이동시켜야 하므로 비용이 크다. O(N)
- 데이터가 많아질수록 검색 작업이 느려진다. O(N) (이 경우 TSet 고려)

Add vs Emplace

Add
- 외부에서 객체를 생성 후, 컨테이너 내부로 복사(Copy) 혹은 이동(Move)한다.
Emplace
- 컨테이너 내부에서 직접 생성자를 호출하여 객체를 만든다.
- 임시 객체 생성 및 복사/이동 비용을 절약할 수 있다.

int와 같은 원시 타입(Primitive Type)은 차이가 없으나, 덩치가 큰 구조체나 클래스는 Emplace 사용을 권장한다. 효율성 측면에서 Emplace는 항상 Add보다 같거나 좋다.

정렬 (Sorting)

Sort: 일반적인 퀵 정렬 기반 (불안정 정렬)
HeapSort: 힙 정렬
StableSort: 병합 정렬(Merge Sort) 기반. 요소의 상대적 순서가 유지된다.

주요 쿼리 및 기능

Num: 요소 개수 반환
GetData: 데이터의 원시 포인터 반환 (C 스타일 배열처럼 사용 가능)
operator[]: 인덱스 접근 (유효성 검사 없음, 빠름)
IsValidIndex: 특정 인덱스의 유효성 검사
Top, Last: 마지막 요소 반환
Find, FindLast: 요소 검색 (O(N))
RemoveAt: 특정 인덱스 제거 (O(N), 뒤의 요소를 당겨옴)
RemoveSwap: 제거 후 맨 끝 요소를 해당 자리로 옮김 (O(1), 순서가 중요하지 않을 때 매우 효율적)

디버깅 팁

언리얼은 기본적으로 최적화 레벨이 높아 디버깅 시 변수 값이 보이지 않을 수 있다.

Int32Array += { 2, 4, 6, 8, 10 };
// 변수가 최적화되어 사용할 수 없습니다.

해결: 솔루션 구성을 Development Editor (O2) -> DebugGame Editor(O0)로 변경
최적화가 꺼지며(O0) 정상적으로 메모리 뷰 확인 가능

메모리 직접 제어

AddUninitialized로 공간만 확보하고 FMemory::Memcpy로 고속 복사가 가능하다.

TArray<int32> Int32ArrayCompare;
int32 CArray[] = { 1, 3, 5, 7, 9, 2, 4, 6, 8, 10 };

// 초기화 없이 메모리 공간만 확보 (생성자 호출 안 함)
Int32ArrayCompare.AddUninitialized(ArrayNum); 
FMemory::Memcpy(Int32ArrayCompare.GetData(), CArray, sizeof(int32) * ArrayNum);

알고리즘 라이브러리

STL의 algorithm과 유사한 Algo 라이브러리를 제공한다.

#include "Algo/Accumulate.h"

// 배열의 합계 계산
int32 SumByAlgo = Algo::Accumulate(Int32Array, 0);

TSet

공식 문서: TSet

STL set vs UE TSet

STL std::set
- 이진 트리(Red-Black Tree) 구성
- 정렬된 상태 유지
- 메모리가 파편화되어 있을 수 있음
- 순회 효율이 상대적으로 낮음
UE TSet
- 해시 테이블(Hash Table) 기반
- 희소 배열(Sparse Array) 형태로 데이터 저장
- 데이터가 비어있는 공간(Hole; Slack)이 존재할 수 있음
- 정렬되지 않음
- 검색 속도가 빠름 O(1)
- 메모리가 상대적으로 모여 있어 순회 효율이 좋음

주요 특징

중복 없는 데이터 집합 구축에 사용
요소가 삭제되어도 메모리를 즉시 재할당하지 않고 빈칸(Invalid)으로 남겨둠
데이터 중간중간 비어있는 공간을 Slack이라 함
KeyFuncs를 통해 해시 생성을 커스터마이징 가능 (이번 강의에서는 다루지 않음)

실습: 삭제 후 재추가 동작 확인

TSet은 내부적으로 희소 배열을 사용하므로, 요소 삭제 시 해당 인덱스에 플래그를 세운다.

TSet<int32> Int32Set;
// 1~10 추가
for (int32 ix = 1; ix <= 10; ++ix) Int32Set.Add(ix);

// 짝수 제거 (2, 4, 6, 8, 10) -> 해당 인덱스는 Invalid 상태가 됨
Int32Set.Remove(2);
// ... 
Int32Set.Remove(10);

// 다시 짝수 추가
Int32Set.Add(2);
// ... 
Int32Set.Add(10);

메모리 뷰 확인

삭제된 공간(Invalid)을 재활용하여 값이 채워진다. 이때 순서는 보장되지 않으며, 빈 공간의 뒤쪽부터 채워지는 경향이 있다.

아래 표를 보면 인덱스[9]에 값으로 2부터 채워진걸 볼 수 있다.

이름	값	형식
Name	Value	Type
[0]	1	int
[1]	10	int
[2]	3	int
[3]	8	int
[4]	5	int
[5]	6	int
[6]	7	int
[7]	4	int
[8]	9	int
[9]	2	int

정리

TArray & TSet 시간 복잡도 비교

	TArray	TSet
접근	O(1)	O(1)*
검색	O(N)	O(1)
삽입	O(N)	O(1)
삭제	O(N)	O(1)
메모리	연속된 메모리 (빈틈없음)	희소 배열 (Invalid 존재)
특징	최고의 접근/순회 성능	빠른 중복 감지 및 검색

TSet의 접근은 이터레이터를 통하거나 해시를 통한 조회를 의미하며, TSet을인덱스로 임의 접근하는 것은 일반적인 사용법이 아님.

게임 로직의 대부분은 TArray로 해결된다.
하지만, 빈번한 검색과 중복 방지가 필요할때는 TSet으로의 전환을 고려하자.

[UE5/OOP] 9. Delegate & Pub/Sub

Sun, 08 Feb 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

강의 목표

느슨한 결합의 장점과 이를 편리하게 구현하도록 도와주는 델리게이트의 이해
발행 구독 디자인 패턴의 이해
언리얼 델리게이트를 활용한 느슨한 결합의 설계와 구현의 학습

Delegate

이전에 배운 컴포지션(Composition)은 강한 결합 관계를 가진다.
델리게이트(Delegate)는 약한 결합 관계를 가지며, 주로 구독자 패턴(Observer Pattern)을 구현할 때 사용한다.

언리얼 Delegate 공식 문서

발행 구독 디자인 패턴 (Pub/Sub)

푸시(Push) 형태의 알림(Notification)을 구현하는데 적합한 디자인 패턴
발행자(Publisher)와 구독자(Subscriber)로 구분
- 콘텐츠 제작자는 콘텐츠를 생산한다.
- 발행자는 콘텐츠를 배포한다.
- 구독자는 배포된 콘텐츠를 받아 소비한다.
- 제작자와 구독자가 서로를 몰라도, 발행자를 통해 콘텐츠를 생산하고 전달할 수 있다.
장점
- 제작자, 구독자는 서로를 모르기 때문에 느슨한 결합(Loose Coupling)으로 구성된다.
- 유지 보수가 쉽고, 유연하게 활용될 수 있으며, 테스트가 쉬워진다.
- 시스템 스케일을 유연하게 조절할 수 있으며(Scalability), 기능 확장(Extensibility)이 용이하다.

실습 시나리오

학사정보 (CourseInfo) 학생(Student)
- 학교는 학사 정보를 관리한다.
- 학사 정보가 변경되면 자동으로 학생에게 공지한다.
- 학생은 학사 정보의 알림 구독을 해지할 수 있다.
시나리오 흐름
- 학사 정보 시스템과 3명의 학생이 존재한다.
- 시스템에서 학사 정보를 변경한다.
- 학사 정보가 변경되면 알림을 구독한 학생들에게 변경 내용을 자동으로 전달한다.

언리얼 델리게이트 선언 시 고려사항

인자의 수와 각각의 타입을 설계
- 일대일?
- 일대다?
프로그래밍 환경 설정
- Only C++?
- UFUNCTION으로 지정된 블루프린트(BP) 함수와 함께 사용?
어떤 함수와 연결할 것인가?
- 클래스 외부에 설계된 C++ 함수?
- 전역에 설계된 정적 함수?
- 언리얼 오브젝트의 멤버 함수? (보통 이 방식을 사용)

매크로 구조

DECLARE_{델리게이트유형}DELEGATE{함수정보}

델리게이트 유형
- DECLARE_DELEGATE (일대일)
- DECLARE_MULTICAST (일대다)
- DECLARE_DYNAMIC (블루프린트 연동, 일대일)
- DECLARE_DYNAMIC_MULTICAST (블루프린트 연동, 일대다)
함수 정보
- DECLARE_DELEGATE
- DECLARE_DELEGATE_OneParam
- DECLARE_DELEGATE_RetVal_ThreeParams
- 최대 9개 파라미터까지 지원

실습

설계 내용

학사정보 변경 시 학교명, 내용을 학생에게 전달해야 함 -> 2개의 인자
변경된 학사 정보는 다수 인원을 대상으로 발송해야 함 -> MULTICAST
오직 C++ 프로그래밍에서만 사용 -> DYNAMIC 사용 X

결론: DECLARE_MULTICAST_DELEGATE_TwoParams 매크로 사용

1. CourseInfo

발행자 (Publisher) 역할
델리게이트를 정의하고, 학사 정보가 변경될 때 Broadcast로 알림을 발행한다.

CourseInfo.h

// delegate 매크로 선언
DECLARE_MULTICAST_DELEGATE_TwoParams(FCourseInfoOnChangedSignature, const FString&, const FString&);

UCLASS()
class UNREALDELEGATE_API UCourseInfo : public UObject
{
    GENERATED_BODY()
public:
    UCourseInfo();

    // 델리게이트 멤버 변수 선언
    FCourseInfoOnChangedSignature OnChanged;
    
    // 외부에서 학사정보 변경 요청 시 호출되는 함수
    void ChangeCourseInfo(const FString& InSchoolName, const FString& InNewContents);

private:
    FString Contents;
};

CourseInfo.cpp

UCourseInfo::UCourseInfo()
{
    Contents = TEXT("기존 학사 정보");
}

void UCourseInfo::ChangeCourseInfo(const FString& InSchoolName, const FString& InNewContents)
{
    // 5. 학사 정보 내용 업데이트
    Contents = InNewContents;
    
    UE_LOG(LogTemp, Log, TEXT("[CourseInfo] 학사 정보가 변경되어 알림을 발송합니다."));
    
    // 6. 델리게이트를 통해 알림 발행 (구독자들에게 방송)
    OnChanged.Broadcast(InSchoolName, Contents);
}

2. Student

구독자 (Subscriber) 역할
발행자(CourseInfo)가 알림을 보내면 자신이 등록한 함수(GetNotification)를 자동으로 호출받는다.

Student.h

UCLASS()
class UNREALDELEGATE_API UStudent : public UObject
{
    GENERATED_BODY()

public:
    // 알림을 받을 함수
    void GetNotification(const FString& School, const FString& NewCourseInfo);
private:
    FString Name;
};

Student.cpp

// 7. 모든 구독자 학생들이 알림을 받음
void UStudent::GetNotification(const FString& School, const FString& NewCourseInfo)
{
    UE_LOG(LogTemp, Log, TEXT("[Student] %s 님이 %s로부터 받은 메시지 : %s"), *Name, *School, *NewCourseInfo);
}

3. MyGameInstance

조율자 (Coordinator) 역할
발행자와 구독자를 연결해주는 역할을 한다.
- CourseInfo를 생성
- Student들을 생성한다. (여기서는 3개)
- Student들을 CourseInfo의 델리게이트에 바인딩(구독)시킨다.
유일하게 두 클래스(CourseInfo, Student)를 모두 include한다.

MyGameInstance.h

private:
    UPROPERTY()
    TObjectPtr<class UCourseInfo> CourseInfo;

MyGameInstance.cpp

void UMyGameInstance::Init()
{
    Super::Init();

    // CourseInfo는 MyGameInstance의 SubObject가 되고
    // MyGameInstance는 CourseInfo의 Outer가 됨
    // 1. Composition 관계로 CourseInfo 생성 (발행자)
    CourseInfo = NewObject<UCourseInfo>(this); 

    UE_LOG(LogTemp, Log, TEXT("==============================="));

    // 2. Student 객체 생성 (구독자)
    UStudent* Student1 = NewObject<UStudent>(this);
    Student1->SetName(TEXT("학생1"));
    UStudent* Student2 = NewObject<UStudent>(this);
    Student2->SetName(TEXT("학생2"));   
    UStudent* Student3 = NewObject<UStudent>(this);
    Student3->SetName(TEXT("학생3"));   
    
    // 3. 모든 학생을 구독자로 등록 (Binding)
    CourseInfo->OnChanged.AddUObject(Student1, &UStudent::GetNotification);
    CourseInfo->OnChanged.AddUObject(Student2, &UStudent::GetNotification);
    CourseInfo->OnChanged.AddUObject(Student3, &UStudent::GetNotification);

    FString SchoolName = TEXT("언리얼대학교");
    
    // 4. 발행자에게 정보 변경 요청 (이벤트 발생 트리거)
    CourseInfo->ChangeCourseInfo(SchoolName, TEXT("변경된 학사 정보"));
}

출력 결과

LogTemp: ===============================
LogTemp: [CourseInfo] 학사 정보가 변경되어 알림을 발송합니다.
LogTemp: [Student] 학생3 님이 언리얼대학교로부터 받은 메시지 : 변경된 학사 정보
LogTemp: [Student] 학생2 님이 언리얼대학교로부터 받은 메시지 : 변경된 학사 정보
LogTemp: [Student] 학생1 님이 언리얼대학교로부터 받은 메시지 : 변경된 학사 정보

전체 흐름 요약

MyGameInstance: CourseInfo 생성 (발행자 준비)
MyGameInstance: Student 객체 생성 (구독자 준비)
MyGameInstance: 학생들을 CourseInfo.OnChanged 델리게이트에 구독자로 등록 (AddUObject)
CourseInfo: 학사 정보 변경 시 델리게이트 Broadcast 실행 (모든 학생에게 발행)
Student: 등록된 함수 GetNotification 자동 호출 (구독자 알림 수신)

정리

델리게이트 vs 컴포지션

델리게이트: 느슨한 결합 (기능적 의존성 제거, 구독자 패턴 활용)
컴포지션: 강한 결합 (객체의 생성과 소멸 주기를 완전히 소유)

느슨한 결합 (Loose Coupling)의 장점

향후 시스템 변경 사항에 대해 손쉽게 대처할 수 있다.
발행-구독 모델의 이점
- 클래스는 자신이 해야 하는 작업에만 집중 가능
- 외부 변경 사항에 영향을 받지 않음
- 자신의 기능을 확장해도 다른 모듈에 영향을 주지 않음

언리얼 C++ 델리게이트 선언시 생각할 점

적합한 매크로를 선택하기 위해 다음을 고려한다

인자의 개수: 파라미터가 몇 개 필요한가?
동작 방식: 1:1 통신인가, 1:N(Multicast) 통신인가?
블루프린트 연동: 에디터/BP에서 접근이 필요한가? (Dynamic 필요 여부)

기타: UML에서의 표기

따로 번외편에서 정리.

[UE5/OOP] 8. Composition

Sat, 07 Feb 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

강의 목표

언리얼 C++의 컴포지션 기법을 사용해 오브젝트의 포함 관계를 설계한다.
언리얼 C++이 제공하는 열거형(Enum) 타입의 선언과 메타데이터 활용 방법을 학습한다.

컴포지션 (Composition)

객체 지향 설계에서 상속이 가진 Is-A 관계에만 의존해서는 복잡한 기능을 설계하고 유지 보수하기 어렵다.

컴포지션은 Has-A 관계를 구현하는 설계 방법이다. 복합적인 기능을 가진 거대한 클래스를 상속으로만 처리하지 않고, 필요한 기능을 가진 부품(오브젝트)을 조립해서 만든다.

하나의 언리얼 오브젝트에는 항상 클래스 기본 오브젝트인 CDO(Class Default Object)가 존재한다.
언리얼 오브젝트에 다른 언리얼 오브젝트를 조합(Composition)할 때, CDO 생성 시점에 따라 두 가지 선택지가 존재한다.
- 생성자 CDO 생성 시점에 미리 산하 오브젝트를 생성해 조합한다. (CreateDefaultSubobject API 활용)
- 런타임 CDO에는 빈 포인터만 두고, 런타임(게임 실행 중)에 필요할 때 오브젝트를 생성해 조합한다. (NewObject API 활용)
언리얼 오브젝트 간의 컴포지션 관계 용어
- SubObject 내가 소유한 산하 언리얼 오브젝트 (그림의 보라 상자 → 초록 상자)
- Outer 나를 소유한 상위 언리얼 오브젝트 (그림의 초록 상자 → 보라 상자)

실습

1. Card 클래스 생성 (Enum 활용)

언리얼 엔진의 리플렉션 기능을 활용하기 위해 UENUM 매크로와 UMETA를 사용한다. Card.h

UENUM()
enum class ECardType : uint8
{
	Student = 1 UMETA(DisplayName = "For Student"),
	Teacher UMETA(DisplayName = "For Teacher"),
	Staff UMETA(DisplayName = "For Staff"),
	Invalid
};

UCard 클래스 생성 및 ECardType 멤버 변수 추가
CardType에 대한 Getter/Setter 구현

2. Person has-a Card (컴포지션 구현)

Person 클래스가 Card 객체를 소유하도록 구현한다.

Person.h

UCLASS()
class UNREALCOMPOSITION_API UPerson : public UObject
{
	GENERATED_BODY()

public:
	UCard* GetCard() const { return Card; }
	void SetCard(UCard* InCard) { Card = InCard; }

protected:
	// Person has-a Card
	// 언리얼 5부터는 원시 포인터 대신 TObjectPtr<T> 사용 권장
	UPROPERTY()
	TObjectPtr<UCard> Card; 
	
	// class UCard* Card; // 언리얼 4 방식
};

TObjectPtr 언리얼 5로 넘어오면서 UPROPERTY로 지정된 멤버 변수는 원시 포인터 대신 TObjectPtr 래퍼 클래스를 사용하는 것으로 변경되었다. (에디터 빌드 시 동적 로딩 등 이점 제공, 런타임에서는 원시 포인터와 동일)

3. GameInstance에서 활용

컴포지션 객체 접근

MyGameInstance.cpp

const UCard* OwnCard = Person->GetCard();
if (OwnCard)
{
	ECardType CardType = OwnCard->GetCardType();
	UE_LOG(LogTemp, Log, TEXT("%s님이 소유한 카드 종류 %d"), *Person->GetName(), (int32)CardType);
}

Enum 메타데이터 접근 (리플렉션)

FindObject를 사용해 열거형의 메타 정보(UMETA로 지정한 DisplayName)를 가져올 수 있다.

MyGameInstance.cpp

const UEnum* CardEnumType = FindObject<UEnum>(nullptr, TEXT("/Script/UnrealComposition.ECardType"));
if (CardEnumType)
{
	// Enum의 Value를 통해 DisplayName(MetaData)을 문자열로 추출
	FString CardMetaData = CardEnumType->GetDisplayNameTextByValue((int64)CardType).ToString();
	UE_LOG(LogTemp, Log, TEXT("%s님이 소유한 카드 종류: %s"), *Person->GetName(), *CardMetaData);
}

출력 결과

LogTemp: ===============================
LogTemp: 학생님이 소유한 카드 종류 1
LogTemp: 선생님님이 소유한 카드 종류 For Teacher
LogTemp: 직원님이 소유한 카드 종류 For Staff

정리

언리얼 C++는 객체 간의 포함 관계(Has-A)를 구현하는 컴포지션 패턴을 지원한다.
생성자 단계에서 CreateDefaultSubobject를 사용해 필수적인 SubObject를 미리 생성하고 조립할 수 있다.
- SubObject 내가 소유한 하위 오브젝트
- Outer 나를 소유한 상위 오브젝트
TObjectPtr는 UE5부터 도입된 표준 객체 포인터 래퍼 클래스이다. (헤더에서 TObjectPtr<UCard> Card; 형태로 선언하여 컴포지션 구현)
enum class와 UMETA매크로를 조합하면 열거형의 메타 정보를 런타임에 활용 가능하다.

[UE5/OOP] 7. Interface

Fri, 06 Feb 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

강의 목표

언리얼 C++ 인터페이스 클래스를 사용해 안정적으로 클래스를 설계하는 기법 학습

이론

Interface

객체가 반드시 구현해야 할 행동을 지정하는 데 활용하는 타입
다형성(Polymorphism)의 구현, 의존성이 분리(Decouple)된 설계에 유용하게 활용

UE 게임 콘텐츠 오브젝트 설계 예시

월드에 배치되는 모든 오브젝트(움직이지 않는 것도 포함) : Actor
움직이는 오브젝트 : Pawn
길찾기 시스템을 반드시 사용하면서 움직이는 오브젝트 : INavAgentInterface 인터페이스를 구현한 Pawn

언리얼 Interface 특징

인터페이스를 생성하면 두 개의 클래스가 생성됨
- U로 시작하는 타입 : UInterface 클래스 (타입 정보 제공)
- I로 시작하는 Interface 타입 : IInterface (실질적인 설계 및 구현)-
U타입 클래스 정보는 런타임시 인터페이스 구현 여부 파악 용으로만 사용
- 실제로 U타입 클래스를 작업할 필요 X
인터페이스 구성 및 구현은 I 클래스에서 진행

실습

아래 클래스 구조를 직접 구현해보자.

1. 전 프로젝트 소스 코드 불러오기

UnrealInterface라는 새 프로젝트 생성
외부 프로젝트에 만들어둔 MyGameInstance.h 와 MyGameInstance.cpp를 현재 프로젝트 폴더로 옮긴 후, UE에서 Tools -> Refresh Visual Studio Project를 하면 VS에 뜨긴 하지만 컴파일 에러가 발생
MyGameInstance.h 코드 구조를 보면:

class OBJECTREFLECTION_API UMyGameInstance : public UGameInstance

현재 프로젝트에 맞게 _API 매크로를 변경할 필요가 있음
- OBJECTREFLECTION_API -> UNREALINTERFACE_API
언리얼 엔진이 어떤 식으로 빌드하는지는 이후 강좌에서 다룸

2. 클래스 설계

Person 클래스 생성
상속받는 클래스 3개 생성
- Student
- Teacher
- Staff

Person 객체는 생성자, getter/setter, Name 프로퍼티 보유
Person.h

UCLASS()
class UNREALINTERFACE_API UPerson : public UObject
{
	GENERATED_BODY()

public:
	UPerson();

	FORCEINLINE FString& GetName() { return Name; }
	FORCEINLINE void SetName(const FString& InName) { Name = InName; } // 복사 1회 발생

protected:
	UPROPERTY()
	FString Name;
};

TArray로 묶어주고 Person을 상속받는 객체 3개를 출력해보자.
MyGameInstance.cpp

UE_LOG(LogTemp, Log, TEXT("==============================="));
TArray<UPerson*> Persons = 
	{ NewObject<UStudent>(), NewObject<UTeacher>(), NewObject<UStaff>() };

for (const auto Person : Persons)
{
	UE_LOG(LogTemp, Log, TEXT("구성원 이름 : %s"), *Person->GetName());
}

실행 결과

LogTemp: ===============================
LogTemp: 구성원 이름 : 학생
LogTemp: 구성원 이름 : 선생님
LogTemp: 구성원 이름 : 직원
LogTemp: ==============================

3. 인터페이스

3-1. 인터페이스 정의

인터페이스를 추가해보자.

인터페이스를 상속받으면, 추상화 부분을 무조건 구현해야 한다.
C++ 인터페이스는 보통 순수 가상 함수(Pure Virtual Function)로 구현을 강제하지만, 언리얼 인터페이스는 내부에 기본 함수 구현을 넣을 수도 있다.

LessonInterface.h

class UNREALINTERFACE_API ILessonInterface
{
	GENERATED_BODY()
public:
	virtual void DoLesson()
	{
		UE_LOG(LogTemp, Log, TEXT("수업에 입장합니다."));
	}
};

3-2. 인터페이스 구현 (상속 및 오버라이드)

Student와 Teacher 클래스에 인터페이스를 상속받고 기능을 구현한다.
Staff는 인터페이스를 상속받지 않는다.

Student.h / Teacher.h

UCLASS()
class UNREALINTERFACE_API UStudent : public UPerson, public ILessonInterface
{
	GENERATED_BODY()
public:
	virtual void DoLesson() override
	{
		UE_LOG(LogTemp, Log, TEXT("%s님은 수업을 듣습니다."), *Name);
	}
};

UCLASS()
class UNREALINTERFACE_API UTeacher : public UPerson, public ILessonInterface
{
	GENERATED_BODY()
public:
	virtual void DoLesson() override
	{
		UE_LOG(LogTemp, Log, TEXT("%s님은 가르칩니다."), *Name);
	}
};

3-3. 인터페이스 검사 : Cast<T>()

Cast<T>()를 통해 인터페이스를 상속받고 있는지 검사가 가능하다.

MyGameInstance.cpp

// 형변환으로 검사
for (const auto Person : Persons)
{
	ILessonInterface* LessonInterface = Cast<ILessonInterface>(Person);
	if (LessonInterface)
	{
		UE_LOG(LogTemp, Log, TEXT("%s님은 수업에 참여할 수 있습니다."), *Person->GetName());
		LessonInterface->DoLesson();
	}
	else
	{
		UE_LOG(LogTemp, Log, TEXT("%s님은 수업에 참여할 수 없습니다."), *Person->GetName());
	}
}

실행 결과

LogTemp: 학생님은 수업에 참여할 수 있습니다.
LogTemp: 학생님은 수업을 듣습니다.

LogTemp: 선생님님은 수업에 참여할 수 있습니다.
LogTemp: 선생님님은 가르칩니다.

LogTemp: 직원님은 수업에 참여할 수 없습니다.

(참고: DoLesson() 내부에서 Super::DoLesson()을 호출하지 않았으므로 "수업에 입장합니다" 로그는 출력되지 않고 오버라이드된 로그만 출력됨. 만약, 인터페이스의 구현부 출력이 필요하면 Super로 추가할 것)

정리

interface는 클래스가 반드시 구현해야 하는 기능을 지정하는 데 사용된다.
C++은 기본적으로 다중 상속을 지원하지만, 언리얼 C++에서는 interface를 사용하여 축소된 다중상속(단일 상속 + 다중 인터페이스 구현) 형태로 설계하는 것이 향후 유지보수에 유리하다.
interface 생성 시 두 개의 클래스(UInterface, IInterface)가 생성된다.
언리얼 인터페이스는 abstract 타입으로 강제되지 않으며, 내부에 기본 함수 동작을 구현할 수 있다.

[UE5/UObject] 6. UObject Reflection 2

Thu, 05 Feb 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

강의 목표

리플렉션 시스템을 이용해 언리얼 오브젝트를 다루는 방법
- 속성/함수 검색 및 호출/변경
- 접근 지시자 우회

1. FProperty로 속성 접근/변경

MyGameInstance.cpp

Super::Init();

// 언리얼 오브젝트 생성 - NewObject<T>()
UStudent* Student = NewObject<UStudent>(this);
UTeacher* Teacher = NewObject<UTeacher>(this);

FString CurrentTeacherName;
FString NewTeacherName(TEXT("새이름"));

FProperty* NameProp = UTeacher::StaticClass()->FindPropertyByName(TEXT("Name"));
if (NameProp)
{
	// 접근
	NameProp->GetValue_InContainer(Teacher, &CurrentTeacherName);
	UE_LOG(LogTemp, Log, TEXT("현재 선생님 이름 %s"), *CurrentTeacherName);
	
	// 변경
	NameProp->SetValue_InContainer(Teacher, &NewTeacherName);
	UE_LOG(LogTemp, Log, TEXT("현재 선생님 이름 %s"), *Teacher->GetName());
}

Person.h

protected:
	UPROPERTY()
	FString Name; // 선생(학생) 이름

Output Log

LogTemp: 현재 선생님 이름 이선생
LogTemp: 현재 선생님 이름 새이름

FProperty의 API를 이용해 프로퍼티의 접근 및 변경이 가능하다.
- GetValue_InContainer()
- SetValue_InContainer()
이때, Protected로 보호받고 있는 프로퍼티 값인 선생님 이름을 Reflection을 이용해 그대로 출력 가능

2. UFunction으로 함수 사용

MyGameInstance.cpp

Student->DoLesson();
UFunction* DoLessonFunc = Teacher->GetClass()->FindFunctionByName(TEXT("DoLesson"));
if (DoLessonFunc)
{
	Teacher->ProcessEvent(DoLessonFunc, nullptr); // 인자가 없는 함수라 null 전달
}

Output Log

LogTemp: 새이름님이 수업에 참여합니다. // Person.cpp
LogTemp: 3년차 선생님 새이름님이 수업을 강의합니다. // Teacher.cpp

UFunction의 API를 이용해 함수 사용이 가능하다.

정리

Reflection System 활용
- 언리얼 오브젝트의 특정 속성과 함수를 이름으로 검색 가능
- 접근 지시자와 무관하게 값을 설정
- 언리얼 오브젝트의 함수 호출
언리얼 엔진의 프레임워크는 리플렉션을 활용해서 구축되어 있으므로, 이해가 필요
(주의) 컴파일러의 타입 체크 지원을 받지 못하므로, 런타임때 검증 로직을 직접 작성해야 함

번외

타입 안정성 개선 : CastField<T>()

문제

FindPropertyByName은 단순히 메모리 오프셋 정보만 가져온다.
타입 일치 여부를 보장하지 않아, 메모리 오염(Memory Corruption) 위험이 존재

개선

CastField<T>를 사용해 런타임 타입 검사(RTTI)를 수행

FProperty* NameProp = UTeacher::StaticClass()->FindPropertyByName(TEXT("Name"));
if (NameProp)
{
	// FStrProperty인지 확인 (int, float 등 다른 타입일 경우 크래시 방지를 위해서)
	FStrProperty* StrProp = CastField<FStrProperty>(NameProp);
	if (StrProp)
	{
		StrProp->SetValue_InContainer(Teacher, &NewTeacherName);
	}
}

상속시 주의점 : generated.h

#include "Student.generated.h"
#include "Person.h" // generated.h 아래에 있으면 빌드 오류 발생

언리얼에서 다른 헤더를 상속 받을때 항상 generated.h파일이 가장 밑에 include 되도록 주의하자.
UHT가 Student.h와 같은 C++ 헤더를 파싱하여, 리플렉션 정보가 담긴 .generated.h를 만들기 때문에, 당연히 이 파일이 마지막에 있어야 GENERATED_BODY 매크로가 정상 작동한다.

GetValue_InContainer vs C++ 직접 접근

문제

리플렉션은 유연하지만 느리다. 매 프레임 호출되는 Tick같은 곳에서는 지양해야한다.
- FindPropertyByName검색은 당연히 직접 접근하는 Teacher->SetName()보다 느리다.

써야 한다면 캐싱해서 쓰자

BeginPlay에서 FindPropertyByName으로 FProperty*를 찾아 변수에 저장(캐싱)해두고
Tick에서는 저장된 포인터로 SetValue_InContainer만 수행

실습 코드 구조

Student와 Teacher는 Person을 상속받음

MyGameInstance.h

#pragma once
#include "CoreMinimal.h"
#include "Engine/GameInstance.h"
#include "MyGameInstance.generated.h"
UCLASS()
class OBJECTREFLECTION_API UMyGameInstance : public UGameInstance
{
	GENERATED_BODY()
public:
	UMyGameInstance(); // 생성자

	virtual void Init() override;

private:
	UPROPERTY() // 이래야 UE가 관리해줌(GC, 직렬화, 리플렉션 등)
	FString SchoolName;
};

MyGameInstance.cpp

#include "MyGameInstance.h" // 현재 언리얼 오브젝트 헤더가 가장 위에 있어야 함 (UHT 규칙)
#include "Student.h"
#include "Teacher.h"

UMyGameInstance::UMyGameInstance()
{
	SchoolName = TEXT("기본 학교"); // 이 기본값은 CDO 템플릿 객체에 저장
}

void UMyGameInstance::Init()
{
	Super::Init();

	// 언리얼 오브젝트 생성 - NewObject<T>()
	UStudent* Student = NewObject<UStudent>();
	UTeacher* Teacher = NewObject<UTeacher>();

	Student->SetName(TEXT("학생1"));
	UE_LOG(LogTemp, Log, TEXT("새로운 학생 이름 %s"), *Student->GetName());

	// reflection을 이용해 속성 접근/변경
	FString CurrentTeacherName;
	FString NewTeacherName(TEXT("새이름"));
	FProperty* NameProp = UTeacher::StaticClass()->FindPropertyByName(TEXT("Name"));
	if (NameProp)
	{
		NameProp->GetValue_InContainer(Teacher, &CurrentTeacherName);
		UE_LOG(LogTemp, Log, TEXT("현재 선생님 이름 %s"), *CurrentTeacherName);

		// FProperty API는 주소(void*)를 요구하며, 대상 객체 메모리에 값을 복사한다.
		// 단, FString은 내부적으로 버퍼 공유 + 참조 카운트 증가 방식이라 
		// 실제 문자열 데이터는 즉시 복제되지 않는다 (Copy-On-Write 발생 X → O(1), 발생 시 → O(n))
		NameProp->SetValue_InContainer(Teacher, &NewTeacherName);
		UE_LOG(LogTemp, Log, TEXT("현재 선생님 이름 %s"), *Teacher->GetName());
	}

	UE_LOG(LogTemp, Log, TEXT("===================="));

	// reflection을 이용해 함수 사용
	Student->DoLesson();

	UFunction* DoLessonFunc = Teacher->GetClass()->FindFunctionByName(TEXT("DoLesson"));
	if (DoLessonFunc)
	{
		Teacher->ProcessEvent(DoLessonFunc, nullptr); // 인자가 없는 함수라 null 전달
	}
}

Person.h

#pragma once
#include "CoreMinimal.h"
#include "UObject/Object.h"
#include "Person.generated.h"
UCLASS()
class OBJECTREFLECTION_API UPerson : public UObject
{
	GENERATED_BODY()
public:
	UPerson();

	UFUNCTION()
	virtual void DoLesson();

	const FString& GetName() const;
	void SetName(const FString& InName);

protected:
	UPROPERTY()
	FString Name;

	UPROPERTY()
	int32 Year;

private:
};

[Algorithm] Network Flow

Wed, 04 Feb 2026 00:00:00 GMT

조건

정점 u -> v 일때

간선의 용량 : c(u, v)
실제 흐르는 유량 : f(u, v)
전체 정점의 집합 : V

다음 3가지 속성을 만족해야한다.

1. 용량 제한 속성

f(u, v) <= c(u, v)
- 자명한 속성
- 그래프의 한 간선에서 흐르는 유량은 용량을 초과할 수 없다.

2. 유량의 대칭성

f(u, v) == -f(v, u)
- u -> v 로 양수의 유량을 보낸다는 것은, v -> u 로 음수의 유량을 보내는 것으로 간주
- 역방향 간선에 음의 유량이 흐르는 것으로 처리(잔여 그래프; Residual Graph생성)하여, 나중에 경로를 취소할 수 있음

3. 유량의 보존

∑f(in) == ∑f(out) (들어온 양 = 나간 양)
- 소스와 싱크를 제외한 모든 정점에는(파이프의 이음새)에는 물이 고일 수 없음

소스&싱크 개념

소스는 유량이 시작되는 정점이고, 싱크는 유량이 끝나는 정점이기 때문에, 이 두가지 정점에 한해서 유량의 보존 성질이 성립하지 않는다.

소스 (source) : 수원지
싱크 (sink) : 목적지

유량 그래프에서 소스 -> 싱크로 최대로 흐를 수 있는 유량을 구하는 문제를 네트워크 유량 문제라고 한다.

Ford-Fulkerson method

동작 원리

u -> v 로 보낼 수 있는 잔여 용량을 r(u, v)라고 할때
- r(u, v) == c(u, v) - f(u, v)
일단 임의의 경로로 용량을 흘려보내고
기존에 선택했던 경로를 취소하고, 새로운 경로로 더 개선된 답을 찾는다.

최대 유량 최소 컷 정리 (Max-Flow Min-Cut)

컷 (cut)

그래프를 두개의 조각으로 토막낸 것
유량 그래프에서의 컷은, 시작점인 소스와 종점인 싱크가 다른 집합에 속하도록 그래프를 쪼갠 것
- 소스가 있는 컷 : S
- 싱크가 포함된 컷 : T
S -> T 로 가는 간선들의 용량 합 : 컷 S, T의 용량
S -> T 로 가는 실제 유량 : 컷 S, T의 유량
- (중요) 컷의 유량은 역방향 간선의 -유량도 더해야 함

속성

컷의 유량은 소스 -> 싱크로 가는 총 유량과 같다.
컷의 유량은 컷의 용량(capacity)보다 크지 않다.

추론

(유량 보존) 임의의 컷을 통과하는 순 유량은 모두 동일하며, 이는 소스 -> 싱크로 흐르는 총 유량과 같다.
(컷 용량 제한) 컷을 통과하는 유량은 물리적으로 그 컷의 용량을 초과할 수 없다. 유량 <= 컷의 용량
(상한) 따라서 그래프의 모든 컷 중 가장 작은 용량을 가진 컷(최소 컷) 의 용량이 전체 유량의 한계치가 된다.
만약 현재 유량 == 컷의 용량이 되는 상태(모든 간선이 꽉 찬 컷)를 하나라도 발견하면, 그 이상 유량을 늘리는 것은 불가능하므로 이때가 최대 유량이다.
- 더 이상 증가 X -> 컷의 용량 포화

결론

최대 유량 == 최소 컷의 용량
즉, Max-Flow == Min-Cut 정리가 성립한다.

Edmonds-Karp Algorithm

이론

BFS로 시작점에서 가장 간선 개수가 적은 경로(최단 경로)부터 찾는다.
- 이러면 유량을 흘려보내는 횟수가 O(VE)로 제한된다.

알고리즘 흐름

아래의 과정을 경로가 없을 때까지 무한 반복한다.

1. 길 찾기 (BFS)

소스(S) -> 싱크(T) 로 가는 경로를 BFS로 탐색
- 이동 조건: 현재 유량 < 용량 인 간선만 이동 가능 (물이 꽉 차면 이동 X)
- 이때, parent배열로 경로 역추적 필요

2. 병목 지점 찾기 (Bottleneck)

싱크(T)에 도착했다면, parent배열을 타고 소스(S)까지 올라간다
이 경로상에 파이프 중 잔여 용량(Capacity - Flow)이 가장 작은 값을 찾는다.
잔여 용량(amount) 이 값이 이번 턴에 흘려보낼 수 있는 유량 (가장 좁은 파이프만큼만 물이 흐르므로)

3. 유량 흘리기 (Update & Reverse Edge)

다시 경로를 거슬러 올라가면서 유량 데이터를 갱신
정방향 : flow[u][v] += amount (물 채우기)
역방향 : flow[v][u] -= amount (반대 유량은 감소 -> 음수 유량)

예제

구조

#include <iostream>
#include <vector>
#include <queue>
#include <algorithm>
using namespace std;

const int INF = 0x3f3f3f3f;
const int MAX = 1000;

// c: Capacity 용량
// f: Flow 현재 유량
int c[MAX][MAX]; // cur -> nxt
int f[MAX][MAX]; // cur -> nxt
vector<int> adj[MAX];

// 최대 유량 구하기 S(source) -> T(sink; target)
int getMaxFlow(int source, int sink)
{
    int totalFlow = 0;
    while (true)
    {
        // 1. 길 찾기 (BFS)
        vector<int> parent(MAX, -1);
        queue<int> q;
        q.push(source); // 시작점
        parent[source] = source; // 방문 표시

        while (!q.empty())
        {
            int cur = q.front(); q.pop();
            for (int nxt : adj[cur])
            {
                if ((c[cur][nxt] - f[cur][nxt]) <= 0) continue; // 잔여 용량이 남지 않음
                if (parent[nxt] != -1) continue; // 이미 방문함

                q.push(nxt);
                parent[nxt] = cur; // cur -> nxt 경로 기록
                if (nxt == sink) break; // 싱크 도착
            }
        }

        // 2. 싱크에 도달 못함. 경로가 없음
        if (parent[sink] == -1) break;

        // 3. 병목 지점 찾기 (Bottleneck) - 가장 작은 파이프
        int amount = INF;
        for (int p = sink; p != source; p= parent[p])
        {
	        int prv = parent[p];
	        amount = min(amount, c[prv][p] - f[prv][p]);
        }

        // 경로 역추적
        for (int p = sink; p != source; p = parent[p])
        {
            int prv = parent[p];
            f[prv][p] += amount; // u->v 정방향
            f[p][prv] -= amount; // v->u 역방향
        }
        
        totalFlow += amount;
    }
    
    return totalFlow;
}

연습 문제 - BOJ 6086 최대 유량 구현

#include <iostream>
#include <vector>
#include <queue>
#include <algorithm>
using namespace std;

const int INF = 0x3f3f3f3f;

int c[150][150]; // capacity
int f[150][150]; // flow 0
vector<int> adj[150]; // 파이프 연결 list

int main()
{
    int n; cin >> n;
    for (int i = 0; i < n; i++)
    {
        char u, v;
        int w;
        cin >> u >> v >> w;
        
        // 양방향 그래프
        c[u][v] += w;
        c[v][u] += w;
        adj[u].push_back(v);
        adj[v].push_back(u);
    }

    int ans = 0;
    while (true)
    {
        // S(source) -> T(target; sink)
        int s = 'A';
        int t = 'Z';

        vector<int> p(150, -1); // BFS 기록용
        queue<int> q;
        q.push(s);
        p[s] = s; // 시작점 부모

        // BFS로 가능한 파이프 경로 찾기
        while (!q.empty())
        {
            int cur = q.front(); q.pop();
            for (int nxt : adj[cur])
            {
                if (p[nxt] != -1) continue; // 이미 방문
                if (c[cur][nxt] - f[cur][nxt] <= 0) continue; // 이미 다씀

                q.push(nxt);
                p[nxt] = cur; 
                if (nxt == t) break; // sink 도착
            }
        }

        // BFS로 sink에 도달 못함. (최대 유량임)
        if (p[t] == -1) break;

        // 거슬러 올라가면서 최소 찾기
        int amount = INF;
        for (int cur = t; cur != s; cur = p[cur])
            amount = min(amount, (c[p[cur]][cur] - f[p[cur]][cur]));
        for (int cur = t; cur != s; cur = p[cur])
        {
            f[p[cur]][cur] += amount; // 정방향 : 유량 늘림
            f[cur][p[cur]] -= amount; // 역방향 : 유량 줄임 (다시 빼는경우)
        }
        ans += amount;
    }

    cout << ans;
    return 0;
}

[UE5/UObject] 5. UObject Reflection 1

Wed, 04 Feb 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다. 옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

문서 내용 정리 -> 강의 요약 -> 실습 & 분석 -> 번외 순으로 정리되어 있습니다.
복습할때는 실습&분석 파트를 읽는걸 권장

강의 목표

언리얼 오브젝트의 특징과 리플렉션 시스템의 설명
언리얼 오브젝트의 처리 방식의 이해

(문서) Unreal Property System

링크 Reflection은 반사를 의미하는 그래픽 용어와 혼동되어 Unreal Property System이라고도 부른다.

Reflection은 프로그램이 실행시간에 자기 자신을 조사하는 기능
- but) C++은 지원하지 않아, 언리얼 자체적으로 구축되어 있음

include "FileName.generated.h"

UENUM(), UCLASS(), USTRUCT(), UFUNCTION(), UPROPERTY() 등의 매크로를 추가하면 언리얼 헤더 툴이 적절한 코드들을 자동으로 Intermediate 폴더 내부에 생성
모든 멤버 변수가 반드시 UPROPERTY() 로 설정될 필요는 없음
리플렉션된 프로퍼티가 아닌 것들은 UE시스템에서 관리를 받지 않음
- GC가 레퍼런스를 확인 못함 (위험)
- UPROPERTY() 붙이면 아넌
UHT는 실제 C++ 파서가 아님 (한계)
- 너무 족잡한 유형은 UHT이 읽어드리지 못함

프로퍼티 시스템의 계층 구조
- 추후 강의에서 자세히 다룸

UField
	UStruct - 기본적인 종합 구조체
		UClass (C++ class) - 자손으로 함수나 프로퍼티 포함 가능
		UScriptStruct (C++ struct) - 자손은 프로퍼티로만 제한
		UFunction (C++ function)   - 자손은 프로퍼티로만 제한
	UEnum (C++ enumeration)
	UProperty (C++ member variable or function parameter)
		(Many subclasses for different types)

이렇게 구축된 UnrealObject 클래스는 Static 클래스 함수나 Get 클래스 함수로 접근 가능

이 함수를 호출하면 이러한 Reflection, UHT이 분석해서 만들어 놓은 Reflection 정보들을 보관한 특정 객체에 접근 가능

for (TFieldIterator<UProperty> PropIt(GetClass()); PropIt; ++PropIt)
{
	UProperty* Property = *PropIt;
	// Do something with the property
}

UProperty라는 UnrealObject를 사용해서 순회하면, UnrealObject의 속성들을 우리가 조회하면서 거기에 대한 값이나 정보를 빼올 수 있다.

다음 강의 실습 예제로 확인

(이론 강의)

언리얼 오브젝트의 구성

언리얼 오브젝트에는 특별한 프로퍼티와 함수 지정 가능
- UPROPERTY : 클래스 멤버 변수
- UFUNCTION : 클래스 멤버 함수
모든 언리얼 오브젝트는 클래스 정보와 함께 함
- 모든 프로퍼티 & 함수 정보를 언제든 조회 가능
  - 컴파일 타임 : UMyGameInstance::StaticClass();
  - 런타임 : GetClass();
이런 기능을 제공하는 언리얼 오브젝트는 NewObject API를 사용해 생성해야 함.

언리얼 오브젝트 처리

Class Default Object; CDO

언리얼 클래스 정보에는 클래스 기본 오브젝트 CDO가 포함됨
CDO는 언리얼 객체가 가진 기본 값을 보관하는 템플릿 객체
가정) 한 클래스로부터 다수의 물체를 생성해 게임 콘텐츠에 배치하는 상황
- 일관성 있게 기본 값을 조정하는데 유영하게 사용
클래스 정보UClass -> GetDefaultObject() = CDO 추출 가능
UClass, CDO는 엔진 초기화 과정에서 생성
- 직접 디버그 걸어서 확인 가능 (엔진 로드 75%쯤에서 브레이크 걸림)

UClass()와 CDO가 어떻게 동작하는지 실습을 통해 알아보자

0. 실습용 코드 구조

헤더 구조는 그대로 가져가고, cpp는 실습에 맞춰 수정 MyGameInstance.h

#pragma once

#include "CoreMinimal.h"
#include "Engine/GameInstance.h"
#include "MyGameInstance.generated.h"

/**
 * 
 */
UCLASS()
class OBJECTREFLECTION_API UMyGameInstance : public UGameInstance
{
	GENERATED_BODY()
public:
	UMyGameInstance(); // 생성자

	virtual void Init() override;

private:
	UPROPERTY() // 이래야 UE가 관리해줌(GC, 직렬화, 리플렉션 등)
	FString SchoolName;
};

MyGameInstance.cpp

#include "MyGameInstance.h"

UMyGameInstance::UMyGameInstance()
{
	SchoolName = TEXT("기본 학교"); // 이 기본값은 CDO 템플릿 객체에 저장
}

void UMyGameInstance::Init()
{
	Super::Init();

	UE_LOG(LogTemp, Log, TEXT("===================="));
	UClass* ClassRuntime = GetClass();
	UClass* ClassCompile = UMyGameInstance::StaticClass();
	UE_LOG(LogTemp, Log, TEXT("학교를 담당하는 클래스 이름 : %s"), *ClassRuntime->GetName());

	SchoolName = TEXT("임의의 학교");
	UE_LOG(LogTemp, Log, TEXT("학교 이름 : %s"), *SchoolName);
	UE_LOG(LogTemp, Log, TEXT("학교 이름 기본값 : %s"), *GetClass()->GetDefaultObject<UMyGameInstance>()->SchoolName);

	UE_LOG(LogTemp, Log, TEXT("===================="));
}

1. 검증 코드 (Assertion 함수)

MyGameInstance.cpp

#include "MyGameInstance.h"
UMyGameInstance::UMyGameInstance()
{
}

void UMyGameInstance::Init()
{
	Super::Init();

	UE_LOG(LogTemp, Log, TEXT("===================="));
	UClass* ClassRuntime = GetClass();
	UClass* ClassCompile = UMyGameInstance::StaticClass();
	check(ClassRuntime == ClassCompile);

	UE_LOG(LogTemp, Log, TEXT("학교를 담당하는 클래스 이름 : %s"), *ClassRuntime->GetName());

	UE_LOG(LogTemp, Log, TEXT("===================="));
}

로그

LogTemp: ====================
LogTemp: 학교를 담당하는 클래스 이름 : MyGameInstance
LogTemp: ====================

정상적으로 check() Assertion 함수를 통과하고, 로그에 MyGameInstance가 찍히는걸 볼 수 있다.

1-1. check()

MyGameInstance.cpp

check(ClassRuntime != ClassCompile);

이번에는, check를 부정이 뜨도록 바꿔보자.

Unreal Crash Reporter

LoginId:ec4d00644b8bfc8993dcb989a922f693
EpicAccountId:4d1d3208fcc147eba2964ad944fd2b63

Assertion failed: ClassRuntime != ClassCompile [File:F:\UE5\UE5Part1\ObjectReflection\Source\ObjectReflection\MyGameInstance.cpp] [Line: 17]

컴파일 후, 언리얼을 실행해보면, 위와 같이 Crash Reporter가 뜨며 에디터가 다운된다.
- Assertion failed: ClassRuntime != ClassCompile에서 Assertion 실패

1-2. ensure()

MyGameInstance.cpp

ensure(ClassRuntime != ClassCompile);

Output Log ![[Pasted image 20260204093829.png]]

실행하면, 에디터는 돌아가나 로그에 빨간 에러가 잡힌다.

1-3. ensureMsgf()

MyGameInstance.cpp

ensureMsgf(ClassRuntime != ClassCompile, TEXT("에러 발생 !!!"));

Output Log ![[Pasted image 20260204094409.png]]

로그에, 우리가 입력한 TEXT도 함께 잡힌다.

정리

check()와 같은 함수를 계속 넣어주며 검증하기
- 실제 게임으로 빌드할때는 모두 사라지니 안심하고 사용하자

2. Class Default Object; CDO

정의

UE엔진은 모든 UClass타입에 대해 기본 객체 (Default Object)를 하나 자동으로 생성.
- 이 기본 객체를 Class Default Object; CDO라고 부른다.

역할

해당 클래스의 기본값(Default Propery Values)을 저장하는 템플릿 역할
새 인스터스를 만들 때, 이 CDO에 저장된 값들을 복사해서 초기화
블루프린트 에디터에서 Default Values 창에 보이는 값들이 사실상 CDO에 들어있는 값

특징

엔진이 자동으로 생성
- 개발자가 new로 만드는 게 아님.
StaticClass()->GetDefaultObject()로 접근 가능

실습

2-1. CDO를 덮어주는 값 출력

MyGameInstance.cpp

#include "MyGameInstance.h"

UMyGameInstance::UMyGameInstance()
{
	SchoolName = TEXT("기본 학교"); // 이 기본값은 CDO 템플릿 객체에 저장
}

void UMyGameInstance::Init()
{
	Super::Init();

	UE_LOG(LogTemp, Log, TEXT("===================="));
	UClass* ClassRuntime = GetClass();
	UClass* ClassCompile = UMyGameInstance::StaticClass();
	UE_LOG(LogTemp, Log, TEXT("학교를 담당하는 클래스 이름 : %s"), *ClassRuntime->GetName());

	SchoolName = TEXT("임의의 학교"); // 현재 인스턴스의 멤버 변수를 덮는다. (CDO로 설정된 초기값이 덮어짐)
	UE_LOG(LogTemp, Log, TEXT("학교 이름 : %s"), *SchoolName);

	UE_LOG(LogTemp, Log, TEXT("===================="));
}

위와 같이 SchoolName = TEXT()로 CDO에 저장된 값을 덮어씌우면, 정상적으로 변경된다.

LogTemp: ====================
LogTemp: 학교를 담당하는 클래스 이름 : MyGameInstance
LogTemp: 학교 이름 : 임의의 학교
LogTemp: ====================

2-2. CDO 기본값 출력

MyGameInstance.cpp

SchoolName = TEXT("임의의 학교");
UE_LOG(LogTemp, Log, TEXT("학교 이름 : %s"), *SchoolName);
UE_LOG(LogTemp, Log, TEXT("학교 이름 기본값 : %s"), *GetClass()->GetDefaultObject<UMyGameInstance>()->SchoolName);

이번에는, *GetClass()->GetDefaultObject<UMyGameInstance>()->SchoolName로 CDO 기본값을 출력해보자

LogTemp: ====================
LogTemp: 학교를 담당하는 클래스 이름 : MyGameInstance
LogTemp: 학교 이름 : 임의의 학교
LogTemp: 학교 이름 기본값 : 
LogTemp: ====================

위와 같이 기본값이 안나오는데...
Class Default Object를 고쳐주는 생성자 코드를 변경하는 경우에도 헤더 파일을 고치는 것과 똑같이 에디터를 꺼줘야한다.
- 헤더 파일의 리플렉션 정보에 구조를 변경
- 생성자 코드에서 CDO의 기본값을 변경

LogTemp: ====================
LogTemp: 학교를 담당하는 클래스 이름 : MyGameInstance
LogTemp: 학교 이름 : 임의의 학교
LogTemp: 학교 이름 기본값 : 기본 학교
LogTemp: ====================

에디터를 다시 실행하면 정상적으로 로그에 찍히는걸 볼 수 있다.

3. 정리

UObject <-> UClass 매칭

모든 UObject기반 클래스는 자신을 설명하는 UClass객체를 하나 가진다.
StaticClass()로 해당 클래스의 UClass객체에 접근이 가능하다.
UClass()aozmfhsms UHT가 해당 클래스를 리플렉션 시스테멩 등록하도록 표시한다.

UClass의 역할

UClass는 다음 2가지의 요소를 관리한다.

1. 클래스 메타데이터

클래스 이름, 함수 목록, 프로퍼티 목록 등
- 클래스 자체의 정보

2. CDO (Class Default Object)

기본값을 담은 템플릿 객체
- 인스턴스 생성 시 초기화 기준으로 사용
- UClass는 CDO의 포인터를 가지고 있어 런타임에 접근 가능

생성 및 반영

클래스 정보와 CDO는 엔진 초기화 과정에서 자동으로 생성되므로 안전하게 사용 가능
헤더 변경 or 생정자에서 CDO 기본값 수정시 -> 에디터 종료 후 다시 컴파일해야 정상 반영

4. 번외

UPROPERTY()

매크로 분석

// These macros wrap metadata parsed by the Unreal Header Tool, and are otherwise
// ignored when code containing them is compiled by the C++ compiler
#define UPROPERTY(...)
#define UFUNCTION(...)
#define USTRUCT(...)
#define UMETA(...)
#define UPARAM(...)
#define UENUM(...)
#define UDELEGATE(...)
#define RIGVM_METHOD(...)
#define VMODULE(...)

주석 부분
- 이 매크로들은 Unreal Header Tool (UHT)가 파싱하는 메타데이터를 감싸는 역할을 한다.
- C++ 컴파일러가 코드를 컴파일할 때는 무시된다.

즉, UPROPERTY()는 C++ 컴파일러 입장에서는 아무 의미 없는 빈 매크로이고, UHT가 소스 코드를 읽을 때만 의미를 가진다.

매크로 정의 부분
- #define UPROPERTY(...)라는 이름의 매크로를 정의했는데, 인자를 받아도 아무 코드로 치환되지 않는다.
- C++ 컴파일러가 볼 때는 그냥 '없음!' 으로 처리된다.

정리

UPROPERTY()는 C++ 컴파일러에는 무시되는 깡통 매크로
하지만, UHT (Unreal Header Tool)이 소스 코드를 파싱할 때는 중요한 메타데이터로 인식
- GC
- 직렬화
- 리플렉션
- 블루프린트 등에 필요한 정보를 생성
C++ 컴파일러는 위에서 생성된 .generated.h에 메타데이터 코드를 포함해서 컴파일

Assertion (어설션) 함수

정의

프로그램이 실행될 때 특정 조건이 참인지 검사하는 함수

목적

잘못된 상태가 발생했을 때 즉시 알려주어 디버깅을 쉽게하고, 치명적인 오류를 방지

종류

assert() 표준 C/C++
- <cassert헤더에 정의됨
- 조건이 거짓이면 프로그램을 강제 종료하고 오류 메시지를 출력
Unreal Engine의 check() / ensure()
- check() : 조건이 거짓이면 즉시 크래시 발생 (개발 중 치명적 오류 확인용)
- ensure() : 조건이 거짓이면 경고 메시지 출력 후 계속 실행 (비치명적 오류 확인용)

예시

void UMyGameInstance::Init()
{
    Super::Init();

    // 반드시 SchoolName이 비어있지 않아야 한다고 가정
    check(!SchoolName.IsEmpty()); // 조건이 거짓이면 크래시 발생

    // 혹은 덜 치명적인 경우
    ensure(!SchoolName.IsEmpty()); // 조건이 거짓이면 경고만 띄우고 실행은 계속
}

[UE5/UObject] 4. UObject DOCS

Tue, 03 Feb 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

이미 번외에서 다룬 내용이 많아 간략하게 넘어갑니다.

강의 목표

언리얼 오브젝트의 필요성
언리얼 오브젝트 선언 & 엔진 내부 컴파일 과정

언리얼 오브젝트

게임 프로그래밍의 특수성

사용자 : 쾌적한 경험을 위해 최대 성능을 뽑아내야 함
개발자 : 게임의 규모가 커질수록 개발 안정성이 중요함

모덴 객체 지향 설계 원칙

현재 시점에서 모던하다는 뜻은 아님. 추후 강의에서 더 자세히 다룰 예정

SOLID 원칙
후발 언어에서 보완한 새로운 기능
- 인터페이스 (Interface) : 객체 설계의 틀을 제공하는 추상 클래스
- 리플렉션 (Reflection) : 런타임에서 객체의 구조를 파악하고 객체에 메타데이터 부여
- 델리게이트 (Delegate) : 프로그램에서 발생한 이벤트를 다수의 객체에 효과적으로 전달하는데 활용

언리얼 엔진은?

기존 C++ 언어를 확장해 모던 객체 지향 설계를 가능하도록 만듬

일반 C++ 오브젝트는 : F
- 저수준의 빠른 처리
언리얼 오브젝트는 : U
- 콘텐츠 제작 관련 복잡한 설계 구현

언리얼 오브젝트 문서

언리얼 오브젝트

언리얼에는 게임 오브젝트 처리용 탄탄한 시스템이 있다.
언리얼에서 오브젝트의 베이스 클래스는 UObject
UCLASS 매크로를 사용하여 태그를 해주면 UObject 처리 시스템에서 인식

UCLASS 매크로

CDO -> 다음 강의에서 더 자세히 다룰 예정
UClass에는 클래스를 정의하는 프로퍼티와 함수 세트가 들어있다.

UObject에 제공되는 함수성

여러가지 매크로로 제공

언리얼 헤더 툴

UHT (Unreal Header Tool)

컴파일 과정에서 언리얼 오브젝트를 처리하기 위한 특수한 과정들이 들어감 헤더 파일 포맷
언리얼이 가지는 독특한...

오브젝트 업데이트 및 소멸

현재 단계에서는 자세히 X

언리얼 오브젝트가 가지는 특징

추후 강의에서 예제를 통해 살펴볼 예정

클래스 기본 객체 (CDO)
리플렉션
인터페이스
향상된 열거형
델리게이트
GC
향상된 구조체 (Struct)
직렬화 (Serialization)

실습

번외편에서 이미 다룬 분석 내용이므로, 간략하게 요약합니다.

UHT : 언리얼 헤더 툴이 실행됨
매크로들을 참조해서 언리얼 오브젝트에 관련된 generated.h 파일 같은걸 UHT이 자동으로 생성해줌
그걸 포함해서 완벽한 프로그램이 되는것

정리

게임이 대형화되면서 성능/유지보수 두가지가 모두 중요해짐
언리얼 엔진은 C++을 확장한 U오브젝트라는 객체 구조를 고안
지정된 매크로를 사용해 빌드를 수행하면, 추가 코드가 자동으로 만들어지는 구조
언리얼 오브젝트를 사용해 대규모 게임 제작을 안정적으로 설계 및 구현 가능

[UE5/UObject] 3. 기본타입과 문자열

Mon, 02 Feb 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

이번 노트는 언리얼 표준 컨벤션을 요약 정리한 내용입니다.

강의 목표

언리얼 환경에서 알아두어야 할 기본 타입과 고려할 점
캐릭터 인코딩 시스템에 대한 이해
언리얼 C++이 제공하는 다양한 문자열 처리 방법과 내부 구성의 이해

언리얼 C++ 기본 타입

int32

언리얼은 int를 사용하지 않고 int32를 사용함

float & double

국제 표준으로 4byte 8byte가 정의되어 있기때문에
float double 그대로 사용

bool

bool은 크기가 명확하지 않음
헤더에는 가급적 uint8 타입을 사용한다. but) 1byte는 너무 크다.
- 그래서 Bit Field 오퍼레이터를 사용 : uint8 bNetTemporary:1;
- 일반 uint8과의 구분을 위해 b접두사 사용
Cpp 로직에서는 자유롭게 bool 사용

언리얼 문자 인코딩

UE 내부 문자열 표현

FStrings : 내부적으로 TArray<TCHAR>을 사용해 문자열을 관리하는 클래스
TCHAR : 언리얼 표준 문자 타입
- Windows 기준으로 wchar_t와 매핑되어 UTF-16으로 저장
- 플랫폼에 따라 UTF-8로 매핑될 수도 있음
UTF-16 인코딩 : 윈도우 기준 2byte로 사이즈가 균일
TEXT() 매크로 : 문자열 리터럴을 항상 TCHAR배열로 변환
- TEXT("unreal") -> const TCHAR[] = {'u', 'n', 'r', 'e', 'a', 'l', '\0'}
- c언어 스타일로 \0이 붙음
FString : TChar 배열을 포함하는 헬퍼 클래스
- 문자열 생성, 비교, 변환 등 다양한 기능 제공
- 단순 포인터TCHAR*보다 안전하고 편리하게 문자열을 다룰 수 있음

UE에서 TEXT파일 로드 방식

UTF-16 으로 파일을 로드한다.
- UnMisc.cpp 에 구현된 appLoadFileToString() 함수로 처리
- 위 함수는 파일에 포함된 유니코드 BOM을 인식하여 문자열을 로드
- 만약, BOM이 없다면 플랫폼별 인코딩 규칙에 따라 해석
  - Windows라면 UTF-16
  - 다른 플랫폼은 UTF-8로 처리될 수 있음

UE에서 사용되는 TEXT 파일 추천 인코딩

INI/INT 파일
- 지역화(INI) 및 설정(INT) 파일은 UTF-16 인코딩을 권장
- Windows환경에 안정적, 다국어 지원에 적합
소스 코드 내 문자열 처리
- C++ 소스 코드 안에서 직접 문자열 하드코딩은 권장 X
- 문자열은 별도의 INT/INI 파일로 분리하는걸 권장
  - 지역화 & 유지보수에 유리
소스 코드에서 한글 사용 시 주의점
- 소스에 꼭 한글을 사용하겠다면, UTF-8 방식 저장 (권장x)

실습

1. TCHAR & TEXT() 매크로

TCHAR 배열은 C 스타일 문자열 포인터 const TCHAR* : %s 를 충족한다.
- 내부적으로 \0로 끝남
즉, *포인터 없이 TCHAR[] -> TCHAR*로 decay되므로 바로 전달 가능하다.

MyGameInstance.h

UCLASS()
class UNREALSTRING_API UMyGameInstance : public UGameInstance
{
	GENERATED_BODY()
public:
	virtual void Init() override;

private:
};

MyGameInstance.cpp

#include "MyGameInstance.h"

void UMyGameInstance::Init()
{
	Super::Init();

	TCHAR LogCharArray[] = TEXT("Hello Unreal");
	UE_LOG(LogTemp, Log, TEXT("%s"), LogCharArray);
}

Output Log

LogTemp: Hello Unreal

2. FString 클래스

FString : 언리얼 문자열 클래스
- 내부적으로 TArray<TCHAR>를 관리한다.
FString자체를 %s에 넘길 수 없다. %s는 객체가 아니라 포인터*를 요구하므로
FString은 operator*를 오버로드해서 내부 버퍼의 const TCHAR*를 반환하도록 되어있다.

MyGameInstance.cpp

#include "MyGameInstance.h"

void UMyGameInstance::Init()
{
	Super::Init();

	TCHAR LogCharArray[] = TEXT("Hello Unreal");
	UE_LOG(LogTemp, Log, TEXT("%s"), LogCharArray);

	FString LogCharString = LogCharArray;
	UE_LOG(LogTemp, Log, TEXT("%s"), *LogCharString); // 포인터 필요
}

Output Log

LogTemp: Hello Unreal

FString

![[Pasted image 20260201225015.png]]

FName

FName : 에셋 관리를 위해 사용되는 문자열 체계 (해시)
- 대소문자 구분 X
- 한선 선언되면 변경 X
- 가볍고 빠름
- 문자표현용 X, 에셋 키를 지정하는 용도. 빌드시 해시값으로 변환
FText : 다국어 지원을 위한 문자열 관리 체계
- 일종의 키로 작용함
- 별도의 문자열 테이블 정보가 추가로 요구됨
- 게임 빌드 시 자동으로 국가별 언어로 변환

구조

사진 첨부 필

정리

언리얼이 C++ 타입 Int를 사용하지 않는 이유
다양한 캐릭터 인코딩 시스템 이해
언리얼의 문자열 처리
FString의 구조와 사용 방법
FName의 구조와 사용 방법

[UE5/UObject] 언리얼 클래스 문법과 필수 매크로

Mon, 02 Feb 2026 00:00:00 GMT

강의 외적인 의문을 정리한 번외 파트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

UCLASS()
class UNREALSTRING_API UMyGameInstance : public UGameInstance
{
    GENERATED_BODY()
public:
    virtual void Init() override;
};

위와 같은 언리얼 C++을 처음 접하면 기존 C++과 다른 클래스 문법이 몇가지 보인다.

UCLASS()
UNREALSTRING_API
GENERATED_BODY()

1. 기존 C++ 클래스 문법

C++에서 클래스는 아래와 같이 선언한다.

class 클래스명 : 접근제한자 부모클래스명
{
    // 멤버 변수와 함수
};

예시

class MyClass : public BaseClass
{
    void Hello();
};

2. UCLASS() 매크로

2-1. UCLASS() 의미

UCLASS()

언리얼 엔진은 자체 오브젝트/리플렉션 시스템을 보유
UCLASS() 매크로는 해당 클래스가 리플렉션 시스템에 등록된다는 표시
- 블루프린트에서 사용 가능
- 직렬화(Serialization), 네트워킹, GC 등 엔진 기능과 연동
  - UHT가 생성하는 코드와 연결

2-2. generated.h와 UHT

UCLASS() 자체는 모든 기능을 담지 않고, UHT가 생성한 코드와 연결하는 hook 역할을 한다.

#include "MyGameInstance.generated.h" 는 UHT가 빌드 과정에서 자동 생성한 헤더
UCLASS() 매크로는 내부적으로 BODY_MACRO_COMBINE(...) 같은 토큰을 생성
- 실제 구현은 generated.h 안에서 확장

2-3. UCLASS() 매크로 확장 과정

UCLASS()를 추적해보면 아래와 같이 define 되어있는데

#define UCLASS(...) BODY_MACRO_COMBINE(CURRENT_FILE_ID,_,__LINE__,_PROLOG)

여기서 CURRENT_FILE_ID + __LINE__ 등이 합쳐져서 고유한 매크로 이름이 생성

#define BODY_MACRO_COMBINE_INNER(A,B,C,D) A##B##C##D
#define BODY_MACRO_COMBINE(A,B,C,D) BODY_MACRO_COMBINE_INNER(A,B,C,D)

예를 들어, MyGameInstance.generated.h 안에서는 다음과 같이 확장된다.

#define FID_UnrealString_Source_UnrealString_MyGameInstance_h_16_INCLASS_NO_PURE_DECLS \
private: \
	static void StaticRegisterNativesUMyGameInstance(); \
	friend struct ::Z_Construct_UClass_UMyGameInstance_Statics; \
	static UClass* GetPrivateStaticClass(); \
	friend UNREALSTRING_API UClass* ::Z_Construct_UClass_UMyGameInstance_NoRegister(); \
public: \
	DECLARE_CLASS2(UMyGameInstance, UGameInstance, COMPILED_IN_FLAGS(0 | CLASS_Transient), CASTCLASS_None, TEXT("/Script/UnrealString"), Z_Construct_UClass_UMyGameInstance_NoRegister) \
	DECLARE_SERIALIZER(UMyGameInstance)

FID_UnrealString_Source_UnrealString_MyGameInstance_h_16_INCLASS_NO_PURE_DECLS와 같이 combine 되어 있고, 이는 다시 헤더 내부에서 define되고 있다.

2-4. 라인 번호 변화에 따른 FID 매크로 이름 변화

_h_16_의 숫자는 클래스 선언이 위치한 소스 파일의 라인 번호를 뜻한다.

#define FID_UnrealString_Source_UnrealString_MyGameInstance_h_16_INCLASS_NO_PURE_DECLS

만약 클래스 선언 위에 엔터를 하나 더 쳐서 줄이 바뀌면, __LINE__값이 증가하여 다음과 같이 바뀐다.

#define FID_UnrealString_Source_UnrealString_MyGameInstance_h_17_INCLASS_NO_PURE_DECLS

3. UNREALSTRING_API 매크로

UNREALSTRING_API같은 매크로는 모듈 간 심볼 export import를 처리하기 위한 장치이다.

class UNREALSTRING_API UMyGameInstance : public UGameInstance

위 코드에 UNREALSTRING_API를 VS에서 추적해보면 아래와 같이 잡힌다.

// Windows (MSVC)
#define UNREALSTRING_API DLLEXPORT
// ->
#define DLLEXPORT __declspec(dllexport)

언리얼 프로젝트는 여러 모듈로 나뉘어 있고, 각 모듈은 DLL로 빌드된다.
다른 모듈에서 정의한 클래스를 사용하려면 export import 가 필요하다.
언리얼은 멀티 플랫폼을 지원하므로, XXXXX_API 매크로를 두고 환경에 맞게 아래와 같이 치환한다.
- MSVC : __declspec(dllexport) / __declspec(dllimport)
- GCC/Clang : __attribute__((visibility("default")))

4. GENERATED_BODY() 매크로

UCLASS()
class UNREALSTRING_API UMyGameInstance : public UGameInstance
{
    GENERATED_BODY()
};

GENERATED_BODY()는 엔진이 자동으로 필요한 내부 코드를 삽입하게 해주는 매크로
- 리플렉션, 직렬화, 블루프린트 지원 등..
클래스마다 고유한 함수/메타데이터를 생성하는 코드가 들어간다.
- StaticRegisterNativesUMyGameInstance()
- DECLARE_CLASS(...)
- DECLARE_SERIALIZER(...)

리플렉션

리플렉션(Reflection)은 프로그램이 자기 자신을 메타 데이터로 인식하고 다룰 수 있는 기능

언리얼에서는 리플렉션을 통해 다음이 가능하다.
- 블루프린트 노출
- 직렬화(저장/로드)
- 에디터에서 프로퍼티 수정
- 네트워킹/레플리케이션

5. 결론

언리얼 클래스 선언부는 아래와 같이 이해하면 된다

UCLASS()
class [모듈 매크로] [클래스명] : [접근제한자] [상속클래스명]
{
    GENERATED_BODY()
}

정리하면

UCLASS() : 언리얼 리플렉션 시스템 등록용 매크로
XXXXX_API : 모듈 간 심볼 export/import 처리용 매크로 (멀티 플랫폼 호환성)
GENERATED_BODY() : 엔진이 자동으로 필요한 내부 코드를 삽입하는 매크로

[UE5/UObject] 2. UE C++ 표준 Docs

Sun, 01 Feb 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

이번 노트는 언리얼 표준 컨벤션을 요약 정리한 내용입니다.

강의 목표

프로그래밍을 시작하기 전에 알아두어야 할 언리얼 C++ 코딩 표준 이해
언리얼 C++ 코딩 표준에서 주의할 점 확인

구글 & 언리얼 C++ 코딩 표준 URL

클래스 체계

public 구현을 먼저 선언한 후 클래스의 private 구현이 뒤따라야 한다.

명명 규칙

파스칼 케이싱 (Pascal Casing) 사용
U A S E b F 등의 접두어 활용
- UObject U
- AActor A
- Swidget S : Slate 라는 UI전용 클래스
- enum E
- bool b : 소문자 - ex: bPendingDestrction
그 외 대부분의 클래스는 접두사 F

포터블 C++ 코드 (ex: int)

int 및 부호 없는 int타입은 플랫폼에 따라 크기가 다를 수 있다.
주요 타입은 아래와 같이 크기를 표기해준다.
- TCHAR - character(문자) (TCHAR 크기 추정 금지)
- uint8 - unsigned byte(부호 없는 바이트) (1바이트)
- int8 - signed byte(부호 있는 바이트) (1바이트)
- uint16 - unsigned shorts(부호 없는 short) (2바이트)
- int16 - signed short(부호 있는 short) (2바이트)
- uint32 - unsigned int(부호 없는 int) (4바이트)
- int32 - signed int(부호 있는 int) (4바이트)
- uint64 - unsigned quad word(부호 없는 쿼드 단어) (8바이트)
- int64 - signed quad word(부호 있는 쿼드 단어) (8바이트)
- PTRINT - 포인터를 가질 수 있는 정수(PTRINT 크기 추정 금지)

Const 정확도

const 가능하면 붙여주기
그 외에 아래와 같은 경우에도 const 활용

1. 루프

TArray<FString> StringArray;
for (const FString& : StringArray)
{
    // 이 루프의 바디는 StringArray를 수정하지 않습니다.
}

2. 포인터 자체에 const

	// 데이터 수정은 가능하나, 포인터에 증감 연산자 사용은 불가함
    T* const Ptr = ...;
    
    // X 틀림
    T& const Ref = ...;

3. 데이터에 const

	// X [복사] 나쁜 예 - const 배열 반환 
    const TArray<FString> GetSomeArray();
    
    // [읽기] 좋은 예 - const 배열로의 레퍼런스 반환
    const TArray<FString>& GetSomeArray();
    
    // [읽기] 좋은 예- const 배열로의 포인터 반환
    const TArray<FString>* GetSomeArray();
    
    // X [나쁜 예 - const 배열로의 const 포인터 반환 (포인터/데이터 모두 const)
    const TArray<FString>* const GetSomeArray();

예시 포맷

규칙에 맞춰 코드를 작성하면, JavaDoc기반으로 자동 문서화 가능

정리

public 에서 private로 이어지는 클래스 체계 (Organization) 준수
명명 규칙
1. 파스칼 케이싱(Pascal Casing)
2. 소문자를 가급적 사용하지 말고, 공백 및 언더스코어 없음
3. 모든 클래스와 구조체에는 고유 접두사
코드의 명확성
1. 파라미터에 가급적 In Out 접두사
2. const 지시자 (directive) 적극적 활용
3. 레퍼런스를 통한 복사 방지
4. auto 키워드 가급적 자제
Find In Files 활용
헤더 파일 및 #include구문 의존성 최소화 시켜 주의 깊게 다루기

[UE5/UObject] 1. UE C++ 환경 설정

Sat, 31 Jan 2026 00:00:00 GMT

"이득우의 언리얼 프로그래밍 Part1 - 언리얼 C++의 이해" 학습 내용을 정리한 강의 노트입니다.
옵시디언에 정리한 마크다운 문서라 블로그 마크다운 양식에 일부 맞지 않을 수 있습니다.

강의 시작 전, 언리얼과 VS세팅에 관한 내용 정리입니다.

강의 목표

언리얼 C++ 프로그래밍을 위한 개발 환경 설정
앞으로 강의에 사용할 프로그래밍 환경 구성 학습

개발 환경 설정

Visual Studio 설정

Visual Studio
UE 5.7.2
- 디버깅을 위한 에디터 심볼 (현재는 필수 x)
- Rider가 VS보다 빠르다고 한다. (디버깅에는 VS가 유리)
Development Editor 좌측쯤을 우클릭해서 common으로 변경, 해당 부분 너비를 늘려준다.
언리얼 새 프로젝트 -> Blank -> 이름은 "HelloUnreal" 에 C++로 생성
C++ 매크로 자동 들여쓰기를 방지하기 위해 visualcommander와 ue4vstool 설치
- (언리얼4 기준. 필수 아닌듯)
- https://vlasovstudio.com/visual-commander/

언리얼 클래스 추가

tools -> add c++ class 로 클래스를 추가하자. 생성 후, VS로 가보면 Games/HelloUnreal에 MyGameInstance.cpp와 MyGameInstance.h가 생겨있다.

언리얼 Maps 끄기

게임을 시작할때 오픈월드 맵과 같은 연산은 아직 불필요하다.
아래와 같이 전부 Clear 해서 날려주자.

언리얼 Game Instance Class (싱글톤)

위 사진과 같이 Game Instance Class를 우리가 만든 MyGameInstance로 변경

언리얼 코드 컴파일 방법

헤더 파일에 변경이 발생 - 에디터를 끄고 비주얼 스튜디오에서 컴파일
소스 파일에만 변경이 발생 - 라이브 코딩으로 컴파일 (ctrl + alt + F11)

GameInstance 클래스

Init() 원형

헤더 선언

public 으로 virtual void Init() override
오버라이딩 해주자.

구현

먼저 Super 키워드를 반드시 사용해서 부모 클래스 로직을 실행한다.
그 후, UE_LOG() 로직 찍는다.
이때 TEXT() 매크로를 이용해야 한글과 같은 2byte 문자를 사용할때 문제가 안생긴다.

결과

아래와 같이 LogTemp: 에 로그가 찍힌걸 볼 수 있다.

정리

"Hello Unreal!" 로그를 출력하기까지의 과정은 다음과 같았다.

언리얼 엔진 설치 & 프로그래밍 환경 구축
언리얼 에디터 클래스 추가
언리얼 C++ 클래스 상속 & 오버라이딩
언리얼 엔진 문자열 처리 : TEXT() 매크로
GameInstance클래스 적용 & 로그 확인

2025년 회고

Wed, 07 Jan 2026 00:00:00 GMT

2025년을 보내며

미루고 미루던 블로그. 더 이상 방치하면 안 될 것 같아 2025년 회고록이라도 남겨본다. 올해는 하계부터 대외 활동과 프로젝트가 몰리면서, 1학기에 비해 2학기는 정말 빠르게 지나갔다.

1. 알고리즘 스터디 및 CS 공부

2025년은 CS 지식의 뿌리를 다시 단단히 하는 시기였다.

알고리즘 스터디와 백준 플래티넘

연초부터 알고리즘 & 자료구조 스터디에 참가했다. 실력이 뛰어난 분들을 많이 알게 되었는데, 마음속의 라이벌이자 롤모델로 삼을만한 분들을 만난 것이 가장 큰 수확이다.
(사실 지금 블로그의 Astro 템플릿도 스터디원분 덕분에 알게 된 것이다. 여러모로 정말 감사한 분이다.)

10월부터는 다른 활동 및 수업과 시간이 겹쳐 아쉽게도 하차하게 되었지만, 정말 유익한 시간이었다. 몇 개월이나 지치지 않고 함께 해준 스터디원분들과 스터디장님께 감사한 마음이다.

그 열정을 이어 2학기에는 교내에서 직접 알고리즘 스터디를 개설해 보기도 했다.

야심 차게 시작했으나, 참가율 저조와 나의 주말 수업 일정이 겹치는 악재로 사실상 흐지부지되었다. 운영이란 게 쉽지 않음을 느꼈던 경험.

백준 티어는 플래티넘을 달성했다.

티어 상승을 계기로 예전에 알던 몇몇 분들이 연락을 주시기도 했다.

대회 참가 기록과 아쉬움

여름 시즌에는 실력 점검 차원에서 몇몇 대회에 참가했다.

교내 알고리즘 대회: 문제 난이도는 전체적으로 평이했다(3차원 BFS 정도가 변별력 문제). 하지만 진행 방식이 좀 아쉬웠다. 2회차라 그런지 규칙 공지가 미흡했고, 제출 시간이 성적에 반영되는 줄 모르고 여유 있게 제출했다가 대상을 놓치고 2위(최우수상)에 머물렀다. 다음 대회는 변별력을 위해 난이도가 조금 더 상향되었으면 좋겠다.
삼성 SCPC: 1차 예선에서 1번, 3번 문제를 풀어 2솔브로 2차 진출에 성공했다. 하지만, 고질적인 밤샘 습관 때문에 2차 대회 날짜를 착각해 늦잠을 자버렸다. 문제 구경도 못 하고 불참이라니... 뼈아픈 실책이었지만, 학교에서 NYPC 성적과 합산해 장학금을 챙겨준 것으로 위안을 삼았다.
2025 넥슨 NYPC 대학생 코드배틀: 요트 게임 AI를 제작하는 대회였다. 게임 AI에 대한 도메인 지식이 부족해 성적 자체는 좋지 않았으나, 룰 기반이 아닌 AI 로직을 고민해 보는 과정에서 많은 공부가 되었다.

그 외에 읽은 책들

네트워크, 알고리즘, 리버싱, 운영체제등..

2. 개발 및 기술 연구 (토이 프로젝트)

AWS 인프라 비용

개인 토이 프로젝트로 '로즈몬티스' 캐릭터와 채팅이 가능한 웹사이트/디스코드 봇을 운영했었다. AWS EC2 기반으로 호스팅 중이었는데, 프리 티어가 만료되자 청구되는 비용이 학생 입장에서 꽤 부담스러웠다. 결국 눈물을 머금고 서버를 내렸다. 집에 있는 라즈베리파이로 마이그레이션해서 나중에 다시 살려낼 계획이다.

디코에서 다른사람들과 대화중에 편하게 쓸 수 있어서 꽤나 애용했었다. 명일방주 일퀘 자동화, 일정관리, 시간측정, 녹음, 마크서버관리 등.. 잡다한 기능을 통합해 놨었다.

게임 엔진과 그래픽스

C++ Asio 분석: 네트워크 프로그래밍의 기초를 복습하기 위해 C++ Asio 라이브러리의 공식 튜토리얼을 분석하며 비동기 I/O 모델을 학습했다.
Unreal Engine 5 리슨 서버 분석: 언리얼 5의 리슨(Listen) 서버를 기준으로 제공되는 API와 서버 구조를 뜯어보았다. GameMode, GameState, PlayerState 같은 핵심 클래스와 RPC(Remote Procedure Call)의 작동 원리 등을 분석하고, 이를 검증하기 위한 간단한 프로젝트를 제작하며 개념을 확립했다.
AI × Unity 클리커 토이 프로젝트: '나노바나나 AI'와 'Grok'을 활용해 세로 모드 클리커 게임을 만들어보았다. 원래 유니티 UI 계층 구조를 깔끔하게 설계하는 아키텍처 연습용 프로젝트였으나, 게임에 필요한 이미지 리소스들을 AI로 생성해 보면서 나노 바나나의 위력의 위력을 몸소 체감한 프로젝트였다.

귀의 움직임이 나오는게 특히나 신기했던 리소스

OpenGL & Shader Sandbox: 학교 발표 과제를 계기로 OpenGL과 C++ GUI 라이브러리인 glad를 활용한 샌드박스 프로젝트를 진행했다. 큐브를 렌더링하고 회전시키며 쉐이더 코드, 텍스처, 조명 색상 등을 런타임에 변경하는 툴을 만들었다. 엔진이 다 해주는 걸 직접 짜보니 공부가 많이 됐다.

빙글빙글~

3. 커리어 및 활동

올해는 다양한 활동 덕분에 경제적인 부분(등록금, 생활비)을 어느정도 해결하며, 공부에 집중할 수 있는 환경을 만들 수 있었다.

스타트업 근무 및 연구생

작년말부터 여름까지 작은 스타트업에서 유니티 클라이언트 개발로 근무했다. 2학기부터는 개인 프로젝트와 깊이 있는 공부에 더 시간을 쏟고 싶어 아쉽지만 퇴사했다. 퇴사 후, 교수님의 추천으로 2학기 동안은 학생 연구원 신분으로 소속되어 있었다.

영호남 대학 학술대회 (최우수상 & 리버스 엔지니어링상)

2박 3일 일정으로 참가해 프로젝트를 발표했다.

성과: 최우수상과 동료 평가상인 '리버스 엔지니어링상'을 동시 수상했다. 단순한 발표가 아니라, 포스트 디펜스 형식으로 다른 참가자들과 양방향으로 소통하며 내 프로젝트를 이해시키는 과정이 꽤 즐거웠다.
배운 점: PyPI 배포, AWS 및 Terraform 활용 등 인프라 지식이 확실히 늘었다.
에피소드: 팀명을 명일방주의 '로즈몬티스'에서 따와 '로즈마리'로 지었으나... 아무도 못 알아봤다. 우리 팀을 제외하면 전원 4학년이었는데, 2학년 팀으로서 유의미한 상금과 성과를 거둬 뿌듯했다.

생산성 도구와 자격증 (GenAI)

학교 생성형 AI 수업을 통해 NotebookLM, Replit 등 다양한 툴을 익혔고, 커리큘럼에 포함된 AWS Certified AI Practitioner 자격증까지 취득했다.

실무 툴 사용법도 익히고, 학교에서 자격증 취득 장학금도 챙겨주니 일석이조였다.

학업 성취와 장학금 해프닝

전공 변경과 복수전공으로 걱정이 많았으나, 다행히 과 수석을 차지하며 등록금 전액 면제를 받았다. 여기에 각종 대외 활동과 SW중심대학 마일리지까지 더해져 꽤 많은 장학금을 기대했는데...

학교 규정상 한 학기 최대 수혜 가능 마일리지는 2,500점이었고, 2학기에만 무려 3,120마일리지를 모아버린 나는 강제로 장학금이 삭감당하는(?) 웃지 못할 일을 겪었다. 결과적으로 급여, 각종 대회 상금, 그리고 (깎였지만) 넉넉한 장학금과 등록금 면제 덕분에 부모님 손을 빌리지 않고 한 해를 마무리했다. 덕분에 2026년에는 알바 걱정 없이 온전히 개발과 공부에만 몰입할 수 있는 시간을 벌어둔 것 같아 든든하다.

4. 코딩력 채우기

올해는 유독 비주얼 노벨 장르를 많이 즐겼다. <활협전>, <명말천리행>, <당신과 나의 존재불명>, <마법소녀의 마녀재판> 등... 스토리 게임들에 푹 빠져 지냈다. 특이한 점은 이런 스토리 게임의 OST를 들으면 묘하게 코딩 욕구가 솟구친다는 것이다. 벅차오르는 감정 때문인지, 몰입감 때문인지는 모르겠지만 개발 생산성에 긍정적인 도움이 된다고 믿고 있다. (단순한 자기합리화일지도 모르겠지만, 일단 나는 그렇다.)

가장 잔인하고 상냥한 복수. 릴리스는 존재하며 병을 구우면 병 구이가 된다.

5. 2026년 계획

26년에는 아래와 같은 분야에 관심을 가져볼 예정이다.

Unity NGO 프로젝트: 26년도부터 지인과 함께 유니티 NGO(Netcode for GameObjects)를 활용한 게임을 개발해 보려고 한다. 과거에 비해 유니티 네트워크 생태계가 어떻게 변했는지 직접 부딪혀보며 체험해볼 생각이다.
UE5 공부: 최근에 공개한 언리얼의 네트워크(서버) 관련 로드맵이 심상치않다. 지금이라도 언리얼을 공부해서 UE6즈음에 서버 코드를 분석이 가능한 기초 체력을 만들어 놔야 될거 같다.
AI 인식 변화: 2025년 2학기 GenAI수업을 통해 여러 노코드툴과 AI를 직접 접하고, 토이 프로젝트에 직접 사용해보면서 내 생각보다 AI의 발전이 매우 빠르다는걸 체감했다. 이후로는 AI툴을 적극적으로 사용하고 관련 정보를 놓치지 않도록 노력해 볼 것이다.

[TIL] ++i vs i++ 어셈블리 비교 메모

Wed, 03 Sep 2025 00:00:00 GMT

전위 증가 (++i) vs 후위 증가 (i++)

후위 증가는 임시 변수가 필요해 전위 증가보다 느리다고 하는데, 어셈블리 레벨에서 확인해보자.

환경: MSVC (Visual Studio) x64 C++ 컴파일러 기준

전위증가

mov         eax,dword ptr [b]                   ; eax = b
inc         eax                                 ; eax++
mov         dword ptr [b],eax                   ; b = eax
mov         eax,dword ptr [b]                   ; eax = b
mov         dword ptr [d],eax                   ; d = eax

후위증가

mov         eax,dword ptr [a]                   ; eax = a
mov         dword ptr [rbp+134h],eax            ; ! temp = a
mov         eax,dword ptr [a]                   ; eax = a
inc         eax                                 ; eax++
mov         dword ptr [a],eax                   ; a = eax
mov         eax,dword ptr [rbp+134h]            ; ! eax = temp
mov         dword ptr [c],eax                   ; c = eax

후위연산은 임시로 base pointer + 0x134 (+308byte) 떨어진 곳에 a를 저장(mov)
다시 불러오는(mov) 과정이 추가
결론적으로 mov연산이 2회 추가

코드 전문

	int a = 1;
00007FF650F8DF8C  mov         dword ptr [a],1  
	int b = 1;
00007FF650F8DF93  mov         dword ptr [b],1  

	a++;
00007FF650F8DF9A  mov         eax,dword ptr [a]  
00007FF650F8DF9D  inc         eax  
00007FF650F8DF9F  mov         dword ptr [a],eax  
	++b;
00007FF650F8DFA2  mov         eax,dword ptr [b]  
00007FF650F8DFA5  inc         eax  
00007FF650F8DFA7  mov         dword ptr [b],eax  

	int c = a++;   // 후위 증가
00007FF650F8DFAA  mov         eax,dword ptr [a]  
00007FF650F8DFAD  mov         dword ptr [rbp+134h],eax  
00007FF650F8DFB3  mov         eax,dword ptr [a]  
00007FF650F8DFB6  inc         eax  
00007FF650F8DFB8  mov         dword ptr [a],eax  
00007FF650F8DFBB  mov         eax,dword ptr [rbp+134h]  
00007FF650F8DFC1  mov         dword ptr [c],eax  
	int d = ++b;   // 전위 증가
00007FF650F8DFC4  mov         eax,dword ptr [b]  
00007FF650F8DFC7  inc         eax  
00007FF650F8DFC9  mov         dword ptr [b],eax  
00007FF650F8DFCC  mov         eax,dword ptr [b]  
00007FF650F8DFCF  mov         dword ptr [d],eax

Hepari's Blog

[PCG] 4. HISM 기반 3D 렌더링 및 은면 제거

1. Actor 스폰의 Draw Call 병목

2. HISM을 활용한 하드웨어 인스턴싱

3. 에디터 타임 메모리 관리 (ClearInstances)

4. 인접 타일 검사를 통한 은면 제거 (Culling)

5. 결과 시각화 및 다음 목표

[PCG] 3. 2D Grid 메모리 최적화 및 A* 기반 타일 맵 생성

1. 논리적 선(Vector)에서 물리적 면(Grid)로

2. 1차원 배열을 활용한 2D Grid 메모리 최적화

3. A* 길찾기를 이용한 복도 생성

4. A* 가중치를 이용한 우회 경로 (Soft Constraint)

5. 결과 시각화 및 다음 목표

[PCG] 2. 언리얼 엔진 이식 및 MST 기반 그래프 생성

1. 언리얼 C++ 메모리 및 난수 엔진 이식

2. OnConstruction과 DrawDebug를 활용한 데이터 시각화

3. BSP 통로의 한계 & 그래프 도입

4. Union-Find와 Kruskal 기반 MST 구현

5. 순환로 생성

6. 결과 시각화 및 다음 목표

[UE5] 0-1. 개발 환경 구축부터 네트워크 세션 기초 설계까지

1. 데디케이티드 서버 빌드 타겟과 로그 설정

2. 버전 관리 시스템 (Git) 환경 설정

3. GAS(Gameplay Ability System) 디버깅 환경

4. Enhanced Input: WASD 이동 로직 재구성

5. C++ 플레이어 캐릭터 클래스 설계

6. 언리얼 엔진 네트워크 모델 이해

서버-클라이언트 구조

Actor의 3가지 네트워크 역할 (Role)

7. 주요 프레임워크 클래스 설계

C++ 클래스 구현

8. 온라인 서브시스템 (OSS) 및 세션 구현

DefaultEngine.ini 설정

GameInstance를 활용한 세션 관리

9. 접속 테스트 및 검증

방법 1: 에디터 내 테스트 (PIE)

방법 2: 커맨드라인 데디서버 테스트

[PCG] 1. C++ 콘솔 기반 BSP 알고리즘 테스트

1. BSP 트리 구조체 설계

2. 결정론(Determinism) 보장과 난수 엔진 초기화 병목 해결

3. 생성 함수 분리 (결합도 줄이기)

4. 결과 시각화 및 다음 목표

생성 과정 gif

다수의 StaticMesh 컴포넌트 배치시의 부하 원인 (Draw Call)

1. 메모리 관점: 복사가 아닌 '참조' (Flyweight Pattern)

2. 렌더링 관점: 진짜 부하의 원인은 '드로우 콜(Draw Call)'

3. 최적화 기법: 하드웨어 인스턴싱 (Hardware Instancing)

4. C++ 생성자 코드와의 연관성

5. 심화: 하이폴리곤 메시 자체의 크기는 부하를 주지 않는가?

5-1. 버텍스 쉐이더(Vertex Shader) 연산

5-2. USkeletalMesh의 스키닝(Skinning) 비용

5-3. 쿼드 오버드로우(Quad Overdraw)와 마이크로 트라이앵글(Micro-triangle)

5-4. 언리얼 엔진의 해결책

6. 정리

6. Reference

[UE5/System] 언리얼 엔진 데이터 관리 및 시스템 구조

1. 직렬화 (Serialization)

1.1 직렬화와 언리얼의 방식

1.2 실습: 일반 C++ 구조체 직렬화

1.3 실습: UObject 직렬화 (2단계 방식)

2. 패키지(Package)와 에셋(Asset)

2.1 패키지와 에셋의 관계

2.2 오브젝트 패스와 에셋 로딩 전략

3. 모듈(Module)과 플러그인(Plugin)

3.1 C++ 프로젝트와 모듈

3.2 UBT (Unreal Build Tool)

요약 (System Architecture Flow)

[Algorithm] Permutation Cycle Decomposition

개념

예시

최소 교환 횟수 공식

예제

메인 로직

연습 문제 - BOJ 10451 순열 사이클

연습 문제 - BOJ 34078 벨과 와이즈의 가게 홍보

[UE5/Data] 12. UE GC & FGCObject

C++ 언어 메모리 관리의 문제점과 GC

GC 시스템

GC를 위한 객체 저장소

GC의 메모리 회수

3. 에디터 타임 메모리 관리 (`ClearInstances`)