06 · 모던 코덱 — WebP / AVIF
이 문서가 답하는 질문: WebP(VP8 기반)와 AVIF(AV1 키프레임)는 JPEG와 무엇이 다르고, 왜 인코딩이 느리며, 언제 어느 것을 써야 하는가?
한 줄 답 (Pyramid Top)
WebP와 AVIF는 모두 비디오 코덱의 키프레임을 이미지로 추출한 포맷이다. 비디오 코덱은 30년간 발전한 공간 + 시간 압축 기술의 누적이라, 이미지 전용 JPEG보다 더 강력한 공간 압축을 가진다. 대신 인코딩 비용이 5~10배 비싸고, 작은 파일에서는 이득이 줄어든다.
Why — 왜 비디오 코덱을 이미지에 썼나
코덱 발전의 진짜 동력은 비디오 — Netflix·YouTube·Disney가 매년 페타바이트의 트래픽을 줄이려고 코덱에 투자. 그 결과:
| 시기 | 비디오 코덱 | 키프레임 → 이미지 포맷 |
|---|---|---|
| 1992 | MPEG-1/2 | (이미지 별도) — JPEG |
| 2003 | H.264/AVC | (사용 안 함) |
| 2010 | VP8 | → WebP (2010) |
| 2013 | H.265/HEVC | → HEIF (2017) |
| 2018 | AV1 | → AVIF (2019) |
핵심 통찰: 비디오의 인트라 프레임(I-frame) 압축 = 이미지 압축. 비디오 코덱이 JPEG보다 똑똑한 이유:
- 더 큰 변환 블록 (4×4 ~ 64×64까지 적응적)
- 방향성 인트라 예측 (이전 픽셀에서 33+ 방향으로 예측)
- CABAC / CDF 산술 코딩 (Huffman보다 5~15% 효율)
- 루프 필터 (블록 경계 부드럽게)
How — WebP와 AVIF의 내부
1) WebP (2010)
- 인코더: VP8 (lossy) / VP8L (lossless)
- 컨테이너: RIFF (Microsoft가 만든 단순 박스 포맷)
- 변환 블록: 4×4 (DCT) / 16×16 (예측)
- 인트라 예측: 6 방향 (V, H, DC, TM, …)
- 엔트로피: Boolean Arithmetic Coding
- 알파: 별도 lossless 채널 또는 lossy
- 약점: 8bit only, HDR 없음, 인트라 모드 적음
WebP lossless(VP8L)은 PNG와 다른 접근:
- LZ77 (반복 매칭)
- Color cache (자주 쓰는 색 캐싱)
- Color transform (RGB의 채널 간 상관 제거)
- → PNG보다 ~26% 작음
2) AVIF (2019)
- 인코더: AV1 (Alliance for Open Media, 2018)
- 컨테이너: ISOBMFF (HEIF와 동일)
- 변환 블록: 4×4 ~ 64×64
- 인트라 예측: 56가지 방향 + CFL(Chroma From Luma) + Palette + IntraBC
- 엔트로피: Daala range coder (CDF 기반 산술 코딩)
- 루프 필터: Constrained Directional Enhancement Filter (CDEF) + Loop Restoration
- 알파: 별도 모노크롬 AV1 트랙
- HDR: 10/12bit, PQ/HLG, Rec.2020
핵심 차이: 블록 크기가 64×64까지 커진다 → 단조로운 영역(하늘, 잔디)을 한 블록으로 처리 가능 → 압축률 폭증.
3) 인코딩 비용 — 왜 AVIF가 느린가
JPEG 인코더는 결정론적 1-pass:
- DCT → 양자화 → Huffman (변경점 없음)
AVIF 인코더는 탐색 문제:
- 4×4부터 64×64까지 블록 분할 조합 탐색
- 각 블록에 56가지 인트라 예측 방향 시도
- 변환 종류 16가지 (DCT, ADST, FLIPADST, IDTX) 조합
- 각 조합의 RD(rate-distortion) cost를 비교해 최적 선택
→ 전수 탐색하면 우주가 끝나기 전까지 못 끝남. 그래서 인코더는 speed preset으로 탐색 깊이를 제한.
| Preset (libaom-av1) | 시간 (1080p 1장) | 품질 |
|---|---|---|
cpu-used 0 (best) | 60s+ | 최고 |
cpu-used 4 | 4s | 고품질 |
cpu-used 6 | 1.5s | 보통 |
cpu-used 8 (fastest) | 0.4s | JPEG 수준 |
SVT-AV1, rav1e는 더 빠른 AV1 인코더 — Netflix와 Mozilla가 각각 개발.
What — 구체 비교
1) 압축률 비교 (1920×1080 풍경 사진)
| 코덱 | 품질 옵션 | 파일 크기 | SSIM | 인코딩 |
|---|---|---|---|---|
| JPEG (mozjpeg q=85) | 표준 | 285 KB | 0.972 | 0.3s |
| WebP (q=85) | cwebp | 195 KB (-32%) | 0.972 | 0.5s |
| AVIF (cpu=6, q=63) | aomenc | 145 KB (-49%) | 0.972 | 1.5s |
| AVIF (cpu=4, q=63) | aomenc | 130 KB (-54%) | 0.972 | 4.5s |
| HEIF (HEVC q=70) | x265 | 150 KB (-47%) | 0.972 | 2.0s |
2) 작은 이미지에서 이득이 줄어든다
| 원본 크기 | JPEG | WebP | AVIF | AVIF 이득 |
|---|---|---|---|---|
| 50 KB | 50 KB | 38 KB | 35 KB | -30% |
| 200 KB | 200 KB | 145 KB | 110 KB | -45% |
| 1 MB | 1 MB | 700 KB | 500 KB | -50% |
이유: AVIF의 컨테이너 오버헤드(ISOBMFF 박스, 헤더)가 약 3~5KB 고정. 50KB 이미지에서는 5KB 오버헤드가 10%라 이득이 적음.
3) 디코딩 비용
| 코덱 | 디코딩 시간 (1080p) | 메모리 | 하드웨어 가속 |
|---|---|---|---|
| JPEG | 25 ms | 8 MB | 일부 (JPEG hardware) |
| WebP | 30 ms | 10 MB | 거의 없음 |
| AVIF | 80 ms | 15 MB | 점진적 (AV1 디코더) |
| HEIF | 60 ms | 12 MB | iPhone/Mac 전용 |
→ 모바일에서 AVIF 100장 동시 디코딩 = JPEG보다 3배 느림.
4) 호환성 (2026.05)
| 코덱 | 첫 지원 | iOS Safari | Chrome Android | Edge | Firefox |
|---|---|---|---|---|---|
| WebP | 2010 | iOS 14 (2020) | Android 4.0+ | 2018 | 65 (2019) |
| AVIF | 2019 | iOS 16.4 (2023.03) | 105 (2022) | 121 (2024) | 113 (2023) |
| HEIF | 2015 | iOS 11 (2017) | X | X | X |
iOS Safari AVIF의 역사:
- iOS 16.0 (2022.09): AVIF 지원 발표 — 그러나 애니메이션 미지원
- iOS 16.4 (2023.03): 본격 지원 — animated AVIF 포함
- iOS 17 (2023): 성능 개선
- → 2026년 현재 iOS 16.4 미만 사용자 ~3% — 여전히 fallback 권장
5) <picture> 패턴
<picture>
{/* 1순위: AVIF (가장 작음) */}
<source type="image/avif" srcset="hero.avif">
{/* 2순위: WebP (iOS 14+) */}
<source type="image/webp" srcset="hero.webp">
{/* 폴백: JPEG (모든 환경) */}
<img src="hero.jpg" alt="..." loading="lazy">
</picture>중요: 브라우저가 type을 알면 파일을 다운로드하기 전에 fallback 결정. 그래서 type 명시가 필수.
6) Content Negotiation (서버 협상)
GET /image.jpg
Accept: image/avif,image/webp,image/jpeg,*/*;q=0.8서버는 Accept 헤더를 보고 동적으로 AVIF/WebP/JPEG 중 선택해 반환.
- 장점: HTML 변경 불필요
- 단점: CDN 캐시 분기 (Vary: Accept), 서버 인코딩 부담
- 사례: Cloudflare Polish, Cloudinary, imgix
What-if — 함정과 대응
함정 1) AVIF 인코딩이 너무 느려서 빌드 시간 폭증
증상: Next.js next/image가 AVIF 자동 생성 → 빌드 30분.
대응:
cpu-used 6~8로 빠른 프리셋- 빌드 시 인코딩이 아닌 요청 시 인코딩 + CDN 캐시
- Cloudflare Images / Vercel Image Optimization 같은 외부 서비스
함정 2) animated AVIF가 iOS 16.0~16.3에서 깨짐
증상: iOS 16.0에 출시한 앱에서 GIF→AVIF 변환한 파일이 깨짐.
대응: User-Agent 분기 또는 <picture> fallback.
함정 3) AVIF 8bit가 JPEG보다 클 때
증상: 작은 아이콘(50KB 이하) AVIF가 JPEG보다 큼.
원인: 컨테이너 오버헤드.
대응: 작은 이미지는 JPEG/WebP, 큰 이미지만 AVIF.
함정 4) WebP 무손실이 PNG보다 큰 경우
증상: 단순 다이어그램 PNG=20KB → WebP lossless=23KB.
원인: PNG의 DEFLATE가 반복 패턴에 매우 강함. WebP는 자연사진에 최적화.
대응: 도구별로 비교 (cwebp -lossless vs oxipng)해서 작은 쪽 채택.
함정 5) AVIF 색공간 메타 누락
증상: AVIF가 sRGB로 디코딩되어야 하는데 색이 진하게 나옴.
원인: AVIF의 colr 박스에 NCLX가 잘못 설정됨.
대응:
# avifenc 명시적 설정
avifenc -q 60 \
--cicp 1/13/6 \ # primaries=BT.709, transfer=sRGB, matrix=BT.601
input.png output.avifInsight — 비디오 코덱이 이미지를 잡아먹는 시대
“AVIF는 AV1의 부산물이다”
2018년 AOMedia가 AV1을 발표할 때 이미지 파일 포맷은 부수적 목표였다. 그러나 Netflix/Google이 이미 AV1 인프라를 갖고 있어서 키프레임만 추출하는 AVIF가 한 달 만에 만들어짐. 비디오 인프라가 있으면 이미지 코덱은 공짜로 따라온다 — 이게 AVIF가 차세대로 자리잡은 배경.
“libwebp가 WebP를 살렸지만 죽이기도 했다”
Google의 libwebp는 안정적이고 빠른 reference 구현 → WebP 보급에 결정적. 그러나 2010년 이후 VP8 자체가 거의 발전이 없어서 압축률이 정체. AVIF가 등장한 2019년부터 WebP는 과도기 포맷이 됨. 2022년 libwebp의 heap overflow 취약점(CVE-2023-4863)이 모든 Chromium에 영향 → 보안 책임의 무게도 드러남.
“AVIF의 인코더 전쟁”
AV1은 표준이지만 인코더는 4가지가 경쟁:
인코더 개발자 특징 libaom 참조 구현, 가장 좋은 압축, 가장 느림 SVT-AV1 Netflix + Intel 멀티스레딩 우수, 실시간 가능 rav1e Mozilla + Xiph Rust 구현, 안정성 우선 EVE-AV1 Two Orioles 상용, 최고 품질 (~10% 더 작음) 같은 AVIF 파일도 인코더에 따라 ±15% 크기 차이.
“HEIF는 갈라파고스가 됐다”
Apple이 2017년 iOS 11에서 HEIF를 기본 카메라 포맷으로 채택. 그러나 HEVC의 라이선스 문제로 비-Apple 환경에서 디코더 보급 실패. iPhone 사용자가 HEIF 사진을 카톡/슬랙에 보내면 받는 사람이 못 봄 → 시스템이 자동 JPEG 변환. AVIF가 결국 HEIF의 자리를 차지할 가능성.
한 단락 요약
WebP와 AVIF는 비디오 코덱의 인트라 프레임을 이미지화한 포맷이고, 더 큰 블록 + 더 많은 인트라 예측 + 더 좋은 엔트로피 코딩으로 JPEG의 30
50% 크기를 만든다. 대신 인코딩이 510배 비싸고, 작은 이미지에서는 컨테이너 오버헤드가 커진다. iOS Safari AVIF 16.4 지원과 함께 2024년부터<picture>3단 fallback이 사실상 표준.