ToolBox Image — 완전히 브라우저에서 작동하는 ToolBox Image를 만든 이유

대부분의 무료 온라인 이미지 도구는 같은 방식으로 작동합니다: 파일을 서버에 업로드하고, 서버가 처리한 다음, 결과를 다운로드합니다. 이 모델은 구축하기 간단하지만 숨겨진 비용이 따릅니다——사용자의 프라이버시, 서버 비용, 파일 크기 및 처리량 제한이 그것입니다.

ToolBox Image는 다른 접근 방식을 취합니다. 전체 애플리케이션——디코딩, 인코딩, 압축, 크기 조정, 형식 변환——이 브라우저 안에서 실행됩니다. 업로드할 서버가 없습니다. 이미지가 기기를 떠나지 않습니다. 이 아키텍처는 의도적인 선택이었으며, 제품에 대한 모든 결정을 형성했습니다.

왜 브라우저 우선 접근법인가?

명백한 대안은 전통적인 서버 측 아키텍처입니다. 이미지를 업로드하면 서버가 ImageMagick이나 Sharp 같은 도구로 처리하고 결과를 반환합니다. 이는 작동하지만, 해결하기 어려운 문제들을 만듭니다:

• 프라이버시. 사용자는 귀하가 이미지를 저장, 분석 또는 유출하지 않을 것이라고 신뢰해야 합니다. 민감한 문서——의료 이미지, 디자인 목업, 개인 사진——의 경우 그 신뢰를 얻기 어렵습니다.
• 비용. 모든 압축은 귀하의 인프라에서 실행됩니다. 더 성공할수록 더 많이 지불합니다. 이는 파일 크기를 제한하거나, 대기열을 추가하거나, 유료 등급을 도입하는 압력을 만듭니다.
• 지연 시간. 느린 연결로 100MB 파일을 업로드하는 데는 처리가 시작되기 전에 몇 분이 걸립니다. 연결 상태가 좋지 않은 지역의 사용자에게는 도구가 사실상 사용 불가능합니다.
• 확장성. 단일 서버는 수십 개의 동시 압축을 처리할 수 있습니다. 하지만 수천 개는? 자동 확장 그룹, 로드 밸런서, CDN 업로드 엔드포인트가 필요합니다——이 모든 것이 복잡성과 비용을 증가시킵니다.

브라우저 우선 모델은 이 모든 것을 한 번에 해결합니다. 처리는 무료(사용자의 CPU 사이클)이고, 프라이빗(데이터가 기기를 떠나지 않음)하며, 무한히 확장 가능(각 사용자가 자신의 하드웨어를 사용)합니다.

작동 방식: WebAssembly와 Web Workers

10년 전에는 브라우저에서 이미지 코덱을 실행하는 것이 불가능했습니다. 오늘날 WebAssembly를 사용하면 C 및 Rust 라이브러리를 브라우저가 네이티브에 가까운 속도로 실행할 수 있는 형식으로 직접 컴파일할 수 있습니다. Mozilla의 mozJPEG, Google의 libwebp, libaom AVIF 인코더——모두 C로 작성됨——를 WebAssembly로 컴파일합니다. 브라우저는 네이티브로 설치된 것처럼 효율적으로 실행합니다.

하지만 단일 스레드 인코딩은 대규모 배치에 느립니다. 여기에 Web Workers가 등장합니다. 각 worker는 별도의 CPU 코어에서 실행되며, 기기가 가진 코어 수만큼 worker를 생성합니다. 8코어 최신 노트북에서는 8개의 이미지가 동시에 압축됩니다. 단일 스레드에서 몇 분이 걸리던 200장의 사진 배치가 몇 초 만에 완료됩니다.

포기한 것들

브라우저 우선 접근법이 공짜는 아닙니다. 가장 중요한 트레이드오프는 메모리입니다. 브라우저 탭은 기기의 RAM에 접근할 수 있지만, 이미지가 사용 가능한 메모리를 초과하여 탭이 충돌하는 것은 좋지 않은 경험입니다. 안전한 범위를 유지하기 위해 개별 파일을 100MB, 배치 크기를 200개 파일로 제한합니다.

또한 영구 저장소, 이메일 전송, 분석과 같은 서버 측 기능도 포기했습니다. 압축된 이미지 데이터베이스, 이메일 뉴스레터, 사용자가 선호하는 형식 추적이 없습니다. 이는 프라이버시에 대한 우리의 입장과 철학적으로 일치하지만, "최근 압축"이나 "세션 간 저장된 프리셋"과 같은 기능을 제공할 수 없음을 의미합니다.

향후 계획

브라우저는 성능에 민감한 애플리케이션을 위한 합법적인 런타임이 되고 있습니다. WebAssembly가 가비지 컬렉션, 스레딩, SIMD 지원을 갖추게 되면서, 애플리케이션 스택의 더 많은 부분이 클라이언트 측으로 이동할 수 있습니다. 더 빠른 픽셀 처리를 위해 WebGPU, 매끄러운 폴더 통합을 위해 File System Access API를 탐색하고 있습니다.

현재 압축기는 라이브 상태이며 매일 수천 개의 이미지를 처리하고 있습니다——모두 제자리에 머물러 있습니다.