DEVOCEAN

11월 6일 Anthropic이 에이전트 메모리를 다룬 글 「The components of agent memory」를 올렸습니다.

글 후반에 '꿈꾸기(dreaming)'라는 정리 작업이 나오는데,

Claude Code를 쓰면서 메모리 폴더가 계속 불어나던 참이라 읽자마자 우리 개발 환경에 바로 써 볼 만하다는 생각이 들었습니다.

원문 내용을 간추리고, 사내 개발자분들이 내일부터 해 볼 수 있는 방법까지 한번 정리해봅니다.

원문은 꽤 길고 실험도 여러 개라, 본문에는 개발하면서 쓸 만한 부분 위주로 골랐고 원문 전체의 흐름은 글 끝의 부록에 순서대로 정리해 두었습니다.

숫자는 모두 원문과 Anthropic 공식 문서에 있는 값입니다.

1. 글에서 말하는 에이전트 메모리

글은 에이전트 메모리를 'Claude가 경험에서 얻어 세션이 바뀌어도 간직하는 지식'으로 정의합니다.

모델 가중치가 바뀌는 학습, 한 대화 안에서의 학습, 컨텍스트 창이 차서 요약하는 compaction은 여기에 넣지 않습니다.

매번 새 세션으로 시작하는 에이전트가 지난 세션에서 배운 걸 어떻게 가져가느냐가 주제입니다.

메모리는 네 개의 층으로 나눕니다.

오른쪽 열은 원문에 있는 내용이 아니고, 글을 읽으면서 Claude Code 기준으로 맞춰 본 것입니다.

원문은 Claude Code 자동 메모리가 세션 시작 때 MEMORY.md의 앞 200줄 또는 25KB까지만 읽는다는 점을 들어, 맨 위층은 인덱스처럼 작게 두라고 합니다.

2. 꿈꾸기(dreaming)란

사람은 깨어 있을 때 해마가 경험을 빠르게 담아 두고, 자거나 쉴 때 그 경험을 다시 돌려 보면서 일부를 장기 기억으로 옮긴다고 합니다.

글은 에이전트도 같은 방식으로 나눌 수 있다고 봅니다. 일하는 동안에는 로그와 메모만 쌓고, 정리는 작업이 끝난 뒤 따로 돌리는 겁니다.

이 오프라인 정리 작업을 꿈꾸기라고 부릅니다.

그림 1. 에이전트 메모리의 층과 꿈꾸기 단계 (원문 내용을 바탕으로 다시 그림)

순서는 그림처럼 다섯 단계입니다.

노트와 원본 기록을 읽고, 노트를 원본과 대조하고, 틀린 것을 고치면서 중복을 합치고 링크를 달고, 위키 같은 표현을 만들거나 갱신하고, 마지막으로 중요한 몇 가지만 맨 위층에 올립니다.

원문은 이 과정을 "Dreaming gives Claude a way to test its notes against the original transcripts."라고 설명합니다.

메모는 원본의 요약일 뿐이고, 둘이 다르면 원본이 맞다고 보고 메모를 고친다는 뜻입니다.

이게 왜 필요한지는 포켓몬 레드 실험에서 잘 보입니다.

Claude가 달맞이산 포켓몬센터가 동쪽에 있다고 잘못 적어 두고 "Mt Moon DONE"이라고 쓴 뒤 일방통행 절벽으로 내려가 버렸고, 세 번을 다시 시도해도 같은 길로 돌아왔습니다.

꿈꾸기가 그 메모를 트랜스크립트와 대조해 고친 뒤에는 동굴로 다시 들어가 약 1,935번째 행동에서 블루시티에 도착했습니다.

메모를 고치지 않은 실행과 메모리가 없는 실행은 끝내 블루시티에 가지 못했습니다.

틀린 메모 하나가 계속 같은 실수를 부른다는 걸 보여 주는 예라서 기억에 남았습니다.

3. 실험에서 눈여겨본 숫자

원문에는 실험이 여럿 있는데, 개발할 때 판단에 도움이 될 만한 것만 골랐습니다.

표를 보면서 세 가지가 와닿았습니다. 첫째, 메모를 많이 쓰는 것보다 무엇을 쓸지 고르는 판단이 더 중요했습니다.

화면만 봐도 아는 돈이나 위치까지 적은 Sonnet 3.7은 파일 정리에만 행동 17번을 쓰기도 했습니다. 둘째, 규칙을 세세하게 정해 주면 오히려 손해일 수 있습니다.

원문은 메모리가 무엇에 쓰이는지만 알려 주고 어떻게 쓸지는 맡기는 편이 Opus 4.7과 Opus 5에서 효과가 컸다고 합니다.

다만 Sonnet 4.6은 답하기 전에 메모를 먼저 읽고 가설을 직접 시험하라고 시키자 점수가 0.364에서 0.641로 거의 두 배가 됐습니다.

모델에 따라 시켜야 할 것이 다르다는 얘기입니다. 셋째, 위키는 만능이 아니었습니다.

문서 여러 개를 엮어야 하는 질문에서는 도움이 됐지만, 답이 문서 한 곳에 있는 과제에서는 효과가 없었고 원본보다 커지기도 했습니다.

4. 우리 개발 환경에 적용하기

여기부터는 원문과 공식 문서를 바탕으로 사내 개발자분들께 권하는 방법입니다. 가볍게 해 볼 수 있는 것부터 적었습니다.

4-1. Claude Code 메모리부터 점검하기

Claude Code를 오래 쓰다 보면 프로젝트별 메모리 폴더(~/.claude/projects/<프로젝트>/memory/)에 메모가 계속 쌓입니다.

한번 열어 보시면 이미 끝난 작업 얘기, 지금은 없는 파일 경로, 같은 내용을 다르게 적은 메모가 섞여 있을 가능성이 큽니다.

원문 기준으로 보면 이렇게 정리하는 게 좋습니다.

• MEMORY.md는 한 줄짜리 인덱스로만 씁니다. 세션마다 앞 200줄 또는 25KB만 읽고, 여기에 틀린 내용이 있으면 모든 세션이 그 내용을 믿고 시작합니다.

• 메모 파일은 주제마다 하나씩 두고, 규칙과 이유를 함께 적습니다.

• 저장소나 git 기록, 화면을 보면 바로 알 수 있는 값은 적지 않습니다. 금방 낡아서 관리할 거리만 늘어납니다.

• ID, 명령어, 사용자가 한 말처럼 정확해야 하는 값은 요약하지 말고 원문 그대로 적습니다. 계약 조건 실험에서 요약한 표는 사실의 28%를 잃었습니다.

4-2. 주기적으로 꿈꾸기 돌리기

꿈꾸기 절차는 단순해서 Claude Code에서는 스킬 하나로 만들어 둘 수 있습니다.

아래는 원문의 다섯 단계를 Claude Code 메모리에 맞춰 옮긴 스킬을 줄인 것입니다.

~/.claude/skills/memory-dream/SKILL.md로 저장해 두고 "메모리 꿈꾸기 해줘"라고 하면 됩니다.

---
name: memory-dream
description: Claude Code 자동 메모리 폴더를 원본(세션 기록·저장소·파일)과 대조해 고치고, 중복을 합치고, MEMORY.md를 작게 유지한다. '꿈꾸기', '메모리 정리' 요청 시 사용.
---

1. 읽기: 현재 프로젝트 메모리 폴더 전체(MEMORY.md + 노트)를 읽는다.
2. 원본과 대조: 노트의 사실 주장(경로, 저장소, 명령, 사용자 발언)을 확인한다.
   - 경로·저장소는 ls, git log로 확인
   - 사용자 지시는 세션 기록(*.jsonl)에서 키워드로 grep (통째로 읽지 않는다)
   - 확인하지 못한 주장은 지우지 말고 '미확인'으로 표시해 보고
3. 고치기: 틀린 것은 수정, 낡은 것은 삭제, 같은 주제는 한 파일로 합치고 링크로 연결
4. 빈틈 채우기: 최근 세션에서 반복된 요청·사용자 교정만 새 노트로 추가
5. 상단 정리: 원본으로 확인한 것만 MEMORY.md에 한 줄로 올린다
6. 보고: 고친 것 / 합친 것 / 지운 것 / 새로 쓴 것 / 미확인

주의: 노트가 원본보다 커지면 실패다. 민감정보(토큰·비밀번호·개인정보)는 쓰지 않는다.

돌리는 주기는 정해진 답이 없습니다.

원문도 모든 메모를 계속 점검하는 건 비용이 커서 현실적이지 않다고 하고, 바뀔 가능성이 큰 정보 위주로 보고 자주 쓰는 정도에 따라 주기를 조정해 보라고 합니다.

처음에는 큰 작업이 하나 끝났을 때나 일주일에 한 번 정도 돌려 보고, 고친 내용이 많으면 주기를 줄이는 식으로 맞춰 가면 될 거 같습니다.

손으로 부르다 보면 잊어버리기 쉬워서, 주기적으로 알아서 돌게 해 두는 편이 원문이 말하는 '자는 동안 정리'에 더 가깝습니다.

Claude Code는 claude -p "메모리 꿈꾸기 해줘"처럼 대화 없이 한 번 실행하는 모드가 있어서, 이 명령을 cron 같은 스케줄러에 걸어 두면 됩니다.

이때는 사람이 옆에서 권한을 허락해 줄 수 없으니 허용할 도구를 미리 정해 두고, 메모를 바로 덮어쓰는 대신 바꿀 내용을 보고 파일로 남기게 해서 다음 날 확인하고 반영하는 방식이 안전합니다.

결과는 Claude가 보고한 내용을 그대로 반영하지 말고 한번 읽어 보시길 권합니다. 메모가 틀렸다고 판단한 근거가 무엇인지 보고에 같이 나오게 하면 확인이 쉽습니다.

4-3. 메모를 쓰게 할 때의 규칙

CLAUDE.md나 에이전트 시스템 프롬프트에 메모 규칙을 넣을 때도 원문 결과를 참고할 수 있습니다.

• 메모리가 무엇에 쓰이는지를 알려 주고, 무엇을 적을지는 모델 판단에 맡깁니다. "실패만 기록하라" 같은 고정 규칙은 앞의 실험처럼 점수를 깎았습니다.

• 성능이 낮은 모델을 쓴다면 반대로, 답하기 전에 메모를 먼저 읽고 가설은 직접 확인하라고 적어 줍니다.

• 에이전트 여러 개가 같은 메모리에 동시에 쓴다면 공용 표 하나에 몰아 쓰지 말고, 대상마다 페이지를 따로 두게 합니다. 계약 조건 실험에서 이 차이가 72%와 100%로 갈렸습니다.

4-4. 에이전트를 만드는 팀이라면 Managed Agents의 Dreams

Claude API로 에이전트를 직접 만드는 팀이라면 Claude Managed Agents의 Dreams를 볼 만합니다.

5월 19일 리서치 프리뷰로 나왔고, 신청서를 내서 접근 권한을 받아야 합니다. 출시 글에는 법률 AI 회사 Harvey가 이 기능을 시험해 작업 완료율이 약 6배 올랐다고 나옵니다.

Dream은 비동기 작업입니다. 기존 메모리 저장소 하나와 지난 세션 1~100개를 넣으면, 중복을 합치고 낡거나 모순된 내용을 최신 값으로 바꾼 새 메모리 저장소를 만듭니다.

입력 저장소는 건드리지 않아서 결과를 검토한 뒤 쓰거나 버릴 수 있습니다. 공식 문서의 Python 예시는 이렇습니다.

dream = client.beta.dreams.create(
    inputs=[
        {"type": "memory_store", "memory_store_id": store_id},
        {"type": "sessions", "session_ids": [session_a, session_b]},
    ],
    model="claude-opus-5-5",
    instructions="Focus on coding-style preferences; ignore one-off debugging notes.",
)

instructions로 무엇에 집중할지 정할 수 있지만, 특정 문장을 고치라는 식의 지시는 대부분 반영되지 않는다고 합니다.

개별 메모를 고칠 때는 결과 저장소를 Memory Stores API로 직접 고칩니다.

비용은 모델의 일반 토큰 요금이고 입력 세션 수와 길이에 거의 비례하니, 문서 권고대로 세션 몇 개로 시작해서 정리 품질을 본 뒤 늘리는 게 좋겠습니다.

프롬프트와 모델을 직접 고르고 싶다면 Claude Cookbook의 「Dreaming with a dynamic workflow」 예제가 세션마다 분석 에이전트를 붙이고 정리 에이전트가 중복과 링크를 손보는 방식을 보여 줍니다.

사내에서 쓸 때는 데이터 취급을 먼저 확인해야 합니다. 공식 문서 기준으로 Managed Agents의 세션은 지울 때까지 트랜스크립트가 남고, Zero Data Retention 대상이 아닙니다.

고객 정보나 내부 기밀이 세션에 들어가는 업무라면 사내 AI 사용 규칙과 보안 담당 부서 기준을 먼저 확인하시길 권합니다.

Cookbook도 트랜스크립트에는 도구 출력에 섞인 지시문이 들어 있을 수 있으니 믿을 수 없는 입력으로 다루고, 메모리에는 비밀값을 넣지 말고, 처음 만든 메모리는 에이전트가 읽기 전에 사람이 검토하라고 권합니다.

5. 주의할 점

원문도 아직 배울 게 많다고 밝히고 있어서, 적용할 때 몇 가지는 염두에 두는 게 좋겠습니다.

• 틀린 메모가 맨 위층에 올라가면 모든 세션에 퍼집니다. 위로 올리는 건 원본으로 확인한 것만 합니다.

• 꿈꾸기도 컴퓨팅 비용이 듭니다. 쉽게 다시 읽을 수 있는 상태값은 저장하지 않는 편이 비용과 관리 양을 함께 줄입니다.

• 위키는 문서 여러 개를 엮어야 하는 질문에서만 효과가 있었고, 원본보다 커지면 요약 역할을 못 합니다. 원문도 트랜스크립트 검색을 바탕에 두고 그 위에 표현을 더하는 방식을 권합니다.

• 결과는 모델마다 달랐습니다. 우리 팀이 쓰는 모델과 과제에서 메모리가 실제로 도움이 되는지는 직접 재 봐야 압니다.

마치며

글을 읽기 전에는 메모리를 많이 남길수록 에이전트가 똑똑해진다고 막연히 생각했는데, 실험 결과는 적게 쓰고 자주 고치는 쪽을 가리키고 있어서 생각을 좀 바꾸게 됐습니다.

특히 틀린 메모 하나 때문에 같은 절벽을 세 번 내려간 포켓몬 실험은 Claude Code에서 낡은 메모를 믿고 엉뚱한 파일을 찾던 경험과 겹쳐 보였습니다.

지금은 LLM_Wiki에 이렇게 주기적으로 꿈꾸기를 돌리는 기능을 넣어 만들고 있습니다.

아직 만드는 중이라 얼마나 자주 돌려야 하고 정리 전후로 작업이 실제로 나아지는지는 숫자로 확인하지 못했습니다.

써 보시고 효과가 있었던 규칙이나 주기가 있으면 댓글로 나눠 주시면 좋겠습니다.

부록. 원문 전체 정리

원문 「The components of agent memory」를 절 순서대로 간추렸습니다.

번역이 아니라 요약이고, 자세한 그래프와 예시는 원문에서 보실 수 있습니다. 글쓴이는 Anthropic의 Lance Martin이고, 2026년 11월 6일 Engineering 팀 글로 올라왔습니다.

1) 메모리의 정의와 범위

에이전트 메모리를 'Claude가 경험에서 얻어 세션 사이에 간직하는 지식'으로 정의합니다. 모델 가중치 변경, 한 대화 안의 in-context learning, 컨텍스트 창을 이어 가려고 요약하는 compaction은 범위에서 뺍니다. 사람의 해마가 낮에 경험을 빠르게 담고 잠자는 동안 다시 돌려 보며 신피질에 장기 기억으로 옮기는 것에 빗대어, 에이전트도 작업 중에는 기록을 남기고 정리는 오프라인으로 하는 분업이 가능하다고 봅니다. 이 생각의 배경으로 Letta와 UC Berkeley의 sleep-time compute 연구를 듭니다.

2) 메모리의 층

아래에서부터 원본 기록(검색할 수 있는 트랜스크립트), 메모 노트(Claude가 쓴 관찰이나 메모리 폴더의 파일), 메모리 표현(서로 링크된 위키 페이지 모음), 주입 컨텍스트(세션마다 처음에 읽는 내용)의 네 층입니다. 꿈꾸기는 어느 층에서도 돌 수 있고, 정보를 층 사이로 옮기는 역할도 합니다.

3) 메모리가 있으면 얼마나 나아지나 (CL-Bench)

질문마다 새 세션으로 시작하되 메모리 폴더 하나는 계속 읽고 쓸 수 있게 한 데이터베이스 과제입니다. 평균 점수는 아래와 같습니다.

모델마다 메모를 다루는 모습도 달랐습니다. Sonnet 4.6은 확인하지 않은 가설만 적고 학습 고리를 닫지 못했고, Opus 4.7은 노트를 합치면서 사실마다 확인됨과 미확인을 표시했습니다. Sonnet 5는 채점 뒤 답이 맞았는지 적고 틀린 것을 고쳤으며, Opus 5는 규칙과 근거, 주의할 점까지 적어 처음으로 고리를 끝까지 닫았습니다. Opus 5.5와 Sonnet 5.5도 고리를 닫았고, 메모리가 있을 때 점수는 Opus 5와 비슷하지만 메모리 없이도 점수가 조금 더 높았습니다.

4) 무엇을 기억할지 고르는 판단 (포켓몬 레드)

약 1만 단계를 진행했을 때 Sonnet 3.7은 225개 폴더에 413개 파일(약 98만 자)을 쓰고 배지 1개를 얻었습니다. 돈이나 위치처럼 화면에 이미 나오는 값까지 적다 보니 기록이 금방 낡았고, 파일을 만들고 지우는 정리에만 행동 17번을 쓰기도 했습니다. Fable 5는 두 폴더의 파일 9개와 global.md(약 4만 3천 자)만 쓰고 배지 4개를 얻었는데, 화면에 없는 전략과 계획 위주로 적었습니다. Opus 5.5는 현재 목표와 다음 할 일을 적는 작은 폴더를 두고 게임을 끝까지 깼습니다. 몬스터볼을 여러 번 실패한 뒤 "3번 넘게 연속으로 실패하면 타이밍을 바꿔라" 같은 규칙을 스스로 적은 예도 나옵니다.

5) 메모 쓰기를 어떻게 이끌까

메모리가 무엇에 쓰이는지만 알려 주고 쓰는 방법은 정하지 않아도 Opus 4.7과 Opus 5는 CL-Bench 점수가 분명히 올랐습니다. 반대로 "실패만 기록하라"는 규칙을 주자 메모리로 얻던 이득이 Opus 5는 0.234, Opus 4.7은 0.150, Sonnet 4.6은 0.020 줄었습니다. Sonnet 4.6에게 답하기 전에 메모를 읽고 가설을 직접 시험하라고 시키자 점수가 0.364에서 0.641로 올랐습니다. Sonnet 5는 시키지 않아도 10번 중 9번 메모를 먼저 읽었고, Sonnet 4.6은 절반이 안 됐습니다.

6) 꿈꾸기로 틀린 메모 고치기

본문 2절의 달맞이산 사례입니다. 포켓몬센터 위치를 잘못 적은 메모 때문에 일방통행 절벽으로 세 번 떨어졌고, 세 번째에는 Claude가 같은 곳을 맴도는 걸 멈추겠다고 적기도 했습니다. 꿈꾸기가 메모를 트랜스크립트와 대조해 고친 뒤에는 약 1,935번째 행동에서 블루시티에 도착했고, 고치지 않은 실행과 메모리 없는 실행은 도착하지 못했습니다.

7) 위키 만들기

Anthropic이 5월에 인수한 Stainless의 사내 문서 약 35만 개(약 4억 2천만 토큰)로 위키를 만들고 질문 25개로 평가했습니다. Opus 5 에이전트로 꿈꾸기를 2세션에서 128세션까지 늘리자 위키만으로 맞힌 채점 기준이 13%에서 48%로 올랐습니다. 위키는 2세션 뒤 103페이지·링크 766개에서 128세션 뒤 222페이지·링크 12,893개로 커졌습니다. 위키와 검색을 함께 쓰면 61%로 검색만 쓴 53%보다 높았고, 질문당 약 2만 토큰을 아꼈습니다. 원문은 초기 위키를 갓 들어온 신입의 지식에, 꿈꾸기가 계속되며 깊어지는 위키를 경력이 쌓인 직원의 지식에 빗댑니다.

8) 위키가 맞지 않는 경우 (Harvey LAB 법률 과제)

인수합병 관련 질문 24개처럼 여러 문서를 엮거나 계산해야 하는 과제에서는 위키가 87%로 검색만 쓴 73%보다 높았습니다. 채점 기준 대부분이 문서 한 곳에 있는 과제에서는 뚜렷한 차이가 없었습니다. 또 다른 과제에서는 위키(68페이지, 링크 255개, 203KB)가 원본(115KB)의 1.77배로 커졌고, 원문은 보르헤스의 소설을 빌려 아무것도 추상화하지 못한 아주 자세한 위키였다고 평합니다.

9) 여러 에이전트가 함께 쓸 때

여러 에이전트가 계약 조건을 공용 표 하나에 동시에 쓰자 채점 대상 사실 57개 중 41개(72%)만 남았습니다. 돌아보고 고치는 과정을 거쳐 계약마다 페이지를 따로 두고 조건을 원문 그대로 인용하게 바꾸자 57개가 모두 남았습니다.

10) 주입 층으로 올리기

Claude Code 자동 메모리는 세션 시작 때 MEMORY.md의 앞 200줄 또는 25KB만 읽어 인덱스처럼 씁니다. 원문은 주입된 메모리가 귀한 토큰을 쓰고, 틀린 메모 하나가 모든 세션으로 옮겨 갈 수 있다고 경고합니다. 맨 위층은 작게 두고 세부 내용은 링크로 아래층에 두라는 것이 권고입니다.

11) 두 번째 꿈꾸기

첫 정리 뒤 다시 꿈꾸기를 돌리자, 여섯 페이지에 있던 링크 9개가 존재하지 않는 페이지를 가리키던 것을 기존 페이지로 고치고, 색인·안내 메일·에스컬레이션 페이지 3개를 새로 만들었습니다. 항목은 38개에서 41개로, 링크는 225개에서 278개로 늘었습니다.

12) 남은 과제

원문은 아직 배울 게 많다고 밝히며 몇 가지 열린 문제를 적습니다. 작업 중에 기록하면 본 작업에서 주의를 빼앗고, 꿈꾸기는 뒤에서 돌지만 결과를 바로 쓰지 못할 수 있습니다. 메모는 처음부터 틀리거나 시간이 지나 낡을 수 있고, 위키에도 오류나 환각이 쌓일 수 있습니다. 메모리 유지에는 컴퓨팅 비용이 들어 모든 메모를 계속 점검하기는 어렵기 때문에, 바뀔 가능성이 큰 정보에 집중하고 접근 빈도에 따라 꿈꾸기 주기를 조정하는 방법을 제안합니다. 바탕에는 트랜스크립트 검색을 두고, 필요할 때 그 위에 표현을 더하는 방향을 권합니다.

참고 자료

• Anthropic, 「The components of agent memory」 (2026-11-06): https://www.anthropic.com/research/components-of-agent-memory

• Claude 블로그, 「New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration」 (2026-05-19): https://claude.com/blog/new-in-claude-managed-agents

• Claude Platform 문서, Dreams: https://platform.claude.com/docs/en/managed-agents/dreams

• Claude Cookbook, 「Dreaming with a dynamic workflow」: https://platform.claude.com/cookbook/managed-agents-cma-dreaming-with-a-dynamic-workflow