WebAssembly를 통해 Google 어스에 대한 브라우저 간 액세스 개선
이상적인 환경에서는 개발자가 빌드하는 모든 애플리케이션을 기술과 관계없이 브라우저에서 사용할 수 있을 것입니다. 하지만 프로젝트에 구축한 기술과 다양한 브라우저 공급업체에서 해당 기술을 얼마나 잘 지원하는지에 따라 프로젝트를 웹으로 구현하는 데에는 장애물이 있습니다. WebAssembly (Wasm)는 W3C에서 표준화된 컴파일 타겟으로, 웹에서 JavaScript 이외의 언어에서 코드베이스를 실행할 수 있도록 함으로써 이 문제를 해결하는 데 도움을 줍니다.
Google 어스를 통해 이러한 작업을 마쳤습니다. 현재 WebAssembly에서 미리보기 베타로 사용할 수 있습니다. 이 기능은 아직 Google 어스의 베타 버전이며 이전보다 원활하지 않을 수 있습니다 (일반 웹용 어스 사용해 보기). Chrome은 물론 Edge (Canary 버전), Opera 등 기타 Chromium 기반 브라우저와 Firefox에서 이 베타 기능을 실험해 볼 수 있습니다. 플랫폼별 애플리케이션에 더 나은 교차 브라우저 지원을 찾고 있다면 이 베타를 고려해 보시기 바랍니다.
Google 어스에 WebAssembly를 선택한 이유
원래 Google 어스의 대부분은 설치용 데스크톱 애플리케이션이었기 때문에 C++로 작성했습니다. 이후 스마트폰이 널리 사용되면서 Android 및 iOS로 포팅할 수 있었으며 NDK 및 Objective-C++를 사용하여 대부분의 C++ 코드베이스를 유지했습니다. 2017년에는 어스를 웹에 도입할 때 Native Client (NaCl)를 사용하여 C++ 코드를 컴파일하고 Chrome 브라우저에서 실행했습니다.
당시 NaCl은 C++ 코드를 브라우저로 포팅하고 지구에 필요한 수준의 성능을 제공할 수 있는 유일한 브라우저 기술이었습니다. 안타깝게도 NaCl은 Chrome에서만 사용되는 기술로, 여러 브라우저에서 채택되지 않았습니다. 이제 WebAssembly로 전환하기 시작하여 동일한 코드를 여러 브라우저에서 실행할 수 있게 합니다. 즉, 웹 전반에서 더 많은 사용자가 어스를 사용할 수 있게 됩니다.
스레딩의 스레드
WebAssembly는 여전히 표준으로 진화하고 있으며 브라우저는 더 많은 기능을 통해 계속 확장되고 있습니다. 어스 관점에서 브라우저 간 WebAssembly 지원의 가장 큰 차이점은 스레딩 지원입니다. 멀티스레딩을 지원하는 브라우저도 있지만 그렇지 않은 브라우저도 있습니다. 지구를 현실 세계의 거대한 3D 비디오 게임이라고 생각하십시오. 따라서 우리는 지속적으로 데이터를 브라우저에 스트리밍하고, 압축을 풀고 화면에 렌더링할 수 있도록 준비합니다. 백그라운드 스레드에서 이 작업을 수행할 수 있게 됨으로써 브라우저의 어스 성능이 명확하게 개선되었습니다.
멀티스레드 WebAssembly는 스펙터 및 멜트다운 보안 취약점이 발견된 후에 브라우저에서 가져온 SharedArrayBuffer라는 브라우저 기능에 의존합니다. 공격으로 인한 잠재적 피해를 완화하기 위해 Chrome 보안팀은 모든 데스크톱 운영체제의 Chrome에 사이트 격리를 도입했습니다. 사이트 격리는 각 렌더기 프로세스를 단일 사이트의 문서로 제한합니다. 이 보안 기능을 도입한 후 Chrome에서 데스크톱용 SharedArrayBuffer를 다시 사용 설정했으며, 이를 통해 Chrome용 어스와 함께 멀티스레드 WebAssembly를 사용할 수 있게 되었습니다.
다른 브라우저에서 SharedArrayBuffer를 다시 사용 설정하기 위해 사이트 격리 또는 기타 완화 조치를 취하고 있습니다. 그때까지는 어스가 해당 브라우저에서 단일 스레드로 실행됩니다.
WebAssembly가 다양한 브라우저에서 작동하는 방식
어스를 포팅하는 브라우저의 WebAssembly 지원 상태에 관해 많은 내용을 알아봤습니다. WebAssembly를 사용하여 애플리케이션을 개발하려면 WebAssembly가 여러 브라우저에서 작동하는 방식의 현재 상태를 이해하는 것이 중요합니다.
에지
Edge는 EdgeHTML 렌더기에서 Chromium 기반 렌더기로 전환하는 Microsoft의 선택에 따라 두 가지 고유한 개발 환경이 되고 있습니다. 현재 WebAssembly의 Google 어스 베타는 WebGL2를 지원하지 않기 때문에 최신 Edge 공개 버전에서 실행되지 않습니다. 이 문제는 Chromium을 기반으로 하는 새 버전의 Edge가 조만간 출시되면 해결될 예정입니다. Edge의 Canary 버전을 다운로드하여 어스가 정상적으로 작동하는지 확인해 보시기 바랍니다.
Chrome
Chrome은 데스크톱의 멀티 스레딩을 포함하여 WebAssembly를 강력하게 지원하므로 어스가 더 원활하게 실행됩니다. 앞으로 Chrome이 WebAssembly에 멀티 스레딩으로 동적 메모리 할당을 추가하게 되기를 기대합니다. 그때까지는 메모리 용량이 제한된 기기 (예: 32비트 시스템)에서 어스가 시작되지 않을 수 있습니다.
Firefox
Firefox는 WebAssembly를 제대로 지원하지만 다중 스레딩은 지원하지 않습니다. 따라서 어스의 작동 속도가 느려질 수 있습니다. Mozilla는 향후 버전에서 멀티스레딩을 다시 지원할 수 있기를 기대합니다. 게다가 Firefox는 동적 메모리 할당을 지원합니다.
오페라
Opera는 Chrome과 마찬가지로 Chromium 및 향후 출시될 Edge 버전을 기반으로 합니다. 하지만 현재 Opera 버전은 WebAssembly의 단일 스레드 지원만 제공합니다. 어스는 Opera에서 실행되지만 다소 성능이 저하됩니다. 최신 버전의 Opera가 멀티 스레딩을 지원하고 WebAssembly를 더욱 강력하게 지원합니다.
Safari
Safari는 WebAssembly의 강력한 구현을 제공하지만 WebGL2를 완벽하게 지원하지는 않습니다. 따라서 WebAssembly가 포함된 어스는 Safari에서 실행되지 않습니다. 특히 일부 셰이더에는 GLSL 1.2가 필요합니다. WebGL2에 대한 지원이 강화되면 Safari에서도 어스를 사용할 수 있게 되기를 바랍니다.
WebAssembly 기능이 더 많이 도입되기를 기대합니다.
지구를 웹에서 사용할 수 있도록 하기까지는 오랜 시간이 걸렸습니다. 약 6년 전, 초기 asm.js 기반 내부 데모로 시작하여 수년에 걸쳐 유지 관리 및 확장했습니다. WebAssembly가 W3C 채택 표준이 되면서 어스의 WebAssembly 빌드로 전환되었습니다.
아직 WebAssembly와 어스를 사용할 방법이 남아 있습니다. 특히 Emscripten (C++ 코드에서 WebAssembly를 생성하는 도구 모음)을 사용하여 LLVM 백엔드로 이전하려고 합니다. 이 변경으로 향후 SIMD 지원이 가능할 뿐만 아니라 소스 언어 코드의 소스 맵과 같은 보다 강력한 디버깅 도구도 사용할 수 있게 됩니다. 그 밖에도 OffscreenCanvas를 채택하고 WebAssembly에서 동적 메모리 할당을 완벽히 지원하기를 기대하고 있습니다. 하지만 우리는 잘하고 있습니다. WebAssembly는 웹용 어스의 장기적인 미래입니다.
잠시 시간을 내어 베타를 사용해 보세요. 어스에 직접 의견을 남겨 사용 방법을 알려주세요.