짧은 답
치수를 바꾸지 않고 이미지를 작게 만들려면 리사이즈가 아니라 압축으로 파일을 줄이세요. 압축은 같은 픽셀을 저장하는 방식을 바꾸고, 리사이즈는 픽셀 격자 자체를 바꿉니다.
이 구분은 폼이 이런 식으로 요구할 때 중요해집니다.
- 「이미지는 600 x 600 픽셀, 200KB 미만이어야 합니다.」
- 「2 x 2 인치 여권 사진 업로드, JPG만, 최대 240KB.」
- 「프로필 사진은 최소 1000 x 1000 픽셀, 최대 1MB.」
- 「이미지 치수를 바꾸지 마세요.」
이런 경우 너비와 높이도 요구 사항의 일부입니다. 리사이즈하면 KB 문제는 해결해도 치수 규칙을 어길 수 있으니, 먼저 압축 도구를 쓰세요.
파일 크기와 치수는 다른 것
이미지의 「크기」라는 말은 서로 다른 두 가지를 같은 단어로 부르기 때문에 헷갈립니다.
| 자주 하는 표현 | 실제 의미 | 예시 | 바꾸는 방법 |
|---|---|---|---|
| 파일 크기 | 디스크 상의 바이트 | 85KB, 240KB, 2.8MB | 압축, 메타데이터 제거, 형식 변경 |
| 픽셀 치수 | 너비와 높이 | 600 x 600 px, 1200 x 800 px | 리사이즈 또는 크롭 |
| 인쇄 크기 | 물리적 출력 크기 | 2 x 2 인치, 4 x 6 인치 | 픽셀과 DPI/PPI 메타데이터에 의존 |
2000 x 2000 이미지가 10MB가 될 수도 300KB가 될 수도 있습니다. 치수는 같고, 저장 방법이 다를 뿐입니다.
반대도 마찬가지입니다. 500 x 500 PNG 스크린샷이 비효율적으로 저장되거나 투명, 메타데이터가 포함돼 있으면 2000 x 2000 JPEG 사진보다 더 클 수도 있습니다.
리사이즈하지 말아야 할 때
지금 치수가 이미 맞다면 압축부터 하세요.
- 정부·학교 폼: 폼이 픽셀 치수와 파일 크기를 함께 검증할 수 있습니다.
- 여권·신분증 사진: 크롭이 이미 정확할 확률이 높고, 리사이즈하면 얼굴 크기나 머리 위치 요건을 깨뜨릴 수 있습니다.
- 프로필 사진: 플랫폼은 최소 픽셀 크기 이상의 정사각형 이미지를 요구할 때가 많습니다.
- 레이아웃에 맞춰 이미 치수를 정한 웹사이트 이미지: CSS 슬롯은 같은 종횡비와 픽셀 격자를 전제로 합니다.
- 문서화용 스크린샷: 치수를 바꾸면 UI 텍스트가 부드러워지거나 비교하기 어려워질 수 있습니다.
- 다른 시스템이 사용하는 이미지: 템플릿, 데이터베이스, 인쇄 워크플로, 배치 스크립트가 정확한 치수를 기대할 수 있습니다.
리사이즈는 목적지가 더 작은 치수를 허용하거나, 필요한 것보다 훨씬 많은 픽셀을 이미지가 갖고 있을 때만 하세요. web.dev의 이미지 안내는 두 관심사를 분리해서 다룹니다. 올바르게 치수를 맞춘 이미지는 불필요한 바이트를 줄이고, 압축은 남은 파일을 손봅니다.
압축이 바꾸는 것
치수가 그대로여도 파일 크기는 여전히 달라질 수 있습니다. 내보낸 파일이 다음 중 하나 이상에서 달라지기 때문입니다.
- 품질 단계: 손실 형식은 품질이 내려갈수록 시각적 디테일을 덜 저장합니다.
- 형식: WebP나 AVIF는 같은 픽셀 치수를 JPEG나 PNG보다 효율적으로 저장할 수 있습니다.
- 압축 모드: 무손실은 픽셀을 정확히 보존하고, 손실은 픽셀을 살짝 바꿔 더 많은 바이트를 절약합니다.
- 색 정보: 일부 인코더는 색 정밀도나 크로마 디테일을 줄입니다.
- 메타데이터: 카메라 모델, GPS, 미리보기 썸네일, DPI 태그, 편집 이력 등이 제거될 수 있습니다.
MDN의 캔버스 내보내기 문서는 브라우저 도구를 이해할 때 좋은 사고 모델입니다. 브라우저는 같은 캔버스 비트맵을 서로 다른 파일 형식과 품질 단계로 내보낼 수 있습니다. 캔버스가 1200 x 800 픽셀이면 내보낸 JPEG나 WebP도 1200 x 800을 유지하고, 바이트 크기만 달라집니다.
이미지 종류로 방법 고르기
| 원본 이미지 | 치수 유지? | 먼저 시도 | 피할 것 |
|---|---|---|---|
| 업로드 제한을 넘긴 JPG 사진 | 예 | JPEG 품질을 작은 폭으로 낮추기 | 같은 JPG를 반복해서 다시 저장하기 |
| 투명이 없는 PNG 사진 | 예 | 허용되면 JPG나 WebP로 변환 | 처음부터 PNG였다는 이유만으로 PNG 유지 |
| 텍스트가 있는 PNG 스크린샷 | 예 | PNG 최적화 또는 무손실 WebP | 낮은 품질의 JPEG |
| 투명 로고나 컷아웃 | 예 | 대상 지원에 따라 PNG 또는 WebP | 투명을 제거하는 JPEG |
| 이미 치수를 맞춘 웹사이트 히어로 | 예 | 폴백이 있는 WebP 또는 AVIF | 밴딩을 유발할 만큼 낮은 품질 |
| 이메일 첨부 | 대개 | 사진은 JPEG, 그래픽은 PNG | 수신자가 지원하지 않을 수 있는 WebP나 AVIF |
| 아카이브나 마스터 파일 | 예 | 원본은 유지하고, 필요하면 압축본을 추가 | 유일한 마스터를 손실 내보내기로 덮어쓰기 |
여기서 흔한 압축 글이 어긋납니다. 「WebP로 변환하라」는 여러분이 통제하는 웹사이트 이미지에는 좋은 조언이지만, 법원 서식, 학교 폼, 인쇄소, JPG나 PNG만 받는 이메일 첨부에는 잘못된 조언이 될 수 있습니다.
대개 잘 통하는 품질 설정
만능 품질 수치는 없습니다. web.dev는 시각적 품질과 파일 크기 사이의 최적 절충점을 찾을 때까지 여러 압축 단계를 시험해 보라고 권합니다. 아래 값은 출발점일 뿐 법칙이 아닙니다.
| 이미지 용도 | JPEG/WebP 시작값 | 확인할 부분 |
|---|---|---|
| 여권, 신분증, 프로필, 문서 사진 | 82-90 | 얼굴 디테일, 텍스트 라벨, 가장자리 선명도 |
| 상품 사진 | 80-88 | 원단, 라벨, 모서리, 색 편차 |
| 블로그·웹사이트 사진 | 75-85 | 피부, 하늘, 그림자, 그러데이션 |
| 썸네일이나 미리보기 | 65-78 | 작은 크기에서 피사체가 잘 보이는지 |
| 배경 이미지 | 55-72 | 밴딩과 눈에 띄는 블록 |
| 텍스트가 있는 스크린샷 | 먼저 무손실 PNG/WebP | 메뉴 텍스트, 아이콘, 얇은 선 |
AVIF는 도구마다 다른 스케일을 쓰는 경우가 많으므로 숫자를 JPEG나 WebP와 그대로 비교하지 마세요. 「품질 60」의 AVIF는 「품질 60」의 JPEG와 같지 않습니다.
가장 안전한 워크플로는 지루하지만 확실합니다. 내보내고, 비교하고, 조정하고, 반복하는 것입니다.
리사이즈 없이 형식 바꾸기
형식을 바꾸면 픽셀 치수를 유지한 채 파일 크기를 줄일 수 있습니다. 관건은 대상 시스템이 새 형식을 받아 주는지입니다.
JPEG → WebP: 웹 배포에 자주 유용합니다. Google WebP 문서는 자체 테스트 세트에서 평균적인 절감폭이 상당하다고 보고하고 있으며, WebP는 손실·무손실·투명·애니메이션을 모두 지원합니다. 그래도 브라우저는 지원하더라도 엄격한 업로드 폼은 WebP를 거부할 수 있습니다.
PNG 사진 → JPEG나 WebP: PNG가 카메라 사진이고 투명이 필요하지 않다면 큰 이득을 볼 수 있습니다. PNG는 무손실이라 미세한 카메라 노이즈까지 모두 보존합니다. JPEG나 WebP는 사진용 손실 압축으로 같은 치수를 더 적은 바이트에 담을 수 있습니다.
PNG 스크린샷 → JPEG: 대개 손해입니다. 파일은 작아질 수 있지만 텍스트와 뚜렷한 가장자리가 지저분해 보입니다. 먼저 PNG 최적화나 무손실 WebP를 시도하세요.
투명 PNG → JPEG: 배경을 채워 없애도 괜찮은 경우에만 하세요. JPEG는 투명 픽셀을 유지할 수 없습니다.
JPEG → JPEG(재인코딩): 됩니다. 하지만 가지고 있는 가장 나은 원본에서 시작하세요. 이미 압축된 JPEG를 여러 번 다시 압축하면 아티팩트가 쌓입니다.
PhotoTools에서 치수를 바꾸지 않고 압축하는 방법
너비와 높이를 반드시 유지해야 할 때의 흐름입니다.
- 리사이즈가 아니라 압축을 엽니다.
- 이미지를 드래그해서 놓습니다.
- 도구가 표시하는 입력 치수, 또는 OS의 파일 정보로 치수를 확인합니다.
- 같은 치수를 유지하고, 대상 시스템이 받는 출력 형식을 고릅니다.
- JPEG, WebP, AVIF의 품질 슬라이더를 조금씩 낮춥니다.
- 결과를 다운로드합니다.
- 업로드하기 전에 다운로드한 파일의 픽셀 너비와 높이를 다시 확인합니다.
- 개인 정보가 중요하다면 EXIF/GPS 메타데이터가 남아 있는지도 확인합니다.
PhotoTools는 압축 워크플로를 여러분의 브라우저에서 실행합니다. 이미지는 변환을 위해 서버로 업로드되는 것이 아니라, 도구 세션 중에 로컬에서 처리됩니다.
대상 시스템이 지금의 픽셀 치수를 요구한다면 리사이즈 도구는 사용하지 마세요. 리사이즈는 너비와 높이를 바꾸는 도구, 압축은 바이트를 바꾸는 도구입니다.
실제 업로드 문제로 본 예
| 문제 | 더 나은 선택 | 이유 |
|---|---|---|
| 600 x 600 JPG를 200KB 미만으로 | JPG 유지, 품질을 80대 후반에서 80대 초반으로 낮추기 | 치수와 허용 형식이 안전하게 유지됨 |
| 1200 x 1200 프로필 사진이 2MB, 제한 1MB | JPG 압축, 또는 허용되면 WebP로 변환 | 픽셀을 바꾸지 않고도 여유가 넉넉함 |
| 900KB PNG 스크린샷, 치수 유지 필요 | PNG 최적화 또는 무손실 WebP 시도 | 텍스트가 선명하게 유지됨 |
| 투명 상품 컷아웃이 너무 큼 | 허용되면 알파 지원 WebP 시도 | 웹의 많은 경우 더 적은 바이트로 투명을 유지 |
| 4000 px 폭 웹 이미지지만 800 px로 표시 | 허용되면 먼저 리사이즈 후 압축 | 4000 px 유지는 바이트 낭비 |
| 폼이 정확히 413 x 531 px JPG, 최대 300KB를 요구 | 리사이즈 없이 JPG로만 압축 | 검증기가 어떤 치수 변경도 거부할 수 있음 |
어려운 경우는 대개 엄격한 폼입니다. 폼이 정확한 픽셀 값과 파일 크기 상한을 명시했다면, 일반적인 이미지 조언보다 그 요구 사항을 우선하세요.
리사이즈까지 필요한 때
「리사이즈하지 않는다」가 오히려 잘못된 제약일 때가 있습니다. 이미지가 필요한 것보다 훨씬 많은 픽셀을 갖고 있으면, 압축만으로는 보기 흉한 품질 설정으로 밀려나기도 합니다.
4000 픽셀 폭 사진을 매우 낮은 JPEG 품질로 짓눌러도 여전히 무겁고 결과도 더 나빠집니다. 대상 시스템이 이미지를 1000 px 폭으로만 표시하고 그 크기를 허용한다면, 먼저 리사이즈한 뒤 적당히 압축하는 편이 낫습니다. 대개 불필요한 픽셀을 붙들고 디테일을 망가뜨리는 것보다 결과가 좋습니다.
규칙:
- 치수가 필수면 압축 먼저.
- 치수가 필요보다 클 뿐이면 리사이즈 먼저.
- 확신이 없다면 치수를 바꾸기 전에 업로드 안내를 확인.
문제 해결
이미지가 여전히 너무 큼
더 효율적인 허용 형식을 시도하고, 품질을 조금 더 낮추고, 메타데이터를 제거하거나, 이미 내보냈던 사본이 아니라 원본 파일에서 다시 시작하세요. 그래도 제한을 크게 초과하고 대상 시스템이 더 작은 치수를 허용한다면 먼저 리사이즈합니다.
업로드 폼이 파일을 거부
허용된 파일 형식을 확인하세요. JPG와 PNG만 받는 폼이 많습니다. WebP 파일은 치수와 파일 크기가 맞아도 폼이 WebP를 허용 형식으로 나열하지 않으면 여전히 실패할 수 있습니다.
이미지가 흐려 보임
치수는 그대로일 수 있지만, 압축 품질이 너무 낮거나 형식이 잘못 선택되었을 수 있습니다. 품질을 더 높여 보세요. 스크린샷, 다이어그램, 텍스트에는 낮은 품질의 JPEG 대신 PNG나 무손실 WebP를 사용하세요.
투명 배경이 흰색이나 검정으로 바뀜
이미지가 JPEG로 변환된 것으로 보입니다. JPEG에는 투명이 없습니다. 대상 시스템이 투명을 지원한다면 PNG, WebP, AVIF로 내보내세요.
치수가 결국 바뀌었음
픽셀 격자를 바꾸는 리사이즈, 크롭, 내보내기 프리셋을 사용했을 가능성이 큽니다. 원본을 다시 열어 압축만 사용하세요. 파일을 제출하기 전에 출력 치수를 확인하세요.
품질을 지키는 마지막 규칙
원본을 남겨 두세요. 가장 좋은 원본에서 다시 내보낼 수 있을 때 압축은 가장 안전합니다.
압축한 이미지를 반복해서 내려받아 다시 압축하고, 또 다른 손실 형식으로 변환한 뒤 또 압축하면 아티팩트가 쌓입니다. 한 번의 업로드라면 감수할 수 있지만, 상품 사진, 신분증 사진, 반복 사용하는 웹사이트 자산은 깨끗한 마스터를 보관하고 거기서 배포용 사본을 만드세요.