포터블 에이전트 메모리: Claude Code, Cursor, Codex, Gemini 전반에 걸쳐 컨텍스트 유지하기

프로젝트 중간에 Claude Code에서 Cursor로 전환하면 에이전트는 모든 것을 잊어버립니다: 지난주에 내린 아키텍처 결정, 이미 수정한 버그, 커밋 작성 방식까지. 컨텍스트는 이동하지 않고 첫 번째 도구 안에 갇혀 있습니다. **포터블 에이전트 메모리(Portable Agent Memory)**는 이 문제를 해결하는 패턴입니다: 에이전트들이 공유하는 하나의 메모리 레이어로, 도구를 전환할 때마다 처음부터 다시 시작하는 대신 Claude Code, Cursor, Codex, Gemini CLI 전반에 걸쳐 컨텍스트가 따라옵니다.

이 가이드는 포터블 에이전트 메모리가 무엇인지, 이를 구축하는 주요 접근 방식, 트레이드오프, 그리고 다시 벤더 종속에 빠지지 않는 방법을 설명합니다.

포터블 에이전트 메모리란?

포터블 에이전트 메모리는 결정 사항, 수정 내역, 컨벤션, 사실 등 지속적인 프로젝트 컨텍스트를 저장하는 공간으로, 특정 에이전트 외부에 존재하며 모든 에이전트가 읽을 수 있습니다. 각 도구가 자체적인 사일로화된 노트를 유지하는 대신, 에이전트들이 공유 풀에서 읽고 씁니다.

이것이 해결하는 문제는 벤더 종속입니다. 내장 메모리는 컨텍스트를 하나의 코딩 에이전트에 묶어두고, 도구를 전환하면 그 자리에 남겨집니다. 훌륭한 CLAUDE.md는 Cursor에서 아무 소용이 없고, Cursor의 노트패드는 Codex에서 아무 소용이 없습니다. 대부분의 팀이 이제 하나 이상의 에이전트를 사용하므로, 고립된 컨텍스트는 실제로 반복되는 비용입니다.

이식성은 두 가지를 의미합니다:

• 크로스 도구: 동일한 메모리가 Claude Code, Codex, Cursor, Gemini CLI, 그리고 읽을 수 있는 모든 도구에서 작동합니다.
• 벤더 종속 없음: 지식을 재구축하지 않고도 도구 — 또는 메모리 레이어 자체 — 를 떠날 수 있습니다.

전환 시 컨텍스트가 고립되는 이유

각 에이전트는 자체 형식과 위치에 메모리를 저장합니다. Claude Code는 하나의 메모리 시스템을 가지고, Cursor는 다른 시스템을 가집니다. 서로 다른 에이전트가 서로 다른 것을 알고 있으면, 다음 세션에서 이미 답한 질문을 다시 묻거나 이전에 했던 실수를 반복합니다.

근본적인 문제는 도구별 플랫 메모리가 에이전트 전반에 걸쳐 확장되지 않는다는 것입니다. 하나의 클라이언트를 위해 작성된 노트는 다음 클라이언트에게 보이지 않습니다. 모든 도구 전환, 모든 새 채팅 창, 다른 설정을 사용하는 모든 팀원에 걸쳐 이를 곱하면, 동일한 컨텍스트가 반복해서 재구축됩니다.

포터블 메모리의 주요 접근 방식

오늘날 사용되는 세 가지 광범위한 패턴이 있습니다. 이들은 주로 컨텍스트를 저장하는 방식과 에이전트에 연결하는 방식에서 차이가 납니다.

1. MCP 기반 메모리 서버

가장 일반적인 접근 방식은 Model Context Protocol (MCP)을 통해 모든 에이전트에 메모리 서버를 연결합니다. MCP는 모든 도구가 모든 에이전트에 연결하는 표준 방법을 제공하므로, 하나의 메모리 레이어가 동일한 프로토콜을 통해 여러 클라이언트를 지원할 수 있습니다.

agentmemory와 Memorix 같은 오픈소스 프로젝트가 이 방식을 택합니다. agentmemory는 Claude Code, Cursor, Gemini CLI, Codex CLI, 그리고 모든 MCP 클라이언트를 위한 지속적 메모리로 자신을 설명하며, 전역으로 설치되고 MCP 서버로 등록됩니다. Memorix는 하나의 채팅 창이나 도구 내부가 아닌 Git 프로젝트 아래에 프로젝트 메모리를 유지하는 로컬 우선 공유 메모리 레이어입니다.

장점: 한 번 설정하면 MCP를 지원하는 모든 에이전트가 동일한 메모리를 볼 수 있습니다. 트레이드오프는 실행 중인 서비스와 각 클라이언트의 MCP 지원에 대한 의존성입니다.

2. 플랫 파일, 벤더 중립 볼트

더 가벼운 접근 방식은 데이터베이스와 서버를 완전히 건너뜁니다. Agent Memory OS는 데이터베이스 없이, 실행할 서비스 없이 일반 Markdown 파일과 몇 가지 소규모 스크립트로 구축된 포터블 메모리 시스템입니다. Claude Code, Codex, Gemini CLI, Cursor, 또는 파일을 읽을 수 있는 모든 것과 함께 작동하며, 도구를 전환해도 설정을 재구축할 필요가 없도록 의도적으로 벤더 중립적인 아이덴티티 파일을 유지합니다.

여기서 검색은 일반적으로 임베딩이 아닌 어휘적(lexical) 방식입니다 — 라우터가 쿼리에 대해 Markdown 노트를 순위 매기고 가장 관련성 높은 몇 가지를 반환합니다. 장점은 단순성, 이식성, 그리고 인프라 비용 없음입니다. 트레이드오프는 대규모 지식 베이스에서 벡터 기반 시스템보다 덜 정교한 검색입니다.

3. 호스팅 / 프로토콜 기반 메모리 레이어

세 번째 그룹은 암호화, 검증 가능한 스토리지, SDK 같은 기능을 갖춘 관리형 메모리를 제공합니다. 이들은 에이전트가 연결하는 내구성 있고 이식 가능한 레이어를 목표로 하며, 종종 SDK와 MCP 통합을 모두 제공하여 앱과 세션 전반에 걸쳐 컨텍스트가 이동합니다.

장점은 운영 작업 감소와 더 많은 내장 기능입니다; 트레이드오프는 외부 서비스에 컨텍스트를 신뢰하고 새로운 종류의 종속 — 이번에는 메모리 레이어 자체에서 — 을 주의해야 한다는 것입니다.

선택 방법 — 그리고 다시 종속되지 않는 방법

이식성의 요점은 전환의 자유입니다. 그 자유를 유지하세요:

• 개방형 형식을 선호하세요. Markdown 볼트와 문서화된 스키마는 읽고, 마이그레이션하고, 검사하기 쉽습니다. 독점 형식은 그렇지 않습니다.
• 내보내기 경로를 유지하세요. 무엇을 채택하든, 메모리를 내보내고 다른 곳으로 이동할 수 있는지 확인하세요.
• 메모리를 도구가 아닌 프로젝트에 범위를 지정하세요. Git 프로젝트 아래에 있는 메모리는 저장소와 함께 이동하며 도구 전환, IDE 변경, 새 채팅 창에서도 살아남습니다.
• "세 번째 시도" 규칙을 신호로 취급하세요. 에이전트가 세 번째로 같은 실수를 하면, 그것은 나쁜 모델이 아니라 누락된 메모리 노트입니다. 반복되는 결정과 수정 사항을 지속적인 메모리에 흡수하세요.
• 비밀을 저장하지 마세요. 비밀이 어디에 있고 어떻게 사용되는지 기록하되 — 값 자체는 절대 저장하지 마세요.

옵션을 비교하는 빠른 방법:

앞으로의 방향

포터블 메모리는 새로운 기능이 아닌 기본 기대치로 빠르게 자리잡고 있습니다. 팀이 여러 에이전트를 나란히 실행하면서 — 터미널 작업용 하나, IDE용 하나, 스크립트용 하나 — 메모리 레이어는 버전 관리처럼 공유 인프라로 변모하고 있습니다. 승자는 개방적이고, 이식 가능하며, 떠나기 쉬운 레이어가 될 것입니다.

기억하는 멀티 에이전트 워크플로우 구축하기

포터블 메모리는 여러 에이전트를 동시에 실행할 때 가장 중요합니다 — 이것이 바로 멀티 에이전트 워크포스가 하는 일입니다. Eigent는 실제 워크플로우에서 AI 에이전트 팀을 조율하는 오픈소스 로컬 "Cowork" 데스크톱 앱입니다. 사용자, 워크스페이스, 또는 세션에 범위를 지정할 수 있는 메모리와 지속적인 멀티턴 실행을 추가하여, 보존할 가치가 있는 컨텍스트가 고립되는 대신 의도적으로 전달됩니다. 도구를 전환할 때마다 프로젝트를 다시 설명하는 것에 지쳤다면, Eigent를 다운로드하고 에이전트에게 기억할 수 있는 공유 공간을 제공하세요.