이미지 압축 완벽 가이드: JPG·PNG·WebP 용도별 선택

2026-04-13 공개 8분 읽기

요약 (TL;DR)

지난 주말 고양이 사진을 Squoosh에 올려 봤는데, 원본 4.2MB짜리 JPG가 품질 80으로 380KB까지 줄었습니다. 91% 감소. 휴대폰 화면에서는 원본과의 차이를 솔직히 구분할 수 없었습니다. 이게 손실 압축이 제대로 동작할 때의 풍경입니다.

이미지 포맷 선택은 “무엇이 가장 좋은가”가 아니라 “무엇에 쓸 것인가”로 결정됩니다. 사진처럼 연속 톤이 많은 이미지에는 손실 압축 계열인 JPEG, WebP(손실), AVIF가 적합합니다. 같은 시각적 품질 기준으로 WebP는 JPEG 대비 대략 25–35% 더 작고, AVIF는 JPEG 대비 약 40–50% 더 작은 파일을 만들 수 있습니다. 반대로 로고·아이콘·스크린샷처럼 경계선이 뚜렷하고 문자 가독성이 중요한 이미지는 PNG, WebP(무손실), TIFF 같은 무손실 포맷이 안전합니다. 투명도와 애니메이션을 동시에 지원해야 한다면 WebP나 APNG, AVIF가 후보입니다. 브라우저 지원은 2026년 초 기준으로 WebP는 Chrome 32(2014)·Firefox 65·Safari 14 이후 사실상 전 브라우저에서 동작하고, AVIF는 Chrome 85(2020년 8월)·Firefox 93(2021년 10월)·Safari 16(2022년 9월) 이후부터 정상 표시됩니다. 일반적인 제작 흐름은 “로고는 SVG, 사진은 WebP 또는 AVIF, 스크린샷은 PNG”로 두고, 호환성이 염려될 때 <picture> 요소로 대체 포맷을 제공하는 방식입니다.

배경/개념

JPEG·WebP(손실)·AVIF 같은 손실 압축은 사람 눈이 덜 민감한 정보를 버려 용량을 줄입니다. 핵심 단계는 두 가지입니다. 첫째는 양자화(quantization) 로, 주파수 성분을 정수 단위로 근사하면서 고주파 성분을 더 거칠게 잘라냅니다. 사진처럼 완만한 명암 변화가 많은 이미지에서는 잘 안 보이지만, 날카로운 경계선에서는 “블록 경계”가 드러날 수 있습니다. 둘째는 크로마 서브샘플링(chroma subsampling) 입니다. 휘도(Y)보다 색차(Cb·Cr) 채널의 해상도를 낮추는 기법으로, 4:4:4는 색차를 그대로 유지하고 4:2:0은 가로·세로 모두 절반으로 줄입니다. 대부분의 기본값은 4:2:0이라 텍스트가 포함된 이미지에서 빨간·파란 글자 가장자리가 번지듯 보이는 경우가 생깁니다.

JPEG는 이산 코사인 변환(DCT, Discrete Cosine Transform) 기반으로 1992년 표준화된 포맷입니다. 이에 비해 WebP는 VP8 영상 코덱의 인트라 프레임 기술을, AVIF는 AV1의 인트라 프레임을 응용한 것이라 훨씬 현대적인 예측·변환을 사용합니다. PNG는 완전히 다른 계열로, LZ77 계열 deflate 알고리즘을 쓰는 무손실 압축이며 투명도를 위해 알파 채널을 지원합니다. 그래서 PNG는 품질 저하가 없지만 연속 톤이 많은 사진에서는 용량이 매우 커집니다.

비교/데이터

포맷손실무손실투명도애니메이션평균 압축비(사진)2025년 브라우저 지원
JPEGOXXX약 10:1 수준모든 브라우저
PNGXOOAPNG 확장약 2–3:1모든 브라우저
WebPOOOOJPEG 대비 약 25–35% 작음Safari 14(2020) 이후 사실상 전 브라우저
AVIFOOOOJPEG 대비 약 40–50% 작음Chrome 85+, Firefox 93+, Safari 16+
GIFO(팔레트 256색)XO(1비트)O사진에는 부적합모든 브라우저

평균 압축비는 콘텐츠·설정·인코더에 따라 크게 달라지므로 표는 일반 경향으로만 참고하세요. 같은 이미지라도 JPEG 품질 85%와 60%는 3–4배 차이가 나며, AVIF는 빠른 인코딩 프리셋을 쓰면 WebP와 비슷한 수준까지만 줄어들기도 합니다.

실전 시나리오

시나리오 1 — 블로그 썸네일과 히어로 이미지. 제 블로그 히어로가 1.8MB였는데 WebP 품질 82로 다시 뽑으니 210KB, LCP가 2.4초→1.1초로 내려갔습니다. 기본 출력은 WebP, 구형 환경 호환이 필요하면 <picture>에 JPEG 폴백을 둡니다. 표시 폭에 맞춰 자른 뒤 내보내야 대역폭 낭비가 없고, 품질은 WebP 80–85면 육안 구분이 어렵습니다.

시나리오 2 — 로고와 아이콘. 벡터 원본이 있다면 SVG가 1순위입니다. 한 번은 빨간 로고를 JPEG 품질 75로 내보낸 마케팅 페이지에서 글자 테두리가 핑크빛으로 번져 보이는 걸 목격했습니다. 크로마 서브샘플링이 빨간 경계를 가장 먼저 망가뜨립니다. 래스터만 있다면 PNG 또는 WebP 무손실을 씁니다.

시나리오 3 — 스크린샷과 UI 캡처. 스크린샷은 PNG가 기본입니다. 문서 가이드에 JPEG 스크린샷을 썼다가 “코드 폰트가 뿌옇다”는 리뷰를 두 번 받은 뒤로 이 규칙을 고집합니다. 용량을 줄여야 한다면 pngquant(brew install pngquant)로 256색까지 내려도 UI 스크린샷은 보통 티가 안 납니다.

자주 하는 오해

“PNG가 항상 최고 품질이다.” 무손실이라는 의미에서는 맞지만, 사진에는 압축 효율이 너무 낮아 실제 웹 표시에서는 비효율적입니다. 사진 1장이 수 MB가 되면 모바일 환경에서 체감 로딩이 크게 떨어집니다.

“WebP는 호환성이 떨어진다.” 2020년 Safari 14 이후 사실상 모든 최신 브라우저에서 동작합니다. 여전히 걱정된다면 <picture> 폴백으로 JPEG를 병행 제공하면 됩니다.

“AVIF는 마법이다.” 압축 효율은 뛰어나지만 인코딩이 느립니다. 제 M2 맥북 에어에서 2400×1600 사진 한 장을 avifenc --speed 4로 돌리면 5–9초씩 걸렸습니다. 오래된 모바일 디바이스의 디코더 속도도 이슈가 될 수 있습니다. 사용자 업로드마다 실시간 인코딩보다는 배치 변환이나 빌드 타임 파이프라인이 현실적입니다.

“그냥 JPEG 쓰면 된다.” 2010년대 중반까지는 현실적인 선택이었지만, 지금은 동일 품질에서 더 작은 WebP가 광범위하게 지원되므로 새 파이프라인에서는 WebP를 기본으로 두는 쪽이 합리적입니다.

체크리스트 또는 의사결정 플로우

  1. 이미지 소스가 벡터인가? → 예: SVG로 저장.
  2. 투명도가 필요한가?
    • 예 & 사진형 → WebP(손실+알파) 또는 AVIF.
    • 예 & 로고/아이콘 → PNG 또는 WebP(무손실).
  3. 애니메이션이 필요한가? → WebP 애니메이션, APNG, AVIF. GIF는 색 수 제한으로 사진에 부적합.
  4. 사진·그라디언트 중심인가? → WebP(손실) 기본, 대역폭이 중요하다면 AVIF 추가.
  5. 스크린샷·문자 중심인가? → PNG 또는 WebP(무손실).
  6. 브라우저 범위가 매우 넓어야 하는가? → <picture> 요소로 AVIF → WebP → JPEG 순서의 폴백을 제공.

관련 도구

이 글에서 다룬 내용을 바로 시험해 보고 싶다면 relatedToolUrl에 적힌 Patrache Studio 이미지 압축 도구로 JPEG·PNG·WebP를 손실·무손실 옵션과 함께 변환해 볼 수 있습니다. 이미지와 자주 함께 다뤄지는 주제는 PDF와 QR 코드이므로 브라우저 PDF 병합·분할의 보안 이점과 QR 코드 보안: 동적 QR 위험과 단축 URL의 함정을 함께 읽어 두면, 이미지·문서·링크가 포함된 자료를 만들 때 일관된 판단 기준을 세울 수 있습니다.

참고 자료

관련 도구

tools.patrache.studio/image/compress/