▲

Google이 JPEG XL 지원을 되살렸나?

 (tonisagrista.com)
4P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • 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의 재평가를 환영하면서도, 이 결정이 너무 늦게 이루어졌음을 지적함
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 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를 사용할 가능성이 높음
    아마 충분히 안정화될 때까지 기다리다가 통합하려는 듯함
    관련 이슈는 여기에서 확인 가능함

    • 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
    FSF Slams Google over Dropping JPEG-XL in Chrome
    Google set to deprecate JPEG XL support in Chrome 110
    Chromium jpegxl issue closed as won't fix

  • 나는 몇 년째 .avif를 사용 중임
    완벽하진 않지만 .jpg나 .png보다 훨씬 낫다고 느낌
    .webp나 jpeg-xl도 고려했지만, 결과적으로 .avif에 만족함
    다만 Google이 웹 표준을 사실상 좌지우지하는 건 불만임
    상업 기업이 디지털 생태계를 통제하는 건 바람직하지 않음

    • “.jpg보다 .avif가 낫다”는 문장에서 .avif를 두 번 반복해서 헷갈림
    • 고품질 JPEG를 작게 만들고 싶다면 jpegli를 써보길 추천함
      jpegli GitHub
      AVIF의 시각적 무손실 설정을 잘 고르면 jpegli보다 작을 수도 있지만, 평균적으로는 jpegli가 더 효율적임
    • 참고로 영어에서는 “since some years”보다 “for several years”가 자연스러움
    • JPEG XL은 여러 번 재저장해도 품질 손실이 적어서 웹 환경에 유리함
      관련 영상: YouTube 링크

  • 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로 설명할 수 있을 듯함

  • C++ 기반의 멀티스레드 의존성이 많아 보안 공격면이 커질 수 있다는 이유로 JXL이 지연된 것 같음
    Mozilla와 Google 모두 이를 피하기 위해 Rust 구현체를 선호함
    표준 자체는 확실히 기존보다 개선된 포맷임

    • 1억 라인이라니 너무 과장된 수치 같음
    • 실제로는 약 3만 라인 정도이며, 단일 스레드 버전은 1만 라인 내외임
      AVIF보다 바이너리 크기도 훨씬 작고, 명세서도 훨씬 간결함
    • Google이 JXL 개발에 참여했으니, 메모리 안전한 디코더를 빨리 만들지 않은 건 자기 책임임
    • 혹시 10만 라인 정도를 말한 것 아닌지? 그중 상당수는 테스트 코드일 것 같음
    • 실제 libjxl은 약 11만 2천 라인 정도로, 1억 라인 주장과는 3자릿수 차이임

  • iPhone 17 Pro의 RAW 파일은 JPEG XL로 압축된다고 함

답변달기