Today I Learned - Day 72 ['오브젝트' 풀의 난점]

유니티로 프로그래밍을 하다 보면은 자주 사용하게 되는 것이 바로 오브젝트 풀이다.

공격 오브젝트 부터 시작해서 몬스터 오브젝트 등, 생성과 파괴가 잦은 것들은 일단 오브젝트 풀에다가 넣어버리게 되는 것이 보통이다 보니, 별 수 없지 않나 싶다.

 

다만, 이 오브젝트 풀에도 난점은 있다.

간략하게 알아보자.

---

'오브젝트' 풀

오브젝트 풀에 대해서는 일전에 정리한 바 있다.

[참고 URL: https://lsu0503.tistory.com/84]

 

일반적으로 오브젝트 풀을 설명할 때에는 게임 오브젝트를 풀의 내용으로 기술하는 경우가 많다.

그도 그럴게, 그렇게 하면 굳이 다른 작업을 할 필요 없이 오브젝트 풀을 구현할 수가 있으니까.

그렇다 보니 오브젝트 풀을 처음 접하는 경우에도 GameObject 기반으로 만드는 경우가 잦다.

다만, 이렇게 만들면 오브젝트 풀의 이점을 절반 만 활용하는 꼴이 된다.

지금 부터 정리 해 보자.

---

GameObject = GetComponent

자, 소제목을 보면 알겠지만 GameObject 변수의 가장 큰 난점은 바로 GetComponent다.

GameObject는 그 자체로 동작을 제어할 수가 없다. 때문에 그 안에 속해있는 '컴포넌트'를 활용해야 하는데, 이 컴포넌트를 가져오는 과정, GetComponent가 유니티 안에서도 꽤나 무거운 동작 중 하나다.

일전에 GetComponent 최적화에 대해서도 작성한 적이 있을 정도로, 이는 최적화에 매우 중요한 요소로 작용한다.

[참고 URL: https://lsu0503.tistory.com/121]

 

자, 그러면 문제를 정리해 보자.

오브젝트 풀을 GameObject 기반으로 작성하게 된다면, 이 GetComponent를 반드시 수행해야 한다.

분명 생성과 파괴의 연산을 줄이려고 쓰는 기술인데, 정작 생성 과정에서 존재하는 무거운 연산은 그대로 남아있다는 이야기다.

실제로 오브젝트 풀의 내용을 복합적으로 사용하는 구성이라면 이러한 GetComponent에 의해서 시스템 부하가 꽤 많이 일어난다. 그렇다고 복합 구성을 아주 안쓰는 것도 불가능하기 때문에, 가능하면 예방하는 것이 좋을 것이다.

---

[2024.12.27 수정] 컴포넌트로 오브젝트 풀을 활용하자.

자, 이제 해결법을 알아보자. 예상외로 간단한 내용이다.

그냥 오브젝트 풀을 GameObject가 아닌, Component로 구성하면 된다.

그러면 굳이 GetComponent를 할 필요 없이 해당 오브젝트를 제어할 수 있으면서도 gameObject를 통해서 게임 오브젝트에도 접근이 가능하다.

물론, 이렇게 구성하는 경우에는 반환형이 고정된 형태가 아니니까 당연하게도 제너릭을 사용해야하는 등, 

[2024.12.27 수정. 본래 작업 구상을 한 뒤에 작성한 내용이었는데, 실제 작업을 해 보니까, 제너릭 클래스로는 구현이 불가능했다.]

오브젝트 풀의 기반으로 활용하기 위한 부모클래스를 두고 해당 부모클래스의 자식 클래스를 가지고 있게 만든다거나, 오브젝트를 가져오는 함수를 제너릭 반환형으로 둔다거나 해야하는 등, 구조 상의 차이점은 분명히 존재할 수 밖에 없긴 하다.

 

특히 이 방법은 Pacade 디자인 패턴과 궁합이 좋다.

Pacade에 해당하는 컴포넌트를 오브젝트 풀으로 작성한 다음, Pacade를 통해서 각 컴포넌트에 접근할 수 있으니 말이다.

물론, 당연히 주의는 해야한다. GameObject라는 공통된 기준을 활용하는 게 아니니 만큼, 이 차이점에 의한 오류는 당연히 발생할테니 말이다.