[언리얼서밋] 리니지2M, 왜 언리얼로 개발하게 됐을까?

게임뉴스 | 윤서호 기자 | 댓글: 35개 |


▲ 엔씨소프트 김종현 클라이언트 리드

몇 년 전만 해도 모바일 MMORPG는 상상하기 어려운 장르였다. 당시 통신 기술로는 대규모 인원이 동시에 동일 서버에 접속하기 어려웠다. 뿐만 아니라 모바일 디바이스 환경에서 MMORPG의 방대한 리소스를 소화해내기 힘들었다.

점차 기술이 발전하면서 모바일에서도 MMORPG의 오픈 월드와 대규모 리소스를 소화해낼 수 있게 되자, 시장에는 모바일 MMORPG들이 하나둘 자리잡기 시작했다. 최근에 출시된 일부 게임은 PC MMORPG급의 퀄리티를 어느 정도 구현할 만큼 기술력을 보여주기도 했다.

이러한 퀄리티 있는 MMORPG 중에는 언리얼 엔진을 채택한 작품들이 상당 수 있다. 과연 언리얼 엔진의 어떤 점을 MMORPG 개발자들이 눈여겨보고 있으며, 또 어떤 식으로 엔진을 활용해서 모바일 MMORPG를 만들어가고 있는 걸까? 엔씨소프트의 김종현 클라이언트 리드는 오늘(14일) 서울 그랜드 파르나스 호텔 그랜드 볼룸에서 열린 언리얼 서밋 2019에서 현재 개발 중인 리니지2M의 사례를 통해서 설명해나갔다.


김종현 리드는 우선 '리니지2M' 프로젝트가 시작할 때 주어진 목표에 대해서 먼저 언급했다. 임원진에서 제시한 '리니지2M'의 방향은 최소 천 대 천의 대규모 공방이 이루어지는 MMORPG였다. 그만한 인원을 수용하기 위해서는 서버에 채널이 분산되지 않아야 했으며, 리니지2급의 월드를 모바일로 구현해야 한다는 것이었다. 즉 원 채널 심리스 오픈 필드를 구축해야 한다는 미션이 주어진 셈이었다.



▲ 목표는 "리니지2의 풀3D그래픽의 감동을 재현하는 것"과 "원 채널 심리스 오픈 월드 구현" 두 가지였다

그는 현재 게임 엔진 시장을 살펴보면 유니티와 언리얼의 양립 구도로 되어있다고 보았다. 그 중 언리얼을 채택하게 된 이유로 우선 리니지2가 언리얼 엔진2를 썼기 때문에 눈길이 끌렸다고 밝혔다. 전작이 언리얼을 썼다고 해서 꼭 후속작을 언리얼로 해야 한다는 법은 없지만, 맥락으로 볼 때나 은연 중에나 의식이 될 수밖에 없었다고 고백했다.

그가 언리얼에서 주목한 것은 엔진 내 소스가 공개되어있으며, 오픈 소스라는 점이었다. 상용 엔진으로 개발을 하다보면 여러 어려운 이슈들이 종종 발생한다. 이를 인터넷을 검색하고 UDM을 찾아서 해결하거나, 혹은 엔진 개발사의 서포트팀에 연락해서 해결하고는 하지만 그 과정은 쉽게 풀리지 않은 경우가 다수다. 그래서 개발자가 직접 엔진을 열어서 디버깅을 하고, 혹은 자신에게 맞춰서 고쳐 쓰고자 하는 니즈가 생기게 된다. 언리얼은 이 조건에서 가장 잘 맞는 엔진이었다고 설명했다. 물론 그 소스가 방대해서 전부 보기는 어렵지만, 자기가 개발할 때 필요한 부분들을 볼 수 있다는 점은 매력적이었다고 덧붙였다.

언리얼은 선택한 가장 큰 이유로는 큰 심리스 오픈 월드를 만들기 편하다는 점 때문이었다. 이전 버전부터 랜드스케이프 기능이 괜찮았고, 새롭게 업데이트되면서 월드 콤포지션과 레벨 스트링 기술의 바탕이 잘 다듬어졌기 때문이었다. 그래서 리니지2M에 요구되는 방대한 심리스 오픈 월드를 구현하기가 쉽다고 판단해서 언리얼 엔진을 채택하게 됐다고 밝혔다.



▲ 언리얼 엔진은 방대한 심리스 필드를 구현하기에 적합했다고 판단했다

김종현 리드는 리니지2M은 2년 전부터 프로젝트가 언급이 되고, 본격적으로 프로세스에 들어선 것은 1년 반 전쯤의 이야기라고 회상했다. 언리얼 엔진을 사용하기로 결정하고 개발자들을 찾았지만 당시에 모바일 쪽에서 언리얼 엔진을 제대로 쓴 사람이 사내에 많지 않았다. 그리고 외부에서 채용한 인력도 언리얼 엔진보다는 다른 엔진을 더 많이 사용한 개발자가 많았다. 그럼에도 한 달 정도 지나자 다들 언리얼 엔진에 금방 적응했기 때문에 이 부분은 크게 문제가 안 됐다고 설명했다.

인력을 구한 다음에는 엔진을 어떤 식으로 활용할까 하는 문제에 봉착하게 됐다. 엔진 내부를 볼 수 있고 수정할 수 있다고 하지만, 개발 과정에서 이를 활용하느냐 마느냐는 별개의 문제였다. 엔진도 게임처럼 지속적으로 버전업이 되고, 그에 따라서 기능이 바뀌거나 수정이 된다. 그런 상황에서 자체적으로 한 번 엔진을 수정하게 되면 그 업데이트 내용에 맞춰서 수정하거나 일부 기능을 처리해야 하는 문제가 발생한다. 즉 당장 개발에 쓰기는 편하지만, 나중에 엔진이 업데이트되면서 업무가 늘어나는 것이다.

리니지2M 개발팀에서는 일단 엔진을 수정하되, 최소한으로 한다는 원칙을 정했다. 디버깅 등 급한 이슈가 발생했을 때 자체적으로 최대한 빨리 해결할 수 있어야 했기 때문이다. 다만 한 번 API를 건드리기 시작하면 계속해서 건드리게 되는 만큼, 이런 부분은 신중하게 볼 필요가 있었다. 이런 부분은 미리 살펴두는 게 좋다고 조언했다.



▲ 한 번 엔진을 건드리게 되면 업데이트 때마다 일이 쌓이기 때문에, 이를 최소화하는 방향으로 갔다

엔진 수정 후에 빌드 배포는 소스 빌드가 아닌 인스톨드 빌드 방식을 채택했다. 소스 빌드는 엔진 소스를 바로 빌드에 적용하기 때문에 수정 사항이 바로바로 적용되는 이점이 있지만, MMORPG는 다수의 인력이 개발하는 만큼 수정 사항이 바로바로 적용되는 것보다는 안정성을 요구했기 때문이다. 그래서 엔진 소스에서 인스톨드 버전을 따로 뽑은 뒤에 배포하는 인스톨드 빌드를 채택하게 됐다고 설명했다.

그 외에도 CI툴과 쉐어드 DDC를 개발 과정에서 활용했다고 밝혔다. 특히 CI툴은 빌드 수정할 때 사람이 일일히 손보기 어려운 만큼, 이 과정을 자동화할 때 꼭 필요하니 가용하다면 유료 툴을 활용하는 것이 좋다고 조언했다. 또 하나 강조한 사항은 언리얼을 쓰는 개발자라면 컴파일 시간을 줄이기 위해서 인크레디 빌디, XGE를 써볼 것을 권했다



▲ 빌드 관리도 개발 과정에서는 중요하다

많은 개발자들이 개발 과정 중에 엔진 업데이트를 하느냐, 마느냐 하는 상황에 처하게 된다. 이에 대해서는 조금 참으라고 조언했다. 업데이트 초기에는 기존의 엔진 버전과 충돌이 나는 경우가 많고, 그 외에도 추가된 기능이 이후 업데이트에서 수정되면서 다시 변경해야 할 일도 있기 때문이다. 그렇다고 엔진 업데이트를 아예 안 할 수 없다는 점도 설명했다. 엔진 버전이 업그레이드되면서 더욱 더 고퀄리티의 작업이 가능해지기도 하고, 예전에는 어려웠던 작업이 쉽게 가능하기 때문이다. 그래서 김종현 리드는 리니지2M 팀 기준으로는 해당 업데이트의 첫 버전을 바로 적용하지 않고, 그 다음 단계 버전에서부터 차츰차츰 적용해나가는 방식을 채택했다고 밝혔다. 예를 들면 4.2 버전이면 4.20을 바로 쓰는 것이 아니라 4.21 무렵부터 준비하는 식이다.

이 다음에는 물리 기반 렌더링(PBR)을 어느 정도까지 구현할 것인가? 하는 과제가 주어졌다. 이 과제를 리니지2M 개발팀에서는 쉐이더 모델5(SM5)를 기준으로 잡았다. 다만 이 기준은 처음에 리니지2M 개발에 들어갔을 때는 상당히 어려운 과제였다. 당시의 언리얼 엔진 버전은 4.17이었는데, 이 버전은 모바일 렌더러를 OpenGL ES2.0을 기준으로 잡았다. 쉐이더 모델5가 OpenGL ES3.1 버전 정도로 잡은 만큼, 이를 모바일 환경에서 구축하기가 어려웠던 것이다. 그래서 처음에는 OpenGL ES2.0에 맞춰서 작업했는데, 이는 일반인이 보기에는 다소 차이가 있는 정도였지만 아티스트들이 보기에는 PBR의 격차가 상당히 컸다고 고백했다. 자세히 보면 빛 연산이 잘 이루어지지 않아서 뿌옇게 번지거나, 어두운 곳에서 재질감이 안 사는 등 문제가 발생했기 때문이다.

결국 OpenGL ES2.0을 버리고 다시 OpenGL ES3.1에 맞추는 수준으로 작업하는 방향으로 진행했다. 이 과정에서 디바이스 요구 사양이 높아지기 때문에 이 결정은 사업부와 임원진도 검토를 했어야 했다고 고백했다. 그렇지만 회사에서도 리니지2가 처음 나왔을 때 고사양을 지향하고 나왔던 것처럼 리니지2M 역시도 고사양을 지향하는 방향으로 결정하면서 쉽게 지원이 결정됐다고 설명했다.

PBR을 그렇게 끌어올리기로 결정한 다음에는 서브스탠스창에서 작업한 프리뷰가 실제 게임에서 본 것과 최대한 비슷하게 작업한다는 목표를 세웠다. 그러기 위해서 기본적이고 공통적인 마테리얼은 최대한 단순하게 작업해서 작업 효율을 높이고, 메가스캔 같은 실사 아트 애셋을 우선 최대한 많이 구축했다. 여기서 핵심은 아트팀이 얼마나 이에 대한 이해도가 있고 능력이 있나 하는 부분이었던 만큼, 아트팀이 굉장히 고생을 많이 했다고 고백했다.



▲ PBR 지침도 바꾸고 개선 작업이 이루어졌다

이렇게 작업하면서 어려웠던 점으로는, 예전 버전에서는 프리뷰 렌더링 레벨이 저장이 되지 않았다는 점을 꼽았다. 렌더링한 것을 열면 SM5로 오픈이 되는데, 프리뷰 세팅이 안 된 상태로 열리다보니 각 직원들의 엔진 세팅에 따라서 잘 될 때도 있고 안 될 때도 있었기 때문이었다. 최근에는 버전 업데이트를 통해서 이런 문제가 없어졌다고 덧붙였다.

또한 4.17 버전을 기준으로 하면 랜드스케이프 레이어가 3개밖에 없어 작업이 불편했는데 이후 4개로 늘어나면서 랜드스케이프 구성도 쉬워졌다고 설명했다. 모바일 환경에서는 기존의 스킨, 헤어 쉐이딩 모델을 적용하기 어려웠던 만큼 이를 새로 구축할 필요도 있었다.

SSAO(Screen Space Ambient Occlusion), 즉 사물에 의해 생기는 빛의 감쇠 효과 적용도 리니지2M에서는 들어갔다. 개발팀에서는 이를 적용하는 것이 비싸기도 하고 무겁기도 하지만, 이것이 주는 사물의 자연스러운 묘사 떄문에 채택했다고 설명했다. 이는 기본 설정이 아닌 옵션으로 들어갈 예정이라고 밝혔다.

또한 언리얼에서 기본으로 설정된 라이트맵은 최대한 안 쓰는 방향으로 잡았다. 일부 개발팀에서는 어떻게 라이트맵 없이 만들었냐는 질문을 하지만, 오픈 필드가 주가 되는 리니지2M에서는 오히려 라이트맵을 쓸 일이 그리 많지 않았다고 설명했다. 방대한 오픈필드에서 라이트맵을 적용하게 되면 쉐이더 용량이 어마어마하게 커지는데, 그만한 효과가 나지 않았기 때문에 이를 배제했다고 덧붙였다.

김종현 리드는 필드와는 별개의 구역인 던전에서는 라이트맵을 구현할 예정이었고 밝혔다. 그러나 이에 맞는 라이트맵을 쓰는 과정이 번거롭고 힘들었기 때문에 이 부분은 다른 식으로 구현했으며, 이 과정은 아티스트들과 엔진 프로그래머들이 한 부분이라서 이 자리에서는 자세히 설명하기 어렵다고 말했다.




오픈필드를 구현해야 하는 만큼, 넓은 시야 거리도 중요했다. 예시로 잡은 스크린샷은 1.5km에서 2km인데, 이를 랜드스케이프 기능으로 구현했다. 처음에 그 정도 시야거리도 모바일에서 구현이 될까 의심이 들었다고 고백했다. 현 단계에서는 일단 구동은 되는 상태라고 덧붙였다. 또한 예전에는 다른 팀에서도 랜드스케이프 기능을 활용하지 않았지만 최근에는 언리얼 엔진의 랜드스케이프 기능이 개선되면서 많이 사용하고 있다고 설명했다. 특히나 마테리얼 세팅을 해서 퀄리티가 높은 지형도 만들어낼 수 있다는 점을 높게 샀다.

'리니지' 시리즈는 방대한 심리스 월드 외에도 텔레포트로 이리저리 필드를 오가는 특징이 있다. 이를 리니지2M에서 구현하기 위해서도 고려할 부분이 있었다. 텔레포트 과정을 살펴보면 그 방대한 심리스 월드의 시야가 한 순간에 없어졌다가, 텔레포트한 지역의 에셋을 다 불러오는 상태로 만들어야 한다. 사측에서는 이 로딩 과정을 없애라는 방침을 내렸고, 이것이 불가능하더라도 로딩 속도를 최대한 줄여서 플레이의 흐름이 끊기지 않게끔 해야 했다.

이를 처리하기 위해서 랜드스케이프와 채팅 메시지 등 화면에 들어가는 여러 가지 요소들을 잘게 나눠서 최소화하는 방법을 채택했다. 잘게 나누었기 때문에 불러오는 것이 큰 문제가 되지 않기 때문이다. 다만 굉장히 넓은 오픈 월드를 구축을 해야 하는 만큼, 너무 잘게 나누면 작업하는 데 불편함을 겪기 때문에 이 단위를 잘 정하는 것이 중요했다고 덧붙였다. 또한 그것들을 일일히 다 처리하기에는 벅차기 때문에 자동화를 하는 과정도 필요했다고 강조했다. 월드 콤포지션 역시도 수정을 가해야 했는데, 퍼시스턴스 레벨을 하나만 두고 나머지를 그 한 레벨에 붙였다 뗐다 하는 식으로 구현했다.




언리얼 엔진에서 가장 많이 언급이 되는 블루프린트에 대해서는 호불호가 갈리는 데다가, 복잡한 로직을 구조화하기 어렵기 때문에 최소한으로 사용한다는 원칙을 세웠다. Anim 등 꼭 써야 하는 부분만 쓰거나, 혹은 프로토타입으로 기능을 한 번 보고자 할 때만 쓰고 그 외에는 되도록이면 안 썼다고 밝혔다.



▲ 결국 블루프린트는 최소화하는 방향으로 갔다

또한 언리얼 엔진은 개발 과정에서 확인한 결과 C++ 언어 중에서 최신 버전인 C++14와는 그리 잘 맞지 않았다고 설명했다. 비주얼 스튜디오 상에서는 잘 구현이 되지만 GCC 등에서 컴파일할 때는 어떤 환경에서는 되고, 어떤 환경에서는 오류가 나는 일이 잦았던 것이다 .특히 템플릿 관련 부분에서 오류가 잦았는데, 이는 문법적인 오류이기 때문에 조치를 취하기가 어렵고, 여기에 코스트를 들이는 것이 소모적이었다. 흔히 말하는 STL에 대해서는 언리얼에서 그리 많이 안 쓰고, 자체적으로 제공하는 템플릿을 쓰는 게 더 나았다고 설명했다. 특히 STL을 쓰면 로케이터를 제대로 언리얼 쪽 메모리에 연결하지 않았을 때 iOS 버전에서 문제가 생기는 현상이 최근 발견됐다고 덧붙였다.

마지막으로 김종현 리드는 그간 언리얼 엔진은 여러 면에서 많은 발전을 이루었지만, 특히 포트나이트가 성공하고 난 뒤, 그리고 4.21 버전부터 모바일 게임 개발 부문으로 많은 성과를 냈다고 평가했다. 이전에도 모바일에 맞춰서 개발할 수 있었지만, 그 두 시점부터 고퀄리티면서 빠르게 모바일에서 동작하게끔 변했다는 것이다. 앞으로도 언리얼 엔진이 지속적인 업데이트를 통해서 좀 더 고퀄리티의 성능을 모바일 환경에서 구현할 수 있기를 바란다고 하면서 강연을 마쳤다.

댓글

새로고침
새로고침

기사 목록

1 2 3 4 5