AI 에이전트를 위한 프로덕션 메모리: 내부 구조를 수정하지 않고도 에이전트에 지속적인 컨텍스트 제공하기

제가 AI 코딩 에이전트를 재시작할 때마다, 마치 새로운 주니어 개발자를 온보딩(onboarding)하는 것 같은 기분이 듭니다. 에이전트는 프로젝트 아키텍처(architecture), 진행 중인 버그, 또는 우리가 지난주에 내렸던 결정들을 기억하지 못합니다. 프롬프트 엔지니어링 (prompt engineering), 파인튜닝 (fine-tuning), 그리고 커스텀 플러그인 (custom plugins)을 시도해 보았지만, 세션을 넘나드는 지속적이고 구조화된 메모리를 제공해 주는 것은 아무것도 없었습니다.

대부분의 메모리 솔루션은 에이전트의 내부 구조와 깊은 통합을 요구합니다. 에이전트 자체를 패치(patch)해야 하는데, 이는 특정 플랫폼에 종속되게 만들고 업데이트 시 작동이 중단되는 문제를 일으킵니다. 또는 단순한 채팅 기록 덤프 (chat history dumping)에 의존하기도 하는데, 이는 확장성(scale)이 떨어집니다. 저는 Hermes, Claude Code, Cursor, Codex와 같이 어떤 에이전트와도 에이전트를 수정하지 않고 작동할 수 있는 무언가를 원했습니다. 세션을 아카이브(archive)하고, 지식을 구축하며, 필요할 때 관련 컨텍스트 (context)를 주입하는 별도의 프로세스 말입니다. 그렇게 Memory Sidecar가 탄생했습니다.

Memory Sidecar는 에이전트와 함께 사이드카(sidecar)로서 실행됩니다: 별도의 프로세스, 공유 데이터 디렉토리. 이는 아무것도 패치하지 않습니다. 아키텍처는 세 가지 레이어 (layer)를 사용합니다:

• Hot Layer – 최근 컨텍스트 (약 5KB 제한), 지난 몇 차례의 턴(turn) 동안 발생한 일에 대한 빠른 액세스.
• Warm Layer – 세션을 분석하고 구조화된 메모리를 추출하는 PostgreSQL 기반의 사후 분석 (hindsight) 서비스.
• Cold Layer – FTS5 검색 기능이 있는 지식 그래프 (knowledge graph, gbrain)로, 사람, 프로젝트 및 반복되는 문제에 대한 장기적인 지식을 저장.

에이전트가 새로운 세션을 시작하면, 사이드카는 시스템 프롬프트 (system prompt)에 계층화된 컨텍스트를 주입합니다. 이는 최신성과 관련성을 우선시하며 세 가지 레이어 모두에서 정보를 가져옵니다. 에이전트는 기억할 가치가 있는 내용에 대해 압축되었지만 풍부한 요약을 전달받게 됩니다.

최신 릴리스 (v3.1.1)에는 여러 프로덕션 준비 완료 (production-ready) 기능이 추가되었습니다:

• memory_watermark.py — 메모리 사용량이 임계값을 초과할 때 자동으로 감지하여 오래된 데이터를 아카이브(archive)하므로, 컨텍스트 제한(context limits)을 초과하지 않도록 도와줍니다.
• memory_snapshot_backup.py — 메모리 상태에 대한 주기적이고 설정 가능한 백업 기능을 제공합니다.
• hindsight-service.py — 웜 레이어(warm layer)를 위한 단순화된 독립형 데몬(standalone daemon)으로, 복잡한 오케스트레이션(orchestration)이 필요하지 않습니다.
• session_to_gbrain.py — 이제 환경 변수(environment variables)에서 토큰을 읽어옵니다 (더 이상 하드코딩된 설정이 필요하지 않습니다).
• HERMES_ONBOARDING.md — 모든 도구 목록과 예시를 포함하여, 어떤 에이전트든 연결할 수 있는 완전한 통합 가이드를 제공합니다.

사용해야 할 때: 이 설정은 장기 프로젝트를 수행하거나, 사용자 선호도를 기억해야 하거나, 세션 전반에 걸쳐 복잡한 디버깅을 처리해야 하는 에이전트에게 탁월합니다. 에이전트를 재시작할 때마다 같은 말을 반복하는 것에 지쳤다면, 이 시스템은 즉시 사용할 수 있는 실제적이고 지속적인 메모리 레이어(memory layer)를 제공합니다.

사용하지 말아야 할 때: 단일 세션 내에서의 실시간 메모리를 위한 것이 아닙니다 — 그 기능은 에이전트의 내장된 컨텍스트 윈도우(context window)가 처리합니다. 또한 파인튜닝(fine-tuning)을 대체하는 것도 아닙니다; 이는 모델 업데이트가 아니라 캐싱(caching) 및 검색(retrieval) 레이어입니다.

저는 몇 주 동안 이것을 실행해 왔으며, 그 차이는 극명합니다. 이제 제 에이전트는 프로젝트의 예외 패턴, 우리가 사용하는 API 키, 그리고 세 번 전 세션에서 설정한 선호도를 기억합니다. 더 이상 컨텍스트를 반복할 필요가 없습니다. 모든 것을 다시 설명해야 하는 정신적 부담도 사라졌습니다.

이 프로젝트는 오픈 소스(MIT)이며 여기서 찾을 수 있습니다: Memory Sidecar on GitHub. 세션 전반에 걸쳐 작동해야 하는 에이전트를 구축하고 있다면, 한 번 시도해 보세요. 정말 잘 작동한다는 것을 알게 될 것입니다.