유니티 엔진과 언리얼 엔진 4 소감
유니티 엔진을 몇년을 써봤고, 언리얼 엔진 4을 써본지는 아직 2년 좀 안된거 같다. 그간 둘다 열심히 써본 경험을 어느정도 남겨두는 것이 좋겠다고 생각했다. 이 둘을 1:1로 비교해보기보다는 유니티 엔진에서 UE4로 경험을 이동시키면서의 느낀점을 정리했다고 보는 것이 더 알맞을듯 하다.
- 적어도 엔진을 가볍게 사용하려하진 않았다. 유니티 엔진을 사용할땐 자세히 알아보는데에 다소 한계가 있었지만, 최대한 동작 방식을 파악하며 사용하려고 했다.
- UE 4는 많은 부분 이미 이전 버전부터 내려온 구조가 많다고 들었다. UE4 이전 버전의 엔진을 다뤄보지 못했다.
- 유니티 엔진을 다룰때는 4.X 대를 주로 다뤄봤고 UE4 는 4.1X 부터 쓰고 있다.
- UE4 를 알아가는 것은 현재 진행형이다. 여기에 적은 내용들은 바로 내일 생각과 느낌이 바뀔 수 있다.
- 개인적인 경험의 한계가 분명히 있다. 그간의 경험에 대한 소감을 정리해보는 것이지 내 생각이 엔진을 정의하는 근거가 되지 않는다.
두 엔진은 지향하는 점이 다소 다른 방향으로 시작했는데, 분명 엔진이 발전하는 과정에서 서로 양방향으로 많은 영향을 주었다. 지향하는 점이 많이 다르면서도 비슷해져가기도 하고, 어떤 면에서는 궁극적으로 떨어져있다.
유니티 엔진
처음에는 나도 코드를 다루던 프로그래머에게는 거부감을 줄 수 밖에 없는 유니티 엔진에 거부감을 가지고 있었다. 하지만 현실적으로 유니티 엔진에 대한 (당시 디렉터의) 선택은 매우 좋은 선택이었고, 개발하는 당사자도 쓰면 쓸 수록 유니티 엔진의 많은 장점에 대해 좋은 인상을 받게 되었다. 거기에 당시에는 잘몰랐던 C#의 위대함도 알게 되며 결과적으로 둘은 좋은 조합이었다.
유니티 엔진에 대한 장점을 마저 적자. 컴포넌트 시스템은 어느정도의 단점은 있지만 결국 생산성의 향상을 가져온것은 맞다. 의외로, 아니 당연하게도 컴포넌트 갖다 붙이기만으로 게임이 만들어지는 경우는 거의 없지만, 그 컴포넌트 시스템 안에서 C#으로 필요한 구현을 하는 것은 제법 괜찮은 방식이다. 결과적으로 유니티로 게임을 만드는 것은 좋은 방법이다.
하지만, 프로그래머에게는 유니티가 그렇게 좋은 환경은 아닐 수 있다. 일반적으로 프로그래머는 무엇을 만들기도 하지만, 그 만드는 과정에서 많은 것을 배우고 발전해나간다. 구현의 벽이 막혔을 때, 버그가 나서 원인을 찾아보면서 배울때, 남이 짜놓은 코드(엔진)를 보고 욕하고 감탄하며 배우면서 많은 것을 배운다. 하지만 유니티로 만드는 것은 프로그래머의 배움에 있어 많은 한계가 있다.
원인은 뻔하다. 엔진 코드가 없고, 혹시 어떤 경유로 소스가 있다 하더라도 커스텀 빌드를 못해서 디버깅을 못하는 상황 때문이다. 이 제약은 프로그래머 발전을 크게 저해한다. 물론 유니티로 게임을 만든다 하더라도 프로그래머는 일이 많다. 하지만 대체적으로 상위 레벨에서의 일들이지 게임 엔진에서의 일들이 아니다. 게임 엔진에서 어떤 일어나는지 알 수가 없거나, 이미 알아야 이해가 가거나, 아니면 우회를 해서 추측해내야 한다. 프로그래머에게 있어서 이런 경험은 불편함을 떠나서 발전을 저해한다.
엔진 코드를 볼 수 없어서 도무지 원인을 알 수 없는 경우 대안은 우회하기 밖에 없다. 이 ‘우회하기’는 프로그래머에게 안좋은 습관을 만들어 줄 수 있다. 우회하기 방법 자체가 나쁜 것은 아니다. 때로는 여러 고민 없이 빠른 포기 후 다른 방법을 찾는게 좋을 때도 있다. 실제로 때로는 유니티로 개발할때 편하기도 했다. 즉, 포기하면 편하다. 단지 우회하기는 문제를 해결하는 여러 방법 중 하나인데, 이 방법이 유일한 대안이라는 것은 프로그래머에게 큰 독이 된다.
언리얼 엔진 4
유니티 엔진의 장점(혹은 단점) 중 하나는 노출된 API가 철저히 분리 되어 있다는 점이다. 엔진에 손을 댈 수가 없으니 노출 되어 있는 것들만 사용해야하니 당연하다.
UE4는 전혀 그렇지 않다. 이 점이 내가 UE4로 옮겨 오면서 가장 잘못했던 것 중에 하나다. 최대한 노출 된 API에서만 작업을 하고 가급적 로우레벨에 대한건 (물론 필요할땐 코드를 살펴보고 수정은 하더라도) 접근하지 않는 쪽이 에픽에서 의도한 것이 아닐까 생각했다. 매우 큰 착각이었다. UE4는 결국 옛날 버전의 엔진부터 내려오는 엔진일 뿐이고, 큰 변화가 있다 한들 근본적으로는 (유니티 같이) 완전히 새로운 엔진은 아니다.
게임을 ‘제대로’ 만들기 위해 로우레벨을 보고 파악을 한다는 것은 단점이자 장점이다. 장점은 위에 유니티의 단점으로 꼽은 것들에 대한 반대일테고, 단점은 엔진이 방대해서 살펴보는데 오래 걸린다는 것이다. 어디까지 봐야하는지 판단을 내리기가 쉽지 않다. 즉, 내가 원하는 것을 하기 위해 얼마나 밑바닥까지 내려가야하는지 알기 어렵다는 것이다. 물론 옆에서 누군가가 여기까지 봐 라고 딱 집어준다면 한결 수월하겠지만.
소스가 방대해서 만약 회사가 아닌 개인이라면 엔진 소스를 수정해가며 테스트 하고 엔진을 알아보는 것은 진짜 굉장한 정신적 노동을 필요로 한다. 개인이라 IncrediBuild 같은 툴의 도움도 못받는다면 그 길고 긴 엔진 컴파일 시간을 다 집중력 깨뜨리는데에 날려먹어야 한다. IncrediBuild 없는 빌드는 상상 이상으로 길고 끔찍하다.
에픽에서는 블루프린트만으로도 게임을 만들 수 있다는 것을 큰 ‘셀링 포인트’로 노리고 있다. 하지만, 뭐 먼 미래에는 어떻게 될지 모르겠지만 아직은 너무도 힘들다. 주변에서 들은 얘기, 그리고 팀에서 직접 겪고 있는 바로는 그냥 블루프린트는 최대한 안쓰고 어느정도의 보조 툴 대용(파라미터 변경용)으로 쓰는 편이 현명하다. 각종 오류와 디버깅 이슈가 너무나 크다.
렌더링
주 분야가 렌더링이다 보니 이 분야만 좀 더 적겠다. 의외로 유니티에서의 렌더링이 자유도가 높은 경우가 있다는 것은 매우 의외의 발견 중 하나이다. 정확히 말하자면 UE4 에서는 기본적인 기능에서의 자유도는 극히 제한적이다. PBR + 디퍼드 엔진의 제약안에서1 다양한 것을 시도해보기가 너무 어렵다. 쉐이더 노드는 전혀 자유도를 주는 영역이 아니고 편리함을 주는 영역이지만, 쉐이더 코드를 어느정도 짜본 사람이라면 쉐이더 노드가 딱히 편리함도 주진 않는다는 점을 공감할 것이다.
쉐이더의 로우레벨에서는 이 특성이 역전 된다. 유니티에서는 엔진 속으로 파고 들어갈 핵심 기술에 대해서는 구현 못하는 경우가 대부분이다. 할 수 있다 한들, 성능에 매우 취약한 환경에서는 별로 추천할 수 없을 것이다. 반면 UE4에서는 얼마든지 구현할 수 있다는 장점이 있다. 물론, 진짜 문제는 구현할 수 있느냐 아니냐가 아니다. 구현해 놓으면 에픽에서 추후에 기능을 탑재해서 헛수고로 만드느냐를 판단하는 것이기도 하다.
이러한 특성을 종합해보면 테크니컬 아티스트에게는 아마도 유니티가 더 좋을 것이다. 쉐이더 코드로 이것저것 해보기 좋다. 하지만 프로그래머에게는 UE4가 월등히 좋다.
그래픽스/렌더링 프로그래머에게는 유니티가 허용하는 영역보다 아래에 있는 영역들도 매우 중요하다. 어떤 파이프라인이고, 어떤 순서로 렌더링 되고, 어떤 기법을 썼고, 거기서의 성능이 어떤 영향을 주고 어떤식으로 배치를 하며 등등… 엔진을 보고 배우거나 수정해보고 직접 짜보면서 배워야 할 영역이 크다.
어떤 사람에게는 유니티를 쓰면 이런 것을 신경 쓰지 않아서 좋을 수 있겠으나, 프로그래머에게는 아무런 공부가 되지 않는 독이 될 수 있다.
종합
너무 단점만 적었나 싶다. 뭐, 장점은 많고 그건 각 회사에서 열심히 홍보를 하니 굳이 적을 필요는 없을것도 같다. 둘다 훌륭한 엔진은 맞다.
나는 분명 유니티 엔진과 같은 ‘쓰기 쉬운 엔진’의 발전도 환영한다. 물론 우리나라에서 흔히 보는 것처럼 뭐가 핫할때 모든 방향이 거기로만 향하는 것은 많이 아쉽긴 하지만, 그건 엔진이 잘못이 아니지 않은가. 어쨌건 게임 개발은 좀 더 쉬워지는 것은 옳은 방향이다.
하지만 인간의 욕심은 끝이 없어서 아무리 게임 개발이 쉬워져도 언제나 더 어렵고 복잡한 것을 만들려고 할 것이다. 인간의 욕심은 끝이 없다. 쉬운 엔진으로 조금이라도 어려운 것을 만들려고 하면 더 어려워진다. 조금이라도 어려운 것을 하려면 성능이나 기능상 한계가 생긴다. 설령 추후에 유니티 엔진을 뜯어 고칠 수 있게 된다 하더라도 이 문제는 여전할것이다. 추상화가 잘 되어 있는 만큼 그 추상화를 깨트리려 하면 더욱 복잡한 문제에 봉착하게 된다2.
이처럼 조금이나마 쉬워진 개발의 이점을 이용하여 게임 개발자의 바람직한 욕심으로 더 개성있는 게임을 개발하려 하는 곳이 있다는 것은 그나마 긍정적인 측면인 반면, 한편으로 그렇지 않기도 하다. 유니티 엔진 등으로 게임 개발이 쉬워지면 더 다양한 아이디어의 게임이 나올것이라 기대했지만 게임들을 살펴보면 별로 그렇지 못한 것도 같다. 실상은 그저그런 게임들을 더 쉽게 만들어 내려고 하는 경우도 많다. 즉, 독창적인 게임이 딱히 엔진을 가리지 않고 다양한 곳에서 나오는걸 보면, 게임 개발이 쉬워지는 것과 독창적인 것은 별로 관련이 없지 않나 생각이 들기도 하다.
끝으로 적어도 프로그래머에게는 유니티가 좋은 공부거리가 아니라는 점 만큼은 다시한번 강조하고 싶다. 프로그래머가 필요 없는 쉬운 게임 개발도 좋다. 하지만 그런 시대는 아직 멀었고, 여전히 프로그래머는 필요하고, 프로그래머가 발전할 거리는 많이 남아 있다. 유니티와 에픽의 Siggraph/GDC 발표 자료들을 보면 게임 업계는 여전히 발전 중이다. 요즘 유니티 본사의 움직임도 심상치 않다. 훌륭한 인재를 다방면으로 열심히 영입중이다. 그렇게 훌륭한 인재들이 엔진을 개발하는데, 게임 개발자들은 유니티를 사용함으로써 그것을 배울 수 없고, 더 격차가 벌어진다면 아이러니하고 안타까운 상황일 것이다.