좋은 결과 뒤에 있는 기술, 형식 및 작은 결정에 대한 팀의 메모.
2026년 AVIF 호환의 풍경
AVIF의 브라우저 지원은 2026년까지 전 세계 브라우저의 약 94.3퍼센트에 이르렀지만, 브라우저 지원이 전부는 아닙니다. 이미지 소비의 큰 몫은 브라우저 밖에서 일어납니다. 본문에 이미지를 그리는 메일 클라이언트, 편집하려고 파일을 여는 디자인 도구, 업로드를 검증하고 다시 손질하는 콘텐츠 관리 시스템, 전달용 이미지 처리 흐름, 자산을 끼워 넣는 문서 편집기, 그리고 업로드 시점에 이미지를 처리하는 소셜입니다. 이런 브라우저가 아닌 시스템 대부분에서 AVIF 지원은 브라우저 보급보다 한참 뒤처져 있습니다. Gmail, Outlook, 그리고 대부분의 기업용 메일 클라이언트는 아직도 AVIF를 거부하는 오래된 흐름으로 이미지를 다룹니다. Adobe Creative Cloud는 2024년 후반 판에 와서야 AVIF 지원을 더했습니다. 오래된 이미지 플러그인을 쓰는 많은 WordPress 구성은 지금도 업로드에서 AVIF를 막습니다. 반면 WebP는 이런 거의 모든 플랫폼에서 여러 해 동안 채택되어 왔습니다. AVIF를 WebP로 변환하는 일은 이 브라우저가 아닌 기반을 위한 호환의 다리입니다.
이 방향이 양쪽 모두 빠른 이유
AVIF에서 WebP가 반대 방향보다 빠른 것은 코덱이 짜인 방식 때문입니다. AVIF 읽기는 브라우저의 네이티브 읽기가 맡으며, 최신 기기에서는 하드웨어 도움을 받아 돌아갑니다. WebP 써내기도 브라우저의 네이티브 WebP 방식을 쓰고, 대부분의 플랫폼에서 역시 하드웨어 도움을 받습니다. 두 작업 모두 무거운 부품을 불러올 필요가 없는데, 그것이 바로 AVIF 써내기의 병목입니다. AVIF 출력을 위한 부품은 크고 세션마다 시동에 약 1초가 듭니다. AVIF에서 WebP는 그 모든 것을 건너뜁니다. 흐름은 읽은 뒤 네이티브 경로로 써내는 것뿐이고, 2메가픽셀 사진의 왕복은 어떤 최신 데스크톱이나 노트북 브라우저에서도 1초를 한참 밑돌며 끝납니다. 그래서 AVIF에서 WebP는 사용자가 1초 안의 응답을 기대하는 대화형 작업에 알맞습니다.
다시 써내기의 실제 비용
AVIF를 WebP로 변환하는 데는 다시 써내기가 한 번 들어갑니다. AVIF는 원래 어느 정도의 손실 압축으로 써내진 것입니다. 그것을 읽으면 그 손실된 원본을 반영한 픽셀 값이 나옵니다. 이어서 WebP가 그 픽셀에, 화질 85에 맞춘 거의 무손실 설정으로 제 압축을 입힙니다. 그 설정에서 흔한 사진 내용이면 출력의 PSNR은 약 44 dB가 됩니다. 사진을 보통 크기로 보는 사람에게 원본 AVIF와 출력 WebP의 차이는 보이지 않습니다. 작은 크기의 아주 가는 글자, 픽셀 단위로 정확한 아이콘, 가장자리가 단단한 색 덩어리가 든 그림에서는 두 번의 손실 단계가 쌓여 가까이서 보면 미묘한 차이가 나타날 수 있습니다. 라이브러리 전체 변환에 들어가기 전에, 화질에 가장 민감한 자산에서 대표적인 표본을 최대 확대로 시험하세요.
투명도 왕복을 자세히 보기
AVIF의 투명 정보는 별도의 레이어로 저장되며, 브라우저는 파일을 읽을 때 색상 내용과 함께 이를 디코딩합니다. 브라우저가 AVIF를 읽으면 색 버퍼와 투명도 마스크가 함께 만들어집니다. 변환은 둘을 완전한 투명도로 합쳐, 반투명 영역까지 빠짐없이 지킵니다. 이어서 WebP는 손실 WebP를 써내되, 그 알파는 투명도 레이어에 한해 WebP의 무손실 방식으로 따로 저장됩니다. 그 결과, 출력 WebP의 투명도 마스크는 AVIF에서 읽어 들인 알파 값에 대해 무손실로 보존됩니다. 부드러운 그러데이션과 흐린 가장자리는 살아남습니다. 남는 알파의 손상은 AVIF의 원래 부호화가 넣은 만큼뿐입니다. 원본 AVIF의 알파 가장자리가 깔끔하면 출력 WebP의 가장자리도 깔끔하며, 같은 마스크가 어떤 배경 위에 겹칠 준비를 마친 상태입니다.
출력을 다른 선택지와 견주기
AVIF를 읽지 못하는 시스템에 맞춰야 할 때 현실적인 선택지는 셋입니다. WebP로의 변환, PNG로의 변환, JPG로의 변환입니다. 투명도가 있는 자산에는 JPG가 잘못된 선택인데, 투명도 레이어이 없어 그것을 단색으로 평탄화해 버리기 때문입니다. PNG는 가장 큰 파일을 만들어 보통 AVIF의 세 배에서 열 배쯤 되며, 무손실 중간본이 필요하거나 받는 쪽이 PNG 그 자체를 요구할 때만 옳은 선택입니다. WebP는 그 가운데에 놓입니다. 최신 환경에서의 보편적인 호환을 주고, 투명도를 지키며, PNG처럼 AVIF의 300에서 1000퍼센트가 아니라 보통 20에서 25퍼센트만 큰 파일을 만듭니다. 무손실 출력을 요구하지 않는 호환을 위한 변환이라면 WebP가 옳은 중간본입니다.
한 장은 브라우저에서, 묶음은 서버에서
이 짝은 일에 따라 두 길로 돕니다. 한 장의 AVIF는 기본 길을 따라 통째로 당신의 브라우저 안에서 디코딩되어 WebP로 다시 저장되니, 한 파일이면 업로드가 전혀 없고, 페이지가 읽힌 뒤 바깥으로 나가는 요청이 영임을 개발자 도구가 뒷받침합니다. 이것은 빠른 볼일과 은밀한 고객의 일, 자사 제품 이미지, 자기 기기에 두고 싶은 문서에 맞는 길입니다. 여러 파일을 한꺼번에 변환하는 것은 우리 서버에서 합니다. 묶고, 싸고, 한 세트를 건네는 것은 서버가 잘하는 일이기 때문입니다. 파일은 올라가고, 인코딩되고, 싸여, 하나의 다운로드로 돌아오며, 그것은 약 2시간 안에 사라지고, 계정도 없고 오래 보관하지도 않습니다. 실제로 한 변환은 결코 기기를 떠나지 않고, 묶음은 멀리서 처리되지만 다운로드에 드는 짧은 창 동안만 보관됩니다.