웹은 어떻게 소프트웨어를 먹어치울 수 있는가WebGPU, WebAssembly 및 게임의 가능성 — JON RADOFF
안녕하세요. 빌리버 루크입니다. 웹이 공간웹으로 발전하고 그 기술 발전은 향후 게임엔진과 같은 웹 세상을 만들 수 있다고 믿는 입장에서 동일한 주장의 기술 포스팅을 발견 하여 번역 공유합니다.
JON RADOFF는 2000명 이상의 구독자를 가진 테크 리더 이며, 1987년 아타리 때부터 게임 개발을 진행했던 분으로 왕좌의 게임, 스타트렉 타임라인, 워킹 데드등의 유명 모바일 게임을 개발하신 분입니다. 현재는 Disruptor Beam Inc의 대표 이사로 게임, 인공지능, 그래픽스, 가상세계와 메타버스를 테마로 한 기업가로 WebGPU와 Wasm같은 기술이 웹기술이 인공지능을 포함한 모든 그래픽스와 메타버스를 먹어치울 수 있는 가능성에 대해 이야기 합니다. 예전에 제가 ChatGPT와 했던 대담도 참고해보시면 도움이 되실 것 같습니다.
웹 르네상스, 2부: 웹은 어떻게 소프트웨어를 먹어치울 수 있는가WebGPU, WebAssembly 및 게임의 가능성
이 글은 웹과 인터넷의 변화를 다룬 3개의 시리즈 글 중 두 번째로, 현재 일어나고 있는 웹의 혁신에 관한 글입니다. 이 글은 제 게임 경험을 통해 얻은 인사이트를 통해 작성되었습니다. 처음 이 글을 읽는 분들께 먼저 감사를 드립니다. 제 포스팅은 게임, 게임 기술, 가상 세계, 인공 지능, 공간 컴퓨팅 및 메타버스와의 교차점을 다룹니다.
웹 브라우저는 모든 소프트웨어에 액세스하는 범용적인 포털이 되고자 노력해 왔지만, 아직까지는 성공하지 못했습니다.
이유는 성능 저하와 열악한 패키징입니다. 이 글에서는 이를 혁신하는 새 기술에 대해 설명합니다:
- WebGPU
- 웹어셈블리
- 프로그레시브 웹 애플리케이션(PWAs)
게임은 웹이 고성능 소프트웨어를 제공하는 데 있어 다른 플랫폼보다 훨씬 뒤처져 있다는 것을 보여주는 좋은 예입니다. 또한 게임이 사용하는 기술은 앞으로 출시될 수많은 공간 컴퓨팅, 과학적 시각화, 시뮬레이션 및 메타버스 제품의 선구자이기도 합니다.
긴글에 앞서: WebGPU, WebAssembly, PWA의 개선으로 웹 브라우저에서 훨씬 더 뛰어난 성능과 애플리케이션을 게임과 같은 소프트웨어를 제공할 수 있게 되었습니다. 상세한 이해를 원하시면 이 글을 계속 읽고, 이러한 변화가 비즈니스에 미치는 영향에 더 집중하고 싶다면 3부(곧 제공 예정)로 넘어가세요.
모바일 소프트웨어의 배포
모바일 장치는 웹 사이트 트래픽의 거의 60%를 차지합니다. 따라서 웹을 통한 소프트웨어 제공할때 우리는 대부분 모바일 기기를 이용합니다. 모바일 사용자와 개발자들이 웹 소프트웨어의 혜택을 가장 많이 받는데, 이는 모바일 앱 스토어가 배포를 통제하고 수수료와 제한을 통해 혁신을 방해한다는 단순한 이유 때문입니다.
WebGPU
웹 혁신의 가장 중요한 촉매 기술 중 하나는 모든 주요 웹 브라우저에서 지원하는 새로운 그래픽 API인 WebGPU입니다. WebGPU는 웹에서 그래픽 성능을 크게 향상시킵니다. 이는 웹 소프트웨어가 그래픽 하드웨어에 직접적으로 액세스할 수 있기 때문입니다.
그래픽스 API의 간략한 역사
WebGPU의 역사에 대해 이해하려면 기존의 그래픽 API의 역사를 빠르게 살펴보는 것이 좋습니다.
1980년대로 거슬러 올라가보면, 그래픽 컴퓨터 워크스테이션의 선구자인 실리콘 그래픽스에서 만든 PHIGS와 IRIS GL 같은 그래픽 API가 있었습니다. 1992년 이는 OpenGL로 변경되었고, 다른 컴퓨터 아키텍쳐에서도 범용 적으로 사용되기 시작합니다.
당시에는 GPU란게 없었습니다. 컴퓨터는 몇가지 기능이 정적으로 정의된 그래픽을 위한 코프로세서를 이용했습니다. 동적인 작업을 하고 싶으면 프로그래밍을 위해 CPU를 통해 비효율적인 방식으로 메모리간의 데이터 전환이 필요했습니다.
1999년 NVIDIA가 “세계 최초 GPU” GeForce 256을 출시했을 때, 사용자 코드를 병렬로 동작시킬 수 있는 전용칩을 구동할수 있는 프로그래밍 가능한 셰이더가 새로운 혁신으로 등장했습니다. 자체 그래픽 함수와 병렬 처리가 가능하여 그래픽 성능은 빠르게 향상 되었습니다. 이는 새로운 아키텍처 패러다임의 등장이었습니다. 고정 함수의 코프로세서 시대에 설계된 OpenGL은 수정되었고, 빠르게 새로운 시대를 열었습니다.
프로그래밍 가능한 셰이더가 등장하면서 새 하드웨어에 성능 최적를 위한 다양한 그래픽 API가 개발되었습니다. GPU의 등장이후 변화한 아키텍쳐에 맞춰 하위 레벨의 엑세스가 가능한 API를 구성함으로서 새로운 API들은 OpenGL보다 훨씬 뛰어난 성능을 보여주었습니다. DirectX11은 2009년, MS에서 출시했고, 쉽게 작업이 가능하였으며 구형 하드웨어에 직접적으로 액세스가 가능하여 게임 제작에 여전히 인기 있는 API입니다. MS는 하드웨어에 더 직접적으로 억세스 가능하고 뛰어난 성능의 버전(DirectX12)를 출시했습니다. 마찬가지로 애플도 Mac, iOS 및 Vision OS 기기에 최적화된 애플만의 에코시스템을 위해 MetalAPI를 만들었습니다.
Vulkan은 훨씬 더 낮은 오버헤드로 하드웨어에 직접 액세스 할 수 있는 API로 2016년 OpneGL의 단점을 보완하기 위해 출시 되었습니다. 크로스 플랫폼(하나의 코드로 대부분의 하드웨어에서 실행 가능)이면서 하드웨어 전용 API와 유사한 성능을 제공합니다. Vulkan은 그래픽이 중요한 Android기기(메타퀘스트 포함)가 고성능을 제공할 수 있는 방법으로 윈도우즈와 애플 기기 모두 비슷한 성능을 제공합니다.
웹은 수년 동안 WebGL을 고집해 왔습니다. 이는 OpenGL의 제한된 하위 집합을 기반으로 하는 오래된 API입니다. OpenGL의 낡은 아키텍처와 많은 성능 문제가 있습니다. 또한 OpenGL보다 더 제한적이며, OpenGL에서 사용할 수 있는 셰이더 프로그래밍 언어(GLSL)를 사용할 수 있지만, 다양한 보안 및 크로스 플랫폼 문제로 인해 사용이 매우 제한되어 있습니다. 특히 ML/AI 애플리케이션에 필요한 컴퓨팅 셰이더는 WebGL로 만들 수 없습니다.
Nanite and Lumen(나나이트와 루멘)
최근 그래픽 API으로는 언리얼5의 나나이트와 루멘을 한번 살펴보겠습니다.
나나이트를 사용하면 개발자가 지오메트리에 제한이 없는 오브젝트를 생성할 수 있으며, 씬에 배치된 오브젝트를 자동으로 최적으로 렌더링하여 개발자의 수고로운 최적화 및 폴리곤 축소 작업을 덜어줍니다.
루멘은 실시간으로 씬에 적절한 조명을 비출 수 있는 글로벌 조명 시스템입니다. 최종 사용자 입장에서는 광원이 씬을 이동함에 따라 변화하는 씬을 훨씬 더 역동적으로 경험 할 수 있습니다. 무엇보다도 개발자에게는 환경을 개발 흐름을 방해하는 소모적인 사전 작업 시간에 해당되는 ‘Baking’작업을 하지 않아도 됩니다.
나나이트와 루멘은 DirectX 12와 Vulkan에서 작동하지만, 이전 미들 레벨 수준의 API는 지원하지 않습니다. 이는 개발자가 GPU에 직접 액세스할 수 있을 때 가능한 혁신을 보여주는 좋은 예시입니다. 루멘은 WebGL은 물론이고 OpenGL이나 이전 버전의 DirectX에서도 구현할 수 없었습니다.
WebGL에서 WebGPU로
WebGL은 웹 기반의 과학적인 시각화, 특히 지리 공간 웹 솔루션 등장에 많은 기여를 했지만, 큰 성능 차이로 인해 웹에서 게임의 폭발적인 성장을 일으키지는 못했습니다.
하지만, WebGPU는 WebGL을 크게 개선했습니다. 점진적으로 개선된 것이 아니라, OpenGL대신 최신 하드웨어와 Vulkan과 같은 API의 영향을 더 많이 받았습니다.
WebGPU는 최신 그래픽 하드웨어 아키텍처를 위해 구축된 크로스 플랫폼 그래픽 API입니다. 오버헤드가 낮고 성능이 뛰어납니다. 실행 중인 웹 페이지에 대한 데이터 액세스를 제한하고 명령을 GPU로 전송하기 전에 유효성을 검사하는 등 웹 소프트웨어에서 직접 사용할 수 있는 보안 기능도 포함되어 있습니다.
그 결과 그래픽 애플리케이션에서 WebGPU 성능은 Vulkan과 같은 최신 그래픽 API의 성능에 근접합니다. 다음은 WebGL에서 WebGPU로 전환했을 때 8fps에서 60fps로 성능이 향상되는 데모입니다.
WebGPU는 프로그래머가 하드웨어에 더 직접적으로 억세스 하면서, 보안과 크로스플랫폼까지도 고려되어 있습니다. 또한 WebGL과 달리 WebGPU는 프로그래밍 가능한 셰이더(WebGPU 셰이딩 언어 또는 WGSL)를 지원합니다. 이를 통해 3D 엔진, 수정가능한 그래픽 집약적인 애플리케이션 개발 및 연산에 다양한 고급 기능을 사용할 수 있으며, 이는 GeForce 256이 프로그래머블을 도입하기 전과 현재의 GPU 간에 일어난 게임 성능 향상과 비교할 수 있습니다. 그래픽 API가 하드웨어에 직접 액세스할 수 있게 되면서 루멘이 언리얼 엔진 5에 실시간 레이트레이싱을 추가한 것처럼, 웹 GPU도 마찬가지로 웹에서 고성능 그래픽 시스템의 완전히 새로운 영역을 열것으로 기대합니다.
WebGPU를 지원하는 3D 저작도구(엔진)
3D저작도구(엔진)은 앞서 설명한 다양한 그래픽 API를 위한 추상화 계층을 제공하고, 그래픽 집약적인 애플리케이션을 구성하는 데 필요한 대부분의 작업을 많은 코딩 없이 수행할 수 있는 워크플로우를 제공하며, 제품을 더 빠르게 조립할 수 있는 상호 운용 가능한 에셋 스토어(플러그인 코드 및 그래픽 개체) 에코시스템을 제공하는 등 몇 가지 중요한 작업을 수행합니다.
유니티는 WebGPU 지원을 발표했으며, 현재 버전에서는 나나이트와 루멘을 지원하지 않지만 이미 이를 지원하는 Unreal 5 빌드도 있습니다(현재 버전에서는 지원하지 않음). Babylon.js와 같은 웹 네이티브 3D 엔진도 지원을 발표했으며, 많은 웹 개발자가 사용하는 인기 있는 Three.js 그래픽 라이브러리를 위한 WebGPU 백엔드도 있습니다. 몰입형 웹을 개발하는 스타트업인 원더 인터랙티브(Wonder Interactive)는 언리얼 5에 웹GPU를 도입했습니다:
셰이더 계산 (Compute Shaders)
앞서 언급했듯이 셰이더 프로그래밍은 렌더링에만 국한되지 않습니다. 컴퓨팅 셰이더는 소프트웨어가 GPU 하드웨어에서 실행되지만 반드시 그래픽에 관한 것이 아닌 병렬 처리 애플리케이션에도 사용할 수 있습니다. 이것이 바로 GPU가 머신 러닝과 인공 지능에 사용되게 된 이유입니다.
최신 버전의 OpenGL에서 컴퓨팅 셰이더에 대한 지원이 추가되었지만, 이상하고 효율성이 떨어지는 프로그래밍 구조였기 때문에 WebGL에 적용되지 못했습니다. DirectX, Vulkan, Metal은 모두 컴퓨트 셰이더를 허용하며, 웹 GPU에 영향을 준 벌칸처럼 컴퓨트 셰이더를 활용하는 소프트웨어도 만들 수 있습니다.
따라서 향후 웹의 애플리케이션은 클라우드 기반 추론에 의존하지 않고 디바이스에서 ML/AI 작업을 수행할 수 있게 될 것입니다.
예전 포스팅 “웹 르네상스 1부: 위대한 리번들링” 에서 언급했듯이 LLM은 점점 더 사용자에게 가까이 다가가고 있습니다. Arc Search는 LLM을 사용하여 더 빠른 지식 도출 시간을 제공하지만, 여전히 클라우드 기반의 생성형 AI입니다. 오픈 소스 AI 모델에 대한 개발 속도가 매우 빠르므로 다음 단계는 브라우저 내에서 모델을 제공하여 사용자의 컴퓨터가 더 많은 작업을 수행할 수 있게 될겁니다. (이는 곧 개인화된 데이터를 안전한 방식으로 통합하는 더 많은 에이전트 기능을 개방해야 함을 의미합니다).
WebAssembly (웹어셈블리)
웹어셈블리(Wasm)-(와즘)는 자바스크립트와 같이 해석된 언어가 아닌 바이트코드를 웹 브라우저로 전송하는 기술입니다. WebAssembly는 CPU 중심 작업을 거의 네이티브 속도에 가깝게 수행할 수 있습니다. WebAssembly용으로 작성된 프로그램은 모든 언어를 사용할 수 있습니다: 크로스 컴파일러를 작성한다는 가정 하에 C, C++, C#, Rust 등 모든 언어를 사용할 수 있습니다. 모바일 브라우저를 포함한 대부분의 브라우저에서 몇 년 동안 사용되어 왔습니다.
원칙적으로 Wasm은 WebGPU가 GPU에서 수행하는 작업을 CPU에서 수행합니다. 즉, 크고 복잡한 프로그램도 함께 제공할 수 있습니다. 3D 엔진이 그래픽 집약적인 웹용 게임을 타겟으로 하려면 WebGPU가 중요하지만, 엔진은 WebAssembly도 지원해야 합니다. 다행히 유니티는 크로스 컴파일러인 엠스크립템을 통해 Wasm을 지원하며, 커뮤니티 내에서 언리얼 엔진용 Wasm 개발이 진행되고 있습니다.
프로그레시브 웹 애플리케이션(Progressive Web Applications)
네이티브 수준의 기능에 액세스하고, 백그라운드에서 실행 가능하며, 사용자에게 알림을 보낼 수 있고, 오프라인에서도 이용 가능한 ‘앱’처럼 작동하는 웹을 꿈꾸는 것이 프로그레시브 웹 애플리케이션(PWA)기술입니다. 웹 페이지를 익숙한 소프트웨어처럼 작동하는 웹 애플리케이션으로 재패키징 할 수 있습니다.
위에서 이야기했듯이 웹 소프트웨어는 주로 모바일을 의미합니다. 아래 제 아이폰에서 프로그레시브 웹 앱으로 실행되는 FRVR 게임의 예시입니다.
PWA로 구현하면 여러 가지 장점이 있습니다. 가장 큰 장점 중 하나는 이러한 애플리케이션이 자체 아이콘이 있는 독립형 홈 화면 애플리케이션으로 존재하며 애플리케이션 간에 전환할 때 웹 브라우저와 독립적으로 표시된다는 점입니다.
PWA는 또한 로컬 저장소, 푸시 알림, 백그라운드 실행을 지원합니다. 또한 자체 웹사이트 내에서 운영되기 때문에 광고, Stripe 또는 다른 카드 프로세서를 사용한 구매, Web3 등 원하는 방식으로 애플리케이션에서 자유롭게 수익을 창출할 수 있으며, Google이나 Apple에 비용을 지불하지 않아도 됩니다.
역사적으로 애플은 안드로이드에 비해 PWA의 모든 기능을 수용하는 데 있어 상당히 느렸습니다. 예를 들어, iOS에서는 최근에야 푸시 알림이 지원되었습니다. 또한 Android는 ‘클릭하여 설치’ 사용자 인터페이스 프롬프트를 지원하는 반면, iOS Safari는 이를 허용하지 않습니다.
또 다른 큰 차이점은 안드로이드에서는 원하는 웹 브라우저를 설치할 수 있다는 것입니다. 하지만 iOS에서는 Chrome이나 Firefox를 설치했을 수도 있지만 실제로는 Safari를 활성화하는 WebKit용 래퍼를 사용하고 있는 것입니다. 최근 유럽에서는 디지털 시장법에 따라 Apple이 WebKit 이외의 브라우저를 허용해야 한다는 법이 생겼습니다. 그래서 iOS 17.4부터 이를 준수하기 시작했지만, 대신 PWA를 금지했습니다.
상황이 바뀌어 유럽인들이 다시 PWA를 사용할 수 있기를 바랍니다. 그리고 애플이 이 금지 조치를 전 세계로 확대하지 않기를 바랍니다. PWA는 비전OS에서도 허용되지 않습니다. 이 또한 바뀔 수 있기를 바랍니다. 언리얼 엔진의 개발사 에픽게임즈의 CEO인 팀 스위니와 같은 일부 사람들은 그 이유에 대해 아래와 같이 추측하고 있습니다:
다음은 모바일 플랫폼의 PWA 지원 현황에 대한 요약입니다 :
공간 웹 앱(Spatial Web Apps)
WebXR 표준을 사용하면 웹 페이지에서 2D 화면 또는 가상 현실 장치를 사용하여 경험할 수 있는 몰입형 3D 애플리케이션을 표시할 수 있습니다. WebXR은 비전OS에서 지원됩니다(다소 아쉬운 점은 계속 멈추는 현상이 발생한다는 것입니다). 메타 퀘스트 및 Chromium 브라우저가 포함된 기타 XR기기에서 더 잘 작동합니다.
이미 WebXR-WebGPU 결합을 위한 작업이 진행 중이므로 WebXR의 성능과 경험은 크게 향상될 것입니다. 그러나 공간 컴퓨팅에는 렌더링 외에도 이미지 인식, 제스처 인식, 깊이 인식 등 많은 공간 애플리케이션이 카메라가 무엇을 보는지에 따라 달라집니다. 이를 처리하기 위한 인공지능 모델은 디바이스의 하드웨어의 성능을 필요로 하므로 WebGPU가 도움이 될 수 있지만, 이러한 모델은 크고 복잡한 소프트웨어다보니 네이티브 환경만큼은 원활하하지 않을 수도 있습니다. 하지만, 시간이 지나면 그 가능성을 더 확실히 알 수 있을 것이고 혁신을 위한 수많은 선택지 중에 하나가 될 수 있습니다.
게임 로딩 시간 최적화
하지만 웹에는 새로운 문제가 있습니다. : 게임의 용량이 커졌습니다. 가장 큰 게임 중 하나낭인 ARK: Survival Evolved는 저장 용량이 250GB에 달합니다. 2023년 올해의 게임인 발더스 게이트 3는 150GB입니다. 대부분의 게임 개발자는 기기에 대용량 파일 세트를 제공하는 데 익숙합니다. 하지만 웹에서는 사람들이 게임을 빠르게 시작할 수 있게 하는 것이 중요합니다. 1초라도 기다리게 되면 유저는 주의가 산만해져 다른 게임으로 이동할 수 있지만, 구매한 AAA급 게임의 경우 모든 콘텐츠를 미리 다운로드하고 업데이트를 기다릴 의향이 있습니다.
유니티는 어드레서블이라는 기술로 이 문제를 해결하려고 시도했지만, 안타깝게도 확장성이 좋지 않아 대형 게임개발 자들은 자체적인 대안 기술을 만들었습니다. 많은 모바일 개발자가 작은 바이너리를 배포하고 나중에 콘텐츠를 다운로드하는 방식을 이용합니다. 일부는 게임을 계속 플레이하면서 백그라운드에서 콘텐츠를 스트리밍하는 방법도 사용합니다. 이러한 기술은 웹의 고유 기술이라기보다는 진정한 웹용 게임을 제작하는 데 필요한 기술이며, 이러한 방식으로 게임을 쉽게 제작하려면 3D 엔진과 콘텐츠 관리 기술이 개선되어야 합니다.
웹 르네상스
WebGPU, WebAssembly, PWA, WebXR 등 이 모든 기술은 이전에는 운영 체제의 영역의 기술을 웹 브라우저가 성능과 안전성을 갖춘채 제공할 수 있게 해줍니다. 이는 개발자가 웹의 많은 이점을 유지하면서 더 많은 사람에게 도달할 수 있는 애플리케이션을 자유롭게 구축 가능하게 합니다.
이 시리즈의 1부를 읽지 않으셨다면 웹 르네상스 1부: 위대한 리번들링에서는 AI와 대규모 언어 모델이 웹 브라우저를 사용하고 콘텐츠를 검색하는 전체 방식을 어떻게 혁신하고 있는지에 대해 설명한 내용도 읽어보세요.
3부에서는 리번들링과 제가 다룬 기술 변화로 인해 마케팅, 결제 시스템 및 소프트웨어 배포 비즈니스가 어떻게 변화할 것인지에 대해 다룰 예정입니다. 곧 게시될 예정이니 게시되면 구독해 주세요:
추가 주석
1. 프로그래머블 셰이더의 역사, 셰이더의 기능 및 작동 방식에 대해 자세히 알아보고 싶다면 컴퓨팅 셰이더 소개를 참고하세요.
2. DX12가 더 뛰어난가? 의 논란
게임의 모든 분야가 그렇듯, 이 부분은 논쟁의 여지가 있습니다. 버그나 번역 레이어 문제로 인해 DX 11이 실제로 DX 12보다 성능이 더 뛰어난 경우도 있지만, 이는 대개 버그 때문입니다. “Witcher 3의 Steam 데크에서 DX12를 사용해야 하는가, 아니면 DX11을 사용해야 하는가”(Steam 데크는 실제로 Linux 장치이므로 Proton을 사용하는 Windows 호환성의 특수한 경우)와 같은 내용을 검색하면 이에 대한 많은 댓글을 볼 수 있습니다. 하지만 일반적으로 말하자면, Proton과 같은 과도한 변환 레이어 없이 DX12를 제대로 사용할 때 성능이 더 뛰어난 경우가 많습니다.
3. Vulkan은 멀티플랫폼에서 유사한 성능을 지원할 수 있다. 의 논란
다시 한 번 말씀드리지만, 실제 결과는 여러 가지 이유로 인해 달라질 수 있습니다. 다음은 발더스 게이트 3의 성능을 Vulkan과 DirectX 11(DX 12를 지원하지 않음)에서 비교한 예시입니다. 구형 중간 수준의 DX 11이 벌칸을 다소 능가하는 경우도 있습니다. 하지만 일반적으로 최신 하드웨어에서는 벌칸이 더 우수합니다.
4. WebGL만으로 충분한 성능을 제공할 수 있다. 의 논란
즉, 그래픽 렌더링 요구 사항이 다소 제한적이고 고객의 하드웨어가 충분하다면 WebGL로 게임이 잘 작동하도록 만들 수 있습니다. 저희는 스타트렉 타임라인을 개발할 때 WebGL을 사용하여 웹에서 실행했고, 좋은 하드웨어에서 충분히 성능을 발휘할 수 있었습니다. WebGL의 가장 주목할 만한 사용자는 아마도 이전 버전에서 다음과 같은 기능을 구현할 수 있었던 Google 지도일 것입니다.
웹으로 3D메타버스를 구현한다면, XRCLOUD를 찾아주세요.
