Hacker News 2026.04.25 30

브라우저에서 tar 파일을 '진짜 파일시스템'처럼 마운트하기 - WebAssembly의 재미있는 활용

브라우저 안에서 파일시스템을 만든다는 것

Jeroen Ooms라는 개발자가 최근 자신의 블로그에 "WebAssembly에서 tar 아카이브를 파일시스템으로 마운트하기"라는 흥미로운 기술 노트를 올렸어요. 제목만 들으면 "그게 뭐 어쨌다는 거지?" 싶을 수 있는데, 실제로 해보면 굉장히 실용적인 응용이 많아요. 브라우저에서 네이티브 앱처럼 파일을 다루는 방식이 가능해지거든요.

먼저 배경을 짚어볼게요. WebAssembly(이하 WASM)는 브라우저에서 C, C++, Rust, Go 같은 언어로 작성된 코드를 거의 네이티브 속도로 실행할 수 있게 해주는 기술이에요. 문제는 이 네이티브 코드들이 보통 파일을 읽고 쓰는 걸 전제로 한다는 거예요. 예를 들어 R 통계 언어나 Python 인터프리터를 WASM으로 포팅하면, 이 친구들은 내부적으로 표준 라이브러리 파일을 읽어야 동작해요. 브라우저에는 진짜 파일시스템이 없는데 어떻게 해결할까요?

tar 아카이브를 파일시스템으로 쓰는 아이디어

가장 흔한 방법은 Emscripten이 제공하는 MEMFS(메모리 파일시스템)에 필요한 파일을 전부 올려두는 거예요. 하지만 파일이 수천 개씩 있으면 초기화가 느리고 메모리 사용량도 많아져요. 여기서 Jeroen이 제시한 방법이 영리해요. tar 아카이브 파일 하나를 받아서, 그걸 가상 파일시스템처럼 인덱싱해두고 필요할 때만 해당 오프셋에서 데이터를 읽는 거예요.

tar 포맷이 이 용도에 딱 맞는 이유가 있어요. tar는 원래 "Tape Archive"의 약자로, 옛날 테이프 드라이브용으로 설계된 포맷이에요. 각 파일이 512바이트 헤더 + 파일 내용 + 패딩 순서로 단순하게 연결되어 있어서, 처음부터 쭉 스캔하면서 "어떤 파일이 몇 번째 오프셋부터 시작하는지" 인덱스만 만들어두면 되거든요. 압축이 안 되어 있는 대신 이런 랜덤 액세스가 쉽다는 게 장점이에요. ZIP 같은 포맷도 가능하지만 압축 때문에 특정 파일만 빨리 꺼내기가 더 복잡해요.

더 재밌는 건 HTTP Range 요청과 결합할 때예요. HTTP Range 요청이란 "이 파일의 1000번째 바이트부터 2000번째 바이트까지만 보내줘"라고 서버에 부탁할 수 있는 기능이에요. tar 파일을 서버에 통째로 올려두고, 클라이언트는 인덱스만 먼저 받은 다음 실제로 필요한 파일이 있을 때만 해당 범위만 다운로드하는 거예요. 그러면 수 기가바이트짜리 tar 아카이브에서도 실제로는 필요한 몇 메가바이트만 네트워크로 전송되니까 엄청나게 효율적이에요.

실제 구현에서의 고려사항

Jeroen의 접근은 이 아이디어를 Emscripten의 가상 파일시스템 레이어에 연결하는 거예요. Emscripten은 open, read, stat 같은 POSIX 시스템 콜을 자바스크립트 콜백으로 연결할 수 있는 인터페이스를 제공하는데, 여기에 tar 기반 읽기 로직을 연결하면 WASM 안의 네이티브 코드는 "나는 그냥 평범한 파일을 읽고 있어"라고 생각하면서도 실제로는 브라우저가 HTTP Range로 조각조각 가져오는 거죠.

이 방식의 성능 특성을 보면, 최초 접근 시에는 네트워크 왕복 때문에 약간의 지연이 있지만, 한번 가져온 블록은 브라우저 캐시나 메모리에 남아서 두 번째 접근부터는 빠르게 동작해요. 캐시 전략을 어떻게 짜느냐에 따라 체감 성능이 많이 달라져요.

업계에서 비슷한 접근들

이런 "아카이브를 파일시스템처럼 다루기"는 의외로 여러 곳에서 쓰이고 있어요. 게임 업계에서는 Unity의 AssetBundle이나 Unreal의 PAK 파일이 비슷한 역할을 해요. 리눅스에서는 SquashFS라는 읽기 전용 압축 파일시스템이 있어서 임베디드 시스템이나 라이브 USB에 널리 쓰이고요. Docker 이미지도 내부적으로는 레이어별 tar 아카이브예요.

웹 쪽에서는 Pyodide(Python을 WASM으로 포팅한 프로젝트)가 비슷한 기법으로 수백 개의 파이썬 패키지를 효율적으로 로드하고 있어요. WebR(R 언어의 WASM 포팅)도 같은 고민을 하고 있고, Jeroen이 이 글을 쓴 배경에도 WebR 작업이 있어요. zip.js나 ZipFS 같은 라이브러리도 유사한 철학이지만 tar 쪽이 구현 단순성에서 앞서요.

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

당장 실무에 쓸 만한 시나리오를 몇 개 생각해볼게요. 첫째, 브라우저에서 실행되는 교육용 플레이그라운드예요. 학생들에게 Python이나 R을 가르칠 때 설치 없이 브라우저에서 바로 실행되게 만들려면 이런 기법이 필수예요. 국내 코딩 교육 플랫폼들이 참고할 만해요. 둘째, 대용량 정적 에셋을 다루는 웹앱이에요. 예를 들어 지도 타일, 폰트 세트, 머신러닝 모델 가중치 같은 걸 tar로 묶어두고 필요한 조각만 가져오는 방식이 가능해요. 셋째, 오프라인 PWA에서도 초기 다운로드 크기를 줄이는 데 쓸 수 있어요.

당장 프로젝트에 도입하지 않더라도, "파일시스템은 추상화일 뿐이고 그 뒤에 뭐가 있든 상관없다"는 관점을 체감하는 것만으로도 웹 개발의 시야가 넓어져요.