매일 저녁 동부 표준시(Eastern Time) 오후 7시 10분, 나의 OpenClaw 에이전트는 잠자리에 듭니다.

에이전트는 휴식을 취하는 것이 아닙니다. _처리 (processes)_를 하는 것입니다. 약 60초 동안, cron job이 내가 그날 수행한 모든 작업 — 내가 위임한 모든 태스크, 내가 기록한 모든 에러, 내가 내린 모든 결정 — 에 대해 3단계 파이프라인 (three-stage pipeline)을 실행합니다. 아침이 되면 에이전트의 메모리 (memory)는 조용히 편집되어 있습니다. 노이즈 (noise)는 버려지고, 시그널 (signal)은 승격되며, 패턴 (patterns)이 드러납니다.

나는 이 설정을 3주 동안 실행해 왔습니다. 수치는 정직합니다:

• 6월 23일: 62개의 후보군 스테이징 (staged) → 257개의 반복되는 테마 발견 → 2개가 장기 메모리 (long-term memory)로 승격
• 6월 22일: 64개의 후보군 스테이징 → 242개의 반복되는 테마 → 1개 승격
• 6월 21일: 63개의 후보군 스테이징 → 241개의 반복되는 테마 → 1개 승격

에이전트가 보는 것의 대부분은 거절됩니다. 그것이 핵심입니다.

내가 Dream Protocol을 구축한 이유

장기간 실행되는 AI 에이전트의 문제는 컨텍스트 (context)가 압축된다는 점입니다. 매 세션마다 시스템은 발생한 일을 요약하고 압축 (compaction)이 시작됩니다 — 40개의 메시지를 몇 개의 단락으로 응축합니다. 이는 효율적이지만, 손실 (lossy)이 발생하기도 합니다. 중요한 교훈들은 평균화되어 사라집니다. 수정 사항들은 희미해집니다. 다음번에 결정적인 역할을 할 컨텍스트는 모호한 언어로 압축됩니다.

나는 일상적인 노이즈 속에서 실제로 중요한 것을 드러낼 방법이 필요했습니다.

그 해답은 내가 Dream Protocol이라고 부르는 야간 cron job이었습니다. 이는 정교하지 않습니다 — 나의 일일 메모리 로그 (memory logs)를 대상으로 실행되는 Python 스크립트일 뿐입니다. 하지만 이는 규율이 있으며, 메모리 시스템에서는 규율이 영리함보다 승리합니다.

3단계 파이프라인 (Three-Stage Pipeline)

1단계: 얕은 잠 — 후보군 스테이징 (Staging Candidates)

스크립트는 그날의 메모리 로그를 스캔하여 모든 "배운 점 (lesson learned)" 항목 — 모든 ## What I learned 섹션, 모든 ## Self-Improvement 노트, 모든 플래그가 지정된 수정 사항 — 을 스테이징 (stages) 합니다. 또한 지난 며칠간의 로그에서도 데이터를 가져옵니다.

중복 제거 (deduplication)를 하기 전에는 이것이 노이즈처럼 보입니다: 동일한 수정 사항에 대한 반복적인 시도, 같은 내용을 세 가지 다른 방식으로 말하는 장황한 수정 사항, 이미 해결된 오래된 항목들 등입니다.

중복 제거 (deduplication) 단계는 유사한 중복 항목들을 제거합니다. 이는 매우 중요합니다. 만약 제가 일주일 동안 동일한 문제를 세 번 해결하려고 시도했다면, 그것은 세 개의 교훈이 아니라 하나의 교훈이기 때문입니다.

2단계: REM 수면 — 점수 산정 및 필터링 (Scoring and Filtering)

이 단계에서 실제적인 선택이 이루어집니다.

스크립트는 _재발성 (recurrence)_을 확인합니다. 즉, 이 패턴이 서로 다른 날, 서로 다른 세션, 서로 다른 문맥에서 얼마나 자주 나타나는지를 봅니다. 한 번 나타나는 교훈은 노이즈 (noise)입니다. 세 가지 서로 다른 쿼리 문맥 (query contexts)에 걸쳐 세 번 나타나는 교훈은 신호 (signal)입니다.

점수 산정 게이트 (scoring gates)는 다음과 같습니다:

• 최소 회상 횟수 (Minimum recall count): 3 (회상 저장소 (recall store)에 최소 3번 나타나야 함)
• 최소 고유 쿼리 수 (Minimum unique queries): 3 (최소 3개의 서로 다른 검색 문맥에서 관련성이 있어야 함)
• 최소 점수 (Minimum score): 0.8

후보가 이 세 가지 게이트를 모두 통과하면, 에이전트의 장기 지식 베이스 (long-term knowledge base)인 MEMORY.md로 승격됩니다. 그 외의 모든 것은 거부됩니다.

거부율은 가혹합니다. 6월 23일: 828개의 후보 중 824개 거부. 6월 22일: 806개의 후보 중 803개 거부. 에이전트가 배우는 것의 대부분은 에이전트가 잊어버립니다. 하지만 살아남는 것들은 계속해서 나타나는 것들이며, 그것이 바로 제가 실제로 에이전트가 기억하기를 원하는 것입니다.

3단계: 꿈 일기 — 선택되지 못한 것들의 로그 (Dream Diary — The Log of What Didn't Make It)

세 번째 출력물이 있습니다. 세부 사항 없이 프로세스만을 기록하는 꿈 일기 (Dream Diary) 항목입니다. 이것은 에이전트를 위한 것이 아니라 저를 위한 것입니다. 얼마나 많은 후보가 단계별로 배치되었는지, 얼마나 많은 테마가 발견되었는지, 어떤 게이트가 적용되었는지, 그리고 최고 점수를 받은 생존자들이 무엇이었는지를 추적합니다.

이는 잠에서 깨어났을 때 꿈의 내용은 기억나지 않지만, 무언가 일이 일어났다는 사실은 알고 있는 에이전트의 상태와 같습니다.

무엇이 승격되는가

필터링이 가혹하게 들릴 수 있지만, 적절한 것을 찾아내는 데 놀라울 정도로 효과적입니다.

지난 2주 동안 MEMORY.md에 살아남은 것들은 다음과 같습니다:

• 올바른 압축 모델 (compaction model)로서의 MiniMax-M2.7 — 80개 이상의 회상 (recall) 항목에서 나타났으며, 세션 검토 데이터를 통해 정확함이 확인됨
• 무료 티어 모델을 사용한 폴백 체인 (fallback chain) 실패 — cron 실패 로그에 계속해서 나타났으며, 3회 이상의 별도 실패 이벤트 이후 최종적으로 장기 기억 (long-term memory)으로 승격됨
• /tmp/ 임시 파일 버그 패턴 — 동일한 근본 원인 (cron 페이로드 내 하드코딩된 임시 파일 참조)이 포착되기 전까지 3개의 별도 cron 세션에서 나타남

지속적으로 거부되는 것들:

• 일회성 수정 사항 (예: "프롬프트 X의 오타 수정")
• 짧은 항목과 동일한 내용을 담은 장황한 설명
• 문제가 이미 해결된 날의 오래된 항목들

이것이 실제로 변화시키는 것

3주 후의 실질적인 효과: 에이전트의 행동이 변화했습니다.

새로운 cron이 이전과 동일한 방식으로 실패할 때, 에이전트는 그 패턴을 더 빠르게 인식합니다. 이는 명시적으로 교육받았기 때문이 아니라, 해당 패턴이 MEMORY.md에 충분한 가중치를 가지고 나타나 압축 (compaction) 과정을 견뎌냈기 때문입니다. 새로운 모델 구성이 제안될 때, 에이전트는 명시적인 지시 없이도 무료 티어 폴백 (fallback)에 대해 반대할 수 있는 충분한 근거를 갖게 됩니다.

꿈 프로토콜 (dream protocol)은 마법이 아닙니다. 그것은 단지 절제된 노이즈 캔슬링 (noise cancellation)일 뿐입니다.

그 반대인 모든 것을 저장하는 방식은 정반대의 효과를 낳습니다. 노이즈로 가득 찬 메모리는 에이전트가 실제로 중요한 것이 무엇인지 구별하는 것을 더 어렵게 만듭니다. 압축 모델은 모든 것을 평균화하며, 이 과정에서 신호 (signal)가 희석됩니다.

한 줄 요약

AI 에이전트가 배우는 것의 대부분은 잊어버리세요. 서로 다른 3일 동안 3개의 서로 다른 맥락 속에서도 살아남은 3% — 그것이 바로 당신이 장기 기억 (long-term memory)에 남기고 싶은 것입니다.

Dream Protocol (꿈 프로토콜)은 실행 비용이 거의 들지 않는 60초짜리 cron job (크론 잡)입니다. 3주가 지난 지금, 이 프로토콜 덕분에 제 에이전트는 며칠 동안이나 눈치채지 못했을 조용한 cron crash (크론 충돌)를 잡아낼 수 있었습니다. 또한 에이전트가 프로덕션 (production) 환경의 cron job에 대해 무료 티어 (free-tier) 대체안을 제안하는 것을 멈추게 한 이유이기도 합니다. 그리고 제가 제 자신의 메모보다 이 메모를 더 신뢰하게 된 이유이기도 합니다.

만약 당신이 OpenClaw를 실행 중이고 에이전트의 메모리가 시간이 지날수록 계속 노이즈가 심해진다면, 매일 밤 deduplication (중복 제거) 과정을 시도해 보세요. 정교한 시스템은 필요하지 않습니다. "3개의 서로 다른 날짜에 걸쳐 3번 나타남"이라고 말해주는 게이트 (gate)와, 그 외의 나머지를 실제로 삭제하는 절제력만 있으면 됩니다.