1장 글자 한 개와 파일 한 개 사이

사진을 보냈는데 오래 걸린다. 인터넷 상품 설명에는 빠른 속도가 적혀 있고 파일 크기도 그리 커 보이지 않는다. 이때 가장 먼저 확인할 것은 속도 측정 사이트가 아니라 단위일 수 있다. 파일은 보통 바이트로, 통신 속도는 비트로 표시한다. 영어 대문자 B와 소문자 b의 차이가 기다리는 시간을 여덟 배나 다르게 보이게 한다.

비트는 두 상태를 구별하는 정보의 단위다. 여덟 비트가 한 바이트다. 100 MB 파일을 100 Mbps 연결로 옮긴다고 가정하면, 십진 단위를 사용했을 때 파일은 800 Mb이고 이상적인 전송 시간은 8초다. 실제로는 헤더, 암호화, 다른 사용자와의 공유, 저장 장치의 쓰기 속도 때문에 더 오래 걸릴 수 있다. 이 계산은 약속된 완료 시간이 아니라 조건을 단순화한 출발점이다.

MB와 MiB도 구분해야 한다. MB를 십진 단위로 쓰면 백만 바이트이고 MiB는 1,048,576바이트다. 어떤 화면은 이 차이를 엄격히 표시하지만 어떤 화면은 관습적으로 다른 표기를 쓴다. 저장 장치를 샀는데 운영체제에 표시되는 숫자가 작다고 해서 곧바로 용량이 사라진 것은 아니다. 단위 체계와 파일 시스템이 쓰는 공간을 먼저 분리해서 보자.

문자에도 약속이 필요하다

컴퓨터는 화면의 글자 모양을 그대로 통신선에 흘려보내지 않는다. 문자를 나타내는 번호와 그 번호를 바이트로 바꾸는 규칙이 필요하다. 유니코드는 문자에 코드 포인트를 부여하는 체계이고, UTF-8은 이를 바이트열로 표현하는 인코딩 중 하나다. 글꼴은 그 문자를 어떤 모양으로 그릴지에 관여한다. 글자가 깨지는 문제와 글꼴이 마음에 들지 않는 문제는 서로 다르다.

UTF-8에서 영문 기본 문자는 대체로 한 바이트지만 한글 완성형 음절은 보통 세 바이트다. “가”라는 한 글자를 저장하는 데 필요한 크기와 영어 A를 저장하는 크기가 같지 않다. 여기에 결합 문자나 이모지가 들어가면 눈에 보이는 한 글자가 여러 코드 포인트로 이루어질 수 있다. 사용자가 입력한 이름을 열 글자로 제한하려면 바이트 길이, 코드 포인트 수, 사람이 인식하는 문자 수 중 무엇을 셀지 결정해야 한다.

서로 닮은 문자열이 내부적으로는 다를 수도 있다. 한글 음절을 하나의 코드 포인트로 표현하거나 자모의 조합으로 표현하는 경우가 있다. 검색과 파일 이름 비교에서는 정규화 정책이 중요해진다. 반대로 보안과 서명 검증에서는 원문 바이트를 임의로 바꾸면 안 되는 경우가 있다. “보기에는 똑같다”는 판단과 “정확히 같은 데이터다”라는 판단을 구별해야 한다.

다음 코드는 Python 3가 설치된 자신의 컴퓨터에서만 실행하는 짧은 관찰 예다. 파일이나 네트워크를 바꾸지 않는다. 출력의 첫 숫자는 Python 문자열의 코드 포인트 수, 둘째 숫자는 UTF-8 바이트 수다. 눈에 보이는 글자 수를 완전히 세는 방법으로 오해하지 말자.

samples = ["A", "가", "네트워크"]
for value in samples:
    encoded = value.encode("utf-8")
    print(value, len(value), len(encoded), encoded.hex())
# A 1 1 41
# 가 1 3 eab080
# 네트워크 4 12 eb84a4ed8ab8ec9b8ced81ac

파일 이름은 내용을 보장하지 않는다

확장자가 jpg라고 해서 내용이 반드시 JPEG 그림인 것은 아니다. 확장자는 프로그램 선택과 사용자 안내에 쓰이는 관습이고, 실제 파일 형식에는 구조와 규칙이 있다. 다운로드 서비스는 이름뿐 아니라 허용 형식, 크기, 내용을 함께 검증해야 한다. 업로드된 파일 이름을 서버의 실행 경로로 곧바로 쓰는 설계는 위험하다. 저장할 데이터와 실행할 코드를 분리하는 이유가 여기서도 나타난다.

압축과 암호화도 혼동하기 쉽다. 압축은 중복을 줄여 표현을 작게 만드는 작업이고, 암호화는 적절한 키 없이는 내용을 알아보기 어렵게 만드는 작업이다. 이미 압축된 동영상에 압축 프로그램을 한 번 더 적용해도 크게 줄지 않을 수 있다. 암호화된 데이터는 일반적인 압축으로 줄이기 어렵다. 보안과 저장 공간이라는 서로 다른 목적을 같은 해결책으로 기대하지 말아야 한다.

체크섬이나 해시는 받은 파일이 기대한 바이트와 같은지 확인할 때 도움이 된다. 다만 파일과 해시값을 모두 공격자가 바꿀 수 있다면 둘이 일치한다는 사실만으로 신뢰할 수 없다. 해시값을 얻은 경로도 신뢰할 수 있어야 한다. 전자서명은 누가 해당 내용을 승인했는지 검증하는 별도의 도구다. 데이터의 동일성과 출처의 신뢰성을 나누어 생각하면 다운로드 검증 절차가 명확해진다.

업로드가 느릴 때 파일을 덜어 내는 일은 종종 회선을 바꾸는 것보다 간단하다. 화면에 작은 사진 한 장만 필요한데 원본 사진 수십 메가바이트를 보내고 있지는 않은지 살펴보자. 그러나 문서의 증거성이나 의료 영상처럼 원본 보존이 중요한 목적에서는 손실 압축을 함부로 적용할 수 없다. 최적화는 크기만 줄이는 일이 아니라 어떤 정보를 반드시 지켜야 하는지 정하는 일이다.

이 장에서 기억할 질문은 세 가지다. 숫자의 단위가 무엇인지, 같은 데이터라고 판단하는 기준이 무엇인지, 크기를 줄이면서 버려도 되는 정보가 무엇인지. 네트워크 속도나 데이터베이스 저장 공간을 이야기할 때 이 질문으로 돌아오면 이름만 거창한 논쟁을 실제 계산으로 바꿀 수 있다.