웹어셈블리란?
웹어셈블리(WebAssembly, 간단히 Wasm)는 실행 프로그램 및 그와 일치하는 텍스트 어셈블리어, 그리고 이러한 프로그램과 호스트 환경 간 통신을 용이케하는 인터페이스를 위한 이식가능한 이진 포맷을 정의하는 개방형 표준입니다. 즉, 웹에서 사용할 수 있는 매우 효율적이고 컴팩트한 저수준 바이트 코드라고 설명할 수 있습니다.
2015년부터 개발된 기술로 2017년에 처음으로 발표되었습니다. 현재는 W3C WebAssembly Working Group과 Community Group에서 웹 표준으로 개발 되고 있습니다.
웹어셈블리는 브라우저 내에 구축되어 있어 플러그인이 필요없습니다. 사실 웹어셈블리 파일을 열게 되면 단순 바이너리 파일입니다. 따라서, 브라우저에서 Wasm을 사용하려면 사용자는 Emscripten SDK를 사용하여 C++(혹은 C나 Rust, Go 등의 기타 LLVM* 지원언어) 소스코드를 이진파일로 컴파일한 다음 동일한 샌드박스에서 일반 자바스크립트 코드로도 실행할 수 있습니다.
- * LLVM - 현재 웹어셈블리를 가장 잘 지원하는 컴파일러 도구 모음
웹어셈블리의 로딩 및 실행
WASM을 사용하면 자바스크립트 이외의 언어(e.g. C, C++, Rust 등)를 사용하여 프로그램을 작성한 다음 런타임 이전에 웹어셈블리로 컴파일 할 수 있습니다. 따라서 로드 및 실행이 매우 빠른 웹, 앱을 얻을 수 있습니다.
자바스크립트는 인터프리트(interprete) 언어로, 파일을 로딩하려면 브라우저는 .js 파일의 텍스트들을 모두 읽어들여야하지만, 웹어셈블리에서는 이미 컴파일되어 있고 이진파일로 된 .wasm파일만 인터넷을 통해 전송하기 때문에 브라우저에서 로드하는 속도가 더 빠릅니다.
또한 현재 웹어셈블리의 실행 속도는 네이티브 코드보다 20%밖에 느리지 않습니다. 샌드박스 환경으로 컴파일된 후 보안상에 취약한 점이 없도록 많은 제약 조건하에 실행되었음에도 불구하고 슈퍼 빨라서(?) 매우 놀라운 결과를 보여주고 있습니다. 수정과 새로운 기능들의 추가가 계속 되면 속도가 점점 더 빨라질 것입니다.
2017년 2월 28일, 주요 브라우저 4개(Chrome, Edge, Firefox, Webkit)는 웹어셈블리의 MVP가 완료되었다고 합의했습니다. 즉, 브라우저들이 기본적으로 웹어셈블리를 제공하기 시작할 수 있게 되었고 최초의 안정적인 버전을 제공하게 되었습니다. 따라서 웹어셈블리는 특정 브라우저에 구속되지 않는다는 장점이 있습니다. 이 덕분에 현재 크롬, 파이어폭스 등에서 데모나 3D 시뮬레이션을 볼 수 있게 되었습니다.
WASM 작성
웹어셈블리는 다른 어셈블리 언어들과는 달리 직접적으로 물리적인 기계에 매핑되기 보다는 개념상의 기계를 위한 언어입니다. 즉, 자바스크립트 언어보다는 훨씬 직접적으로 기계 코드와 매핑되지만 특정 하드웨어 기기 코드에 매핑되는 것은 아닙니다.
따라서 C언어를 이용하여 .wasm파일을 작성하려면, clang 프론트엔드를 이용해서 LLVM 중간 표현 방식으로 변환할 수 있고, LLVM의 IR로 변환하면 LLVM이 몇 가지 최적화를 할 수 있게 됩니다. 즉, C언어 코드를 작성 후 Emscripten 컴파일러를 이용하여 WebAssembly 모듈로 변환하고 이 .wasm파일을 웹팩 로더를 사용해서 로딩 및 번들링하면 됩니다.
웹어셈블리가 자바스크립트를 대체할 수 있을까?
우리가 분명히 해야할 것은 웹어셈블리는 자바스크립트의 경쟁상대가 아니라는 것입니다.
웹어셈블리가 js보다 컴파일 속도가 빠르고, 효율적이며 높은 이식성을 가져 성능면에서 큰 장점을 가지지만, js만큼의 좋은 접근성과 유연성을 가지지 못한다는 점에서 아쉬움이 있습니다. 또한 자바스크립트로는 하기 힘든 작업을 웹어셈블리로는 쉽게 해결할 수 있어 서로 상호보완관계라고도 볼 수 있습니다.
예를 들어, 자바스크립트는 포토샵, 프리미어 프로와 같이 사진/영상 작업(image processing)을 하기에는 매우 어렵고 느리다는 단점을 가집니다. 그러나 웹어셈블리 덕분에 포토샵 등을 브라우저에서 바로 돌릴 수 있게 되어 컴퓨터에 프로그램을 설치하지 않을 수 있게 될 것입니다. 또한, 사진/영상작업 툴 이외에도 게임을 브라우저로 실행시킬 수 있게 되어 컴퓨터에 게임프로그램을 설치하는 등의 수고로움을 덜 수 있습니다.
[출처] 노마드 코더 Nomad Coders
앞서 말했듯이 주요 브라우저들에서 사용가능하여 우리에게 가까이 다가왔지만, 아직까지는 웹어셈블리 모듈이 모든 플랫폼 API에 액세스하지는 못합니다. 모든 것은 자바스크립트가 기반이 되어 조정됩니다. 즉, 웹어셈블리 모듈 내부의 특정 플랫폼 API에 액세스하려면 자바스크립트를 통해 호출해야합니다.
예를 들어, console.log를 원하면 C 혹은 C++ 코드 대신 자바스크립트로 호출해야 합니다. 물론 이러한 자바스크립트 호출에는 비용이 듭니다. 하지만 향후에 wasm에 플랫폼 API를 제공 하는 사양이 추가될 수 있기때문에, 그 때는 자바스크립트 없이 웹어셈블리만으로도 앱을 출시 할 수 있게 될 지도 모릅니다.
그러나 여기에서 또 하나 짚고 넘어가야할 점은 WASM은 개발자가 직접적으로 작성하는 것이 아니라 C, C++, Rust 등의 LLVM 지원언어로 작성하고 해당 로직이 브라우저에서 작동하도록 허용하기위한 것이기 때문에 자바스크립트를 대체하는 것과는 거리가 멀어 보입니다.
결론적으로, 현재 웹어셈블리와 자바스크립트는 서로 대체제가 아니라 서로의 보완재로서 충분히 제 역할을 할 수 있습니다. 예를 들어, 굉장히 빠른 웹어셈블리 함수를 유저가 버튼을 클릭하면 자바스크립트가 호출하는 것으로 만들 수 있습니다. 즉, 웹어셈블리와 자바스크립트는 함께 쓰임으로써 폭발적인 에너지를 낼 수 있다고 생각합니다.
웹어셈블리의 미래
웹 어셈블리는 다른 것들과 웹 사이의 격차를 해소하는 목표를 두고 설계가 되었고, 그 목표를 향해 발전해나가고 있습니다. 부족한 점이 많은 것은 사실이지만 성능 면에서는 확실히 큰 이점을 가지고 있고, 메이저 브라우저들에서 지원해주고 있다는 사실은 관심을 끌기에 충분합니다.
또한, 웹어셈블리는 앱의 보안 측면에서도 강점을 가지고 있습니다. 각 웹어셈블리 어플리케이션은 자체 샌드박스에서 실행되기 때문에, 시스템 내에서 하나라도 변경할 시 무조건 API 또는 다른 의도적인 방법을 통해야만 합니다.
현재는 자바스크립트와 타입스크립트 등이 트렌드를 꽉 잡고 있기 때문에, 자바스크립트가 아닌 LLVM 지원 언어들을 사용하여 웹 개발을 원하거나 이미지 프로세싱 등 자바스크립트로 하기에는 어려운 경우와 같은 ‘소수의 상황에서 사용되는 도구’ 이상이 될 수 있을 지는 장담하지 못합니다.
그러나 계속적으로 빠른 속도와 높은 보안성을 원하는 사람들이 증가함과 동시에 더욱더 각광받는 언어가 되지 않을까 예상해봅니다.
요약 및 결론
웹어셈블리는 현재 주요 브라우저들에서 제공이 되고 있는, 자바스크립트 이외의 LLVM에서 제공하는 C, C++, Rust 등의 언어로 만든 저수준 코드들을 사용하여 컴파일할 수 있는 것입니다. 이 때, 하드웨어 기기의 코드에 직접 맵핑되는 것이 아닌 개념상의 기계를 위한 언어입니다.
현재까지는 아직 자바스크립트를 사용하지 않고 웹어셈블리로만 웹 혹은 앱을 제작하기에는 부족한 부분이 있지만, 이를 차차 발전해나간다면 성능면에서나 사용범위면에서나 프론트엔드 개발자들에게 충분히 매력적인 코드로써 작용할 수 있다고 생각합니다.
GDSC UOS FE팀의 10월 Teck Talk 주제인 ‘10년 뒤 자바스크립트는 망할 것인가?’ 에 대한 제 생각은 ‘아니오’입니다. ‘망한다’라고 주장한 측에서는 웹어셈블리의 강점을 들며 주장했지만, 사실 자바스크립트와 웹어셈블리는 경쟁상대가 아닌 상호보완적관계라 생각할뿐더러 함께 성장해나간다면 그 효력이 더 좋을 것 같습니다.
끝~~!