이번 시간엔 ECS와 Job, Burst에 대해 알아보려 합니다.
그전에 알아봐야할 OOD에 대해 간단하게 설명해보려 합니다.
OOD란?(Object Oriented Design)
- 속성, 기능을 하나로 묶어 객체로 표현하고 이 객체를 기반으로 점차 확장, 연결하여 다양하고 긴밀한 객체들을 개발합니다.
이러한 방식은 개발자가 의도한대로 빠른 개발이 가능한 장점이 있지만 여러 문제점이 있습니다
객체 지향 디자인의 문제점
- 기능이 추가 될 때마다 구조가 복잡 : 새로운 객체들이 생길때마다 점점 늘어나기 때문
- 과거 개발 히스토리를 파악해 두어야함 : 위에 설명한 것처럼 새로운 것들이 생길때마다 늘려가기 때문에 과거 히스토리를 모르면 어려울 수 있음
- 연산처리가 객체 중점 : CPU보다는 메모리를 많이 사용하며 CPU는 빠르게 발전하지만 메모리는 CPU에 비해 발전이 느린 상태
DOD의 등장
위와 같은 OOD의 문제점을 해결하기 위해 연산 중심의 효율적인 디자인이 DOD(Data Oriented Design)가 나타나게 되었습니다.
- 잉여 자원이 많이 남는 CPU를 적극적으로 사용하여 성능을 끌어올릴 수 있는 디자인
- OOD와 다르게 각 개별로 나누어 데이터로 모아 CPU로 전달하는 방식으로 병렬 처리, 모듈화 등 좋은 장점들이 많습니다.
단, 기존 개발 방식과 너무나도 다르며 난이도가 수직 상승(마치 컴퓨터와 같은 생각으로 개발)
DOTS의 종류
Sparse Set(대표 방식)
- 엔티티를 구성하는 각 구성요소 별로 묶어 관리하는 방식
Archetype
- 엔티티의 조합 타입별로 묶어서 관리하는 방식
- 메이저 게임 엔진에서 주로 채용된 방식으로 동일한 조합의 형태만 모아 빠르게 접근하도록 관리하는 DOTS방식
ECS(Entity Componet System)
- GameObject와 호환되는 데이터 지향 프레임워크로서 고성능의 제어 및 결정성으로 더욱 스케일이 큰 컨텐츠를 만들 수 있습니다.
엔티티 하이라이키
- 유니티 ECS는 병렬처리를 위해 SubScene으로 나눠져 있으며, 일반적인 하이라이키에서 볼 수 없고 엔티티 하이라이키에서 볼 수 있습니다.
시스템
- 컨텐츠에 존재하는 엔티티들의 활동을 실시간으로 확인할 수 있는 인터페이스
- 각 엔티티들의 활동 개수, 처리 시간을 확인할 수 있으며 퍼포먼스의 비중을 편리하게 분석할 수 있음
(참고영상에 보면 메가시티에서 10000개가 넘는 것들을 1초안으로 처리하는 모습을 볼 수 있음)
컴포넌트
- ECS 구축을 위해 작성한 모든 DOTS 컴포넌트 목록을 확인할 수 있는 창
- 게임의 규모가 크면 클수록 점점 늘어남
아키타입
- ECS, 유니티 DOTS의 가장 중요한 정보로서 데이터 그룹을 결정하는 아키타입들의 목록을 확인할 수 있고 자세히 분석이 가능함
- 컴포넌트가 많이 붙어있을수록 점점 무거운 아키타입이 됨
(아키타입은 개발자가 직접 설정하는 것이 아닌 컴포넌트를 적용하면 유니티에서 자동으로 설정함)
결론
- ECS는 CPU 연산 능력 활용도가 높아 높은 성능을 보여주지만 구현하기 위해선 많은 것을 배워야하고 아직 22년 기준으로 유니티 컴포넌트를 100%활용하기엔 아직 업데이트가 필요한 상황입니다.
정리
- ECS는 DOD기반이며 OOD보다 CPU 연산 능력 활용도가 높아 높은 성능을 끌어낼 수 있습니다.
- Unity에서는 Archetype으로 사용되고 있으며 Archetype은 구성요소별로 나누는 것이 아닌 비슷한 것 끼리 그룹별로 모아 처리 하는 방식입니다.
- Unity에서는 병렬처리를 위해 SubScene을 이용하고, ECS Component는 기존 Component와 달리 Inspector 뷰 방식이 다릅니다.
*추후 샘플과 함께 실습해볼 예정
참고영상 : 바로가기
'유니티 > 유니티 이론' 카테고리의 다른 글
[이론] 렌더 파이프 라인 (5) | 2025.06.23 |
---|---|
[이론] 에셋 번들 (2) | 2025.06.18 |
[이론] Addressable (0) | 2025.06.15 |
[이론] UniTask (3) | 2025.06.12 |
[이론] async/await (0) | 2025.06.11 |