Claude가 자는 사이 메모리에서 일어나는 일

자고 있는 동안 뇌가 하는 일이 있어요. 낮 동안 받은 자극과 학습을 정리하고, 중요한 패턴을 장기 기억으로 옮기고, 다음 날 쓸 워크플로우를 다듬어 둡니다. 이걸 사람이 의식적으로 하지 않아도 자동으로 돌아가요.

Anthropic이 5월 6일 Code with Claude 컨퍼런스에서 공개한 dreaming은 Claude 에이전트한테 같은 종류의 정리 시간을 주는 기능이에요. 액티브 세션 사이에 스케줄된 백그라운드 프로세스가 돌면서 과거 세션 log와 memory store를 검토하고, 패턴을 추출해서 다음 세션이 참조할 새 memory store를 생성합니다. 모델 가중치는 안 건드려요. 사람이 들여다볼 수 있는 일반 텍스트 노트와 playbook 파일로 결과가 떨어집니다.

이 글이 짚으려는 건 작명입니다. dreaming이 새 기능 하나인지, Anthropic이 4월 8일 출시한 Managed Agents 아키텍처 위에서 의도한 다음 카드인지가 의사결정자가 가져야 할 진짜 질문이에요.

Managed Agents 아키텍처의 다음 카드

Anthropic은 4월 8일 Claude Managed Agents를 public beta로 출시하면서 brain·hands·session을 분리한 아키텍처를 공개했어요. Claude와 harness는 brain, tool 실행 환경(컨테이너)은 hands, append-only 이벤트 log는 session. 셋이 독립 인터페이스로 묶여 있어서 brain이 실패해도 session log에서 복구할 수 있고, hands가 죽어도 세션은 살아남습니다.

Anthropic 엔지니어링 블로그가 "how to design a system for programs as yet unthought of"라고 표현한 이 디자인의 핵심은 세션 log가 컨텍스트 윈도우 외부에 안정적으로 살아있다는 점이에요. compaction이나 컨텍스트 트리밍처럼 돌이킬 수 없는 결정으로 정보를 잃지 않고, harness가 필요할 때 log를 다시 잘라서 읽어옵니다.

이 구조 위에서 dreaming이 자연스럽게 떠올라요. 세션 log가 영속적이고 검색 가능하다면, 세션 사이 빈 시간에 그 log들을 가로질러 패턴을 뽑는 별도 프로세스를 굳이 못 돌릴 이유가 없습니다. dreaming은 그걸 정식 API로 만든 거예요. Dreams API는 입력 memory store와 최대 100개의 prior session을 받아서 새 output memory store를 생성합니다. 입력 store는 그대로 유지 — 사람이 dream 결과를 들여다본 뒤 채택할지 폐기할지 결정해요.

Anthropic의 Research PM Alex Albert는 컨퍼런스에서 dreaming을 "사람이 Claude와 이리저리 헤맨 워크플로우 끝에 스킬을 기록하는 것 — 그걸 모델이 자동으로 하는 것"이라고 정리했어요. 즉 dreaming은 모델 학습이 아니라 운영 자산을 자동으로 정리해 두는 행위입니다.

Dreams API가 발견하는 세 가지

dreaming이 발견하는 패턴은 단일 세션이 절대 볼 수 없는 종류예요.

• 반복 실수 — 같은 CLI 플래그를 매번 잘못 쓰는 패턴, 같은 파일 포맷을 매번 오해하는 패턴, 같은 디버깅 워크플로우를 매주 재발견하는 패턴
• 수렴하는 워크플로우 — 여러 에이전트가 독립적으로 같은 절차에 도달하는 경우. 그게 정식 playbook이 될 신호
• 팀 공통 선호 — 한 팀의 여러 세션이 공통으로 쓰는 컨벤션·도구 선호

Anthropic 라이브 데모는 가상 항공우주 스타트업 Lumara가 달 자원 채굴용 자율 드론을 착륙시키는 시나리오였어요. Commander·Detector·Navigator 3개 전문 에이전트가 6개 사이트에서 시뮬레이션을 돌렸고, 결과는 강했지만 완벽하지는 않았어요. 다음날 dreaming을 한 번 돌리니 descent-playbook.md 파일이 생성됐고, 같은 시뮬레이션을 다시 돌렸을 때 이전에 성능이 낮았던 사이트들의 결과가 의미 있게 개선됐어요.

dreaming만 단독으로 도착한 게 아니에요. 같은 발표에서 Outcomes(별도 채점 에이전트가 새 컨텍스트 윈도우에서 채점 기준으로 평가 → 작업 에이전트 재시도)와 Multi-agent Orchestration(주도 에이전트가 전문 에이전트에게 위임)이 research preview에서 public beta로 승격됐어요. 셋이 묶이면 다중 에이전트로 작업 분할 → Outcomes로 평가 → dreaming으로 다음 세션을 위한 playbook 정리라는 지속 개선 루프가 됩니다.

숫자가 말하는 것

dreaming의 임팩트가 의사결정자한테 의미가 있으려면 실제 운영 수치가 필요해요. Anthropic이 공개한 것 중 가장 큰 숫자는 Harvey 사례입니다.

거시 신호도 같이 봐야 해요. Anthropic 1Q 2026 매출·사용량은 회사가 10배 성장 가정으로 계획했음에도 80배 연환산이 나왔고, API 볼륨은 70배 전년 대비로 증가했어요. CEO Dario Amodei가 fireside chat에서 "그래서 컴퓨팅 부족 사태를 겪었다"고 인정한 배경입니다. Mercado Libre는 23,000명 엔지니어가 Claude Code를 쓰면서 50만 건 넘는 PR을 리뷰했고, 2026 Q3까지 90% 자율 코딩을 목표로 한다고 발표했어요.

이 수치들은 의사결정자한테 두 가지를 말합니다. 첫째, dreaming은 실제 운영 부하를 다루는 팀들이 이미 의미 있는 결과를 내고 있는 기능이에요. 둘째, Anthropic 플랫폼 위에서 돌아가는 워크플로우의 절대 규모가 빠르게 커지고 있어서, 지금 Anthropic이 출시하는 것은 그 규모를 감당하기 위한 운영 도구에 가깝습니다.

한 곳에 다 모은다는 위험

같은 발표를 다르게 읽는 시각도 있어요. VentureBeat 5월 8일 후속 기사 제목이 "Anthropic이 당신 에이전트의 메모리·평가·오케스트레이션을 다 가져가려 한다 — 이건 enterprise한테 nervous한 일이다"였습니다.

논점은 명확해요. 많은 기업이 지금까지 LangGraph·CrewAI(오케스트레이션) + Pinecone(벡터 메모리) + DeepEval(평가) + human-in-the-loop QA를 모듈식 스택으로 조합해서 썼어요. dreaming + outcomes + multi-agent orchestration이 한 번에 묶여 도착하면서 그 모듈식 스택의 각 레이어가 Anthropic 플랫폼 안으로 흡수될 수 있는 시나리오가 열렸습니다. 완전 호스팅 런타임이라 데이터 보관지 입증이 까다롭다는 규제 준수 우려도 같이 따라옵니다.

보안 시각에서 한 가지를 더 짚어 둘 만해요. dreaming은 오래 살아남는 영향 통로입니다. memory store가 오염되면 dreaming이 오염된 학습을 통합해서 다음 세션 모두에 전파해요. 그래서 읽기 전용 조직 store + 읽기 전용 프로젝트 store + 읽기·쓰기 작업 store의 3-store 레이아웃, 그리고 dream 결과를 실제 운영 메모리에 채택하기 전에 검토 게이트를 두는 패턴이 권장됩니다.

의사결정자가 지금 처음 할 일

dreaming이 정식 출시되기 전이라도 지금 할 수 있는 결정은 세 개예요.

1. research preview 접근 신청 — Managed Agents에서 dreaming을 쓰려면 별도 신청이 필요해요. Anthropic 플랫폼 위에서 실제 운영 에이전트를 굴리고 있거나 검토 중이라면 줄을 서 두는 게 합리적이에요
2. 현재 스택 점검 — 지금 쓰는 메모리·평가·오케스트레이션 도구가 각각 어떤 레이어를 담당하는지 정리. 어디까지가 대체 가능한 범용 부품이고 어디부터가 바꾸면 위험한 도메인 자산인지 분리해야 dreaming이 도착했을 때 합리적 결정이 가능해요
3. dream 결과 검토 게이트 설계 — 자동 채택은 빠르지만 메모리 오염 통로예요. 처음에는 사람이 검토한 뒤 채택하는 모드로 시작하고, 신뢰가 쌓이면 자동으로 옮기는 단계적 접근

작명이 비유라는 비판은 정당해요. 다만 그 비유 뒤에 있는 메커니즘은 OS-level의 메모리 큐레이션이고, Anthropic이 4월에 깔아둔 Managed Agents 아키텍처가 그 위에서 자연스럽게 꺼낸 다음 카드입니다. 메모리는 모델 가중치가 아니라 운영 가능한 파일이다 — 이 한 줄이 dreaming이 풀려는 진짜 페인의 정의예요.

자주 묻는 질문

dreaming은 Claude의 모델 가중치를 바꾸나요?

아니에요. dreaming은 모델 학습이 아니라 일반 텍스트 노트와 playbook 파일을 자동으로 정리하는 운영 자동화입니다. 결과물은 사람이 들여다보고 채택 여부를 직접 결정해요.

dreaming을 지금 쓰려면 어떻게 해야 하나요?

Claude Managed Agents 위에서 research preview 접근을 별도 신청해야 해요. public beta가 아니라 접근을 받은 개발자만 즉시 적용 가능하고, 5월 6일 발표 직후라 대기열이 길 수 있어요.

자체 모듈식 스택을 쓰는 팀은 dreaming으로 갈아타야 하나요?

즉시 갈아탈 필요는 없어요. 각 레이어(메모리·평가·오케스트레이션)가 범용 부품인지 도메인 자산인지 먼저 점검하고, 갈아탔을 때 잃는 비용과 통합으로 얻는 비용을 비교한 뒤 결정하는 게 안전합니다.

dreaming과 기존 Memory 기능의 차이는 무엇인가요?

Memory는 단일 세션이 자기 컨텍스트를 파일로 저장하는 기능이에요. dreaming은 그 위에서 여러 세션을 가로질러 패턴을 추출해 새 memory store를 만드는 상위 레이어입니다. 둘이 묶여야 자가 개선 메모리 시스템이 됩니다.

dreaming이 메모리 오염 위험을 키우지 않나요?

키울 수 있어요. 오염된 세션이 입력으로 들어가면 dreaming이 잘못된 패턴을 통합해 다음 세션 모두에 전파해요. 읽기 전용 조직 store와 읽기·쓰기 작업 store를 분리하고, dream 결과는 사람 검토 후 채택하는 구조가 권장돼요.

dreaming은 어떤 작업에 가장 효과적인가요?

같은 실수를 반복하거나, 여러 에이전트가 독립적으로 같은 워크플로우에 도달하거나, 팀 전체가 공통 컨벤션을 공유해야 하는 장기 실행·다중 에이전트 작업이 가장 효과적이에요. 일회성 작업엔 ROI가 작아요.

dreaming은 Claude Code에서도 쓸 수 있나요?

발표 시점 기준 dreaming은 Claude Managed Agents 전용 research preview예요. Claude Code는 별개 라인으로 routine·code review·remote agent 같은 다른 업데이트가 같은 컨퍼런스에서 같이 발표됐어요.

Anthropic이 outcomes·multi-agent까지 묶어 발표한 이유가 뭔가요?

셋이 묶여야 지속 개선 루프가 닫혀요. 다중 에이전트로 분할하고 outcomes로 평가하고 dreaming으로 다음 세션 playbook을 정리하는 흐름이에요. 한 기능만으로는 기업이 실제 운영에 위임할 수준에 못 이른다는 판단입니다.

작성: Bruce Choe · agenticworkflows.club