크롬이 JPEG XL을 다시 받아들였다 — 4년 만의 번복은 무엇을 바꿨나

크롬의 JPEG XL 복귀는 포맷이 이겼다는 신호인가, 아니면 브라우저가 새 디코더를 들이는 비용 공식이 바뀌었다는 신호인가?

도입

2026년 10월 6일, Chrome for Developers 블로그에 「Shipping JPEG XL in Chrome」이라는 글이 올라왔다. 필자는 Luca Versari, Moritz Firsching, Philip Jägenstedt 세 사람이다. 요지는 짧다. Chrome 155부터 JPEG XL(.jxl) 이미지 포맷의 디코딩 지원을 출시한다는 것이다. 이 글은 해커뉴스에 올라가 575점을 받았다.

발표문은 JPEG XL을 웹 개발자와 사진가를 위한 차세대 포맷으로 소개하며, JPEG보다 30~50% 나은 압축, 무손실 압축, 내장 HDR 지원, 무손실 JPEG 트랜스코딩을 장점으로 든다. 그러면서도 「일반적으로 AVIF와 JPEG XL을 둘 다 시도해 보기를 권한다」고 적고, JPEG XL이 가장 도움이 될 곳으로 고충실도 또는 무손실 압축, 특히 사진 이미지나 세밀한 프로그레시브 디코딩이 선호되는 경우를 꼽는다. 「JPEG XL이 낫다」가 아니라 「이런 경우에 낫다」는 조심스러운 문장이다.

이 조심스러움에는 역사가 있다. 크롬은 2022년에 바로 이 포맷을 코드베이스에서 걷어낸 적이 있다. 당시의 이유 가운데 하나는 「기존 포맷 대비 충분한 증분 이점이 없다」는 것이었다. 그로부터 약 4년, 포맷의 비트스트림은 크게 바뀌지 않았다. 그렇다면 바뀐 것은 무엇인가. 이 글은 발표문이 스스로 밝힌 이유, 해커뉴스 토론에서 드러난 해석들, 그리고 AVIF와의 실제 트레이드오프를 차례로 살펴본다.

제거에서 출시까지: 발표문과 타임라인

먼저 사실관계를 시간순으로 정리하자. 해커뉴스의 한 이용자(swiftcoder)는 이번 스레드에 과거 토론 네 개를 링크해 맥락을 붙였다(직접 인용은 아니고, 코멘트의 요지를 요약). 그 항목들을 직접 확인한 결과는 다음과 같다.

2022년 10월 30일: 「Google set to deprecate JPEG XL support in Chrome 110」(Phoronix 기사, 146점)
2022년 12월 10일: 「JPEG XL support has officially been removed from Chromium」(Chromium 코드 리뷰 링크, 292점)
2025년 11월 24일: 「Chrome Jpegxl Issue Reopened」(Chromium 이슈 트래커 링크, 293점)
2026년 9월 14일: 「The case against JPEG XL」(Gianni Rosato의 블로그, 277점)

2022년 Phoronix 기사는 당시 Google 엔지니어가 Chromium 이슈 트래커에 남긴 제거 사유를 옮겨 두었다. 네 가지다. 실험 플래그와 코드는 무기한 남아 있어서는 안 된다. 생태계 전체의 관심이 실험을 계속할 만큼 충분하지 않다. 새 포맷이 기본 활성화를 정당화할 만큼의 증분 이점을 가져오지 않는다. 그리고 M110에서 플래그와 코드를 제거하면 유지보수 부담이 줄어 기존 포맷 개선에 집중할 수 있다. 당시 JPEG XL은 플래그 뒤에 숨은 실험 기능이었고, Phoronix는 비트스트림이 2020년 말에야 동결되었고 libjxl 도구가 아직 1.0 이전이었다는 점을 들어 「생태계의 관심이 없다」는 판단이 성급하다고 비판했다. 플래그 뒤에 있는 기능에 개발자가 몰려들 리 없다는, 닭과 달걀의 지적이다.

2025년 11월의 재개 스레드에서 한 이용자(markdog12)는 blink-dev 메일링 리스트의 게시물을 인용했다(직접 인용은 아니고, 코멘트의 요지를 요약). 그 내용은, 긍정적인 신호들을 고려해 고성능이면서 메모리 안전한 JPEG XL 디코더를 Chromium에 통합하는 기여를 환영하며, 기본 활성화를 위해서는 장기 유지보수에 대한 약속이 필요하고, 그것과 통상의 출시 기준이 충족되면 크롬에 출시하겠다는 것이었다. 이 문장이 이번 발표의 설계도다. 조건은 세 개였다. 성능, 메모리 안전성, 장기 유지보수.

2026년 10월의 발표문은 이 세 조건에 하나씩 답하는 구성으로 읽힌다. 메모리 안전성에 대해서는 C++ 레퍼런스 구현인 libjxl 대신 순수 Rust로 다시 쓴 디코더 jxl-rs를 통합했다고 밝힌다. 성능에 대해서는 「메모리 안전한 디코더가 최고의 비안전 대안과 대략 비슷한 속도라면, 상당한 성능 타협이 있는 선택보다 훨씬 명백한 선택」이라고 쓰고, 이를 위해 Rust의 target_feature_11 기능이 안정화되어 unsafe 코드 없이 SIMD 명령을 쓸 수 있게 되었으며, C++ Highway 라이브러리에서 영감을 받은 SIMD 추상화 계층 jxl_simd를 만들었다고 설명한다. unsafe 연산은 「소수의, 철저히 검증된 위치」로 제한했다. 검증에 대해서는 퍼징과 AI 코드 리뷰를 포함한 기법을 썼고, 구현 이력 전체에서 메모리 안전성 버그를 하나도 발견하지 못했다고 적는다.

마지막으로 발표문은 결정의 근거를 개발자 피드백에 둔다. Interop Process에서 JPEG XL은 2026년과 그 이전 여러 해에 걸쳐 인기 있는 제안이었고, 크롬 팀은 Interop 2026 JPEG XL Investigation에 참여해 JPEG XL의 모든 기능에 대한 테스트 커버리지를 확보하고 크롬이 그 테스트를 통과하도록 했다고 한다.

심층 분석: 바뀐 것은 포맷이 아니라 비용 공식이다

2022년의 사유 목록과 2026년의 발표문을 나란히 놓으면 흥미로운 비대칭이 보인다. 2022년 목록에는 「보안」이라는 단어가 없다. 그런데 2026년 발표문은 첫 섹션 전체를 보안에 쓴다. 이미지 디코더는 현대 브라우저에서 가장 중요하고 가장 많이 공격받는 공격 표면 중 하나이며, 네트워크에서 온 복잡하고 신뢰할 수 없는 바이너리 구조를 렌더러 프로세스 안에서 직접 처리한다고 발표문은 말한다. C++ 같은 메모리 비안전 언어로 쓴 디코더는 역사적으로 범위 밖 읽기, 힙 오버플로, use-after-free 취약점에 시달려 왔다. 크롬의 보안 모델은 샌드박싱과 심층 방어, 그리고 「rule of two」에 의존하지만, 발표문 스스로 샌드박싱은 2차 방어선일 뿐이라고 인정한다.

여기서 하나의 해석이 가능하다. 2022년 사유 중 「유지보수 부담」이라는 항목은, 실제로는 대형 C++ 디코더를 렌더러에 들이는 보안 비용을 포함하는 말이었을 수 있다. 해커뉴스에서 surajrmal이라는 이용자가 정확히 이 해석을 내놓았다(직접 인용은 아니고, 코멘트의 요지를 요약). 현실은 단순하다는 것이다. 기존 라이브러리의 보안 문제를 해결하는 비용이 그럴 가치가 없다고 판단되어 포맷을 포기했고, 산업계 채택이 늘고 더 안전한 새 라이브러리가 나타나자 결정이 바뀌었다는 설명이다. 그는 Google이 Rust 라이브러리를 개발했지만 그 투자를 한 것은 크롬 팀이 아니었다는 점도 덧붙였다. 이 마지막 주장은 발표문에서 확인되지 않는다. 다만 발표문의 감사 인사에는 Chrome 통합과 jxl-rs 양쪽에 상당한 기여를 한 사람으로 Helmut Januschka가, jxl-rs 자체에 기여한 사람으로 Martin Bruse, Zoltan Szabadka, Sami Boukortt, Wonwoo Choi가 이름을 올렸다.

이 해석이 맞다면, 이번 번복의 핵심은 JPEG XL이라는 포맷이 좋아진 것이 아니라 「새 포맷 하나를 받아들이는 비용」의 분모가 줄어든 것이다. 포맷의 압축 효율은 2022년과 크게 다르지 않을 수 있다. 하지만 디코더를 렌더러에 넣는 위험이 Rust와 안전한 SIMD 덕분에 극적으로 낮아졌다면, 같은 이점으로도 비용-편익 판단이 뒤집힐 수 있다. 이것은 JPEG XL만의 이야기가 아니다. 앞으로 브라우저가 새 코덱, 새 폰트 형식, 새 파서를 받아들일지 판단할 때 「메모리 안전한 구현이 있는가」가 사실상의 입장 조건이 될 수 있다는 선례다.

물론 다른 해석도 있다. 「Google 경영진이 막았고 엔지니어가 마침내 설득했다는 내부 싸움 이야기를 기대했다」는 YesThatTom2의 코멘트에는 여러 반론과 대안 설명이 달렸다(직접 인용은 아니고, 코멘트의 요지를 요약). pwg는 Adobe가 다가오는 PDF 사양 개정에서 JPEG XL을 승인된 압축 방식으로 채택한 것이 전환점이었다고 주장했다. 모든 브라우저가 PDF 렌더러이기도 하므로 어차피 JPEG XL 디코더를 탑재해야 하고, 그렇다면 그것을 img 태그에도 노출하는 것이 자연스럽다는 논리다. pmarreck는 Apple이 iOS에서 네이티브로 지원하고 아이폰에서 사진을 JPEG XL로 저장하는 옵션을 둔 것이 영향을 주었을 것이라고 추측했다. cbolton은 JPEG XL 자체가 사양, 레퍼런스 구현, Rust 구현까지 상당 부분 Google의 작업이라는 점을 들어 「경영진이 막았다」는 서사를 반박했고, 크롬 엔지니어들이 원하지 않았던 이유는 코드가 크고, 당시 채택이 적었고, 웹 용도로는 AVIF·WebP와 중복되었기 때문으로 본다고 적었다.

이 주장들 가운데 PDF 사양 채택과 Apple 지원의 구체적 내용은 이 글에서 별도로 확인하지 못했다. 다만 같은 스레드에서 JyrkiAlakuijala는 자신이 JPEG XL 표준화 과정에서 PIK와 FUIF를 하나로 합치는 방안을 위원회에 제안했다고 밝히며, 전문 사진(Digital Negative 등), 문서(PDF/EPUB), 의료 영상(DICOM)에서 채택된 뒤 이제 웹 호환성을 완성하는 단계라고 썼다(직접 인용은 아니고, 코멘트의 요지를 요약). 이해당사자의 서술이라는 점을 감안해도, 「웹 바깥에서 먼저 자리를 잡고 웹으로 역류했다」는 경로는 여러 코멘트가 공통으로 그리는 그림이다. 크롬 발표문이 Interop을 강조하는 것도 같은 맥락이다. 다른 브라우저가 이미 지원하거나 지원을 준비하는 상황에서, 크롬만 빠져 있는 것은 상호운용성의 구멍이 된다.

그렇다고 모두가 반긴 것은 아니다. 「The Case Against JPEG XL」의 필자라고 밝힌 computerbuster는 이번 스레드에서도 이 포맷이 웹에 왜 가치 있는 추가인지 여전히 모르겠다고 썼다(직접 인용은 아니고, 코멘트의 요지를 요약). 그의 논점은 넷이다. 손실 압축에서는 현대 인코더를 쓴 AVIF가 어떤 충실도 목표에서든 훨씬 효율적이다. 무손실에서는 WebP보다 약 10~13% 낫지만 디코드가 6배 이상 느릴 수 있어, 클라이언트가 그 비용을 치른다. JPEG 재압축도 늘어난 디코드 시간이 표시 시간 이득을 상쇄하는 경우가 많다. AVIF도 프로그레시브 디코드 패스를 원하는 만큼 둘 수 있다. 그는 32비트 부동소수 정밀도나 다층 지원 같은 강점은 인정하면서도, 새 코덱을 웹에 넣는 기준이 무엇인지 모르겠다고 했다. 이에 대해 yyyk는 브라우저가 더 이상 웹에만 좁게 맞춰진 소프트웨어가 아니며, PDF와 카메라 같은 다른 용도가 JPEG XL로 이득을 보고, 일단 지원이 들어오면 웹에 켜는 것은 쉬운 일이라고 반론했다. 논쟁은 결국 「웹 코덱은 웹에 특화되어야 하는가, 아니면 범용이어도 되는가」라는 철학의 차이로 수렴한다.

전망과 시사점: 어디에 JPEG XL을 쓸 것인가

실무자에게 남는 질문은 「그래서 무엇을 쓰라는 것인가」다. 발표문의 권고는 앞서 본 대로 둘 다 시도해 보라는 것이고, 고충실도·무손실·사진·프로그레시브를 JPEG XL의 자리로 지목한다.

해커뉴스 코멘트에서 드러난 실무 쟁점도 이 경계선 위에 있다. theandrewbailey는 1비트/픽셀 이하에서는 AVIF가 여전히 낫고 그 이상에서는 JPEG XL이 더 효율적이라고 정리했다. jug는 손실이 큰 압축에서는 AVIF가 약간 앞설 수 있지만, CPU가 극히 제한된 경우가 아니라면 JPEG XL로 크게 잘못될 일은 없으며, AVIF·PNG·JPEG·WebP, 일부 TIFF 용도까지 대체할 수 있는 범용성이 강점이라고 썼다. 호환성 쪽에서는 flockonus가 caniuse 기준 JPEG XL 지원이 17%, WebP가 97%라고 지적했고, boutell은 Safari가 프로그레시브 렌더링과 애니메이션을 아직 지원하지 않는다고 caniuse를 근거로 언급했다. tepmoc는 확장자만으로는 손실인지 무손실인지 알 수 없다는 단점을 들었다(이상 모두 직접 인용은 아니고, 코멘트의 요지를 요약). 이 수치들은 코멘트 작성 시점의 caniuse 값으로, 이 글에서 따로 확인하지는 않았다.

여기서 시사점을 세 가지로 정리할 수 있다.

첫째, 무손실 JPEG 재압축은 JPEG XL만의 독특한 카드다. 이미 JPEG로 쌓여 있는 거대한 이미지 아카이브를 화질 손실 없이 줄이고, 필요하면 원본 JPEG로 비트 단위 복원할 수 있다는 성질은 AVIF가 제공하지 않는다. 디코드 비용이 실제 이득을 얼마나 잠식하는지는 논쟁 중이지만, 저장 비용이 지배적인 아카이브 용도에서는 계산이 다를 수 있다.

둘째, 인코더 품질이 포맷 평가를 좌우한다. llm_nerd는 Affinity의 JPEG XL 출력이 압축률과 품질 모두 나빠서 이 포맷에 실망한 사람들을 안다며, 무압축으로 내보낸 뒤 레퍼런스 도구 cjxl로 변환하라고 조언했다(직접 인용은 아니고, 코멘트의 요지를 요약). 포맷 비교는 결국 특정 인코더 구현의 비교다.

셋째, 프로그레시브 디코딩은 사용자 경험의 문제로 남는다. cyberrock은 Firefox(안드로이드 제외)와 크롬이 프로그레시브 로딩을 켠 채 출시한 반면 Safari는 아직 켜지 않았다고 지적했다(직접 인용은 아니고, 코멘트의 요지를 요약). 같은 파일이 브라우저마다 다르게 「나타나는」 상황은 한동안 계속될 것이다.

(10월 17일 추기: 10월 15일, Jake Archibald가 「JPEG XL vs AVIF for web use-cases」를 게시했고 해커뉴스에서 319점을 받았다. 그는 JPEG XL이 이제 모든 주요 브라우저에 들어왔다고 전제한 뒤 avifenc 1.4.2, libjxl 0.12.0, 새 인코더 jixel 0.4.2로 벤치마크했다. 결론은 이렇다. 웹의 손실 사진에서는 AVIF가 거의 항상 더 작은 파일을 만들며, 기본 노력 설정에서 최선의 JPEG XL 파일은 대개 15~~25%, 최대 노력에서는 6~~20% 더 크다. 스크린숏·일러스트와 투명도가 있는 이미지에서는 AVIF가 훨씬 낫다. 디코드는 AVIF가 빠르고, JPEG XL은 중간 품질에서 2~~3배 걸리지만 매우 높은 품질에서는 그 격차가 좁아진다. 반면 JPEG XL은 기존 JPEG를 추가 손실 없이 9~~20% 줄일 수 있고, 무손실에서는 확실한 승자다. 프로그레시브 JPEG XL은 높은 노력 설정에서 거의 공짜이며, AVIF도 크롬에서 프로그레시브 렌더링을 지원한다. 그의 기본값은 AVIF 4:4:4이고, AVIF가 유난히 큰 파일을 낼 때 jixel로 JPEG XL을 시도해 보겠다고 했다. 또 두 포맷 모두 최근 크게 개선되었으니 권고가 바뀔 수 있고, 자기 이미지로 직접 테스트하라고 덧붙였다. 크롬 발표문의 「둘 다 시도하라, JPEG XL은 고충실도·무손실에서」라는 권고와 대체로 맞아떨어지는 결과다.)

결론

크롬의 JPEG XL 출시는 「포맷 전쟁에서 누가 이겼는가」로 읽으면 오독하기 쉽다. 손실 웹 이미지라는 가장 큰 시장에서 AVIF의 우위는 이번 발표로 사라지지 않았고, 크롬 스스로도 둘 다 시도하라고 권한다.

이번 번복이 실제로 보여 주는 것은 브라우저가 새 기능을 받아들이는 비용 공식의 변화다. 2022년의 크롬은 「이점이 충분하지 않다」고 했다. 2025년의 크롬은 「고성능이고 메모리 안전한 디코더와 장기 유지보수 약속이 있으면 출시하겠다」고 했다. 2026년의 크롬은 Rust로 다시 쓴 디코더, unsafe 없이 쓰는 SIMD, 퍼징과 Interop 테스트를 가지고 돌아왔다. 이점의 크기보다 위험의 크기가 줄어든 것이 판정을 바꿨다고 보는 편이 사료에 더 잘 맞는다. 여기에 PDF·카메라·OS 같은 웹 바깥의 채택이 압력을 더했다는 해석이 있지만, 그 인과의 무게는 공개된 자료만으로는 판정하기 어렵다.

여러분의 이미지 파이프라인에서 JPEG XL이 들어갈 자리는 어디인가. 기존 JPEG 아카이브, 무손실 원본 보관, 고충실도 사진이라면 지금 시험해 볼 이유가 있다. 그 밖의 웹 이미지라면, 당분간은 자신의 이미지로 직접 재 보는 것 말고는 정답이 없다.

출처: