Claude Dreaming 들여다보기, sub-agent 메모 모순이 새벽에 정리된 자리

 

어제 새벽 두 시, MEMORY.md를 열어보다가 한숨이 나왔습니다. Sub-agent 네 개가 남긴 메모가 서로 어긋나 있었거든요. /dream 한 줄에 손이 갔던 순간이었어요.

 

Claude Dreaming, 망각을 자동화하는 4단계 사이클

앤스로픽(Anthropic)이 2026년 5월에 공개한 클로드 매니지드 에이전트(Claude Managed Agents) 플랫폼의 신기능입니다. 모델 자체는 GA(정식 출시)지만, Dreaming 기능은 현재 리서치 프리뷰(research preview) 단계로 제공되고 있어요. 이름은 '꿈'이지만 의인화된 무언가는 아니고, 누적된 메모리를 입력받아 정리된 새 메모리를 출력하는 consolidation 작업입니다. 다만 단순한 결정론적 배치 잡이 아니라, consolidation 모델이 LLM 추론을 수행하는 sub-agent 형태로 돌아간다는 점이 중요해요. 뒤에서 다룰 "추론을 사실로 굳히는 위험"이 바로 여기서 출발합니다.

 

지원 모델은 클로드 오푸스(Claude Opus) 4.7과 클로드 소넷(Claude Sonnet) 4.6입니다. 세션이 어느 정도 쌓이면 백그라운드에서 자동으로 돌아가거나, /dream 명령어로 직접 호출할 수도 있어요.

 

작동은 네 단계로 진행됩니다.

1. Gather Signal: 현재 MEMORY.md 인덱스와 토픽 파일, 최근 sub-agent 로그를 훑어 신호를 수집
2. Consolidate(Merge): 여러 sub-agent의 중복 노트와 부분 결론을 하나의 통합 엔트리로 병합
3. Prune & Index: 오래되거나 모순된 정보를 제거하고(Agent A의 "규칙 X 적용"과 Agent B의 "규칙 X 폐기" 기록 중 최신 결정만 채택), 정리된 내용으로 새 MEMORY.md 인덱스를 생성
4. Reindex(상위 통찰 승격): 핵심 통찰을 상위 레벨로 끌어올려 후속 sub-agent가 바로 참조하도록 배치

핵심은 기억 강화가 아니라 삭제와 압축에 가깝습니다. 무엇을 남길지보다 무엇을 지울지를 결정하는 작업이라는 얘기예요. HITL(Human-in-the-Loop)이나 Task Budgets 같은 운영 장치와 같이 놓고 봐야 하는 이유도 그래서고요.

 

 

Sub-agent 네 개의 메모 모순, /dream이 정리한 자리

도입부에 한숨 쉬었던 그 새벽 이야기로 돌아가볼게요. 안드로이드 리팩토링 프로젝트에 sub-agent 네 개를 돌리고 있었습니다. 하나는 모듈 분리, 하나는 의존성 정리, 하나는 테스트 보강, 하나는 컨벤션 점검 담당이었어요.

 

일주일쯤 돌리고 나니 MEMORY.md 안에서 같은 클래스에 대해 서로 다른 결론이 누적돼 있더라고요. 예를 들면 이런 식이었어요.

- [moduleSplitter] 이 클래스는 분리 대상
- [dependencyCleaner] 이미 분리 완료
- [conventionChecker] 분리 보류 (네이밍 충돌)

 

어느 게 최신인지 사람이 한 줄씩 따라가서 확인해야 했네요.

 

/dream을 한 번 돌렸더니 Consolidate 단계에서 세 sub-agent의 부분 전략을 한 줄로 합쳐 놓고, Prune & Index 단계에서 폐기된 결정을 잘라냈습니다. 후속 호출의 토큰 비용도 체감상 30~40% 정도 줄어드는 경우가 많았어요. (다만 이건 제 안드로이드 리팩토링 프로젝트 하나, sub-agent 4개 표본에서의 체감치라 일반화할 수치는 아닙니다.)

 

이게 단순한 토큰 절약보다 효과가 큰 이유는, sub-agent들이 다음 세션에서 이미 합의된 결정 위에서 출발한다는 점입니다. 매번 모순을 사람이 풀어주지 않아도 된다는 점이 컸어요.

 

 

/dream 운영의 함정, Prompt Injection 영속화 위험

다만 마냥 신뢰하기에는 걸리는 자리가 있습니다.

 

독립 3자 벤치마크가 아직 없는 상태라, 정확도를 객관적으로 검증할 방법이 지금 시점에서는 보이지 않습니다. 앤스로픽이 공개한 Harvey나 Wisedocs 같은 사례 수치도 결국 1차 파트너 발표라는 점은 감안해야 해요.

 

더 까다로운 건 추론을 사실로 굳히는 위험입니다. Dreaming 자체가 LLM 추론을 돌리는 sub-agent다 보니, sub-agent들의 추측을 통합하다가 잘못된 패턴을 "합의된 결론"으로 영구 메모리에 박아넣으면, 후속 에이전트 전체가 그 오염된 가정 위에서 작업하게 됩니다.

 

보안 이슈도 더해지는데요, 외부 데이터를 다루는 세션이 Prompt Injection으로 오염됐다고 가정해볼게요. 그 오염된 지시가 Consolidate 단계를 통해 영구 메모리에 침투하면, 일회성 공격이 영속화되는 새로운 경로가 열릴 수 있어요.

 

벤더 종속성도 고민거리네요. Dreaming에 작업 흐름을 최적화할수록 다른 LLM으로 옮기는 비용이 커집니다. 메모리·평가·오케스트레이션이 한 플랫폼에 묶이는 구조더라고요.

 

/dream 운용법과 메모리 백업 루틴

개인적으로는 모든 세션에 /dream을 자동으로 걸어두진 않고 있습니다. 외부 데이터를 만지지 않는 안드로이드 리팩토링 sub-agent 군에만 수동으로 돌리고, 결과를 사람이 한 번 훑은 뒤 커밋하는 방식이에요. HITL 게이트를 한 번은 끼워둔다는 뜻이죠.

 

메모리 파일은 매주 깃허브의 별도 비공개 리포지토리에 플레인 텍스트로 백업하고 있습니다. 플랫폼 중립 포맷을 유지해두면 다른 도구로 옮기더라도 메모리 자산은 살릴 수 있으니까요.

 

 

마치며

Claude Dreaming은 기억을 강화하는 도구가 아니라, 망각을 자동화하는 도구입니다. 무엇이 노이즈이고 무엇이 신호인지 판단하는 책임은 운영자 본인에게 그대로 남아있어요.

 

/dream 한 줄로 새벽의 한숨은 줄었습니다. 그 대신 다음 날 아침에 정리된 MEMORY.md를 사람이 다시 한 번 읽고 머지하는 시간이 일정에 새로 들어왔어요. 이 검증 한 토막을 일정에서 빼버리면 자동화가 만들어낸 결정에 사람이 손댈 자리가 사라집니다.