크롬 155 안정화 버전의 JPEG XL 기본 디코딩 지원 개시
구글이 2026년 10월 6일 공식 개발자 채널인 Chrome for Developers 블로그를 통해 웹 브라우저 구글 크롬(Google Chrome) 155 안정화(Stable) 버전부터 차세대 이미지 규격인 JPEG XL(.jxl)의 기본 디코딩 지원을 정식 출시했다고 밝혔습니다. 이번 릴리스에 포함된 지원 기능은 기본 활성화(Default-on) 형태로 적용되었기 때문에, 일반 사용자와 개발자가 브라우저 내부의 실험적 기능 플래그를 별도로 조작할 필요 없이 웹페이지에 임베드된 .jxl 확장자 이미지를 브라우저 화면에서 즉시 확인하고 렌더링할 수 있습니다.
다만 공식 문서에 명시된 바와 같이 이번에 브라우저에 포함된 기능의 범위는 웹 리소스로 수신된 이미지 파일을 해석하여 화면에 표시하는 디코딩 및 렌더링 단계로 엄격하게 한정됩니다. 브라우저 엔진 차원에서 .jxl 포맷 파일을 직접 인코딩하거나 생성하는 기능은 포함되지 않았으므로, 웹 서비스 실무 운영팀은 cjxl과 같은 독립적인 이미지 처리 유틸리티나 사전 빌드 파이프라인 도구를 활용하여 필요한 그래픽 리소스를 사전에 변환하여 서버에 배치해야 합니다.
코드 폐기 결정 번복과 웹 표준 복원 과정 분석
이번 크롬 155의 정식 도입은 구글이 수년 전 내렸던 기술 정책을 전면적으로 뒤집은 결과라는 점에서 웹 개발 생태계의 비상한 관심을 모으고 있습니다. 구글은 당초 크롬 91 버전에서 실험적 플래그 형태로 JPEG XL을 지원한 적이 있었으나, 2022년 10월 크로미엄(Chromium) M110 버전 릴리스 시점에 생태계 전반의 관심도가 부족하고 기존 레거시 포맷 대비 차별화된 성능 우위가 충분하지 않다는 사유를 들어 관련 지원 코드를 프로젝트에서 완전히 폐기 및 제거한 바 있습니다.
하지만 2023년 9월 애플이 사파리 17.0 버전에 JPEG XL 지원을 정식 탑재하며 반전의 계기가 마련되었고, 주요 브라우저 엔진 제조사 간의 크로스 플랫폼 상호운용성을 점검하는 프로젝트인 Interop 2026의 핵심 조사 과제로 JPEG XL이 선정되면서 분위기가 급변했습니다. 개발자 커뮤니티의 지속적인 복원 요구와 함께 기술적 유용성이 거듭 재평가되면서, 구글은 2026년 상반기 메인 브랜치 재도입을 공식 결정하고 마침내 크롬 155 버전을 통해 프로덕션 배포를 완료했습니다.
메모리 안전성 확보를 위한 Rust 디코더 jxl-rs 도입
크롬 개발팀은 이번 지원을 복원하는 과정에서 기존의 전통적인 C++ 라이브러리(libjxl)를 브라우저 코어에 그대로 탑재하는 대신, 메모리 안전성(Memory Safety)을 원천적으로 보장하는 Rust 언어 기반 구현체인 'jxl-rs' 디코더를 새롭게 채택하여 브라우저에 통합했습니다. 과거 이미지 파싱 라이브러리에서 발생했던 버퍼 오버플로 등 파괴적인 메모리 결함 취약점(예컨대 2023년 libwebp에서 발견되었던 CVE-2023-4863 등)의 재발 위험을 소프트웨어 아키텍처 단계에서 완전히 억제하기 위한 전략적 선택이었습니다.
구글 엔지니어링팀은 jxl-rs 기반 엔진에 광범위한 퍼징(fuzzing) 보안 테스트를 수행하고, SIMD(단일 명령 다중 데이터) 벡터화 연산 최적화를 함께 적용했다고 설명했습니다. 이를 통해 C++ 엔진과 견주어도 손색없는 디코딩 렌더링 성능을 확보하는 동시에, 브라우저 메모리 충돌이나 잠재적 악성 코드 실행 위험을 원천 방어하여 안전한 웹 서핑 환경을 구축했다는 점을 기술적 성과로 강조하고 있습니다.
압축 성능 홍보 주장과 실제 기술 규격 간의 실무 차이
기술 제공사 측은 JPEG XL이 기존 레거시 JPEG 대비 30~50% 더 나은 압축률을 보인다고 강조하지만, 이는 자연 풍경이나 인물 사진과 같은 표준적 사진 리소스 환경에서 산출된 대표 수치로 평가해야 합니다. 그래픽 디자인 요소나 텍스트가 다수 포함된 이미지, 혹은 다양한 압축 품질 파라미터 설정에 따라 실제 대역폭 절감 효율은 상당한 편차를 나타낼 수 있습니다. 또한 기존 JPEG 파일의 DCT 계수를 무손실로 다시 묶어 약 20% 용량을 줄여주는 무손실 재압축 기능 역시 브라우저의 실시간 연산이 아니라 원격 서버에서 사전 처리된 리소스를 전송받아야 효력을 발휘합니다.
다른 최신 포맷과의 적합성을 비교할 때 JPEG XL은 고화질 무손실 사진 보존, 네트워크 대역폭에 반응하는 미세 점진적 디코딩(Progressive decoding), 대용량 이미지 처리 영역에서 뚜렷한 장점을 가집니다. 반면 영상 코덱인 AV1에서 파생된 AVIF는 초저용량 환경의 고압축 손실 그래픽이나 짧은 웹 애니메이션 구현 부문에서 여전히 비교 우위를 유지하고 있으므로, 서비스의 목적과 리소스 유형에 따른 보완적 접근이 필수적입니다.
크로스 브라우저 호환 전략과 모바일 환경의 한계 과제
크롬과 사파리라는 양대 브라우저가 지원 풀에 들어왔음에도 불구하고, 실제 서비스 배포 현장에서는 클라이언트 호환성을 고려한 다중 전송 전략이 여전히 강제됩니다. 사용자의 브라우저 업데이트 시점 지연 및 기타 엔진의 정식 탑재 일정 등을 고려할 때 단일 .jxl 리소스 배포는 위험이 따르며, HTML picture 태그를 활용해 JPEG XL을 우선 제공하되 WebP나 레거시 JPEG로 폴백(Fallback)하는 파이프라인을 유지해야 안정적인 사용자 경험을 보장할 수 있습니다.
또한 하드웨어 고정 기능 가속(ASIC이나 전용 GPU 파이프라인)이 아직 본격화되지 않은 채 CPU의 SIMD 소프트웨어 연산에 전적으로 의존하는 디코딩 구조가 저사양 모바일 기기의 발열과 배터리 소모에 미치는 영향은 독립적인 벤치마크 데이터를 통해 지속 검증되어야 합니다. 여기에 더해 사파리 등 일부 환경에서 점진적 다운로드 렌더링이 완전히 지원되지 않는 호환성 격차가 보고된 만큼, 교차 브라우저 간의 시각적 일관성을 확보하기 위한 실무 모니터링이 요구됩니다.
출처
Chrome for Developers의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Shipping JPEG XL in Chrome (새 창)
