WebAssembly 모듈 인스펙터

사용법

1. .wasm 파일을 상자에 끌어다 놓거나 상자를 눌러 선택하세요. 파일은 페이지 안에서만 읽히고 업로드되지 않습니다.
2. 섹션 표를 먼저 보세요. 각 섹션의 바이트 크기와 파일에서 차지하는 비율이 나오므로 "이 모듈이 왜 3MB인가"에 대한 답이 됩니다.
3. 임포트 목록은 호스트가 채워야 하는 계약입니다. 모듈 이름, 필드 이름, 종류, 그리고 정확한 시그니처를 확인하세요.
4. 익스포트 목록은 자바스크립트에서 호출할 수 있는 API입니다. 매개변수와 반환 타입은 모듈의 type 섹션에서 그대로 읽어 옵니다.
5. 메모리 패널에서 초기 페이지 수와 최대 페이지 수를 확인하고(한 페이지는 65,536바이트), 커스텀 섹션에서 name이나 producers 섹션이 남아 있는지 살펴보세요.

자주 묻는 질문

.wasm 파일이 왜 이렇게 큰가요?

먼저 섹션 표를 보세요. 일반적인 러스트나 C 빌드에서는 code 섹션이 파일의 70~90%를 차지하며, 이 경우 해답은 코드 자체를 줄이는 것입니다. 제네릭 인스턴스화를 줄이고, 패닉 메시지 포매팅을 빼고, wasm-opt -Oz를 돌리는 식입니다. 하지만 구성이 예상과 다른 경우도 많습니다. Go 빌드는 런타임 정적 데이터가 함께 들어가 data 섹션이 크고, 파일을 내장한 emscripten 빌드는 데이터가 대부분이며, DWARF 디버그 정보를 남긴 빌드는 .debug_info 같은 커스텀 섹션에 그 무게를 담고 있습니다. 마지막 경우는 실행에 전혀 쓰이지 않으므로 wasm-strip으로 지우면 됩니다.

메모리가 "17..∞ 페이지"라고 나오면 무슨 뜻인가요?

WebAssembly 메모리는 65,536바이트짜리 페이지 단위로 셉니다. 초기값 17페이지는 인스턴스화 순간에 약 1.1MB를 잡는다는 뜻입니다. 두 번째 숫자는 선언된 최대값이며, 없으면 호스트가 허용하는 한 계속 늘릴 수 있습니다. 32비트 WebAssembly에서 그 한계는 65,536페이지, 즉 4GiB입니다. 최대값이 적혀 있다고 해서 메모리를 아낀다는 뜻은 아니고, 호스트가 주소 공간을 미리 잡아 둘 수 있는 상한일 뿐입니다. 스레드와 함께 쓰는 공유 메모리는 최대값이 반드시 필요합니다.

임포트와 익스포트 이름이 전부 a, b, c인 이유는 무엇인가요?

최적화와 Closure를 켠 emscripten 빌드의 특징입니다. 임포트와 익스포트 이름은 바이너리 안에 문자열로 들어가므로 짧게 줄이면 파일이 작아지고, 함께 배포되는 자바스크립트 글루도 같은 이름으로 축약됩니다. 런타임에는 아무 문제가 없지만 바이너리만 보면 읽을 수 없습니다. 함수 인덱스를 원래 이름으로 되돌려 주는 name 커스텀 섹션도 같은 단계에서 지워집니다. 남아 있으면 이 도구가 풀어 주고, 없으면 producers 섹션이 누가 만들었는지 알려 주는 마지막 단서인 경우가 많습니다.

env와 wasi_snapshot_preview1을 임포트하던데 무엇을 넣어 줘야 하나요?

임포트 항목은 호스트 객체가 모듈 이름과 필드 이름으로 채워야 하는 자리이며, 엔진이 인스턴스화 시점에 타입까지 검사합니다. env는 emscripten이 자바스크립트에서 받기를 기대하는 C 런타임 콜백을 모아 두는 이름 공간이고, wasi_snapshot_preview1은 WASI를 대상으로 빌드했다는 뜻이라 브라우저에서는 WASI 심이 필요합니다. gojs는 Go 런타임의 다리이며, ./something_bg.js 같은 경로는 wasm-bindgen이 생성한 글루 모듈을 기다린다는 뜻입니다. 하나라도 빠지거나 인자 수가 다르면 WebAssembly.instantiate가 그 이름을 짚어 LinkError를 던집니다.

이 도구가 모듈을 실행하거나 디스어셈블하나요?

둘 다 하지 않습니다. 섹션, 타입, 임포트, 익스포트, 리미트, start 함수 인덱스, 커스텀 섹션 같은 선언만 해석합니다. 함수 본문은 개수와 전체 크기만 재고 명령어는 해독하지 않으며, 엔진을 만들지 않으므로 악성 모듈이라도 여기서는 아무 일도 하지 못합니다. 대신 동작은 보이지 않습니다. 어떤 함수가 무엇을 계산하는지, 어떤 임포트가 실제로 호출되는지, 실행 중 메모리를 얼마나 쓰는지, 타입에 드러나지 않는 SIMD나 원자적 명령이 본문에 있는지는 알 수 없습니다.

코드를 읽지 않는데 참조 타입이나 다중 반환값을 쓴다고 어떻게 말할 수 있나요?

일부 MVP 이후 제안은 명령어뿐 아니라 인코딩 자체의 모양을 바꾸기 때문입니다. 반환값이 둘 이상인 함수 타입은 다중 반환값이고, 시그니처의 externref나 두 번째 테이블은 참조 타입이며, 메모리 리미트 플래그의 세 번째 비트는 스레드에 필요한 공유 비트입니다. data count 섹션이나 액티브가 아닌 패시브 세그먼트는 벌크 메모리에서만 나타나고, 시그니처의 v128은 SIMD입니다. 바이트가 증명하는 것만 표시하며, 함수 본문 안 옵코드로만 등장하는 기능은 아예 주장하지 않습니다. 그래서 이 목록은 실제로 쓰인 기능보다 짧을 수 있습니다.

관련 도구