Rust + WASM 파서를 TypeScript로 다시 짰더니 3배 빨라졌다고?

상식을 뒤집는 벤치마크

"Rust로 작성한 WASM 파서를 TypeScript로 재작성했더니 3배 빨라졌다." 이 문장만 보면 뭔가 잘못된 것 같습니다. Rust는 C/C++에 필적하는 성능을 내는 시스템 프로그래밍 언어이고, TypeScript는 JavaScript에 타입을 얹은 스크립팅 언어입니다. 성능 차이가 수십 배는 날 것 같은데, 오히려 반대 결과가 나왔다니요.

OpenUI 팀이 공개한 이 사례는 "항상 저수준 언어가 빠르다"는 통념에 의문을 던집니다. 물론 Rust 자체가 느린 것이 아닙니다. 핵심은 WASM(WebAssembly)이라는 중간 계층에 있습니다. 이 사례를 제대로 이해하려면 WASM이 브라우저에서 어떻게 동작하는지부터 살펴봐야 합니다.

WASM의 약속과 현실

WebAssembly는 브라우저에서 네이티브에 가까운 성능으로 코드를 실행할 수 있게 해주는 바이너리 포맷입니다. C, C++, Rust 같은 언어로 작성한 코드를 WASM으로 컴파일하면 브라우저에서 실행할 수 있습니다. 이론적으로는 JavaScript보다 훨씬 빠를 수 있죠.

하지만 현실은 이론보다 복잡합니다. WASM 코드가 JavaScript 세계와 데이터를 주고받을 때 오버헤드가 발생합니다. 이를 "브릿지 비용" 또는 "FFI(Foreign Function Interface) 오버헤드"라고 부릅니다. WASM은 자체적인 선형 메모리를 사용하고, JavaScript는 V8 엔진이 관리하는 힙 메모리를 사용합니다. 두 세계 사이에서 데이터를 복사하고 변환하는 과정이 필요한데, 이 과정이 빈번하게 발생하면 성능 병목이 됩니다.

파서(parser)의 경우 이 문제가 특히 심각할 수 있습니다. 파서는 입력 데이터를 읽어서 구조화된 트리(보통 AST, Abstract Syntax Tree)를 만드는 작업인데, 이 과정에서 수많은 작은 객체들을 생성합니다. WASM에서 이 객체들을 만들어 JavaScript로 넘기려면, 각 객체마다 메모리 복사와 변환이 일어나야 합니다. 결과적으로 파싱 자체는 빠르더라도, 결과물을 JavaScript 세계로 가져오는 비용이 파싱 비용을 압도하게 되는 것입니다.

왜 TypeScript가 더 빨랐을까

TypeScript(결국 JavaScript로 트랜스파일되는)로 작성한 파서는 V8 엔진 위에서 직접 실행됩니다. 여기서 중요한 것은 현대 JavaScript 엔진의 성능입니다. V8은 JIT(Just-In-Time) 컴파일러를 탑재하고 있어서, 반복적으로 실행되는 코드를 런타임에 네이티브 머신 코드로 컴파일합니다. 파서처럼 동일한 패턴의 작업을 반복하는 코드는 V8의 JIT 최적화에 특히 유리합니다.

또한 TypeScript 파서는 JavaScript 객체를 직접 생성하기 때문에 브릿지 비용이 전혀 없습니다. AST 노드를 만들 때 메모리 복사나 포맷 변환 없이 V8의 힙에 바로 할당합니다. 이 차이가 3배라는 성능 격차를 만든 핵심 원인입니다.

이것은 컴퓨터 과학에서 잘 알려진 원칙과 맞닿아 있습니다. "가장 빠른 코드는 실행하지 않는 코드"라는 격언처럼, 불필요한 데이터 변환과 복사를 제거하는 것이 알고리즘 수준의 최적화보다 더 큰 성능 향상을 가져올 수 있다는 것입니다.

그렇다면 WASM은 언제 써야 하나

이 결과를 보고 "WASM은 쓸모없다"고 결론 내리면 안 됩니다. WASM이 빛을 발하는 영역은 분명히 있습니다. 이미지/비디오 처리, 암호화 연산, 물리 시뮬레이션처럼 연산 집약적이면서 JavaScript와의 데이터 교환이 적은 작업에서는 WASM이 압도적으로 유리합니다.

반면 파서처럼 JavaScript와 빈번하게 데이터를 주고받아야 하는 작업, 또는 많은 수의 작은 객체를 생성하는 작업에서는 브릿지 비용 때문에 순수 JavaScript가 더 나을 수 있습니다. 핵심은 "어떤 언어가 빠른가"가 아니라 "전체 시스템에서 병목이 어디인가"를 파악하는 것입니다.

SQLite를 WASM으로 포팅한 sql.js 같은 프로젝트도 비슷한 고민을 거쳤습니다. 쿼리 실행 자체는 WASM 내부에서 빠르게 처리되지만, 결과 데이터를 JavaScript로 마샬링하는 비용이 상당합니다. 이 문제를 해결하기 위해 공유 메모리나 제로 카피 방식 같은 최적화 기법들이 연구되고 있습니다.

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

이 사례에서 가장 중요한 교훈은 "벤치마크 없는 최적화는 추측에 불과하다"는 것입니다. "Rust가 빠르니까 Rust로 짜면 빠를 것이다"는 합리적인 추측이지만, 실제 환경에서는 다른 결과가 나올 수 있습니다. 특히 여러 런타임이 상호작용하는 환경에서는요.

프론트엔드 성능 최적화를 고민하고 있다면, WASM 도입 전에 먼저 물어봐야 할 질문은 "순수 연산 비용이 병목인가, 아니면 데이터 교환 비용이 병목인가"입니다. 전자라면 WASM이 도움이 되지만, 후자라면 오히려 성능이 나빠질 수 있습니다.

마무리

"더 빠른 언어를 쓰면 더 빠른 프로그램이 된다"는 단순한 공식은 현실에서 항상 성립하지 않습니다. 시스템의 경계에서 발생하는 비용을 이해하는 것이 진정한 성능 최적화의 출발점입니다. 여러분도 WASM을 프로덕션에서 사용해본 경험이 있으신가요? 기대만큼의 성능이 나왔는지, 아니면 예상 밖의 병목을 만났는지 경험을 공유해주세요.