블로그 이미지 용량 줄이기: 같은 그림을 4.95MB에서 360KB로

블로그에 넣을 이미지가 너무 크다면 새로 만들기 전에 저장 형식부터 비교해 보자. 실제 이미지 3장을 WebP로 바꾼 결과와 화질을 확인하는 순서, 교체해도 되는 기준을 정리했다.

블로그에 넣을 그림은 마음에 드는데 파일 용량이 너무 크다면 어떻게 해야 할까? 이 블로그에서는 그림을 다시 만들지 않고, 원본을 남긴 채 저장 형식을 PNG에서 WebP로 바꾸는 방법을 썼다. 이미지 3장의 합계는 4.95MB에서 약 360KB로 줄었다.

이 글은 생성 이미지를 블로그에 올리는 사람이 그림을 다시 만들지 않고도 용량을 줄일 수 있는지, 그리고 어느 정도의 화질이면 교체해도 되는지 판단하기 위한 사례다. 줄어든 것은 이미지 파일 크기이며, 페이지 속도나 검색 순위의 개선을 측정한 결과는 아니다.

먼저 확인할 것: 작아진 파일을 그대로 써도 될까

파일 크기와 화면 품질을 함께 비교하면 된다. 원본과 변환본의 해상도를 같게 맞추고, 실제 게시 크기에서 작은 글자·윤곽선·어두운 배경이 뭉개지지 않는지 본다. 더 작고 필요한 표현이 유지되면 교체 후보가 된다. 흐려졌거나 오히려 커졌다면 원본을 유지하거나 설정을 다시 조정한다.

이번 사례는 AI 칩 공급 일정, 전공정 증설만으로 앞당길 수 없는 이유에 사용한 이미지 3장을 비교한 것이다. 아래에는 측정 조건과 결과, 자신의 이미지에 적용할 순서를 남겼다.

참고: 바이트·PSNR은 2026년 9월 9일의 기존 측정 기록이다. 9월 10일에는 변환을 다시 실행한 것이 아니라 원본과 변환본 6개의 파일 크기와 SHA-256 해시를 확인해 기존 기록과 일치함을 검증했다.

무엇을 했는가

1. 각 글의 원본 PNG(1,672×941)를 그대로 유지했다. 원본을 지우지 않는 것이 재현과 비교의 전제다.
2. 원본과 별도로 WebP 파일을 만들었다. 이 사례에서는 이미지 변환 도구인 sharp를 사용해 품질 90, 압축 노력 수준(effort) 6을 지정했다. 기본값은 품질 80, effort 4이므로 직접 선택한 설정이다. effort는 0~6이며 값이 클수록 인코딩에 더 많은 시간을 쓰는 옵션이다 [4]. 원본을 덮어쓰지 않고 보관해 언제든 비교하거나 되돌릴 수 있게 했다.
3. 변환 후 원본과 변환본을 나란히 두고 두 항목을 검토했다. 내용(한글 라벨 오탈자, 흐름·연결 관계, 수치·연도 오염 여부)과 화풍(어두운 네이비 배경, 무광 질감, 청록·앰버 강조, 글자 밀도)이다.

실측 결과 (이미지 바이트)

두 형식 모두 해상도는 1,672×941로 동일하다. 파일 동일성은 SHA-256 해시로 확인했고, 변환 후 공개 서버의 응답 해시가 디스크 파일과 일치하는지도 확인했다.

아래는 실제 변환 전후 비교다. 먼저 PNG 원본이다.

같은 그림의 WebP 변환본(품질 90)이다. 화면에서 구분이 되는지 직접 비교해 볼 수 있다.

왜 이렇게 작아지는가

PNG는 화소 값을 무손실로 저장하는 형식이라 사실적 일러스트처럼 색 변화가 많은 이미지에서는 파일이 커진다. WebP는 손실 압축을 지원해 사람이 구분하기 어려운 정보를 줄인다. Google의 공식 문서는 같은 SSIM 지표 기준으로 WebP가 JPEG보다 25~34% 작다고 발표하고, 무손실 WebP는 PNG보다 평균 26% 작다고 발표한다. 이 글의 92.73%는 그런 일반 수치보다 훨씬 큰데, 비교 대상이 ‘손실 WebP vs 무손실 PNG’이고 그림이 어두운 단색 배경 위 일러스트라 압축에 유리한 구성이기 때문이다(해석). 숫자를 다른 환경에 일반화하면 안 된다.

브라우저 지원

WebP 손실 형식은 Google Chrome(데스크톱) 17+, Edge 18+, Firefox 65+, Safari 14+(iOS 14+, macOS Big Sur+)부터 네이티브 지원된다(WebP 공식 FAQ 기준). 이 블로그의 방문자 환경을 고려하면 대부분의 최신 브라우저에서 문제없이 표시된다. 참고로 더 오래된 브라우저까지 지원하려면 <picture> 요소로 PNG 대체를 두는 방식이 있다. 이 블로그는 변환 원본 PNG를 남겨두므로 필요하면 언제든 이 방식으로 되돌릴 수 있다.

절충과 한계

• WebP 품질 90은 손실 인코딩이다. 변환본의 PSNR은 원본 대비 41.32/41.16/40.46 dB로 측정되어 있었다(2026-09-09 기록된 기존 측정값. 이번 글 작성 과정에서 재측정하지 않았다). PSNR이 높다는 것은 화질 손실이 대체로 눈에 띄기 어려운 범위라는 보조 신호일 뿐이고, 최종 판단은 원본과 나란히 두고 한 육안 검토로 했다.
• 어두운 배경의 넓은 단색 영역은 밴딩(색 계단 현상)이 생기기 쉬운 조건이지만, 검토한 3장에서 육안으로 식별되는 밴딩은 없었다.
• 생성 모델을 다시 돌리지 않고 기존 그림의 같은 픽셀 데이터를 입력으로 다른 형식으로 저장하는 방식이라, 재생성처럼 구도·화풍이 통째로 바뀔 가능성은 없다는 점이 이 접근의 장점이다. 다시 생성하면 스타일 연속성을 매번 재검증해야 한다. 단, 손실 인코딩이므로 픽셀 값이 원본과 완전히 동일하게 유지되는 것은 아니며, 화풍이 눈에 띄게 달라지지 않았다는 판단은 위의 육안 검토와 PSNR 기록에 근거한다.
• 이 방식은 블로그의 이미지 전송 바이트만 줄인다. 로딩 속도 개선을 확인하려면 별도의 측정(예: 동일 조건에서의 로딩 시간 비교)이 필요하다.
• 다른 종류의 이미지에 적용할 때는 변환 후 바이트 수를 먼저 확인하는 것이 좋다. WebP 공식 FAQ에 따르면 변환 방향과 원본 특성에 따라 결과 파일이 원본보다 커지는 예외가 있다. 색이 적은 PNG를 손실 WebP로 변환하면 오히려 커질 수 있고, 손실 형식(JPEG) 원본을 무손실 WebP로 바꾸거나 원본보다 높은 품질의 손실 WebP로 바꾸는 것도 일반적으로 파일이 커진다 [1]. 이 글의 3장은 어두운 배경 위 그라데이션이 많은 일러스트라 손실 WebP로 줄어드는 방향이었지만, 다른 구성의 이미지에 같은 설정을 적용할 때는 절감률이 달라질 뿐 아니라 절감 자체가 보장되지 않으므로, 변환 후 실제 바이트 수를 원본과 비교해 확인하는 절차를 거치는 것이 안전하다.

내 이미지에 적용하는 순서

특정 블로그나 개발 환경이 없어도 원본과 변환본을 비교할 수 있다. WebP 저장을 지원하는 이미지 편집기나 변환 도구를 사용하되, 사용한 도구와 품질 설정을 함께 기록해 두면 비교하기 쉽다.

1. 원본을 따로 보관한다. 변환 파일은 다른 이름으로 저장해 원본을 덮어쓰지 않는다.
2. 이미지 크기를 유지한 채 WebP로 저장한다. 형식 변경만의 차이를 보려면 가로·세로 해상도를 먼저 같게 맞춘다. 이 사례의 품질 90은 출발점으로 참고할 수 있지만, 도구마다 같은 숫자가 같은 결과를 뜻하지는 않는다.
3. 파일 크기를 비교한다. 원본과 변환본의 바이트 수를 기록한다. 감소율은 (원본 크기 − 변환본 크기) ÷ 원본 크기 × 100으로 계산한다. 변환본이 더 크면 무조건 교체할 필요는 없다.
4. 글자와 세부 표현을 확인한다. 같은 화면 크기로 나란히 열어 작은 글자, 윤곽선, 어두운 배경의 색 계단 현상이 달라졌는지 살펴본다. 크기가 줄었어도 읽기 어려워졌다면 품질 설정을 높이거나 원본을 사용한다.
5. 실제로 사용할 화면에서 확인한다. 블로그에 적용한다면 미리보기에서 이미지가 정상 표시되는지 확인한다. 로딩 속도까지 비교하려면 파일 크기와 별도로 같은 조건에서 측정해야 한다.

이 글에서는 sharp의 품질 90·effort 6을 사용했다. 다른 도구를 쓸 때는 품질과 압축 설정의 의미를 해당 도구 설명에서 확인하면 된다. 도구·버전·옵션이 다르면 같은 원본으로도 파일 크기가 달라질 수 있으므로, 목표는 이 글의 숫자를 그대로 재현하는 것이 아니라 자신의 이미지에서 크기와 품질의 균형을 찾는 것이다 [4][5].

내 파일에 쓸 비교 기록표

아래는 독자가 채우는 빈 양식이다. 이 글의 절감률을 목표값으로 쓰지 말고, 같은 해상도에서 실제로 저장된 파일을 비교한다.

교체 판단: 용량이 줄고 사용할 화면에서 필요한 세부 표현이 유지되면 교체 후보로 삼는다. 글자가 흐려지면 품질을 높여 다시 비교하고, 더 커지거나 품질이 부족하면 원본을 유지한다. 페이지가 빨라졌는지는 이 표로 판단하지 않는다.

확인한 출처 / 근거

• [1] WebP FAQ — Which web browsers natively support WebP? — 브라우저 네이티브 지원 버전, 무손실 WebP의 PNG 대비 26% 절감 발표값, 변환 방향에 따라 파일이 커질 수 있는 예외 사례 확인.
• [2] WebP Compression Study — 동일 SSIM 기준 JPEG 대비 25~34% 절감 발표값 확인.
• [3] WebP Lossless and Alpha Study — 무손실 WebP와 최적화 PNG의 압축 밀도 비교(23~42%) 확인.
• [4] sharp — Output options (webp) — sharp webp() 옵션의 공식 기본값(품질 80, effort 4)과 effort 범위(0~6) 확인.
• [5] cwebp documentation — cwebp -q(기본값 75)와 -m(0~6, 기본값 4) 옵션 정의 확인.

참고: 이미지별 바이트·해시·PSNR 수치는 이 블로그 운영자가 직접 측정·기록한 내부 확인 기록이다(2026-09-09 변환·공개 검증, 2026-09-10 해시·바이트 재확인). 수치는 위 비교 이미지와 이 사례의 측정 조건에 한정된다.