안녕하세요
클리앙 구독자 분이 “장기 기억(Long-term Memory)은 어떻게 운영하나요?” 질문을 주셨습니다.
실제로 AI 멀티 에이전트를 운영해보면,
단순히 에이전트를 연결하는 것보다 더 어려운 건 “같은 실수를 반복하지 않게 만드는 것”이었습니다.
에이전트도 결국 매번 새 context로 시작하면 생산성이 계속 초기화되더군요.
그래서 저는 워크플로우에 LLM Wiki 기반의 장기 기억 시스템을 연결했습니다.
Research → Architecture → Design → Engineering → Review 과정에서 나온:
- 설계 결정
- 실패 사례
- 재사용 가능한 패턴
- 효과적인 context
- 리뷰 피드백과 교훈
을 모두 Wiki 형태로 축적합니다.
중요한 건 단순 로그 저장이 아니라,
“왜 그렇게 했는지”까지 남긴다는 점입니다.
예를 들어:
- 왜 이 구조를 선택했는지
- 어떤 접근이 실패했는지
- 어떤 패턴이 반복적으로 효과 있었는지
- 어떤 프롬프트/context가 성능이 좋았는지
같은 내용을 Collective Memory(집단 기억) 형태로 누적합니다.
이렇게 쌓인 기억이 다음 작업의 context로 다시 들어가면서:
- 반복 작업 감소
- context 이해 속도 증가
- 설계 품질 향상
- 실패 재발 방지
- 에이전트 협업 최적화
효과가 꽤 크게 나타났습니다.
점점 느끼는 건,
AI 워크플로우의 핵심은 단순 자동화가 아니라 “기억이 누적되는 시스템”이라는 점입니다.
에이전트 수를 늘리는 것보다,
경험과 판단이 축적되는 구조를 만드는 게 훨씬 중요하다고 생각합니다.
조만간에 AI 멀티에이전트에 LLM Wiki를 붙여서 전자책 업데이트 해볼게요~
감사합니다.
클로드 코드(Claude Code) 멀티에이전트 팀 자동화 완전 가이드 : AI 개발팀 구성부터 Remote-Control 실전까지
https://wikidocs.net/book/19736
좋은 내용을 무료로 풀어주셔서 정말 감사해요!!
추가해주시면 또 따라서 해보겠습니다. ㅎ
쉽게 말하면, “한 사람이 다 하느냐” 아니면 “여러 사람이 역할을 나눠 팀으로 움직이느냐”의 차이입니다.
모든 AI가 모든 정보를 다 들고 있는 게 아니라 “자기 역할에 필요한 기억만 사용”하게 되는 구조입니다.
그래서 토큰 사용량, 판단 혼선, 실수 반복이 줄고 전체 워크플로우 효율이 훨씬 좋아집니다.
아래 블로그에 LLM Wiki와 RAG 차이를 정리하였으니 한번 봐보세요.
https://wikidocs.net/blog/@Allen/14001/
정말 감사합니다
그런식으로 Wiki를 축적 시키면 실수야 반복 안 할 거 같긴한데..
점점 Wiki가 쌓이고 크기가 커지면 어떻게 할까요?
너무 context가 커져서 토큰이 부담스러워질 것 같은데
속도 비용 등에 문제가 발생하지는 않을까요?
그림 기준으로 보면:
LLM Wiki ↔ 쭌(Context Manager)
사이가 사실상
Retrieval
Context Engineering
Relevance Filtering
레이어 역할입니다.
즉 쭌이:
현재 작업과 관련된 memory만 검색하고 필요한 내용만 압축·정리해서 context bundle 형태로 다음 에이전트에 전달합니다.
그래서 Wiki는 계속 커져도, 실제 LLM이 읽는 Context는 작게 유지할 수 있어 속도·비용·토큰 문제를 상당히 줄일 수 있습니다.
예시:
grep -R "redis timeout" failures/
grep -R "retry policy" decisions/
grep -R "queue worker" implementation/
그러면:
failures/redis-timeout-incident.md
decisions/retry-policy.md
implementation/queue-worker-pattern.md
같은 관련 문서만 추출됩니다.
그 다음 쭌이:
중복 제거
핵심 요약
relevance 정렬
을 해서 “context bundle”로 만들어 다음 에이전트에게 전달하는 흐름입니다.
즉 핵심은:
“Wiki 전체를 읽는 게 아니라, 현재 작업과 관련된 memory만 검색해서 주입” 하는 구조입니다.