언리얼 엔진 vs 유니티 엔진
1. 개요
이 문서는 언리얼 엔진과 유니티 엔진의 특징을 비교한다.
2. 스크립트 언어
2.1. 언리얼 스크립팅
초보적인 프로그래머들로만 구성되어 있는 팀의 입장에서 본다면 언리얼 엔진 4는 스크립팅 언어로서 새로운 언어를 배워야 하는 부담을 없애기 위해 언리얼 엔진 3까지 써오던 Java 스타일의 UnrealScript를 제거하고 보다 대중적으로 다가서기 위해서 게임 프로그래머들에게 익숙한 C++를 채용했다.[1]
언리얼 엔진 4는 아래에서 언급될 비주얼 스크립팅 언어인 블루프린트와 프로그래밍 스트립트 언어를 함께 사용하여 복잡한 구조나 퍼포먼스가 필요한 부분은 프로그래밍 언어로 구성하고, 가변성이 높은 부분은 디자이너가 간단히 변경할 수 있게 블루프린트로 구성하여 상호 보완적으로 활용 가능하다. 때문에 타 직군과의 협업이 굉장히 원할하다.
한편, 언리얼 C++의 경우는 공식적으로 핫 리로드를 지원한다고는 하지만 실상은 유명무실하다. 기존 엔진에서 상속받을 스크립트부터 찾아야하기에 스크립트 추가시 거의 반드시 엔진 컴파일 과정이 추가된다. 이는 C++ 각 객체별로 컴파일을 할수 있는것이 아니기 때문에, 엔진에서부터 시작한 상속받은 스크립트 전부 다 컴파일이 진행되어야 사용 가능하기 때문이다. 언리얼의 다양한 기능도 되려 핫 리로드를 구현할수 없을 지경으로 분할되어있는것도 한몫한다. 간단하게 되어야할 추가 모듈부터 엔진단에 포함되어야 실행되기 때문에 옆동네에서는 그냥 소스 가져다 놓으면 되는걸 엔진을 통으로 컴파일을 진행해야 하는 불상사가 생긴다. 때문에 에디터상에서 컴포넌트를 즉각 붙이는 행위를 막아놓았으며, 해당 문제를 에디터상에서 해결하기위해서는 블루프린트로 재 생성한뒤 수정해야한다. 즉, 블루프린트 기능은 유니티보다 타 직군과의 연계작업을 우월하기 위해 만든 기능이 아니라, 실상은 컴파일 횟수를 조금이라도 줄이기 위해서 만든 수단으로써 출발했던것이다. 이는 언리얼 엔진의 작업속도를 늦추는 요인으로 꼽힌다.
그런 블루프린트 자체도 빠른편이 못된다. C++로 코딩했을때 20ms인 코드가 블루프린트로만 작성했을때는 상황에 따라 5~15배 느린 100ms~300ms의 속도차이가 발생하는 경우도 더러 있다. 그래픽 직군에서 쉐이더 적용이나 기획쪽에서 프로토타입 적용에 유용하게 사용 가능하지만, 개발직군에서는 100% 블루프린트 코드를 짠 게임은 있을수도 없으며 정말 존재한다면 사실상 개발자를 뽑을 이유가 없고, 최적화를 위해 반드시 C++코딩이 필요한데 C++코딩은 상술했듯이 상당히 공과 시간을 많이 들여야 한다.
물론 그렇게 나온 결과물은 배신하지 않을정도로 상당한 퀄리티를 보장한다.
언리얼 엔진은 2015년 3월 이후 버전 4의 소스 코드 전체(지속적으로 업데이트되는 버전 역시 항상 전체 소스 코드 공개)를 공개한다는 점은 굉장한 강점이다. 복잡한 코딩이 가능한 프로그래밍 전문가가 있는 팀의 경우에는 여러모로 언리얼 엔진이 훨씬 더 낫다. 언리얼 C++의 빌드 툴의 지속적인 개선과 엔진을 직접 건드릴수 있는 강점이 있기 때문. 또한 엔진 자체에서도 제공하는 기능이 굉장히 많기 때문에 엔진에 있는 기능만 사용해도 유연하게 해결되는 경우가 상당수이다.
또한, 언리얼 엔진 4 문서에는 언급이 되어 있지 않지만 해외 커뮤니티에서는 C++ 대신 C\#을, 혹은 스크립트 언어인 Lua나 Ruby 등을 언리얼에서 사용하는 방법에 대해 연구하기도 하고 실제로 그러한 스크립트 언어를 사용하여 개발하고 출시한 상용 게임도 있다.
2.2. 유니티 스크립팅
유니티는 C#를 기본 스크립트 언어로 사용한다. C#언어 자체가 C++에 비해 적응이 빠른편이라 비 개발자들도 많이 접근하게 된다.
유니티의 경우 스크립트 생성시 Monobehaviour 만을 상속받아 스크립팅을 하게 만들었다. 해당 파이프라인을 하나로 통일한 덕에 추가적인 기능은 UE에 비해 부족해 컴포넌트 애드온을 필요한 분량만큼 추가해주어야 하지만, 그 대신 컴포넌트를 붙이는데 제약이 적고 수정시 에디터상에 즉각 반영이 되는 Hot Reload 기능이 굉장히 강력하게 구비 되어있다. 주 언어가 C#인것도 한 몫 하는데, 어느 객체를 만들었으면 해당 객체에 대해서만 컴파일이 완료되면 바로 실행이 가능하다. 그렇기에 스크립트의 추가가 굉장히 자유롭고 에디터상에서 직관적이고 즉각적으로 반영이 가능하다. 보통 왠만큼 크지 않는 이상 스크립트를 수정하면 바로 에디터 창으로 돌아와 실행이 가능할정도라 자체 피드백 순환과 QA가 매우 빠르게 처리할 수 있다는 이점이 있다. 이러한 강점은 개별 오브젝트에 눈에 보이는대로 컴포넌트를 붙이면 사용자가 모르는 새 컴파일 되면서 사용 가능한 상태로 바꾸기 때문에, 필요한 요소는 그때그때 만들어 쓸 수 있다는 강점을 가지고 있다.
문제는 비 개발자 작업자에 대한 편의는 적은편이다. 언리얼을 따라 비주얼 스크립트를 개발했지만 사실상 유명무실하며 결국에는 비개발자 인원도 코드를 알아야 정확한 작업을 진행할수 있다. 이는 하단에 유니티 비주얼 스크립팅 문단에 후술한다.
유니티는 엔진 소스 코드를 제공하지 않아 소스 코드를 제공받기 위해서는 별도로 고가의 계약 체결이 필요하다.[2]
때문에 고수준의 작업에서는 자잘한 문제가 발생하고, 이를 피하고 개선하기위해 우회를 반복하다가 어느새 엔진내 소스를 스파게티처럼 만드는 경우도 더러 있다.
3. 비주얼 스크립팅
3.1. 언리얼 블루프린트
프로그래머가 없는 팀의 입장에서 본다면 언리얼 엔진 4에서 새롭게 등장한 블루프린트라는 시각적 프로그래밍 언어를 이용해 블럭들을 마우스로 쭉쭉 이어주기만 하면 코딩 한 줄 없이 프로그래밍이 가능하다. 작동법 하나하나가 매우 복잡하게 되어 있는 블루프린트도 디자이너의 입장에서는 복잡한 세부 구성들을 전혀 이해할 필요없이 최종적으로 보여지는 유저 친화적인 프로퍼티들만을 가지고서 매우 손쉽게 개발을 할 수 있다.
실제로 개발 작업에서 많은 시간이 소요되는 반복처리 및 테스트를 프로그래밍을 전혀 모르는 디자이너들만으로도 가능하게 해 주는 큰 이점이 있다. 물론 전혀 새로운 기능들을 만들기 위해서는 복잡한 세부 블루프린트들을 직접 구성해야 하며 이는 어느 정도의 프로그래밍 지식이 수반되기 때문에 완전히 디자이너들만을 위한 툴은 아니라는 비판도 있었지만, 이는 언리얼 엔진 4가 처음 등장했던 시기의 이야기이고 꾸준한 버전업을 통해 많은 부분들이 개선되면서 초보자의 입장에서도 사용하기 편리하게 구조가 변경이 되었다.
지속되는 버전업을 통한 또 다른 개선점으로는 블루프린트가 단지 스크립팅 부문에만 한정되는 것이 아니라 언리얼 엔진 4 전반에 걸친 모든 기능들이 차차 블루프린트화되어가면서 더욱 유저친화적이면서 직관적이고 편리하게 변해가고 있다.
마켓플레이스에 계속 새롭게 등장하는 다양한 유&무료 블루프린트 애셋들을 활용한다면 프로그래밍을 할 줄 아는 개발자가 전혀 없더라도 많은 기능들을 손쉽게 구현할 수 있다.
3.2. 유니티 비쥬얼 스크립팅
유니티는 기본적으로 C#을 이용해 게임 스크립트를 작성하고 비주얼 스크립팅은 주력이 아니라고 보아야 한다. 낮은 진입장벽의 비주얼 스크립팅과 복잡한 C++을 병행하는 전략을 취하는 언리얼에 비해 C#의 언어적 복잡성은 그 중간 정도에 위치하고 있어 비주얼 스크립팅의 필요성(난이도의 격차)가 상대적으로 적다.
과거 플레이메이커(PlayMaker)라는 서드파티 비주얼 스크립팅 유료 애셋이 있었다.[3] 하지만 언리얼의 블루프린트와 블루프린트 애셋들에 비하면 한참 부족한 수준이다. 애초에 플레이메이커나 애셋 스토어에 있는 비슷한 유/무료 애셋들은 언리얼 블루프린트처럼 엔진의 전반적인 기능들을 제어하는 핵심 요소로서 포함된 수준이 아닌 추가 플러그인 애셋일뿐이고 그런 비슷한 애셋은 언리얼 마켓플레이스에서 볼 수 있는 단순히 블루프린트 애셋이나, 기타 비주얼 스크립팅 에디터 애셋 수준에 불과하기 때문에 언리얼 엔진 4의 블루프린트와는 비교 자체가 성립되지 않는다.
언리얼에 대응하기 위함인지, 2018년 11월에 개최한 Unite LA에서 앞으로의 로드맵을 공개했는데 유니티 2019.2부터의 프리뷰로 시작해서 유니티도 엔진 자체적으로 비쥬얼 스크립팅 기능을 추가한다고 발표했고, 2019년 9월 26일 유튜브에 올라온 로드맵에선 2020.1 버전 프리뷰 영상에선 해당 기능의 추가를 예고했다. 해당 기능은 '''BOLT'''라는 이름으로 추가되었으며, 아직 사용자가 많지 않아 평가는 유보적인 상황이다.
4. 애셋 시장
4.1. 언리얼 마켓플레이스
언리얼 마켓 플레이스는 2020년 기준으로 이제 활성화된지 4~5년 정도로 유니티 애셋 스토어에 비해 절반 정도의 기간이기 때문에 아직까지는 유니티 애셋 스토어보다 규모가 작은 편이다.
주목할만한 점은 개발사인 언리얼 엔진 4의 각종 기술 데모 뿐 아니라 에픽 게임즈에서 직접 개발하다가 중단된 AAA급 게임의 리소스를 공짜로 제공하기에 여러 프로토 타입을 제작하거나 학습에 매우 유리하다.
2015년에는 모바일 게임인 인피니티 블레이드 던전, 2018년에는 무려 1200만 달러(한화로 127억원)의 개발비용이 투자된 파라곤의 리소스를 누구나 다운로드 받아서 사용할 수 있게 풀어서 AAA급 퀄리티를 가진 리소스 제작의 학습뿐 아니라 그대로 사용하던 수정해서 사용하던 해당 리소스들을 상용 게임에 활용하는데도 제한을 두지 않았기 때문에 중소규모의 개발사나 1인 개발자들에게도 엄청나게 큰 도움이 되고 있다.
그리고 퀵셀 메가스캔을 인수하여 지속적으로 고품질의 애셋들을 무료로 공개하고 있다. 또한 상당한 퀄리티를 지닌 이달의 무료 컨텐츠를 5개를 선정해서 매달 무료로 제공하여 학습에 굉장히 유리한게 언리얼 마켓플레이스의 강점이다. 아예 풀 시네마틱이 들어간 프로젝트들도 더러 있으며 파티클이나 레벨디자인을 다룬 프로젝트도 있고 당연하게도 기본적인 메테리얼만 다룬 것도 있다. 전반적으로 상당한 퀄리티의 다양한 프로젝트들을 손쉽게 무료로 받아 참고하여 공부해볼 수 있다.
4.2. 유니티 애셋 스토어
소규모 개발팀이나 1인 개발자들의 입장에서는 엔진용 컨텐츠를 쉽게 구할 수 있는 점에서 2020년 기준으로 약 10년 이상 활성화된 유니티용 컨텐츠몰인 애셋 스토어의 존재와 그 압도적인 추가 에셋의 양은 유니티를 이용하게 하는 결정적인 요소가 되기도 했다.[4] 필요한게 있다면 일단 유니티 에셋 스토어를 검색해보고 나온 결과물과 자신이 만들었을때 비용을 대조해보고 생각하는것이 우선일정도로, 없는게 거의 없다.
엔진 자체가 기능이 정형화되고 안정화에 들어간 지금으로써는 엔진 버젼 업데이트시 기존 리소스가 망가지는 현상도 상대적으로 적은편이다. 기껏 비싼돈을 들여 구매했는데 체계가 바뀌어 쓸모없어지거나 해당 리소스를 쓰기위해 엔진 업데이트를 미루는 일을 줄일수 있다.
유니티 애셋 스토어는 오랜 기간 활성화된만큼 판매되는 애셋의 수가 많으며 이에 비례해서 소규모 개발사나 개인 개발자들을 위한 저렴한 가격의 애셋도 많이 판매되고 있어서 소규모 개발팀이나 1인 개발자들의 좋은 대안이 되어주고 있다.
5. 한국어 지원
5.1. 언리얼 엔진
한국어 지원의 경우 초보자가 보기에 언리얼 엔진이 좀 더 진입장벽이 낮다. 이미 언리얼 엔진 3 시절인 2009년부터 문서 한국어판 지원이 시작되었고 언리얼 엔진 3의 최종 버전과 함께 기본적인 문서들은 대부분 한국어판 작성이 이루어졌다. 언리얼 엔진 4는 지속 버전업 되면서 신기술이 개발되어 감에 따라 새로운 기능들은 한국어 지원이 조금 늦는 감이 있긴 한 편이나 점진적으로 한국어 지원이 이루어지고는 있다. 다만 심층적인 기술 이해가 필요한 부분은 한국어 지원은 진행되지 않는 점도 있어 영어 문서를 참고해야 하는 상황이다. 특히 초보자를 위한 블루프린트는 한국어 레퍼런스와 자료가 있지만 깊이 들어가야 하는 C++ API 쪽은 번역도 미비하고 설명이 부실한 편이다.
언리얼 엔진 4는 엔진 자체도 한국어판이 존재하며 주요 메뉴명이나 기술적인 부분 등 전문용어가 사용되는 부분은 한국어 변환으로 인한 혼란이 초래되지 않도록 완역이 아닌 음역으로 옮겼고 엔진의 설정 메뉴에서 클릭만으로 여러가지 언어로 변경이 가능하다.
5.2. 유니티 엔진
유니티의 경우 공식 튜토리얼 동영상만으로는 진입하는 데 어려움을 느낄 수도 있다. 해외에는 두 엔진 모두 관련 자료들이 넘쳐나지만 국내에서는 공식 카페를 제외하고는 고수준의 개발과정을 다루는 기술 포럼은 찾기 힘들다. 그러나 도서 시장에서는 얘기가 좀 달라지는데, 2016년 기준으로 두 엔진 모두 관련 우리말 서적들이 시장에 출판되고 있다. 양쪽 모두 국내지사에 의해 다양한 행사를 개최한다. 2016년 기준으로 언리얼 엔진 쪽이 더 지원과 행사에 신경을 쓰고 있는 모습을 여실히 느낄 수 있다. 에픽 게임즈에서 직접 올려주는 언리얼 엔진 유튜브 강좌도 꼬박꼬박 한국어 자막이 달리고 있다.
유니티 엔진은 2018년 3월 까지도 한국어판을 지원하지 않고 있다. 공식 문서나 비디오 튜토리얼 등 공식적으로 제공하는 자료들의 한국어 지원도 거의 MSDN을 방불케 하는 언리얼과는 달리 유니티는 부분적으로만 번역된 것이 많으며, 아직도 그냥 번역을 하다 그만둔 수준이다. 국내 중소기업이나 인디 개발팀의 수 많은 소규모 프로젝트들이 유니티를 채택하는 현실을 생각하면 안타까운 점이다.[5]엔진 자체의 한국어판 지원은 언제 시행될지 아직도 미지수다.
6. 작업 생산물 비교
라고 평가 할 수 있다.작업 편의성 및 속도 : 유니티 우위
작업 결과물 : 언리얼 우위
상술한 한국어 지원 - 유니티 문단에서 언급하기도 했지만 작업 편의성은 1인 개발 또는 적은 인원의 개발팀으로 진행되는 소규모 프로젝트일 경우 유니티가 훨씬 유리한 편이다. 또한 작업기간이 짧거나 리소스, 개발인력 및 자금이라는 제한이 걸린경우 유니티 이상의 선택지는 사실상 없다.
언리얼 엔진의 경우는 초기 진입비용이 세지만 그 이후에 드는 비용은 낮다고 볼수있다. 결과물 또한 어느정도 큰 차이를 보이니 최종 결과물에서는 앞서지만, 무시하기 힘든 높은 진입장벽이 존재한다.
엔진 자체의 사양과 무게 차이도 상당하다. 유니티는 비교적 저사양에서 실행 가능하며, 즉시에 가까울정도로 빠르게 컴파일되어 문제가 생기면 빠르게 빠르게 수정이 가능하고 특별히 개발 환경을 크게 세팅할 이유가 없지만, 언리얼 엔진은 사양을 굉장히 타며 상황에 따라 컴파일 한번 하는데도 사양이 낮으면 낮을수록 10분, 20분이상의 시간이 소요되는 경우가 많다. 그리고 그렇게 10분을 기다려 수정본을 실행 했는데 문제가 발생한다면...... 일정 사양이 되지 않는다면 언리얼을 사용하는건 독이 될수 있다.
이는 준비 비용과 생산성에 영향을 끼칠수밖에 없다. 유니티 엔진이 성능상 매우 떨어지는건 누구라도 아는 사실이지만 그만큼 심플하다, 인디게임이나 1인개발, 빠른 개발등 어떤 Cost(인력, 자원 등)에도 맞춰 진행이 가능한데 언리얼은 시작부터 일정 Cost가 준비되지 않으면 프로젝트의 독이 될수 있다. 그리고 사실 같은 Cost라면 유니티도 그렇게 많이 차이나지 않는 퀄리티의 작업물을 내놓을수도 있다.
하지만 그만큼 더 높은 코스트를 유지할수 있다면 언리얼엔진의 결과물이 평균적으로 유니티에 비해 더 좋은편이다. 물론 숙련도에 따라 다르다.
7. 두 엔진의 본질적 차이
흔히 착각하는 것이 두 엔진을 그저 퀄리티나 언어만 다른 비슷한 도구로 생각하는 것인데, 두 엔진의 개발 방식 접근성은 극명하게 다르다.
대표적인 예시로 유니티는 기본 기능이 비교적 빈약하고, 소스를 고칠 수 없는 대신, 기능이 매우 가볍고 사용하기 간편하며 에셋 및 패키지를 구매하거나 덧붙여 보강이 원할하여 추가 모듈을 부착하거나 떼는 식으로 대응한다.
언리얼 엔진은 엔진 자체에서 대부분의 강력한 기능을 제공하지만, 개발사(에픽)의 방향성에 맞춘 기성품에 더 가까워 상대적으로 확장성이 제한된다. 엔진의 성능을 제대로 활용하기 위해서는 고급 인력 또는 방대한 규모의 팀이 필요하다. 당연히 언리얼에도 에셋에 대응하는 플러그인이 존재하지만 이것으로 기능을 늘려나가기에는 한계가 있는데다, 플러그인을 정리하지 않으면 프로젝트 전체가 크래시가 나기 쉬워 적용할때도 상당히 많은 주의를 요한다.
유니티의 경우 입력 메시지의 흐름이나 렌더링 구조를 포함한 엔진의 대부분이 나뉘어져 제각기 접근하고 조립할 수 있다. 예를 들어 렌더링의 경우 쉐이더를 편집한다고 할 때 게임 데이터의 모든 단계를 쉐이더에 사용하고 대부분의 경우 원하는 만큼 충분한 큐잉과 컬링 분류를 할 방법을 제공한다. 대신 그 각각의 기능을 조립하고 옵션을 짜맞추는 것은 개발자의 몫이며, 점점 하이퀄리티로 올라갈수록 Cost또한 장난아니게 높아진다.후반부로 갈수록 퀄리티 상승을 위해 처리해야될 문제들이 산더미처럼 쌓이며, 이는 프로젝트 중후반부에 진입한 게임사들이 언리얼로 전환하는 원인이 되기도 한다.
반면 언리얼의 경우는 회사에서 사용된 엔진으로 시작하였으므로, 상용게임에서 원하는 고도의 추상화가 원래 다 이루어진 상태에서 자유도를 확장시키는 방식으로 범용 엔진으로 만든 것이기 때문에 기본적으로 '에픽 사에서 만든 게임의 아키텍처 대로 만들도록' 되어 있다. 마찬가지로 렌더링의 예를 들자면 원래 주어진 렌더링 파이프라인의 퀄리티는 좋고 원래 제공된 옵션들 중에서 골랐을 대의 편의성은 좋지만 이것을 수정해서 원하는 것을 창조하려고 한다면(예를 들어 카툰 렌더링) 유니티처럼 쉐이더를 갈아끼우는 방식으로는 불가능하고 렌더링 된 결과를 후처리 가공해서 (사실상의 가짜) 효과를 주거나 아예 엔진 소스를 고쳐서 방식을 우회시켜야 한다. 구체적으로는 쉐이더를 바꾸기 위해서 쉐이더를 생성해주는 엔진의 기능인 머터리얼 에디터의 입력인 머터리얼을 변경하는 식으로 간접적으로 변경하고, 그 결과로 렌더링된 최종 결과물을 포스트프로세싱해야 한다. 유니티처럼 '렌더링 자체를 카툰 쉐이더로' 하려면 엔진에서 머터리얼->쉐이더의 생성 코드를 수정해 사용자가 원하는 라이팅 정보를 참조할 수 있도록 만들어야 하며, 라이팅와 연관된 엔진의 다른 여러 부분의 코드들도 그에 맞게 수정해 주어야 한다. 이러려면 당연하게도 쉐이더와 렌더링 파이프라인에 관련하여 프로그래머로서의 상당한 지식을 필요로 하게 된다.
1인칭으로 환경 위에서 캐릭터를 컨트롤하는 구조를 만들려고 할 때, 언리얼이 이미 제공되는(그리고 바꾸기 매우 어려운) 입력->입력 컨트롤러->플레이어 컨트롤러->페르소나 구조를 사용하여 거의 건드릴 것도 없이 상용 수준으로 다양하고 풍부한 조종이 가능한 결과물을 뚝딱 만들어 낼 수 있으나, 그냥 키보드의 W키가 눌릴 때 박스 하나의 좌표가 X방향으로 1m 바뀌었으면 좋겠다는 근원적인 제어를 원할 때 다른 모든 오브젝트 필요 없이 박스 하나를 놓고 스크립트에서 W키->X좌표 +1 이라는 직결구조를 만들 수 있는 것은 유니티이다.
언리얼 엔진 4 초기 버전의 이슈였던 '반투명 물체를 만들기 힘들다' 역시 이러한 구조적 차이[6][7] 때문이다. 반투명 물체의 품질유무가 가장 극명하게 드러나는 것이 머리카락 부분인데, 이 때문에 언리얼 엔진에서 높은 퀄리티로 제작된 여러 작품들이 머리카락 부분만 튀거나 고생고생 해서 여러 우회기법을 적용한 모습을 볼 수 있다. 이러한 차이 때문에, 양 엔진의 에셋 스토어에서 뭔가 고급 기능들을 보면 유니티의 경우 엔진에서 돌아가는 스크립트 코드 혹은 엔진과 함께 돌아가는 플러그인 형태로 제공되는 반면 언리얼의 경우 '엔진의 특정 기능을 커스텀한 것' 이 에셋으로 제공되는 경우도 있다.
언리얼 엔진이 소스코드를 완전히 제공하는데 반해 유니티 엔진은 제한적(코어 부분은 라이센스가 필요하나 요즘엔 대부분의 패키지는 github에 개발 소스코드가 공개되어 있다.)인 것을 보고 전자는 개방적, 후자는 폐쇄적이라고 생각하기 쉽지만 이 역시 엔진의 기초 구조 자체가 다르기 때문이다. 언리얼의 경우 엔진 그 자체는 기성품처럼 제약되고 다듬어진 기능들만을 제공하면서 어느 이상 기능 자체를 확장하고 싶으면 필연적으로 엔진의 C++ 소스 코드 자체를 수정하고 다시 빌드를 하는 쪽으로 나아가게 된다. 엔진 개발사에서도 그쪽을 염두에 두고 권장하고 있다. 반면 유니티의 경우 엔진에서 제공하는 인터페이스만을 가지고도 충분히 확장해 나갈 수 있도록 확장 가능성과 범용성을 목표로 처음부터 설계되어서 엔진 자체를 수정해서 기능을 늘려야 할 필요성이 거의 없다. 유니티는 이러한 취지에서 URP, HDRP 등 렌더링 파이프라인 자체를 사용자가 구성할 수 있는 추가 옵션을 제공하는 등 엔진 자체에서 제공하는 가능성을 확장하는 방향으로 발전해 나가고 있다.
이렇게 유니티와 언리얼은 두가지 엔진에서 이 기능을 할 수 있느냐 없느냐, 단순히 결과물이 멋지느냐 아니냐의 단순한 문제가 아니라, '''어떤 엔진 x 어떤 결과물'''을 원하느냐의 조합에 따라 개발자가 학습해야 하는 정보와 개발하는 경로가 완전히 달라진다는 것을 알 수 있다.
엔진 자체의 보안성에 대해서는 둘 모두 큰 차이가 없다. 일단 유니티는 .NET 기반에 다이나믹 로더를 사용하지만, 그 부분은 게임 로직을 만드는 스크립팅 언어로써 C\#를 활용하는 것이지, 엔진 자체는 C++ 이라서 유니티와 비교해도 큰 차이가 없다. 하지만 게임 로직 코드는 .NET을 사용하는 유니티가 압도적으로 털리기 쉽다.[8] 반면 C++을 이용하는 언리얼 엔진은 게임 로직도 어셈블리로 컴파일 되기 때문에 상대적으로 안전하다.[9] 하지만 요즘은 유니티 역시 C++로 번역 후 컴파일하는 IL2CPP를 지원하고 있고, 최근의 대규모 개발들은 대부분 중요한 비지니스 로직은 서버에 두고, 클라이언트는 서버에서 데이터를 얻어와서 사용하는 구조로 만들어지기 때문에 보안수준은 '''결정적으로 프로그래머가 보안요소를 얼마나 적용하느냐가 결정한다.''' 하지만 싱글 플레이어 게임을 만든다면 언리얼을 쓰거나, 유니티를 쓴다면 중요 코드를 C++로 작성하는 것이 보안에 도움이 될 수도 있다.
8. 전망
불과 몇 년전만 하더라도 인디 프로젝트는 유니티에 비해 언리얼을 이용하는 경우가 드물었으나 2018년 기준으로 스팀에 출시되는 게임들이나 ModDB 등의 커뮤니티에서 확인해보면 인디/소규모 팀에서도 언리얼을 사용하는 빈도도 점점 늘어가고 있음을 알 수 있다. 2012년을 전후로 인디/소규모 게임 개발에 유니티의 급격한 유행 이후 엔진 적응도에서 유니티만을 선호하는 경우가 아니라면 점차 언리얼로 넘어가는 편이고 특히 신규 인디 개발자들은 예전같으면 유니티로 시작했겠지만 규모에 따라 요즘에는 언리얼을 고려하는 경우도 많다.
다만 인디게임이나 2D쪽은 아직까지 실제 개발 과정에서 발생하는 문제에 대한 레퍼런스나 자료는 활용도가 유니티가 많다. 또한 시간 대비 생산성은 유니티가 언리얼보다 우위에 있어 빠르게 프로토타입을 제작하거나 스타트업 1인 개발은 유니티 이상의 선택지는 없다.
3D 중,대규모 프로젝트의 경우 게임의 개발이 유니티로 상당부분 진행됐음에도 불구하고 개발 도중에 유니티의 성능에 한계를 느껴 실제로 엔진의 교체를 추진해서 이미 출시가 됐거나 개발 중이며 이 외에도 다수의 게임들이 유니티로 개발 도중 언리얼 엔진 4로 갈아타거나 최초 기획 단계에서 유니티를 고려했다가 실제 프로젝트의 규모가 커지면 언리얼 엔진 4로 개발되는 경우가 발생하는 케이스도 있다.
언리얼 엔진 4의 그래픽 구현 수준, 그리고 C++ 소스 코드의 자유로운 수정 가능이라는 우위 때문에 유니티는 언리얼 엔진에 서서히 잠식될 것이라는 예상이 많으며, 2016년 중후반까지는 저사양 스마트폰/모바일 게임의 개발에 한해서 유니티가 더 선호되고 있는 추세이나 언리얼 엔진 4의 모바일 지원이 점점 강화되면서 언리얼 엔진을 이용한 모바일 히트작이 하나둘씩 출시되어 가고 또 모바일의 고사양화가 가속화되면 3D모바일에 한해서 언리얼 엔진도 어느정도 많이 쓰이게 될것으로 보인다. 다만 자체적으로 무거운 경향이 없잖아 있어 모바일은 유니티에게 아직도 유리한 시장임에는 변함이 없다.
하이퀄리티 콘솔 및 PC 프로젝트에서는 고퀄리티를 가진 AAA급 콘솔 및 PC MMORPG는 프로젝트는 언리얼을 선호하는 경향이 강하고 그만큼의 성과를 경쟁자에 비해 안정적이게 뽑아낼수 있다. 유니티로도 충분히 고 퀄리티의 프로젝트를 내고 실제로도 언리얼 못지않게 출시되고 있지만, 3D게임을 만들때 엔진의 성능과 퀄리티를 올리기위한 엔진 커스텀이나 추가 플러그인들의 의존이 많고 그런 이유로 출시 이후 유지보수비용도 언리얼에 비해 많이 드는편이라 대체적으로 3D쪽은 언리얼에 손을 들어주는 편이다.
9. 참고자료들
9.1. 유니티
사실 유니티보다 더 구조가 깔끔하고 이론적으로 쉬운 엔진은 그 이외에도 있지만 접근성을 압도적으로 올려주는 것이 수많은 인터넷의 정보들이다.
유니티의 개발 자료들은 인터넷에 널려 있다 말해도 좋을 정도로 풍부하다. 사실 공식 사이트의 레퍼런스를 전혀 보지 않아도 유튜브나 블로그의 자료만 보고 공부해도 될 정도. 영문 자료를 읽는 데 어려움을 느끼는 비전공자들이 우리나라 네이버/티스토리 블로그에 공개된 예제나 따라하기 글들만 봐도 정보를 넘치게 얻을 수 있다는 점이 유니티 생태계가 넓은 데에서 오는 이점이라고 볼 수 있다. 유튜브에서도 한국인들이 우리말과 한글로 만든 수많은 유니티 공부 영상을 찾을 수 있다.
특히 유용한 것이 순수한 소프트웨어 개발 이외의 퍼블리싱 사이트에 등록하는 절차라든가, 각종 수익모델과의 연동이라거나, 광고회사에 등록하고 운영하는 방법이라든가 하는 행정적인 정보들인데, 이것들은 경험적인 팁이 필요하고 실수했을 때 불이익이 올 수 있는 민감한 사항들이 많아서 실제 사례들이 풍부한 것이 접근성에 대단히 크게 작용한다. 이런 측면에서 우리나라 사람들이 중,소규모 입장에서 자신의 경험담이나 실수담, 주의사항 등을 기록한 것이 많은 것이 상대적으로 장점이 된다.
소스코드 공유 사이트나 학교/연구소의 전산 이론 구현에도 유니티를 3D 렌더러처럼 사용하여 기술시연을 한 것이 많기 때문에, 어떠한 렌더링 기법이나 게임 알고리즘이 연구된 바 있다면 그 구현 사례에 유니티를 사용한 테스트 코드나 공개 프로젝트를 거의 대부분 찾아볼 수 있는 편이다.
9.2. 언리얼
규모가 어느정도 이상되는 개발사들의 경우에는 언리얼이 유니티보다 훨씬 오래된 역사와 사례를 가진만큼 언리얼 관련 고급 트러블 슈팅 등 각종 레퍼런스 자료들은 유니티보다 언리얼이 훨씬 방대하다. 언리얼 커스텀 라이센스 시 개발사의 직접적 지원외에도 언리얼 커스텀 라이센시들만이 접근 가능한 언리얼 개발자 네트워크에서 깊이 있는 기술이나 다양한 정보를 참조 및 공유할 수 있다.
[1] UnrealScript의 주요 기능들을 계승하여 언리얼 엔진에 특화시킨 일종의 Unreal C++ 스크립팅 언어로서 기본적으로 언리얼 엔진 4의 구성 및 작동법을 잘 이해해야 제대로 사용할 수 있다.[2] 언리얼 엔진이 소스 코드 공개화 정책을 시행하는데, 유니티 소스 코드 공개화 정책을 시행하지 않은 것을 두고 가혹한 라이센스를 취하고 있다는 의견도 있으나, 소스 코드는 소프트웨어 개발사에 있어서 막대한 자본과 시간, 그리고 노력의 산물이며 거의 대부분의 소프트웨어 회사는 자사 소프트웨어의 소스 코드를 당연히 공개하지 않는다. 언리얼 엔진의 소스 코드 공개화 정책은 시장의 지배를 위한 전략적인 판단에 따른 것이며 결코 언리얼 엔진의 소스 코드 가치가 낮아서 공개한 것이 절대 아니다. 소스 코드 공개화 정책 시행 이전의 언리얼 엔진은 소스 코드를 제공받는 계약 체결시 몇억원대의 라이센스 비용이 드는 엄청난 고가였으며, 그것을 포기하면서도 더 많은 것을 얻을 수 있었기에 가능한 정책인 것이다.[3] 유니티 애셋 스토어의 비주얼 스크립팅.[4] 어지간한 중규모 이상의 개발사만 되더라도 그래픽/음원 리소스 제작팀을 포함하기 때문에 큰 영향이 없을 수도 있을 것이라 생각할 지 모르겠지만, 게임 업계에는 중, 대규모 개발사만 있는 것이 아니다. 지금도 수많은 소규모 제작사와 인디 개발팀은 애셋 스토어의 은혜를 입고 있다. 1인 개발이나 인디 개발팀에게는 애셋 스토어만한 리소스 제공처도 드물다. [5] 일반적으로는 대기업, 대규모 개발팀일수록 영어 등 각종 외국어에 능통한 스태프가 있을 확률이 높으므로.[6] 디퍼드 렌더링이 엔진의 기본 구조이고, 이 방식을 피하려면 엔진 내부를 고치라는 정책[7] 이 문제는 언리얼 엔진 4.14 이후 포워드 렌더링을 일부 지원함으로서 해결된 상태다.[8] 게다가 유니티 5.5 전까지는 Mono 2.0(무려 '''2008년도에''' 나온거다 이거...)을 그대로 쓰고 있어서 보안이고 성능이고 상당히 처참했다.[9] 언리얼 엔진3 까지는 유니티와 비슷한 스크립트 언어였다.