# Chromium이 JpegXL을 병합함

> Clean Markdown view of GeekNews topic #25800. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25800](https://news.hada.io/topic?id=25800)
- GeekNews Markdown: [https://news.hada.io/topic/25800.md](https://news.hada.io/topic/25800.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-14T09:52:04+09:00
- Updated: 2026-01-14T09:52:04+09:00
- Original source: [chromium-review.googlesource.com](https://chromium-review.googlesource.com/c/chromium/src/+/7184969)
- Points: 2
- Comments: 1

## Topic Body

- **Chromium 코드베이스에 JpegXL 디코더가 통합**되어, 브라우저가 JXL 포맷 이미지를 처리할 수 있게 됨  
- 변경 사항은 Gerrit 코드 리뷰 페이지에서 **“Wire up JXL decoder”** 라는 제목으로 확인 가능  
- 이 병합은 **JpegXL 포맷 지원을 위한 핵심 단계**로, 디코더 연결 작업이 포함됨  
- 코드 리뷰는 Chromium의 **src 저장소 내 변경사항(7184969)** 으로 등록됨  
- 웹 브라우저의 **차세대 이미지 포맷 지원 확대**라는 점에서 의미가 있음  

---
### Chromium의 JpegXL 디코더 통합
- Gerrit 코드 리뷰 항목 **“Wire up JXL decoder (7184969)”** 는 Chromium 프로젝트에 JpegXL 디코더를 연결하는 변경사항임  
  - 이 변경은 Chromium의 **src 저장소** 내에서 수행됨  
  - 코드 리뷰 플랫폼은 **chromium-review.googlesource.com**을 사용함  
- 제목 그대로, JXL(JpegXL) 디코더를 **브라우저 내부에 연결(wire up)** 하는 작업을 의미함  
- 페이지에는 **추가 설명이나 코드 세부 내용은 표시되지 않음**, 단순히 변경 제목만 확인 가능  

### 기술적 맥락
- JpegXL은 **차세대 이미지 압축 포맷**으로, 기존 JPEG 대비 효율 향상을 목표로 함 (원문 내 직접 언급 없음, 단 기술명만 존재)  
- Chromium에 디코더가 병합됨으로써, **JXL 이미지 처리 기능이 코드 수준에서 활성화될 기반**이 마련됨  
- 이 변경은 **브라우저 엔진의 미디어 디코딩 체계 확장**과 관련된 기술적 진전임  

### 문서 상태
- 페이지는 **Gerrit 코드 리뷰의 캐시된 스냅샷**으로 표시됨  
- “shadow DOM이 숨겨져 있다”는 경고 문구가 포함되어 있으나, **실제 코드 내용은 표시되지 않음**  
- 따라서 본 문서에서 확인 가능한 정보는 **변경 제목과 리뷰 식별자(7184969)** 뿐임

## Comments



### Comment 49186

- Author: neo
- Created: 2026-01-14T09:52:04+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46597927) 
- [Cloudinary 블로그 글](https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front)을 봤는데, webp, jpegxl, avif, jpeg 등을 비교한 오래된 명작 글임  
  차트가 잘 정리되어 있고, **AVIF는 매우 느림**  
  - JPEG을 가장 낮은 품질로 설정했을 때가 여기서는 훨씬 보기 좋았음  
    [관련 섹션 링크](https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#what_quality_points_)  
  - 이 사이트가 정확히 뭘 하려는 건지 모르겠음  
    [스크린샷 참고](https://i.imgur.com/Q8JGYK3.png)  
  - 인용된 문장처럼 JPEG XL이 현재 **손실/무손실 모두에서 최고의 코덱** 위치를 굳혔다면, JPEG과 PNG를 하나로 대체할 수 있는 큰 발전임  
  - 다만 이 테스트는 **하드웨어 가속 인코더/디코더**를 사용하지 않음  

- [jxl-rs 라이브러리](https://github.com/libjxl/jxl-rs)는 JPEG XL의 Rust 구현체임  
  비교적 새 프로젝트지만 Rust 덕분에 **보안 안정성** 면에서 안심이 됨  
  예전 Chromium 논의 때는 이 라이브러리가 없었음  
  - Google이 JPEG XL을 거부한 이유가 ‘관심 부족’ 때문이었던 걸로 기억함. 보안 문제 때문은 아니었던 듯함  
  - “Rust가 보안 걱정을 덜어준다”는 말에 동의하지 않음. **메모리 안전성은 보안 그 자체가 아님**  
    Rust가 과신을 불러올 수 있고, 위협 모델링을 생략하는 경우가 생김  
    오히려 주의 깊은 C 프로그래머가 더 안전할 수도 있음  
  - 실제로 unsafe 코드가 얼마나 있는지 확인해봤음  
    [검색 결과 링크](https://github.com/search?q=repo%3Alibjxl%2Fjxl-rs%20unsafe&type=code)  

- 최근 WebP와 AVIF를 비교해봤는데, **WebP는 거의 즉시 인코딩**되는 반면 AVIF는 1MP 이미지에 20초 이상 걸림  
  JXL은 아직 지원이 적어서 실제로는 못 쓰지만, WebP 수준의 속도에 더 나은 품질을 기대함  
  - rav1e는 **업데이트가 수년째 멈춘 상태**라서 aom이나 svt-av1 같은 인코더를 쓰는 게 낫다고 함  
  - AVIF는 CPU 사용 파라미터를 조정해야 함. 기본 설정이 너무 높은 CPU 레벨을 써서 느림  
    내 환경에서는 2MP AVIF를 100ms 정도에 생성함  

- JPEG XL의 **공개 명세(spec)** 가 자유롭게 접근되지 않는 게 아쉬움  
  - 비공개 표준을 유지하는 건 부끄러운 일이라고 생각함  
  - ISO, IEC 같은 기관의 수많은 문서가 **유료 벽(paywall)** 뒤에 있는 현실이 문제임  

- 또 하나의 새 이미지 포맷을 받았는데, 결국 변환 없이는 못 쓰는 상황이 반복될까 걱정됨  
  - 그래도 Microsoft조차 JPEG XL 애드온을 냈고, Google이 물러난 지금은 **진짜 기회**가 있다고 봄  
    [Microsoft Store 링크](https://apps.microsoft.com/detail/9MZPRTH5C0TB?hl=en-us&gl=US&ocid=pdpshare)  
  - 실제로는 이미 많은 앱이 지원함 — Affinity, Photoshop, Microsoft Photos, Gimp, 그리고 iOS 17+/macOS 12+의 **시스템 전역 지원**까지 있음  
    Chromium이 오히려 늦은 편임  
  - 물론 새로운 포맷은 항상 **10년 정도의 도입 기간**이 필요함  

- 위키에서 본 JPEG XL의 기능 목록을 읽어보니, **다중 채널 이미지**나 **멀티페이지 문서** 같은 흥미로운 기능이 있음  
  좋은 점도 있지만, 점점 TIFF처럼 복잡해지는 느낌임  

- JPEG과 JPEG-XL 사이에는 여전히 많은 공통점이 있음  
  새 구현체가 기존 JPEG 지원까지 통합하면 **코드 크기 절감**이 가능하지 않을까 궁금함  
  - 실제로 그 기능을 위한 이슈가 JPEG-XL Rust 저장소에 열려 있음  
    [이슈 #513 링크](https://github.com/libjxl/jxl-rs/issues/513)  

- 개인적으로는 WEBP처럼 새로운 포맷보다 **기존 JPEG**을 계속 쓰려 함  
  대부분의 프로그램이 지원하고, 일반 사용자에게는 JPEG + PNG면 충분함  
  간단한 애니메이션은 GIF, 복잡한 건 영상으로 처리하면 됨  
  - “JPEG XL”은 이름과 달리 단순히 JPEG 확장판이 아님  
    PNG보다 작은 용량으로 **무손실 인코딩**이 가능하고, 기존 JPEG을 20% 더 압축하면서 **복원 가능한 트랜스코딩**도 지원함  
    HDR, 와이드 감마, **점진적 로딩** 등 다양한 기능이 있어 웹 전송에도 이상적임  
    [jpegxl.info 참고](https://jpegxl.info/)  
  - WebP는 이제 **사실상 표준 포맷**으로 봐도 됨  
    Safari 14 이후 모든 주요 브라우저가 지원하고, Windows 10·macOS Big Sur 이후 기본 탑재됨  
    [지원 현황](https://caniuse.com/webp), [소프트웨어 목록](https://en.wikipedia.org/wiki/WebP#Graphics_software) 참고  
  - GIF는 이제 비효율적임. **동영상으로 대체**하는 게 5~10배 효율적임  
    [관련 글](https://web.dev/articles/replace-gifs-with-videos)  

- JPEG XL, WebP, AVIF 논쟁을 오래 들어왔지만 잘 몰랐음  
  벤치마크를 보면 JpegXL이 WebP보다 압축 속도와 크기 모두 우수한데, 왜 Chromium은 채택을 주저했는지 궁금함  
  - WebP와 AVIF는 VP8/AV1과 코드가 공유되어 **브라우저 통합이 쉬움**, 반면 JPEG-XL은 별도 코드베이스라 구현 부담이 큼  
    또한 libjxl은 C++ 10만 줄이 넘는 코드라 **보안 취약점 위험**이 있었음  
    Rust 구현이 성숙해지면서 Chrome이 다시 검토하는 듯함  
  - JPEG XL은 **점진적 디코딩**을 지원함  
    [데모 영상](https://www.youtube.com/watch?v=UphN1_7nP8U)  
  - Google은 “비슷한 포맷이 여러 개면 보안 위험만 늘어난다”며 AVIF 하나면 충분하다고 주장했음  
  - AVIF는 낮은 bpp(저화질)에서는 좋지만 무손실은 약함, 반면 JXL은 고화질·무손실에서 강함  
  - 과거 JPEGXL C++ 라이브러리가 **유지보수 중단** 상태였는데, Rust 버전이 등장하면서 브라우저 채택이 가능해졌음  

- JPEG XL이 **애니메이션을 지원하는지** 궁금했음  
  - 지원은 하지만 **프레임 간 압축이 없어 비효율적**이라 일반 영상보다 용량이 큼  
  - Chrome 플랫폼 상태 페이지에 따르면 애니메이션, HDR, **점진적 디코딩** 모두 지원함  
    [상세 링크](https://chromestatus.com/feature/5114042131808256)  
  - 실제로 Canary 브라우저에서 테스트했더니 애니메이션이 잘 작동했음  
  - 누군가 농담처럼 말하길, WebP는 사실상 “비디오 포맷인 이미지”인데, JPEG XL은 “이미지 포맷인 비디오”라서 **역설적인 대칭 구조**가 생겼다고 함 😄