DEV Community: Seongcheol Jeon

[⭐] Wise Saying

Seongcheol Jeon — Sat, 17 Jan 2026 10:54:49 +0000

남의 일에 관심 많고, 남의 시선에 흔들리고, 자신이 아닌 남을 살아가는 먼지 앉은 눈빛으로는 세상의 절박한 그 무엇에도 말을 걸 수가 없다.
우리가 자기를 들여다보지 않아서 우리 눈빛을 잃은 것처럼, 이 세상이 이토록 불안한 구조로 가는 것은 우리가 그토록 서로의 삶을 훼손했기 때문이다.
좋은 눈빛에 흔들렸으면 한다. 그것이 살아가는 것이다. 쉬지 않는 눈빛과 마주쳤으면 한다. 그것이 다행한 일이다.

"인간에게서 가장 놀라운 점이 무엇인가요?"

신이 대답했다.

돈 벌기 위해 건강 잃어버리는 것.
그리고는 건강 되찾기 위해 돈 잃는 것.

미래 염려하느라
현재 놓쳐버리는 것.
그리하여
현재도 미래도 살지 못하는 것.

[C++] const 키워드와 반복자

Seongcheol Jeon — Mon, 29 Dec 2025 17:16:03 +0000

vector::iterator
vector::const_iterator
const vector::iterator
const vector::const_iterator

위의 반복자들을 비교 설명한다.

#include <iostream>
#include <vector>

using namespace std;


int main()
{
    vector<int> v;

    int arr[5] = { 10, 20, 30, 40, 50 };

    v.push_back(10);
    v.push_back(20);
    v.push_back(30);
    v.push_back(40);
    v.push_back(50);

    vector<int>::iterator iter = v.begin();
    // iter는 p처럼 동작
    int* p = arr;
    cout << *iter << ", " << *p << endl; 

    vector<int>::const_iterator citer = v.begin();
    // citer는 cp처럼 동작
    const int* cp = arr;
    cout << *citer << ", " << *cp << endl; 

    const vector<int>::iterator iter_const = v.begin();
    // iter_const는 p_const처럼 동작
    int* const p_const = arr;
    cout << *iter_const << ", " << *p_const << endl; 

    const vector<int>::const_iterator citer_const = v.begin();
    // citer_const는 cp_const처럼 동작
    const int* const cp_const = arr; 
    cout << *citer_const << ", " << *cp_const << endl;  

    return 0;
}

vector::iterator iter;
- iter는 다음 원소로 이동 가능하고 원소의 변경이 가능한 반복자이다.
vector::const_iterator citer;
- citer는 다음 원소로 이동 가능하고 원소의 변경이 불가능한 반복자이다.
const vector::iterator iter_const;
- iter_const는 다음 원소로 이동이 불가능하고 원소의 변경이 가능한 반복자이다.
const vector::const_iterator citer_const;
- citer_const는 다음 원소로 이동이 불가능하며 원소의 변경이 불가능한 반복자이다.

포인터와 연결해 보면, 어렵지 않게 이해할 수 있다. 사실 iterator와 const_iterator만을 주로 사용하므로 이 두 반복자만 알고 있어도 된다.

[C++] std::forward

Seongcheol Jeon — Tue, 28 Oct 2025 05:35:41 +0000

forward는 <utility> 헤더에 정의되어 있다.

template <class T>
constexpr T&& forward(std::remove_reference_t<T>& t) noexcept; // (1)

template <class T>
constexpr T&& forward(std::remove_reference_t<T>&& t) noexcept; // (2)

(1) 오버로딩의 경우, lvalue를 T에 따라 lvalue 혹은 rvalue로 전달한다.

[UE] Render Dependency Graph (RDG)

Seongcheol Jeon — Fri, 24 Oct 2025 05:13:34 +0000

RDG를 더욱 이해할 수 있도록 UnrealEngine 문서를 Clone 및 정리하여 작성하는 글이다.

렌더 종속성 그래프 (Render Denpendency Graph, RDG)

RDG란, 렌더 명령을 컴파일하고 실행할 수 있도록 그래프 데이터 구조체로 기록하는 즉시 모드 API.

렌더 그래프 또는 RDG라고도 하는 렌더 종속성 그래프(Render Dependency Graph)는 렌더 명령을 컴파일하고 실행할 수 있도록 그래프 데이터 구조체로 기록하는 즉시 모드 어플리케이션 프로그래밍 인터페이스(API)이다.
RDG는 오류에 취약한 연산을 자동화하여 고수준 렌더링 코드를 단순화하며, 그래프를 탐색해 메모리 사용을 최적화하고 CPU와 GPU의 렌더 패스를 *병렬화한다.

RDG의 대표적인 기능은 아래와 같다.

비동기 컴퓨트 펜스 예약
최적의 수명과 메모리 Aliasing을 통한 일시적 리소스 할당
분할 베리어를 사용한 서브리소스 전환으로 레이턴시를 숨기고 GPU 오버랩 향상
병렬 명령 목록 기록
그래프의 미사용 리소스 및 패스 컬링
API 사용 및 리소스 의존성 유효성 검사
RDG 인사이트에서 그래프 구조체 및 메모리 수명 시각화

렌더 그래프 API는 Deffered 렌더러와 모바일 렌더러 및 관련 플러그인에 맞춰 전화되었다. 특히 위에서 설명한 고급 기능이 필요한 경우, 모든 고수준 렌더링 코드는 RDG로 작성해야 한다.

셰이더 파라미터 구조체

RDG는 셰이더 파라미터 구조체 시스템을 향한 익스텐션을 통해 그래프 의존성을 표현한다.

HLSL 소스 파일의 셰이더 입력:

float2 ViewportSize;
float4 Hello;
float World;
float3 FooBarArray[16];

Texture2D BlueNoiseTexture;
SamplerState BlueNoiseSampler;

Texture2D SceneColorTexture;
SamplerState SceneColorSampler;

RWTexture2D<float4> SceneColorOutput;

이 셰이더 파라미터는 플랫 C++ 데이터 구조체로도 표현할 수 있다.

이상적인 C++ 버전:

struct FMyShaderParameters
{
    FVector2D ViewportSize;
    FVector4 Hello;
    float World;
    FVector FooBarArray[16];

    FRHITexture* BlueNoiseTexture = nullptr;
    FRHISamplerState* BlueNoiseSampler = nullptr;

    FRHITexture* SceneColorTexture = nullptr;
    FRFISamplerState* SceneColorSampler = nullptr;

    FRHIUnorderedAccessView* SceneColorOutput = nullptr;
};

셰이더 파라미터 구조체는 이를 위해 일련의 선언 매크로를 사용한다.

셰이더 파라미터 구조체:

BEGIN_SHADER_PARAMETER_STRUCT(FMyShaderParameters, /* MODULE_API_TAG */)
    SHADER_PARAMETER(FVector2D, ViewportSize)
    SHADER_PARAMETER(FVector4, Hello)
    SHADER_PARAMETER(float, World)
    SHADER_PARAMETER_ARRAY(FVector, FooBarArray, [16])

    SHADER_PARAMETER_TEXTURE(Texture2D, BlueNoiseTexture)
    SHADER_PARAMETER_SAMPLER(SamplerState, BlueNoiseSampler)

    SHADER_PARAMETER_TEXTURE(Texture2D, SceneColorTexture)
    SHADER_PARAMETER_SAMPLER(SamplerState, SceneColorSampler)

    SHADER_PARAMETER_TEXTURE(RWTexture2D, SceneColorOutput)
END_SHADER_PARAMETER_STRUCT()

이러한 매크로는 동일한 플랫 C++ 데이터 구조체와 컴파일 시간 반영 메타데이터를 생성한다. 이 데이터는 구조체의 스태틱 멤버로 액세스 가능하다.

컴파일 시간 반영 데타데이터:

const FShaderParametersMetadata* ParameterMetadata = FMyShaderParameters::FTypeInfo::GetStructMetadata();

이 메타데이터는 파라미터를 RHI에 다이내믹하게 바인딩하는 데 필요한 구조체의 런타임 트래버셜을 활성화한다. 각 멤버에 대해 확인할 수 있는 정보에는 Name, C++ type, HLSL type, Byte Offset 등이 있다.
RDG는 이 메타데이터를 사용해 패스 파라미터를 탐색한다.

Shader Binding

각 셰이더 파라미터 구조체는 FShader와 짝을 이루어 RHI 명령 목록을 제출하는데 필요한 바인딩을 생성한다.

바인딩을 생성하려면 FShader 파생 클래스에 FParameters 유형으로 파라미터 구조체를 선언한다.

이 작업은 inline으로 정의하거나 typedef 디렉티브를 사용하여 수행할 수 있다. 그 다음, SHADER_USE_PARAMETER_STRUCT 매크로를 사용해 바인딩을 등록할 클래스의 생성자를 만든다.

First Shader Class

class FMyShaderCS : public FGlobalShader
{
    DECLARE_GLOBAL_SHADER(FMyShaderCS);

    // 이 FShader 인스턴스와 함께 FParameter 바인딩을 등록할 생성자를 만든다.
    SHADER_USE_PARAMETER_STRUCT(FMyShaderCS, FGlobalShader);

    // 인라인 정의나 디렉티브로 셰이더에 FParameters 유형을 할당한다.
    using FParameters = FMyShaderParameters;
};

RHI 명령 목록에 셰이더 파라미터를 바인딩하려면 구조체를 인스턴스화하고 데이터를 채운 다음 SetShaderParameters 유틸리티 함수를 호출한다.

파라미터 할당하기:

TShaderMapRef<FMyShaderCS> ComputeShader(View.ShaderMap);
RHICmdList.SetComputeShader(ComputeShader.GetComputeShader());

FMyShaderCS::FParameters ShaderParameters;

// 파라미터 할당
ShaderParameters.ViewportSize = View.ViewRect.Size();
ShaderParameters.World = 1.0f;
ShaderParameters.FooBarArray[4] = FVector(1.0f, 0.5f, 0.5f);

// 파라미터 제출
SetShaderParameters(RHICmdList, ComputeShader, ComputeShader.GetComputeShader(), ShaderParameters);

RHICmdList.DispatchComputeShader(GroupCount.X, GroupCount.Y, GroupCount.Z);

Uniform Buffers

유니폼 버퍼(Uniform Buffers)는 파라미터를 RHI 리소스로 그룹화한다. 이 리소스는 그 자체로 셰이더 파라미터로서 바인딩된다. 각 유니폼 버퍼는 HLSL에서 글로벌 네임스페이스를 정의한다.
유니폼 버퍼는 BEGIN_UNIFORM_BUFFER_STRUCT 및 END_UNIFORM_BUFFER_STRUCT 매크로를 사용해 선언한다.

유니폼 버퍼 정의하기:

BEGIN_UNIFORM_BUFFER_STRUCT(FSceneTextureUniformParameters, RENDERER_API)
    SHADER_PARAMETER_TEXTURE(Texture2D, SceneColorTexture)
    SHADER_PARAMETER_TEXTURE(SamplerState, SceneColorTextureSampler)
    SHADER_PARAMETER_TEXTURE(Texture2D, SceneDepthTexture)
    SHADER_PARAMETER_TEXTURE(SamplerState, SceneDepthTextureSampler)

    // ...
END_UNIFORM_BUFFER_STRUCT()

C++ 소스 파일에서 IMPLEMENT_UNIFORM_BUFFER_STRUCT를 사용해 셰이더 시스템으로 유니폼 버퍼 정의를 등록하고 HLSL 정의를 생성한다.

유니폼 버퍼 구현하기:

IMPLEMENT_UNIFORM_BUFFER_STRUCT(FSceneTextureUniformParameters, "SceneTextureStruct")

유니폼 버퍼 파라미터는 컴파일된 셰이더에 의해 자동으로 생성되며, UniformBuffer.Member 구문으로 액세스할 수 있다.

HLSL의 유니폼 버퍼:

// 유니폼 버퍼 선언을 포함한 파일 생성. Common.ush에 의해 자동으로 포함됨.
#include "/Engine/Generated/GeneratedUniformBuffers.ush"

// 유니폼 버퍼 멤버를 구조체처럼 참조한다.
Texture2DSample(SceneTexturesStruct.SceneColorTexture, SceneTexturesStruct.SceneColorTextureSampler);

이제 SHADER_PARAMETER_STRUCT_REF 매크로를 사용해 부모 셰이더 파라미터 구조체에서 유니폼 버퍼를 파라미터로 포함시킬 수 있다.

SHADER_PARAMETER_STRUCT_REF

BEGIN_SHADER_PARAMETER_STRUCT(FParameters,)
    // ...

    // 레퍼런스 카운트된 TUniformBufferRef<FSceneTexturesUniformParameters> 인스턴스를 정의한다.
    SHADER_PARAMETER_STRUCT_REF(FSceneTextureUniformParameters, SceneTextures)
END_SHADER_PARAMETER_STRUCT()

Static Bindings

셰이더 파라미터는 각 셰이더에 고유하게 바인딩된다. vertex, pixel 등의 각 셰이더 단계에는 별도의 셰이더가 필요하다. 셰이더는 RHI 명령 목록에서 Set{Graphics, Compute}PipelineState를 사용해 Pipeline State Object (PSO)로 함께 바인딩된다.

명령 목록에서 파이프라인 스테이트를 바인딩하면, 모든 셰이더 바인딩이 무효화된다.

PSO를 설정한 다음에 모든 셰이더 파라미터를 바인딩해야 한다. 예를 들어 PSO를 공유하는 일반적인 DrawCall의 명령 흐름을 살펴보자.

PSO A 설정
각 DrawCall에 대해 아래 작업 수행
- vertex shader parameter 설정
- pixel shader parameter 설정
- draw
PSO B 설정
각 DrawCall에 대해 아래 작업 수행
- vertex shader parameter 설정
- pixel shader parameter 설정
- draw

이 접근법의 문제는 렌더러의 mesh draw 명령이 여러 pass와 view 간에 cache가 공유된다는 점이다.
frame마다 각 pass/view 조합별로 각기 다른 draw 명령 세트를 생성해야 한다면, 매우 비효율적일 것이다. 하지만 mesh draw 명령은 pass/view uniform buffer 리소스를 알아야 올바르게 binding을 수행할 수 있다. 이 문제를 해결하기 위해 uniform buffer에는 static binding model이 사용된다.

static binding으로 선언한 uniform buffer는 개별 셰이더의 고유 슬롯이 아니라 RHI 명령 목록과 직접 연결된 static slot에 바인딩된다. 셰이더가 uniform buffer를 요청하면 명령 목록은 static slot에서 직접 바인딩을 가져온다. 이렇게 하면 바인딩이 PSO 빈도가 아닌 pass 빈도로 이루어진다.

아래는 위의 예시와 동일하지만 셰이더 입력을 static uniform buffer에서 가져온다는 차이가 있다.

static uniform buffer 설정
PSO A 설정
각 draw call에 대해 아래 작업 수행
- draw
PSO B 설정
각 draw call에 대해 아래 작업 수행
- draw

이 모델을 사용하면 각 draw call이 명령 목록에서 셰이더 바인딩을 상속할 수 있다.

Static Uniform Buffers 정의하기

static binding으로 uniform buffer를 정의하려면,
IMPLEMENT_STATIC_UNIFORM_BUFFER_STRUCT 매크로를 사용한다. 추가 슬롯을 선언해야 한다. 이는 IMPLEMENT_STATIC_UNIFORM_BUFFER_SLOT 매크로에 지정된다.

여러 static uniform buffer 정의가 동일한 static slot을 참조할 수 있지만, binding할 수 있는 정의는 한 번에 하나뿐이다. 가급적 엔진 내 총 슬롯 수를 줄일 수 있도록 슬롯을 재사용하는 것이 좋다.

Static Uniform Buffers:

// 이름으로 unique static slot을 정의한다.
IMPLEMENT_STATIC_UNIFORM_BUFFER_SLOT(SceneTextures);

// SceneTextures slot에 static 바인딩하여 SceneTexturesStruct uniform buffer를 정의한다.
IMPLEMENT_STATIC_UNIFORM_BUFFER_STRUCT(FSceneTextureUniformParameters, "SceneTexturesStruct", SceneTextures);

// 동일한 static slot으로 MobileSceneTextures uniform buffer를 정의한다.
IMPLEMENT_STATIC_UNIFORM_BUFFER_STRUCT(FMobileSceneTextureUniformParameters, "MobileSceneTexturesStruct", SceneTextures);

RHICmdList.SetStaticUniformBuffers 메서드를 사용해 static uniform buffer를 binding한다. RDG는 각 pass를 실행하기 전에 자동으로 static uniform buffer를 명령 목록에 binding한다. 모든 static uniform buffer는 pass parameter struct에 포함되어야 한다.

Render Graph Builder

렌더 종속성 그래프는 간단히 사용할 수 있도록 설계되었다.

FRDGBuilder 인스턴스를 인스턴스화하고, 리소스를 생성하며, 패스를 추가해 그래프를 구성한다. 그 다음 FRDGBuilder::Execute를 호출해 그래프를 컴파일하고 실행한다.
FRDGBuilder::CreateTexture로 텍스처를 생성하거나 FRDGBuilder::CreateBuffer로 버퍼를 만든다.
- 이러한 메서드에서는 디스크립터만 할당된다. 기반 RHI 리소스는 나중에 실행 과정에서 할당된다.
FRDGBuilder::AddPass 함수를 사용해 패스를 추가하여 Pass 파라미터 구조체와 실행 lambda를 argument로 지정한다.
- Pass 파라미터 구조체는 RDG 리소스를 포함한 파라미터로 셰이더 파라미터 구조체를 확장한다.
- RDG는 이러한 파라미터를 사용해 그래프의 패스와 일시적 리소스 수명 사이의 종속성을 찾아낸다.
- GraphBuilder::AllocParameters로 패스 파라미터를 할당하고 실행 람다에 사용된 모든 관련 RDG 리소스를 지정한다.
패스 실행 람다는 그래프 실행 중 작업을 기록해 RHI 명령 목록에 제출한다.
- Compute Pass(비동기 및 그래픽 컴퓨트 사이의 공유 인터페이스)에 FRHIComputeCommandList를 사용하거나 레스터 패스에 FRHICommandList를 사용한다.
- FRHICommandListImmediate를 사용하면 패스를 병렬 실행할 수 없으므로 이 방법은 반드시 필요한 경우가 아니면 사용하지 않는 것이 좋다.
- 모든 패스 람다가 Thread Safe인 것이 이성적이지만, 실제로는 실행 중 일부 패스의 RHI 리소스를 RenderThread에서 생성하거나 잠가야 한다. 이 경우 즉각 명령 목록(FRHICommandListImmediate)을 사용해야한다.

아래의 예시를 참고하자.

Graph Builder:

{
    FRDGBuilder GraphBuilder(RHICmdList);

    FMyShaderCS::FParameters* PassParameters = GraphBuilder.AllocParameters<FMyShaderCS::FParameters>();
    ...
    PassParameters->SceneColorTexture = SceneColor;
    PassParameters->SceneColorSampler = TStaticSamplerState<SF_Point, AM_Clamp, AM_Clamp>::GetRHI();
    PassParameters->SceneColorOutput = GraphBuilder.CreateUAV(NewSceneColor);

    GraphBuilder.AddPass(
        // printf 시멘틱을 사용해 프로파일러의 패스에 친근한 이름을 지정합니다.
        RDG_EVENT_NAME("MyShader %d%d", View.ViewRect.Width(), View.ViewRect.Height()),
        // RDG에 파라미터 구조체를 전달합니다.
        PassParameters,
        // 컴퓨트 명령이 발생한다.
        ERDGPassFlags::Compute,
        // 실행 시까지 연기된다. 다른 패스와 병렬 실행될 수 있다.
        [PassParameters, ComputeShader, GroupCount](FRHIComputeCommandList& RHICmdList) -> void
        {
            FComputeShaderUtils::Dispatch(RHICmdList, ComputeShader, PassParameters, GroupCount);
        }
    );

    // 그래프를 실행한다.
    GraphBuilder.Execute();
}

그래프 빌더 API는 단일 스레드 방식이며, 한 번에 하나의 인스턴스만 인스턴스화 가능하다. 계층 그래프나 side-by-side 그래프는 제외된다. Deffered Renderer와 Mobile Renderer는 모두 각 씬 렌더 발동에 단일 빌더 인스턴스를 사용한다.

Setup and Execute Timelines

RDG는 렌더 파이프라인을 두 가지 타임라인으로 나눈다. 구성 및 실행 이다.

그래프는 구성 타임라인에서 빌드된다. 여기서 리소스 생성과 렌더 파이프라인 환경설정 분기가 이루어진다. 모든 RHI 명령은 Pass Lambda로 연기되고, Lambda는 실행 타임라인에서 호출된다.

Pass 실행이 병렬화될 수 있으므로 Pass Lambda에서 지정된 코드는 부작용이 없어야 하며, 명령을 명령 목록에 기록하기만 해야 한다.

RDG가 없는 경우에는 렌더링 기능이 하나의 타임라인에 작성된다. 이 타임라인에서 구성과 실행이 모두 이루어진다. RHI 명령은 파이프라인 분기 및 리소스 할당에 따라 직접 기록되고 제출된다.

RDG가 있으면 사용자 제공 패스 실행 람다를 통해 구성 코드가 실행과 분리된다.
RDG는 패스 실행 람다를 호출하기 전에 추가 컴파일 단계를 수행한다. 실행은 여러 스레드에 걸쳐 수행되며, 람다를 호출해 렌더 명령을 RHI 명령 목록에 기록한다.

RDG Utilities Functions

RDG Resources and Views

[UE] GameMode, GameState, Player State, Player Controller, Pawn

Seongcheol Jeon — Tue, 14 Oct 2025 07:09:41 +0000

GameMode, GameState, PlayerState, PlayerController, Pawn

Game Mode	Game State	Player State	Player Controller
Server Only	Server & All Clients	Server & All Clients	Server & Owning Client
Default Classes Pawn Player Controller HUD Rules Player Eliminated Respawning Players Match State Warmup Time Match Time	State of the Game Top Scoring Players Teams in the Lead Team Scores Array of Player States	State of the Player SCore Defeats Carried Ammo Team Slower Net Update(Player State에서는 Net Update 속도가 느리다)	Access to the HUD Display Messages Update HUD Health Update HUD Score Update HUD Defeats Update HUD Ammo

Pawn	HUD/Widget
Server & All Clients	Owning Client Only

Game Mode는 Server만 가지고 있다. Client가 Game Mode에 접근하면 nullptr을 반환한다.

반면, Game State는 Server와 Client 모두 가지고 있다. Server의 정보가 Replicated되어 Game State에 내려오고 이를 통해 Client에 정보가 전달된다.

GameMode, GameState, GameInstance 비교


GameMode	게임 규칙 정의 `Server` 측에서만 존재하며, `Client` 측에서는 `복제(Replicated)`되지 않는다.
GameState	`GameMode`가 정의한 규칙에 따라 게임의 현재 상태를 추적. `GameState`는 모든 `Client`에 `복제(Replicated)`된다.
GameInstance	게임 실행

[UE] Subsystem

Seongcheol Jeon — Tue, 14 Oct 2025 05:14:18 +0000

Subsystem
- Subsystem 종류
- Subsystem을 사용하는 이유
- UEditorSubsystem
- UGameInstanceSubsystem을 상속받는 클래스의 생명주기 (Life Time)
Game Instance vs Game Instance Subsystem

Subsystem

Subsystem 종류

UEngineSubsystem
UEditorSubsystem
UGameInstanceSubsystem
ULocalPlayerSubsystem
UWorldSubsystem

Subsystem 타입		Life Time
Engine	UEngineSubsystem	Editor, In-Game 시작 Engine Subsystem의 Module 로드 -> Module의 Startup() 함수 반환 -> Initialize() 호출 끝 Module의 Shutdown() 함수 변환 -> DeInitialize() 호출
Editor	UEditorSubsystem	Editor 시작 시 시작 Editor Subsystem의 Module이 로드 -> Module의 Startup() 함수 변환 -> Initialize() 호출 끝 Module의 Shutdown() 함수 변환 -> DeInitialize()를 호출:
Game Instance	UGameInstanceSubsystem	In-Game 시작 ~ In-Game 종료 시작 GameInstance Subsystem의 Module이 로드 -> Module의 Startup() 함수 반환 -> Initialize() 호출 끝 Module의 Shutdown() 함수 반환 -> DeInitialize() 호출
Local Player	ULocalPlayerSubsystem	ULocalPlayer의 LifeTime (Level이 여러개면, 해당 Level에 존재하는 ULocalPlayer의 LifeTime) 시작 LocalPlayer Subsystem의 Module 로드 -> Module의 Startup() 함수 변환 -> Initialize() 호출 끝 Module의 Shutdown() 함수 변환 -> DeInitialize() 호출
World	UWorldSubsystem	UWorld의 LifeTime (Level이 여러개이면, Level 별로 존재함)

// Engine Subsystem
class UMyEngineSubsystem : public UEngineSubsystem { ... };

UMyEngineSubsystem* MySubsystem = GEngine->GetEngineSubsystem<UMyEngineSubsystem>();


// Editor Subsystem
class UMyEditorSubsystem : public UEditorSubsystem { ... };

UMyEidotrSubsystem* MySubsystem = GEditor->GetEditorSubsystem<UMyEditorSubsystem>();


// GameInstance Subsystem
class UMyGameSubsystem : public UGameInstanceSubsystem { ... };

UGameInstance* GameInstance = GetGameInstance();
UMyGameSubsystem* MySubsystem = GameInstance->GetSubsystem<UMyGameSubsystem>();


// LocalPlayer Subsystem
class UMyPlayerSubsystem : public ULocalPlayerSubsystem { ... };

UGameInstance* GameInstance = GetGameInstance();
ULocalPlayer* LocalPlayer = GameInstance->GetFirstGamePlayer();
UMyPlayerSubsystem* MySubsystem = LocalPlayer->GetSubsystem<UMyPlayerSubsystem>();

Reference

UnrealEngine 프로그래밍 서브시스템
UnrealEngine 프로그래밍 서브시스템 (extra community info)

Subsystem을 사용하는 이유

Subsystem 내에 이미 존재하는 기능을 가져와서 사용하므로 다음과 같은 이점이 있다.

Engine Class Override를 피할 수 있다.
API 추가를 피할 수 있다.
Subsystem 기능이 Blueprint에 자동 노출되고 Blueprint로 Subsystem을 액세스할 수 있다.

UEditorSubsystem

UEditorActorSubsystem
- TArray GetSelectedlevelActors()
- TArray GetAllLevelActors()

UGameInstanceSubsystem을 상속받는 클래스의 생명주기(Life Time)

// GameInstance Subsystem
class UMyGameSubsystem : public UGameInstanceSubsystem { ... };

위와 같이 UGameInstanceSubsystem을 상속받는 클래스가 존재한다면,

UGameInstance 생성 -> UMyGameSubsystem 인스턴스 생성
UGameInstance 초기화 -> UMyGameSubsystem 인스턴스에서 Initialize()가 호출

UGameInstance 종료 -> UMyGameSubsystem 인스턴스에서 DeInitialize()가 호출
DeInitialize()가 호출된 시점에서 UMyGameSubsystem 인스턴스에 대한 참조가 삭제된다. 더 이상 참조가 없으면 UMyGameSubsystem 인스턴스는 Garbage Collection 대상이 된다.

Game Instance vs Game Instance Subsystem

Game Instance	Game Instance Subsystem
Game 생성 시, Spawn 된다.	Game Instance가 생성 된 후에 생성된다.
Game이 종료될 때까지 소멸되지 않는다(Game 종료 시, 소멸).	Game Instance 종료 시, 소멸되고 Garbage Collector에서 처리된다.

게임에서 레벨을 이동하는 경우(던전 입장, 마을 이동 등)가 빈번하게 발생한다. 또한 FPS 게임의 경우, 한 게임이 끝나고 다시 게임이 시작되는 경우가 비번히 발생한다.

그렇기 때문에 Game이 종료 될 때까지 소멸하지 않는 Game Instance보다 **Game Instance Subsystem을 사용하는 것이 더 유리하다.**

Game Instance Subsystem을 사용하면, Engine Class Override를 피할 수 있고 코드의 재사용성을 높일 수 있다.

[UE] Unreal Performance Optimization Learning Path

Seongcheol Jeon — Wed, 01 Oct 2025 02:19:02 +0000

UnrealEngine 최적화 관련 사이트 정리

https://dev.epicgames.com/community/learning/paths/Rkk/unreal-engine-unreal-performance-optimization-learning-path

[UE] ClassRedirects

Seongcheol Jeon — Mon, 15 Sep 2025 04:47:32 +0000

클래스명 혹은 모듈 이름을 변경할 때, 참조하고 있는 블루프린트가 존재할 때

클래스명 또는 모듈 이름을 변경하려고 할 때, 참조하고 있는 블루프린트가 존재하면 그 블루프린트의 Parent Class는 깨진다.

이럴 때는 Config/DefaultEngine.ini 파일에서 다음과 같이 설정하면 된다.

[CoreRedirects]
+ClassRedirects=(OldName="ClassA",NewName="ClassB")

이것을 "DefaultEngine.ini" 파일에 추가한 후, 에디터를 실행하여 ClassA를 참조하는 모든 블루프린트를 다시 컴파일/저장 후 종료한다.
"DefaultEngine.ini"파일에서 추가한 내용을 제거하고 다시 엔진을 실행하여 제대로 되었는지 확인한다.

continue...