요약

  • Veronica는 Gopher 메뉴 제목을 검색하여 선택 가능한 Gopher 항목을 돌려주었다. 항목 뒤에 있는 파일의 내용까지 검색하지는 않았다.
  • 1994년까지 네바다에서의 데이터 수집과 8개 공개 사이트에서의 질의 처리는 각각 별개의 기능으로 분리되었고, 색인은 외부로 복제되었다.
  • 이 설계는 발견 가능성을 넓히면서도, 커버리지·명명 품질·갱신 시점·로컬 제외 설정은 운영자와 게시자의 손에 남겨두었다.

검색이 수천 건의 결과를 돌려주면서도 단 하나의 문서도 읽지 않았을 수 있다. 1990년대 초 Veronica가 Gopher 사용자에게 제시한 거래가 바로 그것이었다. 서버 메뉴에 인쇄된 제목을 검색한 뒤, 일치하는 항목들로 이루어진 메뉴를 돌려주는 방식이었다. 독자는 그중 하나를 선택해 원본에 도달할 수 있었다. 이 색인은 파일들을 하나의 중앙 저장소로 옮기지 않으면서도 네트워크를 더 쉽게 찾게 해주었다.

1992년 11월 17일 Steve Foster의 공식 발표는 Veronica를 확장 중이던 Gopher 웹의 발견 병목에 대한 실험적 해법으로 소개했다. 당시 258개의 Gopher 서버를 색인했고 500개 이상을 발견한 상태였다. Foster는 이 서비스가 최초의 장비를 넘어 성장할 것으로 예상하며 개발자들이 배포를 계획하고 있다고 밝혔다. 발표문은 핵심 제약을 정직하게 서술했다. Veronica는 각 사이트의 전문(全文)이 아니라 메뉴 제목을 색인한다는 점이었다. 결과 항목은 독자가 별도로 방문해야 하는 호스트명 목록이 아니라 여전히 Gopher 항목 자체였기에 유용했다.

이 구분은 주변 프로토콜에도 반영되어 있었다. 1993년 3월에 공표된 RFC 1436은 Gopher의 타입 7 검색 트랜잭션을 설명하는데, 클라이언트가 선택자(selector)와 검색어를 보내면 서버가 메뉴를 돌려준다. RFC는 Gopher 서버들이 콘텐츠 색인을 구현할 수 있었기 때문에 이를 전문 검색 트랜잭션이라 부른다. 그러나 그 일반적 명칭은 Veronica 자체의 색인을 설명하지 않는다. 1994년까지 발간된 당대 안내서와 Veronica 운영 문서들은 일반 검색이 항목 제목 속 단어와 일치시킨다는 점을 명확히 했다. 디렉터리 제목, 파일 제목, 이미지 라벨은 찾을 수 있었지만, 다른 서비스가 그 문서를 색인하지 않는 한 문서의 본문은 검색 대상이 아니었다.

작고 공통된 인터페이스 뒤에는 두 부분으로 이루어진 서비스가 있었다. 데이터 수집기는 접근 가능한 Gopher 메뉴를 순회하며 색인을 준비하고 데이터세트를 배포했다. 질의 서버는 Gopher 클라이언트의 타입 7 요청에 응답했다. 1994년 2월, Veronica 개발자 Steven Foster가 편집한 상태 보고서는 수집과 준비가 네바다 대학교에서 이루어지고 데이터세트는 다른 사이트들에서 제공되었다고 밝혔다. 8개의 공개 서버는 1993년 7월부터 미국과 유럽의 연구 네트워크 및 기관의 지원 아래 운영되었다. 같은 보고서는 공개 서버들이 2월에 120만 건의 질의를 처리했으며 대부분이 20초 미만에 처리되었다고 추산했다. 이 수치는 당대의 추정치이며 독립적으로 감사된 트래픽 통계가 아니다.

규모는 빠르게 커졌다. 1994년 보고서는 약 2,500대의 인터넷 호스트에서 3,200개 이상의 Gopher 서버를 집계했다. Foster의 FAQ는 이후 1994년 6월 기준 약 5,500개의 Gopher 서버에서 색인된 약 1,000만 개 항목, 11월에는 약 1,500만 개 항목을 보고했다. 1995년 1월에는 5,057개의 Gopher 서버와 더불어 웹 서버, 텔넷 서비스 등 Gopher 메뉴에서 참조되는 약 5,000개의 다른 서비스를 나열했다. 이 수치들은 서로 다른 시점과 범주를 나타내므로 하나의 총계로 합쳐서는 안 된다. 다만 이 수치들은 Gopher 메뉴에 부착된 제목 색인이 Gopher 자체를 넘어서는 자원을 가리키는 포인터까지 노출할 수 있음을 보여준다.

색인이 있다고 해서 모든 항목이 똑같이 찾아지는 것은 아니었다. FAQ에 따르면 새 서버는 월간 수집 주기를 놓칠 수 있었고, 장애나 접근 제한으로 색인에서 빠질 수도 있었다. 사이트 관리자는 자신의 서버 전체를 제외하거나, 제어 파일을 통해 Veronica가 선택된 메뉴만 색인하도록 허용할 수 있었다. 이는 프라이버시와 로컬 선택권에 중요했지만, 동시에 “찾을 수 없음”이 “수집되지 않음”, “접근 불가”, 또는 “검색어가 제목에 없음”을 의미할 수도 있었다는 뜻이었다. Veronica의 질의 안내서는 구체적인 단어 사용을 권했고, 항목 유형이나 불리언 연산자로 좁히는 기능을 제공했다. 기본값으로 서버는 처음 200개 일치 항목만 돌려주었다. 인기 있는 단어 하나가 넓은 색인을 두 번째 탐색 문제로 바꿔놓을 수 있었다.

복제는 또한 시점 차이를 낳았다. Foster의 질의 안내서는 이상적으로는 어떤 Veronica 서버든 같은 답을 돌려줘야 한다고 말했다. 그러나 실제로는 서버들이 서로 다른 시점에 갱신되어 결과가 달라질 수 있었고, 부하와 네트워크 트래픽에 따라 응답 속도가 변했다. 분산된 질의 처리 능력이 중앙 의존성을 없애지는 못했다. 네바다 팀은 여전히 공유 데이터세트를 준비했다. 그리고 중앙 색인이 모든 Gopher 게시자를 지휘하지도 않았다. 색인은 도달 가능한 링크를 따라가고, 게시자가 제공한 이름으로 작동하며, 제외 제어를 존중했다.

이 균형이 바로 역사적 포인트다. Veronica는 네트워크 전역의 발견 계층을 추가하면서도 근본 정보를 소유한다는 가장을 하지 않았다. 작은 공통 요청 하나가 여러 기관으로부터 조립된 결과를 만들어낼 수 있었지만, 로컬 서버는 자신의 파일과 메뉴 색인 여부에 대한 일부 통제권을 유지했다. 노트 64는 공유 명세가 어디서 끝나고 로컬 운영이 어디서 시작되는지를 묻는 데 유용한 이후의 관점을 제공한다. 단, 그것은 Veronica에 대한 근거가 아니며 수십 년 뒤에 작성된 것이다. 당대 기록이 대신 보여주는 것은 구체적인 거래다. 검색 가능한 라벨, 분산 복제된 색인, 그리고 게시자로 되돌아가는 살아 있는 경로. 이 시스템은 자신의 수집과 제목이 보이게 하는 것만 찾을 수 있었고, 그 한계는 전문 검색이라는 약속 뒤에 숨겨진 결함이 아니라 아키텍처의 일부였다.

출처:Foster의 1992년 11월 17일 발표;RFC 1436;RFC 1580;RFC 1689 / FYI 25;RFC 1739;Veronica FAQ, 1부;Veronica FAQ, 2부.