AI 에이전트의 내부 구조를 건드리지 않고 지속성 메모리 부여하기

우리 모두 그런 경험이 있습니다. AI 코딩 어시스턴트(AI coding assistant)와 작업하며 프로젝트의 아키텍처, 선호하는 패턴, 레거시 모듈의 특이사항 등을 학습시키는 훌륭한 대화를 나누고 있다고 가정해 봅시다. 그러다 세션을 종료하고 새로운 세션을 열면, 마치 한 번도 만난 적이 없는 것처럼 느껴집니다. 매번. 매번. 백지 상태가 됩니다.

물론 매번 프롬프트(prompt)에 컨텍스트(context)를 붙여넣을 수도 있지만, 이는 수동적이고 오류가 발생하기 쉬우며 토큰 예산(token budget)을 엄청나게 소모합니다. 어떤 이들은 파인튜닝(fine-tune)을 하지만, 이는 비용이 많이 들고 업데이트 속도가 느립니다. 다른 이들은 RAG 파이프라인(RAG pipelines)에 의존하지만, 이는 설정이 복잡하고 정작 필요한 순간에 가장 관련성 높은 컨텍스트를 불러오는 데 실패하는 경우가 많습니다.

제가 원했던 것은 간단했습니다: 에이전트의 코드를 패치하거나 워크플로우(workflow)를 재설계할 필요 없이, 에이전트 옆에 위치하여 모든 대화로부터 학습하고 중요한 내용을 자동으로 다시 피드백해 주는 메모리 시스템입니다.

그렇기에 저는 정확히 이 역할을 수행하는 오픈 소스 프로젝트인 Memory Sidecar (v3.1.0)를 사용하고 기여해 왔습니다.

작동 방식 요약

Memory Sidecar는 Claude Code, Cursor, Hermes 또는 세션 로그를 작성하는 모든 AI 도구와 같은 에이전트와 병렬로 실행되는 별도의 프로세스로 작동합니다. 이 시스템은 공유 데이터 디렉터리를 감시하고, 새로운 세션 콘텐츠를 포착하여 다음과 같은 3단계 메모리 아키텍처(memory architecture)를 통해 처리합니다:

Hot Layer (핫 레이어): 즉각적인 대화 컨텍스트를 유지하는 작고 빠른 메모리 버퍼(5KB 제한)입니다. 이는 단기 회상(short-term recall)을 위해 에이전트의 시스템 프롬프트(system prompt)에 주입됩니다.
Warm Layer (웜 레이어): 중기 검색(mid-term retrieval)을 위해 세션 데이터를 아카이브하고 인덱싱하는 Hindsight PostgreSQL 저장소입니다. 어제 우리가 논의했던 내용을 기억하는 데 매우 유용합니다.
Cold Layer (콜드 레이어): 중요한 엔티티(사람, 프로젝트, 반복되는 이슈 등)를 기반으로 구축된 지식 그래프(knowledge graph)와 FTS5를 사용한 전체 텍스트 검색(full-text search)의 결합입니다. 이는 몇 주 전의 관련 정보를 불러오는 장기 메모리(long-term memory) 역할을 합니다.

에이전트가 컨텍스트(context)가 필요할 때(또는 새로운 세션이 시작될 때), 사이드카(sidecar)는 계층적 컨텍스트 주입(tiered context injection)을 구성합니다. 즉, 최근의 핫 데이터(hot data), 관련 있는 웜 스니펫(warm snippets), 그리고 콜드 그래프 회상(cold graph recalls)을 결합하여, 에이전트가 정보 과부하 없이 필요한 정보를 계속 파악할 수 있도록 프롬프트(prompt)에 맞게 조정하여 제공합니다.

이 접근 방식이 승리하는 이유

저는 에이전트를 위한 여러 메모리 솔루션을 시도해 보았으며, 대부분은 두 가지 부류로 나뉩니다: "에이전트에 임베딩하기" (깊은 수정이 필요하며 취약함) 또는 "외부 RAG" (무거운 인프라가 필요하며 지속적인 튜닝이 필요함). 메모리 사이드카(Memory Sidecar)는 이 중 어느 쪽도 아닙니다. 이것은 말 그대로 **사이드카(sidecar)**입니다:

에이전트 수정 제로 (Zero agent modifications) — 에이전트가 작성하는 것(세션 로그, state.db)을 읽고, 공유 프롬프트 파일에 컨텍스트를 다시 씁니다. 에이전트는 사이드카의 존재를 전혀 알지 못합니다.
모든 에이전트와 호환 (Works with any agent) — 에이전트가 로그나 상태 파일(state file)을 생성하기만 하면 사이드카가 이를 소비할 수 있습니다. 기본적으로 Claude Code, Cursor, 그리고 커스텀 스크립트를 지원합니다.
낮은 오버헤드 (Low overhead) — 최소한의 의존성을 가진 Python(3.9+) 프로세스입니다. 제 개발 머신에서 실행 중인데 CPU 점유율이 거의 느껴지지 않습니다.
개인정보 보호 우선 (Privacy-first) — 모든 데이터는 로컬에 머뭅니다. 클라우드 호출이 없으며, 메모리 레이어 자체를 위한 API 키도 필요하지 않습니다.

이를 통해 얻는 이점

며칠간 사용해 본 결과, 저의 코딩 어시스턴트는 제 프로젝트를 이해하고 있습니다. 제가 리팩터링(refactoring) 중인 모듈, 선호하는 테스트 프레임워크, 우리가 디버깅하던 이슈를 기억합니다. 이제 매 세션이 시작될 때마다 "parser.py에 있던 그 버그 기억해?"라고 반복할 필요가 없습니다. 회상(recall)이 완벽하지는 않습니다. 최선을 다한 검색(best-effort retrieval) 수준이지만, 특히 최근 작업에 대해 가장 관련성 높은 조각들을 찾아내는 능력이 놀라울 정도로 뛰어납니다.

제가 높게 평가하는 세부 사항 중 하나는 도시에(dossier) 트래킹입니다. 제가 특정 인물의 이름이나 프로젝트 코드명을 자주 언급하면, 사이드카는 이를 중심으로 도시에를 구축하기 시작합니다. 나중에 제가 에이전트에게 그 사람이나 프로젝트에 대해 물어보면, 에이전트는 단순한 원문 텍스트 스니펫이 아니라 구조화된 지식(structured knowledge)을 준비한 상태로 답변합니다.

이것이 필요하지 않을 수도 있는 경우

워크플로가 단일 세션(Single-session) 방식이거나(매번 새로 시작하며 지속성이 필요하지 않은 경우), 이미 잘 작동하는 커스텀 RAG 파이프라인을 보유하고 있다면 이 방식은 과할 수 있습니다. 또한, 이 기술은 여전히 발전 중입니다. 설치 스크립트는 작동하지만, 설정 옵션들이 아직 모두 문서화되지는 않았습니다(이는 로드맵에 포함되어 있습니다).

하지만 여러 세션에 걸쳐 AI 어시스턴트와 작업하면서 같은 말을 반복하는 것을 싫어한다면, 이것은 실용적이고 군더더기 없는 해결책이 될 것입니다.

시작하기

GitHub 리포지토리를 확인해 보세요. MIT 라이선스이므로 사용, 포크(Fork), 수정이 가능합니다. README에는 설치 지침과 빠른 시작(Quick start) 가이드가 포함되어 있습니다. 내부 구조를 이해하고 싶다면 아키텍처 문서(Architecture doc)도 있습니다.

당신의 AI 에이전트에게 메모리를 부여하세요. 그럴 자격이 있습니다.