WebP vs AVIF 2026: 어떤 최신 포맷을 사용해야 할까?

JPG는 1992년부터 웹을 지탱해 온 포맷입니다. 사진 압축 성능이 무난하고 모든 환경에서 동작합니다. 문제는 30년간의 압축 연구가 훨씬 효율적인 알고리즘을 만들어냈다는 것입니다. 2026년에도 JPG를 계속 쓰는 것은 성능 향상의 기회를 포기하는 일입니다. 하루에 5만 건의 이미지를 제공하는 서비스라면, 포맷 선택 하나가 대역폭 비용과 페이지 로드 시간에 직접 영향을 줍니다.

WebP와 AVIF는 같은 질문에 대한 두 가지 답입니다. 어떻게 하면 JPG보다 품질 손실 없이 더 잘 압축할 수 있을까? 2010년 구글이 발표한 WebP는 현재 거의 모든 이미지 처리 라이브러리에 내장된 안정된 포맷입니다. 2019년 표준화된 AVIF는 AV1 비디오 코덱 기반으로 압축률이 훨씬 높지만 인코딩 비용도 상당합니다. JPG, PNG, WebP의 기본 선택 기준은 jpg-vs-png-vs-webp 가이드를 참고하세요.

어느 쪽이 더 낫다고 단정할 수 없습니다. 인코딩 예산, 사용자의 브라우저 환경, 서비스하는 이미지 유형이라는 세 가지 제약 조건에 어떤 포맷의 트레이드오프가 맞는지를 따져야 합니다.

사진 콘텐츠에서 AVIF는 동등한 지각 품질 기준으로 WebP보다 약 20~30% 더 잘 압축됩니다. 500KB JPG를 품질 매칭 변환하면 WebP는 약 350~380KB, AVIF는 약 250~290KB가 됩니다. 복잡한 자연 이미지일수록 차이가 커지고, 단순한 그래픽에서는 좁아집니다.

WebP의 JPG 대비 우위는 사진 기준 평균 약 26%(구글 발표 데이터)입니다. AVIF의 JPG 대비 우위는 동일 품질에서 40~50%에 달하는 경우도 있습니다. 스케일에서 이 차이는 의미가 큽니다. 매월 1TB의 JPG를 제공하는 CDN이라면, WebP로 전환 시 약 600GB, AVIF로 전환 시 약 540GB가 됩니다. WebP 대비 AVIF가 60GB를 추가로 절약합니다.

단색 그래픽, 로고, 일러스트에서는 상황이 다릅니다. 두 포맷 모두 무손실 모드에서 이 유형을 잘 처리하지만, WebP 무손실이 인코딩이 빠르고 디자인 도구 지원이 더 좋습니다. AVIF 무손실 압축도 경쟁력 있지만 실무에서의 사용 빈도는 낮습니다.

2026년 기준 WebP의 전 세계 사용자 지원율은 약 96%입니다(Can I Use 집계 데이터 기준). Chrome, Firefox, Safari(14 이상), Edge, 삼성 인터넷 등 모든 주요 브라우저가 WebP를 렌더링합니다. 나머지 4%는 거의 대부분 구형 기업 환경과 마이너 임베디드 브라우저입니다. 소비자 대상 서비스에서는 이제 JPG 폴백 없이도 WebP를 배포할 수 있는 수준입니다.

AVIF는 2026년 중반 기준 약 92~93%의 전 세계 지원율을 기록합니다. Chrome과 Edge는 2021년, Firefox는 2021년 말, Safari는 Safari 16(2022년)에서 AVIF 지원을 추가했습니다. 국내 환경에서는 네이버 앱 인앱 브라우저나 구버전 삼성 인터넷에서의 지원을 확인해볼 필요가 있습니다. 최신 카카오톡 미니앱 환경은 Chromium 기반이므로 AVIF를 지원합니다.

`<picture>` 요소에 AVIF를 첫 번째 소스로, WebP를 폴백으로 두면 99% 이상의 사용자를 커버할 수 있습니다. 브라우저는 지원하는 첫 번째 포맷만 요청하므로 대역폭 낭비가 없습니다. 최신 브라우저는 AVIF를, 약간 오래된 브라우저는 WebP를, 그 외는 JPG를 받습니다.

여기서 AVIF의 강점이 실질적인 비용으로 이어집니다. 참조 인코더 libaom으로 4MP 사진 한 장을 고품질 AVIF로 인코딩하는 데 5~30초가 걸릴 수 있습니다. 같은 품질의 WebP 인코딩은 libwebp 기준 0.1~0.5초입니다. 차이가 1~2 자릿수입니다. 수천 장의 이미지를 처리하는 빌드 파이프라인에서는 이 격차가 인프라 의사결정에 영향을 줍니다.

더 빠른 AVIF 인코더들이 이 간극을 어느 정도 좁혔습니다. Rust 기반의 cavif와 최신 libaom의 `--speed` 플래그를 쓰면 이미지당 1~3초에 인코딩할 수 있습니다. 파일이 약간 커지는 대가가 있지만요. Node.js의 Sharp는 SVT-AV1을 통해 AVIF 인코딩을 지원하는데, libaom보다 빠릅니다. 그래도 이미지 10,000장을 처리하는 데 8시간 이상이 걸릴 수 있습니다.

온디맨드 CDN 트랜스코딩에서 AVIF의 인코딩 비용은 컴퓨팅 비용 증가로 직결됩니다. Cloudflare Images, Imgix, Cloudinary 모두 AVIF를 지원하지만 WebP보다 변환 비용이 높습니다. WebP 트랜스코딩은 compute 비용이 저렴해서 많은 CDN이 기본 요금에 포함시킵니다.

HTML에서 올바른 프로덕션 패턴은 가장 효율적인 포맷을 먼저 나열하고 브라우저가 선택하게 하는 것입니다. `<picture>` 요소에 AVIF, WebP, JPG 순으로 소스를 나열하면 브라우저가 지원하는 첫 번째 포맷만 내려받습니다. Chrome 사용자는 AVIF, Safari 14 사용자는 WebP, 구형 환경에서는 JPG를 받습니다.

실제로 이미지마다 세 가지 포맷(AVIF, WebP, JPG)을 생성하면 스토리지와 빌드 시간이 세 배가 됩니다. 트래픽이 많고 이미지가 많은 사이트라면 대역폭 절감이 파이프라인 복잡성을 정당화합니다. 이미지가 50장 정도인 작은 사이트라면 WebP와 JPG 폴백만으로 충분하고, 증분적인 AVIF 절감은 미미합니다.

최신 이미지 최적화 프레임워크는 이것을 자동으로 처리합니다. Next.js Image, Astro의 Image 컴포넌트, Nuxt Image 모두 빌드 시 AVIF와 WebP 변형을 생성하고 Accept 헤더에 맞는 포맷을 제공합니다. 이런 프레임워크를 쓴다면 AVIF 지원은 구현 관점에서 사실상 무료입니다. 빌드 시간 비용만이 실질적인 고려사항입니다.

2026년 기준 대부분의 프로덕션 사이트에는 WebP를 기본 포맷으로, JPG를 폴백으로 쓰는 방식을 권장합니다. 빌드 파이프라인이 자동화되어 있고 이미지 볼륨이 크다면 `<picture>` 스택 최상단에 AVIF를 추가하세요. 20~30%의 추가 압축 절감은 스케일에서 실질적으로 누적되지만, 수동으로 관리하거나 인코딩 시간이 세 배로 늘어나는 상황이라면 그 가치를 정당화하기 어렵습니다.

개발 도구와 콘텐츠 파이프라인 측면에서는 실제 이미지로 벤치마크하는 것이 중요합니다. AVIF의 이점은 고디테일 사진에서 가장 크고 단색 그래픽에서 가장 작습니다. 이미지의 대부분이 흰 배경의 제품 사진이라면 AVIF가 유효합니다. UI 스크린샷과 다이어그램이 많다면 WebP 무손실이 더 나은 결과를 줄 수도 있습니다.

포맷 환경은 계속 발전하고 있습니다. 2027년이면 AVIF 인코딩 속도가 더 개선되고 CDN 지원이 완전히 표준화될 것입니다. 그러나 지금 결정해야 한다면 WebP는 안전하고, 인코딩이 빠르며, 광범위하게 지원됩니다. AVIF는 인프라를 갖춘 팀의 합리적인 다음 단계입니다.