여러 AI 에이전트가 같은 문서를 검색하는 환경

프로젝트 문서와 작업 기록, 이전 결정 사항은 Obsidian에 쌓여 있었지만 AI 에이전트는 그 내용을 알지 못했습니다. Claude Code, Codex, Hermes처럼 사용하는 도구를 바꿀 때마다 같은 프로젝트 배경을 다시 설명해야 했고, 과거에 내린 결정을 찾기 위해 문서를 직접 검색하는 일도 반복됐습니다.

특정 에이전트에 종속되지 않으면서 여러 도구가 같은 문서를 검색할 수 있는 구조가 필요했습니다.

문서 수집 범위와 청크 분할 방식, 출처 반환 규칙과 에이전트 연결 구조를 정했습니다. AI 코딩 에이전트를 활용해 Ollama 임베딩, ChromaDB 저장, 증분 인덱싱과 FastAPI 검색 서버를 구현하고 실제 문서 인덱싱과 검색 결과로 검증했습니다.

MCP·HTTP·CLI 인터페이스를 연결하고, 검색 서버가 답변을 생성하지 않고 문서 조각과 출처만 반환하도록 책임 범위를 정했습니다.

Obsidian의 Markdown 문서를 로컬 임베딩으로 변환해 저장하면, 에이전트가 프로젝트 맥락을 검색할 수 있다.

검색 기능을 MCP, HTTP, CLI 세 가지 방식으로 제공하면, 어떤 에이전트든 같은 검색 결과를 사용할 수 있다.

Obsidian Markdown 문서를 재귀적으로 읽어 Ollama 임베딩으로 변환하고 ChromaDB에 저장하는 인덱서를 만들었습니다.

FastAPI 검색 서버를 구성하고, 문서가 변경되면 해당 파일만 다시 처리하도록 증분 인덱싱을 적용했습니다.

검색 기능은 MCP, HTTP, CLI 세 가지 방식으로 제공해 Claude Code, Codex, Hermes가 같은 검색 결과를 사용할 수 있도록 했습니다.

로컬 Ollama 임베딩으로 문서를 청크 단위로 변환하고 ChromaDB에 저장했습니다. 파일 변경 감지 시 해당 파일만 재처리하는 증분 인덱싱을 구현했습니다.

RAG 서버는 답변을 대신 만들지 않고 관련 문서 조각과 출처만 반환합니다. 최종 답변과 작업 판단은 각 에이전트가 담당하도록 분리했습니다.

RAG를 붙이는 것보다 문서를 어떻게 나누고 최신 기록을 우선할지 정하는 일이 검색 품질에 더 큰 영향을 줬습니다.

사용 과정에서 발생한 교정 사항을 작업 로그, 프로젝트별 메모리, 공통 규칙으로 나눠 기록했습니다. 반복해서 확인된 내용만 사람이 검토한 뒤 공통 메모리에 반영하도록 해, 자동으로 잘못된 규칙이 쌓이지 않게 했습니다.

초기 기준 202개 문서를 3,045개 청크로 인덱싱하고, 여러 에이전트가 같은 프로젝트 기록과 결정 사항을 검색할 수 있게 됐습니다.

Hermes에서는 Discord 작업 요청을 받은 뒤 필요할 때 RAG와 MCP 도구를 사용하고 결과와 작업 로그를 남기도록 연결했습니다.

202개 문서와 3,045개 청크는 개인 Obsidian 환경의 초기 운영 규모이며, 조직 전체 문서나 다중 사용자 권한 모델을 검증한 결과가 아닙니다.

여러 에이전트가 같은 검색 결과를 사용할 수 있는 흐름은 확인했지만, 기준 질문 세트와 Top-k 적중률 같은 정량 평가 체계는 아직 구축하지 않았습니다.

문서 분할 전략과 최신 기록 우선 정책을 지속 개선하고 있습니다. 임베딩 모델 교체 실험도 검토 중입니다.

검색 품질 평가 기준을 정의해, 어떤 쿼리에서 결과가 부족한지 정량적으로 파악하는 구조를 계획 중입니다.