Mobile WASM & Bridge Physics

1. Overview

모바일 WASM 및 브릿지 물리(Mobile WASM & Bridge Physics)는 모바일 브라우저와 웹뷰(WebView) 샌드박스 안에서 무거운 3D 그래픽이나 동영상 인코딩 로직을 돌리기 위해, C++나 Rust를 기계어 수준으로 압축한 WebAssembly(WASM)의 실행 역학을 다룹니다.

웹 기술이 발전해도 자바스크립트 엔진(V8, JSC)은 싱글 스레드 텍스트 스크립트 기반이라는 한계 때문에 이미지 처리나 무거운 물리 엔진을 돌릴 때 CPU 병목에 짓눌립니다. 학습자는 이를 타파하기 위해 C/C++나 Rust 코드를 브라우저가 단 1ms 만에 해석할 수 있는 초고속 바이너리 포맷(WASM)으로 컴파일하는 과정을 해부합니다. 또한 모바일 환경의 제한된 메모리 속에서 WASM 선형 메모리(Linear Memory)와 JS 엔진이 서로 포인터를 통해 데이터를 교환하는 브릿지 통신 비용(Overhead)의 물리적 한계를 정밀하게 통제합니다.

2. Scope & Boundaries

In-Scope

• WASM 아키텍처: WebAssembly 바이너리 구조(.wasm), Stack Machine, 브라우저 런타임 인터프리터(AOT/JIT).
• 메모리 물리: WASM 선형 메모리(Linear Memory, ArrayBuffer), JS와 메모리 포인터 교환.
• 언어 컴파일: Rust/C++ $ightarrow$ Emscripten/wasm-pack $ightarrow$ WASM 컴파일 파이프라인.
• 모바일 웹뷰 한계: 하이브리드 앱(Web-to-Native) 브릿지와 WASM 브릿지의 삼중 병목(JS $\leftrightarrow$ WASM $\leftrightarrow$ Native).

Out-of-Scope

• 웹 자바스크립트 코어 렌더링: WASM을 제외한 순수 JS V8/Hermes 엔진의 런타임 물리학 $ightarrow$ 14-01-01. JS Runtime & V8 Engine Mechanics 영역으로 위임.
• 서버사이드 WASM (WASI): 백엔드나 도커(Docker) 컨테이너 대신 WASM을 서버리스로 돌리는 영역 $ightarrow$ 09-02. Cloud Native Physics 영역으로 위임.

Boundaries

• WASM vs React Native JSI (13-03-04 vs 13-03-01): RN JSI(13-03-01)는 JS와 네이티브(OS) C++가 메모리를 통신(브라우저 밖)하는 구조라면, Mobile WASM(13-03-04)은 브라우저 샌드박스 "내부"에서 JS 엔진과 가상 머신(WASM) 런타임이 통신하는 격리망(Browser) 차원의 물리적 차이가 있습니다.

3. Counterexample

• 은탄환의 환상 (WASM Silver Bullet Fallacy): 단순한 문자열 변환이나 작은 JSON 파싱 코드까지 전부 빠르다며 WASM(Rust)으로 짜는 오남용. JS와 WASM 런타임이 데이터를 주고받을 때 컨텍스트 스위칭(Bridge Overhead) 비용이 발생합니다. 가벼운 연산에서는 오히려 순수 JS(JIT 최적화)가 WASM 브릿지 통과 비용보다 3배 이상 빠릅니다. 무거운 배열 연산이나 이미지 처리(픽셀 매트릭스)에만 국한해야 합니다.
• 가비지 컬렉터 맹신 (WASM GC Blindness): 자바스크립트는 안 쓰는 객체를 GC가 지워주지만, 기본적으로 WASM(C/Rust) 안의 선형 메모리 영역에 할당된 100MB 크기의 이미지 배열은 JS의 GC가 건드릴 수 없는 치외법권입니다. 개발자가 WASM 모듈에서 직접 메모리 해제(free) 함수를 호출하지 않으면, 모바일 브라우저의 탭 메모리가 터져서 브라우저가 앱을 강제 종료(OOM)시킵니다.

4. Prerequisites

• 컴파일러와 가상머신 구조 (Basic): 바이너리 코드와 스택 머신(Stack Machine) 구조를 알아야 브라우저가 코드를 해석하는 역학을 알 수 있습니다. (05-03. Compiler Physics)
• 자바스크립트 런타임 (Recommended): JS의 ArrayBuffer와 이벤트 루프 메커니즘을 알아야 WASM과의 메모리 공유 한계를 파악합니다. (14-01-01. JS Runtime)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: WebAssembly 런타임과 바이너리(Binary) 구조

• Why to Learn: 모바일 브라우저에서 무거운 연산을 JS로 돌리면 배터리와 프레임이 무너지므로, 네이티브에 준하는 속도를 내는 탈출구를 뚫기 위함입니다.
• What to Learn: .wasm 바이너리 포맷, Stack Machine 기반 명령어 세트, 디코딩(Decoding) 파이프라인.
• How to Learn: 브라우저가 일반 JS 파일은 텍스트를 읽고 구문 트리를 만들고 JIT를 돌리느라 시간을 버리지만, WASM 바이너리는 넘겨받는 즉시 초고속으로 메모리에 맵핑(Streaming Compilation)되어 실행 준비를 마치는 물리적 시간 단축을 파악합니다.
• Implement: 1부터 10억까지 더하는 루프 연산을 JS 버전과 WASM(Rust/C++) 버전으로 각각 작성하여, 모바일 디바이스 웹뷰에서 실행 시간(Execution Time)이 5배 이상 차이 나는 물리적 벤치마크 테스트 스크립트 구축.

Core Topic 02: 선형 메모리(Linear Memory)와 ArrayBuffer

• Why to Learn: WASM 안에는 JS처럼 자유로운 객체(Object) 개념이 없으며, 오직 거대한 1차원 숫자 배열(도화지)만 존재한다는 물리 법칙을 이해하기 위함입니다.
• What to Learn: Linear Memory, WebAssembly.Memory, 32비트 포인터 할당, JS ArrayBuffer 뷰 인터페이스(Uint8Array).
• How to Learn: WASM이 이미지 픽셀 10,000개를 선형 메모리에 1열로 세워두면, JS 측에서 그 메모리 주소를 Uint8Array 렌즈를 통해 들여다보고 곧바로 브라우저 canvas에 뿌려주는 메모리 공유 복사 방지(Zero-copy) 메커니즘을 뜯어봅니다.
• Implement: JS에서 생성한 거대한 숫자 배열(Float32Array)을 메모리 주소(포인터)만 던져서 WASM 함수로 넘기고, WASM이 각 숫자 배열을 2배로 수정한 뒤 JS가 복사 지연 없이 즉각 변경된 결과를 읽어내는 제로 카피 데이터 패싱 설계.

Recommended

Core Topic 03: JS-WASM 브릿지 비용(Overhead)과 교착 상태

• Why to Learn: 모든 코드를 무조건 WASM으로 갈아타면 오히려 앱 성능이 바닥으로 곤두박질치는 최적화의 함정(오버헤드)을 피하기 위함입니다.
• What to Learn: Context Switching Overhead, Serialization (String/Object 변환), Call 빈도 제어 한계.
• How to Learn: WASM은 숫자(Number)만 이해할 뿐 복잡한 문자열(String)이나 JSON 객체를 던지면 그 문자를 1바이트씩 숫자로 쪼개서 넘기고 복구해야 하므로 브릿지에서 CPU 병목이 발생함을 그래프로 시각화합니다.
• Implement: 초당 60프레임으로 호출되는 렌더링 루프 내부에서 WASM 함수를 가볍게 60번 호출했을 때 발생하는 프레임 드랍 현상을 분석하고, 60번의 데이터를 JS 버퍼에 한 번에 모아서 1번만 호출하는 일괄(Batch) 처리 튜닝 코드 작성.

Core Topic 04: 모바일 하이브리드(WebView) 삼중 병목 역학

• Why to Learn: 모바일 앱 내부에 띄운 웹뷰 안에서 WASM을 돌리고, 다시 그 결과를 안드로이드/iOS 네이티브 OS로 넘기는 과정의 시스템 붕괴를 막기 위함입니다.
• What to Learn: 3-Tier Execution (Native $\leftrightarrow$ JS $\leftrightarrow$ WASM), 모바일 메모리 한계(OOM 킬), 백그라운드 런타임 제약.
• How to Learn: 안드로이드 카메라에서 찍은 이미지(Native) $ightarrow→ 웹뷰 JS(Bridge) → ightarrow→ WASM 필터링 연산 → ightarrow→ 다시 JS → ightarrow$ Native로 저장되는 왕복 4단계의 데이터 직렬화(Serialization) 악몽을 도해로 추적합니다.
• Implement: 네이티브 디바이스 하드웨어 가속 리소스를 WASM이 직접 접근할 수 없는 샌드박스 한계를 극복하기 위해, 영상 인코딩 등 코어 연산만 WASM에 격리하고 UI 렌더링은 네이티브 플랫폼에 위임하는 하이브리드 오프로딩 아키텍처 설계도 작성.

7. Terminology

8. References

Primary References

• [CS2023: Programming Languages / Architecture] — 가상 머신(Virtual Machine) 기반 바이트코드 실행 아키텍처, 런타임 스택 머신 및 샌드박스 격리 기술.
• [SWEBOK v3: Software Construction] — 고성능 컴퓨팅(HPC)의 클라이언트 사이드 오프로딩(Offloading) 및 메모리 매니지먼트.

Secondary References

• [WebAssembly Core Specification (W3C)] — 선형 메모리(WebAssembly.Memory)와 자바스크립트 버퍼 뷰 연동 명세, 바이너리 텍스트 디스코드(WAT).
• [Rust and WebAssembly Book] — wasm-pack 및 wasm-bindgen을 이용한 무비용(Zero-cost) JS 추상화 브릿지 바인딩 전략.

Industry References

• [Mozilla Hacks: Lin Clark’s WebAssembly series] — 인터프리터 텍스트 파싱, JIT(Just-in-Time) 컴파일러 웜업 비용 제거 시각화 다이어그램.
• [Google Web Dev: WebAssembly for Web Developers] — 이미지 처리, 비디오 인코딩 워크로드에서 SIMD(병렬 처리)를 통한 JS 엔진 대비 실행 프레임 최적화.

9. Final Checklist

Primary Checklist

• 모바일 웹뷰(WebView) 환경에서 거대한 배열 연산이나 이미지 픽셀 매트릭스 처리를 할 때, JS 단일 스레드 병목을 회피하기 위해 C++/Rust를 WASM으로 빌드하여 이식했는가?
• 자바스크립트 엔진과 WebAssembly 모듈 사이에 데이터를 주고받을 때, 무거운 JSON이나 문자열 복사를 피하고 선형 메모리(ArrayBuffer) 주소만 넘기는 제로 카피(Zero-copy) 방식을 구축했는가?

Secondary Checklist

• 아주 단순한 덧셈/루프 계산까지 WASM으로 넘길 경우 발생하는 런타임 컨텍스트 스위칭 브릿지 오버헤드(Overhead)를 벤치마크하여, 순수 JS가 나은 임계점을 파악했는가?
• WASM 런타임 내부(선형 메모리)에 할당된 100MB 크기의 임시 버퍼 데이터를 다 쓴 뒤, JS 가비지 컬렉터(GC)에 의존하지 않고 명시적으로 메모리 해제(free)를 호출해 탭 OOM 크래시를 방어했는가?

Industry Checklist

• 네이티브 하드웨어 센서 $ightarrow→ iOS/Android 네이티브 코드 → ightarrow→ 웹뷰(WebView) 브릿지 → ightarrow→ JS 엔진 → ightarrow$ WASM 연산 모듈로 이어지는 4단계 하이브리드 파이프라인에서 중복 직렬화가 일어나지 않게 아키텍처를 압축했는가?
• 모바일 브라우저 환경에서 스트리밍 컴파일(Streaming Compilation, instantiateStreaming)을 적용하여 수 MB 크기의 바이너리 파일을 다운로드와 동시에 메모리에 맵핑(AOT)하여 구동 대기 시간을 단축시켰는가?