매일 다양한 AI 에이전트 (AI agents)를 운영하는 사람으로서, 저는 항상 똑같은 벽에 부딪혔습니다. 모든 새로운 대화가 완전히 메모리가 삭제된 상태로 시작된다는 점이었습니다. 어제 논의했던 프로젝트에 대해 에이전트에게 물어보면, 제가 무슨 말을 하는지 전혀 알지 못했습니다. 정말 답답한 일이었습니다.

물론 각 프롬프트 (prompt)에 수동으로 컨텍스트 (context)를 입력하거나, 각 에이전트 프레임워크 (agent framework)를 위한 맞춤형 플러그인을 구축할 수도 있습니다. 하지만 이는 취약하며 확장성이 떨어집니다. 저에게는 Hermes, Claude Code, 심지어 제가 직접 만든 커스텀 스크립트 (custom scripts)까지, 에이전트의 내부 구조를 침해하는 수술 없이도 모든 에이전트에서 작동하는 무언가가 필요했습니다.

그것이 바로 제가 Memory Sidecar를 구축한 이유입니다.

핵심 아이디어

에이전트와 함께 실행되는 사이드카 (sidecar) 프로세스입니다. 이 프로세스는 대화를 모니터링하고, 중요한 내용을 추출하며, 장기 기억 구조를 구축합니다. 에이전트에게 컨텍스트가 필요할 때, 사이드카는 시스템 프롬프트 (system prompt)에 관련 정보를 주입합니다. 이 모든 과정은 에이전트를 패치 (patching)하거나 내부 구조를 재작성하지 않고 이루어집니다.

작동 방식

에이전트는 세션 (sessions)을 데이터 디렉토리(state.db + 일반 텍스트 파일)에 기록합니다. 사이드카는 주기적으로 새로운 데이터를 확인하고, 이를 처리하며, 세 가지 메모리 계층 (memory layers)을 업데이트합니다:

• Hot layer (핫 레이어): 가장 최근의 상호작용을 보유하는 빠르고 일시적인 버퍼 (5KB 제한)입니다. 에이전트의 단기 기억 (short-term memory)과 같습니다.
• Warm layer (웜 레이어): 의미론적 유사성 (semantic similarity)을 위해 Hindsight를 사용하는 PostgreSQL 기반 저장소입니다.

Memory Sidecar는 단순한 프로토타입이 아닙니다. 신뢰성을 위해 구축된 버전 3.1.1 단계에 와 있습니다. 체크포인팅 (checkpointing) 기능을 통해 세션을 중복 처리하는 일이 없도록 보장합니다. 3계층 아키텍처 (three-tier architecture)를 통해 지연 시간 (latency)과 회상 깊이 (recall depth) 사이에서 항상 적절한 절충안을 가질 수 있습니다.

별도의 프로세스이기 때문에, 메모리를 잃지 않고도 에이전트를 재시작할 수 있습니다. 또한 워밍 레이어 (warm layer)를 독립적으로 확장하거나, 콜드 그래프 (cold graph)를 더 큰 머신에 호스팅하거나, 필요에 따라 구성 요소를 교체할 수도 있습니다.

시작하기

Python 3.9 이상 버전과 세션을 디렉토리에 기록하는 실행 중인 에이전트가 필요합니다. 저장소 (repo)를 클론하고, 의존성 (dependencies)을 설치한 다음, 해당 디렉토리를 감시하도록 사이드카 (sidecar)를 설정하세요. 프로젝트에는 즉시 사용 가능한 러너 스크립트 (runner script)가 포함되어 있습니다.

정확한 설정 방법은 문서를 확인하십시오. 하지만 핵심은 이렇습니다: 사이드카를 에이전트의 출력 디렉토리로 지정하기만 하면 즉시 메모리 구축을 시작합니다. 몇 번의 상호작용 내에 에이전트의 회상 (recall) 능력이 향상되는 것을 볼 수 있을 것입니다.

대상 사용자 (및 대상이 아닌 경우)

매일의 워크플로에서 에이전트를 실행하며 반복적인 작업에 지쳤다면, 이 도구가 시간을 절약해 줄 것입니다. 특히 개인 비서, 코딩 에이전트, 그리고 에이전트가 프로젝트, 선호도 또는 과거의 결정을 기억해야 하는 모든 시나리오에서 유용합니다.

지연 시간이 전혀 없는 응답이 필요하거나 메모리가 극도로 제한된 장치에서 실행하는 경우라면 적합하지 않습니다. 사이드카 자체는 가볍지만, 검색 (retrieval) 과정에서 추론 (inference)에 몇 밀리초 (milliseconds)가 추가됩니다.

결론

에이전트에게 메모리를 부여한다고 해서 반드시 내부 구조를 뜯어고쳐야 하는 것은 아닙니다. 사이드카 접근 방식은 확장 가능하며 다양한 에이전트에 걸쳐 작동합니다. Memory Sidecar는 제 에이전트들에게 지속적인 지식 베이스 (knowledge base)를 제공해주었으며, 저는 몇 달 동안 매일 사용하고 있습니다.

동일한 문제를 해결하고자 한다면 한 번 시도해 보세요. 저장소를 확인하십시오: Memory Sidecar on GitHub

추신 — 아키텍처에 대한 상세한 분석을 포함하여 전체적인 아키텍처 구조가 저장소에 잘 문서화되어 있습니다. 코드를 파고들기 전에 해당 내용을 가볍게 훑어보는 것을 권장합니다.