이 문서는 어떠한 '업계 평균' 숫자도 인용하지 않습니다. 여기서 다루는 압축 데이터는 우리가 직접 실행한 실측 결과이며, 비용 계산은 공식을 제공하므로 본인 청구서의 단가를 대입하여 계산할 수 있습니다.
매월 클라우드 청구서를 확인할 때, 대다수의 사람들은 총액만 보고 지나치곤 합니다.
하지만 청구서를 펼쳐 제품별로 분석해보면 많은 웹사이트와 마이크로프로그램, 콘텐츠 플랫폼에서 상위에 위치한 항목이 보통 두 가지뿐인 것을 발견하게 됩니다:
- 객체 스토리지: GB·월 단위로 저장 비용을 청구합니다
- CDN / 공인망 트래픽: GB 단위로 다운로드 트래픽 비용을 청구합니다
그리고 이 두 항목 중 가장 비중이 큰 것은 보통 이미지입니다.
문제는 사용자가 거의 눈치채지 못하는 바이트가 상당수라는 점입니다. 하지만 매월 그런 바이트에 대해 돈을 지불하고 계십니다.
1. "업로드 시 압축함"은 "충분히 압축했다"는 뜻이 아닙니다
많은 팀이 말합니다. "우리는 업로드 시 이미 압축했습니다."
우리는 이 상황을 전문적으로 테스트해 보았습니다. 샘플은 사용자가 이미지를 업로드할 수 있는 웹사이트로, 데이터베이스 등록 시 이미 일반적인 압축을 한 번 수행한 것입니다: 78개의 폴더, 4624장의 이미지, 총 용량 1.41GB.
| 용량 | 원본 대비 | |
|---|---|---|
| 웹사이트가 이미 압축한 원본 파일 | 1.41 GB | — |
| ZIP으로 패킹 | 1.41 GB | -0.2% |
| ImgZilla 추가 압축 | 0.75 GB | -46.8% |
"이미 압축된" 상태에서 거의 절반을 더 아꼈습니다. 그리고 4624장 중 각각 계속 압축할 여지가 있었으며, 한 장도 "이미 최저치에 도달했으므로 건너뛰기"에 해당하지 않았습니다.
이유는 복잡하지 않습니다. 대부분의 데이터베이스 등록용 압축은 통일된 품질 매개변수를 설정하거나 크기를 제한하는 정도의 보수적인 일회성 처리에 불과하며, 각 포맷의 인코딩 공간을 완전히 활용하지 못합니다.
이미지 라이브러리가 카메라 직접 촬영 사진, 디자인 작업물 내보내기, 또는 운영팀이 직접 업로드한 원본이라면 저장 공간은 더 커집니다. 우리는 32188장의 카메라 직접 촬영 JPEG에서 전체 용량이 76.8% 감소한 것을 확인했습니다.
2. 저장 비용은 가산이고, 트래픽 비용은 승수입니다
이것이 가장 간과하기 쉬운 부분입니다.
- 저장 비용: 이미지가 버킷에 저장되면, 그 용량에 대해 매월 한 번씩 비용을 청구합니다.
- 트래픽 비용: 이미지가 열릴 때마다, 그 용량에 대해 한 번씩 더 청구합니다.
따라서 홈페이지 배너에 300KB의 무효 바이트가 추가되어도 저장 청구서에서는 거의 눈치채지 못하지만, 매일 10만 번 열린다면 트래픽 청구서에는 매일 약 29GB가 추가됩니다.
이미지가 더 인기 있다면, 불필요하게 지불하는 돈은 더 많아집니다. 그리고 가장 인기 있는 이미지는 홈페이지 배너, 상품 메인 이미지, 게시물 상단 이미지 같은 '가벼운 원본 업로드' 위치에 있습니다.
3. 본인의 청구서 계산하기
누구의 추정치도 믿지 마십시오. 지난달 청구서를 꺼내 다음 두 공식에 대입하세요:
월별 저장비 절약액 ≈ 이미지 총 저장량(GB) × 압축률 × 저장 단가(원/GB·월)
월별 트래픽비 절약액 ≈ 이미지 월 다운로드 트래픽(GB) × 압축률 × 트래픽 단가(원/GB)
압축률은 일단 보수적으로 **40%**로 추정하십시오(우리가 "이미 압축된" 샘플에서 측정한 46.8%보다 낮습니다). 본인의 이미지를 직접 돌려본 후 실제 숫자로 바꾸십시오.
데모용 예시 (단가는 가상의 값이며, 청구서의 숫자로 바꾸십시오):
| 항목 | 값 |
|---|---|
| 이미지 저장량 | 500 GB |
| 이미지 월 다운로드 트래픽 | 10 TB |
| 저장 단가(가상) | 0.12 원/GB·월 |
| 트래픽 단가(가상) | 0.20 원/GB |
- 저장: 500 × 40% × 0.12 ≈ 24 원/월
- 트래픽: 10240 × 40% × 0.20 ≈ 819 원/월
분명히 볼 수 있듯이, 진짜 대금은 트래픽입니다. 저장비로 아끼는 것은 일부일 뿐이고, 트래픽비로 아끼는 것이 진짜 돈입니다. 그리고 이 돈은 매달 지불되며, 이미지를 처리하지 않으면 계속 지불됩니다.
청구서에 보이지 않는 추가 이익들도 있습니다: 페이지 로딩 속도 향상, 모바일 사용자 데이터 사용량 감소, LCP 지표 개선, 마이크로프로그램 메인 패키지 용량 한도 이내로 압축 가능 등입니다.
4. 왜 알면서도 계속 누구도 압축하지 않을까?
우리는 많은 개발자와 사이트 관리자에게 물어보았고, 대답은 기본적으로 세 가지뿐이었습니다:
1. 경로 변경을 두려워함.
기존 온라인 압축 도구는 "업로드 → 다운로드 → 이름 변경 → 교체 → 코드의 참조 변경" 과정이 필요하며, 수천 장의 이미지 프로젝트에서는 누구도 건드리지 못합니다.
2. 화질 문제를 걱정함.
압축 후 디자인, 운영팀 또는 상사가 "이미지가 흐릿하다"고 하면 누구도 그 책임을 지고 싶지 않습니다.
3. 너무 번거로움.
폴더가 중첩되어 있고, 한 장씩 처리는 현실적으로 불가능하며, 스크립트를 작성하려면 매개변수를 조정하고 다양한 포맷을 처리해야 합니다.
ImgZilla는 이 세 가지 문제를 해결하기 위해 만들어졌습니다:
- 원본 위치 압축: 압축 후 원본 파일을 직접 교체하므로 파일명, 디렉토리 구조는 완전히 그대로 유지되며, 코드의 참조도 한 줄도 수정할 필요가 없습니다.
- 시각적 손실 없음: PNG, SVG는 진정한 무손실입니다. JPEG, WebP, AVIF, HEIC은 각 포맷별로 매개변수를 개별적으로 조정하여 눈으로 구별할 수 없는 범위 내로 유지합니다. 내장된 좌우 분할 비교 기능을 사용하여 실제 픽셀 단위로 직접 확인할 수 있습니다.
- 폴더 하나만 드래그하면 됨: 모든 하위 폴더를 재귀적으로 처리하므로 파일을 선택하거나 슬라이더를 조정할 필요가 없습니다.
- 모두 로컬 처리: 내부 자산, 미발표 상품 이미지 등 제3자 서버로 업로드할 필요가 없습니다.
5. 스토리지 버킷 '다이어트' 실제 프로세스
이미지가 객체 스토리지에 있다면 프로세스는 다음과 같습니다:
- 로컬로 동기화:
rclone,ossutil,coscmd,aws s3 sync같은 도구를 사용하여 이미지 디렉토리를 Mac으로 가져옵니다. - 백업본 생성: 안심하십시오. 이것은 도구의 불신과는 관련이 없으며 좋은 습관입니다.
- ImgZilla로 드래그: 전체 디렉토리를 드래그하여 실행을 기다립니다.
- 스토리지 버킷으로 다시 동기화: 동일한 도구를 사용하여 덮어쓰기 업로드하며 경로는 그대로 유지합니다.
- CDN 캐시 새로고침: 이미지 디렉토리에 대해 디렉토리 새로고침을 실행하여 엣지 노드가 새 파일을 가져오게 합니다.
5단계를 놓치지 마십시오. 새로고침하지 않으면 CDN 노드는 계속해서 오래된 파일을 분배하므로, 캐시가 만료된 후에만 트래픽 청구서가 감소합니다.
6. 솔직한 설명
- ImgZilla는 현재 macOS 버전만 있으며 (macOS 12.3 이상 필요), Windows 버전은 없습니다.
- PNG와 SVG를 제외한 다른 포맷은 시각적 손실 없음이며 픽셀 단위 무손실은 아닙니다. 의료 영상과 같이 픽셀 완전히 동일해야 하는 비즈니스 요구 사항이 있는 자산의 경우, 이러한 파일에 대해 재인코딩하지 마십시오.
- 압축률은 이미지마다 다릅니다. 우리의 실측 단일 압축 비율은 32%에서 86%까지 다양했습니다. 먼저 한 디렉토리를 테스트하여 실제 숫자를 확인한 후 결정하는 것을 권장합니다.
마무리
클라우드 벤더는 이미지를 더 작게 만들 수 있다고 알려주지 않으며, 청구서에 "무효 바이트" 행을 따로 표시하지도 않습니다.
하지만 그것은 그곳에 있습니다. 매월 GB 단위로 청구되며, 접근할 때마다 한 번씩 더 청구됩니다.
이미지 디렉토리를 ImgZilla로 드래그하여 한 번 실행하고, 다음 달 청구서와 비교해 보십시오.
👉 ImgZilla 다운로드: https://imagetool.app/ImgZilla