오즈라엘

올해 3월, WebGL의 프리뷰(preview) 버전이 Unity 5.0에 포함되어 릴리즈되었습니다. 그 후, 구글은 크롬 브라우저에서의 NPAPI 지원을 중단하였습니다. (기본값) 이는 더 이상 크롬 브라우저에서 Unity Web Player를 실행할 수 없다는 것을 의미합니다. 때문에, 그 대안으로 WebGL을 사용해야만 합니다. 이미 일부 개발자들이 WebGL로 게임을 배포하였습니다만, 기존 Web Player 게임을 WebGL로 포팅하는 데 애로 사항을 겪고 있는 것으로 알고 있습니다. 이는 Web Player와 WebGL은 완전히 다른 플랫폼이기 때문입니다. 웹 브라우저에서 게임을 돌린다는 궁극적인 목적은 동일하지만, 기반 기술은 완전이 다른 플랫폼입니다. 또한 WebGL은 매우 빠르게 성장하고 있기 때문에 시간이 지날 수록 지원 기능들과 상황이 시시각각 다를 것으로 생각합니다.

이러한 이유로, WebGL에 대한 우리의 계획에 대한 이야기를 할 까 합니다. 이 글은 유니티 공식 포럼의 WebGL 로드맵 글을 번역 및 요약한 글입니다.

주의 : 이 글의 모든 정보는 현재의 WebGL 생태계와 계획에 의존하고 있습니다. 이 모든 것들이 미래에는 어떻게 바뀔 지 장담하지는 못합니다. 기능들에 대한 구체적인 릴리즈 날짜를 보장하지는 못합니다. 또한, 일부는 진행하지 않기로 결정 할 가능성도 있습니다. 따라서, 이 글에서 버전이 언급되는 것은 현재의 계획일 뿐이며 미래를 보장하는 것은 아닙니다. (적고보니 보험광고같은 느낌이;;;)

Unity 5.1의 WebGL

5.1에서의 가장 큰 이슈중 하나는 5.0에서 발견 된 버그들을 수정하는 것입니다. 게다가, IL2CPP팀은 지난 몇 개월 간 IL2CPP의 무수히 많은 문제점들을 고치느라 매우 바쁜 시간을 보냈습니다. WebGL은 스크립트 런타임으로 IL2CPP를 사용하다보니 이로 인해 WebGL 플랫폼의 품질도 좋아지게 되었습니다.

또한, Unity 5.1에서의 WebGL 사용자들에게 중요한 이슈 중 하나는 텍스쳐 압축입니다. 텍스쳐 압축을 통해서 전송량 및 용량을 절약하고, 런타임중에 압축을 풀어 GPU 친화적인 DXTn 텍스쳐로 사용합니다. 일반적으로 텍스쳐가 사이즈를 차지하는 주 된 에셋이기 때문에 이를 통해서 WebGL 컨텐츠의 배포 용량을 획기적으로 줄일 수 있게 됩니다.

"프리뷰(Preview)" 레이블

요즘, 프리뷰(preview) 레이블을 언제 제거할 것인가에 대한 질문을 많이 받습니다. 하지만 이에 대해서는 확답을 드릴 수가 없는 상황입니다. 우리는 플랫폼이 안정화 되었다고 판단되어야만 프리뷰 레이블을 제거할 것입니다. 이는 유니티에서의 기술적인 문제 뿐만 아니라 WebGL의 기술 생태계 역시 충분히 준비된 시점을 의미합니다. 그러기 위해서는 브라우저의 개발사들이 우리가 원하는 기능을 구현해주어야만 합니다. 때문에 우리가 기능을 다 구현했다고 프리뷰 레이블을 제거하는 것은 말이 안되는 행위입니다. 우리는 주요 웹 브라우저 업체와 이야기중이고, 우리가 원하는 기능을 위해 최선을 다하고 있다고 믿고 있습니다.

메모리 이슈

현재의 Unity WebGL에서의 가장 큰 이슈중 하나가 메모리 이슈입니다. 특히 크롬 브라우저에서 Unity WebGL을 돌릴 경우 메모리가 낭비되는 현상이 있습니다. 

- 유니티의 WebGL 콘텐츠를 위해서는 연속된 공간의 메모리 블럭이 필요합니다. 이 사이즈는 WebGL Player 셋팅에서 설정할 수 있습니다. 이 사이즈는 리소스를 로드하면서 필요한 메모리 공간 만큼 충분히 확보되어야 합니다. 메모리 프로파일러를 통해서 공간이 어떻게 쓰이고 있는 지 디버깅 가능합니다. 이는 웹브라우저의 힙(heap) 메모리에 연속적인 공간이 필요합니다. 브라우저의 메모리가 낮게 잡혀있거나 힙이 파편화(fragmented)되어 있는 경우 메모리 할당이 실패해버립니다.

- 브라우저는 자바스크립트(JavaScript)를 파싱하는 과정에서 많은 메모리를 사용합니다. Unity WebGL Player로부터 파생된 자바스크립트 코드는 다른 것에 비해 매우 큰 메모리 공간을 소모합니다. 그리고, 자바스크립트 VM은 이러한 코드들을 분석하는 과정에서 매우 많은 양의 메모리를 필요로합니다. 득히, 크롬 V8은 때때로 이러한 이슈때문에 크래시가 일어나곤 합니다. 반면 파이어폭스는 asm.js로 AOT 컴파일을 수행하기 때문에 비교적 적은 메모리를 사용합니다.

이러한 이유들로 메모리 문제는 가장 큰 이슈이긴 합니다만 고치는 것이 쉽지가 않습니다. 현 시점에서는 우리가 할 수 있는 것은 결과 코드 사이즈를 줄이는 것 뿐입니다. 우리는 사내 워크샵에서 이러한 문제를 고민하였으며, 배포 사이즈를 1.2M까지 줄이는 데 성공하였습니다. 코드 스트리핑을 강화하고 컴파일러 설정을 개선하고 불필요한 코드를 제거 하는 등의 작업을 하였으며 이는 계속 개선해 나갈 것입니다. 이러한 개선 사항들은 5.2에 적용될 것으로 예상합니다. 또한 빌드에 포함된 코드 모듈을 시각적으로 확일 할 수 있는 툴을 만들고 있습니다. 얼마나 많은 코드들이 어떤 것에 의해 생성이 되었는 지 등을 확인할 수 있게 됩니다. 이 툴은 빨라야 5.3은 되어야 적용 될 것입니다. 이를 통해서 빌드 결과 사이즈를 줄일 수 있을 것입니다. 결과물의 코드 사이즈가 줄어들면 코드 파싱 시간이 줄어드는 만큼 구동 시간이 빨라지게 될 것입니다.

궁극적으로는, 브라우저의 기술 발전이 메모리 이슈를 훨씬 더 많이 해결할 수 있을 것으로 기대하고 있습니다. 모든 브라우저들이 64비트로 만들어지고 있으며 더 큰 메모리 공간을 사용할 수 있게 됩니다. 또한, 더 중요한 것은, 모질라, 구글, 마이크로소프트가 웹어셈블리(WebAssembly)라 불리우는 신기술을 만들고 있다는 것입니다. 이는 asm.js를 바이트코드(ByteCode) 포맷으로 패킹함으로써 매우 효과적으로 네이티브 코드로 컴파일 될 수 있게 합니다. 이를 통해서 로드 시간과 메모리 오버헤드와 배포 사이즈를 획기적으로 개선시킬 수 있습니다.

데이터 압축

앞서서 메모리 이슈를 언급했 던 것 처럼, 배포 사이즈도 Unity WebGL에서 중요한 이슈입니다. 배포 사이즈는 다운로스 시간과 메모리 사용량에 영향을 미칩니다. 사용할만한 다운로드 속도가 나오려면 데이터를 압축한 상태로 전송해주어야 합니다. 현재로써는 http 프로토콜이 지원하는 gzip 압축에 의존하고 있습니다. 하지만, 이는 종종 서버 사이드의 작업이 필요로하기때문에 불편함이 따릅니다. 게다가, gzip은 현대의 압축 알고리즘에 비해 효율성이 떨어집니다.

미래에는(스케쥴상으로는 Unity 5.3), Unity 자체적으로 에셋 데이터 파일 압축을 모든 플랫폼에서 지원할 것입니다. http 압축에 의존해있던 것을 제거하고 자체적인 압축을 코드상으로 구현할 것입니다. 이로써 WebGL 콘텐츠를 더 빨리 받아볼 수 있게되고, 데이터가 메모리상에 압축된 상태로 머무르는 것이 가능해집니다. 이로 인해서 에셋 로딩 속도도 빨라지고 메모리 대역폭도 줄어들게 됩니다.

성능(Performance)

작년에 작성 한 WebGl 벤치마크 포스팅에서 브라우저와 네이티브 런타임의 성능 비교를 하였습니다. 어떤 영역에서는 괜챦은 성능을 보였었고, 어떤 영역에서는 훨씬 큰 성능 차이를 보여주었습니다. 우리는 이러한 성능 차이를 줄이고자합니다. 큰 성능 차이는 SIMD 및 멀티-스레딩(multi-threading)을 활용함으로써 줄일 수 있습니다. 애석하게도 현재 시점의 WebGL에서는 이들을 사용하는 것이 불가능하지만 다음과 같이 개선 될 예정입니다.

- SIMD : SIMD.js를 통해서 자바스크립트에서 SIMD를 지원할 수 있습니다. 모질라, 구글, 마이크로소프트 모두 이를 지원할 계획을 가지고 있습니다. 현재 다른 플랫폼들이 SIMD를 이용해서 퍼포먼스를 향상시키듯이 WebGL도 SIMD를 활용하면 퍼포먼스가 향상될 것입니다.

- 공유 배열 버퍼(Shared Array Buffers) : 공유 배열 버퍼(Shared Array Buffers)는 WebWorker(자바스크립트에서의 멀티스레드와 같은 역할)가 메모리를 공유할 수 있게 합니다. 이로 인해 기존 멀티스레드 코드를 자바스크립트로 컴파일하는 것이 가능해집니다. 모질라에서는 이미 Unity WebGL 콘텐츠를 멀티스레딩으로 돌리는 것에 성공하였고, 구글 역시 공유 배열 버퍼를 지원할 계획이라고 발표하였습니다.

모바일 지원

모바일에서 WebGL을 지원할 것이냐는 질문도 많이 받고 있습니다. 현재 우리는 모바일에서 구동하는데 방해가 되는 작업을 따로 하고 있지는 않지만, 모바일 최적화를 위한 작업도 따로 하고 있지는 않습니다. 때문에, 고성능의 최신 안드로이드 기기에서는 잘 돌아가겠지만 대부분의 보급형 기기에서는 그렇지가 않을 것입니다. 앞서 언급한 성능 향상 작업들이 모바일에서도 효과를 발휘한다고는 기대하지 않고 있습니다. 때문에, 모바일 지원에 대한 일정에 대해서는 말씀 드릴 것이 없는 상황입니다.

빌드 시간

또 다른 이슈로는 WebGL 빌드가 오래 걸린 다는 것이 있습니다. 모질라는 현재 엠스크립튼(Emscripten) 컴파일러 툴체인을 네이티브 코드로 옮기는 작업을 진행중입니다. 이를 통해서 빌드 시간이 상당히 개선될 것으로 기대하고 있습니다. 이미 Unity 5.1에서는 자바스크립트 최적화가 네이티브로 옮겨진 버젼의 엠스크립튼(Emscripten)이 탑재되서어 5.0에 비해 빌드 속도가 개선되었습니다.

오디오

다른 플랫폼들은 오디오 시스템을 FMOD를 이용하는 반면, 현재의 Unity WebGL은 Web Audio를 기반으로 자체적인 오디오 시스템을 구현하였습니다. 때문에, 현재로써는 기본적인 플레이백(playback)이나 볼륨 및 피치(pitch) 조절 등이 지원 될 뿐 그 이상의 고급 기능은 지원되지 않습니다. 이러한 상황은 Unity WebGL의 스레드 지원이 가능하기 전 까지는 변치 않을 것입니다. 스레드가 지원되면 FMOD 라이브러리를 WebGL로 컴파일 할 수 있게되고 원하는 모습에 가까워 질 수 있습니다. 하지만, Web Audio(“Audio Workers”)의 스펙인 오디오 데이터 워커 API 또한 필요합니다. 하지만 이 기능이 구현 된 브러우저는 아직 존재하지 않습니다. 따라서, 완전한 오디오 기능이 지원되려면 오랜 시간이 걸릴 것으로 예상합니다.

그래픽

WebGL은 OpenGL ES 2.0에 기반을 두고 있는 자바스크립트 API입니다. OpenGL ES 2.0은 많은 제약 사항이 있기 때문에 다른 플랫폼에 비해 제한된 그래픽 기능을 가지고 있음을 의미합니다. 또한, 유니티는 현재 어떤 그래픽 API에서 어떤 그래픽 기능을 사용하는 지에 대해 결정하는 부분이 하드코딩으로 되어있습니다. 이 과정 중에서 OpenGL ES 2.0은 모바일에서 돌아간다고 가정하고 있습니다. 하지만 WebGL은 고성능 데스크톱 GPU에서 구동될 수가 있으므로 이러한 가정은 더 이상 유효하지가 않습니다. 이로 인해 원래 가능한 것 보다는 시각적인 퀄리티가 떨어지는 결과를 초래합니다. 특히 스탠다드 쉐이더와 그림자등이 대표적인 예가 될 것입니다. 우리는 이러한 하드코딩을 걷어내고 쉐이더 품질 등을 프로젝트 별 설정할 수 있는 기능을 만들고 있습니다.

또한, GDC 2015에서 우리는 WebGL 2.0(OpenGL ES 3.0 기반)에서 돌아가는 Unity5의 프로토타입을 시연한 바 있습니다. 이는 WebGL의 그래픽 성능을 한 단계 끌어올린 것입니다. Unity 5.2에서는 WebGL 2.0 지원이 실험적으로 적용될 것입니다. 다만, 브라우저들이 실제적으로 이 API를 올해 안에는 릴리즈 버전에 포함하지는 않을 것으로 생각합니다.

브라우저 지원

현재로써는, Unity WebGL은 크롬, 파이어폭스, 사파리를 지원합니다. 주요 브라우저 중 마이크로소프트의 브라우저는 제외 된 상태입니다. 인터넷 익스플로러의 현재 버젼이 WebGL을 지원하긴 하지만 Web Audio에 대한 지원이 빠져있습니다. 또한, 성능도 썩 좋지 않다보니 우리의 공식 지원 대상에서 제외되었습니다.

마이크로소트의 새로운 브라우저인 Edge에서는 이러한 점이 개선됩니다. Edge는 IE를 대체하여 Windows10에 기본 브라우저로 탑재됩니다. Edge에서는 Web Audio가 탑재되고 asm.js가 지원되어서 높은 성능으로 Unity 콘텐츠를 구동시킬 수 있습니다.

비디오

Unity의 MovieTexture 클래스는 현재 WebGL에서 지원되지 않습니다. MovieTexture는 현재 WebGL의 오디오 솔루션에서 오디오 플레이백이 불가능한 관계로 현재로써는 이에 대한 계획이 없는 상태입니다. 게다가, 브라우저의 html5 비디오 기능을 이용하면 완벽한 비디오 텍스쳐 솔루션을 Unity WebGL에서 손쉽게 이용 가능합니다.

네트워킹

현재 System.IO.Sockets.*과 UnityEngine.Network.*는 WebGL에서 동작하지 않으며 앞으로도 마찬가지 일 것입니다. 이는 플랫폼에서 보안상의 문제로 IP 소켓에 직접 접근하는것이 불가능하기 때문입니다. 대신, WWW는 이용 가능합니다. 또한, 자바스크립트를 이용하여 Web Socket이나 WebRTC를 통합하는 방법도 있습니다. 아니면, Unity 5.1부터 내장되어있는 멀티플레이어 기능을 활용할 수도 있고, 포톤(Photon)이나 스마트폭스서버(SmartFoxServer)같은 서드 파티 라이브러리를 활용하는 방법도 있습니다. 이들 모두 WebGL에서 WebSocket을 이용합니다.

쓰레드

앞서 성능 섹션에서도 언급하였듯이, 브라우저가 공유배열버퍼(Shared Array Buffer)기능을 지원하게되면 우리는 내부 엔진 코드에 멀티 스레딩을 적용할 예정입니다. 또한, 최종적으로는 사용자 System.Threading.*등을 이용하여 사용자 코드에서 멀티스레딩을 활용할 수 있도록 하는 것이 우리의 목표입니다. 하지만, 공유배열버퍼(Shared Array Buffer)는 GC가 필요한 일부 기능들을 제공하지 않는 등 꽤 까다로운 문제들이 있습니다. 우리는 이 문제를 풀기위한 고민을 계속 하고 있으며 언젠가는 기능이 구현 될 것입니다. 다만, 엔진 내부에 멀티스레딩이 적용 된 이후에나 될 것입니다.