이미지를 압축해야 하는 이유 (업로드하기 전에)

방금 찍은 사진이 4~8MB로 저장됐습니다. 원본을 보관하기에는 괜찮은 크기입니다. 1,200만 화소 센서, HDR 처리, 거의 버리지 않은 JPEG. 그런데 그 사진으로 다음에 할 일에는, 이 크기가 거의 최악입니다.

블로그 대표 이미지, 상품 카드, 카카오톡 전송, 입사 지원 양식, 클라이언트에게 보내는 메일. 이런 곳은 대부분 100~400KB면 충분합니다. 남은 메가바이트는 화면에서 더 좋아 보이지 않습니다. 페이지만 느려지고, 전송이 실패하고, 데이터 요금이 아프고, 백업 비용이 커집니다. 원본과 목적지가 실제로 필요한 크기의 간극——그게 무엇이든 올리기 전에 이미지 압축이 중요한 이유입니다.

쓰이지 않는 메가바이트는 웹사이트가 전부 부담한다

웹에서 이미지는 보통 페이지에서 가장 무겁습니다. Largest Contentful Paint(LCP)——주된 화면이 실제로 나타날 때를 추적하는 Core Web Vital——는 많은 경우 「그 대표 이미지를 받는 데 몇 초 걸렸나」와 같습니다. 4G에서 3MB JPEG는 몇 초를 앉아 있을 수 있습니다. 같은 구도의 200KB WebP는 한순간에 나타납니다.

느린 LCP는 추상적인 점수가 아닙니다. 첫 화면이 멈추면 이탈률이 올라갑니다. 상품 사진이 계속 돌면 전환율이 떨어집니다. Google이 이 지표를 순위 신호로 쓰니 검색 순위도 맞습니다. 게시 전에 압축하는 것은 가장 값싼 속도 개선 중 하나입니다. 사이트를 다시 쓸 필요가 없고, 보내는 바이트만 줄어듭니다.

목적지가 페이지라면 할 일은 구체적입니다. 표시 너비로 줄이고, 최신 포맷을 고르고, 여전히 선명해 보이는 품질을 정합니다. 그 과정은웹사이트를 빠르게 만드는 이미지 용량 줄이기에 있습니다. 밑바닥의 「왜」는 단순합니다. 압축하지 않은 업로드는 방문자가 불러올 때마다, 영원히 내는 세금입니다.

이메일, 채팅, 업로드는 원본을 거절한다

일반 이메일의 첨부 한도는 여전히 메시지 전체 기준 대략 20–25MB입니다. 6MB짜리 휴대폰 사진 다섯 장이면 PDF를 더하기 전에 이미 넘습니다. 전송이 실패하거나, 상대가 이미지를 못 받거나, Gmail이 조용히 드라이브 링크로 바꿔 일부는 열지 못합니다. 먼저 압축하는 것이 「사진은 여기」와 용량 이야기로 이어지는 후속 스레드의 차이입니다.

채팅 앱은 다른 방식으로 더 엄격합니다. 카카오톡, iMessage, 대부분의 업무 메신저는 보낸 것을 다시 압축합니다. 흔히 아티팩트가 보이는 작은 JPEG로요. 당신이 안 했다고 가정하기 때문입니다. 품질 통제권을 잃고, 동시에 원본의 업로드 대역폭도 씁니다. 직접 250KB까지 줄인 파일은 두 번째 패스를 거쳐도 의도한 모습에 더 가깝게 남는 편입니다.

양식은 같은 문제의 수수한 버전입니다. 대학 포털, 비자 사이트, 보험 청구, 채용 게시판은 단단한 한도를 적습니다. 「JPG 또는 PNG, 최대 500KB.」 압축하지 않은 휴대폰 사진은 검증에 실패합니다. 사람들은 스크린샷을 찍고 미리보기에서 흐려질 때까지 줄이거나 포기합니다. 제대로 한 번 압축하면 한도 안에 들어가고, 증명사진이 뭉개지지도 않습니다.

같은 파일에는 일부러 내려야 할 선택도 있습니다.손실 압축과 무손실 압축. 사진은 손실 인코딩을 버팁니다. 스크린샷, 로고, 글자가 있는 문서는 종종 그렇지 않습니다. 압축은 슬라이더 하나가 아니라, 파일에 방법을 맞추는 일입니다.

모바일 데이터와 느린 연결이 기본값이지, 예외가 아니다

종량제 연결에서 5MB 이미지는 사소한 불편이 아닙니다. 하루 데이터 한도에서 눈에 띄는 한 입, 붐비는 지하철에서의 멈춤, 호텔 Wi-Fi의 타임아웃입니다. 비싼 모바일 요금제, 시골 광대역, 오래된 기기를 쓰는 사람은 틈새 시장이 아닙니다. 공개 사이트와 단체 채팅 모두에서 큰 비중입니다.

접근성도 같은 그림의 일부입니다. 이미지를 다 불러오지 못하는 페이지는 어떤 사람은 쓸 수 없는 페이지입니다. 압축이 대체 텍스트나 대비를 대신하지는 않습니다. 그래도 콘텐츠가 도착할지 직접 결정하는 몇 안 되는 성능 선택입니다. 5MB 대신 200KB를 보내는 것은 「휴대폰에서 된다」와 「도시에서 좋은 요금제의 휴대폰에서만 된다」의 차이입니다.

저장과 백업은 조용히 불어난다

압축하지 않은 사진 한 장은 성가십니다. 천 장이면 iCloud나 구글 포토 한도가 찹니다. 카메라 롤, 클라이언트 갤러리, 「원본은 남겨 두자」 폴더는 아무도 원본 해상도로 보지 않을 픽셀로 드라이브와 클라우드 할당량을 채웁니다. 백업은 그 메가바이트를 두 번, 세 번 복사합니다.

비용은 돈만이 아닙니다. 동기화가 더 오래 걸립니다. 공유 폴더가 멈춥니다. 웹용 파일 400장을 6MB JPEG로 넘기는 것은, 80MB면 될 세트에 2.4GB 다운로드를 요구하는 일입니다. 그 규모에서는 한 장씩 압축하는 것이 잘못된 도구입니다——ZIP으로 받아가는 일괄 압축이 갤러리를 비싸지 않고 쓸모 있게 유지하는 방법입니다.

압축하지 않은 이미지가 실제로 드는 비용

대략적이고 전형적인 숫자입니다. 실험실 벤치마크가 아니라, 대부분 「업로드」를 누르기 전에 하지 않는 산수입니다.

포맷 선택도 이 숫자를 바꿉니다. 사진의 PNG는 같은 장면의 JPEG보다 몇 배 큰 경우가 많고, WebP와 AVIF는 사진에서 보통 둘 다보다 작습니다. 페이지에 어떤 컨테이너를 둘지 모르겠다면, 잘못된 원본을 압축하기 전에JPG vs PNG vs WebP vs AVIF부터 보세요.

다음에 할 일

새 워크플로 강의는 필요 없습니다. 파일이 기기를 떠나기 전에 목적지에 맞으면 됩니다. 품질을 지키는 설정과 짧은 순서는품질을 지키며 압축하는 방법을 쓰세요. 실제 인코딩은 파일을이미지 압축 도구에 넣으면 됩니다. 브라우저에서 돌아가고, 아무것도 업로드되지 않으며, 보통 수백 킬로바이트면 충분합니다.