WebP vs AVIF vs JPEG: 2026년 어떤 이미지 포맷을 골라야 할까?
핵심 결론: AVIF는 WebP보다 20–30%, JPEG보다 30–50% 더 작습니다. WebP는 JPEG보다 약 25–35% 작습니다. AVIF의 인코딩 속도는 WebP보다 5–20배 느린 반면, 디코딩은 WebP가 셋 중 가장 빠릅니다. 2026년의 정답 워크플로는 AVIF를 우선 제공하고 WebP로 폴백하며 JPEG를 안전망으로 유지하면서, <picture> 요소로 브라우저가 직접 고르도록 하는 것입니다.
대다수 독자에게는 이 답으로 충분합니다. 더 흥미로운 질문은 언제 AVIF를 쓰지 말아야 하는가입니다. CI 예산이 빡빡하고 바이트보다 인코딩 시간이 더 중요한 경우에는 건너뛰십시오. 브라우저 측 AVIF 인코딩이 여전히 들쭉날쭉하므로 실시간 사용자 업로드 시에는 보류하십시오. iOS 16.0–16.3이나 옛 Edge를 반드시 지원해야 한다면 JPEG를 메인으로 두십시오. 그 외 환경에서는 AVIF가 파일 크기 면에서 이깁니다. 단, <picture> 마크업이 정확하고 CDN이 올바른 MIME 타입을 보내야 한다는 조건이 붙습니다.
이 가이드의 나머지는 실무 디테일입니다. 2026년 지원 현황 수치, 실제 사진을 사용한 벤치마크, 사용 사례별 결정 트리, 복사해 쓸 수 있는 <picture> 패턴, 변환 명령어, 그리고 팀의 시간을 잡아먹는 함정 네 가지. 변환 작업만 빠르게 끝내고 싶다면 무료 이미지 압축 도구가 JPEG, PNG, WebP, AVIF를 업로드 없이 브라우저 안에서 처리합니다.
1. 2026년 브라우저 지원 현황: WebP 97%, AVIF 93%
Edge가 AVIF를 도입한 지 2년 반이 지나면서 지원 격차는 전 세계 트래픽의 몇 퍼센트 수준으로 좁혀졌습니다. 이제 질문은 “지원되는가”보다 “남은 3%에게 무엇을 제공할 것인가”에 가깝습니다.
1.1 WebP: 안전한 기본값
WebP는 2012년 Chrome, 2019년 Firefox 65, 2018년 Edge 18, 2020년 Safari 14에 도입됐습니다. 2026년 5월 기준 caniuse는 전 세계 지원율을 약 97%로 집계합니다. 이제 WebP는 “현대적 대안”이라기보다 “쓸 만한 폴백”에 가깝습니다. JPEG가 아닌 단일 포맷 하나만 제공해야 한다면, WebP가 답입니다.
1.2 AVIF: 이제 메인 포맷으로 사용 가능
AVIF는 2020년 8월 Chrome 85, 2021년 10월 Firefox 93에 등장했습니다. Safari 16.4는 2023년 3월 macOS와 iOS에서 활성화했습니다. Edge는 가장 늦게 합류했고, 121(2024년 1월)에서야 디코드 지원을 추가했습니다. 2026년 5월 전 세계 커버리지는 약 93–95%입니다.
짚고 갈 부분 하나. iOS 16.0–16.3에는 알려진 AVIF 디코드 버그가 있어, 특정 이미지에서 Safari가 크래시될 수 있습니다. 해당 빌드는 기업 MDM에 묶인 기기에서 여전히 살아 있으므로, 작동하는 WebP나 JPEG 폴백 없이 AVIF만 제공하면 실제 장애로 이어질 수 있습니다. AVIF를 단독 메인이 아니라 폴백을 갖춘 메인으로 다루십시오.
1.3 빠른 호환성 표
| 포맷 | 전 세계 지원율 (2026년 5월) | 주요 한계 |
|---|---|---|
| JPEG | 100% | 가장 큰 파일 크기, 투명도 없음, HDR 없음 |
| WebP | ~97% | HDR 또는 10비트 색 미지원 |
| AVIF | ~93–95% | 느린 인코드, iOS 16.0–16.3 디코드 버그, Edge 121+ 필요 |
2. 핵심 차이: 압축, 속도, 기능
2.1 실제 사진 기준 압축 효율
동일한 원본을 사용한 벤치마크입니다. 4000×3000 풍경 사진, 원본 PNG 약 24 MB를 지각적으로 동등한 품질로 재인코딩한 결과는 다음과 같습니다.
| 인코딩 | 크기 | JPEG 베이스라인 대비 |
|---|---|---|
| JPEG q75 (mozjpeg) | ~2.1 MB | 0% (베이스라인) |
| WebP q75 (libwebp) | ~1.4 MB | 33% 작음 |
| AVIF q60 (libavif, cpu-used 4) | ~1.0 MB | 52% 작음 |
여기서 AVIF q60은 시각적으로 JPEG q80, WebP q75와 동등합니다. 품질 스케일은 코덱 간에 호환되지 않습니다. “JPEG q75를 AVIF q75로” 재인코딩하는 것은 초보자가 흔히 저지르는 실수입니다. 결과물은 원본과 똑같이 보이지만 파일이 비대해진 AVIF가 나옵니다.
2.2 인코딩 속도: 5–20배 세금
AVIF가 더 강하게 압축하는 이유는 더 많은 일을 하기 때문입니다. libavif를 기본 cpu-used 4로 사용하면 4000×3000 이미지가 libwebp보다 5–20배, mozjpeg보다 약 50배 오래 걸립니다. 이 비용은 CI 빌드, Lambda 콜드 스타트, 수천 개 자산을 재인코딩하는 파이프라인 전반에 누적됩니다.
탈출구는 두 가지입니다. 첫째, cavif --speed 9(또는 libavif cpu-used 9)는 파일이 5–8% 커지는 대가로 libwebp의 3배 이내까지 따라잡습니다. 둘째, 적극적인 캐싱입니다. 변경되지 않은 원본의 재인코딩을 건너뛰는 콘텐츠 어드레서블 자산 파이프라인은 느린 코덱을 일회성 비용으로 바꿔 줍니다.
2.3 색 깊이와 HDR
JPEG와 WebP는 8비트 sRGB가 한계입니다. AVIF는 10비트 및 12비트 색, Rec. 2020, DCI-P3, PQ/HLG 전달 함수를 네이티브로 처리합니다. HDR 비디오 썸네일이나 프로 사진 갤러리, 브라우저 측 인쇄 교정용으로는 오늘날 AVIF가 유일한 표준 옵션입니다.
2.4 투명도와 애니메이션
JPEG는 둘 다 없습니다. WebP와 AVIF는 알파와 애니메이션을 모두 지원합니다. 특히 투명 PNG 대체 용도에서 AVIF는 알파를 더 작게 인코딩합니다. WebP로 30–40% 줄어드는 UI 일러스트레이션이 AVIF로는 50–70% 줄어드는 일이 흔합니다.
3. 결정 트리: 어떤 작업에 어떤 포맷
3.1 정적 사이트: 블로그, 마케팅 페이지, 문서
AVIF 메인, WebP 폴백, JPEG 안전망. 인코딩이 CI에서 한 번만 일어나므로 5–20배 세금은 사용자 시간이 아니라 빌드 시간으로 지불됩니다. 4절의 3-소스 <picture> 패턴이 그대로 들어맞는 사례입니다.
3.2 사용자 업로드: 아바타, UGC, 폼 첨부
브라우저에서 WebP로 압축하고, 서버에서 비동기로 AVIF로 재인코딩. 브라우저 측 canvas.toBlob('image/avif')는 현재 Chrome 99+에서만 동작하므로 AVIF를 업로드 경로로 쓸 수 없습니다. WebP는 브라우저에서 빠르게 압축되고 업로드 자체의 대역폭도 줄여 줍니다.
클라이언트 라이브러리(Squoosh, browser-image-compression, Compressor.js)와 서버 측 Sharp나 Imagemin의 조합을 더 깊게 비교한 글로는 이미지 압축 가이드: 브라우저 vs Node.js가 있습니다. 포맷 선택과 처리 위치는 별개의 축이고, 이 가이드는 포맷 축을 다룹니다.
3.3 HDR과 고충실도 사진
오로지 AVIF. 현재 오픈 웹 스택에서 10비트나 12비트 색을 지원하는 다른 포맷은 없습니다. HDR 전용 자산은 폴백을 건너뛰거나, JPEG 폴백이 SDR로 떨어진다는 점을 받아들여야 합니다.
3.4 레거시 브라우저 비중이 큰 사용자층
JPEG 메인, WebP 선택, AVIF 없음. 정부 포털이나 일부 동아시아 기업 환경, 디바이스 꼬리가 긴 B2B 도구는 분석 도구에서 IE/구 Edge 트래픽이 5–10%로 잡히기도 합니다. WebP는 이제 안전하지만 AVIF는 아직 아닙니다.
3.5 실시간 CDN 전송
서버 측 libvips나 Sharp가 WebP를 스트리밍하고, AVIF는 백그라운드 워커가 생성해 캐시 히트 시 제공. 응답을 AVIF 인코딩에서 블로킹하지 마십시오. Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto가 이 패턴을 자동화합니다.
4. <picture> 폴백, 제대로 하기
<picture> 요소는 브라우저가 가장 잘 지원하는 소스를 직접 고를 수 있도록 만들어졌습니다. AVIF를 맨 앞에 두는 3계층 구조는 구형 클라이언트에서 깨지지 않으면서 가장 작은 바이트 예산을 제공합니다.
4.1 3계층 베이스라인
<picture>
<source srcset="/img/hero.avif" type="image/avif" />
<source srcset="/img/hero.webp" type="image/webp" />
<img src="/img/hero.jpg"
width="1200" height="800"
alt="Mountain landscape at sunset"
loading="lazy" decoding="async" />
</picture>짚어 둘 점이 몇 가지 있습니다. 브라우저는 <source> 요소를 위에서 아래로 훑으며 자신이 이해하는 type의 첫 번째 항목을 고릅니다. 나머지는 무시되고 다운로드되지 않습니다. <img> 태그가 실제로 렌더되는 요소이며, 어떤 소스가 선택되든 속성(alt, sizes, classes)을 그대로 상속합니다. 그리고 <img>의 width/height는 2026년에는 선택 사항이 아닙니다. 공간을 미리 예약해 누적 레이아웃 시프트(CLS)를 막아 줍니다.
폴드 위 이미지에는 loading="lazy"를 loading="eager" fetchpriority="high"로 바꾸십시오. LCP 이미지에 lazy-loading을 거는 것은 Core Web Vitals 점수를 자기 손으로 깎아 먹는 흔한 실수입니다.
4.2 반응형 + 포맷: 완전한 패턴
반응형 해상도까지 필요하다면, 각 <source> 안에서 srcset을 반복합니다.
<picture>
<source type="image/avif"
srcset="/img/hero-800.avif 800w,
/img/hero-1600.avif 1600w,
/img/hero-2400.avif 2400w"
sizes="(min-width: 1024px) 1600px, 100vw" />
<source type="image/webp"
srcset="/img/hero-800.webp 800w,
/img/hero-1600.webp 1600w,
/img/hero-2400.webp 2400w"
sizes="(min-width: 1024px) 1600px, 100vw" />
<img src="/img/hero-1600.jpg"
width="1600" height="900"
alt="Mountain landscape at sunset"
loading="lazy" decoding="async" />
</picture>맞습니다, 이미지 한 장당 9개의 파생 파일이 생깁니다. 이 규모에서는 빌드 단계가 사실상 필수입니다. 5.3절에서 어떤 도구를 끼워 넣을지 다룹니다.
4.3 대안으로서의 서버 측 Accept 협상
CDN이 지원한다면 콘텐츠 협상으로 마크업을 단일 <img> 태그까지 줄일 수 있습니다. 브라우저가 Accept: image/avif,image/webp,image/apng,*/*를 전송하면 CDN이 같은 URL에서 가장 잘 지원되는 포맷으로 응답합니다.
Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto, Lambda@Edge를 결합한 CloudFront가 모두 이 방식을 구현합니다. 트레이드오프는 분명합니다. HTML이 작아지고 이미지당 URL이 하나로 줄지만, CDN 락인이 생기고 로컬 디버깅이 어려워집니다. 실무에서 유용한 분할은 마케팅 페이지에는 CDN 협상, 결정적 동작이 중요한 제품 UI에는 명시적 <picture>입니다.
5. 포맷 간 이미지 변환 방법
5.1 업로드 없이 브라우저에서
일회성이거나 소량 배치라면 브라우저 안에서 끝내는 쪽이 가장 빠릅니다. 무료 이미지 압축 도구에 JPEG를 드롭하고 출력으로 WebP나 AVIF를 고르면 파일이 기기를 떠나지 않습니다. AVIF 입력은 어디서나 지원되며, AVIF 출력은 Chrome 85+에서 네이티브 브라우저 인코딩을 사용하고 아직 AVIF를 인코드할 수 없는 브라우저에서는 자동으로 WebP로 폴백합니다.
5.2 빌드 파이프라인용 명령어
프로덕션 파이프라인에서는 결정적 출력과 재현 가능한 빌드가 필요합니다. 다음 세 명령어가 실무에서 잘 동작합니다.
# AVIF: cavif (Rust, cargo 또는 brew로 간단히 설치)
cavif --quality 60 --speed 4 input.jpg -o output.avif
# WebP: cwebp (Google 공식 libwebp)
cwebp -q 75 -m 6 input.jpg -o output.webp
# 두 포맷 모두, 리사이즈 포함, libvips 사용 (배치에서 가장 빠름)
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]cavif --speed는 0(가장 느림, 가장 작음)부터 10(가장 빠름, 가장 큼)까지입니다. 야간 빌드라면 기본값 4가 균형이 잘 맞고, 속도가 바이트보다 중요한 PR 프리뷰에서는 9까지 올려도 됩니다.
5.3 빌드 파이프라인 통합
대부분의 정적 사이트 프레임워크는 이미 이 인코더들을 래핑하고 있습니다. 자신의 스택에 맞는 것을 고르십시오.
// Next.js — next.config.js
module.exports = {
images: {
formats: ['image/avif', 'image/webp'],
deviceSizes: [640, 828, 1080, 1200, 1920, 2400],
},
};// Astro — astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
image: {
service: { entrypoint: 'astro/assets/services/sharp' },
},
});// 프로그래매틱 방식 — Sharp (Node.js)
import sharp from 'sharp';
await sharp('input.jpg')
.resize({ width: 1600 })
.avif({ quality: 60, effort: 4 })
.toFile('output.avif');
await sharp('input.jpg')
.resize({ width: 1600 })
.webp({ quality: 75, effort: 6 })
.toFile('output.webp');약 5 KB 미만 아이콘이나 인라인 아바타, 이메일 헤더 같은 작은 자산은 네트워크를 완전히 건너뛰고 Base64 인코딩으로 데이터 URI에 인라인하는 편이 낫습니다. HTTP 요청 한 번을 HTML 몇 바이트와 맞바꾸는 셈이며, 보통 5 KB 미만에서는 이득입니다.
클라이언트 측과 Node 측 압축 라이브러리(Sharp, Squoosh, browser-image-compression) 사이에서 고민 중이라면, 이미지 압축 가이드: 브라우저 vs Node.js에 벤치마크와 트레이드오프가 더 자세히 정리돼 있습니다.
6. 함정과 오해
6.1 “AVIF가 항상 이긴다” — 스크린샷과 라인 아트는 예외
AVIF의 강점은 연속 톤 사진입니다. 선명한 텍스트가 있는 스크린샷이나 UI 캡처, 픽셀 아트에서는 같은 품질에서 WebP가 더 작은 파일을 만드는 경우가 잦습니다. AVIF의 디블로킹은 평탄한 색 영역에 미묘한 밴딩을 일으키기도 합니다. 양쪽으로 변환을 돌려 보고 자산 종류별로 승자를 고르십시오.
6.2 “무손실 WebP가 투명 PNG를 완벽히 대체한다” — 비슷하지만 동일하지는 않음
무손실 WebP는 실제로 PNG보다 작으며, 보통 약 26% 줄어듭니다. 함정이 하나 있습니다. “무손실”은 압축된 이미지 자체에 적용되지만, 인코더가 그래디언트가 큰 영역에서 알파 채널 반올림을 바꿀 수 있습니다. 의료 이미지나 아카이브 자산처럼 원본과 픽셀 단위로 일치해야 하는 자산은 PNG를 그대로 두십시오. 그 외 모든 경우에 무손실 WebP는 순이득입니다.
6.3 “.avif 파일을 그냥 업로드” — CDN이 그게 뭔지 모를 수도
오래된 nginx와 Apache 설정은 AVIF 이전 시대의 것입니다. /etc/nginx/mime.types에 image/avif avif;가 없으면 nginx는 AVIF를 application/octet-stream으로 제공합니다. 브라우저는 잘못된 Content-Type을 보고 이미지 렌더링을 거부한 뒤 조용히 JPEG로 폴백하므로 최적화 전체가 무효화됩니다. 배포 후 자산 URL을 curl로 받아 Content-Type 헤더를 확인하십시오. 5초의 점검이 “왜 프로덕션에서 AVIF가 깨졌지”라며 보내는 일주일을 막아 줍니다.
6.4 iOS 16.0–16.3 AVIF 크래시
일부 AVIF 파일은 iOS 16.0–16.3에서 Safari 디코드 크래시를 유발합니다. 이 버그는 16.4(2023년 3월)에서 수정됐지만, 기업 MDM과 더딘 OEM 업데이트가 구형 기기를 살려 둡니다. 완화책은 단순합니다. 같은 <picture> 안에 작동하는 WebP 소스 없이 AVIF만 출하하지 말고, AVIF를 <img>의 src에 직접 설정하지 마십시오. 4절 패턴을 따르고 있다면 이미 보호됩니다.
7. 2026 치트시트
| 시나리오 | 메인 | 폴백 | 인코더 |
|---|---|---|---|
| 정적 마케팅 페이지 | AVIF q60 | WebP q75 + JPEG q80 | CI에서 cavif + cwebp |
| 블로그 글과 문서 | WebP q75 | JPEG q80 | 무료 이미지 압축 도구 (수동) 또는 Sharp (빌드) |
| 사용자 업로드 | WebP (클라이언트 측) | JPEG (WebP 인코드 미지원 브라우저용) | browser-image-compression + AVIF용 서버 측 Sharp |
| HDR / 프로 사진 | AVIF 10비트 q70 | (없음 — SDR 폴백을 버리거나 AVIF 자체를 건너뜀) | cavif + libavif HEIF 모드 |
| 실시간 CDN 전송 | 협상 결과(AVIF 또는 WebP) | JPEG | Cloudflare Polish, Cloudinary f_auto, Vercel Image |
출하 전 두 가지를 다시 확인하십시오. CLS 방지를 위해 <img>에 width와 height를 항상 설정하십시오. 그리고 적어도 한 개의 AVIF 응답에서 프로덕션 Content-Type 헤더를 검증하십시오. 깨진 MIME 설정은 이 목록의 어떤 다른 실패보다도 자주 프로덕션에서 AVIF를 조용히 죽입니다.
자주 묻는 질문(FAQ)
2026년에도 JPEG 폴백이 여전히 필요한가요?
네. AVIF는 전 세계 사용자의 약 93%, WebP는 약 97%에 도달합니다. 즉 옛 Edge, Firefox 93 미만, iOS 16.4 이전, 그리고 iOS 16.0–16.3 버그 구간 등 작지만 실재하는 인구가 여전히 JPEG를 필요로 한다는 뜻입니다. 분석에서 해당 브라우저 트래픽이 사실상 0임을 입증할 수 있을 때만 JPEG를 빼십시오.
AVIF 인코딩이 느린데 CI 빌드를 빠르게 유지하려면 어떻게 하나요?
세 가지 레버가 있습니다. 첫째, cavif --speed 6 이상(기본값 4)을 써서 약 5%의 크기 증가와 약 3배 속도를 맞바꾸십시오. 둘째, GNU parallel이나 빌드 도구의 워커 풀로 코어 전반에 병렬화하십시오. 셋째, 콘텐츠 해시로 캐싱해 변경되지 않은 원본 이미지는 인코더를 완전히 건너뛰게 하십시오. 셋을 결합하면 보통 AVIF 빌드 시간이 WebP의 옛 단일 스레드 베이스라인보다도 짧아집니다.
WebP 디코딩이 정말 AVIF보다 빠른가요?
네. libwebp는 libavif보다 약 2–3배 빠르게 디코드하며, 저사양 모바일에서 격차가 더 벌어집니다. 성능 병목이 네트워크가 아니라 디코드(예: 저가 안드로이드 폰에서 긴 이미지 갤러리)라면 WebP가 더 나은 메인 포맷입니다. 대다수 웹 트래픽에서는 네트워크 절감 효과가 우세해 종합적으로는 AVIF가 여전히 이깁니다.
iPhone 사용자도 AVIF를 볼 수 있나요?
iOS 16.4(2023년 3월) 이상을 실행하는 iPhone은 Safari에서 AVIF를 네이티브로 지원합니다. iOS 16.0–16.3 기기에는 특정 AVIF 파일에서 Safari를 크래시시킬 수 있는 문서화된 디코드 버그가 있고, 그보다 옛 iOS 버전은 AVIF를 전혀 지원하지 않습니다. 영향을 받는 사용자도 무언가는 볼 수 있도록 <picture> 안에 WebP나 JPEG 폴백을 항상 함께 출하하십시오.
<picture>와 Accept 헤더 협상 중 무엇을 써야 하나요?
소규모 프로젝트는 명시적 <picture> 마크업이 유리합니다. 동작이 결정적이고, 로컬에서 디버깅할 수 있으며, 이미지당 HTML 80바이트 정도만 추가됩니다. 트래픽이 큰 사이트는 CDN 측 Accept 협상이 더 잘 맞습니다. 이미지당 URL 하나로 줄고, 포맷이 자동으로 업그레이드되며, CDN이 각 포맷을 별도로 캐싱합니다. 흔히 보이는 하이브리드는 앱 UI에는 <picture>, 마케팅 자산에는 CDN 협상을 쓰는 방식입니다.
PNG를 WebP로 변환했는데 왜 더 커졌나요?
거의 항상 원본 PNG가 이미 pngquant나 oxipng, ZopfliPNG로 빠듯하게 최적화돼 있고, 브라우저의 Canvas 기반 인코더가 그 도구들을 따라잡지 못하기 때문입니다. 최적화된 PNG 대신 원본(Photoshop 익스포트, 디자인 툴 마스터, RAW)에서 재인코딩하십시오. 최적화된 PNG가 유일한 원본이라면 그 PNG는 이미 거의 최적 상태이므로 그대로 두는 편이 낫습니다.
AVIF가 투명도를 지원하나요?
네. AVIF는 8비트에서 12비트까지의 풀 알파 채널을 지원하며, 알파 인코딩이 일반적으로 WebP보다 더 압축적입니다. 투명 PNG 일러스트를 AVIF로 변환하면 보통 50–70% 줄어드는 반면, WebP로는 30–40% 줄어듭니다. 픽셀 단위 무손실 출력이 필요하지 않은 모든 맥락에서 AVIF가 투명 PNG를 가장 강하게 대체합니다.
브라우저가 toBlob(‘image/avif’)로 AVIF를 네이티브 인코딩할 수 있나요?
현재로서는 Chrome 99+만 가능합니다. Safari와 Firefox는 AVIF를 디코드할 수 있지만 2026년 5월 기준 Canvas API로 인코드할 수는 없습니다. 클라이언트 측 AVIF 인코딩에는 현재 libavif-wasm이나 jsquash 같은 WebAssembly 라이브러리가 필요하고, 1–2 MB의 페이로드가 추가됩니다. 대부분의 프로덕션 스택은 브라우저에서 WebP로 압축하고 AVIF 생성은 서버 워커에 넘깁니다.