Firefox in WebAssembly는 Firefox의 화면만 재현한 웹 앱이 아니다. 렌더링 엔진 Gecko와 자바스크립트 엔진 SpiderMonkey를 포함한 Firefox 전체를 WebAssembly로 컴파일해 다른 브라우저의 탭 안에서 실행하는 프로젝트다.1
Firefox의 화면은 브라우저의 HTML canvas 전체에 렌더링된다. 이 구조는 복잡한 데스크톱 소프트웨어도 별도의 설치 파일 없이 웹 링크로 배포할 수 있다는 가능성을 보여준다.
대형 데스크톱 프로그램을 웹 실행 환경으로 옮기다
Firefox의 C·C++ 코드를 WebAssembly로 변환하는 데는 Emscripten이 사용됐다. Firefox가 이식 대상으로 선택된 주요 이유는 Gecko가 단일 프로세스 실행을 비교적 잘 지원하기 때문이다.2
이 환경에서는 SpiderMonkey도 작동하며, WebGL 기반 GPU 가속과 실험적인 자바스크립트→WASM JIT도 제공된다. 다만 JIT는 아직 여러 사이트에서 제대로 작동하지 않는다.3 따라서 현재 결과물은 일상적으로 사용할 브라우저라기보다 WebAssembly가 대규모 네이티브 소프트웨어를 어디까지 수용할 수 있는지 보여주는 실험에 가깝다.
개발에는 약 2만5천 달러 상당의 Claude Opus와 Fable 토큰이 사용됐다.2 이는 대형 코드베이스를 WebAssembly로 이식하는 과정에서 AI 도구가 상당한 규모로 활용된 사례이기도 하다.
실행 방식만큼 중요한 네트워크 구조
브라우저에서 실행되는 코드는 임의의 TCP·UDP 연결을 직접 열 수 없다. 이를 해결하기 위해 데모의 모든 트래픽은 Wisp 프로토콜을 사용하는 WebSocket을 통해 Puter 서버로 전달된다.1 Wisp는 여러 TCP·UDP 연결을 하나의 WebSocket으로 다중화하는 프로토콜이다.
HTTPS의 TLS 암호화는 중계 서버가 아니라 WebAssembly판 Firefox 내부에서 처리된다. 반면 외부 웹사이트에는 사용자의 IP가 아닌 Wisp 중계 서버의 IP가 표시된다.1
따라서 실무 도입 시에는 단순히 “HTTPS를 지원하는가”만 확인해서는 부족하다. 중계 서버의 운영 주체와 장애 가능성, 접속 정보 처리 정책, 네트워크 지연까지 함께 검토해야 한다.
데모를 넘어 살펴볼 기준
이 프로젝트의 의미는 Firefox를 다른 브라우저 안에서 실행했다는 장면 자체보다 크다. 기존 데스크톱 소프트웨어를 처음부터 웹 앱으로 다시 만들지 않고도 브라우저를 배포 경로로 활용할 가능성을 보여주기 때문이다.
비슷한 시도로 WebKit을 WASM으로 컴파일하는 theogbob/WebkitWasm도 있지만, 현재 공개 온라인 데모는 제공되지 않는다. Firefox in WebAssembly는 실제 실행 가능한 형태를 통해 이 접근법의 가능성과 제약을 함께 드러낸다는 점에서 의미가 있다.
실무 적용 가능성을 판단할 때는 다음 항목을 우선 확인해야 한다.
초기 다운로드 크기와 시작 속도
메모리 사용량과 장시간 실행 안정성
입력 장치·폰트·그래픽 호환성
JIT를 포함한 자바스크립트 실행 성능
Wisp 중계 서버의 보안·신뢰성·지연 시간
WebAssembly는 설치 장벽을 낮추고 기존 소프트웨어의 배포 범위를 넓힐 수 있다. 그러나 성능, 호환성, 네트워크 신뢰 문제까지 자동으로 해결해 주지는 않는다. Firefox in WebAssembly의 핵심 가치는 완성된 브라우저 제품이 아니라, 대형 네이티브 애플리케이션을 웹으로 옮길 때 무엇이 가능하고 어떤 비용과 제약을 검토해야 하는지 구체적으로 보여준 데 있다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.