실전 답
웹 이미지를 품질을 망치지 않고 압축하려면, 품질 슬라이더를 “참을 만한” 가장 낮은 값까지 끌어내리는 것부터 시작하지 마세요. 출발점은 그 이미지가 페이지에서 하는 실제 역할입니다. 히어로, 확대해서 보는 상품 사진, 블로그 삽화, 아바타, 스크린샷, 배경 텍스처는 각각 다른 치수·포맷·품질 설정을 원합니다.
쓸모 있는 규칙은 이렇습니다. 실제로 표시되는 최대 크기로 먼저 리사이즈하고, 그다음에 레이아웃에서 원본과 구분되지 않는 선까지만 압축한다. 블로그 이미지가 CSS 너비 760px로 표시된다면, 고밀도 화면을 위해서는 소스가 1500~1600px면 대체로 충분합니다. 5000px짜리 카메라 원본은 낭비입니다. 그렇다고 760px로 그대로 내보내면 레티나 디스플레이에서 무르게 보일 수 있습니다. 적절한 파일은 그 사이에 있습니다.
“품질 손실 없이”라는 말도 실용적인 정의가 필요합니다. 웹 작업에서는 보통 방문자가 실제로 보는 크기에서 눈에 띄는 저하가 없다는 뜻이지, 픽셀 단위의 수학적 완전 일치가 아닙니다. 압축된 WebP는 원본과 동일하지는 않지만, 페이지 안에서는 사실상 구분되지 않게 만들 수 있습니다.
어떤 성격의 웹 이미지인지 먼저 정한다
WebP·AVIF·JPEG·PNG나 품질값을 고르기 전에, 먼저 그 자산을 분류하세요.
| 이미지 역할 | 일반 표시 크기 | 시작하기 좋은 포맷 | 시작 품질 | 자세히 봐야 할 부분 |
|---|---|---|---|---|
| LCP 히어로 이미지 | 너비 1200~2400px | AVIF + WebP/JPEG 폴백 | AVIF 45 |
하늘, 피부, 그림자, 브랜드 컬러 |
| 블로그·본문 이미지 | 소스 너비 1200~1600px | WebP, JPEG 폴백 | WebP 78~85 | 미세한 디테일과 그러데이션 |
| 상품 그리드 썸네일 | 소스 너비 500~900px | WebP | WebP 70~78 | 라벨, 엣지, 텍스처 |
| 상품 상세 이미지 | 소스 너비 1200~2000px | WebP 또는 AVIF | WebP 82 |
확대 시 디테일과 색 정확도 |
| UI 스크린샷 | 실제 표시 크기 또는 2x | PNG 또는 무손실 WebP | 텍스트가 중요할 땐 무손실 | 텍스트, 아이콘, 뚜렷한 엣지 |
| 로고나 아이콘 | 가능하면 벡터 | SVG | 해당 없음 | 매끄러운 확대 |
| 배경 텍스처 | 표시 크기만 | WebP 또는 JPEG | 60~75 | 밴딩, 이음매 |
이 표는 일부러 의견을 드러냈습니다. 웹 이미지 압축이 잘 안 되는 상당수는 모든 자산을 똑같이 다루는 데서 옵니다. 홈 페이지의 히어로는 Largest Contentful Paint에 영향을 줍니다. 상품 상세 이미지는 신뢰와 전환에 영향을 줍니다. 장식적인 배경은 아무도 뜯어보지 않기 때문에 훨씬 더 가볍게 두어도 됩니다.
리사이즈가 먼저: 치수가 대부분의 일을 한다
압축은 정해진 픽셀 격자를 저장하는 데 쓰는 바이트 수를 줄입니다. 리사이즈는 픽셀 격자 자체를 바꿉니다. 소스가 페이지가 보여줄 수 있는 것보다 훨씬 많은 픽셀을 가지고 있다면, 리사이즈가 가장 깔끔한 승리입니다.
간단한 크기 공식:
목표 소스 너비 = 최대 CSS 표시 너비 × 기기 픽셀 비율
예시:
- 320 CSS px로 표시되는 카드 이미지는 2x 화면용으로 640px 소스가 필요합니다.
- 760 CSS px로 표시되는 블로그 이미지는 1500~1600px 소스가 필요합니다.
- 1200 CSS px에 가까운 전체 너비 히어로는 크롭과 사용자 기기에 따라 2000~2400px 소스가 필요할 수 있습니다.
모든 이미지에 기계적으로 3x를 쓰지는 마세요. web.dev는 DPR과 레이아웃이 함께 작용하며, 아주 높은 DPR 소스의 이점을 사용자가 체감하지 못하는 경우가 많다고 지적합니다. 2400px 히어로는 합리적일 수 있습니다. “픽셀 많은 게 안전하니까” 5000px로 만드는 히어로는 대개 대역폭만 태웁니다.
PhotoTools는 이 두 작업을 분리해 둡니다. 정확한 픽셀 값이나 긴 변을 줄여야 하면 Resize를 쓰고, 그다음 Compress에서 JPEG·WebP·AVIF를 골라 품질을 다듬으세요.
품질에 손대기 전에 포맷을 정한다
포맷은 “어떤 종류의 디테일을 깔끔하게 덜어낼 수 있는가”를 결정합니다.
- 대부분의 웹 사진에는 WebP를 쓰세요. 최신 브라우저에서 폭넓게 지원되며, 비슷한 체감 품질에서 JPEG보다 대체로 파일이 작습니다. Google의 WebP 문서는 동급 JPEG 대비 25~34% 절감을 보고합니다.
- 바이트가 아쉬운 곳에는 AVIF를 쓰세요. 큰 사진 자산에서 WebP를 능가할 수 있지만, 인코딩이 느리고 파이프라인이 복잡해집니다. 단독이 아니라 폴백과 함께 사용하세요.
- JPEG는 호환용 폴백으로 씁니다. 이메일, 오래된 CMS 워크플로, 다운로드 배포,
<img>의 폴백 소스에서 여전히 유용합니다. - 스크린샷과 텍스트에는 PNG나 무손실 WebP를 씁니다. 손실 JPEG/WebP는 UI의 작은 글씨를 뭉개고, 뚜렷한 엣지 주변에 색 노이즈를 만들 수 있습니다.
- 로고와 아이콘에는 SVG를 씁니다. 래스터 로고를 WebP로 만들면 PNG보다 작아질 수 있지만, 잘 만든 SVG가 대개 더 선명하고 더 가볍습니다.
<picture>를 쓸 때는 가장 효율적인 포맷을 앞에 두고, 안쪽의 img에 호환 폴백을 남겨 두세요.
<picture>
<source
type="image/avif"
srcset="/images/hero-1200.avif 1200w, /images/hero-2000.avif 2000w"
sizes="100vw"
/>
<source
type="image/webp"
srcset="/images/hero-1200.webp 1200w, /images/hero-2000.webp 2000w"
sizes="100vw"
/>
<img
src="/images/hero-1200.jpg"
width="1200"
height="800"
alt="월넛 캐비닛과 자연광이 들어오는 리모델링 완료 주방"
/>
</picture>
img 요소는 여전히 중요합니다. 폴백 소스, alt, width, height를 담고 있는 것이 이 요소입니다. 접근성이나 레이아웃 정보를 source 요소 안에 숨기지 마세요.
실전에서 쓸 만한 품질 설정
품질 숫자는 표준화되어 있지 않습니다. 어떤 인코더에서의 JPEG 품질 80이 다른 인코더의 80과 같으리라는 보장은 없습니다. WebP 80, JPEG 80, AVIF 50도 서로 등가가 아닙니다. 품질은 출발점으로 다루고, 내보낸 파일을 눈으로 확인하세요.
| 출력 | 시작값 | 올릴 때 | 내릴 때 |
|---|---|---|---|
| JPEG 폴백 | 82~88 | 상품 디테일, 얼굴, 사진 위 텍스트 | 장식 사진, 배경, 파일이 아직 무거움 |
| WebP 사진 | 78~85 | 히어로, 상품, 포트폴리오 이미지 | 썸네일, 그리드, 단순 배경 |
| WebP 썸네일 | 70~78 | 라벨이나 텍스처가 흐물흐물해 보임 | 이미지는 작은데 파일이 여전히 무거움 |
| AVIF 사진 | 45~65 | 밴딩이나 피부, 원단, 세밀한 디테일이 무너짐 | 큰 히어로가 여전히 너무 무거움 |
| PNG | 손실 품질 없음 | 정확한 엣지가 필요한 스크린샷·투명 자산 | 대상 시스템이 지원할 때만 WebP/AVIF 검토 |
흔한 함정은 “안전하니까” 모든 것을 품질 95~100으로 내보내는 것입니다. 대부분의 웹 사진에서 그 여분 바이트는 네트워크 폭포수에서만 보이고, 정작 페이지에서는 티가 나지 않습니다. 또 하나의 함정은 임의의 목표에 맞추려고 품질을 50 아래로 밀어붙이는 것입니다. 거기까지 내려야 한다면, 더 열화시키기 전에 리사이즈나 포맷 교체를 먼저 검토하세요.
페이지 역할별 파일 크기 목표
이 값들은 Google의 규칙도 아니고, 순위를 결정하는 마법의 임계값도 아닙니다. “확실히 너무 무거운 이미지”를 걸러내기 위한 실무적인 검토 기준입니다.
| 자산 | 건전한 작업 목표 | 참고 |
|---|---|---|
| 아바타나 저자 인물 사진 | 10~40KB | 보통 160~400px로 표시 |
| 카드 썸네일 | 15~60KB | 그리드 이미지는 치수를 통일해야 함 |
| 블로그 본문 이미지 | 60~180KB | 너비와 디테일에 따라 다름 |
| 상품 그리드 이미지 | 50~150KB | 라벨이 읽혀야 함 |
| 상품 상세 이미지 | 120~300KB | 확대와 텍스처를 위해 여유 확보 |
| 스크롤 위쪽 히어로 | 150~450KB | 더 클 수도 있지만 LCP 확인 필수 |
| 전체화면 포트폴리오 사진 | 250~700KB | 엄격한 크기보다 품질이 더 중요한 경우 |
| UI 스크린샷 | 30~250KB | 몇 바이트보다 텍스트 선명도가 우선 |
760px 블로그 이미지가 900KB라면 대개 손봐야 합니다. 전체 너비 포트폴리오 이미지가 410KB이고 아주 잘 보인다면, 이를 90KB까지 억지로 줄이는 건 잘못된 목표일 수 있습니다.
LCP·히어로 이미지 압축하기
가장 최적화 가치가 큰 이미지는 대개 스크롤 위쪽에서 가장 큰 이미지입니다. Core Web Vitals 용어로는 보통 Largest Contentful Paint 이미지죠. 압축은 도움이 됩니다. 다만 그 이미지가 조기에 발견되고 조기에 로드되는 경우에 한합니다.
히어로 이미지에서는:
- 페이지에서 실제로 사용하는 종횡비로 크롭합니다.
- 반응형 너비, 예를 들어 1200px와 2000px를 내보냅니다.
- 스택이 지원하면 AVIF를 앞에 두고 WebP/JPEG를 폴백으로 씁니다.
- 히어로나 스크롤 위쪽의 LCP 후보에는 lazy-load를 걸지 않습니다.
- 브라우저가 레이아웃 공간을 예약할 수 있도록
width와height를 넣습니다. fetchpriority="high"는 LCP가 될 가능성이 가장 높은 한 장에만 씁니다.
폴백 img 예시:
<img
src="/images/hero-1200.jpg"
srcset="/images/hero-1200.jpg 1200w, /images/hero-2000.jpg 2000w"
sizes="100vw"
width="1200"
height="800"
fetchpriority="high"
alt="월넛 캐비닛과 자연광이 들어오는 리모델링 완료 주방"
/>
fetchpriority="high"를 갤러리 전체에 붙이지 마세요. 우선순위 힌트는 날이 선 도구입니다. 진짜로 가장 먼저 도착해야 하는 한 장에만 사용하세요.
압축 결과 비교하는 법
올바른 비교는 “원본 vs 압축본을 100% 확대로 보기”가 아닙니다. 그건 지나치게 큰 이미지를 그대로 내보내도록 자신을 설득하는 방식입니다. 방문자가 실제로 보는 크기와 맥락에서 비교하세요.
이 검토 절차를 한 바퀴 돌리세요:
- 압축된 이미지를 실제 페이지 또는 같은 너비의 테스트 레이아웃에 넣습니다.
- 데스크톱과 모바일 너비에서 봅니다.
- 위험 지대를 확인합니다: 얼굴, 피부, 하늘, 그러데이션, 원단, 상품 라벨, 작은 글씨, 대비가 강한 엣지.
- 렌더링된 크기에서 원본과 압축본을 번갈아 봅니다.
- 100% 확대는 명백한 아티팩트를 잡아내기 위한 짧은 확인용으로만. 아무도 안 보는 완벽함을 요구하기 위한 것이 아닙니다.
압축 아티팩트에는 각자의 성격이 있습니다. JPEG는 블록형 엣지, 링잉, 색 노이즈가 잘 나타납니다. 과도하게 압축된 WebP는 텍스처를 문지른 것처럼 만듭니다. AVIF는 밀어붙이면 밴딩이나 플라스틱 같은 질감이 나올 수 있습니다. PNG 스크린샷은 대개 반대 방향으로 실패합니다. 완벽해 보이지만 필요보다 훨씬 무겁죠.
웹 이미지용 PhotoTools 워크플로
PhotoTools는 이미지가 CMS·CDN·리포지토리에 들어가기 전에 유용합니다. 완전한 빌드 파이프라인을 대체하지는 않지만, 소규모 사이트, 블로그 글, 클라이언트 프리뷰, 일회성 자산을 위한 깔끔한 수작업 흐름을 제공합니다.
- 원본 소스 파일은 건드리지 않고 보관합니다.
- 이미지의 역할을 정합니다: 히어로, 본문 이미지, 상품 사진, 스크린샷, 썸네일, 배경.
- 원본이 표시 크기보다 훨씬 크다면 Resize를 먼저 씁니다.
- Compress를 열고 JPEG·WebP·AVIF 중 하나를 선택한 뒤 WebP/JPEG는 품질 80 근처에서 시작합니다.
- “Compress all”을 눌러 각 카드에서 원본 크기, 출력 크기, 절감 비율을 확인합니다.
- 결과를 내려받아 페이지 맥락에서 검토합니다.
- 시각적으로 만족스럽지 않으면 원본이나 리사이즈한 사본으로 돌아가 더 높은 품질로 다시 내보냅니다.
- 그래도 무거우면 품질을 아티팩트 구간으로 내리기 전에 치수를 먼저 줄입니다.
이미 압축된 다운로드를 계속 재압축하지 마세요. 손실 아티팩트가 쌓입니다. 마스터나 깔끔하게 리사이즈된 중간본으로 돌아가는 편이 좋습니다.
메타데이터와 프라이버시
카메라 파일에는 흔히 EXIF 메타데이터가 들어 있습니다: GPS 좌표, 촬영 일시, 카메라 모델, 렌즈, 편집 소프트웨어. 이 메타데이터는 방문자가 이미지를 보는 데는 도움이 되지 않고, 사적인 정보를 노출할 수 있습니다.
PhotoTools는 파일을 디코딩하고 픽셀을 브라우저 캔버스에 그린 뒤 새 파일로 내보내는 방식으로 압축합니다. MDN 문서에는 OffscreenCanvas.convertToBlob()이 손실 압축을 지원하는 포맷에 대해 이미지 타입과 품질을 지정할 수 있다고 명시되어 있습니다. 출력은 캔버스 픽셀에서 만들어지므로, 카메라 메타데이터는 대개 새 파일로 복사되지 않습니다.
민감한 사진이라면 공개 전에 최종 다운로드를 메타데이터 확인 도구로 한 번 더 점검하세요. 프라이버시는 파일 크기만의 문제가 아닙니다.
이미지를 나쁘게 보이게 하는 흔한 실수
- 리사이즈 전에 압축한다: 레이아웃이 절대 보여주지 않을 픽셀에서 바이트를 아끼려는 상황.
- 사진에 PNG를 쓴다: 카메라 이미지에 PNG는 대체로 지나치게 큽니다.
- 텍스트가 있는 스크린샷에 JPEG를 쓴다: 파일은 작아져도 글자가 뭉개집니다.
- 잘못된 크기에서 판단한다: 풀 해상도 확대는 무해한 아티팩트도 과장해 보이게 합니다.
- 모든 기기에 하나의 거대한 히어로를 준다: 모바일 사용자가 쓰지도 못할 데스크톱 픽셀을 내려받게 됩니다.
- 히어로에 lazy-load를 건다: 스크롤 아래 이미지에는 lazy-load를 써도 되지만, LCP 이미지는 안 됩니다.
width와height가 없다: 이미지가 로드되는 동안 레이아웃이 튈 수 있습니다.- 게시된 파일을 재압축한다: 가능하면 원본에서 다시 시작하세요.
간단한 게시 전 체크리스트
웹 이미지를 업로드하기 전에 이 목록을 한 번 훑어보세요:
- 콘텐츠 유형에 맞는 포맷인가?
- 소스 너비가 실제 표시 너비와 현실적인 DPR을 근거로 정해졌는가?
- 모바일에서 히어로 크롭이 달라진다면 더 작은 모바일 후보가 있는가?
- 품질은 얼굴, 라벨, 그러데이션, 상품 디테일을 감당할 정도인가?
- 파일 크기가 그 역할에 비추어 합리적인가?
- 페이지에
width,height, 의미 있는alt, 필요할 때는 반응형srcset/sizes가 들어 있는가? - LCP 이미지는 eager로 우선 로드되고, 스크롤 아래 이미지들은 lazy-load 되어 있는가?
- 내보낸 이미지를 실제 레이아웃에서 확인했는가?
- 원본 파일은 남겨 두었는가?
가장 좋은 압축 워크플로는 좋은 의미로 지루합니다. 맞는 픽셀을 고르고, 맞는 포맷을 고르고, 합리적인 품질로 내보내고, 실제 페이지에서 확인하고, 이미지가 “처리된 느낌”을 내기 직전에 멈추는 것. 그것뿐입니다.
참고한 기술 자료
이 글은 PhotoTools의 현재 압축·리사이즈 구현, web.dev의 이미지 성능 가이드, Chrome의 「Improve image delivery」 인사이트, Chrome의 「Properly size images」 가이드, MDN의 OffscreenCanvas.convertToBlob() 문서, MDN의 이미지 파일 형식 가이드, Google의 WebP 문서와 대조해 검토했습니다.