이미지 용량 줄이는 기준 · 화질을 지키면서 어디까지 줄이나

이미지 용량을 줄이는 기준은 두 단계다. 먼저 화면에 실제로 표시되는 폭의 두 배를 넘는 원본은 그 크기로 리사이즈한다. 그다음 JPEG나 WebP로 압축한다. 순서를 바꾸면 안 된다. 4000픽셀짜리 사진을 800픽셀 자리에 넣어 놓고 압축률만 올리는 것은 용량도 화질도 둘 다 잃는 방식이다. 리사이즈로 줄어드는 폭이 압축으로 줄어드는 폭보다 훨씬 크고, 화질 손상도 거의 없다.

이 글은 그 기준을 실제 작업 순서로 정리한다. 포맷을 어떻게 고르는지, 화질 손상이 눈에 보이기 시작하는 지점이 어디인지, 지연 로딩을 걸어야 할 이미지와 절대 걸면 안 되는 이미지가 무엇인지, 그리고 지금 내 페이지가 몇 MB인지 확인하는 방법까지 다룬다.

이 글에 나오는 숫자는 표에 있는 것이든 본문에 있는 것이든 전부 내가 운영하면서 쓰는 작업 기준값이다. 업계 표준도 아니고 측정된 벤치마크도 아니다. 판단을 빠르게 하려고 정해 둔 선이라는 점을 먼저 밝혀 둔다. 사이트마다 맞는 선은 다르다.

이미지 용량이 모바일 첫 화면을 결정하는 이유

방문자가 페이지를 열었을 때 화면에서 가장 큰 요소가 다 그려지는 시점, 그게 LCP다. 그리고 대부분의 페이지에서 화면의 가장 큰 요소는 이미지다. 히어로 사진, 글 맨 위의 대표 이미지, 상품 대표컷.

이 말은 곧 페이지가 빠른지 느린지가 대개 이미지 한 장에 달려 있다는 뜻이다. 자바스크립트 번들을 줄이고 폰트를 최적화해도, 첫 화면에 3MB짜리 사진이 있으면 그 사진이 다 내려올 때까지 LCP는 끝나지 않는다.

유입이 갑자기 줄었을 때 이미지가 원인인 경우도 있다. 다른 원인들과 함께 가르는 순서는 방문자가 줄었을 때 원인 찾는 순서에 정리했다.

모바일에서는 이게 더 크게 벌어진다. 사무실 와이파이에서 눈 깜짝할 사이에 끝나는 다운로드가 지하철에서는 체감될 만큼 늘어진다. 데스크톱 브라우저로만 확인하면 이 문제가 보이지 않는다.

그래서 이미지 용량은 "언젠가 정리할 기술 부채"가 아니라 첫 화면 속도를 직접 잡고 있는 손잡이다. 손댈 곳 중에 가장 싸고 가장 효과가 확실한 편이기도 하다.

압축보다 리사이즈가 먼저인 이유는 무엇인가

가장 흔한 오해는 "용량 줄이기 = 압축"이라는 생각이다. 실제로 대부분의 무거운 페이지에서 진짜 문제는 압축률이 아니라 크기다.

요즘 스마트폰으로 찍은 사진은 폭이 수천 픽셀이다. 정확한 값은 기기와 촬영 설정에 따라 다르니 각자 파일 정보를 열어 확인하는 편이 빠르다. 이걸 블로그 본문에 그대로 올리면 브라우저는 원본 파일을 전부 내려받은 다음, 화면에 800픽셀로 줄여서 그린다. 나머지 픽셀은 다운로드 시간만 쓰고 버려진다.

픽셀 수는 폭과 높이의 곱이라서 폭을 절반으로 줄이면 픽셀은 4분의 1이 된다. 폭 4000픽셀짜리 사진을 예로 들면, 800픽셀로 줄일 때 픽셀 수 자체가 스물다섯 분의 일이 된다. 압축률을 아무리 손봐도 이만큼은 나오지 않는다.

더 중요한 건 리사이즈는 화면에서 티가 안 난다는 점이다. 어차피 800픽셀 자리에 들어갈 이미지라면 800픽셀로 줄여도 보이는 결과가 같다. 반대로 압축률을 과하게 올리면 그건 바로 보인다.

순서는 항상 리사이즈 먼저, 압축 나중이다. 압축된 파일을 다시 리사이즈하면 압축 흔적이 확대되거나 뭉개져서 결과가 나빠진다.

업로드 전에 최대 폭부터 정해 둔다

압축은 사후 처리다. 이미 올라간 이미지를 나중에 정리하는 일은 사람이 계속 붙어야 하고, 결국 안 한다.

그래서 실제로 효과가 있는 건 업로드 규칙이다. "본문 이미지는 폭 1600픽셀을 넘기지 않는다"를 정해 두고, 올리기 전에 한 번 줄인다. 규칙이 하나면 사람이 기억할 수 있다.

최대 폭은 사이트의 본문 폭에서 역산한다. 본문 콘텐츠 영역이 800픽셀이면 고해상도 화면을 감안해 두 배인 1600픽셀을 상한으로 잡는다. 픽셀 밀도가 더 높은 화면도 있지만, 그 차이까지 쫓아가면서 늘리는 용량은 대개 눈에 보이는 이득으로 돌아오지 않는다. 두 배를 기본값으로 두고 예외만 따로 관리한다.

표에서 눈여겨볼 건 썸네일이다. 한 장은 가볍지만 목록에 스무 장이 깔리면 합계가 본문 사진 여러 장보다 무거워지는 경우가 흔하다. 목록 페이지가 유독 느리면 여기부터 본다.

JPEG, PNG, WebP, AVIF는 각각 무엇에 쓰나

포맷은 취향 문제가 아니라 이미지 종류에 따라 정해진다. 사진은 손실 압축, 선과 글자는 무손실 압축이 맞다.

실무 기준은 단순하게 잡는다. 사진은 WebP, 로고와 아이콘은 SVG, SVG로 못 만드는 그래픽은 PNG. AVIF는 히어로처럼 크고 중요한 이미지 한두 장에만 쓴다.

PNG 스크린샷이 가장 자주 새는 구멍이다. 화면 캡처를 그대로 PNG로 올리면 몇 MB가 되는 경우가 있다. 글자가 있어서 PNG가 맞긴 한데, 캡처 크기가 너무 크다. 여기서도 답은 압축이 아니라 리사이즈다.

예외도 있다. 사진 위에 글자가 얹힌 이미지, 예를 들어 텍스트가 들어간 배너는 JPEG으로 가면 글자 가장자리가 지저분해진다. 이런 건 WebP 손실 압축을 품질을 높여서 쓰거나, 아예 글자를 이미지에서 빼고 HTML 텍스트로 올린다. 후자가 검색 노출에도 낫다.

GIF로 만든 짧은 화면 녹화가 몇 MB씩 나가는 경우도 흔하다. 이건 포맷을 바꿀 게 아니라 동영상 파일로 바꿔야 한다.

화질 손상은 어디서부터 눈에 보이나

압축 품질 설정은 대체로 0에서 100 사이 값이다. 여기서 눈으로 구분되기 시작하는 지점이 있다.

내 경험으로 사진은 품질 80 근처까지는 원본과 나란히 놓고 봐도 구분이 잘 안 된다. 70 아래로 내려가면 하늘이나 피부처럼 색이 완만하게 변하는 면에서 얼룩이 보이기 시작한다. 60 아래는 확대하지 않아도 보인다.

손상이 먼저 드러나는 곳은 정해져 있다.

• 넓고 완만한 그라데이션: 하늘, 벽, 배경 흐림
• 피부 톤
• 선명한 경계선: 글자, 로고 가장자리, 도표의 선
• 어두운 영역의 미세한 계조

반대로 잔디, 나뭇잎, 자갈처럼 디테일이 복잡한 면은 압축을 세게 걸어도 잘 안 보인다.

그래서 한 가지 품질값을 전부에 적용하는 건 좋은 방법이 아니다. 배경 사진은 세게, 제품 상세컷은 약하게 거는 게 맞다.

확인 방법은 하나뿐이다. 원본과 압축본을 실제 표시 크기로 나란히 띄워 놓고 본다. 100% 확대해서 보면 안 된다. 방문자는 그렇게 보지 않는다.

이미지 종류별 압축 목표는 어떻게 잡나

아래는 내가 쓰는 목표값이다. 절대 기준이 아니라 "이 선을 넘으면 한 번 더 본다"는 경보선에 가깝다.

페이지 단위로도 선을 하나 둔다. 나는 글 한 편의 이미지 합계를 1MB 안쪽으로 잡는다. 사진을 여덟 장 쓰는 글이라면 장당 목표를 그만큼 낮춰야 한다는 뜻이다.

이 목표를 못 맞추는 경우가 당연히 있다. 인쇄용 원본을 그대로 보여줘야 하는 포트폴리오, 확대해서 봐야 하는 제품 디테일, 지도나 도면 같은 것들이다. 이럴 때는 목표를 억지로 맞추지 말고, 그 이미지만 예외로 두고 나머지에서 벌면 된다.

지연 로딩은 어디에 걸고 어디에 안 거나

지연 로딩(lazy loading)은 화면에 들어올 때까지 이미지를 안 받는 기능이다. loading="lazy" 속성 한 줄로 켜진다.

긴 글에 사진이 열 장 있고 방문자가 세 번째 사진까지만 읽고 나간다면, 나머지 일곱 장은 받을 이유가 없다. 여기서 지연 로딩은 확실히 이득이다.

그런데 첫 화면에 보이는 이미지에는 절대 걸면 안 된다. 이유가 명확하다. 지연 로딩은 브라우저가 레이아웃을 계산해서 "이 이미지가 화면 안에 있다"고 판단한 다음에야 다운로드를 시작한다. 원래는 HTML을 읽자마자 시작했을 다운로드가 한 단계 뒤로 밀린다.

그 이미지가 LCP 요소라면 첫 화면 렌더링이 통째로 늦어진다. 성능을 올리려고 넣은 속성이 정확히 성능을 깎는다.

판단 기준은 간단하다.

그리고 이미지 태그에는 항상 폭과 높이를 넣는다. 크기를 모르면 브라우저가 자리를 비워 두지 못해서, 이미지가 도착하는 순간 아래 내용이 밀린다. 읽던 문장이 갑자기 튀는 그 현상이다. 용량과는 다른 문제지만 같이 잡아야 한다.

내 페이지가 실제로 몇 MB인지 어떻게 확인하나

감으로 판단하지 않는다. 확인은 브라우저에서 끝난다.

크롬 개발자도구를 열고 네트워크 탭으로 간다. 캐시 비우기를 체크하고 페이지를 새로고침하면 아래에 전체 전송량이 나온다. 유형 필터에서 Img만 남기면 이미지 합계만 볼 수 있다.

여기서 볼 것은 세 가지다.

• 이미지 총합이 몇 MB인가
• 가장 큰 파일 한 장이 몇 KB인가
• 그 파일이 화면에서 몇 픽셀로 표시되는가

세 번째가 핵심이다. 개발자도구에서 이미지 위에 마우스를 올리면 원본 크기와 표시 크기가 함께 뜬다. 두 숫자가 크게 벌어져 있으면 그게 바로 리사이즈 안 된 이미지다.

모바일 기준으로 봐야 한다는 것도 잊지 않는다. 개발자도구에서 기기 모드를 켜고, 네트워크 속도를 느린 조건으로 제한한 뒤 다시 열어 본다. 데스크톱 광랜에서 안 보이던 문제가 여기서 보인다.

도구는 무엇을 쓰나

작은 팀에서는 도구를 늘리는 것보다 한 가지를 습관으로 만드는 게 낫다.

• 맥 미리보기: 도구 메뉴에서 크기 조정. 한두 장이면 이걸로 충분하다
• 스퀴시 같은 웹 변환기: 브라우저에서 포맷 바꾸고 품질 미리보기까지 된다. 결과를 눈으로 확인하며 조절하기 좋다
• ImageMagick, sharp 같은 CLI: 폴더 단위로 한 번에 처리할 때. 규칙을 스크립트로 박아 두면 사람이 기억할 필요가 없다
• CMS나 프레임워크의 이미지 컴포넌트: 리사이즈와 포맷 변환을 자동으로 해 주는 경우가 많다. 이게 있으면 이게 정답이다

마지막 항목부터 확인하는 게 순서상 맞다. 지금 쓰는 CMS나 프레임워크에 이미지 처리 기능이 이미 들어 있는지부터 문서에서 찾아본다. 있는데 안 켜 놓고 수동으로 압축하고 있는 경우가 생각보다 많다. 도구마다 지원 범위가 다르니 이름만 보고 짐작하지 말고 해당 문서를 확인한다.

줄이면 안 되는 경우도 있나

있다. 규칙에는 예외가 있고, 예외를 인정하지 않으면 규칙이 통째로 무시된다.

사진 자체가 상품인 경우가 대표적이다. 사진작가 포트폴리오, 인쇄물 시안, 원단이나 도장 색을 봐야 하는 제품 페이지. 여기서 압축 흔적은 곧 품질 신뢰의 문제다.

확대가 기능인 이미지도 그렇다. 제품 상세컷을 확대해서 보는 UI가 있다면 표시 폭의 두 배 규칙이 적용되지 않는다. 확대했을 때의 폭이 기준이다.

이럴 때 쓰는 방법은 분리다. 목록과 첫 화면에는 가벼운 버전을 쓰고, 확대하거나 클릭했을 때 원본을 따로 불러온다. 무거운 이미지를 없애는 게 아니라 첫 화면에서 빼는 것이다.

또 하나, 파일 하나를 몇 KB 더 줄이려고 오래 붙잡고 있을 이유는 없다. 3MB를 200KB로 줄이는 작업과 200KB를 180KB로 줄이는 작업은 가치가 다르다. 큰 것부터 잡고, 목표선 안에 들어오면 손을 뗀다.

검색 노출에는 무엇이 영향을 주나

용량만 줄인다고 이미지가 검색에 잘 나오지는 않는다. 구글이 이미지를 검색에 표시하려면 그 이미지가 무엇인지 알아야 하고, 그건 파일 크기가 아니라 주변 정보에서 온다.

같이 챙길 것들이다.

• alt 텍스트: 이미지 내용을 그대로 설명한다. 키워드를 욱여넣는 자리가 아니다
• 파일 이름: IMG_4821.jpg보다 내용을 담은 이름이 낫다
• 이미지 주변 문장: 이미지 바로 위아래 텍스트가 맥락을 준다
• 사이트맵: 중요한 이미지는 사이트맵에 포함될 수 있게 둔다
• 고유 URL: 이미지가 안정적인 주소에 있어야 색인된다

그러면 용량은 검색에 아무 상관이 없는가. 그렇게 정리하면 과하다. 다만 순위가 어떻게 매겨지는지를 두고 단정하지는 않겠다. 확실하게 말할 수 있는 건 여기까지다. 무거운 이미지는 방문자가 내용을 보기까지 걸리는 시간을 늘린다. 용량 최적화는 이미지 검색을 위한 작업이라기보다 페이지를 열어 본 사람을 위한 작업이고, 그래서 하는 것이다.

오늘 30분에 할 수 있는 것

한 번에 사이트 전체를 정리하려고 하면 시작을 못 한다. 순서를 좁힌다.

1. 트래픽이 가장 많은 페이지 세 개를 고른다
2. 각각 네트워크 탭에서 이미지 총량과 최대 파일을 적는다
3. 가장 무거운 파일 한 장씩만 리사이즈하고 WebP로 교체한다
4. 첫 화면 이미지에 loading="lazy"가 걸려 있으면 뺀다
5. 새로 올리는 이미지의 최대 폭 규칙을 문서 한 줄로 적어 둔다

5번이 실제로는 가장 오래 간다. 이미 올라간 이미지를 정리하는 건 일회성이지만, 업로드 규칙은 앞으로 올라올 모든 이미지에 적용된다.

자주 묻는 질문

이미지 용량은 몇 KB 이하로 맞춰야 하나요?

절대적인 기준은 없습니다. 다만 판단을 빠르게 하려면 선을 정해 두는 편이 낫습니다. 저는 본문 사진 한 장 200KB 안쪽, 글 한 편의 이미지 합계 1MB 안쪽을 기준으로 씁니다. 사진이 상품인 사이트라면 이 선은 더 높아야 하고, 목록 위주의 페이지라면 더 낮아야 합니다. 사이트 성격을 모르면 정해 드릴 수 없는 숫자입니다.

WebP를 쓰면 오래된 브라우저에서 안 보이지 않나요?

지원 범위는 계속 바뀌므로 여기에 숫자를 적어 두는 것보다 브라우저 지원 표를 그때그때 확인하시는 편이 정확합니다. 확인이 번거롭거나 방문자 환경이 넓게 퍼져 있다면 <picture> 태그로 WebP를 먼저 두고 JPEG을 대체안으로 함께 제공하면 됩니다. 이러면 지원 여부를 브라우저가 알아서 고르므로 고민할 일이 없어집니다. AVIF도 같은 방식으로 대체안을 함께 두시면 됩니다.

압축했는데도 페이지가 느립니다. 왜 그런가요?

이미지가 원인이 아닐 수 있습니다. 네트워크 탭에서 유형별 전송량을 보고, 이미지 합계가 전체에서 큰 비중이 아니라면 자바스크립트나 폰트, 외부 스크립트를 봐야 합니다. 이미지가 원인인데도 안 빨라졌다면 리사이즈를 안 했을 가능성이 큽니다. 압축률만 올리고 원본 크기는 그대로인 경우가 흔합니다.

이미 올라간 이미지 수백 장을 다 다시 올려야 하나요?

전부는 아닙니다. 트래픽이 있는 페이지부터 하는 것이 맞습니다. 방문자가 거의 없는 오래된 글의 이미지를 정리하는 일은 들이는 시간 대비 얻는 게 거의 없습니다. 상위 페이지 몇 개와 앞으로 올릴 이미지의 규칙, 이 두 가지가 대부분의 효과를 냅니다.

첫 화면 이미지에 지연 로딩을 걸면 정확히 무슨 일이 생기나요?

브라우저가 레이아웃을 계산한 뒤에야 그 이미지의 다운로드를 시작합니다. HTML을 읽자마자 받기 시작했을 파일이 한 단계 뒤로 밀리는 것입니다. 그 이미지가 화면에서 가장 큰 요소라면 첫 화면 렌더링 완료 시점이 그만큼 늦어집니다. 성능을 위해 넣은 속성이 반대로 작동하는 대표적인 경우입니다.

참고 자료

• Google 이미지 SEO 권장사항 — 이미지가 검색에 표시되는 조건과 파일 이름·alt 텍스트·사이트맵 등 파일 처리 권장사항
• LCP 최적화 가이드 — 첫 화면 렌더링을 늦추는 요인과 이미지 로딩이 LCP에 미치는 영향