Chrome의 JPEG XL 지원, 압축률과 표시 시간을 따로 봐야 한다

사진 파일을 줄였는데도 사용자가 내용을 알아보는 시점은 늦을 수 있다. 전송량, 디코딩에 드는 시간, 화면에 처음 나타나는 정보가 서로 다르기 때문이다. Chrome의 JPEG XL 지원 소식에서 내가 확인하고 싶은 것도 이 세 가지다. 새 확장자를 추가할 때는 최종 파일 크기와 사진을 기다리는 경험을 따로 비교해야 한다.

Chrome 팀은 2026년 10월 6일 공식 발표에서 Chrome 155부터 JPEG XL 이미지 디코딩을 지원한다고 밝혔다. GeekNews 등록은 10월 7일 오후 10시 42분, 한국 시각이다. JPEG XL은 손실·무손실 압축과 HDR, 점진적 디코딩 등을 지원하는 이미지 형식이다. 여기서 디코딩은 압축된 데이터를 화면에 표시할 픽셀로 풀어내는 처리다.

새 형식을 받아들이는 데도 유지보수 조건이 있다

공식 발표는 웹 개발자의 지속적인 요청을 지원 결정의 배경으로 설명한다. 또 새로운 디코더로 순수 Rust 구현인 jxl-rs를 통합했다. 브라우저의 이미지 디코더는 인터넷에서 받은 복잡한 바이너리를 처리하므로, 형식을 하나 추가하면 관리해야 할 공격 표면도 늘어난다. 구현 선택의 이유

Chrome 팀은 메모리 안전성을 확보하면서 SIMD와 데이터 복사 최소화로 성능을 맞췄다고 설명한다. SIMD는 여러 데이터에 같은 연산을 한 번에 수행하는 CPU 기능이다. 발표에는 퍼징과 코드 검토에서 메모리 안전성 버그를 발견하지 못했다는 보고도 있다. 퍼징은 다양한 비정상 입력을 자동으로 넣어 결함을 찾는 검사다. 이는 팀이 확인한 범위이며 모든 종류의 결함이 없다는 보장은 아니다.

나는 이 변화를 형식의 장점과 구현의 유지보수 비용을 함께 평가한 결정으로 읽는다. Chromium의 보안 원칙도 안전한 언어 안의 unsafe 사용에는 작고 검토 가능한 범위, 안전한 API, 전제 조건의 문서화를 요구한다. Rust라는 이름만으로 검토가 끝나는 구조는 아니다. 다만 웹 개발자가 이 내부 구현을 선택할 필요는 없다. 서비스에서 확인할 것은 해당 브라우저와 사용 경로가 요구하는 이미지를 제대로 표시하는가다.

압축률과 첫 표시 시점은 다른 측정값이다

공식 발표는 JPEG 대비 30~50% 더 나은 압축을 소개하면서도 AVIF와 JPEG XL을 함께 시험하라고 권한다. 이 비율을 우리 이미지의 예상 절감률로 그대로 쓰기는 어렵다. 발표 본문에는 비교 이미지와 인코더 설정을 재현할 상세 조건이 없고, 원본의 종류와 허용할 화질 손실에 따라 결과가 달라질 수 있다. 발표의 수치와 권고 이 글에서는 코덱을 실행하거나 성능을 재측정하지 않았다.

내가 더 주목한 기능은 점진적 디코딩이다. 파일 전체를 받기 전에 거친 형태를 보여 주고 데이터가 도착할수록 세부 정보를 채우는 방식이다. 큰 사진을 느린 연결에서 보여 줄 때는 최종 용량이 비슷해도 내용을 먼저 파악할 여지가 있다. 반대로 작은 카드 이미지나 캐시된 사진에서는 이 이점이 작을 수 있다. 점진적 JPEG도 있으므로 비교 대상에 현재 쓰는 JPEG의 인코딩 방식까지 기록해야 한다.

비교할 요구	함께 관찰할 항목
사진의 세부 질감을 유지한다	같은 표시 크기의 시각적 품질과 전송 바이트
느린 연결에서 내용을 먼저 보여 준다	첫 형태가 보이는 시점과 완전히 표시되는 시점
큰 사진을 모바일에서 연다	전송 시간과 디코딩 시간, 메모리 사용량

무손실 JPEG 트랜스코딩도 의미를 구분해야 한다. 트랜스코딩은 이미 인코딩된 파일을 다른 형식으로 바꾸는 일이다. libjxl README는 JPEG 입력을 기본적으로 무손실 재압축하고, 다시 JPEG로 출력할 때 원래 JPEG 파일을 복원한다고 설명한다. 이미 JPEG 압축에서 없어진 촬영 정보를 되살리는 기능은 아니다. 원본 보관과 웹 표시용 새 인코딩을 같은 작업으로 취급해서는 안 된다.

이미지 태그에서 보이는 것만으로 검증을 끝내지 않는다

Interop 2026의 조사 범위에는 높은 비트 깊이, 넓은 색 영역, HDR, 투명도, 방향 정보, 애니메이션과 점진적 표시가 따로 들어 있다. 이미지 태그뿐 아니라 CSS 배경, Canvas, createImageBitmap() 같은 연결 지점도 구분한다. 같은 .jxl 파일이 열린다는 사실만으로 서비스가 사용하는 모든 기능의 호환성을 확인한 것은 아니다.

예를 들어 상품 사진을 Canvas로 편집하고 다운로드하는 서비스라면 첫 표시 이후의 경로도 시험해야 한다. HDR 사진은 색상과 밝기 처리가 중요하고, 애니메이션을 쓰면 프레임과 반복 동작을 확인해야 한다. 나는 브라우저 이름으로 지원 표를 끝내기보다 실제 방문자의 버전·운영체제와 필요한 기능을 묶어 검증하겠다. Interop의 조사 목록도 모든 브라우저가 모든 항목을 똑같이 지원한다는 선언으로 읽지 않는다.

배포에는 대체 이미지가 필요하다. MDN의 picture 문서는 브라우저가 source의 형식과 화면 조건을 검토하고, 지원하지 않는 형식은 건너뛰며 맞는 후보가 없으면 img를 사용한다고 설명한다. JPEG XL을 후보로 추가하면서 기존 JPEG나 WebP 경로를 유지할 수 있다. 후보의 순서를 정하는 일은 개발자의 선택이며, 브라우저가 파일을 모두 받아 가장 작은 것을 골라 주는 방식으로 기대해서는 안 된다.

브라우저 지원과 서버의 이미지 변환 지원도 별개다. 썸네일 생성기, CDN 변환 기능, 캐시 키와 저장 정책을 함께 확인해야 한다. 여러 형식과 해상도를 미리 만들면 저장량과 변환 시간이 늘고, 요청마다 생성하면 첫 요청의 비용과 캐시 적중률이 중요해진다. 참조 구현인 libjxl의 현재 README는 보안 수정이 포함된 v0.12 업데이트를 권고한다. Chrome의 Rust 디코더 소식을 서버 변환 도구의 보안 상태까지 해결됐다는 뜻으로 확대하면 안 된다.

대표 화면 하나에서 이득과 추가 비용을 같이 본다

고해상도 사진의 세부 표현이 중요한 갤러리나 상품 상세 페이지라면 먼저 비교할 가치가 있다고 본다. 반면 작은 썸네일이 대부분이고 기존 AVIF·WebP 변환 경로가 안정적이라면 형식을 늘리는 비용부터 계산하는 편이 낫다. 필요한 품질과 표시 경험을 이미 충족한다면 기존 구성을 유지하는 것도 합리적인 선택이다.

첫 실험은 사진 몇 장의 파일 크기 표보다 대표 화면 하나로 잡겠다.

1. 원본과 표시 크기를 고정하고 JPEG, 기존 형식, JPEG XL의 품질을 비교한다. 인코더와 설정도 남긴다.
2. 캐시가 없는 느린 연결에서 첫 형태, 충분한 세부 정보, 완전한 표시까지의 시간을 나눠 관찰한다.
3. 지원 환경과 미지원 환경에서 선택된 이미지 URL을 확인하고, 서비스가 쓰는 편집·다운로드 경로까지 시험한다.
4. 변환 시간, 저장량, 캐시 적중률과 운영 비용을 기록해 줄어든 전송 비용과 비교한다.

첫 형태가 빨리 나타나는 것은 유용한 신호지만 구매 판단에 필요한 세부 정보가 언제 보이는지도 중요하다. 두 시점을 함께 봐야 흐릿한 사진을 일찍 보여 주는 것만으로 성공을 선언하지 않는다. JPEG XL을 도입할 근거는 압축률 한 줄보다 구체적이어야 한다. 필요한 품질이 유지되고, 실제 방문 환경에서 기다림이 줄며, 추가된 변환·배포 비용을 감당할 수 있는가. 이 조건이 맞는 화면부터 범위를 넓히겠다.

참고 자료

• Shipping JPEG XL in Chrome — Chrome for Developers
• Interop 2026 JPEG XL Investigation
• The Rule Of 2 — Chromium Docs
• JPEG XL reference implementation — libjxl
• picture 요소 — MDN