이번에 AIController를 다루는 섹션에 들어가게 되면서 갖게 된 고민이 있다.
'Controller는 왜 Actor지?'
Actor는 언리얼을 대표하는 객체답게 다양한 기능을 제공한다. Tick, BeginPlay, EndPlay, OwnedComponent 등 직관적으로 이해할 수 있으며 강력한 기능들이 있다. 뿐만 아니라 멀티 플레이 환경에서 동기화를 쉽게 보장해줄 수 있는 Replicate 기능도 제공한다.
하지만.. 생각해보면 모든 Actor가 이런 기능을 필요로 하진 않는다. 월드에 배치할 객체 모두가 Tick이 켜져있고, 모두 Replicate된다면 정신나간 트래픽을 갖게 될 거다. 그럼 회사 망한다. 따라서 Tick을 끄는 기능이나 Replicate를 끄는 기능들이 제공되어 최적화에 도움을 준다. 여기까진 그럴 수 있겠다 싶다. 하지만 Actor의 기능을 좀 더 살펴보면 '어?' 싶은 게 있다.
데미지 수신, Overlap 이벤트, 마우스와 터치에 반응하는 델리게이트 등이 선언되어있다. 그리고 Controller는 Actor를 상속받는다. Controller는 월드에 존재하긴 하지만, 실체는 없다. 메쉬 혹은 스켈레탈 메쉬 컴포넌트와 콜리전은 Pawn이 갖고 있고, Controller는 그 객체에 빙의해 '조작에 대한 처리'를 담당하는 클래스다. 즉, 위에 있는 것들 대다수가 쓸 일이 없다.
'아 이거는 좀..'
자식 클래스가 안 쓸 기능인데 부모 클래스가 갖고 있다? 이렇게 짜면 욕을 한 바가지로 먹을 수도 있다. 한두 개도 아니고.. 이게 뭔가 싶다. 하지만 언리얼의 설계 철학을 들어보면 그럴 법하다.
'언리얼은 이미 충분히 복잡하다.'
제일 쉬운 블루프린트 강의만 봐도 알아야 할 게 산더미다. 게임 개발이란 것 자체가 흥미를 끌만한 구석이 있으니 도전하는 사람이 많다. 때문에 진입장벽이 낮아보일 수 있는데, 실상은 그렇지 않다. 실제로 유니티나 언리얼 덕분에 진입장벽이 낮아지긴 했으나, 게임 개발은 운영체제 개발과 더불어 최고 난이도의 분야라고 평가받는다.
물리, 그래픽, 실시간 네트워크 등 다양한 기술이 혼용되며, 유저의 피드백을 받아 지속적으로 유지보수할 것을 고려해 구조를 작성해야 한다. 단순히 문을 여는 기능 하나에도 역운동학이 필요하고, 카메라는 어떻게 움직여야 몰입감을 해치지 않으며 어쩌고 저쩌고.. 절대로 쉬운 영역은 아니다.
그런 영역에 뛰어들어 프레임워크를 만들고 직관화시켜, 진입장벽을 낮추기 위해 제작된 물건을 '효율적인 구조'라는 잣대로 복잡하게 만들면 본말전도다.(절대로 효율적인 구조가 나쁘다는 얘기가 아니다.)
그래서 에픽게임즈는 적당히 타협한 거다.
효율적인 구조를 포기하더라도, '직관적인 구조'를 챙기기로.
월드에 존재하는 대부분의 객체가 Actor로 이루어져있다면,
필요없는 기능은 끄는 걸로 최적화할 수 있다면,
정갈하고 이상적인 구조보다 실무에서의 직관성을 가져갈 수 있다면,
개발자들의 학습 곡선은 완화되고, 더 쉽게 개발할 수 있을 것이다.
'그래서 결론은?'
언리얼은 '효율적인 구조'를 포기했다.
그에 따라 '효율적으로 개발'할 수 있는 환경을 만들어냈다.
언리얼이 제공하는 클래스에 좀 쓸모없는 기능들이 있어도 신경 끄자!