JPEG XL, 정말 웹에 필요할까? AVIF 인코더 개발자가 반대하는 이유

들어가며

한때 '차세대 JPEG'로 불린 JPEG XL이 다시 주목받고 있습니다. 2023년 Chrome에서 지원이 철회됐지만, 최근 Rust 기반 JPEG XL 디코더가 Firefox와 Chrome에 조금씩 들어오고 있기 때문입니다.

그런데 AVIF 인코더를 직접 개발해 온 글쓴이는 여기에 반대 의견을 냈습니다. 흥미로운 점은 글쓴이가 Interop 2024에서 JPEG XL을 지지했던 사람이라는 것입니다. 어떤 이유로 생각이 바뀌었는지 차근차근 정리해 보겠습니다.

먼저 짚고 넘어갈 점이 있습니다. 이 글은 JPEG XL 설계자들의 역량을 깎아내리거나 특정 진영의 정치적 입장을 대변하려는 글이 아닙니다. 2026년 기준 이미지 압축 기술로 볼 때 JPEG XL이 웹 플랫폼에 맞는가를 따지는 글입니다.

핵심 요약 (TL;DR)

JPEG XL은 JPEG보다 확실히 발전한 형식이고 웹 밖에서는 매력적입니다.
하지만 웹에 가장 필요한 손실 압축 효율과 빠른 디코딩에서는 잘 최적화된 AVIF에 밀립니다.
무손실 압축, 점진적 렌더링, JPEG 재압축 같은 장점도 따져 보면 무조건적인 우위는 아닙니다.
새 Rust 디코더로 메모리 안전성이 좋아지는 것은 반가운 일이지만, 그것만으로 웹 도입의 타당성이 확보되지는 않습니다.

1. 무손실 압축이 결정적인 이유가 되기 어렵다

웹 이미지는 대부분 손실 압축으로 충분합니다. 사용자에게 필요한 것은 무손실 그 자체보다 비사진 이미지에서 JPEG가 만드는 심한 아티팩트를 피할 수 있는 코덱입니다.

인용된 연구에서 JPEG XL 무손실 파일은 무손실 WebP보다 약 11.9% 작았습니다.
그런데 테스트 데이터가 157MP 사진, 10MP 일러스트, 27MP 책 이미지여서 일반적인 웹 사용을 대표한다고 보기 어렵습니다.
무손실이 필요한 콘텐츠는 양이 적고 대역폭에도 덜 민감합니다. 그래서 약 12% 절감만으로 새 브라우저 코덱을 들이기는 어렵다는 것이 글쓴이의 판단입니다.

글쓴이는 SVT-AV1-PSY 작업에서 Julio Barba와 함께 AVIF를 개선했고, 자체 인코더를 설계하면서 여러 형식의 성능 한계와 최적화 가능성을 검토했습니다. 그 결과 JPEG XL을 택하지 않았다고 합니다.

2. 손실 압축에서는 이미 AVIF가 앞선다

출시 초기 JPEG XL의 큰 강점은 참조 인코더의 지각 품질 최적화였습니다. 지금은 사정이 다릅니다.

AV1 참조 인코더 libaom은 통제된 사람 대상 주관 평가로 지각 품질을 조정했고, 지각 지표에 맞춘 모드도 따로 있습니다. SVT-AV1에도 비슷한 모드가 있습니다.
그래서 '최신 인코더는 사람 눈에 맞춰 최적화되지 않았다'는 반론은 설득력이 약하다고 봅니다.
비교에는 Halide Compression이 개발 중인 Aperture 인코더(aperture-alpha)도 들어갔습니다. libjxl이 최신 인코더를 따라잡으려면 얼마나 더 좋아져야 하는지 보여 주기 위해서입니다.
CVVDP와 SSIMULACRA2는 완벽한 지표가 아니지만, 격차가 클 때는 의미 있는 신호를 줍니다. libaom의 사람 시각 최적화 모드(tune IQ)도 지표 최적화 모드(tune SSIMULACRA2)보다 점수가 몇 점 낮을 뿐입니다.
JPEG XL 참조 인코더의 지각 품질 이슈 가운데 상당수(이슈 414, 3881, 3616)도 아직 해결되지 않았습니다.

물론 벤치마크가 비교하는 대상은 형식이 아니라 인코더 구현입니다. JPEG XL 형식의 이론적 한계는 지금의 libjxl보다 높을 수 있습니다. 문제는 부호화 도구가 덜 직관적이고 잠재적으로 더 약해서, 잘 다듬어진 AVIF 인코더를 빠르게 넘어설 수 있을지 불확실하다는 점입니다.

3. 구조적 제약: 방향성 예측, 필터, 색 공간

방향성 예측이 없다

JPEG XL은 이미지를 2×2부터 256×256까지의 VarDCT 블록으로 나눈 뒤 주파수 표현으로 바로 변환합니다.
WebP 같은 블록 기반 코덱은 주변 픽셀로 블록을 예측하고, 원본과 예측의 차이만 변환합니다. 모드를 잘 고르면 비트를 크게 아끼고 경계도 더 잘 살릴 수 있습니다.
JPEG XL에서 대안으로 거론되는 **스플라인(spline)**은 인코더에서 활용하기가 훨씬 어렵습니다. 스플라인으로 나타낼 픽셀을 찾는 효율적인 알고리듬이 필요하고, 모든 후보를 율-왜곡 최적화(RDO)로 평가해야 합니다. 경계 보존에 쓴 개념 증명 구현도 아직 없습니다.

디블로킹 필터가 없다

JPEG XL에는 **디블로킹 루프 필터(DLF)**가 없습니다.
인루프 도구인 gaborish는 AV1의 루프 복원 필터와, EPF는 AV1의 CDEF와 가장 비슷합니다. 하지만 둘을 함께 써도 DLF를 완전히 대신하지 못합니다.
DLF를 잘 쓰면 JPEG XL에도 남아 있는 모스키토 노이즈를 줄일 수 있습니다.

XYB 색 공간의 효과는 기대보다 작다

지각 색 공간 XYB의 효율 개선은 초기 기대만큼 크지 않아 보입니다. 같은 색 공간을 쓰는 SSIMULACRA2로 평가해도 다른 형식에서 항상 이득이 나지는 않습니다.
현재 libjxl은 B 채널을 공격적으로 양자화해 색 보존 품질이 떨어지고, 새 인코더 개발자가 이를 일부러 되돌려야 합니다.

4. 비사진 이미지와 복잡한 패치 부호화

스크린숏이나 UI 이미지 같은 비사진 이미지에서 JPEG XL은 성능이 좋지 않습니다. 대안으로 제시되는 **패치(patch)**는 AV1의 **Intra Block Copy(IntraBC)**보다 다루기 어렵습니다.

'그런 이미지는 벡터로 만들면 된다'는 반론은 현실적이지 않습니다. 벡터로 표현할 수 있어도 실제로는 래스터인 이미지가 많고, 완벽하게 벡터화할 수도 없습니다.
AV1은 예측 블록을 원본에서 빼고 그 잔차를 변환 계수로 표현합니다.
JPEG XL에서 비슷한 효과를 내려면 잔차 프레임을 디코딩한 뒤 참조 패치를 블렌딩해야 합니다. 이 과정에서 레이어와 블렌딩까지 다뤄야 하고, 참조 프레임, 프레임 헤더, 자르기·블렌딩 정보, 패치 사전 항목, 좌표 같은 부가 정보가 붙을 수 있습니다.
반복 영역이 충분히 크거나 여러 번 재사용되지 않으면 이 부가 비용이 압축 이득을 상쇄합니다.
참고로 libjxl의 패치 기능은 성능 문제 때문에 effort 7 미만에서는 직접 켜야 합니다.

5. 풍부한 기능, 웹에서도 필요할까?

JPEG XL은 최대 4,096개 채널, 임의의 색 심도, 점진적 디코딩, JPEG 재압축까지 지원하는 유연한 명세를 갖췄습니다. 하지만 웹에 필요한 것은 비교적 단순합니다.

RGB/YUV와 알파를 담을 4개 채널
HDR을 표현할 적절한 색 심도 (글쓴이는 10비트면 충분하다고 봅니다)
빠른 로딩

점진적 렌더링은 AVIF도 지원한다

점진적 렌더링은 이미지가 다 도착하기 전에 저품질 미리보기를 먼저 보여 주는 기능입니다. AVIF 형식에서도 원래 가능했고, libavif에는 나중에 구현됐습니다.
AVIF가 이 기능을 지원하지 않던 시기에 그 중요성이 과장됐다는 것이 글쓴이의 시각입니다.
JPEG XL 정보 사이트의 비교를 보면, AVIF는 전체 용량의 약 2~3%만 받아도 JPEG XL보다 훨씬 먼저 알아볼 수 있는 이미지를 보여 줍니다. 전체 파일 크기도 AVIF가 더 작습니다.
다만 이 데모에서 AVIF는 브라우저 기본 디코더를 써서 Chrome에서만 작동하고, JPEG XL은 폴리필을 씁니다. JPEG XL을 지원하는 Safari도 점진적 디코딩은 지원하지 않습니다.

6. 디코딩 비용과 악용 가능성

JPEG 재압축은 공짜가 아니다

기존 JPEG를 JPEG XL로 무손실 재압축하면 흔히 약 20%의 용량 절감을 내세웁니다.
하지만 재압축한 파일은 디코딩이 약 33% 더 오래 걸립니다.

디코딩 속도 비교

같은 원본을 비슷한 크기로 인코딩했을 때 WebP(wpd 디코더)가 jxl-rs보다 10배 이상 빠르게 디코딩됐습니다. WebP 파일이 JPEG XL보다 90KB 이상 컸는데도 그렇습니다.

| 형식 | 파일 크기(바이트) | |---|---| | JPEG | 2,478,828 | | JPEG XL | 2,599,428 | | AVIF (10비트) | 2,649,949 | | WebP | 2,693,794 |

극단적인 입력이라는 위험

JPEG XL은 표현력이 높아서 디코딩에 극단적으로 오래 걸리는 이미지를 만들 수 있습니다.
예를 들어 33,599까지의 소수를 계산하는 이미지는 1,918바이트에 불과하지만, M5 Pro에서 Rust 디코더로 처리하는 데 사용자 CPU 시간 17.43초가 걸렸습니다.
이 디코더가 Chrome과 Firefox에 들어가면 저사양 기기에 부담을 주는 이미지를 쉽게 퍼뜨릴 수 있습니다. JPEG XL을 이미 기본 지원하는 Safari에서는 이런 이미지 수십 개를 한 페이지에 넣어 Apple 기기를 느리게 만들 수도 있습니다.

7. 웹 코덱은 목적이 좁고 효율적이어야 한다

글쓴이가 생각하는 웹 코덱의 조건은 세 가지입니다.

대역폭 절감
빠른 디코딩
사용자가 쉽게 문제를 일으키지 못하는 구조

이 기준에서 보면 WebP는 범위가 다소 좁았지만 방향은 옳았습니다. AVIF도 컨테이너나 4:2:0 업샘플링 규정 등 개선할 점이 있습니다. 그래도 AV1 덕분에 웹 도입이 보장됐고 매우 성숙한 생태계의 덕을 보고 있습니다.

반면 JPEG XL의 넓은 범용성은 웹 밖에서는 강점이지만 웹 적합성까지 보장하지는 않습니다. 새 형식이 늘어나면 이미지를 내려받아 다른 곳에서 쓰려는 사용자의 호환성 부담도 커집니다. WebP 하나 보급하는 데도 오래 걸렸는데, AVIF와 JPEG XL을 동시에 확산시킬 만큼 JPEG XL의 이점이 뚜렷하지 않다는 것이 글쓴이의 결론입니다.

3년 반 사이에 달라진 것

3년 반 전 글쓴이는 AVIF와 JPEG XL이 서로 다른 강점으로 공존하는 웹을 지지했습니다. 당시 JPEG XL은 중간~높은 충실도의 손실 압축에서 훨씬 강한 경쟁자였기 때문입니다. 지금은 AVIF가 전 충실도 구간에서 앞서면서 손실 압축에서 JPEG XL의 실질적인 강점이 사라졌다고 봅니다.

에디터 코멘트

이 글은 JPEG XL이 나쁜 기술이라고 말하지 않습니다. 웹이라는 특정 플랫폼에 맞는 도구인가를 묻는 글입니다. 사진 보관, 전문 이미징, 기존 JPEG 자산 관리처럼 웹 밖에서는 JPEG XL의 유연함이 여전히 큰 무기입니다.

다만 브라우저에 코덱을 넣는 일은 되돌리기 어려운 결정입니다. 압축 효율과 디코딩 속도, 보안과 악용 가능성, 생태계 부담까지 함께 따져야 합니다. 웹 이미지 형식을 고민하는 개발자라면 AVIF 인코더가 얼마나 발전했는지와 디코딩 비용을 직접 측정해 보기를 권합니다.

(원문은 이후 'JPEG XL의 선택권 확대와 웹 밖의 활용'을 다루는 부분에서 끊겨 있어, 해당 내용은 이 글에 담지 못했습니다.)

원문: https://news.hada.io/topic?id=33682