파일은 100MB라고 들었는데 다른 프로그램은 약 95.37로 표시합니다. 회선 안내는 100Mbps인데 다운로드 창은 초당 12.5MB보다 낮게 움직입니다. 어느 숫자가 틀렸는지 묻기 전에 십진·이진 배수, 비트·바이트, 파일의 크기와 전송률을 나눠야 합니다. 이 글은 고정한 바이트 수에서 단위를 바꾸고 이상적인 전송 시간을 계산합니다. 실제 회선 속도나 저장장치를 측정한 실험이 아니라, 서로 다른 단위를 같은 이름으로 읽을 때 생기는 계산 오류를 재현한 자료입니다.
100이라는 숫자보다 MB와 MiB를 먼저 읽습니다.
이 글에서 1MB는 1,000,000바이트, 1MiB는 1,048,576바이트로 정의합니다. 따라서 100MB는 100,000,000바이트이고 100MiB는 104,857,600바이트입니다. 차이는 4,857,600바이트입니다. 숫자 100이 같아도 크기는 다릅니다. 십진 접두어 mega와 이진 접두어 mebi를 구분하면 같은 파일이 화면마다 다르게 보이는 이유의 일부를 설명할 수 있습니다.
모든 프로그램이 화면의 MB 표기를 이 정의대로 일관되게 사용한다고 가정하지는 않습니다. 실제 파일의 바이트 수와 해당 도구의 문서를 확인해야 합니다. “운영체제가 용량을 잃어버렸다” 같은 결론을 숫자 표시 하나로 내리면 안 됩니다. 파일 시스템의 할당 공간, 장치의 예약 영역, 압축과 메타데이터는 배수 표기와 별개의 문제입니다. 여기서는 디스크 장치의 총 용량이나 실제 사용 가능 공간을 계산하지 않았으며 한 파일의 논리적 바이트 수만 다룹니다.
같은 바이트를 나누면 서로 다른 두 표시가 나옵니다.
100,000,000을 1,048,576으로 나누면 약 95.367431640625MiB입니다. 반대로 104,857,600을 1,000,000으로 나누면 104.8576MB입니다. 이 두 변환은 파일을 압축하거나 내용을 바꾸지 않습니다. 같은 정수 바이트 수를 어느 크기의 묶음으로 세는지만 바꿉니다. 보고서에는 원시 바이트 수를 먼저 보존하고 표시용 단위를 별도 열로 두는 편이 검산하기 쉽습니다.
소수 둘째 자리에서 반올림하면 95.37MiB가 되지만, 그 표시값에서 다시 역산하면 원래 바이트를 정확히 복원하지 못할 수 있습니다. 여러 파일을 더할 때도 각 파일의 반올림된 MB를 합산한 값과 전체 바이트를 더해 한 번 변환한 값이 다를 수 있습니다. 비교 목적이 전송 제한 검사인지 화면의 대략적인 안내인지에 따라 원시 정밀도를 유지해야 합니다. 정수 단위의 크기 제한을 체크하면서 표시된 소수만 비교하지 않는 이유입니다.
Mbps의 작은 b와 MB의 큰 B를 섞지 않습니다.
여기서는 한 바이트를 8비트로 셉니다. 100Mbps를 십진 초당 100,000,000비트로 읽으면 바이트 기준으로는 초당 12,500,000바이트, 즉 12.5MB/s입니다. 100이라는 숫자를 그대로 100MB/s로 복사하면 여덟 배 차이가 납니다. 반대로 MB/s에 8을 곱하면 같은 가정의 비트 전송률을 얻습니다. 이 단계에서도 mega는 십진 배수로 고정했습니다.
바이트를 실제 문자 개수로 바꾸는 것은 별개의 변환입니다. 가상 문자열 ‘가나다’는 코드 포인트 세 개지만 UTF-8 바이트는 아홉 개입니다. 글자 수 3을 파일 크기 3바이트로 간주하면 한글 자료의 크기를 과소평가할 수 있습니다. 다운로드 코드가 len(text)와 len(text.encode(‘utf-8’))를 따로 반환하는 이유입니다. 압축·줄바꿈·BOM이 추가되면 파일 바이트도 다시 달라집니다. 문자·바이트·비트를 단위 열에서 각각 구분하면 데이터 가져오기와 전송 계산을 같은 숫자로 오해하는 일을 줄일 수 있습니다.
전송 시간은 파일 비트 수를 비트 전송률로 나눕니다.
손실이나 부가 통신이 전혀 없고 일정한 100Mbps를 전부 파일에 쓴다는 이상적 가정을 둡니다. 100MB의 비트 수 800,000,000을 100,000,000으로 나누면 8초입니다. 100MiB는 838,860,800비트이므로 8.388608초입니다. 파일 표기를 100으로 같게 쓰면 이 차이를 놓치기 쉽습니다. 식을 쓸 때 분자·분모에 단위를 같이 붙여 남은 단위가 초가 되는지 확인하세요.
이 숫자는 대기열·연결 설정·프로토콜 헤더·암호화·재전송·서버 처리·쓰기 지연을 측정한 예상 완료 시간이 아닙니다. 전체 구간에서 일정한 유효 전송률이 유지된다는 가정의 계산입니다. 회선 계약의 최대 속도를 사용했다면 현실의 하한 시간처럼 읽을 수도 있지만, 실제 속도를 보장하는 수치로 광고하면 안 됩니다. 파일 전송이 끝나도 압축 해제나 검증이 뒤에 있을 수 있으므로 ‘파일 비트 전달’과 ‘작업 완료’의 끝점도 분리합니다.
계산기를 사용할 때는 100×1,000,000×8 / (100×1,000,000)처럼 식을 전부 써 보면 단위가 소거되는 과정을 확인할 수 있습니다. MiB를 쓸 때는 분자의 배수만 1,048,576으로 바뀝니다. 회선의 Mbps까지 1,048,576으로 바꾸면 이번 계약과 다른 입력이 됩니다. 숫자와 접두어를 따로 적는 변환표가 도움이 되는 이유입니다. 실제 서비스 문서가 어떤 배수를 정의하는지는 그 문서를 우선 확인해야 합니다.
파일 두 개를 동시에 옮길 때도 각 파일이 회선의 전체 속도를 계속 쓴다고 가정한 시간을 단순 비교하면 안 됩니다. 대역폭을 나눌 수 있고 서버·저장장치 병목이 추가될 수 있기 때문입니다. 이 글은 동시 전송의 자원 배분을 계산하지 않았습니다. 하나의 고정 파일에 하나의 일정 전송률을 적용하는 최소 모델임을 표의 가정 칸에 남기고, 실제 전송 계획에는 실측과 여유 조건을 별도로 더합니다.
| 가정 | 원시 바이트 | 100Mbps 이상적 초 |
|---|---|---|
| 100MB | 100000000 | 8 |
| 100MiB | 104857600 | 8.388608 |
| 100MiB·가상 효율80% | 104857600 | 10.48576 |
전송률만 10Mbps로 바꾼 별도 가정 계산에서 100MB의 이상적 시간은 80초입니다. 100Mbps의 8초와 정확히 열 배 차이가 납니다. 파일 단위는 그대로 두고 속도 하나만 바꿔 계산의 방향을 확인한 결과입니다. 코드에는 1GB=1,000,000,000바이트와 1GiB=1,073,741,824바이트도 별도 필드로 남겼습니다. 서로 다른 접두어의 원시 배수를 먼저 적어야 단위가 커져도 같은 검산을 반복할 수 있습니다.
효율을 넣더라도 실제 측정값인 것처럼 쓰지 않습니다.
코드에는 파일에 쓰이는 비중을 가상으로 80%라고 둔 별도 식이 있습니다. 100MiB를 같은 회선에서 옮긴다면 8.388608초를 0.8로 나눈 10.48576초가 됩니다. 여기서 80%는 측정한 네트워크 효율이 아니라 식의 변화를 보여 주기 위해 고른 입력입니다. “실제 전송은 항상 20% 느리다”라는 규칙으로 바꿔 쓰면 안 됩니다.
전송률이 시간에 따라 바뀌면 전체 바이트를 실제 경과 시간으로 나눈 평균 유효 속도와 순간 속도를 구분해야 합니다. 가장 빠른 순간의 숫자를 전체에 적용해 남은 시간을 계산하면 화면이 계속 흔들릴 수 있습니다. 이 글은 그 변화 곡선을 수집하지 않았고 시뮬레이션도 하지 않았습니다. 실측을 추가하려면 다운로드 전후의 바이트와 단조 시계로 잰 경과 시간을 보존하고, 표본 주기·캐시 여부·실패 처리까지 남겨야 합니다. 간단한 단위 환산을 성능 시험으로 키우지 않는 것이 핵심입니다.
할당 크기와 압축 크기는 같은 파일의 다른 속성입니다.
운영체제는 작은 파일을 저장할 때도 블록 단위의 공간을 할당할 수 있습니다. 압축 파일 안의 항목은 원래 크기와 압축된 크기가 다르고, 네트워크 응답은 압축된 본문을 전송할 수도 있습니다. 이런 숫자를 모두 bytes라는 열 하나에 넣으면 단위는 같아도 측정 대상이 달라집니다. logicalBytes, compressedBytes, allocatedBytes처럼 값의 의미를 이름에 남기면 비교하기 쉽습니다.
파일이 커졌는지를 확인하려는 작업에서 100MB와 95.37MiB를 보고 감소했다고 말하기 전에 바이트를 대조하세요. 이 예제처럼 같은 100,000,000바이트일 수도 있습니다. 반대로 두 화면의 MB 숫자가 같아도 반올림 구간 안에서 실제 바이트가 달라졌을 수 있습니다. 원본 내용까지 같은지 알고 싶다면 크기만으로는 부족하고 해시나 내용 대조가 필요합니다. 백업 목록 검증에서 파일 길이와 해시를 따로 기록하는 이유와 연결되는 부분입니다.
보고서의 단위 표기를 숫자와 함께 검수합니다.
“100MB 파일을 100Mbps로 전송하면 약 8초”라는 문장은 십진 MB와 Mbps, 이상적인 일정 전송률이라는 가정을 함께 둬야 재현됩니다. 화면에는 ‘가정 계산’이라는 말과 원시 바이트를 곁들이고, 실제 다운로드 결과가 필요하다면 별도 관측으로 표시합니다. 숫자가 보기 좋다는 이유로 MiB를 MB로 줄여 적거나, 속도의 초당 표시를 빼지 않습니다.
자동화에서는 모든 내부 값을 바이트와 초처럼 한 기준으로 보관하고 마지막 출력에서만 사람이 읽는 단위로 바꾸는 방법이 단순합니다. 파일 크기는 정수 바이트로, 경과 시간은 필요한 정밀도의 숫자로 저장하되 단위 정보를 명세에 넣습니다. 사용자가 입력한 ‘100M’을 무조건 MB로 추정하는 대신 모호한 입력은 선택하게 하세요. 원시 로그의 단위가 잘못 붙었을 때 값만 나중에 고치면 기존 비교와 합계도 다시 계산해야 하므로 변환 경로를 추적할 수 있어야 합니다.
변환 코드가 통과한 뒤에도 남는 확인 항목이 있습니다.
독립 실행 결과에는 100MB와 100MiB의 바이트, 차이, 서로의 표시값, 100Mbps의 바이트 전송률, 두 이상적 시간과 80% 가정 시간이 들어 있습니다. 단위 검산을 위한 고정 산식이므로 실행할 때 실제 네트워크를 사용하지 않습니다. 프로그램을 실행했다는 이유로 회선 품질·서버 처리량·파일 열기 속도를 확인했다고 말할 수 없습니다.
독자 작업에서는 크기가 알려진 작은 파일 한 개를 골라 파일 관리자, 전송 도구와 코드가 각각 무엇을 표시하는지 나란히 적어 보세요. 원시 바이트가 맞는데 표시만 다르면 배수·반올림을 확인하고, 원시 바이트가 다르면 인코딩·줄바꿈·압축 등의 실제 변화를 살펴봅니다. 이 순서로 보면 단위 착시를 내용 손상과 구분할 수 있습니다. CSV 문자열 보존과 숫자의 반올림 순서를 다룬 기존 글도 연결해 읽으면 파일의 동일성과 표시의 동일성을 별개로 판단하기 쉬워집니다.
입력과 판정을 다시 확인하려면
이 글의 가상 입력과 코드는 2026년 10월 15일 로컬 Python 3에서 실행했습니다. 글의 발행일과 실행일은 다릅니다. 별도 설치 패키지 없이 Python 표준 라이브러리로 실행할 수 있습니다.
터미널에서 python3 decimal-binary-size-units-20261015.py를 실행하면 JSON을 출력합니다. 사용자 자료나 비밀번호는 필요하지 않습니다. 입력과 실행 환경은 결과 JSON에 함께 남겼습니다.
계산 기준을 확인한 원문과 다음 작업
- NIST — Metric prefixes — 십진 접두어의 배수를 확인했습니다.
- NIST — Binary prefixes — mebi와 mega, 비트와 바이트 표기 예를 확인했습니다.
- MDN — ArrayBuffer byteLength — 버퍼 길이가 바이트 단위라는 API 정의를 확인했습니다.
공식 원문은 2026-10-15에 확인했습니다. 문서가 설명하는 API·정의와 이 글의 가상 계산 결과는 구분해서 읽어 주세요.
함께 보면 좋은 글: CSV 문자열 보존, 반올림과 합산.
