이미지 압축 도구

온라인 이미지 압축은 알고리즘을 통해 이미지 파일 크기를 줄여 페이지 로딩을 빠르게 하고, 업로드 크기 제한을 만족시키며, 공유 시 대역폭 소비를 줄여줍니다. 파일은 ToolAct의 변환 서비스에 업로드되어 서버 측 이미지 처리 라이브러리(libvips, mozjpeg, libwebp 등)가 디코딩 및 재인코딩을 수행한 뒤 압축 결과를 브라우저로 다시 보내며, 변환이 완료되면 임시 파일은 즉시 서버에서 삭제되어 보관되지 않으며 훈련에 사용되지 않습니다. 형식에 따라 화질, 메타데이터, 색상 정보, 인코딩 세부 사항이 조정될 수 있으며, 사진은 일반 표시 크기에서 받아들일 만한 화질을 유지하면서도 훨씬 작아질 수 있습니다. 블로그 이미지, 상품 사진, SNS 게시물, 고객 지원 첨부 파일, 모든 원본 픽셀을 보존할 필요가 없는 초안 자료에 적합합니다. 인쇄용 준비, 보관, 정밀한 시각 검사 용도라면 압축 후 결과를 확인해야 합니다. 개인 식별 정보, 사내 자료 또는 기타 민감한 내용이 포함된 이미지는 업로드하지 마세요.

이미지 압축은 손실/무손실 경계를 따라 명확하게 나뉩니다. 손실 형식(JPEG, WebP 손실)은 인간의 지각 한계를 활용합니다. 눈은 고주파 크로마보다 휘도에 훨씬 더 민감하므로, 인코더는 8x8 또는 16x16 블록에서 미세한 색상 세부 정보를 대부분의 사용자가 눈치채지 못하게 제거합니다. JPEG는 1992년부터 이 DCT 기반 경로를 사용해 왔으며, 현대 대안으로는 mozjpeg(동일한 SSIM에서 libjpeg보다 ~5-10% 작고 인코더 느림), libwebp(Google의 VP8/VP8L 이미지 코덱, 2010), AVIF(Alliance for Open Media, AV1 인트라, 2019)가 있습니다. 무손실 형식(PNG, GIF, WebP 무손실)은 엔트로피 코딩(LZ77 슬라이딩 윈도우 사전 + 허프만 또는 산술 코딩)을 통해 바이트를 줄이며 단일 픽셀도 변경하지 않습니다. 이 페이지에서 사용하는 파이프라인은 완전히 서버 측에서 동작합니다. 브라우저는 각 이미지를 서명 인증된 멀티파트 업로드로 ToolAct의 압축 엔드포인트(/image/compress)에 보냅니다. 서버는 요청을 검증한 뒤 바이트 스트림을 libvips — 스트리밍 방식으로 수요에 따라 동작하며 1억 픽셀 입력에서도 메모리 사용량을 낮게 유지하는 고성능 이미지 처리 라이브러리 — 에 전달합니다. libvips는 소스를 디코딩하고 필요시 긴 변을 축소하여 출력 크기를 제한한 뒤, JPEG는 mozjpeg, WebP는 libwebp, PNG는 libpng/oxipng를 통해 재인코딩합니다. 인코딩된 바이트는 다운로드 응답으로 브라우저에 직접 스트리밍되며, 임시 업로드 파일은 응답이 작성되는 즉시 디스크에서 삭제됩니다. 보관도 없고, 훈련 파이프라인도 없으며, 콘텐츠에 대한 사람의 검토도 없습니다. JPEG 양자화는 형식의 핵심입니다. 품질 90은 거의 모든 DCT 계수를 유지하고, 75는 중간 주파수 계수를 버리기 시작합니다(노란색 배경의 빨간 텍스트에서 보임), 50은 부드러운 그라데이션에서 블록 아티팩트가 나타나는 명백한 JPEG 영역이며, 25는 얼굴에서 눈에 띄는 포스터라이제이션을 생성합니다. PNG 압축은 zlib(DEFLATE) 레벨 0-9에 기반합니다. 레벨 1은 빠르지만 더 큰 파일을 생성하고, 레벨 9는 CPU를 사용하여 단색 배너에서 마지막 바이트를 압축합니다. EXIF, ICC 프로필, XMP, IPTC 메타데이터는 인코더가 파일 헤더를 처음부터 다시 빌드하기 때문에 일반적으로 제거됩니다. 이는 200KB 카메라 사진이 동일한 해상도에서도 60KB 업로드가 될 수 있는 실제적인 이유이며, 이미지 출처와 색상 관리 메타데이터가 중요하면 별도로 보존해야 하는 이유이기도 합니다.

• libvips(John Cupitt, LGPL)는 서버 측 이미지 처리 엔진입니다. 스트리밍 방식으로 수요에 따라 동작하는 파이프라인으로, 1억 픽셀 입력에서도 메모리 사용량을 낮게 유지하며 Sharp, ImageMagick의 IM7 vips 위임, 그리고 이 도구 뒤의 변환 엔드포인트의 기반이 됩니다.
• mozjpeg(Mozilla, 더 나은 심리시각 모델을 가진 libjpeg-turbo 포크)는 동일한 SSIM에서 기본 libjpeg보다 5-10% 작은 파일을 생성하지만 인코딩이 약 3-5배 느립니다. 2017년 이후 대부분의 JPEG 품질 80-85 웹 기본값 이면의 트레이드오프입니다.
• PNG는 LZ77 + 허프만입니다. 인코더는 32KB 전까지 반복 바이트 시퀀스를 찾고(슬라이딩 윈도우), (거리, 길이) 쌍을 출력한 뒤 결과를 허프만 코딩합니다. WebP 무손실(VP8L)은 유사한 방식에 Local Palette 패치를 추가하여 동일한 RGBA 픽셀에서 보통 PNG보다 20-26% 더 작습니다.
• libwebp는 Google의 WebP 참조 인코더/디코더입니다. 서버 측에서는 손실 VP8(품질 0-100, 기본 4:2:0 크로마) 또는 무손실 VP8L(품질 파라미터는 압축 노력을 제어하며 픽셀 충실도가 아님)을 출력하는 데 사용됩니다. WebP 디코딩은 광범위하게 지원되며(Chrome 32+ 2014, Firefox 65+ 2019, Safari 14+ 2020), 변환된 WebP는 거의 모든 현대 브라우저에서 안전합니다.
• JPEG의 4:2:0 크로마 서브샘플링 기본값(휘도 4개당 크로마 2개)이 품질 60에서 노란색 배경의 빨간 텍스트가 흐릿하게 보이는 이유입니다. 크로마 세부 정보가 휘도 세부 정보보다 먼저 버려지기 때문입니다. 텍스트 가장자리가 중요한 스크린샷과 UI 캡처에는 서브샘플링 없는 4:4:4로 전환하세요.
• EXIF(교환 가능 이미지 파일 형식, JEITA CP-3451) 및 ICC 색상 프로필은 재인코딩 시 기본적으로 제거됩니다. 따라서 6.3MB iPhone JPEG는 서버를 거친 후 1.8MB가 되는 경우가 많습니다. 이것이 소비자 사진작가가 웹 도구를 거칠 때마다 파일 크기가 줄어드는 이유입니다. 실용적인 배치 함정: 폴더에 작은 아이콘(200x200px 미만, 알파가 있는 PNG), 단색 UI 스크린샷(PNG, 매우 높은 압축성), 휴대폰 사진(JPEG, 대부분 노이즈 유사 콘텐츠)이 혼합되어 있으면 단일 품질 슬라이더는 세 가지 모두에 부적합합니다. 아이콘은 무손실 PNG 또는 WebP 무손실을 원하고, 스크린샷은 품질 85-90의 4:4:4 JPEG를 원하며, 사진은 품질 75-80의 손실 WebP를 원합니다. 모두 품질 60으로 압축하면 바이트는 절약되지만 아이콘에 빨간 테두리, 스크린샷 주변에 링 아티팩트, 사진에 밴딩이 생깁니다. 더 스마트한 파이프라인은 각 카테고리를 다른 인코더 경로로 처리하며, 이는 사용자가 하나의 기본값을 선택해도 인터페이스가 파일별로 대상 형식을 재정의할 수 있도록 허용하는 이유입니다. 앞으로, JPEG XL(ISO/IEC 18181, 2022)은 Google과 Cloudflare가 2020년부터 JPEG 후속으로 밀어온 형식입니다. 동일한 품질에서 ~20% 작고, 완전한 무손실 모드, 크로마 서브샘플링 없음, 느린 네트워크에 친화적인 프로그레시브 디코딩을 제공합니다. 브라우저 지원은 부분적입니다(Chrome 110에서 JPEG XL 비활성화). 따라서 현재 실용적인 마이그레이션 경로는 품질 80의 WebP, 추가 바이트가 필요한 히어로 에셋에는 AVIF, 구형 Safari나 오래된 이메일 클라이언트에는 JPEG 폴백을 유지하는 것입니다. 이 페이지는 품질, 최대 크기, 대상 형식을 중요한 세 가지 레버로 노출하며, 나머지는 모두 구현 세부 사항입니다.
• 서버 측 변환 라이프사이클: 업로드된 각 파일은 libvips 디코딩 + 재인코딩을 실행하고 결과를 스트리밍 회신하는 동안에만 보관됩니다. 임시 파일은 변환의 성공 또는 실패 여부와 관계없이 응답이 닫힐 때 삭제됩니다. 렌더러 메인 스레드를 200-500ms 동안 멈추게 했을 24MP JPEG가 사용자 기기에서 완전히 벗어나 처리됩니다.
• 마이그레이션: AVIF는 차세대 대상입니다(Alliance for Open Media, AV1 인트라, 10/12비트, 알파, 애니메이션 지원). 서버 측에서 libavif/aom을 통해 AVIF를 인코딩하더라도 여전히 WebP보다 10-30배 느리므로 대부분의 페이지는 품질 80의 WebP를 유지하고 추가 15-20% 바이트 절약이 히어로 사진에 유용한 경우에만 AVIF를 사용합니다.