개요

웹 어셈블리, 줄여서 와즘은 웹에서 실행할 수 있는 어셈블리어를 말한다.
여기에서 말하는 웹이란 구체적으로 웹 브라우저를 기동하는 환경, V8(Node.js 가동 엔진)과 같은 것을 말한다.
어셈블리어라고 하나 당연히 이걸 우리가 직접 작성하는 건 아니고, 다양한 언어를 웹 어셈블리에 맞게 컴파일할 수 있도록 지원하고 있다.

브라우저 환경에서 돌아가라고 만든 건데 막상 보니 활용성이 좋아서 컨테이너를 대체할 수 있는 기술이라고도 평가받는다.^[1]
처음 만들어질 때야 웹을 기본으로 했지만..
현재는 WASI(WebAssembly System Interface, 와시)와 같이 아예 OS의 각종 기능과 자원을 받을 수 있도록 하는 인터페이스도 개발되고 있다.^[2]
그래서 그냥 어떤 한정된 공간에서 언어를 실행시키는 중간 계층 정도로 여겨지기도 한다.
어? 이렇게 보니까 컨테이너랑 다를 게 뭐임?
심지어 더 제한성이 강해서 좋아보인다! 뭐 이런 느낌으로 점차 받아들여지는 듯하다..

배경

웹 브라우저 환경에서는 고전적인 표준이 이어지고 있다.
전체 구조와 형식을 규정하는 HTML, 이걸 이쁘게 꾸미는 CSS, 이를 움직이게 만드는 JS.
이때 JS는 느리다는 약점이 있음에도 불구하고 표준으로 잡혔기 때문에 여태 이를 대체할 수 있는 무언가가 없었다.
그래서 느슨해진 웹 생태계에 긴장감을 부여하며, JS의 기능을 확장하고자 나온 것이 와즘이다.
다른 언어를 브라우저에서 실행할 수 있는 런타임과 컴파일러가 생겼으니.. 굳이 자쓰를 쓸 이유가?
라곤 하지만, 언어를 바꾸는 건 당연히 쉬운 일이 아니다.

원리

음. 공식문서에서도 딱히 전체 원리를 설명하는 글은 잘 안 보인다.
다만 어셈블리어 바로 불릴 만한 이유가 있는 게 독립적인 ISA를 따로 정의했다고 한다.
이 ISA는 V8과 같은 환경에서 각 실제 CPU의 명령어로 변환된다.

특징

와즘의 장점은 다음과 같이 정리할 수 있다.

• 이식성 - 계속 런타임 이야기를 하니 느껴지겠지만 실상 JVM을 가진 자바 같은 놈인 거다.
• 범용성 - 근데 그러면서 여러 언어를 지원한다.
• 네이티브 - 해당 언어를 기본 리눅스 환경에서 돌리는 속도와 최대한 비슷한 속도(를 내려고 노력한다.)
  • 평균 1.5배 느리고, 어느 경우엔 오히려 빠르기도 하다.
  • 기본과 비교해선 느린데, 아무튼 자쓰에 비교하면 어마무시한 속도!
• 스타트업 - OS 프로세스를 하나 띄우는 게 아니라 매우 빠르게 실행된다.
• 보안 - 런타임 바깥으로 메모리를 침범할 수도 없고 접근할 인터페이스가 주어지지도 않는다.
  • 인터페이스도 지나치게 제한적이다.

컨테이너와의 비교

그리도 비교를 하곤 하는 컨테이너, 무엇이 다를까?

컨테이너는 사실 가상화랄 게 없다.
그냥 리눅스에 프로세스 별로 자원을 독립시키는 기술이 등장했는데, 이 기술을 잘 이용해 프로세스가 가상의 환경에서 동작하는 것처럼 만들어버린 게 컨테이너다.
그래서 컨테이너와 비교해서 와즘이 더 나을 부분이 뭐가 있을까?

• 보안
  • 와즘은 엄격하게 분리된 런타임 환경을 지원한다.
  • 특별 인터페이스를 거치지 않으면 시스템 인터페이스 자체에 접근하지도 못 한다.
  • 반면 컨테이너는 가상화인 척하며 조금도 가상인 구석이 없는데 심지어 일반 리눅스의 명령어들을 가지고 있으면 이것들을 그대로 실행할 수 있다.
  • 컨테이너 탈출은 코어한 명령어나 파일 디렉토리에 접근하는 것으로 이뤄지는데, 와즘은 그럴 구석이 없다는 점에서 보안 상으론 유리할 수밖에..
• 속도
  • 와즘은 자체적으로 컴파일을 해서 최적화된 바이너리를 만들어 실행한다.
  • 그래서 아무리 한 런타임 위에 가상의 공간에서 실행된다고는 하나 속도가 그렇게 떨어지진 않는다.
  • 이 지점이 컨테이너의 대체로서 고려할 수 있게 만든 한 요소이다.
  • 그러나 그럼에도 파일IO, 네트워킹 등 시스템 호출이 많이 필요한 코드라면 속도는 아무렴 컨테이너가 나은 편이다.
• 빠른 스타트업
  • 컨테이너 이미지는 크기가 큰 경우가 많다.
    • 사실 scratch나 distroless처럼 정말 필요한 바이너리만 구성해서 실행하면 크기도 줄고 효율적이긴 할 텐데, 직접 이를 구성하는 것도 귀찮고 어떤 프로세스는 다른 의존성을 가지는 경우도 왕왕 있다.
  • 와즘은 설치 공간이 훨씬 작으며 초기 시작시간이 10~100배 가량 빠르다.

그래서 컨테이너를 대체하려는 움직임도 일어나고 있는데, 사실 컨테이너를 갈아엎는다는 것은 현재 구축된 쿠버네티스 생태계에 물보라를 일으킨다는 것과 같다.
안 그래도 kubelet을 와즘으로 구현하는 시도가 있었던 것으로 보이는데, 구체적인 이유는 안 봤으나 폭삭 망했수다^[3]
개인적 사견으로는 글쎄, 자바도 무거워서 극혐하는 마당에, 계속 성숙해가는 컨테이너 보안 기술이 있는데 굳이 와즘을..?
기술의 변화는 대체로 느린 편이다.
그런데 정말 빠르게 변화가 오는 케이스는 새로운 기술이 엄청난 편의성을 가져올 때라고 생각한다.
근데 내 눈에는 암만 봐도 편해보이지가 않는다..

활용

와즘은 어디에 활용될 수 있을까?

• 웹 - 시간이 많이 걸리겠지만 자쓰는 구시대 전유물이 될 수도 있다.
• 서버리스 - 서버리스는 애초에 자체적인 프레임워크와 환경을 제공하는 만큼, 와즘의 설계 방향과 잘 어울리며 실제로 이러한 지원이 생기고 있다.
  • 람다의 경우 와즘 서버리스 기능을 이미 제공하고 있다.
• 블록체인
  • 이쪽은 문외한이라 잘 모르겠는데, LLVM 컴파일러가 원래 잘 쓰였나보다.
  • 근데 여기에도 활용은 할 수 있다고 하는 것 같다.

WASI

와시는 W3C에서 지정한 시스템 api이다.^[4]
이걸 이용해서 웹에서만 돌아가던 와즘을 일반 소프트웨어의 레벨로 끌어내릴 수 있게됐다.

25년 기준 다음의 api가 제공되고 있다.

• Clocks - https://github.com/WebAssembly/wasi-clocks
• Random - https://github.com/WebAssembly/wasi-random
• Filesystem - https://github.com/WebAssembly/wasi-filesystem
• Sockets - https://github.com/WebAssembly/wasi-sockets
• CLI - https://github.com/WebAssembly/wasi-cli
• HTTP - https://github.com/WebAssembly/wasi-http

오잉 CLI면 그냥 다 해주는 거 아니냐..?

관련 문서

EXPLAIN - 파생 문서

기타 문서

참고