▲

WASM 3.0 완성

 (webassembly.org)
5P by GN⁺ 4시간전 | ★ favorite | 댓글 2개
  • Wasm 3.0 표준이 공식 발표되며, 6~8년간 준비된 대규모 기능들이 포함됨
  • 64비트 주소 공간, 가비지 컬렉션, 타입드 레퍼런스, 테일 콜, 예외 처리 등으로, 고수준 언어를 Wasm에 더 쉽게 컴파일할 수 있게 함
  • 핵심 신기능들은 고성능 애플리케이션, 다양한 언어 런타임, 안전성 및 확장성에 도움을 줌
  • 웹 환경 외에도 비웹 생태계에서 더 큰 용량과 데이터 집합을 다뤄야 하는 사례에 적합함
  • 이미 주요 웹 브라우저에서 지원 중이며, Wasmtime 같은 독립 엔진에서도 곧 완성될 예정으로, Wasm이 범용 실행 플랫폼으로 더욱 자리잡을 것

Wasm 3.0 출시 개요

  • WebAssembly 표준의 3.0 버전이 2025년 9월 17일에 출시됨
    • 2.0 버전(2022년 완료)이 벡터 명령어, 벌크 메모리 작업, 다중 반환 값, 간단한 참조 타입을 도입한 지 3년 만의 주요 업데이트
    • W3C 커뮤니티 그룹과 워킹 그룹이 개발을 지속하며, 이번 릴리스는 6~8년간 준비된 대형 기능들을 포함한 상당히 큰 규모의 변경
    • Wasm은 저수준 언어로서의 정신을 유지하면서 메모리와 타입 시스템을 강화하여 고수준 언어 컴파일을 더 잘 지원
  • 2.0 버전 이후 개발된 기능들이 마무리되어 Live 표준으로 자리 잡으며, 웹 브라우저와 독립 엔진에서 지원이 확대됨
    • Wasm 기능 상태 페이지에서 각 엔진의 지원 현황을 추적 가능
    • 새로운 SpecTec 도구 체인을 사용해 첫 번째 버전으로 생산되어 신뢰성 향상

주요 변경점 및 신기능

  • 64비트 주소 공간
    • 메모리와 테이블을 i64 타입으로 선언할 수 있음
    • Wasm 애플리케이션의 주소 공간이 약 4GB에서 물리 한계까지(이론적으로 16엑사바이트) 확장 가능
    • 웹의 경우 16GB 제한을 적용하지만, 비웹 생태계에서는 대규모 애플리케이션·데이터셋 지원에 유용함
  • 다중 메모리
    • 단일 모듈 내에서 여러 메모리 객체 선언 및 직접 접근 가능
    • 모듈 병합 및 주소 공간 분리, 버퍼링, 보안 등 다양한 활용 가능
    • wasm-merge 같은 정적 링킹 도구가 모든 Wasm 모듈에 사용할 수 있게 됨
  • 가비지 컬렉션 (GC)
    • 선형 메모리 외에, Wasm 런타임이 자동 관리하는 저장소 지원
    • 컴파일러는 struct/array 타입 및 unboxed 정수 등 데이터 레이아웃을 직접 선언함
    • 메모리 관리의 기본 빌딩블록만 제공하고, 고수준 객체 시스템 또는 클로저는 구현 언어에 따라 개별적으로 설계 가능
  • 타입드 레퍼런스
    • Wasm 타입 시스템이 확장되어, 힙 값의 형태와 함수 참조를 더 정확히 기술
    • 하위타입(subtyping), 타입 재귀를 지원하며, 새로운 call_ref 명령어로 런타임 타입 체크 없이 안전한 간접 함수 호출 가능
  • 테일 콜
    • 기존 함수의 스택 공간 추가 사용 없이, 바로 반환하는 tail call 구조 지원
    • 함수형 언어나 런타임 내부 최적화 등에 활용될 수 있음
  • 예외 처리
    • Wasm 내에서 네이티브 예외 처리 시스템을 도입
    • 예외 태그와 페이로드 선언, 선택적 캐치, 블록단위 예외 핸들러 제공
    • 기존에 JS로 우회하던 비효율적 방법 없이 이식성과 성능 개선 가능
  • 리랙스드(완화된) 벡터 명령어
    • SIMD 명령어의 하드웨어 차이에 대응해, 일부 명령어의 세부 동작을 구현 자유에 맡기도록 relaxed variant 제공
    • 합법적 동작 집합 내에서 다양한 최적화가 가능함
  • 결정론적 프로파일
    • 동일 명령에 대한 결과가 비결정적인 상황(부동소수점 연산, relaxed SIMD 등)에서도, 플랫폼 간 결정론적 실행을 정의
    • 블록체인, 재생 가능한 시스템 등 재현성과 이식성 보장 가능
  • 커스텀 애노테이션 구문
    • 소스 코드 내에서 사람이 읽고 쓸 수 있는 애노테이션 문법 추가
    • 표준이 직접 해석하지 않지만, 향후 표준·확장 구현에 활용 가능

JavaScript 연결 및 호환성

  • JS string builtins
    • JS의 문자열 값을 externref로 Wasm에 전달 및 조작 가능
    • 새 기본 함수를 import하여, Wasm 내부에서 직접 외부 JS 문자열을 쓸 수 있음

Wasm 3.0의 효용성 및 전망

  • 고급 프로그래밍 언어의 Wasm 타겟 컴파일에 필수적 기반 제공
  • Java, OCaml, Scala, Kotlin, Scheme, Dart 등 주요 언어에서도 GC 기능을 적극 활용하기 시작함

사양 제작 및 배포 현황

  • Wasm 3.0은 새로운 SpecTec 툴체인으로 처음 제작된 표준임
  • 대부분의 주요 웹 브라우저에서 이미 Wasm 3.0을 지원 중이며, Wasmtime 등 독립형 엔진도 곧 완성 예정
  • Wasm feature status 페이지에서 각 엔진별 지원 현황 확인 가능
▲
coremaker 1시간전  [-]

메모리 DB 를 만들려는 시도도 생기지 않을까요?

답변달기
▲
GN⁺ 4시간전  [-]
Hacker News 의견

  • 64비트가 스펙의 기본값이 되는 게 정말 기대되는 부분임, 특히 온라인 영상 편집기 같은 웹앱들은 32비트 한계 때문에 지금도 여러가지 제약을 많이 받고 있음, Figma에서도 이런 제약을 직접 경험하고 있음, 한 가지 궁금한 점은 모바일 기기에서 탭별 주소 지정 메모리 제한이 그대로 유지될지 여부임, 보통은 OS에 의해 정의되어 있어서 32비트 공간과 직접적으로 연결되어 있지 않을 수도 있음

    • Video editor 같은 앱이 문서 브라우저에 들어온다는 것이 옳은지 의문임, 잘 만들어진 네이티브 운영체제가 있음에도 이제 아무도 쓰지 않는다는 점이 아쉬움, 만약 기존 운영체제 프로세스에서 주는 가상화보다 더 강력한 가상화 머신이 필요하다면, 아예 목적에 맞는 추상화를 설계하는 게 정직하다고 생각함, 단순한 문서 리더를 억지로 영상 편집기로 개조하는 느낌이 있음

    • 아쉽게도 Memory64 기능은 성능 페널티가 꽤 큼, 기존 32비트에서는 런타임이 매번 4GB 전체를 할당해버려서 경계 체크가 사실상 필요 없었지만, 64비트에서는 경계를 직접 확인해야 하기 때문임, 4GB 이상 메모리가 꼭 필요하다면 어쩔 수 없이 써야 함

    • GC, 참조 타입, JS string API가 도입되는 것도 기대됨, 오랜만에 반가운 J, 잘 지내고 있는지 궁금함

    • 웹앱이 4GiB 메모리 한도에 막히는 게 당연해 보이긴 함, 요즘 메일 읽는 데 512GiB가 최소인 세상 느낌임

  • 가비지 컬렉션이 추가된다는 점이 정말 신기함, 기존에는 Wasm에서 스택에 직접 접근할 수 없어서 스택 스캐닝 같은 전통적 GC 접근이 불가능했음, 덕분에 러우 레벨 언어 성격을 유지하면서 struct, array 타입, unboxed tagged int 등으로 메모리 레이아웃을 명시하고, 할당과 수명 관리는 Wasm이 처리하게 됨, 여기까지임, 감탄스러움

    • GC가 도입되면서 비GC 환경까지 모두 지원하는 구조라 신선함, 이 점이 D 언어와 유사함(D는 비GC와 GC 모두 빠른 컴파일, 실행 지원함), 참고로 Dlang 컴파일러인 LDC로도 이제 Wasm 생성 가능함 Generating WebAssembly with LDC

    • 이 변화로 WebAssembly.Memory 객체의 크기 축소가 가능해지는지 궁금함, 메모리를 해제해도 아직 브라우저에 할당된 상태로 남는다는 점에서 매우 중요한 이슈임 이슈1 이슈2

  • WASM이 DOM을 직접적으로 건드릴 수 있게 되는 시점이 언제인지 궁금함, 이게 원래 WASM의 핵심 목적 같았는데, 지금은 웹과 거의 상관없는 별도의 괴물처럼 느껴짐, JavaScript는 언제쯤 안 써도 되게 될지 궁금함

    • 이 부분과 멀티스레드 접근이 제대로 지원되길 바람, Rust 앱을 써서 wasm으로 컴파일해서 아래처럼 바로 불러오고 싶음:

      <html>
  <body>
    <div id="root"></div>
    <script type="application/wasm" src="./main.wasm"></script>
  </body>
</html>

      고성능 웹앱, 또는 브라우저 확장 같은 곳에서 메모리, 성능 이슈가 실제로 크니까 이게 엄청 도움이 될 것임, wasm 기반 앱이면 v8을 건너뛰고 wasmer 같은 엔진도 직접 쓸 수 있음, 웹 기술이 Electron 같은 데스크톱 앱에 쓰이는 건 데스크톱 API가 너무 별로고 이식성이 없어서라고 생각함, WASM의 네이티브 지원이 강화되면 Slack, VSCode, Discord 같은 앱들이 더 가벼워질 수 있음

    • 지금도 WASM 프로그램으로 DOM 접근 가능함, 다만 기존 JS API를 통해야 해서, 한때 WASM 전용 API를 논의했으나 단점이 많아져서 결국 폐기된 상태임

    • 설계 잘된 프런트엔드 언어를 기다리며 상황을 지켜보고 있음, 그런데 DOM에 접근할 때 JS 래퍼를 거치는 게 그렇게까지 비효율적인가 의문임, 대부분의 코드는 이미 비효율적이어서, 여기서 오는 오버헤드는 실제로 그다지 두드러지지 않는다고 생각함

    • JavaScript에 문제가 있다고 생각한다면 DOM 쪽은 더 심각한 걸 알게 될 것임

    • DOM 참조를 가지게 되면 가비지 컬렉션 가능한 객체를 직접 들여다볼 수 있게 된다는 점이 tricky함, 웹 JavaScript 보안 모델상 GC 내부를 들여다볼 수 없어야 하는데, 만약 WASM이 DOM에 포인터를 들고 있다면 그걸 어떻게 처리해야 할지가 문제임, GC가 제대로 도입된 후에는 이 문제가 다시 논의될 수 있겠지만, GC 없는 WASM에서는 거의 답이 없는 문제로 보임

  • WASM 개발을 1년 정도 팔로업 안 했더니, 버전별 릴리즈 모델로 넘어갔다는 걸 이제야 알게 되었음, 여러 기능이 옵션으로 남을 줄 알았는데, 이제는 모든 구현체가 모든 기능을 지원해야 특정 버전 호환이라고 말할 수 있게 된 듯함(WASM 3.0 등), 두 번째로 3.0 완전 지원하는 non-browser 워크타임이 누가 될지 궁금함, wasmtime이 첫 번째일 것 같음(deno는 v8 기반이라 제외), GC는 특히 tricky한 기능처럼 느껴짐, 3.0 릴리즈가 기존 "evergreen" 모델과 어떻게 연결되는지 아는 사람 있는지 궁금함, evergreen은 계속 표준 초안만 갱신하고, 공식 최종 버전은 따로 두지 않는 모델임, 현재 최신 Candidate Recommendation Draft가 사실상 표준으로 간주됨 wasm feature 현황 wasm 2.0 소식 최신 표준 초안

    • wasmtime은 이미 wasm 3.0의 주요 기능을 전부 지원함, GC는 동료 Nick Fitzgerald가 몇 년 전에 구현했고, tail call은 작년에 Jamey Sharp와 Trevor Elliott가 완전 범위로 구현했음(시그니처 제한 없이, 트램폴린 필요 없음), 예외 처리도 나와서 곧 정식 릴리즈 예정임, "3.0"이라는 릴리즈는 엔진별로 각 기능을 이미 다 준비해왔다는 신호라고 보면 됨, 나는 wasmtime과 Cranelift 메인테이너임

    • Wizard는 research 용 툴이지만 Wasm 3.0을 모두 지원함, 대신 인터프리터와 baseline 컴파일러만 있고, v8이나 wasmtime처럼 최적화된 컴파일러는 없음, 그래서 속도 자체는 느림

    • 버전 관리가 JavaScript의 feature set 방식처럼 될 것 같음, 즉 각 런타임이 어떤 기능 셋을 지원하는지로 말해지게 됨, wasm에서 feature discovery(기능 탐지)는 어떻게 돌아가는지 궁금함

  • GC 지원이 추가된 점이 정말 반가움, 예전엔 WASM에서 스택에 직접 접근이 안 돼서 전통적 stack scanning 방식의 GC 구현이 사실상 불가능했음

  • WebAssembly 커뮤니티가 개발자 경험(DX)를 더 신경 써야 한다고 느낌, 직접 컴파일러를 하나 작성해서 Wasm을 타겟으로 삼아봤는데 꽤 불편했음, 정형화된 의미를 가진 언어라고 생각했지만 실제로는 Binaryen.js로 Wasm을 생성하는 과정에서 명확한 인스트럭션 집합을 타겟팅하는 기분이 별로 안 들었음, 아마 Binaryen 자체와 문서 부족 탓이라고 생각함, Wasm 텍스트 스니펫은 작성할 때 재밌었다는 점이 위안임 jasmine wasm 컴파일러

    • Binaryen은 예전 Wasm가 AST라서 쌓인 레거시가 많음, 새로운 기능들은 기존 모델에 맞추기가 어려움, 우리 컴파일러는 따로 추상 Wasm 표현용 자료구조를 정의해서 쓰고, 컴파일 디폴트는 .wasm, 디버그 때는 .wat로 각각 내보냄, 꽤 직관적이라 인스트럭션 셋은 괜찮다고 생각함 Scala.js wasm backend

    • TypeScript에서 Binaryen을 써보다가 비슷하게 답답함을 느낌, Rust 기반 wasm-tools로 갈아탔는데 훨씬 나은 경험이었음

    • 구체적으로 어떤 부분이 힘들었는지 궁금함, validation error가 정말 짜증나는 경우가 있어서 Wizard에도 --trace-validation 옵션을 둠, 검증 과정을 보기 쉽게 시각화해줌

    • binaryen.js 문서나 바인딩이 실제로 많이 부족하긴 함, 현재는 core Binaryen의 최적화 개선에 역량이 집중돼 있어서 JS/TS 쪽은 발전이 느림, 그래도 누군가 JS/TS 바인딩 개선에 시간을 쓴다면 모두에게 좋을 거라고 생각함

    • 순수 어셈블리 코드를 처음부터 만드는 게 더 쉽다는 느낌도 받음, 대부분의 자료가 Rust 툴에 집중되는데, 직접 손으로 쓰는 경험도 중요함, compiler와 assembly는 별개임, 컴파일러 개발자만 Wasm에 관심 가지는 게 아니라는 관점도 필요함

  • WASM에 여전히 기대를 가지고 있음, 이번 릴리즈가 멋져 보임, envoy에서 트래픽 많은 WASM 플러그인을 돌리고 있고, zellij 같은 터미널 앱용 플러그인에도 WASM을 쓰고 있음, 작은 사이드 프로젝트에선 rust leptos 기반 wasm 웹앱도 운영 중임, 솔직히 3개 중 2개는 기술적으로 최적 선택이 아닐 수도 있지만, 이 흐름이 앞으로 잘 이어질 것 같음, 모두 수고 많음

  • 단순한 게 최고임, 내 바람은 더 쉽고 빠른 Go struct 전달 방법임, go struct를 런타임에 넣거나 뺼 때 코드가 꼬이지 않고, 덧댄 솔루션을 쓸 일 없었으면 함, 여러 언어에 쓸 만한 범용 솔루션도 좋고, 그런데 현실적인 제한이 따르는 것도 괜찮음, 나에겐 go가 가장 중요함

    • 이 말에 공감함, 그리고 GC 없는 언어에서도 현실적으로 별로 더 낫지 않음, 실제로는 wasm에서 GC된 런타임들이 오히려 더 엉망임, 지금까지 쓴 JavaScript 중에 최악 경험은 수동 포인터 정리였음, C++에서는 스코프 벗어나면 소멸자가 처리해주는데 wasm, js에서는 전부 직접 관리해야 해서 JNI 했던 기억이 더 나았음(go 포함), 그리고 고생 끝에 겨우 struct 하나 전달하면 호출당 오버헤드가 커서 결국 더 큰 단위로 포장해 넘기기 시작함, 나 역시 wasm이 파이프라인만 괜찮아지길 바람, 지금까지는 힘듦

    • 네이티브 코드라면 해법은 똑같음: 언어 간에 표준 구조(C struct 등)에 맞추거나 serialize/deserialzie 함, 여러 런타임을 뒤섞어서 쓸 때 언어들이 직접 지원 안 하면 진짜 피곤한 상황임, 이게 왜 문제인지 obvious함

    • 원하는 게 뭔지 정확히는 모르겠으나, WASI의 근간이 되는 component model이 도움이 될 듯함, 이 모델은 각 모듈이 자체적으로 데이터를 메모리에 맵핑하는 방식을 정하고(나중엔 GC heap까지도), 구조체 타입 같은 것도 인터페이스로 정의해서 컴파일러가 glue 코드를 자동 생성하게 해줌

    • 이건 WASM 스펙이 아니라 라이브러리 영역인 것 같음, 내부적으로 이런 코드 제너레이터를 잘 써본 경험 있음

  • OpenMP 지원 기대 중임, 실험적으로 Solvespace 웹 빌드를 돌리고 있고, OpenMP 지원되면 크게 좋아질 것 같음 online solvespace demo, 브라우저에서 돌아가는 오픈소스 CAD임

    • Solvespace 정말 멋진 툴이라고 생각함, 예전에 유튜브 튜토리얼 따라가면서 분할형 키보드 케이스를 설계해서 CNC로 만들기도 했었음, 빠르게 결과를 만들 수 있었음, 유지 관리해줘서 고마움

    • 지금까지 본 WASM 기반 웹 UI 중 최고라고 생각함, 데스크톱 빌드를 Emscripten으로 돌릴 때 가장 어려웠던 점이 뭔지 궁금함

  • 아직 언급된 적 없는 내용이라 남김: multiple-memories 기능이 WebGPU 리소스 매핑 시 중복 복사를 피하는 데 사용될 수 있을지 궁금함, 지금은 ArrayBuffer에 매핑된 게 있어서 WASM에서는 JS 통해 복사해야 하고 성능이 불리함, 여러 WASM 메모리와 Clang/LLVM의 address space 기능이 해결책이 될 것 같지만 실제로 그렇게 간단한지는 잘 모르겠음

    • multi-memory toolchain 지원 논의가 있긴 했으나, LLVM에서 여러 주소공간을 활용한 구현이 실제로 됐는지는 잘 모르겠음

    • 이 모든 게 예전 segmented memory, far-pointers 떠올림, 최근에 Gameboy 게임을 짜보고 있어서 메모리 매핑이 "재미"의 일부이긴 한데, 제약 없는 환경에서 이걸 반복하는 건 좀 싫음, DOS/Win16 시절 far pointers를 묻어버린 데는 그만한 이유가 있었음

답변달기