본문 바로가기

Unreal Engine의 특징과 구조

언리얼 엔진의 리플렉션·컴포넌트·게임 프레임워크 구조를 연결해 에디터와 런타임의 역할을 이해합니다.

언리얼 C++를 시작할 때 가장 먼저 부딪히는 벽은 C++ 문법이 아니라 엔진 구조를 어디서부터 이해해야 할지 결정하는 일입니다.

일반 C++ 프로젝트와 달리 언리얼은 리플렉션, 컴포넌트, 에디터 연동, 런타임 규칙이 함께 움직이기 때문에 처음부터 전체 맥락을 놓치기 쉽습니다.

그래서 단순히 코드를 많이 쓰는 것보다, 엔진이 어떤 단위로 동작하고 객체가 어떤 생명 주기를 갖는지 먼저 잡아두는 편이 훨씬 중요합니다.

이 절에서는 언리얼 엔진이 왜 C++ 개발에서 특별한지, 그리고 이후 장에서 반복해서 만나게 될 핵심 구조가 무엇인지 선명하게 정리합니다.

이 기준을 잡아두면 나중에 클래스 설계나 네트워크 로직을 배울 때도 각 개념이 흩어지지 않고 하나의 그림으로 연결됩니다.


언리얼 엔진의 핵심 강점

언리얼 엔진은 에픽게임즈에서 개발한 실시간 3D 콘텐츠 제작 툴이자 게임 엔진입니다.

이미 게임, 건축 시각화, 영화 등 다양한 분야에서 제작된 사례를 쉽게 확인할 수 있으며, 이러한 폭넓은 활용은 엔진의 기술적 확장성과 제작 파이프라인 호환성에서 비롯됩니다.

가장 먼저 꼽을 특징은 하이엔드 그래픽 성능입니다.

언리얼 엔진은 사실적인 렌더링 파이프라인을 통해 고품질 비주얼을 실시간으로 제공합니다.

루멘(Lumen)은 동적 전역 조명과 반사를, 나나이트(Nanite)는 가상화된 지오메트리 처리를 제공합니다. 지원 플랫폼·렌더링 경로와 성능 예산을 확인해 사용하는 기능을 정합니다.

또 하나의 강점은 블루프린트(Blueprint) 기반 비주얼 스크립팅입니다.

C++을 직접 작성하지 않아도 노드 연결만으로 로직을 구현할 수 있어, 아티스트나 기획자도 개발 루프에 빠르게 참여할 수 있습니다.

이 책은 C++ 중심이지만, 실무에서는 C++과 블루프린트를 함께 사용할 때 생산성이 가장 높아집니다.

또한 언리얼 엔진은 PC, 콘솔, 모바일, VR/AR 등 주요 플랫폼을 지원합니다.

대상 플랫폼의 SDK·개발 권한·지원 엔진 버전과 렌더링 기능이 필요하며, 하나의 구성을 그대로 모든 기기에 배포할 수 있다는 뜻은 아닙니다.

한 번 개발한 콘텐츠를 여러 플랫폼에 맞춰 배포할 수 있다는 것은 개발 시간과 비용을 크게 절감할 수 있다는 의미이기도 합니다.

마지막으로, 언리얼 엔진은 강력한 에디터와 개발 도구를 내장하고 있습니다.

직관적인 인터페이스의 레벨 에디터부터 시작하여, 머티리얼 에디터, 애니메이션 에디터, 파티클 에디터 등 콘텐츠 제작에 필요한 모든 도구들을 언리얼 엔진 안에서 바로 사용할 수 있습니다.

이 통합된 개발 환경은 작업 흐름을 매우 효율적으로 만들어줍니다.


언리얼 엔진의 핵심 구조 들여다보기

언리얼 엔진은 그 규모만큼이나 체계적인 구조를 가지고 있습니다.

그중에서도 여러분이 언리얼 엔진 C++ 개발을 시작하면서 가장 먼저 이해해야 할 몇 가지 핵심 개념들이 있습니다.

  • 액터(Actor): 월드에 배치하거나 스폰하는 객체의 기본 타입입니다. 플레이어 캐릭터, 적 캐릭터, 나무, 건물, 광원 등을 액터로 구성할 수 있습니다. 액터 안의 컴포넌트나 위치 없는 데이터까지 모두 별도의 액터인 것은 아닙니다. 액터의 위치·회전·스케일은 루트 SceneComponent가 있으면 그 컴포넌트의 Transform을 사용합니다. 액터 자체에 별도의 Transform을 저장하는 것은 아닙니다.

  • 컴포넌트(Component): 액터에 기능을 부여하는 모듈입니다. 액터는 여러 컴포넌트를 조합해 복합 동작을 구성합니다. StaticMeshComponent는 3D 모델 표시를, CameraComponent는 카메라 시점을 담당합니다.

    C++에서는 컴포넌트 조합이 기능 확장의 기본 패턴입니다.

  • 월드(World): 액터들이 배치되고 상호작용하는 공간입니다. World는 하나의 영속 레벨과 추가로 로드하는 레벨들을 포함할 수 있습니다. 편집 월드와 PIE 실행 월드도 서로 구분됩니다. 각 월드는 자체적인 물리 시뮬레이션, 렌더링, 게임 플레이 규칙 등을 관리합니다.

  • 게임 모드(GameMode): 게임의 전반적인 규칙을 정의하는 클래스입니다. 예를 들어, 어떤 캐릭터를 스폰할지, 플레이어의 점수를 어떻게 관리할지, 게임의 승리/패배 조건은 무엇인지 등을 게임 모드에서 설정합니다. 게임 모드는 서버에서만 존재하며, 클라이언트에는 복제되지 않습니다.

  • 플레이어 컨트롤러(PlayerController): 플레이어의 입력을 받아 캐릭터를 조작하고 게임과 상호작용하는 역할을 담당합니다. 키보드, 마우스, 게임패드 등의 입력을 처리하고, 이를 액터에게 전달하여 움직이거나 특정 행동을 하도록 합니다.

  • 폰(Pawn): 플레이어나 AI가 제어할 수 있는 액터 타입입니다. PlayerController 또는 AI 컨트롤러가 빙의(Possess)해 제어하며, 그중 캐릭터(Character)는 CharacterMovementComponent를 내장해 복잡한 이동 로직 구현에 최적화되어 있습니다.

UNREAL C++ · CH1-1

포함·제어·상속은 서로 다른 관계입니다

월드에는 액터 인스턴스가 있고, 액터는 컴포넌트로 기능을 구성합니다. Controller의 Possess는 Pawn을 제어하는 연결이며 클래스 상속과 다릅니다.

서버 World의 인스턴스 포함과 제어 관계예시서버World영역에GameMode와PlayerController및CharacterPawn이있다. Character영역안루트SceneComponent와탄약ActorComponent가소속된다. PC의Possess는제어,GameMode점선은스폰클래스규칙이며컴포넌트포함·클래스상속·생성순서와다른관계다.서버 World · 인스턴스의 예PlayerController현재 Pawn 제어GameMode서버의 스폰 규칙Character 인스턴스 · Pawn루트 SceneComponentTransform탄약 기능ActorComponentTransform 불필요Possess스폰 규칙영역은 포함 · 실선은 제어 · 점선은 스폰 규칙
서버 World의 인스턴스 포함과 제어 관계예시서버World영역에GameMode와PlayerController및CharacterPawn이있다. Character영역안루트SceneComponent와탄약ActorComponent가소속된다. PC의Possess는제어,GameMode점선은스폰클래스규칙이며컴포넌트포함·클래스상속·생성순서와다른관계다.서버 World · 인스턴스 예GameMode서버의 스폰 규칙PlayerController현재 Pawn 제어Character · Pawn루트SceneComponentTransform탄약 기능ActorComponentTransform 불필요Possess영역: 포함 · 실선: 제어점선: 서버의 스폰 규칙
Character에서 Actor까지의 부모 타입Character는Pawn을상속하고Pawn은Actor를상속한다. 화살표는자식타입에서부모타입을향하며World인스턴스포함이나ControllerPossess가아니다.Character자식 타입PawnCharacter의 부모ActorPawn의 부모상속상속화살표: 자식 타입 → 부모 타입
Character에서 Actor까지의 부모 타입Character는Pawn을상속하고Pawn은Actor를상속한다. 화살표는자식타입에서부모타입을향하며World인스턴스포함이나ControllerPossess가아니다.
Character자식 타입
상속상속Character · 자식 타입 → Pawn · Character의 부모
PawnCharacter의 부모
상속상속Pawn · Character의 부모 → Actor · Pawn의 부모
ActorPawn의 부모

화살표: 자식 → 부모 타입Possess·부착 관계와 다름

포함 관계 · 실행 중인 월드

World → 레벨에 존재하는 Actor 인스턴스 → 액터가 소유한 Component

SceneComponent

Transform과 부착 계층을 가집니다. Root SceneComponent가 있으면 Actor의 위치·회전·스케일은 이 루트에서 옵니다.

ActorComponent

액터에 재사용할 기능을 조립합니다. 모든 ActorComponent가 공간 Transform을 가지는 것은 아닙니다.

제어 관계 · Controller → Pawn

PlayerController는 플레이어의 입력·판단을 Pawn의 동작으로 연결합니다. AIController도 Pawn을 제어할 수 있습니다.

Controller가 Pawn의 부모 클래스나 SceneComponent가 되는 것은 아닙니다.

상속 관계 · Actor → Pawn → Character

Pawn은 제어할 수 있는 Actor 타입입니다. Character는 Pawn을 상속하고 CharacterMovementComponent를 포함합니다.

클래스의 종류 관계이며 월드 아웃라이너의 부착 트리와 다릅니다.

서버 규칙 · GameMode

스폰할 클래스·승리 조건 같은 게임 규칙을 맡습니다. 원격 클라이언트에 GameMode 인스턴스를 자동 복제하는 관계가 아닙니다.

편집 월드와 PIE 실행 월드는 구분합니다. 이 그림은 역할 관계를 보여주며 객체 생성 순서나 전체 엔진 계층을 나타내지 않습니다.

이러한 핵심 요소들이 유기적으로 결합하여 언리얼 엔진의 거대한 구조를 이룹니다.

앞으로 C++ 코드를 작성하면서 이 개념들을 더욱 깊이 이해하게 될 것입니다.

예시

플레이어 캐릭터가 이동하고 탄약을 가진다고 합시다. 현재 월드의 Character 인스턴스는 위치·회전이 있는 대상이고, 이동은 CharacterMovementComponent, 탄약 개수와 습득 규칙은 별도의 기능 컴포넌트로 나눌 수 있습니다. 탄약을 관리하는 기능 자체에 공간 Transform이 필요하지 않다면 ActorComponent로 생각합니다. 위치가 있는 메시나 카메라처럼 SceneComponent가 필요한 기능과 구별합니다.

플레이어가 다른 Pawn을 조작하게 되는 상황에서도 현재 Controller의 제어 대상 참조를 바꾸는 Possess와 클래스 상속은 다릅니다. 기존 Character 클래스가 새 부모 클래스로 바뀌는 것이 아닙니다. 지금은 생성 코드를 작성하기보다 어느 인스턴스가 어느 기능을 소유하고 누가 제어하는지 설명해 봅니다.

직접 판단할 조건은 세 가지입니다. 월드에 배치할 탄약 Pickup, 현재 Character에 붙일 탄약 관리 기능, 위치 없는 저장 데이터는 모두 Actor여야 할까요? Controller가 Pawn B를 새로 빙의하면 Pawn A가 Controller의 자식 클래스로 바뀔까요?

객체 역할과 관계 확인

Pickup은 월드에 배치할 Actor로 시작할 수 있고, 탄약 관리 기능은 Character에 붙일 ActorComponent로 분리할 수 있습니다. 위치 없는 저장 데이터는 Actor가 필수인 상황이 아니므로 이후 SaveGame 등 목적에 맞는 타입을 선택합니다. Possess는 실행 중 제어 연결이며 클래스 상속이나 컴포넌트 포함 관계를 변경하지 않습니다.


다음 절 준비 메모

설치로 넘어가기 전에 만들 기능의 책임을 다음 기준으로 정리합니다.

  • 월드에 배치할 Actor인지, 액터에 붙일 Component인지, 위치 없는 데이터인지 구분합니다.
  • Controller의 입력·판단과 Pawn의 동작, GameMode의 서버 규칙을 나눕니다.
  • 클래스 접두사와 엔진 객체·일반 C++ 객체의 생성 및 수명 차이를 확인합니다.
  • 조정할 값과 공개할 함수를 정하고, 에디터 기본값·인스턴스 값·런타임 변경을 구분합니다.
  • C++의 공통 구조와 Blueprint의 조정 책임을 기록합니다. 렌더링·물리 같은 엔진 기능은 프로젝트의 성능 예산에 맞게 선택합니다.

다음 절에서는 이 기준으로 개발 환경을 구성합니다.