파일 크기 단위 변환기 (KB · MB · GiB)

“KB”는 두 개의 서로 다른 숫자다

이 도구가 존재하는 이유는 나눗셈이 어려워서가 아닙니다. 같은 기호가 두 개의 다른 값을 가리키기 때문입니다.

SI(국제단위계)에서 킬로는 1000입니다. 킬로그램, 킬로미터, 킬로와트 — 예외가 없습니다. 그런데 컴퓨터는 메모리를 2진수로 주소지정하기 때문에 용량이 2의 거듭제곱으로 떨어졌고, 1000에 가장 가까운 2의 거듭제곱이 1024(2¹⁰)였습니다. 그래서 초기 엔지니어들은 1024바이트를 그냥 “1KB”라고 부르기 시작했습니다.

당시엔 합리적인 근사였습니다. 오차가 2.4%였고, 메모리가 64KB이던 시절에 2.4%는 아무도 신경 쓰지 않는 값이었습니다. 문제는 이 오차가 자리마다 곱해진다는 점입니다. 더해지는 게 아닙니다.

KB vs KiB    1,024 / 1,000               →  +2.4%
MB vs MiB    1,048,576 / 1,000,000       →  +4.9%
GB vs GiB    1,073,741,824 / 1e9         →  +7.4%
TB vs TiB    1,099,511,627,776 / 1e12    →  +10.0%
PB vs PiB    1,125,899,906,842,624 / 1e15 → +12.6%

1980년대에 무시하고 넘어간 2.4%가 지금 TB를 다루는 자리에서 10%가 되어 돌아왔습니다. 그리고 스토리지 용량이 커질수록 이 격차는 계속 벌어집니다. 우리가 지금 이 페이지를 보고 있는 이유가 정확히 이것입니다.

내 하드디스크는 왜 작지? — 범인은 제조사가 아니다

1TB 하드디스크를 사서 Windows에 연결하면 931GB라고 나옵니다. 69GB가 어디로 사라진 것처럼 보이고, 인터넷에는 “제조사가 용량을 부풀려 판다”는 설명이 널려 있습니다.

그 설명은 틀렸습니다. 실제로 일어난 일은 이렇습니다.

디스크에 실제로 들어 있는 것:  1,000,000,000,000 바이트  ← 광고 그대로다

Windows 의 계산:
  1,000,000,000,000 / 1024 / 1024 / 1024 = 931.32...
  화면에 출력: "931 GB"                              ← 여기가 틀렸다

사라진 바이트는 하나도 없습니다.디스크에는 광고한 만큼 정확히 들어 있습니다. Windows가 1024로 세 번 나눠 놓고, 그 결과에 “GB”라는 라벨을 붙인 것뿐입니다. 1024로 나눴으면 단위는 GiB여야 합니다. 즉 931이라는 숫자는 맞고, 그 옆에 붙은 두 글자가 틀렸습니다.

정확히 말하면 이렇게 적어야 합니다: 931.32 GiB = 1.00 TB. 같은 디스크이고, 같은 바이트 수이고, 단지 두 가지 방식으로 읽었을 뿐입니다. 위 변환기에서 1 TB 하드디스크 프리셋을 눌러 보세요. 2진 표의 GiB 행에 931.3226이 찍힙니다 — 탐색기가 보여주는 그 숫자입니다.

이 재구성이 이 페이지에서 가장 중요한 부분입니다. 거의 모든 사람이 제조사를 의심하지만, 규칙을 어긴 쪽은 1024로 나눠 놓고 1000의 단위 이름을 붙인 운영체제입니다.

IEC는 1998년에 이 문제를 고쳤다 — 아무도 쓰지 않았을 뿐

국제전기기술위원회(IEC)는 1998년에 2진 접두어를 표준으로 제정했습니다. 킬로바이너리에서 따온 키비바이트(KiB), 메비바이트(MiB), 기비바이트(GiB)입니다. 규칙은 명확합니다 — 1000으로 나눴으면 KB, 1024로 나눴으면 KiB. 모호함이 사라집니다.

25년이 지난 지금 현실은 이렇게 갈려 있습니다.

• 1000을 쓰고 라벨도 맞게 적는 쪽: 하드디스크·SSD 제조사, 네트워크 장비와 ISP, macOS(10.6 스노우 레퍼드부터 전환), 리눅스 ls -lh의 기본 동작. 이쪽은 최소한 일관됩니다 — 1000으로 나누고 GB라고 적으니 틀린 게 없습니다.
• 1024를 쓰면서 1000의 라벨을 붙이는 쪽: Windows 탐색기, 대부분의 램 제품 표기, 수많은 프로그래밍 언어의 유틸리티 함수. 이쪽이 혼란의 진원지입니다.
• IEC 표기를 그대로 쓰는 쪽: 리눅스의 일부 도구(df -h의 일부 구현), Ubuntu의 정책 문서, 일부 스토리지 벤더의 기술 문서. 정확하지만 소수입니다.

표준이 있는데도 퍼지지 않은 이유는 단순합니다. “기비바이트”는 발음이 어색하고, 이미 모두가 GB라고 말하고 있었으며, 무엇보다 고치면 용량이 줄어든 것처럼 보이기 때문입니다. 어느 회사도 자사 제품이 갑자기 “7.4% 작아 보이는” 변경을 먼저 하고 싶어 하지 않았습니다.

램은 예외가 아니라, 이 이야기의 증거다

여기서 흔한 반문이 나옵니다. “그럼 8GB 램도 7.44GB로 나와야 하는 것 아닌가?” 아닙니다. 그리고 이 예외가 왜 두 산업이 갈라졌는지를 정확히 설명해 줍니다.

메모리는 주소 버스로 접근합니다. 32비트 주소선은 2³²개의 위치를 가리키고, 그 사이의 개수는 존재할 수 없습니다. 즉 램의 용량은 물리적으로 2의 거듭제곱으로만 만들어집니다 — 제조사가 원해도 “8,000,000,000바이트짜리 램”은 만들 수 없습니다. 8GB 램은 실제로 8 GiB = 8,589,934,592 바이트이고, 여기서는 GB라고 적어도 사용자가 손해 보는 일이 없습니다.

반면 하드디스크는 주소 버스가 아니라 섹터 번호로 접근합니다. 2의 거듭제곱이어야 할 이유가 기술적으로 전혀 없습니다. 그래서 제조사는 딱 떨어지는 1조 바이트로 만듭니다. 두 산업이 다른 숫자를 쓰는 건 한쪽이 정직하지 못해서가 아니라 하드웨어 구조가 실제로 다르기 때문입니다. 램을 눌러 8 GiB로 계산해 보면 10진 쪽에 8.59 GB가 찍히는데, 이게 램 광고가 절대 쓰지 않는 숫자입니다.

네트워크는 또 다른 8배 함정

“500Mbps 인터넷인데 왜 60MB/s밖에 안 나오죠?” — 이건 1024 문제가 아니라 더 큰 함정입니다.

500 Mbps  =  500,000,000 비트/초    (소문자 b = bit)
          ÷ 8
          =  62,500,000 바이트/초    =  62.5 MB/s   (대문자 B = Byte)

대소문자 하나가 8배 차이입니다. 게다가 네트워크는 10진을 쓰므로 Mbps에서의 M은 확실히 1,000,000입니다. 그래서 500Mbps 회선의 이론 최대 다운로드 속도는 62.5MB/s이고, 실제로 60MB/s가 나온다면 회선의 96%를 쓰고 있는 셈입니다. 손해 보고 있는 게 아니라 아주 잘 나오고 있는 겁니다.

ISP가 광고에 Mbps를 쓰는 이유도 여기 있습니다. “62.5MB/s”보다 “500Mbps”가 8배 커 보입니다. 이건 틀린 표기는 아니지만, 소비자가 헷갈리는 방향이 정확히 유리한 쪽이라는 점은 짚어 둘 만합니다.

1.44MB 플로피 — 역사상 최악의 단위

재미있는 각주 하나. 3.5인치 플로피 디스크의 “1.44MB”는 어느 체계도 아닙니다.

실제 용량:  1,474,560 바이트  =  1440 KiB

10진 MB 로 읽으면:  1.47 MB   ← 1.44 가 아니다
2진 MiB 로 읽으면:  1.41 MiB  ← 이것도 아니다

1.44 의 정체:  1440 KiB / 1000  =  1.44 × 1000 × 1024

섹터를 KiB(1024)로 세어 1440을 얻은 뒤, 그 1440을 1000으로 나눠 1.44를 만들었습니다. 한 숫자 안에 1024와 1000이 동시에 들어 있는 잡종입니다. 전 세계가 10년 넘게 아무 의심 없이 이 숫자를 썼다는 사실이, 이 업계가 단위 문제에 얼마나 무신경했는지를 보여줍니다. 위 변환기의 1.44 MB 플로피 프리셋으로 직접 확인할 수 있습니다.

실무: 코드와 문서에서 뭘 써야 하나

규칙은 하나로 요약됩니다. 1000으로 나눴으면 GB, 1024로 나눴으면 GiB라고 적으세요.

그리고 이건 문서 스타일 문제가 아니라 실제 장애로 이어지는 문제입니다. 설정 파일에서 자주 보는 모양입니다.

max_upload_size = 1e9        // 1,000,000,000  (10진 GB)
max_upload_size = 1 << 30    // 1,073,741,824  (2진 GiB)
                             // → 7.4% 차이. 용량 계획에서 이건 진짜 오차다.

디스크 여유 공간 90%에서 알림을 띄우는 모니터링을 짤 때, 한쪽은 1000으로 다른 쪽은 1024로 계산하고 있으면 임계치가 7.4% 어긋납니다. 10TB 볼륨이라면 740GB가 어긋난 것이고, 알림이 울려야 할 때 안 울립니다. 이 정도면 사후 분석 보고서에 한 줄 들어갈 만한 원인입니다.

실무 지침을 정리하면 이렇습니다.

• 내부 코드·로그·기술 문서: KiB/MiB/GiB를 쓰세요. 어색해도 명확합니다. 정 못 쓰겠으면 최소한 bytes 원시값을 같이 남기세요 — 바이트에는 이견이 없습니다.
• 사용자에게 보여주는 화면: 이미 GB에 익숙한 사용자에게 GiB를 들이밀면 지원 문의가 늘어납니다. 어느 쪽으로 나눴는지를 툴팁에 적어 두는 절충이 현실적입니다.
• 스토리지 구매·용량 계획: 제조사 스펙은 10진입니다. 운영체제가 보여줄 숫자를 미리 알고 싶다면 1024로 나눈 값을 계산해 두세요. 4TB 디스크는 3.64 TiB로 잡힙니다.
• 속도·대역폭: 비트인지 바이트인지부터 확인하세요. 8배는 어떤 단위 논쟁보다 큽니다.

왜 9PB에서 계산이 멈추는가

마지막으로 이 도구 자체의 한계 하나. 자바스크립트의 숫자는 IEEE 754 배정밀도 부동소수점 하나뿐이고, 정수를 오차 없이 표현할 수 있는 상한은 2⁵³-1 — 9,007,199,254,740,991바이트, 약 9PB입니다.

그 위로 가면 계산이 실패하는 게 아니라 조용히 끝자리가 틀립니다. 이게 더 나쁩니다. 오류가 나면 알아채지만, 그럴듯한 숫자가 나오면 그대로 믿기 때문입니다. 그래서 이 변환기는 한계를 넘으면 결과를 감추는 대신 경고를 띄웁니다 — 규모는 맞고 끝자리는 믿지 말라는 뜻입니다. 엑사바이트 규모를 정확히 세야 한다면 BigInt가 답입니다.