사진 용량 줄이기, 픽셀 크기를 지켜야 할 때

업로드 한도와 최소 해상도를 함께 맞추려면, 언제 크기를 바꾸고 언제 저장 품질을 조정해야 할까.

사진 용량 줄이기는 업로드 창이 요구하는 조건을 먼저 읽는 일이다. 허용하는 파일 형식, 필요한 가로·세로 픽셀 수, 최대 용량을 함께 확인한다. 원본은 남겨 두고 제출할 사본을 만든다. 픽셀을 줄일 여유가 있으면 크기를 조정하고, 이미 필요한 크기라면 그 크기를 유지한 채 저장 품질을 조정한다.

설정 숫자를 바꿨다는 사실만으로 작업이 끝나지는 않는다. 저장한 사본을 다시 열어 실제 바이트와 픽셀 크기, 중요한 부분이 읽히는지를 확인해야 한다. 가장 작은 파일을 만드는 것보다, 받는 곳의 조건 안에 필요한 내용을 남기는 것이 목적이다.

여기서는 사진형 합성 이미지와 문자·가는 선으로 만든 시험 이미지에 같은 두 조정을 적용했다. 크기를 바꾼 결과와 같은 크기에서 저장 품질만 바꾼 결과를 나누어 비교한다. 실제 수치는 이 두 입력과 명시한 설정의 결과다. 휴대폰 사진 전체의 평균이나 모든 압축 앱의 성능으로 읽을 수는 없다.

사진 용량 줄이기 전에 읽을 제출 조건

사진 용량 줄이기에서 먼저 구별할 ‘크기’는 한 가지 숫자가 아니다. 1200×800픽셀은 가로와 세로에 놓인 점의 수를, 300,000바이트는 저장된 파일의 데이터 양을 말한다. 화면에서 사진을 작게 표시하는 일은 둘 중 어느 값을 바꾼 것인지부터 확인해야 한다. 웹페이지의 표시 폭만 줄였을 수도 있기 때문이다.

이 글에서는 해상도를 가로·세로 픽셀 수라는 뜻으로 쓴다. 인쇄 안내문의 DPI나 cm 규격은 별도로 읽어야 한다. 사진의 내용·비율·허용 편집까지 정해진 제출처라면 용량과 픽셀만 맞췄다고 전체 요건을 충족한 것은 아니다. 특히 실제 접수 규격은 해당 접수 화면의 현재 안내를 기준으로 삼는다.

먼저 형식을 본다. JPG만 받는 곳에서는 작은 PNG나 WebP도 제출 조건에 맞지 않을 수 있다. 확장자 이름만 .jpg로 고치는 것으로 형식이 변하지는 않는다. 변환이 필요하면 실제로 허용 형식으로 내보내야 한다. 투명 배경이나 작은 글자가 중요한 이미지라면 그 변환이 필요한 성질을 바꾸는지도 따로 살핀다.

다음은 최소 픽셀과 최대 바이트다. JPG를 받는 가상의 업로드 칸이 가로 1,200·세로 800픽셀 이상, 300,000바이트 이하를 요구한다고 하자. 아래 A·B·C는 판단을 설명하기 위해 정한 가정값이며, 실제 기관 규격이나 압축 시험 결과가 아니다. 세 사본은 모두 가로:세로가 3:2라는 조건도 같다.

A는 용량 한도 아래지만 픽셀이 부족하다. B는 픽셀 크기가 맞아도 바이트가 한도를 넘는다. C는 두 숫자 조건의 경계에 들어온다. ‘이상’과 ‘이하’라는 가정에서는 경계값도 포함된다. 다만 C의 파일 내용이나 읽힘, 실제 접수 성공까지 확인한 것은 아니다.

사진 용량 줄이기에서 바이트만 작아진 결과를 고르면 A를 놓치게 된다. 반대로 큰 사진을 그대로 두고 품질만 계속 낮추면, 줄여도 되는 픽셀까지 남긴 채 세부 표현만 희생할 수 있다. 다음 조정은 파일의 현재 크기가 최소 조건에서 얼마나 여유가 있는지에 따라 달라진다.

사진 용량 줄이기 전후의 값이 KB·MB로 표시되고 한도 가까이에 있으면 표시 방식과 반올림도 살핀다. 이 글의 표는 혼동을 줄이기 위해 실제 파일의 바이트 수를 그대로 적었다. 시험의 300,000바이트를 모든 서비스의 ‘300KB’ 정의로 바꾸지 않는다. 제출처가 바이트 기준을 명시했다면 그 정의로 대조하고, 표시값만으로 뜻이 분명하지 않으면 한도에 딱 붙은 수치의 해석을 단정하지 않는다.

사진 크기를 줄일 수 있는 범위

현재 사진이 필요한 최소 크기보다 충분히 크면, 비율을 유지하며 가로·세로를 줄이는 방법을 먼저 검토할 수 있다. 다만 ‘늘 긴 변을 1200으로’ 같은 공통 처방을 적용하지는 않는다. 가로와 세로를 각각 검사해야 하고, 최대 픽셀·고정 비율·크롭 조건이 따로 있는지도 확인해야 한다.

세로 사진으로 사진 용량 줄이기를 할 때는 긴 변만 보는 규칙이 특히 쉽게 어긋난다. 가로 1500·세로 2000픽셀인 가정 사진에 앞의 최소 1200×800 조건을 적용해 보자. 긴 변인 세로를 1200으로 줄이면 가로는 900이 된다. 세로는 800 이상이지만 가로가 1200보다 작아, 이 사본은 두 픽셀 조건을 함께 만족하지 못한다. 세로 사진이라는 이유로 가로와 세로의 요구를 서로 바꿔 읽을 수는 없다.

같은 사진에서 가로를 1200으로 줄이고 비율을 유지하면 세로는 1600이 된다. 이 경우 두 최소 치수는 남는다. 이미지 용량 줄이기의 크기 선택은 이처럼 두 변을 함께 계산한 뒤 판단한다. 다만 1200×1600이 되었다는 계산으로 바이트 한도나 실제 접수 성공까지 알 수는 없다. 제출처가 정확히 1200×800의 가로 사진을 요구한다면, 이 예시와 다른 조건이며 비율·크롭 허용 여부부터 다시 읽어야 한다.

가로·세로를 각각 절반으로 줄이면 전체 픽셀 수는 4분의 1이 된다. 이는 점의 개수에 대한 계산이다. 압축된 파일의 바이트까지 4분의 1이라고 계산할 수는 없다. 화면의 내용, 저장 방식, 함께 담긴 정보와 인코딩 설정이 파일 크기에 관여하기 때문이다.

이미지 용량 줄이기의 실제 비교에는 1536×1024픽셀의 입력 두 장을 사용했다. 하나는 잎맥·천의 결·과일 표면이 있는 사진형 합성 이미지, 다른 하나는 여러 크기의 한글·숫자와 가는 선으로 만든 이미지다. 두 입력의 내용은 다르지만 가로·세로, RGB 각 채널 8비트라는 조건은 같다. 실제 촬영 사진이나 개인정보가 담긴 서류를 사용한 시험은 아니다.

이미지 용량 줄이기 비교의 공통 설정

크기 비교는 같은 입력에서 1536×1024, 1350×900, 1200×800픽셀로 각각 만들었다. 모든 결과를 JPG로 저장하고 품질 값은 85로 고정했다. 축소에는 Lanczos 리샘플링을 사용했다. 리샘플링은 바뀐 픽셀 수에 맞춰 새 픽셀 값을 계산하는 처리다. 크롭·회전·선명화는 추가하지 않았다.

실행 환경은 Python 3.12.14, Pillow 12.3.0, libjpeg-turbo 3.1.4.1이다. JPEG의 색차 정보를 다루는 서브샘플링은 4:4:4로 고정했고, 추가 최적화(optimize)와 점진 표시(progressive)는 껐다. 모든 JPEG 출력에 EXIF와 ICC 프로필을 따로 넣지 않았다. 이 조건은 비교 변수를 맞추기 위한 선택이며, 모든 실제 사진에서 프로필이나 촬영 정보를 지워야 한다는 권장 사항은 아니다.

각 결과는 최초 입력에서 따로 만들었다. 1536픽셀 JPG를 다시 줄여 1350픽셀 JPG를 만들고, 그 파일을 또 줄여 1200픽셀로 만든 연쇄 저장이 아니다. 입력과 처리 조건을 맞춰야 결과의 차이를 어떤 조정과 연결할지 읽을 수 있다. Pillow의 resize 문서는 출력 픽셀 크기와 리샘플링을, JPEG 문서는 저장 옵션을 별도로 설명한다.

두 입력 모두 이 설정에서는 픽셀을 줄였을 때 파일이 작아졌다. 그러나 최소 크기인 1200×800픽셀에 도달한 뒤의 판단은 달랐다. 문자·선 입력의 224,379바이트는 가정한 한도 아래다. 사진형 입력의 409,095바이트는 아직 한도를 넘는다. 같은 크기·같은 품질 값이 같은 바이트 수를 만들지는 않았다.

사진형 입력의 1536×1024 출력과 1200×800 출력은 각각 1,572,864개와 960,000개의 픽셀을 가진다. 처음 픽셀의 약 61%를 남긴 셈이지만, 사진형 파일의 바이트 비율은 그 값과 같지 않다. 정확한 바이트는 표의 결과로 읽어야 한다. 픽셀 개수의 비율을 곧바로 저장 용량 감소율로 바꾸지 않는 이유다.

이미지 용량 줄이기 뒤 작은 미리보기만으로 축소가 괜찮았다고 판단하기도 어렵다. 페이지에 맞춰 두 이미지를 비슷한 폭으로 표시하면 필요한 세부가 가려질 수 있다. 반대로 크게 확대한 픽셀 경계를 일상적인 표시 크기의 손상과 같게 볼 수도 없다. 전체 장면은 사용할 크기로 보고, 중요한 글자·얼굴 윤곽·선 같은 부분은 별도로 확인하는 편이 낫다. 무엇을 읽어야 하는 사진인지가 먼저다.

사진형 결과는 최소 픽셀 크기에 도달했는데도 바이트 한도를 넘었다. 여기서 더 줄여 한도를 맞추면 픽셀 조건을 깨는 쪽으로 갈 수 있다. 크기를 더 바꾸기 전에, 현재 픽셀을 유지하고 저장 품질을 조정하는 다른 경로를 살펴볼 차례다.

픽셀을 유지한 JPG 용량 줄이기

JPG 용량 줄이기에서 저장 품질 조정은 가로·세로 픽셀 수를 줄이는 일과 다르다. 같은 1200×800픽셀이어도 JPEG로 담는 설정이 달라지면 저장된 바이트와 디코딩한 픽셀 값이 달라질 수 있다. 외곽 크기를 지켰다는 사실이 원래 세부 표현까지 그대로 보존했다는 뜻은 아니다.

이번에는 각 최초 입력을 같은 1200×800픽셀로 줄인 뒤, 품질 85·65·45의 JPG를 각각 저장했다. 품질 이외의 설정은 앞 비교와 같게 두었다. 품질 85 결과는 앞 표와 같은 파일을 사용했다. 아래 각 행은 같은 입력·같은 픽셀 크기에서 저장 품질만 바꾼 결과다.

사진형 입력은 품질 65에서 가정한 두 숫자 조건을 함께 만족했다. 1200×800픽셀을 남긴 채 245,644바이트가 됐다. 품질 45는 더 작았지만, 이미 65에서 바이트 한도 안에 들어왔으므로 45가 무조건 더 좋은 선택은 아니다. 남겨야 할 세부와 실제 사용 크기에서의 읽힘을 함께 볼 이유가 남는다.

여기서 품질 65를 JPG 용량 줄이기의 최적값으로 확정할 수는 없다. 이 시험은 85·65·45만 비교했으므로, 85와 65 사이의 다른 값이 한도를 만족하는지는 측정하지 않았다. 자기 파일에서 더 높은 품질을 남기고 싶다면 같은 입력과 픽셀 크기를 고정한 채 그 사이 값을 별도 사본으로 시험할 수 있다. 이는 다음 조정 방법의 제안이며, 이 글에서 그 중간값의 바이트를 확인했다는 뜻은 아니다.

사진 용량 줄이기에서 이런 재시도는 한 번에 한 변수를 바꿀 때 비교하기 쉽다. 새 결과가 한도 아래로 내려왔더라도 중요한 부분의 읽힘을 함께 보고, 이전 결과보다 무조건 더 낫다고 고르지 않는다. 한도 안에 들어오는 사본을 찾았다면 무엇을 더 남기려는지 분명한 이유 없이 계속 낮추지 않는다. 품질 값을 더 촘촘히 시험하는 일과 작은 글자가 필요한 용도에 충분한지 판단하는 일은 서로 다른 확인이다.

JPG 용량 줄이기를 적용한 문자·선 입력은 같은 크기의 품질 85부터 한도 아래였다. 이 경우 파일을 더 작게 만들 수 있다는 이유만으로 품질을 계속 낮출 필요는 없다. 아래 확대에서는 품질 45 쪽 글자 주변의 얼룩과 경계 변화가 더 눈에 띈다. 이는 해당 시험 이미지의 같은 부위를 확대한 관찰이다. 모든 글자가 읽히지 않는다거나, 모든 사람이 같은 정도의 차이를 느낀다는 판정은 아니다.

품질 숫자가 알려 주지 않는 것

JPG 용량 줄이기에서 품질 65는 ‘원래 정보가 65% 남았다’는 뜻이 아니다. 이번 Pillow의 저장 설정 값이다. 다른 프로그램의 품질 65나 ‘보통’과 같은 척도라고 볼 수도 없다. 숫자만 복사하면 같은 바이트나 같은 화질이 나온다고 보장할 수 없는 이유다.

Pillow의 JPEG 안내는 quality와 함께 subsampling, optimize, progressive 같은 옵션을 구별한다. 현재 문서의 버전은 13.0.0이며, 이 글의 직접 실행은 위에 적은 12.3.0 환경이다. 이 표를 다른 버전·다른 앱·다른 기본값의 결과로 바꾸어 읽지 않는다.

JPG 용량 줄이기 뒤 품질을 최대로 두는 것도 이미 받은 JPG보다 앞선 세부를 되찾는 방법은 아니다. 이미 손실된 입력을 더 큰 파일로 저장할 수는 있어도, 더 커진 바이트 자체가 사라진 정보를 복원했다는 증거가 되지는 않는다. 형식이나 품질 숫자보다 어떤 입력에서 어떤 처리를 거쳤는지를 함께 보는 편이 정확하다.

원본에 충분한 픽셀이 없을 때는 별도 문제가 생긴다. 작은 이미지를 크게 늘려 최소 숫자만 맞추어도, 처음부터 더 세밀한 사진이었던 것으로 바뀌지는 않는다. 이 글의 비교는 필요한 픽셀이 있는 입력을 줄이는 작업이다. 픽셀이 모자란 파일의 복원 성능이나 기관의 업스케일 허용 여부를 시험한 결과가 아니다.

직접 조정할 때 볼 화면

브라우저 도구의 한 예로 Squoosh가 있다. 2026년 11월 4일 화면에서 Resize, Width, Height, Maintain aspect ratio, 출력 형식과 Quality 조절, Download 항목을 확인했다. 아래 순서는 이 조작 항목을 읽는 방법이다. 앞의 실제 바이트 표는 Squoosh가 아니라 Pillow에서 만든 결과이므로 두 프로그램의 품질 숫자를 같은 답으로 쓰지 않는다.

1. 원본을 보존하고, 조정할 이미지의 사본을 연다. 공개할 수 없는 사진이라면 사용하는 도구의 처리·보관 방식을 먼저 확인한다.
2. 픽셀을 줄일 여유가 있다면 Resize를 켠다. Maintain aspect ratio를 유지한 채 Width나 Height를 바꾸고, 자동으로 계산된 다른 변도 최소 조건에 남는지 본다.
3. 받는 곳이 허용하는 출력 형식을 고른다. 이번에 확인한 화면에는 MozJPEG가 있었으며, JPG를 만들 때 검토할 항목이다. 형식을 바꾼 뒤에도 원래 필요한 투명도·읽힘 등의 조건을 확인한다.
4. 더 줄일 수 없는 픽셀 크기에서는 Width·Height를 그대로 두고 Quality를 조정한다. 화면에 표시된 용량 변화를 보되, 특정 숫자를 모든 사진의 정답으로 쓰지 않는다.
5. 출력 쪽 Download로 사본을 저장하고, 저장한 파일의 실제 정보와 내용을 다시 확인한다. 화면의 예상 표시를 다운로드 파일의 바이트 검증으로 대신하지 않는다.

비율 유지의 결과도 확인 대상이다. 공식 예제 사진의 가로를 1200으로 바꾸자 세로는 803으로 표시됐다. 1200×800이라는 예시 숫자를 맞추려고 두 변을 무조건 따로 바꾸면 원래 비율을 바꾸는 일이 될 수 있다. 고정 비율이나 정확한 치수가 필요한 제출이라면 먼저 그 조건을 해석하고, 필요한 크롭이 허용되는지도 따로 판단한다.

Squoosh의 공식 설명은 이미지 자체를 서버로 보내지 않고 기기 안에서 처리한다고 밝힌다. 동시에 방문 정보와 처리 전후 파일 크기 등에 Google Analytics를 사용한다고 적고 있다. 따라서 ‘이미지 서버 미전송’을 ‘어떤 정보도 전송되지 않는다’로 확대해서는 안 된다. 다른 압축 사이트에도 같은 설명을 그대로 적용할 수 없다.

이미지 용량 줄이기 도구를 고를 때 핵심은 이름이나 첫 화면의 절감률보다 결과를 확인할 수 있는가에 있다. 픽셀을 유지할 수 있는지, 원본과 출력을 구별할 수 있는지, 실제 저장 파일을 다시 열어 볼 수 있는지 살핀다. 특정 도구가 열리지 않더라도 최소 픽셀·최대 바이트·중요 부분의 읽힘이라는 판단 기준은 그대로 사용할 수 있다.

저장한 사본을 다시 확인한다

사진 용량 줄이기의 마지막 대상은 설정창이 아니라 저장한 사본이다. 원래 받은 파일과 새 파일의 이름이나 위치를 구별해 두면, 어떤 결과를 확인하고 있는지 놓치기 어렵다. ‘이전보다 작아졌다’는 말도 어느 파일과 비교했는지가 분명할 때 의미가 있다.

사진 용량 줄이기를 마치면 파일 속성이나 이미지 정보에서 실제 바이트와 가로·세로 픽셀을 읽고, 파일을 다시 열어 내용도 본다. 파일 형식·회전·잘린 부분이 요구에 맞는지 함께 확인한다. 시험에서는 만든 JPEG 10개를 모두 다시 열어 형식·픽셀 크기를 확인했고, 파일 바이트를 별도로 읽었다. 출력 파일에 붙은 숫자만 믿고 내용 확인을 생략한 것은 아니다.

이미지 용량 줄이기의 확인 순서를 파일 정보와 내용으로 나누면 놓친 조건을 찾기 쉽다. 먼저 선택한 파일이 방금 내보낸 사본인지 이름과 위치로 확인한다. 다음으로 바이트·가로·세로를 안내문과 대조하고, 마지막으로 실제 사용할 표시 크기에서 필요한 글자나 윤곽을 읽는다. 확대창은 차이가 생긴 부위를 찾는 데 쓰되, 그 배율의 인상을 전체 사용 품질로 일반화하지 않는다. 수치가 맞는 파일도 내용 확인에서 제외될 수 있다.

• 용량: 실제 파일이 최대 바이트 기준 안에 있는가. 화면의 반올림된 KB·MB와 혼동하지 않았는가.
• 픽셀: 가로와 세로가 각각 필요한 범위에 남아 있는가. 표시 크기만 바꾼 것으로 착각하지 않았는가.
• 형식과 내용: 받는 형식으로 실제 저장됐는가. 필요한 비율·회전·내용을 바꾸지 않았는가.
• 읽힘: 사용하려는 크기와 중요한 부분에서 필요한 내용을 확인할 수 있는가. 작은 글자나 경계를 놓치지 않았는가.

읽힘은 바이트나 픽셀 개수만으로 대신 판단할 수 없다. 숫자 조건에 맞는 흐릿한 사진도 있을 수 있고, 작은 미리보기에서는 괜찮아 보이던 글자가 실제로 사용할 때 문제가 될 수 있다. 반대로 12배 확대에서 보이는 모든 차이가 일상적인 표시 크기에서 같은 정도로 눈에 띄는 것도 아니다. 비교의 배율과 용도를 함께 남겨야 한다.

한도에 맞지 않을 때 돌아갈 곳

필요한 픽셀은 충분하고 용량만 초과했다면 같은 보관본에서 설정을 바꾸어 다시 내보낸다. 이미 압축한 사본을 여러 번 이어서 저장하는 경로와 구별한다. 다음 결과를 앞 결과와 비교할 때도 입력과 변경한 설정을 남겨 두면, 무엇을 바꿔 차이가 났는지 따라갈 수 있다.

최소 픽셀까지 줄였는데도 용량을 넘으면 크기를 더 낮추는 것은 조건을 깨는 해결이 될 수 있다. 같은 픽셀에서 품질을 조정한 결과를 확인한다. 그래도 중요한 부분이 읽히지 않거나 내용 요건을 지킬 수 없다면, 그 사본을 제출용으로 고르지 않는다. 허용되는 다른 형식이 있는지, 더 적합한 원본을 받을 수 있는지 확인할 차례다.

용량과 픽셀이 맞는데 업로드가 거절됐다면 파일 크기만 더 줄이지 않는다. 형식, 내용 규정, 회전, 제출처의 실제 오류 메시지처럼 아직 확인하지 않은 다른 조건을 살핀다. 이 글의 시험은 가정한 두 숫자 조건을 대조한 것이지 특정 접수 시스템의 성공을 검증한 결과가 아니다.

사진 용량 줄이기를 다시 시도할 때는 실패한 조건을 짧게 남겨 둘 수 있다. 예를 들어 ‘픽셀은 맞고 바이트 초과’와 ‘바이트는 맞고 작은 글자 확인 필요’는 다음 행동이 다르다. 파일 이름이나 작업 메모에 입력 이름, 출력 픽셀, 바꾼 품질 값을 구별해 두면 여러 사본을 뒤섞지 않는 데 도움이 된다. 이런 표시는 작업을 따라가기 위한 기록이며, 실제 파일을 다시 열어 확인하는 절차나 제출처의 판단을 대신하지 않는다.

원본 보관은 촬영·편집 정보까지 모두 남았다는 선언과도 다르다. 도구가 내보낸 사본에 어떤 메타데이터가 유지되는지는 별도 확인 사항이다. 원래 파일에 있던 위치·촬영 정보가 꼭 없어졌다고 가정해서도, 새 사본에 꼭 남았다고 가정해서도 안 된다. 필요한 보관본을 덮어쓰지 않는 것과 전달할 사본의 정보 범위를 확인하는 일을 나누어 생각한다.

필요한 픽셀 안에서 바이트 한도를 맞추고, 남겨야 할 내용이 읽히는지 확인한다. 사진 용량 줄이기의 기준은 이 세 가지를 같은 사본에 다시 맞대는 데 있다. 다음 조정이 필요할 때 돌아갈 원본까지 남아 있다면, 가장 작게 만든 파일이 아니라 다음 작업을 이어 갈 수 있는 파일을 고를 수 있다.

함께 읽기

참고자료

• Pillow, Image.resize — 출력 픽셀 크기와 리샘플링.
• Pillow, JPEG 저장 옵션 — quality·subsampling·최적화 등의 구별. 현재 문서와 직접 실행 환경의 버전을 본문에서 구별했다.
• Squoosh 공식 저장소·개인정보 설명 — 기기 내 이미지 처리와 수집 정보의 범위.

비교 실행일과 화면 확인일은 2026년 11월 4일이다. 바이트 표는 두 합성 입력을 명시한 설정으로 저장한 결과이며, 모든 사진·기기·편집 프로그램의 품질이나 실제 제출처의 접수 결과를 평가한 자료는 아니다.