2026년 웹 이미지 포맷 선택 가이드: JPEG의 제국, AVIF의 부상, JPEG XL의 망명

12 MP 사진 한 장(4000 × 3000 픽셀)을 여섯 가지 방식으로 내보내 보자. PNG: 24 MB. 품질 90의 JPEG: 3.4 MB. 체감 품질을 맞춘 WebP: 약 2.4 MB. 체감 품질을 맞춘 AVIF: 약 1.7 MB. 256색 상한까지 디더링한 GIF: 6 MB, 화면 곳곳에 밴드 현상이 보인다. SVG는 이 목록에 없다. SVG가 기술하는 것은 도형이고, 사진은 도형이 아니기 때문이다.

화면에 보이는 이미지는 같은데, 디스크 위에서는 14배 차이가 난다. 이 격차는 취향이 아니라 엔지니어링의 결과다. 모든 포맷은 특정 연도의 특정 제약 아래에서 내린 결정의 묶음이고, 그 결정들은 오늘날에도 페이지 무게에 그대로 나타난다.

이 글은 그 실험을 '무엇을 선택할 것인가'의 관점에서 정리한 것이다. 각 포맷이 픽셀에 실제로 어떤 처리를 하는지, 2026년 중반에 어떤 브라우저가 디코딩하는지, 실제 웹이 지금 무엇을 서빙하고 있는지 살펴 보고, 마지막에는 팀 위키에 그대로 붙여 넣을 수 있는 표를 제시한다.

후보들, 하나씩

JPEG (1992). 동작 방식: 이미지를 8 × 8 블록으로 나누고, 각 블록을 이산 코사인 변환으로 주파수로 바꾼 뒤, 인간 시각 모델에 따라 미세한 디테일을 0 쪽으로 양자화한다. 강점: 90년대 중반 이후 만들어진 모든 기기에서 디코딩되고, 인코딩이 빠르고, 연속 톤 사진에 탁월하다. 약점: 투명도도 애니메이션도 없고, 선명한 가장자리와 텍스트 주변에 링잉이 눈에 띄고, 다시 저장할 때마다 품질이 누적되어 저하된다. 사진과, 어디서든 반드시 열려야 하는 모든 것에 적합하다.

PNG (1996). 동작 방식: 완전한 무손실. 각 스캔라인을 예측기로 필터링한 뒤, gzip과 같은 LZ77 + 허프만 조합인 DEFLATE로 포장한다. 강점: 픽셀 단위로 정확한 출력, 완전한 알파 채널, 범용 지원. 약점은 사진이다. 센서 노이즈가 예측기를 무력화해서, 12 MP 사진은 원시 픽셀 대비 고작 1.5:1 정도로만 압축된다. 스크린샷, UI 캡처, 다이어그램, 텍스트나 단색이 들어간 모든 것에 적합하다.

GIF (1987). 동작 방식: 최대 256색 팔레트 위에서 LZW 압축, 여러 프레임을 하나의 파일에 담는다. 남아 있는 유일한 강점은 어디서든 재생되는 애니메이션이다. 최신 포맷을 지원하지 않는 이메일 클라이언트에서도 재생된다. 약점은 나머지 전부다. 256색, 1비트 투명도, 같은 내용의 동영상보다 훨씬 큰 파일 크기. 밈과 작은 UI 루프에 적합하다.

SVG (2001). 동작 방식: 래스터 의미에서는 없다. SVG는 도형과 패스, 그라데이션을 기술한 XML이고, 렌더러가 화면이 필요로 하는 해상도로 픽셀을 그린다. 강점: 해상도 독립적, 기하학적인 그래픽에 극도로 작은 크기, CSS로 스타일링 가능. 약점: 진짜 벡터인 콘텐츠에만 통한다는 것, 그리고 노드 수천 개에 무거운 필터를 잔뜩 얹은 극단적인 파일은 비트맵보다 더 비쌀 수 있다는 것. 로고, 아이콘, 차트, 다이어그램에 적합하다.

WebP (2010). 동작 방식: 손실 모드는 VP8 비디오 코덱의 인트라 프레임 예측을 빌려 오고, 무손실 모드는 공간 예측에 LZ77식 후방 참조를 얹는다. 강점: 하나의 포맷에 두 모드, 손실 모드에서도 알파 지원, 애니메이션, 그리고 구글의 자체 연구 기준으로 체감 품질을 맞췄을 때 JPEG보다 25~34% 작은 파일. 약점: 최대 16383 × 16383 픽셀이라는 크기 제한과, libjpeg보다 CPU를 더 쓰는 인코더. 거의 모든 것에 적합하다. 그래서 웹에서 JPEG, PNG, GIF의 기본 업그레이드 경로가 됐다.

AVIF (2019). 동작 방식: AV1 비디오 코덱의 스틸 프레임을 HEIF 컨테이너에 담은 것. 강점: 브라우저에 실을 수 있는 최고의 손실 압축. Netflix의 2020년 테스트 기준으로 체감 품질을 맞췄을 때 JPEG보다 대략 50% 작고, 여기에 10비트와 12비트 컬러, HDR, 알파, 애니메이션까지. 약점: 인코딩이 진짜로 느리고, 프로그레시브 렌더링이 없어서(이미지가 한꺼번에 뜨거나 아예 안 뜨거나), 품질을 너무 낮추면 JPEG의 정직한 블로킹과는 다른 방식으로 질감이 뭉개진다. 사진과 히어로 이미지처럼 파일 크기가 가장 중요한 곳에 적합하다.

HEIC (2015). 동작 방식: HEVC 스틸 프레임, 역시 HEIF 컨테이너. 강점: AV1급 압축률과, 2017년 이후 모든 iPhone의 기본 촬영 포맷이라는 지위. 약점은 기술이 아니라 법률이다. HEVC는 특허 풀에 둘러싸여 있고, Apple을 제외한 모든 브라우저 벤더가 그 비용을 거절했다. 카메라 롤에 있어야 할 포맷이지, 웹에 있을 포맷이 아니다.

JPEG XL (2021). 동작 방식: 한 지붕 아래 두 개의 엔진. 손실 작업용 VarDCT와 무손실용 모듈러 모드, 거기에 다른 포맷에는 없는 기능이 하나 더 있다. 기존 JPEG을 무손실로 원본의 약 80% 크기까지 재압축할 수 있다. 픽셀은 비트 단위까지 그대로 유지한 채로. 강점: 프로그레시브 디코딩, 뛰어난 무손실 압축률, 고충실도 사진. 약점은 채택률인데, 이는 주로 브라우저 정치에 관한 이야기로 아래에서 다룬다. 사진 파이프라인과 아카이브에 적합하고, Apple 기기에서는 웹에도 적합하다.

브라우저 지원, 2026년 중반

caniuse 데이터 기준으로 각 포맷이 기본값으로 켜진 버전:

이 표에는 눈여겨볼 세부 사항이 세 가지 있다. iOS의 AVIF는 기술적으로 Safari 16.0에 도착했지만 애니메이션이 빠져 있었고, macOS와 iOS 모두에서 완전한 지원이 들어온 것은 16.4다. Edge는 Chromium 기반이면서도 Chrome보다 몇 년 늦게 AVIF를 출시했는데, Microsoft가 Google보다 디코더를 더 오래 비활성화해 두었기 때문이다. 그리고 JPEG XL 행에는 특이한 사연이 숨어 있는데, 이는 아래에서 별도 섹션으로 다룬다.

caniuse의 2026년 수치 기준 글로벌 커버리지: WebP는 약 97%, AVIF는 약 93~94%. JPEG과 PNG은 사실상 100%이며, 이는 바뀔 것 같지 않다.

호환성 서열

도달 범위로 묶어 보면 포맷은 다섯 단계로 나뉜다.

1단계는 범용 세트: JPEG, PNG, GIF, SVG. 모든 브라우저, 모든 이메일 클라이언트, 모든 OS 미리 보기 창, 십 년 된 키오스크에서도 디코딩된다. 파일이 반드시 열려야 한다면 이 넷 중 하나로 간다.

2단계는 WebP 하나다. 마지막으로 버티던 주요 브라우저는 Safari였고, Safari 14가 2020년 9월에 그 격차를 닫았다. 남은 것은 Internet Explorer 설치본과 아주 오래된 Android WebView뿐이다. 이메일이 아니라 웹사이트 기준으로, WebP는 대략 5년째 안전한 기본값이다.

3단계는 AVIF다. Chrome이 2020년, Firefox가 2021년, Safari가 2022년(16.4에서 2023년 3월 완전 지원)에 받아들였고, Edge는 2024년 1월에 기본으로 켰다. 2024년 초 이후 모든 주요 엔진이 AVIF를 별도 설정 없이 디코딩한다. 남은 몇 퍼센트는 오래된 iPhone과 관리되지 않는 Windows 기기들인데, 폴백이 바로 그럴 때 쓰는 것이다.

4단계는 JPEG XL, 정체되어 있다. Apple은 2023년 9월 Safari 17부터 네이티브로 탑재했다. Google은 2022년 말 Chromium의 실험적 디코더를 제거해 2023년 2월 Chrome 110부터 적용했다가, 방향을 바꿔 Rust 기반 디코더(jxl-rs)를 머지했고, 그것이 2026년 2월 Chrome 145에 여전히 플래그 뒤에 숨은 채 실렸다. Firefox도 몇 년째 플래그 뒤에 디코더를 두고 있다. 그러니 2026년 중반의 JPEG XL 지원이란, 모든 Apple 사용자에 플래그를 직접 켜는 극소수의 Chrome·Firefox 사용자를 더한 것이다. 기반으로 삼기에는 너무 작은 집단이다.

5단계는 HEIC: Apple 플랫폼의 Safari 17, 그 외에는 어디에도 없다. 이는 단계라기보다 단일 벤더 생태계에 가깝다.

웹이 실제로 서빙하는 것

지원과 사용은 다르다. HTTP Archive의 Web Almanac은 수백만 개의 실제 페이지를 크롤링해 무엇이 서빙되는지 세는데, 전체 미디어 데이터가 있는 최신판인 2024년 판을 보면 변화는 빙하처럼 느리다. JPEG은 전체 이미지의 32%로 여전히 가장 흔한 단일 포맷이지만, 2022년의 40%에서 꼬박 8포인트 빠진 수치다. WebP는 그중 3포인트를 가져가 12%에 이르렀다. SVG는 약 2포인트를 얻었다. AVIF는 대략 1%에 도달했는데, 반올림 오차처럼 들리지만 상대적으로 읽으면 이야기가 다르다. 2년 만에 거의 4배 성장이다. ICO는 1.3%를 유지했는데, 거의 전부가 파비콘이다. 그리고 37년 된 GIF는 어쩐 일인지 1포인트를 얻었다.

왜 이렇게 느리게 움직일까? 세 가지 마찰이 가장 큰 원인이다. CDN 캐싱: 이미지는 URL을 키로 에지에 올라가 있고, 포맷을 바꾼다는 것은 캐시를 무효화하고 라이브러리 전체를 재인코딩한다는 뜻이다. 오래된 기기: 지원 차트는 97%라고 말하지만, 빠진 3%는 저가 Android 폰과 기업 기기군에 몰려 있고, 깨진 이미지 때문에 판매 한 건이라도 잃을 수 없는 사이트가 있다. 툴 관성: CMS는 늘 그래 왔으니 JPEG 썸네일을 생성하고, 디자인 툴은 가장 큰 버튼이 그것이라서 PNG로 내보내고, 기본값을 바꾼다는 것은 담당자 없는 빌드 파이프라인에 손을 댄다는 뜻이다.

인코드 비용도 있다. AVIF의 압축 우위는 인코드 시점의 CPU로 치르는 대가다. 그래서 이미지 CDN이 여기에 요금을 부과하고, 경험 있는 팀들은 실시간이 아니라 빌드나 업로드 시점에 AVIF를 미리 생성한다.

어디로 가고 있는가

향후 몇 년간 가장 안전한 선택지는 AVIF다. 설계 단계부터 로열티 프리이고(Alliance for Open Media는 HEVC식 특허 풀에서 벗어나겠다는 명시적 목표로 2015년 Amazon, Cisco, Google, Intel, Microsoft, Mozilla, Netflix가 설립했다), 하나의 스펙에서 손실과 무손실을 모두 다루고, HDR을 담고, 폴백 체인 비용이 거의 0이 되는 지원 임계점을 넘었다. 실질적인 비용은 인코드 시간과 프로그레시브 디코드의 부재다. 전자는 미리 생성으로 해결되고, 후자는 감수할 만한 트레이드오프다.

JPEG XL은 지금의 결과보다 더 나은 대우를 받을 자격이 있었다. 기술적 자질로 볼 때 역대 표준화된 포맷 중 가장 완전하다. 프로그레시브 디코딩, 최고의 무손실 모드, 고비트 심도 사진, 그리고 기존 JPEG 전체를 무손실로 재압축하는 능력까지 갖췄다. Google은 생태계의 관심이 부족하다는 이유로 Chromium에서 걷어냈고, 복원 요청은 Chromium 트래커 역사상 가장 많은 별을 받은 이슈 중 하나가 됐다. 3년 뒤 Google은 결정을 뒤집었지만, 그때는 이미 채택의 시기가 대부분 지나간 뒤였다. JPEG XL이 망명 생활을 하는 동안 AVIF가 CDN 통합과 CMS 플러그인, 기본 체크박스를 차지했다. JPEG XL은 아카이브 작업자들이 애용하는 포맷으로, 그리고 Apple 기기의 일등 시민으로 계속 살아남을 것이다. 주류 채택에 필요한 기술적 근거는 충분히 갖추고도 결국 그 자리에 이르지 못했다.

HEIC는 웹 포맷이 되지 않을 것이다. 이유는 품질과 무관하다. HEVC 디코딩에는 특허 라이선스가 필요하고, 무료 브라우저 벤더들은 10년째 그 비용을 거절해 왔다. 웹은 로열티 프리 기술 위에서 돌아간다. 주요 엔진 넷 중 셋이 디코딩하지 않는 포맷은 웹 포맷이 아니다. 경계에서 해결해야 할 내보내기 문제일 뿐이다.

한편 전환 기법은 이미 잘 정착되어 있고, 두 가지 형태가 있다. 서버 측 콘텐츠 협상: 브라우저가 디코딩 가능한 목록을 Accept 헤더로 보내고, 서버나 CDN이 같은 URL에 대해 최적의 변형을 골라 준다. 클라이언트 측: <picture> 요소. 후보를 나열해 두면 브라우저가 이해하는 첫 번째 것을 가져간다:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Team photo" width="1600" height="900" />
</picture>

맨 아래의 <img>가 범용 폴백이라서 어디서도 깨지지 않는다. 이게 93%에게는 AVIF를, 나머지에게는 JPEG을 서빙하면서 사이트를 두 벌 유지하지 않는 방법이다.

결정 표

파비콘에 대해 한 가지 덧붙인다. 표의 행 하나에는 다 담기지 않는 내용이 있기 때문이다. 최신 브라우저는 PNG, 심지어 SVG 파비콘도 받아들이지만, ICO는 모든 크롤러와 RSS 리더, 아주 오래된 브라우저 탭이 이해하는 유일한 포맷이고, ICO 파일 하나에는 여러 크기를 한 컨테이너에 담을 수 있다. 로고가 지금 다른 포맷으로 되어 있다면, JPG to ICO, WebP to ICO, PNG to ICO로 브라우저 안에서 바로 제대로 된 멀티 사이즈 ICO를 만들 수 있다.

포맷 간 변환

변환 작업의 상당수는 위 섹션들의 내용에서 자연스럽게 나온다. 압도적으로 가장 흔한 것은 iPhone에서 HEIC를 꺼내 나머지 세상이 열 수 있는 것으로 바꾸는 일이다. 공유가 목적이라면 HEIC to JPG가 맞는 수순이다. HEIC는 이미 손실 포맷이고, JPEG은 손상이 겹쳐 쌓이는 것을 막아 준다. HEIC to PNG는 편집을 위해 현재 상태를 그대로 얼려 두고, 목적지가 웹사이트라면 HEIC to WebP가 적합하다.

다음으로 JPEG, PNG, WebP 삼각형이 있다. JPEG을 디자인 워크플로우로 옮길 때: JPG to PNG. 품질이 좋아져서가 아니고(그럴 수 없다) 더 이상 잃지 않기 위해서다. 웹용으로 줄일 때: JPG to WebP. 오래된 소프트웨어를 위해 반대로 갈 때: WebP to JPG와 WebP to PNG. 사진 갤러리로 향하는 PNG 스크린샷: PNG to JPG, 또는 파일은 줄이면서 투명도는 지키고 싶다면 PNG to WebP. 비압축 BMP 스캔을 물려받았다면 BMP to JPG, BMP to PNG, BMP to WebP 전부 수백만 바이트짜리 유물을 이메일로 돌리는 것보다 낫다. 문서도 같은 갈림길에 선다. 사진 위주 페이지는 PDF to JPG, 텍스트가 선명해야 한다면 PDF to PNG, 페이지가 웹으로 향한다면 PDF to WebP.

이 도구들은 전부 변환을 브라우저 안에서 로컬로 처리하므로, 파일이 기기를 떠나지 않는다.

포맷은 계속 바뀐다. 법칙은 바뀌지 않는다. 코덱을 콘텐츠에 맞추고, 콘텐츠의 역할이 바뀔 때 변환하라.