LLM Wiki는 메모장이 아니라 Agent의 작업 기억이다

![LLM Wiki Agent memory flow](/uploads/20260627-llmwiki-agent-memory-v2.png) LLM Wiki를 처음 만들 때 가장 경계해야 할 오해는 이것을 “AI가 보는 메모장” 정도로 보는 것이다. 메모장은 사람이 나중에 읽기 위해 남긴다. Agent의 작업 기억은 다르다. Agent가 현재 요청을 처리하기 전에 먼저 조회하고, 조회 결과를 기준으로 판단하고, 작업이 끝난 뒤 다음 세션에도 재사용할 지식을 다시 정리해 넣는 실행 경로의 일부다. Slogs LLM Wiki는 이 관점으로 설계했다. 글 하나를 저장하는 기능보다 중요한 것은 Agent가 언제 검색해야 하는지, 어떤 도구를 써야 하는지, 어떤 정보는 저장하지 말아야 하는지를 정책으로 고정하는 것이다. ## 기억이 필요한 질문과 필요 없는 질문 모든 요청을 기억 서버로 보내면 느려지고 노이즈가 쌓인다. 반대로 기억을 거의 조회하지 않으면 매 세션이 처음 만난 사람처럼 행동한다. 그래서 기준을 단순하게 둔다. - 현재 시각 확인, 짧은 번역, 일회성 명령처럼 맥락이 필요 없는 요청은 바로 처리한다. - 이전 결정, 사용자 선호, 프로젝트 판단 기준, 작업 재시작 지점, 반복 워크플로가 영향을 줄 수 있으면 먼저 LLM Wiki를 조회한다. - 결과가 애매하면 로컬 파일이나 코드보다 기억 후보를 먼저 보고, 그 다음 실제 파일로 검증한다. 이 순서가 중요하다. 코드 저장소에는 “현재 구현”은 남아 있지만, 왜 그렇게 결정했는지나 사용자가 싫어하는 방식은 남아 있지 않을 때가 많다. 예를 들어 “fallback 구현을 싫어한다”는 선호는 코드만 봐서는 알 수 없다. 이런 기준은 Agent가 작업 전에 반드시 회수해야 한다. ## 도구는 역할별로 나뉘어야 한다 MCP 공식 문서에서 도구는 모델이 발견하고 호출할 수 있는 외부 기능으로 설명된다. Slogs LLM Wiki도 이 구조를 따른다. 다만 모든 조회를 하나의 search로 해결하지 않는다. - `llm_wiki_search`: 제목, 요약, 태그, categoryPath로 후보를 작게 고르는 도구 - `llm_wiki_recall`: 답변이나 구현에 바로 반영할 compact context를 회수하는 도구 - `llm_wiki_read`: 선택한 항목의 전체 내용과 출처를 읽는 도구 - `llm_wiki_capture`, `llm_wiki_find_related`: 저장 전에 관련 기억을 찾고 병합 후보를 판단하는 도구 - `llm_wiki_merge`, `llm_wiki_update`, `llm_wiki_remember`: 기존 기억을 갱신하거나 새 기억을 저장하는 도구 이 분리는 토큰 비용을 줄이는 목적만 있는 것이 아니다. Agent가 “대충 검색해서 나온 문장”과 “정말 적용해야 하는 기억”을 구분하게 만든다. ## 좋은 기억은 재사용 가능한 판단이다 Slogs LLM Wiki에 저장할 만한 정보는 단순 실행 로그가 아니다. “방금 배포했다”, “어떤 명령을 실행했다” 같은 일회성 진행상황은 대부분 저장 가치가 낮다. 반대로 다음과 같은 정보는 장기 기억으로 가치가 있다. - 사용자가 명시적으로 정정한 용어와 판단 기준 - 프로젝트에서 반복되는 운영 절차 - 코드만 보고는 알기 어려운 전제조건 - 장애 원인과 검증된 해결 경로 - 다음 세션에서 바로 이어갈 수 있는 재시작 지점 - 나중에 runbook이나 자동화로 바꿀 수 있는 명령 흐름 핵심은 “나중의 Agent가 이 정보를 보고 더 나은 결정을 할 수 있는가”다. 그렇지 않다면 저장하지 않는 편이 낫다. ## 저장보다 병합이 중요하다 기억 시스템이 오래 가려면 새 항목을 무한히 쌓는 방식은 피해야 한다. 같은 주제의 결정이 여러 개로 흩어지면 검색 결과는 많아지지만 실제 판단은 어려워진다. Slogs LLM Wiki는 저장 전에 관련 항목을 먼저 찾도록 한다. 관련 항목이 있으면 읽고, 기존 기억에 병합하거나 갱신한다. 관련 항목이 없을 때만 새 항목을 만든다. 이때 raw provenance도…