대규모 웹 검색 엔진의 해부학, 구글 원형을 설계한 1998년 논문

게시 2026.07.15 · 약 6분 분량

1998년 세르게이 브린과 로런스 페이지는 스탠퍼드 대학원생 시절에 쓴 논문 한 편으로 구글의 원형을 공개했다. 제목은 'The Anatomy of a Large-Scale Hypertextual Web Search Engine'이다. 제목의 '하이퍼텍스트'는 웹의 링크 구조를 순위 신호로 쓴다는 뜻이고, 이 논문은 그 발상과 크롤러부터 검색기까지 이어지는 검색 엔진 전체 구조를 처음으로 자세히 밝힌 공개 문서다. 논문에 따르면 당시 프로토타입은 최소 2,400만 페이지 규모의 전문·하이퍼링크 데이터베이스를 갖췄고, 학술지 Computer Networks and ISDN Systems 30권(1998)에 실렸다. 이 글은 그 논문이 공개한 핵심 설계 — PageRank, 앵커 텍스트, 시스템 구조 — 를 개발자 눈높이로 정리한다. 최신 구글 내부 구현이 아니라 1998년 논문에 담긴 원형에 한정한다.

이 논문은 어떤 문제를 풀려 했나

핵심은 색인 크기가 아니라 검색 품질이었다. 브린과 페이지는 1997년 무렵 검색 엔진들이 색인만 키웠을 뿐 정작 사용자가 원하는 결과를 상위에 올리지 못한다고 봤다. 논문은 1994년 초기 검색 엔진의 하나였던 World Wide Web Worm이 약 11만 페이지를 색인했고, 1997년 11월에는 상위 엔진들이 200만(WebCrawler)에서 1억 페이지까지 색인했다고 적는다. 색인은 수백 배 커졌지만 사람이 실제로 확인하는 결과는 여전히 상위 수십 개뿐이다. 그래서 저자들은 관련 문서를 얼마나 많이 되찾는지(재현율)보다 상위 결과가 얼마나 정확한지(정밀도)를 택했다. 근거로는 1997년 11월 기준 상위 상용 검색 엔진 네 곳 중 자기 이름을 검색했을 때 상위 10위 안에 자기 검색 페이지를 띄운 곳이 단 하나뿐이었다는 관찰을 든다. 이름부터 규모를 겨냥했다. 논문은 10의 100제곱을 뜻하는 googol의 흔한 철자에서 'Google'을 따왔다고 밝혔다.

링크로 순위를 매기다: PageRank

PageRank는 링크를 '투표'로 보는 알고리즘이다. 한 페이지가 다른 페이지로 링크를 걸면 그 페이지에 표를 던진 셈이고, 표를 많이 받은 페이지에서 온 링크일수록 더 무겁게 친다. 학술 논문의 인용 수를 세는 방식을 웹에 옮기되, 링크를 건 페이지 자체의 중요도로 가중치를 준 것이다. 논문이 제시한 계산식은 다음과 같다. d는 감쇠 계수(damping factor)이고, 저자들은 보통 0.85로 둔다고 밝혔다.

PR(A) = (1 - d) + d ( PR(T1)/C(T1) + ... + PR(Tn)/C(Tn) )

 d = 0.85    # 감쇠 계수
 C(T) = 페이지 T에서 나가는 링크 수
 T1...Tn = A를 가리키는 페이지들

직관적으로 PageRank는 '무작위 서퍼' 모형이다. 링크를 따라 아무 페이지나 돌아다니다가 지루해지면 임의의 페이지로 점프하는 사용자를 가정한다. 감쇠 계수 0.85는 매 페이지에서 링크를 계속 따라갈 확률이고, 나머지 0.15가 임의 점프 확률이다. 이 무작위 점프 덕분에 링크를 인위적으로 몰아줘 순위를 조작하기가 훨씬 어려워진다. 규모도 논문이 숫자로 밝혔다. 저자들은 5억 1,800만 개의 하이퍼링크로 링크 지도를 만들었고, 2,600만 페이지의 PageRank는 중간 사양 워크스테이션에서 몇 시간이면 계산된다고 적었다.

앵커 텍스트를 왜 따로 색인했나

링크에 붙은 글자가 링크 건 페이지보다 대상 페이지를 더 잘 설명하기 때문이다. 앵커 텍스트는 <a href="https://example.com">여기 붙는 글자</a>를 가리킨다. 논문은 이 글자를 링크가 놓인 페이지가 아니라 링크가 가리키는 페이지에 연결해 색인했다. 이렇게 하면 이득이 둘이다. 첫째, 링크를 건 사람이 남의 페이지를 요약해 주니 페이지 자체 설명보다 정확할 때가 많다. 둘째, 이미지나 프로그램, 데이터베이스처럼 텍스트로 색인하기 힘든 대상, 심지어 아직 크롤링하지 않은 페이지까지 앵커 텍스트만으로 검색 결과에 넣을 수 있다. 논문은 2,400만 페이지를 크롤링한 당시 크롤에서 2억 5,900만 개가 넘는 앵커를 색인했다고 밝혔다. 앵커 텍스트를 전파하는 아이디어 자체는 앞선 World Wide Web Worm이 먼저 구현했지만, 구글은 이를 품질 신호로 본격 활용했다.

검색 엔진의 해부: 크롤러에서 검색기까지

논문 제목대로 시스템을 '해부'하면 데이터가 흐르는 파이프라인이 드러난다. URL 서버가 크롤러들에게 가져올 주소 목록을 나눠 주고, 여러 대의 분산 크롤러가 페이지를 내려받는다. 받은 페이지는 스토어 서버가 압축해 리포지터리에 저장하고, 새 URL마다 docID라는 정수 ID를 매긴다. 색인기(indexer)는 리포지터리를 읽어 압축을 풀고 문서를 파싱해, 각 단어를 위치·글꼴 크기·대소문자 정보를 담은 '히트(hit)'로 바꾼다. 이 히트들을 '배럴(barrel)'이라는 통에 나눠 담아 부분 정렬된 정방향 색인을 만든다. 색인기는 동시에 페이지의 모든 링크를 뽑아 앵커 파일로 저장한다. 정렬기(sorter)는 docID로 정렬돼 있던 배럴을 wordID 기준으로 다시 정렬해 역방향 색인을 만든다. 단어 하나로 그 단어가 든 문서를 바로 찾게 하려는 것이다. 마지막으로 검색기(searcher)가 웹 서버 위에서 돌며 역색인과 PageRank를 합쳐 질의에 답한다.

자료 구조는 디스크 탐색을 줄이려고 다듬었다. 논문은 디스크 탐색 한 번에 약 10밀리초가 든다고 보고, 가능하면 탐색을 피하도록 설계했다고 적는다. 히트 하나는 손으로 최적화한 압축 인코딩으로 2바이트에 담았고, 정방향 색인은 배럴 64개에 나눠 저장했다. 데이터 대부분은 여러 파일 시스템에 걸칠 수 있는 'BigFiles'라는 가상 파일에 압축해 뒀고, 문서 정보를 담은 문서 색인은 docID로 정렬한 고정폭 ISAM 색인을 썼다. 압축된 원본 HTML 리포지터리만으로 전체 저장 공간의 대략 절반을 차지했다. 논문은 구글 대부분이 효율을 위해 C나 C++로 구현됐고 Solaris나 Linux에서 돌아간다고 밝혔다.

이 설계가 지금도 유효한 이유

세부 수치는 20년 넘게 지나 낡았지만 설계 원칙은 남았다. 크롤링·저장·색인·랭킹을 별개 단계로 쪼개고 각 단계를 독립적으로 확장하는 구조는 지금의 대규모 시스템에서도 기본이다. 링크를 조작에 강한 품질 신호로 삼는 발상, 페이지 밖에서 온 설명인 앵커 텍스트를 페이지 이해에 쓰는 발상도 그대로 이어졌다. 현대 검색은 여기서 훨씬 멀리 갔다. 검색 엔진이 페이지를 더 정확히 읽도록 돕는 흐름은 오늘날 구조화 데이터로 저자·발행일 같은 신호를 직접 마크업하는 방식으로 이어진다. 앵커 텍스트가 '남이 매긴 설명'이라면 구조화 데이터는 '내가 기계가 읽게 매긴 설명'인 셈이다. 원문을 직접 읽고 싶다면 브린과 페이지가 속했던 스탠퍼드 인포랩(infolab.stanford.edu)에서 확인할 수 있다.