<div id="readability-page-1" class="page"><article id="post-10660">
	
		<div>
			
<p>프론트엔드 개발자들에게 잘 알려진 The State of JavaScript와 비슷한 <a href="https://blog.scottlogic.com/2023/10/18/the-state-of-webassembly-2023.html">The State of WebAssembly</a>라는, 개발자들을 대상으로 하는 설문조사를 우연히 알게 되었다. 관련 글과 데이터를 보고 재밌어 보여서 내용과 감상을 글로 남겨본다.</p>



<div><p><h3>면책 조항</h3></p><p>먼저 <span>면책 조항</span>부터 얘기하자. The State of WebAssembly가 WebAssembly에 관한 유일한 설문 조사라서 개인적으로는 나름 재밌게 보았고 이 글을 작성하기도 했지만 표본수가 300명 남짓한, 그리 공신력 있는 조사는 아니다. 아직은 웹 어셈블리에 대한 관심이 적은 게 이유일 것이라 짐작해본다.</p></div>



<p>WebAssembly는 다양한 언어로 작성할 수 있다. 그렇다면 WebAssembly를 사용하는 개발자들이 가장 많이 사용하는 언어는 무엇일까? 이미 짐작한 분도 있겠지만 정답은 Rust였다. </p>



<figure><img decoding="async" fetchpriority="high" width="1024" height="632" src="https://taegon.kim/wp-content/uploads/2023/10/wasm-language-usage-1024x632.png" alt="" sizes="(max-width: 1024px) 100vw, 1024px"></figure>



<p>조금 특이하게 보았던 부분은 의외로 WebAssembly를 작성하는 데 자바스크립트가 많이 사용된다는 것이었다. 방법이 궁금했는데 위에 링크한 글에서는 예시로 Javy를 들면서 자바스크립트 런타임(혹은 엔진)을 웹 어셈블리로 컴파일한 후 그 안에서 JS를 구동한다는 것이었다. 성능 면에서 이점은 없지만 실행 컨텍스트가 완전히 격리되는 만큼 보안 측면에서는 더 나을 거라는 설명이 있었다.</p>



<p>이쯤에서 "굳이?"라는 생각이 들 수 있다. 격리가 필요하다면 Web Worker로 어느 정도 감당이 될 텐데 왜 이런 방법을 사용하는 걸까. 다른 사례의 의도는 잘 모르겠지만 예시로 든 Shopify의 <a href="https://shopify.engineering/javascript-in-webassembly-for-shopify-functions">Javy</a>는 Shopify Functions라는 자체 서버리스 플랫폼에 사용되기 위해 QuickJS를 웹 어셈블리로 컴파일하여 작성된 듯하다. 최근 발표한 <a href="https://shopify.engineering/introducing-ruvy">Ruvy</a>까지 놓고 보면 자사 플랫폼 서비스에서 다양한 백엔드 언어를 지원하는 게 목적인 것으로 보인다. 다시 말해, 이런 플랫폼이 아니라면 JS 런타임을 웹 어셈블리로 사용하는 건 불필요하지 않을까 싶다.</p>



<p>C++은 짐작했던 바이고 Go도 어느 정도는 이해가 되었다. 프론트엔드 개발자에게 상대적으로 친숙한 문법을 내세운 <a href="https://www.assemblyscript.org/">AssemblyScript</a>도 사용한다고 응답은 사람이 생각보다 많아서 의외였다. 새로운 JS 런타임인 Bun 덕분에 유명해진 Zig도 은근히 사용자가 있는 편이었다.</p>



<p>특이한 점은 Zig로 WebAssembly를 사용해보고 싶다는 응답이 현재 사용량에 비해 꽤 높게 나왔다는 것이다. 물론 "WASM으로 사용해보고 싶은 언어" 응답의 양으로 보면 Rust와 JS가 가장 많았다. 하지만 바로 뒤를 이어 Zig가 올라왔다는 점은 눈에 띄었다.</p>



<p>마이너 한 언어를 둘러보는 걸 좋아해서 Zig도 조금씩 맛보고 있었고, 나 역시 WebAssembly 언어로서 Zig를 눈여겨봤기 때문에 나름 반갑기도 한 결과였다. 하지만 Zig라는 언어는, 아직도 발전 중이고 마이너 변경에도 하위 호환성이 깨질 수도 있는 불안정한 언어이다. 이래저래 사용해 보면서 이런 언어로 Bun이라는 결과물을 내놓은 개발자가 대단하다는 생각부터 들었을 정도이다. 이 언어에 대한 감상은 이 글의 주제에서 벗어나므로 나중에 기회가 있을 때 다른 글에서 다루기로 하겠다.</p>



<p>사용 분야를 보면 웹 애플리케이션이 가장 많고 서버리스 애플리케이션과 플러그인, 백엔드 서비스 등이 뒤를 이었다. 다만, 기업에서 사용되고 있거나 사용될 계획 중인 비율은 낮은 수준에 머물러 있었다. 아무래도 아직은 기능 면에서도 부족하고 웹 애플리케이션이 대체로 어마어마한 성능을 필요로 하지 않다보니 JS 정도의 처리 능력이면 충분한 경우가 많아서라고 생각한다.</p>



<p>기능 면에서는 스레드, 예외 처리, 가비지 컬렉션 등에 대한 요구가 높았는데 표준화 단계에서 이미 진척이 많이 된 항목들이라고 하니 조금은 기대가 된다.</p>



<h2>마치며</h2>



<p>정확한 근거를 들 수는 없지만 머지않은 미래에 WebAssembly는 웹을 구성하는 중요한 요소로 자리매김할 것이라고 생각한다. 섣부른 판단일지 모르나 어쩌면 웹의 유일무이한 언어로서 JS가 지켜온 자리가 조금은 흔들리는 계기가 될 수도 있다. 하지만 이번 설문조사 결과에서 보았듯 WebAssembly의 현재 상태는 아직 갈 길이 멀다. 당장 프로덕션에 적용하기엔 무리겠지만, 조금이라도 더 많은 사람들이 이 기술에 관심을 가졌으면 하는 바람과 함께 글을 마친다.</p>



<p>해당 조사 결과에 대해 더 자세한 내용은 <a href="https://blog.scottlogic.com/2023/10/18/the-state-of-webassembly-2023.html">The State of WebAssembly 2023</a>에서 볼 수 있다.</p>
		</div>
	</article></div>

코드쓰는사람

프론트엔드 개발자들에게 잘 알려진 The State of JavaScript와 비슷한 The State of WebAssembly라는, 개발자들을 대상으로 하는 설문조사를 우연히 알게 되었다. 관련 글과 데이터를 보고 재밌어 보여서 내용과 감상을 글로 남겨본다. WebAssembly는 다양한 언어로 작성할 수 있다. 그렇다면 WebAssembly를 사용하는 개발자들이 가장 많이 사용하는 언어는 무엇일까? 이미 짐작한 분도 있겠지만 정답은 Rust였다. 조금 특이하게 보았던 부분은 […]

WebAssembly 사용 현황 / 2023년

댓글