WebAssembly가 로그인 없는 무료 브라우저 도구를 가능하게 하는 방법

Squoosh가 데스크톱 앱과 경쟁하는 코덱으로 이미지를 압축할 수 있는 이유가 있습니다 — 서버 성능과는 아무 관계가 없습니다. 압축은 WebAssembly라는 기술을 사용해 완전히 브라우저 탭 안에서 일어납니다. 업로드 불필요, 계정 불필요, 원격 서버가 파일을 처리하고 돌려보내길 기다릴 필요 없음.

이것은 “무료 브라우저 도구”의 의미를 바꿉니다. 많은 도구에서요.

WebAssembly가 실제로 무엇인지

WebAssembly(줄여서 Wasm)는 JavaScript가 달성할 수 있는 것보다 훨씬 네이티브 코드에 가까운 속도로 브라우저에서 실행되는 이진 명령어 형식입니다. WebAssembly 명세는 2019년 12월에 W3C 표준이 되었지만 브라우저 지원은 더 일찍 도착했습니다. Chrome 57, Firefox 52, Safari 11, Edge 16 모두 2017년에 Wasm 지원을 선보였습니다.

핵심 이해: Wasm은 프로그래밍 언어가 아닙니다. 컴파일 대상입니다. C, C++, Rust, 또는 Go로 코드를 작성하고 .wasm 바이너리로 컴파일해서 브라우저로 전송합니다. 브라우저는 JavaScript를 해석하거나 서버에 연결하지 않고 직접 실행합니다.

성능 차이는 실재합니다. 벤치마크는 지속적으로 Wasm이 동등한 네이티브 코드보다 10-20% 느리게 실행됨을 보여줍니다 — 동등한 네이티브 코드와 비교하면 큰 것 같지만, 특정 작업이 네이티브보다 5-10배 느린 JavaScript와 비교하면 달라집니다. 계산 집약적인 작업(이미지 인코딩, 오디오 처리, 암호화, 데이터베이스 쿼리)에서 Wasm은 브라우저가 할 수 있는 것과 데스크톱 앱이 할 수 있는 것 사이의 간격을 줄입니다.

2022년 WebAssembly SIMD(Single Instruction, Multiple Data) 명령어의 도입은 그 간격을 더 좁혔습니다. SIMD는 Wasm이 병렬 데이터 처리를 위해 CPU 벡터 연산을 사용할 수 있게 합니다 — 데스크톱 이미지 도구를 빠르게 만드는 동일한 최적화입니다. Squoosh 같은 도구는 브라우저가 지원할 때 SIMD를 사용하고 지원하지 않을 때는 부드럽게 대체합니다.

이것이 회원가입이 필요 없는 도구에 왜 중요한지

여기에 업계가 명시적으로 이름 붙이는 데 시간이 걸렸던 연결이 있습니다. 서버 측 처리가 사용자 계정을 요구하는 주요 이유 중 하나입니다.

도구가 서버에서 파일을 처리할 때 서비스는 무엇이 누구의 것인지 추적해야 합니다. 세션 관리, 파일 저장, 작업 큐 — 이 모든 것이 신원을 필요로 합니다. 그리고 신원은 계정, 이메일, 비밀번호를 의미합니다.

계산이 브라우저로 이동하면 그 의존성이 사라집니다. 파일이 내 기기를 떠나지 않습니다. 추적할 작업도, 사용량에 비례한 서버 비용도, 요청을 어떤 신원과 연결할 필요도 없습니다.

“브라우저가 OS다”는 실리콘밸리의 진부한 표현이었습니다. WebAssembly와 함께 이것은 브라우저가 실제로 계산할 수 있는 것에 대한 글자 그대로의 진술이 되고 있습니다.

Wasm 기반 도구들은 진정한 로그인 없음, 회원가입 없음, 등록 없음 경험을 제공할 수 있습니다. 왜냐하면 실제로 여러분이 누구인지 알 필요가 없기 때문입니다. 계산은 내 하드웨어에서, 내 브라우저에서, 내 CPU가 작업을 수행합니다. 개발자의 서버는 정적 파일을 제공합니다. 그게 전부입니다.

이미 이를 사용 중인 도구들 — 광고하지 않고

아래 대부분의 도구들은 홈페이지에 “WebAssembly 기반”을 어디에도 언급하지 않습니다. DevTools의 네트워크 탭을 보면서만 알 수 있을 것입니다 — .wasm 파일이 단서입니다. 하지만 각각을 이해할 가치가 있습니다. 각각이 서버에서 브라우저로 이동한 다른 작업 카테고리를 보여주기 때문입니다.

**Squoosh**는 가장 눈에 띄는 사례입니다. Google이 Wasm이 이미지 압축에 무엇을 할 수 있는지 보여주기 위해 특별히 만들었습니다. 열고 이미지를 드롭하면 MozJPEG, OxiPNG, WebP, AVIF, 또는 JPEG XL로 인코딩할 수 있습니다 — 모두 로컬에서 실행됩니다. Wasm으로 컴파일된 C/C++ 라이브러리가 탭에서 실행됩니다. 데스크톱 사진 앱이 사용하는 동일한 코덱입니다. 내보내기 플러그인이 있는 GIMP를 사용한 비슷한 설정은 전체 설치와 설정이 필요합니다. Squoosh는 아무것도 필요 없습니다.

**hat.sh**는 WebAssembly로 컴파일된 잘 감사된 암호화 C 라이브러리인 libsodium을 사용해 파일을 암호화하고 복호화합니다. 파일은 서버에 절대 닿지 않습니다. hat.sh로 무언가를 암호화할 때 작업은 브라우저 탭의 메모리에서 일어나며, 암호화된 출력만 디스크에 닿습니다. 이것이 암호화 도구의 올바른 아키텍처입니다. 암호화하기 위해 암호화되지 않은 파일을 원격 서버로 보내는 것은 거꾸로 하는 것입니다.

**AudioMass**는 계정이나 설치 없이 멀티트랙 편집을 처리하는 완전한 파형 오디오 편집기입니다. 오디오 조작은 진정으로 계산 집약적입니다 — 필터링, 피치 변경, 형식 변환 모두 실제 처리가 필요합니다. 이것이 브라우저 탭에서 충분히 실행된다는 사실은 Wasm 가능 성능의 직접적인 결과입니다. 몇 년 전에는 “온라인 오디오 편집기”가 파일을 업로드하고 기다리는 것을 의미했습니다. 이제는 로컬에서 처리하는 것을 의미합니다.

**Datasette Lite**는 이보다 더 나아갑니다. 완전한 SQLite 데이터베이스 엔진을 — WebAssembly로 컴파일해서 — 브라우저 안에서 실행합니다. CSV나 SQLite 파일을 로드하고 서버에 아무것도 닿지 않고 실제 SQL 쿼리를 실행할 수 있습니다. 이것은 데스크톱 데이터베이스 클라이언트나 계정이 있는 클라우드 데이터베이스 서비스를 필요로 했습니다. 이제는 브라우저 탭입니다.

비교할 가치가 있는 대조

이 도구들 전반의 패턴이 일관됩니다:

서버 측 처리는 계정을 요구할 이유를 만듭니다. 브라우저 측 Wasm 처리는 그 이유를 제거합니다. 위 표는 완전한 목록이 아닙니다 — 방향입니다.

간과되는 개인정보 측면

Wasm 기반 도구들이 순수 JavaScript 도구들이 종종 갖지 않는 특정 개인정보 속성이 있습니다. 무거운 계산이 샌드박스 환경에서 일어나며, 네트워크 경계를 가로지르는 부작용이 없습니다.

WebAssembly에 관한 MDN Web Docs는 보안 모델을 명확히 설명합니다. Wasm 모듈은 JavaScript와 동일한 샌드박스에서 실행되며, 추가 권한이 없습니다. 독립적으로 네트워크 요청을 할 수 없고, 임의의 파일을 읽을 수 없으며, 명시적인 JavaScript 상호 운용 없이 하드웨어에 접근할 수 없습니다.

개인정보에 민감한 도구 사용자에게 이것이 중요합니다. hat.sh가 파일을 암호화할 때 Wasm 모듈은 물리적으로 그 파일을 네트워크로 전송할 수 없습니다. 모듈 자체는 네트워크 접근이 없습니다. JavaScript가 명시적으로 업로드해야 합니다. 오픈소스 도구는 이것이 일어나지 않는지 감사할 수 있습니다. 소스가 이용 가능하기 때문입니다.

“서버에서 모든 것을 처리하고 로그를 유지하지 않습니다”가 그냥 정책 진술인 도구들과 비교하면 — 데이터에 사업적 이해관계가 있는 회사의 약속을 믿는 것 — 다릅니다.

CyberChef — 인코딩, 디코딩, 암호화 작업을 위한 GCHQ가 만든 브라우저 도구 — 는 오늘날 이것이 어디에 있는지에 대한 유용한 예입니다. 서버 관여 없이 수백 가지 작업(base64, AES, SHA 해시, 이진 파싱, 데이터 형식 변환)을 처리합니다. 이것들이 바로 이전에 계정 시스템이 부착된 전용 백엔드 인프라 운영을 정당화했던 작업들입니다.

회원가입 없음. 등록 없음. 업로드 없음.

Wasm이 아직 할 수 없는 것들

WebAssembly에는 실제 한계가 있습니다. DOM에 직접 접근이 없습니다 — Wasm과 JavaScript는 여전히 브리지를 통해 통신하며, UI 집약적인 작업에 오버헤드가 추가됩니다. 파일 시스템 접근은 브라우저의 File System Access API가 허용하는 것으로 제한되어, 로컬 파일 읽기와 쓰기는 작동하지만 임의의 시스템 수준 작업은 안 됩니다. 그리고 진정으로 대규모 작업(큰 데이터셋으로 ML 모델 훈련, 수백 기가바이트의 데이터 처리)의 경우 클라이언트 측 계산은 여전히 실용적인 메모리 한계에 부딪힙니다.

Wasm은 역사적으로 가비지 컬렉션이 내장되어 있지 않았습니다 — 하지만 2023년에 4단계에 도달한 WebAssembly GC 제안이 Kotlin과 OCaml 같은 언어에 대해 이를 바꿉니다. 스레딩 지원이 있지만(WebAssembly Threads) 모든 호스팅 설정이 제공하지 않는 특정 HTTP 응답 헤더(COOP와 COEP)가 필요합니다.

이 한계들은 실재하지만 줄어들고 있습니다. Wasm 도구 체인은 2년 전보다 더 성숙했습니다 — C/C++를 위한 Emscripten, Rust를 위한 wasm-pack, Go를 위한 TinyGo 모두 활발한 커뮤니티와 좋은 문서를 가지고 있습니다. “브라우저에 너무 계산 집약적”에 해당하는 것이 계속 바뀌고 있습니다.

로그인 불필요 도구 카테고리에 실제로 일어나는 일

Photopea는 계정 없이 PSD, XCF, Sketch 파일을 처리합니다. 그런 파싱 — 복잡한 이진 파일 형식 읽기, 레이어 합성 처리, 색상 공간 관리 — 은 역사적으로 파일을 서버를 통해 라우팅해야 할 이유였습니다. 이제 브라우저 탭에서 실행됩니다. Photoshop 구독과 Adobe 계정이 필요한 웹 앱과 달리, Photopea는 즉시 로드되고, 무료이며, 등록이 없습니다.

제약은 이랬습니다. 브라우저 도구가 실제 컴퓨팅 성능이 필요하면 서버에 전화해야 했습니다. Wasm이 그 제약을 깨뜨렸습니다. 제약이 깨지면 더 넓은 도구 집합에 대해 “이것을 사용하려면 계정이 필요합니다”의 정당성이 약해집니다.

이것이 모든 도구가 로그인 불필요 무료 브라우저 도구가 될 것임을 의미하지는 않습니다. 일부 애플리케이션은 진정으로 지속적인 서버 상태가 필요합니다 — 실시간 협업, 기기 간 클라우드 동기화, 또는 GPU 클러스터가 필요한 대규모 AI 추론. 그런 필요는 실재합니다. 하지만 바닥이 올라가고 있습니다. 브라우저 탭에서 무료로, 등록 없이 잘 수행할 수 있는 작업의 카테고리는 2020년보다 더 넓습니다.

개인정보를 중요하게 생각하는 사용자들에게 — 특히 전 세계 의회에서 데이터 수집에 관한 입법 전투가 진행되면서 — 이것은 올바른 방향입니다. 계산이 기기에서 일어나기 때문에 데이터를 수집할 수 없는 도구들은 그러지 않겠다고 약속하는 도구들과 의미 있게 다릅니다.

실용적인 결론: 계정을 요구하는 도구와 계정 없는 브라우저 기반 대안 사이에서 선택한다면, 브라우저 기반 옵션이 5년 전보다 기능에서 타협일 가능성이 낮습니다. 많은 카테고리에서 더 나은 도구입니다. Wasm이 주요 이유입니다.

회원가입 없는 무료 브라우저 도구들이 더 많이 오고 있습니다. 기반 기술은 계속 빨라지고 있으며, 개발자 도구는 계속 사용하기 쉬워지고 있습니다.

계정 없이 작동하는 도구들, 로그인 불필요, nologin.tools에서 찾아보세요.