WebAssembly와 JVM의 차이점은 무엇인가요?

근본적으로 JVM과 WebAssembly는 둘 다 컴파일된 코드를 어디서나 실행하도록 설계되었습니다. JVM의 경우 이는 당시로선 전례 없는 다른 운영 체제나 CPU 아키텍처를 갖춘 기계를 의미했고, WebAssembly의 경우 이는 앞으로도 계속 어디서나 모든 컴퓨터의 모든 웹 브라우저에서 실행될 수 있음을 의미했습니다.

1990년대 중반에 Java와 함께 도입된 JVM은 가비지 컬렉션, 광범위한 표준 라이브러리, 관리형 실행을 위한 도구 등 풍부한 런타임 지원을 제공하는 본격적인 플랫폼으로 발전했습니다. 하지만 일부 사람들은 이로 인해 JVM이 상당히 팽창하여 메모리 사용량이 늘어나고 시작 시간이 느려진다고 말할 수도 있습니다. 매우 강력하지만 이로 인해 JVM은 가벼운 애플리케이션에는 덜 적합합니다.

이와 대조적으로 WebAssembly는 웹을 염두에 두고 설계되었습니다. 특히 브라우저 내에서 코드를 실행하기 위해 만들어졌습니다. 결과적으로 가벼운 런타임과 매우 빠른 시작 시간을 우선시하도록 설계되었지만, 풍부한 런타임 지원은 제공되지 않았습니다. 브라우저만 타겟으로 삼는다면 Wasm은 Java 바이트코드보다 이식성이 떨어지겠지만, 오늘날 독립형 Wasm 런타임은 웹 외부에서 실행될 수 있어 서버 측 애플리케이션, 임베디드 시스템 및 엣지 컴퓨팅에 새로운 가능성을 열어줍니다. 또한, 일부 제한적인 추가 런타임 지원, 즉 가비지 수집이 WebAssembly에 추가될 예정이지만, JVM이 제공하는 것만큼의 전체 런타임 지원을 WebAssembly에서 볼 수 있을 가능성은 낮습니다.

JVM은 Java, Kotlin, Scala 등 몇 가지 언어와만 호환되며, 이러한 언어는 모두 JVM 상에서 실행되도록 의도적으로 설계되었습니다. Java 생태계에는 광범위한 라이브러리와 프레임워크가 있지만 상호 운용성은 이러한 JVM 언어 간에만 가능합니다. JVM 기반 애플리케이션은 네이티브 코드를 호출할 수 있지만, 그러기 위해서는 많은 노력과 주의가 필요합니다.

WebAssembly는 단 하나의 프로그래밍 언어만 지원하거나 함수형, 가비지 수집형, 해석형 등 특정 언어 스타일을 선호하도록 설계된 것이 아닙니다. Rust, JavaScript, Python, C++ 등 모든 언어가 Wasm 런타임에서 실행되도록 컴파일될 수 있습니다. 지금 당장 각 언어의 코드가 서로 통신할 수 있다는 것은 아니지만, 새로운 컴포넌트 모델 표준을 통해 개발자는 서로 다른 언어로 작성된 여러 Wasm 모듈을 가져와 원활하게 연결할 수 있습니다. WebAssembly의 경우 곧 연결과 상호 운용성이 보장될 것입니다.

플러그인이나 사용자 정의 로직을 실행하기 위해 애플리케이션에 JVM을 내장했다는 이야기를 마지막으로 들은 건 언제였나요? 최근에 있었던 일이 아닌가요? JVM은 강력하지만 다른 애플리케이션에 내장하는 것은 매우 어려운 것으로 악명이 높습니다. 일부 주목할 만한 임베딩(브라우저의 Java 애플릿 등)이 등장했지만, 이러한 임베딩은 대체로 사용하기 불편하거나 유지 관리가 어렵다는 이유로 사라졌습니다.

반면, WebAssembly는 내장을 위해 설계되었습니다. 애플리케이션에 Wasm 런타임을 내장하는 것은 종종 새로운 라이브러리를 가져오는 것만큼 쉽습니다. 이 작업이 완료되면 애플리케이션에서 Wasm 코드를 실행할 수 있습니다. 이를 통해 게임 엔진을 확장하거나, 알고리즘을 수정하거나, 이벤트에 응답하거나, 상상할 수 있는 모든 작업을 수행할 수 있습니다. Wasm은 JVM이 제공할 수 없는(또는 제공하고 싶어하지 않는) 다양한 임베디드 기능을 제공합니다.

이것은 아마도 WebAssembly가 가장 빛나는 부분일 것입니다. JVM은 자체 보안 모델을 가지고 있지만, 실행되는 코드는 신뢰할 수 있다는 가정 하에 설계되었습니다. WebAssembly는 브라우저에서 발생하는 전제를 근본적으로 거부합니다. 즉, 웹사이트를 방문하면 신뢰할 수 없는 코드가 다운로드되어 실행된다는 전제를 거부합니다. Wasm은 기본적으로 거부하는 엄격한 샌드박스 모델을 사용합니다. 명시적으로 승인되지 않는 한 코드에 시스템 리소스, 메모리 또는 기타 기능에 대한 액세스 권한을 부여하지 않습니다. 이러한 접근 방식은 본질적으로 공격 표면을 최소화하며, 신뢰할 수 없는 코드 실행이 문제가 되는 환경에 Wasm을 이상적으로 만듭니다.

JVM의 보안 모델은 기능적이지만 Wasm이 제공하는 보안 수준에 맞게 설계되지 않았습니다.

JVM은 기술 세계의 노련한 베테랑입니다. 수십 년의 역사를 가지고 있으며, 엄청난 도입률, 광범위한 엔터프라이즈 툴, 그리고 소프트웨어 개발에서 움직일 수 없는 원동력처럼 느껴지는 광대한 커뮤니티에 뒷받침되어 있습니다. 그리고 우리는 이것이 조만간 사라지지 않을 것이라는 걸 알고 있습니다. 사용 사례에서 장수성과 검증된 안정성이 중요하다면 JVM이 그 역할을 합니다.

반면, WebAssembly는 아직 새로운 분야입니다. Wasm은 아직 어리고 10주년을 맞이한 지 얼마 안 되었지만, 이에 대한 열정은 기하급수적으로 커지고 있습니다. 오늘날 JVM만큼 성숙하지는 않았지만 WebAssembly의 발전 방향은 밝은 미래를 시사합니다.

WebAssembly와 JVM은 둘 다 놀라운 기술이며, 각각 해당 환경과 사용 사례에 적합한 방식으로 탁월한 성능을 발휘합니다. JVM은 완전한 애플리케이션과 풍부한 런타임 기능이 중요한 엔터프라이즈 워크플로에서 빛을 발합니다. 반면 Wasm은 내장성, 가벼운 런타임, 언어 간 호환성, 탁월한 보안성 덕분에 플러그인과 엣지 컴퓨팅에 적합한 선택입니다.

그러면 어떤 것을 선택해야 할까요? 견고한 런타임 요구 사항이 있는 독립형 애플리케이션을 개발하는 경우 JVM은 여전히 실용적이고 시간에 따라 검증된 선택입니다. 하지만 언어 전반에 걸친 유연성이 필요하거나 기존 앱에 손쉽게 플러그인할 수 있는 기능이 필요하다면 WebAssembly가 그 대안이 될 수 있습니다.