OdinMonkey의 황혼: asm.js와 작별하기
10년 넘게 웹 브라우저에 네이티브 수준의 성능을 가져오려는 노력은 웹 개발의 '성배'와 같았습니다. 2013년, Mozilla는 JavaScript의 엄격하고 정적으로 타입이 지정된 하위 집합을 활용하여 C 및 C++ 코드가 네이티브에 가까운 속도로 실행될 수 있도록 하는 영리한 솔루션인 asm.js를 도입했습니다.
최근 Mozilla는 Firefox 148부터 SpiderMonkey의 asm.js 최적화가 기본적으로 비활성화되며, 향후 릴리스에서 코드를 완전히 제거할 계획이라고 발표했습니다. 이는 한 시대의 종말을 의미하지만, 웹 플랫폼의 성숙도를 반영하는 전환이기도 합니다.
asm.js의 유산
asm.js는 Google의 Native Client (NaCl) 및 PNaCl에 대한 대응으로 탄생했습니다. Mozilla의 목표는 별도의 샌드박스, IPC 또는 대체 API를 요구하지 않고 네이티브 속도를 달성하는 것이었습니다. 엔진이 즉석에서 인식하고 네이티브 코드로 직접 컴파일할 수 있는 JavaScript의 하위 집합을 생성함으로써, Mozilla는 웹이 개방성을 유지하고 호환성을 확보할 수 있도록 했습니다.
그 영향은 즉각적이고 심오했습니다. Unity와 Unreal Engine 같은 프로젝트들이 처음으로 C/C++ 코드베이스를 웹으로 배포할 수 있게 되었습니다. 가장 주목할 만한 초기 성공 사례 중 하나는 Epic Citadel 데모였으며, 이는 단 4일 만에 웹으로 포팅되어 브라우저가 고성능 게임 엔진을 처리할 수 있음을 증명했습니다.
즉각적인 성능 향상 외에도, asm.js는 **WebAssembly (Wasm)**로 가는 개념적 가교 역할을 했습니다. 바이너리 형태의 형식이 브라우저에서 효율적으로 실행될 수 있음을 증명함으로써, Firefox 52에서 출시된 Wasm 표준의 토대를 마련했습니다.
왜 지금 전환이 일어나는가
asm.js 최적화 비활성화 결정은 유지보수와 보안이라는 두 가지 주요 요인에 의해 추진됩니다.
- Maintenance Overhead: 유지보수 오버헤드가 큽니다. 현대적인 WebAssembly 파이프라인과 함께 asm.js를 위한 별도의 최적화 경로를 유지하는 것은 엔지니어링 시간 측면에서 비용이 많이 듭니다.
- Attack Surface: 공격 표면이 넓어집니다. 가상 머신(VM) 내의 추가적인 최적화 경로는 보안 취약점에 대한 잠재적인 공격 표면을 증가시킵니다.
Mozilla는 asm.js가 일반 JavaScript의 하위 집합이므로 기존 사이트가 깨지지는 않을 것이라고 언급했습니다. 코드는 단순히 일반적인 Just-In-Time (JIT) 컴파일러를 통해 실행될 것입니다. 하지만 OdinMonkey라고 알려진 컴파일러에 의해 처리되는 특화된 asm.js 경로의 성능 이점은 사라질 것입니다.
커뮤니티의 관점: Wasm의 트레이드오프
업계가 대체로 WebAssembly로 이주했을지라도, 이번 발표는 개발자들 사이에서 향수와 기술적 논쟁을 불러일으켰습니다. 많은 이들이 웹이 급격한 속도로 진화하던 2010년대 초반의 설렘을 기억합니다.
하지만 일부 개발자들은 WebAssembly를 이전 기술인 asm.js와 비교했을 때의 한계에 대해 우려를 제기했습니다.
- API Access: 일부 사용자들은 asm.js가 shim이나 복잡한 데이터 이동 없이 Web API를 직접 호출할 수 있었기 때문에 더 유연했다고 주장합니다.
- Data Handling: 데이터 처리 방식에 대한 논쟁은 반복적으로 제기됩니다. 한 댓글 작성자는 다음과 같이 언급했습니다.
"js에서 wasm으로 zero copy buffer를 보낼 수 없습니다. 모든 것은 트레이드오프입니다. 격리(isolation)는 좋은 것이지만, 동시에 나쁜 것이기도 합니다."
- Integration: 별도의
.wasm파일을 로드해야 하는 Wasm과 달리, asm.js는 "just JavaScript"였기에 일부 개발자들에게는 로딩 프로세스가 더 간단했습니다.
이러한 비판에도 불구하고, Wasm의 바이너리 형식이 훨씬 더 작은 바이너리 크기와 더 빠른 실행 시간을 이점으로 하여, 대중적인 현대적 애플리케이션의 대 대부분의 경우에 더 우수한 선택임을 보여주는 합의가 이루어졌습니다. 예를 들어, 전문적인 디자인 도구인 Figma가 원래 asm.js를 사용하여 브라우저에서 실행될 수 있음을 증명했으나, 결국 로딩 시간을 개선하고 JavaScript AST 파싱 오버헤드를 피하기 위해 Wasm으로 전환했습니다. \n## OdinMonkey에서 BaldrMonkey로
북유럽 신화에 대한 시적적 인용을 담아, Mozilla는 이 전환을 "Ragnarök"로 묘사했습니다. 특화된 asm.js 컴파일러인 OdinMonkey는 BaldrMonkey (Wasm 최적화 컴파일러)와 RabaldrMonkey (Wasm 베이스라인 컴파일러)를 위해 길을 터주기 위해 운명적인 종말을 맞이하게 됩니다.
여전히 레거시 asm.js 콘텐츠를 유지보수하고 있는 분들에게 권장 사항은 명확합니다: WebAssembly로 재컴파일하십시오. 현대적인 Wasm 파이프라인은 asm.js 경로가 가졌던 것보다 훨씬 더 발전되어 있으며, 점점 더 복잡해지는 웹 생태계에서 더 나은 성능과 더 작은 크기를 제공하는 길을 제시합니다.