인덱스 파일은 퇴출 계획이었다: ALIWEB의 웹 검색 실험, 1993–94

요약

• ALIWEB은 무엇을 기술할지 선택하는 권한을 각 정보 제공자에게 맡기면서, 수집과 검색은 중앙 서비스가 유지했다.
• 1994년 파일럿은 작은 색인이 다른 목록에서도 활용될 수 있음을 보여 주었으나, 웹 전체를 커버했거나 광범위한 채택을 이뤘다는 것은 입증하지 못했다.

1993년 말이 되자 웹의 문제는 더 이상 문서를 어떻게 발행하느냐만이 아니었다. 모든 서버를 사람이 직접 훑거나 로봇에게 도달 가능한 모든 페이지를 가져오게 하지 않고도 유용한 문서를 찾으려면 어떻게 해야 하는가가 문제였다. 수작업 목록은 맥락을 제공할 수 있었지만, 목록 관리자는 모든 변화와 새 서비스를 볼 수 없었다. 크롤러는 더 많은 것을 발견할 수 있었지만 반복적인 요청은 서버에 부담을 주었고, 기계는 컬렉션을 이해 가능하게 만드는 구조를 놓칠 수 있었다.

1993년 11월 30일, Martijn Koster는 ALIWEB을 “분산형” 웹 색인 실험으로 발표했다. 각 서버는 자신의 콘텐츠를 로컬 파일로 광고하고, 하나의 사이트가 그 파일들을 가져와 처리하며, 사용자는 웹을 통해 통합 데이터베이스를 검색할 수 있었다. Koster의 이후학회 논문에 따르면, 파일럿은 이미 10월부터 NEXOR에서 운영 중이었다. Koster는11월 30일 발표에서 이 설계를 최종 답이 아니라 첫걸음이라 불렀고, 눈에 띄는 약속을 했다. 더 나은 방식이 등장하면 데이터를 쉽게 활용하거나 변환할 수 있어야 한다는 것이었다.

이 약속은 그 아키텍처를 읽는 방식을 바꾼다. ALIWEB은 검색 서비스를 분산화하지 않았다. 색인에 대한 통제권을 나눈 것이다. 사이트 관리자는 어떤 문서와 서비스가 기록에 값하는지 선택하고 그 기술을 제공했다. ALIWEB 운영자는 참여 서버의 목록을 관리하고, 각 파일을 언제 가져올지 결정하며, 형식을 검증하고, 승인된 기록을 통합해 검색 인터페이스를 운영했다. 제공자가 자기 사이트에 대한 기술을 소유했고, 그 기술이 여러 사이트에서 발견 가능해지는 경로는 서비스가 소유했다.

입력은 일반적으로/site.idx라는 이름의 준비된 텍스트 파일로, Internet Anonymous FTP Archives(IAFA) 템플릿에서 만들어졌다. 이러한 속성-값 기록 하나의 파일 안에서 여러 객체를 기술할 수 있었다. 예컨대 템플릿 유형, 제목, URI, 설명, 키워드 등이다. 이 형식은 ALIWEB에게 마크업으로부터 모든 페이지의 의미를 추론하도록 요구하지 않았다. 사이트 구조를 아는 사람들이 내부 조직을 그대로 둔 채 선별된 진입점을 노출할 수 있는 방법을 준 것이다. Koster의 샘플은 서버의 모든 파일이 아니라 NEXOR의 Perl 자료와 그 매뉴얼을 기술한다.

참여에는 여전히 작은 운영 계약이 필요했다. 관리자는 호스트, 포트, 색인 파일 경로를 등록하고, 책임 연락처를 제공하며, 가져오기 사이 최소 간격을 지정할 수 있었다. 서비스는 등록을 수락하기 전에 파일과 그 형식을 검증했다. 별도의 Perl 수집기는 등록된 파일을 점검하고, 변경된 사본을 가져오고, UNIXcron일정에 따라 통합 데이터베이스를 재구축했다. 같은 데이터베이스는 ALIWEB 자체의 웹 양식으로 검색하거나 CUI W3 Catalog를 포함한 다른 목록에 통합될 수 있었다.

웹을 걷는 로봇과의 차이는 절대적인 것이 아니라 실용적인 것이었다. ALIWEB은 가져오기와 데이터베이스 구성을 자동화했지만, 호스트의 모든 링크와 문서를 순회하는 대신 지명된 색인 파일 하나를 가져왔다. 이는 수집 트래픽을 낮추고 제공자가 맥락을 보존하게 했다. 그러나 침묵에도 의미가 생겼다. 제공자의 색인에 없는 페이지는 크롤러가 도달할 수 있었더라도 보이지 않은 채 남을 수 있었다. 검색 결과는 제공자 파일만큼 최신일 수 있었지만, 신선함은 중앙 수집기만으로 보장되지 않았다.

Koster가 보고한 파일럿 수치는 도달 범위와 한계를 모두 보여 준다. 논문 시점까지 54개 호스트가 등록했고 데이터베이스에는 310개 항목이 있었다. ALIWEB의 단순 검색 양식은 하루 평균 80건의 질의를 처리했고, CUI W3 Catalog는 같은 데이터베이스를 바탕으로 주당 8,000건 이상의 질의를 처리했다. 이 수치는 작동하는 서비스와 하나의 유용한 통합을 확인해 준다. 그러나 색인된 웹의 비율, 결과의 품질, 혹은 몇 개의 호스트가 사용 가능한 파일을 유지할 수 있고 의지했는지는 측정하지 않는다.

온보딩 문제는 초기부터 드러났다. 일부 관리자는 색인 파일을 제공하지 않은 채 호스트를 등록했는데, 모델을 이해하기 전에 등록 양식에 먼저 도달했기 때문으로 보였다. Koster의 팀은 문서를 확충하고 파일 존재 여부와 형식에 대한 즉시 검사를 추가했다. 오류는 계속되었고, 파일럿은 이를 기록한 뒤 수동 실행 스크립트로 책임자에게 이메일을 보냈다. 이것은 유지보수가 필요 없는 분산화가 아니었다. 모든 페이지를 크롤링하는 일이, 관리된 색인을 만들고 검증하고 갱신하는 일로 옮겨진 것이다.

“수작업”이 영원히 손으로 입력한다는 뜻이었던 것도 아니다. Koster는 결과가 선별에 필요한 충분한 기술 메타데이터를 유지한다면 소프트웨어가 파일을 생성할 수 있다고 주장했다. 1995년까지 별도의 아카이브 프로젝트는 파일시스템 변경 사항에서 IAFA 템플릿을 갱신하고 이를 텍스트, Gopher, HTML 색인으로 도출하는 과정을 문서화했다. 이후의 이W3C 학회 논문은 템플릿 개념이 여러 보기(view)로 이동할 수 있음을 보여 준다. 그러나 ALIWEB 자체의 코퍼스가 이전되었거나 서비스가 광범위한 채택에 도달했다는 것은 확립하지 않는다.

규모는 설계의 두 번째 경계를 드러냈다. 웹 전체를 위한 단일 데이터베이스가 너무 커질 수 있다는 점을 Koster는 인정했다. 그는 여러 출구를 제안했다. 수집 작업을 분산하거나, 검색 접근을 미러링하거나, 데이터베이스를 주제별로 분할하거나, ALIWEB 서비스의 계층 구조를 만드는 것이었다. 그는 또한 색인 파일이 미래의 디렉터리 시스템으로 자동 변환 가능할 것으로 기대했다. 이는 종이 위의 옵션이었고, 배포된 기능이 아니었다. 그 중요성은 형식이 파일럿의 중앙 수집기보다 오래 살아남도록 의도되었다는 데 있다.

1994년 네트워크 정보 검색 조사에서 이 분야는 여전히 초기 단계로 기술되었고, 분류 같은 기능은 아직 널리 퍼지지 않았다. ALIWEB은 수작업 색인, CUI W3 Catalog, JumpStation과 RBSE URL 데이터베이스 같은 로봇 기반 접근과 나란히 있었으며, 최초의 웹 검색 도구는 아니었다. 더 좁은 기여는 출처가 스스로 선택한 기술들을 자동으로 수집하고 다른 곳에서 재사용할 수 있음을 보여 준 것이었다.

Lu Heng의 이후Running-Code Primacy에 관한 노트 65는 회고적 렌즈를 제공하며, Koster의 사고에 대한 증거가 아니다. 형식은 이식성을 제안할 수 있지만, 그 이식성을 실제로 만드는 것은 이를 채택하는 작동하는 시스템뿐이다. 논문은 ALIWEB이 작동하고 있고 W3 Catalog가 그 데이터베이스를 사용하고 있음을 문서화한다. 보편적 채택, 웹 발행자에 대한 위임, 완료된 이전을 문서화하지는 않는다. 따라서 유용한 역사적 구분은 세 부분이다. 제공자들은 자기 사이트가 무엇을 말하는지 결정했고, ALIWEB은 무엇이 공유 색인에 들어가는지 결정했으며, 미래의 시스템은 파일럿의 중앙 서비스를 물려받지 않고 파일을 재사용할 수 있었다.