WebP vs PNG: 어떤 포맷을 써야 할까?

전송 용량을 줄여야 하고 손실 압축을 허용할 수 있거나, 무손실 WebP가 해당 이미지에서 PNG보다 작다면 WebP를 선택하세요. 픽셀을 그대로 보존해야 하거나 편집·배포 과정이 PNG에 의존하거나, 실제 비교에서 PNG가 더 낫다면 PNG가 맞습니다. 두 포맷 모두 알파 투명도를 지원하므로 투명하다는 이유만으로 포맷이 결정되지는 않습니다.

확장자보다 압축 방식이 먼저다

WebP라는 확장자 안에는 서로 다른 두 선택지가 있습니다. 손실 WebP는 용량을 줄이기 위해 이미지 정보 일부를 버리므로 사진, 그라데이션, 질감이 복잡한 이미지에 잘 맞는 경우가 많습니다. 무손실 WebP는 원래 픽셀 값을 복원할 수 있어 압축 흔적이 생기면 안 되는 그래픽에 쓸 수 있습니다. WebP는 두 방식 모두에서 알파 채널을 지원하며, 색상 데이터는 손실 압축하면서 투명도를 유지하는 구성도 가능합니다.

PNG는 무손실 압축을 사용합니다. PNG 표준은 인덱스 색상, 그레이스케일, 트루컬러 래스터 이미지와 선택적 알파 채널을 정의합니다. 가장 작은 전송 용량보다 정확한 픽셀, 또렷한 경계, 기존 무손실 작업 흐름이 중요할 때 안정적인 선택입니다.

따라서 비교할 대상은 단순히 “WebP와 PNG”가 아니라 다음 둘 중 하나입니다.

• 렌더링 픽셀이 바뀌면 안 될 때: 무손실 WebP와 PNG
• 용량을 줄이기 위해 시각적 변화를 허용할 때: 손실 WebP와 PNG

이미지와 작업 흐름에 맞춰 고르기

• 사진과 질감이 많은 그림: 손실 WebP부터 시험하되, 실제 표시 크기에서 얼굴, 미세한 질감, 그라데이션, 대비가 강한 경계를 확인합니다.
• 스크린샷, 도표, UI 그래픽: PNG나 무손실 WebP부터 비교합니다. 글자와 1픽셀 선은 손실 압축 흔적이 더 쉽게 드러납니다.
• 투명 배경의 래스터 로고와 아이콘: PNG와 무손실 WebP를 비교합니다. 둘 다 알파를 지원하고, 색이 적은 단순한 PNG도 이미 효율적으로 압축될 수 있습니다.
• 편집용 원본이나 보관 파일: 제작 도구에서 손실 없이 다시 열 수 있는 포맷을 유지합니다. 배포 포맷이 원본을 대체할 필요는 없습니다.
• 현대 브라우저 밖에서도 쓰는 이미지: 편집기, 이메일 클라이언트, CMS, 네이티브 앱, 후속 처리 서비스까지 필요한 환경을 모두 확인한 뒤 바꿉니다.

Google 문서는 WebP의 손실·무손실 압축과 투명도 지원을 설명하고 자체 포맷 연구의 평균 용량 차이도 제시합니다. 이 수치는 참고 자료이지 모든 이미지에서 보장되는 절감률은 아닙니다. 이미지 내용, 해상도, 인코더 설정, 메타데이터에 따라 개별 결과는 반대로 나올 수 있습니다.

같은 원본으로 공정하게 비교하기

이미 압축된 WebP를 PNG로 되돌리거나 작은 PNG를 WebP로 바꾼 다음, 더 작은 쪽이 우수하다고 결론 내리면 안 됩니다. 반복 인코딩을 거치면 한쪽이 손상되었거나 이미 최적화된 상태에서 출발하게 됩니다.

1. 모든 결과물을 같은 비압축 원본 또는 가장 품질이 높은 원본에서 만듭니다.
2. 픽셀 해상도, 크롭, 방향, 색 처리, 알파 정보를 동일하게 유지합니다.
3. 메타데이터 정책도 맞춥니다. 두 파일에서 모두 제거하거나 동등한 메타데이터를 남깁니다.
4. 픽셀을 그대로 복원해야 한다면 PNG와 무손실 WebP를 먼저 비교합니다.
5. 손실을 허용한다면 품질 값 하나를 믿지 말고 손실 WebP 후보를 여러 개 만듭니다. 품질 숫자의 의미는 인코더마다 다릅니다.
6. 실제 CSS 표시 크기와 대표적인 밝은·어두운 배경에서 확인합니다. 글자, 경계, 반투명 픽셀은 확대해서 한 번 더 봅니다.
7. 선호하는 포맷에 유리한 이미지 하나가 아니라 대표 이미지 묶음으로 파일 바이트와 허용 가능한 품질을 기록합니다.

결과는 조건별로 달라도 됩니다. 사진은 손실 WebP, 일부 투명 그래픽은 무손실 WebP, 작거나 작업 호환성이 중요한 몇몇 이미지는 PNG가 될 수 있습니다. 사이트 전체에 하나의 규칙을 강제하는 것보다 이런 혼합 정책이 더 타당할 때가 많습니다.

바이트가 줄었다고 페이지가 자동으로 빨라지지는 않는다

이미지가 작아지면 네트워크 전송량을 줄일 수 있지만, 확장자를 바꾸는 것만으로 성능 지표가 개선되지는 않습니다. 이미지가 화면 아래에 있거나 이미 캐시되어 있을 수 있고, 페이지가 여전히 지나치게 큰 원본을 요청할 수도 있습니다. 레이아웃, 요청 우선순위, 렌더링 작업이 체감 성능을 좌우하는 경우도 있습니다.

최종 파일은 실제 배포할 페이지에서 시험하세요. 반응형 이미지 마크업이 알맞은 해상도를 보내는지, 표시 공간을 미리 확보해 레이아웃 이동을 막았는지 확인하고, 실제 전송량과 관련 페이지 지표를 비교합니다. 필요한 외관을 유지하면서 실제 전달 경로가 나아질 때만 WebP 결과물을 채택하면 됩니다.

1차 출처

• Google WebP 포맷 개요
• W3C PNG 표준 제3판