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