Chrome에 JPEG XL 지원 도입

보안 문제 때문 아니었나? libjxl에는 브라우저에 들어갔다면 WebP 취약점 공격에 맞먹었을 악명 높은 버그들이 있었음. Project Zero도 Google 브라우저 팀에 안전하지 않은 디코더·인코더를 추가하지 말라고 주의를 줬던 것으로 기억함. https://security.snyk.io/vuln/?search=libjxl

핵심은 Google이 제거했던 지원을 되살렸다는 것이라고 봄. 대기업은 자존심도 강한 만큼 거의 기적에 가까움. 이제야 JXL이 확실히 자리 잡을 것 같은 느낌이 듦.

왜 브라우저가 모든 미디어 형식을 직접 지원해야 할까? 시스템 전체에서 쓰는 공유 라이브러리로 배포하면 안 될까?

지원해도 득 볼 사람이 없어서 제거했고, 지원하면 승진할 사람이 생겨서 다시 추가한 것임.

반가운 변화임. JXL과 AVIF 대신 하나로 통일되면 더 좋겠지만, 적어도 WebP의 시대를 끝낼 계기는 될 듯함. WebP는 얻는 이점에 비해 불편만 많이 준 것처럼 보임.
생태계 전반의 지원은 아직 보편적이지 않지만 조금씩 나아지고 있음. iOS 18의 사진 앱에서는 .jxl이 안 됐지만 27에서는 작동함. macOS 27에서도 훑어보기와 미리보기, 썸네일이 잘 작동하며, Linux에서도 문제를 겪지 않았고 이미지 편집기들도 지원을 추가하는 중임.
앞으로 10년은 기존 JPG가 어디에나 남아 있겠지만, 마침내 실질적인 단점도 없고 특허 골칫거리도 없는 더 나은 선택지가 생겨 기쁨.

WebP에 어떤 불편이 있나?

새 이미지 형식이 나올 때마다 앱 간 호환성 난맥상부터 떠오름. Telegram은 아직도 .webp를 제대로 지원하지 않고 스티커로 취급함. macOS가 새 형식을 지원하기까지 오래 걸릴 수 있고, 이미지 뷰어는 더 오래 걸리거나 끝내 지원하지 않기도 함.

JPEG XL은 특허 부담이 크지 않고 용도에 맞는 라이선스를 갖췄음. 구현 복잡성 외에는 사용하거나 지원에 포함하지 않을 사업적·기술적 이유가 거의 없음. 뛰어난 압축률과 무손실 모드, 투명도 등을 갖춰 앞으로 20여 년간 대표 이미지 형식이 될 자격이 충분함.
특히 마음에 드는 기능은 점진적 렌더링임. 필요한 픽셀 데이터 비율에 맞춰 출력 스트림을 잘라내면 되므로 썸네일을 따로 만들 필요가 없어짐.
iOS도 이제 촬영 사진에 기본 지원하지만, 내가 쓰는 iPhone 15 Pro Max보다 최신 기종이어야 함.

JPEG XL은 웹 안팎에서 현재 쓰이는 주요 이미지 형식 대부분을 대체할 만큼 기능 구성이 균형 잡혀 있다고 봄. 완벽한 형식은 없고 특수 목적 형식도 계속 필요하겠지만, 이미지 형식계의 USB가 될 가능성이 충분함.

형식 입출력을 위한 시스템 공통 플러그인 구조가 일부 플랫폼 밖으로 확산되지 못한 것이 아쉬움. AmigaOS에는 1980년대부터 DataTypes가 있었고, BeOS에는 1990년대부터 Translators가 있었음.
Linux·자유 오픈소스 생태계는 앱이 자체 입출력 필터 대신 ImageMagick이나 FFmpeg 같은 공통 라이브러리·도구를 쓰는 경우가 많아 어느 정도 비슷함. 그래도 특정 형식의 라이브러리 하나만 시스템에 설치하면 기존 소프트웨어 모두가 즉시 읽고 쓸 수 있으면 좋겠음.

실수로 Windows 컴퓨터에 HEIC를 넣거나 학생이 학교 학습관리시스템에 WebP를 올리려 할 때마다 답답함.

Safari는 아직 점진적 로딩을 켜지 않았는데, Android를 제외한 Firefox와 Chrome은 켠 상태로 출시해 버림. libjxl은 Safari가 JPEG XL 지원을 추가하기 전부터 이 기능을 갖고 있었음. 거북이가 토끼를 추월한 셈이고, 3년 만에 이제 Safari 차례가 됨.

한 가지 단점은 확장자만으로 손실·무손실 여부를 알 수 없다는 것임.

요즘은 PNG도 확실히 구분할 수 없음. 압축률을 높이려고 PNG 인코딩 전에 이미지를 양자화하는 최적화 도구가 많기 때문임.

WebP와 AVIF도 마찬가지임. 현대적인 이미지 코덱은 모두 손실·무손실 모드를 제공하는 듯하며, 손실은 JPEG, 무손실은 PNG로 나뉘었던 것이 오히려 역사적인 특이점처럼 보임.

무손실 JPEG XL을 나타내는 비공식 관례로 .ll.jxl을 쓰면 어떨까? 나는 앞부분에 메타데이터가 있는 Markdown 파일에 .frontmatter.md나 .fm.md를 쓰고 있음.

답답하긴 하지만, 무손실을 그저 최고 화질로 본다면 대부분의 사용자에게는 그리 큰 문제가 아닐 듯함. 개인적으로는 무손실 이미지와 애니메이션에 별도 확장자를 쓰는 관례가 합리적이라고 봄.

Google 경영진이 JPEG XL을 막으려 했고 엔지니어들이 어떻게 설득했는지, 그 내부 공방을 다루는 글이길 바랐음. 내 추측으로는 엔지니어들이 논쟁에서 이겼다기보다, 다른 브라우저가 모두 지원하자 경영진이 포기한 듯함.

큰 전환점은 Adobe가 차기 PDF 명세의 승인된 이미지 압축 알고리즘으로 JPEG XL을 채택한 일이었던 듯함. 브라우저들이 PDF 렌더러 역할까지 하려 하니 JPEG XL 디코더를 포함할 수밖에 없어진 셈임. 성과가 있다면, 어차피 배포해야 하는 디코더를 PDF 렌더러뿐 아니라 태그에서도 쓸 수 있게 한 것임.

정보가 부족하고 선입견이 강하면 여러 가설이 생기는 게 흥미로움. 실제 사정은 더 단순함. 기존 라이브러리의 보안 문제를 해결할 비용을 들일 가치가 없다고 판단해 형식을 포기했지만, 업계 채택이 늘고 더 안전한 새 라이브러리가 등장하면서 결정이 바뀐 것임. 새 Rust 라이브러리를 개발한 곳은 Google이지만, 투자 주체는 Chrome 팀이 아니었음.

실제로는 그런 경위가 아니지 않나? 여기에 정리한 연혁을 참고하면 됨. https://news.ycombinator.com/item?id=49445897. JPEG XL은 명세부터 참조 구현, 더 안전한 Rust 구현까지 Google이 크게 기여한 작업임. Google 경영진이 왜 막으려 했겠나? 내가 파악하기로는 규모가 크고 당시 채택이 적었으며 웹 용도로는 AVIF·WebP와 상당히 겹친다는 이유로 Chrome 엔지니어들이 원하지 않았던 것임. 경영진의 관련 지침이 전혀 없었다는 뜻은 아니지만, 엔지니어들도 무엇을 넣고 뺄지 상당한 발언권을 가짐.

Apple의 iOS 기본 지원도 영향을 줬을 듯함. iPhone 16 이상에는 촬영 사진을 Apple 독자 형식 대신 JPEG XL로 저장하는 옵션이 있음.

JPEG XL에 불안·불확실성·의심을 충분히 퍼뜨려 놓은 탓에 이제 멀쩡한 조직이라면 채택하지 않을 것임. 절대 권력자 Google이 2027년에 또 지원을 없앨 수도 있음.

예제 이미지가 로딩되는 모습을 보니 256색 인터레이스 GIF가 한 줄씩 느리게 내려오던 옛날이 떠오름.

어떤 이유에선지 점진적 로딩이 퇴보한 것 같은 느낌이 듦. 예전에는 점진적 JPEG와 PNG도 실제로 단계적으로 표시됐고, JPEG는 첫 단계가 흑백에 가깝게 보이는 경우도 흔했던 것으로 기억함.

이제 주요 브라우저와 운영체제 모두 지원하는 셈임. Firefox 지원도 곧 들어올 예정임.

Firefox에서는 이미 한동안 기능 플래그를 켜면 사용할 수 있었던 것으로 알고 있음.

다음은 휴대전화와 카메라 차례임. 수년간의 파편화 끝에 다시 공통 이미지 형식을 갖게 되면 정말 좋겠음.

Android Chrome에서도 활성화하는 건가? 그렇다면 적어도 기본 지원은 완성되는 셈임. 물론 상당수 Android 휴대전화에 그 버전이 보급되기까지는 시간이 걸릴 것임.
다만 caniuse가 최신 상태라면 macOS와 iOS의 Safari는 여전히 점진적 렌더링과 애니메이션을 지원하지 않음. https://caniuse.com/jpegxl
찬물을 끼얹으려는 건 아니며, 목표에 도달하기 위해 필요한 한 걸음을 내디딘 것임.