AVIF vs JPEG XL: 하나는 성공하고 다른 하나는 실패한 이유
JPEG XL은 의심할 여지 없이 더 나은 포맷입니다. 하지만 실제로 서비스에 적용할 수 있는 것은 AVIF입니다. 이러한 결과가 나타나게 된 짧은 역사적 배경을 알아봅니다.
AVIF를 사용하십시오. AVIF는 모든 주요 브라우저에서 지원되는 반면, JPEG XL은 그렇지 않기 때문입니다. 대부분의 기술적 지표에서 JPEG XL은 무손실 JPEG 트랜스코딩, 점진적 디코딩, 바이트당 뛰어난 화질을 제공하는 더 강력한 포맷입니다. 하지만 실질적인 관점에서 볼 때, 공개 웹에서는 배포가 불가능한 상태입니다.
Chrome은 2023년에 생태계의 관심 부족을 이유로 JPEG XL 지원을 제거했으며, Chrome 없이는 웹 이미지 포맷이 자리 잡을 수 없습니다. AV1 Image File Format (AVIF)은 브라우저 제공업체들이 이미 투자하고 있던 비디오 코덱인 AV1을 등에 업고 유리한 고지를 점했습니다. 더 나은 기술이 더 강력한 유통력을 가진 기술에 패배한 것이며, 이는 새로운 현상이 아닙니다.
두 포맷의 비교
JPEG XL은 인코딩 속도, 점진적 로딩, 무손실 JPEG 변환에서 우위를 점하고 있으며, AVIF는 배포를 결정짓는 유일한 기준인 브라우저 지원에서 승리했습니다.
| 기능 | AVIF | JPEG XL |
|---|---|---|
| 브라우저 지원 | 모든 주요 브라우저 | 제한적, Chrome 미지원 |
| 사진 압축률 | 우수함 | 우수함, 미세하게 더 나음 |
| 인코딩 속도 | 느림 | 빠름 |
| 점진적 디코딩 | 아니요 | 예 |
| 무손실 JPEG 트랜스코딩 | 아니요 | 예, 약 20% 더 작음 |
| 작은 파일에서의 성능 | 10 KB 미만에서 취약함 | 좋음 |
| 애니메이션 지원 | 예 | 예 |
무손실 JPEG 트랜스코딩 행은 웹이 잃어버린 기능입니다. JPEG XL은 기존 JPEG를 약 20% 더 작게 재포장하고 이를 완전히 동일한 원본 파일로 다시 변환할 수 있으므로, 아카이브를 아무런 리스크 없이 축소할 수 있었을 것입니다.
Chrome이 JPEG XL을 제거한 이유
Chrome은 생태계의 관심 부족, 기존 포맷 대비 제한적인 이점, 그리고 또 다른 디코더를 유지 관리하는 데 드는 비용을 이유로 들었습니다. 이 결정은 2022년에 발표되어 2023년에 적용되었습니다.
이 논리는 당시에도 논란이 많았고 지금도 마찬가지입니다. 지지자들은 측정 가능한 압축률의 우위와 여러 대형 이미지 퍼블리셔의 지원을 지적했습니다. 반론은 브라우저가 이미 비디오용으로 탑재한 디코더를 사용하여 AVIF가 이미 대부분의 이점을 제공하고 있다는 것이었습니다. 어느 쪽 의견이 맞든 간에, Chrome이 지원하지 않는 포맷은 대부분의 웹 트래픽에 서비스할 수 없습니다.
JPEG XL이 여전히 사용되는 곳
JPEG XL은 전문 사진 분야, 아카이브 저장소, 그리고 단일 벤더가 파이프라인을 제어하는 Apple 소프트웨어에서 살아남아 있습니다. Safari가 2023년에 지원을 추가하면서 Apple 플랫폼에서 이 포맷의 명맥이 유지되고 있습니다.
- 사진 아카이브는 손실 리스크 없이 저장 공간을 줄이기 위해 무손실 JPEG 트랜스코딩을 사용합니다.
- 전문 카메라 워크플로우는 높은 비트 심도와 넓은 색역 지원의 이점을 누립니다.
- Apple 플랫폼은 이를 디코딩할 수 있어 폐쇄형 생태계 내부에서 유용하게 쓰입니다.
- 의료 및 과학 이미지 분야는 무손실 모드와 점진적 디코딩을 가치 있게 여깁니다.
- 사용하기 위해 모든 브라우저에서 작동해야 하는 공개 웹에서는 사용되지 않습니다.
웹사이트에서 AVIF를 사용해야 하는 시기
가장 큰 사진에 AVIF를 사용하십시오. WebP 대비 20에서 30%의 용량을 절약할 수 있습니다. 이 장점은 이미지 크기가 클수록 커지며, 작은 그래픽에서는 사라집니다.
히어로 이미지, 전체 너비 배너, 사진 갤러리가 명확한 사용 사례입니다. 대략 10 KB 미만에서는 컨테이너 오버헤드가 압축 이득보다 크기 때문에 AVIF 파일이 WebP 파일보다 커지는 경우가 많습니다. 라이브러리를 크기별로 나누어 무거운 이미지에는 AVIF를 적용하고 나머지는 WebP를 적용하면, 인코딩 비용을 최소화하면서 대부분의 이점을 얻을 수 있습니다.
AVIF 인코딩 비용
AVIF는 WebP보다 인코딩 속도가 몇 배나 느리며, 이는 단일 이미지보다는 대량의 이미지를 처리할 때 문제가 됩니다. WebP로 변환하는 데 1초도 걸리지 않는 사진이 AVIF로는 몇 초가 걸릴 수 있습니다.
500장의 이미지 배치 작업에서는 그 차이가 분 단위로 벌어집니다. 이 비용은 이미지당 단 한 번만 지불하면 되며, 지원하는 모든 브라우저에서 디코딩은 빠르게 이루어집니다. 컴퓨터가 다른 작업을 하지 않을 때 대량 변환을 계획하고, 브라우저 탭을 전면에 띄워 두십시오. 브라우저가 백그라운드 탭의 리소스를 제한하여 작업을 크게 지연시키기 때문입니다.
AVIF를 안전하게 서비스하는 방법
이전 브라우저를 중단시키지 않고 AVIF를 사용하려면 다음 5단계를 따르십시오.
- 각 페이지에서 가장 큰 이미지(보통 히어로 배너 및 주요 사진)를 식별합니다.
- 각 이미지를 페이지에서 차지하는 너비로 줄이고, 고해상도 화면을 위해 두 배로 설정합니다.
- AVIF는 JPEG보다 낮은 수치에서도 디테일을 잘 유지하므로, 품질 설정을 60에서 70으로 하여 AVIF로 변환합니다.
- 동일한 원본을 두 번째 옵션으로 WebP로 변환하고, 원본 JPEG를 최종 폴백용으로 유지합니다.
- picture 요소를 사용하여 AVIF를 첫 번째, WebP를 두 번째로 배치하고 img 태그에 JPEG를 넣어 3가지 모두를 서비스합니다.
브라우저는 자신이 이해하는 첫 번째 포맷을 선택하므로 어디서도 깨지지 않습니다. 마크업을 작성하는 것이 대개 파일을 변환하는 것보다 더 오래 걸립니다.
다르게 작동하는 AVIF 품질 설정
AVIF 품질 60은 JPEG 품질 85와 비슷해 보이므로, 익숙한 수치를 그대로 적용해서는 안 됩니다. JPEG 습관을 AVIF에 적용하면 필요 이상으로 큰 파일이 생성됩니다.
사진의 경우 60에서 시작하여 조정해 보십시오. 특정 문제를 주의해야 하는데, AVIF는 공격적인 설정을 적용할 때 블록 현상이 생기기보다는 미세한 질감을 뭉개버리는 경향이 있어 잔디, 머리카락, 직물이 그림처럼 보일 수 있습니다. 이 아티팩트는 JPEG의 블록 현상보다 덜 거슬리며, 누군가 지적하기 전까지는 놓치기 쉽습니다.
포맷의 성패가 갈리는 방식
이미지 포맷은 기술적 우수성이 아니라 유통이 결정하며, 브라우저 제공업체가 유통을 제어합니다. 동일한 패턴이 WebP의 성공(Chrome이 탑재했기 때문)과 JPEG 2000의 실패(기술적으로 우수했음에도 불구하고)를 만들어냈습니다.
AVIF는 이미지보다는 비디오에 대해 내려진 결정 덕을 보았습니다. 브라우저 제공업체들은 스트리밍 비용을 줄이기 위해 이미 AV1에 투자했기 때문에, 동일한 디코더를 기반으로 하는 이미지 포맷을 추가하는 데 드는 비용이 거의 없었습니다. 반면 JPEG XL은 새로운 디코더, 새로운 유지 관리, 새로운 보안 영역이 필요했으며, 브라우저들은 그 이점이 이미 제공하고 있는 것에 비해 미미하다고 판단했습니다.
이것이 일반 사용자에게 영향을 미칩니까
아니요, 대부분의 사람들은 이미지 포맷을 직접 선택하지 않으며, 결정은 그들이 퍼블리싱하는 플랫폼에 의해 내려집니다. 이 논쟁은 자체적인 전송 방식을 제어하는 사이트 소유자, 사진작가, 개발자에게 중요합니다.
마켓플레이스, 소셜 네트워크 또는 호스팅형 사이트 빌더를 통해 글을 올리는 사람은 누구나 JPG 또는 PNG를 업로드하고 플랫폼이 알아서 재인코딩하도록 둡니다. 포맷 논쟁은 방문자가 다운로드하는 파일을 직접 제어할 때만 와닿는 문제이기 때문에, 웹 성능 토론에서는 지배적이지만 다른 곳에서는 보이지 않는 것입니다.
이것이 귀하의 라이브러리에 의미하는 바
무손실 마스터를 보관하고, AVIF와 WebP로 배포하며, 포맷 논쟁은 무시하십시오. 배포 포맷은 몇 년마다 바뀌지만 마스터 파일은 영구적으로 유용합니다.
전체 라이브러리를 배포 포맷으로 변환하고 원본을 삭제한 사람들은 이전에도 이 문제를 겪었습니다. 저장 공간은 카탈로그를 다시 촬영하는 것에 비해 저렴하므로, 가장 좋은 버전을 저장해 두고 웹의 트렌드가 바뀔 때마다 배포용 복사본을 생성하는 것이 실질적인 전략입니다.
JPEG XL이 돌아올까요
복귀하려면 Chrome이 결정을 번복해야 하지만, 그러한 계획을 암시하는 발표는 없습니다. Safari의 지원과 사진 소프트웨어의 지속적인 관심 덕분에 포맷이 완전히 사라지는 것은 막고 있습니다.
이전에도 더 나쁜 상황에서 복귀한 포맷들이 있었으므로 가능성은 열려 있습니다. 하지만 그 가능성을 염두에 두고 웹사이트를 구축하는 것은 현명하지 않습니다. 현재 배포에는 AVIF와 WebP를 사용하고, 마스터는 무손실 포맷으로 보관하십시오. 그러면 향후 새로운 포맷을 도입하는 것은 사이트 재구축이 아니라 단순한 배치 변환 작업이 될 것입니다.
라이브러리를 AVIF로 변환하기
기존 JPEG가 아닌 원본 마스터에서 변환하십시오. 손실이 있는 원본은 새 파일에 손상을 그대로 전달하기 때문입니다. AVIF 인코더는 실제 디테일과 구분할 수 없는 JPEG 아티팩트를 표현하는 데 비트를 낭비하게 됩니다.
최대 500개의 파일을 한 번에 추가하거나 ZIP 아카이브를 전달하면 전체 세트가 한 번에 인코딩됩니다. 모든 작업은 자체 프로세서를 사용하여 브라우저 내부에서 실행되므로, 사진 라이브러리, 클라이언트 작업물, 미공개 캠페인 자산이 서버로 전송되지 않습니다. 로컬에서 인코딩한다는 것은 대량의 배치 작업이 업로드 속도가 아니라 컴퓨터의 속도로 실행됨을 의미합니다.