언리얼 엔진을 처음 접하면, 기존 C++에서 익숙하게 사용하던 코드들이 다른 이름과 규칙으로 다시 등장한다는 점에서 혼란을 느끼기 쉽습니다. 특히 C++ 경험이 있는 개발자일수록 “이미 알고 있는 개념인데 왜 언리얼에서는 다른 방식을 요구하는가”라는 의문을 갖게 됩니다.
대표적인 예로는 문자열 타입과 STL 컨테이너, 그리고 스마트 포인터를 들 수 있습니다.
C++에서는 std::string, std::vector, std::unique_ptr, std::shared_ptr 와 같은 표준 라이브러리 타입을 사용하지만, 언리얼에서는 이에 대응하는 엔진 전용 타입들이 존재합니다.
대표적으로 다음과 같은 엔진 전용 타입들이 사용됩니다.
• FString, FName, FText
• TArray, TMap, TSet
• TUniquePtr, TSharedPtr, TSharedRef, TWeakPtr
• UObject*, TObjectPtr, TWeakObjectPtr
겉보기에는 C++ 표준 라이브러리와 매우 유사해 보이지만, 언리얼에서는 이들을 표준 라이브러리 대신 사용하도록 권장하고 있으며, 표준 라이브러리와의 혼용 역시 지양하고 있습니다. 이로 인해 “언리얼은 STL이나 std를 쓰지 않는다”라는 인상을 받기 쉽습니다.
그렇다면 정말로 언리얼 엔진은 C++ 표준 라이브러리를 배제하고 있는 것일까요?
이에 대한 답은 Epic Games에서 공식적으로 제공하는 C++ 코딩 표준 문서에 비교적 명확하게 정리되어 있습니다.
아래 문서는 언리얼 엔진에서 C++ 표준 라이브러리를 어떻게 바라보고 있는지, 그리고 왜 자체적인 구현과 규칙을 유지해 왔는지를 직접적으로 설명하고 있습니다.
아래 내용은 위 문서 중 Use of Standard Libraries 항목을 중심으로, 핵심 내용을 정리한 요약입니다.
언리얼 엔진에서 표준 라이브러리를 지양해온 이유
Epic Games는 역사적으로 언리얼 엔진 내부 코드에서 C 및 C++ 표준 라이브러리를 직접 사용하는 것을 피해 왔습니다. 이는 특정 라이브러리가 나쁘기 때문이라기보다는, 엔진이라는 특수한 환경에서 요구되는 조건들을 만족시키기 위함이었습니다.
공식 문서에서 언급하는 주요 이유는 다음과 같습니다.
• 당시 표준 라이브러리 구현이 엔진 요구 성능을 충족하지 못했던 경우가 있었기 때문
• 엔진 전반에서 메모리 할당 방식을 보다 세밀하게 통제하기 위함
• 표준에 아직 포함되지 않은 기능을 선제적으로 도입하기 위함
• 엔진에 적합하지 않은 표준 동작을 피하거나 수정하기 위함
• 코드베이스 전반에 걸쳐 일관된 문법과 스타일을 유지하기 위함
• 언리얼 엔진의 객체 모델(UObject, GC 등)과 충돌하는 구조를 피하기 위함
이러한 이유로 언리얼은 문자열, 컨테이너, 스마트 포인터 등 핵심 요소들을 자체적으로 구현해 왔으며, 이를 통해 엔진 전체의 동작 방식과 긴밀하게 결합된 구조를 유지해 왔습니다.
다만 이는 “표준 라이브러리를 절대 사용하지 말라”는 의미는 아닙니다. 현재의 C++ 표준 라이브러리는 성능과 안정성 면에서 크게 발전했으며, 엔진과 명확히 분리된 영역에서는 std:: 사용이 문제되지 않는 경우도 존재합니다. 그럼에도 불구하고 엔진 코드 및 게임플레이 코드에서는 언리얼이 제공하는 타입과 규칙을 사용하는 것이 유지보수성과 안정성 측면에서 더 바람직하다는 것이 Epic의 기본적인 입장입니다.
결국 언리얼 엔진에서의 C++ 코딩은 “표준 라이브러리를 배제한다”기보다는, 엔진과 강하게 결합되는 영역에서는 언리얼이 제공하는 전용 규칙을 따르자는 철학에 가깝다고 볼 수 있습니다. 이 전제를 이해하고 나면, 언리얼 전용 타입들이 왜 존재하는지, 그리고 왜 혼용을 지양하는지가 자연스럽게 납득됩니다.
'Unreal' 카테고리의 다른 글
| 특이한 언리얼 3D 좌표계와 회전 방향 (0) | 2025.12.13 |
|---|
