최근 수정 시각 : 2026-06-17 20:50:42

WebAssembly

WASM에서 넘어옴

{{{#!wiki style="margin:-10px"<tablebordercolor=#808080><tablebgcolor=#808080> 파일:WWW 아이콘.svg월드 와이드 웹
관련 문서 		}}}
{{{#!wiki style="word-break: keep-all; margin: 0 -10px -5px;"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="letter-spacing: -1px; margin:-6px -1px -11px; word-break: keep-all"		<colbgcolor=#808080><colcolor=#fff> HTTP 버전(HTTP/1.1 · HTTP/2 · HTTP/3) · HTTPS · 응답 코드 · 헤더 · HSTS
표현 레이어 HTML · URL(쿼리 문자열) · wai-aria
클라이언트 HTTP 클라이언트 · 웹 브라우저(브라우저 전쟁 · 렌더링 엔진 · WebDriver · 브라우저 개발자 도구)
표준화 웹 표준 · W3C · WHATWG
기술 웹소켓 · WebGL · 웹 컴포넌트 · 프로그레시브 웹 앱 · WebAssembly · CORS · WebRTC
기타 오픈 그래프 프로토콜 · MDN
}}}}}}}}} ||
웹어셈블리
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. 대한민국에서 현황3.2. 바이트코드 얼라이언스3.3. WASM과 JavaScript
4. 엔진 및 런타임5. 사용하는 소프트웨어

1. 개요


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

WASM은 프로그래밍 언어가 아니다. WASM은 실행 가능한 바이트코드 바이너리이며, 만들기 위해서는 일반적으로 WASM 타겟팅을 지원하는 다른 언어의 코드를 작성한 후 컴파일해야 한다. 하지만 직접 작성하고 싶은 경우 WAT(WebAssembly Text format)를 작성해 WABT로 컴파일 하는 방법도 있다.

2. 목적과 성능

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

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

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

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

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 등) 및 윈도우즈가 호환된다.

3.1. 대한민국에서 현황

대한민국에서도 웹어셈블리 연구개발 활동이 이뤄지고 있다.

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

카이스트에서도 웹어셈블리 연구 성과가 나왔다. 카이스트 전산학부 류석영 교수 연구팀(류석영, 윤동준, 신원호 #)이 웹어셈블리 연구 성과를 인정받아 2025년 10월 구글 V8 연구지원금(Google V8 Research Grant)에 선정되었다.

이 외에도, 2017년 삼성전자 (김현덕, 정진우 #), 2020년 NSHC (이준영, 이영준, 서주영, 함은지 #) 등이 웹어셈블리 연구 성과를 발표한 바 있다.

다만, 국내에서도 웹어셈블리를 이용해 임베디드, 웹, 그 외 분야에서 다양한 연구 성과를 내고 있음에도 불구하고, 여전히 저수준 명령어라는 인식 때문에 특수 분야에서나 사용되는 것으로 여겨져 관련 논의가 제한적인 현실이 한계로 지목된다.

3.2. 바이트코드 얼라이언스

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

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

3.3. WASM과 JavaScript

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

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

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

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

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

분류