Chrome에 JPEG XL 디코딩 지원을 적용합니다

AI 요약

Chrome 155부터 JPEG XL(.jxl) 이미지 디코딩을 지원합니다. Chrome 팀은 JPEG XL이 사진과 고화질 이미지, 무손실 압축, 세밀한 점진적 디코딩이 필요한 경우 유용하다고 설명합니다. 다만 모든 상황에서 JPEG XL이 더 낫다고 단정하지 않고, AVIF와 함께 시험해 적합한 형식을 고르라고 권합니다.

Rust로 디코더를 다시 구현합니다

이미지 디코더는 네트워크에서 받은 복잡한 바이너리 데이터를 렌더러 프로세스에서 처리하므로 브라우저의 주요 공격 표면입니다. 메모리 안전성을 보장하지 않는 C++ 디코더에서는 범위를 벗어난 읽기, 힙 오버플로, 해제 후 사용 같은 취약점이 생길 수 있습니다. Chrome은 샌드박스와 다층 방어를 사용하지만, 이를 보조 수단으로 보고 위험을 코드 수준에서 줄이기 위해 순수 Rust 구현인 jxl-rs를 통합했습니다.

메모리 안전성만 확보하고 성능을 크게 희생하면 적용하기 어렵다는 점도 짚습니다. 최신 코덱의 성능에는 SIMD 활용이 중요합니다. Rust의 target_feature 기능이 안정화되면서 unsafe 코드 없이 SIMD 명령을 사용할 수 있게 됐고, Chrome 팀은 C++ 라이브러리 Highway에서 영감을 얻은 SIMD 추상화 계층 jxl_simd를 만들었습니다. 이를 바탕으로 여러 플랫폼에서 SIMD 최적화를 적용하면서 unsafe 연산은 검토를 거친 소수의 지점에 한정했습니다.

jxl-rs는 libjxl의 최적화 기법도 활용합니다. 영역 경계를 넘는 처리 단계를 위한 일반화된 파이프라인을 구성하고, 데이터 복사를 줄여 하드웨어 성능을 끌어냅니다. 팀은 여러 하드웨어에서 성능을 측정하는 대시보드를 운영하며, 퍼징과 AI 코드 검토 등으로 구현을 검증했다고 밝혔습니다. 구현 전반에서 메모리 안전성 버그를 발견하지 못했다고도 전합니다.

개발자 요청과 상호운용성

Chrome 팀은 버그 보고, 설문, Developer Signals Project, Interop Project 등 여러 경로로 개발자 의견을 살핍니다. JPEG XL은 2026년 Interop Process에서 인기 제안이었고, 그 전부터도 지원 요청이 이어졌다고 설명합니다. 브라우저마다 형식 동작이 달라지지 않도록 Interop 2026 JPEG XL Investigation에도 참여해 기능별 테스트를 마련하고 Chrome에서 통과하는지 확인했습니다.

Hacker News 반응

• @theandrewbailey — Chrome이 JPEG XL을 지원하는 일은 반갑습니다. AVIF는 픽셀당 1비트 이하의 매우 강한 압축에서 더 낫고, 그보다 높은 비트레이트에서는 JPEG XL의 효율이 더 좋습니다. JPEG XL이 그 구간에서도 AVIF를 앞설 수 있나요?
  • @gcr — 제 경험은 다릅니다. 학회 자료를 아주 작은 썸네일로 압축해 봤는데, 그 용도에서는 JPEG XL이 AVIF보다 훨씬 나았습니다.
  • @Broiler9437 — 가능성은 있습니다. 참조 인코더는 개선 여지가 많고, 무손실 압축도 더 나아질 부분이 있습니다.
• @xx_ns — 한때 Chrome에서 빠졌던 JPEG XL 지원이 다시 들어와 반갑습니다. 가장 많이 쓰이는 브라우저가 지원하지 않아 웹에서 활용하기 어려웠습니다.
  • @innocent_name — 이전에는 보안 문제 때문 아니었나요? libjxl에는 브라우저에 들어갔다면 WebP 취약점만큼 위험했을 버그가 있었던 것으로 기억합니다.
  • @dncornholio — 그래서 Google이 Rust로 자체 디코더를 구현한 것 같습니다.
  • @mrandish — 예전 미지원 사유는 이해할 만하지만 설명이 모호합니다. 불과 2년 뒤에 결정을 바꾼 이유도 함께 설명했으면 좋겠습니다.
• @2OEH8eoCRo0 — 브라우저가 왜 모든 미디어 형식을 직접 지원해야 하나요? 운영체제 전체가 쓰는 공유 라이브러리로 제공하면 안 되나요?
  • @burnte — 브라우저가 지원 형식을 직접 관리하면 사용자가 라이브러리를 설치하지 않아 기능이 깨지는 일을 막을 수 있습니다.
  • @groundzeros2015 — 브라우저는 일관된 플랫폼을 제공하려 합니다. 운영체제 업체가 브라우저의 필요에 맞춰 지원하리라 기대하기 어렵습니다.
• @kelseydh — 새 이미지 형식이 나올 때마다 앱 사이의 호환성 문제가 걱정됩니다. Telegram은 아직 WebP를 스티커처럼 처리하고, 이미지 뷰어 상당수는 새 형식을 지원하지 않습니다.
  • @zarify — Windows에서 HEIC 파일을 받거나 학생이 학교 학습관리시스템에 WebP를 올릴 때마다 곤란합니다.
• @tepmoc — 확장자만 보고 손실 압축인지 무손실 압축인지 알 수 없다는 점은 단점입니다.
  • @AshleysBrain — WebP와 AVIF도 마찬가지입니다. 최신 이미지 코덱은 손실·무손실 모드를 모두 갖춘 경우가 많습니다.
• @surajrmal — 더 단순한 설명은 기존 라이브러리의 보안 문제를 해결할 비용이 지원 가치를 넘었고, 산업 채택이 늘고 안전한 새 라이브러리가 나오자 결정을 바꿨다는 것입니다.
  • @F3nd0 — 처음 JPEG XL을 거부할 때 Google이 밝힌 이유에는 보안 문제가 거의 나오지 않았습니다.

원문: Chrome Developers / 번역·요약: Trawling