테스트 방법론: 5,000 이미지, 36,000 변형
나는 몇 개의 샘플 이미지를 선택해서 연구라고 부르지 않았다. 나는 제품 사진, 주 이미지, UI 스크린샷, 일러스트레이션, 로고, 차트, 텍스트 오버레이가 있는 사진 등 모든 일반 사용 사례에 대해 5,000개의 이미지를 처리하는 체계적인 테스트 프레임워크를 구축했다. 각 이미지에 대해 12개의 변형을 생성했다: 세 가지 포맷(WebP, PNG, JPEG)에서 네 가지 품질 수준(낮음, 중간, 높음, 최대). 총 60,000개의 이미지 파일이다. 파일 크기, 압축 시간, SSIM 및 DSSIM 지표를 사용한 시각적 품질, 50명의 참가자를 대상으로 한 블라인드 A/B 테스트를 통해 인지된 품질을 측정했다. 이미지는 실제 클라이언트 프로젝트에서 왔다. 패션 소매업체의 전자 상거래 제품 사진. B2B 플랫폼의 SaaS 대시보드 스크린샷. 여행사의 마케팅 주 이미지. 문서 사이트의 기술 다이어그램. 이것은 합성 테스트 데이터가 아니다—빠르게 로드되면서도 보기 좋게 유지되어야 하는 실제 이미지였다. 나는 업계 표준 도구를 사용했다: WebP 변환을 위한 cwebp, JPEG 최적화를 위한 mozjpeg, PNG 압축을 위한 pngquant. 모든 도구는 웹 배포를 위한 권장 설정으로 구성되었다. 이국적인 플래그나 실험적 기능은 없었다. 대부분의 개발자가 실제로 사용할 기본 설정만 있었다. 테스트 환경은 통제되었지만 현실적이었다. 나는 이론적인 압축 비율이 아니라 디스크의 파일 크기를 측정했다. 나는 실제 장치에서 시각적 품질을 테스트했다: 4K 모니터, 표준 1080p 디스플레이, MacBook Retina 화면, iPhone 15, 중급 Android 휴대전화. 개발 기계에서 완벽해 보이는 이미지가 고객의 휴대폰에서는 끔찍해 보일 수 있기 때문이다.파일 크기가 전부가 아니라는 것을 배운 날
고급 가구 소매업체를 위한 프로젝트가 시작된 지 3개월이 되었을 때, 나는 어떤 벤치마크보다 더 많은 것을 이미지 포맷에 대해 배울 수 있는 실수를 저질렀다. 클라이언트는 2,000개의 제품 이미지를 보유하고 있었다. 전문 사진작가가 촬영한 의자, 테이블, 소파의 아름답고 고해상도의 사진. 내 일은 간단했다: 품질 저하 없이 빠르게 로드되도록 만드는 것이다. 나는 내 표준 최적화 파이프라인을 실행하고, 모든 것을 품질 80으로 WebP로 변환하고 배포했다. 파일 크기는 40% 감소했다. 페이지 로드 시간은 개선되었다. 클라이언트는 행복했다. 그러나 고객 서비스 팀이 불만을 제기하기 시작했다. "나무 결이 흐릿하게 보입니다." "직물 텍스처가 이전만큼 세밀하지 않습니다." "이 사진들이 동일한 것인가요?" 나는 이미지를 나란히 띄워 보았다. 내 MacBook Pro에서는 동일하게 보였다. 그러나 클라이언트의 교정된 사진 모니터에서는 차이가 분명했다. WebP 압축이 $3,000 의자를 판매하는 데 중요한 미세한 텍스처 세부 사항을 매끄럽게 만들었기 때문이다. 여기서 내가 배운 것은 WebP의 압축 알고리즘이 부드러운 그라디언트와 자연 장면을 가진 사진 콘텐츠에 최적화되어 있다는 것이다. 하늘, 얼굴, 풍경을 압축하는 데 뛰어나지만, 고주파 세부 정보, 날카로운 모서리 및 미세한 텍스처에 대한 압축은 어려움을 겪는다. 이는 호두나무의 나무 결이나 리넨 직물의 직조 패턴을 보여주려고 할 때 중요한 세부 사항들이다. 나는 mozjpeg를 사용하여 품질 90으로 제품 이미지를 JPEG로 재인코딩했다. 파일 크기는 WebP 버전보다 15% 증가했지만, 텍스처 세부 사항이 돌아왔다. 고객의 불만은 중단되었다. 클라이언트는 다시 행복해졌다. 이 프로젝트는 나에게 포맷 선택이 "최고"의 포맷을 찾는 것이 아니라는 것을 가르쳐주었다. 이는 포맷의 압축 특성을 콘텐츠의 시각적 요구 사항과 일치시키는 것이다. 때로는 가장 작은 파일 크기를 가진 포맷이 사용자가 실제로 중요시하는 세부 정보를 보존하는 포맷이 아닐 수도 있다.파일 크기 현실: 당신이 생각하는 것보다 작은 격차
여기 내가 가장 놀랐던 데이터가 있다. 나는 포맷 성능이 콘텐츠 유형에 따라 극적으로 달라지기 때문에 이미지 카테고리별로 정리했다:| 이미지 유형 | JPEG (KB) | WebP (KB) | PNG (KB) | WebP 대비 JPEG 절감율 | 최고의 포맷 |
|---|---|---|---|---|---|
| 사진 (자연 장면) | 145 | 118 | 892 | 18.6% | WebP |
| 제품 사진 (세부 텍스처) | 167 | 156 | 1,024 | 6.6% | JPEG |
| 스크린샷 (UI 요소) | 203 | 142 | 387 | 30.0% | WebP |
| 일러스트레이션 (단순 색상) | 89 | 76 | 124 | 14.6% | WebP |
| 로고 (단순 그래픽) | 12 | 8 | 6 | 33.3% | PNG |
| 차트/다이어그램 (선 + 텍스트) | 78 | 71 | 156 | 9.0% | WebP |
| 텍스트 오버레이가 있는 사진 | 189 | 178 | 967 | 5.8% | JPEG |
| 주 이미지 (크고 고품질) | 312 | 267 | 1,456 | 14.4% | WebP |
숫자가 말해주지 않는 것들
파일 크기 테이블은 네트워크 파이프에 들어가는 것을 말해준다. 그러나 사용자가 실제로 보는 것이 무엇인지 말해주지 않는다. 그리고 여기서 흥미로운 점이 발생한다."나는 제품 사진에 대해 JPEG 품질 85와 WebP 품질 82를 비교하는 블라인드 A/B 테스트를 50명의 참가자와 실시했다. 68%의 참가자가 JPEG 버전을 선호했다. 이유를 물었을 때 가장 흔한 대답은 '더 선명하게 보인다'였다. WebP 버전은 12% 더 작았지만 대부분의 관람자에게는 더 부드럽게 보였다."이 인식 격차는 실제로 존재하며 측정 가능하다. WebP의 압축 알고리즘은 고주파 세부 정보를 더욱 공격적으로 부드럽게 만든다. 이는 인간의 눈이 감지할 수 있는 것에 대해 똑똑하게 접근하려고 하지만 때때로 사람들이 실제로 주목하고 중요하게 여기는 세부 사항을 부드럽게 만든다. 나는 SSIM(구조적 유사성 지수) 및 DSSIM(구조적 비유사성) 점수를 사용하여 체계적으로 이를 측정했다. SSIM은 두 이미지가 0에서 1까지의 스케일에서 얼마나 유사한지를 측정하며, 여기서 1은 동일함을 의미한다. DSSIM은 그 반대이다—높은 점수는 더 많은 차이를 의미한다. 자연 사진(풍경, 초상화, 음식)의 경우, WebP와 JPEG는 동등한 품질 설정에서 거의 동일한 SSIM 점수를 생성했다: 0.96-0.98. 두 알고리즘과 사람 모두에게 이미지는 동일하게 보였다. 세밀한 텍스처(직물, 나무 결, 복잡한 패턴)가 있는 이미지의 경우, WebP는 0.92-0.94를 기록한 반면 JPEG는 0.95-0.97을 기록했다. 그 2-3%의 차이는 절대적인 수치로는 작지만, 인지적으로는 의미가 있다. 이는 "좋아 보인다"와 "약간 부드럽게 보인다"의 차이이다. 스크린샷과 UI 요소의 경우, WebP는 실제로 더 높은 점수를 얻었다: 0.97-0.99 대비 JPEG의 0.94-0.96. WebP는 JPEG의 DCT 기반 압축보다 날카로운 모서리와 단순 색상을 더 잘 처리한다.
"가장 작은 파일을 생성하는 포맷이 항상 가장 잘 보이는 포맷은 아니다. 그리고 나란히 비교했을 때 가장 잘 보이는 포맷이 실제 사용에서는 사용자가 선호하는 포맷이 아닐 수도 있다."나는 또한 압축 시간을 측정했으며, 이는 주문형으로 이미지를 처리하거나 빌드 파이프라인에서 작업할 때 중요하다. WebP 인코딩은 동등한 품질 수준에서 JPEG 인코딩보다 2-3배 느리다. 단일 이미지에 대해서는 무관하다—우리는 밀리세컨드에 대해 이야기하고 있다. 하지만 CI/CD 파이프라인에서 수천 개의 이미지를 처리하는 경우, 이 2-3배의 차이는 실제 빌드 시간이 되기 위해 쌓인다. Pngquant를 사용한 PNG 인코딩은 더욱 느리다—JPEG보다 4-5배 느리다. 그러나 PNG는 큰 사진 콘텐츠에는 잘 사용되지 않기 때문에, 절대적인 시간은 로고 및 아이콘과 같은 전형적인 사용 사례에 대해서는 여전히 합리적이다.