모바일 페이지 한 장을 여는 데 이미지가 평균 1.3MB 이상을 차지합니다. 처음 제 블로그의 PageSpeed Insights 점수가 40점대로 찍혔을 때, 지적 항목 1순위가 항상 "차세대 형식으로 이미지 제공"이었습니다. 그때는 그게 뭘 뜻하는지도 몰랐는데, 지금 돌아보면 그 한 줄이 이 모든 삽질의 시작이었습니다.
WebP와 AVIF, 무엇이 다른가
두 포맷을 두고 "AVIF가 무조건 낫다"고 보는 시각도 있는데, 실제로 써보니 상황에 따라 전혀 다른 판단이 필요했습니다.
WebP는 구글이 2010년에 공개한 이미지 포맷으로, JPEG·PNG 대비 동일 화질에서 파일 크기를 30~40% 줄일 수 있습니다. 여기서 손실 압축(Lossy Compression)이란 이미지 데이터 일부를 버려 용량을 줄이되, 사람 눈으로는 거의 구분이 안 되는 수준을 유지하는 방식을 말합니다. 브라우저 호환성이 넓고 인코딩 속도가 빠른 것이 가장 큰 장점입니다.
AVIF는 AV1 코덱 기반의 포맷으로, 동일 품질 기준 파일 크기를 최대 50%까지 줄일 수 있습니다. 여기서 AV1 코덱이란 Alliance for Open Media가 개발한 오픈소스 영상·이미지 압축 표준으로, 넷플릭스·구글·애플 등이 공동 개발에 참여했습니다. HDR(High Dynamic Range), 즉 어두운 부분과 밝은 부분을 동시에 정교하게 표현하는 기능도 지원하며, WCG(Wide Color Gamut)라는 더 넓은 색 영역 재현 기능도 갖추고 있습니다.
문제는 압축 효율이 높은 만큼 인코딩 과정에서 CPU를 상당히 소모한다는 점입니다. 제가 직접 배치 처리를 돌려봤는데, AVIF 인코딩이 WebP보다 5~10배 느렸습니다. 저가형 Android 기기에서는 AVIF 디코딩 시 JPEG 대비 CPU 사용량이 5~10% 급증한다는 점도 간과하기 어렵습니다.
포맷 자동화, 직접 구축해본 경험
처음 전환점은 Squoosh라는 구글 오픈소스 툴이었습니다. 브라우저에서 바로 WebP 변환이 가능했고, 4MB짜리 스마트폰 사진이 400KB 이하로 줄어드는 걸 눈으로 확인하고 나서야 "아, 이게 진짜구나" 싶었습니다. 솔직히 이건 예상 밖이었습니다. 같은 사진인데 용량이 10분의 1이 되다니, 그전까지 얼마나 무지했는지 실감했습니다.
이후 Sharp.js를 이용한 Node.js 스크립트로 폴더 내 이미지를 일괄 변환하는 파이프라인을 만들었습니다. 여기서 Sharp.js란 Node.js 환경에서 이미지 리사이징, 포맷 변환, 압축을 처리하는 고성능 라이브러리로, libvips 엔진 기반이라 처리 속도가 빠릅니다. CI/CD에 연결해 이미지 커밋 시 자동으로 WebP 버전을 생성하도록 구성했고, 그 결과 Lighthouse 점수가 70점대 초반으로 올라갔습니다.
한 단계 더 나아가 Claude API에 이미지를 넘기고 "이 이미지에 적합한 포맷과 품질 설정은 무엇인가"를 판단하게 하는 방식도 구성해봤습니다. 사진처럼 디테일이 많은 이미지는 WebP 손실 압축 품질 80%, 로고나 아이콘처럼 단색이 많은 이미지는 AVIF 또는 SVG 변환을 권장하는 방식이었습니다. 수작업으로 판단하던 걸 자동화하니 시간이 대폭 줄었고, 팀원들이 포맷을 신경 쓰지 않아도 파이프라인이 알아서 처리해줬습니다.
다만 AVIF 대용량 배치 처리 시 멀티스레드 큐를 별도로 구성해야 했습니다. 이 부분이 생각보다 꽤 까다로웠고, 인프라 설정에 익숙하지 않은 분들에게는 진입 장벽이 될 수 있습니다.
워드프레스 환경이라면 Converter for Media 플러그인이 현실적인 대안입니다. 50만 개 이상의 사이트에 적용된 검증된 플러그인으로, 기존 이미지를 WebP와 AVIF로 자동 변환해줍니다. Cloudflare, Fastly, Akamai 같은 주요 CDN도 별도 설정 없이 AVIF·WebP를 캐시하기 때문에, CDN을 이미 쓰고 있다면 플러그인 설치만으로 상당 부분이 해결됩니다.
포맷별 선택 기준을 정리하면 다음과 같습니다.
- 브라우저 호환성이 최우선이고, 인코딩 속도를 중시한다면 WebP
- 압축 효율이 최우선이고, HDR·WCG 색 표현이 필요하다면 AVIF
- 로고, 아이콘, 단색 도형 이미지라면 SVG 또는 AVIF 무손실
- 저사양 Android 기기 이용자 비중이 높은 서비스라면 WebP 우선 권장
HTML picture 태그로 브라우저 호환성 확보하기
포맷을 바꿨는데도 구형 브라우저에서 이미지가 깨진다는 경험을 해보셨다면, picture 태그를 안 쓴 게 원인이었을 가능성이 높습니다. 제 경험상 이건 간과하기 쉬운 부분인데, picture 태그 하나로 해결됩니다.
picture 태그는 브라우저가 지원하는 포맷을 위에서부터 순서대로 탐색해 최적 포맷을 자동 선택하게 하는 HTML 요소입니다. AVIF를 먼저 선언하고, 그다음 WebP, 마지막으로 JPEG를 fallback으로 두면 브라우저 호환성과 압축 효율을 동시에 챙길 수 있습니다. 여기서 fallback이란 최신 포맷을 지원하지 않는 브라우저에서 대신 불러올 보험용 이미지를 의미합니다.
이 방식은 CDN 사용 여부와 무관하게 적용할 수 있으며, 추가 플러그인 없이 HTML 수정만으로 즉시 효과를 볼 수 있습니다. 실제로 제가 picture 태그를 적용하고 나서 특정 구형 Android 브라우저에서 발생하던 이미지 깨짐 현상이 사라졌습니다.
2024년 말 기준으로 모바일 페이지의 중간값 용량은 약 2.2MB이며, 그 중 이미지가 1.3MB 이상을 차지합니다(출처: HTTP Archive). 이 수치만 봐도 이미지 포맷 최적화가 웹 성능에서 차지하는 비중을 실감할 수 있습니다.
구글 web.dev에서도 차세대 이미지 포맷 적용을 Core Web Vitals 개선 방법 중 하나로 명시하고 있습니다(출처: web.dev). 여기서 Core Web Vitals란 구글이 사용자 경험을 측정하기 위해 제시한 핵심 지표로, LCP(최대 콘텐츠 로딩 시간)·INP(다음 페인트까지의 상호작용)·CLS(누적 레이아웃 이동) 세 가지로 구성되며 검색 순위에도 반영됩니다.
포맷 전환으로 모든 게 해결된다는 착각
"AVIF로 바꾸기만 하면 된다"고 생각하는 분들도 있는데, 저는 그 생각이 위험하다고 봅니다. 포맷 최적화는 성능 개선의 한 축일 뿐, 전부가 아닙니다.
제가 가장 뼈저리게 느낀 건 이겁니다. 4MB짜리 JPEG를 AVIF로 바꾸면 1MB가 될 수 있습니다. 하지만 300px짜리 카드 이미지 슬롯에 4,000px 이미지를 서빙하는 구조적 문제는 포맷을 바꿔도 해결되지 않습니다. 이미지 크기(dimension) 최적화, 즉 실제 표시 크기에 맞는 해상도로 리사이징하는 작업이 포맷 변환보다 선행되어야 합니다.
또한 AI가 "최적 포맷을 추천"하는 자동화를 구성했더라도, 그 판단 근거를 검증하지 않으면 맹목적 자동화가 됩니다. 제가 직접 써봤는데, AI가 추천한 설정이 특정 이미지 유형에서 기대보다 압축률이 낮게 나온 경우가 있었습니다. 자동화를 믿되, 정기적으로 결과를 샘플링해서 확인하는 습관이 필요합니다.
성능 최적화는 결국 측정 → 가설 → 적용 → 재측정의 루프입니다. PageSpeed Insights나 Lighthouse 점수를 주기적으로 확인하면서, 어떤 변경이 실제로 수치를 움직였는지 따져보는 것이 장기적으로 더 효과적입니다.
포맷 전환은 분명 효과적인 첫 단계입니다. 하지만 그것만으로 충분하다고 안심하는 순간, 다른 병목이 조용히 쌓이고 있을 가능성이 높습니다. WebP로 시작해서 측정하고, 필요하면 AVIF로 넘어가고, 그 과정에서 이미지 크기와 로딩 전략까지 함께 손보는 것이 제가 경험으로 얻은 결론입니다.
참고:
- HTTP Archive, "Web Almanac 2024" — https://httparchive.org/
- oneimage.co, "2025 이미지 형식 가이드: AVIF, WebP, JPEG 또는 JPEG XL을 선택해야 할 때" — https://oneimage.co/ko/blogs/image-format-guide-2025/
- itcreator.co.kr, "WebP vs AVIF 이미지 포맷 비교" — https://www.itcreator.co.kr/2024/07/comparison-webp-avif.html
- web.dev, "이미지 로딩성능 최적화" — https://velog.io/@min5x5/이미지영상-로딩성능-최적화