파일 크기 단위 변환기 (MB / MiB / GB / GiB)
KB/KiB/MB/MiB/GB/GiB의 바이트 수를 즉시 변환. 경계값 테스트 설계와 업로드 상한 계산에 활용.
—
—
—
—
—
—
—
—
관련 기사
📖 자주 걸리는 지점
B·KB·KiB·MB·MiB·GB·GiB 를 상호 환산합니다. 1000 진 (SI) 과 1024 진 (이진 접두어) 양쪽을 나란히 표시하므로 어느 의미로 쓰인 숫자인지 확인할 수 있습니다. 처리는 브라우저 안에서 끝납니다. 다만 당신이 보고 있는 「500MB」가 어느 쪽 의미인지는 이 도구가 알 수 없습니다 — 단위 표기만으로는 판별할 수 없고, 그것을 쓴 소프트웨어의 관례를 알아야 합니다. 용량에 얽힌 문제의 대부분은 계산 착오가 아니라 이 「어느 쪽 1MB 인가」의 어긋남입니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 같은 「GB」라도 7% 넘게 어긋난다 | 1 GB 는 1,000,000,000 바이트, 1 GiB 는 1,073,741,824 바이트이며 그 차이는 7.4% 입니다. 접두어가 한 단계 올라갈 때마다 차이는 벌어져 TB 와 TiB 에서는 약 10% 가 됩니다. 문제는 많은 소프트웨어가 1024 진으로 계산하면서 「GB」라고 표시한다는 점입니다 — Windows 탐색기가 바로 이것이라 1 GiB 파일을 「1 GB」로 보여 줍니다. 한편 드라이브 제조사와 macOS 는 1000 진을 씁니다. 그래서 「500GB 드라이브를 샀는데 465GB 밖에 없다」는 오표기가 아닙니다 — 500,000,000,000 바이트를 1024 진으로 다시 세면 465.7 GiB 가 된다는 것뿐입니다. | 사양서·요건·API 문서에는 단위가 아니라 바이트 수를 쓰세요. max_upload = 10485760 은 오해할 여지가 없지만 「10MB 까지」는 읽는 사람에 따라 10,000,000 이 되기도 10,485,760 이 되기도 합니다. 기존 숫자가 어느 쪽인지 모를 때 구분하는 방법이 있습니다 — 그 수를 1024 로 몇 번 나눠 보아 깔끔한 정수가 되면 1024 진입니다 (4194304 은 4 MiB). 반대로 끝에 0 이 늘어서면 1000 진입니다. 커맨드라인에서는 ls -l 과 stat 이 돌려주는 날 바이트 수가 유일한 정답이며 -h 를 붙이는 순간 반올림이 들어갑니다 — 숫자를 맞춰 볼 때는 반드시 날 바이트 수로 비교하세요. |
| 업로드 상한은 「파일 크기」가 아니다 | 「10MB 까지」라고 정해도 서버에 도착하는 요청은 10MB 보다 커집니다. multipart/form-data 에는 필드 경계와 헤더가 붙고, 파일을 Base64 로 보내는 설계 (JSON API 에 심는 등) 라면 33% 늘어납니다 — 10MB 파일이 13.3MB 가 됩니다. 나아가 상한은 한 곳이 아니라 여러 층에 있고 가장 작은 값이 이깁니다: nginx 의 client_max_body_size, PHP 의 upload_max_filesize 와 post_max_size, 애플리케이션 쪽 검증, 로드밸런서나 CDN 의 상한. 층마다 증상이 다른 것이 까다롭습니다 — nginx 에서 넘으면 413 이 돌아오고 PHP 에서 넘으면 $_FILES 가 빈 채로 200 이 돌아오므로 후자는 「아무 일도 일어나지 않는다」는 가장 알기 어려운 방식으로 깨집니다. |
네 값을 동시에, 같은 방침으로 정하세요. 기준은 client_max_body_size ≥ post_max_size ≥ upload_max_filesize ≥ 실제로 허용할 크기이며 사이에 20〜30% 의 여유를 둡니다 — 10MB 를 허용한다면 upload_max_filesize=10M / post_max_size=12M / client_max_body_size=16M 정도입니다. 큰 파일을 다룬다면 시간 쪽도 맞춥니다: max_execution_time 과 nginx 의 fastcgi_read_timeout 중 한쪽만 늘려도 짧은 쪽에서 끊깁니다. 그리고 상한값은 「예상되는 최대 유스케이스 × 2」를 출발점으로 삼고, 왜 그 값인지를 주석에 남기세요 — 근거 없는 값은 나중에 아무도 안전하게 바꿀 수 없습니다. |
| 디스크상의 점유량은 표시 크기와 다르다 | 파일 시스템은 블록 단위로 영역을 할당하므로 1 바이트 파일이라도 4 KiB 를 점유합니다 (많은 환경의 기본 블록 크기). 파일 하나라면 오차지만 작은 파일이 1 만 개 있으면 합계 100KB 여야 할 것이 40MB 를 쓰고 있습니다 — 캐시 디렉터리나 node_modules 에서 「크기를 더해도 맞지 않는」 이유가 이것입니다. 반대 방향의 어긋남도 있습니다: 스파스 파일 (내용이 비어 있는 거대한 디스크 이미지 등) 은 표시 크기보다 실제 점유가 작고, 파일 시스템의 압축이나 중복 제거가 걸려 있으면 더 작아집니다. 즉 「크기」라는 말이 서로 다른 두 양을 가리키고 있습니다. |
두 수를 따로 재세요. Linux / macOS 라면 du -sh --apparent-size 가 「파일 내용의 합계」, du -sh 가 「실제로 점유한 블록의 합계」입니다. 이 둘이 크게 어긋나는 디렉터리는 작은 파일이 대량으로 있다는 뜻이며 디스크 여유뿐 아니라 inode 고갈에도 가까워지고 있습니다 (df -i 로 확인할 수 있습니다 — 용량에 여유가 있는데 쓸 수 없다면 대개 이쪽입니다). 백업이나 컨테이너 이미지의 견적에서는 「실점유」가 아니라 「내용의 합계」를 쓰세요 — 전송량과 아카이브 크기는 내용에 비례하지 블록 할당에 비례하지 않습니다. |
접두어의 의미는 분야에 따라 바뀝니다. 외워 두면 헤매지 않는 대응이 셋 있습니다. 메모리는 언제나 1024 진입니다 — 「8GB 의 메모리」는 반드시 8 GiB 이며, 이는 물리적으로 주소선이 2 의 거듭제곱이기 때문입니다. 스토리지의 제품 표시는 1000 진. 그리고 네트워크의 대역폭은 비트이고 게다가 1000 진입니다 — 「1Gbps」는 125 MB/s (비트를 바이트로 바꾸므로 8 로 나눕니다). 「100Mbps 회선인데 12MB/s 밖에 안 나온다」는 정상입니다. 또 하나, 비트와 바이트의 표기는 b 와 B 의 대소문자만으로 구별됩니다 — 이 한 글자가 8 배의 차이를 낳으므로 자료를 쓸 때는 Mbps 인지 MB/s 인지를 생략하지 말고 쓰세요. 마지막으로 KB 는 역사적으로 1024 를 가리키는 일도 많았고 KiB 라는 표기는 그것을 해소하기 위해 1998 년에 도입되었습니다 — 새로 쓰는 문서에서는 KiB / MiB 를 쓰고, 읽을 때는 양쪽 가능성을 의심하는 것이 실무적입니다.
📖 사용법
-
1
값과 단위 입력숫자를 입력하고 단위(B/KB/KiB/MB/MiB/GB/GiB)를 선택합니다.
-
2
모든 단위 변환 결과 확인B, KB, KiB, MB, MiB, GB, GiB, TB로의 변환값이 한 번에 표시됩니다.
-
3
SI 단위(MB)와 이진 단위(MiB)의 차이 확인1 MB = 1,000,000 B, 1 MiB = 1,048,576 B입니다.
❓ 자주 묻는 질문
MB와 MiB의 차이는?
왜 OS가 표시하는 GB와 사양서의 GB가 다른가요?
1 GB는 몇 바이트인가요?
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.