2026-09-08

업로드가 내 사진을 거부하는 이유 — 네 가지 상한 중 무엇에 걸렸나

업로드가 실패합니다. 안내 문구는 ‘용량’ 어쩌고 하는 애매한 한 줄뿐입니다. 그러면 누구나 같은 반응을 합니다. 압축 사이트에 넣고, 품질 슬라이더를 내리고, 다시 시도. 그게 통할 때도 있습니다. 하지만 아무것도 달라지지 않는 경우도 그만큼 많습니다 — 애초에 내 사진을 거부한 쪽이 바이트를 세고 있던 게 아니기 때문입니다.

‘용량 초과’는 서로 무관한 네 가지 실패가 같은 옷을 입고 있는 상태입니다. 넷은 해법이 전부 다르고, 엉뚱한 해법을 고르는 바람에 화질만 뭉개진 40KB짜리 사진을 만들어 놓고도 여전히 등록이 안 되는 일이 생깁니다. 10초 만에 구분하는 방법을 정리했습니다.

네 가지 상한, 네 가지 해법

1. 바이트 상한 — 압축이 통하는 유일한 경우

익숙한 그 상한입니다. 다만 목적지에 따라 자릿수가 통째로 달라집니다. 한국산업인력공단이 운영하는 큐넷의 공식 사진등록 안내는 등록 가능한 사진파일을 ‘파일형식 *.JPG 또는 *.JPEG, 파일용량 200KB 이하’로 못 박아 두었습니다. 국가기술자격 원서를 넣으려면 피할 수 없는 관문입니다. 반대편 끝에는 깃허브가 있습니다. 공식 문서는 첨부 상한을 “10MB for images and gifs”로 적어 두었습니다 — 큐넷보다 50배 너그럽습니다. ‘충분히 작다’는 절대 기준이 아니라 목적지가 정하는 값입니다.

바이트 상한은 품질 슬라이더가 정확히 맞는 해법인 유일한 경우입니다. JPEG나 WebP를 더 낮은 정밀도로 다시 인코딩하면 가로세로 픽셀은 그대로인 채 파일만 작아집니다. (슬라이더의 퍼센트 숫자가 왜 결과 용량을 예측해 주지 못하는지, 그리고 내려받아 확인하는 반복을 실시간 예상 용량이 어떻게 없애는지는 이 블로그의 다른 글에서 따로 다뤘습니다.)

2. 픽셀 상한 — 압축이 아무 힘도 못 쓰는 곳

픽셀 상한은 가로×세로를 셉니다. 인코더에 무슨 짓을 해도 이 값은 바뀌지 않습니다. 6000×4000 사진을 12MB에서 400KB로 줄여도 여전히 6000×4000, 여전히 24메가픽셀입니다.

쇼피파이의 상품 미디어 문서는 이 둘을 한 문단 안에서 나란히 적어 두어, 왜 사람들이 헷갈리는지를 잘 보여 줍니다. 이미지는 “any size up to 5000 x 5000 px, or 25 megapixels”여야 하고, 별개로 “a file size smaller than 20 MB”여야 등록된다고 되어 있습니다. 서로 독립적인 두 검사입니다. 9000×2500짜리 파노라마는 300KB밖에 안 돼도 두 번째는 통과하고 첫 번째에서 막힙니다.

둘이 무관하다는 걸 가장 선명하게 보여 주는 건 위키백과와 위키미디어 공용을 돌리는 미디어위키입니다. $wgMaxImageArea 매뉴얼은 기본값을 12,500,000픽셀 — 대략 3500×3500 — 로 문서화하면서 그 취지를 “Don't thumbnail an image if it will use too much working memory”라고 적고, “users are still allowed to upload large files”라고 덧붙입니다. 즉 그 값을 넘겨도 업로드 자체는 성공합니다. 대신 Error creating thumbnail: File with dimensions greater than 12.5MP가 뜹니다. 문제는 바이트가 아니라 디코딩된 이미지였던 겁니다.

이 마지막 문장이 원리 전부입니다. 이미지를 디코딩하면 압축 파일이 아무리 작아도 대략 가로×세로×4바이트의 메모리를 씁니다. 그래서 내 사진을 ‘열어야 하는’ 서비스는 — 썸네일을 만들든, 검사하든, 다시 인코딩하든 — 업로드 용량 예산과는 완전히 별개인 픽셀 수 예산을 갖고 있습니다. 구글 포토도 저장 단계에서 같은 논리를 씁니다. 백업 화질 도움말은 저장공간 절약 모드에서 “If a photo is larger than 16 MP, it'll be resized to 16 MP”라고 밝히고 있습니다.

계산은 간단하고, 한 번쯤 해 볼 값어치가 있습니다. 메가픽셀은 가로×세로를 100만으로 나눈 값입니다. 6000×4000은 24MP. 흔한 휴대폰 사진 규격인 4032×3024는 약 12.2MP로 대부분의 상한 아래입니다. 사람들이 소리 없이 선을 넘는 건 대개 파노라마 합성 사진이나 평판 스캐너로 뜬 스캔 파일 쪽입니다 — 파일 용량은 작은데 픽셀만 어마어마한 경우죠.

3. 형식 상한 — 대개는 내 휴대폰 탓

세 번째 실패는 안내가 가장 불친절합니다. 보통 ‘지원하지 않는 파일 형식입니다’ 한 줄로 끝납니다. 깃허브가 10MB 상한을 적어 둔 바로 그 문서의 지원 형식 목록에는 이미지가 넷뿐입니다. PNG, GIF, JPEG, SVG. WebP도 HEIC도 없습니다. 큐넷은 JPG와 JPEG만 받습니다. 그런데 최근 아이폰을 쓴다면 내가 올리려는 사진은 그 목록 어디에도 해당하지 않을 가능성이 큽니다.

애플의 지원 문서 Using HEIF or HEVC media on Apple devices가 그 설정을 설명합니다. 설정 → 카메라 → 포맷에서 ‘높은 호환성(Most Compatible)’을 고르면 “all new photos and videos will then use JPEG or H.264 format”이 됩니다. 같은 문서는 아이폰을 연결해 사진 앱이나 이미지 캡처, PC로 가져올 때 “the media might be converted to JPEG or H.264”라고도 적어 두었습니다. 이 문제가 평소에는 안 보이다가 하필 휴대폰에서 바로 업로드하는 그 한 번에만 터지는 이유가 여기 있습니다. PC를 거치면 변환이 일어나고, 안 거치면 HEIC가 그대로 올라가니까요.

해법은 압축이 아니라 형식 변환입니다. 그리고 이 상한은 다른 상한과 겹칠 수 있습니다. 큐넷은 JPG 이면서 200KB를 요구하므로, HEIC로 찍힌 증명사진은 변환과 압축을 둘 다 거쳐야 등록됩니다.

4. 포맷 자체의 한계 — 아무도 말해 주지 않는 상한

사이트 정책이 전혀 개입하지 않아도, 각 이미지 포맷에는 파일 구조에 새겨진 최대 크기가 있습니다. 가로세로를 적어 두는 헤더 필드의 비트 폭이 정해져 있기 때문입니다. 권고나 관행이 아니라, 그 바이트가 물리적으로 표현할 수 있는 한계입니다.

실무에서 실제로 발목을 잡는 건 WebP입니다. 그림을 스캔하거나 파노라마를 이어 붙인다면 16,383은 결코 큰 숫자가 아닙니다. 가로 20,000픽셀짜리 이미지는 어떻게 인코딩하든, 결과가 아무리 작든 WebP가 될 수 없습니다 — 그 폭을 적어 둘 자리가 포맷에 없습니다. 되는 것처럼 보이는 도구가 있다면 말없이 리사이즈를 해 준 겁니다.

그리고 도구가 브라우저에서 도는 경우라면 — NearIMG도 포함해서 — 이 아래에 다섯 번째 상한이 하나 더 있습니다. MDN의 canvas 요소 문서는 이렇게 적습니다. “the exact maximum size of a canvas element depends on the browser and environment. While in most cases the maximum dimensions exceed 10,000 x 10,000 pixels, notably iOS devices limit the canvas size to only 4,096 x 4,096 pixels.” 그리고 “exceeding the maximum dimensions or area renders the canvas unusable”. 브라우저 기반 이미지 편집기는 전부 이 바닥 위에 서 있습니다.

내 파일의 실제 숫자부터 확인하기

무언가 바꾸기 전에 지금 가진 값을 보세요. 윈도우는 파일 우클릭 → 속성 → 자세히에서 크기와 해상도가 함께 보이고, 맥은 파일을 고르고 Cmd + I를 누르거나 미리보기의 도구 → 크기 조절에서 확인됩니다. 휴대폰은 사진 정보 화면에 같은 두 숫자가 있습니다. 그다음 목적지가 적어 둔 제한을 읽습니다 — 대개 업로드 버튼 옆 작은 글씨 한 줄입니다 — 그리고 항목별로 따로 맞춰 보세요. 바이트는 바이트끼리, 픽셀은 픽셀끼리, 확장자는 허용 목록과.

NearIMG에 파일을 떨어뜨리면 그 읽는 작업은 대신 해 줍니다. 작업 화면의 각 파일에 가로×세로 · 용량이 표시되는데, 파일 이름이 아니라 파일의 실제 바이트에서 읽은 값입니다. 압축·리사이즈 패널에서는 설정을 바꿀 때마다 실제로 인코딩해 본 결과 용량이 갱신됩니다.

네 가지를 한 번에, 내 기기 안에서

NearIMG는 브라우저에서 도는 이미지 도구 모음이고, 떨어뜨린 파일은 어디로도 올라가지 않습니다. 앞의 네 상한에 대응시키면 압축은 바이트를, 리사이즈는 픽셀을 움직이고(비율을 유지하는 픽셀 박스로 맞추거나 퍼센트로 줄이거나), 변환은 JPG·PNG· WebP로 씁니다. 세 설정을 한 번에 함께 적용할 수 있고, 사진 폴더를 통째로 떨어뜨리면 같은 설정이 모든 파일에 적용되어 ZIP 하나로 돌아옵니다 — 스무 장을 전부 같은 규격으로 맞춰 내라는 양식이 요구하는 게 보통 딱 이 모양이니까요.

NearIMG가 할 수 있는 것과 없는 것

상한에 대한 글이니 저희 쪽 상한도 같이 적습니다.

• 입력 용량. 데스크톱 브라우저에서 파일당 100MB, 한 번에 400MB. 휴대폰이거나 기기가 보고하는 메모리가 4GB 이하이면 30MB와 100MB로 내려갑니다. 그보다 큰 파일은 열기 전에 거부됩니다.
• 저희에게도 픽셀 상한이 있습니다. 대략 120메가픽셀을 넘는 이미지는 거부합니다 (앞의 저메모리 기기에서는 40MP). 이유는 위에서 설명한 그대로입니다. 디코딩은 가로×세로×4바이트를 할당하고, 아주 작은 파일이 엄청난 크기를 주장할 수 있습니다. PNG와 SVG는 디코딩 전에 헤더에 적힌 크기를 먼저 읽어서 걸러 냅니다.
• 브라우저의 캔버스 상한은 그대로 적용됩니다. 저희 검사를 통과한 파일이라도 브라우저가 내주는 캔버스에는 너무 클 수 있고, 특히 iOS에서 그렇습니다. 페이지 안에서 저희가 어떻게 해 줄 수 있는 부분이 아닙니다.
• 출력 포맷은 JPG·PNG·WebP뿐입니다. AVIF, TIFF, PSD, SVG 출력은 없습니다. GIF, BMP, HEIC, SVG를 넣으면 셋 중 하나를 고르지 않는 한 PNG로 나옵니다.
• HEIC 입력은 되지만 비용이 붙습니다. 대부분의 브라우저는 HEIC를 디코딩하지 못하므로, HEIC 파일을 실제로 떨어뜨린 경우에만 저희 사이트에서 libheif의 웹어셈블리 빌드(약 1.4MB)를 내려받아 씁니다. AVIF 입력은 브라우저 자체의 AVIF 디코딩 지원에 달려 있습니다.
• 출력 포맷의 물리적 한계는 저희가 대신 확인하지 않습니다. 가로 16,383px을 넘는 이미지에서 WebP를 요구하면 어떻게 되는지는 저희가 아니라 브라우저 인코더가 정합니다. 먼저 리사이즈하세요.
• GIF 만들기는 의도적으로 작습니다. 출력 가로는 240·360·480px 중 하나이고 세로는 1000px에서 잘립니다. 사진 해상도로 만든 움직이는 GIF는 감당이 안 되는 크기가 되기 때문입니다.
• 메타데이터는 남지 않습니다. 모든 결과물은 새로 인코딩된 파일이라 EXIF도 XMP도 컬러 프로파일도 없습니다. GPS 좌표를 지우고 싶을 때는 장점이지만, 원본의 촬영 정보가 필요한 경우라면 문제입니다. 그럴 때는 원본을 손대지 말고 따로 보관하세요.

한 줄 요약

‘용량 초과’는 서로 무관한 네 가지 실패가 같은 문구를 쓰고 있는 것입니다. 바이트는 압축으로 해결됩니다 — 깃허브는 이미지를 10MB, 큐넷은 200KB로 제한합니다. 픽셀은 리사이즈로만 해결되고 압축의 영향을 전혀 받지 않습니다 — 쇼피파이의 5000px/25MP와 20MB라는 별개의 두 제한, 그리고 업로드는 되는데 썸네일이 실패하는 미디어위키의 12.5MP 상한이 그 증거입니다. 형식은 변환으로 해결됩니다 — 깃허브 목록에는 PNG·GIF·JPEG·SVG뿐이고, 내 아이폰은 아마 HEIC로 찍고 있습니다. 그리고 모든 포맷에는 자기 헤더에 새겨진 물리적 한계가 있습니다. WebP는 한 변 16,383px, JPEG와 GIF는 65,535px. 품질 슬라이더에 손대기 전에 내 파일이 실제로 가진 두 숫자부터 보면, 처음부터 맞는 해법을 고를 수 있습니다.