웹의 미래는 Rust다
Vite 8.0이 바꾼 것
2026년 3월 12일, Vite 8.0이 릴리즈됐다. 변경사항 목록을 보면 가장 눈에 띄는 것은 번들러 교체다.
Vite는 지금까지 두 개의 번들러를 같이 써왔다. 개발 서버에는 esbuild, 프로덕션 빌드에는 Rollup. 속도가 다르고 동작 방식이 다른 두 도구를 같은 프로젝트에서 쓰는 구조였다. 이 이중 구조의 문제는 미묘하다 — 개발 중에는 잘 되는데 빌드하면 동작이 달라지는 경우가 생긴다. 같은 코드를 두 번 다르게 처리하기 때문이다.
Vite 8.0은 이걸 Rolldown 하나로 통일했다. Rolldown은 Rust로 작성된 번들러로, Rollup의 API와 호환된다. 기존 플러그인 생태계를 깨지 않으면서 내부 엔진을 교체한 것이다.
성능 차이는 숫자로 나온다. 19,000개 모듈 기준 40.10초 → 1.61초, 약 25배 빠르다.1 Linear는 Vite 8.0으로 전환 후 빌드 시간이 46초에서 6초로 줄었다고 밝혔다.2
번들러 하나가 Rust로 교체됐다는 것만으로 끝나지 않는다. 프론트엔드 툴링의 핵심 레이어가 시스템 언어로 재작성되고 있다는 신호다. Rolldown만이 아니다 — 린터 Oxc, 타입 유틸리티 Biome, 패키지 매니저 Bun의 번들러. 자바스크립트 생태계의 빌드 인프라가 Rust로 향하고 있다.
브라우저의 한계
툴링은 개발자 경험의 문제다. WASM은 다른 차원의 이야기다.
JavaScript는 브라우저에서 싱글스레드로 실행된다. 가비지 컬렉터가 있고, 메모리에 직접 접근할 수 없다. 이 제약들은 언어 설계의 결과이기도 하지만, 브라우저 보안 모델의 결과이기도 하다. 파일시스템, GPU 직접 접근, 카메라 원시 데이터 — 브라우저 API는 의도적으로 샌드박스 안에 묶여 있다.
이 한계 안에서는 특정 종류의 연산이 불가능하거나 너무 느리다. 영상 인코딩, 이미지 포맷 변환, 물리 시뮬레이션. JavaScript로도 할 수 있지만, 실용적인 속도가 나오지 않는다.
WebAssembly는 이 문제에 대한 브라우저의 답이다. C, C++, Rust 등으로 작성된 코드를 WASM 바이너리로 컴파일하면, 브라우저가 이를 네이티브에 가까운 속도로 실행한다. JavaScript의 제약을 우회하는 게 아니라, 아예 다른 실행 경로를 쓰는 것이다.
WASM이 이미 하고 있는 것들
개념이 아니라 지금 프로덕션에서 쓰이고 있는 사례들이다.
ffmpeg.wasm. C로 작성된 FFmpeg 전체를 Emscripten으로 WASM에 컴파일한 것이다. 브라우저에서 서버 없이 영상 인코딩, 트랜스코딩, 썸네일 추출이 된다.3 서버에 파일을 올리지 않아도 된다.
Google Squoosh. 이미지 변환 도구인데, 내부적으로 OxiPNG(Rust), JPEG-XL(C++), MozJPEG(C) 등을 WASM으로 컴파일해서 쓴다.4 AVIF, WebP2 같은 최신 포맷을 브라우저에서 직접 변환하고, WASM 멀티스레딩으로 1.5~3배 추가 가속이 붙는다.5
Figma. 렌더링 엔진 전체가 C++ WASM이다. 브라우저 앱이지만 렌더링 성능이 네이티브 수준인 이유가 여기 있다.
Clipchamp, CapCut Web. 브라우저에서 대용량 영상 편집이 된다. 서버 처리가 아니라 클라이언트 사이드 WASM이다.
이것들은 "기술적으로는 가능하지만 느려서 못 쓰는" 수준이 아니다. 수백만 명이 매일 쓰는 서비스들이다.
왜 C가 아닌 Rust인가
WASM은 C/C++도 컴파일할 수 있다. Emscripten이 이미 오래전부터 C 코드를 WASM으로 변환해왔다. 그런데 새로 만들어지는 WASM 프로젝트들은 점점 Rust를 선택한다. 이유가 있다.
C의 근본적인 문제는 메모리 버그다. use-after-free, buffer overflow, null pointer dereference — 이런 버그들은 컴파일 타임이 아닌 런타임에 터진다. 데스크탑 앱에서 메모리 오염은 크래시로 끝나지만, 브라우저에서는 보안 취약점이 된다. 샌드박스 탈출, 민감한 데이터 노출로 이어질 수 있다.6
Rust의 소유권 시스템(ownership + borrow checker)은 이런 버그들을 컴파일 타임에 원천 차단한다. 코드가 컴파일됐다면, 메모리 관련 버그가 없다는 보장을 컴파일러가 한다.
런타임 비용도 다르다. Rust는 GC가 없다. 메모리 관리가 컴파일 타임에 결정되기 때문에 런타임 오버헤드가 없고, 바이너리 크기도 작다. WASM에서 이건 중요하다 — 초기 로딩 속도와 메모리 사용량에 직결된다.7
개발 경험도 Rust가 낫다. wasm-bindgen과 wasm-pack은 Rust 코드를 WASM으로 컴파일하고 JavaScript 바인딩까지 자동으로 만들어준다.8 C에서 같은 작업을 하려면 손으로 써야 할 것들을 도구가 처리해준다.
그리고 솔직히 말하면, Rust가 더 힙하다. 아무도 기술 결정 문서에 이 이유를 쓰지 않지만, 개발자 커뮤니티에서 기술 선택이 어떻게 확산되는지 생각해보면 무시할 수 없는 요소다.
WASI: 브라우저 밖으로
WASM의 방향이 브라우저 안에서만 머물지 않는다는 신호들이 있다.
WasmGC는 2024년 말 기준 Chrome 119+, Firefox 120+, Safari 18.2+ 모두에서 지원된다.9 브라우저 간 파편화 없이 쓸 수 있는 기반이 갖춰졌다는 뜻이다.
WASI(WebAssembly System Interface) 는 WASM이 OS 수준 API에 접근하는 표준 인터페이스다. 파일시스템, 네트워크, 클럭 — 브라우저 샌드박스 밖에서 WASM이 실행될 수 있게 해주는 인터페이스다. 같은 WASM 바이너리를 브라우저에서도, 서버에서도, CLI 도구에서도 실행할 수 있다. "한 번 컴파일, 어디서나 실행"이 실제로 가능해지는 구조다.
2025년, Fermyon이 Akamai에 인수됐다.10 Fermyon은 WASM 서버사이드 실행에 집중한 회사다. 세계 최대 CDN이 여기에 베팅했다는 건, 엣지 컴퓨팅의 실행 단위로 WASM이 진지하게 고려되고 있다는 신호다.
마무리
Vite 8.0의 Rolldown 전환은 "빌드가 빨라졌다"는 소식 이상이다. 번들러, 린터, 타입체커 — 프론트엔드 툴링의 핵심들이 Rust로 재작성되는 흐름의 일부다. 동시에 WASM은 브라우저가 뷰어가 아니라 연산 환경이 될 수 있다는 가능성을 이미 현실로 만들고 있다.
나는 이걸 트렌드라기보다 방향으로 본다. 트렌드는 지나가지만, 방향은 다음 단계를 규정한다. Rust와 WASM이 웹 스택의 어느 레이어까지 내려갈지, 5년 뒤에 어떤 모습이 될지 아직 모른다. 다만 지금 움직임들이 같은 방향을 가리키고 있다는 건 분명하다.