최근 수정 시각 : 2025-10-24 16:07:36

WebAssembly

웹어셈블리
WebAssembly
파일:WebAssembly 로고.svg
<colbgcolor=#fff,#1c1d1f><colcolor=#654FF0> 특징 명령형, 구조적, 정적 타이핑
최초 공개 2017년 3월
설계 W3C
개발 W3C, Intel, Red Hat, Fastly,
Mozilla, Microsoft, Google, Apple
라이선스 Apache License 2.0
파일 확장자 .wat (텍스트 포맷)
.wasm (바이너리 포맷)
파일:홈페이지 아이콘.svg

1. 개요2. 목적과 성능
2.1. 웹 밖의 분야에서
3. 현황 및 전망
3.1. WASM과 자바스크립트
4. 엔진 및 런타임5. 사용하는 소프트웨어

1. 개요


웹어셈블리(WebAssembly)는 웹 브라우저에서 실행하는 바이트코드 언어이다. 웹 플랫폼에서 스크립트 언어인 JavaScript에 취약한 연산 집중적인 작업을 가능케 하기 위해 2015년부터 개발되었다. 2019년부터는 웹 외의 다양한 플랫폼에서 활용하는 연구가 진행중이다.

WASM은 어디까지나 웹 브라우저라는 가상머신에서 실행하기 위한 바이트코드이지, WASM 자체는 실제 플랫폼에서 실행할 수 있는 프로그래밍 언어가 아니다. 그렇기에 WASM 코드를 생성하기 위해서는 우선 다른 언어로 코드를 작성한 후 컴파일을 수행해야 한다.

2. 목적과 성능

웹어셈블리는 물리엔진이나 3D 그래픽 등의 헤비한 연산을 요하는 분야를 웹 상에서 실행할 수 있다는 것에 존재 의의가 있다. 기존 자바스크립트는 근본적으로 스크립트 언어에서 시작했기 때문에 동적 타입, 저수준 메모리 접근 불가 등 연산 집중적 작업에 적절하지 않다. 반면 웹어셈블리는 포인터 접근과 메모리 조작은 물론이고, 무려 멀티스레딩# 및 SIMD#를 지원한다.[1]

다만 그렇다고 해서 성능이 절대적으로 JS보다 빠른 것은 아니다. JS 엔진들에는 JIT 컴파일링 등 수준 높은 최적화 기법이 다수 적용되었으며, 이때문에 같은 코드라도 웹어셈블리의 속도가 뒤떨어지는 결과가 빈번히 나온다. # 그러나 웹어셈블리는 JS와 달리 저수준 최적화의 여지가 있기에, 이를 활용한 성능 향상은 전적으로 개발자의 구현에 달려있다. 만약 본인의 프로젝트가 진정으로 연산 집중적인 작업을 다루는게 아니라면, 굳이 WASM을 적용하려 하다가 돈·시간을 낭비할 필요는 없다.

웹어셈블리에 타기팅이 가능한 언어 목록
대부분의 주류 언어는 웹어셈블리 컴파일러가 존재한다. 인기 좀 있다 싶은 언어들은 다 되는 수준. 때문에 서로 다른 언어 코드베이스도 웹어셈블리로 컴파일하면 모두 웹에서 쓸 수 있다. 이 덕분에 C, C++ 처럼 코드베이스가 탄탄한 분야의 경우 굳이 JS로 재구현하지 말고 컴파일하여 바로 사용할 수 있다는 것 또한 장점이다.

웹어셈블리를 광고할때 네이티브 코드에 비해 약 10% 정도 느리다고 하지만 실제로는 이보다는 훨씬 느리다. 2019년 USENIX에 발표된 벤치마크에서 네이티브 대비 1.5 ~ 2.5배 낮은 속도가 보고되었다. 2년 후인 2021년에 이루어진 한 개인적인 테스트에서도 100% 낮은 속도(2배 느림)를 보였고 2023년에 실시된 또 다른 비교에서도 최대 130% 속도 저하(2.32배 느림)를 보인 것을 보면 '네이티브 대비 10% 속도 저하'는 아무리 좋게 봐줘도 일부 애플리케이션에 한정된 뻥카이며 앞으로 개선될 전망은 적어도 당분간은 보이지 않는다. 물론, 아래 기술된 대로 자바스크립트에 비하면 확실한 장점들도 있고 속도 향상 측면에서도 근본적인 문제는 코드 최적화이기 때문에 희망의 끈은 놓을 필요는 없을 것이다.

2.1. 웹 밖의 분야에서

2008년에 WASM+WASI가 있었다면 Docker를 만들 필요가 없었을 것입니다. 그만큼 중요합니다. 서버의 웹어셈블리는 컴퓨팅의 미래입니다.
Docker 설립자 Solomon Hykes[2]
웹어셈블리가 대부분의 언어로부터 컴파일 가능한 바이트코드란 점, 그리고 보다 견고한 샌드박스 보안 구조를 갖고 있는 점에서 WASM 모듈을 기준으로 소프트웨어 배포를 이루는 것이 가능하다.

서로 다른 언어 코드베이스를 WASM으로 컴파일하여 사용하는 방법 또한 연구되고 있다.

또한 도메인 특화 언어 및 데이터 스키마의 경우, 어떤 기능을 제공하기 위해 새로운 형식을 만들어야 하는 불편 대신, WASM을 사용하여 사용자가 원하는 언어로 구현이 가능하도록 하는 방안이 연구된다. 일례로 Redpanda의 사용자 지정 데이터 변환은 WASM을 통해 정의할 수 있다. #

3. 현황 및 전망

웹어셈블리 커뮤니티는 기존 기계어 시장과 달리 상대적으로 신흥 연구자들의 참여가 활발한 편이다. WASM을 웹 관련 기업과 협회가 주도하고 있고 배우는 사람들도 웹 기술을 통해 처음 접하는 경우가 많기 때문이다. 현재 WASM 해석기(인터프리터)를 사용할 수 있는 CPU 아키텍처는 X86, ARM, MIPS, RISC-V 등이 있다. 운영체제는 POSIX 기반 시스템(리눅스, BSD 등) 및 윈도우즈가 호환된다.

대한민국에서도 웹어셈블리 연구개발 활동이 이뤄지고 있다. 어셈넥스트(AsmNEXT) 연구팀(캐츠워즈리서치 고남현 연구원 외 1인)이 2022년도 바이트코드 연합(Bytecode Alliance)에 정식 회원으로 참가하여, 웹어셈블리 런타임 개선에 기여하고 국내에서 웹어셈블리 컨퍼런스를 개최하였다.[3]

2022년 기준 바이트코드 연합 참여 목록은 다음과 같다.

[ 펼치기 · 접기 ]
* 모질라


대한민국에 소재한 대학인 KAIST에서도 웹어셈블리 연구 성과가 나왔다. 카이스트 전산학부 류석영 교수 연구팀(카이스트 류석영 교수 외 2인)이 웹어셈블리 연구 성과를 인정받아 2025년 10월 구글 V8 연구지원금(Google V8 Research Grant)에 선정되었다.

3.1. WASM과 자바스크립트

이런저런 이유로 웹어셈블리가 한국에서도 활성화되고 성숙하고 나면 기존의 자바스크립트에게는 사실상의 시한부 인생 카운트다운이 내려질 것이라고 점치는 사람들도 적지 않다. 왜냐하면 자바스크립트는 호불호가 극단적으로 갈리는 동시에 아무래도 싫어하는 사람들이 좀 많기 때문이다. 자바스크립트가 항상 인기도 면에서 1위인 이유는 웹용 언어이고 웹에서 수십년 간 대체재가 전혀 없는, 말하자면 공인된 독점 시장이었기 때문인데, 그렇기 때문에 애착을 가진 사람들도 많은 반면 설계상 깔끔하지도 않은 누더기 언어를 강제당하는 개발자들의 원한도 엄청나다. 자바스크립트 옹호론자들은 npm의 패키지 누적량이 세계 최고이며 자바스크립트의 우월성을 증명하는 것이라고 하지만... 반대로 구석구석마다 서드 파티 라이브러리를 쓰지 않고서는 답이 안나오는 덜떨어진 언어를 직업상 써야 하니까 직접 확장하는 경우가 많을 수밖에 없다는 반론도 만만치 않다.

즉, 지금도 자바스크립트 사용을 피하기 위해 타입스크립트나 커피스크립트 등을 써가며 자바스크립트를 컴파일 타깃 취급하는 경향이 많은데 컴파일 타깃마저 웹어셈블리로 옮겨가고 나면 누가 수백 가지 함정을 감수해 가며 자바스크립트를 쓰겠냐는 것이 논지이다.

일단 웹어셈블리 개발 기획상으로는 자바스크립트를 대체하는 것이 아니라 서로 보완하는 관계가 될 것이라고는 하지만[4] 정말로 자바스크립트의 역할이 단지 각종 웹어셈블리의 글루코드 역할만 하게 된다면 그건 사실상 죽는 것이나 다름없긴 하다.(그마저도 여타 유사 자바스크립트 언어 등에서 트랜스파일 해버린다면?)

물론, 실제로 자바스크립트가 사장되는 일은 쉽게 일어나지는 않을 것이고, 일어나더라도 시간이 좀 걸릴 것이다. 한 가지 이유는 이미 자바스크립트로 작성된 웹사이트는 유지보수를 해야 되기 때문이고, 주니어 웹 개발자를 찍어내는 가장 빠른 방법이 자바스크립트를 가르치는 것이기 때문이다. 또 하나의 이유는 같은 기능을 구현했을 때 웹어셈블리 배포 파일의 크기가 자바스크립트 보다 꽤 크다는 점이다. 배포 파일 로딩 시간 보다 실행 성능이 중요한 기능 구현에는 웹어셈블리가 유리하겠지만 (예: 게임, 사진 편집, 동영상 편집, 온라인 IDE), 로딩 시간이 더 중요한 컨텐츠 위주 웹사이트들의 프론트엔드에는 웹어셈블리가 불리하다. (예: 뉴스, 쇼핑, SNS) 상기한 특징을 보면 과거 리치 인터넷 애플리케이션이 활발하게 쓰였을 당시에도 자바스크립트가 자신의 지분을 가지고 있었던 것을 생각해볼 수 있다. 그리고 자바스크립트 언어의 한계를 보완한 유사 자바스크립트 언어 중 현재 가장 대표적인 타입스크립트는 자바스크립트에 타입 문법을 추가한 것이라서, 먼저 자바스크립트를 공부해야 한다.

==# 코드 비교 #==
  • C 소스 코드
    {{{#!syntax cpp
#include <stdio.h>

int factorial(int n) {
if (n == 0)
return 1;
else
return n * factorial(n-1);
}
}}}
  • WebAssembly IR
    {{{get_local 0
i64.eqz
if (result i64)
i64.const 1
else
get_local 0
get_local 0
i64.const 1
i64.sub
call 0
i64.mul
end
}}}
  • WebAssembly 바이너리
    {{{20 00
50
04 7E
42 01
05
20 00
20 00
42 01
7D
10 00
7E
0B
}}}

4. 엔진 및 런타임

5. 사용하는 소프트웨어

[1] JS에서 멀티스레딩을 구현하는 방법으로 Web Worker가 있긴 하다. 그러나 이는 스레드 직접 조작의 패러다임과는 다른 방식이다.[2] 웹어셈블리에 주목하라[3] 한국 어셈넥스트 팀, ‘바이트코드 얼라이언스’ 합류 (보안뉴스, 2022-04-08)[4] 아직까지 웹어셈블리는 직접 웹사이트를 조작하는 것이 아니라 자바스크립트에서 모듈처럼 불러와서 그 기능만을 사용하게 되어 있다.

분류