Anthropic Dreaming을 통한 AI 에이전트의 메모리 관리와 리뷰 설계의 변화

Anthropic이 Claude Managed Agents에 dreaming 기능을 도입했습니다.

이름만 보면 상당히 거창하게 들립니다. AI가 꿈을 꾸는 것이라기보다는, 과거 세션과 memory store(메모리 저장소)를 나중에 다시 읽어 들여 중복된 기억을 정리하거나, 오래된 기술을 새로운 내용으로 교체하거나, 다음 태스크에 도움이 될 만한 패턴을 찾아내는 메커니즘입니다. 현재는 Research Preview 단계이며, Managed Agents를 위한 기능입니다.

하지만 저는 이것이 단순히 "메모리 기능이 조금 똑똑해졌다"는 이야기가 아니라고 생각합니다.

Vibe Coding 다음에 올 까다로운 주제가 상당히 명확하게 보였기 때문입니다. 앞으로의 AI 에이전트 운용에서는 프롬프트(Prompt)를 잘 쓰는 것보다 "무엇을 기억하게 하고, 무엇을 잊게 할 것인가"의 설계가 중요해질 것입니다.

AI 코딩에서 은근히 힘든 점은 똑같은 설명을 반복해야 한다는 것입니다.

예를 들어 프론트엔드 리포지토리(Repository)라면 대략 다음과 같은 로컬 규칙이 있습니다.

• 폼(Form)은 vee-validate가 아니라 react-hook-form을 따른다.
• API 타입은 생성물이므로 직접 편집하지 않는다.
• UI 컴포넌트는 features/**에서 shared/ui로 역류시키지 않는다.
• Tailwind의 arbitrary value는 원칙적으로 사용하지 않는다.
• Storybook의 story를 업데이트하지 않는 차분(diff)은 리뷰에서 차단한다.

사람 동료라면 몇 번의 리뷰를 거치면서 이를 익히게 됩니다.

하지만 기존의 AI 에이전트는 세션이 끊기면 다시 신입 사원으로 돌아가는 듯한 느낌이 있었습니다. 물론 project instructions나 AGENTS.md, rules file(규칙 파일)로 상당히 개선할 수 있습니다. 그럼에도 실제 리뷰에서 나온 세세한 습관까지는 남기기 어렵습니다.

결과적으로 매번 다음과 같은 대화가 반복됩니다.

이 프로젝트에서는 shared/ui의 props를 늘리지 마세요.
지난번에도 같은 이유로 반려했습니다.
이번에는 features/billing 측에서 어댑터(adapter)를 만들어 주세요.

이 "지난번에도 말했다"라는 내용을 에이전트 측에서 다룰 수 있는 형태로 쌓아 올릴 수 있는가. Dreaming의 흥미로운 점은 바로 이 부분입니다.

Claude의 docs(문서)를 읽어보면, dream은 asynchronous job(비동기 작업)으로 동작합니다.

입력값은 기존의 memory store와 과거 세션의 transcript(기록)입니다. 출력값은 새롭게 정리된 memory store입니다. 원래의 store는 직접 변경되지 않으므로, 필요하다면 사람이 차분을 확인한 후 채택할 수 있습니다.

대략 다음과 같은 처리 과정입니다.

past sessions + current memory store
-> dream job
-> proposed memory store
...

여기서 중요한 것은 모델에게 "적당히 잘 기억해 둬"라고 맡기기만 하는 것이 아니라는 점입니다.

메모리는 방치하면 오염됩니다. 오래된 사양, 중복된 지시, 나중에 뒤집힌 판단, 어쩌다 한 번 통과된 예외 사항. 이런 것들이 섞이면 에이전트는 똑똑해지기는커녕 과거의 실수를 자신만만하게 재사용하게 됩니다.

Dreaming은 그 부분을 청소하기 위한 메커니즘입니다. 따라서 저는 이를 "에이전트를 키우는 기능"인 동시에 "memory의 가비지 컬렉션(Garbage Collection, 쓰레기 수집) 기능"으로 보고 있습니다.

이 기능이 프론트엔드에서 효과를 발휘한다면, 아마 화려한 코드 생성은 아닐 것입니다.

진정한 효과는 리뷰의 기억에서 나옵니다.

예를 들어, AI 에이전트에게 몇 번이고 같은 컴포넌트 수정을 요청하는 상황을 가정해 봅시다.

목적:
- AccountSettings의 알림 설정 UI를 분할한다
수정 가능한 범위:
...

이 태스크 자체는 현재의 에이전트도 충분히 해낼 수 있습니다.

문제는 리뷰 이후입니다.

Review notes:
- shared/ui/Button에 loading prop을 추가하려 했으나, 이 프로젝트에서는 feature 측에서 래핑(wrap)한다.
- generated/api의 타입을 직접 수정하려 했으나, schema(스키마) 업데이트가 필요하다.
...

이러한 리뷰 결과를 다음 작업에 활용하고 싶습니다.

사람이라면 "이 리포지토리에서는 shared/ui를 건드리면 혼난다"라고 기억합니다. 에이전트도 똑같이 기억해주길 바랍니다. 다만, 그 기억은 노이즈와 함께 늘어나기 때문에 정기적으로 정리할 필요가 있습니다.

Dreaming (Dreaming)이 실용화된다면, 이 리뷰 기억의 유지보수(maintenance)가 가장 큰 가치를 가질 것입니다.

이 지점에서 오해하면 위험합니다.

에이전트가 스스로 과거를 되돌아본다면 인간의 리뷰가 줄어든다는 뜻이 아닙니다. 오히려 그 반대입니다. 리뷰 대상이 코드뿐만 아니라 memory (메모리)의 차분(diff)으로까지 확장됩니다.

저라면 최소한 다음 세 가지는 확인할 것 같습니다.

# Agent memory review checklist
1. 오래된 사양이 남아있지 않은가
- 폐지된 API
...

memory (메모리)는 설계 문서(design document)가 아닙니다.

그보다 작업에 더 가까운, 에이전트가 다음 단계에서 사용하기 위한 압축된 문맥(context)입니다. 따라서 추상적인 마음가짐을 넣어도 별로 효과가 없습니다. 효과가 있는 것은 리뷰에서 실제로 차단되었던 구체적인 실패 패턴입니다.

이 부분도 구분해 두고 싶습니다.

AGENTS.md나 repository instructions (레포지토리 지침)는 팀이 명시적으로 결정한 규칙을 적는 곳입니다.

- 패키지 매니저는 pnpm을 사용한다
- UI는 Radix + Tailwind를 사용한다
- 테스트는 Vitest를 사용한다
...

반면 Dreaming (Dreaming)을 통해 성장하는 memory (메모리)는 운영 과정에서 발생하는 습관을 포착하는 장소에 가깝습니다.

- 이 레포지토리에서는 feature (피처) 측 adapter (어댑터)로 흡수하는 판단이 많다
- UI 차분 발생 시 story (스토리) 업데이트 누락이 리뷰에서 자주 걸러진다
- billing (결제) 주변은 optimistic update (낙관적 업데이트)보다 명시적인 refetch (리페치)를 선호한다

전자가 헌법이라면, 후자는 현장 메모입니다.

이 두 가지를 섞으면 괴로워집니다. 규칙 파일에 너무 세세한 리뷰 이력을 적으면 인간이 읽을 수 없습니다. memory (메모리)에 절대적인 규칙을 너무 많이 적으면 어느샌가 낡은 것이 되어버립니다.

Dreaming (Dreaming)을 정말로 사용하려면 아마도 이러한 분리가 필요할 것입니다.

제가 팀에 도입한다면, 갑자기 모든 작업 이력을 대상으로 삼지는 않겠습니다.

우선 리뷰 지적 사항에만 집중하겠습니다.

# agent-review-notes.md
## 2026-05-11 AccountSettings refactor
Keep:
...

이런 메모를 작업 후에 남겨 dream (드림)의 대상으로 만듭니다. 그리고 나온 memory (메모리) 차분을 인간이 검토합니다.

채택하는 memory (메모리)는 짧아도 괜찮습니다.

When changing feature UI, update the matching Storybook story and run the focused story test.
Do not expand shared/ui public props for feature-specific loading or error states; prefer a feature-local wrapper.

이 정도의 입도(granularity)라면 다음 작업에서 효과를 발휘합니다. 반대로 긴 반성문을 그대로 넣는 것은 컨텍스트 (context)만 잡아먹을 뿐입니다.

Dreaming (Dreaming)이라는 이름은 솔직히 조금 강하다고 생각합니다. AI가 자는 동안 똑똑해지는 것처럼 들리기 때문입니다.

하지만 기능적으로 보면 상당히 현실적입니다.

AI 에이전트가 긴 작업을 수행할수록 memory (메모리)는 오염됩니다. 여러 에이전트가 작업할수록 동일한 프로젝트에 대한 해석이 어긋납니다. 세션을 넘나들수록 '지난 리뷰에서 무엇을 배웠는가'가 중요해집니다.

즉, 필요한 것은 마법 같은 자율성이 아니라, 지속적인 memory hygiene (메모리 위생 관리)입니다.

프론트엔드 개발로 말하자면, AI에게 컴포넌트를 작성하게 하는 것 자체는 이제 드문 일이 아닙니다. 차이가 발생하는 지점은 그 이후입니다.

• 어떤 실패를 기억시킬 것인가
• 어떤 기억을 버릴 것인가
• memory (메모리)의 차분을 누가 리뷰할 것인가
• 규칙 파일과 운영 메모를 어떻게 나눌 것인가

이런 부분들을 설계할 수 있는 팀은 에이전트를 진정으로 육성할 수 있다고 생각합니다.

반대로 이 부분을 방치하면 '이전보다 똑똑한 AI'가 아니라 '오래된 고정관념을 가진 AI'가 만들어집니다. 이는 상당히 피하고 싶은 결과입니다.

Anthropic (Anthropic)의 Dreaming (Dreaming)은 AI 에이전트를 인간처럼 만드는 기능이라기보다, 장기 운용을 위한 memory maintenance (메모리 유지보수)에 가깝습니다.

따라서 개발자 측의 업무도 변합니다.

훌륭한 프롬프트 (prompt)를 작성한다. 코드를 리뷰한다. 여기까지는 지금까지와 같습니다. 앞으로는 에이전트가 무엇을 학습한 것으로 간주할지를 리뷰할 필요가 있습니다.

AI 에이전트를 단순한 '도구'로만 사용한다면, 매번 프롬프트 (prompt)를 던지면 그만입니다.

하지만 팀 멤버에 가까운 형태로 사용하려면 육성 메커니즘이 필요합니다. Dreaming은 그에 대한 첫 번째로 이해하기 쉬운 구현으로 보입니다. 편리해 보이지만, 무심코 맡겨버리면 평범하게 위험할 수 있습니다. 바로 그 점이 흥미롭습니다.

• Claude Blog: New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration
• Claude API Docs: Dreams
• Ars Technica: Anthropic's Claude Managed Agents can now "dream," sort of