JPEG XL(JXL)은 기술적으로 인상적인 이미지 코덱이다. 기존 JPEG를 확실히 대체할 만하고, WebP보다 유연하며, 웹을 넘어선 다양한 용도까지 감당할 수 있다. 그럼에도 2023년 크롬에서 지원이 거부되면서 논란의 중심에 섰다. JPEG 위원회가 내놓은 로열티 프리 코덱이자 압축 효율이 좋고 대기업의 관심까지 받던 포맷이 밀려났기 때문에, 이 결정은 많은 이들에게 납득되지 않았다. 최근 러스트로 작성된 JXL 디코더가 파이어폭스와 크롬에 일부 형태로 들어가면서, 2023년 WebP 취약점 사태의 재현을 막을 수 있다는 기대와 함께 주요 브라우저 진영이 입장을 바꾸는 것 아니냐는 관측도 나온다. 그러나 안전한 디코더 하나가 웹에서 JXL을 정당화하기에 충분한지는 별개의 문제다.
이 글의 필자는 원래 영상 압축을 하다가 이미지 압축으로 넘어온 엔지니어로, 과거에는 모든 용도에서 JXL을 지지했고 Interop 2024에서도 이를 추천했다. 포맷 저자들의 태도와 기술적 역량을 높이 평가한다는 점도 분명히 한다. 그럼에도 자신의 인코더를 직접 만들기로 했을 때, 여러 포맷의 잠재력과 최적화 가능성, 현재와 미래의 효용을 저울질한 끝에 JXL을 선택하지 않았다고 밝힌다. 이 글은 저자나 그 작업을 깎아내리려는 것이 아니라, 2026년 현재 이미지 압축과 웹 플랫폼의 상태를 경험적으로 짚으려는 교육적 성격의 글이다.
무손실 우위와 인코더 성능
핵심 논지는 웹 트래픽의 대부분이 유연한 손실 압축만으로 충분하다는 데서 출발한다. 평균적인 웹 소비자에게는 무손실이 필요하지 않고, 비사진 콘텐츠에서 심각한 아티팩트를 내지 않을 만큼 유연한 손실 코덱이면 된다. 이 지점에서 JXL의 무손실 강점은 설득력을 잃는다. 실제 측정에서 JXL의 무손실은 WebP 무손실보다 약 11.9% 작을 뿐이고, 그마저도 157메가픽셀 사진과 10메가픽셀 일러스트, 27메가픽셀 서적 이미지처럼 웹 현실과 동떨어진 데이터셋에서 나온 수치다. 대역폭에 덜 민감한 소량의 콘텐츠에서 12%를 아끼자고 새 코덱을 브라우저에 들이는 것은 합당하지 않다는 것이다.
한때 JXL의 강력한 근거였던 '레퍼런스 인코더의 뛰어난 지각 최적화'도 지금은 유효하지 않다. AV1 레퍼런스 인코더는 통제된 주관적 인체 실험을 바탕으로 지각 튜닝을 받았고, SVT-AV1도 유사한 튜닝 모드를 갖췄다. CVVDP와 SSIMULACRA2 같은 강력한 지각 메트릭에서 JXL이 뒤처지는 폭이 크다는 점은 단순한 지표의 한계로 넘기기 어렵다. 포맷의 이론적 상한은 libjxl이 현재 도달한 수준보다 높을 수 있지만, 덜 직관적이고 잠재적으로 약한 코딩 도구를 감안하면 그 격차를 빠르게 좁혀 잘 최적화된 AVIF 인코더를 앞지르리라 확신하기 어렵다는 것이 필자의 판단이다.
유연성이라는 이름의 부담
JXL의 명세는 최대 4096채널, 임의의 색심도, 프로그레시브 디코드, JPEG 재압축 등 놀랄 만큼 유연하다. 문제는 이 대부분이 웹에서는 필요 없다는 점이다. 웹에는 RGB/YUV와 알파를 위한 4채널, HDR을 위한 합리적 색심도(10비트면 충분), 그리고 빠른 로딩이면 족하다. 프로그레시브 렌더링은 한때 AVIF에 없다는 이유로 JXL의 강점처럼 부풀려졌지만, libavif가 이를 구현한 지금은 논쟁이 사실상 끝났다. JXL 정보 사이트의 자료에서도 AVIF는 전체 용량의 2~3% 수준에서 이미 쓸 만한 이미지를 보여주며, 전체 용량 또한 더 작다. 게다가 AVIF의 프로그레시브 디코드는 크롬의 네이티브 디코더로 동작하는 반면, JXL은 지원 환경인 사파리에서조차 폴리필에 의존한다.
자주 인용되는 JPEG 재압축의 20% 절감도 공짜가 아니다. 재압축된 JPEG는 디코드에 약 33% 더 오래 걸린다. 실제로 동일 원본을 비슷한 용량으로 맞춘 비교에서 WebP는 JXL보다 90KB 이상 큰데도 러스트 디코더(jxl-rs)보다 10배 넘게 빠르게 디코드됐다. 흔히 느리다고 여겨지는 AVIF조차 JXL 앞에서는 빠른 편이다.
표현력이 낳은 위험
디코드 속도만의 문제가 아니다. JXL의 높은 표현력은 악용의 여지를 남긴다. 필자는 33,599까지의 소수를 계산하도록 만든 1,918바이트짜리 이미지가 M5 Pro에서 러스트 디코더로 17.43초의 사용자 시간을 잡아먹는 사례를 든다. 바로 이 디코더가 크롬과 파이어폭스에 들어가고 있으며, 사파리는 이미 JXL을 네이티브로 지원하는 만큼 저사양 기기를 겨냥한 이른바 'JXL 폭탄'을 심는 일이 손쉬워진다. 웹 코덱은 목적에 맞게, 효율적이고 좁게 설계되어야 한다는 것이 필자의 관점이다. WebP는 다소 좁게 설계됐지만 방향은 옳았고, AVIF는 AV1 생태계의 성숙함이라는 든든한 배경을 가졌다. 반면 '모두에게 모든 것'을 지향하도록 설계된 JXL은 대역폭 절감, 빠른 디코드, 안전성이라는 웹의 요구에 WebP만큼도 맞지 않는다.
다만 이는 JXL이 쓸모없다는 뜻이 아니다. AVIF와 JXL은 근본적으로 다른 강점을 가지며, JXL은 어도비 계열 도구를 쓰는 전문가나 카메라 제조사, 스마트폰 OEM 등 웹 바깥에서 충분히 빛날 여지가 있다. 실무자 입장에서 정리하면, 웹 이미지 최적화의 현실적 선택지는 여전히 손실 압축 전 구간을 아우르는 AVIF이며 JPEG·WebP 자산도 당분간 병행 관리 대상이다. 새 포맷을 적용할 때는 무손실 절감 수치나 프로그레시브 지원 같은 홍보 문구가 아니라, 실제 디코드 시간과 저사양 기기에서의 안전성, 그리고 다운로드한 이미지를 다른 곳에서 쓸 때의 호환성 비용까지 함께 따져야 한다.