JPEG XL에 대한 반론 — 웹 이미지 코덱으로서의 위치를 다시 묻다

본문

JPEG XL은 JPEG 위원회가 만든 로열티 프리 차세대 이미지 코덱으로, JPEG의 명백한 상위 호환이자 WebP보다 다재다능한 포맷입니다. 그러나 2023년 Chrome이 지원을 철회하면서 큰 논란이 됐고, 최근 Rust로 작성된 새 디코더(jxl-rs)가 Firefox와 Chrome에 일부 도입되면서 지원 재개 논의가 다시 불붙었습니다. AV1 인코더 작업 출신의 이미지 압축 엔지니어인 저자는 과거 Interop 2024에서 JPEG XL을 지지했고 포맷 저자들과도 교류해 왔지만, 직접 인코더를 만들 포맷을 고르며 JPEG XL을 제외했다고 밝힙니다. 이 글은 정치적 논쟁이 아니라 2026년 현재의 실증적 평가를 목표로 합니다.

왜 손실 압축이 판단 기준인가

웹 이미지 트래픽의 대부분은 무손실이 아니라 다용도 손실 압축으로 충분히 서빙됩니다. JPEG XL의 무손실 모드는 lossless WebP보다 약 11.9% 작을 뿐이고, 그마저 웹 기준으로 비현실적인 데이터셋(157MP 사진, 10MP 일러스트, 27MP 스캔 도서)에서 나온 수치입니다. 손실에서 경쟁력이 없다면 무손실 우위만으로 새 코덱을 브라우저에 올릴 근거가 되기 어렵다는 것이 저자의 판단입니다. 그리고 손실에서도 상황은 좋지 않습니다. AV1 레퍼런스 인코더와 SVT-AV1은 통제된 인간 시청 실험 기반의 지각 튜닝을 거쳤고, SSIMULACRA2와 CVVDP 같은 지각 메트릭 비교에서 libjxl은 AVIF 인코더들에 큰 차이로 뒤집니다. "코덱 벤치마크가 아니라 인코더 벤치마크"라는 반론, 즉 포맷의 천장은 더 높다는 주장에 대해 저자는 포맷 자체의 구조적 한계를 근거로 반박합니다.

JPEG XL의 구조적 한계

첫째, 방향성 예측(directional prediction) 모드가 없습니다. WebP 같은 블록 기반 코덱은 주변 데이터로 블록 픽셀을 예측한 뒤 잔차만 주파수 변환해 비트를 절약하지만, VarDCT 블록 기반의 JPEG XL은 이 경로가 없어 엣지 보존이 약합니다. 대안으로 제시된 스플라인(spline)은 어떤 픽셀을 스플라인으로 표현할지 판별하고 RDO로 검증해야 해서 인코더 구현이 훨씬 어렵고, 엣지 보존용 PoC조차 존재하지 않습니다. 둘째, 디블로킹 루프 필터(DLF)가 없습니다. gaborish와 EPF가 각각 AV1의 loop restoration, CDEF에 대응하는 도구로 거론되지만 둘을 합쳐도 정식 DLF를 대체하지 못해 모기 노이즈(mosquito noise)가 남습니다. 셋째, 지각 색공간 XYB는 직관에 기반한 설계로, libjxl이 B 채널을 공격적으로 양자화하는 방식에 의존하면서 색 보존이 떨어지는 문제가 있어 새 인코더 개발자가 이를 되돌려야 합니다. 넷째, 비사진 이미지에 취약합니다. 대안인 패치(patch)는 AV1의 Intra Block Copy보다 비트스트림 표현 비용이 커서, 레퍼런스 프레임·프레임 헤더·크롭·블렌딩 정보·패치 사전 항목·잔차 프레임까지 필요한 구조상 반복 영역이 크거나 여러 번 재사용되지 않으면 오버헤드가 절감분을 삼켜 버립니다. libjxl은 effort 7 미만에서 성능 문제로 패치를 기본 비활성화합니다. "벡터로 만들면 된다"는 반론에 대해 저자는 현실의 세계를 최적화 대상으로 삼아야 한다고 일축합니다.

디코딩 시간과 프로그레시브 렌더링

JPEG XL의 사양은 최대 4,096 채널, 임의 비트 심도, 프로그레시브 디코딩, JPEG 재압축 등 매우 유연하지만, 웹에 필요한 것은 4채널, HDR을 위한 10비트, 빠른 로딩 정도입니다. 프로그레시브 렌더링은 AVIF도 libavif를 통해 지원하며, JPEG XL 정보 사이트의 비교에서 AVIF는 전체 크기의 2~3% 시점에 이미 사용 가능한 이미지를 보여주면서 총 용량도 더 작았습니다. JPEG 무손실 재압축은 흔히 20% 절감으로 인용되지만 재압축된 JPEG은 디코딩이 약 33% 느려 "공짜"가 아닙니다. 동일 소스를 크기 맞춰 인코딩한 디코딩 속도 비교에서는 WebP가 JXL보다 90KB 이상 크면서도 jxl-rs 대비 10배 이상 빨랐습니다. 더 심각한 것은 표현력이 높은 사양 덕분에 악의적 이미지 제작이 가능하다는 점입니다. 33,599까지 소수를 계산하도록 만들어진 1,918바이트짜리 이미지가 M5 Pro에서 17.43초의 디코딩 시간을 소모했는데, 이 디코더가 Chrome과 Firefox에 들어가는 만큼 저사양 기기를 느리게 만드는 'JXL 폭탄'이 쉬워질 수 있고, Safari는 이미 네이티브 지원 중이라 지금도 가능하다고 저자는 경고합니다.

결론: 범용성은 웹 밖에서

저자는 웹 코덱은 대역폭 절감·빠른 디코딩·사고 방지라는 좁은 목적에 맞춰 설계돼야 한다고 봅니다. JPEG XL은 설계상 "모든 이를 위한 모든 것"을 지향하므로 웹에는 WebP보다도 맞지 않으며, 이미지 다운로드 후 활용의 호환성 문제까지 더한다고 지적합니다. 3년 반 전 "AVIF와 JPEG XL이 공존하는 웹"을 바랐지만, 이제 AVIF가 전 fidelity 구간을 지배하면서 JPEG XL의 실질적 우위는 사라졌다고 평가합니다. 또한 JPEG XL 지지 논의의 상당 부분이 기술적 우위보다 Google 중심 웹 생태계에서 개발자 선택권을 늘리려는 열망에서 나온다는 의견을 덧붙이며, JPEG XL은 Adobe 계열 도구, 카메라 제조사, 스마트폰 OEM 등 웹 밖 영역에서 번창할 수 있다고 마무리합니다.

Lobsters 반응

• @kangalio — JPEG XL의 가치는 깊이가 아니라 폭이라고 반박합니다. 알파 채널, 최대 10억×10억 픽셀, 32비트 비트 심도, 프로그레시브 디코딩, 애니메이션, 손실·무손실 겸용, 최대 4,096개 추가 채널, JPEG 무손실 변환까지 갖춘 포맷이며, 웹 이미지 전송을 극한 최적화하는 용도가 아니라 코덱 계측에 수십 시간을 쓰기 과한 모든 상황에서 쓰는 '만능 제너럴리스트' 기본값이라는 취지입니다.

원문: Lobsters / 번역·요약: Trawling