왜 검색부터 손봤나
내가 블로그를 작성하는 목적은 미래의 나 또는 AI가 잊어버린 기억을 빠르게 되찾는 데 쓰는 것이다.
기술 설명은 정돈하되, 내 혼잣말이나 삽질, 감정까지 없어지면 곤란하다. 무엇을 알았는지만큼 왜 그런 접근을 했고, 어디에서 생각이 달라졌는지도 남겨두고 싶다. 글을 다듬는 blog-post 스킬에도 이 기준을 먼저 반영했다.
이번에는 그 기록을 다시 꺼내는 쪽을 손봤다. 블로그 안의 검색 엔진과 WebMCP를 비교하고, 실제로 검증하고 구현하는 작업을 AI에게 요청했다. 검색에 넣을 주제로는 스레드, 멀티스레드, 컴퓨터 CS 지식을 골랐다.
구현과 실행 검증은 AI에게 맡겼고, 아래 결과는 그 실행 기록을 기준으로 정리했다.
사람은 검색창으로, AI는 필요한 구간으로
이번 구현은 글 원문을 두고 읽는 입구를 나눈 구조다.
Jekyll이 렌더링한 게시글 HTML
+-- 제목·날짜·배너·소제목별 본문 추출
+-- Pagefind 색인 → 사람이 사용하는 검색 화면
+-- 글별 JSON 자료 → AI가 읽을 글·구간 목록
WebMCP를 지원하는 브라우저
+-- 같은 검색·자료 읽기 함수를 도구로 호출
Pagefind는 정적 HTML에서 검색용 자료를 만들고 브라우저에서 검색할 수 있게 해주는 라이브러리다. 이번 블로그에서는 Jekyll 빌드 뒤에 색인을 생성하도록 연결했다. 별도의 검색 서버나 유료 AI API를 추가하지 않았다.
검색 결과는 글 제목만 보여주는 대신 검색어가 걸린 소제목과 본문 발췌를 함께 보여준다. 제목을 누르면 해당 글의 구간으로 이동한다. 한 글의 여러 구간이 검색되더라도 결과 목록에서는 같은 글을 묶는다.
컴퓨터 CS 지식처럼 범위가 넓은 표현에는 운영체제·프로세스·메모리·스레드·네트워크·자료구조를 함께 찾도록 명시적인 규칙을 넣었다. 이건 임베딩으로 문장 의미를 이해하는 검색은 아니다. 내가 평소 쓰는 기술명과 기록에 남은 표현을 이어주는 정도다.
WebMCP는 어디에 쓰나
WebMCP의 Imperative API는 웹페이지에서 JavaScript 함수와 입력 형식을 도구로 등록하는 방식이다. 이 블로그에서는 다음 세 가지를 등록한다.
| 도구 | 하는 일 |
|---|---|
search_posts |
관련 글과 찾은 구간을 검색한다. |
get_post |
글의 정보와 소제목별 구간 목록을 가져온다. |
get_section |
선택한 구간의 원문을 읽는다. |
글 전체를 매번 전달하는 대신, 목록에서 필요한 구간을 골라 읽게 했다. 긴 구간은 나누어 읽을 수 있고 날짜와 출처 링크도 함께 돌려준다. 예전 글의 판단을 현재의 사실처럼 받아들이지 않도록 원문을 확인할 단서를 남긴 셈이다.
| 방식 | 이번 목적에 맞는 점 | 남는 제약 |
|---|---|---|
| 본문 검색 | 사람이 기억나는 단어로 바로 찾고 원문으로 이동할 수 있다. | 표현이 많이 달라지거나 긴 질문이면 원하는 글을 못 찾을 수 있다. |
| 글별 JSON | WebMCP가 없어도 AI에 글·구간 목록을 전달할 수 있다. | 자료를 읽을 수 있는 AI 환경과 연결 과정은 별도로 필요하다. |
| WebMCP | 지원 환경에서는 검색과 구간 읽기를 정해진 도구로 호출할 수 있다. | 브라우저와 AI 클라이언트의 지원에 영향을 받는다. |
2026년 9월 8일 로컬 검증에서는 Chrome 152의 실험 플래그를 켜고 세 도구의 실행을 확인했다. 이 결과가 모든 AI 서비스와 연결됐다는 뜻은 아니다. 지원하지 않는 브라우저에서는 일반 검색과 JSON 자료 링크를 사용할 수 있게 했다.
기능은 괜찮아 보였는데, 디자인은 아쉬웠다
첫 결과를 보고 남긴 피드백은 이거였다.
괜찮아 보이는데 디자인이 너무 아쉬운 거 같아. 기존 블로그의 테마나 톤에 맞춰서 디자인을 수정해줄래?
글마다 배너가 조금씩 보이는 배치도 요청했다. 그래서 두 번째 수정은 기존 글 목록을 기준으로 진행했다.
- 제목은 짙게, 본문은 차분한 회색으로 두고 얇은 구분선으로 글을 나눴다.
- 날짜·분류 → 제목 → 찾은 구간 → 본문 발췌 순서로 정리했다.
- 기존 글의 배너를 작은 썸네일로 연결했다. 배너 속 글자가 잘리지 않도록 전체 이미지가 보이게 했다.
- 모바일에서는 이미지 폭을 줄이고, 다크 모드에서는 입력창과 글자 색도 함께 바뀌도록 했다.
2026년 9월 8일 로컬 검증 화면. 멀티스레드를 검색하고 연도를 2026년으로 좁힌 상태다.
이미지가 깨지면 제목까지 같이 못 읽는 일은 없어야 한다. 배너 로딩에 실패하면 이미지 자리만 접고 제목과 발췌는 남긴다. 새 이미지를 만드는 대신, 이미 글에 지정해둔 배너를 검색 자료까지 전달하도록 수정했다.
어디까지 확인했나
아래 숫자는 이 글을 추가하기 전의 검증 시점을 기준으로 한다. 글이 늘어나면 다음 빌드에서 색인도 다시 만들어진다.
| 확인 항목 | 결과 |
|---|---|
| 전체 Jekyll 빌드와 색인 생성 | 글 261편, 본문 구간 2,896개 생성 |
| 검색·AI 도구 관련 자동 테스트 | 12개 통과 |
| 실제 주제 검색 | 스레드·멀티스레드·컴퓨터 CS 지식의 결과와 이미지 연결 확인 |
| 화면 확인 | 데스크톱 1360px, 모바일 390px, 좁은 화면 320px에서 가로 넘침 없음 |
| 테마·오류 처리 | 밝은/어두운 테마, 배너 요청 실패, 결과 없는 연도·태그 조합 확인 |
이건 해당 사례에서 기능이 동작했다는 기록이다. 모든 기억을 정확하게 찾아준다는 점수는 아니다. 아직 긴 자연어 질문을 이해해 답을 만들어주는 기능은 없고, 검색 결과가 나온 뒤에도 원문의 날짜와 맥락을 읽어야 한다.
소제목별로 자료를 나눴기 때문에 서로 다른 구간에 흩어진 단서를 한 번에 찾기 어려울 수도 있다. 우선 짧은 기술명으로 찾고, 연도·분류·태그로 좁혀가는 방식으로 사용하면 된다.
다시 찾을 때 필요한 입구
- 기억 찾기: 본문과 코드에서 검색하기.
- AI 자료 사용 안내: 글·구간 목록을 AI에 전달하는 방법.
- 글·구간 목록: 빌드에서 생성한 공개 자료.
구현을 다시 손볼 때는 scripts/build-memory.mjs가 자료 생성, assets/js/memory-client.mjs가 검색과 구간 읽기, assets/js/memory-ui.mjs와 assets/css/memory-search.css가 화면을 맡는다. 운영 절차는 저장소의 docs/memory-search.md에 남겼다.
한줄 평
- 오늘 10시에 GPT 사용한도가 초기화된다는 말을 듣고, GPT-6 Astra로 지금까지 미뤄뒀던 일들을 생각해보며 실행한 결과로 꽤나 만족스럽다!