AVIF와 WebP: 2026년에 어떤 이미지 포맷을 선택할까

온라인 쇼핑몰, 블로그, 상품 카탈로그를 운영한다면 페이지에서 가장 무거운 요소는 거의 틀림없이 이미지입니다. 이미지가 로딩을 느리게 만들고, 방문자의 데이터를 소모하며, 검색엔진의 속도 점수를 떨어뜨립니다. 좋은 소식은 최근 몇 년 사이 익숙한 JPG보다 몇 배나 강하게 압축하면서도 화질은 그대로인 포맷들이 등장했다는 점입니다. 나쁜 소식은 그런 포맷이 한둘이 아니고, 각각 장점과 함정이 달라 단번에 고르기가 쉽지 않다는 것입니다. 이 글에서는 AVIF가 WebP와 무엇이 다른지, JPEG XL은 어디에 위치하는지, 언제 어떤 포맷을 써야 하는지, 그리고 예외 없이 모든 방문자에게 빠른 로딩을 제공하도록 설정하는 방법을 정리합니다.

겉보기에 똑같은 두 장의 상품 사진을 떠올려 보세요. 하나는 800KB, 다른 하나는 180KB입니다. 눈으로는 차이가 없지만 사이트 입장에서는 엄청난 차이입니다. 카탈로그 페이지에는 보통 이미지가 20~40장 있고, 각 이미지가 조금씩만 무거워도 페이지 전체가 수 메가바이트로 부풀어 오릅니다. 그다지 빠르지 않은 모바일 인터넷을 쓰는 방문자는 로딩을 기다리지 못하고 그냥 탭을 닫아 버립니다. 통계적으로 상당수의 사람들이 3초 넘게 걸리는 페이지에서 이탈하며, 그 원인은 대개 무거운 이미지입니다.

로딩 속도는 이미 오래전부터 랭킹 요소입니다. 검색엔진은 페이지의 주요 콘텐츠가 얼마나 빨리 그려지는지를 측정하는데, 그 영향력에서 이미지가 1순위입니다. 이미지가 가벼울수록 페이지가 빨리 뜨고, 방문자가 남아 무언가를 구매할 확률이 높아집니다. 이것은 양방향으로 작동합니다. 빠른 사이트는 검색에서 더 많은 방문자를 얻고, 빠른 페이지는 이미 들어온 사람을 더 잘 붙잡습니다. 텍스트와 스타일은 킬로바이트 단위인 반면 압축되지 않은 사진 한 장은 메가바이트가 나갈 수 있으므로, 이 방정식에서 이미지는 거의 항상 가장 약한 고리입니다.

순전히 비용 측면도 있습니다. 방문자에게 내보내는 매 메가바이트가 곧 트래픽입니다. 하루 방문이 수천 건인 큰 사이트에서는 이미지 용량이 호스팅 비용과 서버 처리 속도에 직접 영향을 줍니다. 이미지를 절반으로 줄이면 화질 손실 없이 부하와 비용도 절반으로 줄어듭니다.

정든 JPG는 제 역할을 다했지만 압축 효율에서는 절망적으로 뒤처졌습니다. 최신 포맷은 같은 시각적 화질에서 파일을 두 배 가볍게 만듭니다. 문제는 새 포맷 중 무엇을 고르고, 구형 브라우저를 쓰는 사람들을 위해 사이트를 망가뜨리지 않는 방법일 뿐입니다. 불필요한 이론 없이, 실전에 쓸 것만 순서대로 살펴보겠습니다.

이해를 돕는 포맷 간단 사전

비교에 앞서 등장인물들을 훑어봅시다. 다섯이고, 각각 역할이 있습니다.

• JPG(JPEG). 1992년부터의 베테랑. 손실 압축, 투명도와 애니메이션 없음. 어디서든 열리지만 효율에서는 완전히 구식입니다.
• PNG. 무손실 압축, 투명도 지원. 로고, 아이콘, 선이 또렷한 그래픽에는 필수지만 사진을 담으면 매우 무겁습니다.
• WebP. 구글이 만든 포맷으로 2010년에 등장해 2010년대 중반에 대중화됐습니다. 손실과 무손실 압축을 모두 지원하고 투명도와 애니메이션도 가능합니다. 호환성 면에서 중간 지점입니다.
• AVIF. AV1 비디오 코덱을 기반으로 한 젊은 포맷으로 2019년에 등장했습니다. 같은 화질에서 가장 강하게 압축하고 투명도, 애니메이션, 확장 색공간, HDR을 지원합니다. 주된 단점은 느린 인코딩입니다.
• JPEG XL(JXL). 거의 모든 것을 해내고 JPG와 역호환되는 유망한 신참이지만, 아직 브라우저 지원이 약합니다. 아래에서 따로 다룹니다.

AVIF는 최신 비디오 인코딩 기술 위에 세워진 비교적 새로운 포맷입니다. 현대 스트리밍 서비스가 돌아가는 바로 그 AV1 코덱의 프레임 내 압축을 사용합니다. 최대 강점은 공격적인 압축이며, 이 부분에서 선두입니다.

AVIF의 장점

• 가장 강한 압축. 같은 시각적 화질에서 AVIF 파일은 WebP보다 20~30% 가볍고, JPG보다 약 50% 가볍습니다. 즉 AVIF는 익숙한 JPG 이미지의 절반 무게가 될 수 있는데 눈으로는 차이를 알아채지 못합니다.
• 복잡한 이미지를 잘 견딤. 부드러운 그러데이션이 있는 사진(하늘, 피부, 흐린 배경)에서 AVIF는 JPG가 강하게 압축할 때 만드는 흉한 아티팩트와 사각형 블록을 거의 남기지 않습니다. 사각형 블록화 대신 부드러운 흐림을 주는데, 눈은 이를 훨씬 관대하게 받아들입니다.
• 투명도와 애니메이션. AVIF는 WebP처럼 알파 채널(투명 배경)과 애니메이션을 지원하므로 PNG와 GIF를 모두 대체할 수 있습니다.
• 넓은 색공간과 HDR. WebP에는 전혀 없는 부분입니다. AVIF는 10비트, 12비트 색 심도, 확장 색공간, HDR을 지원합니다. 신발 카탈로그에는 중요하지 않지만, 사진 갤러리나 포토그래퍼 포트폴리오, 여행 관련 사이트에서는 최신 화면에서 생생하고 진한 사진이 눈에 띄게 풍부해 보입니다.
• 낮은 비트레이트에서도 우수. 매우 강하게 압축해도 AVIF는 가장 우아하게 무너집니다. 용량을 한계까지 짜내도 이미지가 그럭저럭 봐줄 만한 반면, 같은 상황의 JPG는 모자이크로 변합니다.

AVIF의 함정

• 느린 인코딩. 이것이 가장 큰 단점입니다. 이미지를 AVIF로 변환하는 것은 WebP보다 5~10배 느리고, 최고 화질 설정에서는 더 느립니다. 이것이 사용자 생성 콘텐츠(UGC)에서 특히 문제인 이유는 이렇습니다. 사람이 지금 당장 리뷰 사진이나 프로필 이미지를 올리며 기다리는데 인코딩에 몇 초가 더 걸리면 경험 전체가 나빠집니다. 사이트의 정적 이미지라면 한 번 변환하고 잊으면 되므로 문제가 아니지만, 실시간 처리에서는 지연이 체감됩니다.
• 지원율은 약간 낮지만 이미 훌륭. 2026년 기준 AVIF는 브라우저의 약 95% 이상이 이해합니다. Chrome은 85버전(2020)부터, Firefox는 93버전(2021)부터, Safari는 iOS 16과 macOS Ventura의 16버전(2022)부터 지원합니다. 매우 좋은 수치지만 그래도 WebP보다 몇 퍼센트 낮습니다. 그러니 포맷이 열리지 않는 사람을 위한 대체 수단이 필요합니다.
• 구형 소프트웨어는 못 엶. 많은 데스크톱 프로그램, 이메일 클라이언트, 메신저, 사진 편집기가 아직 AVIF를 열지 못합니다. 방문자가 그런 이미지를 컴퓨터로 내려받으면 익숙한 뷰어에서 열리지 않을 수 있습니다. 그래서 AVIF는 사이트에서 보여주기에는 좋지만 내려받기나 전송용 파일로는 아직 애매합니다.
• 표시할 때 자원 요구가 약간 높음. AVIF 디코딩은 WebP보다 기기의 프로세서를 약간 더 씁니다. 최신 휴대폰과 컴퓨터에서는 느껴지지 않지만, 아주 오래되고 약한 기기에서는 이론적으로 렌더링이 조금 느려질 수 있습니다. 용량 이득에 비하면 사소하지만 정직하게 언급해 둡니다.

더 실감 나게, 1200×1200 픽셀 사진 한 장이 든 전형적인 상품 카드를 떠올려 봅시다. 준수한 화질의 JPG로는 약 350KB입니다. 같은 컷을 WebP로 하면 약 230KB, AVIF로 하면 약 140KB입니다. 즉 여기서 AVIF는 JPG보다 두 배 반, WebP보다 1.5배 가볍습니다. 이를 수백 개 상품에 곱하면 절감 규모가 분명해집니다.

이미지를 AVIF와 WebP로 변환하는 방법

방법은 여러 가지이며, 선택은 이미지 개수와 자동화 정도에 달렸습니다.

1. 일회성 작업용 온라인 변환기. 몇 장만 변환할 때 가장 간단합니다. 이미지를 올리고 AVIF나 WebP를 받아 내려받아 사이트에 올립니다. 첫 화면 이미지, 배너, 핵심 사진 십여 장에 이상적입니다.
2. 폴더 일괄 처리. 이미지가 수백 장이면 묶어서 돌리는 편이 좋습니다. 많은 변환기가 폴더 전체를 받아 같은 이름의 새 포맷 파일 세트를 내줍니다.
3. 사이트 측 자동화. 대형 카탈로그라면 새 이미지가 올라올 때마다 사이트가 AVIF와 WebP를 스스로 만들고 브라우저 종류에 맞는 버전을 내보내도록 설정하는 것이 합리적입니다. 그러면 수동 변환은 아예 잊어도 됩니다.

변환 시 유의점입니다. 화질은 중간에서 높음 사이로 잡고, 몇 킬로바이트를 더 아끼겠다고 압축을 최대로 올리지 마세요(뭉개짐이 생깁니다). 그리고 반드시 원본 JPG나 PNG를 대체 수단으로 보관하세요. 픽셀 크기도 중요합니다. 페이지에서 800픽셀로 보여줄 사진을 4000픽셀 폭으로 들고 있을 이유가 없습니다. 먼저 필요한 크기로 줄인 다음 변환해야 이득이 최대가 됩니다.

요약하면 AVIF는 최소 용량이 가장 중요하고 일회성 변환에 시간을 들일 수 있는 경우를 위한 포맷입니다. 한 번 올려 수천 명에게 보여줄 정적 이미지에 이상적입니다. 한 번 몇 초를 들여 변환하면 페이지를 볼 때마다 속도 이득을 얻고, 그것이 수백만 번 반복됩니다.

WebP는 최신 경쟁자들보다 먼저 나와 사실상 표준으로 자리 잡았습니다. 어디서든 그냥 작동하고 골칫거리를 만들지 않는 단일 포맷을 원한다면 바로 이것입니다.

WebP의 강점

• 거의 완전한 브라우저 지원. WebP는 전 세계 브라우저의 97% 이상이 이해합니다. Chrome은 2010~2014년에, Firefox는 65버전(2019)부터, Safari는 macOS Big Sur의 14버전(2020)부터, 아이폰은 iOS 14부터 완전히 지원합니다. 즉 대다수 방문자가 아무런 편법 없이 이미지를 봅니다.
• 눈에 띄는 용량 절감. 같은 화질의 JPG와 비교해 WebP는 약 25~35% 가볍습니다. 대부분의 사이트에는 이미 큰 도약입니다. 4MB짜리 페이지가 2.5MB 아래로 내려갑니다.
• 빠른 인코딩. 이미지를 WebP로 바꾸는 것은 빠르며 AVIF보다 몇 배 빠릅니다. 사용자가 프로필이나 리뷰 사진을 올리고 지금 결과를 기다리는 것처럼 즉석 변환이 필요할 때 결정적입니다.
• 투명도와 애니메이션 지원. WebP는 알파 채널(투명 배경)과 애니메이션을 모두 지원하므로, 투명 배경 PNG의 대체이자 무거운 GIF 애니메이션의 대체로 쓸 수 있습니다. 애니메이션 WebP는 같은 영상의 GIF보다 몇 배 가볍습니다.
• 무손실 모드. WebP에는 PNG의 직접 경쟁 상대인 무손실 모드도 있습니다. 픽셀을 완벽히 보존하면서 평균 20~26% 가벼운 파일을 주므로 스크린샷과 그래픽에 잘 맞습니다.
• 성숙한 생태계. 포맷이 충분히 오래되어 대중적인 콘텐츠 관리 시스템, 플러그인, 도구가 별다른 수고 없이 다룹니다. 어떤 서비스가 이 포맷을 이해하지 못하는 상황은 거의 만나지 않습니다.

WebP가 밀리는 지점

WebP에 대한 가장 큰 불만은, 더 강하게 압축하는 포맷이 존재한다는 점입니다. 이미지가 아주 많으면(카탈로그에 상품 수천 개) 절감된 각 퍼센트가 실제 트래픽 절감과 더 빠른 로딩으로 이어집니다. 이미지가 수십 장 수준이면 WebP와 더 공격적인 압축의 차이는 거의 느껴지지 않습니다. 하지만 대형 카탈로그나 수백 장짜리 갤러리라면 그 퍼센트가 수십, 수백 메가바이트로 쌓이고, 여기서는 WebP가 밀립니다.

또 하나의 사소한 점입니다. 손실 압축 WebP는 큰 사진의 아주 부드러운 그러데이션을 최신 포맷보다 약간 못 다룰 때가 있습니다. 실제로는 강한 압축에서만, 그것도 드물게 나타나지만, 예술 사진을 다룬다면 알아 둘 만합니다. WebP에는 크기 제한도 있습니다. 최대 16383×16383 픽셀로, 거의 항상 충분하지만 거대한 파노라마는 담기지 않습니다.

이 절감이 어디서 오는지 알아 두면 유용합니다. WebP는 구형 JPG보다 인접 픽셀을 더 똑똑하게 예측하고 반복되는 영역을 더 효율적으로 담습니다. 쉽게 말해 다음 조각이 어떨지 더 잘 맞히고 전체가 아니라 차이만 저장합니다. 사용자에게는 결국 한 가지 의미입니다. 별도 설정 없이 더 가벼운 용량으로 같은 선명함을 얻는 것입니다.

WebP가 특히 빛을 발하는 실전 상황

거의 아무것도 망가뜨릴 위험 없이 WebP 전환이 가장 빠르고 뚜렷한 효과를 내는 전형적인 시나리오가 몇 가지 있습니다.

• 블로그와 정보성 아티클. 여기서는 이미지가 주로 삽화이고 수도 많지 않으며, 마지막 몇 퍼센트의 압축보다 최대 호환성이 더 중요합니다. WebP가 완벽히 해결합니다.
• 카탈로그의 미리보기와 썸네일. 목록으로 나열되는 작은 이미지는 즉시, 모두에게 똑같이 뜨는 것이 핵심입니다. WebP는 빠르게 인코딩되고 빠르게 로딩됩니다.
• 완성형 플랫폼 기반 사이트. 표준적인 콘텐츠 관리 시스템을 쓴다면 이미지의 WebP 전환은 대개 기성 솔루션 하나로 처리됩니다. 지원하는 사람에게는 WebP를, 나머지에게는 일반 JPG를 자동으로 내보냅니다. 수작업 없이 속도 이득을 얻는 가장 간단한 길입니다.
• 무거운 GIF 대체. GIF로 된 애니메이션 배너와 짧은 루프 영상은 엄청나게 무겁습니다. 같은 영상을 애니메이션 WebP로 하면 몇 배 가벼우면서 화질은 같거나 더 낫습니다.

많은 사이트 운영자에게는 WebP 전환 하나만으로도 향후 몇 년의 이미지 최적화 과제가 정리됩니다. AVIF가 필요 없다는 뜻이 아니라, WebP가 20%의 노력으로 80%의 결과를 주므로 여기서 시작하는 것이 합리적이라는 뜻입니다.

WebP 결론은 단순합니다. 안전한 기본값이라는 것입니다. 세부 사항과 대체 설정에 파고들고 싶지 않다면 전부 WebP로 옮기기만 해도 최신 포맷의 이득 대부분을 얻습니다. 여기서 실수하기란 사실상 불가능하고, 수많은 사이트에는 WebP 하나만으로도 로딩을 획기적으로 빠르게 하기에 차고 넘칩니다.

스펙에 헤매지 않도록 실용적인 규칙을 지니세요. 거의 모든 실제 상황을 덮습니다.

요약표: 콘텐츠 유형별 포맷

몇 초 만에 결정해야 한다면 이미지 종류로 판단하세요.

• 카탈로그의 상품 사진: WebP 대체를 둔 AVIF. 이미지가 많고 자주 로딩되며 절감이 최대입니다.
• 큰 배너와 커버: AVIF. 가장 무거운 요소라 공격적인 압축에서 가장 크게 이득을 봅니다.
• 아이콘, 로고, 단순 그래픽: 가능하면 SVG, 아니면 PNG나 무손실 WebP.
• 아티클 삽화: WebP, 양이 많으면 AVIF. 여기서는 극한 압축보다 호환성이 값집니다.
• 사용자가 올리는 사진(UGC): WebP, 즉석 처리가 중요하기 때문입니다.
• 이메일 안 이미지: JPG나 PNG만. 이메일은 새 포맷을 이해하지 못합니다.
• 소셜 미리보기(og:image): JPG나 PNG. 아니면 미리보기가 안 만들어질 수 있습니다.
• 애니메이션: GIF 대신 애니메이션 WebP나 AVIF. 절감이 몇 배입니다.

AVIF를 선택하세요, 이럴 때

• 이미지가 정적이고 거의 바뀌지 않을 때: 카탈로그 상품 사진, 아티클 삽화, 배너, 헤더와 푸터 이미지.
• 이미지가 많고, 절약한 각 킬로바이트가 수천 회의 조회에 곱해질 때.
• 이미지를 실시간이 아니라 미리 준비할 때(사이트에 올리며 한 번 변환).
• 넓은 색공간이나 HDR의 생생한 사진이 필요할 때, 예컨대 포트폴리오나 사진 갤러리.
• 주된 목표가 최대 속도와 최소 트래픽일 때.

WebP를 선택하세요, 이럴 때

• 콘텐츠를 사용자가 만들 때: 프로필, 리뷰 사진, 지금 올려 즉시 처리돼야 하는 이미지.
• 대체 처리로 씨름하지 않는 단순함과 예측 가능성이 중요할 때.
• 최소 노력으로 최대한 넓은 호환성이 필요할 때.
• 압축 차이가 결정적일 만큼 이미지가 많지 않을 때.

PNG를 선택하세요, 이럴 때

• 로고, 아이콘, 스크린샷, 또는 또렷한 선과 색 블록이 있는 그래픽일 때.
• 가장자리에 아주 미세한 아티팩트도 없는 완벽하게 깨끗한 투명도가 필요할 때.
• 이후에 편집할 이미지라서 픽셀을 그대로 보존하는 것이 중요할 때.

JPG를 남겨 둘 때

JPG는 압축에서 구식이지만 아주 오래된 프로그램과 기기에서도 어디서나 열립니다. 예외적인 경우나, 새로운 것을 전혀 이해하지 못하는 시스템에 이미지를 넘겨야 할 때(예: 고전 포맷만 받는 일부 마켓플레이스에 상품 사진을 올릴 때)를 위한 최후의 대체 수단으로만 JPG를 유지하는 것이 합리적입니다. 사이트 자체의 주력 포맷으로 JPG를 2026년에 고르는 일은 이제 없습니다.

JPEG XL은 어떤가

JPEG XL(JXL)은 많은 사람이 기대를 거는 새 포맷이며, 그럴 만합니다. 기술적으로 인상적입니다. 사진에서 AVIF와 비슷하거나 조금 더 나은 수준으로 압축하고, AVIF보다 빠르게 인코딩되며, 투명도, 애니메이션, 넓은 색공간, HDR, 점진적 로딩(이미지가 위에서 아래로가 아니라 서서히 드러남)을 지원합니다. 특히 값진 점은 기존 JPG를 무손실로 약 20% 더 줄이면서 원본으로 되돌릴 여지를 남긴다는 것입니다. 이상적인 포맷처럼 들립니다.

문제는 하나지만 결정적입니다. 브라우저 지원입니다. 2026년 기준 JPEG XL을 기본으로 이해하는 것은 Safari(17버전부터)이고, Chrome은 지원을 없앴으며, Firefox는 플래그로만 켭니다. 즉 신뢰할 수 있는 대체 없이 대다수 방문자에게 JXL을 내보내는 것은 아직 불가능하며, 실무에서는 대개 수고에 비해 이득이 적습니다. 결론은 이렇습니다. JPEG XL은 매우 유망한 포맷으로 레이더에 올려 두되, 2026년 실사용 사이트에서는 AVIF와 WebP 조합이 더 안전합니다. Chrome이 지원을 되살리면 판도가 바뀔 수 있고, 그때 전략을 재검토할 만합니다.

애매한 상황

가끔 과제가 규칙에 딱 들어맞지 않습니다. 자주 만나는 갈림길과 해결법입니다.

• 카탈로그는 크지만 판매자들이 직접 사진을 올린다. 여기서는 혼합이 합리적입니다. 업로드 시 어떤 포맷이든 받고, 즉시 표시용으로 빠른 WebP를 실시간 생성하며, 밤에는 백그라운드 프로세스로 쌓인 것을 AVIF로 변환합니다. 그러면 사용자는 기다리지 않고 방문자는 결국 가장 가벼운 버전을 받습니다.
• 로고, 아이콘, 또렷한 선의 단순 그래픽. 색 수가 적은 이런 이미지에는 여전히 벡터 그래픽(SVG)이나 PNG가 잘 맞고, 래스터 중에서는 무손실 모드 WebP가 좋습니다. 단순 그래픽에서 AVIF의 이득은 사진보다 작습니다.
• 이메일 발송용 이미지. 이메일 프로그램은 새 포맷 지원이 나쁩니다. 이메일 안에서는 AVIF도 WebP도 기대할 수 없습니다. 고전 JPG나 PNG를 두세요. 용량보다 호환성이 중요한 경우입니다.
• 소셜과 링크 미리보기용 이미지. 공유 시 미리보기를 만드는 소셜 로봇은 대개 JPG와 PNG만 이해합니다. og:image 이미지는 고전 포맷으로 두세요. 아니면 미리보기가 안 뜰 수 있습니다.

전환을 미루게 만드는 오해들

새 포맷을 둘러싸고 사람들이 간단하고 이득이 되는 한 걸음을 못 떼게 하는 오해가 몇 가지 쌓였습니다. 가장 흔한 것을 살펴봅니다.

• 오해: 새 포맷은 화질이 나쁘다. 정반대입니다. 같은 용량이면 AVIF와 WebP가 JPG보다 낫고, 같은 화질이면 더 가볍습니다. 압축을 한계까지 올릴 때만 화질이 나빠 보이는데, 이는 포맷이 아니라 설정 문제입니다.
• 오해: 도입이 어렵다. 최소 수준에서는 온라인 변환기 하나와 파일 교체로 끝입니다. picture를 쓰는 완전한 방식은 조금 더 복잡하지만 아래 소개하는 틀을 따르면 되고 이후에는 복사만 하면 됩니다.
• 오해: 방문자 절반은 이미지를 못 본다. 대체 없이 새 포맷을 내보낼 때만 맞습니다. picture 연쇄를 쓰면 100%의 방문자가 확실히 이미지를 봅니다. 누군가는 가벼운 AVIF를, 누군가는 대체 JPG를 받을 뿐입니다.
• 오해: 검색엔진은 새 포맷을 싫어한다. 정확히 반대입니다. 속도 점검 도구 자체가 최신 포맷으로 옮기라고 권하고, 빠른 사이트가 더 잘 랭킹됩니다.
• 오해: AVIF가 있으니 WebP는 더 이상 필요 없다. 필요합니다. 바로 AVIF의 대체로, 그리고 사용자 업로드용 빠른 포맷으로요. 둘은 짝을 이뤄 작동합니다.

가장 우아한 해법은 하나의 포맷을 고르는 것이 아니라 각 브라우저에 그가 다룰 수 있는 최선을 내보내는 것입니다. 브라우저가 스스로 이해하는 첫 포맷을 고르고 나머지는 건너뜁니다. 이 일은 picture 태그로 합니다.

picture 태그의 구조

picture 안에는 가장 효율적인 것부터 가장 호환되는 것 순으로 후보를 나열합니다. 브라우저는 위에서 아래로 읽어 첫 번째 적합한 것을 취합니다.

• 첫째로 AVIF, 가장 가벼운 버전. 브라우저가 이해하면 바로 이것을 로딩합니다.
• 둘째로 WebP, AVIF가 지원되지 않을 경우를 위해.
• 맨 끝에 JPG나 PNG를 담은 일반 img 태그. 아주 오래된 브라우저를 위한 보험입니다.

구조는 이렇습니다.

```html <picture> <source srcset="foto.avif" type="image/avif"> <source srcset="foto.webp" type="image/webp"> <img src="foto.jpg" alt="설명" width="800" height="600" loading="lazy" decoding="async"> </picture> ```

중요한 점입니다. alt, width, height, loading 등의 속성은 source가 아니라 picture 안의 img 태그에 답니다. source 태그는 파일 선택만 담당하고 나머지는 모두 최종 img에서 가져옵니다.

카탈로그 페이지에서 실제로 벌어지는 일

이득이 추상적으로 남지 않도록 실제 예로 계산해 봅시다. 카탈로그 페이지가 1200픽셀짜리 상품 사진 30장과 첫 화면 배너를 보여준다고 합시다.

• 전에는, 전부 JPG: 사진 30장 × 350KB에 배너 500KB, 이미지만 약 11MB입니다. 모바일에서 이런 페이지는 고통스럽게 느리게 열리고 상당수 방문자가 먼저 떠납니다.
• 후에는, 전부 WebP 대체를 둔 AVIF: 사진 30장 × 140KB에 배너 200KB, 약 4.4MB입니다. 용량이 절반 넘게 떨어졌고, 그것도 눈으로 보는 화질 손실이 전혀 없습니다.

한 페이지에서 6MB 넘게 절약한다는 것은 방문자에게 빠른 로딩일 뿐 아니라 서버 측 트래픽 절감이자 속도 점검 도구의 더 나은 점수이기도 합니다. 하루 조회가 수천 건이면 한 달 트래픽 절감은 수십, 수백 기가바이트로 측정됩니다.

단계별 도입 계획

1. 이미지 버전을 준비하세요. 각 이미지마다 AVIF와 WebP 두 벌을 만드세요. 원본 JPG나 PNG는 최후의 대체로 남겨 둡니다.
2. img 태그에 width와 height를 명시하세요. 이미지 자리를 미리 잡아 로딩 중 페이지가 튀지 않게 하며, 덤으로 레이아웃 안정성(CLS 지표) 점수도 개선합니다.
3. 첫 화면 아래 이미지에는 loading lazy를 추가하세요. 방문자가 스크롤해 도달할 때만 로딩되어 첫 화면이 더 빨리 열립니다.
4. 첫 화면의 주요 이미지에는 lazy를 걸지 마세요. 오히려 fetchpriority high를 붙여 브라우저가 가장 먼저 로딩하고 최대한 일찍 뜨게 하는 편이 좋습니다.
5. 여러 브라우저에서 확인하세요. 어디서나 이미지가 표시되는지, 그리고 최신 브라우저가 실제로 가벼운 AVIF를 가져오는지 점검하세요. 개발자 도구의 Network 탭에서 어떤 파일이 로딩됐는지 보면 쉽게 확인됩니다.

PageSpeed, 코어 웹 바이탈, SEO에 미치는 영향

이미지를 최신 포맷으로 옮기는 것은 검색이 반영하는 가장 무게 있는 속도 지표를 직접 겨냥합니다.

• LCP(최대 콘텐츠 요소 렌더링). 화면에서 가장 큰 요소는 대개 첫 화면 이미지입니다. 그것이 JPG로 350KB가 아니라 AVIF로 140KB라면 눈에 띄게 빨리 로딩되고 LCP가 개선됩니다. 코어 웹 바이탈에서 가장 중요한 지표이며 이미지가 여기에 가장 크게 영향을 줍니다.
• CLS(레이아웃 이동). 포맷 변경 자체는 CLS에 영향을 주지 않지만, picture 도입 시 반드시 width와 height를 넣게 되므로 로딩 중 페이지 튐이 사라집니다. 한 동작으로 두 가지 이득입니다.
• 전체 페이지 용량과 PageSpeed 점수. 속도 점검 도구는 무거운 이미지를 대놓고 지적하고 최신 포맷 전환을 제안합니다. 이를 실행하면 그 권고 목록에서 가장 흔한 항목 하나를 지우게 되고 전체 점수가 오릅니다.
• 행동 지표와 SEO. 빠른 페이지는 방문자를 덜 잃고 이탈률이 낮으며 조회 깊이가 깊습니다. 검색이 이를 보고 그런 사이트를 올립니다. 즉 가벼운 이미지의 이득은 기술적일 뿐 아니라 순위와 매출로 환산됩니다.

도입 시 흔한 실수

• 대체를 잊음. 대체 없이 AVIF만 내보내면 소수 방문자에게는 이미지가 아예 로딩되지 않습니다. 연쇄 끝에 최소한 WebP나 JPG를 항상 남기세요.
• type 속성을 엉뚱한 소스에 붙임. 브라우저는 source 태그의 type 값을 보고 판단합니다. 타입을 뒤섞으면 엉뚱한 포맷을 고르거나 적합한 것을 건너뛸 수 있습니다. AVIF 파일에 image/avif가, WebP에 image/webp가 붙었는지 재확인하세요.
• AVIF 버전을 너무 강하게 압축함. 화질을 잃으면서까지 최소 용량을 좇을 필요는 없습니다. AVIF에는 화질 설정이 있고, 너무 공격적인 값은 뭉개짐과 디테일 손실을 줍니다. 균형을 잡으세요. 보통 중간에서 높음 정도면 여전히 가벼우면서 훌륭한 이미지가 나옵니다.
• 레이아웃의 크기를 갱신하지 않음. 한 버전과 다른 버전의 비율이 다르면 페이지가 튑니다. 한 이미지의 모든 버전은 같은 폭과 높이를 가져야 합니다.
• AVIF를 내려받기에 넣음. 구형 소프트웨어가 못 연다는 점을 기억하세요. 이미지 내려받기 버튼이 있다면 익숙한 JPG나 PNG를 내주고, AVIF는 페이지 표시에만 쓰세요.

이미지마다 이중 변환으로 씨름하기 싫다면 작게 시작하세요. 가장 무거운 이미지(상품 사진, 큰 배너, 첫 화면 이미지)를 WebP 대체를 둔 AVIF로 옮기고 나머지는 WebP로 두세요. 부분 도입만으로도 체감되는 속도 향상이 있고, 성능 점수의 차이를 바로 보게 됩니다. 과정에 익숙해지면 점차 사이트 전체로 넓히면 됩니다.

AVIF는 항상 WebP보다 가벼운가요?

사진에서는 거의 항상, 보통 20~30% 가볍습니다. 하지만 색이 두어 개뿐인 아주 단순한 그래픽이나 작은 아이콘에서는 차이가 거의 사라지고, 때로는 무손실 WebP가 오히려 이기기도 합니다. 규칙은 이렇습니다. 사진은 AVIF, 단순 그래픽은 둘 다 확인해 더 가벼운 쪽을 고르세요.

AVIF나 WebP로 옮기면 화질이 떨어지나요?

압축을 한계까지 올리지 않는 한 아닙니다. 정상적인 화질 설정에서 최신 포맷은 원본과 시각적으로 구별되지 않으면서 몇 배 가벼운 이미지를 줍니다. 최소 용량을 위해 압축을 최대로 올릴 때만 화질이 떨어지며, 그렇게 할 필요는 없습니다.

변환 후 옛 JPG를 지워야 하나요?

아니요, 오히려 picture 연쇄의 최후 대체로 남기세요. 디스크에서 거의 무게가 없고, 아주 오래된 브라우저나 고전만 이해하는 외부 시스템에 대비한 보험이 됩니다.

AVIF는 투명 배경을 지원하나요?

네, AVIF는 PNG나 WebP처럼 완전한 알파 채널을 갖습니다. 그래서 투명도가 있는 무거운 PNG를 대체해 같은 깨끗한 투명도로 몇 배 가벼운 파일을 얻을 수 있습니다.

사용자가 올리는 사진에는 무엇을 고를까요?

WebP입니다. AVIF는 5~10배 느리게 인코딩되어 사용자가 기다립니다. 빠른 WebP가 즉시 결과를 보여주고, 최대 압축을 정 원한다면 쌓인 사진을 나중에 밤사이 백그라운드로 AVIF로 변환하면 됩니다.

지금 바로 JPEG XL로 옮길 만한가요?

아직 아닙니다. 기술적으로 훌륭한 포맷이지만 Chrome이 지원하지 않고, 이는 너무 큰 방문자 비중입니다. 2026년 실사용 사이트에는 AVIF와 WebP 조합이 더 안전합니다. 브라우저 지원이 자라면 JPEG XL로 돌아올 만합니다.

이미지 포맷이 검색 순위에 영향을 주나요?

간접적이지만 뚜렷하게요. 포맷 자체는 랭킹 요소가 아니지만 로딩 속도와 코어 웹 바이탈을 개선하고, 이것들은 이미 반영됩니다. 게다가 빠른 사이트는 방문자를 더 잘 붙잡아 행동 신호도 당신에게 유리하게 작동합니다.

정리하면, 1분 안에 결정할 수 있도록 지금까지의 이야기를 빠른 메모로 묶습니다.

• 골칫거리 없이 단일 포맷이 필요한가? WebP를 고르세요. 지원율 97% 이상, 빠른 인코딩, 실수하기 불가능.
• 최대 속도를 짜내고 싶은가? 정적 이미지에 AVIF를 쓰세요. WebP보다 20~30%, JPG보다 약 두 배 가볍습니다.
• 사용자가 실시간으로 사진을 올리는가? WebP. AVIF는 5~10배 느리게 인코딩됩니다.
• 로고, 아이콘, 스크린샷인가? PNG나 SVG, 또는 무손실 WebP.
• 이메일, 소셜, 링크 미리보기인가? 고전 JPG나 PNG. 새 포맷은 거기서 지원되지 않습니다.
• 완벽하게 하고 싶은가? AVIF, 그다음 WebP, 끝에 JPG를 둔 picture 연쇄.
• JPEG XL? 유망하지만 이릅니다. Chrome이 아직 지원하지 않습니다.

또 하나의 유용한 습관입니다. 새 포맷을 도입한 뒤 결과를 측정하세요. 변경 전후로 페이지 속도 점검 도구를 열어 페이지 용량과 성능 점수를 비교하고, 겸사겸사 LCP 지표도 보세요. 그러면 이득의 구체적 수치를 보고 나머지 이미지도 옮길지 판단하게 됩니다. 측정 없는 최적화는 점치기가 되지만, 측정과 함께라면 이해 가능하고 관리 가능한 과정이 됩니다.

핵심 생각은 이것입니다. AVIF와 WebP는 서로를 없애려는 경쟁자가 아니라 짝입니다. AVIF는 더 나은 압축을, WebP는 더 나은 호환성과 인코딩 속도를 주며, 고전 JPG와 PNG는 오래된 시스템으로 이어지는 보험이자 다리로 남습니다. 이 조합이 모든 경우를 덮습니다.

이 이야기에서 가장 어려운 부분은 어떤 포맷이 나은지 파악하는 것이 아니라 실제로 이미지를 변환하는 일입니다. 이 단계를 쉽게 하도록, 브라우저에서 바로 이미지를 최신 포맷의 가벼운 버전으로 변환해 사이트에 게시할 준비를 마칠 수 있습니다. 가장 무거운 이미지 몇 장을 옮겨 전후 용량을 비교해 보세요. 아마 그 수치가 기분 좋게 놀라게 할 것이고, 방문자는 빠른 로딩에 고마워할 것입니다. 메인 페이지의 가장 무거운 이미지부터 시작하면 그다음은 저절로 굴러갑니다.