요약

  • Archie는 원격 FTP 디렉터리 목록을 검색 가능한 이름과 위치로 만들었지만, 목록에 담긴 파일 자체를 색인으로 옮겨온 것은 아니었다.
  • 1991년 5월 매뉴얼에 따르면 매일 밤 일부 사이트에서 수집했지만 각 사이트의 갱신은 약 한 달에 한 번이었고, 따라서 검색 결과는 그 나이가 중요한 '관찰 기록'을 보여주는 것이었다.

날짜가 답의 일부였다

검색 결과는 현재에 대한 진술처럼 보인다. 그러나 Archie의 경우 그것은 날짜가 붙은 메모에 가까웠다. 즉, '이 시스템이 그 아카이브의 디렉터리를 마지막으로 수집했을 때 이 이름이 이 경로에서 나타났다'는 기록이었다. 사용자가 그럴듯한 파일명을 보고 그 파일이 여전히 내려받을 수 있다는 증거로 받아들인다면 이 구분은 쉽게 놓칠 수 있었다.

이 서비스는 익명 FTP에서 색인을 만들었다. 1991년 5월 20일자 매뉴얼에 따르면 Archie의 데이터베이스 하위 시스템은 약 600개의 FTP 아카이브 사이트를 파악하고 있었다. 매일 밤 그 일부 사이트에 익명으로 접속해 재귀적 디렉터리 목록을 가져왔고, 그런 파일이 있는 경우에는 해당 목록을 담은 파일을 가져왔다. 각 사이트는 대략 한 달에 한 번 갱신되었다. Archie는 압축된 목록을 맥길 대학의quiche.cs.mcgill.ca에 저장했고, 인터넷 커뮤니티는 익명 FTP를 통해 이를 받아볼 수 있었다. 크롤러는 모든 아카이브의 소프트웨어, 문서, 데이터를 맥길로 복사할 필요가 없었다. 그 원격 자산을 찾기 쉽게 해주는 이름과 경로만을 수집했던 것이다. (1991년 Archie 매뉴얼)

사용자용 명령은 이름 색인과 파일 서버 사이의 차이를 그대로 드러냈다.prog는 이름을 검색해 아카이브 호스트, 경로, 파일 크기, 수정 날짜 같은 정보를 돌려주었다.site는 알려진 아카이브의 전체 목록을 출력할 수 있었다.list명령은 사이트의 목록이 마지막으로 갱신된 시점을 보여주었다. 결과를 찾은 뒤에도 사용자는 여전히 아카이브에 직접 접속해 파일을 전송받아야 했다. 1992년 RFC 1325는 이 손잡음을 그대로 서술했다. Archie는 아카이브 이름, IP 주소, 위치를 돌려주고 다음 단계는 원격 사이트에서 이루어진다는 것이었다. 1994년 RFC 1689는 Archie를 '2차 출처'로 부르며, 일치 항목을 FTP로 아카이브 자체에서 가져오는 절차를 명시적으로 설명했다. (RFC 1325;RFC 1689)

이러한 분리가 색인에 시계를 부여했다. 수집 사이에 디렉터리는 바뀔 수 있었다. Archie가 마지막에 수집한 목록을 계속 보고하는 동안 파일은 옮겨지거나 이름이 바뀌거나 사라질 수 있었다. 1991년 5월 매뉴얼은 이 나이를 완전히 숨기지는 않았다. 마지막 갱신 정보를 노출했기 때문이다. 그러나 검색 결과가 실시간 확인이라고 주장하지도 않았다. 결과는 어느 이름과 위치가 관찰되었다는 증거였을 뿐이며, 파일이 여전히 그곳에 있고 사용 가능하다는 것은 아카이브의 현재 상태와 성공적인 전송만이 입증할 수 있었다.

이 경계는 시스템의 커버리지에서도 드러났다. 같은 매뉴얼은 'UNIX 사이트만 해당'이라는 제한을 명시하면서, 사용자가 검색 범위를 특정 사이트로 좁힐 수 없다고도 말했다. 이것은 사소한 인터페이스 누락이 아니었다. 어떤 아카이브가 나타날 수 있는지, 사용자가 색인에 무엇을 구분해 달라고 요청할 수 있는지를 결정했다. 중앙 디렉터리는 방대한 집합을 검색하기 쉽게 만들었지만, 그 시야는 인터넷의 전체 파일 시스템이 아니었고 서로 다른 아카이브를 균일하게 만들지도 않았다.

1991년 5월 기준으로 이 서비스를 자체적으로 유지하는 일은 비용이 많이 드는 일이었다. 매뉴얼은 데이터베이스가 약 70MB에 이르며, 갱신과 검색이 이를 호스팅하던 Sun 4/280에 상당한 부하를 준다고 추정했다. Archie는 여전히 개발 단계로 서술되었고, 소프트웨어는 아직 외부 사이트에 배포되지 않았으며, 다른 서버로의 확산은 장기 계획이었다. 수집 일정, 저장 용량, 질의 부하는 따라서 같은 설계 문제의 일부였다. 크롤링을 더 자주 하면 관찰의 나이를 줄일 수 있었지만, 각 갱신은 아카이브 쪽의 네트워크 작업과 색인 호스트 쪽의 처리 작업을 다시 요구했다.

서비스는 수치를 단일한 시대를 초월한 총계가 아니라 스냅샷으로 읽어야 할 만큼 빠르게 성장했다. Emtage와 Deutsch의 1992년 겨울 USENIX 논문에는 1991년 10월 30일자 표가 포함되어 있다. 1,025개 사이트가 알려져 있었고, 886개가 색인되어 있었으며, 데이터베이스는 1,502,976개의 파일 참조와 686,104개의 고유 파일명을 담고 있었다. 참조 수와 고유 이름 수의 차이는 중요하다. 파일명이 곧 전 세계적으로 유일한 하나의 객체라는 뜻은 아니었기 때문이다. 이어진 1992년 5월 RFC는 약 900개 아카이브에서 약 150만 개의 파일명과 전 세계 9개의 Archie 서버를 언급했다. 사용자가 맥길의 부하를 덜기 위해 더 가까운 서버를 선택할 수 있다고도 했다. 이는 더 넓은 접근과 부하 분산 목표를 문서화할 뿐, 모든 서버가 동일하거나 똑같이 신선한 목록을 갖고 있었다는 증거는 아니다. (Emtage와 Deutsch, 1992 USENIX 논문;RFC 1325)

RFC 1689에 기록된 1993년 갱신 기준으로 상용 Archie 서버 시스템은 약 27개 설치로 구성되었으며, 모두 공개적으로 이용 가능한 것은 아니었다. 맥길의 한 대에서 여러 서버로의 확장은 접근성을 넓혔지만, 발견과 전달을 하나의 권위 아래로 합치지는 않았다. 아카이브 운영자는 여전히 바이트를 통제했고, Archie는 이름이 관찰되었던 위치에 대한 유용하지만 날짜가 찍힌 기록을 조립했을 뿐이다. (RFC 1689)

Archie의 기여는 중앙의 답이 원격 파일을 최신 상태로 만들어준다는 것이 아니었다. 그것은 인터넷의 공개 파일 컬렉션을 그 파일을 소유하지 않으면서도 검색할 수 있을 만큼 읽기 쉽게 만들었다. 이 설계는 어려운 질문을 '이 파일이 어디에 있을 수 있는가?'에서 '이 관찰이 얼마나 오래되었으며, 아카이브가 여전히 이를 제공할 수 있는가?'로 옮겨놓았다. 검색은 근거로 가는 길이었고, 근거의 출처가 아니었다.

출처