이미지 압축 글에서 자주 보이는 결론은 "WebP가 더 작다"이다. 하지만 실제 도구를 만들 때 이 문장은 절반만 맞다. 사진은 WebP 변환과 리사이즈로 크게 줄어드는 경우가 많지만, UI 스크린샷은 작은 글자의 선명도가 더 중요하고, 투명 PNG는 결과 크기보다 투명 영역 보존이 먼저일 수 있다.
이 글은 브라우저 이미지 압축 구현 전체 가이드의 벤치마크 기준을 더 구체화한다. 애드센스 승인용 콘텐츠 관점에서도 단순 주장보다 직접 비교 기준을 갖춘 글이 더 높은 독립 가치를 가진다.
비교 대상을 먼저 나눠야 한다
이미지를 하나의 그룹으로 묶어 압축률을 비교하면 결과가 흐려진다. 사진, 스크린샷, 투명 그래픽은 픽셀 구조가 다르다. 사진은 색 변화가 자연스럽고 노이즈가 많아 손실 압축에 강하다. 스크린샷은 텍스트와 경계선이 많아서 약간의 손실도 눈에 띈다. 투명 그래픽은 알파 채널과 가장자리 품질이 중요하다.
| 유형 | 압축 판단 기준 | 주의점 |
|---|---|---|
| 사진 | 용량 감소와 체감 품질 | 품질 값을 너무 낮추면 피부나 배경 그라데이션이 뭉개짐 |
| 스크린샷 | 글자 선명도와 경계선 | 압축률보다 텍스트 가독성이 우선 |
| 투명 그래픽 | 알파 채널과 가장자리 | 투명 영역 깨짐이나 테두리 번짐 확인 필요 |
사진은 리사이즈 효과가 가장 크다
모바일로 찍은 사진은 원본 해상도가 웹 표시 목적보다 큰 경우가 많다. 이런 파일은 품질 값을 낮추기 전에 최대 너비와 높이를 제한하는 것만으로도 큰 감소 효과가 나온다. 예를 들어 본문 이미지라면 4000px 원본을 그대로 둘 이유가 거의 없다. 1600px 또는 2000px 정도로 줄이면 화면 표시 품질을 유지하면서 파일 크기를 줄일 수 있다.
이때 중요한 것은 원본보다 크게 만들지 않는 것이다. 작은 이미지를 강제로 키우면 용량은 늘고 품질은 좋아지지 않는다. 이 내용은 Canvas 이미지 리사이즈 품질 저하를 줄이는 방법과도 연결된다.
스크린샷은 글자 선명도를 먼저 본다
개발 블로그에서 스크린샷은 단순 장식이 아니라 정보 전달 수단이다. 코드 에디터, DevTools, 설정 화면의 글자가 흐려지면 압축률이 높아도 실패다. 스크린샷은 WebP 품질 값을 낮추기보다 표시 크기에 맞게 리사이즈하고, 결과를 실제 화면 배율에서 확인하는 것이 좋다.
압축 도구의 결과 화면에는 파일 크기만 보여주지 말고 미리보기 영역도 함께 제공하는 편이 좋다. 사용자는 80% 감소라는 숫자보다 글자가 읽히는지 직접 보는 것을 더 신뢰한다.
투명 이미지는 포맷 이름보다 결과 확인이 중요하다
투명 PNG는 로고, 아이콘, UI 그래픽에 자주 쓰인다. 이런 파일은 이미 최적화된 경우가 많아 WebP로 바꿔도 감소 폭이 작을 수 있다. 더 중요한 것은 투명 영역이 유지되는지, 가장자리에 어색한 테두리가 생기지 않는지다.
const shouldUseWebP = webpFile.size < originalFile.size;
const result = shouldUseWebP ? webpFile : originalFile;이런 단순한 조건만 있어도 "압축했는데 더 커지는" 문제를 피할 수 있다. 단, 최종 판단에는 시각적 확인이 함께 있어야 한다.
정리
JPEG, PNG, WebP 비교는 포맷 순위를 정하는 일이 아니다. 이미지 유형에 따라 무엇을 보존해야 하는지 정하고, 그 기준에 맞춰 리사이즈와 변환을 적용하는 일이다. 사진은 용량 감소, 스크린샷은 가독성, 투명 그래픽은 알파 채널을 우선해서 확인해야 한다.
측정 표에는 조건을 반드시 같이 적는다
벤치마크 글에서 숫자만 나열하면 독자는 결과를 재현하기 어렵다. 같은 이미지를 어떤 최대 너비로 줄였는지, WebP 품질 값은 얼마였는지, 원본이 이미 압축된 파일인지에 따라 결과가 크게 달라진다. 그래서 표에는 원본 형식, 원본 크기, 리사이즈 후 픽셀 크기, 변환 형식, 품질 값, 결과 크기, 판단을 같이 적는 편이 좋다.
| 항목 | 기록 이유 |
|---|---|
| 원본 형식 | JPEG, PNG, WebP의 출발 조건이 다르면 비교 결과도 달라진다. |
| 픽셀 크기 | 리사이즈 효과와 포맷 변환 효과를 분리해서 볼 수 있다. |
| 품질 값 | 같은 WebP라도 품질 값에 따라 결과 크기와 체감 품질이 달라진다. |
| 판단 | 숫자만 보지 않고 실제 도구에서 선택할 결론을 남긴다. |
이런 기록 방식은 이미지 압축 구현 전체 가이드의 결과 선택 로직과 연결된다. 결과가 작다는 사실만으로 자동 채택하지 않고, 이미지 유형과 사용 목적을 같이 판단해야 한다.
압축률만 높은 결과는 실패일 수 있다
검색 유입을 기대하는 벤치마크 글이라면 "몇 퍼센트 줄었다"보다 "어떤 조건에서 추천할 수 있는가"를 더 분명히 말해야 한다. 예를 들어 사진은 70% 이상 줄어도 자연스럽게 보일 수 있지만, 코드 스크린샷은 30%만 줄어도 글자가 흐려지면 실패다. 반대로 투명 아이콘은 10% 감소라도 가장자리 품질이 유지된다면 충분히 의미가 있다.
따라서 결과 판단은 파일 크기, 미리보기 품질, 용도 세 가지를 함께 본다. 블로그 본문 이미지인지, 다운로드 파일인지, UI 아이콘인지에 따라 허용 가능한 손실 범위가 달라진다.
도구 기본값은 가장 공격적인 값이 아니라 가장 안전한 값으로 둔다
이미지 압축 도구의 기본값을 너무 공격적으로 잡으면 첫 사용 경험이 나빠진다. 사용자는 결과가 작아졌다는 사실보다 이미지가 망가지지 않았다는 확신을 먼저 원한다. 그래서 기본 품질 값은 극단적으로 낮추기보다 사진과 스크린샷에서 모두 무난한 수준으로 시작하고, 고급 사용자가 직접 낮출 수 있게 하는 편이 안전하다.
이 기준은 Canvas 이미지 리사이즈 품질 체크리스트와 함께 적용해야 한다. 품질 값만 낮추는 것보다 표시 목적에 맞는 리사이즈가 먼저이고, 그 다음에 포맷 변환과 품질 값을 조정하는 순서가 좋다.
