연결됨 다시 연결 중 다시 연결 연결 실패 연결 일시 중지 복구 실패
LLM Wiki는 메모장이 아니라 Agent의 작업 기억이다 대표 이미지
공개 지식 로그 출처 @dimohy 리비전 v2 3개 관련 로그 2개 이전/다음 로그 0개 댓글

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

공개 로그
@dimohy 팔로우 0개 2026.06.27 11 분 67 조회관계 잇기수정 2026.06.27 15:07

로그 요약

본문과 댓글은 @dimohy의 #llm wiki 태그, Slogs LLM Wiki 시리즈, 리비전 v2, 2개 이전/다음 로그에 이어진 지식 로그입니다.

주요 태그 #llm wiki 로그 시리즈 Slogs LLM Wiki 리비전 v2 3개 관련 로그 2개 이전/다음 로그

Slogs LLM Wiki가 단순 메모장이 아니라 Agent가 조회, 판단, 저장을 반복하는 작업 기억 계층으로 동작하는 방식을 정리합니다.

LLM Wiki Agent memory flow

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도 중요하다. 읽기 좋은 통합 기억은 필요하지만, 처음 어떤 요청에서 나온 결정인지도 남아 있어야 한다. 그래야 나중에 검색 품질이나 병합 품질을 점검할 수 있다.

운영 체크리스트

Agent 기억 서버를 만들 때는 기능보다 운영 규칙을 먼저 정해야 한다.

  • 조회와 저장 도구를 분리한다.
  • 저장 전 관련 기억 탐색을 강제한다.
  • 민감 정보, API 키, 토큰, 일회성 로그는 저장하지 않는다.
  • categoryPath를 필수에 가깝게 사용한다.
  • 검색 결과의 품질 진단값을 확인한다.
  • 기억을 사용하지 못했으면 사용했다고 말하지 않는다.

이 규칙들이 있어야 LLM Wiki가 “많이 저장된 메모장”이 아니라 Agent의 작업 기억으로 동작한다.

참고 링크

0 대화 흔적

이전 로그

공개 로그로그 시리즈: slogs 사용 가이드5 태그 0 대화 흔적 0 공감

정보 경로: @dimohy -> #slogs -> 시리즈 slogs 사용 가이드 -> 0 대화 흔적 / 0 공감

Slogs LLM Wiki 사용법 완전 가이드

Slogs LLM Wiki를 UI와 MCP Agent 양쪽에서 사용하는 방법을 설치, 검색, 회상, 저장, 병합, Raw Provenance, categoryPath, 검색 품질 점검까지 스크린샷과 함께 정리하였습니다.

@dimohy

대화 흔적 (0)

이 로그에 댓글을 남기려면 지식 로그 홈으로 돌아가야 합니다. 지식 로그로 돌아가기

아직 이어진 댓글이 없습니다. 첫 댓글을 남겨 보세요.

지식 로그 연결이 잠시 끊겼습니다. 다시 연결 ×