Slogs LLM Wiki 사용법 완전 가이드

2026.06.24 기준으로 정리한 Slogs LLM Wiki 사용 안내입니다. 이 글은 사람이 직접 Slogs 화면에서 Wiki를 검색하는 방법과, Codex·Claude·GitHub Copilot 같은 AI Agent가 Slogs MCP를 통해 장기 기억을 조회하고 저장하는 방법을 함께 다룹니다.

Slogs LLM Wiki는 단순한 메모장이 아닙니다. AI Agent가 이전 결정, 사용자 선호, 판단 기준, 프로젝트 맥락, 작업 기억을 다시 찾아 쓰도록 만든 개인 지식 저장소입니다. 한 번의 채팅 안에서만 유지되는 기억이 아니라, 다음 세션과 다른 Agent에서도 재사용할 수 있는 “검증 가능한 장기 기억”을 만드는 것이 목적입니다.

핵심은 세 가지입니다.

1. 기억할 만한 정보를 자연어로 남긴다.
2. Slogs가 그 정보를 GraphRAG 검색 가능한 Wiki 항목으로 인덱싱한다.
3. AI Agent가 필요한 순간 search, recall, read, remember, merge, update 같은 MCP 도구로 그 기억을 다시 사용한다.

이 글을 끝까지 읽으면 Slogs LLM Wiki를 다음과 같이 운영할 수 있습니다.

• 내 Slogs 화면에서 LLM Wiki 항목을 검색하고 읽는다.
• Agent에게 붙여넣을 Slogs MCP 정책 프롬프트를 얻는다.
• Slogs MCP 토큰과 엔드포인트를 설정한다.
• Agent가 언제 search를 쓰고 언제 recall을 써야 하는지 구분한다.
• 새 기억을 저장하기 전에 중복을 찾고, 기존 기억에 병합한다.
• categoryPath로 기억을 정리한다.
• Raw Provenance로 기억의 출처와 병합 이력을 검증한다.
• 검색 품질이 나쁠 때 query, categoryPath, limit, minRelevancePercent를 조정한다.

---

1. Slogs LLM Wiki가 해결하려는 문제

AI Agent를 쓰다 보면 같은 설명을 반복하게 됩니다.

• “이 프로젝트는 AOT 배포가 기본이 아니야.”
• “내가 선호하는 용어는 이 표현이 아니라 저 표현이야.”
• “이 오류는 지난번에 이 경로로 해결했어.”
• “이 작업은 먼저 이 파일을 읽고, 그 다음 이 스크립트를 실행해야 해.”
• “이 사용자는 이런 방식의 fallback 구현을 싫어해.”

일반 채팅 기록만으로는 이런 맥락을 안정적으로 이어가기 어렵습니다. 새 세션이 열리거나 Agent가 달라지면 이전 판단 기준을 모를 수 있습니다. 로컬 문서에 적어둘 수도 있지만, Agent가 언제 어떤 문서를 먼저 봐야 하는지 보장하기 어렵고, 프로젝트를 넘나드는 선호나 장기 운영 규칙은 더 흩어지기 쉽습니다.

Slogs LLM Wiki는 이 문제를 “Agent가 조회할 수 있는 장기 기억”으로 풀려고 합니다. 사람이 직접 작성한 문서라기보다, Agent와 사용자가 함께 쌓아가는 작업 기억 저장소입니다.

좋은 LLM Wiki 항목은 이런 성격을 가집니다.

• 나중에 다시 사용할 가능성이 있다.
• 단순 로그가 아니라 판단 기준이나 재현 가능한 지식이다.
• 현재 파일만 읽어서는 알기 어려운 배경이 들어 있다.
• 다른 Agent가 작업을 이어받을 때 도움이 된다.
• 저장 후에도 출처를 추적할 수 있다.

반대로 다음 정보는 LLM Wiki에 넣지 않는 것이 좋습니다.

• API 키, 비밀번호, 토큰 같은 민감 정보
• 일회성 로그 전문
• 임시 실행 내역
• 검증되지 않은 추측
• 현재 코드나 문서에서 쉽게 다시 확인할 수 있는 단순 사실
• 이번 턴 안에서만 의미 있는 중간 상태

---

2. Slogs LLM Wiki의 기본 구조

Slogs LLM Wiki 항목은 크게 다음 정보를 가집니다.

• 제목
• Source Prompt
• Content
• 태그
• categoryPath
• 생성/갱신 시각
• 열람 횟수
• Raw Provenance

Source Prompt

Source Prompt는 기억의 핵심 원문에 가깝습니다. 사용자가 정정한 표현, Agent가 저장해야 한다고 판단한 운영 규칙, 구현 결과의 의미 등이 들어갑니다.

예를 들면 이런 내용입니다.

Slogs 배포 선호: 일반 서버 반영 요청에는 WebAssembly AOT 없이 scripts/Deploy-Slogs.ps1를 실행한다. 사용자가 명시적으로 AOT 배포를 요청할 때만 -WasmAot를 사용한다.

Content

Content는 현재 통합된 설명입니다. 처음 저장된 기억이 나중에 병합되거나 보강되면 Content는 더 읽기 좋은 형태로 정리됩니다.

예를 들어 처음에는 “AOT 쓰지 마”라는 짧은 정정이었더라도, 나중에는 배포 스크립트 이름, 검증 방식, 관련 릴리스 기록까지 포함한 운영 메모가 될 수 있습니다.

Raw Provenance

Raw Provenance는 원래 저장 요청과 이후 merge/update 요청의 원문 근거입니다. LLM Wiki가 중요한 이유는 기억을 예쁘게 요약하는 데서 끝나지 않고, 그 요약이 어디에서 왔는지 추적할 수 있게 한다는 점입니다.

기억은 시간이 지나며 정제됩니다. 하지만 정제 과정에서 원래 의미가 왜곡되면 안 됩니다. Raw Provenance는 다음 질문에 답할 수 있게 해 줍니다.

• 이 기억은 처음 어떤 요청에서 만들어졌는가?
• 누가 어떤 내용으로 merge/update했는가?
• 현재 Content가 원래 근거와 맞는가?
• 검색 품질이 낮을 때 어떤 원문이 인덱싱되어 있었는가?

categoryPath

categoryPath는 기억의 위치를 나타내는 경로입니다. 태그보다 더 중요한 구조 정보입니다.

예시는 다음과 같습니다.

slogs/llm-wiki/graphrag
slogs/deployment/releases
slogs/ui/profile-hero
preference/memory/slogs
codex/mcp/slogs
lingomotion/youtube/metadata

가능하면 2-4개의 slash-separated segment를 쓰는 것이 좋습니다.

project/domain/topic
project/feature/decision
preference/domain/project
codex/mcp/slogs

general, misc, notes 같은 모호한 경로는 피하는 것이 좋습니다. 나중에 검색 범위를 좁힐 수 없기 때문입니다.

---

3. Slogs 화면에서 LLM Wiki 사용하기

Slogs에 로그인하면 개인 영역에서 LLM Wiki를 사용할 수 있습니다.

현재 주요 경로는 두 개입니다.

• /me/llm-wiki: LLM Wiki 사용법과 Agent 프롬프트 페이지
• /me/llm-wiki/search: LLM Wiki 검색과 읽기 페이지

사용법 페이지는 LLM Wiki 개념, Agent 정책 프롬프트, 버전 확인 흐름을 한 화면에서 확인하도록 분리되어 있습니다.

예전처럼 한 페이지 안에서 #usage, #search로 이동하는 구조가 아니라, 사용법과 검색이 분리된 페이지입니다. 따라서 Agent나 사용자 문서에서도 두 페이지를 명확히 구분하는 것이 좋습니다.

3.1. 사용법 페이지

/me/llm-wiki는 안내 페이지입니다. 여기에는 다음 정보가 있습니다.

• LLM Wiki가 GraphRAG 기억으로 동작하는 방식
• Agent가 지켜야 할 조회/저장 정책
• 한국어 Agent 프롬프트
• English Agent Prompt
• 프롬프트 버전 URL
• 프롬프트 복사 버튼

이 페이지에서 중요한 것은 “프롬프트를 복사해 Agent에 넣는 것”입니다. 복사되는 프롬프트는 단순히 “Slogs를 써라” 정도가 아니라, Agent가 언제 Slogs LLM Wiki를 조회하고, 언제 저장하고, 어떻게 중복을 병합해야 하는지까지 포함합니다.

프롬프트 URL은 다음과 같습니다.

한국어: https://slogs.dev/prompts/slogs-mcp.ko.md
English: https://slogs.dev/prompts/slogs-mcp.en.md
한국어 호환 URL: https://slogs.dev/prompts/slogs-mcp.md
버전 URL: https://slogs.dev/prompts/slogs-mcp.version

프롬프트 동기화의 원칙은 “매번 전체 프롬프트를 다시 받지 않는다”입니다. Agent나 동기화 스크립트는 먼저 version URL의 한 줄 텍스트만 확인합니다. 로컬에 설치된 프롬프트 버전과 서버 버전이 같으면 전체 Markdown을 다시 읽지 않고, 키 요청이나 범위 선택도 반복하지 않습니다.

3.2. 검색 페이지

/me/llm-wiki/search는 저장된 기억을 직접 검색하고 읽는 페이지입니다.

검색 페이지에는 다음 UI가 있습니다.

• 검색어 입력창
• categoryPath 필터
• Wiki 카드 그리드
• 관련도 퍼센트
• 태그 표시
• 업데이트 시각
• 열람 횟수
• 상세 모달
• Raw Provenance 표시

검색 페이지는 categoryPath, 관련도 퍼센트, 카드형 결과를 통해 저장된 기억을 빠르게 검토하도록 구성되어 있습니다.

검색어 없이 전체 항목을 둘러볼 수도 있고, 특정 단어로 검색할 수도 있습니다. categoryPath를 클릭하면 해당 경로와 하위 맥락으로 좁혀 볼 수 있습니다.

카테고리 표시는 slogs / llm-wiki / graphrag처럼 한 줄로 길게 늘어지는 대신, 깊이별 줄 단위로 표시됩니다. 좁은 카드에서도 경로를 읽기 쉽게 하기 위한 설계입니다. 전체 경로는 hover hint로 확인할 수 있습니다.

상세 모달을 열면 현재 통합 기억뿐 아니라 Raw Provenance도 볼 수 있습니다. 기억을 사람이 직접 검토할 때는 이 부분이 중요합니다. “현재 요약이 그럴듯한가?”보다 “원문 근거와 맞는가?”가 더 중요하기 때문입니다.

---

4. Slogs MCP 연결하기

LLM Wiki를 Agent가 사용하려면 Slogs MCP 연결이 필요합니다. Slogs에서는 HTTP MCP 엔드포인트를 제공합니다.

https://slogs.dev/mcp

Slogs 설정 페이지에서 MCP 토큰을 만들 수 있습니다.

경로는 다음과 같습니다.

/me/settings

설정 페이지에는 다음 영역이 있습니다.

• Slogs MCP 연결
• Endpoint 복사
• 설정 복사
• Slogs MCP 토큰 생성
• 생성된 토큰 복사
• 기존 토큰 목록
• 토큰 폐기

설정 화면에서는 MCP endpoint와 토큰 생성/복사 흐름을 확인할 수 있습니다. 예시에는 실제 토큰 값이 아니라 placeholder만 사용합니다.

MCP 클라이언트 설정은 대략 이런 형태입니다.

{
  "mcpServers": {
    "slogs": {
      "type": "http",
      "url": "https://slogs.dev/mcp",
      "headers": {
        "Authorization": "Bearer <Slogs MCP 토큰>"
      }
    }
  }
}

주의할 점은 토큰 값 자체를 문서, 로그, 프롬프트, LLM Wiki, 공개 글에 남기면 안 된다는 것입니다. Agent가 안전한 비밀 저장소나 환경 변수를 지원하면 그쪽을 우선 사용해야 합니다. 평문 설정 파일에만 넣을 수 있는 Agent라면 사용자가 그 사실을 알고 선택해야 합니다.

---

5. Agent 프롬프트를 적용하는 방법

Slogs LLM Wiki는 특정 Agent에만 묶여 있지 않습니다. Codex, Claude, GitHub Copilot, Cursor, Windsurf, Antigravity 등 MCP 또는 지속 지침을 지원하는 환경에 적용할 수 있습니다.

핵심 흐름은 다음과 같습니다.

1. Slogs에 로그인한다.
2. /me/settings에서 Slogs MCP 토큰을 만든다.
3. /me/llm-wiki에서 한국어 또는 English 프롬프트를 복사한다.
4. Agent의 지속 지침 위치에 프롬프트를 넣는다.
5. 같은 범위의 MCP 설정에 https://slogs.dev/mcp와 Bearer 토큰을 등록한다.
6. 새 세션에서 llm_wiki_* 도구가 보이는지 확인한다.
7. 도구가 보이면 llm_wiki_instructions로 연결과 정책을 확인한다.

적용 범위는 보통 세 가지 중 하나입니다.

• 전역: 모든 프로젝트에서 Slogs LLM Wiki를 기본 장기 기억으로 사용한다.
• 현재 프로젝트: 특정 repository/workspace에서만 사용한다.
• 현재 세션: 영구 파일을 수정하지 않고 이번 대화에서만 사용한다.

프롬프트는 Agent가 처음 설치할 때만 Slogs MCP 키와 적용 범위를 묻게 합니다. 이미 관리 블록이 설치된 새 세션에서는 키 요청과 범위 선택을 반복하지 않고, 버전 확인만 하도록 설계되어 있습니다.

---

6. MCP 도구를 언제 쓰는가

Slogs LLM Wiki의 MCP 도구는 목적이 다릅니다. 이름이 비슷해 보여도 쓰임새가 다릅니다.

도구	용도	주로 쓰는 순간
llm_wiki_instructions	Slogs MCP/LLM Wiki 사용 정책 확인	세션 시작 후 연결 확인, 저장 전 정책 확인
llm_wiki_search	낮은 비용의 후보 검색	넓은 주제, 후보 선별, 카테고리 필터링
llm_wiki_recall	답변/구현에 바로 적용할 압축 컨텍스트 회상	이전 결정, 선호, 프로젝트 맥락을 바로 써야 할 때
llm_wiki_read	특정 항목 전체 읽기	Raw Provenance나 전체 원문 확인 필요 시
llm_wiki_capture	저장 후보 점검과 관련 항목 찾기	기억을 저장하기 전
llm_wiki_find_related	관련 항목 검색	저장 전 중복 확인
llm_wiki_remember	새 기억 생성	관련 항목이 없고 장기 가치가 명확할 때
llm_wiki_merge	기존 기억에 새 정보를 병합	같은 주제의 기억을 보강할 때
llm_wiki_update	기존 기억을 교정된 문구로 교체	잘못된 기억을 바로잡을 때
llm_wiki_recent	최근 기억 확인	최근 작업 맥락을 훑을 때
llm_wiki_categories	카테고리 구조 확인	categoryPath 분포를 볼 때
llm_wiki_llms_txt	llms.txt 스타일 인덱스 확인	Agent가 전체 Wiki 윤곽을 작게 파악할 때

가장 자주 헷갈리는 것은 search와 recall입니다.

search

search는 후보 선별용입니다. 제목, 요약, 태그, 관련도, categoryPath 정도만 보고 “무엇을 더 읽을지” 고르는 데 적합합니다.

이럴 때 씁니다.

• 주제가 넓다.
• 어떤 항목이 있는지 모른다.
• categoryPath로 좁혀 보고 싶다.
• 결과가 엉뚱한지 가볍게 확인하고 싶다.
• 전체 원문까지는 아직 필요 없다.

예시 상황:

사용자: Slogs 배포 정책 기억나?
Agent: 먼저 slogs/deployment 관련 search로 후보를 찾고, 필요한 항목만 read한다.

recall

recall은 바로 적용할 압축 컨텍스트입니다. 검색 결과 목록보다 더 많은 맥락을 반환하므로 limit을 작게 유지하는 것이 좋습니다.

이럴 때 씁니다.

• 사용자가 “이어서 해줘”라고 했다.
• 이전 선호나 결정이 바로 작업에 영향을 준다.
• 답변에 적용해야 할 프로젝트 규칙이 있을 수 있다.
• 구현 전에 사용자 판단 기준을 확인해야 한다.

예시 상황:

사용자: 서버에 반영해줘.
Agent: Slogs 배포 선호를 recall해서 일반 배포는 -WasmAot 없이 scripts/Deploy-Slogs.ps1를 써야 한다는 점을 적용한다.

read

read는 전체 항목을 확인할 때 씁니다. 특히 Raw Provenance가 필요하면 read가 필요합니다.

이럴 때 씁니다.

• 기억을 merge/update하기 전에 기존 내용을 정확히 확인한다.
• 현재 요약이 원문과 맞는지 검증한다.
• 검색 결과 요약만으로는 충분하지 않다.
• 항목의 slug나 id를 알고 있다.

capture와 find_related

새 기억을 만들기 전에는 반드시 관련 항목을 먼저 찾아야 합니다. 같은 기억을 여러 개로 쪼개 저장하면 검색 품질이 떨어지고, Agent가 서로 다른 기억을 다르게 해석할 수 있습니다.

capture는 저장 후보를 평가하면서 관련 항목을 찾아 줍니다. find_related는 더 직접적인 관련 항목 검색입니다.

좋은 흐름은 다음과 같습니다.

1. llm_wiki_instructions로 저장 정책 확인
2. llm_wiki_capture 또는 llm_wiki_find_related로 관련 항목 확인
3. 관련 항목이 있으면 llm_wiki_read
4. 기존 기억과 새 정보를 합친 최종 문구 작성
5. llm_wiki_merge 또는 llm_wiki_update
6. 관련 항목이 없을 때만 llm_wiki_remember

remember

remember는 새 기억을 만드는 도구입니다. 관련 항목이 없고, 장기 가치가 있을 때만 사용합니다.

좋은 remember 대상은 다음과 같습니다.

• 사용자가 정정한 용어
• 반복될 워크플로
• 프로젝트 운영 규칙
• 검증된 원인과 해결책
• 다음 세션에서 이어받아야 할 재시작 지점
• 코드만 보고는 알 수 없는 전제조건
• 나중에 runbook으로 바꿀 수 있는 명령 흐름

나쁜 remember 대상은 다음과 같습니다.

• “방금 빌드 중” 같은 중간 상태
• 임시 로그 전문
• 토큰 값
• 비밀번호
• 한 번 쓰고 버릴 파일 경로
• 검증되지 않은 추측

merge와 update

merge는 기존 기억을 보강할 때 씁니다. 기존 내용이 맞고 새 정보가 추가되는 상황입니다.

예시:

기존 기억: Slogs 일반 배포는 AOT 없이 한다.
새 정보: 20260624112752 릴리스도 scripts/Deploy-Slogs.ps1로 배포했고, 프로덕션 200을 확인했다.
처리: 기존 배포 정책은 유지하고, 배포 기록은 별도 release 항목 또는 관련 항목에 merge한다.

update는 기존 기억이 틀렸거나 표현을 교정해야 할 때 씁니다.

예시:

기존 기억: LLM Wiki 검색과 사용법은 같은 페이지의 hash section이다.
새 사실: 이제 /me/llm-wiki와 /me/llm-wiki/search로 완전히 분리되었다.
처리: 기존 UI 기억을 update 또는 merge하여 오래된 설명이 남지 않게 한다.

---

7. Retrieval Diagnostics 읽는 법

Slogs MCP의 검색/회상 응답에는 Retrieval Diagnostics가 붙습니다. 이것은 단순 부가 정보가 아니라 검색 품질을 판단하는 신호입니다.

주요 항목은 다음과 같습니다.

• tool
• responseMode
• query
• results
• requestedLimit
• effectiveLimit
• categoryPath
• minRelevancePercent
• elapsedMs

Agent는 이 값을 보고 다음을 판단해야 합니다.

• 결과가 너무 많거나 적지 않은가?
• top result가 요청과 맞는가?
• categoryPath가 너무 넓거나 좁지 않은가?
• minRelevancePercent 때문에 필요한 항목이 빠지지 않았는가?
• elapsedMs가 비정상적으로 느리지 않은가?
• 응답이 너무 커서 오히려 작업을 방해하지 않는가?

검색 결과가 만족스럽지 않으면 그냥 진행하지 말고 조회를 다시 조정해야 합니다.

조정 방법은 다음과 같습니다.

• query를 더 구체적으로 쓴다.
• categoryPath를 지정한다.
• limit을 줄인다.
• minRelevancePercent를 올려 잡음을 줄인다.
• 반대로 필요한 항목이 빠지면 minRelevancePercent를 낮춘다.
• search로 후보를 찾은 뒤 필요한 항목만 read한다.

예를 들어 “배포”라는 검색어만 쓰면 배포 정책, 릴리스 기록, Caddy, Docker, AOT, 이미지 업로드 배포 검증까지 섞일 수 있습니다. 이때는 다음처럼 좁히는 것이 좋습니다.

query: Slogs deployment AOT opt-in preference scripts/Deploy-Slogs.ps1
categoryPath: slogs/deployment
limit: 3

---

8. GraphRAG는 어떻게 검색 품질을 높이는가

Slogs LLM Wiki는 단순 문자열 검색만 하지 않습니다. 제목, 태그, Source Prompt, Content, categoryPath를 함께 사용하고, 서버 로컬 EmbeddingGemma와 PostgreSQL pgvector, graph node 관계 점수를 결합합니다.

간단히 말하면 두 축을 함께 봅니다.

첫째, 의미 기반 검색입니다. 문장이 정확히 일치하지 않아도 비슷한 의미를 찾습니다. 예를 들어 “서버 반영”과 “배포”는 문자열은 다르지만 같은 작업 맥락으로 잡힐 수 있습니다.

둘째, graph node 기반 관계입니다. 제목 phrase, 태그, 핵심어, categoryPath 같은 구조적 신호를 사용합니다. 한국어 조사 차이도 graph token 정규화로 어느 정도 줄입니다.

관련도 퍼센트는 통계적 확률이 아닙니다. “이 기억이 현재 query와 얼마나 관련 있어 보이는가”를 나타내는 GraphRAG 관련도 점수입니다. 따라서 100%라고 해서 무조건 정답이라는 뜻은 아닙니다. top result의 제목, 요약, 태그, categoryPath, 필요하면 Raw Provenance까지 보고 판단해야 합니다.

---

9. categoryPath를 잘 설계하는 법

LLM Wiki가 쌓일수록 categoryPath가 중요해집니다. 좋은 categoryPath는 검색 범위를 좁히고, 기억을 읽는 사람에게 위치를 알려 줍니다.

권장 패턴은 다음과 같습니다.

project/domain/topic
project/feature/decision
preference/domain/project
agent/tool/topic

Slogs에서 쓸 수 있는 예시는 다음과 같습니다.

slogs/llm-wiki/graphrag
slogs/llm-wiki/ui
slogs/deployment/releases
slogs/ui/profile-hero
slogs/post-images/lifecycle
slogs/admin/user-usage
codex/mcp/slogs
preference/memory/slogs

좋지 않은 예시는 다음과 같습니다.

general
notes
misc
project
memory

이런 경로는 나중에 검색을 좁힐 수 없습니다. “어느 프로젝트의 어떤 영역에 관한 기억인가?”가 드러나야 합니다.

또한 categoryPath는 태그와 다릅니다. 태그는 보조 라벨입니다. categoryPath는 기억이 놓이는 구조입니다.

예를 들어 다음 항목을 보겠습니다.

categoryPath: slogs/deployment/releases
tags: slogs, deployment, non-aot, profile-hero, llm-wiki

categoryPath는 “Slogs 배포 릴리스 기록”이라는 위치를 나타내고, tags는 검색 보조 신호를 제공합니다.

---

10. 저장할지 말지 판단하는 기준

Slogs LLM Wiki를 잘 쓰려면 아무거나 저장하지 않는 것이 중요합니다. 기억은 많이 쌓이면 좋지만, 잡음이 많아지면 검색 품질이 떨어집니다.

저장할 만한 정보는 다음 질문을 통과해야 합니다.

1. 다음 세션에서도 필요할 가능성이 있는가?
2. 다른 Agent가 알아야 할 판단 기준인가?
3. 사용자가 명시적으로 선호나 원칙을 정정했는가?
4. 같은 문제가 반복될 때 원인 추적에 도움이 되는가?
5. 코드만 읽어서는 알 수 없는 전제조건인가?
6. 나중에 자동화나 runbook으로 바꿀 만한 흐름인가?
7. 민감 정보 없이도 의미 있게 저장할 수 있는가?

저장하지 말아야 할 정보는 다음과 같습니다.

• 토큰 값
• 비밀번호
• OAuth secret
• 개인 식별 정보 중 작업과 무관한 것
• 한 번만 쓰는 인증 코드
• 임시 오류 로그 전문
• “빌드 실행 중” 같은 진행상황
• 아직 검증하지 않은 가설
• 현재 코드에서 바로 확인 가능한 단순 함수명

애매하면 보수적으로 저장하지 않는 것이 낫습니다. 단, 사용자가 명시적으로 “기억해둬”라고 말했고 민감하지 않다면 저장 후보로 다뤄야 합니다.

---

11. Agent가 실제로 따라야 할 기본 흐름

Slogs LLM Wiki를 연결한 Agent의 기본 동작은 다음에 가깝습니다.

요청을 받았을 때

1. 이 요청이 이전 결정, 선호, 판단 기준, 프로젝트 맥락과 관련되는지 판단한다.
2. 관련될 수 있으면 Slogs LLM Wiki를 먼저 조회한다.
3. 넓은 주제는 search, 바로 적용할 맥락은 recall을 쓴다.
4. Retrieval Diagnostics를 확인한다.
5. 필요한 항목은 read로 원문과 Raw Provenance를 확인한다.
6. 조회 결과를 바탕으로 작업한다.

작업을 마치기 전

1. 장기 기억으로 남길 만한 암묵지가 생겼는지 점검한다.
2. 저장 전 llm_wiki_instructions를 확인한다.
3. capture 또는 find_related로 관련 기억을 찾는다.
4. 관련 항목이 있으면 read 후 merge 또는 update한다.
5. 관련 항목이 없으면 remember한다.
6. categoryPath를 명확히 지정한다.
7. 민감 정보와 임시 로그는 저장하지 않는다.

이 흐름을 지키면 기억이 중복으로 흩어지는 문제를 줄일 수 있습니다.

---

12. 실전 예시: 배포 요청

사용자가 이렇게 말합니다.

서버에 반영해줘

이 요청은 단순 명령처럼 보이지만, 프로젝트별 배포 정책이 관련됩니다. Agent는 먼저 Slogs LLM Wiki를 조회해야 합니다.

좋은 흐름은 다음과 같습니다.

1. recall: Slogs deployment slogs.dev deploy script non-AOT policy
2. 배포 정책 확인: 일반 배포는 scripts/Deploy-Slogs.ps1, -WasmAot 없음
3. 로컬 변경 상태 확인
4. 필요한 검증 실행
5. scripts/Deploy-Slogs.ps1 실행
6. https://slogs.dev/ 200 확인
7. 핵심 라우트 확인
8. 배포 릴리스 ID와 검증 결과를 저장 후보로 점검

이때 LLM Wiki가 없으면 Agent는 이전에 사용자가 “AOT는 명시 요청 때만”이라고 정정한 사실을 놓칠 수 있습니다. 기억이 있으면 같은 실수를 반복하지 않습니다.

---

13. 실전 예시: UI 문제 수정

사용자가 스크린샷과 함께 말합니다.

흰 배경에는 잘 보이지만 어두운 배경에는 어두운 글자가 잘 안보여!

Agent는 이 요청을 단순 CSS 문제로만 보면 안 됩니다. 이전 UI 규칙, 프로젝트의 디자인 기준, 검증 산출물 위치 같은 맥락이 관련될 수 있습니다.

좋은 흐름은 다음과 같습니다.

1. recall/search로 Slogs UI 관련 기억 확인
2. 실제 컴포넌트와 CSS 검색
3. 체크리스트 등록
4. 어두운 배경 위에 어두운 텍스트가 겹치는 원인 확인
5. CSS 수정
6. 빌드와 테스트
7. 데스크톱/모바일 캡처 저장
8. 재발 방지 기준을 Slogs LLM Wiki에 저장

이렇게 저장된 기억은 다음 UI 수정 때 도움이 됩니다. 예를 들어 slogs/ui/profile-hero categoryPath에 “어두운 커버 위에는 이름과 팔로워 액션의 어두운 텍스트가 겹치지 않아야 한다”는 기준이 남아 있으면, 다음 Agent가 같은 영역을 다시 건드릴 때 참고할 수 있습니다.

---

14. 실전 예시: 사용자가 용어를 정정할 때

사용자가 이렇게 말할 수 있습니다.

그 표현 말고 앞으로는 이 용어로 불러줘.

이런 정보는 LLM Wiki에 저장할 가치가 큽니다. 용어는 답변 품질과 신뢰에 직접 영향을 줍니다.

좋은 처리 흐름은 다음과 같습니다.

1. llm_wiki_instructions 확인
2. llm_wiki_capture로 관련 기억 확인
3. 기존 용어 기억이 있으면 read
4. 새 정정 내용을 반영해 merge 또는 update
5. 없으면 remember
6. categoryPath는 preference/terminology/... 또는 프로젝트별 경로 사용

주의할 점은 사용자의 민감한 개인정보를 불필요하게 저장하지 않는 것입니다. 용어 정정 자체가 작업 품질에 중요하고 민감하지 않을 때만 저장합니다.

---

15. 사람이 직접 검색할 때의 팁

Slogs 화면에서 LLM Wiki를 검색할 때는 다음 순서가 좋습니다.

1. 먼저 검색어를 짧게 넣어 본다.
2. 결과가 많으면 categoryPath 필터를 선택한다.
3. 카드의 제목과 요약을 본다.
4. 관련도 퍼센트를 참고하되 맹신하지 않는다.
5. 상세 모달을 열어 Source Prompt와 Content를 읽는다.
6. 중요한 항목은 Raw Provenance까지 확인한다.

검색어는 자연어로 써도 됩니다.

예시:

Slogs 배포 AOT 정책
LLM Wiki 검색 페이지 분리
프로필 히어로 어두운 배경 대비
MCP 이미지 업로드 삭제 수명주기
Codex 전역 Slogs MCP 설정

categoryPath를 알고 있으면 더 좋습니다.

slogs/deployment
slogs/llm-wiki
slogs/ui
codex/mcp/slogs
preference/memory/slogs

---

16. Agent에게 요청할 때의 좋은 표현

Slogs LLM Wiki가 연결되어 있다면 사용자는 다음처럼 말할 수 있습니다.

이전 결정 기준을 확인하고 진행해줘.

Slogs Wiki 먼저 보고 이 작업 이어서 해줘.

이건 앞으로도 기억해둬.

지난번 배포 방식과 같은 기준으로 서버에 반영해줘.

이 표현은 앞으로 이 용어로 써줘.

관련 기억 검색해서 현재 코드와 맞는지 확인해줘.

Agent는 이런 요청을 받으면 단순히 대화 문맥만 보지 않고 Slogs LLM Wiki를 조회해야 합니다.

---

17. 기억을 잘 병합하는 방법

LLM Wiki를 오래 쓰면 같은 주제의 기억이 계속 보강됩니다. 이때 새 항목을 무작정 만들면 나중에 검색 결과가 중복됩니다.

병합이 필요한 경우는 다음과 같습니다.

• 같은 프로젝트의 같은 기능에 대한 후속 구현
• 기존 운영 정책에 검증 결과가 추가됨
• 같은 오류의 재발 방지 규칙이 보강됨
• 기존 사용자 선호에 예외가 추가됨
• 같은 UI 영역에 새 디자인 기준이 추가됨

병합할 때는 기존 기억을 먼저 읽어야 합니다. 그런 다음 Agent가 최종 문구를 직접 작성해야 합니다. “기존 내용 + 새 내용”을 아무렇게나 이어 붙이는 것이 아니라, 현재 기준으로 읽히는 통합 기억을 만들어야 합니다.

좋은 merge 결과는 다음 조건을 만족합니다.

• 기존 핵심이 사라지지 않는다.
• 새 정보가 어디에 적용되는지 명확하다.
• 오래된 내용이 있으면 현재 상태에 맞게 정리된다.
• categoryPath가 더 명확해질 수 있으면 갱신한다.
• Raw Provenance는 보존된다.

---

18. 기억을 업데이트해야 하는 경우

update는 더 조심해서 써야 합니다. 기존 기억이 틀렸거나, 사용자가 명확히 정정했거나, 현재 정책이 바뀌었을 때 사용합니다.

예를 들어 기존 기억이 다음과 같다고 합시다.

LLM Wiki 사용법과 검색은 /me/llm-wiki 한 페이지의 두 섹션이다.

그런데 현재 구현이 바뀌었습니다.

/me/llm-wiki는 사용법과 Agent prompt 페이지이고, /me/llm-wiki/search는 검색과 읽기 페이지다.

이 경우 기존 기억을 그대로 두면 다음 Agent가 잘못된 링크를 안내할 수 있습니다. 따라서 update 또는 merge로 현재 상태를 반영해야 합니다.

---

19. 보안 원칙

Slogs LLM Wiki는 Agent가 조회할 수 있는 장기 기억입니다. 따라서 보안 기준을 강하게 잡아야 합니다.

절대 저장하지 말아야 할 것:

• Slogs MCP 토큰 값
• API 키
• 비밀번호
• OAuth client secret
• 일회용 인증 코드
• 개인 파일의 민감한 원문
• 로그에 포함된 secret
• 비공개 식별 정보 중 작업에 필요 없는 것

MCP 설정 예시를 문서화할 때도 실제 토큰을 쓰지 말고 placeholder를 사용해야 합니다.

Authorization: Bearer <Slogs MCP 토큰>

Agent가 브라우저나 파일에서 토큰을 보게 되더라도, 그것을 응답이나 LLM Wiki에 남기면 안 됩니다.

---

20. 운영자가 볼 수 있는 품질 신호

Slogs에는 관리자용 LLM Wiki MCP 품질 지표도 있습니다. 이 지표는 사용자의 기억 내용 원문을 저장하는 것이 아니라, metadata-only audit row를 기반으로 품질을 봅니다.

예를 들어 다음 신호를 볼 수 있습니다.

• 최근 MCP 호출 수
• recall/search 호출 수
• valid-result rate
• empty-result rate
• repeated-query rate
• 평균 응답 시간
• p95 응답 시간
• slow call 수
• mutation call 비율
• tool별 breakdown

이 지표는 “LLM Wiki가 실제로 도움이 되는가?”를 판단하는 데 유용합니다. 검색이 자주 빈 결과를 내거나, 반복 query가 많거나, 특정 도구가 느리다면 query 설계, categoryPath, 인덱싱, Agent 정책을 조정해야 합니다.

---

21. 좋은 LLM Wiki 운영 습관

마지막으로, Slogs LLM Wiki를 오래 쓰기 위한 습관을 정리합니다.

1. 작업 시작 전에 기억을 먼저 본다

프로젝트 맥락이 조금이라도 중요하면 먼저 조회합니다. 특히 배포, 사용자 선호, 반복 워크플로, 이전 오류는 기억을 먼저 보는 것이 안전합니다.

2. 저장은 적게, 하지만 중요한 것은 놓치지 않는다

모든 로그를 저장하지 않습니다. 대신 “다음 Agent가 이것을 몰라서 실수할 수 있는가?”를 기준으로 봅니다.

3. categoryPath를 성의 있게 정한다

나중에 검색 품질은 categoryPath의 영향을 많이 받습니다. misc에 넣는 순간 미래의 검색 비용이 커집니다.

4. merge/update를 두려워하지 않는다

좋은 Wiki는 항목 수가 많은 Wiki가 아니라, 같은 주제의 기억이 잘 통합된 Wiki입니다.

5. Raw Provenance를 확인한다

중요한 판단에는 원문 근거를 확인합니다. 기억은 요약될 수 있지만, 출처는 보존되어야 합니다.

6. Retrieval Diagnostics를 읽는다

검색 결과가 나왔다는 사실만으로 충분하지 않습니다. 결과 수, 관련도, elapsedMs, limit, categoryPath를 보고 검색이 건강한지 확인합니다.

7. Agent 정책을 최신으로 유지한다

프롬프트 전체를 매번 다시 붙여넣을 필요는 없습니다. version URL을 확인하고, 버전이 바뀌었을 때만 갱신합니다.

---

22. 빠른 시작 요약

처음 사용하는 사람은 아래 순서만 따라도 됩니다.

1. Slogs에 로그인합니다.
2. /me/settings에서 Slogs MCP 토큰을 생성합니다.
3. /me/llm-wiki에서 한국어 Agent 프롬프트를 복사합니다.
4. 사용하는 Agent의 전역 또는 프로젝트 지침에 프롬프트를 적용합니다.
5. MCP 설정에 https://slogs.dev/mcp와 Bearer 토큰을 등록합니다.
6. 새 세션에서 llm_wiki_* 도구가 보이는지 확인합니다.
7. Agent에게 “이전 결정이나 프로젝트 맥락이 관련되면 Slogs LLM Wiki를 먼저 조회해”라고 지시합니다.
8. Slogs 화면에서는 /me/llm-wiki/search에서 저장된 기억을 검색합니다.
9. 기억을 저장할 때는 먼저 관련 항목을 찾고, 중복이면 merge/update합니다.
10. 민감 정보와 임시 로그는 저장하지 않습니다.

---

마무리

Slogs LLM Wiki는 “AI가 알아서 다 기억한다”는 막연한 기능이 아닙니다. 오히려 반대에 가깝습니다. 무엇을 기억해야 하고, 무엇을 저장하지 말아야 하며, 저장된 기억이 어떤 원문 근거를 갖는지 명확히 관리하려는 도구입니다.

Agent를 오래 쓰다 보면 중요한 것은 모델의 순간적인 답변 능력만이 아닙니다. 반복되는 프로젝트 맥락, 사용자의 판단 기준, 검증된 운영 절차, 정정된 용어를 얼마나 일관되게 이어가느냐가 실제 작업 품질을 좌우합니다.

Slogs LLM Wiki는 그 일관성을 만들기 위한 개인 지식 기반입니다. 사람은 Slogs 화면에서 검색하고 검토할 수 있고, Agent는 MCP 도구를 통해 필요한 기억을 조회하고 저장할 수 있습니다. 이 둘이 함께 동작할 때, Slogs는 단순한 블로그를 넘어 Agent와 함께 쓰는 작업 기억 시스템이 됩니다.