옵시디언을 기반으로 하는 llmwiki를 하네스로 다모앙에 공개한적이 있습니다.
소개글 : https://damoang.net/ai/5251
활용글 : https://damoang.net/ai/5616
다시 소개 (LLMwiki란)
llmwiki는 RAG처럼 질문마다 지식을 다시 찾는 대신, 소스를 넣을 때 한 번 정리해 두고 계속 갱신하는 방식입니다. 사람의 기억 구조를 본떠 작업기억 → 일화기억 → 의미기억 → 절차기억 4계층으로 정보를 승격시키고, 각 페이지에 신뢰도·최종 확인일·감쇠 등급을 붙입니다.
이번에 바뀐 것
옵시디언 볼트 안에서만 쓰던 위키를 옵시디언 볼트 밖에서도 쓸 수 있게 MCP 서버로 만들어 npm에 공개했습니다. 다른 저장소에서 코드를 고치다가, Codex CLI로 작업하다가, Cursor에서 문서를 쓰다가 위키에 물어볼 수 있습니다.
npx -y obsidian-llmwiki-mcp --selftest --root <볼트>
claude mcp add --scope user llmwiki -- npx -y obsidian-llmwiki-mcp --root <볼트>
Claude Code·Codex·Gemini CLI·agy·Cursor·Windsurf·Claude Desktop·VS Code 8종 등록 스니펫을 서버가 직접 만들어 줍니다. 읽기 전용이라 볼트에는 아무것도 쓰지 않습니다.
숫자 몇 개 (같은 조건 A/B 실측)
사실 브리핑 질의: 50.6k → 22.7k 토큰(−55%), 도구 호출 14회 → 1회
절차·how-to 질의: 개선 없음(약 39.5k → 38k). 절차는 본질적으로 여러 페이지를 봐야 해서 스코핑으로 줄지 않았습니다.
MCP 서버 2회차 호출: 1,000페이지 합성 볼트에서 164ms → 26ms(프로세스 내 캐시)
Python 원본 스크립트와 출력이 바이트 단위로 같은지 매 커밋 검사합니다(픽스처 56건 + 실볼트 20건 + 차등 퍼징 420건, 3개 OS CI)
아직 안 되거나 확인하지 못한 것.
agy 클라이언트는 규칙 스니펫을 넣어도 도구 선택이 불안정합니다
Gemini CLI와 Cursor는 설정 파일 병합만 확인했고 실사용은 검증하지 못했습니다.
macOS의 NFD 파일명과 NFC 질의가 어긋날 수 있습니다.
관련 링크
▶ 원문 출처: https://skillmaru.hell0world.net/space/global/llmwiki-harness
▶ 원문 출처: https://github.com/cookyman74/llmwiki-harness
