정적 검색 색인, 책 뒤 찾아보기가 웹으로 온 날

두꺼운 전문서 맨 뒤에는 찾아보기가 붙어 있어요. 단어 하나를 거기서 찾으면 몇 쪽으로 가야 하는지 바로 나와요. 이 목록은 책의 내용을 늘리지 않지만 책을 쓸 수 있는 물건으로 만들어요.

컴퓨터의 검색도 같은 구조예요. 글 전체를 매번 처음부터 읽는 대신, 어떤 단어가 어느 문서에 나오는지 미리 정리해 둔 목록을 봐요. 원문에서 단어를 찾는 방향을 뒤집어 단어에서 문서를 찾게 만들었다고 해서 이 자료 구조를 역색인이라고 불러요. 검색이 빠른 이유는 컴퓨터가 빨라서가 아니라 답의 절반이 미리 계산돼 있기 때문이에요.

서버가 없어도 검색이 되는 이유

검색이라고 하면 대개 서버가 하는 일로 여겨요. 방문자가 단어를 보내면 서버가 데이터베이스를 뒤져 결과를 돌려주는 그림이에요. 그런데 이 시리즈의 첫 글에서 다룬 대로, 미리 구워 둔 파일만 내보내는 사이트에는 뒤져 볼 서버가 없어요.

방법은 역색인을 글과 함께 만드는 거예요. 예를 들어 ‘캐시’가 2번과 7번 글에 나온다는 목록을 미리 두면, 브라우저는 모든 본문을 읽지 않고 후보 글을 찾을 수 있어요. 글과 색인을 같은 빌드에서 만들면 함께 맞추기 쉬워요. 다만 배포를 일부만 올리거나 오래 열린 브라우저가 이전 색인을 갖고 있다면 버전이 어긋날 수 있어요. 같은 빌드로 만드는 것과 독자에게 같은 묶음이 도착하는 것은 따로 지켜야 할 조건이에요.

대신 다른 제약이 생겨요. 색인은 글이 늘수록 커지는데 그것을 방문자가 내려받아야 해요. 검색 한 번에 색인 전체를 받게 하면 배보다 배꼽이 커져요. 그래서 요즘 방식은 색인을 잘게 나눠 두고 검색어에 해당하는 조각만 가져가요. 정적 사이트용 검색 도구인 Pagefind는 이 방식으로 만 쪽 규모의 사이트도 전체 내려받기 없이 검색되게 한다고 설명해요. 조각내기의 목적은 검색 속도가 아니라 첫 검색에서 오가는 전송량이에요.

한국어에서 색인이 까다로운 이유

역색인을 만들려면 먼저 글을 단어 단위로 잘라야 해요. 영어는 띄어쓰기가 대체로 그 경계와 일치하지만 한국어는 그렇지 않아요. 조사와 어미가 붙어 같은 낱말이 여러 형태로 나타나고, 어절 안에 의미 단위가 여러 개 들어 있기도 해요.

영어권 검색 도구는 이 문제를 어간 추출로 다뤄요. 여러 변화형을 하나의 뿌리로 모아 색인하는 방식인데, 한국어는 이 처리가 지원되지 않는 경우가 많아요. 그러면 붙은 형태 그대로 색인에 들어가므로, 사람이 같은 낱말이라고 생각하는 것들이 색인에서는 서로 다른 항목이 돼요. 한국어 검색이 기대만큼 매끄럽지 않게 느껴질 때 원인은 대개 여기에 있어요. 제대로 풀려면 형태소 분석이 필요한데, 그것을 브라우저에서 돌릴 만큼 가볍게 만드는 일이 또 다른 문제예요.

찾아오게 하는 다른 층

사이트 안에서 찾는 일과 사람이 사이트에 도착하는 일은 다른 문제예요. 아무리 좋은 색인을 갖춰도 사이트의 존재를 모르면 소용이 없어요.

가장 오래된 것은 구독이에요. RSS의 첫 판은 1999년 3월 Netscape가 내놓았고, 같은 해 7월 Dan Libby가 다듬은 판이 뒤를 이었어요. 사이트가 새 글 목록을 정해진 형식으로 내놓으면 읽는 사람이 여러 사이트를 한 자리에서 모아 볼 수 있어요. 알고리즘이 고르지 않은 목록을 직접 갖고 싶은 사람에게는 여전히 살아 있는 방식이에요.

검색 엔진에게 말을 거는 방법도 정리됐어요. 예전에는 크롤러가 링크를 따라다니며 찾아 주기를 기다려야 했는데, 사이트가 자기 글 목록을 직접 건네는 형식이 사이트맵이에요. 2006년 11월 Google과 Yahoo!, Microsoft가 이 형식을 함께 지원하기로 하면서 검색 엔진마다 따로 준비할 필요가 없어졌어요. 마지막 층은 검색 결과에 어떻게 보일지예요. 사람에게는 제목과 날짜와 글쓴이가 한눈에 보이지만 기계에게는 글자 덩어리이므로, 2011년 6월 같은 검색 엔진들이 모여 내놓은 schema.org라는 공통 어휘로 그 의미를 따로 표시해 줘요.

세 갈래는 서로 다른 상대에게 말을 걸기 때문에 하나가 빠져도 나머지는 멀쩡히 돌아요. 그래서 빠진 쪽은 대개 조용하고, 무엇이 잘못됐는지는 한참 뒤에 다른 신호로 짐작하게 돼요.

무엇이 빌드에서 빠지면	독자가 겪는 일	언제 드러나나
역색인이 옛 빌드에 머문다	사이트 안 검색에 새 글이 안 나온다	검색해 본 사람만 안다
사이트맵이 갱신되지 않는다	검색 엔진이 새 글을 늦게 안다	유입이 줄어야 짐작한다
RSS 항목이 빠진다	구독자에게 알림이 가지 않는다	아무도 알려 주지 않는다

저는 왜 지금 색인을 붙였나

글이 열 편도 되지 않을 때 검색을 붙이는 것은 과해 보였어요. 목록을 한 화면에서 다 볼 수 있는데 검색창이 왜 필요한가 싶었고, 실제로 한동안은 필요하지 않았어요.

그래도 붙여 둔 이유는 나중에 붙이기가 더 어렵기 때문이었어요. 색인은 글의 구조를 읽어 만들어지므로, 나중에 도입하면 그때까지 쌓인 글의 마크업과 메타데이터를 전부 다시 맞춰야 할 수 있어요. 글이 열 편일 때 하는 일과 이백 편일 때 하는 일의 크기가 달라요. 지금 필요한가보다 나중에 하면 얼마나 비싼가를 기준으로 정한 몇 안 되는 결정이었어요.