이전 글에서는 유니티와 언리얼 엔진이 모두 Component 기반 구조를 사용하지만,
실제로는 객체를 바라보는 방식과 엔진 철학이 조금 다르다는 점을 정리했습니다.
유니티는 비교적 조합 중심 구조가 강한 엔진에 가깝고,
언리얼 엔진은 Actor 중심 구조와 Component 구조를 함께 사용하는 방향에 가깝습니다.
그런데 유니티를 사용하다 언리얼 엔진을 처음 접하면 생각보다 헷갈리는 부분이 하나 있습니다.
바로, GameObject와 Actor가 정확히 무엇이 다른가 하는 점입니다.
겉보기에는 둘 다 Scene(또는 Level) 안에 배치되는 게임 객체처럼 보입니다.
- 위치를 가지며
- Component를 붙일 수 있고
- 게임 로직을 실행할 수 있습니다.
하지만 실제로는 엔진이 객체를 바라보는 관점 자체가 조금 다릅니다.
이번 글에서는 유니티의 GameObject와 언리얼 엔진의 Actor가 어떤 차이를 가지는지,
그리고 왜 서로 다른 방향으로 발전하게 되었는지를 정리해보려고 합니다.
유니티의 GameObject는 굉장히 가벼운 컨테이너에 가깝다
유니티를 사용하다 보면 대부분의 객체는 GameObject 형태로 존재합니다.
그리고 실제 기능은 대부분 Component를 통해 추가됩니다.
예를 들어 아래와 같은 구조를 생각해볼 수 있습니다.
GameObject Player ├─ Transform ├─ Rigidbody ├─ BoxCollider ├─ AudioSource └─ PlayerController
흥미로운 점은 GameObject 자체는 많은 기능을 직접 가지지 않는다는 점입니다.
실제 동작은 대부분 Component들이 담당합니다.
- 물리 처리는 Rigidbody
- 충돌 처리는 Collider
- 렌더링은 Renderer
- 게임 로직은 Script Component
각 기능들을 컴포넌트들이 나누어 맡아서 처리하는 구조입니다.
즉, 유니티에서는 “객체 자체”보다, “어떤 Component들이 붙어 있는가”가 훨씬 중요해집니다.
언리얼 엔진의 Actor는 객체 개념이 조금 더 강하다
반면, 언리얼 엔진의 Actor는 조금 다른 느낌을 가집니다.
물론 언리얼 엔진 역시 Component 구조를 굉장히 적극적으로 사용합니다.
예를 들어 아래와 같은 형태입니다.
AActor ├─ RootComponent ├─ StaticMeshComponent ├─ CameraComponent └─ AudioComponent
겉보기에는 유니티와 굉장히 비슷해 보일 수도 있습니다.
하지만 실제로는 Actor 자체가 생각보다 많은 역할을 가지고 있습니다.
Actor는 다양한 시스템과 깊게 연결되어 있습니다.
- Tick
- Replication
- Network
- Lifecycle 관리
- Possession
즉, 언리얼 엔진은 Component 조합 구조를 사용하면서도,
“객체 자체의 역할”을 굉장히 중요하게 바라보는 방향에 가깝습니다.
유니티는 Component가 중심이고, 언리얼 엔진은 Actor도 중심이다
이 차이를 조금 단순하게 표현하면 아래처럼 볼 수도 있습니다.
유니티는 “GameObject는 기능을 담는 컨테이너”에 가까운 느낌입니다.
반면, 언리얼 엔진은 “Actor 자체도 게임 세계의 중요한 객체”에 조금 더 가깝습니다.
즉, 유니티는 Component 중심 구조가 강하고,
언리얼 엔진은 Actor와 Component가 함께 중심 역할을 하는 구조에 가깝습니다.
그래서 언리얼 엔진을 보다 보면 Actor 상속 구조 역시 굉장히 자주 등장합니다.
- Character
- Pawn
- PlayerController
- GameMode
즉, 언리얼 엔진은 객체 개념(상속구조)이 비교적 강하게 유지되고 있는 엔진이라고 볼 수도 있습니다.
왜 언리얼 엔진은 Actor 구조를 강하게 유지했을까?
흥미로운 점은 이런 특징이 언리얼 엔진의 역사와도 이 부분이 연결된다는 점입니다.
언리얼 엔진은 굉장히 오래된 엔진입니다.
그리고 FPS, 멀티플레이, 네트워크 게임 개발 경험이 굉장히 깊게 축적되어 있습니다.
이 과정에서 다양한 시스템들이 Actor 중심으로 발전해왔습니다.
- 플레이어 제어
- 네트워크 동기화
- 권한 관리
- 월드 관리
즉, Actor는 단순히 Level에 배치되는 객체를 넘어서 게임 세계에서 동작하는 핵심 단위라고 할 수 있습니다.
그래서 언리얼 엔진에서는 Actor 자체가 많은 책임을 가지게 됩니다.
유니티는 비교적 빠른 조합과 확장을 중요하게 봤다
반면, 유니티는 비교적 가볍고 빠른 조합 구조를 굉장히 중요하게 생각해왔습니다.
GameObject는 비교적 단순하게 유지하고,
필요한 기능들을 Component로 계속 추가하는 방향입니다.
- Rigidbody 추가
- Collider 제거
- Script 교체
즉, 유니티는 “기능을 얼마나 빠르고 쉽게 조합할 수 있는가”를 굉장히 중요하게 여기는 엔진이라고 할 수 있습니다.
두 엔진 모두 결국 복잡도를 관리하려는 방향이다
흥미로운 점은 두 엔진 모두 결국 비슷한 문제를 해결하려고 한다는 점입니다.
게임은 기능 조합이 굉장히 많고,
프로젝트 규모가 커질수록 복잡도 역시 빠르게 증가하기 때문입니다.
다만, 그 복잡도를 관리하는 방식이 조금 다를 뿐입니다.
유니티는 비교적 조합 중심 방향으로 강하게 이동했습니다.
언리얼 엔진은 객체 중심 구조와 Component 구조를 함께 활용하는 방향으로 발전했습니다.
즉, 두 엔진 모두 Component 구조를 사용하지만, 엔진 철학 자체는 생각보다 꽤 다를 수 있습니다.
최근 엔진 구조는 점점 더 작은 단위로 분리되기 시작했다
최근에는 여기서 더 나아가 다양한 구조들도 계속 등장하기 시작했습니다.
- ECS(Entity Component System)
- Data Oriented Design
- Job System
그리고 이런 구조들은 기존 GameObject 또는 Actor 구조보다도 더 강하게 데이터를 분리하기 시작합니다.
즉, 최근 게임 엔진 구조는 점점 “거대한 객체”보다,
“작은 데이터와 기능의 조합” 방향으로 이동하고 있다고 볼 수도 있습니다.
유니티가 DOTS(ECS)를 연구하는 이유 역시 결국 이런 흐름과 연결됩니다.
어떤 구조가 더 좋다고 보기는 어렵다
여기서 중요한 부분이 있습니다.
유니티 방식이 무조건 더 좋다거나,
언리얼 엔진 방식이 더 우월하다고 보기는 어렵습니다.
프로젝트 특성과 엔진 철학에 따라 더 적합한 방향이 달라질 수 있기 때문입니다.
예를 들어, 빠른 프로토타이핑과 조합 구조가 중요하다면 유니티 방식이 굉장히 편할 수 있습니다.
반면, 대규모 게임 로직, 복잡한 네트워크 시스템, 강한 객체 개념이 중요하다면
언리얼 엔진 구조가 더 자연스러울 수도 있습니다.
즉, 중요한 것은 어떤 엔진이 정답인가보다, 왜 그런 구조를 선택했는지를 이해하는 것입니다.
게임 엔진 구조를 바라보는 관점이 중요하다
처음에는 GameObject와 Actor가 단순히 이름만 다른 객체처럼 느껴질 수도 있습니다.
하지만 조금 더 깊게 들여다보면, 두 엔진이 객체를 바라보는 관점 자체가 다르다는 것을 알게됩니다.
그리고 이런 차이를 이해하기 시작하면,
왜 최근 게임 엔진 구조가 지금과 같은 방향으로 발전하고 있는지도 조금씩 보이기 시작합니다.
즉, 최근 게임 엔진 구조 변화는 단순한 구현 차이가 아니라,
복잡도를 어떻게 관리할 것인가에 대한 고민과 연결되어 있다고 볼 수도 있습니다.
마무리
유니티의 GameObject와 언리얼 엔진의 Actor는 겉보기에는 굉장히 비슷해 보일 수 있습니다.
하지만 실제로는 객체를 바라보는 방식과 엔진 철학이 생각보다 꽤 다릅니다.
유니티는 비교적 순수한 Component 조합 구조에 가까운 방향으로 발전했고,
언리얼 엔진은 Actor 중심 구조와 Component 구조를 함께 사용하는 방향으로 발전했습니다.
그리고 이런 차이는 게임 엔진이 복잡도를 어떻게 관리하려고 하는가와도 깊게 연결됩니다.
게임 엔진 구조를 공부하다 보면 단순히 API 사용법보다, 왜 이런 구조가 등장했는지를 이해하는 것이 점점 더 중요해진다는 것도 느끼게 됩니다.
👉 게임 엔진 구조를 더 깊이 이해하고 싶다면
아래 강의를 통해 직접 구현해보는 것을 추천드립니다.
👉 C++로 만드는 게임 엔진 프레임워크 강의 바로가기