1TB인데 931로 보이는 저장 공간, GB와 GiB부터 구분하기

1TB 저장장치가 화면에서는 약 931로 보인다면 바이트를 묶는 단위부터 맞춰 보자. 십진 TB와 이진 GiB의 표시 차이를 계산한 뒤, 포맷과 기존 파일이 차지하는 실제 공간을 따로 살펴야 한다. 압축 자료를 내보낼 때 필요한 여유 공간도 최종 파일 크기와 다를 수 있다.

여기서 단위 차이를 설명하는 일과 실제 장치의 사용 가능 공간을 확인하는 일은 나누어야 한다. 시스템 영역이나 파일 시스템, 이미 저장한 자료까지 모두 단위 차이로 설명할 수는 없다.

GB와 GiB는 같은 이름의 두 표기가 아니다

NIST의 이진 접두어 설명에 따르면 1GB는 1,000,000,000바이트이고, 1GiB는 1,073,741,824바이트다. GB는 십진 접두어, GiB는 이진 접두어를 사용한다. 따라서 같은 바이트 수를 GiB로 나타내면 GB로 나타낸 숫자보다 작다.

미디어플럭스는 바이트 정의를 바탕으로 아래 산술 계산을 실행했다. 장치를 측정한 결과가 아니라 단위 변환이다. 계산 기록에서 입력값과 결과를 확인할 수 있다.

같은 양의 자료를 다른 묶음 크기로 세는 것이므로 이 계산 자체에서 바이트가 없어지는 것은 아니다. 다만 실제 표시에는 반올림이나 운영체제의 표기 관행이 섞일 수 있다. 가능하면 세부 정보에서 바이트 수를 직접 확인하는 편이 정확하다.

표시 단위와 사용 가능한 공간을 따로 본다

장치의 전체 바이트 용량, 파일 시스템이 사용하는 영역, 현재 파일이 차지한 공간, 남은 공간은 서로 다른 값이다. 전체 용량의 단위를 맞춘 다음 사용량과 남은 공간을 확인해야 실제 차이를 좁힐 수 있다.

전체와 사용 가능 공간을 섞어 비교하면 단위 변환 결과와 맞지 않을 수 있다. 예를 들어 제품 표기와 화면의 ‘남은 공간’을 비교하면 이미 저장한 파일의 용량까지 차이에 포함된다. 숨김 폴더, 휴지통, 다른 계정의 자료 등도 사용하는 환경에 따라 확인할 대상이다.

작은 파일이 많을 때 파일의 바이트 크기 합과 장치에서 차지하는 공간이 꼭 같다고 기대하지 않는다. 파일 시스템은 저장 공간을 일정 단위로 할당하므로 파일 크기와 실제 할당된 공간을 구분해 보여줄 수 있다. 정확한 방식은 해당 운영체제와 파일 시스템의 안내를 확인한다.

압축 파일 36GB를 받으면 남은 공간도 36GB면 될까

자료를 내려받는 과정에서는 압축 파일과 풀린 파일, 검토용 사본이 동시에 존재할 수 있다. 설명용으로 압축 묶음이 36GB, 풀린 자료가 40GB, 별도 검토 사본이 40GB인 작업을 생각해 보자. 셋을 같은 장치에 유지하면 파일 크기 합만으로도 116GB다. 여기에 작업 중 임시 자료와 파일 시스템의 사용 공간이 추가될 수 있다.

이 수치는 특정 내보내기 서비스의 압축률을 측정한 결과가 아니다. 입력한 크기로 작업 단계의 공간을 합산한 예제다. 이미 압축된 영상과 사진이 일반 텍스트처럼 줄어들 것으로 기대하지 않고, 실제 묶음과 풀린 결과의 크기를 확인해 계획을 갱신한다.

공간을 줄이려고 압축 원본을 먼저 지우기보다는 어느 단계의 확인이 끝났는지 본다. 다른 장치에 안전하게 보관한 원본이 있고 검토 결과가 정상이라면 작업 사본 정리를 결정할 수 있다. 파일 크기 계산과 보관의 독립성은 함께 고려할 조건이다.

작은 파일에서는 크기 합과 할당 공간을 구분한다

파일 시스템은 공간을 일정 단위로 할당할 수 있다. 단순한 설명 모델에서 할당 단위를 4,096바이트라고 두면, 1바이트 파일 40개의 내용 크기는 40바이트지만 각 파일에 한 단위를 할당하는 모델의 합은 163,840바이트다. 실제 파일 시스템은 압축·저장 구조 등 추가 조건이 있으므로 이 모델을 자신의 장치 측정값으로 쓰면 안 된다.

이 예제는 ‘파일의 크기’와 ‘디스크에서 차지한 공간’이 다른 값을 가질 수 있다는 의미를 보여준다. 많은 작은 파일을 옮길 때는 원래 내용 크기의 합만으로 필요한 공간을 확정하지 않고 실제 장치의 할당·남은 공간 정보를 함께 확인한다.

단위 차이를 맞춘 다음 실제 사용량을 찾는다

1TB의 십진 바이트 수를 GiB로 바꾸면 약 931.32GiB가 된다. 하지만 제품 표기와 화면의 남은 공간 차이를 전부 이 값으로 설명할 수는 없다. 먼저 전체 용량의 단위를 맞추고, 그다음 시스템 영역과 이미 저장한 자료, 휴지통·임시 결과처럼 실제 사용 항목을 살핀다.

다른 앱의 숫자를 비교할 때도 전체·사용·남은 공간 중 무엇을 표시하는지 적는다. 같은 ‘GB’라는 글자가 보여도 바이트 값을 확인할 수 있다면 그 값으로 대조하는 편이 정확하다. 반올림된 숫자만으로 자료가 사라졌다고 단정하지 않는다.

작업 계획에는 장치별 위치를 함께 적는다. 압축 파일은 컴퓨터, 보관용 원본은 외장 장치, 검토 사본은 다른 폴더처럼 위치를 정하면 필요한 공간과 정리 시점을 찾기 쉽다. 충분한 용량은 보관을 시작할 조건이고, 실제 자료를 다시 쓸 수 있는지는 별도의 확인 결과다.

내보내기 작업은 최종 파일 크기만 필요한 일이 아니다

사진을 내보내거나 압축 파일을 내려받을 때는 원본 다운로드, 압축 묶음, 압축을 풀 결과와 작업용 사본이 같은 장치에 함께 존재할 수 있다. 최종 보관할 폴더가 100GB라고 해서 남은 공간 100GB만으로 모든 작업이 끝난다고 단정하면 안 된다.

계획을 세울 때는 자료가 각 단계에서 어디에 존재하는지 적어 본다. 원본 서비스에서 내려받는 위치, 압축 파일 저장 위치, 압축을 풀 위치, 별도 백업 장치를 나누면 어느 장치에 공간이 필요한지 보인다. 단계별 임시 자료를 지우기 전에는 다음 단계의 확인이 끝났는지도 살핀다.

압축률은 파일 종류에 따라 다르다. 이미 압축된 사진·영상과 일반 텍스트가 같은 비율로 줄어든다고 생각하지 않는다. 분할 압축 파일 일부만 풀어 결과를 살펴볼 때도 전체에 필요한 공간을 바로 확정하지 않고 범위와 자료 종류를 함께 본다.

Mbps와 MB도 글자의 대소문자로 구분한다

저장 용량의 B는 바이트, 네트워크 속도에서 쓰는 b는 비트에 해당한다. 기본적으로 1바이트는 8비트이므로, 초당 비트 수를 그대로 초당 바이트 수로 읽으면 계산이 달라진다. 다운로드 화면과 인터넷 상품의 단위를 비교할 때 자주 생기는 혼동이다.

속도가 일정하다는 단순 가정에서 20Mbps로 두 시간 전송하는 자료는 20 × 1,000,000 × 7,200 ÷ 8바이트, 즉 18GB다. 이 값은 전송 속도가 실제로 계속 일정하고 모든 비트가 계산한 자료에 해당한다는 산술 예시다. 스트리밍의 실제 사용량이나 인터넷의 실효 속도를 측정한 결과는 아니다.

스트리밍은 장면과 화질 선택, 압축과 네트워크 상황에 따라 전송량이 달라질 수 있다. 스트리밍 속도와 사용량에서 서비스의 권장 속도와 실제 데이터 관리 설정을 나누어 설명한다.

용량이 예상보다 다를 때의 확인 순서

먼저 비교한 두 숫자의 단위를 맞춘다. 이어 전체 공간과 남은 공간 중 무엇을 보고 있는지 확인한다. 다음으로 파일 크기 합과 할당 공간, 숨은 자료나 임시 폴더 등 실제 사용 항목을 살펴본다. 마지막에는 작업 중 추가로 필요한 사본과 임시 결과를 포함해 계획한다.

단위 정의를 알면 정상적인 표기 차이를 오류로 오해하는 일을 줄일 수 있다. 동시에 모든 차이를 표기 탓으로 넘기지 않을 수 있다. 실제 장치의 바이트 수나 사용량이 설명되지 않는다면 그 환경의 상세 정보와 공식 지원 안내를 통해 따로 확인해야 한다.

사진 백업 설계처럼 자료 보존이 목적이라면 공간이 남는지만이 아니라 사본의 독립성과 복원 가능성도 확인한다. 저장 용량이 충분하다는 것은 보관을 할 수 있는 한 조건이며, 보관이 제대로 끝났다는 증거까지 되지는 않는다.