구글 검색엔진의 해부학

Abstract

이 논문을 통해 우리는 구글(Google)이라는, 하이퍼텍스트를 통해 나타나는 구조적 특징을 대폭 사용한 대형 검색 엔진의 프로토타입을 제시하고자 한다. 구글은 웹을 능률적으로 긁어와서 인덱싱(색인화)한 다음 (crawling & indexing) 기존의 시스템보다 훨씬 더 만족스런 검색 결과를 나타낼 수 있도록 디자인되었다. 최소 2천 4백만 페이지로 이뤄진 하이퍼링크 데이타베이스와 풀 텍스트로 이뤄진 구글의 프로토 타입은 http://google.stanford.edu의 주소로 이용해 볼 수 있다.

검색엔진을 제작한다는 것은 상당히 도전적인 과제다. 검색 엔진은 수억에서 수십억 개의 웹 페이지와 수억-수십억 개의 용어들을 함께 인덱싱한다. 또한 검색엔진은 매일 수천 만 개의 질의어에 응답한다. 웹 기반의 대형 검색엔진의 중요성이 분명함에도 불구하고 이에 대해 학문적으로 연구된 바는 거의 없다. 게다가 웹의 분화와 테크널러지의 발달이 매우 빠르기 때문에 오늘 웹 검색엔진을 만드는 것은 3년 전에 만드는 것과 전혀 다르다. 이 논문에서 우리는 우리가 만든 대형 웹 검색엔진에 대해서 자세하게 묘사하고자 한다.(현 시점까지 이렇게 자세한 내용이 공개된 것은 최초라 할 수 있다.)

전통적인 검색 기술을 거대한 크기의 데이타에 맞게 확장하는 것에서 초래되는 문제들은 별개로 하더라도, 보다 나은 검색 결과를 나타낼 수 있도록 하이퍼텍스트에 나타나는 부가적인 정보를 이용하는 문제 같은 새로운 기술적 과제들이 있다. 이 논문에서는 이와 같은 하이퍼텍스트에 존재하는 부가적인 정보를 실제 사용 가능한 대형 시스템을 구축하는 데 어떻게 활용할 수 있는가라는 문제에 대한 해결책을 제시한다. 또한 우리는 웹처럼 아무나 원하는 것을 출판할 수 있는 조절되지 않는 하이퍼텍스트 문서 컬렉션(uncontrolled hypertext collections)을 어떻게 효과적으로 다룰 수 있을지의 문제도 살펴본다.

1. 개괄

웹은 정보검색(IR; Information Retrieval)에 새로운 과제를 안겨줬다. 웹에 존재하는 정보들은 매우 빠르게 늘어나고 있다. 그리고 웹에서 무엇인가를 찾는 것에 익숙하지 못한 새로운 사용자들의 숫자도 급속하게 늘어나고 있다. 사용자들이 웹 써핑을 할 때 대개 링크 그래프(link graph)를 이용하는 경향이 크다. 사람이 직접 만든 목록 중 아주 높은 품질의 목록(야후! 같은)에서 출발하거나 검색엔진을 이용한다. 사람이 직접 유지관리하는 목록은 보편적인 주제를 효과적으로 커버할 수 있다는 장점이 있지만, 주관적이기 쉽고 구축/유지 비용이 매우 높고, 개선이 느리고 모든 특이한 주제를 커버할 수 없다는 단점이 있다. 한편 키워드 매칭(keyword matching)을 기반으로 하는 자동화된 검색엔진(automated search engine)은 대개 너무 많은 낮은 질의 맷치를 결과로 돌려주는 경우가 잦다. 게다가 어떤 광고인들은 자동화된 검색엔진이 엉뚱한 결과를 나타낼 수 있는 방법을 사용해서 사람들의 주의를 끌어가려는 시도를 한다. 우리는 이와 같은 기존 시스템의 여러가지 문제점들을 해결한 대형 검색엔진을 구축했다. 특히 우리 검색엔진은 훨씬 높은 수준의 검색 결과를 제공하기 위해 하이퍼텍스트에 존재하는 부가적인 구조를 대폭 사용했다. 우리는 우리 시스템 이름을 '구글'(Google)로 택했는데, 이것은 10¹⁰⁰ 또는 'googol'을 뜻하는 일반적인 철자이기 때문이기도 하고 매우 큰 스케일의 검색엔진을 구축하겠다는 우리의 목표와 잘 부합되기 때문이기도 했다.

1.1 웹 검색엔진의 확장: 1994 - 2000

검색엔진 기술은 웹의 성장세에 맞춰 극적으로 확장되어 왔다. 1994 년 최초의 검색엔진 중 하나인 World Wide Web Worm(WWWW)은 110,000 페이지의 웹문서 및 웹을 통해 접근가능한 문서를 색인화(indexing;인덱싱)한다. 1997년 현재, 최고 수준의 검색엔진들은 2백만 문서에서(WebCrawler) 1억 개의 문서까지 인덱싱했다고 주장하고 있다. 2000년 말쯤이면, 약 10억 개 이상의 문서에 대한 포괄적인 인덱스(comprehensive index)가 만들어질 것으로 예상되고 있다. 검색엔진이 다루는 질의어(queries)의 숫자 역시 믿기지 않을 정도로 성장해 왔다. 1994년 3,4월경, WWWW은 매일 평균 1500여 개의 질의어를 받았었다. 그런데 1997년 11월, 알타비스타(AltaVista)의 주장에 따르면 매일 약 2천만 개의 질의어를 처리하고 있다 한다. 웹 사용자가 더욱 늘어나게 됨에따라, 2000년 말쯤에 이르면 탑 검색엔진들은 매일 평균 약 수억 개의 질의어를 다루게 될 것이다. 우리 시스템은 검색엔진 기술을 위와 같은 놀라운 크기의 숫자를 다룰 수 있게 확장하는 데 있어 발생하는 많은 문제점들을 그 질적인 측면에서나 확장성 면에서나 잘 해결해 보겠다는 목표를 갖고 있다.

1.2 구글(Google): 웹과 함께 확장한다

오늘날의 웹 정도를 포괄하는 검색엔진을 만드는 일도 많은 도전적 과제를 해결해야 한다. 웹 문서들을 모으고 최신 상태로 유지하기 위해서는 빠른 속도의 크롤링 기술(crawling technology)이 필요하다. 그리고 색인(index)을 저장하고 때로는 문서 자체를 저장하기 위해 저장 공간은 반드시 효율적으로 사용되어야만 한다. 인덱싱 시스템은 수백 기가바이트의 데이타를 효율적으로 처리할 수 있어야만 하고 질의어 역시 초당 수백, 수천 개 이상의 빠른 속도로 처리되어야 한다.

이런 과제들은 웹이 계속 성장해 감에 따라 갈수록 어려워지고 있다. 하드웨어 성능과 비용이 극적으로 좋아지고 있는 것은 이런 문제점들을 어느 정도는 상쇄한다. 그러나 거기에도 주목할 만한 예외가 있다. 디스크 검색 속도(disk seek time)라든지 운영체계의 강력함(robustness)은 별로 개선되지 못하고 있다. 구글을 디자인함에 있어, 우리는 웹의 성장 속도와 테크널러지의 변천 속도 모두를 고려해 왔다. 구글은 극단적으로 큰 데이타 셋(data sets)을 위해서도 충분히 확장될 수 있도록 디자인되어 있다. 인덱스를 저장하기 위한 저장 공간을 효율적으로 사용할 뿐만 아니라 구글의 데이타구조는 빠른 억세스, 효율적인 억세스에 적합하도록 최적화되어 있다. (4.2 섹션에서 자세히 다룬다) 그리고 HTML이나 텍스트를 저장하고 인덱싱하는 비용은 그 양이 늘어남에 비해 상대적으로 감소할 것으로 예상된다. 이것은 구글과 같은 중앙집중식 시스템의 확장성에 좋은 영향을 미치게 된다.

1.3 디자인 목표

1.3.1 검색 품질의 개선

우리의 주된 목표는 웹 검색 엔진의 질적인 면을 개선하는 것이었다. 1994년 당시만 해도 완전한 검색엔진 인덱스를 갖춤으로써 무엇이든 쉽게 찾을 수 있을 것이라 믿는 사람들이 있었다. "Best of the Web 1994 -- Navigators"에는, "최상의 네비게이션 서비스는 웹상의 거의 모든 것을 쉽게 찾을 수 있도록 해줘야 한다 (일단 모든 데이타가 입력되고 나면)" 라고 실려있었던 것이다. 하지만 1997년의 웹은 그 전과 전혀 다른 양상이다. 최근 검색 엔진을 사용해 본 사람이라면 누구나 인덱스 자체의 완전성이 검색 결과의 품질을 결정하는 유일한 요소가 아님을 얘기할 것이다. "쓰레기 검색 결과"(Junk results)가 원하는 결과를 압도해버리는 것이 드물지 않다. 사실, 1997년 11월 현재, 검색창에 검색엔진 자신의 이름을 입력했을 때 탑 10 결과 내에 자신의 이름이 들어있는 검색 엔진은 상위 4 개의 상업적 검색 엔진에 불과하다.

이것의 주된 원인은, 문서의 수는 기하급수적으로 증가해온 반면 사용자가 문서를 찾는 능력은 그렇지 못했기 때문이다. 사람들은 여전히 검색 결과 중 수십 개 정도만을 보려한다. 그러므로 문서 모음(이하 컬렉션, collection)의 크기가 증가함에 따라 대단히 높은 프리시젼(precision)역자주을 가진 툴이 필요해진다. (precision은 검색 결과 중 실제 검색어와 관계되는 결과의 비율)

사실 우리는, "관계되는"이라는 단어의 의미를 아주 높은 수준으로 규정하려 했는데 그 이유는 '약간' 관계되는 문서들만 해도 수만 개 이상이기 때문이다. 극도로 높은 수준의 프리시젼은 심지어 리콜(recall)을 희생해서라도 달성해야 할 만큼 중요하다. (recall은 관계되는 문서 중 얼마나 많은 것을 찾아낼 수 있느냐를 의미)

최근, 하이퍼텍스트적인 정보를 보다 더 많이 이용함으로써 검색이나 다른 부문의 기능을 개선할 수 있을 것이라는 낙관적인 전망이 많이 나오고 있다. 특히 링크 구조와 링크 텍스트는 "관계성 판단"(relevance judgement)과 질적인 필터링에 있어서 많은 정보를 제공할 수 있다. 구글은 그 링크 구조와 앵커 텍스트(anchor text)를 사용하고 있다.

역자주 : recall과 precision은 정보검색(IR)에서 중요한 성능 측정 기준으로 사용하는 지표입니다. precision은 검색 결과 중에 실제로 '관계되는' 문서가 몇 개인가를 의미합니다. 즉, 결과의 '정확도'입니다. recall은 검색어와 관계되는 문서 전체 중에 몇 개를 찾아내느냐입니다. precision은 보통 상위 몇 위까지 중 관계되는 문서가 몇 개인가 형태로 평가합니다.

예를 들어 어떤 컬렉션의 총 문서 갯수는 100 개이고 이 중에 '사과'와 관계되는 문서가 30 개 있다고 합시다. 질의어 '사과'에 대해서 어떤 검색 시스템이 총 15 개의 결과를 되돌려 주었고 상위 10 위까지의 결과 중 실제로 사과와 관계되는 문서가 8 개였다면 precision과 recall은 이렇게 계산합니다.

상위 10 위에서의 precision = 8 / 10 = 0.8
recall = 15/30 = 0.5

논문은, 웹 검색의 경우 리콜이 극도로 높고 (대개 검색결과가 수만 페이지 이상이기 때문에) 사용자들은 상위 몇 개만을 보려하기 때문에 프리시젼이 극도로 높아야만 한다는 것을 얘기하고 있습니다. 소규모 도서관 정보 검색 시스템이라면 얘기가 전혀 다릅니다. 관계되는 모든 서적을 다 찾아내는 것이 더 중요할 수 있습니다. 그 때는 리콜이 더 중요합니다. 그렇다면 리콜과 프리시젼은 어떤 관계일까요? 반비례일까요, 비례일까요? 아니면?

1.3.2 검색 엔진에 관한 학술 연구

웹은 자체 성장속도 뿐만 아니라 상업화의 속도도 엄청나게 빠르다. 1993 년에는 .com 도메인이 전체의 1.5%였다. 그러던 것이 1997 년에는 전체의 60%를 차지하고 있다. 검색엔진 역시 학술적 영역에서 벗어나 상업화되어 왔다. 현재까지 기업체에서 개발한 검색엔진의 대부분은 기술적인 디테일을 거의 발표하지 않고 있다. 검색 엔진 기술은 장막에 가려진 채 광고 지향적인 것으로 남아있는 실정이다. 우리는 구글을 통해서 검색 엔진 개발과 이해를 보다 학술적인 영역으로 끌어와 보고자 했다.

또 하나 중요한 디자인 목표는 상당한 숫자의 사람들이 실제로 사용할 수 있는 시스템을 구축해 보자는 것이었다. 구축한 시스템이 실제로 사용되어야 한다는 점이 중요한데 그 이유는, 오늘날의 웹 시스템에서 만들어질 수 있는 대용량의 유시지 데이타(usage data)를 활용함으로써 아주 흥미로운 연구가 이뤄질 수 있다고 생각하기 때문이다. 예를 들면 매일매일 이뤄지는 수억 건의 검색 행위와 관계되는 데이타가 그렇다. 하지만 이런 데이타는 확보하기가 매우 어렵다. 상업적 가치가 높다고 여겨져서 공개되지 않기 때문이다.

마지막 디자인 목표는 대용량 웹 데이타상에서 많은 새로운 연구 활동이 이뤄질 수 있도록 그 기반을 구축해 보겠다는 것이었다. 새로운 연구에 사용되게 만들기 위해 구글은 크롤링한 실제 문서 그 자체를 압축된 형태로 저장한다. 구글을 디자인함에 있어 우리의 주된 목표 중 하나는 다른 연구자들이 웹의 상당한 부분을 처리해서 흥미로운 결과를 내놓은 것에 쉽게 참여할 수 있는 길을 터주자는 것이었다. 구글 시스템을 가동한 지 얼마되지 않았음에도 구글에 의해 생성된 데이타베이스를 이용한 여러 편의 연구가 이미 발표되었고 또한 많은 연구가 현재 진행중이다. 또 하나의 목표는 구글을 일종의 우주 실험실과 같은 환경으로 만들어서 다른 연구자들이나 학생들이 대형 웹 데이타상에서 여러가지 흥미로운 실험을 제안하고 실행해 볼 수 있게 하겠다는 것이다.

구글 검색 엔진은 검색 결과가 높은 프리시젼을 갖도록 두 가지 중요한 특징을 부여했다.
첫째, 구글은 개별 웹 페이지 품질을 순위 매기기 위해 웹의 링크 구조를 이용한다. 이 랭킹은 페이지랭크(PageRank)라 일컬어지며 다른 논문에서 자세히 설명했다. 둘째, 구글은 검색 결과를 개선하기 위해서 링크를 사용한다.

2.1 페이지랭크(PageRank) : 웹에 순서를 매긴다

웹의 인용(링크) 그래프는 기존의 웹 검색 엔진들이 거의 사용하지 않고 있는 중요한 자원 중 하나이다. 우리는 총 5억1800만 개의 하이퍼링크를 담고 있는 링크 지도를 만들었는데 이것은 전체 웹의 상당 부분을 포괄하는 것이다. 이 지도를 이용하면 어떤 웹 페이지의 "페이지랭크" 값을 빠르게 계산할 수 있다. 페이지랭크는 일반적인 사용자가 생각하는 특정 페이지의 중요성과 잘 상응하는 인용 중요성의 객관적인 측정치다. 인간 판단과의 이런 연관성 때문에 페이지랭크는 웹 키워드 검색 결과를 순위 매기는 데 있어 최상의 수단이 된다. 대부분의 일반적 검색어에 있어서, 문서 제목과 검색어가 일치하는지만을 평가하는 단순한 텍스트 매칭 검색 엔진을 이용한 결과에서도, 그 결과를 페이지랭크로 순위를 매기는 경우 상당한 성능을 보여준다. 물론 구글 시스템과 같이 완전한 텍스트 검색을 수행하는 시스템에서도 페이지랭크는 매우 큰 도움을 준다.

2.1.1 페이지랭크 계산 방법

학술 문헌 인용 방식을 웹에도 적용해보려는 시도가 있어 왔는데 대개 어떤 페이지의 인용 횟수(백링크; back link)를 세는 방식으로 이뤄진다. 어떤 페이지가 얼마나 많이 인용(참조)되고 있는가를 셈으로써 그 페이지의 중요성이나 품질을 추정해볼 수 있는 것이다. 페이지랭크는 이 아이디어를 더욱 확장해서 단순히 모든 링크를 세는 것에서 한 발 더 나아가 그 링크가 어떤 페이지로부터 왔는지를 차별화했고, 링크를 하고 있는 페이지로부터 외부로 나가는 총 링크 갯수로 노멀라이징(normalizing)했다. 페이지랭크는 다음과 같이 정의된다:

페이지 A를 가리키는 다른 페이지들이 T1, T2, ... Tn 까지 있다고 하자. ( = T1,...Tn은 페이지 A를 인용)
퍼래미터 d는 damping factor로 0에서 1 사이의 값을 갖는다. 우리는 보통 d = 0.85로 했다. d값에 관해서는 다음 섹션에서 다룬다.
C(A)는 페이지 A에서 밖으로 나가는 링크의 갯수다. 이때 A 페이지의 페이지랭크 PR(A)는:

페이지랭크 PR(A)는 단순한 반복 알고리듬(iterative algorithm)을 이용해서 계산할 수 있으며, 그 값은 웹 링크를 노멀라이징해서 행렬로 바꾸었을 때 주고유벡터(principal eigenvector)에 해당한다. 또한 2천6백만 페이지의 페이지랭크는 중간 크기의 웍스테이션에서도 몇 시간 정도면 계산할 수 있다. 이에 관해서는 이 페이퍼의 범위를 벗어나는 많은 세부사항이 있다.

2.1.2 직관적 정당화

페이지랭크는 사용자 행동을 모델링한 것으로 생각해볼 수 있다.
"랜덤 써퍼"가 한 명 있다고 하자. 이 사람은 무작위로 선택한 어떤 웹 페이지에서 출발해서 백버튼을 누르지 않고 계속 링크를 따라 클릭해 나간다. 그러다가 지루해지면 또 다른 무작위로 선택된 페이지에서 써핑을 시작할 것이다. 랜덤 써퍼가 특정 페이지를 방문할 확률이 바로 그 페이지의 페이지랭크다. 그리고 d damping factor는 랜덤 써퍼가 어떤 페이지를 읽다가 지루해져서 또 다른 랜덤 페이지를 찾게될 확률을 뜻한다. 페이지랭크의 변형된 형태 중에서 중요한 것 중 하나가 댐핑 팩터(damping factor) d를 특정 페이지 하나 또는 일군의 페이지에만 선택적으로 적용하는 것이다. 이렇게 함으로써 사용자화(personalization)가 가능하며 랭킹을 올리기 위해 교묘하게 조작하는 것을 사실상 불가능하게 만들 수 있다. 그 외에도 많은 페이지랭크의 확장이 있다.

또 하나의 직관적인 정당화는, 페이지랭크가 올라가기 위해서는 많은 페이지가 어떤 한 페이지를 가리켜야 하거나 특정 페이지를 가리키는 페이지 그 자체의 페이지랭크 값이 커야 한다는 점이다. 직관적으로도 웹상의 여러 곳에서 인용되고 있는 페이지는 살펴볼 만한 가치가 있다는 의미이므로 쉽게 이해가 된다. 또한 Yahoo!와 같은 중요한 곳에서 인용이 되고 있다면 링크가 오직 한 개뿐일지라도 그 페이지는 살펴볼 가치가 있을 것이다. 어떤 페이지가 품질이 낮거나 링크가 깨져있다면, Yahoo!같은 곳에서 그 페이지로 링크를 걸어놓지 않을 것이기 때문이다. 페이지랭크는 이 두 가지 경우 모두를 잘 다루고 있으며 양자 사이의 모든 부분도 웹의 링크 구조를 통해 가중치를 재귀적으로 전파시켜 나감으로써 잘 다루고 있다.

2.2 앵커 텍스트(Anchor Text)

우리 검색 엔진은 링크의 텍스트 그 자체를 특별하게 다룬다. 대부분의 검색 엔진들은 링크의 텍스트를 링크를 담고 있는 그 페이지와만 연관시킨다. 우리는 더 나아가 링크가 가리키는 페이지까지 링크의 텍스트와 연관시킨다. 이것은 여러가지 장점이 있다. 첫째, 앵커는 종종 그 링크가 담겨있는 페이지보다 그 링크가 가리키는 페이지에 대한 보다 정확한 설명을 담고 있는 경우가 많다. 둘째, 일반적인 텍스트 검색 엔진이 인덱싱할 수 없는 이미지나 프로그램, 데이타베이스로의 앵커(링크)도 존재할 수 있다. 그러므로 앵커를 활용하면 실제로 크롤링되지 않은 웹 페이지들까지 찾아낼 수 있다. 물론 크롤링되지 않은 페이지들이 문제를 일으킬 수 있다는 점은 주의해야 한다. 이 페이지들은 사용자에게 결과로 뿌려주기 전에 유효성을 먼저 테스트 해야한다. 심지어 실제 존재하지 않는 페이지인데도 가리키는 링크가 있기 때문에 반환될 수도 있다. 하지만 이런 검색 결과를 분류하는 것이 가능하므로 특별한 문제를 일으키는 경우는 거의 없다.

앵커 텍스트를 그 앵커가 가리키는 페이지로 전파시켜 나간다는 아이디어는 World Wide Web Worm 검색 엔진에서 구현되었었다. 앵커 텍스트가 텍스트가 아닌 정보를 검색하는데 도움이 되었고, 검색 엔진이 다운로드한 문서보다 훨씬 더 많은 부분을 커버할 수 있게 확장해주기 때문이다. 앵커 텍스트를 효율적으로 사용하려면 대용량의 데이타를 처리해야만 하기 때문에 기술적으로 까다롭다. 우리는 크롤링한 2400만 페이지에서 약 2억5900만 개 이상의 앵커를 인덱싱할 수 있었다.

2.3 다른 특징들

페이지랭크 기술과 앵커 텍스트를 사용한다는 점 외에 구글은 몇 가지 다른 특징을 가진다.
첫째, 구글은 모든 힛(hit)에 관한 위치 정보를 저장하기 때문에 검색 時 근접도를 광범위하게 활용한다. 둘째, 구글은 어떤 단어의 폰트 크기와 같은 시각적인 세부 요소를 추적한다. 폰트 싸이즈가 큰 단어나 볼드체로 된 단어는 그렇지 않은 단어에 비해 더 높은 가중치가 부여된다. 셋째, 구글은 완전한 HTML도 저장하기 때문에 이를 이용할 수 있다.

3. 관련 연구

웹 상의 검색 연구는 역사가 얼마 되지 않는다. World Wide Web Worm (WWWW) 검색 엔진이 대표적인 최초의 검색엔진이다. WWWW을 기점으로 그 뒤에 몇 개의 학술적 목적의 검색엔진이 나타났다. 웹의 성장세나 검색 엔진의 중요성에 비해 현대적 웹 검색엔진에 관한 문서는 거의 없는 실정이다. Michael Mauldin(Lycos 의 Chief Scientist)씨는, "라이코스를 포함한 여러 서비스들은 자기 데이타베이스의 디테일들을 엄격하게 감추고 있다"고 밝혔다. 하지만 검색엔진의 특정 기능에 관해서는 상당한 양의 연구가 진행되어 왔다. 특히 기존의 상업적 검색엔진을 이용한 결과물을 후처리(post processing)한 것에 관한 부문이 두드러진다. 반면 정보검색(IR, Information Retrieval)에 관해서는, 특히 잘 조절되고 있는 컬렉션을 대상으로한 것은, 이미 많은 연구가 나와있다. 다음 두 섹션에서, 우리는 이들 연구를 웹에서 보다 더 잘 동작하도록 확장하는 방법을 살펴볼 것이다.

3.1 정보 검색

정보 검색 시스템에 관한 연구는 오래 전부터 있어 왔으며 잘 정리되어 있다. 하지만 대부분의 정보 검색 시스템에 관한 연구는 소규모의 잘 통제되고 있는 동질적인 컬렉션(a small well controlled homogenous collection)을 대상으로 하고 있다. 예를 들면 과학 논문이나 서로 연관되는 뉴스 기사들을 대상으로 하고 있다. 실제 정보 검색의 가장 대표적인 벤치마크로 사용되는 TREC(Text Retrieval Conference)의 경우 아주 작은 크기의 잘 통제되어 있는 컬렉션을 이용한다. "초대형" 벤치마크라고 해 봐야 겨우 20기가 바이트에 지나지 않는다. 반면 우리가 모아놓은 2천400만 개의 웹 페이지는 147기가 바이트에 이른다. TREC에서는 좋은 결과를 보이더라도 웹에서는 좋은 결과를 나타내지 못하는 경우가 많다. 예를 들어, 표준적인 벡터 공간 모형(Vector Space Model)은 질의어와 문서를 단어 빈도에 의거한 벡터로 파악해서 질의어에 가장 근접한 문서를 되돌려주는 방식이다. 하지만 웹에서 벡터 공간 모형을 사용하면 질의어 외에 몇 단어 없는 매우 짧은 문서가 반환되는 경우가 많다. 메이져 검색 엔진에 "Bill Clinton"이라는 질의어를 넣어 보면 "Bill Clinton Sucks"라는 문장과 사진이 담겨 있는 페이지만 결과로 되돌려 준다. 어떤 사람은 질의어 외에 부가적으로 단어를 추가해서 사용자가 찾는 단어를 더 정확하게 표현할 수 있는것 아니냐고 주장한다. 우리는 그런 주장에 전혀 동의하지 않는다. 사용자가 "Bill Clinton"이라는 질의어를 입력했다면 당연히 합리적으로 받아들일 수 있는 결과를 얻어야 한다. 웹에는 그 주제에 관한 엄청나게 많은 고품질의 페이지가 있기 때문이다. 이런 예들을 보면서 우리는 표준적인 정보 검색 연구를 웹에 효과적으로 적용하기 위해서는 더욱 많은 확장이 필요하다고 생각하게 되었다.

3.2 웹과 잘 통제되는 컬렉션 사이의 차이점들

웹은 전혀 통제되지 않는 이질적인 문서들로 이뤄진 거대한 컬렉션이다. 웹상의 문서는 문서 내부적으로도 극단적으로 다양할 뿐만 아니라 문서 외부적인 메타 정보 역시 매우 다양하다. 예를 들어, 여러 웹 문서들은 내부적으로 사용 언어 측면에서 다르고 (인간의 언어 측면에서도 그렇고 컴퓨터 언어 측면에서도 그렇다), 어휘에 있어서도 다르고 (이메일 주소, 링크, 우편 번호, 전화 번호, 제품 번호 등), 포맷이나 유형 면에서도 다르며 (텍스트, HTML, PDF, 이미지, 싸운드) 심지어 어떤 문서들은 컴퓨터에 의해 생성되고 있는 것이다. (로그 파일, DB 로부터 출력된 내용)

메타 정보의 경우도 마찬가지다.
우리는 외부 메타 정보를 어떤 문서 내부에는 담겨 있지 않은 정보로, 그 문서 자체에 관해 유추할 수 있는 정보로 정의한다. 외부 메타 정보에는 그 페이지의 명성, 업데잇 빈도, 품질, 인기도 또는 유시지(usage), 그리고 인용 등이 있다. 외부 메타 정보는 그 잠재적 소스가 다양할 뿐만 아니라, 측정값 역시 큰 차이가 난다. 야후! 홈페이지와 수십 년된 낡은 기사를 비교해 보자. 야후!는 매일 수백만 페이지뷰 이상을 받지만, 후자의 경우는 십 년만에 한 번 찾아지거나 할 것이다. 이 경우 사용도는 현격하게 차이가 난다. 그리고 검색 엔진은 이 둘을 전혀 다른 방식으로 다뤄야 한다는 것 역시 당연하다.

잘 통제되는 컬렉션과 웹이 크게 다른 또 다른 점은, 웹에서는 누가 무엇을 올려놓을지를 조절할 방법이 사실상 없다는 점이다. 무엇이든 퍼블리슁할 수 있다는 웹의 유연성이 트래픽을 안내하는 검색 엔진의 엄청난 영향력과 맞물리면, 검색 엔진을 교묘하게 조절해서 이득을 취해가려는 회사들이 심각한 문제가 된다. 이런 점들은 전통적인 폐쇄적 정보검색 시스템에서는 전혀 문제가 되지 않았었다.

웹 검색 엔진의 경우 메타 데이타(메타 택 (Meta Tag))를 사용하려는 시도가 거의 실패로 돌아갔다는 점 또한 특기할 만하다. 실패한 이유는 검색 엔진을 악용하기 위해 메타 정보가 남용되었기 때문이다. 심지어 메타 태그를 이용, 검색 엔진을 조작하는 쪽으로 특화한 회사들도 상당수 존재할 정도이다.

[원본자료]http://www.emh.co.kr/xhtml/google_search_engine.html