Hacker News 2026.06.04 104

JPEG XL은 어떻게 탄생했나 — 오픈소스 실험이 만든 차세대 이미지 코덱

이미지 포맷에도 세대교체가 필요해요

우리가 30년 넘게 써온 JPEG, 다들 익숙하죠. 사진 찍으면 .jpg로 저장되고, 웹에 올릴 때도 기본이고요. 그런데 JPEG은 1992년에 나온 포맷이에요. 그동안 화면은 고해상도·HDR로 발전했는데 이미지 포맷은 제자리였던 거죠. 구글이 이번에 JPEG XL이 어떻게 만들어졌는지, 그 뒤에 어떤 오픈소스 실험들이 있었는지를 공개했어요.

JPEG XL이 뭐가 다른가요?

JPEG XL은 두 갈래의 연구가 합쳐져서 태어났어요. 하나는 구글의 PIK, 다른 하나는 클라우드플레어의 FUIF예요. 이 둘의 장점을 합쳐 만든 게 JPEG XL이에요.

핵심 강점을 풀어볼게요.

첫째, 압축률이 훨씬 좋아요. 같은 화질이라면 JPEG보다 파일 크기가 훨씬 작아요. 이게 뭐냐면, 같은 사진을 더 작은 용량으로 저장할 수 있다는 거라 웹사이트 로딩도 빨라지고 저장 공간도 아낄 수 있어요.

둘째, 무손실 JPEG 재압축이 가능해요. 이게 정말 똑똑한 기능인데요, 기존에 갖고 있던 수십억 장의 .jpg 파일을 화질 손해 없이 JPEG XL로 변환해서 약 20% 더 작게 만들 수 있고, 필요하면 원본 JPEG으로 똑같이 되돌릴 수도 있어요. 그동안 쌓아둔 사진들을 버리지 않아도 되는 거죠.

셋째, 점진적 디코딩(progressive decoding)이에요. 이미지를 위에서부터 한 줄씩 그리는 게 아니라, 처음엔 흐릿하게 전체가 보였다가 데이터가 더 오면서 점점 선명해지는 방식이에요. 느린 네트워크에서 특히 체감이 좋아요.

넷째, 무손실·손실 압축을 하나의 포맷에서 다 지원하고, 투명도와 애니메이션, HDR, 아주 큰 해상도까지 한 포맷으로 커버해요. PNG, JPEG, GIF가 하던 일을 혼자 다 할 수 있는 셈이죠.

경쟁자들과 비교하면

차세대 이미지 포맷 경쟁은 치열해요. 구글이 밀던 WebP, 그리고 AV1 영상 코덱에서 파생된 AVIF가 대표 주자예요. AVIF는 아주 낮은 용량에서 화질이 좋지만 큰 사진이나 텍스트가 많은 이미지에선 약점이 있고, 인코딩이 느린 편이에요. 반면 JPEG XL은 사진·그래픽·고해상도 전반에서 고르게 강하고, 무엇보다 기존 JPEG 자산과의 호환성이라는 독보적 무기가 있어요.

다만 정치적인 우여곡절도 있었어요. 한때 크롬이 JPEG XL 지원을 뺐다가 다시 살리는 논쟁이 있었거든요. 반면 애플은 사파리와 iOS에서 일찍 지원을 넣었어요. 그래서 "기술은 좋은데 브라우저 보급이 관건"이라는 평이 오래 따라다녔죠.

한국 개발자에게 주는 시사점

이미지가 많은 서비스(커머스, 미디어, 포트폴리오 사이트)를 운영한다면 주목할 만해요. 이미지 용량은 곧 트래픽 비용이고 로딩 속도거든요. 당장 전면 도입은 브라우저 지원을 봐가며 판단해야 하지만, 서버에서 JPEG XL로 저장해두고 브라우저 지원 여부에 따라 골라서 내려주는 방식은 지금도 시도해볼 수 있어요. <picture> 태그로 포맷별 대체 이미지를 주는 패턴이 대표적이에요.