파일을 업로드하지 않는 브라우저 동영상 압축기를 만든 이야기
2026-05-20
"온라인 동영상 압축"을 검색하면 무료에 깔끔하고 편리해 보이는 서비스가 수십 개 나옵니다. 파일을 끌어다 놓고 30초 기다리면 작아진 버전을 받습니다. 간단합니다.
거의 아무도 말하지 않는 사실: 당신의 동영상은 그들의 서버에 있습니다. 몇 시간 후에 지워질지도 모릅니다. 직원이 보지 않을지도 모릅니다. 백업에 사본이 남지 않을지도 모릅니다. 모릅니다.
저희는 ToolKoala 동영상 압축기 를 만들면서 그 "모릅니다"를 없애려고 했습니다. 동영상 파일은 노트북을 떠나지 않습니다. 저희 서버로도, 그 어떤 서버로도 가지 않습니다. 압축은 전부 브라우저에서, 당신의 CPU 위에서 일어납니다. 이 글은 어떻게 작동하는지, 무엇을 포기해야 하는지, 그리고 직접 검증하는 방법을 설명합니다.
핵심 기술: WebAssembly로 컴파일된 FFmpeg
FFmpeg는 대부분의 전문 동영상 도구 — YouTube의 인제스트 파이프라인부터 좋아하는 Mac 앱까지 — 의 뒷단에서 동작하는 오픈소스 동영상 인코더입니다. 20년 넘게 존재해 왔고, 생각할 수 있는 거의 모든 코덱, 컨테이너, 색 공간을 처리합니다.
몇 년 전, FFmpeg 팀이 프로젝트 전체를 WebAssembly 로 컴파일했습니다 — 어떤 현대 브라우저에서도 거의 네이티브에 가까운 속도로 동작하는 이식 가능한 바이너리 포맷입니다. 그 결과물이 @ffmpeg/ffmpeg — 약 30 MB의 WebAssembly 모듈을 로드해 FFmpeg의 명령줄 인터페이스를 웹 페이지에 노출하는 JavaScript 패키지입니다.
저희 동영상 압축기에 MP4를 드롭하면 이런 일이 일어납니다:
- 브라우저가 FFmpeg WebAssembly 모듈(~30 MB)을 한 번 다운로드합니다. 캐시되므로 다음 방문에서는 건너뜁니다.
- 모듈이 Web Worker — DOM을 만질 수 없는 백그라운드 스레드 — 에 로드됩니다.
writeFile()로 동영상 파일을 worker에 넘깁니다. 인메모리 복사. 네트워크 없음.- Worker가
ffmpeg -i input.mp4 -c:v libx264 -crf 28 output.mp4를 실행해 CPU에서 동영상을 다시 인코딩합니다. - Worker가 압축된 바이트를 돌려줍니다. Blob으로 감싸 다운로드 링크를 만들면 끝.
그 어느 시점에도 동영상이 네트워크로 전송되지 않습니다. 유일한 네트워크 트래픽은 FFmpeg 엔진 자체가 공개 CDN에서 로드되는 것뿐입니다.
직접 검증 — 10초면 됩니다
저희를 믿지 마세요. 브라우저의 DevTools를 믿으세요.
- Chrome이나 Firefox에서 https://www.toolkoala.com/ko/video-compress/ 를 엽니다.
- DevTools를 엽니다 (F12 또는 우클릭 → 검사).
- Network 탭으로 갑니다. 휴지통 아이콘으로 기존 요청을 지웁니다.
- 동영상 파일을 페이지에 드롭합니다.
네트워크 요청이 발생하는 게 보입니다 — 하지만 FFmpeg 엔진 파일(ffmpeg-core.js와 ffmpeg-core.wasm, unpkg.com 출처)뿐입니다. 당신의 동영상 파일은 외부로 0건의 요청을 만듭니다. 0건. 압축 내내 Network 탭을 열어두고 확인할 수 있습니다 — 조용한 상태가 유지됩니다.
이것이 중요한 유일한 종류의 프라이버시 주장입니다: 발행자를 신뢰하지 않고도 10초만에 검증할 수 있는 종류.
왜 모든 온라인 압축기가 이렇게 안 할까?
세 가지 이유.
속도. 서버 측 압축은 전용 하드웨어를 사용합니다 — 보통 GPU나 전용 H.264 ASIC 인코더. 1분짜리 클립을 10초 안에 압축합니다. WebAssembly는 노트북 CPU에서 싱글 스레드로 돌아갑니다. 같은 작업이 저희에게는 1-3분 걸립니다. 대부분의 개인 용도에는 괜찮습니다. 100개 동영상을 배치 처리한다면 아닙니다.
파일 크기. 브라우저 메모리는 유한합니다. 업로드를 1 GB로 제한합니다. 서버 측 도구는 수백 GB를 다룹니다. 4K 아카이브를 압축한다면 데스크톱의 HandBrake를 쓰세요.
엔지니어링 비용. 서버 측은 모든 프레임워크가 가르치는 표준 아키텍처입니다. 브라우저 측은 Web Worker, WebAssembly 메모리 모델, blob URL, 그리고 type: "module"과 type: "classic" worker의 미묘한 차이(저희가 직접 부딪힌 버그입니다 — module worker는 importScripts를 지원하지 않으므로 UMD가 아니라 ESM 빌드의 ffmpeg-core를 로드해야 합니다)에 대한 이해가 필요합니다. 프라이버시가 진짜 제품 요구사항이 아니라면 대부분의 팀이 선택하지 않을 더 짜증나는 길입니다.
무엇을 희생했는가
마케팅보다 정직함이 중요합니다. 서버 측 압축은 할 수 있지만 저희는 할 수 없는 것들:
- GPU 가속.
-hwaccel cuda나-c:v h264_nvenc없음. 순수 CPU. - 하드웨어 가속 H.265/AV1. 브라우저 WebAssembly는 소프트웨어 H.264를 지원합니다. 새 코덱들도 동작하지만 더 느립니다.
- ~1 GB 초과 파일. 브라우저 메모리 제한은 플랫폼에 따라 2-4 GB. ~1 GB 초과 입력에서는 할당이 실패하기 시작합니다.
- 신뢰할 만한 모바일 경험. 휴대폰은 긴 동영상에서 메모리 부족이 나고 크게 느려집니다. 데스크톱을 권장합니다.
그게 중요하다면 HandBrake(데스크톱, 무료, 오픈소스)를 쓰세요.
그래도 만든 이유
설득력 있는 실제 사용 사례 두 가지:
이메일 첨부. 사람들은 Gmail 25 MB 첨부 제한에 끊임없이 부딪힙니다. 60 MB짜리 동영상을 보내기 전에 줄여야 합니다. "이 압축 서비스가 썸네일을 팔지 않을까?" 같은 생각을 하고 싶지 않습니다.
민감한 자료. 보험금 청구, 의료 녹화, 가족의 순간, 작업 중인 초안. 임의의 도메인에 업로드하기 불편한 모든 것. "이 사이트 안전한가?"라는 정신적 부담은, 답이 증명 가능하게 "당신의 파일은 어디에도 가지 않습니다"일 때 사라집니다.
둘 중 하나에 해당한다면 시도해 보세요: ToolKoala 동영상 압축기. 파일 드롭, 품질 선택, 1분 기다림, 다운로드. 가입 없음, 워터마크 없음, 이메일 없음, 업로드 없음.
감사의 말
이것이 가능한 것은 FFmpeg 팀의 20년에 걸친 작업, 이를 브라우저용으로 감싸준 @ffmpeg/ffmpeg 유지보수자들, 그리고 바이트 수준의 이식성을 출시할 수 있을 만큼 지루하게 만든 WebAssembly 명세 작성자들 덕분입니다.
저희는 브라우저 기반 프라이버시 도구 스택 을 만드는 작은 운영 팀입니다. PDF, 이미지, 텍스트, 동영상 — 매번 같은 원칙입니다: 당신의 파일이 소프트웨어를 쓰기 위해 디바이스를 떠날 필요는 없습니다.