🖼️ 사진을 압축했는데 파일이 8배 커졌습니다 — 품질 100의 함정

사진 용량을 줄이려고 압축 도구에 넣었습니다. 품질은 손해 보기 싫어서 100으로 올렸고요. 결과는 1.6MB짜리 사진이 13.4MB가 됐습니다. 718% 늘어난 셈이에요. 압축했는데 파일이 여덟 배 커지는 상황을 이해하려면 품질 슬라이더가 실제로 무엇을 조절하는지 알아야 했습니다.

압축은 화질을 낮추는 게 아니라 정보를 버리는 일입니다

JPEG 압축은 사람 눈이 잘 못 알아채는 정보부터 버리는 방식입니다. 여기서 중요한 건 한 번 버린 정보는 돌아오지 않는다는 점이에요.

그래서 이미 압축된 JPEG을 다시 압축하면 두 가지 중 하나가 일어납니다. 더 버릴 게 있으면 파일이 줄고, 없으면 줄지 않습니다. 카메라나 휴대폰에서 나온 사진은 이미 상당히 효율적으로 압축돼 있어서 짜낼 여유가 별로 없어요.

여기에 하나 더 있습니다. 다시 압축할 때 도구는 원본을 보는 게 아니라 이미 한 번 정보를 버린 결과물을 보고 다시 버릴 것을 고릅니다. 그래서 같은 파일을 여러 번 저장하면 용량은 별로 안 줄면서 화질만 조금씩 나빠져요. 사진을 편집할 때 중간 저장을 반복하면 어딘가 뿌옇게 뭉개지는 이유가 이겁니다.

문제는 여기서 그치지 않았다는 겁니다. 파일이 안 줄어드는 정도가 아니라 오히려 커졌으니까요.

품질 100은 최고 품질이 아니라 다른 스위치입니다

원인은 크로마 서브샘플링이라는 기법에 있었습니다.

사람 눈은 밝기 변화에는 예민하지만 색상 변화에는 상대적으로 둔합니다. 그래서 대부분의 JPEG은 밝기 정보만 전부 저장하고, 색상 정보는 해상도를 줄여서 저장해요. 네 칸의 색을 하나로 뭉쳐 담는 식입니다. 이걸 4:2:0이라고 부르고, 사진에서는 눈으로 차이를 알아채기 어렵습니다. 대신 용량은 크게 줄어들고요.

여기서 함정이 나옵니다. 품질을 100으로 올리면 이 기법이 꺼집니다. 색상 정보를 하나도 뭉치지 않고 전부 저장하는 상태(4:4:4)가 되는 거예요.

정리하면 이렇게 됩니다.

카메라 원본   색상 정보를 뭉쳐서 저장 (4:2:0) → 1.6MB
품질 100      색상 정보를 전부 저장  (4:4:4) → 13.4MB

같은 사진인데 색상 정보를 담는 방식이 달라졌을 뿐입니다. 품질 슬라이더를 끝까지 올린 게 화질을 조금 더 챙긴 게 아니라, 완전히 다른 저장 방식으로 갈아탄 셈이었어요.

기준은 브라우저마다 다릅니다. 파이어폭스는 품질 90부터 이 기법을 끄는데, 크로미움 계열은 100에서만 끕니다 (출처: WHATWG HTML 저장소 이슈 #5395). 같은 웹 도구를 써도 브라우저가 다르면 결과 용량이 달라질 수 있다는 뜻이에요.

물론 이 기능 자체가 나쁜 건 아닙니다. 색이 있는 글자나 가는 선이 들어간 이미지에서는 색상 정보를 뭉치면 경계가 번져 보이거든요. 그럴 때 품질 100은 유용합니다. 다만 그건 화질을 지키려고 용량을 포기하는 선택이지, 용량을 줄이려는 사람이 고를 자리가 아니었어요. 제 실수는 슬라이더 오른쪽 끝이 그냥 “가장 좋은 값”이라고 생각한 것이었습니다.

그럼 어디에 맞춰야 할까

경험적으로는 85에서 90 사이가 무난했습니다. 이 구간에서는 색상 정보를 적당히 뭉치면서도 눈에 띄는 열화가 잘 안 보입니다.

다만 사진이 아닌 이미지는 얘기가 다릅니다. 색이 있는 글자나 선이 들어간 이미지, 스크린샷 같은 것들은 색상 정보를 뭉치면 경계가 번져 보여요. 이런 이미지는 애초에 JPEG이 아니라 PNG로 저장하는 게 맞습니다. 색상 경계가 뚜렷한 그림은 JPEG이 가장 못하는 종류거든요.

용량을 확실히 줄여야 한다면 품질을 만지기 전에 크기부터 줄이는 게 효율적입니다. 가로폭을 절반으로 줄이면 픽셀 수는 4분의 1이 되니까요. 웹에 올릴 사진이라면 원본 해상도가 필요한 경우가 많지 않습니다.

원인이 늘 원리 쪽에 있는 건 아닙니다

같은 도구에서 이상한 사례를 하나 더 만났습니다. 픽셀 수를 20%로 줄였는데 파일이 오히려 2.6배 커진 경우였어요. 이건 서브샘플링과 무관했습니다.

크기를 줄이는 처리가 끝나기 전에 저장이 먼저 실행되는 순서 문제였습니다. 원본 그대로 인코딩된 결과가 저장된 거예요. 원리로 설명되는 현상이 아니라 그냥 도구 쪽 결함이었습니다.

이런 경우를 가려내는 방법은 단순합니다. 저장된 파일의 실제 크기를 확인해보는 것이에요. 가로세로 픽셀 수가 줄어 있는데 용량만 커졌다면 인코딩 설정 문제고, 픽셀 수가 그대로라면 처리 자체가 안 걸린 겁니다. 숫자 두 개만 보면 어느 쪽인지 나옵니다.

정리

압축했는데 파일이 커졌다면 대개 품질을 최대로 올린 게 원인입니다. 품질 100은 화질을 조금 더 챙기는 설정이 아니라 색상 정보를 전부 저장하는 다른 모드예요. 사진이라면 85~90 근처에서 멈추고, 색 경계가 뚜렷한 이미지는 PNG로 보내고, 용량이 급하면 품질보다 크기를 먼저 줄이는 편이 낫습니다.

그리고 결과가 예상과 정반대로 나올 때는 원리를 더 파기 전에 도구를 한 번 의심해보세요. 저는 원리 쪽만 들여다보다 한참 돌아갔습니다.