LLM Wiki를 구축했다고 생각했는데, 검색이 300초 만에 타임아웃 됐다

vault에 1,270개 노트를 쌓고, qmd 인덱스에 841개 문서를 등록하고, GBrain 자동 백필 크론까지 돌리고 있었다. 그런데 막상 검색을 시도하자 300초 타임아웃이 났다. 원인은 단 하나, 벡터 임베딩이 동작하지 않고 있었다. LLM Wiki의 핵심은 "문서를 저장하는 것"이 아니라 "문서를 검색 가능하게 만드는 것"이다. (본문 수치: 2026-08-06 자체 인프라 점검 결과)

카파시가 제안한 LLM Wiki는 복잡한 아키텍처 없이 마크다운 파일과 규칙서(schema)만으로 지식 베이스를 만드는 방식이다. 벡터 DB 없이도 동작한다는 점이 RAG와 다르다. 하지만 "벡터 DB 없이"는 "임베딩이 불필요하다"는 뜻이 아니다. 실제 구축 과정에서 이 차이를 정확히 이해하지 못하면, 저장소는 거대해지는데 검색은 되지 않는 상황이 벌어진다.

LLM Wiki와 RAG는 무엇이 다른가

RAG(검색 증강 생성)는 벡터 DB 구축, 임베딩 파이프라인, 검색 로직이 필요하다. 문서를 벡터로 변환하고, 유사도 검색으로 관련 청크를 찾아 LLM에 주입한다. LLM Wiki는 이 과정을 의도적으로 생략한다. 대신 마크다운 파일과 스키마 규칙으로 검색 품질을 확보한다. 이 개념은 안드레 카파시가 그의 공개 저장소와 글에서 제안한 것으로, "검색이 안 되는 것은 데이터가 부족해서가 아니라 AI가 따라야 할 규칙이 없기 때문"이라는 철학에 기반한다.

도메인 분류 체계를 먼저 설계하고, 답변 형식 규칙을 문서로 정의하면, LLM이 파일을 직접 읽고 원하는 정보를 조합할 수 있다. 우리가 샘 호트만의 "RAG 대신 LLM Wiki + Hermes" 영상(2026)에서 이 개념을 처음 적용해본 것도 같은 맥락이었다.

실제 구축 현황: 뼈대는 다 있었지만

2026년 8월 6일, 인프라 점검을 위해 각 구성 요소를 확인했다. Obsidian vault에 1,270개 마크다운 노트가 있었고, qmd라는 검색 도구가 vault를 인덱싱하고 있었으며, GBrain이라는 지식 그래프가 매일 새벽 3시에 자동으로 문서를 동기화하고 있었다. Ollama에는 nomic-embed-text(261MB)와 bge-m3(1.1GB) 임베딩 모델도 설치돼 있었다.

구성 요소만 보면 LLM Wiki를 위한 준비가 끝난 것처럼 보였다. 문서 저장소, 검색 도구, 자동화, 임베딩 모델 — 네 가지가 모두 존재했다. Nous Research의 Hermes 에이전트가 매일 크론으로 이 파이프라인을 돌리고 있었고, Google의 NotebookLM도 유튜브 영상 요약에 함께 쓰고 있었다. "이 정도면 검색이 잘 되겠지"라고 생각했다.

그런데 검색이 300초 만에 타임아웃 됐다

qmd 인덱스 상태를 확인하자 문제가 드러났다. 총 841개 문서 중 임베딩이 완료된 문서는 0개, 즉 완료율 0%였다. 상태 표시는 "Needs embedding: 841" — 전부 임베딩 필요 상태였다. 실제 검색을 시도하자 300초가 지나도록 응답이 오지 않아 타임아웃됐다. 콘솔에는 아무 에러도 없었고, 그저 무한 대기만 이어졌다.

문서는 저장되어 있었지만, 의미 기반 검색의 전제인 벡터가 전혀 생성되지 않은 상태였다. 키워드 검색만 가능한 상황에서 벡터 검색을 요청하니 시스템이 임베딩을 시도하다가 멈춘 것이다. 카파시가 "채점기를 작성할 수 없다면 아직 루프가 없는 것이고, 그냥 대화를 하고 있는 것이다"라고 말한 것처럼, 임베딩이 없으면 검색 시스템도 아직 검색이 아니라 문서 더미일 뿐이었다. 실제로 지식 관리 실무를 맡은 팀장이라면 이런 상황에서 "문서는 다 있는데 왜 검색이 안 되지?"라는 질문부터 하게 된다.

원인은 임베딩 모델 설정이었다

qmd 설정 파일(index.yml)을 열어보니 임베딩 모델이 HuggingFace의 GGUF 파일(embeddinggemma-300M)을 직접 로드하도록 되어 있었다. 이 설정은 GPU가 있는 환경에서는 문제없이 동작하지만, CPU 전용 머신에서는 극도로 느리다. 841개 문서의 임베딩을 시도하다가 사실상 멈춰버린 것이다.

그런데 이미 Ollama에 nomic-embed-text와 bge-m3가 설치되어 있었다. 로컬에서 바로 사용할 수 있는 임베딩 모델이 있었던 것이다. 문제는 설정이 그 모델들을 바라보지 않고 있었다는 점이다.

LLM Wiki 구축에서 배운 교훈

첫째, 저장소와 검색은 별개의 문제다. 문서를 쌓는 것과 문서를 검색 가능하게 만드는 것은 완전히 다른 작업이다. 둘째, 임베딩 파이프라인은 배포 전에 반드시 검증해야 한다. 문서 수천 개를 쌓은 뒤에 임베딩이 안 된다는 사실을 알면 복구 비용이 커진다. 셋째, 이미 설치된 도구부터 활용하라. Ollama에 모델이 있는데 HuggingFace에서 직접 로드하려 한 것이 실패의 원인이었다.

LLM Wiki는 복잡한 아키텍처가 필요 없다는 점에서 진입 장벽이 낮다. 하지만 그 단순함 때문에 임베딩 설정 같은 기초 작업을 소홀히 하기 쉽다. 기초가 무너지면 아무리 많은 문서를 쌓아도 검색은 되지 않는다.

핵심 요약 (Key Takeaways)

• LLM Wiki는 벡터 DB 없이 마크다운과 규칙으로 동작하지만, 임베딩이 불필요한 것은 아니다.
• 문서 저장과 검색 가능은 별개의 문제다. 1,270개 노트를 쌓아도 임베딩이 없으면 검색이 안 된다.
• CPU 환경에서는 HuggingFace GGUF 직접 로드보다 Ollama 로컬 모델이 안정적이다.
• 검색 파이프라인은 문서 수천 개를 쌓기 전에 미리 검증해야 한다.
• 기존에 설치된 도구(Ollama)부터 활용하는 것이 실패 확률을 줄인다.

자주 묻는 질문 (FAQ)

LLM Wiki란 무엇인가?

안드레 카파시가 제안한 개념으로, 벡터 DB와 임베딩 파이프라인 없이 마크다운 파일과 규칙서(schema)만으로 구성하는 지식 관리 체계다. 데이터의 양보다 규칙을 중요하게 여긴다.

LLM Wiki와 RAG의 차이는 무엇인가?

RAG는 벡터 DB, 임베딩 파이프라인, 검색 로직이 필요하다. LLM Wiki는 벡터 DB 없이 마크다운 파일과 스키마 규칙으로 동작한다. 검색이 안 되는 건 데이터 부족이 아니라 규칙이 없기 때문이라는 철학이다.

벡터 임베딩이 안 되면 어떤 문제가 생기나?

문서는 저장돼 있지만 의미 기반 검색이 불가능해진다. 실제 사례에서 841개 문서가 전부 임베딩 필요 상태였고, 검색 요청이 300초 만에 타임아웃됐다.

로컬 임베딩 모델은 어떻게 선택하나?

Ollama에 이미 설치된 nomic-embed-text나 bge-m3 같은 모델을 쓰는 것이 안전하다. HuggingFace GGUF를 직접 로드하는 설정은 CPU 환경에서 극도로 느려질 수 있다.

관련 가이드

• alignsdot — AI 에이전트와 자동화의 실전
• Andrej Karpathy — LLM Wiki 개념
• Ollama nomic-embed-text

결론

LLM Wiki의 핵심은 문서를 쌓는 것이 아니라 검색 가능하게 만드는 것이다. 저장소가 아무리 커도 임베딩이 동작하지 않으면 지식 베이스는 죽은 저장소일 뿐이다. 임베딩 모델 선택과 파이프라인 검증을 먼저 하고, 그 위에 문서를 쌓는 순서가 맞다.