Anthropic의 Claude Managed Agents 가이드, 메모리를 둘로 분할하다 — 사용자가 쓰는 저장소와 에이전트가 쓰는 저장소 (2026)

가이드는 익숙한 문제에서 출발합니다. Anthropic은 자동화가 "아무도 모르게 소스에 대한 액세스 권한을 잃거나 우리의 선호도를 따르지 못할 수 있다"고 설명합니다. 이 문장의 두 부분 모두 본질적으로는 메모리 문제입니다.

메모리가 필요한 이유는 "각 실행이 이전 실행의 메모리가 없는 신선한 샌드박스에서 시작되기 때문"입니다. 가이드는 그 결과에 대해 다음과 같이 직설적으로 말합니다. "메모리가 없으면 피드백이 유지되지 않습니다." 하지만 반대의 위험에 대해서도 똑같이 경고합니다. "오래된 메모리는 에이전트를 혼란스럽게 만들 수 있습니다." 예를 들어, 오래된 노트를 가진 에이전트는 이미 해결된 항목을 여전히 대기 중인 것으로 보고하거나, 이미 보고했다고 믿고 열려 있는 항목을 누락할 수 있습니다.

참조 구현체는 /mnt/memory/ 아래에 마운트된 두 개의 저장소로 이 문제를 해결합니다.

첫 번째는 선호도(preferences)로, "사용자의 것이며 에이전트에게는 읽기 전용"으로 설명됩니다. 여기에는 "어떤 채널과 리포지토리를 읽을지, 무엇을 제외할지, 길이 제한, 대상, 그리고 언제 중지할지"가 포함됩니다.

두 번째는 상태(state)로, "에이전트의 것이며 읽기/쓰기가 가능"하다고 설명됩니다. 여기에는 "북마크, 보고한 내용의 원장(ledger, 실행당 하나의 레코드), 사용자의 선호도에 대해 제안하는 변경 사항, 각 소스의 작동 방식에 대한 노트"가 포함됩니다.

이 두 목록을 나란히 읽어보면 논리가 명확해집니다. 첫 번째 저장소의 모든 것은 사용자가 내린 결정입니다. 두 번째 저장소의 모든 것은 에이전트가 관찰하거나 수행한 작업입니다. 에이전트는 사용자의 선호도에 대한 변경 사항을 제안할 수 있지만, 그 제안은 에이전트 자체의 저장소에 저장됩니다. 사용자의 규칙은 사용자가 직접 변경할 때만 변경됩니다.

읽기 전용 경계가 중요한 이유

Anthropic의 메모리 문서에서는 이 분할이 방지하고자 하는 위험을 설명합니다. "메모리 저장소는 기본적으로 read_write 권한으로 연결됩니다." 그런 다음 다른 사람의 텍스트를 읽는 에이전트에게 이 기본값이 무엇을 의미하는지 명시합니다. "에이전트가 신뢰할 수 없는 입력(사용자가 제공한 프롬프트, 가져온 웹 콘텐츠 또는 타사 도구 출력)을 처리하는 경우, 프롬프트 인젝션이 성공하면 저장소에 악성 콘텐츠를 쓸 수 있습니다. 이후 세션에서는 해당 콘텐츠를 신뢰할 수 있는 메모리로 읽게 됩니다."

이에 따라 다음과 같은 권장 사항이 이어집니다. "참조 자료, 공유 조회 테이블 및 에이전트가 수정할 필요가 없는 모든 저장소에는 read_only를 사용하세요." 그리고 이는 모델이 준수하도록 요청하는 단순한 규칙이 아닙니다. "access 권한은 파일 시스템 수준에서 강제됩니다. read_only 마운트는 쓰기 요청을 거부합니다."

자동화 가이드는 이를 정확히 적용합니다. 이 에이전트는 다른 사람들이 작성한 Slack 메시지와 GitHub 이슈를 읽으며, 가이드는 "그 텍스트가 지시 사항으로 해석될 수 있음"을 인정합니다. 따라서 "GitHub 토큰과 선호도 저장소는 읽기 전용이며, 환경은 허용 목록(allowlist)에 있는 호스트에만 도달할 수 있습니다." 가이드는 이것이 무엇을 보호하고 무엇을 보호하지 못하는지에 대해 솔직하게 밝힙니다. "심어진 지시 사항은 실행 사이에 에이전트가 유지하는 노트를 통해서를 포함하여 요약본의 내용을 여전히 변경할 수 있습니다. 하지만 GitHub에 글을 쓰거나 사용자의 규칙을 편집할 수는 없습니다."

이 마지막 문장이 전체 논쟁의 축소판입니다. 에이전트 자체의 노트는 에이전트가 읽는 내용에 노출되므로 틀릴 수 있습니다. 하지만 사용자의 규칙은 에이전트가 쓸 수 없는 저장소에 있으므로 안전하게 유지됩니다.

선호도 복사본이 포인터보다 나쁜 이유

가이드는 두 번째로, 잘 드러나지 않는 실패 사례를 언급합니다. "흔히 발생하는 문제는 선호도의 복사본이 프롬프트에 내장되어(baked), 이미 변경한 규칙을 계속 적용하는 경우입니다." 해결책은 매번 소스를 새로 읽는 것입니다. "에이전트가 매 실행마다 파일을 새로 읽도록 하세요. 파일을 읽을 수 없다면 기본값으로 실행하는 대신 실행을 중단하고 그 사실을 알려야 합니다."

이는 Managed Agents뿐만 아니라 메모리에 대한 일반적인 교훈입니다. 시스템 프롬프트, 붙여넣은 브리핑, 캐시된 요약 등 선호도의 복사본은 생성되는 순간부터 노후화되기 시작합니다. 가이드의 해답은 매 실행 시작 시 읽는 단 하나의 신뢰할 수 있는 위치를 두는 것입니다.

하나의 메모리 저장소가 더 간단하다고 가정하기. 설정하기는 더 간단합니다. 하지만 에이전트가 따라야 할 규칙을 스스로 다시 쓰게 만들고, 에이전트가 읽는 모든 내용이 해당 규칙에 유출되도록 허용합니다. Anthropic의 문서에서는 "메모리의 서로 다른 부분에 서로 다른 소유자나 액세스 규칙이 있는 경우" 여러 저장소를 연결할 것을 권장합니다.

시스템 프롬프트에 선호도 내장하기. 편리하지만, 가이드에서 지적한 흔한 문제가 발생합니다. 프롬프트가 사용자가 이미 변경한 규칙을 계속 적용하게 됩니다.

에이전트가 스스로 규칙을 유지하도록 허용하기. 에이전트는 패턴을 파악하는 데 능숙하며, 참조 구현체도 이를 활용합니다. 하지만 제안된 변경 사항을 에이전트가 직접 적용하게 하는 대신, 사용자가 검토할 수 있도록 에이전트 자체의 저장소로 라우팅합니다.

"새로운 내용 없음"이라는 보고를 신뢰하기. 가이드는 이것이 왜 위험한지 보여줍니다. "MCP 서버가 다운되었거나 토큰이 만료되어도 실행은 시작되지만, 해당 서버의 도구만 없을 뿐입니다." 그리고 "세션에 오류가 기록되지만, 에이전트는 해당 소스에서 아무것도 보지 못합니다." 명시적인 규칙이 없다면, 고장 난 소스는 아무 일도 없었던 평화로운 날과 똑같이 보입니다.

고정된 시간 창(time window) 읽기. 가이드는 에이전트에게 마지막 하루와 같은 고정된 시간 창을 읽도록 요청하는 것에 대해 경고합니다. "실행이 늦어지면 공백이 생기고, 실행이 빨라지면 항목이 중복됩니다." 가이드의 해답은 "대신 에이전트에게 소스별로 북마크를 제공하는 것"입니다.

1단계: 에이전트가 기억해야 할 모든 것을 작성자 기준으로 분류하기

에이전트가 실행 간에 유지해야 하는 항목을 나열한 다음, 각 항목을 두 열 중 하나에 배치합니다.

첫 번째 열은 결정(decisions)입니다. 어떤 소스를 읽을지, 무엇을 중요하게 여길지, 무엇을 제외할지, 결과가 어디로 갈지, 길이 제한, 그리고 언제 중지할지 등입니다. 이것은 사용자의 영역입니다. 에이전트가 무언가를 관찰할 때가 아니라, 사용자가 마음을 바꿀 때 변경됩니다.

두 번째 열은 관찰 및 진행 상황(observations and progress)입니다. 에이전트가 각 소스에서 어디까지 읽었는지, 이미 무엇을 보고했는지, 각 실행에서 무슨 일이 일어났는지, 각 소스에 대해 알게 된 특이사항 등입니다. 이것은 에이전트의 영역이며, 에이전트는 매 실행마다 이를 업데이트해야 합니다.

깔끔하게 분류되지 않는 것은 대개 에이전트가 영향을 미치고 싶어 하는 결정 사항입니다. 에이전트가 제안할 수 있는 공간을 에이전트의 열에 마련해 두고, 사용자의 일정에 따라 해당 제안을 검토하세요. 이는 참조 구현체가 상태 저장소에 "사용자의 선호도에 대해 제안하는 변경 사항"을 저장하는 방식과 일치합니다.

2단계: 사용자의 열을 에이전트가 읽기만 할 수 있는 저장소에 넣고, 매 실행마다 읽기

선호도를 위한 메모리 저장소를 생성하고 read_only 권한으로 연결합니다. 선호도 파일은 직접 작성합니다. 참조 구현체에서 에이전트를 배포하면 "선호도 저장소는 생성되지만 그 안의 파일은 생성되지 않으며", 시드 스크립트가 첫 번째 실행 전에 파일을 작성합니다.

그런 다음 가이드가 권장하는 지침을 추가합니다. 매 실행 시작 시 선호도를 새로 읽고, 파일을 읽을 수 없는 경우 명확한 메시지와 함께 중단하도록 합니다. 선호도를 시스템 프롬프트에도 붙여넣지 마세요. 두 개의 복사본은 서로 어긋나게 됩니다.

팀 규칙이나 용어집과 같이 여러 에이전트가 동일한 참조 자료를 공유하는 경우에도 동일한 원칙이 적용됩니다. 문서에서는 "여러 세션에 연결된 하나의 읽기 전용 저장소(표준, 규칙, 도메인 지식)를 각 세션의 자체 읽기/쓰기 저장소와 분리하여 유지하는 것"을 설명합니다.

3단계: 에이전트 자체 저장소에 원장, 북마크, 정직한 실패 라인 제공하기

읽기/쓰기 저장소에서 에이전트에게 세 가지 구조를 제공합니다.

각 실행이 끝날 때 기록되는 소스별 북마크. 이를 통해 다음 실행은 이전 실행이 멈춘 정확한 지점부터 읽기 시작합니다.

원장(ledger). "에이전트는 요약본이 중복되지 않도록 보고한 모든 항목의 원장인 ledger.md를 유지합니다." 각 줄에는 고유 ID와 항목의 마지막으로 확인된 상태가 포함되어 있어, 에이전트가 중복 보고 대신 변경 사항을 보고할 수 있도록 합니다.

실패 규칙. 소스를 읽을 수 없을 때, 가이드의 에이전트는 "해당 소스의 북마크를 그대로 두고, 다른 소스에서 요약본을 작성한 다음, 읽을 수 없었던 소스의 이름을 명시하는 한 줄로 요약본을 마무리"합니다. 가이드의 요약 규칙은 그대로 복사할 가치가 있습니다. "읽기 실패는 읽을 수 없음으로 보고하고, 절대 조용한 날로 보고하지 마십시오."

읽기/쓰기 저장소에 대한 모든 쓰기는 버전을 생성하므로, 에이전트가 무엇을 언제 기록했는지 검토할 수 있습니다. "메모리에 대한 모든 변경은 불변의 메모리 버전을 생성합니다." 요약본이 잘못된 것처럼 보일 때 이 이력을 사용하면 에이전트가 어떤 노트에 의존하고 있었는지 확인할 수 있습니다. 이러한 추적 경로가 왜 중요한지에 대해서는 memory provenance explained를 참조하세요.

Anthropic 가이드의 분할 방식은 특정 플랫폼 외부에서도 자연스럽게 적용될 수 있습니다. 사용자의 결정과 선호도는 사용자가 직접 작성하고 모든 에이전트가 준수하기를 바라는 부분입니다. 에이전트는 실행되는 위치가 어디든 자체적인 작업 노트를 유지합니다. MemoryLake는 사용자가 작성하는 레이어인 첫 번째 부분을 보관하여, 사용하는 에이전트와 어시스턴트 전반에서 일관되게 유지할 수 있는 공간입니다.

사용자는 자신의 언어로 직접 항목을 작성합니다. Anthropic의 메모리 저장소, 에이전트의 작업 노트 또는 다른 벤더의 저장소에서 아무것도 읽거나 쓰거나 삭제하지 않습니다. Anthropic의 메모리 저장소는 Anthropic 자체 API를 통해 관리되며 원래 위치에 그대로 유지됩니다.

1단계: API 키 생성하기

로그인한 후 대시보드에서 키를 생성합니다. 이 키는 Claude Console 조직과 분리된 MemoryLake 워크스페이스에 속합니다.

2단계: 첫 번째 메모리 업로드하기

1단계의 결정 열부터 시작하세요. 자신에게 중요한 것, 제외할 것, 결과를 어떻게 전달받고 싶은지 등을 작성합니다. 변경 사항을 확인할 수 있도록 항목당 하나의 선호도를 날짜와 함께 기록합니다.

3단계: AI 및 에이전트 연결하기

사용하는 어시스턴트와 에이전트를 연결합니다. 이제 사용자의 선호도는 각 에이전트의 프롬프트에 내장된 복사본이 아니라, 하나의 작성된 소스로 제공됩니다.

첫 번째 차이점은 규칙이 어긋나지 않는다는 것입니다. 에이전트가 편집할 수 없는 저장소에서 선호도를 새로 읽어오기 때문에, 사용자가 변경한 사항은 다음 실행에 즉시 적용되며 에이전트가 이를 임의로 재해석할 수 없습니다.

두 번째는 피해 반경(blast radius)이 줄어든다는 점입니다. Anthropic이 분명히 밝혔듯이 에이전트가 읽는 텍스트는 여전히 자체 노트에 쓰는 내용에 영향을 미칠 수 있습니다. 하지만 자신을 지배하는 규칙을 다시 쓸 수는 없습니다.

세 번째는 정직한 출력입니다. 원장과 북마크 덕분에 에이전트는 중복이 아닌 변경 사항을 보고하고, 실패 라인 덕분에 고장 난 소스는 고장 난 상태로 표시됩니다. 동일한 문제가 일반 사용자용 도구에서도 나타납니다. stopping ChatGPT's scheduled tasks from starting over every run에서는 대부분의 사람들이 가장 먼저 접하는 버전을 다룹니다.

네 번째는 검토 가능한 학습입니다. 제안된 선호도 변경 사항은 사용자가 수락할 때까지 에이전트의 저장소에 머물러 있습니다. 이는 에이전트가 스스로를 업데이트하는 것보다 훨씬 깔끔한 루프이며, 이 주제는 self-improving agents without retraining에서 자세히 다루고 있습니다.

결정과 관찰을 분리하세요. 결정은 사용자가 작성하는 저장소에, 관찰은 에이전트의 저장소에 저장합니다.

사용자의 저장소를 읽기 전용으로 만드세요. Anthropic은 이를 파일 시스템 수준에서 강제하므로 적극 활용하세요.

매 실행마다 선호도를 새로 읽으세요. 프롬프트에 두 번째 복사본을 절대 두지 마세요.

선호도를 읽을 수 없을 때는 중단하세요. 기본값으로 실행하는 것은 명확한 실패 메시지를 보여주는 것보다 나쁩니다.

시간 창이 아닌 북마크를 사용하세요. 각 실행은 이전 실행이 멈춘 정확한 지점에서 시작됩니다.

읽을 수 없는 소스는 명시적으로 보고하세요. 조용한 날과 만료된 토큰은 다르게 보여야 합니다.

에이전트가 기록하는 내용을 검토하세요. 메모리 버전을 통해 무엇이 변경되었는지 확인할 수 있습니다. Cowork의 관련 패턴은 controlling whether a Cowork scheduled task uses your memory를 참조하시고, Anthropic의 백그라운드 통합에 대해서는 how Claude's Dreams rebuild an agent's memory store를 참조하세요. 메모리가 어디에 존재하고 누가 접근할 수 있는지에 대한 더 넓은 질문은 the security problem nobody discusses에서 다룹니다.

예약형 에이전트를 위한 Anthropic의 참조 구현체는 단일 에이전트에 두 개의 메모리 저장소를 부여합니다. 하나는 사용자의 선호도를 보관하며 에이전트에게는 읽기 전용입니다. 다른 하나는 에이전트의 북마크, 원장, 실행 기록, 제안된 변경 사항 및 노트를 보관하며 읽기/쓰기가 가능합니다. 그 이유는 Anthropic의 설명대로입니다. 오래된 메모리는 에이전트를 혼란스럽게 하고, 선호도 복사본은 오래된 규칙을 계속 적용하게 만들며, 신뢰할 수 없는 입력에 노출된 읽기/쓰기 저장소는 주입된 지시 사항을 이후 실행으로 전달할 수 있기 때문입니다.

이 설계는 복제하기 쉽습니다. 각 메모리 조각을 누가 작성할지 결정하고, 액세스 모드로 이를 강제하며, 매 실행마다 규칙을 새로 읽고, 에이전트가 무언가를 보지 못했을 때 이를 사용자에게 알리도록 만드세요.

가이드는 전체 접근 방식에 적용되는 조언으로 끝을 맺습니다. "이를 출발점으로 삼아 소스, 대상 또는 메모리 선호도에 맞게 에이전트를 맞춤 설정하세요."