구글이 크롬 155부터 차세대 이미지 형식인 JPEG XL(.jxl)의 디코딩을 정식 지원한다고 밝혔다. JPEG XL은 기존 JPEG 대비 30~50% 더 나은 압축률을 제공하고, 무손실 압축과 내장 HDR, 그리고 기존 JPEG 파일을 화질 손실 없이 재인코딩하는 무손실 트랜스코딩을 지원하는 것이 특징이다. 크롬은 이미 AVIF를 지원하고 있는데, 구글은 두 형식을 모두 시험해보되 사진처럼 디테일이 많은 이미지나 점진적 디코딩이 중요한 경우, 고화질·무손실 압축이 필요한 경우에는 JPEG XL이 특히 유리할 것으로 본다고 설명했다.
JPEG XL은 여러 해에 걸쳐 웹 개발자들이 꾸준히 요청해온 형식이다. 구글은 이번 결정이 버그 리포트, 설문, 개발자 신호 수집, 그리고 브라우저 간 상호운용성을 다루는 Interop 프로젝트 등 여러 경로로 모인 의견에 기반했다고 밝혔다. 실제로 JPEG XL은 2026년을 포함해 최근 몇 년간 Interop 과정에서 인기 있는 제안이었다. 구글은 Interop 2026의 JPEG XL 항목에 참여해 이 형식의 모든 기능에 대한 테스트 범위를 마련하고, 해당 테스트가 크롬에서 통과하도록 작업했다고 한다.
왜 Rust로 다시 작성했나
이번 발표에서 기술적으로 가장 주목할 부분은 디코더를 C++가 아닌 순수 Rust 구현인 jxl-rs로 통합했다는 점이다. 이미지 디코더는 현대 브라우저에서 가장 민감한 공격 표면 중 하나다. 네트워크에서 바로 들어오는, 신뢰할 수 없는 복잡한 바이너리 구조를 렌더러 프로세스 안에서 직접 처리하기 때문이다. C++처럼 메모리 안전성이 보장되지 않는 언어로 작성된 디코더는 경계를 벗어난 읽기, 힙 오버플로, 해제 후 사용(use-after-free) 같은 취약점에 노출되기 쉬웠다.
구글의 보안 모델은 이른바 '2의 규칙'에 따라 샌드박싱과 심층 방어에 의존해왔다. 그러나 구글은 샌드박스를 어디까지나 2차 방어선으로 규정하고, 위험을 원천에서 제거하기 위해 디코더 자체를 메모리 안전한 언어로 옮겼다고 설명한다. 실제로 퍼징과 AI 기반 코드 검토 등 여러 최신 검증 기법을 적용한 결과, 전체 구현 이력에서 메모리 안전성 관련 버그를 한 건도 발견하지 못했다고 밝혔다. 이는 Rust가 메모리 안전성 측면에서 가져오는 실질적 개선을 보여주는 사례로 제시됐다.
성능을 포기하지 않기 위한 작업
메모리 안전성만큼이나 중요한 것이 속도였다. 구글은 메모리 안전한 디코더가 그렇지 않은 최적 구현과 거의 비슷한 속도를 낼 수 있다면 당연한 선택이지만, 성능이 크게 떨어진다면 이야기가 달라진다는 점을 분명히 했다. 최신 코덱 성능의 핵심은 기기에 탑재된 SIMD 하드웨어를 최대한 활용하는 데 있는데, 이를 안전하게 쓰려면 Rust의 target_feature_11 기능이 안정화돼야 했다. 이 기능 덕분에 unsafe 코드 없이도 SIMD 명령어를 사용할 수 있게 됐다.
그다음으로 구글은 libjxl(JPEG XL의 C++ 참조 구현)을 위해 개발된 Highway 라이브러리에서 영감을 받아 jxl_simd라는 SIMD 추상화 레이어를 구축했다. 이를 통해 여러 플랫폼을 지원하면서도 안전하지 않은 연산을 엄격히 검증된 소수의 지점으로 제한할 수 있었고, 그러면서도 SIMD 최적화 성능은 저해하지 않았다고 한다. jxl-rs의 성능 최적화는 libjxl의 성과를 기반으로 하며, 리전 경계를 넘나드는 단계에서 데이터 복사를 최소화하는 범용 처리 파이프라인을 포함한다. 구글은 jxl-rs 성능 대시보드를 통해 다양한 하드웨어에서 이 Rust 재구현의 성능을 추적해왔다.
실무자가 지금 점검할 것
한국의 웹·콘텐츠 실무자 입장에서 이번 발표의 의미는 크게 두 갈래다. 첫째는 전송 효율이다. 사진 중심 서비스나 고해상도 이미지를 많이 다루는 플랫폼이라면 JPEG XL의 무손실 JPEG 트랜스코딩은 기존 자산을 화질 저하 없이 더 작게 만들 수 있는 현실적인 수단이다. 다만 크롬 155의 지원은 '디코딩'에 한정된 것으로, 인코딩 파이프라인과 CDN·스토리지 측 처리는 별도로 준비해야 한다. 둘째는 호환성이다. 아직 모든 브라우저가 JPEG XL을 동일하게 지원한다고 보기 어려운 만큼, picture 요소나 콘텐츠 협상을 통해 AVIF·JPEG 등으로의 폴백을 함께 설계하는 것이 안전하다.
요컨대 이번 변화는 단순히 형식 하나가 추가된 것을 넘어, 브라우저 핵심 컴포넌트를 메모리 안전 언어로 옮기는 흐름이 실제 배포 단계까지 왔음을 보여준다. 구글은 개발자와 콘텐츠 제작자, 플랫폼 운영자가 자신의 파이프라인에서 .jxl 이미지와 애니메이션을 시험해보고 버그를 신고해줄 것을 당부했다. 당장 전면 전환을 서두르기보다는, 자신의 트래픽 구성과 타깃 브라우저 분포를 기준으로 폴백을 갖춘 제한적 도입부터 검토하는 접근이 합리적이다.