그래픽과 관련한 최신 기능은 게임 엔진에서 가장 중요한 포인트로 손꼽혔다. 업계 일각에서는 흔히 때깔이 좋다고 하는 그래픽을 더 쉽게 구축하거나, 혹은 이전에 나온 게임보다 더 좋은 그래픽을 구현할 수 있느냐 여부를 엔진 선정의 기준으로 삼기도 했다.
유니티는 올해 고퀄리티의 그래픽 구현을 위한 기능 구축에 충실한 모습을 보였다. 뿐만 아니라 그 그래픽을 더욱 쉽게, 디테일하게 수정할 수 있도록 하고자 했다. 일례로 2019.3 버전에서 정식 출시되는 리얼 타임 레이트레이싱뿐만 아니라 고해상도 그래픽을 쉽게 렌더링하고 바로 수정하면서 피드백할 수 있는 HDRP, 코딩 없이 시각화된 그래프를 조작해서 이펙트를 세밀하게 수정할 수 있는 비주얼 이펙트 그래프 등을 선보였다.
특히 올해는 3D뿐만 아니라 2D 분야에서도 여러 가지 기술을 선보였다. 그간 2D 그래픽 기술을 메인으로 내세우는 경우는 드물었지만, 이번에는 2D에서도 라이팅이 구현 가능한 URP, 개선된 2D 툴 등을 키노트나 여러 행사에서 소개하고는 했다.
이와 같은 행보를 걸어온 유니티는 앞으로 그래픽 관련 분야에서 궁극적으로 어떤 목표를 지향하고 있을까? 아리사 스콧 PM과의 인터뷰를 통해서 지금까지 유니티가 선보인 기술에 대한 더 자세한 설명과, 앞으로의 구현하고자 하는 기술에 대해서 이야기를 들을 수 있었다.
Q. 올해 유니티에서 공개한 것 중에 개인적으로 2D 관련된 기술이 인상깊었다. 특히 2D에서 라이팅을 집어넣는다는 게 좀 생소한 개념 아닌가. 보통은 스프라이트로 다 그려내야 했으니 말이다. 이를 어떤 식으로 구현해낸 것인지, 그 개념을 설명해주었으면 한다.
물론 조금은 낯선 개념이었을 것이다. 왜냐하면 예전에는 빛에 따른 음영 변화도, 스프라이트로 하나하나 만들어서 적용해야 했기 때문이다. 그리고 이에 대한 기술적으로 새로 접근하고자 하는 시도도 드물었다. 정확히 말하면 단순 기술적으로는 가능하지만, 스타일의 문제가 봉착했다고 해야 할까. 어떻게 해야 더 섬세하게, 원하는 대로 표현할 수 있을까? 그 원하는 표현이 무엇인가? 하는 것이다.
2D 그래픽의 컨셉, 그리고 구현 과정을 살펴보면서 이 문제를 차근차근 짚어나갔다. 엔진에서 주로 보게 되는 2D 그래픽 유형은 스프라이트다. 그래서 스프라이트 단위로만 생각하지만, 그 스프라이트를 분해해보면 수많은 레이어를 토대로 하고 있다. 라이팅을 넣기 전의 스프라이트도 잘 보면 하이라이트 등 표현이 되어있지 않나. 그리고 그 안에는 여러 빛을 다각도로 분석해서 아티스트들이 집어넣은 색채 효과들이 녹아들어가있다.
그렇게 분석한 뒤에는 이제 엔진에서 어떻게 시각화하고, 어떻게 적용할 수 있을까 하는 문제가 남는다. 하지만 단위를 하나의 스프라이트가 아닌, 레이어로 조명해보면 이야기는 달라진다. 그 레이어 위에다 또 다른 레이어를 덧씌우고 효과를 주면 되기 때문이다. 그것을 한두 개의 레이어가 아닌, 섬세한 표현을 위해서 더 많은 레이어에, 더 세세한 파라미터를 적용할 수 있도록 설정하는 것이다.
2D 라이트와 쉐도우는 기본적으로 이렇게 해서 만들어졌다. 광원을 설정하고, 그 광원을 중심으로 해서 빛의 레이어가 만들어지면 그에 따라서 효과를 받는 레이어들이 내부에서 생성된다. 그리고 광원의 설정에 따라서 각 레이어도 영향을 받는 식이다. 이런 방식은 단순히 라이트, 쉐도우에만 쓰인 것이 아니다. 키노트에서 시연했듯이 낮과 밤, 캐릭터의 음영 표현 등 다양하게 쓰일 수 있다.
사실 그간 2D 게임 개발자들은 스프라이트를 안 그리고도 쉐이더나 여러 특수 효과를 입힐 수 있는 방법들을 찾아왔다. 하지만 대다수가 툴킷을 별도로 만들어서 활용하는 식이었고, 이를 구축하기 위해서는 프로그래밍에 대한 이해도가 필요했다. 이번 2D 툴의 개선은 그런 불편함을 덜고 아티스트나 디자이너들도 2D 그래픽을 얼마든지 쉽게, 빠르게 활용할 수 있도록 하는 데에 중점을 두었다고 하겠다.
Q. 리얼 타임 레이트레이싱이 요즘 화두가 되고 있다. 한편으로는 리얼 타임 레이트레이싱을 무리 없이 구현할 수 있는 하드웨어 스펙에 대한 이야기도 나오고 있다. 유니티 2019에서 리얼 타임 레이트레이싱을 무리없이 구현하기 위한 스펙은 어느 정도로 보고 있나?
리얼타임 레이트레이싱은 아무래도 극사실적인 그래픽에, 연산해야 할 것도 많은 건 사실이다. 유니티에서는 이 부담을 줄이기 위해서 고해상도 렌더파이프, 즉 HDRP를 적용했다. 렌더링 파이프라인의 근간은 직접 개발자가 렌더링 과정에 접근하면서, 이를 확장적용하거나 혹은 덜어내거나 하는 식이다. HDRP를 활용하면 고해상도 환경에서 렌더링과 그에 적용되는 것들, 예를 들면 후처리나 쉐이더 등을 조절해서 각 환경에 최적화된 리얼타임 레이트레이싱이 가능하다.
저번 GDC에서 시연했던 BMW 레이트레이싱 시연을 기준으로 말한다면, 에일리언웨어 노트북을 사용했다. 그 노트북에 내장된 그래픽카드는 GTX 1080이었던 걸로 알고 있다. 그 정도 사양에서도 리얼타임 레이트레이싱은 구현할 수 있지만, 아마 플레이타임이 길어지거나 더 복잡한 환경에서의 리얼타임 레이트레이싱을 구현한다면 좀 더 높은 스펙이 필요하지 않을까 싶다.
Q. 셰이더 그래프, 비주얼 이펙트 그래프 등을 살펴보면 유니티 엔진이 프로그래밍, 코딩의 비중을 낮춰가고 있는 것 같다.
좀 더 정확하게 말하자면, 아티스트들이 툴을 좀 더 쉽게 다룰 수 있도록 하고 있다. 물론 이제 양상이 조금씩 바뀌고 있긴 하지만, 게임 엔진하면 아무래도 개발자, 그 중에서도 프로그래머 계열에서 다룬다는 인식이 있지 않나. 실제로 엔진을 잘 다루려면 프로그래밍을 알아야 하기도 하고.
하지만 게임의 전체 개발 과정을 보면 아티스트, 디자이너도 중요하다. 게임뿐만의 이야기가 아니다. 제조업 쪽에서도 그렇지 않나. 기능뿐만 아니라 어떤 디자인인지도 중요한 평가 요소다. 이를 실질적으로 구축해나가는 사람들이 아티스트, 디자이너들인 만큼 그들도 일련의 작업에 더 활발히 참가해야 하지 않을까 생각했다.
그런 의미에서 유니티에서는 추가로 DOTS와 C# 소스 패키지도 준비한 것이다. 물론 이건 그래픽에만 국한된 문제는 아니고, 내 전문분야가 아니기 때문에 자세히 설명하기는 어렵다. 요는 그간 엔진 내에서 프로그래머, 혹은 엔진을 공부한 사람만 알 수 있는 형태의 것들을 아티스트, 디자이너도 쉽게 파악할 수 있는 형태로 시각화했다는 점이다.
코딩을 할 줄 모르는 사람은 스크립트를 보면 무슨 말인지 모르고, 어떻게 로직이 적용되고 있는지 모른다. 그렇지만 이를 노드, 파라미터 등으로 시각화하면 어떻게 진행되고 있는지 이해하기 쉽지 않나. 그런 식으로 차츰차츰 그 갭을 줄여나가는 것이 유니티가 추구하고 있는 방향이다.
Q. 유니티의 방향을 유저로서 보면 직접 게임을 만들어서 '이런 퍼포먼스가 가능하다'라고 보여주기보다는 '이런 기능이 있다'라고 소개하는 것에 그치는 느낌이다. 그 기능이나 퍼포먼스가 유저 입장에서는 와닿지 않을 것 같은데, 유저가 직접 이를 체감할 수 있게끔 별도의 게임 같은 것을 만들 생각은 없나?
그와 같은 질문은 여러 번 듣고 있다. 실제로 유니티에서 데모를 정말 많이 만들고 있지만, 그 데모를 마켓에 파는 형태로 만들지 않기 때문에 그럴 것이다.
마켓에 올라가는 형태의 데모는 분명 일반 유저들에게도 이런 게 가능하다고 알릴 수 있는 수단이긴 하겠다. 하지만 그것이 우리의 고객, 그리고 개발자들에게 궁극적으로 보면 이익이 되는 건 아니라고 보고 있다. 우리가 그렇게 만들어버리면, "이건 이렇게 써야 한다"라는 어떤 기준점을 제시해버리는 셈이 되지 않을까 싶다. 그게 좋을 수도 있지만, 다양성과 피드백에 있어서는 그리 좋지 않다고 보고 있다.
사실 유니티에서 데모를 만드는 주된 이유는, 그 기능을 내세운다기보다는 "이런 기능이 있으니 한 번 써보는 게 어때?"라는 취지다. 물론 첨단 기술이 도입됐을 때 이것이 어떻게 도입됐는지 설명하는 그런 취지도 있긴 하다. 하지만 주된 방향은 전자다.
그런 데모들을 여럿 만들고, 이를 유니티 커뮤니티 안에서 공유하면서 활발히 피드백을 받고 있다. 데모하면 아마 플레이타임이 굉장히 짧고 작은 규모의 프로젝트만을 생각하지만, 유니티는 그 데모와 샘플의 범주가 넓다. 최근에 공개한 FPS 샘플을 보면 16인 멀티플레이 지원에, HDRP용 에셋이 포함된 필드 및 아레나 레벨, 멀티프레이 모드, FPS 넷코드 등이 구현되어있다. 조금 볼륨이 작긴 하지만, 하나의 게임이라고 봐도 무방할 정도다.
유니티는 이제 게임 외에도 다른 분야에도 쓰이고, 그래서 게임뿐만 아니라 다른 분야에 활용될 기술을 데모로 보여주기 위해 여러 가지 샘플을 제작하고 있다. 게임뿐만 아니라 다양한 곳에서 피드백을 받고 있고, 그러면서 기능들을 다시금 재조명한다. 우리가 미처 보지 못했던 문제가 다른 분야에서는 보이기 때문이다. 우리가 직접 어떤 완성된 예시를 보여주는 것도 좋지만, 그렇게 해서 그 가능성이 좁아지는 것이 아닐까, 그렇게 생각한다.
Q. 유니티가 다양한 업계에서 활용되는 만큼, 엔진에서 그래픽 관련 기술을 구현할 때 게임 개발자뿐만 아니라 여러 업계를 고려해야 할 것 같다. 그때 가장 어려웠던 점은 무엇인가?
디자인이라는 측면에서 보면 각각 비슷해보일지 모르겠다. 그래픽스와 관련된 디자인의 대다수는 2D로 된 환경에서 3D를 구축해나간다는 기본이 있으니 말이다. 하지만 각각이 추구하는 방향이 다르다. 그래픽이라는 요소는 그것만 달랑 떼어놓고 이야기할 수 없다. 그냥 모양만 만드는 게 전부가 아니기 때문이다.
건축을 예로 들면, 건물은 그냥 모양만 그려내는 것이 아니지 않나? 디테일하게 살펴보면 뼈대나 구조, 공법에 활용된 자재 등등, 여러 가지가 포함이 된 것이다. 완성예상도에만 한정한다면 이런 것들이 전부 보이지는 않겠지만, 어찌 되었거나 이런 요소들이 수정했을 때 어떻게 변화하는지, 이걸 분석해야 할 필요가 있다.
개인적으로 이런 시뮬레이션류 중에서 가장 인상깊고 재미있게 본 건 의료 시뮬레이션 분야다. XR 기술을 활용해서 환자를 개복해서 수술을 집도하지 않고 어렵고 복잡한 수술 과정을 실습한다는 게 흥미진진했기 때문이다. 이 과정에서 인체의 장기의 외형을 정교하게 실사로 표현하는 것도 중요하고, 각 부분의 움직임 하나하나까지 다 묘사하는 것도 중요하지 않나.
게임에서도 실사에 가까운 그래픽을 구현하기 위해서 노력하지만, 워낙 범위가 넓기 때문에 일부에서는 '그렇게 보이게끔' 처리한다. 하지만 산업 디자인에선 그렇지 않다. 말 그대로 실사여야 한다. 게임뿐만 아니라 다른 업계에 활용되는 것까지 고민하다보면, 실제 사물에 가까운 그래픽 어떻게 더 효율적으로 구현할 수 있을까, 더욱 더 고민하게 되는 것이다.
Q. 2D의 느낌을 담은 3D 등, 기존의 2D와 3D의 경계를 허무는 그래픽도 최근 일부 게임 장르에서 언급이 되고 있다. 그와 같은 기술과 방향에 대해서는 어떻게 생각하나?
게임에서 그래픽은 기술 차이라기보다는, 스타일의 차이라고 보고 있다. 어떤 것이 우위에 있다 이런 개념이 아니라, 개발자의 상황이나 목표에 따라서 채택하는 방법이 다를 뿐이다.
스타일의 관점에서 본다면 2D와 3D를 완전히 별개로 둘 이유는 없지 않나. 2D 게임에 3D 배경을 집어넣는다거나, 3D 게임인데 2D 플랫포머의 형태로 구현한다던가, 이미 개발자들은 경계를 넘어서 자신만의 스타일을 보여주고자 노력하고 있다.
그 방향에 대해서 우리가 일일히 다 맞춤식으로 지원하는 것은 한계가 있다. 게임개발자들은 많고 그들이 원하는 스타일은 각각 다른데다가, 때로는 서로 상충하기 때문이다. 그래서 이걸 다 일일히 맞추기보다는, 어떤 큰 방향에서 개선을 하되 개발자들이 유연하게 적용할 수 있도록 하는 게 중요하다고 보고 있다. 그 과정에서 개발자들이 좀 더 쉽게 선택하고, 조율할 수 있도록 지원하는 방향으로 가고 있다고 보면 되겠다.
Q. 2D 툴의 개선도 키노트에서 발표가 됐다. 2D도 게임에서 큰 부분을 차지하지만, 최신 기술을 선보이기 어렵다는 점 때문에 그간 메인에 서지 못했던 분야다. 이 분야에 대해서 재조명하게 된 계기가 있다면?
2D 게임이 게임 전체에서 차지하는 비중이 굉장히 높지 않나. 실제로 2D는 굉장히 역사가 오래된 스타일이고, 게임을 개발하는 사람들 그리고 게이머들에게는 굉장히 중요한 스타일이기도 하다.
앞서 말한 것처럼 게임에서 그래픽은 단순히 기술에 한정된 것이 아닌, 스타일이다. 그 특정 스타일을 좀 더 쉽게 구현할 수 있도록 하려면 어떻게 해야 할지 툴 전문팀과 테크팀에서 계속 고민을 해왔다. 그리고 그 과정을 키노트의 메인으로 삼지는 않았더라도, GDC 세션이나 워크샵 등에서 꾸준히 공유해왔다.
이러한 고민과, 문제 해결을 위한 노력이 축적되면서 2D 그래픽 관련 분야에 강점이 생겼다고 판단했다. 이번에 키노트에서 발표된 2D 워크플로우, 2D 애니메이션, 라이트, 쉐도우, 쉐이더 그래프 등을 살펴보자. 그간 일일히 스프라이트로 그려내거나, 혹은 용도에 따른 툴을 일일히 만들어내야 했던 것이지 않나. 또 이전부터 2D 리깅 애니메이션 관련해서 여러 가지 기능도 있었는데, 이번에 2D 툴을 개선하면서 이 역시도 개선이 됐다. 2D 게임 개발자들에게 이런 점들이 큰 도움이 될 것이라고 보았고, 그들이 좀 더 많이 이 정보를 알 수 있도록 키노트에서도 메인으로 나가게 된 것이 아닌가 싶다.
Q. 이번의 유니티에서 발표한 것들을 보면 초고퀄리티의 그래픽, 첨단의 기술뿐만 아니라 유연함, 호환성을 강조한 느낌이 든다. 유니버설 렌더링 파이프라인도 그런 취지에서 만들어진 것인가.
비주얼과 퍼포먼스라는 측면을 살펴보자. 그것이 엄청난 퀄리티의 그래픽과 완전히 똑같은 뜻은 아니지 않나. 물론 리얼타임 레이트레이싱 같은 기술이 보여주는 실사의 느낌, 압도적인 그래픽, 그리고 이를 최적화하는 기술이 그래픽에서는 굉장히 중요한 비중을 차지하는 건 사실이다. 하지만 그것이 그래픽 기술의 전부는 아니지 않나.
유니버설 렌더링 파이프라인은 완전히 새로운 렌더링 파이프라인은 아니다. 조금 더 진화한 개념이다. HDRP와 동일하게 비주얼 이펙트 그래프, 쉐이더 그래프, 후처리, 라이트맵 등 기능을 활용해서 렌더링이 손쉽게 가능하다. 여기에서 고해상도라는 부분보다는, 렌더링한 결과물을 다른 플랫폼에 돌려도 퀄리티나 해상도 변화가 일어나지 않고 온전히 구동하도록 하는 것을 목표로 둔 셈이다.
더 나아가서 렌더링 파이프라인을 활용해서 별도의 코딩 없이도 여러 가지 효과를 바로바로 렌더링해서 적용할 수 있게끔 했다. 기존에는 이런 특성들을 적용하기 위해서는 스크립트로 조건을 일일히 설정하고, 함수를 호출하고 그 함수에 들어갈 애셋들을 구축하는 식으로 해야 했는데, 이제는 각 특성으로 분류한 뒤에 이를 그래프와 파라미터에 대입했다. 코딩을 모르는 아티스트들도 각각의 파라미터, 그래프를 조작해서 원하는 효과를 얻을 수 있게끔 말이다.
Q. 분명 코딩 비중을 낮아지면 아티스트들, 그리고 초보 개발자들은 반기지만 전문 개발자들은 조금 다르게 생각할 것 같다. 결국 자신들에게 딱 맞게 커스터마이징하려면 코딩이 필요할 테니 말이다. 오히려 이런 방향이 개발력 향상에 도움이 되지 않을 것이라 보는 견해도 있는데, 이런 관점에 대해서는 어떻게 생각하고 있나?
이해한다. 앞서 말했듯이, 최대한 많은 요구에 맞춰서 무언가를 내놔도 모두가 만족하리라는 보장은 없다. 따라서 자신이 원하는 것에 맞춰서 세팅이나 커스터마이징을 해야 할 것이고, 그 과정에서 프로그래머의 역할은 굉장히 크다. 그들이 내부 구조를 분석한 뒤, 아티스트들이 요구하는 것을 맞춰서 구현할 수 있도록 짜맞춰나가기 때문이다.
그렇지만 아티스트의 관점도 보자. 흔히들 아티스트와 프로그래머는 서로 상극이라고 하지 않나. 아티스트는 프로그램이 어떻게 돌아가는지 모른다. 프로그래머는 그 요구가 안 된다는 건 알지만, 왜 필요로 하는지 또 어떤 결과물을 얻고 싶어서 그런 요구를 하는지, 다른 방법은 없는지를 묻는다. 서로가 서로의 분야를 모르는 만큼, 이 간극은 메워지지 않는다.
코딩의 비중이 낮아지고 그 요소들이 시각화가 되면, 아티스트들이 다루기가 쉬워진다. 그리고 이렇게 된 것이, 아예 코딩을 안 썼다는 의미가 아니다. 내부에서 돌아가는 코딩과, 로직은 동일하다. 다만 그것이 겉으로 드러난 방식이 다른 것이다. 아티스트들이 그 로직에 대해서 이해하는 것뿐만 아니라, 프로그래머도 그들이 샘플로 만들어낸 것을 보고 어떤 것을 원하는지, 왜 그렇게 요구를 했는지 파악할 수 있지 않겠나.
물론 더욱 더 깊이 들어가서 엔진의 성능을 한계까지 끌어내고자 한다면, 코딩의 비중이 낮아질 수가 없다. 다만 그 전 단계까지 가는 길을 완만하게 다듬었다고 보면 되겠다.
Q. 분야는 다르지만, C# 소스 패키지라던가 DOTS 등도 지향하는 방향이 비슷한 것 같다.
그 둘은 프로그래밍과 훨씬 더 깊은 연관이 있으니 좀 다르긴 하다, 사용되는 기술도 다르고. 그렇지만 목표 중에 한 가지는 동일하다. 프로그래밍을 모르는 사람도 좀 더 쉽게 접근할 수 있도록 해야 한다는 것이다.
Q 초고도화된 그래픽 기술을 언급할 때 리얼타임 레이트레이싱을 빼놓을 수 없다. 아직은 일부 데모로만 언급이 되기 때문에 일반인들에게는 실감이 안 되고 있는데, 대중화 시기는 어느 정도라고 보나?
아직은 하드웨어의 가격 문제 때문에 대중화에 대해서 언급하기에는 이르지 않나 싶다. 또 하나 오해하고 있는 부분이, HDRP가 리얼타임 레이트레이싱을 위한 툴 중 하나라고 보는 것이다. 고해상도 그래픽을 더 효율적으로 구현하기 위한 렌더링 파이프라인이고, 그 렌더링 파이프라인을 적용해서 구현하고자 하는 것 중에 하나가 리얼타임 레이트레이싱이다.
그리고 리얼타임 레이트레이싱 자체가 굉장히 복잡하고 많은 연산 과정을 처리하는 것이기 때문에 렌더링 파이프라인을 개선해도 하드웨어에서 높은 처리 능력이 요구될 수밖에 없다. 물론 개인이 아닌 산업체에서는 그 정도 하드웨어를 충분히 구축할 수 있는 환경인 만큼, 이쪽은 별도로 생각해봐야 할 것이다.
Q. 유니티 엔진의 앞으로의 발전 방향을 설명한다면?
그간 고해상도, 그리고 고퀄리티라는 측면에 대해서 굉장히 강조해왔다. 다음 세대에는 이 두 가지뿐만 아니라 다양한 사용자에게 친화적이냐 아니냐도 중요한 요소가 되지 않을까 싶다.
세상에는 리얼타임 레이트레이싱, HDRP를 사용할 정도로 규모가 크고 정말 퀄리티 높은 프로젝트를 만드는 팀도 있다. 엔진에 대한 이해도도 굉장히 높고, 얼마든지 그 기능을 극한까지 끌어올릴 수 있는 개발자들도 많고. 그렇지만 전체적으로 보면 트리플 A 게임, 혹은 고퀄리티 그래픽의 게임만 있는 것은 아니지 않나. 소규모 개발팀이 모여서 작게 만들고 있는 프로젝트도 있고, 캐주얼하게 만드는 게임도 있다..
후자에 적용되는 기술을 만드는 것은 그간 별로 주목받지 못한 일이었다. 구현하는 방법은 굉장히 간단하지 않나. 스프라이트를 그냥 다 그리고, 또 그리고, 그렇게 만든 것을 적절히 붙이고, 호출하고, 없애고, 그러는 식으로 구현되지 않나. 즉 첨단 기술을 요구하는 것도 아니고, 기술력이 돋보이지도 않는 과정이다. 하지만 기존의 그 번거로웠던 스프라이트 과정을 줄일 수 있게 되면서, 많은 2D 게임 개발자들이 자신의 작품을 좀 더 쉽게 만들어낼 수 있게 될 것이다.
유니티는 기술을 자랑하는 수단이 아니다. 개발, 창조를 위한 도구다. 즉 유니티를 활용해서 더욱 더 많은 사람들이 자신의 작품을 창조적으로, 완성도 있게 만들 수 있다는 것이 앞으로는 더욱 더 중요해질 것이라고 보고 있다.
Ruudi@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
