WebP JPG 변환: 언제, 왜 바꿔야 할까

Google은 2010년 웹에서 JPG를 대신할 더 작은 형식으로 WebP를 내놓았지만, Safari가 표시하지 못한 탓에 10년 동안 틈새 형식에 머물렀습니다. 상황이 바뀐 것은 2020년 Apple이 Safari 14와 macOS Big Sur에 WebP 지원을 넣으면서입니다. 주요 브라우저가 모두 WebP를 표시할 수 있게 되자 대규모로 이미지를 제공하는 기업들이 WebP로 갈아탔고, 그 전환은 서버 쪽에서 이뤄졌습니다. 그래서 사용자는 그 결정을 볼 일이 없고, 페이지 어디에도 지금 보는 이미지가 어떤 형식인지 나와 있지 않습니다.

예를 들어 Shopify의 이미지 CDN은 상품 사진을 JPG로 올렸더라도 WebP를 표시할 수 있다고 알리는 브라우저에는 WebP를 보냅니다. Google 이미지 검색도 미리보기를 WebP로 보여 줍니다. WordPress는 2021년 5.8 버전부터 WebP 업로드를 받았습니다. JPG 업로드를 기본적으로 WebP로 변환하려던 계획은 6.1 버전 출시 전에 철회되었지만, WordPress 성능 팀의 Modern Image Formats 플러그인과 많은 호스팅 업체의 이미지 최적화 기능이 정확히 그 일을 합니다. 결과는 어디서나 같습니다. 사이트 운영자의 컴퓨터에서는 JPG였던 파일이 내 컴퓨터에 도착할 때는 WebP가 되어 있습니다.

브라우저도 이 과정에 기꺼이 참여합니다. Chrome, Edge, Firefox가 이미지를 요청할 때마다 보내는 Accept 헤더에는 image/webp(그리고 image/avif)가 들어 있고, 형식 협상을 지원하는 서버는 이 목록을 읽어 내가 표시할 수 있는 가장 작은 형식을 고릅니다. 마우스 오른쪽 버튼을 눌러 다른 이름으로 이미지 저장을 고르면 브라우저는 이미 받아 둔 바이트를 그대로 저장합니다. 그래서 주소 표시줄에서는 파일 이름이 .jpg로 끝나는데 디스크에는 WebP로 저장되고, 때로는 .jpg.webp처럼 확장자가 두 개 붙기도 합니다.

브라우저는 이미 몇 년 전에 문제가 아니게 되었습니다. 문제는 그 밖의 모든 곳에 있습니다. 2022년 이전에 설치한 데스크톱 소프트웨어, 허용 목록을 한 번 정해 놓고 다시 손대지 않은 업로드 양식, JPG와 TIFF를 기준으로 짜인 인쇄소 작업 흐름, 본문 이미지를 자체 디코더로 표시하는 이메일 클라이언트가 그렇습니다. 이들 중 어느 것도 친절하게 실패하지 않습니다. 인화 사이트는 그냥 파일을 거부하고, 관공서 양식은 형식이 잘못되었다고만 하며, 오래된 Photoshop은 WebP 이야기는 전혀 없이 "요청을 완료할 수 없습니다"라는 일반적인 메시지를 띄웁니다.

Adobe는 2022년 2월에 출시한 Photoshop 23.2 버전부터 WebP 열기와 저장을 기본 지원합니다. 그보다 오래된 버전은 서드파티 플러그인이 필요합니다. Lightroom Classic은 몇 년 동안 WebP를 가져오지 못했기 때문에, 오래된 버전의 카탈로그는 가져오기 과정에서 이런 파일을 조용히 건너뜁니다. Windows에서는 구형 Windows 사진 뷰어가 WebP를 아예 열지 못하고, Windows 10 사진 앱은 Microsoft Store의 WebP 이미지 확장 패키지가 있어야 합니다. 가장 엄격한 것은 업로드 양식입니다. 예를 들어 미국 국무부의 DS-160 비자 사진 업로드는 JPEG만 받고, 많은 대학 입학 지원·채용 포털은 JPG, PNG, PDF만 허용합니다.

WebP는 형식 하나가 두 가지 역할을 모두 한다는 점에서 특이합니다. 사진에는 손실 압축을, 그래픽에는 알파 채널을 갖춘 무손실 압축을 씁니다. WebP에서 다른 형식으로 바꿀 때는 이 파일이 둘 중 어느 역할을 하고 있었는지 골라야 합니다. JPG와 PNG는 각각 그중 하나만 잘 처리하기 때문입니다. 따져야 할 것은 어느 형식이 전반적으로 더 나은지가 아니라(그 비교는 JPG vs JPEG vs PNG에서 다룹니다), 바로 이 이미지에 무엇이 담겨 있고 다음에 어디로 가는지입니다.

상품 사진, 배경화면, 요리 사진, 여행 스냅은 JPG가 맞습니다. PNG의 몇 분의 일 용량으로 똑같아 보입니다. 로고, 아이콘, 스티커, 투명 배경 위의 누끼 상품 이미지, 글자가 가득한 스크린샷은 PNG가 맞습니다. JPG로 바꾸면 투명한 부분이 단색으로 채워지거나 글자의 날카로운 가장자리가 번지기 때문입니다. 판단이 서지 않으면 어두운 테마의 브라우저 탭에서 파일을 열어 보세요. 피사체 주변으로 체크무늬나 어두운 페이지가 비쳐 보인다면 투명도가 있는 이미지이므로 PNG가 필요합니다.

손실 WebP를 JPG로 변환하면 픽셀을 디코딩한 뒤 다른 방식으로 다시 인코딩하므로, 결과물이 비트 단위로 똑같지는 않습니다. 하지만 실제로 JPG 품질 85~90에서는 고해상도 화면이라도 원래 크기로 볼 때 알아챌 수 있는 수준보다 차이가 훨씬 작습니다. 내려받은 WebP에서 보이는 화질 손실은 그보다 앞서 웹사이트가 압축할 때 생긴 것이고, 변환으로 그 디테일을 되살릴 수는 없습니다. 변환은 그 위에 손실을 크게 더하지 않을 뿐입니다. 두 번, 세 번 변환하면 손실이 쌓이므로, 형식을 여러 번 거치지 말고 저장한 WebP에서 한 번만 변환하세요.

눈치챌 만한 변화는 세 가지입니다. 첫째, JPG가 덜 효율적인 형식이라 파일이 보통 3분의 1 이상 커집니다. 양식에 KB 상한이 있다면 먼저 변환한 다음 100 KB 이하로 압축하거나 한도에 맞춰 줄이세요. 둘째, 투명도가 사라집니다. WebP JPG 변환기의 투명 영역 설정은 기본적으로 그 픽셀을 흰색으로 채우며, 검은색이나 직접 지정한 색으로 바꿀 수 있습니다. 셋째, 애니메이션이 사라집니다. JPG는 프레임 하나만 담을 수 있어 첫 프레임만 남습니다.

바뀌지 않는 것도 그만큼 중요합니다. 픽셀 크기, 방향, 색상은 그대로이고, 색상 프로필 유지를 켜 두는 한 내장된 색상 프로필도 유지됩니다. 인화용으로 변환한다면 품질을 90 이상으로 올리세요. 현상소에서는 늘어난 용량이 아무 문제가 되지 않고, 하늘이나 피부의 부드러운 그러데이션에 대한 걱정도 사라집니다. KB 상한이 엄격한 업로드라면 사진은 80에서도 대개 깨끗하고, 90보다 한도 아래 여유가 더 많이 남습니다. 70 아래로 내려가면 글자와 가는 선 주변에 깍두기 같은 블록 노이즈가 생기기 시작합니다.

변환하기 전에 사이트가 원본 파일을 내주는지 확인해 볼 만합니다. 그러면 압축 한 단계를 통째로 건너뛸 수 있기 때문입니다. 통할지는 사이트가 WebP를 만드는 방식에 달려 있습니다. CDN이 그때그때 WebP를 만든다면 서버에는 여전히 JPG가 있으므로 요청만 제대로 하면 받을 수 있습니다. 일부 WordPress 설정처럼 업로드를 변환한 뒤 WebP만 보관한다면 받을 JPG가 남아 있지 않으니 변환하는 수밖에 없습니다.

아래 방법은 확실한 것부터 덜 확실한 것 순으로 정리했습니다. 특별한 것은 없고, 모두 평범한 브라우저 동작이거나 사이트가 이미 제공하는 다운로드 링크입니다. 온라인에서 가장 자주 추천되는 방법, 즉 이미지 주소 끝에 ?format=jpg를 붙이는 방법은 가장 믿을 수 없습니다. 이미지 CDN이 마침 정확히 그 이름의 매개변수를 읽을 때만 통하는데 대부분은 그렇지 않아서, 아무 오류 없이 같은 WebP를 돌려받게 되고 방법이 실패했다는 사실조차 알 수 없습니다.

상품 카탈로그, 참고 이미지 모음, 배경화면 폴더를 저장해 두었다면 파일을 하나씩 변환하는 일은 금세 지칩니다. 변환기는 한 번에 최대 20개, 파일당 최대 95 MB까지 받아 모든 파일에 같은 품질과 투명 영역 설정을 적용하고 ZIP 파일 하나로 돌려줍니다. 파일은 처리 30분 뒤 서버에서 삭제되며, 아무것도 설치할 필요가 없습니다. 이미지 100장이 든 폴더라면 다섯 번에 나눠 처리하면 됩니다.

시작하기 전에 폴더를 분류하세요. 사진은 JPG용 묶음에, 로고와 아이콘처럼 배경이 비치는 이미지는 WebP PNG 변환용 묶음에 넣어야 흰 상자가 둘러진 결과물이 생기지 않습니다. Mac에서는 미리보기의 내보내기 명령으로 파일을 하나씩 변환할 수 있고, 명령줄을 쓴다면 아주 큰 폴더에 ImageMagick의 mogrify -format jpg *.webp를 실행하면 됩니다. 어느 쪽이든 브라우저 변환기와 결과는 같고, 준비 작업을 얼마나 할지만 다릅니다.

Chrome, Edge, Firefox에는 "이미지를 JPG로 저장" 같은 설정이 없으며, 이는 실수로 빠뜨린 것이 아닙니다. 형식을 고르는 것은 브라우저가 아닙니다. 브라우저는 자신이 표시할 수 있는 형식을 알릴 뿐이고, 웹사이트가 그중 하나를 고릅니다. Chrome은 받은 그대로 재인코딩 없이 저장하는데, 이것이 올바른 동작입니다. 저장할 때 몰래 변환하면 요청하지도 않은 손실 단계가 추가되기 때문입니다. 같은 이유로 브라우저를 바꿔도 거의 소용이 없습니다. 현재 모든 브라우저가 Accept 헤더에 WebP를 넣기 때문에, 같은 사이트에서는 모두 같은 WebP를 받습니다.

그래서 현실적인 선택지는 세 가지입니다. 위의 방법으로 사이트에서 원본을 받을 수 있습니다. 저장할 때 이미지를 다시 인코딩하는 브라우저 확장 프로그램을 설치할 수도 있는데, 버튼만 다를 뿐 같은 변환입니다. 아니면 WebP로 저장해 두었다가 무언가가 거부할 때, 그때만 변환하면 됩니다. 대개는 세 번째가 가장 수고가 적습니다. 저장한 이미지의 상당수는 화면으로만 보게 되는데, WebP는 모든 브라우저, macOS Big Sur 이후의 미리보기, Windows 11 사진 앱에서 문제없이 열리기 때문입니다.

WebP가 요즘 사이트들이 제공하는 다른 최신 형식, 특히 같은 CDN에서 WebP를 대체하기 시작한 AVIF와 어떻게 다른지 궁금하다면 AVIF·HEIC·WebP 비교를 참고하세요. 이 글의 실용적인 조언은 거의 그대로 적용됩니다. 프로그램이 거부하는 AVIF도 같은 방법, 즉 사진은 JPG로, 그래픽은 PNG로 변환해 해결합니다. 형식 자체에 대한 자세한 내용은 Google의 WebP 프로젝트 페이지에 있습니다.