정적 검색 색인, 검색 서버 없이 글을 찾는 법

정적 사이트로 블로그를 만들고 나면 검색창을 붙이고 싶어진다.
그런데 미리 만든 파일만 내보내는 사이트에는 검색어를 받아 글을 뒤져 줄 서버가 없다.
그렇다면 검색은 어떻게 할까.

블로그 템플릿에 들어 있는 sitemap.xml과 rss.xml도 이 질문과 이어져 있다.
검색창은 사이트 안에서 글을 찾는 도구이고, 이 두 파일은 사이트 밖에서 글을 찾아오게 하는 도구다.

검색이 빠른 건 미리 만든 목록 덕분이다

검색어가 들어올 때마다 모든 글을 처음부터 읽으면 글이 늘수록 검색도 느려진다.
그래서 검색 도구는 어떤 단어가 어느 글에 나오는지를 미리 정리해 둔다.

‘캐시’⁠라는 단어 옆에 글 2와 글 7을 적어 두는 식이다.
글에서 단어를 찾는 방향을 뒤집어 단어에서 글을 찾게 만든 이 목록을 역색인이라고 한다.

검색어가 들어오면 역색인에서 그 단어의 줄만 찾으면 된다.
답의 상당 부분은 검색어가 들어오기 전에 이미 계산되어 있다.

색인도 빌드할 때 같이 만든다

정적 사이트에서는 이 역색인을 빌드할 때 글과 함께 만든다.
색인도 파일로 같이 올려 두고, 방문자의 브라우저가 그 파일을 받아 직접 검색한다.

그런데 색인은 글이 늘수록 커진다.
검색 한 번 하려고 색인 전체를 받게 하면 검색보다 내려받기가 더 오래 걸린다.

그래서 색인을 잘게 나눠 두고 검색어에 필요한 조각만 받아 오는 도구가 나왔다.
정적 검색 도구인 Pagefind⁠는 이 방식으로 1만 쪽짜리 사이트도 라이브러리를 포함해 300kB가 안 되는 전송량으로 검색할 수 있다고 밝힌다.

글과 색인을 같은 빌드에서 만들면 둘이 어긋날 일이 적다.
그래도 파일을 일부만 올렸거나 오래 열어 둔 브라우저가 예전 색인을 쥐고 있으면 새 글이 검색에 안 나올 수 있다.
그래서 글과 색인은 한 묶음으로 배포한다.

한국어 검색이 까다로운 이유

역색인을 만들려면 먼저 글을 단어로 잘라야 한다.
영어는 띄어쓰기가 대체로 단어의 경계와 맞지만, 한국어는 조사와 어미가 붙어서 같은 낱말이 여러 모양으로 나온다.

‘배포를’, ‘배포가’, ‘배포했다’⁠는 사람에게는 같은 낱말이다.
띄어쓰기로만 자르면 색인에는 이 셋이 서로 다른 단어로 들어간다.

검색 도구는 변화형을 하나의 뿌리로 모으는 어간 추출로 이 문제를 다루기도 한다.
영어의 runs와 running을 run으로 모으는 식이다.
Pagefind는 한국어의 화면 문구 번역은 지원하지만 어간 추출은 지원하지 않는다.

글 1에는 ‘배포를’, 글 2에는 ‘배포가’, 글 3에는 ‘배포했다’⁠가 나온다. 같은 검색어로 찾는 글은 색인을 만들 때 어간 추출을 했는지에 따라 달라진다.

검색어: 배포했다

색인에 든 단어

• 단어나오는 글
• 단어: 배포를나오는 글: 글 1
• 단어: 배포가나오는 글: 글 2
• 단어: 배포했다나오는 글: 글 3

찾아본 줄

배포했다

검색어 그대로

찾은 글

글 3

1편

띄어쓰기로만 자른 색인에서 ‘배포했다’⁠로 검색하면 같은 모양이 나오는 글 3만 찾는다. 어간 추출을 하면 ‘배포를’, ‘배포가’, ‘배포했다’⁠가 뿌리 ‘배포’ 한 줄로 모여 세 글을 모두 찾는다.

띄어쓰기로만 자른 색인에는 세 변화형이 서로 다른 단어로 들어 있다. 검색어와 모양이 같은 ‘배포했다’ 줄만 맞아 글 3만 나온다.

어간 추출은 색인의 단어와 검색어를 모두 뿌리 ‘배포’⁠로 바꾼다. 세 변화형이 한 줄에 모여 세 글이 모두 나온다.

세 낱말만 넣은 예시 색인이다. 어간 추출을 적용한 쪽은 그 기능이 있는 검색 도구를 가정했고, Pagefind는 한국어에 어간 추출을 하지 않는다. Pagefind가 실제로 만드는 색인과 순위는 재현하지 않았다.

어간 추출이 없으면 같은 뿌리의 변화형끼리 검색 결과가 이어지지 않는다.
제대로 풀려면 문장을 뜻을 가진 가장 작은 단위로 나누는 형태소 분석이 필요하다.
이것을 브라우저에서 돌릴 만큼 가볍게 만드는 일은 또 다른 숙제다.

사이트 밖에서 찾아오게 하는 길

사이트 안에서 글을 찾는 일과 사람이 사이트에 처음 도착하는 일은 다른 문제다.
색인이 아무리 좋아도 사이트가 있다는 것을 모르면 쓸 일이 없다.

검색 엔진은 크롤러라는 프로그램으로 링크를 따라다니며 페이지를 찾는다.
사이트맵은 사이트가 자기 페이지 목록을 크롤러에게 직접 건네는 XML 파일이다.

사이트맵 형식은 Google, Yahoo!, Microsoft가 함께 지원하는 공통 규격이라, 파일 하나로 여러 검색 엔진에 같은 목록을 건넬 수 있다.

사이트맵을 내면 바로 검색에 나올 거라고 생각하기 쉽다.
하지만 Google의 사이트맵 제출 문서는 제출이 힌트일 뿐, 그 파일을 받아 크롤링에 쓴다는 보장은 아니라고 적는다.
제출은 Search Console에서 하거나, robots.txt 파일에 사이트맵 주소를 한 줄 적어 두면 된다.

작은 블로그에도 사이트맵이 꼭 필요할까.
Google은 페이지가 500개 정도를 넘지 않고 링크로 잘 이어진 사이트라면 사이트맵이 없어도 될 수 있다고 본다.
새 사이트라 다른 곳에서 걸어 준 링크가 적다면 있는 편이 낫다.

RSS는 구독하는 사람을 위한 목록이다.
사이트가 새 글 목록을 정해진 형식으로 내놓으면, 읽는 사람은 RSS 리더로 여러 사이트의 새 글을 한곳에서 받아 본다.
RSS 리더는 이 목록을 때때로 다시 읽어, 전에 없던 항목을 새 글로 띄운다.

구조화 데이터는 검색 결과에 어떻게 보일지를 돕는 표시다.
사람은 제목과 날짜, 글쓴이를 한눈에 알아보지만 기계에게는 글자 덩어리일 뿐이다.
그래서 검색 엔진들이 함께 만든 schema.org 어휘로 그 의미를 따로 적어 준다.

검색 색인과 사이트맵, RSS는 같은 빌드에서 만들어져도 서로 다른 상대를 위한 파일이다.
하나가 빠져도 나머지는 멀쩡히 돌아가니, 빠진 쪽은 한동안 아무도 모르기 쉽다.

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

새 글을 올린 뒤에 확인할 것

색인과 사이트맵, RSS는 글과 같은 빌드에서 만들어지게 해 둔다.
그러면 셋 중 하나만 옛 상태로 남는 일이 줄어든다.

새 글을 배포한 뒤에는 사이트 검색창에 새 글의 단어를 넣어 보고, sitemap.xml과 rss.xml을 열어 새 주소가 들어갔는지 확인한다.
Search Console의 사이트맵 보고서에서는 Google이 사이트맵을 언제 읽었는지와 처리 중에 난 오류도 볼 수 있다.