압축 도구에서 가장 흔히 쓰는 광고 문구는 '용량 70% 감소' 같은 검증할 수 없는 숫자입니다. 이 글은 업계 통계를 인용하지 않고, 실제 실행한 측정 결과만 제시하며, 누구나 직접 재현할 수 있도록 전체 비교 방법을 함께 제공합니다.
1. 테스트 대상: 원본이 아니라 '이미 한 번 압축된' 이미지
대부분의 압축 테스트는 카메라에서 바로 출력한 원본 사진을 사용하는데, 조건이 너무 이상적입니다. 이번 테스트는 의도적으로 실제 비즈니스 시나리오에 가깝게 구성했습니다. 사용자가 이미지를 업로드할 수 있는 웹사이트가 DB에 저장할 때 이미 자체적으로 기본 압축을 한 번 수행한 상태 — 즉, 테스트 대상은 가공되지 않은 원본이 아니라, 이미 '한 번 압축된' 완성본 이미지입니다.
샘플 규모: 78개 폴더, 총 4,624장의 이미지(주로 JPG)이며, 디렉터리 구조는 '앨범 하나당 폴더 하나'의 일반적인 아카이브 방식으로, 어떤 필터링이나 정리도 하지 않았습니다.
이 파일들의 서버 원본 총 용량: 1.41GB.
핵심 질문: 이미 압축 도구로 처리된 이미지를 다른 압축 도구에 다시 맡기면 얼마나 더 줄일 수 있을까? 대부분의 사용자는 '이미 압축했으니 더 압축해도 의미 없을 것'이라고 직관적으로 생각합니다.
2. 대조군: ZIP으로 묶으면 얼마나 줄어들까?
ImgZilla를 실행하기 전에 동일한 파일들을 그대로 ZIP으로 묶어 범용 압축 알고리즘의 효과를 확인했습니다:
| 용량 | 원본 대비 | |
|---|---|---|
| 웹사이트 압축 후 원본 파일 | 1.41GB | — |
| ZIP으로 묶은 경우 | 1.41GB | -0.2% |
거의 변화가 없습니다. 이유는 복잡하지 않습니다. JPEG 자체가 압축 형식이므로, 이미지 데이터는 이미 엔트로피 코딩을 거쳤고, 범용 알고리즘(ZIP은 DEFLATE 사용)은 이미 압축된 데이터를 더 압축하기 어렵습니다. 원본이 웹사이트 처리를 거쳤는지와 관계없이 ZIP은 이를 더 줄일 수 없습니다.
3. ImgZilla 재압축 실측
위 파일들을 ImgZilla에 끌어다 놓고 제자리 압축을 실행했습니다. 78개 폴더, 4,624장 이미지의 파일 이름과 디렉터리 구조는 완전히 유지됐습니다:
| 용량 | 원본 대비 | |
|---|---|---|
| 웹사이트 압축 후 원본 파일 | 1.41GB | — |
| ZIP으로 묶은 경우 | 1.41GB | -0.2% |
| ImgZilla 재압축 후 | 0.75GB | -46.8% |
웹사이트가 자체 압축한 상태에서 ImgZilla는 약 662MB를 추가로 절약해 용량이 거의 절반으로 줄었습니다. 모든 폴더 경로, 파일 이름, 계층 구조가 전후 완전히 동일합니다. 이는 직접 검증 가능한 실제 데이터이지 마케팅 레토릭이 아닙니다.
이것은 핵심 사실을 보여줍니다. '웹사이트 업로드 시 압축한 것'과 '형식별 매개변수로 정밀하게 인코딩한 압축'은 서로 다른 것입니다. 대부분의 웹사이트는 저장할 때 일회성으로 다소 보수적인 압축(보통 품질 매개변수나 크기만 제한)을 수행하며, 각 형식의 인코딩 여지를 충분히 활용하지 못합니다. ImgZilla는 각 형식에 맞게 매개변수를 개별 조정하고 JPEG에 시각적 무손실(visually lossless) 재인코딩을 적용합니다. 픽셀 수준에서는 실제로 변화가 있지만, 매개변수가 육안으로 거의 구분할 수 없는 범위로 설정되어 '이미 압축된' 상태에서도 추가 공간을 확보합니다.
혼동하기 쉬운 개념을 명확히 하자면, '시각적 무손실'은 '무손실'과 다릅니다. 진정한 무손실(픽셀 완전 유지)은 PNG(oxipng)와 SVG에만 적용됩니다. JPEG, WebP, AVIF, HEIC, GIF는 원리상 손실 재인코딩에 속하며, 단지 압축 매개변수가 시각적 무손실 한계치 안으로 제어될 뿐입니다. ImgZilla에는 비교 창이 내장되어 압축 전후를 좌우 분할로 보거나 실제 크기로 확대해 픽셀 단위로 대조할 수 있으므로 직접 확인할 수 있습니다.
4. 상세 분석: 파일별 압축률, 픽셀 크기, 작업 소요 시간
앞서 나온 46.8%의 전체 압축률은 4,624장 이미지의 총합 결과입니다. 개별 파일 수준으로 분해하면 더 많은 세부 정보를 얻을 수 있습니다.
이미지별 압축률 분포는 고르지 않다
각 이미지의 압축률(압축 후 바이트 수 / 압축 전 바이트 수)을 하나씩 계산한 결과, **32.3%에서 85.8%**까지 다양했습니다:
- 압축률이 가장 높은 그룹: 약 765KB가 109KB로 줄어 압축률 85.8% — 이런 이미지는 보통 초기 압축 강도가 부족해 재인코딩 여지가 더 큽니다.
- 압축률이 가장 낮은 그룹: 약 572KB가 387KB로 줄어 압축률 32.3% — 이런 이미지는 이전에 이미 강하게 압축되어 추가로 줄일 여지가 제한적입니다.
- **4,624장 이미지 압축률의 산술 평균은 46.44%**로, 전체 용량 기준으로 계산한 46.8%와 비슷하지만 동일하지는 않습니다. 전자는 각 파일 압축률의 단순 평균이고, 후자는 '총 절약 바이트 ÷ 총 원본 바이트'입니다. 이 차이는 압축률이 높고 낮은 파일들이 전체 용량에서 차지하는 비중이 비대칭적이며, 소수의 대용량 파일이 전체에 더 큰 영향을 미친다는 것을 보여줍니다.
흥미로운 점은 모든 이미지의 압축률이 양수라는 것입니다. 즉 '이미 최소라 건너뜀'인 경우가 없었다는 뜻입니다. 이번 '웹사이트에서 이미 압축된' 이미지들은 각각 ImgZilla로 실제 공간을 더 확보할 수 있었습니다.
픽셀 크기: 조금도 다르지 않다
전체 4,624장 이미지의 픽셀 크기를 집계한 결과, 가장 흔한 규격은 1600×2400(1,756장)과 그 가로형 2400×1600(500장)이었고, 크기 범위는 가장 작은 450×675(약 30만 픽셀)부터 가장 큰 3000×2000 / 2000×3000(약 600만 픽셀)까지였습니다.
압축 전후 픽셀 크기를 표본 추출해 대조한 결과, 완전히 동일하며 어떤 변화도 없었습니다:
| 파일(예시) | 원본 크기 | 압축 후 크기 |
|---|---|---|
| 샘플 1 | 1600×1066 | 1600×1066 |
| 샘플 2 | 2000×3000 | 2000×3000 |
| 샘플 3 | 1416×2128 | 1416×2128 |
이것은 '제자리 압축'의 정의에서 간과하기 쉬운 나머지 절반입니다. 파일 이름과 경로뿐 아니라 해상도도 그대로 유지됩니다. ImgZilla는 크기를 조정하거나 잘라내지 않으며, 모든 용량 감소는 픽셀을 희생하는 것이 아니라 순전히 재인코딩에서 비롯됩니다.
작업 소요 시간: 4,624장 처리에 51분 32초, 장당 평균 0.669초
테스트 환경: Mac mini(Apple M1 칩, 8GB 통합 메모리)에서 이미지는 2.5G 유선 네트워크로 연결된 NAS 하드디스크에 저장되어 있었습니다.
각 이미지의 마지막 쓰기 시간(즉 ImgZilla가 압축을 완료하고 디스크에 다시 쓴 시점)으로 작업 진행 상황을 추적했습니다. 첫 번째 이미지는 16:06:09에, 마지막 이미지는 16:57:41에 기록되었으며, 전체 배치 처리 총 소요 시간은 51분 32초, 장당 평균 0.669초입니다.
이 데이터는 제품의 '직렬 처리' 설계와 일치합니다. 병렬로 순서 없이 쓰는 것이 아니라 한 장씩 순서대로 압축합니다. 계산하면 대략 분당 90장을 처리하는 셈입니다. 실제 속도는 이미지 용량과 기기 성능에 따라 달라지며, 여기 제시된 수치는 평균 장당 약 305KB인 이번 이미지들이 위 환경에서 처리된 실제 소요 시간일 뿐 일반적인 기준이 아닙니다.
5. 별도 사본으로 저장하지 않고 '제자리' 압축을 선택한 이유
만약 이번 테스트가 '압축 버전을 별도로 저장'하는 도구를 사용했다면 결과는 원본 1.41GB + 압축본 0.75GB로 동시에 2.16GB를 차지해 오히려 더 많은 공간을 사용하게 되고, 수많은 xxx-min.jpg 파일이 생성되어 데이터베이스나 상품 테이블의 참조를 수동으로 정리하고 업데이트해야 합니다.
ImgZilla는 제자리 덮어쓰기 방식을 사용합니다. 압축 결과가 원래 경로에 직접 기록되므로 78개 폴더의 4,624개 파일 이름이 모두 그대로 유지됩니다. 이미지 경로가 데이터베이스, CDN, CMS 참조에 이미 저장된 웹사이트의 경우 특히 중요한데, 압축 후 어떤 링크도 수정할 필요가 없기 때문입니다. 대신 원본 파일을 수정하므로, 기본적으로 원본 이미지를 먼저 시스템 휴지통으로 이동시킨 뒤 압축 결과를 기록합니다. 되돌리고 싶다면 휴지통에서 마우스 오른쪽 버튼으로 '원래 위치로 복원'을 누르면 됩니다.
6. 효과 분석: 실제 시나리오에서 월 청구서까지
이 데이터는 누구에게 실질적인 가치가 있는가
- 사용자 업로드 이미지 서비스를 운영하는 웹사이트/개발자: 이미지 스토리지와 CDN 트래픽은 보통 GB 단위로 과금되므로 용량이 절반이 되면 청구 금액도 절반이 됩니다. 게다가 트래픽 비용은 방문할 때마다 발생하는 비용이라 방문량이 많을수록 복리 효과가 커집니다. 저장 시 기본 압축을 이미 수행했더라도 이번 실측은 '전문적으로 조정된 압축을 한 번 더 실행'하면 여전히 상당한 이득을 얻을 수 있음을 보여줍니다.
- 저장 공간이 부족한 서버/소용량 디스크 사용자: 정리 도구는 보통 캐시나 중복 파일을 삭제하지만 몇 달 후 다시 쌓입니다. 반면 압축으로 확보한 공간은 사용 중인 파일 자체가 작아진 것이므로 다시 늘어나지 않습니다. 이번 78개 폴더는 압축 후 사용 가능한 공간이 662MB 늘어났으며, 이는 영구적으로 확보된 것입니다.
- 데이터를 자주 옮기는 사용자: 복사, 동기화, 백업 시 용량이 46.8% 줄어들면 전송 시간도 거의 같은 비율로 단축됩니다. 한 번 압축하면 이후 매번 옮길 때마다 시간을 절약할 수 있습니다.
월 청구서로 환산하면: 이 46.8%는 도대체 얼마의 가치인가
용량 감소는 결국 청구서에 반영되어야 설득력이 있습니다. 아래에서는 '압축이 전환율을 높인다'는 식의 통계는 전혀 인용하지 않고, 이번 실측 **46.8%**를 주요 클라우드 서비스 제공업체의 공개 스토리지/트래픽 요금에 곱해 순수 산술 계산만 수행합니다.
스토리지 비용 절감 = 줄어든 용량(GB) × 단가(위안 또는 달러 / GB / 월)
아웃바운드 트래픽 비용 절감 = 줄어든 용량(GB) × 당월 다운로드/방문 횟수 × 단가(위안 또는 달러 / GB)
용량이 절반이면 두 항목의 청구 금액도 기본적으로 절반으로 줄어듭니다. 이는 추측이 아니라 수학입니다.
스토리지 비용: 이미지 보관함이 클수록 절감 효과도 커진다
중국 업체:
| 이미지 보관함 원본 크기 | 절약된 용량 | Alibaba Cloud OSS 표준 스토리지 ¥0.09/GB/월 |
|---|---|---|
| 10GB | 4.68GB | ¥0.42/월 |
| 100GB | 46.8GB | ¥4.21/월 |
| 1TB | 479GB | ¥43.1/월 |
해외 업체:
| 이미지 보관함 원본 크기 | 절약된 용량 | AWS S3 Standard $0.023/GB/월 |
Google Cloud Storage $0.020/GB/월(미국 리전) |
Azure Blob Storage $0.018/GB/월(Hot, LRS) |
Cloudflare R2 $0.015/GB/월 |
|---|---|---|---|---|---|
| 10GB | 4.68GB | $0.11/월 | $0.09/월 | $0.08/월 | $0.07/월 |
| 100GB | 46.8GB | $1.08/월 | $0.94/월 | $0.84/월 | $0.70/월 |
| 1TB | 479GB | $11.02/월 | $9.58/월 | $8.62/월 | $7.19/월 |
해외 주요 업체들의 스토리지 단가는 매우 비슷합니다(격차 30% 이내). 핵심은 누가 더 싼가가 아니라, 어느 업체를 선택하든 용량이 절반이면 해당 청구 금액도 기본적으로 절반으로 줄어들고 월 단위로 반복 청구된다는 점입니다. 한 번 압축하면 이후 매달 새 용량 기준으로 청구되므로, 일회성 투자로 장기간 지속되는 이익입니다.
트래픽 비용: 실제로 가장 큰 비용이며, 방문량에 따라 커진다
트래픽 비용은 스토리지 비용보다 더 주목할 만합니다. 용량 × 다운로드 횟수의 곱이기 때문입니다. 이미지가 자주 접근될수록 압축 효과도 커집니다. 100GB 이미지 보관함이 한 달에 CDN을 통해 500GB의 다운로드 트래픽을 발생시킨다고 가정해 보겠습니다(보관함 전체가 약 5회 완전히 다운로드되는 셈).
| CDN / 아웃바운드 트래픽 요금(첫 구간 가격) | 압축 전 월 트래픽 비용 | 압축 후(트래픽 -46.8%) | 월 절감 | 연 절감 |
|---|---|---|---|---|
| Alibaba Cloud CDN 중국(낮은 구간 ¥0.15/GB) | ¥75.0 | ¥39.9 | ¥35.1 | ¥421 |
| AWS CloudFront 아시아 태평양($0.12/GB) | $60.0 | $31.9 | $28.1 | $337 |
| Google Cloud CDN 북미/유럽($0.08/GB) | $40.0 | $21.3 | $18.7 | $224 |
| Azure Front Door 표준판 Zone 1($0.08/GB) | $40.0 | $21.3 | $18.7 | $224 |
위 표는 각 업체의 최저 구간 요금을 기준으로 했으며, 실제 계단형 요금은 더 높을 수 있습니다(Alibaba Cloud CDN 중국 트래픽 계단은 최고 ¥1.31/GB까지 가능). 청구 금액이 클수록 압축으로 절약되는 절대 금액도 커집니다. 또한 현재 Azure의 해당 구간은 Front Door 표준판으로, GB당 아웃바운드 트래픽 외에 약 $35/월의 기본 서비스 요금이 포함됩니다. 이 요금은 압축으로 줄일 수 없으므로 위 표의 절감액에는 포함하지 않았습니다.
Cloudflare R2는 예외입니다. R2의 아웃바운드 트래픽은 애초에 $0입니다. 즉, 스토리지 버킷을 R2에 두면 압축 효과는 거의 전적으로 스토리지 비용에 반영되고, 트래픽 부분은 청구서 자체가 없습니다. 이는 '스토리지 + 트래픽' 이중 과금 구조(예: Alibaba Cloud OSS+CDN, AWS S3+CloudFront)와는 다른 비용 구조이므로, 서비스 제공업체를 선택하기 전에 자신의 과금 항목을 명확히 해야 합니다.
위 단가는 2026년 기준 각 플랫폼 공개 요금을 정리한 것이며, 실제 가격은 지역, 계정 할인, 계단형 구간에 따라 달라지므로 공식 웹사이트의 실시간 가격을 기준으로 하시기 바랍니다. 다운로드 횟수와 방문 수는 예시 가정이므로, 자신의 청구서 실제 데이터로 바꿔서 추산하시기 바랍니다.
7. 전송 및 업로드 시간 절약
용량이 절반이면 전송 시간도 거의 같은 비율로 줄어듭니다. 이 법칙은 클라우드 청구서와 무관하게 로컬 복사, 백업은 물론 사용자 업로드 과정에서도 동일하게 적용됩니다.
로컬 시나리오: USB 3 및 기가비트 네트워크
- USB 3 휴대용 HDD: 지속 읽기/쓰기 처리량은 보통 100~150MB/s이며, 중간값인 120MB/s 기준.
- USB 3 휴대용 SSD: 처리량이 확연히 높아 보통 400~500MB/s이며, 450MB/s 기준.
- 기가비트 유선 네트워크(1000Mbps): 이론상 최대 125MB/s이지만, 프로토콜 오버헤드를 제외하면 실제 지속 처리량은 약 100~110MB/s이며, 105MB/s 기준.
위 값은 일반적인 실측 구간의 추정치이며, 실제 속도는 디스크 매체, 인터페이스 품질, 네트워크 환경에 따라 달라지므로 추정 시 참고용으로만 사용하시기 바랍니다.
| 시나리오 | 절약된 용량 | USB 3 HDD @120MB/s | USB 3 SSD @450MB/s | 기가비트 네트워크 @105MB/s |
|---|---|---|---|---|
| 이번 실측 이미지들 | 662MB | 약 5.5초 | 약 1.5초 | 약 6.3초 |
| 10GB 이미지 보관함 | 4.68GB | 약 40초 | 약 10초 | 약 45초 |
| 100GB 이미지 보관함 | 46.8GB | 약 6.5분 | 약 1.7분 | 약 7.4분 |
| 1TB 이미지 보관함 | 479GB | 약 66분 | 약 18분 | 약 76분 |
이번 실측의 662MB는 한 번만 보면 몇 초에 불과해 크게 느껴지지 않을 수 있습니다. 그러나 스토리지 비용과 마찬가지로 이것은 일회성 투자로 장기간 지속되는 이익입니다. 휴대용 하드디스크에 복사하거나 꺼낼 때, NAS를 동기화할 때, Time Machine을 실행할 때, 새 Mac으로 마이그레이션할 때, 동료에게 전달할 때 등 이 데이터를 옮길 때마다 항상 같은 비율로 시간이 절약됩니다. 한 번 압축하면 이후 매번 옮길 때마다 시간을 절약할 수 있습니다.
압축이 사용자 업로드 전에 이루어진다면: 줄어드는 대기 시간
앞서 계산한 것은 '이미지 저장 후'의 이익, 즉 스토리지 비용, CDN 트래픽 비용, 로컬 전송입니다. 여기서 한 가지 더 고려할 가치가 있습니다. 사용자가 '업로드' 버튼을 누른 뒤 진행률 표시가 완료될 때까지의 대기 시간은 사용자 자신의 업로드 대역폭을 사용합니다. 그런데 업로드는 보통 전체 경로에서 가장 느린 병목 지점입니다. 대부분의 소비자용 광대역 업로드 속도는 다운로드의 10분의 1에서 5분의 1에 불과하며, 모바일 네트워크는 더욱 그렇습니다. 사용자가 업로드하기 전에 웹사이트나 앱이 ImgZilla로 먼저 이미지를 압축한다면, 줄어든 용량은 그대로 사용자의 대기 시간 감소로 이어집니다.
이번 실측의 장당 평균 용량을 기준으로 계산하면, 웹사이트가 압축한 원본은 평균 299KB였고, ImgZilla로 재압축한 후에는 평균 159KB가 되어 장당 평균 약 140KB를 절약했습니다.
| 업로드 대역폭(공개 속도 측정 데이터의 일반적인 범위, 참고용) | 장당 299KB→159KB |
50장 앨범 업로드 약 15.0MB→8.0MB |
이번 실측 전체 4,624장 업로드 1.41GB→0.75GB |
|---|---|---|---|
| 모바일 네트워크(4G/5G 종합, 국내 공개 속도 측정 중앙값 약 10~50Mbps, 30Mbps 기준) | 약 0.04초 절약 | 약 1.9초 절약 | 약 3분 절약 |
| 일반 가정용 광대역 업로드(100Mbps/1Gbps 다운로드 요금제, 업로드는 보통 제한되어 약 20~30Mbps, 25Mbps 기준) | 약 0.04초 절약 | 약 2.2초 절약 | 약 3.5분 절약 |
| 기가비트 대칭 광대역 업로드(일부 통신사/기업 전용회선, 1000Mbps) | 약 0.001초 절약 | 약 0.06초 절약 | 약 5.3초 절약 |
| 해외 참고: 미국 평균 유선 광대역 업로드(Ookla 데이터, 2026) | 약 0.02초 절약 | 약 1초 절약 | 약 1.5분 절약 |
단일 이미지로 이 표를 보면 의미가 없어 보일 수 있습니다. 0.04초는 거의 느낄 수 없기 때문이며, 이는 정직한 결과입니다. 이번 테스트 샘플 자체가 크지 않기 때문입니다(웹사이트 저장 전에 이미 압축되어 장당 평균 299KB에 불과). 진정한 가치가 드러나는 시나리오는 두 가지입니다. 한 번에 앨범 전체나 수십 장을 업로드하는 배치 작업, 그리고 용량이 훨씬 큰 원본 소스(예: 카메라에서 바로 출력한 JPEG, 또는 웹사이트 압축을 거치지 않은 UGC 최초 업로드로 장당 수백 KB가 아니라 수 MB에 달하는 경우)입니다. 같은 압축 비율이라면 절약되는 절대 시간도 같은 비율로 커집니다. 업로드 대역폭이 원래 느린 모바일 네트워크 사용자라면 대기 시간 단축이 더욱 두드러집니다.
모바일 네트워크와 가정용 광대역의 범위 수치는 중국 공개 속도 측정 통계(4G/5G 중앙값, 광대역 업로드 일반적인 비율)를 기반으로 하며, 실제 속도는 통신사, 지역, 기기, 네트워크 혼잡에 따라 크게 달라질 수 있으므로 대략적인 수준으로만 참고하시기 바랍니다. 미국 유선 광대역 업로드 데이터는 Ookla Speedtest 관련 보도를 인용했습니다.
직접 확인해 보시겠어요? Mac App Store에서 ImgZilla를 바로 다운로드한 뒤, 자신의 웹사이트에서 이미 처리된 이미지 몇 장으로 직접 테스트해 보고 나머지를 계속 압축할지 결정하세요.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
더 알아보기: https://imagetool.app/ImgZilla