JPEG는 지난해로 30년을 맞았습니다. 그리고 그 긴 시간 동안, 이 포맷을 진지하게 흔든 존재는 사실 거의 없었습니다. WebP가 2010년에 도전했고 Google도 꽤 강하게 밀었지만, 사람들은 대체로 시큰둥했고 JPEG는 그대로 살아남았습니다. 투명도가 필요한 자리에서는 지금도 PNG가 흔하게 쓰이고 있고, GIF는 어째서인지 아직도 완전히 사라지지 않았습니다.
하지만 AVIF는 이야기가 조금 다릅니다. 브라우저 업체들이 마지못해 호환성 표에 하나 더 끼워 넣는 그런 포맷이 아닙니다. 포맷 전쟁은 이미 끝났고, 승자는 AVIF였습니다. 과장처럼 들릴 수 있지만, 숫자를 보면 그렇게 말할 수밖에 없습니다.
AVIF는 정확히 무엇인가
AVIF는 AV1 Image File Format의 약자입니다. 여기서 중요한 건 배경입니다. AV1은 원래 비디오용으로 만들어졌고, Google, Apple, Mozilla, Microsoft, Netflix, Amazon이 참여한 연합이 개발했습니다. 이 기업들은 H.264와 HEVC에 계속 로열티를 내는 일에 지쳐 있었고, 그래서 자원을 모아 로열티 프리 코덱을 처음부터 만들었습니다. 수년이 걸렸지만 결과물은 놀라울 만큼 훌륭했습니다.
그러다 누군가 아주 단순한 사실을 발견했습니다. AV1 비디오에서 한 프레임을 뽑아 정지 이미지로 저장하면 압축 효율이 엄청나게 높다는 것입니다. 1992년의 JPEG 알고리즘으로는 따라가기 어려운 수준입니다. 그게 바로 AVIF입니다. AV1을 사진에 적용한 결과라고 보면 이해가 쉽습니다.
숫자는 어떻게 말하고 있나
일반적인 사진 기준으로 AVIF는 비슷한 시각 품질에서 JPG보다 약 50% 더 높은 압축 효율을 냅니다. 10%도 아니고 15%도 아닙니다. 파일 크기가 거의 절반이 된다는 뜻입니다. 이미지를 많이 제공하는 웹사이트라면, 이 차이는 대역폭 비용과 로딩 속도에서 분명히 체감됩니다.
Google이 이전에 밀었던 현대적 이미지 포맷인 WebP도 JPEG보다 낫습니다. 다만 AVIF는 대부분의 콘텐츠에서 WebP보다도 약 30% 정도 더 효율적입니다. 이미 WebP를 쓰고 있고 그 정도면 충분하다고 생각한다면, 여전히 꽤 많은 성능을 놓치고 있는 셈입니다.
압축 성능만 좋은 것도 아닙니다. AVIF는 HDR, 넓은 색 영역, 알파 투명도를 지원합니다. 같은 파일 크기라면 텍스트와 날카로운 경계도 JPEG보다 더 잘 살려냅니다. 애니메이션 역시 지원하지만, 실제 현장에서는 움직이는 콘텐츠에 GIF나 WebP가 여전히 더 자주 쓰입니다.
왜 2026년이 진짜 전환점인가
AVIF는 2019년쯤부터 존재했습니다. Chrome은 비교적 일찍 지원했고 Firefox도 뒤따랐습니다. Safari는 더 늦었는데, 이게 중요한 이유는 iPhone의 Safari가 결코 틈새 브라우저가 아니기 때문입니다. Safari 16에서 지원이 추가됐고, 2024년 기준 Can I Use는 전 세계 브라우저 지원율을 93%로 집계했습니다. 2026년 초에는 그 수치가 95%를 넘었습니다.
이쯤 되면 웹 개발자는 AVIF를 주력 선택지로 현실적으로 사용할 수 있습니다. 아주 오래된 기기를 위해 JPEG 백업을 남겨두는 편이 여전히 좋지만, <picture> 요소를 쓰면 한 번 설정해둔 뒤 거의 잊고 운영할 수 있습니다.
Google PageSpeed Insights도 JPEG와 PNG 이미지를 최적화 기회로 표시하기 시작했고, 구체적으로 AVIF를 권장하고 있습니다. Core Web Vitals를 중요하게 본다면, 그리고 검색 순위에 영향을 주는 만큼 당연히 중요하게 봐야 하는데, Google은 이제 꽤 분명하게 이 방향을 밀고 있습니다.
아직은 맞지 않는 영역
가장 뚜렷한 빈틈은 이메일입니다. 대부분의 이메일 클라이언트는 AVIF를 제대로 렌더링하지 못하고, 당분간도 크게 달라질 것 같지 않습니다. 뉴스레터나 자동 메일용 이미지를 만든다면 JPEG나 PNG를 유지하는 편이 안전합니다.
인쇄 워크플로도 비슷합니다. 인쇄소와 사진 랩이 기대하는 건 TIFF, PDF, 또는 고품질 JPEG입니다. AVIF는 아직 그 세계의 표준이 아닙니다.
또 Lightroom이나 Capture One에서 라이브러리를 관리하는 사진가라면, 네이티브 AVIF 내보내기 지원은 아직 고르지 않습니다. 변환 도구를 거치면 가능하긴 하지만, JPEG나 TIFF만큼 자연스럽게 녹아 있지는 않습니다.
웹사이트 운영자에게는 무엇이 달라지나
Cloudflare나 Cloudinary 같은 CDN을 사용한다면, 이미 AVIF를 제공하고 있으면서도 모를 가능성이 있습니다. 이런 서비스들은 Accept 헤더를 보고 브라우저가 무엇을 지원하는지 파악한 뒤, 적절한 포맷을 자동으로 전달할 수 있습니다. 사용자는 JPEG를 업로드하고, 나머지는 서비스가 처리합니다.
Next.js를 쓴다면 Image 컴포넌트는 버전 13부터 기본적으로 AVIF를 제공합니다.
그 외 대부분의 사람들에게도 현실적인 경로는 분명합니다. 기존 이미지를 AVIF로 변환하고 JPEG fallback과 함께 제공하는 것입니다. FastConvert의 이미지 변환기를 사용하면 한 번에 처리할 수 있습니다. JPEG나 PNG를 올리고 AVIF를 받으면 끝입니다.
개발자가 아니라면 신경 써야 할까
아마 실무적으로는 크게 신경 쓰지 않아도 되는 경우가 많습니다. Squarespace, Wix, 또는 최신 테마의 WordPress로 사이트를 운영하고 있다면, 포맷 처리는 점점 더 뒤로 숨겨지고 있습니다. 호스팅이나 CDN이 알아서 해결해줍니다.
그래도 왜 어떤 사이트는 이미지가 눈에 띄게 빨리 뜨는데, 다른 사이트는 그렇지 않은지, 그런데도 육안으로는 품질 차이가 거의 안 느껴지는지 궁금했던 적이 있다면, 그 답의 큰 부분은 포맷 선택에 있습니다. 이미지 한 장당 800KB짜리 JPEG를 여전히 보내는 사이트와 350KB짜리 AVIF를 보내는 사이트의 차이는 특히 모바일에서 금방 누적됩니다.
JPEG는 길고 좋은 시대를 보냈습니다. 그 긴 수명을 누릴 만한 포맷이었습니다. 하지만 기본 포맷으로서의 시간은 끝나가고 있고, 그 자리를 AVIF가 가져가고 있습니다.
