포스트

Claude의 기억 시스템 심층 분석 — Auto Memory, Auto Dream, 그리고 Sleep-time Compute

Claude의 기억 시스템 심층 분석 — Auto Memory, Auto Dream, 그리고 Sleep-time Compute
TL;DR — 핵심 요약
  • Claude Code의 메모리는 CLAUDE.md(명시적 규칙) + Auto Memory(자동 학습) + Auto Dream(수면 정리)의 3단계로 진화했으며, 이는 인간의 '쓰기→자기→정리→기억' 사이클을 모방한다
  • Auto Dream은 Sleep-time Compute 논문(2025)의 이론적 근거 위에 설계되었다 — 사용자가 질문하기 전에 미리 계산해두면 테스트 시간 연산을 약 5배 절감할 수 있다
  • 최신 연구(2025~2026)는 에이전트 메모리를 사실적(Factual)·경험적(Experiential)·작업(Working) 메모리로 분류하며, 형성→진화→검색의 생명주기로 관리한다
Visitors

들어가며

AI 에이전트가 단일 대화를 넘어 장기적으로 학습하고 기억하는 능력은 2025~2026년 AI 연구의 핵심 화두다. Claude Code는 이 분야에서 가장 공격적으로 실험하고 있는 제품 중 하나인데, 최근 코드에서 발견된 미출시 기능 Auto Dream은 그 방향성을 극명하게 보여준다.

이 글에서는 세 가지 축으로 Claude의 기억 시스템을 해부한다:

  1. 제품 레벨: Claude Code의 메모리 아키텍처 (CLAUDE.md → Auto Memory → Auto Dream)
  2. 이론 레벨: Sleep-time Compute 논문이 제시하는 “수면 중 사전 계산” 패러다임
  3. 연구 레벨: 2025~2026년 에이전트 메모리 분류 체계와 최신 서베이 논문들

1. Claude Code 메모리 아키텍처의 전체 그림

1-1. 3계층 메모리 시스템

Claude Code의 메모리는 누가 쓰는가언제 로드되는가에 따라 세 계층으로 나뉜다.

계층작성자내용로딩 시점범위
CLAUDE.md사용자명시적 규칙·컨벤션매 세션 시작 (전체)프로젝트/사용자/조직
Auto MemoryClaude학습한 패턴·선호도매 세션 시작 (200줄)git 저장소 단위
Auto DreamClaude (백그라운드)정리된 기억조건 충족 시 자동git 저장소 단위

CLAUDE.md — 선언적 규칙의 계층 구조

CLAUDE.md는 프로젝트 수준의 지침 파일이다. 가장 좁은 범위(프로젝트)가 가장 넓은 범위(조직)보다 우선한다.

1
2
3
4
우선순위 (높음 → 낮음):
1. Managed Policy — /Library/Application Support/ClaudeCode/CLAUDE.md (IT 관리자)
2. Project       — ./CLAUDE.md 또는 ./.claude/CLAUDE.md (팀 공유)
3. User          — ~/.claude/CLAUDE.md (개인 전역)

효과적인 CLAUDE.md의 조건:

  • 200줄 이하에서 규칙 준수율 92% 이상, 400줄을 넘으면 71%로 급락
  • 모호한 지시(“코드 잘 정리해줘”)보다 검증 가능한 지시(“2칸 들여쓰기 사용”)가 효과적
  • .claude/rules/ 디렉토리로 모듈화하면 파일별 글로브 패턴으로 조건부 로딩 가능

Auto Memory — Claude가 스스로 쓰는 노트

Auto Memory는 사용자가 아무것도 쓰지 않아도 Claude가 세션 중 발견한 패턴을 자동으로 기록하는 시스템이다.

1
2
3
4
5
~/.claude/projects/<project>/memory/
├── MEMORY.md          # 인덱스 (매 세션 200줄 로드)
├── debugging.md       # 디버깅 패턴
├── api-conventions.md # API 설계 결정
└── ...                # Claude가 자유롭게 생성

작동 원리:

  1. 세션 시작 시 MEMORY.md의 처음 200줄을 컨텍스트에 주입
  2. 대화 중 사용자의 수정, 선호도, 반복 패턴을 감지
  3. “이 정보가 미래 대화에 유용한가?”를 판단해 선별적으로 저장
  4. 상세 내용은 토픽 파일로 분리, MEMORY.md는 인덱스로만 유지

1-2. Auto Memory의 근본적 문제

Auto Memory는 강력하지만, 시간이 지나면 혼란에 빠진다.

20개 이상의 세션이 쌓이면:

  • 모순된 항목이 누적된다 (“pnpm 사용” vs “npm 사용”)
  • 상대 날짜가 의미를 잃는다 (“어제 수정한 버그”가 3개월 전 기록)
  • 일시적 메모와 본질적 학습이 동일한 수준에서 저장된다
  • 200줄 제한 안에서 중요도 경쟁이 벌어진다

이것은 단순한 구현 버그가 아니라, 쓰기만 하고 정리하지 않는 시스템의 구조적 한계다.


2. Auto Dream — “잠자는 동안 기억을 정리하는” AI

2-1. 발견 경위

Auto Dream은 2026년 3월, 일본의 개발자 灯里(akari)가 Claude Code의 /memory 명령에서 발견한 미출시 기능이다. UI에 표시되지만 활성화할 수 없는 서버 측 피처 플래그로 제어된다.

1
2
3
4
5
코드네임: tengu_onyx_plover
기본 설정:
  enabled: false
  minHours: 24        # 최소 24시간 간격
  minSessions: 5      # 5개 세션 축적 후 실행

이 이중 게이트 설계는 의도적이다 — 가벼운 사용에는 트리거되지 않고, 활발한 개발 프로젝트에서만 정기적으로 정리가 실행된다.

2-2. Auto Dream의 4단계 프로세스

Auto Dream은 인간의 REM 수면에 비유된다. 깨어 있는 동안(세션) 수집한 정보를 잠자는 동안(백그라운드)에 정리하고 통합한다.

Phase 1 — Orientation (방향 설정)

메모리 디렉토리를 스캔하고 현재 상태를 파악한다. 어떤 토픽 파일이 있는지, MEMORY.md의 현재 크기는 얼마인지, 마지막 정리 이후 얼마나 시간이 흘렀는지를 확인한다.

Phase 2 — Gather Signal (신호 수집)

세션 트랜스크립트에서 중요한 정보를 선별적으로 추출한다. 모든 파일을 읽지 않고 좁은 범위의 grep 검색을 수행한다:

  • 사용자의 수정 사항 (“아니, 그게 아니라…”)
  • 명시적 저장 명령 (“이것을 기억해”)
  • 반복되는 주제와 패턴
  • 중요한 기술적 결정

Phase 3 — Consolidation (통합)

새로운 정보를 기존 파일에 병합하면서:

  • 상대 날짜(“어제”)를 절대 날짜(“2026-03-24”)로 변환
  • 모순된 사실 중 최신 것만 보존
  • 오래되고 더 이상 유효하지 않은 메모리 제거
  • 중복 항목을 하나로 통합

Phase 4 — Prune and Index (정제 및 인덱싱)

MEMORY.md 인덱스를 200줄 이하로 유지하며 최신 상태로 업데이트한다.

2-3. Auto Memory + Auto Dream = 기억의 완성

1
2
3
4
5
6
7
8
9
10
  Auto Memory (깨어 있을 때)          Auto Dream (잠잘 때)
  ┌─────────────────────┐         ┌─────────────────────┐
  │  경험 수집           │         │  신호 추출           │
  │  패턴 감지           │  ───▶   │  모순 해결           │
  │  노트 작성           │         │  통합·정리           │
  │  토픽 파일 분리       │         │  인덱스 갱신         │
  └─────────────────────┘         └─────────────────────┘
           ↑                                │
           └────────────────────────────────┘
                    다음 세션에 반영

이 사이클은 인간의 “경험 → 수면 → 기억 강화” 패턴을 직접적으로 모방한다. 신경과학에서는 수면 중 해마(hippocampus)가 낮 동안의 경험을 재생(replay)하며 대뇌피질로 전이하는 과정을 기억 공고화(memory consolidation)라고 부르는데, Auto Dream은 정확히 이 역할을 한다.

2-4. 왜 아직 출시되지 않았나?

기술적으로는 즉시 출시 가능하지만, 세 가지 비즈니스 판단이 남아 있다:

  1. 비용: 사용자가 요청하지 않은 서브에이전트가 백그라운드에서 토큰을 소비한다
  2. 투명성: 사용자 모르게 메모리를 재구성하는 것에 대한 신뢰 문제
  3. 기본값: opt-in vs opt-out, 어떤 것이 올바른 기본 동작인가?

3. 이론적 토대 — Sleep-time Compute

3-1. 논문 개요

Auto Dream의 이론적 근거는 2025년 4월 발표된 “Sleep-time Compute: Beyond Inference Scaling at Test-time” 논문이다.

저자: Kevin Lin, Charlie Snell, Yu Wang, Charles Packer, Sarah Wooders, Ion Stoica, Joseph E. Gonzalez arXiv: 2504.13171 핵심 아이디어: 사용자가 질문하기 전에 미리 계산해두면, 실제 추론 시 필요한 연산량을 대폭 줄일 수 있다.

Sleep-time Compute 개념도 Figure 1: Sleep-time compute는 원본 컨텍스트를 사전 처리하여, 미래 쿼리에 유용할 수 있는 추가 계산을 수행한다. (Lin et al., 2025)

3-2. 핵심 결과

논문은 두 가지 수정된 추론 과제(Stateful GSM-Symbolic, Stateful AIME)에서 인상적인 효율성 개선을 입증한다.

Sleep-time vs Test-time accuracy tradeoff Figure 3: Stateful GSM-Symbolic에서의 테스트 시간 연산 대 정확도 트레이드오프. 음영 영역이 sleep-time compute가 파레토 최적 경계를 개선하는 구간이다.

핵심 수치:

  • 테스트 시간 연산 ~5배 절감: 같은 정확도를 달성하는 데 필요한 추론 시간 연산량을 약 1/5로 줄임
  • 정확도 최대 13% 향상: sleep-time compute를 확장하면 기존 방식보다 최대 13%p 더 높은 정확도 달성
  • 쿼리당 평균 비용 2.5배 감소: 같은 컨텍스트에 대한 여러 쿼리를 공유하면 비용 절감

쿼리 공유를 통한 비용 절감 Figure 9: Multi-Query GSM-Symbolic에서 컨텍스트당 질문 수가 증가할수록 sleep-time compute의 비용-정확도 파레토가 개선된다.

3-3. 예측 가능성과 효과의 상관관계

특히 흥미로운 발견은, 사용자 질문이 컨텍스트로부터 예측 가능할수록 sleep-time compute의 효과가 커진다는 점이다.

예측 가능성과 sleep-time 효과 Figure 10: 질문의 예측 가능성이 높을수록 sleep-time compute와 표준 추론의 성능 격차가 벌어진다.

이것이 Auto Dream에 시사하는 바는 명확하다:

  • 개발 프로젝트에서 반복되는 패턴(빌드 명령, 코딩 스타일, 아키텍처 결정)은 높은 예측 가능성을 가진다
  • 따라서 이런 패턴을 미리 정리해두면, 다음 세션에서 Claude가 더 적은 토큰으로 더 정확한 응답을 생성할 수 있다
  • Auto Dream은 결국 개발 컨텍스트에 특화된 sleep-time compute

3-4. 실제 소프트웨어 엔지니어링 적용

논문은 SWE-Features라는 실제 소프트웨어 엔지니어링 작업에서도 검증했다.

SWE-Features 결과 Figure 11: SWE-Features에서 낮은 테스트 시간 예산에서 sleep-time compute가 표준 방식보다 높은 F1 점수를 보인다.


4. 학술적 맥락 — 에이전트 메모리 연구의 현재

Claude의 메모리 시스템은 더 넓은 학술 연구 흐름 속에 위치한다. 2025~2026년에 발표된 주요 서베이 논문들을 통해 이 맥락을 이해해보자.

4-1. 인간 기억 → AI 메모리로의 매핑

“From Human Memory to AI Memory” (Wu et al., 2025)는 인간 기억의 분류 체계를 AI 메모리 시스템에 매핑하는 프레임워크를 제안했다.

인간 기억과 AI 메모리의 대응 관계 Figure 1: 인간 기억(감각 기억, 작업 기억, 명시적/암시적 기억)과 LLM 기반 AI 시스템 메모리의 대응 관계. (Wu et al., 2025)

이 논문은 3차원(대상·형태·시간)과 8개 사분면으로 메모리를 분류한다:

차원설명예시
대상(Object)누구의 메모리인가개인 vs 집단
형태(Form)어떤 형태로 저장되는가텍스트, 벡터, 파라미터
시간(Time)얼마나 지속되는가단기 vs 장기

Claude Code에 대입하면:

  • CLAUDE.md = 명시적 장기 기억 (사용자가 선언한 규칙)
  • Auto Memory = 암시적 장기 기억 (경험에서 자동 추출)
  • 컨텍스트 윈도우 = 작업 기억 (현재 세션)
  • Auto Dream = 기억 공고화 (수면 중 정리)

4-2. AI 에이전트 시대의 메모리 분류 체계

“Memory in the Age of AI Agents” (Hu, Liu et al., 2025/2026)는 47명의 저자가 참여한 대규모 서베이로, 기존의 단순한 “장기/단기 메모리” 분류를 넘어서는 새로운 체계를 제안한다.

arXiv: 2512.13564 (2025년 12월, v2: 2026년 1월)

에이전트 메모리 vs 관련 개념

먼저 이 논문은 에이전트 메모리를 LLM 메모리, RAG, 컨텍스트 엔지니어링과 구분한다.

에이전트 메모리 개념 비교 Figure 1: 에이전트 메모리(Agent Memory)와 LLM 메모리, RAG, 컨텍스트 엔지니어링의 개념적 비교. (Hu et al., 2025)

형태(Forms) 차원 — 메모리의 물리적 구조

에이전트 메모리의 물리적 형태는 세 가지로 분류된다.

메모리 형태 비교 Figure 4: 토큰 레벨, 파라미터, 잠재적(Latent) 메모리의 세 형태 비교.

토큰 레벨 메모리는 가장 직관적인 형태로, 정보를 텍스트 토큰으로 저장한다. 위상적 복잡도에 따라 세분화된다:

토큰 레벨 메모리의 위상적 분류 Figure 2: 토큰 레벨 메모리의 위상적 분류 — 평면(1D), 평면형(2D 그래프/트리), 계층형(3D 다층 구조).

형태구조예시Claude Code 대응
Flat (1D)선형 시퀀스단순 텍스트 로그MEMORY.md 항목 나열
Planar (2D)트리/그래프지식 그래프토픽 파일 간 참조
Hierarchical (3D)다층 구조피라미드 메모리MEMORY.md → 토픽 파일 계층

파라미터 메모리는 모델 가중치 자체에 정보를 인코딩하는 방식이다. Fine-tuning이나 LoRA가 대표적이다. Claude Code에서는 사용하지 않는다.

잠재적(Latent) 메모리는 은닉 상태(hidden state)나 KV 캐시에 정보를 저장하는 방식이다. Anthropic의 프롬프트 캐싱이 이 범주에 가깝다.

기능(Functions) 차원 — 메모리의 인지적 역할

기능적 분류 체계 Figure 6: 에이전트 메모리의 기능적 분류 — 사실적(Factual), 경험적(Experiential), 작업(Working) 메모리.

사실적 메모리 (Factual Memory)

에이전트의 선언적 지식 기반이다. 두 하위 유형으로 나뉜다:

  • 사용자 사실 메모리: 사용자와의 상호작용에서 일관성을 유지하기 위한 정보 (“이 프로젝트는 pnpm을 사용한다”)
  • 환경 사실 메모리: 외부 세계 지식과의 일관성 보장 (“Node.js 20에서 이 API가 deprecated됐다”)

Claude Code에서는 CLAUDE.md가 사실적 메모리의 주요 저장소다.

경험적 메모리 (Experiential Memory)

과거 경험에서 추출한 학습이다. 세 하위 유형:

  • 사례 기반(Case-based): 과거 에피소드의 기록 (“지난번 빌드 오류는 이렇게 해결했다”)
  • 전략 기반(Strategy-based): 추론 패턴의 학습 (“이 프로젝트에서는 항상 타입 체크를 먼저 한다”)
  • 스킬 기반(Skill-based): 절차적 능력 (“테스트 → 빌드 → 배포 파이프라인”)

Claude Code에서는 Auto Memory가 경험적 메모리를 담당한다.

작업 메모리 (Working Memory)

용량이 제한된 활성 컨텍스트다. 현재 세션에서 진행 중인 작업의 상태를 유지한다.

Claude Code에서는 컨텍스트 윈도우 자체가 작업 메모리이며, MEMORY.md의 200줄 제한은 인간 작업 기억의 용량 제한(밀러의 7±2 법칙)을 연상시킨다.

동역학(Dynamics) 차원 — 메모리의 생명주기

메모리 생명주기 Figure 8: 에이전트 메모리의 생명주기 — 형성(Formation), 진화(Evolution), 검색(Retrieval).

단계설명Claude Code 대응
형성(Formation)새로운 정보를 메모리에 기록Auto Memory가 세션 중 패턴 감지·저장
진화(Evolution)기존 메모리를 업데이트·변환·삭제Auto Dream이 모순 해결·통합·정제
검색(Retrieval)필요한 시점에 메모리 접근세션 시작 시 200줄 로드 + 온디맨드 토픽 파일 읽기

메모리 진화 프로세스 Figure 7: 메모리 진화의 세부 메커니즘 — 업데이트, 강화, 망각, 재구조화.

4-3. 메모리 시스템의 Write–Manage–Read 루프

“Memory for Autonomous LLM Agents” (2026)는 에이전트 메모리를 Write–Manage–Read 루프로 형식화했다.

1
2
3
4
5
6
7
┌──────────┐    ┌──────────┐    ┌──────────┐
│  Write   │───▶│  Manage  │───▶│   Read   │
│ (기록)    │    │ (관리)    │    │ (검색)    │
└──────────┘    └──────────┘    └──────────┘
     ↑                                │
     └────────────────────────────────┘
              피드백 루프

Claude Code에 이 프레임워크를 적용하면:

단계구현담당자
Write세션 중 메모리 파일에 기록Auto Memory
Manage주기적 정리·통합·정제Auto Dream
Read세션 시작 시 200줄 로드 + 필요 시 토픽 파일 접근Claude Code 런타임

5. Claude의 메모리를 더 넓은 맥락에서 보기

5-1. Chat Memory vs Claude Code Memory

Claude의 메모리 시스템은 사용자 유형에 따라 다른 계층을 제공한다.

계층대상작동 방식정리 주기
Chat Memory모든 Claude 사용자대화에서 자동 추출 (Memory Synthesis)~24시간
CLAUDE.md + Auto MemoryClaude Code 개발자명시적 규칙 + 자동 학습수동 / Auto Dream
API Memory Tool앱 빌더프로그래밍 방식 CRUD앱 로직에 따라

Chat Memory는 가장 단순한 형태로, 약 24시간마다 대화 내용에서 장기적으로 유용한 정보를 추출하는 추출적 요약(extractive summarization) 방식이다. Claude Code의 Auto Memory + Auto Dream 조합은 이를 훨씬 정교하게 발전시킨 것이다.

5-2. 인프라 스케줄링의 세 계층

Auto Dream의 실행 인프라도 세 단계로 발전하고 있다:

계층범위지속성예시
CLI /loop세션 중만 유효세션 종료 시 소멸loop 10m /simplify
Desktop Scheduled Tasks로컬 머신 지속머신 종료 시 소멸crontab 기반
Cloud Scheduled TasksAnthropic 인프라항상 실행서버리스 실행

Auto Dream이 Cloud Scheduled Tasks로 올라가면, 사용자의 컴퓨터가 꺼져 있어도 메모리 정리가 진행될 수 있다. 2026년 3월 Anthropic이 Claude Partner Network에 1억 달러를 투자한 것과 맞물리는 방향이다.

5-3. 경쟁 환경에서의 위치

제품메모리 형태정리 메커니즘개발자 통합
Claude Code파일 기반 (CLAUDE.md + MEMORY.md)Auto Dream (예정)git 저장소 단위
ChatGPT서버 측 키-밸류자동 요약제한적
GitHub Copilot.github/copilot-instructions.md없음저장소 단위
Cursor.cursorrules없음프로젝트 단위

Claude Code의 차별점은 정리 단계(Auto Dream)의 존재다. 다른 도구들이 “쓰기만 하는” 메모리를 제공할 때, Claude Code는 “쓰고, 자고, 정리하고, 기억하는” 완전한 사이클을 구현하려 한다.


6. 실전: 효과적인 메모리 관리 전략

6-1. CLAUDE.md 작성 원칙

1
2
3
4
5
6
7
8
9
# 좋은 예: 구체적이고 검증 가능
- 2칸 들여쓰기 사용
- 커밋 전 `npm test` 실행
- API 핸들러는 `src/api/handlers/`에 위치

# 나쁜 예: 모호하고 검증 불가
- 코드를 깔끔하게 작성
- 적절한 테스트를 수행
- 파일을 잘 정리

6-2. Auto Memory 활용 팁

  1. 정기적으로 /memory로 확인: Claude가 무엇을 기억하고 있는지 수시로 점검
  2. 모순 발견 시 즉시 수정: “이건 더 이상 맞지 않아”라고 말하면 Claude가 업데이트
  3. 200줄 넘어가면 토픽 파일 분리 유도: “메모리를 정리해줘”라고 요청
  4. 민감한 정보 주의: API 키, 비밀번호 등이 저장되지 않도록 확인

6-3. Auto Dream 대비 전략

Auto Dream이 정식 출시되면, 다음을 기대할 수 있다:

  • 자동 모순 해결: 같은 설정에 대한 상충 기록이 최신 것으로 통합
  • 상대 날짜 변환: “어제”가 절대 날짜로 자동 변환
  • 중요도 기반 정리: 일시적 메모보다 반복적 패턴에 높은 가중치
  • 수동 트리거: /dream 명령으로 대규모 리팩토링 후 즉시 정리 가능

마무리 — AI가 꿈을 꾸는 시대

Claude의 메모리 시스템 진화를 한 줄로 요약하면:

“쓰기(Auto Memory)만으로는 부족하다. 자고 나서 정리해야(Auto Dream) 진짜 기억이 된다.”

이것은 단순한 기능 추가가 아니라, LLM 에이전트가 인간 인지의 근본적 메커니즘을 모방하기 시작했다는 신호다. Sleep-time Compute 논문이 이론을 제공하고, 에이전트 메모리 서베이들이 분류 체계를 제공하며, Claude Code의 Auto Dream이 이를 제품으로 구현한다.

게임 개발자로서 비유하자면, NPC의 AI가 단순 상태 머신(FSM)에서 행동 트리(Behavior Tree)로, 다시 유틸리티 AI로 진화한 것과 같은 궤적이다. 각 단계마다 에이전트가 처리할 수 있는 상황의 복잡도가 질적으로 달라졌듯이, AI의 기억 시스템도 “단순 저장 → 자동 학습 → 수면 정리”의 궤적을 따라 질적 도약을 준비하고 있다.


참고 문헌 및 관련 자료

논문

  1. Kevin Lin et al., “Sleep-time Compute: Beyond Inference Scaling at Test-time”, arXiv:2504.13171, 2025.
  2. Yuyang Hu, Shichun Liu et al., “Memory in the Age of AI Agents: A Survey”, arXiv:2512.13564, 2025/2026.
  3. Yaxiong Wu et al., “From Human Memory to AI Memory: A Survey on Memory Mechanisms in the Era of LLMs”, arXiv:2504.15965, 2025.
  4. “Memory for Autonomous LLM Agents”, arXiv:2603.07670, 2026.
  5. “A Survey on the Memory Mechanism of Large Language Model-based Agents”, ACM TOIS, 2025.

기사 및 문서

  1. 灯里(akari), “Claudeに『いい夢みてね』を言う日がくるかもしれない”, Zenn, 2026-03-24.
  2. Anthropic, “How Claude remembers your project”, Claude Code Docs.
  3. “Claude Memory Guide: Understanding the 3-Layer Architecture”, ShareUHack, 2026.
  4. “Claude Code Auto Dream: Memory Consolidation Feature Explained”, ClaudeFast.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.