WebP vs AVIF, 이미지 포맷 완벽 비교

결론부터 말하면 이렇다. AVIF가 압축률에서는 가장 앞서지만, 지금 당장 실무에서 가장 안전한 선택은 여전히 WebP다. AVIF는 같은 화질에서 파일 크기를 더 줄여 주지만 인코딩(압축 처리) 속도가 느리고 일부 구형 환경에서 폴백(대체 포맷) 준비 없이 쓰면 이미지가 아예 안 보이는 사고로 이어질 수 있다.

두 포맷 모두 오래된 JPEG·PNG보다 파일 크기를 크게 줄여 준다는 공통점은 같다. 문제는 "무조건 최신 포맷이 좋다"는 말만 믿고 아무 준비 없이 전환했다가, 특정 브라우저에서 이미지가 깨지거나 변환 작업 자체에 시간을 너무 많이 쓰는 경우다.

이미지 최적화는 홈페이지 속도를 좌우하는 요소 중에서도 비교적 손이 덜 가면서 성과는 확실한 영역이다. 텍스트 콘텐츠를 새로 쓰거나 서버를 통째로 옮기는 작업과 달리, 이미지 포맷 전환은 기존 화면 구성을 그대로 두고도 적용할 수 있어 진입 장벽이 낮다. 그럼에도 정작 "어떤 포맷을, 어떻게, 어디까지" 바꿔야 하는지 기준이 없어 미루는 경우가 많다.

이 글은 WebP와 AVIF가 무엇이 다른지부터, 실제 압축률·화질·호환성 데이터, 카페24·아임웹·워드프레스 같은 플랫폼별 적용법, 그리고 코어 웹 바이탈(웹사이트 속도를 측정하는 구글의 핵심 지표) 개선 효과까지 예시 중심으로 정리한다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• AVIF는 같은 화질 기준으로 JPEG보다 약 50% 작고, WebP는 약 25에서 35% 작은 경향을 보인다
• 전세계 브라우저 지원율은 WebP 약 96%, AVIF 약 95%로 둘 다 이제 실무에서 쓸 만한 수준이다
• 구형 환경 대비를 위해 AVIF → WebP → JPEG 순서로 대체(폴백)하는 구성이 가장 안전하다
• 카페24·아임웹·식스샵 같은 국내 플랫폼은 자동 변환·최적화를 상당 부분 대신 처리해 준다
• 이미지가 큰 페이지일수록 포맷 전환이 코어 웹 바이탈의 LCP(화면이 다 뜨는 속도) 개선에 직접 도움이 된다

WebP와 AVIF, 정확히 뭐가 다른가?

WebP는 구글이 2010년에 공개한 이미지 포맷이고, AVIF는 2019년에 등장한 더 최신 포맷이다. 둘 다 사진·일러스트 이미지를 JPEG·PNG보다 작은 용량으로 담기 위해 만들어졌지만, 내부에서 쓰는 압축 기술이 다르다.

WebP는 구글의 VP8 동영상 코덱(압축·복원 기술)을 이미지에 응용해 만들었다. 손실 압축(화질을 일부 포기하고 용량을 줄이는 방식)과 무손실 압축(화질 손상 없이 용량만 줄이는 방식)을 모두 지원하고, 투명 배경(알파 채널)과 애니메이션(움직이는 GIF 대체)도 처리할 수 있다.

AVIF는 넷플릭스·구글·아마존 등이 참여한 AOM(Alliance for Open Media)이 개발한 AV1 동영상 코덱을 기반으로 만든 이미지 포맷이다. AV1은 유튜브 같은 대형 동영상 서비스에서 쓰는 최신 압축 기술이라, 정지 이미지에 적용해도 같은 화질에서 파일 크기를 더 크게 줄이는 결과로 이어진다.

비유하자면 WebP는 "JPEG를 대체하기 위해 처음 나온 실용적인 대안"이고, AVIF는 "그보다 한 세대 더 진화한, 압축 효율을 극한까지 끌어올린 포맷"에 가깝다.

두 포맷을 등장 시기로 줄 세워 보면 왜 지원율에 차이가 나는지도 자연히 이해된다. JPEG는 1992년, PNG는 1996년, WebP는 2010년, AVIF는 2019년에 각각 공개됐다. 브라우저 제조사가 새 포맷을 코드에 심고, 다시 전 세계 사용자의 기기에 그 업데이트가 퍼지기까지는 보통 몇 년이 걸린다. AVIF가 WebP보다 아직 지원율이 살짝 낮은 이유도 이 시간차 때문이다.

무손실 압축(원본 화질을 그대로 유지하면서 용량만 줄이는 방식) 성능도 조금 다르다. 사진처럼 색이 복잡한 이미지에서는 WebP·AVIF 모두 손실 압축을 주로 쓰지만, 로고나 스크린샷처럼 텍스트·도형이 섞인 이미지는 무손실 압축이 더 어울린다. 이런 이미지에서는 PNG 대비 절감 폭이 손실 압축만큼 크지 않을 수 있다는 점도 참고할 만하다.

두 포맷의 기본 성격을 표로 정리하면 다음과 같다.

구분	WebP	AVIF
등장 시기	2010년(구글)	2019년(AOM)
기반 기술	VP8 동영상 코덱	AV1 동영상 코덱
압축률(JPEG 대비)	약 25에서 35% 절감	약 50% 절감
투명 배경	지원	지원
애니메이션	지원	지원(일부 브라우저 제한)
인코딩 속도	상대적으로 빠름	상대적으로 느림
브라우저 지원율	약 96%	약 95%

이 표에서 눈여겨볼 점은 압축률만 보면 AVIF가 우세하지만, 인코딩 속도는 WebP가 더 빠르다는 사실이다. 이미지 수가 아주 많은 쇼핑몰에서는 전체 상품 이미지를 AVIF로 변환하는 데 걸리는 시간과 서버 자원까지 함께 고려해야 한다.

압축률은 실제로 얼마나 차이 나나?

같은 원본 사진을 세 가지 포맷으로 저장해 비교하면, JPEG를 100으로 뒀을 때 WebP는 약 65에서 75, AVIF는 약 45에서 55 수준의 용량이 나오는 경향을 보인다. 이 수치는 사진의 내용(단색이 많은지, 세부 디테일이 많은지)과 압축 강도 설정에 따라 달라질 수 있다.

실무에서 체감하는 차이를 예시로 보면 이렇다.

• 나쁜 예: 쇼핑몰 상품 상세 페이지에 3MB짜리 원본 JPEG 이미지 15장을 그대로 올린다. 페이지 전체 용량이 45MB를 넘어가고, 모바일에서는 로딩만 몇 초씩 걸린다.
• 좋은 예: 같은 원본을 AVIF로 변환해 올린다. 화질 차이는 눈으로 거의 구분되지 않는 수준인데, 페이지 전체 용량은 20MB 안팎으로 줄어든다.

압축률 차이가 특히 크게 벌어지는 대상은 사진처럼 색상이 복잡하고 디테일이 많은 이미지다. 반대로 로고나 아이콘처럼 단색 면적이 넓은 이미지는 포맷을 바꿔도 차이가 크지 않을 수 있어, 이런 경우는 SVG(벡터 이미지 포맷) 같은 다른 방식을 함께 검토하는 것이 낫다.

압축률 수치는 인코더(압축 프로그램) 버전과 설정값에 따라 계속 달라진다. "AVIF가 항상 WebP보다 몇 퍼센트 작다"는 식의 고정된 수치보다, 실제 자기 이미지로 직접 비교해 보는 습관이 더 정확하다.

이미지 종류별로 절감 폭이 어떻게 달라지는지 대략적인 감을 잡아 두면 실무에서 유용하다.

이미지 종류	JPEG 원본 예시	WebP 변환 후	AVIF 변환 후
인물·풍경 사진	약 2.5MB	약 1.6에서 1.8MB	약 1.1에서 1.3MB
제품 촬영 사진(흰 배경)	약 1.2MB	약 0.7에서 0.9MB	약 0.5에서 0.6MB
스크린샷·UI 캡처	약 800KB	약 500에서 600KB	약 400에서 500KB
단순 배너·그래픽	약 400KB	약 250에서 300KB	약 200에서 250KB

절감 폭이 가장 크게 나타나는 대상은 디테일이 풍부한 사진이고, 이미 단순한 그래픽·배너는 상대적으로 절감 폭이 적다는 경향이 이 표에도 드러난다. 위 수치는 대략적인 참고값이며, 실제 결과는 원본 해상도와 압축 설정에 따라 달라질 수 있다.

브라우저 호환성, 지금 안전하게 쓸 수 있나?

둘 다 이제 실무에서 안전하게 쓸 수 있는 수준의 지원율에 도달했다. 다만 AVIF는 WebP보다 조금 더 늦게 대중화됐기 때문에, 구형 브라우저나 오래된 기기에서는 폴백(대체 포맷) 구성이 여전히 필요하다.

브라우저별 지원 현황을 정리하면 다음과 같다.

브라우저	WebP 지원	AVIF 지원
크롬(Chrome)	전 버전	85버전 이상
엣지(Edge)	전 버전	121버전 이상
파이어폭스(Firefox)	전 버전	93버전 이상(정지 이미지 기준)
사파리(Safari)	14버전 이상	16.4버전 이상

사파리가 두 포맷 모두에서 가장 늦게 지원을 시작한 브라우저라는 점이 특징이다. 아이폰·맥 사용자 비중이 높은 사이트라면, 방문자의 실제 브라우저 버전을 서치 콘솔이나 GA4에서 확인해 보는 것이 안전하다.

AVIF를 아직 지원하지 않는 구형 환경에서는 브라우저가 이미지 자체를 표시하지 못한다. 반드시 WebP나 JPEG로 대체(폴백)되도록 구성해야, 일부 방문자에게 "깨진 이미지"가 보이는 사고를 막을 수 있다.

이런 대체 구성은 HTML의 <picture> 태그로 간단히 처리할 수 있다.

<picture>
  <source srcset="/images/product.avif" type="image/avif" />
  <source srcset="/images/product.webp" type="image/webp" />
  <img src="/images/product.jpg" alt="상품 이미지 설명" />
</picture>

이 코드는 브라우저가 AVIF를 지원하면 AVIF를, 안 되면 WebP를, 그것도 안 되면 마지막으로 JPEG를 보여 주는 방식이다. 대부분의 최신 CDN(콘텐츠 전송 네트워크)과 이미지 최적화 도구가 이 구조를 자동으로 만들어 준다.

화질은 어느 쪽이 더 좋은가?

같은 파일 크기로 맞춰 비교하면 AVIF가 화질에서도 앞서는 경향이 있다. 특히 얼굴 피부처럼 미세한 그러데이션이 있는 사진이나, 그림자가 있는 제품 사진에서 AVIF가 블록 노이즈(뭉개짐 현상)를 덜 만든다는 평가가 많다.

다만 화질 차이는 압축 강도를 어느 수준으로 맞추느냐에 따라 크게 달라진다. 같은 AVIF라도 압축을 너무 세게 걸면 WebP보다 화질이 더 나쁠 수도 있다. "포맷 자체가 화질을 보장한다"기보다는, "같은 파일 크기 조건에서 AVIF가 화질을 더 잘 지킨다"고 이해하는 편이 정확하다.

기능별 지원 여부를 표로 정리하면 다음과 같다.

기능	WebP	AVIF
투명 배경(알파 채널)	지원	지원
애니메이션	지원(GIF 대체 가능)	지원하지만 브라우저별 편차 존재
HDR(하이 다이내믹 레인지)	미지원	지원
넓은 색 영역(광색역)	미지원	지원
점진적 렌더링	지원	미지원

AVIF의 점진적 렌더링 미지원은 실무에서 은근히 중요한 차이다. 점진적 렌더링은 이미지가 위에서 아래로 흐릿하게 먼저 보이고 점점 선명해지는 방식인데, AVIF는 이 기능이 없어 이미지가 완전히 다운로드될 때까지 아예 표시되지 않을 수 있다. 느린 회선 환경에서는 이 차이가 체감 속도에 영향을 줄 수 있다.

나쁜 예 · 좋은 예로 화질 관리를 비교하면 다음과 같다.

• 나쁜 예: 모든 이미지를 압축률 최우선 설정 하나로 일괄 변환한다. 대표 이미지까지 뭉개진 화질로 게시되어, 오히려 브랜드 신뢰도를 떨어뜨린다.
• 좋은 예: 대표 이미지·상세 사진처럼 화질이 중요한 이미지는 압축 강도를 낮게, 썸네일·목록용 작은 이미지는 압축 강도를 높게 설정해 이원화한다.

반응형 이미지와 함께 쓰면 왜 더 효과적인가?

포맷만 바꾸는 것보다, 화면 크기별로 다른 해상도를 함께 제공하면 절감 효과가 훨씬 커진다. 이 방식을 반응형 이미지라고 부른다. 모바일 화면에 데스크톱용 대형 이미지를 그대로 내려보내는 것은 그 자체로 낭비이기 때문이다.

HTML의 srcset 속성을 쓰면 화면 폭에 맞는 이미지를 브라우저가 알아서 골라 받는다. 포맷 대체(<picture>)와 해상도 대체(srcset)를 함께 쓰면 다음과 같은 구조가 된다.

<picture>
  <source
    type="image/avif"
    srcset="/images/banner-480.avif 480w, /images/banner-1200.avif 1200w" />
  <source
    type="image/webp"
    srcset="/images/banner-480.webp 480w, /images/banner-1200.webp 1200w" />
  <img src="/images/banner-1200.jpg" alt="배너 설명" />
</picture>

나쁜 예 · 좋은 예로 비교하면 다음과 같다.

• 나쁜 예: 데스크톱용으로 촬영한 2400픽셀 폭 원본 이미지 하나를 포맷만 AVIF로 바꿔서 모바일에도 그대로 내려보낸다. 화면에는 훨씬 작게 보이는데도 다운로드 용량은 그대로다.
• 좋은 예: 같은 이미지를 480픽셀·768픽셀·1200픽셀·2400픽셀 등 여러 해상도로 미리 준비해 두고, 방문자의 화면 크기에 맞는 파일만 전달되도록 구성한다.

직접 코드를 다루기 부담스럽다면, 앞서 소개한 워드프레스 플러그인이나 Next.js의 이미지 컴포넌트, 대부분의 국내 홈페이지 빌더가 이 반응형 처리를 자동으로 대신해 준다. 처음부터 모든 것을 손으로 구현할 필요는 없다.

언제 WebP를, 언제 AVIF를 써야 하나?

답은 상황에 따라 다르다. 압축률만 보면 AVIF가 유리하지만, 변환 속도·호환성·운영 편의성까지 함께 고려하면 WebP가 더 나은 선택인 경우도 많다.

• 상품 이미지가 수천 장 넘는 대형 쇼핑몰: AVIF 인코딩에 시간이 오래 걸릴 수 있어, 먼저 WebP로 전체를 전환하고 대표 이미지 위주로만 AVIF를 추가하는 방식이 현실적이다.
• 홈페이지·소개 페이지처럼 이미지 수가 적은 사이트: 이미지가 몇십 장 수준이라면 처음부터 AVIF로 변환해도 부담이 크지 않다.
• 로고·아이콘·일러스트처럼 색상이 단순한 이미지: 포맷 전환보다 SVG(벡터 이미지)를 쓰는 편이 용량과 화질 모두에서 유리한 경우가 많다.
• 움직이는 배너·GIF 대체 이미지: 브라우저별 재생 편차가 적은 WebP 애니메이션이 더 안전하다.

처음 도입한다면 "무조건 AVIF"보다 "AVIF를 우선 제공하되 WebP로 폴백하는 구조"를 기본값으로 삼는 편이 실무적으로 안전하다. <picture> 태그 하나로 두 포맷의 장점을 동시에 챙길 수 있다.

업종별로 어디에 우선순위를 둘지 정리하면 다음과 같다.

업종·사이트 유형	이미지 특성	우선 검토 사항
쇼핑몰(대형)	상품 이미지 수천 장	WebP 전면 전환 + 대표 이미지만 AVIF
쇼핑몰(소규모)	상품 이미지 수백 장 이내	AVIF 우선 적용, WebP 폴백
병원·미용실	시술 사례 갤러리 사진	화질 우선, 압축 강도는 보수적으로
기업 소개·B2B	이미지 수 적음, 텍스트 위주	대표 이미지 1에서 2장만 신경 써도 충분
포트폴리오·사진 중심 사이트	고해상도 사진 다수	AVIF + 반응형 이미지 조합이 효과적

카페24·아임웹·워드프레스, 플랫폼별로 어떻게 적용하나?

플랫폼마다 자동화 수준이 다르다. 어떤 곳은 업로드만 하면 알아서 최적화해 주고, 어떤 곳은 플러그인이나 별도 설정이 필요하다.

• 카페24: 이미지 호스팅 옵션에서 WebP 자동 변환을 지원한다. AVIF는 아직 플랫폼 차원의 자동 변환이 보편적이지 않아, 대표 이미지 위주로 원본을 직접 AVIF로 준비해 업로드하는 방식이 안전하다.
• 아임웹·식스샵: 이미지를 업로드하면 플랫폼이 자동으로 최적화 처리를 해 준다. 운영자는 고화질 원본(JPEG·PNG)을 그대로 올리는 것에 집중하면 되고, 포맷 변환은 플랫폼 쪽에서 대부분 처리한다.
• 워드프레스: 자체 호스팅 구조라 자동 변환 기능이 기본으로 켜져 있지 않다. Converter for Media, Smush 같은 플러그인을 설치하면 업로드 이미지를 WebP·AVIF로 자동 변환하고 <picture> 태그 구조까지 만들어 준다.
• Next.js 등 자체 개발 사이트: next/image 같은 이미지 컴포넌트를 쓰면, 요청하는 브라우저에 맞춰 AVIF·WebP 중 알맞은 포맷을 서버가 자동으로 골라 응답한다. 개발자가 직접 포맷을 하나하나 관리할 필요가 없다.

나쁜 예 · 좋은 예로 비교하면 다음과 같다.

• 나쁜 예: 워드프레스에서 아무 플러그인도 없이 3MB짜리 JPEG 원본을 그대로 올린다. 방문자마다 매번 무거운 원본을 그대로 내려받는다.
• 좋은 예: Converter for Media 같은 플러그인을 설치해 업로드 즉시 WebP·AVIF로 자동 변환되도록 설정하고, 기존에 올려 둔 이미지도 일괄 재변환한다.

플랫폼을 직접 고르는 단계라면, 홈페이지 제작 시점부터 이미지 최적화 구조를 함께 설계해 두는 것이 나중에 다시 손대는 수고를 줄여 준다.

워드프레스에서 플러그인을 설치한 뒤 실제로 확인해야 할 절차는 대략 다음과 같다.

1. 플러그인을 설치하고 활성화한 뒤, 자동 변환 대상 포맷(WebP만 할지, AVIF까지 포함할지)을 설정한다.
2. 새로 업로드하는 이미지가 자동으로 변환되는지 샘플 이미지 하나로 먼저 확인한다.
3. 기존에 이미 올려 둔 이미지도 일괄 변환(재생성) 기능으로 함께 처리한다.
4. 변환 후 사이트를 실제로 열어 이미지가 정상적으로 보이는지, 특히 구형 브라우저에서도 문제없는지 점검한다.

카페24·아임웹처럼 플랫폼이 자동 처리를 해 주는 경우에도, 관리자 화면의 이미지 관련 설정 메뉴에서 최적화 옵션이 실제로 켜져 있는지 한 번은 직접 확인해 보는 것이 안전하다. 기본값이 꺼져 있거나, 특정 상품 유형에서는 적용되지 않는 경우도 있기 때문이다.

이미지는 어떤 도구로 변환하나?

개발 지식이 없어도 웹 기반 변환 도구로 충분히 처리할 수 있다. 대량으로 처리해야 한다면 명령줄 도구나 자동화 스크립트가 더 효율적이다.

• 웹 기반 변환 도구: Squoosh(구글이 만든 무료 온라인 변환 도구)는 원본을 업로드하면 WebP·AVIF 변환 후 화질과 용량을 화면에서 바로 비교할 수 있어, 소량 이미지를 다룰 때 편리하다.
• 명령줄 도구: cwebp(WebP 변환), avifenc(AVIF 변환) 같은 도구는 폴더 단위로 대량 변환 작업을 자동화할 수 있다. 개발자가 있는 팀이라면 이 방식이 가장 빠르다.
• 플러그인·CDN 자동 변환: 앞서 소개한 워드프레스 플러그인이나, Cloudflare·Cloudinary 같은 CDN 서비스의 이미지 자동 최적화 기능을 쓰면 변환 작업 자체를 신경 쓸 필요가 없다.

변환할 때 실수하기 쉬운 부분을 예시로 정리하면 다음과 같다.

• 나쁜 예: 압축률을 최대로 높여 파일 크기만 줄이는 데 집중한다. 결과물을 눈으로 확인하지 않아, 실제로는 화질이 심하게 깨진 이미지가 그대로 게시된다.
• 좋은 예: 변환 후 원본과 나란히 놓고 화질을 눈으로 비교한다. 큰 차이가 없는 선에서 압축률을 조절하고, 대표 이미지처럼 중요한 사진은 압축 강도를 한 단계 낮춰 화질을 우선한다.

JPEG XL·HEIC 같은 다른 최신 포맷도 검토해야 하나?

지금 실무 도입 대상으로는 WebP와 AVIF 두 가지만 고려해도 충분하다. JPEG XL, HEIC 같은 포맷도 이름이 종종 언급되지만, 홈페이지 이미지에 바로 적용하기에는 아직 이르다.

JPEG XL은 압축 효율이 뛰어나다는 평가를 받는 차세대 포맷이지만, 주요 브라우저의 지원 여부가 아직 불안정하다. 한때 크롬이 지원을 시도했다가 제외한 이력도 있어, 표준으로 자리 잡을지는 좀 더 지켜봐야 하는 단계다.

HEIC는 아이폰이 사진을 찍을 때 기본으로 저장하는 포맷으로 잘 알려져 있지만, 이는 애플 생태계 안에서의 저장·촬영 용도에 가깝다. 웹 브라우저에서 HEIC를 직접 표시하는 기능은 지원이 제한적이라, 홈페이지에 그대로 올리기보다는 업로드 전에 JPEG나 PNG로 먼저 변환하는 것이 안전하다. 실제로 아이폰에서 촬영한 사진을 홈페이지에 올렸는데 이미지가 안 보인다는 문의는 대부분 이 HEIC 파일을 그대로 업로드했을 때 발생한다.

새로운 포맷 이름이 등장할 때마다 전부 따라갈 필요는 없다. 표준화가 끝나고 주요 브라우저 지원율이 90%를 넘어선 뒤에 검토해도 늦지 않는다. 지금은 WebP·AVIF 조합만으로도 충분한 성과를 볼 수 있다.

코어 웹 바이탈(LCP)에 실제로 얼마나 도움되나?

이미지가 많고 무거운 페이지일수록 개선 폭이 크다. 코어 웹 바이탈의 세 지표 중 LCP(화면에서 가장 큰 요소가 뜨는 속도)는 대표 이미지 용량의 영향을 직접적으로 받기 때문에, 포맷 전환 효과가 가장 뚜렷하게 나타나는 지표다.

예를 들어 대표 이미지 하나가 2MB짜리 JPEG였던 페이지를 생각해 보자. 같은 이미지를 AVIF로 바꾸면 파일 크기가 절반 이하로 줄어들면서, 그만큼 화면에 이미지가 뜨는 시점도 앞당겨진다. 모바일처럼 회선 속도가 느린 환경일수록 이 차이는 더 크게 체감된다.

• 나쁜 예: 홈페이지 상단 배너 이미지가 4MB짜리 원본 PNG 그대로 올라가 있어, 모바일에서 LCP가 4초를 넘는다.
• 좋은 예: 같은 배너를 AVIF로 변환하고 적정 해상도로 리사이징하니 LCP가 2.5초 이내 "좋음" 구간으로 들어온다.

이미지 포맷 전환은 페이지 속도 최적화 작업 중에서도 비교적 손이 덜 가면서 효과는 확실한 항목이다. CDN과 함께 적용하면 개선 폭이 한층 더 커진다.

포맷 전환과 CDN을 함께 적용했을 때의 개선 흐름을 예시로 정리하면 다음과 같다.

1. 1단계(포맷 전환 전): 대표 이미지 2.5MB짜리 원본 JPEG, 오리진 서버 직접 응답, LCP 약 4.2초.
2. 2단계(포맷만 전환): 같은 이미지를 AVIF로 변환, 파일 크기 약 1.2MB로 감소, LCP 약 3.1초.
3. 3단계(CDN까지 함께 적용): AVIF 이미지를 CDN 엣지 서버가 캐시 응답, LCP 약 2.2초로 "좋음" 구간 진입.

이처럼 포맷 전환 하나만으로도 개선은 되지만, CDN·리사이징 같은 다른 최적화와 겹쳐 적용할 때 효과가 누적된다는 점을 기억해 두면 우선순위를 정하기 쉽다.

다만 포맷을 바꾸는 것만으로 LCP 문제가 전부 해결되지는 않는다. 이미지 크기 자체가 화면에 필요한 크기보다 훨씬 크게 올라가 있다면, 포맷 전환과 별개로 적정 해상도로 리사이징하는 작업도 함께 해야 한다.

이미지 포맷 전환 시 자주 하는 실수는?

가장 흔한 사고는 폴백 없이 AVIF만 올려서 일부 방문자에게 이미지가 안 보이는 경우다. 이 밖에도 몇 가지 반복되는 실수 유형이 있다.

• 원본을 남기지 않고 변환 파일만 저장한다: 나중에 다른 포맷으로 다시 변환해야 할 때 원본이 없으면 처음부터 다시 촬영·제작해야 하는 상황이 생길 수 있다.
• alt 텍스트를 빼먹는다: 포맷을 바꾸는 과정에서 이미지 SEO의 기본인 alt 텍스트(대체 텍스트)를 새로 채우지 않고 넘어가는 경우가 많다. 파일 형식이 바뀌어도 이 작업은 그대로 유지해야 한다.
• 파일명은 그대로 두고 확장자만 바꾼다: 상품1.jpg를 상품1.avif로 바꾸는 데 그치지 말고, 검색에 도움이 되도록 파일명 자체도 의미 있는 단어로 정리하는 편이 좋다.
• 모든 이미지를 한꺼번에 최고 압축률로 바꾼다: 대표 이미지처럼 화질이 중요한 사진까지 과도하게 압축해, 결과물의 완성도가 떨어지는 경우가 있다. 이미지 성격에 따라 압축 강도를 다르게 적용하는 것이 안전하다.
• 변환 후 결과를 실제 기기에서 확인하지 않는다: PC 모니터에서는 괜찮아 보여도, 실제 방문자가 많이 쓰는 모바일 화면에서는 화질 저하나 레이아웃 깨짐이 다르게 보일 수 있다. 데스크톱과 모바일 양쪽에서 한 번씩 확인하는 습관이 필요하다.

전환 작업을 마친 뒤에는 반드시 PageSpeed Insights 같은 도구로 적용 전후 점수를 비교해, 실제로 개선됐는지 숫자로 확인하는 절차를 거쳐야 한다.

실제로 적용한다면 어떤 순서로 진행해야 하나?

한 번에 전체를 다 바꾸려 하지 말고, 효과가 큰 부분부터 단계적으로 적용하는 것이 안전하다. 대략적인 진행 순서는 다음과 같다.

1. 현재 상태 확인: PageSpeed Insights나 서치 콘솔로 현재 페이지 속도와 LCP 수치를 먼저 기록해 둔다. 개선 전후를 비교할 기준점이 있어야 효과를 눈으로 확인할 수 있다.
2. 대표 이미지부터 전환: 홈페이지 상단 배너, 상품 목록의 대표 이미지처럼 방문자가 가장 먼저 보는 이미지를 우선 AVIF·WebP로 바꾼다.
3. 플랫폼 자동화 기능 점검: 카페24·아임웹 같은 플랫폼이라면 관리자 화면에서 이미지 최적화 옵션이 켜져 있는지 확인하고, 워드프레스라면 변환 플러그인을 설치한다.
4. 폴백 구조 확인: <picture> 태그나 플러그인 설정으로 AVIF·WebP·JPEG 순서의 대체 구조가 실제로 동작하는지 여러 브라우저에서 테스트한다.
5. 나머지 이미지 일괄 전환: 대표 이미지에서 효과를 확인한 뒤, 상품 이미지·본문 이미지 등 나머지 전체로 작업 범위를 넓힌다.
6. 효과 재측정: 전환을 마친 뒤 다시 PageSpeed Insights로 점수를 확인해, 1단계에서 기록해 둔 수치와 비교한다.

이미지 수가 많은 사이트일수록 4에서 6단계가 시간이 걸릴 수 있으므로, 대표 이미지 전환만 먼저 끝내고 나머지는 별도 일정으로 진행해도 무방하다. 중요한 것은 완벽하게 한 번에 끝내는 것보다, 효과가 큰 부분부터 순서대로 처리하는 흐름이다.

자주 묻는 질문

PNG는 이제 아예 안 써도 되나요?

투명 배경이 필요하지 않은 사진이라면 대부분 AVIF나 WebP로 대체할 수 있다. 다만 로고처럼 투명 배경이 필수이면서 선명한 경계선이 중요한 이미지는 PNG나 SVG를 그대로 쓰는 경우도 여전히 많다. WebP·AVIF도 투명 배경을 지원하므로, 파일 크기를 줄이고 싶다면 전환을 검토해 볼 만하다.

이미지를 전부 AVIF로 바꾸면 문제없나요?

폴백 구성 없이 AVIF만 올리는 것은 권장하지 않는다. AVIF를 지원하지 않는 구형 브라우저나 오래된 기기 사용자에게는 이미지가 아예 표시되지 않을 수 있다. <picture> 태그로 WebP나 JPEG를 대체 포맷으로 함께 준비하는 것이 안전하다.

이미지 파일 크기가 줄어들면 정말 순위가 오르나요?

파일 크기 감소가 순위를 직접 올려 주지는 않는다. 다만 이미지 최적화로 개선되는 LCP는 구글이 공식적으로 인정한 코어 웹 바이탈 지표이며, 사용자 경험과 이탈률에 실질적인 영향을 준다. 순위보다는 방문자를 붙잡아 두는 효과로 이해하는 편이 정확하다.

AVIF로 변환하면 화질이 항상 좋아지나요?

압축 강도를 어떻게 설정하느냐에 달려 있다. 같은 파일 크기 조건에서는 AVIF가 화질을 더 잘 지키는 경향이 있지만, 압축 강도를 지나치게 높이면 AVIF도 화질이 나빠질 수 있다. 변환 후에는 반드시 눈으로 결과물을 확인하는 절차가 필요하다.

이미지 전용 CDN을 쓰면 포맷 변환을 신경 쓰지 않아도 되나요?

대부분의 작업을 대신 처리해 준다. Cloudinary·imgix 같은 이미지 전용 CDN은 방문자의 브라우저에 맞춰 AVIF·WebP를 자동으로 골라 제공한다. 이미지 수가 아주 많은 대형 쇼핑몰이라면 이런 서비스를 함께 검토할 만하다.

네이버 블로그·스마트스토어에도 이미지 포맷 전환이 필요한가요?

직접 신경 쓸 필요는 거의 없다. 네이버 블로그와 스마트스토어는 업로드한 이미지를 플랫폼이 자체적으로 처리해 서빙하는 구조라, 운영자가 WebP·AVIF 변환을 따로 할 수 없고 할 필요도 없다. 이미지 포맷 전환은 카페24·아임웹·워드프레스처럼 자체 도메인으로 운영하는 홈페이지에 해당하는 이야기다.

이미지를 이미 다 올려 둔 사이트인데, 지금이라도 전환할 가치가 있나요?

충분히 있다. 기존 이미지를 한꺼번에 다시 변환하는 작업(일괄 재생성)은 플러그인이나 CDN 도구로 비교적 수월하게 처리할 수 있다. 특히 방문자가 가장 먼저 보는 대표 이미지·배너부터 우선 전환하면, 큰 작업 없이도 체감 속도 개선 효과를 빠르게 확인할 수 있다.

AI가 생성한 이미지도 WebP·AVIF로 바꿔야 하나요?

마찬가지로 전환하는 것이 좋다. AI 이미지 생성 도구가 만들어 내는 원본 파일도 대부분 PNG나 JPEG 형태이기 때문에, 홈페이지에 올리기 전에 다른 이미지와 똑같은 방식으로 압축·포맷 변환 과정을 거치는 것이 안전하다. 생성형 이미지는 특히 파일 용량이 큰 경우가 많아, 포맷 전환에 따른 절감 효과가 더 크게 나타나기도 한다.

이미지 포맷 전환은 한 번 구조를 잡아 두면 이후 업로드하는 이미지에도 계속 효과가 이어지는 작업입니다. 화려하게 티가 나는 개선은 아니지만, 방문자와 검색엔진 모두에게 조금씩 더 나은 경험을 쌓아 주는 항목입니다. 특히 이미지 비중이 큰 업종일수록, 지금 당장 큰 비용을 들이지 않고도 체감할 수 있는 변화를 만들어 낼 수 있는 부분이기도 합니다.

이루웹은 홈페이지 제작 단계부터 이미지 최적화 구조를 함께 설계해 드리고 있으며, 이미 운영 중인 사이트의 이미지 포맷을 점검하고 전환하는 작업도 도와드리고 있습니다. 사이트 속도나 이미지 관리가 고민이시라면 이루웹에 문의 주시면 현재 상태를 진단해 드리고, 우리 사이트에 맞는 최적화 방안을 함께 찾아 드리겠습니다.