WebAssembly란?
WebAssembly(Wasm)는 C, C++, Rust 같은 언어를 컴파일해 어디서나 실행할 수 있도록 설계된 바이너리 명령어 형식입니다. 웹 브라우저에서 코드를 네이티브에 가까운 속도로 돌릴 수 있게 해 줍니다. 2019년 W3C 권고안이 되었고, 현재 Chrome, Firefox, Safari, Edge 등 모든 주요 브라우저가 지원합니다.
파일 처리 관점에서 보면, PDF 편집, 이미지 압축, OCR 문자 인식처럼 무거운 작업을 서버가 아닌 브라우저 안에서 끝낼 수 있다는 뜻입니다. Photopea나 Figma 같은 웹 앱도 WebAssembly를 활용합니다. Allin PDF의 로컬 도구 역시 같은 브라우저 기술을 기반으로 합니다. JavaScript와 WebAssembly 라이브러리를 Web Worker에서 실행하기 때문에, 파일을 내 기기에서 처리하는 동안에도 화면이 멈추지 않습니다.
pdf-lib, PDF.js, Tesseract.js는 브라우저에서 어떻게 파일을 처리할까
Allin PDF의 로컬 도구는 세 가지 오픈소스 라이브러리로 만들어졌습니다. 모두가 WebAssembly는 아니지만, 모두 내 기기에서 실행됩니다.
pdf-lib — 브라우저 안에서 PDF 편집
pdf-lib는 PDF 문서를 클라이언트에서 직접 만들고 수정하는 JavaScript(TypeScript) 라이브러리입니다. 페이지 합치기, 분할, 순서 변경, 텍스트 삽입, 이미지 삽입을 서버 호출 없이 처리합니다. pdf-lib 자체는 WebAssembly가 아닌 순수 JavaScript입니다. 최신 JavaScript 엔진이 이를 빠른 기계어로 컴파일하고, Web Worker에서 실행하면 큰 작업을 하더라도 페이지가 멈추지 않습니다.
PDF.js — PDF 페이지 렌더링
PDF.js는 Firefox에 내장된 Mozilla의 PDF 엔진입니다. PDF 페이지를 분석하고 화면에 그려 주기 때문에 PDF를 이미지로 변환하는 도구에 쓰입니다. 대부분 JavaScript로 작성되었고, 최근 버전에서는 일부 이미지 디코더에 WebAssembly를 사용합니다.
Tesseract.js — 서버 없이 OCR
Tesseract.js는 Tesseract OCR 엔진을 WebAssembly로 옮긴 버전입니다. 엔진 자체는 다양한 언어를 학습시킬 수 있지만, Allin PDF의 무료 OCR은 영어, 중국어 간체, 중국어 번체, 일본어, 한국어 다섯 가지 언어를 제공합니다. 언어 데이터는 처음 사용할 때 다운로드되며, 이후 인식 작업은 이미지나 PDF를 업로드하지 않고 브라우저 탭 안에서 진행됩니다.
성능: WebAssembly vs 네이티브 앱
브라우저에서 처리하면 데스크톱 프로그램보다 느릴까요? 일상적인 PDF 작업이라면 차이를 거의 느끼지 못할 만큼 빠른 경우가 대부분입니다. 실제 속도는 기기, 브라우저, 파일에 따라 달라집니다. 아래 표는 Allin PDF에서 각 작업을 무엇이 처리하는지, 속도에 영향을 주는 요소가 무엇인지 정리한 것입니다.
| 작업 | 처리 담당 | 실행 위치 | 속도에 영향을 주는 요소 |
|---|---|---|---|
| PDF 압축 | pdf-lib + 이미지 재인코딩 | 내 브라우저 | 이미지 개수와 크기, 압축 단계 |
| PDF 합치기(2~20개) | pdf-lib(페이지를 그대로 복사) | 내 브라우저 | 전체 파일 크기와 페이지 수 |
| 페이지 OCR | Tesseract.js(WebAssembly) | 내 브라우저 | 이미지 해상도, CPU 성능, 첫 사용 시 언어 데이터 다운로드 |
| PDF 암호 설정(AES-256) | 브라우저 내 PDF 암호화 | 내 브라우저 | 파일 크기 |
| PDF를 이미지로 렌더링 | PDF.js | 내 브라우저 | 페이지 수, 출력 해상도 |
일반적으로 WebAssembly는 같은 코드를 네이티브로 컴파일했을 때보다 조금 느리지만, 브라우저 엔진의 Wasm 컴파일러가 개선되면서 그 차이는 계속 줄고 있습니다. 보통의 PDF라면 파일 크기, 이미지 비중, 기기 메모리가 속도에 더 큰 영향을 줍니다.
보안 모델: 샌드박스 실행이 중요한 이유
WebAssembly는 샌드박스 실행 모델을 통해 강력한 보안을 제공합니다.
- 메모리 격리: Wasm 코드는 브라우저의 다른 영역과 분리된 자체 선형 메모리에서 동작합니다. 다른 탭, 쿠키, 시스템 리소스에 접근할 수 없습니다.
- 시스템 직접 접근 불가: Wasm은 스스로 파일 시스템을 읽거나 네트워크에 접속하거나 OS API를 호출할 수 없습니다. 페이지의 JavaScript가 명시적으로 넘겨준 데이터만 사용할 수 있습니다.
- 동일 출처 정책: Wasm 모듈은 JavaScript와 같은 보안 제약을 따르므로, CORS 헤더 없이는 다른 출처의 데이터에 접근할 수 없습니다.
- 실행 전 검증: 모든 Wasm 바이너리는 실행 전에 검증됩니다. 잘못된 코드는 차단되고, 네이티브 프로그램에서 흔한 메모리 오류 상당수가 예방됩니다.
브라우저 기반 도구의 미래
WebAssembly는 계속 발전하고 있으며, 최근 도입되었거나 준비 중인 기능들이 네이티브 앱과의 격차를 더 줄여 줍니다.
- WASI(WebAssembly System Interface): 파일 입출력과 네트워크를 위한 표준 시스템 인터페이스로, 주로 브라우저 밖에서 Wasm을 실행할 때 쓰입니다
- 스레드와 SIMD: 멀티스레드 Wasm과 SIMD 명령어로 큰 파일의 병렬 처리가 빨라집니다
- 가비지 컬렉션: 내장 GC 지원으로 Java, Kotlin, Dart 같은 언어를 Wasm으로 효율적으로 컴파일할 수 있습니다
- 컴포넌트 모델: 서로 다른 언어로 만든 Wasm 모듈을 하나의 애플리케이션으로 조합할 수 있습니다
흐름은 분명합니다. 데스크톱급 애플리케이션이 점점 더 브라우저로 옮겨 오고 있습니다. PDF, 문서, 이미지처럼 개인정보가 담긴 파일을 다룰 때, 로컬 브라우저 도구는 속도와 개인정보 보호, 편리함을 함께 챙길 수 있는 선택지입니다.
자주 묻는 질문
모바일 브라우저에서도 WebAssembly가 동작하나요?
네. Android용 Chrome, iOS의 Safari, Android용 Firefox 모두 WebAssembly를 지원합니다. 모바일 기기는 데스크톱보다 CPU 성능과 메모리가 적어 큰 파일은 시간이 더 걸리지만, PDF 압축이나 합치기 같은 일반 작업은 요즘 스마트폰에서 무리 없이 처리됩니다.
WebAssembly가 허락 없이 내 파일에 접근할 수 있나요?
아니요. WebAssembly는 파일 시스템에 직접 접근할 수 없습니다. 파일 선택 창이나 드래그 앤 드롭으로 사용자가 직접 파일을 골라야 합니다. Wasm 코드는 사용자가 넘겨준 데이터만 처리할 수 있으며, 기기에 있는 다른 파일을 검색하거나 읽을 수 없습니다.
WebAssembly가 JavaScript를 대체하나요?
아니요. WebAssembly는 JavaScript를 보완합니다. UI 상호작용, DOM 조작, 앱 로직에는 여전히 JS가 적합합니다. Wasm은 압축, 파싱, OCR처럼 네이티브에 가까운 속도가 필요한 계산 작업을 맡습니다. 대부분의 최신 웹 앱은 두 가지를 함께 사용합니다.