Claude Code v2.1.83 기준
IT/AI
Claude Code Auto Dream, 켜져 있어도 안 되는 경우 있습니다
/memory 메뉴에서 Auto-dream: off를 확인했다면 설정 문제가 아닙니다. 서버에서 막혀 있는 겁니다. 이 기능이 뭔지, 왜 아직 못 쓰는지, 지금 당장 쓰는 방법은 있는지 — 직접 확인한 내용을 정리했습니다.
Auto Dream이 나온 이유 — Auto Memory만으로는 부족한 이유가 있습니다
Claude Code는 2026년 2월부터 Auto Memory라는 기능을 제공하기 시작했습니다. 세션을 진행하는 동안 Claude가 스스로 메모를 남기는 기능인데, 빌드 명령어나 아키텍처 결정, 코딩 스타일 같은 것들을 자동으로 MEMORY.md 파일에 기록합니다. Anthropic 기술 스태프 Thariq Shihipar의 설명대로, CLAUDE.md는 사용자가 Claude에게 내리는 지시이고, MEMORY.md는 Claude가 스스로 쌓아가는 메모장입니다. (출처: tessl.io, 2026.03.26)
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다
Auto Memory를 20~30회 이상 사용하면 메모 품질이 오히려 떨어집니다. 직관과 반대인데, 기록이 많을수록 더 정확해질 것 같지만 실제로는 “오래된 노트”가 쌓이면서 Claude가 이미 삭제된 파일의 디버그 해결책을 진짜인 것처럼 참조하기 시작합니다. 메모가 많을수록 Claude가 더 잘 기억한다는 전제 자체가 틀렸습니다.
실제로 자주 발생하는 문제를 나열하면 이렇습니다. “어제 Redis로 결정했다”는 메모는 3주 뒤에도 그대로 남아 시제가 깨지고, “API는 Express를 쓴다”는 항목이 Fastify로 마이그레이션한 이후에도 살아 남아 충돌합니다. 세 개의 세션에서 동일한 빌드 명령어를 메모해 중복이 생기고, MEMORY.md 자체가 200줄을 넘으면 그 이후 항목은 세션 시작 시 아예 로드되지 않습니다. 200줄이 시작 시 로드 한도라는 건 공식 문서에 그대로 나와 있습니다. (출처: claudefa.st/blog/guide/mechanics/auto-dream)
Auto Dream은 이 문제를 해결하려는 기능입니다. 메모를 쌓는 Auto Memory의 “낮 시간 기록” 단계와 짝을 이루는 “밤 시간 정리” 단계입니다.
4단계 처리 구조 — 실제로 무슨 일이 벌어지는지
Auto Dream이 실행되면 4개의 단계를 순서대로 거칩니다. (출처: institute.sfeir.com, 2026.03.26)
Orientation
메모리 디렉토리를 스캔하고 MEMORY.md를 읽어 현재 상태를 파악합니다.
Signal Gathering
세션 트랜스크립트(JSONL 파일)를 전수 검토하는 것이 아니라 특정 패턴만 grep 방식으로 검색합니다. 전체를 읽으면 토큰 비용이 폭증하기 때문입니다.
Consolidation
핵심 단계입니다. 상대 날짜를 절대 날짜로 변환하고, 모순되는 항목을 삭제하고, 중복을 병합합니다.
Prune & Index
MEMORY.md를 200줄 이하로 다듬고, 더 이상 존재하지 않는 파일 링크를 제거합니다.
실제 관측된 사례에서 Auto Dream은 913개 세션의 메모리를 약 8~9분 만에 처리했습니다. (출처: claudefa.st/blog/guide/mechanics/auto-dream) 이 수치가 의미하는 건 간단합니다 — 장기 프로젝트에서 수백 개 세션이 쌓여도 처리 시간은 커피 한 잔 마시는 시간입니다.
처리 전후를 비교하면 효과가 눈에 보입니다. 30개 이상 세션이 쌓인 프로젝트에서 280줄이 넘어가 있던 MEMORY.md가 정리 후 142줄로 떨어졌고, 삭제된 파일에 대한 디버그 노트와 충돌하는 기술 스택 항목들이 모두 제거됐습니다. 200줄 이하라는 게 단순한 깔끔함의 문제가 아니라, 그 기준을 넘으면 세션 시작 시 해당 항목들이 로드조차 안 된다는 실질적 제약이 있습니다.
한 가지 중요한 안전 장치가 있습니다. Auto Dream은 메모리 파일만 수정하고 소스 코드에는 절대 손대지 않습니다. 잠금 파일(lock file) 구조로 동시에 두 개의 Claude Code 인스턴스가 같은 프로젝트에서 실행되더라도 충돌이 생기지 않습니다. 백그라운드 실행이라 현재 세션을 차단하지도 않습니다.
켜져 있어도 안 되는 이유 — 서버 플래그 문제
⚠️ 주의: /memory 메뉴에서 Auto-dream 토글이 보인다고 해서 실제로 작동하는 게 아닙니다. Auto Dream은 서버사이드 피처 플래그(tengu_onyx_plover)로 제어됩니다. 로컬 settings.json을 아무리 수정해도 이 플래그를 건드릴 수 없습니다. (출처: dev.to/akari_iku, 2026.03.24)
기본값은 이렇게 고정돼 있습니다.
{
"enabled": false,
"minHours": 24,
"minSessions": 5
}
enabled: false는 Anthropic이 서버에서 제어합니다. 이 값을 로컬에서 true로 바꿔봤자 무효입니다. 2026년 3월 현재 점진적으로 롤아웃 중이며, Claude Code v2.1.83 이상에서 UI에는 보이지만 실제 자동 실행은 대부분 사용자에게 아직 열려 있지 않습니다. (출처: tessl.io, 2026.03.26)
💡 “설정 메뉴에 있으면 쓸 수 있다”는 가정이 어디서 깨지는지 보입니다
UI에 토글이 존재한다는 것과 그 토글이 실제로 기능을 켠다는 것은 다릅니다. Anthropic은 Auto Dream을 소리 없이 배포하면서 공식 발표 없이 UI만 먼저 노출했습니다. 자동 실행 조건(minHours: 24 + minSessions: 5)이 두 가지 모두 충족되더라도, 서버 플래그가 활성화되지 않은 계정에서는 아무 일도 일어나지 않습니다.
작동 조건 두 가지가 모두 충족돼야 자동 실행됩니다. 마지막 정리로부터 24시간 이상 경과했어야 하고, 그동안 5회 이상의 세션이 쌓였어야 합니다. 하나라도 충족되지 않으면 실행되지 않습니다. 하루에 한 번 긴 세션 하나만 진행한 경우처럼 세션 수가 5회 미만이면, 시간이 아무리 지나도 자동 실행은 없습니다.
지금 바로 쓸 수 있는 방법
자동 실행 플래그가 아직 열리지 않았더라도, 수동으로 즉시 실행하는 방법은 있습니다. Claude Code 세션 안에서 아래 중 하나를 입력하면 됩니다.
dream consolidate my memory files auto dream
이 명령들은 자동 실행 조건(24시간 + 5회 세션)을 기다리지 않고 즉시 4단계 정리 프로세스를 시작합니다. (출처: institute.sfeir.com, 2026.03.26) 공식 /dream 슬래시 커맨드는 아직 전체 롤아웃 전이지만, 대화 중에 직접 입력하면 동일하게 작동합니다.
언제 수동으로 실행하면 좋은지 정리하면 아래와 같습니다.
- 대규모 리팩터링 직후 — 파일명이나 디렉토리 구조가 크게 바뀌었다면, 오래된 메모가 없어진 경로를 계속 참조하게 됩니다.
- 기술 스택 전환 직후 — Express에서 Fastify로, REST에서 GraphQL로 바꿨을 때 이전 정보가 남아 있으면 혼란을 줍니다.
- MEMORY.md가 200줄을 넘겼을 때 — 그 이상의 항목은 세션 시작 시 로드되지 않아 사실상 없는 것과 같습니다.
- 세션 수가 30~50개를 넘었을 때 — 경험적으로 이 시점부터 메모 품질 저하가 느껴지기 시작합니다.
수동 실행 후에는 /memory 명령으로 결과를 확인할 수 있습니다. MEMORY.md가 줄어들었는지, 중복 항목이 정리됐는지 눈으로 확인해보는 게 좋습니다. 정리 결과가 마음에 안 들면 해당 파일은 일반 마크다운 파일이므로 직접 편집해도 됩니다.
이 기능이 비싸지 않을 수 있는 이유
처음 Auto Dream 설명을 보면 “백그라운드에서 세션 트랜스크립트를 분석한다”는 부분에서 토큰 비용 걱정이 드는 게 당연합니다. 하지만 설계 구조를 들여다보면 다릅니다.
💡 “백그라운드 처리 = 비용 폭탄”이라는 선입견이 설계를 보면 달라집니다
Phase 2(Signal Gathering)에서 세션 트랜스크립트를 전부 읽는 게 아니라 grep 방식으로 특정 패턴만 검색합니다. 사용자 수정 내역, 명시적 저장 요청, 반복 패턴, 주요 결정 사항 — 이 4가지만 추출하는 구조입니다. 500개 세션 전체를 읽는 것과 패턴만 추출하는 것의 토큰 비용은 자릿수가 다릅니다.
이 설계는 UC Berkeley와 Letta 팀의 논문 “Sleep-time Compute: Beyond Inference Scaling at Test-time”(arXiv:2504.13171, 2025년 4월)에서 이론적 근거를 찾을 수 있습니다. 이 논문은 테스트 타임에 컴퓨팅을 쏟아붓는 대신, 사용자가 쿼리를 보내기 전 유휴 시간에 미리 처리해두면 동일 정확도를 내는 데 필요한 테스트 타임 컴퓨팅이 약 5배 줄어든다는 것을 보여줬습니다. 멀티 쿼리 환경에서는 쿼리당 비용이 2.5배 절감됩니다. (출처: arXiv:2504.13171)
Auto Dream은 이 원리를 메모리 정리에 적용한 것입니다. 세션 시작 시 오염된 메모리를 처리하는 비용 대신, 세션 사이 유휴 시간에 정리를 미리 끝내두는 방식입니다. 정리된 MEMORY.md는 더 짧고, 더 관련성 높은 정보만 담고 있어 세션 시작 시 컨텍스트 윈도우를 덜 차지합니다. 정리된 메모리가 짧을수록 실제 작업에 쓸 수 있는 컨텍스트 공간이 늘어납니다.
| 구분 | Auto Memory | Auto Dream |
|---|---|---|
| 역할 | 정보 수집 | 기존 정보 정리·통합 |
| 실행 시점 | 매 세션 진행 중 | 24시간 + 5회 세션 후 |
| 작성자 | Claude (자동) | Claude (자동 또는 수동) |
| 건너뛰면 | 유용한 정보를 놓침 | 메모 품질이 점점 저하됨 |
| 인간 비유 | 낮에 노트 필기 | REM 수면 중 기억 정리 |
두 기능은 처음부터 세트로 설계됐을 가능성이 높습니다. Auto Memory만 먼저 나온 건 우선순위 문제였을 뿐, 한쪽만 있으면 반쪽짜리입니다.
한계와 주의할 점 — 좋다고 무조건 믿으면 안 됩니다
Auto Dream이 편리한 기능인 건 맞지만, 몇 가지는 직접 챙겨야 합니다.
첫 번째, Auto Memory가 로컬 기계에만 저장됩니다. 팀원과 함께 쓰는 프로젝트에서 Auto Dream이 정리한 메모리는 다른 팀원에게 자동으로 공유되지 않습니다. Anthropic 공식 문서에 “Auto memory is machine-local”이라고 명시돼 있습니다. (출처: dev.to/akari_iku, 2026.03.24) CLAUDE.md는 버전 관리 시스템으로 공유할 수 있지만, Auto Memory와 Auto Dream의 결과물인 MEMORY.md는 그렇지 않습니다.
두 번째, Auto Dream의 정리 결과가 항상 맞지 않을 수 있습니다. 정리 후 가끔 MEMORY.md를 직접 열어봐야 합니다. 자동화 처리이기 때문에 “이 항목은 남겨두고 싶었는데”라는 상황이 생길 수 있습니다. 파일이 일반 마크다운이라 수동 편집은 언제든 가능합니다.
세 번째, Auto Dream이 소스 코드를 건드리지 않는 것은 설계 원칙이지만, 피처 플래그 기반 점진적 배포이므로 아직 초기 단계입니다. Anthropic이 이 기능에 대한 공식 발표를 내놓지 않은 상태에서 커뮤니티 분석을 통해 알려진 내용입니다. 세부 동작이 버전 업데이트에 따라 바뀔 수 있습니다.
네 번째, Auto Memory를 꺼둔 상태라면 Auto Dream이 정리할 재료가 없습니다. Auto Dream은 Auto Memory가 쌓아둔 노트를 정리하는 기능입니다. Auto Memory를 꺼둔 경우에는 수동으로 메모리를 작성하거나, Auto Memory를 다시 켜고 몇 가지 세션을 진행한 뒤에 실행하는 게 의미 있습니다.
📌 주요 미지수: Auto Dream이 결국 자동 실행 플래그를 활성화할 경우 발생하는 API 비용을 누가 부담하는지에 대해 Anthropic이 공식 답변을 내놓지 않은 부분입니다. 사용자 구독 비용 범위 안에 포함되는지, 별도 토큰 차감인지는 정식 출시 전까지 확인이 필요합니다.
자주 묻는 질문
마치며
Auto Dream은 Claude Code의 메모리 시스템을 완성하는 마지막 퍼즐 조각입니다. Auto Memory가 쌓고, Auto Dream이 정리하는 구조가 양쪽 다 돌아갈 때 장기 프로젝트에서 Claude의 작업 품질이 세션이 지나도 유지됩니다.
솔직히 말하면, 지금 단계에서 “이 기능이 정식 출시됐다”고 소개하는 글들은 조심할 필요가 있습니다. UI에 보이고, 수동 실행이 가능하고, 서버 플래그가 일부 사용자에게 열려 있는 건 맞지만 — 아직 Anthropic이 공식 발표를 내놓지 않은 상태입니다. 기능이 어떤 식으로 완성되어 정식 출시될지는 지켜봐야 합니다.
당장 쓸 수 있는 것은 수동 실행입니다. MEMORY.md가 200줄을 넘겼다면, 대규모 리팩터링을 막 끝냈다면, 세션이 수십 개를 넘겼다면 — 지금 Claude Code 세션에서 “dream”을 입력해봐도 좋습니다.
본 포스팅 참고 자료
- Anthropic 공식 엔지니어링 블로그 — Claude Code auto mode (https://www.anthropic.com/engineering/claude-code-auto-mode)
- Sleep-time Compute 논문 — arXiv:2504.13171 (https://arxiv.org/abs/2504.13171)
- claudefa.st — Claude Code Auto Dream 심층 분석 (https://claudefa.st/blog/guide/mechanics/auto-dream)
- tessl.io — Anthropic tests ‘auto dream’ to clean up Claude Code’s memory (2026.03.26) (https://tessl.io/blog/anthropic-tests-auto-dream-to-clean-up-claudes-memory/)
- institute.sfeir.com — Claude Code Dream & Auto Dream: Automatic Memory Consolidation (https://institute.sfeir.com/en/articles/claude-code-dream-auto-dream-memory-consolidation/)
- dev.to — Does Claude Code Need Sleep? Inside the Unreleased Auto-dream Feature (https://dev.to/akari_iku/does-claude-code-need-sleep-inside-the-unreleased-auto-dream-feature-2n7m)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. Auto Dream은 2026년 3월 기준 점진적 배포 중인 기능으로, Claude Code 버전 업데이트에 따라 동작 방식이 달라질 수 있습니다. 본 포스팅은 Anthropic과 무관하게 작성된 독립 콘텐츠입니다.
댓글 남기기