WebAssembly가 JavaScript를 죽일까? 직접 확인해보자 (+ 라이브 데모) 🚀

Source: Dev.to

TL;DR 🧠

WASM vs. JS 벤치마크와 GitHub 레포가 포함된 작은 라이브 데모입니다.

• JavaScript만으로도 이미 매우 빠르며 대부분의 작업에 충분합니다.
• 무거운 연산에 대해서는 WASM이 큰 이점을 가지고 있습니다. SIMD 같은 고급 최적화 없이도 말이죠.

⚠️ 입력값을 검증하지 않았으니 주의하세요 – 브라우저 탭이 쉽게 멈출 수 있습니다.

Demo:
Repo:

WebAssembly 코드를 어떻게 작성하나요? 🤔

기본

WASM으로 컴파일되는 코드는 보통 저수준 언어로 작성됩니다:

• Rust
• Go
• C / C++

왜 Python이나 순수 JavaScript가 안 될까?

WebAssembly는 네이티브 CPU 머신 코드가 아닙니다.
브라우저가 나중에 JIT‑컴파일을 통해 머신 코드로 변환하는 휴대용 바이트코드 포맷이며, JavaScript와 매우 유사한 방식으로 동작합니다.

Python이나 JS가 문제가 되는 이유는 “무거운 컴파일러”가 아니라:

• 동적 타이핑
• 큰 런타임
• 가비지 컬렉션
• 예측 불가능한 메모리 모델

WASM은 단순하고 예측 가능한 실행 및 메모리 모델을 중심으로 설계되어 Rust나 C++ 같은 언어에 더 잘 맞습니다. (WASM GC도 존재하고 발전 중이지만 아직 프로덕션에서는 주류가 아닙니다.)

내가 Rust 🦀를 사용한 이유

데모에서는 Rust를 사용했는데, 이는 거의 없는 런타임과 메모리를 명시적으로 제어할 수 있기 때문입니다.

• Windows에서도 설정이 어렵지 않으며(Visual Studio 툴체인 설치만 하면 됨)
• Rust는 흔히 *“스테로이드가 붙은 TypeScript”*라고 불리며, 타입에 매우 엄격하고 any가 없습니다.
• 소유권과 빌림 같은 개념이 많은 버그를 방지해 줍니다.

더 깊이 파고들고 싶다면 dev.to에 Rust 관련 좋은 글이 많이 있습니다.

WASM으로 컴파일하기

컴파일 과정은 간단하며 CI/CD 파이프라인에 쉽게 통합할 수 있습니다.
레포지토리에는 컴파일된 파일이 포함돼 있어 실제 WASM 출력물을 확인하고 JavaScript에서 어떻게 사용하는지 볼 수 있습니다.

언제 WASM을 쓰고 언제 JavaScript가 더 좋을까? ⚔️

데모에서 직접 확인해 보세요. 벤치마크 코드는 GitHub에 공개돼 있어 부정 행위가 없음을 검증할 수 있습니다.

Reminder: 입력값은 사용자 책임입니다 – 브라우저 탭이 쉽게 멈출 수 있습니다.

JavaScript는 정말 빠릅니다 🏎️

WASM도 엄청나게 빠르지만, 브라우저 엔진 개발자들도 잠을 자지 않습니다. V8이나 SpiderMonkey 같은 엔진의 JIT 컴파일은 매우 효율적입니다.

일반적인 프론트엔드 앱(간단한 CRUD, 많은 DOM 상호작용)을 만든다면, 순수 JavaScript가 전체적으로 더 빠를 수 있습니다. 꽤 무겁지만 직관적인 연산이라면 말이죠.

예시: 행렬 곱셈

n × n 행렬 곱셈(결과는 하나의 숫자, mod 1 000 000 007) 은 JS로도 충분히 처리 가능하며, 종종 WASM보다 빠르게 보입니다.

그 이유는 JS ↔ WASM 경계 횡단 비용 때문입니다. 경계를 자주 넘고 데이터를 많이 복사할수록 성능 이득이 사라집니다.

JS가 한계에 부딪히는 순간 💥

아주 무거운 연산에서는 상황이 바뀝니다.

예시: 팩토리얼 모듈러

n! mod 1 000 000 007 은 JavaScript가 WASM보다 훨씬 느립니다. 절대 시간은 이 작은 예시에서는 여전히 짧지만, 다음과 같은 경우를 생각해 보세요:

• 물리 시뮬레이션
• 수치 해석기
• 대규모 통계 모델

JavaScript는 IEEE‑754 double‑precision 숫자를 사용합니다. 값이 매우 커지면 BigInt 로 전환해야 하는데, 이는 느립니다. 반면 Rust는 u64 를 네이티브로 사용해 엄청난 성능 차이를 보입니다.

결과는 다음 요인에 따라 달라집니다:

• 브라우저
• JS 엔진
• 하드웨어

내 환경에서는 Firefox가 Chrome보다 격차가 작았습니다.

이미지 처리에서는 어떨까? 🖼️

WASM은 이미지, 비디오, 오디오 처리에 자주 언급되며 실제로도 놀라운 성능을 보여줄 수 있습니다.

하지만 아주 간단한 벤치마크(이미지에 Gaussian blur 적용)에서는 JS가 WASM을 완전히 압도했습니다. 이유는 전체 Uint8Array 를 WASM 메모리로 복사해야 했기 때문입니다.

WASM이 승리하기 시작한 것은 전체 이미지‑처리 파이프라인을 구축했을 때였습니다:

• 여러 필터를 연속으로 적용
• 가능한 한 많은 작업을 WASM 내부에서 수행

교훈: “WASM은 이미지에 좋다”는 연산이 충분히 무거울 때만 성립합니다. (공유 메모리를 사용하면 오버헤드를 줄일 수 있지만 복잡도가 늘어납니다.)

수백만 픽셀을 처리하는 Gaussian blur조차도 JS가 놀라울 정도로 잘 수행합니다.

보너스: WASM만이 전부는 아니다 🧰

다른 웹 기술도 상황에 따라 훌륭한 대안이 될 수 있습니다:

• Web Workers – 무거운 작업을 백그라운드 스레드로 오프로드
• OffscreenCanvas – 메인 스레드가 아닌 곳에서 그래픽 렌더링
• GPU 솔루션 (WebGPU) – 병렬 작업을 위해 GPU 활용

어떤 도구를 선택할지는 해결하려는 문제에 따라 달라집니다.