구글 크롬 팀이 10월 6일(현지시간) 크롬 155부터 JPEG XL(.jxl) 이미지 디코딩을 지원한다고 크롬 개발자 블로그를 통해 발표했다.
크롬은 2022년 JPEG XL 지원을 걷어 내 웹 개발자들의 거센 반발을 샀다. 이번 복귀의 열쇠는 포맷 자체보다 디코더에 있다. 구글은 C++ 참조 구현 대신 순수 러스트로 다시 짠 jxl-rs를 렌더러에 넣었다.
- 크롬 155가 JPEG XL 디코딩을 지원한다. 크로미움 일정상 155의 안정판 날짜는 10월 6일이다.
- 디코더는 순수 러스트 구현 jxl-rs다. 신뢰할 수 없는 이미지를 렌더러에서 처리하는 디코더의 메모리 안전성 위험을 원천 차단하려는 선택이다.
- 크롬 팀은 AVIF와 JPEG XL을 모두 시험해 보라고 권하며, 고화질·무손실 사진과 세밀한 점진적 디코딩에서 JPEG XL이 특히 유리할 것으로 봤다.
PART 01무슨 일이 있었나
크롬 개발자 블로그에 루카 베르사리(Luca Versari), 모리츠 피르싱(Moritz Firsching), 필립 예겐스테트(Philip Jägenstedt)가 공동으로 "Shipping JPEG XL in Chrome"이라는 글을 올렸다. 핵심은 크롬 155가 .jxl 파일 디코딩을 시작한다는 것이다. 별도 플래그 없이 이미지를 볼 수 있게 됐다고 여러 매체가 전했다.
결정의 배경으로 크롬 팀은 개발자 수요를 들었다. JPEG XL은 브라우저 간 호환성 개선 프로젝트인 Interop 2026에서 인기 제안이었고, 그 이전 여러 해에도 꾸준히 제안됐다. 크롬 팀은 Interop 2026의 JPEG XL 조사 작업에 참여해 모든 기능에 대한 테스트 커버리지를 만들고 크롬이 그 테스트를 통과하도록 했다고 밝혔다.
작업은 올해 초부터 차근차근 진행됐다. Phoronix에 따르면 지난해 12월 jxl-rs가 크로미움에 병합됐고, 1월 크롬 145 개발 단계에서 디코더가 연결됐다. 그때까지는 chrome://flags/#enable-jxl-image-format를 켜야 했다. 155는 이 과정의 마무리다.
되짚어 보면 크롬은 2022년 JPEG XL을 실험 기능에서 빼기로 하면서 생태계 전체의 관심이 충분하지 않다는 점을 이유로 들었다. 당시 이 결정에는 개발자와 이미지 업계의 비판이 쏟아졌고, 이슈 트래커에는 복귀를 요구하는 댓글이 수년간 이어졌다. 이번 블로그 글이 버그 리포트와 설문, Interop 제안을 근거로 명시한 것은 그 요구에 대한 공식 답변인 셈이다. AlternativeTo에 따르면 블로그는 jxl-rs 라이브러리와 크롬 통합 작업을 맡은 헬무트 야누슈카(Helmut Januschka)를 비롯해 여러 기여자의 이름을 따로 밝혔다.
PART 02JPEG XL에서 기대할 수 있는 것
크롬 팀은 JPEG XL을 AVIF의 대체재로 내세우지 않았다. 블로그는 둘 다 시험해 보라고 권하면서, JPEG XL이 고화질 또는 무손실 압축, 특히 사진과 세밀한 점진적 디코딩이 필요한 경우에 가장 큰 도움이 될 것이라고 적었다. 저화질·고압축 영역에서 강한 AVIF와 역할을 나눠 쓰라는 의미로 읽힌다.
PART 03복귀의 진짜 주인공, jxl-rs
이미지 디코더는 브라우저에서 가장 위험한 코드 중 하나다. 웹 페이지가 건네는 임의의 바이트를 렌더러 프로세스 안에서 해석해야 하기 때문이다. 크롬 팀은 블로그에서 메모리 안전하지 않은 코드가 힙 오버플로나 해제 후 사용(use-after-free) 같은 버그를 반복적으로 일으켜 왔고, 샌드박스는 2차 방어선일 뿐이라며 위험을 근원에서 없애는 것이 목표라고 밝혔다.
성능을 포기하지 않으려는 장치도 소개됐다. 러스트의 target_feature_11 기능이 안정화되면서 unsafe 없이 SIMD 코드를 쓸 수 있게 됐고, 구글 Highway 라이브러리에서 영감을 얻은 jxl_simd 추상화 계층을 둬서 꼭 필요한 unsafe 연산은 검토된 소수 지점에 몰아 두었다. C++ 참조 구현 libjxl의 최적화를 바탕으로 데이터 복사를 최소화하는 범용 처리 파이프라인을 만들었고, 성능은 공개 대시보드로 추적한다. 검증에는 퍼징과 AI 코드 리뷰를 함께 썼다고 한다.
이 접근은 크롬의 최근 방향과도 맞닿아 있다. 크롬은 폰트·이미지처럼 외부 입력을 직접 해석하는 구성 요소를 러스트로 옮기는 작업을 이어 왔다. JPEG XL은 기능이 많은 만큼 파서도 복잡한 포맷이어서, C++ 디코더를 그대로 넣었다면 보안 팀이 상당한 부담을 떠안았을 것이다. 러스트 구현이 있었기에 "기능은 늘리되 공격면은 늘리지 않는다"는 조건을 맞출 수 있었다고 보는 것이 자연스럽다.
PART 04웹 개발자는 무엇을 해야 하나
크롬 블로그는 서빙 방법까지는 다루지 않았다. 다만 크롬 이전 버전과 다른 브라우저가 여전히 섞여 있으니, 당분간은 대체 이미지를 함께 내보내는 방식이 기본이다. 사파리는 이미 2023년 사파리 17부터 JPEG XL을 지원하고 있어, 이번 크롬 지원으로 주요 엔진 중 두 곳이 .jxl을 읽게 됐다.
<picture>
<source srcset="/img/hero.jxl" type="image/jxl">
<source srcset="/img/hero.avif" type="image/avif">
<img src="/img/hero.jpg" alt="대표 이미지" width="1200" height="630">
</picture>image/jxl MIME 타입을 올바르게 내보내는지 본다. 확장자 매핑이 없으면 브라우저가 이미지를 거부할 수 있다.자주 묻는 질문
크롬은 몇 버전부터 JPEG XL을 지원하나요?
크롬 155부터 JPEG XL(.jxl) 디코딩을 지원한다. 구글은 10월 6일 크롬 개발자 블로그에서 이를 발표했다. 크롬 145 무렵에는 플래그를 켜야 실험적으로 쓸 수 있었다.
크롬은 왜 JPEG XL을 다시 넣었나요?
크롬 팀은 버그 리포트, 설문, Interop 2026 제안 등에서 확인된 개발자 수요를 이유로 들었다. 여기에 순수 러스트 디코더 jxl-rs가 준비되면서 이미지 디코더의 메모리 안전성 위험을 크게 줄일 수 있게 된 점이 결정적이었다.
JPEG XL과 AVIF 중 무엇을 써야 하나요?
크롬 팀은 둘 다 시험해 보라고 권했다. JPEG XL은 고화질·무손실 압축, 특히 사진과 세밀한 점진적 디코딩에서 유리할 것으로 봤다. 실제 선택은 자기 이미지로 용량과 화질, 인코딩 속도를 비교해 정하는 것이 좋다.
jxl-rs는 무엇인가요?
JPEG XL 참조 구현을 관리하는 libjxl 조직이 만든 순수 러스트 디코더다. SIMD 최적화를 위한 unsafe 코드를 소수 지점에 몰아 두는 구조로 성능과 메모리 안전성을 함께 노렸으며, 크롬 팀은 구현 이력 전체에서 메모리 안전성 버그가 없었다고 밝혔다.
댓글 0