1MB 파일인데 업로드가 안 될 때: MB·MiB와 바이트 수 확인하기

화면에 보이는 1MB만으로는 부족합니다

파일 목록에는 1MB로 보이는데 첨부 화면에서는 용량을 초과했다고 나올 수 있습니다. 이때는 파일을 다시 만들기 전에 정확한 바이트 수와 서비스의 제한 조건을 확인하세요. 바이트(B)는 파일 크기를 세는 기본 단위입니다.

같은 파일도 큰 단위로 바꾸거나 소수점을 반올림하면 표시가 달라집니다. 반대로 화면에 같은 크기로 표시된 두 파일의 실제 바이트 수가 다를 수도 있습니다.

이 글에서는 문자 A만 담은 텍스트 파일3개를 만들었습니다. 디스크에서 읽은 크기와 브라우저가 읽은 크기를 비교했습니다. 특정 사이트에 업로드하거나 실제 거절 사례를 재현한 실험은 아닙니다. 서비스마다 다른 제한을 하나의 규칙으로 단정하지 않기 위해, 비교 조건도 따로 적었습니다.

MB와 MiB는 나누는 수가 다릅니다

MB는 메가바이트, MiB는 메비바이트입니다. 두 단위는 다음처럼 다릅니다. NIST의 단위 비교표에서도 이 구분을 확인할 수 있습니다.

예를 들어 1,048,576바이트 파일은 정확히 1MiB입니다. MB로 바꾸면 1.048576MB입니다. 파일 내용이 바뀐 것이 아니라 나누는 수가 바뀐 것입니다.

서비스 안내에 ‘1MB’라고만 쓰여 있다면 내부에서 어떤 숫자로 비교하는지는 그 안내만으로 알 수 없습니다. 도움말에 정확한 바이트 수가 있는지 확인하세요. 명시된 값이 없으면 운영자에게 문의하거나 복사본을 조금 더 줄여 다시 시도하세요.

파일3개의 실제 측정 결과

2026년10월21일 macOS에서 Node.js 24.11.0으로 파일을 만들었습니다. 각 파일에는 A를 정해진 횟수만큼 저장했습니다. 줄바꿈이나 다른 문자는 추가하지 않았습니다. 파일 자체의 크기를 읽은 뒤 Chromium 151에서 페이지의 파일 입력 칸에 같은 파일을 자동으로 넣었습니다.

브라우저에서는 선택한 파일의 File.size를 읽었습니다. 이 값은 바이트 수입니다. MDN의 size 설명은 File과 Blob의 크기를 바이트 단위로 반환한다고 안내합니다.

환산값은 소수점6자리로 반올림했습니다. 세 파일 모두 디스크에서 읽은 크기와 File.size가 일치했습니다. 표가 잘리면 좌우로 넘겨 나머지 값을 확인하세요. 원본 측정 기록에는 실행 환경과 파일별 SHA-256도 담았습니다. SHA-256은 파일 내용을 비교할 때 쓰는 고정 길이의 값입니다. 사용 방법은 파일 해시 비교 글에서 확인할 수 있습니다.

첫 번째와 두 번째 파일을 MB로 바꾸고 소수점2자리까지만 표시하면 둘 다 1.00MB입니다. 하지만 실제로는 1바이트 차이가 납니다. 이 표시는 실험 코드에서 만든 반올림 결과이며, 모든 파일 관리자가 이렇게 표시한다는 뜻은 아닙니다.

또 어떤 프로그램이 MiB로 계산한 값을 MB라고 표시한다고 가정해 보세요. 세 번째 파일은 화면에서 1MB로 보이지만 1,000,000바이트 제한은 넘습니다. 특정 프로그램의 동작을 측정한 결과가 아니라, 단위 표시가 모호할 때 생길 수 있는 상황을 설명한 예입니다.

‘이하’와 ‘미만’도 결과가 다릅니다

같은 파일에 다음 두 가지 조건을 직접 적용했습니다. 여기서 제한은 1,000,000바이트로 정했습니다.

‘이하’는 경계값을 포함하고 ‘미만’은 포함하지 않습니다. 같은 1,000,000바이트 파일도 ‘이하’ 조건에서는 통과하고 ‘미만’ 조건에서는 통과하지 못합니다. 실패 원인을 찾을 때는 단위와 경계 조건을 함께 확인하세요.

내 파일의 정확한 크기를 확인하는 순서

먼저 첨부하려는 파일1개를 고르세요. 파일 관리자의 정보·속성 창에 바이트 수가 표시되면 그 값을 적습니다. 디스크에서 차지하는 공간이 아니라 파일 자체의 크기를 확인하세요. 사용 중인 프로그램이 반올림한 값만 보여 준다면 아래 명령으로도 확인할 수 있습니다.

Windows PowerShell

PowerShell을 열고 파일의 전체 경로를 넣어 실행하세요. 다음 경로는 예시이므로 내 파일 경로로 바꿔야 합니다. 작은따옴표는 그대로 두세요. ‘경로로 복사’로 가져온 경로에 큰따옴표가 붙어 있다면 큰따옴표를 지우고 작은따옴표 안에 넣으세요. 경로 자체에 작은따옴표가 있으면 그 문자 하나를 작은따옴표2개로 적어야 합니다.

(Get-Item -LiteralPath 'C:\Users\Lake\Downloads\photo.jpg').Length

출력되는 정수가 파일의 바이트 수입니다. -LiteralPath는 경로의 대괄호 같은 문자를 검색 기호로 해석하지 않도록 합니다. Microsoft의 Get-Item 문서와 FileInfo.Length 문서를 기준으로 작성했습니다. Windows PowerShell에서는 이번에 직접 실행하지 않았습니다.

macOS 터미널

터미널에 stat -f %z 를 입력하세요. 마지막에 공백을 넣고 Finder의 파일을 터미널로 끌어 놓은 다음 Enter를 누르세요. 파일 경로가 자동으로 채워집니다. 공백 앞에 \가 붙어도 지우지 말고 그대로 실행하세요. 명령의 모양은 다음과 같습니다.

stat -f %z '/Users/Lake/Downloads/photo.jpg'

이 명령도 바이트 수를 정수로 출력합니다. 이번에 만든 예제 파일3개에서 직접 실행해 표와 같은 값을 확인했습니다. macOS용 명령이므로 Linux에서는 그대로 사용하지 마세요.

제한을 넘었다면 복사본부터 줄이세요

1. 서비스 안내에서 파일1개 제한인지 첨부 전체의 합계 제한인지 확인하세요.
2. MB·MiB 또는 정확한 바이트 수, ‘이하·미만’ 조건을 확인하세요.
3. 실제로 선택한 파일의 바이트 수와 비교하세요. 원본과 수정본의 이름이 비슷하면 경로도 확인하세요.
4. 초과했다면 원본은 보존하고 복사본을 줄이세요. 사진은 크기 축소와 화질 조절의 차이를 보고 방법을 고를 수 있습니다.
5. 수정본을 저장한 뒤 크기를 다시 읽고, 첨부 목록의 이전 파일을 새 파일로 바꿔 재시도하세요.

단위가 모호한 서비스에서 ‘1MB’에 맞추려면 1,048,576바이트를 목표로 삼지 마세요. 예를 들어 950,000바이트로 줄이면 1,000,000바이트와 1,048,576바이트보다 모두 작아집니다. 이 숫자가 모든 업로드를 보장하지는 않습니다. 파일 형식·암호 설정·전체 첨부 제한 등 다른 조건이 있다면 그 조건도 맞춰야 합니다.

실제 바이트 수가 제한보다 작은데도 실패한다면 용량만 계속 줄이지 마세요. 화면에 나온 오류 문구를 확인하세요. 서비스가 허용하는 형식과 파일 상태를 먼저 대조해야 화질을 불필요하게 낮추는 일을 줄일 수 있습니다.

같은 실험을 다시 해보려면

개발 환경이 있다면 저장소의 생성 스크립트로 재현할 수 있습니다. Node.js 24와 Git이 설치된 환경에서 터미널을 열고 다음 순서로 실행하세요. 저장소를 내려받을 새 폴더가 생기고, 필요한 패키지와 실험용 브라우저가 설치됩니다.

git clone https://github.com/hjh3311504/hjh3311504.github.io.git
cd hjh3311504.github.io
npm ci
npx playwright install chromium
node scripts/generate_blog_size_examples.js

예제 파일3개는 output/blog-file-size/에 생깁니다. 실행하면 static/downloads/blog/file-size/measurements.json도 내 실행 환경의 기록으로 바뀝니다. 스크립트는 파일을 선택해 크기를 읽고, 바이트 수와 두 경계 조건의 결과가 예상과 같은지 확인합니다. 외부 업로드 사이트의 접수 여부는 검사하지 않습니다.