내가 본 것만 검색하는 검색 엔진 — Hister와 개인 인덱스의 귀환

개인 검색 엔진은 망가진 웹 검색에 대한 반동인가, 아니면 AI 비서의 기억을 내 손에 되돌려 놓기 위한 기반 공사인가?

도입

2026년 9월 17일(한국 시간으로는 18일 새벽) 해커뉴스 1면에 「Hister: 당신이 방문한 페이지와 당신이 보관한 파일을 위한 프라이빗 검색 엔진」이 올라와 741점을 받았다. 링크는 GitHub 저장소 asciimoo/hister를 가리킨다. 저장소는 2026년 1월에 만들어졌고, Go로 작성됐으며, 라이선스는 AGPLv3다. 이 글을 쓰기 위해 조회한 시점(10월 18일)의 GitHub 스타 수는 6,074개였다.

작성자는 스레드에 직접 나타나 「무엇이든 물어보라」고 했다. 그가 밝힌 이력이 흥미롭다. 그의 첫 자유 소프트웨어 검색 프로젝트는 프라이버시를 존중하는 메타검색 엔진 Searx였고, 메타검색이라는 개념의 한계 때문에 다른 접근을 택했다는 것이다. 메타검색은 결국 다른 검색 엔진의 결과를 모아 보여 주는 방식이다. 그 결과 자체가 흐려지면 아무리 프라이버시를 지켜도 얻는 것이 줄어든다. Hister는 방향을 정반대로 돈다. 웹 전체를 검색하지 않고, 내가 이미 본 것만 검색한다.

같은 프로젝트는 한 달 전인 8월 18일에도 「Hister – 당신이 통제하는 프라이빗 전문(全文) 검색 인덱스」라는 제목으로 497점을 받은 적이 있다. 한 달 만에 다시 1면에 올랐고 점수는 더 높았다. 스레드에는 「몇 주째 쓰고 있다」, 「한두 달째 업무용 머신에서 돌리고 있다」는 사용 후기가 여럿 섞여 있다. 이 글은 Hister라는 도구 자체보다, 이 도구가 건드린 질문을 따라가 본다. 왜 지금 다시 개인 인덱스인가, 그리고 그 대가는 무엇인가.

현상 분석 — Hister가 실제로 하는 일

README와 공식 문서에서 확인되는 구조부터 정리한다. Hister는 클라이언트-서버 구조다. 서버가 문서를 저장하고 검색하며, 클라이언트가 콘텐츠를 모으거나 검색을 실행한다. 모든 것을 한 대의 컴퓨터에서 돌릴 수도 있고, 여러 클라이언트를 하나의 서버에 붙일 수도 있다. 빠른 시작 절차는 바이너리를 내려받아 hister listen을 실행하고, 127.0.0.1:4433을 연 뒤, Firefox 또는 Chrome 확장을 설치하는 것이 전부다.

콘텐츠가 들어오는 경로는 다섯 갈래다. 브라우저 확장, 브라우저 방문 기록 가져오기, 북마크 가져오기, 감시 대상 로컬 디렉터리, 그리고 웹사이트 크롤러다. 문서가 이 경로들의 차이를 꽤 정직하게 설명한다는 점이 눈에 띈다.

  • 브라우저 확장은 페이지가 로드된 뒤 현재 탭을 읽어 URL, 제목, 추출된 텍스트, 렌더링된 HTML, 파비콘을 설정된 서버로 보낸다. 페이지를 새로 요청하지 않고 이미 렌더링된 화면을 그대로 담는다. 그래서 JavaScript로 그려지는 페이지나 로그인해야 보이는 페이지도 색인된다.
  • 방문 기록 가져오기는 다르다. 브라우저의 기록 DB에는 URL, 제목, 방문 횟수, 타임스탬프만 있고 페이지 내용은 없다. 그래서 Hister는 URL 목록을 읽은 뒤 크롤러로 지금 그 페이지를 다시 가져온다. 문서는 이렇게 색인된 내용이 원래 보았던 것과 다를 수 있다고 명시한다. 페이지가 바뀌었거나 사라졌거나 로그인이 필요해졌을 수 있다는 것이다.

작성자는 스레드에서 확장 방식의 장점을 이렇게 설명했다(직접 인용은 아니고, 코멘트의 요지를 요약). 확장은 웹사이트 입장에서 완전히 보이지 않으므로 캡차, 봇 차단, 인증 문제처럼 일반 크롤러가 늘 부딪히는 병목을 브라우저와 사용자가 이미 해결해 준 상태에서 내용을 얻는다는 것이다. 다른 사용자는 이를 두고 인스타그램처럼 닫힌 사이트를 색인할 수 있는 최초의 「검색 엔진」일지도 모른다고 반응했다.

검색 쪽 기능은 필드 필터, 구문 검색, 와일드카드, 부정, 별칭, 결과 우선순위를 지원하는 쿼리 언어와, 선택적으로 켤 수 있는 의미 검색으로 나뉜다. 의미 검색은 기본값이 꺼짐이다. 켜면 문서 텍스트를 겹치는 청크로 나눠 외부 임베딩 모델로 벡터화하고, 검색 시 질의도 임베딩해 가장 가까운 청크를 키워드 결과와 합쳐 재정렬한다. 임베딩 엔드포인트는 OpenAI 호환이면 되며, 문서의 기본값은 로컬 Ollama 주소와 qwen3-embedding:8b 모델이다.

그리고 세 번째 인터페이스가 있다. 웹 UI, 터미널(TUI와 CLI)에 더해 MCP 엔드포인트가 있다. AI 비서가 Hister 인덱스를 직접 검색하고 저장된 미리보기를 가져올 수 있게 하는 통로다. 작성자 소개글에서도, README 첫 문단에서도 이 점이 앞에 놓여 있다. 「웹 인터페이스, 터미널, 또는 MCP로 연결된 AI 비서에서 다시 찾을 수 있다」.

스레드의 실사용 후기는 이 구조가 어디서 효용을 내는지 보여 준다. jjice는 업무 머신에서 한두 달 돌려 왔는데, 평소에는 들여다보지 않다가 필요할 때 지난 한 달 치 브라우저 기록을 뒤지는 일을 해결해 준다고 썼다. 다만 초기에 제외 규칙을 꽤 많이 쌓아야 했다고 덧붙였다(직접 인용은 아니고, 코멘트의 요지를 요약). Yehoshaphat은 Hister를 기본 검색 엔진으로 쓰고, 바깥이 필요할 때만 !! 접두어로 Kagi에 넘긴다고 했다. RobGR은 모든 페이지를 색인하지 않고 확장으로 특정 페이지만 골라 넣는데, 진짜 가치는 자신이 잊어버릴 만큼 오래된 것이 쌓였을 때 나올 것 같다고 했다.

심층 분석 — 왜 지금, 그리고 무엇을 대가로

한때 브라우저가 하던 일

답글이 많이 달린 갈래 중 하나는 jval43의 코멘트였다. 구글 크롬이 2008년에 이미 방문한 모든 페이지의 전문 검색을 오프라인으로 제공했고, 아무도 기억하지 못하지만 대표 기능이었으며, 2013년쯤 사라졌다는 내용이다(직접 인용은 아니고, 코멘트의 요지를 요약). 답글에서 xd1936이 근거 링크를 찾아 붙였다. 디지털 포렌식 블로그 dfir.blog의 2013년 10월 2일 글은 크롬 v30에서 「History Index YYYY-MM」이라는 SQLite 파일들이 제거됐다고 기록한다. 이 파일들에는 사용자가 방문한 대부분의 웹사이트 텍스트가 들어 있었고, 크롬은 이를 옴니박스 제안에 썼다. 인용된 커밋 메시지는 「전문 색인 기능은 더 이상 아무것도 사용하지 않는다」며 TextDatabase를 지운다고 적고 있다.

다른 답글들은 비슷한 기억을 보탰다. Google Desktop, Mac판 IE5, 크로미움 이전 시대의 Opera. TeMPOraL은 지금은 어떤 브라우저도 열린 탭, 북마크, 기록에서 제대로 찾아 주지 않는다고 불평했다. 사라진 이유를 두고는 기술적 제약이라는 추측과 광고가 붙지 않는 오프라인 페이지가 회사 이익과 맞지 않았다는 냉소가 엇갈렸는데, 어느 쪽도 스레드 안에서 확인되지는 않았다.

여기서 읽히는 것은 「새로운 발명」에 대한 열광이 아니라 「잃어버린 기능」의 복원 욕구다. 개인 전문 색인은 기술적으로 오래전에 가능했고 실제로 대형 브라우저에 들어가 있었다. 그것이 빠진 자리를 13년 뒤 개인 프로젝트가 채우고 있다.

AI 비서가 대신 기억해 주면 되지 않나

스레드에서 가장 직접적인 반론은 361994752의 코멘트다. 몇 달 전에 읽은 것을 못 찾을 때 ChatGPT에 「몇 달 전에 x, y에 관해 읽었는데 못 찾겠다」고 물으면 놀라울 만큼 정확한 답이 돌아온다는 것이다(직접 인용은 아니고, 코멘트의 요지를 요약). 이 코멘트에 붙은 답글 두 개가 이 글의 질문을 정확히 가른다. cobertos는 그게 가능하려면 이미 브라우징 기록이 ChatGPT에 있어야 하는 것 아니냐고 물으며, Hister에 MCP 서버가 있으니 그런 워크플로도 가능하고 AI가 실패할 때 사람이 직접 볼 수 있는 형태로 데이터를 들고 있는 것이 핵심이라고 했다. rglullis는 더 짧게, 그건 문제를 푼 게 아니라 OpenAI에 대한 의존을 늘리며 고통의 지점을 바꾼 것뿐이라고 했다.

이 대립은 「사람 대 AI」가 아니다. 쟁점은 기억의 원본을 누가 갖고 있느냐다. 범용 챗봇이 「어디서 읽었더라」에 답할 수 있는 것은 그 글이 공개 웹에 있고 학습 데이터나 검색 대상에 들어 있기 때문이다. 내가 로그인해서 본 사내 위키, 유료 기사, 닫힌 소셜 피드는 그 범위 밖이다. Hister의 확장이 렌더링된 페이지를 그대로 담는다는 설계는 바로 그 공백을 겨냥한다. 그리고 MCP 엔드포인트는 그렇게 쌓인 원본을 원하는 AI 비서에 「빌려주는」 형태다. 원본은 내 서버에, 추론은 원하는 모델에. 이것이 Hister가 AI와 경쟁하는 대신 택한 배치로 읽힌다. 이 해석은 필자의 분석이며, 작성자가 이런 말로 설명한 것은 아니다.

다만 이 배치에도 새로운 위험이 붙는다. Hister의 MCP 문서는 이 점을 숨기지 않는다. 색인된 제목, URL, 본문, 기록 필드는 모두 신뢰할 수 없는 원천 데이터이며, 페이지 안에 AI를 겨냥한 지시문이 들어 있을 수 있다고 적는다. 도구 응답은 원천 값을 untrusted_content 아래에 두고 각 레코드에 trust: "untrusted"를 붙이며, 보이지 않는 제어 문자를 제거한다. 그러면서도 「이런 통제는 위험을 줄이지만 모든 모델이 프롬프트 인젝션에 저항한다고 보장할 수는 없다」고 하고, 읽기 전용 조회 밖의 행동에는 사용자 확인을 요구하라고 권한다. 내가 본 모든 페이지를 AI에 연결한다는 것은, 내가 본 모든 페이지의 작성자가 그 AI에 말을 걸 수 있게 된다는 뜻이기도 하다.

로컬 퍼스트의 세 가지 비용

로컬에서 직접 돌린다는 선택에는 비용이 따른다. 스레드와 문서에서 확인되는 것을 저장 공간, 프라이버시, 신선도의 세 축으로 나눠 본다.

저장 공간. 데이터 수명주기 문서는 페이지 하나를 저장하는 데 평균 약 100KB가 든다고 적는다. 단순 계산으로 1만 페이지면 약 1GB, 10만 페이지면 약 10GB다(필자의 산술이며, 문서는 페이지 내용에 따라 편차가 크다고 경고한다). 더 중요한 것은 상한이 없다는 점이다. 문서는 자동 만료 기간도, 최대 문서 수도, 전체 디스크 할당량도 없다고 밝히고, 저장소 감시와 백업과 삭제 일정은 서버 운영자의 책임이라고 못 박는다. 줄이는 방법도 적혀 있다. HTML 미리보기를 끄고, 잡음이 많은 URL을 건너뛰는 규칙을 걸고, 버전 기록은 필요한 페이지에만 적용하라는 것이다. 개인 인덱스는 설치하는 순간 작은 데이터 운영 업무가 된다.

프라이버시. 「프라이빗」이라는 말은 「외부로 나가지 않는다」는 뜻이지 「안전하다」는 뜻이 아니다. 문서는 색인된 데이터가 Hister에 의해 암호화되지 않는다고 명시하고, 필요하면 디스크 암호화를, 신뢰할 수 없는 네트워크를 건널 때는 HTTPS를 쓰라고 한다. 확장 문서는 렌더링된 페이지에 개인적이거나 민감한 정보가 들어 있을 수 있으며 비공개 계정 페이지도 전송될 수 있다고 경고한다. 기본 설정에서는 인증도 요구하지 않는다. 즉 Hister를 켜는 순간, 내 은행 화면과 의료 포털과 사내 시스템이 한 디렉터리에 평문 전문 색인으로 모일 수 있다. 의미 검색을 원격 임베딩 API로 켜면 그 텍스트는 다시 외부로 나간다. 스레드에서 computator가 배포판 패키지가 아닌 프로그램과 브라우저 확장을 들이는 것 자체를 망설인다고 쓴 것, 그리고 답글들이 네트워크 접근을 막은 컨테이너, AppArmor, systemd 하드닝 같은 격리책을 제안한 것은 이 맥락에서 읽어야 한다.

신선도. 개인 인덱스는 내가 본 순간의 스냅샷이다. 작성자는 원본 페이지가 바뀌거나 사라져도 검색 가능하도록 추출된 내용과 오프라인 미리보기를 저장한다고 설명했다. 이것은 장점이자 한계다. 같은 URL을 다시 방문하면 현재 내용이 이전 값을 덮어쓰고, 변경 이력을 남기려면 별도의 버전 규칙을 걸어야 한다. 반대로 방문 기록 가져오기는 과거 URL을 지금 다시 긁어 오므로, 그때 본 것이 아니라 지금 남아 있는 것을 색인한다. 결국 개인 인덱스가 정확히 답하는 질문은 「이 주제의 최신 정보는?」이 아니라 「내가 그때 본 그것은 어디 있었나?」다.

전망과 시사점

스레드에서 눈에 띄는 패턴은 「나도 비슷한 걸 만들었다」는 코멘트의 수다. bradrn, sbeckeriv(세 번째 버전이라고 했다), tombert, taude가 각자의 도구를 소개했고, Zotero, ArchiveBox, Karakeep, Betula, recoll, histre 같은 기존 도구 이름도 줄줄이 나왔다. taude는 브라우저 기록 SQLite를 cron으로 훑어 특정 규칙에 맞는 페이지를 마크다운으로 바꿔 Obsidian 보관함에 넣고 LLM으로 분류까지 시키는 파이프라인을 설명하면서, 이것이 정말 유용한지 지식 수집의 야크 털 깎기인지 확신이 없다고 했다(직접 인용은 아니고, 코멘트의 요지를 요약). 수요는 분명하지만 표준적인 답이 없어서 각자 다시 만드는 상태다.

반대편 목소리도 있다. ozim은 큐레이션한 노트에서 투자 대비 수익을 얻은 적이 없고, 잊어도 삶이나 일에 영향이 없는 것은 그냥 잊는다고 했다. elestor는 써 보다가 CPU와 배터리 소모 때문에 그만뒀다며 다른 머신에 셀프 호스팅하는 것이 전제냐고 물었다. 이런 반응은 개인 인덱스가 모두에게 필요한 인프라는 아니라는 점을 상기시킨다. 회수 빈도가 낮은 사람에게는 저장과 운영 비용만 남는다.

이름 문제도 걸려 있다. 작성자는 Hister라는 이름이 미국의 등록 상표와 충돌하며 상대 측이 이름 변경을 요청해 왔다고 밝혔고, 다른 사용자는 histre.com 측이 서한을 보냈다는 이야기를 Discord에서 봤다고 썼다. 작성자는 법적으로 너무 비슷하다고 판단된다며 후보를 모아 투표에 부치겠다고 했다. 이 글이 다루는 시점 이후 이름이 바뀌었는지는 확인하지 않았다.

시사점을 정리하면 이렇다. 첫째, 개인 인덱스의 경쟁 상대는 구글이 아니라 「AI 비서의 기억 기능」이다. 둘 다 「그때 본 그것」을 찾아 주겠다고 약속하지만, 원본을 누가 쥐느냐가 다르다. 둘째, MCP 같은 표준 통로가 생기면서 개인 인덱스는 독립 제품이 아니라 AI 비서의 외부 기억 장치로 위치를 잡을 수 있게 됐다. Hister가 MCP를 README 첫 문단에 올린 것은 그 방향을 보여 준다. 셋째, 그 대가로 프라이버시는 「클라우드에 안 보낸다」에서 「내가 운영한다」로 의미가 바뀐다. 암호화, 인증, 보존 기한, 프롬프트 인젝션 방어를 사용자가 직접 결정해야 한다.

결론

Hister가 741점을 받은 것은 검색 엔진으로서의 기술적 신기함 때문이라기보다, 많은 사람이 공유하는 작은 좌절을 정확히 짚었기 때문으로 보인다. 분명히 읽었는데 다시 찾을 수 없는 페이지. 브라우저는 한때 그것을 해결했다가 그만두었고, 웹 검색은 그 페이지를 다시 띄워 주지 않으며, AI 비서는 내가 로그인해서 본 것을 모른다.

Searx에서 Hister로 옮겨 온 작성자의 궤적은 그 자체로 하나의 진단이다. 남의 인덱스를 아무리 프라이버시 친화적으로 감싸도, 그 인덱스가 나에게 맞지 않으면 소용이 없다. 그래서 인덱스를 내 쪽으로 가져온다. 그 순간 저장 공간과 보안과 신선도의 책임도 함께 넘어온다.

당신이 마지막으로 「분명히 어디서 봤는데」라고 중얼거린 것은 언제였는가. 그 페이지를 다시 찾아 준다면, 당신은 그것을 누구에게 맡기겠는가. 검색 회사인가, AI 비서인가, 아니면 디스크 암호화와 백업을 스스로 챙겨야 하는 자기 자신인가.

출처: