언리얼 엔진 교보재

[UE5] 멀티스레딩

1. 게임에서 멀티스레딩이 필요한 이유게임은 매 프레임마다 렌더링, 물리 시뮬레이션, AI 연산, 네트워크 처리 등 수많은 작업을 수행해야 합니다. 이 모든 작업을 게임 스레드 하나에서 순차적으로 처리하면, 하나의 무거운 연산이 전체 프레임 시간을 잡아먹어 프레임 드롭이 발생합니다. 예를 들어 오픈 월드 게임에서 수천 개의 액터에 대한 경로 탐색을 한 프레임 안에 처리하려 하면, 게임이 버벅거리는 현상을 피할 수 없습니다.멀티스레딩은 이러한 무거운 작업을 별도의 스레드에 분산시켜 게임 스레드의 부담을 줄이는 기법입니다. 현대 CPU는 대부분 멀티코어를 탑재하고 있기 때문에, 여러 스레드를 동시에 실행하면 전체 처리 속도를 크게 향상시킬 수 있습니다. 언리얼 엔진 5는 이를 위해 다양한 수준의 멀티스레딩 ..

[UE5] 비동기 프로그래밍

1. 비동기 프로그래밍이 필요한 이유게임은 매 프레임(보통 16.6ms, 60FPS 기준) 내에 모든 로직을 처리해야 합니다. 그런데 대규모 데이터 연산, 네트워크 요청, 파일 I/O, 경로 탐색(Pathfinding) 같은 작업은 한 프레임 안에 처리하기에 너무 무겁습니다. 이러한 작업을 게임 스레드에서 동기적으로 실행하면 해당 프레임의 처리 시간이 급증하여 프레임 드롭(hitching)이 발생하고, 플레이어는 게임이 "멈추는" 것처럼 느끼게 됩니다.비동기 프로그래밍은 이 문제를 해결합니다. 무거운 작업을 별도의 스레드나 백그라운드 태스크로 위임하여 게임 스레드가 블로킹되지 않도록 하고, 작업이 완료되면 결과를 게임 스레드로 돌려받는 구조입니다.언리얼 엔진은 비동기 프로그래밍을 위해 두 가지 큰 축의 ..

[UE5] 비동기 애셋 로딩

1. 비동기 애셋 로딩이 필요한 이유게임이 대규모화될수록 텍스처, 메시, 사운드, 애니메이션 등 애셋의 수와 크기도 기하급수적으로 늘어납니다. 만약 게임 시작 시 모든 애셋을 한꺼번에 메모리에 올린다면, 로딩 시간이 길어지고 메모리 사용량이 폭증하여 실제 플레이에 필요하지 않은 애셋까지 불필요하게 점유하는 문제가 발생합니다.이 문제의 핵심 원인은 하드 레퍼런스(Hard Reference)에 있습니다. 언리얼 엔진에서 UObject*나 TObjectPtr 같은 직접 포인터로 애셋을 참조하면, 해당 포인터를 소유한 오브젝트가 로드될 때 참조하는 애셋도 자동으로 함께 로드됩니다. 이러한 참조가 연쇄적으로 걸려 있으면 하나의 오브젝트를 로드하기 위해 관련된 수십, 수백 개의 애셋이 한꺼번에 로드되는 상황이 발생..

[UE5] 델리게이트

1. 델리게이트가 필요한 이유게임 개발에서는 서로 다른 오브젝트 간에 이벤트를 전달해야 하는 상황이 매우 빈번합니다. 캐릭터의 체력이 변경되면 UI가 갱신되어야 하고, 적이 사망하면 퀘스트 시스템이 이를 감지해야 하며, 문이 열리면 사운드와 애니메이션이 동시에 재생되어야 합니다. 이러한 상호작용을 구현할 때 각 오브젝트가 서로의 구체적인 타입을 알아야 한다면, 코드의 결합도(coupling)가 높아져 유지보수가 어려워집니다.델리게이트(Delegate)는 이 문제를 해결하는 핵심 메커니즘입니다. 델리게이트를 사용하면 호출하는 측은 응답하는 측의 구체적인 타입을 알 필요 없이, 특정 시그니처(반환형과 파라미터 목록)에 맞는 함수를 등록해 두고 나중에 호출할 수 있습니다. 이를 통해 오브젝트 간의 결합도를 낮..

1. 언리얼만의 오브젝트 생성 방식이 필요한 이유C++ 개발자라면 객체를 생성할 때 new 키워드를 사용하고, 사용이 끝나면 delete로 해제하는 것이 자연스럽습니다. 그러나 언리얼 엔진에서는 UObject 파생 클래스에 대해 new와 delete를 직접 사용하는 것이 금지되어 있습니다.그 이유는 언리얼 엔진의 핵심 시스템들이 오브젝트의 생성과 소멸 과정에 깊이 관여하기 때문입니다. 리플렉션 시스템은 오브젝트가 생성될 때 클래스 정보를 등록해야 하고, 가비지 컬렉션(GC) 시스템은 오브젝트의 참조 관계를 추적하여 자동으로 메모리를 회수해야 합니다. 시리얼라이제이션 시스템은 오브젝트를 저장하거나 불러올 때 올바른 초기화 순서를 보장해야 합니다. new를 직접 사용하면 이러한 시스템들이 오브젝트를 인식하지..

1. 언리얼 엔진에 자체 컨테이너가 필요한 이유게임 프로젝트에서는 수천 개의 액터 목록, 인벤토리 아이템, 퀘스트 데이터 등 대량의 데이터를 효율적으로 관리해야 합니다. C++ 표준 라이브러리(STL)에도 std::vector, std::unordered_map, std::unordered_set 같은 훌륭한 컨테이너가 있지만, 언리얼 엔진은 이를 직접 사용하지 않고 자체 컨테이너 라이브러리(UCL)를 구현하여 사용합니다.그 이유는 크게 세 가지입니다. 첫째, STL은 범용성을 중시하여 컴파일 시간이 길어지는 경향이 있으며, 대규모 게임 프로젝트에서는 이 비용이 누적되어 빌드 시간에 상당한 영향을 줍니다. 둘째, 언리얼 엔진의 리플렉션 시스템과 가비지 컬렉션을 지원하려면 UPROPERTY 매크로와 연동되..

1. 성능 문제가 시작되는 곳게임을 개발하다 보면 초반에는 문제가 없던 프로젝트가 액터 수가 늘어날수록 점점 프레임이 떨어지는 경험을 하게 됩니다. 원인을 추적해보면 상당수는 동일한 패턴에서 비롯됩니다. 매 프레임 실행되는 Tick 함수에 무거운 로직이 들어가 있거나, 컴포넌트를 조회할 때마다 선형 탐색을 반복하거나, 필요 없는 컴포넌트들이 여전히 매 프레임 업데이트되고 있는 경우입니다.언리얼 엔진 5는 액터와 컴포넌트를 효율적으로 운용하기 위한 다양한 도구를 제공합니다. 이 글에서는 그 도구들을 어떻게 올바르게 사용하는지, 그리고 어떤 실수가 성능 병목을 만드는지를 중심으로 설명합니다.2. 액터와 컴포넌트의 구조언리얼 엔진에서 AActor는 월드에 존재하는 모든 객체의 기반 클래스입니다. 액터 자체는 ..

1. 가비지 컬렉션이 필요한 이유C++은 메모리 관리를 개발자에게 전적으로 맡기는 언어입니다. new로 할당한 메모리는 반드시 delete로 해제해야 하며, 이 규칙을 지키지 않으면 메모리 누수가 발생합니다. 반대로 이미 해제한 메모리에 다시 접근하면 댕글링 포인터(Dangling Pointer) 문제가 생기고, 이는 즉시 크래시로 이어지거나 더 위험하게는 눈에 보이지 않는 정의되지 않은 동작(Undefined Behavior)을 유발합니다.게임 엔진처럼 수천 개의 객체가 생성되고 파괴되는 환경에서는 이러한 수동 메모리 관리의 부담이 극도로 커집니다. 레벨을 전환하며 액터를 파괴하고, 스트리밍으로 서브레벨을 로드·언로드하고, 에디터에서 실시간으로 객체를 추가·삭제하는 상황을 모두 수동으로 관리한다면 버그..

1. 리플렉션이 필요한 이유C++은 기본적으로 런타임에 클래스나 구조체가 어떤 멤버를 갖고 있는지 알아낼 수 있는 방법을 제공하지 않습니다. C++ 표준에 포함된 RTTI(Run-Time Type Information)는 typeid와 dynamic_cast 정도의 제한적인 기능만 지원하며, "이 클래스에 어떤 프로퍼티가 있고, 각각의 타입은 무엇인가?"와 같은 질문에는 답할 수 없습니다.그런데 게임 엔진은 런타임에 클래스 정보를 반드시 알아야 합니다. 에디터의 디테일 패널에 프로퍼티를 표시하려면 해당 클래스에 어떤 변수가 있는지 알아야 하고, 저장·로딩(시리얼라이제이션)을 하려면 객체가 가진 데이터를 순회할 수 있어야 합니다. 네트워크 리플리케이션에서 변경된 프로퍼티만 골라서 전송하는 것도 마찬가지입니..