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