이미지 용량 줄이기 — 화질 안 깨뜨리고 업로드 제한 통과하는 순서
수정 6분 분량
“첨부 파일 최대 2MB.” 내 사진은 8.4MB. 손댈 수 있는 손잡이는 세 개인데, 그 순서를 지키는지가 깔끔한 결과와 얼룩덜룩한 결과를 가릅니다.
이 순서가 정답입니다
1. 크기(픽셀). 2. 형식. 3. 품질. 언제나 이 순서로.
이유는 간단합니다. 파일 용량은 픽셀 개수에 비례하고, 픽셀 개수는 가로·세로의 곱이기 때문입니다. 가로와 세로를 각각 절반으로 줄이면 픽셀의 75%가 사라집니다. 품질 슬라이더로는 절대 따라올 수 없는 감소폭이고, 어차피 작게 볼 이미지를 작게 만드는 것이므로 눈에 보이는 손실도 없습니다.
같은 1200만 화소 휴대폰 사진(4032 × 3024, 8.4MB HEIC)에 손잡이를 하나씩만 써본 결과입니다.
| 무엇을 바꿨나 | 결과 |
|---|---|
| 아무것도 안 함 — JPEG 품질 95 | 약 4.9MB |
| 품질만 — JPEG 80 | 약 1.6MB |
| 크기만 — 폭 1600px, 품질 95 | 약 1.1MB |
| 크기 + 형식 + 품질 — 1600px, WebP 80 | 약 180KB |
사진 내용에 따라 수치는 달라집니다. 나뭇잎이 가득한 사진은 단색 벽 앞 인물 사진보다 훨씬 압축이 안 됩니다. 하지만 순위는 바뀌지 않습니다. 무거운 일은 리사이즈가 합니다.
1단계: 크기를 얼마까지 줄일 수 있나
이 이미지가 실제로 어디에 쓰이는지 먼저 물어보세요.
- 양식 업로드, 증명사진, 문서 스캔: 양식이 요구하는 크기 그대로, 그 이상은 불필요합니다. 600 × 800을 요구하는데 4000px을 보내면 반려 위험만 커집니다.
- 웹페이지나 메일 본문: 긴 변 1600px이면 충분합니다. 글 안의 이미지가 800px보다 넓게 보이는 일은 드물어서 1600px이면 고밀도 화면까지 커버됩니다.
- SNS 게시물: 사이즈 가이드의 비율표 기준. 1080px이 표준 하한선입니다.
- 인쇄: 인치 × 300. 줄이면 안 되는 유일한 경우입니다.
- 내 사진 보관: 아예 리사이즈하지 마세요. 원본은 그대로 두고 공유용 사본만 줄입니다.
2단계: 내용에 맞는 형식 고르기
사진과 스크린샷은 압축에서 완전히 다르게 움직입니다.
- 사진 — 계조가 연속적이고 딱 떨어지는 경계가 없습니다. 호환성이 최우선이면 JPEG, 같은 체감 품질에서 25~35% 줄이려면 WebP, 더 줄이려면 AVIF.
- 스크린샷·도표·글자나 단색 면이 있는 이미지 — PNG나 무손실 WebP를 쓰세요. 손실 압축을 걸면 글자마다 지저분한 테두리가 생기는데, 원래 색 수가 적어서 절감 효과도 크지 않습니다. 무손실 WebP는 같은 내용의 PNG보다 보통 20~30% 작습니다.
- 투명도가 필요한 이미지 — PNG, 또는 알파 채널을 지원하는 WebP/AVIF. JPEG는 투명도를 지원하지 않아 투명한 부분이 검게 채워집니다.
3단계: 이제서야 품질을 건드립니다
JPEG는 품질 80~85가 거의 모든 사진의 최적 구간입니다. 70 아래로 내려가면 하늘이나 그라데이션에 사각형 자국이 보이기 시작합니다. 90 위로는 용량만 빠르게 늘고, 블라인드 테스트에서 차이를 알아보는 사람은 거의 없습니다.
WebP도 75~85에서 비슷하게 동작합니다. AVIF의 숫자는 비교 대상이 아닙니다. AVIF “50”이 JPEG “80” 정도에 해당하는 경우가 많아서, AVIF 파일이 예상보다 크게 나왔다면 숫자를 너무 높게 잡았을 가능성이 큽니다.
실전에서는 슬라이더를 움직이면서 예상 용량을 보고, 제한에 들어오는 첫 값에서 멈추면 됩니다. 40에서 시작해 올려가지 마세요.
제한별 공략
2MB 양식: 양식이 요구하는 크기로 줄이고 JPEG 85로 내보냅니다. 그래도 넘친다면 거의 확실히 아직 픽셀 크기가 큰 상태입니다. 품질을 더 깎기 전에 크기를 다시 확인하세요.
지메일 25MB: 제한이 메일 전체에 걸리므로 일괄 처리 문제입니다. 사진 20장을 1600px·품질 82로 줄이면 대략 8~10MB라 문제없이 전송됩니다. 손대지 않은 원본 20장은 안 됩니다. 전체를 한 번에 줄여서 사본을 첨부하세요.
신경 쓰는 웹페이지: 솔직한 목표는 콘텐츠 이미지 하나당 200KB 이하, WebP나 AVIF, 표시 폭의 2배 크기까지. 페이지가 느리게 느껴진다면 이미지를 가장 먼저 보세요. 보통 페이지의 모든 코드를 합친 것보다 무겁습니다.
메신저: 카카오톡·왓츠앱·라인은 일반 대화로 보낸 이미지를 다시 압축합니다. 때로는 아주 강하게. 미리 줄여서 보내면 압축할 여지 자체가 줄어듭니다. 원본을 그대로 전달해야 한다면 사진이 아니라 파일(문서)로 전송하세요.
하지 말아야 할 것
JPEG를 반복 저장하지 마세요. JPEG 저장은 매번 새로운 손실 압축입니다. 열고 → 줄이고 → 저장 → 다시 열고 → 자르고 → 저장하면 두 번 압축된 것이고, 첫 압축의 자국을 두 번째 압축이 실제 디테일로 착각해 붙잡습니다. 이게 단톡방을 돌아다닌 사진이 복사기로 복사한 것처럼 보이는 이유, 즉 세대 손실입니다. 항상 원본에서 시작해 한 번에 모든 편집을 적용하고 한 번만 내보내세요.
“화질 개선”을 위해 확대하지 마세요. 센서가 기록하지 않은 디테일은 만들어지지 않습니다. 용량만 커지고 뿌연 정도만 더 잘 보입니다.
확장자만 믿지 마세요. 휴대폰에서 나온 .png 스크린샷이 수 MB인 경우가 흔합니다. 같은 내용을 무손실 WebP로 바꾸면 눈에 보이는 변화 없이 몇 분의 일이 됩니다. 형식 변환이 어떤 슬라이더보다 큰 성과일 때가 많습니다.
폴더 단위로 처리하기
위 과정은 파일 1개든 200개든 똑같습니다. 그게 일괄 처리 도구를 쓰는 이유 전부입니다. 긴 변을 정하고, 형식과 품질을 한 번 고르고, 예상 합계를 확인하고, ZIP으로 내보내면 됩니다. 모든 처리가 내 기기에서 돌기 때문에 사진 300장 작업의 제약은 업로드 대기열이 아니라 내 CPU이고, 그 과정에서 파일이 기기를 벗어나지도 않습니다.