🔗 학습 날짜 인증(주제와 무관)

오늘 한 내용

---

• C++ 코드카타
• 언리얼 C++ 빌드 파이프라인 분석
• AI Model 캐릭터 적용 및 로직 구현

리플렉션

---

리플렉션(Reflection)은 프로그램이 실행 중(Runtime)에 자기 자신의 구조와 속성을 관찰하고 제어할 수 있는 능력 을 의미한다.

사실 해당 내용만 보는 건 이해하기 어려우므로, 아래 예시를 통해서 정리해보려고 한다.

코드 전문은 아니지만, 아래와 같이 표준 C++로 동작하는 프로그램이 있다고 가정하자.

class MyPlayer {
public:
    int Health = 100;
};

이때, 런타임에서 Health라는 이름을 사용해서 Health의 값을 변경할 수 있을까?
표준 C++에서는, 메모리 주소로만 메모리에 접근하기 때문에 Health라는 이름을 통해서 변경하려고 하면 알 수 없다.

언리얼 C++에서는 특정 마커만 달아주면 언리얼의 UHT가 코드를 훑어보고, 메타 데이터 사전을 만들어 준다.

class MyPlayer : public UObject {
    GENERATED_BODY()
public:
    UPROPERTY()
    int Health = 100;
};

그래서 리플렉션은 런타임에서 Health라는 이름을 사용해서 주소를 반환하여 알 수 있도록 만들어준다.

이러한 이점을 활용해서, 리플렉션은 다음과 같은 기능을 제공해준다.

• 런타임으로, 객체 타입 정보를 확인
• 에디터와 연동되어, 마킹된 변수(UPROPERTY()가 있는 변수)가 Detail Panel에 표시
• 객체 참조 관계를 추적함으로써, 메모리 자동 관리

가비지 컬렉션

---

표준 C++과 달리, 언리얼 C++에서는 가비지 컬렉션 기능을 제공한다.
표준 C++에서는 기본적으로 메모리 할당(new)/해제(delete)를 수동으로 해줘야 하기 때문에 메모리 누수(Memory Leak), 댕글링 포인터(Dangling Pointer), 이중 해제(Double-Free)현상이 나타날 수 있다.

스마트 포인터의 경우와 차이점이라고 한다면, 순환 참조가 걸릴 일이 없지만 객체를 청소하는 타이밍을 알 수 없다는 점이다.

가비지 컬렉션의 동작 원리는 다음과 같다.

1. GameInstance나 Wolrd 등. 전역으로 돌아가는 핵심 객체를 루트 셋(Root Set)에 넣고 가비지 컬렉터의 출발점으로 인식한다.
2. 이후 순차적으로 UObject를 상속하고 UPROPERTY()가 붙어있는 객체들을 하나씩 탐색하고 마킹한다.
3. 모두 방문 했을 때, 마킹되지 않은 객체가 존재한다면 삭제(Sweep)한다.

가비지 컬렉션이 할당된 메모리를 삭제할 때 어떤 일이 일어나는 지 다음 코드로 확인해보려고 한다.

// TestObject.h
UCLASS()
class ADVANCEDPROJECT_API UTestObject : public UObject
{
	GENERATED_BODY()
	
public:
	void InitObject(FString InName);

private:

	FString MemoName;
};

// TestObject.cpp
void UTestObject::InitObject(FString InName)
{
	MemoName = InName;
}

// MyGCObserver.h
UCLASS()
class ADVANCEDPROJECT_API AMyGCObserver : public AActor
{
	GENERATED_BODY()

protected:
	virtual void BeginPlay() override;

public:	
	virtual void Tick(float DeltaTime) override;

	UPROPERTY()
	class UTestObject* SafeObject;

	class UTestObject* DangerObject; // 리플렉션 시스템 미등록, GC 처리 대상
};

// MyGCObserver.cpp
void AMyGCObserver::BeginPlay()
{
	Super::BeginPlay();
	
	SafeObject = NewObject<UTestObject>();
	SafeObject->InitObject(TEXT("SafeObject"));

	DangerObject = NewObject<UTestObject>();
	DangerObject->InitObject(TEXT("DangerObject"));
}

// Called every frame
void AMyGCObserver::Tick(float DeltaTime)
{
	Super::Tick(DeltaTime);

	bool bSafeIf = SafeObject != nullptr;
	bool bSafeValid = SafeObject->IsValid();

	bool bDangerIf = DangerObject != nullptr;
	bool bDangerValid = DangerObject->IsValid();
}

실행해보면 알겠지만, 여기서 DangerObject는 GC에 의해서 메모리 제거 대상인데, 제거 되더라도 bDangerIf와 bDangerValid 모두 true로 유지된다.

그 이유는 리플렉션 시스템을 등록하지 않았기 때문에, 가비지 컬렉터가 DangerObject의 존재를 모르기 때문이다.

리플렉션 시스템에 등록된 SafeObject의 경우 메모리가 해제되면 해당 값을 nullptr로 변경하지만, DangerObject는 해제된 메모리 주소를 계속 지니는 Dangling Pointer 현상을 초래한다.

그렇기 때문에 nullptr, IsValid()로 메모리를 상태를 체크하고 접근하려고 하면 크래시가 발생한다.

IsValid()의 대체재로는 IsValidLowLevel()을 사용함으로써, 해당 포인터가 유효한 메모리를 가리키고 있는지 깊게 파고들어야 한다.

void AMyGCObserver::Tick(float DeltaTime)
{
	Super::Tick(DeltaTime);

	bool bSafeIf = SafeObject != nullptr;
	bool bSafeValid = SafeObject->IsValidLowLevel();

	bool bDangerIf = DangerObject != nullptr;
	bool bDangerValid = DangerObject->IsValidLowLevel();
}

하지만 IsValidLowLevel()는 메모리가 유효한지만 체크할 뿐, 여전히 DangerObject는 Dangling Pointer 현상을 막지 못하기 때문에 다음과 같이 오브젝트를 약한 참조 스마트 포인터(TWeakObjectPtr)로 먼저 선언해줘야 한다.

이러면, 메모리가 삭제되더라도 DangerObject 또한 nullptr로 세팅이 된다.

TWeakObjectPtr<class UTestObject> DangerObject;

UBT, UHT

---

UBT(Unreal Build Tool)은 프로젝트에 어떤 모듈이 있고, 어떤 플랫폼(Windows, Android, PS5 등)으로 빌드할지 결정하는 역할을 한다.

솔루션을 열어보면 .Target.cs, .Build.cs 파일이 있는데, 해당 파일들을 바탕으로 전체적인 빌드 계획을 세우는 게 UBT의 역할이다.

UHT(Unreal Header Tool)은 C++의 컴파일러가 여러 언리얼 매크로(UPROPERTY(), UFUNCTION() 등) 이해할 수 있게 하는 역할을 하며 여러 메타 데이터들을 에디터에 반영할 수 있도록 .generated.h파일을 생성해준다.

그래서 언리얼의 빌드 파이프라인의 흐름은 다음과 같다.

1. UBT가 프로젝트의 빌드 과정을 총괄한다.
2. UHT가 언리얼의 매크로, 메타 데이터 등을 수집하여 에디터에 반영할 수 있도록 .generated.h를 제공해준다.
3. C++ 컴파일러가 컴파일을 진행하고 링커가 컴파일된 오브젝트 파일을 조립한다.

CDO

---

CDO(Class Default Object)는 UObject 클래스마다 한 개씩 지니는 기본값 보관소이다.

클래스 당 1개의 CDO를 가지고 있으며, CDO는 엔진이 실행되는 시점에서 생성된다.

CDO가 없는 표준 C++로 인스턴스를 100개 생성한다고 하면, 100개의 생성자를 호출하게 되므로 속도가 조금 느리지만, 언리얼은 인스턴스에 CDO 메모리를 복사만 하기 때문에 속도가 조금이나마 빨라진다.

또한 네트워크를 통한 데이터 전송 시, 여러 인스턴스의 정보를 처음부터 전달할 필요 없이 CDO의 내용과 차이점만 전달하면 되므로 대역폭이 줄어든다는 장점이 있다.

하지만, 게임이 실행되고 있는 상황에서 CDO를 수정하는 건 세이브 파일이나 여러 시스템들과의 호환성을 저해하는 행동이기 때문에 CDO를 게임 실행 중에는 수정하면 안된다.