Slogs LLM Wiki 검색은 어떻게 기억을 찾아내는가

![Slogs LLM Wiki GraphRAG search flow](/uploads/20260627-llmwiki-graphrag-v2.png) LLM Wiki에서 검색은 단순히 “키워드가 들어간 문서를 찾는 일”이 아니다. Agent가 다음 행동에 쓸 수 있는 기억을 찾아야 한다. 그래서 Slogs LLM Wiki의 검색은 세 가지 신호를 함께 본다. - 사용자의 질문이 어떤 의미를 갖는지 - 저장된 기억의 의미 벡터가 얼마나 가까운지 - 기억 사이의 카테고리, 태그, 관련 항목 연결이 어떤 그래프를 이루는지 이 글에서는 Slogs LLM Wiki의 검색 흐름을 GraphRAG 관점으로 정리한다. ## 1. 질문을 임베딩으로 바꾼다 검색의 첫 단계는 질문을 임베딩 벡터로 바꾸는 것이다. Slogs에서는 서버 로컬의 EmbeddingGemma 모델을 사용하도록 정책을 잡았다. 외부 hosted API에 매번 보내는 구조가 아니라, 서버 내부에서 재현 가능한 임베딩을 만들기 위해서다. 이 선택에는 장점이 있다. - API 키가 검색 경로에 끼지 않는다. - 로컬 운영 환경에서 검색 품질을 반복 측정하기 쉽다. - 장애 원인이 네트워크/API/과금 이슈로 퍼지지 않는다. 물론 로컬 모델을 쓰면 배포 크기와 초기 로딩 시간이 늘어난다. 그래서 Slogs는 모델 호출을 핵심 경로로 인정하고, 실패 시 조용히 다른 검색으로 우회하는 방식을 피한다. 검색 품질을 보장하려면 실패가 드러나야 한다. ## 2. pgvector로 가까운 기억 후보를 고른다 임베딩이 만들어지면 PostgreSQL의 pgvector를 통해 가까운 기억 후보를 찾는다. pgvector는 PostgreSQL 안에서 vector 타입과 유사도 검색을 사용할 수 있게 해주는 확장이다. 이 단계는 seed retrieval에 가깝다. 처음부터 “정답”을 하나 고르는 것이 아니라, 의미적으로 가까운 후보 묶음을 만든다. 후보를 너무 많이 가져오면 Agent에 전달되는 문맥이 커지고, 너무 적게 가져오면 중요한 기억이 빠진다. 그래서 Slogs MCP 도구는 기본 limit을 작게 잡고, 필요할 때만 좁은 query/categoryPath/minRelevancePercent로 다시 조회하게 한다. ## 3. 그래프 신호로 후보를 다시 본다 GraphRAG의 핵심 아이디어는 문서 조각을 벡터로만 보지 않고, 지식 간의 관계를 함께 활용하는 데 있다. Slogs LLM Wiki도 이 방향을 따른다. 예를 들어 어떤 기억이 `slogs/llm-wiki/graphrag` 카테고리에 있고, 다른 기억이 `slogs/deployment/wasm-aot`에 있다면 둘은 모두 Slogs 프로젝트 기억이지만 적용 맥락은 다르다. 같은 단어가 들어 있어도 categoryPath가 다르면 Agent가 다르게 해석해야 한다. 그래서 categoryPath는 단순 분류 라벨이 아니다. 검색 범위를 좁히고, 기억의 적용 영역을 판단하는 구조 정보다. 좋은 categoryPath는 대체로 이렇게 생겼다. ```text project/domain/topic project/feature/decision preference/domain/project codex/mcp/slogs ``` 반대로 `general`, `misc`, `notes` 같은 경로는 나중에 검색을 어렵게 만든다. 주제를 알 수 있으면 구체적으로 저장해야 한다. ## 4. Retrieval Diagnostics로 검색 품질을 본다 Agent 검색에서 가장 위험한 상황은 “검색을 했지만 사실상 실패한 것”을 성공으로 착각하는 것이다. 결과가 0개였거나, 상위 결과가 엉뚱하거나, 너무 넓은 범위를 훑어서 쓸모없는 문맥만 가져왔는데도 Agent가 그럴듯하게 답하면 기억 시스템은 오히려 위험해진다. 그래서 Slogs LLM Wiki 응답에는 Retrieval Diagnostics를 붙인다. - result count - effectiveLimit - categoryPath - minRelevancePercent - elapsedMs…