좋은 결과 뒤에 있는 기술, 형식 및 작은 결정에 대한 팀의 메모.
WebP가 데스크톱 앱에서 보편적으로 지원되지 않는 이유
Google은 2010년에 WebP를 내놓았지만 데스크톱 소프트웨어의 채택은 브라우저 지원에 한참 뒤처졌습니다. 브라우저는 자기 렌더링 엔진을 직접 다루고 Google이 Chrome의 WebP 지원을 경쟁 우위로 적극 다듬었기 때문에 일찍 WebP를 받아들였습니다. 데스크톱 앱은 새 이미지 형식을 채택하는 데 더 오래 걸립니다. 각 앱이 자체 디코딩 구조를 유지하고, 새 형식을 지원하려면 길게 이어지는 예외 사례들에 대해 검증해야 하기 때문입니다. 대다수 전문 사진가와 디자이너가 쓰는 Adobe Photoshop은 2022년 말 버전 23.2에 와서야 WebP를 기본 지원했습니다. Microsoft Office 앱은 2026년인 지금도 플랫폼에 따라 WebP를 일관되지 않게 다룹니다. 인쇄용 RIP 소프트웨어와 대부분의 오래된 보관 도구는 WebP를 아예 채택하지 않았습니다. 실질적인 결과로, 브라우저에서는 완벽하게 보이는 파일이 사용자가 필요로 하는 소프트웨어에서는 통째로 거부될 수 있으며, PNG로 변환하는 것이 믿을 만한 우회책입니다.
WebP가 PNG보다 높은 압축 효율을 얻는 원리
PNG는 1996년의 범용 무손실 알고리즘인 DEFLATE 압축을 씁니다. 압축 전에 가로줄마다 되돌릴 수 있는 필터를 한 차례 적용하고 그 결과를 zlib 스트림으로 부호화합니다. 효과적이지만 기계 학습과 영상 코덱 연구가 더 나은 기법을 내놓기 전에 설계되었습니다. WebP의 손실 모드는 VP8 영상 압축에서 나온 블록 단위 변환을 써서, 프레임 내 예측과 이산 코사인 변환을 16x16 매크로블록 단위에 적용합니다. WebP의 무손실 모드는 공간 예측, 색 변환, 그리고 전형적인 이미지 내용에 대해 DEFLATE보다 구조적으로 더 효율적인 LZ77 부호화 단계를 씁니다. Google이 공개한 벤치마크는 무손실 WebP가 표준 시험 이미지 모음에서 PNG보다 약 26퍼센트 작고, 알파가 있는 손실 WebP가 비슷한 화질에서 PNG의 약 3분의 1 크기임을 보여 줍니다. PNG에서 WebP로 가는 방향은 이 이득을 취하고, WebP에서 PNG로 가는 방향은 그것을 되돌리므로 출력이 커집니다.
파일 크기 증가를 측정한 예
Chrome 148, Linux 데스크톱에서, 디코딩한 WebP 입력에 시스템의 PNG 저장 경로를 적용해 측정했습니다. 400x300 픽셀의 작은 벡터풍 그래픽을 품질 80의 WebP로 저장한 것은 약 15에서 25밀리초 만에 디코딩되어 PNG로 다시 쓰이며, 크기는 보통 20에서 30퍼센트 늘어납니다. 1024x768의 사진풍 WebP, 약 작은 크기는 100밀리초 안에 디코딩되어 PNG로 다시 쓰이며 보통 3배에서 5배 늘어납니다. 3840x2160의 큰 사진풍 WebP, 약 큰 크기는 약 1.2초 만에 PNG로 쓰이며 장면 복잡도에 따라 5배에서 10배 늘어납니다. 실질적인 상한은 대략 대용량짜리 WebP 사진이 수배 큰짜리 PNG가 되는 지점입니다. 이 수치들은 두 형식의 압축 효율 차이를 반영하며 픽셀 수에 비례해 늘어납니다.
왕복 과정에서의 알파 투명도
WebP와 PNG의 8비트 알파 채널은 같은 값 범위를 쓰며, 0은 완전히 투명하고 255는 완전히 불투명합니다. 브라우저가 알파를 가진 WebP를 디코딩하면, A 성분이 원래 알파 데이터를 반영하는 RGBA 값의 픽셀 버퍼를 만듭니다. 그 버퍼를 PNG로 다시 쓸 때, PNG 저장 쪽은 A 값을 PNG의 알파 채널에 그대로 씁니다. 합성 단계는 일어나지 않고, 배경색이 입혀지지도 않으며, 미리 곱하는 부작용이 픽셀 값을 바꾸지도 않습니다. 결과는 알파 채널의 무손실 전달이며, PNG의 각 픽셀 불투명도 값은 WebP가 저장했던 것과 일치합니다. 가장자리에 섬세한 안티에일리어싱이 있는 이미지에서도, 글자 가장자리에서 불투명도 40퍼센트인 픽셀 같은 중간 알파 값이 모두 왕복을 온전히 견딥니다. 이 충실함이, 받는 앱이 이미지를 여러 배경 위에 보여 줘야 할 때 JPG가 아니라 PNG를 올바른 선택으로 만드는 것입니다.
EXIF와 메타데이터의 동작
다시 쓰는 처리는 출력되는 PNG에서 EXIF, IPTC, XMP 메타데이터를 제거합니다. WebP 파일은 메타데이터 청크에 EXIF를 담을 수 있는데, 브라우저가 이미지를 디코딩하고 다시 쓰면 그 데이터는 사라집니다. ICC 색 프로파일은 다른 경로를 따릅니다. Chrome과 Safari는 WebP를 디코딩한 뒤 출력 PNG에 sRGB ICC 프로파일 태그를 유지하지만, Firefox는 ICC 프로파일을 포함한 모든 메타데이터를 제거합니다. 실질적인 결과는 모든 브라우저에서 sRGB로 안전한 출력이지만, 원본 WebP에 담긴 넓은 색역 프로파일은 Firefox에서는 살아남지 못합니다. ICC 태그가 붙은 왕복에 의존하는 전문 사진 작업 흐름이라면 메타데이터를 의식하는 변환 도구를 쓰세요. 일반적인 웹 이미지 처리에서는 메타데이터 제거가 대개 받아들일 만하고 출력 파일 크기를 조금 줄이는 작은 이점도 있습니다.
실제로 개인정보 보호 확인하기
파일 데이터가 브라우저를 떠나지 않는다는 주장은 특별한 도구 없이도 확인할 수 있습니다. 브라우저를 열고 webp-to-png 페이지로 이동한 뒤, F12나 오른쪽 클릭 메뉴로 개발자 도구를 엽니다. 네트워크 탭으로 전환하고 기존 요청을 지운 다음, WebP 파일을 끌어다 놓아 변환을 실행합니다. 요청 목록을 Fetch, XHR, 또는 전체로 거릅니다. 저장하는 동안 이미지 데이터를 담은 나가는 요청은 목록에 하나도 없습니다. 나타나는 유일한 네트워크 요청은 초기 페이지 로딩 자산과 일반적인 분석용 ping뿐이며, 이는 페이지 조회수와 Core Web Vitals 성능 데이터만 기록하고 이미지 내용은 담지 않습니다. 주요한 원격 WebP를 PNG로 변환하는 도구는 변환마다 적어도 업로드 POST 하나와 다운로드 GET 하나를 발생시키며, 둘 다 서버에 기록됩니다. 기기 안에서 처리하는 구조에서는 그런 기록이 애초에 만들어지지 않으며, 이것이 민감한 내용을 담은 파일을 변환하는 사용자에게 의미 있는 차이입니다.