WebAssembly에서 Apple Silicon GPU로 제로카피 추론하기 — 브라우저 AI의 새 지평

왜 이게 의미 있는 소식일까요

최근 브라우저에서 LLM을 돌리는 시도들이 활발해지고 있어요. ONNX Runtime Web, WebLLM, Transformers.js 같은 프로젝트들이 대표적인데, 공통된 고민이 하나 있어요. 바로 WebAssembly(WASM)와 GPU 사이의 데이터 이동 비용이에요. 이번에 공개된 글은 Apple Silicon의 통합 메모리 구조(Unified Memory)를 활용해서 이 비용을 0으로 만드는 접근을 다루고 있어요. 맥 사용자가 많은 한국 개발자 커뮤니티 특성상, 어떤 원리인지 제대로 이해해둘 가치가 있는 주제라 차근차근 풀어볼게요.

제로카피가 뭐고 왜 중요한가

일반적으로 CPU와 GPU는 별도의 메모리를 가져요. NVIDIA 카드를 예로 들면, 시스템 램(예: DDR5)에 있는 데이터를 GPU에서 쓰려면 PCIe 버스를 통해 VRAM으로 복사해야 해요. 이게 뭐냐면, 요리사가 재료를 냉장고에서 꺼내 조리대로 옮기는 시간과 같아요. 작은 파일이면 무시해도 되지만, 수 GB짜리 모델 가중치나 이미지 배치를 매번 복사하면 병목이 생겨요.

Apple Silicon(M1, M2, M3, M4 칩)은 구조가 달라요. CPU, GPU, Neural Engine이 같은 물리 메모리를 공유하거든요. 이걸 유니파이드 메모리라고 하고, 이론적으로는 데이터를 복사할 필요가 없어요. 그냥 같은 주소를 가리키면 되니까요. '제로카피(Zero-Copy)'라는 말은 이걸 실제로 구현했을 때 쓰는 표현이에요.

WASM은 왜 여기에 어려운 상대였나

문제는 WebAssembly가 샌드박스 안에서 자기만의 선형 메모리(linear memory)를 쓴다는 점이에요. 이게 뭐냐면, WASM 모듈은 브라우저나 런타임이 할당해준 고정 크기의 바이트 배열 안에서만 데이터를 다룰 수 있어요. 보안을 위해 외부 메모리에 직접 접근하지 못하게 막혀 있거든요. 그래서 WASM 안에서 만든 텐서를 GPU에 넘기려면, 일반적으로 이런 과정을 거쳐요.

먼저 WASM 선형 메모리에서 호스트(브라우저) 메모리로 복사하고, 그 다음 호스트에서 GPU 버퍼(Metal, WebGPU)로 또 복사해요. 맥북에서 7B 파라미터 모델을 돌린다면 가중치 크기가 4GB쯤 되는데, 이걸 매번 두 번 복사하면 수백 ms가 날아가요. 추론 속도가 생명인 AI 앱에서는 치명적이죠.

어떻게 제로카피를 달성했나

이번에 소개된 접근은 WASM 선형 메모리 자체를 Metal 버퍼와 공유 가능한 영역에 할당하는 방식이에요. 구체적으로는 MTLBuffer를 storageModeShared 모드로 만들어서, 이 버퍼의 포인터를 WASM 모듈이 자기 선형 메모리로 인식하게 해요. 이게 가능하려면 WASM 런타임이 메모리 초기화 시점에 호스트가 제공한 버퍼를 쓸 수 있게 협조해야 하는데, 일부 런타임(Wasmtime, Wasmer)은 커스텀 메모리 프로바이더를 지원해요.

결과적으로 WASM 코드가 텐서를 자기 메모리에 쓰는 순간, Metal 셰이더도 같은 데이터를 즉시 읽을 수 있어요. 복사 단계가 사라지는 거예요. 글에 제시된 벤치마크를 보면 토큰당 레이턴시가 수십 % 줄어들고, 메모리 사용량도 절반 가까이 줄어요(같은 데이터를 두 벌 안 갖고 있으니까요).

추론 파이프라인은 WASM에서 토큰화와 전처리를 하고, 준비된 텐서 포인터를 Metal 컴퓨트 셰이더에 넘겨 행렬 연산을 돌리고, 결과를 다시 같은 메모리에서 WASM이 읽어 후처리해요. 전체 과정이 단일 메모리 공간 위에서 일어나요.

업계 맥락에서의 위치

브라우저 AI 쪽은 지금 크게 세 흐름이에요. 첫째는 WebGPU로, 구글이 밀고 있고 크로스 플랫폼 표준을 지향해요. 둘째는 WebNN으로, W3C에서 표준화 중이고 OS의 네이티브 AI 가속을 브라우저에서 호출할 수 있게 해줘요. 셋째는 WASM SIMD + 멀티스레딩으로 CPU에서 최대한 빠르게 돌리는 접근이에요.

이번 제로카피 접근은 셋 중 하나가 아니라, WASM 런타임과 네이티브 GPU API를 얇은 층에서 직접 연결하는 엣지 최적화에 가까워요. 브라우저 밖의 네이티브 런타임(Tauri, Electron 앱에 Wasmtime을 끼워 쓰는 식)에서 현실적으로 활용하기 좋고, 순수 브라우저에서는 샌드박스 제약 때문에 그대로 적용하기 어려워요. Apple이 사파리의 WebGPU/WebAssembly를 어떻게 열어주느냐에 따라 가능성이 갈려요.

한국 개발자에게 주는 시사점

맥북으로 개발하는 분들이 많고, 로컬에서 LLM이나 Stable Diffusion을 돌려본 경험 있는 분들도 많죠. Ollama, LM Studio, MLX 같은 도구들이 빠르게 퍼지는 이유도 Apple Silicon의 유니파이드 메모리가 워낙 AI에 적합해서예요. 이번 기술은 온디바이스 AI 앱을 만들 때 '성능은 네이티브급, 배포는 웹 기반'이라는 두 마리 토끼를 잡을 길을 보여줘요.

당장 실무에 바로 쓰기는 어려워요. 아직 런타임 지원도 제한적이고 런칭된 라이브러리도 적어요. 다만 사내 툴, 엔터프라이즈 AI 보조기, 맥 전용 크리에이티브 앱 같은 영역에서는 6개월 ~ 1년 내 실제 도입 사례가 나올 것 같아요. 특히 사용자 데이터를 서버로 보내지 않고 로컬에서 처리해야 하는 요구(의료, 법률, 금융)가 있는 분야에 매력적이에요.

기술적으로 배워둘 가치는 확실히 있어요. WASM 런타임의 커스텀 메모리 훅, Metal의 storage mode, WebGPU의 mappedAtCreation 같은 저수준 개념을 한 번 정리해두면 앞으로 나올 유사 프로젝트를 빠르게 이해할 수 있어요.

마무리

한 줄 정리하면 Apple Silicon의 유니파이드 메모리 위에서 WASM과 GPU가 같은 버퍼를 공유하게 만들어, 추론의 메모리 복사 비용을 없앤 접근이에요. 여러분은 로컬 AI 추론에서 가장 큰 병목이 뭐라고 느끼시나요? 모델 크기, 메모리, 배터리 중 어떤 축을 우선 최적화해야 한다고 보시는지 의견이 궁금해요.