# Google이 JPEG XL 지원을 되살렸나? > Clean Markdown view of GeekNews topic #24782. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24782](https://news.hada.io/topic?id=24782) - GeekNews Markdown: [https://news.hada.io/topic/24782.md](https://news.hada.io/topic/24782.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-03T00:33:37+09:00 - Updated: 2025-12-03T00:33:37+09:00 - Original source: [tonisagrista.com](https://tonisagrista.com/blog/2025/google-unkills-jpegxl/) - Points: 5 - Comments: 2 ## Summary 한때 구글이 “관심 부족”을 이유로 버렸던 **JPEG XL**이 Chromium 엔진에 다시 돌아왔습니다. **Meta·Intel·Adobe** 등 주요 기업과 커뮤니티의 꾸준한 압박, 그리고 **PDF Association의 HDR 기본 포맷 채택 움직임**이 이 변화를 이끌었습니다. 특히 **Rust 기반 jxl-rs 디코더 개발**로 보안성과 성능을 동시에 확보하려는 시도가 주목받습니다. 이미지 포맷 혁신이 멈춘 듯 보이던 시점에, 오랜 논쟁 끝에 되살아난 이 포맷이 웹 그래픽의 새 표준으로 자리 잡을지 기대됩니다. ## Topic Body - **Chromium 엔진이 JPEG XL 지원을 복원**하면서, 한때 폐기된 이미지 포맷이 다시 주목받고 있음 - 2022년 구글은 JPEG XL을 “생태계의 관심 부족”을 이유로 제거했으나, **커뮤니티와 주요 기업들의 지속적 압박**이 이어짐 - **Meta, Intel, Adobe, Cloudinary, Krita** 등 여러 조직이 포맷 유지 필요성을 공개적으로 지지함 - 최근 **PDF Association이 HDR 콘텐츠용 기본 포맷으로 JPEG XL 채택 의사**를 밝히며 흐름이 강화됨 - Chrome의 재도입 결정은 **JPEG XL의 대중적 표준화 가능성을 높이는 전환점**으로 평가됨 --- ### JPEG XL의 부활 배경 - 2022년 Chromium 팀은 JPEG XL을 “충분한 생태계 관심 부족”과 “기존 포맷 대비 이점 부족”을 이유로 코드와 플래그를 제거함 - 당시 커뮤니티는 **Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips, Krita** 등 주요 조직의 지지를 표명 - 이후 블로그, 영상, SNS를 통해 **삭제 결정의 부당성**을 지적하는 반응이 이어짐 - 2025년 말, Chromium 팀이 `Obsolete` 상태였던 JPEG XL 이슈를 **`Assigned`로 변경**하며 공식적으로 복원 절차에 착수 - Blink 개발자 그룹에서 **Rick Byers**가 “성능 좋고 메모리 안전한 JPEG XL 디코더를 환영한다”고 언급 - 이 결정은 **Safari의 지원, Firefox의 입장 변화, PDF Association의 채택 움직임** 등 긍정적 신호에 기반함 ### Firefox와 Rust 기반 디코더 개발 - Firefox 팀은 JPEG XL의 **C++ 기반 libjxl 디코더의 보안 위험**을 우려하며 “메모리 안전한” Rust 버전 필요성을 제기 - 이에 따라 Google Research가 **Rust 구현체 jxl-rs**를 개발 시작 - 이 프로젝트는 JPEG XL의 **브라우저 내 안전한 통합 가능성**을 높이는 계기 ### PDF Association의 채택 움직임 - **PDF Association CTO Peter Wyatt**은 JPEG XL을 **PDF 사양의 HDR 이미지 기본 포맷**으로 포함할 의사를 발표 - 이는 문서·출판 분야에서 JPEG XL의 **표준화 가능성**을 강화하는 요소로 작용 ### JPEG XL의 주요 기술적 특징 - **기존 JPEG의 무손실 재압축** 지원으로, 품질 손실 없이 약 30% 용량 절감 가능 - **광색역 및 HDR 지원**, 최대 **32비트 채널** 및 **4,099개 채널** 처리 가능 - **최대 이미지 크기 1,073,741,823×1,073,741,824** 지원으로 초대형 이미지 처리 가능 - **점진적 디코딩(progressive decoding)** 지원으로 웹 전송 효율 향상 - **애니메이션, 알파 투명도, 깊이 맵(depth map)** 기능 포함 - **세대 손실에 강한 구조**로 반복 인코딩 시 품질 저하 최소화 ### 결론 - JPEG XL은 **차세대 이미지 포맷으로서의 요건을 충족**하며, Chrome 엔진의 복귀는 대중적 확산의 결정적 계기 - 커뮤니티의 장기적 압력 끝에 이루어진 복원으로, **웹 이미지 생태계의 새로운 표준 후보**로 부상 - 필자는 Chromium의 재평가를 환영하면서도, **이 결정이 너무 늦게 이루어졌음**을 지적함 ## Comments ### Comment 47095 - Author: xguru - Created: 2025-12-03T05:47:01+09:00 - Points: 1 2022-09-04 [Show GN: J40: JPEG XL 디코더](https://news.hada.io/topic?id=7389) 2022-11-02 [구글 크롬, 110버전 부터 JPEG-XL 지원을 중단할 예정](https://news.hada.io/topic?id=7709) 2023-07-22 [JPEG XL: 시작과 현재 상황](https://news.hada.io/topic?id=9924) 2024-04-05 [Jpegli - 구글이 만든 새로운 JPEG 코딩 라이브러리](https://news.hada.io/topic?id=14155) 2024-09-21 [애플이 아이폰16에 JPEG XL을 사용하는 이유와 사진에 미치는 영향](https://news.hada.io/topic?id=16866) ### Comment 47090 - Author: neo - Created: 2025-12-03T00:34:37+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46108563) - JPEG XL의 덜 알려진 멋진 기능 중 하나는 **JPEG에서 무손실로 트랜스코딩**하면서 약 20%의 저장 공간 절감을 얻는 모드임 원본 엔트로피 비트스트림을 그대로 유지하기 때문에 완전히 **가역적**임 GCP가 이를 DICOM Store API에 적용 중이라, JXL의 공간 절약 효과를 누리면서도 JPEG로 실시간 변환해 제공할 수 있음 우리 회사는 수십 PB 규모의 데이터를 GCP DICOM Store에 저장하고 있어서, 이 기능으로 연간 요금을 크게 절감할 수 있을 것으로 기대함 브라우저의 **네이티브 지원**도 희망 중이며, Chrome 팀이 결국 지원할 것이라는 이야기를 들었음 - 평균적인 JPEG 인코더나 **mozjpeg**와 비교했을 때 어떤 차이가 있는지 궁금함 - 예전에 GCP DICOM Store를 테스트할 시간이 없었는데, 실제로 써보면 어떤지 궁금함 완전한 PACS인지, WADO 구현인지, 아니면 단순한 커스텀 API인지 알고 싶음 - 가역적이라면 그냥 JPEG XL로 저장하고 서비스 시 다시 변환하면 되는 것 아닌지 궁금함 혹시 처리 시간이 많이 걸리는 것인지 물어봄 - 어차피 원본 DICOM을 저장해야 한다면, 트랜스코딩의 의미가 있는지 의문임 저장비용의 대부분은 DICOM 자체일 것 같음 - 결국 GCP의 대형 고객들이 이 기능으로 큰 이익을 보게 되니, **Chrome에서 JXL을 밀어붙이는 이유**가 내부 고객 때문이라는 생각이 듦 - JPEG XL의 경쟁상대는 AVIF가 아님 AVIF는 이미 **사실상 표준**으로 자리 잡았고, 거의 모든 브라우저가 지원하며, Apple의 기본 이미지 포맷으로도 쓰이고 있음 JXL은 아직 브라우저 지원이 약하지만, **보존용·전문 사진·의료용** 등 틈새 시장에서 자리를 잡아가고 있음 10년쯤 후에는 사람들이 그냥 “JPEG”라 부를 정도로 보편화될 수도 있음 AVIF는 오픈·로열티 프리 표준이며, JPEG/WebP보다 압축 효율이 훨씬 높고, JXL과도 비슷한 수준임 JXL의 최대 이미지 크기가 더 크긴 하지만, 실제 채택은 AVIF가 훨씬 앞서 있음 AV2가 나오면 품질 격차는 거의 사라질 것이고, 두 포맷 모두 발전하면서 **비슷한 품질 수준**을 유지할 것으로 봄 - AVIF가 JPEG이나 WebP보다 압축 효율이 좋은 건 당연하지만, JXL과는 **경쟁이 안 됨** 현실적인 품질 설정에서는 JXL이 더 높은 압축률과 빠른 인코딩·디코딩 속도를 보임 게다가 **progressive decoding**도 지원함 AV2가 나오면 따라잡을 수도 있겠지만, 지금은 JXL이 훨씬 앞서 있다고 생각함 - Chrome 팀이 JXL 지원을 중단했던 이유 중 하나가 이미 AVIF가 충분히 좋았기 때문이었음 이번 재검토가 그때의 결정과 연결된 것 같음 - “Apple의 기본 이미지 포맷이 AVIF”라는 말은 잘못된 것 같음 iPhone은 HEIF를 사용함 - libjxl을 직접 써봤는데 **메모리 사용량이 많고 불안정**했음 고해상도 이미지를 인코딩하려면 테라바이트급 RAM이 필요할 정도였음 코드베이스가 엉망이라 놀랐고, 많은 옵션이 제대로 작동하지 않았음 jxl-rs로 다시 시도하는 건 긍정적이지만, 같은 개발자들이 참여하고 있어서 조심스럽게 보고 있음 - Chromium이 JPEG XL 기능을 위해 **jxl-rs crate**를 사용할 가능성이 높음 아마 충분히 안정화될 때까지 기다리다가 통합하려는 듯함 관련 이슈는 [여기](https://issues.chromium.org/issues/40168998#comment507)에서 확인 가능함 - Mozilla는 비슷한 입장이었지만, Google은 한동안 **적대적 태도**를 보였음 사용자들의 반대에도 불구하고 이슈를 닫았고, 최근에야 다시 열었음 아마 **PR 문제**나 내부 불만 때문일 수도 있음 - jxl-rs는 1년 반 넘게 커밋이 없던 시기가 있었음 지금 잘 진행되는 건 **운이 좋았던 결과**일 수도 있음 - JPEG XL의 **참조 구현(C++)** 을 봤는데, 2년 전만 해도 코드 품질이 좋지 않았음 보안 문제가 생길 것 같은 느낌이었음 - 그래서 Mozilla와 Google 모두 **메모리 안전한 구현체**를 조건으로 JXL 지원을 검토 중임 Rust 버전이 개발 중이며, Google은 Chromium의 모든 디코더를 점차 Rust로 교체하려는 계획을 가지고 있음 - 사실 지금 시점(2025년)에 C++로 작성된 대규모 이미지 처리 코드는 그 자체로 **보안 리스크**임 JPEG XL만의 문제가 아님 - JPEG XL의 최대 해상도는 1,073,741,823 × 1,073,741,824로, **수백 페타바이트**에 달하는 초고해상도 이미지를 표현할 수 있음 현실적으로는 압축 후에도 수십~수백 PB 수준임 - 600DPI 기준으로는 한 변이 **마라톤 거리**에 해당함 이런 거대한 이미지를 작은 바이트 공간에 정의할 수 있다면 **DOS 공격 벡터**가 될 수도 있을 것 같음 A4 용지로 환산하려다 Gemini 계산기가 단위를 혼동해서 엉뚱한 결과를 내놨음 - 이런 초대형 이미지는 **타일링과 피라미드 구조**로 다루는 것이 유일한 실용적 방법임 - 지구 전체를 약 4cm 해상도로 찍은 이미지 정도의 크기일 것 같음 - 그 해상도로 셀피를 찍으면 **초해상도 현미경 수준**일 듯함 - JPEG XL은 AVIF와 달리 **효율적인 progressive decoding**을 지원해서, 다운로드 중에도 저화질 미리보기를 빠르게 볼 수 있음 - 과거 HN 논의 모음 [Chromium Team Re-Opens JPEG XL Feature Ticket](https://news.ycombinator.com/item?id=46018994) [FSF Slams Google over Dropping JPEG-XL in Chrome](https://news.ycombinator.com/item?id=35589179) [Google set to deprecate JPEG XL support in Chrome 110](https://news.ycombinator.com/item?id=33399940) [Chromium jpegxl issue closed as won't fix](https://news.ycombinator.com/item?id=40407475) - 더 많은 관련 스레드는 [이곳](https://news.ycombinator.com/item?id=36214955)에 정리되어 있음 - 최근 주요 토론은 [Google Revisits JPEG XL in Chromium After Earlier Removal](https://news.ycombinator.com/item?id=46021179) 참고 - 나는 몇 년째 **.avif**를 사용 중임 완벽하진 않지만 .jpg나 .png보다 훨씬 낫다고 느낌 .webp나 jpeg-xl도 고려했지만, 결과적으로 .avif에 만족함 다만 Google이 웹 표준을 사실상 **좌지우지**하는 건 불만임 상업 기업이 디지털 생태계를 통제하는 건 바람직하지 않음 - “.jpg보다 .avif가 낫다”는 문장에서 **.avif를 두 번 반복**해서 헷갈림 - 고품질 JPEG를 작게 만들고 싶다면 **jpegli**를 써보길 추천함 [jpegli GitHub](https://github.com/google/jpegli) AVIF의 시각적 무손실 설정을 잘 고르면 jpegli보다 작을 수도 있지만, 평균적으로는 jpegli가 더 효율적임 - 참고로 영어에서는 “since some years”보다 “for several years”가 자연스러움 - JPEG XL은 여러 번 재저장해도 품질 손실이 적어서 웹 환경에 유리함 관련 영상: [YouTube 링크](https://www.youtube.com/watch?v=w7UDJUCMTng) - JXL을 없앤 건 “Google 전체”가 아니라 **Chrome 팀**임 JXL은 Google Zurich 연구소의 **Jyrki Alakuijala**가 설계했는데, 그는 Chrome 팀이 아닌 Google Research 소속임 Chrome 팀은 Mountain View 중심의 **폐쇄적 문화**를 가지고 있음 - Jyrki는 **Brotli, WebP lossless, WOFF2, jpegli** 등도 만든 뛰어난 엔지니어임 JpegXL이 폐기된 후 jpegli를 만든 것도 일종의 반응이었음 - 이 상황은 [Conway’s Law](https://en.wikipedia.org/wiki/Conway%27s_law)로 설명할 수 있을 듯함 - C++ 기반의 멀티스레드 의존성이 많아 **보안 공격면**이 커질 수 있다는 이유로 JXL이 지연된 것 같음 Mozilla와 Google 모두 이를 피하기 위해 **Rust 구현체**를 선호함 표준 자체는 확실히 기존보다 개선된 포맷임 - 1억 라인이라니 너무 과장된 수치 같음 - 실제로는 약 **3만 라인** 정도이며, 단일 스레드 버전은 1만 라인 내외임 AVIF보다 바이너리 크기도 훨씬 작고, 명세서도 훨씬 간결함 - Google이 JXL 개발에 참여했으니, **메모리 안전한 디코더를 빨리 만들지 않은 건 자기 책임**임 - 혹시 10만 라인 정도를 말한 것 아닌지? 그중 상당수는 테스트 코드일 것 같음 - 실제 libjxl은 약 **11만 2천 라인** 정도로, 1억 라인 주장과는 3자릿수 차이임 - iPhone 17 Pro의 **RAW 파일**은 JPEG XL로 압축된다고 함