Obsidian RAG — 에이전트가 내 문서를 찾아보게 하기

왜 만들었나

AI 에이전트를 여러 개 쓰다 보면 같은 말을 반복하게 된다.

프로젝트 문서, 작업 기록, 결정 과정은 Obsidian에 쌓여 있다. 그런데 에이전트는 그걸 모른다. Claude Code를 쓰다가 Codex를 쓰고, 다시 Hermes로 넘어가면 같은 배경을 또 설명해야 한다.

새로운 챗봇이 필요한 건 아니었다. 어떤 에이전트를 쓰든 같은 Obsidian 문서를 찾아볼 수 있으면 됐다.

내가 정한 선

원칙은 단순하게 잡았다.

1. Obsidian 문서를 그대로 원천 데이터로 쓴다.
2. 임베딩과 벡터 검색은 로컬에서 처리한다.
3. 에이전트는 HTTP 또는 MCP로 검색 결과만 받아간다.
4. 답변은 각 에이전트가 알아서 만든다.

이렇게 하면 특정 에이전트나 모델에 묶이지 않는다. Claude Code, Codex, Hermes, Discord 봇이 같은 검색 결과를 가져갈 수 있다.

전체 구조

Obsidian Vault
  → Markdown 문서 인덱싱
  → 로컬 임베딩 생성
  → ChromaDB 저장
  → FastAPI 검색 서버
  → MCP / HTTP / CLI 어댑터
  → 각 AI 에이전트가 검색 결과 사용

일부러 RAG 서버가 답변을 만들지 않게 했다. 서버는 질문과 비슷한 문서 조각과 출처만 돌려준다. 그 다음은 각 에이전트가 자기 작업에 맞게 사용한다.

구현한 것

• Obsidian Vault의 Markdown 파일 재귀 인덱싱
• 로컬 Ollama 임베딩 기반 벡터화
• ChromaDB 기반 문서 청크 저장
• FastAPI 검색 서버 구성
• 파일 변경 감지 watcher로 증분 재인덱싱
• MCP 서버로 search_vault, vault_status 툴 제공
• CLI 검색 스크립트 제공
• 헬스체크와 재시작 스크립트 추가

처음 돌렸을 때는 202개 문서가 3,045개 청크로 나뉘어 들어갔다.

에이전트 연결 방식

연결 방식은 일부러 여러 개 열어뒀다.

이렇게 해두면 에이전트를 바꿔도 지식 베이스를 다시 만들 필요가 없다. 새 도구가 HTTP 호출이나 MCP 중 하나만 지원해도 붙일 수 있다.

해보고 느낀 것

RAG를 붙인다고 바로 똑똑해지는 건 아니었다. 문서가 어디에 있고, 어떤 단위로 잘라야 하고, 오래된 문서와 새 문서를 어떻게 구분할지 같은 문제가 먼저 나온다.

문서를 쌓아두는 것과 에이전트가 찾아 쓸 수 있게 만드는 것은 다르다. 사람이 보기 좋은 문서가 곧 검색하기 좋은 문서는 아니었다.

그래도 효과는 분명했다. 필요한 문맥을 검색할 수 있게 해두니, 에이전트에게 매번 같은 배경 설명을 덜 하게 됐다.

다음 단계

지금은 개인 지식 베이스에 맞춘 작은 구조다. 다음에는 검색 품질을 조금 더 손보고 싶다.

• 검색 결과 품질 평가셋 만들기
• 오래된 문서와 최신 문서의 우선순위 조정
• 에이전트가 언제 RAG를 호출해야 하는지 규칙화
• 작업 완료 후 관련 문서를 자동 업데이트하는 루프 구성

목표는 거창하지 않다. 에이전트가 작업 전에 "이 프로젝트에서 예전에 무슨 결정을 했는지" 정도는 먼저 찾아보고 시작하게 만드는 것이다.