요약

  • 1982년 1월 11일 ISI 회의에서 참가자들은 username @ hostname을 username @ host.domain으로 확장하기로 했다. 새 계층 전체를 단 하나의 @ 오른쪽에 놓고, 점을 포함할 수도 있는 지역 사용자 이름은 건드리지 않았다.
  • 상위 도메인 이름에는 전 세계적 고유성이 필요했고 이름 조회 응답도 종류별로 구별해야 했다. 호스트 필드의 점을 소프트웨어가 읽도록 고치는 일과 새 주소를 언제 전역에서 보낼지 정하는 일도 남았다.

오래된 우편실을 떠올려 보자. 왼쪽 서랍마다 세입자가 자기 방식으로 이름을 적어 놓았다. 어떤 이름에는 점이 들어간다. 건물을 넓히러 온 설계사가 새 평면도를 펴며 기존 명패부터 모두 바꾸자고 한다면, 우편 담당자는 도면보다 반송 봉투를 먼저 떠올릴 것이다. Jon Postel의 RFC 805는 1982년 1월 11일 ISI에서 열린 컴퓨터 메일 회의를 기록한다. 참가자들은 인터넷의 주소를 늘리되, 왼쪽 서랍의 명패는 그대로 두기로 했다.

회의에는 더 우아해 보이는 구상도 있었다. unique-id @ location-id라면 편지함의 고유한 정체성과 현재 배달 위치를 분리할 수 있다. 사용자가 옮겨도 정체성은 이어진다. 하지만 이미 쓰이는 표기는 user @ host였고, user를 적는 방법은 지역 시스템마다 달랐다. 전 세계의 깔끔한 설계를 위해 곳곳의 작동 중인 프로그램을 개조할 비용이 컸다. 참가자들은 그 구상을 미루고 익숙한 형식을 확장했다.

계층을 @ 왼쪽에 둘지 오른쪽에 둘지, 각 단계를 어떤 순서로 적을지 논의했다. 담는 정보는 비슷했지만 기존 주소에 끼치는 손해는 달랐다. 일부 시스템은 이미 사용자 이름에 점을 사용했다. 그 점을 갑자기 세계 공통의 계층 구분자로 읽으면 어제 도착하던 메일이 오늘부터 길을 잃는다. 그래서 새 계층은 호스트 쪽에만 놓였다. @는 정확히 하나, 오른쪽의 점으로 나뉜 부분은 가장 구체적인 것에서 가장 일반적인 것으로 이어진다. 문서의 예는 Postel @ F.ISI.IN이다. 높은 층의 이름은 세계적으로 유일해야 하고 선택 과정에도 관리가 필요했다. 사람이 누구인지는 지역에서 정하고, 장소의 큰 지도는 함께 맞춘 셈이다.

회의록은 절대적인 계층 이름과 상대적인 소스 경로를 갈라 놓는다. 이름 서비스도 한 가지 마법으로 취급하지 않는다. 속성으로 사람을 찾기, 안정적인 정체성을 위치에 연결하기, 위치를 숫자 네트워크 주소로 바꾸기는 서로 다른 일이다. 당장 필요한 것은 마지막 일이었다. 조회 결과로 최종 호스트 주소, 하위 이름 서버, 전달자가 올 수 있으므로 프로그램은 응답의 종류를 알아야 한다. 다음 안내 창구를 받았는데 그것을 최종 배달함으로 생각해서는 안 된다. NCP/FTP와 TCP/SMTP가 공존하는 환경에서는 서비스와 프로토콜 정보도 문제였다.

이름 정보를 제공하는 방식으로 FTP에서 읽는 텍스트 파일, TCP와 비슷한 연결을 통한 질의, UDP 데이터그램 질의가 거론됐다. 중앙 서버로 먼저 시작하고 도메인별 서버와 데이터베이스 사본으로 관리와 장애 대응을 나누자는 생각도 있었다. 이는 당시의 설계 선택지이지 훗날의 이름 시스템이 이미 배포됐다는 기록이 아니다. 먼저 고쳐야 할 것은 메일 명세와 전환 계획, 그리고 호스트 필드의 점을 받아들이는 프로그램이었다.

달력에도 기술적 역할이 생겼다. DARPA의 Duane Adams는 1982년 3월 1일까지 점이 든 호스트 이름을 ARPANET과 Internet 전역에서 보내도 수신자가 이의를 제기하지 않을 날짜를 정하라는 과제를 받았다. RFC 805는 과제와 마감일을 적지만 그날 전환이 끝났다고 말하지 않는다. 새 주소를 적을 수 있는 발신기와 그 주소를 읽을 수 있는 수신기는 같은 날 태어나지 않는다.

이 설계의 재치는 경계를 잘 골랐다는 데 있다. @ 왼쪽에는 지역의 이름, 오른쪽에는 함께 키울 수 있는 장소의 계층을 두었다. 증축 도면은 완성됐어도 새 출입문을 여는 날짜만큼은 이웃들과 맞춰야 했다.