2026-08-05
정확한 용량 제한에 맞춰 사진을 압축하는 법 — 몇 번씩 다운로드해서 확인할 필요 없이
평소에는 사진이 몇 킬로바이트인지 아무도 신경 쓰지 않습니다. 그러다 신경 쓸 수밖에 없는 벽에 부딪힙니다 — "메시지가 너무 큽니다"라며 튕겨 나오는 이메일, 그냥 거부당하는 디스코드 업로드, 작은 글씨로 적힌 용량 제한 말고는 아무 설명도 없이 사진을 반려하는 입사지원 양식. 그 순간 중요한 질문은 딱 하나입니다 — 압축하면 이 파일이 실제로 몇 KB가 될까? 이게 왜 생각보다 답하기 어려운 질문인지, 그리고 다운로드하기 전에 실제로 그 답을 아는 방법을 정리했습니다.
실제로 발목을 잡는 용량 제한들
가상의 숫자가 아닙니다. 사람들이 사진을 끊임없이 올리는 몇몇 곳에서 실제로, 지금 이 순간 적용되고 있는 제한이고, 그 크기 차이는 자릿수 두 개 정도 납니다.
| 어디 | 명시된 제한 |
|---|---|
| Gmail 개인 계정 | 이메일 한 통당 25MB — 첨부파일 각각이 아니라 전부 합쳐서 25MB입니다. |
| 디스코드 무료 등급 | 파일당 10MB. 디스코드는 2024년 9월에 25MB였던 걸 다시 10MB로 낮췄는데, 자체 데이터로 이용자의 99%가 어차피 10MB 미만이었다는 게 그 이유였습니다. |
| 한 한국 채용 사이트(career.co.kr)의 자체 이력서 사진 업로드 도구 | 1MB — 디스코드보다 20배 이상, Gmail보다 25배 엄격한, 명시적으로 걸려 있는 제한입니다. |
이 세 숫자를 다 외우고 있는 사람은 없고, 그럴 필요도 없습니다 — 핵심은 숫자를 암기하는 게 아니라, "충분히 작다"는 기준이 어디에 올리느냐에 완전히 달려 있고 그 격차가 엄청나게 크다는 사실입니다.
"품질 80%" 슬라이더가 그 질문에 답하지 못하는 이유
압축 도구의 품질 슬라이더는 인코더에 넣는 입력값이지, 결과 바이트 수에 대한 약속이 아닙니다. 똑같은 80% 설정이라도 단순하고 단색이 많은 그래픽에서는 200KB가 나오고, 픽셀 크기가 똑같은데도 디테일이 많고 노이즈가 있는 사진에서는 4MB가 나올 수 있습니다 — 인코더는 고정 비율을 지키는 게 아니라 이미지에 실제로 담긴 정보량에 반응하는 것뿐입니다. 그리고 출력 형식이 PNG라면, 슬라이더는 눈에 보이는 변화를 아예 만들어내지 못합니다. PNG의 압축은 정의상 무손실이라 "품질"이라는 매개변수 자체가 적용될 자리가 없기 때문입니다(이 블로그의 세 번째 글이 포맷 압축 원리 쪽에서 이미 다룬 바로 그 사실입니다). 어느 쪽이든, 슬라이더 위의 퍼센트 하나로는 정작 필요한 숫자를 알 수 없습니다.
예전 방식: 다운로드하고, 확인하고, 바라기
결과 크기를 미리 볼 방법이 없으면, 알아낼 방법은 실제로 파일을 만들어보는 것뿐입니다 — 다운로드하고, 마우스 우클릭으로 속성(맥이면 정보 가져오기)을 확인하고, 그 숫자를 지금 씨름 중인 제한과 비교하고, 여전히 크면 다시 돌아가서 품질 슬라이더를 조금 더 낮추고, 반복합니다. 되긴 됩니다만 이건 루프이고, 한 바퀴 돌 때마다 실제 다운로드 한 번과 실제 확인 한 번이 듭니다.
바뀐 것: 다운로드 전에 보여주는 진짜 재인코딩
NearIMG의 압축 도구는 이제 각 사진 옆에 — 가로×세로 표시 바로 옆에 — 실시간 "≈" 예상 용량을 보여주고, 품질 슬라이더(또는 출력 형식, 리사이즈 설정)를 조정하다 멈추면 잠시 후 자동으로 갱신됩니다. 숫자처럼 꾸며낸 보간 추정치가 아닙니다. 실제 다운로드가 쓰는 것과 완전히 똑같은 디코드→렌더링→인코딩 파이프라인으로 파일을 실제로 돌려본 뒤, 그 결과 바이트 수만 보고하고 인코딩된 데이터 자체는 버립니다. 사진을 여러 장 한꺼번에 올렸다면, 페이지 상단의 합계 용량에도 같은 "≈" 표시가 붙습니다 — 다만 배치에 포함된 모든 사진에 실측값이 다 채워졌을 때만입니다. 일부는 실측이고 일부는 아직 원본 크기인 채로 섞여서 합계가 오해를 일으키는 일은 없습니다.
실제로 목표에 맞추기
이게 갖춰지면 특정 제한 안에 맞추는 일이 더 이상 시행착오가 아닙니다. 사진을 압축 도구에 넣고, 품질 슬라이더를 조정하면서 퍼센트가 아니라 "≈" 숫자를 보세요. 목표하는 값 — 디스코드의 10MB든, 이력서 포털의 1MB든, 같은 메일에 같이 첨부하는 다른 파일까지 합쳐 25MB인 Gmail이든 — 아래로 여유 있게 내려오면 멈추고, 한 번만 다운로드하면 됩니다. 이미 얼마가 나올지 알고 있으니까요.
이게 못 하는 것 — 숨기지 않는 한계
- AI 업스케일을 켜면 이 숫자는 아무 말도 해주지 못합니다. 이 기능은 일반 압축 파이프라인이 돌기도 전에 사진의 바이트를 완전히 별개인 모델의 결과물로 통째로 바꿔치기하기 때문에, 일반 예상 용량 로직은 그 결과를 예측할 수 없습니다. 틀린 짐작을 보여주는 대신 숫자 자체가 사라집니다.
- 출력 형식이 PNG라면 슬라이더를 아무리 움직여도 숫자가 꿈쩍하지 않습니다. 이건 예상 용량 기능의 버그가 아니라, PNG의 압축이 무손실이라 품질 설정 자체를 무시한다는 사실을 정확히 반영하는 겁니다. 실제로 용량을 조절할 손잡이가 필요하다면, JPEG나 WebP로 바꾸는 게 그 손잡이를 쥐는 방법입니다.
- 숫자는 마지막 조정 이후 대략 0.3초 정도 늦게 따라옵니다. 즉시 반영되는 게 아닙니다 — 미리 계산해둔 표를 찾아보는 게 아니라 실제로 백그라운드에서 인코딩을 돌리는 것이라, 조정을 멈출 때까지 기다렸다가 그제서야 그 작업을 합니다.
한 줄 요약
"충분히 작다"는 하나의 숫자가 아닙니다 — 이력서 사진이면 1MB, 디스코드 업로드면 10MB, Gmail 메시지 전체로 합쳐서 25MB, 아니면 전혀 다른 어딘가가 요구하는 또 다른 숫자입니다. 품질 퍼센트 하나로는 애초에 그 어느 경계선 안쪽에 들어갈지 알 방법이 없었습니다. 설정을 바꾸는 동안 실제로 측정된(짐작이 아닌) 예상 결과 용량을 지켜보는 것, 그게 마침내 그 답을 줍니다.