예리한 개발자들이 WebAssembly(줄여서 Wasm)를 처음 접하면 흔히 이런 의문을 품습니다. WebAssembly는 Java Virtual Machine(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이 조만간 사라질 일은 없다는 뜻입니다. 사용 사례에서 장기적인 지속 가능성과 검증된 안정성이 중요하다면 JVM이 그 기대를 충족합니다.
한편 WebAssembly는 아직 신생 기술입니다. 등장한 지 10년이 채 되지 않은 비교적 젊은 기술이지만, Wasm을 향한 관심과 열기는 기하급수적으로 커지고 있습니다. 현재로서는 JVM보다 성숙도가 낮지만, WebAssembly의 발전 추세를 보면 밝은 미래가 기대됩니다.
결론
WebAssembly와 JVM은 모두 뛰어난 기술로, 각각의 환경과 사용 사례에 적합한 영역에서 탁월한 성능을 발휘합니다. JVM은 완전한 기능을 갖춘 애플리케이션과 풍부한 런타임 기능이 중요한 엔터프라이즈 워크플로에서 강점을 보입니다. 반면 Wasm은 뛰어난 임베디드 가능성, 경량 런타임, 언어 간 호환성, 독보적인 보안성을 바탕으로 플러그인과 엣지 컴퓨팅을 위한 매력적인 선택지로 자리 잡고 있습니다.
그렇다면 무엇을 선택해야 할까요? 강력한 런타임 기능이 필요한 독립형 애플리케이션을 개발한다면 JVM은 여전히 실용적이고 오랜 시간 검증된 선택입니다. 하지만 여러 언어를 유연하게 활용하거나 기존 앱에 손쉽게 통합할 수 있는 기능을 원한다면 WebAssembly가 더 나은 선택일 수 있습니다.
관련 블로그 게시물
AI 시대의 새로운 애플리케이션 제공 원칙으로 복잡성 극복하기
보안, 일관성, 완전 자동화에 중점을 둔 애플리케이션 제공의 새로운 6가지 원칙을 도입하여 복잡성 없이 하이브리드 멀티클라우드의 유연성을 누리세요.
디지털 혁신을 가속화하는 6가지 기술 역량
오늘날의 엔터프라이즈 아키텍처에는 기술 변화를 주도하는 데 핵심적인 민첩성, 확장성, 보안 및 관찰 가능성이 부족하지만, 이 여섯 가지 핵심 역량은 기업이 디지털 혁신 전반에 걸쳐 위험과 과제를 관리하는 데 도움이 될 것입니다.
하이브리드 근무가 ID 중심 보안으로의 전환을 이끌고 있습니다
자동화와 디지털화의 폭발적인 성장에 하이브리드 근무 모델로의 전환 추세가 더해지면서, IP 기반 보안에서 벗어나 ID 기반 액세스 전략으로 전환하는 움직임이 더욱 가속화될 것입니다.
관점의 현대화: 애플리케이션에서 경험으로
그리스와 로마의 신들처럼, 여러 신화에서도 동일한 존재가 다양한 모습으로 나타나는 것을 볼 수 있습니다. 본질적으로 각각의 화신은 기존 존재가 새로운 얼굴로 드러난 것입니다. 디지털 세계에서도 이와 비슷한 양상이 나타납니다. 우리가 ‘애플리케이션’이라고 부르는 것들은 흔히 기존 기능이 새로운 형태로 구현된 것이라 볼 수 있습니다.
코로나19 이후 기업 결제의 디지털 전환
디지털 결제는 과거의 현금만큼이나 보편화되었습니다. 코로나19 팬데믹으로 인한 봉쇄 조치는 소비자의 디지털 결제 서비스 의존도를 더욱 빠르게 높였습니다. 기업의 디지털 결제 도입 역시 가속화되었습니다. 대중을 상대로 영업하든 하지 않든 기업에는 여전히 지급해야 할 대금과 받아야 할 대금이 있기 때문입니다.
공급망 해킹과 보안에서 하드웨어의 역할
수석 아키텍트 Dave Schmitt와 CTO 오피스가 최근 Bloomberg의 Super Micro 관련 기사를 계기로 하드웨어 보안 전문성의 중요성을 되짚어봅니다. 또한 이 글에서는 시스템이 안전하게 보호되고 있는지 확인하기 위해 공급업체에 물어봐야 할 질문도 소개합니다.