[내배캠] TIL : 언리얼과 유니티 비교

간단한 공피하기 2D 게임을 만들었다. 강의에서 만드는 방법을 자세하게 설명해준다. 강의를 듣고 유니티를 처음 사용해본 입장에서 느낀 점을 언리얼과 간단히 비교해보자. 아직 유니티로는 2D 게임만 건들여봤기 때문에 수준 높은 비교는 되지 않겠지만 기본적인 틀에 대해서 이야기해보려고 한다.

 

개발 방법

 유니티는 먼저 씬에 게임 오브젝트를 배치하고, 배치된 오브젝트에 컴포넌트를 붙여가며 게임을 완성하는 방식이다. 재사용이 필요한 오브젝트만 따로 프리팹으로 만든 다음에 사용한다.

 그와 비교해 언리얼은 유니티의 프리팹과 유사한 블루프린트를 먼저 만든다. 하나의 완성된 객체를 먼저 만든 다음, 유니티의 씬에 해당하는 레벨에 블루프린트로 객체를 배치한다. 이것을 액터라고 부른다.

 물론 언리얼에도 컴포넌트를 붙여서 블루프린트를 완성하긴 하지만 C# 스크립트가 컴포넌트로서 게임 오브젝트가 분리되어있는 유니티와 다르게, 언리얼의 모든 구성 요소는 C++ 또는 수준 높은 비주얼 스크립팅을 제공하는 블루프린트로 스크립트를 작성할 수 있다.

 

유니티의 좋은 점

높은 자유도, 낮은 진입 장벽, 빠른 개발속도가 유니티의 장점인 것 같다.

 먼저 높은 자유도에 대해 이야기해보자. 만들고 싶은대로 어떤 제약에 구애받지 않고 그냥 만들면 된다. 초심자에게는 크게 와닿지 않을 수 있겠지만 높은 자유도는 엄청난 장점이다. 수많은 개발 도구들은 일정한 형식을 강제해 내 개발 방식에 제한을 만드는 경우가 많은데, 적어도 아직까지 유니티에서는 그런 점을 느낄 수 없었다.

 제한이 적다는 이야기는 곧 진입장벽이 낮다는 이야기다. 필수로 알아야 할 내용이 많지 않아 적은 학습량으로도 꽤 괜찮은 퀄리티의 작업물을 만들어낼 수 있다는 뜻이다.

 빠른 개발속도도 엄청난 장점이다. 자유롭고 제한도 적으며 진입장벽도 낮은데 빠르게 만들지 못할 이유가 없다.

언리얼의 좋은 점

블루프린트의 비주얼 스크립팅은 압도적인 편리함을 제공한다. 대부분의 상황에서 권장하는 개발 방법이 존재하고, 에픽 게임즈에서는 프레임워크로 사용할만큼 매우 훌륭한 LyraSampleGame라는 샘플 프로젝트를 제공하기 때문에 개발 방법론에 대해 고민할 필요가 없다. 

유니티의 단점

 UI 캔버스는 정말 구리다. 차라리 따로 에디팅 화면을 제공해주는게 좋지 않을까? 도대체 왜 씬 화면을 축소하고 그 위에 캔버스를 그리게 만들어둔 것인지 전혀 이해할 수 없다. 만약 씬 화면이 캔버스만큼 큰 게임을 만든다면 실제 게임 화면과 에디팅 화면의 괴리 때문에 개발에 문제가 생길 수 있을 것 같다.

 만드는 게임의 규모가 커진다면 높은 자유도만큼 개발자의 책임도 덩달아 커지게 된다. 게임을 만들 때에는 항상 구조를 변경해야 하는 상황이 있기 마련인데, 이때 개발자의 숙련도가 낮다면 엄청난 스파게티 코드와 마주해야 할 수 있다.

언리얼의 단점

보일러플레이트 코드를 많이 작성해야 한다. 간단한 기능 추가도 비교적 많은 작업량이 필요하기 때문에 귀찮다.

파일 관리 시스템이 진짜 별로다. 파일 이름이나 클래스 및 함수 이름 변경에도 리디렉터의 존재 때문에 많은 불편함이 있다. 언리얼에서 사용하는 모든 파일은 .uasset 이라는 새로운 확장자로 변경되고 관리되어 드래그 앤 드롭으로 파일을 추가하지 못한다. 좋게 말하면 원본 파일 보호지만 나쁘게 말하면 쓸때없는 래핑이다.

비주얼 스크립팅은 엄청난 장점이지만 바이너리 파일이기 때문에 git으로 변경사항을 추적하기 매우 어렵다. 언리얼 내 비교 툴이 존재하나 아직 개발단계인지 완벽하게 추적하지는 못한다.

 

총평

굳이 비유하자면 언리얼은 공장형 인테리어, 유니티는 셀프 인테리어다. 언리얼은 여러 제약과 정해진 방법대로 해야하는 스트레스가 있지만 그만큼 퀄리티가 보장되고 규모가 커져도 생산성에 별로 영향이 없다. 그에 비해 유니티는 생산성에 영향을 미칠 가능성이 있지만 초반 생산성이 언리얼과 비교해 높다고 할 수 있다.