PLOZEN RAG Knowledge System
문제와 목표
Obsidian 세션 기록, 프로젝트 문서, 완료 Todo가 쌓이면서 문서 그래프가 방대해졌고, 에이전트가 필요한 맥락을 문서 단위로 매번 프롬프트에 붙이는 방식은 토큰 낭비가 컸다.
목표는 내부 문서와 운영 기록을 PostgreSQL pgvector 기반 RAG 저장소로 색인하고, 에이전트가 필요한 지식만 검색해 가져올 수 있는 FastAPI/MCP 검색 기반을 만드는 것이었다.
내가 맡은 범위와 구현
Obsidian 원문은 source of truth로 유지하고, 13서버 Ubuntu Docker 환경에 pgvector 컨테이너를 구성해 문서 검색 index를 분리했다.
문서 source, chunk, embedding vector, content hash, metadata, 검색 audit log를 분리한 schema와 similarity search smoke test로 검색 가능 상태를 검증했다.
기술 구조
Docker, PostgreSQL, pgvector, FastAPI, MCP, Markdown/Obsidian.
세션 기록, 프로젝트 문서, Todo, 운영 로그가 누적되면서 Vault 그래프가 방대해졌습니다. 에이전트가 전체 문서를 매번 프롬프트에 붙이는 방식은 토큰 비용과 검색 정확도 측면에서 한계가 있었고, 이 원문 저장소를 검색 가능한 RAG index로 분리할 필요가 있었습니다.
문서가 단순 업로드 상태인지, chunking/embedding을 거쳐 VectorDB에 저장된 상태인지 확인하는 관리 콘솔입니다. 문서 목록, 글자량, 조각 수, 적재/벡터 상태를 한 화면에서 확인하고, 업로드와 벡터 생성을 분리해 검색 index 전환 상태를 운영자가 확인할 수 있게 구성했습니다.
문서 source, chunk, embedding vector, content hash, metadata, search audit log를 분리한 schema로 저장하고, similarity search smoke test로 RAG 저장소가 실제 검색 가능한 상태인지 검증했습니다.
Obsidian Vault는 세션 기록, 프로젝트 문서, Todo archive, 운영 로그의 source of truth로 유지하고, RAG DB는 검색을 위한 파생 index로 분리했습니다. 에이전트는 전체 문서를 프롬프트에 붙이는 대신 필요한 chunk만 검색해 컨텍스트로 사용할 수 있게 했습니다.
문서 조회, 업로드, 벡터 생성, chunk 조회, 검색, audit log endpoint를 FastAPI로 분리했습니다. Console과 Agent가 같은 API 계층을 사용할 수 있고, MCP tool은 이 API를 감싸는 방식으로 확장할 수 있게 설계했습니다.
FastAPI Knowledge API 위에 search_knowledge, list_sources, get_source 도구를 제공하는 stdio MCP Server를 붙였습니다. Codex는 로컬 설정에서 SSH runner를 호출하고, 서버 측 runner가 Knowledge API를 감싸는 방식으로 에이전트 세션에서 내부 지식 검색 도구를 사용할 수 있게 했습니다.
현재 단계는 포트를 외부로 열지 않는 stdio MCP 연결 완료 상태입니다. JSON-RPC tools/list와 tools/call smoke test로 도구 노출과 list_sources 호출 흐름을 확인했고, HTTP/streamable-http MCP는 인증, 방화벽, rate limit, 로그 기준을 먼저 설계한 뒤 별도 단계로 분리합니다.