AI 코딩 어시스턴트를 오래 쓰다 보면 이상한 순간이 옵니다. 어제 고친 버그는 잊어버리면서, 한 달 전 임시 우회책은 계속 "프로젝트 규칙"처럼 믿습니다. 문제는 기억 용량이 부족한 것이 아니라, 무엇을 믿을 만한 지식으로 남길지 정리하는 기준이 부족하다는 데 있습니다.
최근 Claude의 "Dreaming"이 주목받는 이유도 여기에 있습니다. The Decoder는 이 기능을 에이전트가 과거 실수에서 배우도록 설계된 기능으로 소개했고1, Anthropic은 Claude Managed Agents에서 Dreaming을 연구 프리뷰로 공개했습니다. Dreaming은 과거 세션과 메모리 저장소를 주기적으로 검토해 반복 실수, 팀 선호, 워크플로 패턴을 추출하고 메모리를 정리하는 과정입니다2.
핵심은 더 많이 기억하는 것이 아니라 덜 위험하게 믿는 것
Dreaming을 단순히 "Claude가 잠자는 동안 기억을 정리한다"로 이해하면 절반만 맞습니다. 실무적으로는 메모리의 유지보수 레이어에 가깝습니다.
기존 메모리는 작업 중 알게 된 사실을 저장합니다. 예를 들어 빌드 명령어, 디버깅 패턴, 코드 스타일, 아키텍처 결정 같은 것들입니다. Dreaming은 그 뒤에 일어납니다. 여러 세션을 되돌아보고 중복된 메모리를 합치고, 낡은 내용을 제거하고, 반복되는 실패를 더 일반적인 규칙으로 바꿉니다.
이 변화가 중요한 이유는 장기 프로젝트에서 AI의 오류가 "모르는 것"보다 "잘못 기억하는 것"에서 자주 나오기 때문입니다. 오래된 API 구조, 폐기된 브랜치의 임시 해결책, 한 번뿐이었던 예외 처리가 메모리에 남으면 에이전트는 더 자신 있게 틀릴 수 있습니다.
따라서 Dreaming의 가치는 저장 공간 확장이 아니라 증거 위계 정리에 있습니다. 무엇이 공식 문서인지, 무엇이 세션 중 관찰인지, 무엇이 아직 논쟁 중인 결정인지 구분하지 않으면 깔끔한 메모리도 위험합니다.
Dreaming에 맡겨도 되는 기억과 안 되는 기억
Dreaming에 잘 맞는 정보는 시간이 지나도 비교적 안정적인 지식입니다.
예를 들면 이런 것들입니다.
프로젝트의 아키텍처 원칙
반복되는 테스트·빌드 절차
팀의 네이밍 규칙과 코드 스타일
사용자가 자주 교정한 실수
여러 에이전트가 반복해서 발견한 작업 패턴
반대로 자동 정리에 맡기기 위험한 정보도 있습니다.
임시 버그, 실험 브랜치의 가정, 보안 정보, 아직 합의되지 않은 제품 결정, "이번 배포에서만" 적용한 우회책은 Dreaming이 요약해 장기 기억으로 승격시키면 안 됩니다. 특히 에이전트가 여러 개로 나뉘어 병렬 작업하는 환경에서는 한 에이전트의 제한된 관찰이 전체 프로젝트의 규칙처럼 굳어질 수 있습니다.
Anthropic은 Dreaming이 자동으로 메모리를 업데이트하게 할 수도 있고, 반영 전 사람이 검토하게 할 수도 있다고 설명합니다2. 실무에서는 후자가 기본값이어야 합니다. 적어도 초기 도입 단계에서는 "자동 정리"보다 "자동 제안 + 사람 승인" 모델이 안전합니다.
깨끗한 메모리도 틀릴 수 있다
Dreaming의 숨은 실패 모드는 지저분함이 아니라 과도한 정돈입니다. 요약은 항상 손실을 동반합니다.
예를 들어 "Redis를 캐시로 쓰기로 했다"는 문장은 깔끔합니다. 하지만 실제 맥락이 "트래픽 급증 대응을 위해 2주간만 Redis를 실험한다"였다면, Dreaming은 임시 결정을 영구 아키텍처로 바꿔버릴 수 있습니다.
또 다른 문제는 소수 맥락의 삭제입니다. 다수 세션에서 반복된 패턴이 항상 옳은 것은 아닙니다. 특정 장애 상황에서만 유효한 예외, 한 고객사에만 적용되는 요구사항, 보안팀이 보류한 결정은 빈도만으로 판단하면 사라지기 쉽습니다.
그래서 Dreaming을 도입할 때는 메모리 파일을 이렇게 나누는 편이 좋습니다.
stable: 장기적으로 유지할 규칙과 원칙working: 현재 진행 중인 가정과 임시 판단decisions: 결정 내용, 날짜, 근거, 변경 이력do-not-summarize: 원문 보존이 필요한 민감하거나 논쟁적인 맥락
Dreaming은 원문 문서를 대체하기보다 색인과 요약을 갱신하는 역할에 머물러야 합니다. 중요한 결정은 반드시 출처 링크, 날짜, 승인자를 함께 남겨야 합니다.
Claude Code의 Auto Dream과는 구분해야 한다
혼동할 지점도 있습니다. 현재 공식 발표의 Dreaming은 Claude Platform의 Managed Agents 기능입니다. 반면 Claude Code 쪽에서는 커뮤니티를 통해 Auto Dream 토글이나 관련 동작이 보고됐지만, 문서화 상태와 사용 가능 여부가 사용자별로 달랐다는 분석이 있습니다3. 즉 "Claude 전체에 동일한 Dreaming이 완전히 배포됐다"고 단정하면 안 됩니다.
Managed Agents의 Dreaming은 장시간 실행되는 에이전트, 여러 하위 에이전트, 공유 메모리, 결과 평가 같은 흐름과 함께 설계된 기능입니다. Anthropic은 같은 발표에서 Outcomes와 multiagent orchestration도 함께 공개했는데, 이는 에이전트가 기억만 하는 것이 아니라 성공 기준에 맞춰 다시 시도하고, 여러 에이전트의 작업을 조율하는 방향으로 제품이 이동하고 있음을 보여줍니다2.
결론은 간단합니다. Dreaming은 "AI가 똑똑해지는 마법"이 아니라 "AI가 무엇을 배웠다고 믿어도 되는지 관리하는 장치"입니다. 장기 코드베이스, 리서치 자동화, 고객별 운영 에이전트를 쓰는 팀이라면 지금부터 메모리 구조를 설계해야 합니다. 반대로 작업이 짧고, 맥락이 자주 바뀌며, 결정 근거가 민감한 조직이라면 자동 반영보다 검토 워크플로부터 만드는 것이 먼저입니다.
앞으로 봐야 할 변화는 모델 성능보다 메모리 거버넌스입니다. 좋은 에이전트는 많이 기억하는 에이전트가 아니라, 잊어야 할 것을 알고 의심해야 할 기억에 표시를 남기는 에이전트가 될 가능성이 큽니다.
참고
1Claude's new "Dreaming" feature is designed to let AI agents learn from their mistakes
2New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration
3Claude Code Auto Memory vs Auto Dream 정리 : AI가 잠자면서 기억을 정리한다? Auto Dream 기능의 진실
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.