이 기사에서 수행한 것 (2026년 6월): Anthropic이 2026년 5월 6일에 발표한 Claude Managed Agents의 신기능 「Dreaming」(Research Preview)과, 내가 직접 운용하고 있는 자체 메모리 정리 스킬 /dream (보조 스크립트 410행·스킬 정의 269행)을 설계 수준에서 대조했다. 결론은 「어느 쪽이 더 우수한가」가 아니라, 양자가 「AI에게 어디까지 설계를 맡길 것인가」라는 질문에 서로 다른 답을 내놓고 있다는 점에 있다. 직접 테스트해 보지 못하더라도 설계 원칙은 읽어낼 수 있다——본 기사는 그 실증이기도 하다. 또한, Dreaming은 API 한정 Research Preview이므로, 비교는 공식 블로그(claude.com/blog/new-in-claude-managed-agents)의 기재 내용과 자체 구현의 실측치를 근거로 한다.

「AI가 자신의 메모리를 정리하는」 기능이 왔다

AI 에이전트(Agent)를 오래 사용하다 보면 반드시 부딪히는 문제가 있다. 에이전트에게 학습시킨 지식(메모리)이 점점 비대해지고, 중복되며, 때로는 모순되는 문제다.

내가 운용하고 있는 Claude Code의 메모리 디렉토리에는 현재 시점에서 개별 메모리 파일이 43개가 있다(~/.claude/projects/*/memory/ 하위 실측, 여러 Claude 프로젝트를 횡단한 합계). 「기사의 1인칭은 나」, 「Opus 사용 전에 허가를 구할 것」과 같은 운용 규칙이 파일당 하나의 테마로 축적되어 있다. 편리한 반면, 비슷한 규칙이 두 개의 파일로 나뉘어 있거나 오래된 설정값이 남아 있기도 한다. 이를 수동으로 계속 정리하는 것은 매우 고된 일이다.

이 과제에 대해 Anthropic이 2026년 5월 6일에 「Dreaming」이라는 기능을 발표했다. 공식 블로그에 따르면, Dreaming은 「에이전트의 세션과 메모리 스토어(Memory Store)를 리뷰하고, 패턴을 추출하며, 메모리를 정리하는 스케줄된 프로세스(Scheduled Process)」다 (출처: claude.com/blog/new-in-claude-managed-agents, 원문 "Dreaming is a scheduled process that reviews your agent sessions and memory stores, extracts patterns, and curates memories so your agents improve over time.").

여기서 주의해야 할 표현이 있다. 「스케줄된 프로세스(Scheduled Process)」이지, 「유휴 상태(Idle)일 때 멋대로 기동하는 것」은 아니다. 나도 처음에는 「인간이 자는 동안 AI가 꿈을 꾸듯 메모리를 정리한다」는 이미지로 받아들였지만, 공식 측이 말하는 것은 어디까지나 정기 실행되는 잡(Job)이다. 이 구분은 이후의 대조에서 중요한 역할을 한다.

문제는 Dreaming이 Claude Managed Agents의 API 기능이며, 게다가 Research Preview라는 점이다. 신청은 웨이트리스트(Waitlist) 방식의 폼(claude.com/form/claude-managed-agents)을 통해 이루어지며, 대상 자격 요건은 공식적으로 명시되어 있지 않다. 구독(Pro / Max) 서비스로는 사용할 수 없으며, API 과금 체계 내에서만 제공된다 (2026년 6월 8일 기준 공식 블로그 기재 내용에 따름). 즉, 많은 개인 개발자는 「발표는 읽었지만 테스트해 볼 수 없는」 상태에 놓여 있다.

나 또한 그중 한 명이다. 하지만 테스트해 보지 못하더라도 설계는 읽어낼 수 있다. 그리고 내 손에는 비슷한 목적으로 직접 만든 스킬이 있다. 그렇다면 공식 사양과 자체 구현을 나란히 놓고 「설계 사상의 차이」를 추출해 보자, 라는 것이 이 기사의 출발점이다.

공식 Dreaming의 설계를 공식 기술로부터 읽기

먼저, 공식 측이 무엇을 말하고 있는지를 정확히 파악한다. 내가 테스트해 보지 못한 이상, 이 부분은 단언을 피하고 공식 블로그의 기재 내용에 한정하여 작성한다.

공식 블로그에서 읽어낼 수 있는 Dreaming의 설계상 요점은 3가지가 있다.

• 정기적으로 실행되는 프로세스이다. 앞서 언급했듯이 "scheduled process"라고 명시되어 있다. 트리거의 최소 유휴 시간(idle time) 등 상세 조건은 공식적으로 기재되어 있지 않다. -
• 세션과 메모리를 가로질러 패턴을 추출한다. 단일 파일의 정리가 아니라, 에이전트가 과거 세션에서 학습한 내용(공식 예시에서는 "파일 형식별 회피책", "도구 고유의 패턴")을 추출하여 메모리에 반영한다. -
• 반영 전 리뷰를 선택할 수 있다. 공식 측은 "메모리를 자동으로 업데이트하거나, 변경 사항이 반영되기 전에 리뷰할 수 있다"라고 기술하고 있다(원문 "update memory automatically, or you can review changes before they land."). 즉, 리뷰는 필수 사항이 아니라 옵션이다.

세 번째는 내가 당초 오해했던 부분이다. "리뷰 필수"라고 믿고 있었으나, 공식 기술은 달랐다. 자동 업데이트도 선택할 수 있다——리뷰를 거칠지 여부는 이용자의 설정에 맡겨져 있다.

효과로서, 공식 측은 Harvey 사의 내부 테스트에서 "태스크 완료율이 약 6배(~6x)"라는 수치를 제시하고 있다. 이는 Harvey 사의 내부 테스트 값이며, 개인의 메모리 정리에도 그대로 적용되는 수치는 아니라는 점에 유의해야 한다.

자체 제작 /dream 스킬 구현

여기서부터는 내가 시도할 수 있는 영역이다. 나는 Claude Code용으로 /dream이라는 스킬을 직접 제작하고 있다. 목적은 동일하다——비대화, 중복, 모순을 일으키는 메모리 파일군을 정리하는 것이다.

구현은 2개의 파일로 구성된다. 스킬의 절차를 기술한 스킬 정의(dream.md, 269행)와, 파일 조작을 담당하는 보조 스크립트(dream.sh, 410행)이다. 스크립트의 서브 커맨드(subcommand)는 list(전체 메모리 내용 출력)·backup(백업 생성)·apply(변경 적용)·restore(복원)의 4가지이며, 의미 분석 자체는 Claude가 담당한다.

정리 내용은 3가지 작업으로 이루어진다.

• 중복 병합(Merge): 동일한 운용 규칙이나 설정값이 2개 이상의 파일에 존재하는 경우, 상세하거나 최신 기술을 가진 쪽으로 통합하고 다른 한쪽은 삭제 후보로 만든다. -
• 모순 및 노후화(Obsolescence) 탐지: 동일한 설정에 대해 서로 다른 값이 여러 파일에 있거나, "폐지" 또는 "구 사양"이라고 주석 처리된 기술을 탐지하여 업데이트 안을 제시한다. -
• 새로운 인사이트 추출: 여러 파일을 가로질러 보이는 경향(예: "feedback 계열 파일의 상당수가 위임 비용(delegation cost)을 언급하고 있음")을 기술한다.

설계상 내가 가장 중시한 것은 **쓰기 안전성(write safety)**이다. /dream은 기본적으로 dry-run 모드로 동작한다. 변경 안을 제시할 뿐, 파일에는 일절 손을 대지 않는다. 실제로 쓰려면 --apply를 명시적으로 붙여야 하며, 그 후 yes 확인 과정을 거쳐야 한다. 쓰기 전에는 반드시 백업을 수행하며(tmp/dream-backup/YYYYMMDD-HHMM/), restore 서브 커맨드로 언제든 되돌릴 수 있다.

구체적인 실행 이미지는 다음과 같다.

# 우선 변경 안만 확인한다 (기본적으로 dry-run, 쓰기 없음)
/dream
# 출력 예시:
...

즉 "AI가 분석하고, 인간이 한 건씩 승인하며, 인간의 승인 없이는 1바이트도 바뀌지 않는다"라는 설계다. 자동 업데이트 선택지는 내 구현에는 애초에 존재하지 않는다.

대비: 설계의 무엇이 다른가

양자를 나란히 놓고 보면, 표면적으로는 "메모리를 정리한다"라는 동일한 목표로 보인다. 하지만 설계의 전제가 다르다.

공통점은 명확하다. 둘 다 "AI가 패턴을 추출하여 메모리를 정돈한다"라는 발상에 서 있다. 그리고 둘 다 인간이 리뷰할 수 있는 경로를 가지고 있다.

차이점의 핵심은 리뷰가 기본적으로 켜져 있는지(On) 꺼져 있는지(Off) 여부에 있다. 공식 Dreaming은 리뷰를 "선택할 수 있다"——뒤집어 말하면, 리뷰를 거치지 않고 자동으로 메모리를 업데이트시키는 운용이 공식적으로 상정되어 있다. 반면, 나의 /dream은 리뷰를 건너뛸 수단이 없다. dry-run (드라이 런)을 생략하고 바로 기록하는 경로를 나는 일부러 구현하지 않았다.

이 차이는 기능의 우열이 아니다. "AI에게 메모리 설계를 어디까지 맡길 것인가"라는 설계 판단의 차이다.

자체 제작 /dream과 Dreaming, 어느 쪽을 선택해야 할까?

지금까지의 대비를 한마디로 요약하면, 양자는 "제어권을 내려놓는 지점"이 다르다.

공식 Dreaming의 자동 업데이트 모드는 메모리 정리를 AI에게 맡기는 **위임 모델 (Delegation Model)**이다. 인간은 방침을 설정하면, 나머지는 AI가 스케줄에 따라 정리한다. 리뷰를 거칠 수도 있지만, 거치지 않는 운용도 성립한다. 팀 규모가 크고 에이전트(Agent)의 수가 많아 건건이 리뷰하는 것이 현실적이지 않은 상황에서는 이 위임이 합리적이다. Harvey 사처럼 다수의 에이전트를 운용하는 조직에게는 메모리가 자동으로 성장하는 가치가 리뷰를 생략하는 리스크를 상회할 것이다.

나의 /dream은 메모리 설계를 인간이 계속 쥐고 있는 **관리 모델 (Management Model)**이다. AI는 분석과 제안까지 담당하지만, 무엇을 채택할지는 반드시 내가 결정한다. 이는 내가 개인적으로 운용하고 있으며, 메모리 한 건 한 건이 기사 작성이나 운용 규칙에 직결되기 때문이다. "기사의 1인칭은 나"와 같은 규칙이 의도치 않게 바뀌면, 후속되는 모든 결과물에 영향을 미친다. 그래서 나는 정리의 자동화보다 매번 검토하는 비용을 선택했다.

어느 쪽이 옳다는 이야기가 아니라, 자신의 케이스에 대입할 수 있는 판단 기준이 3가지 있다.

• 에이전트의 수: 수십 개 이상을 동시에 운용하고 있어 모든 변경 사항을 수동으로 리뷰하는 것이 현실적이지 않다면 → 위임 모델에 가깝게
• 메모리 1건의 영향 범위: 파일 1개의 수정이 다수의 결과물(기사, 규칙, 외부 전송)로 파급된다면 → 관리 모델로 계속 쥐고 있음
• AI의 정리 결과에 대한 신뢰 수준: 아직 정밀도를 검증 중이라면 → 관리 모델로 시작하여 실적을 쌓은 뒤 위임을 늘림

나의 경우에는 "개인 운용 · 영향 범위가 넓음 · 아직 신뢰도를 검증 중"이므로 관리 모델을 선택했다. 하지만 향후 Dreaming을 사용할 수 있게 되고 정리 정밀도를 검증할 수 있다면 판단은 바뀔 수 있다.

공식 Dreaming과 Playbook을 공존시키는 설계——GA 이후에 무엇을 맡길 것인가

마지막으로, 양자는 이분법적인 선택 사항이 아니라는 점을 말해두고 싶다.

내가 /dream을 통해 배운 것은 정리 기능 그 자체보다 "어떤 변경을 채택하고 어떤 것을 기각할 것인가"라는 리뷰의 요령이다. 중복 병합(Merge)에서 상세한 쪽을 남길 것인가, 모순 탐지에서 새로운 값을 취할 것인가——이러한 판단 기준은 설령 향후 Dreaming을 도입하더라도 헛되지 않는다. 오히려 "Dreaming이 후보를 내고, 내가 쌓아온 기준으로 채택 여부를 결정한다"라는 구도로 발전시킬 수 있다. 위임 모델과 관리 모델은 레이어를 나누면 공존할 수 있다.

현시점에서 무엇이 다음 분기점인지를 정리해 둔다. Dreaming은 Research Preview 상태이며, 나는 아직 웨이트리스트(Waitlist)의 앞단에 있다. GA(General Availability, 일반 제공)로의 이행, 혹은 구독 서비스 범위에서의 제공이 다음 분기점이 될 것이다. 그때까지 할 수 있는 일은 자체 제작한 /dream으로 리뷰 판단 기준을 계속 언어화하는 것이다. 비교 대상을 자신의 손에 쥐고 있으면, 공식 기능이 나왔을 때 "무엇을 맡기고 무엇을 계속 쥐고 있을지" 즉각 판단할 수 있다.

테스트해 볼 수 없는 기능이라도 사양(Specification)으로부터 원칙은 읽어낼 수 있다. 그리고 자체적으로 유사한 것을 만들면 "비교할 수 있다"라는 부수적인 이득을 얻는다. 만약 당신이 메모리 관리 체계를 설계한다면, 처음에 물어야 할 것은 "어떤 기능을 사용할 것인가"가 아니라 "제어권을 어디서 내려놓을 것인가"——즉, 위임 모델과 관리 모델 중 어느 쪽을 선택할 것인가라고 생각한다.

내일 바로 할 수 있는 1가지 액션: ~/.claude/projects/*/memory/ 하위의 파일들을 ls로 목록화해 보기. 파일 수와 내용을 훑어보는 것만으로 충분하다. 비슷한 규칙이 적힌 파일이 2개 발견된다면, 그것이 당신의 /dream 설계, 혹은 Dreaming 도입 판단의 출발점이 될 것이다.

관련 기사

• Claude 에이전트는 잠자는 동안 성장한다 —— Dreaming 기능으로 태스크 완료율이 6배 증가한 메커니즘 (본 기사의 전제: Dreaming 기능 소개)
• Claude Code Max 5x에 월 $100 크레딧 —— Agent SDK와 대화형 사용의 과금 분리 분석 (Claude Managed Agents의 과금 구조)
• "후보를 올려줘"라는 한마디로 50분 만에 12개 스킬 완성 —— Claude Code가 스스로 설계·구현·push한 실록 (Claude의 자기 개선 루프 실례)

Zenn Book 시리즈

• 코드를 못 쓰는 내가 Claude Code로 「AI 팀」을 만들기까지 (Vol.1)
• 코드를 못 쓰는 내가 Claude Code로 「AI 팀」을 운영하기까지 (Vol.2)
• 코드를 못 쓰는 내가 Claude Code로 「AI 팀」과 계속 써 내려가기까지 (Vol.3)

출처

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

• Claude Managed Agents 신청 양식 (웨이트리스트제):
  https://claude.com/form/claude-managed-agents

• 자체 제작 /dream

스킬 구현값 (dream.sh 410행 · dream.md 269행 · 메모리 개별 파일 43개)은 2026-06-08에 실측

이 기사는 はてなブログ(Hatena Blog)로부터의 크로스 포스트입니다.

Discussion