유니티는 언리얼이나 프로스트 바이트 처럼 화려한 그래픽의 엔진으로 유명하진 않지만, 모바일 게임 개발의 과반수 이상의 파이를 차지하는 엔진입니다. 그 편리함과 범용성으로 모바일 게임 엔진 시장에서 왕좌를 차지한지 오래 됐지만 과연 유니티는 모바일게임용으로만 사용해야 하는 엔진일까요?
유니티 엔진
C#이라는 프로그래밍 언어가 있습니다. 이 언어는 마이크로소프트에서 주도 했고, 당시의 마이크로소프트는 다른 플랫폼에 매우 폐쇄적인 입장이었습니다. 하지만 언어가 주는 편리함과 그 특징들은 매력적이어서, 다른 플랫폼들에서도 이 언어가 작동 할 수 있도록 MONO라 불리는 오픈 소스 프로젝트가 진행됐으며, 이 프로젝트를 바탕으로 만들어진 게임엔진이 유니티였습니다. 재미있게도 이 프로젝트는 마이크로소프트의 자회사에서 개발을 이어 받아 유지되고 있습니다.
다양한 플랫폼에서 동일하게 작동한다는 이야기는 다르게 말하면, 해당 플랫폼의 특징을 잘 활용한다기 보다 일단 돌아 가게끔 우선 만들고 나중에 개선하겠다는 이야기도 됩니다. 또한 작동방식이 다른 각 플랫폼에서 하나의 코드로 된 프로그램을 작동시킬 수 있도록 만들기 위한 중간 단계도 하나 더 필요했습니다. 실시간으로 작동해야 하는 게임과 그다지 어울리는 구조는 아니었습니다. 그래서 유니티의 코어는 C++로 제작되어 있습니다. 즉, C#으로 만들어진 부분과 그 중 빠르게 작동해야 하는 부분을 C++코어에게 전달해주는 구조로 이루어 집니다.
코어와 스크립트가 분리되어 있으니 사실 스크립트 부분만 손보면 C#이 아니어도 됐습니다. 그래서 초창기에는 JavaScript도 지원하고 있었으며, 애초에 닷넷프레임워크와 모노에서 지원하던 Boo스크립트도 지원했었습니다. 하지만 다양한 지원은 유지보수가 힘드니 현재는 C#하나로 자리 잡고 있는 모습입니다.
에디터
유니티의 매력은 툴의 편리함이 큰 몫을 했습니다. 매우 유연하게 레이아웃을 사용자 마음대로 변경이 가능하며, 모든 부분은 창으로 떼어내서 아무대나 다시 놓을 수도 있습니다. 게다가 이런 유연함이 윈도우, 맥, 리눅스를 가리지 않고 매우 잘 작동하기 까지 합니다. 그리고 스크립트만 좀 다룰 줄 알면 개발에 필요한 툴도 뚝딱 만들어 낼 수도 있으니, 애매하게 외부 툴을 더 실행하지 않아도 되는 경우가 많아 집니다.
그리고 실제로 유니티 에디터 UI는 게임과 동일하게 C#으로 대부분 만들어져 있으며, 코드도 공개되어 있습니다. - 유니티 에디터 CS 오픈 소스 저장소
C#
위에서 이야기한 내용대로 유니티의 스크립트 언어는 C#입니다. 언어의 자세한 내용은 저도 잘 모르니 넘어 가지만, 잘 모르는 저도 쓰다보면 편하다고 느낄 때가 많습니다. C언어의 파생언어들이 다 비슷 하듯이 C#도 마찬가지인 기본 문법위에 쌓여 있는 것들이 단순히 기능확장만을 위한다기 보다 편리함이 상당히 고려된 모습이고, 이러한 점들이 생산성으로 직결됩니다.
생산성이 좋다는 이야기는 게임을 만들면서 빠르게 무언가를 해보기에 좋다는 이야기이기도 합니다. 그래서 언리얼의 블루프린트 같은 기능인 비주얼 스크립팅같은 기능이 생겨도 코드 짜는게 부담스럽지 않으니 크게 주목받지 못하는 느낌도 듭니다. 물론 코딩이 부담스러운 분들에게는 좋은 대안으로써 없는 것보다는 훨씬 나은 대안인 것에는 틀림 없을 것입니다.
이런 좋은 생산성에도 불구하고 ‘사람이 쓰기 편하고 알아 듣기 편한 언어는 기계가 힘들어 한다’는 현실이 닥쳐 옵니다. 게임 처럼 실시간 퍼포먼스가 중요한 분야에서는 아쉬운 부분들이 좀 있습니다. 대표적으로 박싱같은 문법적인 부분이나 GC같은 언어적인 한계입니다. GC는 쉽게 말해 프로그램이 메모리를 사용하고, 잘 사용했으면 반환해야 하는데 이러한 작업을 알아서 처리해 주는 역할을 하는데, 쌓아 뒀다가 한꺼번에 정리하면서 겜이 특정 시점에 끊기는 문제가 발생하게 됩니다. 이러한 문제들은 게임의 경험적인 부분에 문제를 드리웠고, 유니티에 대한 사람들의 인식에 안좋은 영향을 끼친 큰 주범이라고 생각합니다.
또한 유니티 엔진은 지금은 안붙어 있지만 이름 뒤에 ‘3D’가 붙어 있었습니다. 3D엔진임에도 내장된 수학 함수들이 벡터계산의 SIMD를 지원하지 않아 대규모 처리에 버거움을 느끼는 부분도 있었습니다. 그래서 상대적으로 케쥬얼 게임과 같은 계산량이 많지 않은 게임에서 많이 사용된다는 인상이 강한 것도 사실입니다.
이러한 부분들은 모두 C#이라는 언어를 기본 스크립트 언어로 사용하면서 생긴 문제이지만 언어의 문제로 치부하지 않고 어떻게던 언어의 한계를 뛰어 넘으려는 노력이 지금의 유니티를 지탱하고 있습니다. C#은 본래 중간 언어로 한번 변경된 후 기계가 처리하게 되는데 이러한 아이디어에서 착안하여 C#의 중간언어를 C++로 변경해서 처리하게 하려는 IL2CPP같은 기술을 만들거나, SIMD를 지원하는 수학 라이브러리를 추가로 만들고, 버스트 컴파일러로 C#을 네이티브처럼 작동하게 최적화 시킬 수 있는 기능도 넣으며 시대에 맞춰 나가고 있습니다.
에셋 스토어
아트 에셋을 만든다는 것은 정말 시간이 엄청나게 들어 가는 일입니다. 종종 정말 뛰어난 아티스트가 휙휙 만들기도 하지만 그런 아티스트들 조차도 물리적으로 만드는데 들어 가는 시간 자체는 어쩔 수 없기 때문에 다양한 에셋을 만드는 것 또한 시간이 드는 것은 어쩔 수 없습니다. 그리고 아티스트의 능력이 뛰어날 수록 인력비 또한 엄청나게 늘어납니다.
심지어 게임에 사용되는 에셋들은 최적화라는 녀석이 늘 따라 올 수 밖에 없습니다. 초당 수십장을 그려내는 매우 극한으로 컴퓨터(혹은 콘솔이나 휴대폰 등등)를 쥐어 짜야 하는 게임이라는 분야에서는 어쩔 수 없는 작업입니다. 이 최적화라는 마법의 작업 하나만으로 게임에서 표현할 수 있는 표현의 한계, 제작의 시간이 더 들어 갈 수 밖에 없습니다. 그래서 언리얼에 나나이트라는 녀석이 생긴 것이겠죠.
유니티의 에셋스토어는 이런면에서 매우 혁신적이었습니다. 아티스트는 자신의 작업물을 손쉽게 올릴 수 있었고, 당연히 좋은 에셋은 그에 맞는 보상으로 돌아 왔습니다. 비단 아트 에셋 뿐만 아니라 유니티에 모자란 기능들을 만들어 올린 프로그래머들도 보상을 받을 수 있었습니다. 반대로 그런 좋은 에셋들은 그럴싸한 게임을 만들고 싶지만 아티스트를 구하기 힘든 저자본 프로젝트에서는 각광을 받았습니다. 언리얼의 마켓플레이스 또한 에셋스토어에 영향을 받지 않았다면 우스울 것입니다.
딱히 보상이 필요 없다고 해도 괜찮은 에셋들을 공유 하려는 사람도 많았는데 그런 사람들에게도 매우 좋은 플랫폼인 것도 부정할 수 없을 것입니다. 무료 에셋들 또한 쓸만한 것들이 매우 많기 때문에 좋아 보인다고 무작정 구매하기 보다는 대안을 찾아 잘 적용했을때의 성취감도 있습니다.
하지만 에셋 스토어가 늘 정답은 아닙니다. 실제 프로젝트에서 괜찮은 것을 찾아 잘 사용하는 것은 또 다른 능력입니다. 그리고 본인의 프로젝트에 맞는 에셋을 찾지 못할 수도 있습니다. 에셋 스토어만으로 무엇인가를 만들려고 하면, 주객이 전도된 아트 방향성을 가질 수도 있습니다.
각종 툴이나, 컴포넌트들 또한 본인의 프로젝트에 맞는지 알기 위해서는 많은 경험을 필요로 합니다. 국소적인 부분만 놓고 괜찮아 보여 툴을 사서 쓰다가 결국 개발중에 못써먹겠다며 버리는 일도 종종 생깁니다.