Summary

  • BBN은 원격 유지보수에 쓰려고 디렉터리 생성·삭제·현재 위치 확인·상위 이동을 맡는 실험적 FTP 명령 네 가지를 RFC 775에 실었다.
  • 생성 명령에 쓴 짧은 이름이 다음 접근에도 통한다는 보장은 없었다. 서버가 반환하는 절대 경로가 서로 다른 운영체제 사이에서 디렉터리 트리를 옮기는 열쇠였다.

“폴더를 만들었습니다.” “그 폴더로 들어갈게요.” “그런 폴더는 없습니다.” 터미널이 이런 대화를 나눴다면 농담처럼 들리겠지만, RFC 775는 실제로 일어날 수 있는 명령 순서를 적었다. TOPS-20 서버에서 XMKD MYDIR는 성공하고 XCWD MYDIR는 실패할 수 있다. 새 디렉터리가 사라진 것이 아니라, 서버가 알아듣는 전체 이름이 <DFRANKLIN.MYDIR>인 것이다.

BBN은 ARPA의 원격 현장 유지보수 사업에서 UNIX를 실행하는 여러 DEC PDP-11의 소프트웨어를 설치하고 관리했다. 파일만 복사해서는 설치 구조를 그대로 옮길 수 없다. 목적지에도 파일을 담을 디렉터리의 나뭇가지를 만들어야 한다. 그래서 BBN은 FTP 서버에 생성 XMKD, 삭제 XRMD, 현재 위치 표시 XPWD, 상위 디렉터리 이동 XCUP를 덧붙였다. 상위로 올라가는 방법을 명령으로 만든 덕분에 클라이언트는 운영체제마다 다른 ‘부모 경로 표기’를 외울 필요가 줄었다.

UNIX 밖에서는 문제가 더 또렷해졌다. ARPANET의 TOPS-20과 Multics에도 트리형 디렉터리가 있었지만 경로를 쓰는 문법은 달랐다. TOPS-20의 <DFRANKLIN>에 있는 클라이언트가 XMKD MYDIR라고 보내면 서버는 자식 디렉터리를 만든다. 그러나 만들어진 결과에 다시 접근할 이름은 <DFRANKLIN.MYDIR>일 수 있다. 요청에 쓴 단어는 동작을 지정할 뿐, 결과물의 영구 주소를 보증하지 않는다.

RFC 775가 택한 해법은 응답을 명확하게 만드는 것이었다. 생성이 성공하면 서버는 257 응답에 새 디렉터리의 절대 경로를 큰따옴표로 묶어 보낸다. UNIX 예시는 257 "/usr/dm/child" directory created다. TOPS-20 서버라면 TOPS-20식 표기로 답한다. 이름 자체에 큰따옴표가 들어 있을 때는 응답에서 그 문자를 두 번 쓴다는 규칙도 있다. 자동화 프로그램이 따옴표 하나에 속아 경로를 중간에서 잘라 먹지 않게 하는 장치다.

디렉터리 나무를 복사하는 프로그램은 이 반환값을 다음 작업의 발판으로 쓴다. 자식을 만들고, 서버가 알려준 경로를 보관하고, 그곳으로 이동해 파일과 다음 가지를 옮긴 뒤, 부모로 돌아온다. 자기 운영체제 방식대로 경로를 짐작하면 파일 전송 자체는 멀쩡해도 저장 위치가 틀어질 수 있다. 당시의 골칫거리는 전송 속도가 아니라 “방금 만든 곳을 다시 어떻게 가리키는가”였다.

이미 같은 이름의 디렉터리가 있으면 어떻게 할지도 명시했다. BBN의 구현은 오류로 처리하고, 더 진행하지 않는 521 응답을 예로 들었다. 표에는 당시 쓰던 옛 FTP의 응답 코드와 더 새로운 RFC 765 방식에 맞춰 제안한 코드가 따로 있다. 257은 앞쪽의 새 코드이고, 뒤쪽에서는 251을 제안했다. 같은 시기의 두 버전을 하나의 숫자로 뭉개면 이 과정이 보이지 않는다.

RFC 765는 사용자에게 호스트별 파일 시스템 차이를 가려 주려는 FTP의 목표를 내세우면서도, 공통 경로 표기법은 아직 없다고 인정했다. RFC 775는 모든 컴퓨터에 한 문법을 강요하는 대신 디렉터리를 실제로 만든 서버가 그 이름을 말하도록 했다. 1985년 RFC 959에는 실험을 뜻하던 X가 빠진 MKD, RMD, PWD와 상위 이동용 CDUP가 새로운 선택 명령으로 등장한다. 명령 이름은 다듬어졌지만, 새 장소의 주소는 그 장소를 가진 기계가 가장 잘 안다는 원칙은 남았다.