요약
Chrome 155부터 JPEG XL 이미지를 표시하며, 디코더는 Rust로 만든 jxl-rs를 씁니다.
10월 6일 Chrome 개발자 블로그에 올라온 발표입니다. 개발자들이 Interop(브라우저 간 호환성을 맞추는 공동 프로젝트)에서 몇 년째 꾸준히 지원을 요청한 것이 계기라고 밝혔습니다.
왜 중요한가
- 점유율이 가장 큰 브라우저가 지원하면서 JPEG XL을 웹에서 실제로 쓸 수 있는 길이 열립니다.
- 이미지 디코더는 외부 데이터를 렌더러 안에서 해석하는 주요 공격 지점입니다. Rust 디코더는 메모리 안전 버그를 원천에서 줄입니다.
핵심 내용
- JPEG XL은 JPEG보다 압축 효율이 30~50% 높고 무손실 압축도 지원한다고 소개했습니다.
- HDR을 기본으로 지원하고, 기존 JPEG 파일을 화질 손실 없이 JPEG XL로 바꿀 수 있습니다.
- 내려받는 대로 점점 선명해지는 점진적 디코딩을 세밀하게 할 수 있습니다.
- 퍼징(무작위 입력으로 결함을 찾는 시험)과 AI 보조 리뷰를 거쳤고, 메모리 안전 버그는 나오지 않았다고 했습니다.
- 개발자에게는 AVIF와 JPEG XL을 둘 다 시험해 보고 나은 쪽을 고르라고 권했습니다.
HN 반응
- Firefox도 158 버전에서 지원할 예정입니다. 모질라가 구글을 따라갔을 뿐이라는 주장과 Rust 디코더를 조건으로 건 모질라의 판단이었다는 반론이 맞섰습니다.
- AVIF를 도입했다가 인코딩이 너무 느려 서버 비용이 늘었다는 경험담이 이어졌습니다. 일부 이용자는 JPEG XL도 하드웨어 인코딩이 나오기 전까지는 비슷할 것이라고 우려했습니다.
곧 Firefox도 Stable에 포함합니다. 10월 중에 Safari만 지원하던 상태에서 대다수 브라우저가 지원하는 상태로 넘어가게 되죠. 다사다난한 한 달입니다!
AVIF가 손실이 꽤 큰 압축 같은 일부 경우에는 약간 앞설 수 있지만, JPEG XL을 쓴다고 해서 잘못된 선택이 되지는 않습니다(CPU 사양이 심하게 제한된 환경이 아니라면요). 저는 이 포맷의 강점이 한동안 “만능 이미지 포맷”으로 쓸 수 있을 만큼 활용 범위가 극단적으로 넓다는 데 있다고 봅니다. 기능에 따라 비교 성능이 괜찮은 수준에서 훌륭한 수준까지 걸쳐 있고요. 용도에 따라 AVIF, PNG, JPEG, WebP는 물론이고 높은 비트 심도, 다채널, 레이어가 필요한 일부 TIFF 사용 사례까지 대체할 수 있습니다.
Firefox는 158 버전에서 지원하게 될 것 같습니다.
https://groups.google.com/a/mozilla.org/g/dev-platform/c/3YMV4MS34KA?pli=1
당연하죠, 구글 나리들이 결정하고 나서야 하는 거니까요.
아뇨, 정반대예요. 모질라는 몇 년 전 구글이 JPEG XL을 밀어붙이려 했을 때 반대했고, 안전하다고 자신 있게 말할 수 있는 구현체가 나오기 전에는 탑재하지 않겠다고 했습니다. 이걸 보세요. https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/ :
"우리는 2021년에 플래그 뒤에 숨긴 실험적 JPEG XL 지원을 추가했습니다. 하지만 멀티스레드 C++ 코드가 10만 줄에 달해 Firefox의 공격 표면이 넓어지는 점이 우려스러웠습니다. 그래서 구글 리서치의 JPEG XL 팀에 과제를 던졌습니다. 안전하고, 빠르고, 작고, 호환되는 JPEG XL 디코더를 Rust로 만들어 오면 탑재하겠다고요. 그 과제는 달성되었고, 구글 리서치가 jxl-rs를 만들었으며, 이것이 Firefox의 JPEG XL 지원의 핵심입니다."
전혀 그렇게 된 게 아닙니다.
몇 년 전에는 Chrome과 Firefox 둘 다 실험적 지원이 있었습니다. 2022년 10월에 Chrome이 갑자기 지원 중단을 발표했고, 이유라고 댄 것도 관심 부족이나 기존 포맷 대비 개선 부족 같은 미심쩍은 것들이었습니다. [1] 모질라가 이 포맷에 별로 신경 쓰지 않는다는 공식 입장을 낸 건 한참 뒤인 2023년 1월입니다. [2]
2023년 10월에는 JPEG XL 개발자 한 명이, 도입을 막는 이유가 그것뿐이라면 구글의 담당 팀이 Rust로 디코더를 쓸 준비가 되어 있고 브라우저 통합 작업까지 돕겠다고 했습니다. [3] 한 달 뒤에는 다른 개발자가, 이미 존재하던 또 다른 Rust 디코더가 표준을 준수한다고 확인해 주었고요. [4]
그런데 모질라가 공식 입장을 신경 안 쓴다에서 적합한 Rust 디코더를 기다린다로 바꾼 건 거의 1년이나 지난 2024년 9월이었습니다. [5] jxl-rs 개발이 본격적으로 속도를 낸 것도 그때부터입니다. [6] Chrome도 그 뒤에야 입장을 바꿨는데, 무엇이 마음을 바꿨는지는 추측할 수밖에 없습니다.
구글이 한때 WebP로 그랬던 것처럼 JPEG XL을 모두에게 억지로 떠먹인 적은 없습니다. 모질라가 처음부터 분명하고 원칙 있는 입장을 취한 것도 아니었고요. JPEG XL이 그럴 만한 가치가 있었든 없었든, 이 두 회사 중 어느 쪽도 떳떳하고 모범적으로 행동하지는 않았습니다. 그리고 사용자에게 JPEG XL 지원을 처음 내놓은 주요 브라우저가 Safari였으니, 다른 쪽의 결정에도 그게 한몫했을 수 있습니다.
그 모든 게 제 요점을 뒷받침하는데요, 모질라는 "구글 나리들"이 내려보낸 명령에 그냥 따르는 게 아니라는 겁니다.
Firefox는 AVIF(역시 구글이 확실히 밀어주는 또 다른 최신 이미지 포맷)는 지원하는 데 오래 걸리지 않았습니다. 제가 틀렸다면 바로잡아 주세요. 그런데 모질라가 AVIF의 형편없는 무손실 성능이나 (그 뒤 일부 개선된) 다른 단점들에 난색을 표했다거나, JPEG XL처럼 메모리 안전한 디코더를 쓰라고 고집했다는 얘기는 들어 본 적이 없습니다. 왜 이렇게 대우가 다른 걸까요?
확실히 말할 수는 없지만, 제가 떠올릴 수 있는 가장 그럴듯한 설명은 구글의 막대한 영향력입니다. 그리고 의사 결정의 첫 단계가 구글이 뭘 하는지 보는 거라면, ‘명령에 따른다’는 표현이 갑자기 그렇게 틀린 말도 아니게 됩니다. (점유율이 3%밖에 안 되니 선택지가 별로 없다고 주장할 수도 있겠지만, 그건 논점이 아닙니다.)
모질라는 개방형 미디어 연합(Alliance for Open Media)의 창립 회원이었습니다. Xiph가 Daala를 만들도록 후원했고, 그게 나중에 구글의 VP10과 합쳐져 AV1이 되었죠. 모질라는 AVIF를 포함해 AV1과 관련된 모든 것을 밀어야 할 이해관계가 있습니다. 이건 구글의 환심과는 아무 상관이 없고, 전적으로 모질라 자신의 이익 때문입니다. AVIF가 존재한다는 사실을 지렛대 삼아, 하드웨어 업체들이 AV1 하드웨어 지원을 제공할 유인을 키우려던 겁니다.
왜죠? AV1은 비디오 코덱으로 개발됐습니다. 그렇다고 이미지 포맷으로도 그만큼 좋다는 뜻은 아니고, 개발을 지지한 모두가 이걸 이미지 포맷으로 만드는 데 이해관계가 있다는 뜻도 아닙니다. 누가 멋진 망치를 만들었다고 해서 이제 모든 게 못으로 보여야 하는 건 아니잖아요. (이런 출신 때문에 단점도 따라오는데, 이번에는 아무도 잠깐 멈춰 서서 생각해 보지 않고 또 하나의 이미지 포맷을 던져 넣은 것 같습니다.)
이런 얘기는 처음 읽는데, 이미지 디코딩이 어떻게 하드웨어 지원을 제공할 만한 의미 있는 유인이 되는지 이해하기 어렵습니다(특히 비디오 코덱으로서의 AV1에는 이미 다들 어느 정도 동의하고 있었으니까요). 물론 제가 틀렸을 수도 있습니다. 모질라가 AVIF를 채택한 이유로 이것을 밝힌 링크나, 하드웨어 업체가 AVIF를 하드웨어로 디코딩하는 문제를 진지하게 고려한다는 링크가 있다면 알려 주시면 감사하겠습니다.
[2]는 모질라의 선제적 복종이었습니다. 나중에 배짱을 되찾았다니 다행이죠. (아니면 구글이 언젠가 구현하리라는 걸 알고 있었을 테니 입장을 바꿔도 잃을 게 없었던 것일 가능성이 더 높고요.)
그건 억지 논리입니다. 모질라가 구글의 명령을 따르고 있었다면 중립적인 무입장을 설명하려고 “선제적 복종” 같은 표현까지 동원할 필요가 없겠죠. 구글의 명령을 따랐다면 그냥 지지를 표명하고 끝났을 테고, 그 지지를 철회할 때도 구글과 발맞춰 철회했을 텐데, 그러지 않았잖아요.
다시 묻겠습니다. 구글이 JPEG XL을 지지한 적이 정확히 언제입니까? Chrome 안정판에 넣겠다고 약속한 적은 언제고요? 처음에 실험 기능으로 개발 중이었던 건 맞지만, Firefox도 마찬가지였습니다.
제가 보기에는 두 회사 모두 처음엔 조심스럽게 관심을 보이다가, 구글이 마음을 바꿨다고 하자 얼마 뒤 Mozilla도 별로 신경 쓰지 않기로 한 겁니다. 상관관계가 인과관계는 아니지만, 최소한 두 곳의 입장이 어느 정도 비슷한 궤적을 그린 건 사실입니다. (예컨대 Apple과는 대조적으로요.)
구글이 한때 Mozilla보다 훨씬 더 JPEG XL 도입에 적극적이었다는 생각을 어디서 계속 가져오시는지 모르겠습니다.
그렇지 않았어요. 모질라도 구글과 비슷한 표현을 썼다고요.
모질라
구글
(이것도 한심한 말이긴 했지만, 어쩔 수 없이 그렇게 말해야 하는 처지라면 별수 없죠)
출시 계획은 탄탄해 보이지만, 저는 아무리 일러도 내년 초까지는 실서비스에 배포하지 않을 생각입니다. 그래야 브라우저 보급이 이루어질 시간을 벌 수 있으니까요.
가장 걱정되는 건 몇 년 전 AVIF 때와 같은 문제, 즉 서버 쪽 하드웨어 가속입니다. AVIF를 도입해 봤는데 인코딩 시간이 너무 길어서, 요청이 대기열에 쌓이다가 동기 호출이 타임아웃 나는 일이 생겼습니다. 많이 나아지긴 했지만, 이런 신형 포맷은 전부 연산 자원이 정말 더 많이 든다는 점은 알아 두셔야 합니다. 인코더가 칩에 들어가기 전까지는 WebP 대비 비용 면에서 득이 안 될 수도 있습니다.
저도 AVIF로 똑같은 문제를 겪었습니다. 저희 플랫폼은 사용자가 업로드한 영상 위에 마우스를 올려 썸네일로 영상을 “훑어볼” 수 있게 해 줍니다. 이를 위해 대표 프레임 100개를 프레임당 가로 최대 480px로 격자 형태로 만듭니다. 그래서 이미지가 꽤 크고, JPEG로는 용량을 많이 차지합니다. 파일 크기는 썸네일을 훑어볼 수 있게 되기까지의 지연 시간을 줄여 주기 때문에 중요합니다.
AVIF를 써 봤더니 파일 크기는 훨씬 좋아졌지만, 생성에만 몇 분씩 걸렸습니다. 직접 호스팅해서 쓰는 고객들로부터는 시스템 자원을 너무 많이 잡아먹는다는 피드백도 받았습니다.
그래서 지금은 WebP를 씁니다. CPU를 훨씬 적게 쓰면서 10초쯤이면 생성됩니다. JPEG XL이 그 지표들을 개선할 수 있다면 도입할 의향이 있습니다.
프레임은 어떻게 생성하고 계신가요? 일정 간격으로 프레임을 훑으면서 실제로 영상을 "렌더링"(정확한 용어는 모르겠네요)해야 하는 건 아닌가요? 대신 영상 파일에 완전한 이미지가 저장돼 있는 키프레임만 뽑아 보셨나요?
네, JXL 홍보에서 과소평가되는 부분이 바로 인코딩 비용이에요. effort 7 정도의 cjxl은 고품질 프리셋의 aomenc/rav1e보다 확실히 빠르고, 썸네일이라면 effort 5~6도 용량이 조금 늘어나는 것 말고는 충분해요. 하드웨어 속도까지는 아니지만, 사용자 업로드 파이프라인에서는 절약한 바이트만큼 CPU 비용도 중요하죠. 벤치마크를 돌려 본 지 오래됐다면 다시 돌려 볼 만해요.
이 댓글이 왜 신고당하거나 비추천을 받았는지 모르겠네요.
제가 제대로 이해했는지 확인하고 싶은데요, 우려하시는 건 애플리케이션 서버가 방문자마다 맞춤으로 렌더링하는 이미지에만 해당하는 거죠?
더 오래 유지되고 캐시할 수 있는 종류의 이미지라면 그런 문제는 아마 없을 것 같은데, 맞나요?
사용자에게서 이미지 업로드를 어떤 식으로든 받는다면 해당됩니다. AVIF 이미지를 받기 시작하자 처리 시간이 10~20배쯤 늘었고, 그 처리를 동기 함수에 맡길 수 없다는 걸 알게 됐습니다. 대규모로 지원하려면 비동기로 바꾸고 하드웨어도 올려야 했어요. 저는 미디어 업로드를 받는 레딧 비슷한 작은 사이트를 운영하는데, 결국 AVIF를 포기하느냐 서버 비용을 두 배로 늘리느냐 중에 골라야 했습니다. 그때는 webp 대비 이미지 용량 절감이 그만한 값어치가 없다고 판단했습니다.
JXL도 하드웨어 인코딩이 나오기 전까지는 아마 같은 이야기가 될 겁니다.
고맙습니다! 디코딩 쪽 사정은 생각하지 못했는데, 이미지를 처리해야 하는 사이트라면 (썸네일만 만드는 경우까지 포함하면 아마 대부분이 그럴 겁니다) 사용량 대비 수익이 낮은 곳일수록 새 포맷을 일부러 피하려 할 만한 이유가 있겠다는 짐작이 듭니다.
맞습니다. 휴대폰에서 올라오는 hevc(heic) 인코딩 이미지가 늘어난 것만으로도 저희는 CPU 사용량이 4배가 됐습니다.
인코딩이 아니라 디코딩을 말씀하시는 것 같은데, 제가 놓친 게 있나요?
저는 현재 Firefox ESR에서 지원하지 않는 건 아무것도 배포하지 않습니다. 그러면 2027년 6~7월이 됩니다.
무손실 쪽에서는 이 다재다능함이 다소 단점입니다. 무손실과 손실을 둘 다 담는 포맷에서는 프로그램들이 꼼수를 부리기도 해서, 무손실처럼 보여도 실제로는 아닐 때가 있습니다. 무손실을 기대한다는 걸 (확장자+MIME으로) 직접 표시할 방법이 있었다면 더 좋았을 겁니다.
JPEG 트랜스코딩은 아주 훌륭한 기능입니다.
양자화된 PNG도 있는데 그것도 쉽게 알아낼 수 없어요. JXL은 Modular 모드로 압축한 파일 대부분이 무손실이고, 메타데이터에서 확인할 수 있어요.
문제는 무손실 확장자(예: PNG)가 붙은 파일이 실제로는 손실 처리를 거쳤을 수 있다는 게 아닙니다.
프로그램, 파이프라인, 변환 도구에 무손실로만 동작하라고 지시하는 게 반드시 간단하지는 않다는 게 문제입니다. 공통 스위치는 분명히 없고, 일부 인코더와 포맷에서는 품질 100도 여전히 손실입니다. 실제로 일부 프로그램은 확장자를 보고 자기가 무엇을 해야 하는지 판단합니다.
이게 문제를 해결해 주지는 않지만, 좋은 소식은 JXL이 손실 모드에서 세대 손실(generation loss)이 다른 포맷에 비해 훌륭하다는 겁니다. 높은 품질로 재압축해도 원래 품질이 꽤 잘 유지됩니다.
예전 포맷과는 다르죠.
https://youtube.com/watch?v=qc2DvJpXh-A
예전에 Chrome에서 JXL이 제거되고, 지원할 의사도 없어 보였는데 다시 추가된다니 반갑습니다 1.
JXL은 멋진 이미지 포맷인데, 가장 많이 쓰는 브라우저가 지원하지 않는 바람에 특히 웹에서 쓰임이 크게 제한됐다고 생각합니다.
네, 제 생각에 여기서 가장 큰 이야깃거리는 구글이 JXL을 없앴다가 다시 넣었다는 점입니다. 큰 회사는 자존심도 크기 마련이라 이건 거의 기적에 가깝죠.
이제는 JXL이 드디어 살아남겠다는 느낌이 듭니다.
원래 libjxl은 C로 작성됐고 보안 문제가 끊이지 않았습니다. Chrome이 출시했고 곧 Firefox도 출시할 것은 Rust로 다시 쓴 버전입니다.
이게 입장을 뒤집은 상당한 이유일 거라고 생각합니다. 거대한 C 라이브러리를 새로 브라우저에 넣는 건 큰 걱정거리니까요.