asm.js와의 작별: 웹 어셈블리 시대의 마지막 다리가 걷히다

asm.js가 뭐였길래, 왜 지금 작별 인사를 할까

Firefox를 만드는 모질라의 SpiderMonkey 팀이 자바스크립트 엔진에서 asm.js 전용 최적화 경로를 걷어낸다고 발표했어요. 이름이 낯선 분들도 있을 텐데, asm.js는 2013년쯤에 등장한 "자바스크립트의 아주 좁은 부분집합"이에요. 정수와 부동소수점 같은 타입을 명시적으로 표시하고, 객체나 동적 기능을 거의 안 쓰는 형태로 작성된 자바스크립트인 거죠.

이게 왜 중요했냐면, 당시 웹에서 C/C++ 같은 네이티브 코드를 돌릴 방법이 마땅치 않았어요. 게임이나 무거운 시뮬레이션을 브라우저에 올리고 싶어도, 자바스크립트의 동적 특성 때문에 항상 한 단계 느렸거든요. 그래서 Emscripten이라는 도구가 등장해서 C/C++ 코드를 asm.js 스타일의 자바스크립트로 변환해 줬어요. 엔진은 이 코드를 보고 "아, 이건 정수 연산만 하는구나"라고 알아챈 다음, 일반 자바스크립트보다 훨씬 빠른 기계어로 컴파일했죠. 한때는 네이티브 대비 1.5배 정도까지 따라갈 정도로 빨랐어요.

그런데 2017년에 WebAssembly(줄여서 Wasm)가 정식으로 등장하면서 상황이 완전히 바뀌었어요. Wasm은 처음부터 "브라우저에서 빠르게 돌리는 저수준 바이트코드"로 설계됐고, 텍스트로 된 자바스크립트보다 파싱도 빠르고 검증도 빠르고, 무엇보다 진짜 네이티브에 가까운 성능을 냅니다. 그래서 asm.js의 자리는 자연스럽게 Wasm으로 넘어갔고, 약 10년이 흐른 지금 모질라는 "이제 asm.js를 특별히 빠르게 만들어주던 코드를 엔진에서 빼겠다"고 결정한 거예요.

그래서 정확히 뭐가 사라지는 걸까

오해하면 안 되는 게, asm.js 코드가 동작을 멈추는 건 아니에요. asm.js는 결국 평범한 자바스크립트의 부분집합이라서, SpiderMonkey의 일반 JIT 컴파일러(IonMonkey)가 그대로 실행해 줍니다. 다만 예전에는 "use asm";라는 지시문을 만나면 엔진이 "오, 이건 특별 취급해야지" 하면서 AOT(Ahead-Of-Time) 컴파일 경로로 가서, 처음 함수가 호출되기도 전에 미리 기계어로 만들어 놓는 별도 파이프라인이 있었어요. 이 별도 파이프라인이 이제 제거되는 거예요.

모질라가 든 이유는 명확해요. 첫째, 유지보수 비용이에요. asm.js 전용 코드 경로는 일반 JIT와 다르게 동작하기 때문에, 자바스크립트 엔진에 새로운 기능을 추가할 때마다 "이게 asm.js 경로에서도 잘 돌아가는지" 따로 검증해야 했어요. 둘째, 실제 트래픽이 거의 없다는 점이에요. Emscripten은 이미 한참 전에 기본 출력을 Wasm으로 바꿨고, 새로 컴파일되는 코드는 거의 다 Wasm이에요. 셋째, 보안 표면이에요. 별도의 코드 생성 경로는 그 자체로 잠재적인 취약점이 될 수 있거든요. 적게 쓰이는 길일수록 버그가 오래 숨어 있을 가능성이 크고요.

실측 데이터도 흥미로워요. 모질라가 자체 분석한 바로는, 일반 JIT로 돌려도 asm.js 전용 경로 대비 성능 손실이 크지 않다고 해요. 일부 벤치마크는 오히려 더 빨라지기도 한답니다. 그 사이 IonMonkey가 워낙 똑똑해져서, asm.js 패턴 정도는 굳이 특별 취급하지 않아도 잘 최적화해주는 수준이 된 거죠.

웹 어셈블리 시대를 다시 정리해보면

이번 발표는 "기술 하나의 단종" 이상의 의미를 가져요. 웹에서 고성능 코드를 돌리는 방법이 자바스크립트 트릭에서 진짜 바이트코드로 완전히 넘어갔다는 상징이거든요. asm.js는 사실상 "우리도 빠른 코드를 돌리고 싶다"는 욕구를 표준화 이전에 임시로 해결한 다리였고, 그 다리가 이제 안전하게 걷힐 만큼 반대편 땅이 단단해졌다는 신호예요.

Wasm 생태계는 그 사이 정말 많이 자랐어요. 브라우저 안에서 Figma, AutoCAD Web, Photoshop Web 같은 묵직한 애플리케이션이 돌고, Unity와 Unreal로 만든 게임이 웹에서 구동되죠. 브라우저 바깥에서도 Wasmtime, Wasmer, WasmEdge 같은 런타임이 서버사이드와 엣지에서 자리잡고 있고요. Cloudflare Workers, Fastly의 Compute@Edge, Fermyon Spin 같은 엣지 컴퓨팅 플랫폼은 "콜드 스타트가 거의 0인 함수"의 기반을 Wasm으로 잡고 있어요. 컨테이너가 수백 밀리초씩 걸리는 구간에서 Wasm은 1ms 이하로도 시작 가능하니까요.

표준 측면에서도 WASI(WebAssembly System Interface)가 진화하면서 파일 시스템, 네트워크, 소켓 같은 시스템 자원에 접근하는 표준이 자리를 잡아가고 있어요. Component Model이라는 사양은 서로 다른 언어로 짠 Wasm 모듈들이 마치 라이브러리처럼 안전하게 조합되게 해주는 그림을 그리고 있고요. 단순히 "브라우저용 빠른 코드"가 아니라 "멀티언어 보안 샌드박스 런타임"으로 격이 올라가고 있는 셈이에요.

한국 개발자에게 주는 시사점

프런트엔드 개발자라면 사실 이 변화로 코드를 고칠 일은 거의 없을 거예요. 우리가 쓰는 React, Vue, Svelte 코드는 asm.js와 전혀 상관이 없으니까요. 다만 사내에 오래된 Emscripten 결과물이나, 옛날에 만든 WebGL 게임 같은 게 있다면 한 번쯤 빌드 파이프라인을 점검해볼 만해요. Emscripten 최신 버전으로 다시 빌드해서 Wasm 출력으로 바꾸면 더 빠르고 작은 결과물이 나옵니다.

더 큰 그림에서 보면, Wasm은 더 이상 "알아두면 좋은 것"이 아니라 "진지하게 한 번은 만져봐야 할 것"이 됐어요. 백엔드 쪽에서 멀티테넌트 환경, 플러그인 시스템, 사용자 코드 실행 같은 요구가 있다면 Wasm 런타임이 강력한 대안이에요. AI/ML 쪽에서도 모델 추론을 브라우저나 엣지로 내리는 흐름이 강해지면서 Wasm + WebGPU 조합이 점점 주목받고 있고요. Rust, Go(TinyGo), C#(Blazor) 모두 Wasm 출력을 잘 지원하니까, 자신이 쓰는 언어에서 Wasm 한 줄 짜보는 데 큰 비용이 들지 않아요.

마무리

asm.js의 퇴장은 슬픈 이별이라기보다 세대교체가 잘 끝났다는 증명에 가까워요. 한 시대를 풍미했던 임시방편이, 더 잘 설계된 표준에게 자리를 양보하고 명예롭게 물러나는 모습이거든요. 웹의 성능 한계를 자바스크립트의 좁은 부분집합으로 비집고 들어가서 풀어보려 했던 그 노력이 결국 Wasm이라는 더 큰 길을 닦은 셈이에요.

여러분은 최근에 Wasm을 실무에서 써보신 적이 있나요? 브라우저 안에서든, 엣지나 서버에서든, 어떤 시나리오에 도입해봤고 어떤 점이 좋고 아쉬웠는지 댓글에서 이야기 나눠봐요.