PNG를 WebP로 바꾸는 이유 (그리고 절대 안 바꾸는 한 가지 경우)
Dov Azencot
@DovAzencot책상에 to-shrink라는 폴더가 하나 있습니다. 오랫동안 스크린샷이 죽으러 가는 곳이었습니다. 대시보드와 미완성 시안이 담긴 2MB짜리 PNG를, 제 화면 2MB가 전혀 필요 없는 사람들에게 메일로 보내곤 했습니다. 어느 오후 그 폴더를 정말 열어 계산해 봤더니, 같은 주에 프로덕션에 올린 앱보다 더 컸습니다. PNG의 조용한 문제가 바로 이것입니다. 훌륭한 형식이면서도 놀랄 만큼 많은 공간을 낭비하는데, 대역폭은 싸고 파일은 「잘 열리니」 우리 대부분은 눈치채지 못합니다.
그래서 훨씬 일찍 누군가 제게 해 줬으면 싶었던 이야기를 해 보겠습니다. PNG가 웹사이트로 향한다면, 즉 편집이 아니라 보이는 곳으로 간다면, 거의 틀림없이 WebP여야 합니다.
PNG가 정말 잘하는 것
PNG는 무손실입니다. 넣은 픽셀이 언제나 정확히 그대로 나옵니다. 그리고 이것은 원본 파일에게는 진짜 미덕입니다. 디자인 도구가 PNG로 내보내고, 스크린샷이 PNG이며, 또렷한 가장자리와 투명함이 필요할 때 PNG를 찾는 이유입니다. 무손실이라는 것은 백 번을 열고 고치고 다시 저장해도 아무것도 열화되지 않는다는 뜻입니다.
문제는 「모든 픽셀을 완벽하게 저장한다」는 약속의 값을 바이트로 치른다는 점입니다. 사진을 PNG로 저장하면 그러데이션, 센서 잡음, 눈으로는 대충 근사해도 결코 알아채지 못할 미묘한 색 변화까지 정직하게 기록합니다. 아무도 못 보는 디테일에 정가를 다 내는 셈입니다.
WebP가 하고 PNG는 못 하는 것
WebP는 단순한 질문에 대한 구글의 답이었습니다. 그냥 더 나은 형식을 만들면 어떨까? WebP는 PNG가 못 하는 두 가지를 합니다. 원할 때 손실 압축을 할 수 있고(JPEG처럼 눈에 안 띄는 것을 버리되 더 영리하게), 그러면서도 완전한 알파 채널을 지킵니다. 이 두 번째가 조용한 기적입니다. 오랫동안 거래는 「투명함 아니면 작은 파일, 하나만 고르기」였습니다. WebP는 둘을 한꺼번에 줍니다.
실제로 사진이나 스크린샷 위주의 PNG를 적당한 품질로 변환하면 대략 60%에서 90% 사이로 작아집니다. 10%가 아닙니다. 1.8MB 스크린샷이 약 250KB가 되고, 나란히 놓아도 어느 것이 어느 것인지 구분할 수 없습니다. 인정하고 싶은 것보다 더 자주 이 시험을 스스로 해 봤습니다. 이번엔 WebP의 허점을 잡겠거니 확신하면서요. 한 번도 못 잡았습니다.
저를 믿게 만든 비교
지난달에 변환한 묶음에서 뽑은 대략적인 수치입니다.
| 원본 PNG | WebP로 |
|---|---|
| UI 스크린샷 — 1.8 MB | ~240 KB |
| 헤더용 사진 — 3.1 MB | ~380 KB |
| 평평한 2색 로고 — 42 KB | ~30 KB |
로고를 보세요. 거의 움직이지 않았습니다. 그리고 바로 그 각주가 가장 중요합니다.
변환을 굳이 안 하는 때
단순한 그래픽, 즉 평평한 색 몇 가지에 또렷한 가장자리는 PNG가 압축하도록 만들어진 바로 그것이고, PNG는 그 일을 어느 것 못지않게 해냅니다. 2색 아이콘, 선으로 된 도표, QR 코드는 PNG로 두거나, 벡터가 있다면 SVG로 내보내는 편이 더 낫습니다. WebP가 그런 파일을 해치지는 않지만 딱히 돕지도 않고, 공연히 단계만 하나 늘립니다.
변환하지 않는 또 다른 때는 원본입니다. 무언가의 유일한 사본은 절대 건드리지 않습니다. WebP의 손실 모드는 한 방향 문입니다. 버린 디테일은 되돌아오지 않습니다. 그래서 절대 어기지 않는 한 가지 규칙은 이것입니다. 게시하는 사본을 변환하고, 원본은 편집하는 곳에 두세요. 제 컴퓨터에서는 말 그대로 파일 두 개입니다. PNG는 프로젝트 폴더에 남고 WebP는 사이트로 갑니다. 값싼 보험이고, 한 번도 후회한 적 없습니다.
「그런데 정말 어디서나 되나요?」
예전엔 진짜 반론이었지만 이제는 아닙니다. 사람들이 실제로 쓰는 모든 브라우저가 2020년쯤부터 WebP를 지원합니다. Chrome, Safari, Firefox, Edge 전부요. 메일 클라이언트는 여전히 들쭉날쭉하고 오래된 기업용 소프트웨어는 이상하게 굴 때가 있어, 뉴스레터라면 아직 JPEG를 씁니다. 하지만 열린 웹이라면? 예비 없이 WebP를 내보내는 것이 용감한 선택이던 시절은 몇 년 전에 끝났습니다.
제가 실제로 하는 방법
솔직히 이 사이트의 PNG를 WebP로 변환하는 도구를 만든 이유는, 스크린샷을 아무 온라인 도구에나 끌어다 넣어 줄이면서 정작 내 파일이 어디로 가는지 알 수 없는 게 지겨웠기 때문입니다. 그래서 제가 권하는 방식은 지루하고 비공개인 쪽입니다. 파일이 기기를 절대 벗어나지 않는 브라우저 안에서, 자기 컴퓨터로 변환하세요. PNG를 넣고, 용량 열이 떨어지는 것을 보고, WebP를 내려받으세요.
하지만 핵심은 도구가 아닙니다. 핵심은 습관입니다. 「편집은 PNG, 게시는 WebP」가 몸에 배면, 2MB 스크린샷을 남에게 보내는 일이 사라지고, 페이지는 공짜로 빨라지며, 책상의 그 to-shrink 폴더가 마침내 비어 있게 됩니다. 제 것은 이제 한 1년째 비어 있습니다. 작은 승리지만, 기꺼이 받아들이겠습니다.
관련 글
스크린샷이 2MB인 이유, 그리고 60~90% 줄이는 법
거의 빈 대시보드 스크린샷이 2MB일 이유는 없습니다. PNG가 왜 그렇게 만드는지, 그리고 WebP로 바꾸면 보이는 손실 없이 60~90%가 어떻게 깎이는지 이야기합니다.
AVIF vs WebP - 더 작은 파일이 늘 정답은 아닙니다
AVIF는 대개 WebP보다 용량이 작고, 때로는 20% 넘게 작습니다. 그 추가 압축이 인코딩 시간과 예외 상황에서 무엇을 대가로 치르는지, 그리고 저는 언제도 여전히 WebP를 꺼내는지 짚어 봅니다.
PNG일까 JPG일까? 제가 십 년째 쓰는 판단 규칙
무손실이냐 손실이냐, 가장자리냐 사진이냐, 투명함이냐 아니냐. 파일이 어떤 형식이어야 하는지는 단 하나의 질문으로 갈립니다. 실제 용량 표로 증명해 보입니다.
전체 글