유니티 엔진
Unity Technologies[8]가 개발하여 2005년 6월 8일 처음 출시된 게임 엔진
3D 및 비디오 게임을 개발하는데 사용되는 게임 엔진이고
주로 저사양/소규모 게임의 개발에 적합한 관계로, 특히 가벼운 모바일 게임에 많이 사용되는 엔진이다
유니티엔진 특징
직관적인 GUI제공하고 다양한 플랫폼으로 빌드 가능하며 낮은 요구 사양을 가지고 있다
또한 저렴한 라이센스 비용과 에셋 스토어로 넓은 사용자층이있고 풍부한 자료들이있다
하지만 라이센스 비용은 점점 오르고있고 각종 문제가 있다
유니티 게임 엔진 사양
윈도우 10 64bit 또는 맥 OS 10.14 모하비 이상이 설치된 데스크톱 PC, 8GB 이상 RAM, 인텔 또는 AMD 프로세서(쿼드 코어 이상 추천)
DIrectX 11 이상 지원 (윈도우), Metal 1.2지원(맥OS) 그래픽 카드 등이 필요하다
유니티 게임 엔진 역사
유니티 첫버전은 데이비드 헬가슨, 조와치 앤티 및 니콜라스 프란시스가 제작하였다.
2005년 6월 6일, 게임 개발의 대중화를 내걸고 아마추어 게임 개발자를 위해 보급형 게임 엔진을 만드는 것을 목표로 첫버전의 서비스를 시작했다. 유니티는 파이널 컷 프로 제품의 드래그 앤드 드롭 인터페이스에 영향을 받았다. 처음에는 Mac OS X에서만 사용할 수 있었으며, 소수의 플랫폼에만 유니티를 배포하였다. 버전 4.3.1.은 윈도우과 Mac OS X를 포함하여 모두 12개의 플랫폼에 제공된다.
초기 유니티 엔진은 멀티플랫폼 중 하나로 브라우저 역시 주력 지원했고, '유니티 웹 플레이어'라는 이름으로 현재까지 남아 있다. 유니티 웹 플레이어는 플래시와 같은 NPAPI 기반이었기에 5.4 버전에서 제거되었고 대신 WebGL로 빌드 할 수 있는 기능을 제공한다. 하지만 전문적인 게임엔진에 비해 비교적 단순하고 사용법이 쉽다는 점에 착안한 개발자들이 이를 이용해 게임을 만들기 시작하면서 아예 게임 엔진으로 방향이 선회되었다. 언리얼 엔진의 퍼블리싱 라이선스 옵션 도입 전[10]에는 유니티의 라이선스 비용이 매우 저렴하고, 여타의 고급 엔진들로 대형 프로젝트를 개발하는 것에 비해 단순한 게임들을 만들어 내기에는 비교적 쉬운 편이라서 아이폰을 필두로 한 스마트폰 게임이 새로운 블루오션으로 떠오르던 태동기에 절묘한 타이밍으로 선점하여 모바일에서 승승장구했었다. Shiva3D와 같은 유사한 경쟁자들도 있었으나, 애셋 스토어라는 생태계의 조성에 힘입어 넓은 사용자 풀이 형성되면서 막 모바일 게임 시장이 확장되던 시기에 독보적으로 치고 나아갔다.
또한 단순히 게임 엔진으로서 남지 않으려는 듯, 최근 여러 분야의 기술들을 확장 지원하고 시각효과 기업들을 인수합병하는 등 공격적인 확장 정책을 보이고 있다. 예를 들어, PyTorch를 통하여 게임 엔진 속의 오브젝트에게 머신러닝을 시키는 기능을 통합할 수 있는 ML-Agent 라던가, 자동차 및 제조산업을 위한 AR/VR을 제공하는 Unity Industrial Collection 등 다양한 시도를 하고 있다
마스코트
유니티는 2013년 12월 16일에 코하쿠 오토리(Kohaku Ōtori)의 공식 마스코트 캐릭터 유니티짱의 스크린샷을 공개하였다. 12월 29일에 도쿄에서 열린 행사 ‘코믹마켓 85’에서 캐릭터 상품을 판매하고 유니티짱의 성우도 초청하였다. 기술팀의 일본인 디자이너 닌티(ntny)가 오픈소스 여주인공 유니티짱을 제작했다. 유니티짱은 인증을 받은 프로젝트에서만 하부 프로젝트로 사용할 수 있다. 예를 들면 유니티짱은 런보우 게임에서 플레이어 캐릭터로 활용되었다. 유니티짱은 계속 인기 얻어 보컬로이드로 등장하게 된다. 보컬로이드 버전 4에서 유니티짱의 목소리 모음집이 포함되었고 '보컬로이드와 함께 하는 유니티 특별판'으로 불리는 5.0버전에도 포함되었다.
역대 유니티들과 특징
Unity
2005년 6월 8일에 출시된 유니티 엔진의 최초 정식 버전으로, 초창기에는 macOS만 지원했으나 나중에 Windows와 PC 기반의 웹 브라우저들도 추가로 지원하게 되었다.
Unity 2
2007년에 출시된 첫 메이저 업그레이드 버전으로, 3D 기능 강화와 공동 작업 기능, 비디오 재생 기능을 비롯하여 50여가지의 새로운 기능들이 추가되었다.
2008년에 애플의 앱 스토어가 런칭되면서 iPhone OS(현 iOS)를 추가 지원하여 유니티 엔진으로 개발된 게임을 앱 스토어로도 배포할 수 있게 되었다.
Unity 3
2010년 9월에 출시된 버전으로, 기존의 PC 플랫폼과 iPhone OS(iOS)뿐만 아니라 Android 같은 모바일 플랫폼, PS3, Xbox 360, Wii 같은 콘솔 게임기 등의 다양한 플랫폼으로 확장되었고 동시에 전세계적으로 스마트폰의 대중화와 맞물려서 유니티 엔진으로 개발된 게임들이 급격하게 늘어났다.
현재 유니티 엔진 버전별로 모아 놓은 공식 아카이브에서는 2011년 7월 26일에 발표된 3.4 버전부터 다운로드 받아 사용할 수 있다.
5.0.0부터 다운로드 받아 사용할 수 있게 바뀌었다
Unity 4
2012년 11월 13일에 출시된 버전으로, DirectX 11을 지원하기 시작했고 새로운 애니메이션 도구가 추가되었다.
2013년에 페이스북이 유니티 엔진 기반의 게임을 위한 개발 도구를 통합함으로써 유니티 엔진으로 개발한 게임을 페이스북에 등록하기가 쉬워졌다. SNS 연동으로 다른 사용자에게 게임 추천 기능을 제공하여 접속할 수 있는 일종의 광고 캠페인 기능이 추가되었다.
Unity 5
2015년 3월 3일에 정식 출시된 버전으로, GDC 2015에서 언리얼 엔진 4의 완전 무료화에 이어 유니티도 개인용 무료화를 선언하였다. 그러나 완전 무료는 아니고 여러가지 조건에 따른 제약 사항이 따른다.
2015년 9월 8일에 발표된 5.2 버전부터는 Windows 10 유니버셜 앱 플랫폼을 추가 지원하며, 코드 작성에 있어서 비주얼 스튜디오나 JetBrains의 Rider와의 연동이 가능하다.
Unity 2017
2017년 7월 10일에 정식 출시된 버전으로, Unity의 버전 이름이 연도 방식으로 변경되었을 뿐만 아니라 마이너 업데이트 버전의 형식도 2017.0.0 버전이 아니라 2017.1.0 버전부터 출발하는 것으로 변경되었다. 이후에 라이선스 정책도 변경되었다.
2017의 특정 버전부터 32비트 에디터를 더 이상 지원하지 않으므로 32비트에서 사용하려면 5 버전을 사용해야 한다.
Unity 2018
2018년 5월 2일에 정식 출시된 버전으로, 3D 그래픽 성능이 크게 개선되었고 잡 시스템과 ECS를 지원하여 멀티스레드를 이용한 포크-조인 방식의 병렬 프로그래밍이 유니티 스크립트에서도 사용 가능해졌다.
Unity 2019
2019년 4월 15일에 정식 출시된 버전으로, 경량 렌더 파이프라인이 정식으로 적용되어 2018 버전에 이어서 3D 그래픽 성능의 최적화가 개선되었고 버스트 컴파일러가 정식으로 적용되어 컴파일 속도가 개선되었다. 가비지 컬렉션 이슈가 일부 개선되었다.
안드로이드의 경우 64비트가 추가. 64비트 대응 추가 자체는 유니티 2017에도 비슷한 시기에 나온 2017.4.16f1부터 추가되었는데, 플레이 스토어에서 64비트 지원을 의무화하는 구글 정책의 여파라고 한다. 다만, ARM 64비트 대응 과정에서 안드로이드의 x86_64 지원 여부때문에 사용 빈도로 대응 여부를 검토한 결과, 안드는 x86 쓰는 기기가 거의 없어 2019.3 버전부터 x86을 아예 빼버렸다. 그래서 안드로이드에서 유니티 엔진 쓰는 게임은 x86을 아예 미지원하는 경우가 늘었고 이는 플레이 스토어의 어플리케이션 업데이트시 64비트 지원이 의무화된 2019년 8월부터 본격적으로 증가했다.
Unity 2020
2020년 현재 유니티의 게임 엔진으로 제작된 소프트웨어는 15억 개 이상의 기기에서 실행되고 있다. 유니티에 따르면 자사의 게임 엔진으로 제작된 앱은 전체 모바일 게임의 50%를 차지하고 매월 30억 회 이상 다운로드되고 있으며, 매일 약 15,000개의 새로운 프로젝트가 소프트웨어로 시작된다고 한다. 파이낸셜 타임즈는 유니티의 엔진이 "포켓몬 고와 액티비전의 콜 오브 듀티 모바일과 같은 세계에서 가장 수익성이 높은 모바일 게임 중 일부에 동력을 제공한다"고 보도했다.
2020년 6월, 유니티는 증강현실(AR) 애플리케이션 생성을 위한 추가 기능을 개발자에게 제공하는 MARS(Mixed and Augmented Reality Studio)를 선보였다. 유니티는 2020년 12월 9일 자동차 및 소매 솔루션 도구인 Unity Forma를 출시했다.
2020년 6월, 유니티는 유니티 에디터가 애플 실리콘을 지원할 것이라고 발표했다. 첫 베타 버전은 연도 말에 배포되었다.
Unity 2021
유니티 2021에는 유니티 비주얼 스크립팅 시스템인 Bolt, 멀티플레이어 게임을 지원하는 새로운 멀티플레이어 라이브러리, 향상된 IL2CPP 런타임 성능, 고화질 렌더 파이프라인을 위한 볼류메트릭 클라우드 등 다양한 신규 기능이 추가되다. 섀도 캐싱 및 HDRP용 스크린 스페이스 글로벌 조명, 유니버설 렌더 파이프라인의 경우 포인트 라이트 섀도, 디퍼드 렌더러, 일반 코어 엔진 개선 및 기타 수정사항이 포함되었다.
유니티 2021.2부터 애플 실리콘 정식 지원이 추가되었다. 애플 실리콘 에디터에 대한 Unity Hub 지원은 2022년 1월 버전 3.0부터 제공된다.
Unity 2022
유니티 2022의 변경 사항은 플레이 모드로 전환하고 파일을 임포트하는 데 필요한 시간을 단축하고 패키지 관리자에서 시각적 검색 쿼리와 다중 선택을 구현하여 생산성을 향상하였다. 2D 프로젝트의 경우 핵심 소프트웨어, 임포트, 애니메이션, 피직스 속도를 높이는 데 중점을 두고 변경 사항이 적용되었다.
스프라이트 아틀라싱이 수정되었다. 2D PSD 임포터에 PSD 확장 파일 및 레이어 관리 지원이 추가되었고 2D 물리학을 위한 Delaunay 테셀레이션이 추가되었다.
Unity 2023
HDRP 강화, 다중 플랫폼간 멀티플레이 환경 개발 개선, 제작하는 게임의 메뉴 등 UI를 실시간으로 확인하는 WYSIWYG 강화 등 개발 환경 개선이 많다.
DirectX 12와 플레이스테이션 5 환경에서 CPU 사용 효율이 최적화되었다.
하술하듯 유니티 2023은 사후 지원이 긴 LTS를 발매하지 않고 유니티 6으로 넘어갔다.
Unity 6
2023년 11월 16일, 유니티는 엔진의 다음 버전이 이전 버전 번호 매기기 규칙으로 되돌아가는 Unity 6라고 발표했다. Unity 6는 2024년에 출시될 예정이며, 새로운 제너레이티브 AI 툴인 Unity Muse와 Unity Sentis 등의 기능이 포함될 예정이다. 2024년 10월 정식으로 발매되었다.
기존 넘버링으로 버전 체계가 돌아간 것은 메인 버전이 "5"까지 출시된 언리얼 엔진 보다 숫자로 앞서 있다는 인식을 주기 위한 의도도 있는 것으로 보인다는 말도 있다. 플레이스테이션 3와 시절의 엑스박스가 엑스박스 "2"가 아닌 "360"으로 출시한 것, 그리고 언리얼 엔진이 4가 된지 얼마 되지 않은 시점이었던 지난 2016년도에 크라이엔진이 갑자기 넘버링을 크라이엔진 V(5)로 올렸던 것과 같은 의도다. 그러나 그게 아니더라도 유니티 5가 나온 시점은 지난 콘솔 세대였으며, 충분히 한 세대가 지난 시점에 넘버링을 올린 것이므로 굳이 그런 의도를 가지지 않은 것일 수도 있다. 5 버전을 유지해야할 시점인 몇 년 동안 버전에 년도를 붙였던 것이기 때문이다.
당초 Unity 2023의 세 번째 테크 스트림인 Unity 2023.3이 나올 예정이었으나 Unity 6 Preview라는 이름으로 출시되었다. 당초 2023 LTS로 알려졌던 버전은 Unity 6라는 이름으로 나올 예정이다. 다만 기존 버전과의 호환성을 위해 내부 버전 넘버링은 6000대를 사용한다.
주요 기능개선은, 렌더링 성능 향상: GPU Resident Drawer, 조명 워크플로우 최적화, Multiplayer 생성 단순화, 웹 런타임으로 멀티플랫폼 범위 확장(얼리 액세스), AI 개선, 여러가지 툴과 기능 업그레이드가 있다.
Unity 장점
직관적인 툴의 UI
툴의 GUI가 매우 직관적이다. 내부 에셋들의 위치를 바꾸고 적용하거나, 임포트 등이 매우 손쉽게 가능하며 유니티가 소규모/인디 게임에 폭발적인 인기를 얻게 된 가장 큰 비결이었다. 게임 엔진에서 유저 친화적 UI가 얼마나 중요한지 상징적으로 보여줬으며, 향후의 게임 엔진들에 매우 많은 영향을 주었다
간편한 빌드
버튼 몇 번만 누르면 다양한 플랫폼으로 빌드가 가능하다. 그러나 플랫폼별 특성에 맞게 어느 정도 조정작업 및 별도의 최적화도 필요하다. 플랫폼별로 특징이 다르므로 당연한 일이며 유니티를 쓴다고 해서 그런 조정작업이나 최적화가 자동으로 되지는 않는다. 게임 하나 만들어 놓고 별다른 노력도 없이 다양한 플랫폼으로 출시할 수 있는 건 아니니 반드시 유의해야 한다.
낮은 요구 사양
버전 업되면서 요구 사양이 점점 높아졌지만 AAA급 고퀄리티 게임을 개발할 수 있는 다른 메이저 게임 엔진에 비하면 비교적 가벼운 편이라 저사양 PC에서도 저사양 타겟의 간단한 게임 정도는 무리없이 개발이 가능하다.
다만, 어디까지나 다른 메이저 게임에 비해 가볍다는거지, 여기서도 개발자의 최적화 능력이 부족하다면 요구사양에 비해 버벅이는 문제점이 생길 수도 있다. 정확한 사양은 위에 참조
에셋 스토어
인디 게임개발자들이나 초보 개발자들에게 유리한 이점을 제공한다. 바로 에셋 스토어의 존재다. 각종 리소스부터 스크립트, 플러그인으로 사용할 수 있는 다양한 기능, 미리 만들어 놓은 AI 등 수많은 기능들을 이용자들이 올려서 서로 사고 팔 수 있는 장터를 제공한다. 이 정책은 크게 성공하여 유니티 붐을 일으키는 데 일조했다. 사용자가 많을수록 에셋 스토어에 더 많은 상품들이 올라오고, 그것을 본 사람들은 유니티 사용에 긍정적으로 접근하게 되고, 신규 유입된 사람들이 다시 스토어에 유니티 기능을 만들어 올리는 등 선순환 과정이 형성되어 있다. 그리고 유니티에서 운영하는 인디, 초보자들을 지원하는 프로그램 등 관련된 다양한 행사가 진행된다는 점도 강점이다. 엔진 자체의 확장성과 맞물려 게임 이외에 방송, 애니메이션, 툴 등 3D 게임 엔진으로 할 수 있는 각종 에셋들이 존재하며, 찾아보면 이런 것도 있나 싶을 정도로 방대한 생태계를 자랑한다.
유니티를 다른 엔진들에 비해 우월한 지위에 올려 준 가장 큰 요소이다. 디자인, 모델링부터 유니티에 기능을 추가하는 플러그인에 해당하는 에셋까지 누구나 무료로 배포하거나, 유료로 판매할 수 있는 에셋용 앱스토어이다. 코딩에 익숙하지 않은 디자이너들이나 리소스 제작이 힘든 개발자들이 이 에셋 스토어에서 구매하거나 무료로 다운받은 에셋을 사용하여 프로젝트를 수월하게 진행할 수 있도록 도와준다.
| 항목 | 에셋 |
| GUI | NGUI, Scaleform, Noesis GUI ... |
| 2D | 2D Toolkit, ... |
| Shader | Substance, Shader Forge, ... |
| Script | Playmaker, uScript, ... |
| AI | Simple Path, ... |
| Tween | iTween, LeanTween, ... |
| Modeling | UModeler, Simplygon, GameDraw, ProBuilder 2, ... |
에셋 스토어 폴더에 파일이 너무 많으면 로드가 매우 느려질 수도 있으며, 빈 회색 화면만 보인다면 edit > project setting > player에서 use Direct3D 11을 체크 해제하면 해결될 수 있다.
넓은 사용자 층과 풍부한 관련 자료
개발 초보자나 비 프로그래머에서부터 고급 개발자까지 사용자층이 다양하고 그 수가 많다. 특히 입문 장벽이 낮기 때문에 초보자 인구가 많은데, 이 때문에 인터넷을 검색해보면 관련 자료가 많이 나온다.
마이너하거나 사용자층이 한정될수록 인터넷 상에 자료들이 적고 제작사에서 제공하는 도움말이나 공식포럼이 고작인 경우가 많은데, 이는 사용자 수 자체가 적은 것도 있고, 사용자들이 이미 대부분 고여버려서 어지간한 상황에서 만나는 장애물들은 알아서 이미 해결가능하기 때문인 경우도 있다. 반면 유니티의 경우엔 정말 생초보들을 위한 그림책 수준의 강의부터 오만 잡다한 에러의 해결법 및 흔히 마주치는 실수, 사람들이 즐겨 사용하는 베스트 프랙티스까지 매우 많은 정보가 인터넷에 돌아다니고 있으며, 이것들이 엔진을 배우는 데 큰 도움이 된다. 그 형태도 블로그, 유튜브 강좌나 튜토리얼, 인터넷 강의, 소스 공유 사이트의 공개된 실습 코드등 매우 다양하기 때문에 동일한 기술을 배우는 데도 자기가 알아듣기 쉽고 따라하기 편한 매체를 고를 수 있다.
언리얼 엔진 공식 도큐먼트의 질이 더 좋다는 평이 많다. 그러나 인터넷에서 찾을 수 있는 수많은 실제 예제들이 이러한 불리함을 보충해 주고 있어, 특히 초보 개발자들에게 많은 도움이 되고 있다. 다만, 2020년대부터는 언리얼 엔진도 초보자 인구가 급격하게 늘어나면서 엇비슷해지고 있다.
Unity 단점
낮은 버전 지원으로 인한 호환성 문제
유니티의 뜻 그대로 가져온 것들을 잘 통합해야 할 것인데, 잘 가져오지도 못하고 통합도 못하고 있다는 것이 사실 가장 큰 문제이다. C#의 경우 9.0조차도 불완전하게 지원하며, 닷넷 프레임워크도 4.x버전이며, AI를 외치는 파이썬도 3.10.9로 10버전대의 마지막 버전도 아니다. 모두 3년 이상 뒤쳐진 상태다. 이게 언뜻 보기에는 별 문제가 없어 보이지만, 최신 기능을 반드시 써야하는 경우(온디바이스 AI라던가) 엄청난 문제가 발생한다. 어떻게든 1가지 호환성 문제를 해결하면 다른 호환성 문제는 해결하기 어려운 상황이 계속해서 발생한다. 이런 문제가 1+1=3의 수준으로 증가한다. 그래서 유명한 다카하시 케이지로 등의 예시를 봐도 1번에 1개의 모델만을 돌리는 걸 알 수 있다. 거기에 추가로 버전별 호환성 문제가 또다시 중복된다. 다카하시 케이지로의 경우도 1개의 모델만을 돌려도 유니티 버전에 따라 실행되고 안되고가 크게 영향을 받는다는 걸 알 수 있다. 당연히 여러개의 모델을 돌리면 문제는 더욱 심각해진다. 물론 여러 처리단계가 필요한 경우도 마찬가지다.
참고로 위의 C#, 닷넷 프레임워크, 파이썬의 호환성 문제는 큰 줄기로써 대표적인 예시에 불과하다. 애플(IOS->AR관련), 구글(안드->AR관련), 스팀과 메타(VR등), ONNX 등도 원래 구현된 것들을 제대로 지원하지 않거나(버전이 낮은 것을 포함) 지원하더라도 뭘 지원하는지 제대로 표시하지 않거나 성능 상 문제가 있기도 하다. 또한 본인들 스스로가 새롭게 지원하는 기능이 기존에 있던 기능은 빼놓고 구현하는 등의 문제가 있다. 예를들어 새로운 입력시스템은 키 시뮬레이션을 지원하지 않는다. 심지어 마소의 dll파일을 불러와도 먹히지 않는다. 물론 구 입력 시스템은 키 시뮬레이션은 물론이고 마소의 dll파일도 잘 먹힌다.
이상하게 아무도 이 문제를 언급하지 않는 건 C++프로그래밍이나 클라우드, 처리의 분산을 통해서 이 문제를 우회하고 있기 때문일 것이다. 그러나 C++로 프로그래밍할 것이면 굳이 추가로 C#을 쓰는 유니티를 쓸 이유가 없다. 그리고 클라우드 서비스는 추가적인 요금이 발생한다. 싱글 패키지 게임은 다른 컴퓨터로 처리해서 넘기기가 불가능하다. 물론 여전히 legacy로 사용할 수도 있을 것이다.
또한 이 문제는 유니티 외부의 프로그램을 사용하지 않고 유니티 내부에서만 모든 것을 처리한다면(고전적인 게임 개발), 발생하지 않는다. 그러나 일단 그런 환경에 포함된다면 유니티 사용을 포기해야 할 정도로 중대한 문제이다.
아주 직접적으로 말해보자. 인디바이스로 복합 모델을 사용하는 AI를 포함시키고 싶다? 유니티를 쓰지 마라. 일단 C#쪽보다 C++쪽이 자료가 훨씬 많다. 물론 파이썬 쪽은 더더욱 많다. 그러나 유니티는 파이썬 지원 버전이 낮다. 추가적으로 파이썬 버전에 따른 각종 파이썬 API들의 호환성도 해결해야한다. 그러니 그냥 쓰지 마라. 어차피 C# 지원 버전도 낮다. 닷넷 프레임워크 쪽에서는 마이크로소프트가 AI관련 프레임워크를 여러 차례를 만들다 포기하다하길 반복했다. 앞으로도 그럴 것 같다. 자료도 별로 없다. 그리고 어차피 닷넷 프레임워크도 4.x밖에 지원하지 않는다. 그러니 포기해라. 그냥 C++을 쓰는 게 성능 면에서도 물론이고 훨씬 낫다.
이런 수년 동안 쌓인 문제가 빠르게 해결될 것 같지도 않고, 그냥 애당초 해결할 의지가 있어 보이지도 않는다.
유니티는 AI에 대해 비전을 제시하면서 무한한 열린 세계로의 연결이 아니라 결국 자신들의 새로운 구독제를 제시하는 것으로 보인다. 갈라파고스화하는 것이다. 열린 AI의 세계를 포기하거나 굳이 또다시 C++프로그래밍을 추가하거나 유니티나 클라우드에 돈을 얼마든지 지불할 의사가 있다면 유니티를 계속 써도 좋을 것이다.
제한적 멀티스레드 기능
유니티 API가 메인 스레드 외에서는 호출이 안전하지 않기 때문에[19] 제한적으로만 멀티 스레드를 적용할 수 있으며 결국 이를 통해서 높은 성능 향상을 꾀할 수는 없다. 유니티 API가 없는 순수한 연산 집약적 동작을 병렬 처리하는 것인데, 이는 전체 동작에 대한 완전 병렬화가 아니다. 또한 연산 관련 코드에서 API를 통하지 않는 경우는 많지 않으면서, 대부분의 연산 능력을 API에서 요구하기 때문. 즉, 병렬화가 되는 부분이 극히 일부이기 때문에 높은 이득을 취할 수는 없다. 암달의 법칙 참고.
설령 어찌해서 구현했다 해도 노력 대비 얻는 성능 향상이 크지 않아서 이를 동적 로딩(프리로드)에 응용하는 경우도 볼 수 있는데, 마찬가지로 유니티 API를 멀티스레드에서 안전하게 사용할 수 없으니 완벽한 동적 로딩을 구현하기는 힘들고 성능 향상도 기대에 미치지는 못한다. 즉, 고도의 편법을 완벽하게 익혀서 문제가 될 부분을 최소화하여 적용하지 않는 이상, 성능 이슈가 될 가능성이 높은 부분을 병렬화하지 못해 0번 코어만 죽어라 갈구는 경우가 될 가능성이 높다는 것이다.
실제로 유니티 엔진 4로 개발된 로켓 발사 시뮬레이션 게임인 Kerbal Space Program은 시뮬레이션 특성상 물리연산을 엄청 빡세게 하는데 이 물리연산 스레드를 코어 하나가 전부 감당해야 하기 때문에 어디가서 성능 좀 된다 하는 CPU도 부품이 많아지면 프레임을 제대로 못뽑는 상황이 무조건 발생한다. 이때문에 개발자가 유니티 엔진 5로 엔진을 갈아타는(!) 작업을 완료해 업데이트를 했지만, 그나마도 우주선 하나당 코어 하나씩 분담시키는 수준이 한계라고 밝혔다. 멀티스레딩이 안되어서 생기는 문제의 아주 대표적인 예. 물론, 이 문제는 KSP 못지 않게 연산량이 드럽게 많은 시티즈: 스카이라인도 마찬가지인데[20], 이 게임은 아예 유니티 본사 측에서 기술 지원을 해줬다(...). 그나마도 8스레드까지 인식하지만 실질적인 스레드 분담은 4스레드까지. 그래서 짝퉁 멀티코어 지원이라고 까이고 있다.
다수의 저성능 코어를 빅 리틀 솔루션까지 적용해가며 끌어모은 모바일 환경은 물론, 각 코어당 성능이 높은 편인 PC에서까지 영 좋지 않은 자원 활용도를 보일 수밖에 없다. 따라서 일정 수준 이상의 규모가 되는 게임을 개발하기에는 아쉬움이 크다.
다행히 2018.1 버전부터 C# 잡 시스템(JobSystem)[21]과 ECS[22]이라는 방법으로 멀티스레드를 이용한 병렬 처리를 지원한다. 하지만, 아직 문제가 많고 불안정해서 많은 개발자들이 지켜보고 있는 상황이다.
GC 스파이크 문제
유니티 엔진이 스크립팅용 언어로 C#을 사용하는 만큼 실제 실행과정에서는 .NET 런타임의 가비지 컬렉터가 메모리 관리를 담당하고 있으며 유니티 측에서는 이에 대해서 가상머신의 가비지 컬렉터가 담당하는 관리 영역과 가비지 컬렉터가 담당하지 않는 비관리 영역을 구분하고 있다.
.NET 런타임은 추적 기반 가비지 컬렉터를 사용하므로 프로그램 실행 중에 현재 할당되어 있는 모든 메모리를 한꺼번 조사하여 접근 불가능한 객체의 경우 삭제한다. 다만 이 과정에서 프로그램이 일시 정지가 되므로 실시간으로 실행하는 프로그램이 뚝뚝 끊긴다는 문제가 있고 관리되는 메모리 영역이 많아질수록 조사 시간이 걸려 GC Spike 등의 성능 문제가 자주 발생하며 이와 관련된 대표적인 게임이 Escape from Tarkov다.
'Use incremental GC' 옵션으로 GC Spike를 완화 할 수 있는데, 이는 GC가 한 프레임이아닌 여러 프레임에 걸쳐 작업 되게 만드는 옵션이기에 결국에는 프레임레이트를 희생해 스파이크를 낮추는 효과로 나타난다. 따라서 결국 애초부터 GC 동작을 예측하고 프로그래밍하는것이 중요하다.
사실 유니티는 일단은 가비지 컬렉션 관련 기능을 수동으로 제어하거나 심지어는 C/C++로 이루어진 코어 부분의 메모리 영역에 접근하는 방법을 만들어 둬 이를 작정하고 이용해 최적화 할경우 GC Spike등의 문제를 최소화 할수 있다. 문제는 유니티 엔진을 쓰는 회사들 규모가 상대적으로 작은 편이라 그렇게 까지 최적화를 할 필요성을 못느끼는 개발자들이 많기 때문에 단순 GC Spike 뿐만이 아니라 유니티에서도 메모리 누수가 빈번히 발생하는 게임들을 볼수있다. 핵심은 유니티가 GC 에 의존한다기 보다는 제대로 메모리를 관리하지 않고 GC에게 일임해버리는 개발자들이 문제인 셈.
라이센스 문제
위의 장점 항목에서처럼 인디~저매출 기업에게 매우 유리한 라이센스 정책으로 엔진에게 큰 홍보효과를 얻는 반면, Unity 본사와 달리 Unity Korea에서는 대학에 과금을 시도하려는 조짐이 보이고 있어 게임학과에서 큰 반발을 불러오고 있다. 美 게임 엔진 '유니티', 대학에 사용료 받나... 학계 공동대응 예고
또한, 점점 유료 라이센스의 가격이 비싸지고 있다. 엔진의 발전이 더딘데 가격만 오르고 있어서, 해당 엔진 사용자 입장에서는 불만이 가득한 편. 결국 그 동안 쌓이던 불만이 다운로드 횟수에 따른 종량제 논란을 기점으로 한꺼번에 폭발했다.
사실, 이러한 갑작스런 요금제 변경발표에는 지난 20여년간의 누적된 적자, 이로인한 투자자들의 압박이 요금제 개편압박으로 작용했다고 볼 수 있다. 하지만, CEO 존 리치티엘로가 사태에 책임을 지고 사임하고, 무료사용 매출 기준을 20만달러로 완화하여 인디개발자들에게 이전보다 더 나은 혜택을 주고, 런타임요금제 또한 매출의 2.5%와 설치당 비용중 적은쪽을 선택하여 지불할 수 있으며, 설치당비용을 선택할 경우, 설치회수는 이용자가 직접 집계하여 보고할수 있도록하였다.
2024년 10월 런타임 요금제를 폐지하고, 프로와 엔터프라이즈 라이센스 이용료를 올리기로 결정했다.
소스 코드 비공개
유니티는 기본적으로 월간 비용을 지속 지불하더라도 전체 소스코드는 여전히 비공개며, 전체 소스코드가 포함된 라이선스를 원할 경우 그 비용은 언리얼 엔진 커스텀 라이선스 비용과 맞먹게 된다. 유니티 측은 프로 라이선스도 소스 코드에 엑서스 할 수 있는 것 마냥 선전하고 있지만 실상은 구독과 별개로 소스코드를 구매해야 한다고 한다. 여기에 개발기간이 길어진다던가, 개발팀 인원이 증가된다던가, 타 스튜디오 등의 지원을 받아서 유니티의 시트당 사용자수가 늘어날 경우에 따라서 개발 비용이 지나치게 높아질 수 있으므로 상황에 따라서 언리얼 엔진의 사용을 고려해야 할 수도 있다. 언리얼 엔진은 4.0 이후 버전부터는 소스 코드를 모든 사용자에게 무료로 공개하는 정책을 고수하고 있다.
보안성 문제
이전 버전의 경우 C# 프레임워크인 Mono에 기반했기 때문에 보안이 거의 하나도 되지 않았다. 강제로 오픈소스화된다고 할 정도로, 게임 내의 모든 리소스를 포함해서 스크립트의 코드를 담고 있는 DLL 또한 압축해제와 리버싱을 통해 얼마든지 내용이 드러나게 된다.[24] 이는 결과물이 중간 바이트코드인 대부분의 경우에 공통적으로 해당된다. 기계어 수준까지 컴파일이 되는 경우는 역컴파일이 쉽지 않고, 그마저도 현재는 C로 제한적인 표현이 가능한 수준이다. 그것도 다른 언어로 컴파일된 것이면 해석이 더욱 어렵다. 암호화를 시키면 되지만...
보안 문제는 메모리 해킹 방어, 스크립트 암호화[25], 변수 암호화 및 다중화, 체크섬 및 패킷 암호화 등 프로그래머들이 갈려나가면서 보안성을 마련하면 어느 정도는 해결될 수는 있다. 시간 많고 능력 좋은 수준급 해커와 만나면 털리는 것은 시간문제이긴 하지만. 문제는 유니티의 낮은 진입장벽에 의해 코드 암호화를 하지 않는 프로그래머가 대다수라는 점이 문제다. 어차피 모바일 환경이 보안성을 살릴 수 없는 환경이라는 점과[26] "어차피 털릴 어플은 털린다"라는 생각을 가지는 개발자들이 대부분이고 현장의 인식도 여기에서 크게 다르지 않은 상태라서 많은 게임들은 클라이언트-서버 구조로 제작해서 중요한 부분을 서버에서 처리하는 형태로 운영되고 있다. 이러면 다행이기라도 하지, 아예 보안장치를 마련하지 않는 사례도 수두룩하다.
그래서 해당 부분을 암호화하기 위하여 애셋 스토어에 CodeGuard나 Anti-Cheat-Toolkit 등의 서드파티 툴이 기본적인 코드 난독화, 메모리 해킹감지 등을 제공했다. 물론 완벽하게 막아줄 수는 없다.
최신 버전에 들어서면서 Mono 대신 .Net framework 4 이상의 버전으로 마이그레이션함과 동시에 아예 C++로 변환 후 네이티브 코드를 생성하는 IL2CPP / Burst Compiler를 도입하여 이 약점에 대응하는 수단이 등장했다. 네이티브 코드의 경우 C#이 해독되는 가장 큰 약점인 중간 바이트코드가 없이 C/C++과 동일하게 어셈블리 코드를 생성하므로 해당 문제점이 나타나지 않는다. 초기에는 IL2CPP의 컴파일 시간이나 버그에 대한 불만이 있었으나 현재는 거의 안정화된 상태이다.