2026년 이미지 포맷 선택 가이드: AVIF, WebP 또는 JPEG

• AVIF는 사진 파일 크기를 JPEG 대비 30~50% 줄이지만 인코딩 속도가 느립니다.

• WebP는 브라우저 지원율이 97%+인 안전한 중간 지점입니다.

• JPEG는 누구나 깨진 이미지를 보지 않도록 최종 폴백(fallback)으로 사용됩니다.

• <picture> 요소는 위에서 아래로 각 포맷을 자동으로 시도합니다.

지난달에 저는 1.4MB의 JPEG가 적용된 히어로 사진이 있는 제품 페이지를 출시했습니다. 이를 AVIF로 재인코딩하자 눈에 띄는 손실 없이 320KB까지 줄었습니다. 이것이 이 선택이 중요한 이유이며, 2026년에는 단지 하나만 고를 필요가 없습니다.

제가 어떤 포맷을 제공할지 결정하는 방법과 모든 브라우저의 방문자가 사진을 볼 수 있도록 세 가지를 어떻게 쌓아 올리는지 알려드리겠습니다.

각 포맷이 실제로 좋은 점

JPEG는 30년 된 기술이며 여전히 어디서나 작동합니다. 모든 브라우저, 모든 이메일 클라이언트, 심지어 오래된 Android 휴대폰에서도 그렇습니다. 사진을 잘 처리합니다. 날카로운 모서리, 텍스트, 평평한 색상에서는 무너지는 경향이 있어 선 주위에 회색 얼룩이 생깁니다. 투명도를 지원하지 못합니다. 지원 여부가 바이트보다 더 중요한 사진의 경우, 여전히 괜찮습니다.

WebP는 제가 기본적으로 선택하는 포맷입니다. 손실 압축(lossy)과 무손실 압축(lossless)을 모두 처리할 수 있고, 투명도를 지원하며, 애니메이션도 가능합니다. 일반적인 제품 사진의 경우, 동일한 시각적 품질에서 JPEG보다 25~35% 더 작습니다. 인코딩 속도가 빠릅니다. 지원율은 이제 거의 보편적입니다.

AVIF는 강력한 포맷입니다. AV1 비디오 코덱을 기반으로 하며, 제가 테스트해 본 어떤 것보다도 파일 크기를 크게 줄여줍니다. 1.4MB의 JPEG가 320KB가 된 것은 우연이 아니며, JPEG 대비 3050% 감소는 일반적인 결과입니다. 투명도, 넓은 색 영역(wide color gamut), HDR을 처리할 수 있습니다. 단점은 인코딩 시간입니다. AVIF는 압축 속도가 느려서, 동일한 이미지에 대해 WebP보다 때로는 1020배 더 느립니다.

그래서 제가 사용하는 대략적인 규칙은 다음과 같습니다:

• 바이트 하나하나가 중요한 사진: AVIF를 먼저 사용합니다.
• 텍스트가 있는 UI 에셋, 아이콘, 스크린샷: WebP를 사용합니다. 인코딩이 빠르고 날카로운 모서리에서 품질을 유지하기 때문입니다.
• 예측할 수 없는 하드웨어에 표시되어야 하는 모든 것: JPEG를 준비해 둡니다.

사람들이 잊는 한 가지는 품질 설정이 포맷별로 비교할 수 없다는 것입니다. AVIF 품질 50은 WebP 품질 50과 같지 않습니다. 저는 숫자를 단순히 복사하는 것이 아니라, 눈으로 보거나 목표 파일 크기를 기준으로 각 포맷을 조정합니다. 일반적으로 1600px 너비의 히어로 이미지를 사용할 경우, AVIF 품질 55, WebP 품질 78, JPEG 품질 82 정도에서 결정됩니다. 이 수치들은 이미지마다 달라지지만, 저에게는 시작점입니다.

2026년 브라우저 지원 현황과 이것이 장애물이 아닌 이유

예전에는 '브라우저 지원' 문제가 이런 논쟁을 끝내는 기준이었습니다. 하지만 더 이상 그렇지 않습니다.

WebP는 현재 모든 브라우저에서 지원되며 수년 동안 그래왔습니다. 만약 WebP를 제공하고 JPEG로 폴백(fallback)하는 방식만 사용한다면, 2020년경부터 브라우저 업데이트를 거친 모든 사용자들을 커버할 수 있습니다. 예외 사항이 없습니다.

AVIF는 더 새로운 포맷이며, 이 때문에 사람들이 여전히 망설입니다. 하지만 Chrome, Firefox, Edge, Safari, 그리고 이들 브라우저의 모바일 버전 모두 이제 AVIF를 디코딩합니다. 지원하지 않는 경우는 오래된 설치본이나 일부 임베디드 웹뷰(embedded webviews)에 국한됩니다. 이는 아주 작은 부분이며 매달 줄어들고 있습니다.

이 모든 것이 저에게 문제가 되지 않는 이유는 폴백 체인(fallback chain) 덕분입니다. 저는 AVIF 지원 여부에 베팅할 필요가 없습니다. AVIF를 지원하는 브라우저에는 AVIF를 제공하고, 나머지 사용자들에게는 WebP, 그리고 JPEG로 조용히 다운그레이드됩니다. 브라우저는 자신이 이해하는 첫 번째 포맷을 선택합니다. JavaScript의 기능 감지(feature detection)도, user-agent 스니핑도, 깨진 이미지 아이콘도 없습니다.

이 부분이 주목할 만한 지점입니다. 폴백 메커니즘이 HTML 자체에 내장되어 있기 때문에, 단점 없이 가장 새롭고 작은 포맷을 채택할 수 있습니다. 오래된 브라우저의 최악의 시나리오는 어차피 받았을 JPEG를 받는 것입니다. 반면, 최신 브라우저의 최상의 시나리오는 크기가 4분의 1도 안 되는 파일을 받는 것입니다.

저는 성능 작업에 임하는 방식과 신뢰성(reliability) 작업에 임하는 방식을 동일하게 취합니다. 무언가가 실패할 것이라고 가정하고, 그 실패를 지루한 것으로 만드는 것입니다. 만약 재시도(retries)에 이 사고방식이 적용된 것을 보고 싶다면, Retry With Backoff and Jitter를 참고하세요. 이 글은 제가 모든 프로젝트에 적용하는 패턴을 설명합니다.

AVIF를 추가하는 유일한 실제 비용은 빌드 시의 인코딩 단계이며, 이는 사용자 문제가 아니라 기계(시스템) 문제입니다. 이로 인해 제가 실제로 고려하는 트레이드오프가 발생합니다.

인코딩 비용 대 파일 크기

작은 파일이 공짜는 아닙니다. 누군가의 CPU가 그 비용을 지불했습니다.

AVIF의 압축은 많은 작업을 선행하여 처리함으로써 이루어집니다. 제 빌드 머신에서 단일 2000px 사진을 좋은 품질 설정으로 AVIF 인코딩하는 데 몇 초가 걸립니다. WebP는 같은 이미지를 그보다 훨씬 짧은 시간에 처리합니다. JPEG는 거의 즉각적입니다. 이를 수백 장의 제품 사진 카탈로그에 곱하면, AVIF 단계가 갑자기 빌드 과정에서 가장 느린 부분이 됩니다.

저는 이를 캐시로 처리합니다. 원본 이미지와 인코딩 설정을 해싱하고, 아무것도 변경되지 않았다면 결과를 재사용합니다. 따라서 AVIF는 빌드당 한 번이 아니라 이미지당 한 번만 느린 인코딩 비용을 지불하면 됩니다. 첫 실행 후에는 수정되지 않은 항목은 리빌드를 건너뜁니다. 이는 제가 카탈로그 조회에 사용하는 캐싱 직관과 동일하며, Binary Search vs Array.includes()에서 벤치마킹했습니다.

느린 인코딩 비용을 상쇄할 만한 수치를 살펴보겠습니다: 각 1.4MB인 10개 이미지 갤러리는 JPEG로 총 14MB입니다. 같은 갤러리를 AVIF로 만들면 4MB 미만일 수 있습니다. 이는 모바일에서 즉시 로드되는 페이지와, 사용자가 이미 스크롤하고 지나가는데 이미지가 2초 정도 늦게 나타나는 페이지 사이의 차이입니다.

또한 모든 크기에 대해 모든 포맷으로 인코딩하지 않습니다. 두세 개의 너비(예: 640, 1280, 1920)를 선택하고, 각 너비에 대해 AVIF와 WebP를 생성한 다음, 너비별로 JPEG 폴백을 하나씩 추가합니다. 이는 관리 가능한 분기(fan-out)입니다. 제가 만드는 페이지의 종류로는 세 개보다 더 넓은 크기를 사용하는 것이 거의 이득이 없습니다.

만약 압축하기 전에 원본 아트를 생성하거나 업스케일링하는 경우, 인코딩 단계는 사용자가 내보내는 모든 것에 대해 실행됩니다. 저는 많은 원본 이미지를 먼저 Magnific를 통해 업스케일링한 다음, 그 결과를 포맷 스택으로 압축합니다. 깨끗한 소스를 넣으면 작은 파일이 나옵니다.

솔직히 한 가지 주의할 점이 있습니다: AVIF는 미세한 입자나 필름 노이즈가 있는 이미지의 경우 파일 크기가 매우 작을 때 WebP보다 더 나쁘게 보일 수 있습니다. 중요하지 않다고 생각하는 디테일을 부드럽게 처리합니다. 배경이 단순한 제품 사진에서는 눈에 띄지 않습니다. 질감이 있는 사진이라면, 바이트 수를 믿기 전에 직접 눈으로 확인해 보세요.

실제로 구현하는 폴백 체인 (Fallback Chain)

이것 전체가 하나의 HTML 요소 안에 들어갑니다. picture 요소는 소스(source)들을 순서대로 나열할 수 있게 해주며, 브라우저는 자신이 지원하는 첫 번째 것을 사용합니다.

<picture>
  <source srcset="hero.avif" type="image/avif">
...

브라우저는 위에서 아래로 읽습니다. 만약 AVIF를 지원하면, 첫 번째 줄을 가져가고 멈춥니다. AVIF 지원은 없지만 WebP가 작동한다면, 대신 두 번째 줄을 사용합니다. 아무것도 현대적이지 않다면? 일반 img 태그로 넘어갑니다. 이 태그는 모든 브라우저가 이해합니다. 이 img는 선택 사항이 아닙니다. 이미지가 깨져도 아무도 보지 못하게 보장하는 것입니다.

제가 절대 건너뛰지 않는 몇 가지 세부사항들.

항상 img에 width와 height를 설정하세요. 이렇게 하면 이미지가 로드되기 전에 공간을 확보하여 페이지가 갑자기 움직이는 것을 방지합니다. 레이아웃 이동(Layout shift)은 가장 쉽게 성능을 개선할 수 있는 방법 중 하나인데, 대부분의 사람들이 이를 놓칩니다.

항상 실제 alt 텍스트를 작성하세요. 폴백 체인은 포맷을 보호하고, alt는 이미지 자체가 실패했을 때 의미를 보호합니다.

반응형 크기의 경우, 각 source에는 너비 설명자(width descriptors)가 포함된 자체 srcset와 브라우저가 이미지가 얼마나 넓게 렌더링되는지 알 수 있도록 하는 sizes 속성이 필요합니다. 이것은 금방 길어지기 때문에, 저는 손으로 작성하기보다는 템플릿에서 전체 블록을 생성합니다. 이미지 이름과 치수를 입력하면, 세 가지 포맷과 모든 너비가 연결된 마크업이 나옵니다.

저는 해당 생성 로직을 나머지 에셋 파이프라인과 같은 위치에 유지하며, 어떤 이미지가 재인코딩되었고 어떤 이미지가 캐시에서 왔는지 확인할 수 있도록 구조화된 로그(structured logs)를 사용합니다. 만약 이 방식이 유용하게 들린다면, 제가 그렇게 설정한 방법은 Structured Logging I Add on Day One을 참고할 수 있습니다.

그 결과는 하나의 진실 공급원(source of truth)이 됩니다. 제가 JPEG나 PNG를 넣으면, 빌드 과정에서 AVIF와 WebP 변형 파일들을 생성하고 캐싱하며 picture 마크업을 작성합니다. 저는 폴백 체인(fallback chain)을 직접 건드릴 일이 없기 때문에 절대 실수할 일이 없습니다.

핵심 요약 (Bottom Line)

다른 것을 하지 않아도 된다면, JPEG를 기본값으로 하고 WebP를 제공하세요. 이는 사진 크기를 25~35% 줄여주면서도 신경 쓸 필요가 없는 지원을 제공하며, 파이프라인 작업으로는 한 시간 정도만 걸릴 수 있습니다.

더 큰 폭의 감소를 원하고 캐싱할 수 있는 빌드 단계(build step)가 있다면, AVIF를 체인의 최상단에 추가하세요. picture 요소는 위험이 없다는 의미입니다. 구형 브라우저는 원래 받았을 JPEG를 받고, 최신 브라우저는 크기가 1/3인 파일을 받게 됩니다. 질감이 있는 이미지는 눈으로 확인하고, 느린 인코딩(slow encode)은 한 번만 실행되도록 캐싱하세요.

가장 무거운 페이지에서 세 가지 포맷 스택을 시작하여 로드를 측정하고, 거기서부터 배포하는 것을 추천합니다. 패턴은 어디서든 동일하며, 이것이 핵심입니다. 제 파이프라인이 어떻게 구성되는지에 대한 전체적인 그림을 원하신다면, Claude Blueprint에서 이러한 빌드 시간 단계들을 반복 가능한 설정으로 연결하는 방법을 문서화했습니다.

포맷별로 선택하고, 폴백(fallback)은 유지하며, 브라우저가 직접 선택하게 두세요.

본 기사에는 제휴 링크(affiliate links)가 포함되어 있습니다. 이 링크를 통해 가입하시면 추가 비용 없이 제가 소액의 수수료를 받을 수 있습니다. (광고)