AVIF vs WEBP

의사결정 회의에서 쓸 평가표

포맷 논쟁을 줄이려면 점수표가 필요합니다. 예를 들어 압축 점수, 인코딩 비용, QA 용이성, 파트너 호환, 기존 툴 재사용성을 5점 척도로 평가합니다. AVIF가 압축에서 이겨도 QA/호환에서 크게 지면 총점이 뒤집어질 수 있습니다. 엔지니어링 취향이 아니라 운영 총비용으로 결정하세요.

평가 데이터는 실제 카탈로그에서 뽑으세요. 스톡 사진 벤치마크는 자사 상품 컷·배너·텍스트 합성 이미지의 결과를 대체하지 못합니다. 최소 상품 10, 배너 5, 썸네일 10처럼 세트를 고정해 두 포맷을 같은 조건으로 뽑고 총 바이트와 육안 실패 수를 기록합니다.

마이그레이션 중 혼재를 관리하는 법

전환 기간에는 AVIF/WEBP/JPG가 동시에 존재합니다. URL 규칙과 템플릿 컴포넌트를 명확히 하지 않으면 어떤 페이지는 폴백이 없고 어떤 페이지는 이중 다운로드가 생길 수 있습니다. 이미지 컴포넌트를 한곳으로 모으고, 포맷 우선순위를 설정으로 주입하세요.

구형 앱 웹뷰 비중이 높은 서비스(특정 인앱 브라우저)는 실험군을 작게 가져가세요. 외부 최신 크롬에서는 멀쩡한 AVIF가 인앱 웹뷰에서 실패하는 사례가 보고되곤 합니다. 사용자 에이전트나 서버 능력을 과신하지 말고 실제 웹뷰에서 확인하세요.

되돌리기 계획

포맷 전환에는 롤백이 필요합니다. CDN 원본에 JPG/WEBP 마스터가 남아 있는지, 기능 플래그로 AVIF를 끌 수 있는지 미리 확인하세요. “이미 AVIF만 남김” 상태가 되면 문제 발생 시 복구가 느려집니다. 절감보다 복구 가능성이 우선인 캠페인 기간에는 특히 보수적으로 진행하세요.

작은 실험으로 끝내는 비교 프로토콜

프로덕션 전면 적용 전에 스테이지에서 히어로 5장만 AVIF/WEBP로 각각 배포해 보세요. 동일 캐시 정책, 동일 해상도, 동일 관측 기간을 유지합니다. 결과 지표는 전송 바이트, LCP, JS 오류/이미지 오류, CS 티켓입니다. 한 지표만 보고 결정하지 마세요.

실험이 성공해도 즉시 전 페이지로 확대하기보다, 템플릿 유형별로 단계 적용하세요. 상세페이지 → 검색 목록 → 블로그 순처럼 위험도가 낮은 곳부터 가면 롤백이 쉽습니다. 문서화된 프로토콜이 있으면 포맷 전쟁이 재발해도 같은 실험으로 끝낼 수 있습니다.

실험 중에는 마스터 파일을 반드시 보존하세요. AVIF/WEBP 파생본만 남은 상태에서 결과가 안 좋으면 재인코딩 누적으로 판단이 흐려집니다. 원본에서 다시 뽑을 수 있어야 공정한 A/B가 됩니다.

둘 다 쓸 때의 기본 아키텍처

원본 마스터(JPG/PNG/고품질) → 파생 WEBP → (선택) 파생 AVIF → 구형 클라이언트 JPG 폴백. 이 층위를 건너뛰어 AVIF만 원본으로 삼으면 하위 호환 제작이 어려워집니다. 스토리지가 걱정되면 마스터만 고품질로 두고 파생본은 CDN에서 생성·캐시하세요. 중요한 것은 언제든 JPG를 다시 만들 수 있는 출발점이 남아 있어야 한다는 점입니다.

관측 시에는 포맷별 히트율과 오류율을 분리해 보세요. AVIF 오류율이 특정 웹뷰에서만 높다면 그 세그먼트만 제외하는 규칙이 WEBP 전면 포기보다 낫습니다. 세밀한 제외가 어렵다면 당분간 WEBP+JPG가 정답일 수 있습니다.

선택 가이드 한 단락

추가 절감과 파이프라인이 준비됐으면 AVIF를 시험하고, 운영 단순성이 우선이면 WEBP에 머무르세요. 어느 쪽이든 JPG 폴백과 마스터 보관은 포기하지 마세요. 작은 실험 프로토콜로 총 바이트와 오류를 측정한 뒤 확대 여부를 결정하세요. 포맷 논쟁 시간보다 측정 시간이 짧아지는 상태가 이상적입니다. 관련 변환 도구로 호환 사본을 만드는 방법도 팀에 공유해 두세요.