파일은 도착했다. 네 비트는 역에 남았다

요약

• RFC 913은 간단한 파일 전송을 위해 ASCII, Binary, Continuous 세 유형을 제안했다. 36비트 단어 512개로 된 TOPS-20 페이지는 문서의 예에서 각각 2560, 2048, 2304개의 8비트 바이트로 전송된다.
• Binary는 단어마다 네 바이트를 꺼내고 마지막 네 비트는 남긴다. Continuous는 단어 경계를 넘어 모든 비트를 잇는다. 전송 완료 메시지는 선택된 흐름의 도착을 알려 줄 뿐, 원래 페이지의 모든 부분이 그 흐름에 포함됐는지는 알려 주지 않는다.

화면에는 ‘완료’가 뜬다. 이제 파일을 열었는데 무언가 빠져 있다면 어디부터 살펴야 할까. 선로가 고장 났다는 생각부터 하기 쉽지만, 선로가 맡은 바이트를 모두 옮겼을 수도 있다. Mark Lottor의 1984년 RFC 913은 이런 상황의 출발점을 보여 준다. 그가 제안한 Simple File Transfer Protocol은 TCP 115번 포트에서 동작하도록 적힌 옛 SFTP다. 나중에 SSH와 함께 알려진 파일 전송 도구와는 약자만 같다. TFTP보다 쓸모를 늘리고 FTP보다 구현을 가볍게 하며 TCP 연결 하나만 쓰려는 제안이었다. 그 안에서 파일의 운명을 가른 명령이 TYPE이다.

예시의 주인공 TOPS-20은 단어 하나가 36비트다. 디스크 한 페이지는 단어 512개, 모두 1만8432비트다. ASCII 유형은 각 단어에서 7비트 문자 다섯 개를 꺼낸다. 35비트를 쓰고 마지막 한 비트는 문자 표현에 들어가지 않는다. 문자는 상위 비트를 0으로 둔 8비트 단위로 보내며, 현지 줄 끝은 NETASCII에 따라 CRLF로 바꾼다. 그래서 페이지는 512 곱하기 다섯, 2560바이트가 된다. 문장을 다른 컴퓨터에서 읽게 하는 일이라면 이런 변환이 정확히 필요할 수 있다. 저장된 모든 비트를 복제하는 일과는 다른 목표다.

Binary라는 이름은 마음을 놓게 한다. 하지만 이 문서에서는 36비트 단어마다 8비트 묶음 네 개, 곧 32비트만 꺼낸다. 위치 32부터 35까지의 네 비트는 전송되지 않는다. 페이지의 전송 크기는 2048바이트다. 남겨 둔 비트에 중요한 정보가 있었는지는 파일의 저장 방식에 달렸다. RFC가 특정 파일 손상을 보고한 것은 아니다. 대신 ‘바이너리’를 선택하면 36비트 단어의 모든 비트가 자동으로 보존된다고 생각할 근거가 없음을 보여 준다. 포장 상자에 적힌 이름이 내용물 목록은 아니다.

Continuous는 단어의 끝을 포장 상자의 끝으로 삼지 않는다. 첫 단어에서 네 바이트를 꺼낸 뒤 남은 네 비트를 다음 단어의 첫 네 비트와 합쳐 다음 바이트를 만든다. 512개 단어의 1만8432비트를 모두 이으면 2304바이트가 된다. 단어 폭이 애초에 여덟의 배수인 기계에서는 Binary와 Continuous가 같게 구현돼야 한다고 문서는 말한다. TOPS-20에서는 다르다. 하나는 단어마다 바이트 네 개를 고르고, 다른 하나는 페이지 전체의 비트 줄을 지킨다. 받은 쪽이 그 줄을 어떤 파일로 되살릴지는 또 다른 규칙이 필요하다.

사용자는 이를 쉽게 지나칠 수 있었다. 명령은 ASCII 네 글자와 끝의 NUL 바이트였고, 종류를 명시하지 않으면 Binary가 기본값이었다. 서버는 사용자 이름, 계정, 비밀번호를 요구할 수 있었고 목록 보기, 디렉터리 이동, 이름 바꾸기, 삭제, 파일 송수신을 제공했다. 연결도 응답도 정상일 수 있다. 그런데 선택한 표현이 2048바이트였다면 완전한 비트 줄을 담은 2304바이트와는 다른 물건을 정직하게 배달한 셈이다. 성공 여부와 원본의 의미가 남았는지는 따로 확인해야 한다.

RFC Editor 기록은 이 제안을 현재 역사적 문서로 분류한다. 세 크기는 계산 예시이며, 실제 사용자의 손상 사례 집계가 아니다. 그래도 한 페이지가 2560, 2048, 2304바이트 가운데 하나가 된다는 사실은 묵직하다. 전송이 끝났다는 말은 선택한 바이트가 도착했다는 뜻이다. 네 비트가 처음부터 기차에 타지 못했다면, 도착 안내 방송은 그 사실을 모른다.