oCompress의 작동 원리
파일을 놓으면 무슨 일이 일어나는지, 아무것도 업로드되지 않는다는 것을 어떻게 확인하는지, 무손실 압축과 손실 압축이 실제로 무엇을 뜻하는지 알아보세요.
간단히 말하면
도구 페이지를 열면 브라우저는 페이지와 작은 프로그램인 압축기를 내려받습니다. 파일을 추가하면 브라우저가 파일을 읽고, 압축기가 사용자의 프로세서에서 이를 처리하며, 결과는 다운로드 형태로 돌려드립니다. 어느 단계에서도 파일은 네트워크로 전송되지 않습니다. 전체 과정은 다음과 같습니다.
- 불러오기. 페이지와 도구 화면이 먼저 로드됩니다. 파일 형식별 엔진(이미지, 동영상·오디오, 문서)은 해당하는 파일을 추가할 때만 가져오므로, 쓰지 않는 코드를 내려받을 일이 없습니다.
- 읽기. 브라우저는 사용자가 고른 파일에만 페이지가 접근하도록 허용하며, 기기의 다른 것에는 접근할 수 없습니다.
- 압축. 작업은 브라우저의 백그라운드 스레드인 Web Worker에서 실행되므로, 페이지가 계속 반응하고 언제든 취소할 수 있습니다.
- 저장. 압축된 파일은 메모리(큰 동영상은 브라우저 전용 저장소)에서 만들어지고, 브라우저의 일반 다운로드 기능으로 하나씩 또는 ZIP으로 저장됩니다.
브라우저에서 실행되는 것
최신 브라우저는 WebAssembly로 컴파일된 코드를 네이티브에 가까운 속도로 실행할 수 있고, WebCodecs라는 인터페이스로 웹 페이지가 기기의 하드웨어 동영상 인코더에 접근하게 해 줍니다. oCompress는 둘 다 사용합니다.
- 이미지: JPEG용 MozJPEG, PNG용 OxiPNG와 팔레트 양자화기, Google libwebp의 WebP 인코더, AVIF용 libavif, SVG용 SVGO, 그리고 GIF와 TIFF 전용 디코더와 인코더. JPEG, PNG, WebP, AVIF 코덱은 WebAssembly로 컴파일되어 있습니다.
- 동영상과 오디오: MP4, WebM 같은 컨테이너를 읽고 쓰는 Mediabunny 라이브러리와 WebCodecs. 인코딩에는 가능하면 그래픽 칩의 하드웨어 인코더를 쓰므로 브라우저에서도 빠를 수 있습니다. MP3 파일은 LAME 인코더로, FLAC 파일은 libFLAC으로 만드는데, 둘 다 WebAssembly로 컴파일되어 필요할 때만 로드됩니다.
- 문서: 오픈 소스 PDF·ZIP 라이브러리를 바탕으로 한 저희 코드가 PDF와 오피스 파일을 열고, 안의 그림을 이미지 코덱으로 다시 압축한 뒤 새 파일을 만듭니다.
저희가 제공하는 모든 라이브러리는 오픈 소스입니다. 대부분 MIT, BSD, Apache 2.0 같은 관대한 라이선스이고, Mediabunny는 MPL 2.0, LAME MP3 인코더는 별도의 교체 가능한 파일로서 LGPL입니다. 라이브러리 버전 및 라이선스 목록을 참고하세요.
아무것도 업로드되지 않는다는 것을 확인하는 방법
저희 말을 그냥 믿으실 필요는 없습니다. 간단한 테스트 두 가지가 있습니다.
- 오프라인으로 전환하기. 도구 페이지를 열고 파일 하나를 압축해 엔진을 로드한 다음, Wi-Fi나 모바일 데이터를 끄고 같은 형식의 다른 파일을 압축해 보세요. 네트워크가 전혀 필요 없으므로 작동합니다.
- 네트워크 지켜보기. Chrome, Edge, Firefox에서 F12를 누르고 네트워크 탭을 연 다음 파일을 압축해 보세요. 저희 사이트에서 압축기 코드를 불러오는 요청과 분석·광고 요청은 보이지만, 파일을 담은 요청은 보이지 않습니다. 10MB 사진이라면 10MB 업로드로 나타날 텐데, 그런 것은 없습니다.
페이지는 'JPG 몇 메가바이트짜리가 압축됨' 같은 익명 사용 이벤트를 Google Analytics로 보냅니다. 이 이벤트에는 도구, 파일 형식, 그리고 크기·절감량·처리 시간의 대략적인 범위만 담기며, 파일 이름이나 내용은 절대 담기지 않습니다.
무손실 압축: 같은 내용, 더 적은 바이트
무손실 압축은 중복, 즉 두 번 이상 저장되었거나 예측할 수 있는 것을 찾아 더 간결하게 기록합니다. 디코딩은 이 과정을 정확히 되돌립니다. 거의 모든 무손실 형식에는 세 가지 아이디어가 등장합니다.
- 예측. 이미지의 이웃 픽셀이나 오디오의 연속된 샘플은 보통 비슷합니다. 전체 값 대신 예측값과의 작은 차이를 저장하면 대부분 0에 가까운 숫자만 남습니다. PNG 필터와 FLAC의 선형 예측기가 이런 방식으로 작동합니다.
- 반복. 반복되는 시퀀스를 앞선 사본을 가리키는 짧은 참조로 바꿉니다. ZIP, PNG, 오피스 파일에 쓰이는 DEFLATE의 LZ77 부분입니다.
- 엔트로피 부호화. 자주 나오는 값에는 짧은 코드를, 드문 값에는 긴 코드를 줍니다(허프만 부호화 또는 산술 부호화).
무손실 압축에는 자연스러운 한계가 있습니다. 무작위 잡음은 예측할 수 없으므로, 입자가 거친 사진이나 잡음이 많은 녹음은 손실 없이는 크게 줄지 않습니다. 이미 압축된 파일, 예를 들어 ZIP 안의 JPEG를 압축해도 거의 줄지 않는 이유도 이것입니다.
손실 압축: 아쉽지 않을 것을 덜어 내기
손실 코덱은 사람의 눈과 귀가 거의 인식하지 못하는 정보를 버림으로써 한 걸음 더 나아갑니다. JPEG와 WebP는 색을 밝기보다 낮은 해상도로 저장하고 고주파의 미세한 디테일을 반올림해 없앱니다. MP3, AAC, Opus는 더 큰 소리에 가려진 소리를 버립니다. H.264 같은 동영상 코덱은 이따금 완전한 그림을 하나 저장하고, 그 사이에는 주로 움직임과 변화만 저장합니다.
품질이나 비트레이트 설정이 얼마나 버릴지 정합니다. 적당한 설정에서는 손실을 알아차리기 매우 어렵지만, 너무 밀어붙이면 전형적인 잡티가 나타납니다. 이미지에는 블록과 번짐, 오디오에는 금속성이나 물속 같은 소리, 빠른 동영상 장면에는 뭉개짐이 생깁니다.
도구가 약속하는 것과 약속하지 않는 것
- 더 큰 파일을 받는 일은 절대 없습니다. 결과가 더 작지 않으면 도구는 원본을 돌려드리고 이미 최적화되어 있다고 알려 드립니다.
- 문서와 오디오 파일은 같은 파일과 설정이면 똑같은 바이트를 냅니다. 하드웨어 동영상 인코더는 실행할 때마다 몇 바이트씩 다를 수 있습니다.
- 문서의 텍스트는 텍스트로 남으며, 페이지가 그림으로 바뀌는 일은 없습니다.
- GPS 위치 같은 이미지 메타데이터는 기본적으로 제거되며, 색상 프로필과 회전 정보는 유지됩니다. 위치, 기기, 날짜 같은 동영상 메타데이터도 기본적으로 제거됩니다. 오디오는 끄지 않는 한 태그와 커버 이미지를 유지합니다.
저희가 약속할 수 없는 것은 특정 비율입니다. 얼마나 줄어드는지는 전적으로 파일이 어떻게 만들어졌는지에 달려 있습니다. 휴대폰 사진이나 스캔한 PDF는 보통 줄일 여지가 충분하고, 이미 최적화된 파일은 여지가 적습니다. 도구는 파일마다 정확한 압축 전후 크기를 보여 줍니다.
브라우저에서 압축할 때의 한계
브라우저 탭은 메모리가 제한된 샌드박스이며, 이것이 현실적으로 가능한 범위를 정합니다. 도구는 컴퓨터에서 이미지는 최대 200MB·1억 화소, PDF와 오피스 파일은 최대 300MB, 동영상과 오디오는 최대 4GB(휴대폰에서는 1GB)까지 받지만, 긴 4K 동영상은 그래도 탭의 메모리에 다 들어가지 않을 수 있습니다. 속도는 하드웨어에 달려 있습니다. 빠른 Windows PC의 Chrome에서 테스트했을 때 1080p 동영상 1분은 약 20초, 2400만 화소 사진은 약 2.5초가 걸렸으며, 휴대폰은 훨씬 느릴 수 있습니다. 동영상과 대부분의 오디오 변환에는 WebCodecs가 필요한데, 최신 Chrome, Edge, Opera, Firefox 130 이상, Safari 26 이상에서 제공됩니다. WAV와 AIFF는 WebCodecs가 없어도 MP3, FLAC, WAV로 바꿀 수 있습니다.
WMA, AVI, WMV처럼 브라우저에 디코더가 아예 없는 형식도 있고, 오래된 바이너리 오피스 파일은 안전하게 다시 쓸 수 없습니다. 이런 경우 도구는 손상될 수 있는 파일을 만드는 대신 가능한 선택지를 설명합니다. 브라우저로 감당하기에 너무 큰 작업이라면 동영상은 HandBrake, 문서는 LibreOffice 같은 데스크톱 프로그램을 쓰시라고 솔직하게 권해 드립니다.