압축한 이미지가 오히려 커지는 이유와 해결법

이미지를 압축하거나 변환했는데 내려받은 파일이 원본보다 큰 경우가 있습니다. 대부분은 버그가 아닙니다. 인코더는 받은 픽셀을 지정한 포맷으로 다시 기록할 뿐이고, 그 기록이 원래 파일보다 길어질 때가 있습니다.

짧은 답: 용량이 느는 경우는 다섯 가지입니다. 새 설정이 원본보다 더 많은 정보를 남길 때(강하게 압축된 JPEG를 더 높은 품질로 다시 저장), 손실 압축 사진을 무손실 포맷으로 옮길 때(JPG → PNG), 원본이 쓰던 압축 방식을 인코더가 버릴 때(팔레트 PNG를 32비트로 다시 저장), 아주 작은 이미지에서 포맷 자체의 고정 용량이 더 클 때, 그리고 픽셀 수가 늘어날 때입니다. 저희 테스트에서 135 kB JPEG는 PNG로 바꾸자 2.21 MB가 됐고, 504바이트 아이콘은 WebP로 1,104바이트가 됐습니다. 해결책은 대개 원본을 그대로 쓰거나, 다른 포맷을 고르거나, 품질을 낮추는 것입니다. 경우별로 무엇을 하면 되는지 아래에 적었습니다.

아홉 가지 경우 한눈에 보기

아래 숫자는 모두 저희 컴퓨터에서 한 번 실행한 결과입니다. 표의 크기는 정확한 바이트 수이고, 본문에서 1 kB는 1,000바이트입니다.

어떻게 측정했나요?

모든 측정은 2026-10-16(UTC)에 macOS 26.6.2가 설치된 Apple M4 Mac에서 했습니다.

• 브라우저 인코더: Google Chrome 155.0.8059.85 헤드리스 모드. 저희 이미지 압축 도구가 쓰는 라이브러리인 browser-image-compression 2.0.2를 빈 로컬 페이지에 불러와 압축 도구의 기본 설정으로 호출했습니다. 품질 0.8, 목표 크기 1 MB, 긴 변 최대 1920px, 원본 포맷 유지, EXIF 제거, 재시도 최대 30회입니다. 변환은 저희 변환 페이지와 같은 캔버스 호출을 썼습니다. 이미지를 그리고, JPG일 때는 뒤를 흰색으로 채운 뒤, 변환 도구 기본 품질인 90%로 canvas.toBlob을 호출합니다. 사이트 화면을 직접 클릭하며 테스트하지는 않았습니다. 코드 경로는 같지만 그 주변 페이지는 테스트용 페이지였습니다.
• 그 밖의 인코더: Node v26.12.0의 sharp 0.35.5(libvips 8.18.7, mozjpeg, libwebp 1.6.0, libaom 3.15.1, libimagequant 2.4.1, libpng 1.6.58), 그리고 저희 GIF → APNG 변환기가 쓰는 PNG/APNG 인코더 upng-js 2.1.0.
• 이미지: Bonnie Moreland의 CC0 풍경 사진(Wikimedia Commons)을 이전 벤치마크에서 저희 압축 도구로 처리한 결과물(1920 x 1280, 250,382바이트)과, 이를 mozjpeg 품질 70으로 다시 인코딩한 파일(135,151바이트). 코닥 테스트 이미지 kodim04(512 x 768 PNG, 코닥이 자유 사용을 허용해 공개). 저희 /compress 페이지 스크린샷(1440 x 900 PNG). Enzy Cell의 CC0 "NEW LOGO R"(Wikimedia Commons)과 그 팔레트 버전. 이번 테스트를 위해 직접 그린 32 x 32 아이콘과 12프레임 GIF. kodim04에서 잘라 낸 폭 320px 썸네일.

각 수치는 한 번 실행한 결과입니다. 브라우저의 PNG 인코더는 실행할 때마다 바이트가 조금씩 달라지므로 직접 재현하면 작은 차이가 날 수 있습니다. ImgCompress.app은 저희가 만드는 서비스이며, 누가 운영하는지는 소개 페이지에 있습니다. 글 초안은 AI의 도움을 받아 썼고, 모든 수치는 원본 출력 파일과 대조해 확인했습니다.

JPEG를 다시 압축했는데 왜 더 커지나요?

"품질 80"이 정해진 압축량을 뜻하지 않기 때문입니다. 품질 값은 인코더마다 따로 정한 설정이어서, 인코더가 다르거나 숫자가 다르면 남기는 디테일의 양도 달라집니다.

135 kB짜리 테스트 JPEG는 작은 파일을 만들도록 조정된 mozjpeg로 품질 70에서 만든 것이었습니다. 이 파일을 Chrome 내장 인코더가 품질 80으로 다시 저장하자 168 kB, 24% 큰 파일이 나왔습니다. 브라우저는 JPEG를 일반 픽셀로 디코딩합니다. 이때 mozjpeg가 남긴 블록 모양 압축 노이즈도 함께 픽셀이 됩니다. 그 픽셀을 원본보다 촘촘한 양자화로 다시 인코딩한 것입니다. 처음 압축할 때 잃은 정보는 돌아오지 않고, 새 파일은 같은 그림과 예전 아티팩트를 담느라 바이트를 더 씁니다.

같은 사진을 덜 압축한 250,382바이트 버전은 달랐습니다. Chrome 품질 80으로 저장하니 250,670바이트로, 겨우 288바이트 늘었습니다. 파일을 만든 것과 같은 인코더, 같은 설정으로 다시 저장하면 원래 크기와 거의 똑같이 나옵니다.

저희 압축 도구는 이렇게 처리합니다

저희 압축 도구는 첫 결과를 확인합니다. browser-image-compression은 출력이 원본보다 크거나 목표 크기를 넘으면 직전 품질의 0.95배(PNG는 0.85배)로 다시 인코딩하고, 두 기준을 모두 만족하거나 재시도 횟수가 끝날 때까지 반복합니다. 이 과정에서 가로세로 크기는 파일이 목표 크기를 넘을 때만 줄어들기 때문에, 작은 사진은 픽셀 크기가 그대로 유지됩니다.

250 kB 파일은 품질 0.76으로 한 번 더 인코딩해 240,546바이트, 3.9% 줄었습니다. 135 kB mozjpeg 파일은 일곱 번을 거쳐 품질 0.56까지 내려가서야 134,643바이트가 됐습니다. 이미 압축된 파일에서 품질을 크게 낮추고 얻은 게 508바이트입니다. 결과 카드에 표시된 절감률이 몇 퍼센트 이하라면 원본을 쓰는 편이 낫습니다.

결과가 여전히 작지 않고 포맷도 바뀌지 않았다면 압축 도구는 원본 파일을 그대로 돌려줍니다. 그래서 같은 포맷으로 더 큰 파일을 받는 일은 없습니다.

품질 값에 대한 더 자세한 설명은 JPEG 압축 가이드에 있습니다.

JPG를 PNG로 바꿨더니 왜 이렇게 커지나요?

PNG는 무손실 포맷이라 모든 픽셀을 정확히 저장합니다. 디코딩한 JPEG 사진에는 주변과 조금씩 다른 픽셀이 아주 많습니다. 필름 그레인, 센서 노이즈, JPEG 압축이 남기는 희미한 8 x 8 블록 무늬 같은 것들입니다. 무손실 포맷은 이것을 전부 담아야 합니다.

저희 테스트에서는 JPEG를 강하게 압축했을수록 증가 폭이 컸습니다. 시작 파일은 작아졌는데 PNG가 저장할 픽셀 수는 같기 때문입니다. PNG로 바꾼다고 JPEG에서 생긴 손상이 복구되지도 않습니다. 흐림과 블록 현상은 그대로이고, 이제 그것을 무손실로 보관할 뿐입니다.

JPG → PNG 변환은 PNG가 꼭 필요할 때 쓰세요. PNG만 받는 편집기, 여러 번 고칠 원본 보관용 파일, JPG를 거부하는 업로드 양식 같은 경우입니다. 목적이 용량 줄이기라면 JPG를 유지하거나 WebP·AVIF로 옮기는 게 맞습니다.

PNG를 다시 저장했는데 왜 용량이 늘었나요?

브라우저에서는 두 가지가 불리하게 작용합니다.

첫째, Chrome 캔버스의 PNG 인코더는 받은 파일보다 데이터를 훨씬 느슨하게 압축했습니다. kodim04 사진을 canvas.toBlob으로 다시 저장하자 픽셀은 같은데 637,432바이트가 846,413바이트, 33% 커졌습니다. 신경 써서 무손실로 다시 저장해도 당연히 작아지지는 않습니다. sharp에서 libpng 압축 레벨 9로 저장한 결과는 638,304바이트로, 원래 파일보다 872바이트 컸습니다.

둘째, 캔버스는 모든 이미지를 32비트 RGBA로 다루고 Chrome은 그대로 기록합니다. 팔레트 PNG는 각 픽셀을 작은 색상표의 번호로 저장하는데, TinyPNG나 pngquant가 파일을 작게 만드는 방법이 이것입니다. 로고의 팔레트 버전은 45,525바이트였습니다. 캔버스에 그려 다시 저장하자 색상표가 사라지고 모든 픽셀이 온전히 저장되면서 170,429바이트, 3.7배가 됐습니다.

저희 압축 도구는 PNG에 canvas.toBlob을 그대로 쓰지 않습니다. browser-image-compression은 픽셀을 UPNG에 넘기고, 색상 수 상한을 4096 × 품질로 정합니다. 기본값 0.8이면 3,276색입니다. 같은 실행에서 나온 결과입니다.

이 단계는 색 수를 줄이므로 무손실이 아닙니다. 사진은 고유 색이 31,716개에서 3,277개로, 스크린샷은 2,002개에서 1,314개로 줄었습니다. 이미 최적화된 팔레트 PNG는 더 줄일 여지가 거의 없어서, 저희 도구를 포함해 어떤 도구로 다시 압축해도 얻는 게 별로 없습니다.

스크린샷을 JPG로 저장해도 될까요?

대체로 아닙니다. JPEG는 사진처럼 부드럽게 이어지는 디테일에 맞게 설계됐고, 스크린샷은 단색 면과 글자 주변의 날카로운 경계로 이뤄져 있습니다. Chrome은 JPG를 4:2:0 크로마 서브샘플링으로 저장했는데, 이는 색 정보를 가로세로 모두 밝기의 절반 해상도로 저장하는 방식입니다. 색이 있는 글자와 가는 색선에서 먼저 티가 납니다. 품질 90을 2배로 확대해 보니 PNG와 차이는 잘 보이지 않았지만, 파일은 여전히 더 컸습니다.

사이트가 JPG만 받는다면 PNG → JPG 변환에서 80%로 저장했을 때 PNG보다 작아졌고, 90%에서는 그렇지 않았습니다. WebP를 받는 곳이라면 스크린샷은 PNG → WebP 변환이 더 낫습니다. 가장 작은 파일은 팔레트 PNG였는데, 저희 도구에는 256색 팔레트 모드가 없습니다. 마지막 50 kB까지 줄여야 한다면 pngquant나 Squoosh 같은 도구를 쓰세요. 두 포맷의 장단점은 WebP vs PNG 비교에 정리했습니다.

WebP나 AVIF로 바꿨는데 왜 원본보다 커지나요?

이유는 두 가지이고, 서로 다른 테스트에서 나타났습니다.

이미 압축된 JPEG를 높은 품질로 변환할 때

같은 화질이라면 WebP와 AVIF가 JPEG보다 작은 경우가 많습니다. 하지만 이 비교는 깨끗한 원본에서 시작한다는 전제가 있습니다. JPEG에서 시작하면 새 인코더는 JPEG의 아티팩트를 디테일로 여기고 그대로 재현해야 합니다.

250 kB JPEG는 품질 90 WebP로 바꾸자 250,382바이트에서 269,556바이트로 7.7% 커졌습니다. 포맷보다 품질 값이 더 큰 영향을 줍니다. JPG → WebP 변환을 쓸 때는 슬라이더를 기본값 90%에서 내려 보며 크기를 비교하거나, JPG → AVIF 변환을 시도해 보세요. AVIF가 섬세한 질감을 어떻게 처리하는지는 AVIF 포맷 정리에서 다룹니다.

아주 작은 이미지와 고정 용량

포맷마다 헤더 같은 고정 비용이 있고, 투명도가 있는 손실 WebP는 알파 채널을 따로 저장합니다. 이미지 전체가 504바이트라면 이 비용이 크게 작용합니다.

무손실 WebP는 PNG보다 140바이트 작았지만, 나머지는 AVIF 두 설정을 포함해 대부분 아이콘을 키웠습니다. 아이콘이나 작은 UI 그래픽은 PNG를 그대로 두고, 벡터 원본이 있다면 SVG를 쓰세요. 저희 테스트에서 WebP와 AVIF가 용량을 줄인 건 사진이었지 아이콘이 아니었습니다.

크기를 키우거나 메타데이터를 남기면 용량이 늘까요?

확대하면 디테일은 늘지 않고 바이트만 늘어납니다. 320 x 480 썸네일은 28,034바이트였습니다. 같은 크기로 품질 80 재저장하면 28,513바이트였고, 먼저 640 x 960으로 키우면 62,114바이트로 2.2배가 됐는데 그림은 오히려 더 흐려졌습니다. 저희 압축 도구는 확대하지 않습니다. 1920px 설정은 상한이기 때문입니다. 리사이저는 큰 숫자를 넣으면 확대하므로, 이미지 리사이저에서 내보내기 전에 출력 크기를 확인하세요. 업스케일로 디테일을 되살릴 수 없는 이유는 화질 손실 없이 이미지 크기 조절하기에 설명했습니다.

메타데이터의 영향은 저희 테스트에서 작았습니다. 썸네일에는 480바이트짜리 Display P3 색상 프로파일과 258바이트 EXIF 태그가 들어 있었고, 28,290바이트 중 약 2.6%였습니다. 저희 압축 도구는 기본으로 EXIF를 지우고, "EXIF 유지"를 켰을 때만 남깁니다. 카메라 파일에는 내장 미리보기 이미지처럼 더 큰 블록이 들어 있을 수 있어서, 카메라나 휴대폰에서 작게 내보낸 파일이라면 EXIF 제거가 더 효과가 있을 수 있습니다. GPS 위치 정보도 함께 지워집니다.

GIF를 변환하면 어떻게 되나요?

GIF는 오래된 포맷이지만, 색이 몇 개뿐인 단색 위주의 짧은 애니메이션에서는 작습니다. 팔레트 번호로 저장하고 프레임마다 바뀐 부분만 저장할 수 있기 때문입니다. 단색 배경 위로 점이 움직이는 240 x 240, 12프레임 애니메이션을 그려서 비교했습니다.

어느 쪽도 크기가 크게 달라지지 않았습니다. 이 결과는 작은 단색 애니메이션에만 해당합니다. 사진 프레임으로 된 긴 GIF는 테스트하지 않았는데, 그런 파일은 256색 제한과 디더링 때문에 GIF가 더 불리합니다. 짧은 단색 애니메이션은 GIF로 두어도 괜찮고, 더 줄여야 한다면 GIF 압축 도구부터 써 보세요.

결과가 더 크면 저희 도구는 어떻게 하나요?

위의 처리는 모두 브라우저에서 이뤄지고, 저희 사이트에서는 이미지가 업로드되지 않습니다. 출력이 커졌을 때 도구별 동작은 다음과 같습니다.

• 압축 도구, 원본 포맷 유지: 파일이 원본보다 크면 품질을 낮춰 다시 시도하고, 그래도 작아지지 않으면 원본 파일을 돌려줍니다.
• 압축 도구, 포맷 변경: 더 커져도 변환된 파일을 받습니다. 결과 카드에는 두 크기가 모두 표시되고 퍼센트는 작아졌을 때만 나타나므로, 두 숫자를 직접 비교하세요.
• 변환 도구: 슬라이더 값(손실 포맷은 기본 90%)으로 한 번 인코딩하고 크기는 확인하지 않습니다. 변환의 목적은 포맷이므로 크기는 커질 수도 작아질 수도 있습니다.
• 목표 크기: 파일이 목표를 넘는 동안 매번 품질을 낮추고, "원본 해상도 유지"가 꺼져 있으면 가로세로를 5%씩 줄입니다. 30회가 지나면 멈추고, 도달하지 못한 목표는 카드에 표시됩니다.

다시 압축하거나 변환하기 전 체크리스트

1. 이미 최적화된 파일인가요? CDN, CMS, TinyPNG 같은 도구를 거친 파일이라면 한 번 더 압축해도 줄어드는 양이 적습니다. 저희 도구로는 3.9%와 0.4%였습니다. 이 정도라면 원본을 쓰세요.
2. 사진을 PNG로 옮기나요? PNG가 꼭 필요할 때만 하세요. 저희 JPEG 두 장은 10.7배, 16.4배 커졌습니다.
3. 스크린샷이나 단색 그래픽인가요? PNG를 유지하거나 WebP를 쓰세요. 저희 테스트에서 90% JPG는 PNG보다 컸습니다.
4. 몇 kB도 안 되는 파일인가요? 아이콘은 PNG나 SVG로 두세요. WebP와 AVIF의 헤더가 픽셀 데이터보다 클 수 있습니다.
5. 픽셀 크기가 커졌나요? 저장하기 전에 출력 크기를 확인하세요. 확대하자 썸네일 용량이 두 배로 늘었습니다.
6. 변환 도구가 90%로 되어 있나요? JPG → WebP라면 75~80%로 낮춰 비교해 보세요.
7. 메타데이터가 필요한가요? 공개용 작은 이미지는 EXIF를 지우고, 보관할 사진은 남겨 두세요.

같은 포맷에서 용량만 줄이고 싶다면 압축 도구에서 시작하고, 내려받기 전에 결과 카드의 전후 크기를 비교해 보세요.