Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — "돌아왔다"와 "쓸 수 있다"는 다른 말입니다
짧은 복습 — 2022년에 무슨 일이 있었나
2025년 11월 22일 — 4년 전 그 스레드에 올라온 번복
Chrome에 실제로 들어간 것 — Gerrit으로 추적
Firefox — 같은 디코더, 반 발짝 뒤
Safari와 Interop 2026 — 나머지 퍼즐의 정확한 위치
오늘 기준 상태표
실무 판단 — 지금 무엇을 하고, 무엇을 하지 말아야 하나
마치며
참고 자료

들어가며 — "돌아왔다"와 "쓸 수 있다"는 다른 말입니다

2025년 11월 말부터 "Chrome이 JPEG XL을 다시 지원하기로 했다"는 기사가 돌았고, 2026년 초에는 "Chrome 145에 JPEG XL이 들어갔다", 최근에는 "Firefox 152에도 들어갔다"는 이야기까지 나왔습니다. 전부 어느 정도는 사실입니다. 그리고 그대로 믿고 .jxl을 프로덕션에 배포하면 사고가 납니다.

이미지 포맷 지원 문제는 유독 소문과 실제 상태의 간극이 큽니다. "코드가 트리에 있다", "플래그 뒤에 있다", "Nightly에서 기본 활성이다", "릴리스에서 기본 활성이다"는 전부 다른 단계인데, 뉴스 제목은 이 구분을 뭉갭니다. 그래서 이 글은 기사 대신 1차 소스만 봅니다 — Chromium Gerrit의 머지된 CL, 소스 트리의 실제 게이트, Bugzilla의 마일스톤, 브라우저 벤더의 공식 릴리스 API. 오늘(2026-07-17) 기준으로 JPEG XL이 정확히 어디까지 왔는지, 그리고 실무자는 언제 움직여야 하는지를 정리합니다.

포맷 자체(AVIF 대비 압축 효율, 무손실 JPEG 재압축 같은 기능 비교)는 이미지 포맷 2026 딥다이브에서 다뤘으니, 여기서는 "브라우저에 실리는 중인가"라는 한 가지 질문만 팝니다.

짧은 복습 — 2022년에 무슨 일이 있었나

시간순으로 요약하면 이렇습니다.

2021년, Chromium은 libjxl(C++) 기반의 실험 디코더를 플래그 뒤에 넣고 blink-dev에 Intent to Prototype 스레드를 올렸습니다.
2022년 10월, 같은 스레드에 제거 공지가 올라왔습니다. 요지는 세 가지였습니다 — 실험 플래그를 무기한 유지하지 않는다, 생태계 전반의 관심이 실험을 계속할 만큼 크지 않다, 기존 포맷 대비 증분 이득이 기본 활성화를 정당화할 만큼 크지 않다.
코드와 플래그는 Chrome 110에서 실제로 제거됐습니다. Chrome 공식 버전 이력 API 기준으로 110 스테이블 롤아웃 시작은 2023년 2월 1일입니다.

이후 3년간 이 결정은 크롬 이슈 트래커에서 가장 시끄러운 이미지 포맷 논쟁으로 남았습니다. 그 사이에 바깥 상황이 바뀌었습니다. Apple은 Safari 17 릴리스 노트(2023년 9월)에 JPEG XL 지원 추가를 명시했고 — 지금까지도 기본 활성으로 지원하는 유일한 메이저 엔진입니다. Mozilla는 공식 표준 입장 문서에서 position 자체는 neutral을 유지하되, 근거문에 "또 하나의 C++ 이미지 디코더를 추가하는 비용을 정당화할 만큼 이득이 크지 않지만, 메모리 안전한 디코더라면 그 비용이 크게 줄어들며 요구사항을 충족하는 구현이라면 출시할 의향이 있다"는 취지를 명시했습니다. 흔히 "Mozilla가 positive로 돌아섰다"고 알려져 있는데, 등록된 입장은 지금도 neutral입니다 — 조건부 개방이 정확한 표현입니다.

그리고 그 조건에 맞는 물건이 생겼습니다. libjxl 팀이 만드는 순수 Rust 디코더 jxl-rs입니다. 저장소 스스로 "규격 준수·안전·속도를 목표로 하는 진행 중(work-in-progress) 재구현"이라고 소개합니다. 이 "진행 중"이라는 단서는 뒤에서 다시 중요해집니다.

2025년 11월 22일 — 4년 전 그 스레드에 올라온 번복

번복 공지는 새 블로그 포스트가 아니라, 2021년 Intent to Prototype이 올라왔던 바로 그 blink-dev 스레드에 답글로 올라왔습니다. 작성자는 Rick Byers, Chrome ATL(Architecture Tech Leads) 명의입니다. 내용을 요약하면:

지난 평가 이후 상황이 바뀌었다 — Safari가 출시했고, Firefox가 입장을 갱신했고, 버그 추천수·Interop 제안·설문 같은 개발자 신호가 계속 관측되며, PDF 표준에 JPEG XL이 추가된다는 발표도 있었다.
이 신호들을 근거로: "we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder"(성능 좋고 메모리 안전한 JPEG XL 디코더를 통합하는 기여를 환영한다).
단, 기본 활성화하려면 장기 유지보수에 대한 약속이 필요하고, 그것과 통상적인 출시 기준이 충족되면 Chrome에 실겠다.

문장을 뜯어보면 이건 "우리가 하겠다"가 아닙니다. "누가 해 오면, 그리고 계속 유지보수하겠다고 약속하면, 실어 주겠다"입니다. 2022년 제거의 핵심 논거가 유지보수 부담이었다는 점을 기억하면 일관된 태도입니다 — 부담을 지지 않는 조건으로만 문을 연 겁니다. 이 구조를 이해해야 이후 8개월의 진행 속도가 해석됩니다.

Chrome에 실제로 들어간 것 — Gerrit으로 추적

머지된 CL과 공식 일정만으로 타임라인을 그리면 이렇습니다. 전부 Chromium Gerrit에서 확인할 수 있습니다.

2025-11-22  blink-dev에 조건부 번복 공지 (Chrome ATLs)
2025-12-10  jxl-rs를 third_party에 벤더링 — CL 7201443, +73,908줄
2025-12-28  JXL 인프라 추가: enum과 빌드 플래그
2026-01-08  jxl-rs 기반 JXL 이미지 디코더 추가 (revert 후 01-09 reland)
2026-01-13  디코더 연결(wire up) + 피처 플래그 게이팅 + WPT 테스트 추가
2026-01-16  [M145] 태그가 붙은 145 브랜치 체리픽 시작
2026-02-10  Chrome 145 스테이블 (chromiumdash 공식 일정) — M110 이후
            처음으로 JPEG XL 디코더가 스테이블 바이너리에 복귀
2026-02-24  DevTools 통합 (JXL 비활성 에뮬레이션, host config 노출)
2026-01~04  jxl 크레이트 0.1.4 → 0.4.3 버전 롤 반복
2026-05-07  chrome://flags 항목 만료를 M152로 연장
2026-06-28  잘린 파일 렌더링·애니메이션 크래시 등 안정화 수정이 계속 머지되는 중

몇 가지 짚을 점이 있습니다.

첫째, 게이트는 세 겹입니다. 소스 기준으로 컴파일 스위치는 gn 인자 enable_jxl_decoder이고 기본값이 true라서 공식 빌드에 디코더가 들어갑니다. 하지만 런타임은 blink::features::kJXLImageFormat이 쥐고 있는데, 이 base::Feature는 오늘 main 기준 FEATURE_DISABLED_BY_DEFAULT입니다. 사용자가 켜는 방법은 chrome://flags의 enable-jxl-image-format 항목뿐입니다. 요컨대 Chrome 145부터 151(현재 스테이블)까지, 바이너리 안에 디코더는 있지만 기본값 기준으로는 꺼져 있습니다.

둘째, "기여 환영" 모델이 문자 그대로 실행됐습니다. flag-metadata.json에 기록된 이 플래그의 소유자는 Google 직원이 아니라 외부 기여자(helmut@januschka.com)입니다. 실제로 C++ libjxl 기반 1차 구현이 리뷰에서 "Rust로"라는 피드백을 받고 폐기됐고, jxl-rs 기반으로 다시 만든 과정이 기여자 본인의 회고 글에 정리돼 있습니다. 그 글에 실린 저자 자체 측정(2025년 12월, jxl-rs 커뮤니티의 SIMD 최적화 26개 PR 이후 기준)을 보면 테스트 이미지 3장 중 2장에서는 여전히 C++ libjxl이 빨랐고(예: 2048x2560 사진에서 jxl-rs 198ms 대 libjxl 170ms), 1장에서는 jxl-rs가 3배 이상 빨랐습니다. 어디까지나 특정 이미지 몇 장에 대한 개인 측정이라 일반화는 어렵지만, "Rust 디코더가 아직 전면적으로 빠른 건 아니다"라는 방향성 정도는 읽을 수 있습니다.

셋째, 출시 절차는 시작도 안 했습니다. chromestatus 항목의 Chrome 상태는 여전히 "Proposed"이고, Intent to Ship 스레드는 없습니다. 5월에 플래그 만료가 M152로 연장됐는데, chromiumdash 일정상 152 스테이블은 2026년 8월 25일입니다. 이 연장은 "그때까지는 플래그 상태로 둔다"는 뜻이지 "152에 출시한다"는 뜻이 아닙니다 — 플래그 만료 연장은 관례적인 하우스키핑입니다. 6월 말까지도 잘린 파일의 부분 렌더링 처리, 애니메이션 반복 횟수 조회 시 크래시 같은 것을 고치는 CL이 머지되고 있다는 사실이, 이 코드가 아직 "기본 활성화 후보" 단계가 아니라 "안정화 중" 단계임을 더 정확히 말해 줍니다.

Firefox — 같은 디코더, 반 발짝 뒤

Firefox 쪽 진행은 Bugzilla 마일스톤으로 정확히 짚을 수 있습니다.

버그 1986393 (2025-09-02 생성, FIXED, 마일스톤 149): "초기 jpegxl rust 코드를 pref 꺼진 채로 랜딩". 흥미롭게도 Chromium의 번복 공지보다 두 달 이상 앞섭니다 — Mozilla는 자기 조건(메모리 안전 디코더)이 충족되자 조용히 먼저 움직이고 있었습니다.
버그 2016688 (FIXED, 마일스톤 152): "beta/release 빌드에서도 jpeg xl 코드를 빌드". 실제로 ESR 140의 moz.configure에는 Nightly에서만 컴파일하는 조건이 남아 있고, 152 릴리스 브랜치에서는 그 조건이 사라져 모든 채널에서 컴파일됩니다.
단, StaticPrefList.yaml의 image.jxl.enabled 기본값은 @IS_NIGHTLY_BUILD@입니다. 즉 2026년 6월 16일 출시된 Firefox 152 릴리스 빌드에는 디코더가 컴파일돼 있지만 pref가 꺼져 있고, about:config에서 수동으로 켜야 동작합니다. 152 공식 릴리스 노트에 JPEG XL 언급은 없습니다 — "Firefox 152가 JPEG XL을 지원한다"는 기사 제목과 실제 출하 상태의 간극이 딱 이만큼입니다.

주목할 사실 하나: Firefox의 Cargo.lock이 고정하는 디코더는 jxl 크레이트 0.4.3, 즉 Chromium이 벤더링한 것과 같은 libjxl/jxl-rs입니다. 두 엔진이 같은 서드파티 디코더 구현을 공유하는 겁니다. 2022년 제거 논거의 한 축이 "브라우저마다 C++ 디코더를 하나씩 더 짊어지는 유지보수 부담"이었다는 점을 떠올리면, 부담의 구조 자체가 달라졌습니다 — 이제 한 저장소의 안전성·성능 개선이 두 브라우저에 동시에 흘러갑니다.

물론 미완 목록도 소스에 그대로 보입니다. 추적 메타버그 1539075는 2019년에 열려 7년째 ASSIGNED 상태이고(마지막 활동은 이 글 이틀 전), mac x86_64에서 디코딩이 3배 느려지는 문제의 워크어라운드가 아직 남아 있으며(버그 2043091), 색공간을 ICC 프로파일 합성 대신 CICP enum으로 인식하게 하는 작업(버그 2055224) 같은 품질 이슈가 이번 주에도 새로 등록되고 있습니다.

Safari와 Interop 2026 — 나머지 퍼즐의 정확한 위치

Safari는 이 이야기에서 변수가 아닙니다. 2023년 9월 Safari 17부터 기본 지원이고, Byers의 공지가 첫 번째 근거로 꼽은 것도 Safari였습니다.

더 조심해서 읽어야 하는 건 Interop 2026입니다. "JPEG XL이 Interop 2026에 포함됐다"는 말이 도는데, 공식 README를 보면 JPEG XL은 점수가 매겨지는 focus area가 아니라 investigation effort입니다. 문서 스스로 현재 웹 플랫폼 테스트가 희소하다고 인정하고, 올해 목표를 "이 기능을 테스트 가능하게 만드는 것"으로 잡았으며, 개발자들이 중요하게 여기는 progressive rendering조차 브라우저가 언제 어떻게 수행해야 하는지 아직 논쟁 중이라고 적고 있습니다. 상호운용성 점수를 매기는 단계가 아니라, 채점 기준표를 만드는 단계라는 뜻입니다. 실제로 올해 상반기 Gerrit과 Bugzilla 양쪽에서 jpegxl WPT 디렉터리에 테스트를 채워 넣는 커밋이 계속 흐르고 있습니다 — 방향은 맞는데, 완주 시점은 아무도 약속하지 않았습니다.

오늘 기준 상태표

정리하면 2026년 7월 17일 현재 상태는 이렇습니다.

                          디코더 컴파일   기본 활성   수동 활성 방법
Chrome 151 (스테이블)          O            X       chrome://flags 의
                                                    enable-jxl-image-format
Firefox 152 (릴리스)           O            X       about:config 의
                                                    image.jxl.enabled
Firefox Nightly (154)          O            O       -
Safari 17+                     O            O       -

Intent to Ship (Chromium):     없음 (chromestatus 상태 "Proposed")
릴리스 기본 활성화 일정:        어느 엔진도 공표한 바 없음
Interop 2026:                  investigation effort (채점 대상 아님)

"3년 만에 처음으로 세 엔진 모두의 코드베이스에 JPEG XL 디코더가 존재한다"는 문장과 "여전히 웹 트래픽의 대부분에서 JPEG XL은 렌더링되지 않는다"는 문장이 동시에 참입니다. 이 두 문장을 같이 들고 있는 것이 지금 이 주제에 대한 정확한 이해입니다.

실무 판단 — 지금 무엇을 하고, 무엇을 하지 말아야 하나

지금 하지 말아야 할 것부터. 유저에게 나가는 웹 이미지 포맷을 JPEG XL로 전환하는 일입니다. Chrome 계열과 릴리스 Firefox에서 기본 미지원이므로, content negotiation 없이 .jxl을 내보내면 대부분의 사용자에게 깨진 이미지가 갑니다. WASM 폴리필로 우회하는 선택지도 있지만 — 앞의 회고 글 저자가 만든 폴리필은 제작자 표기 기준 gzip 후 약 540KB입니다 — 이미지 몇십 KB를 아끼자고 540KB 런타임을 얹는 것은 대부분의 웹 성능 시나리오에서 본말전도입니다. 폴리필이 값을 하는 곳은 JXL 원본을 이미 대량 보유한 특수한 뷰어류 정도입니다.

지금 해 둘 만한 것. 첫째, 이미지 파이프라인이 <picture>나 Accept 헤더 기반 포맷 분기를 이미 갖추고 있는지 점검하세요. WebP에서 AVIF로 넘어올 때 만들었던 그 구조가 그대로 JXL 수용 통로가 됩니다 — 포맷이 하나 더 늘어나는 것뿐입니다. 둘째, CDN이나 오리진 로그에서 Accept: image/jxl의 등장 비율을 관측 항목에 넣어 두세요. Safari와 플래그를 켠 사용자들이 이미 보내고 있고, 이 비율이 계단식으로 뛰는 날이 어떤 브라우저가 기본값을 바꾼 날입니다. 셋째, 판단 신호를 뉴스가 아니라 1차 소스에 걸어 두세요. 진짜 신호는 두 가지입니다 — blink-dev에 "Intent to Ship: JPEG XL"이 올라오는 것, 그리고 Firefox의 image.jxl.enabled 기본값이 Nightly 조건 없이 true로 바뀌는 커밋. 이 둘 중 하나가 일어나기 전까지는 전부 준비 운동입니다.

덧붙여, 이 사례에는 포맷과 무관한 교훈이 하나 있습니다. 2022년의 제거는 "품질이 나빠서"가 아니라 "유지보수 부담을 질 이유가 부족해서"였고, 2025년의 번복은 벤치마크가 아니라 그 부담의 구조를 바꾼 것(메모리 안전 공유 디코더 + 외부 기여 + 유지보수 약속)이 만들었습니다. 브라우저에 기능을 넣는 문제에서 기술 우위 논쟁은 생각보다 변수가 아니고, 유지보수 경제학이 상수입니다.

마치며

"JPEG XL이 돌아왔다"의 정확한 버전은 이렇습니다 — Chromium이 조건을 걸고 문을 열었고, 외부 기여자와 libjxl 팀의 Rust 디코더가 그 문으로 들어갔으며, Firefox는 같은 디코더를 한 발 먼저 싣기 시작했고, Safari는 애초에 떠난 적이 없다. 그러나 2026년 7월 현재 어떤 엔진도 릴리스 기본값을 바꾸지 않았고, 바꾸겠다는 일정도 없다.

그래서 지금 할 일은 전환이 아니라 관측입니다. 포맷 분기 구조를 정비해 두고, Accept 헤더를 지켜보고, Intent to Ship이라는 단 하나의 진짜 신호를 기다리는 것 — 그게 오늘 시점에서 JPEG XL에 대해 실무자가 취할 수 있는 가장 정직한 포지션입니다.