나의 OpenClaw가 꿈을 꾸도록 학습시켰습니다. 하룻밤 사이에 무엇을 배웠는지 공개합니다.

매일 밤 UTC 기준 07:05, 나의 OpenClaw 인스턴스는 내가 계획하지 않은 일을 수행합니다. 바로 꿈을 꾸는 것입니다.

비유적인 표현이 아닙니다. 나의 대화 기록에 대해 전체 REM 주기 (REM cycle)를 실행하는 크론 잡 (cron job)이 있습니다. 이 작업은 700개 이상의 회상 항목 (recall entries)을 점수화하고, 노이즈 (noise)를 거부하며, 신호 (signals)를 장기 기억 (long-term memory)으로 승격시킵니다. 내가 깨어나기 전에 그 결과들을 기록해 둡니다. 내가 커피를 들고 책상에 앉을 때쯤이면, 나의 에이전트 (agent)는 잠들기 전보다 약간 더 날카로워진 버전이 되어 있습니다.

이 포스트는 그것이 어떻게 작동하는지, 8시간의 비지도 메모리 관리 (unsupervised memory management)를 통해 실제로 무엇을 하는지, 그리고 왜 이러한 패턴 — 수면 + 통합 (sleep + consolidation) — 이 오늘날 대부분의 AI 에이전트 설정에서 빠져 있는 핵심 요소라고 생각하는지에 대해 다룹니다.

대부분의 에이전트가 메모리에 대해 잘못 알고 있는 것

표준적인 에이전트 메모리 패턴은 다음과 같습니다: 모든 것을 컨텍스트 파일 (context file)에 추가하고, 윈도우 (window)가 넘칠 때까지 방치한 다음, 자르거나(truncate) 새로운 스레드 (thread)를 시작합니다. 이는 손실이 발생하며 수동적인 접근 방식입니다. 당신은 에이전트에게 무언가를 가르치는 것이 아니라, 그저... 저장하고 있을 뿐입니다.

'더 나은 메모리'를 위한 나의 첫 번째 시도도 마찬가지였습니다: 무한히 커지는 일일 로그 파일 (daily log files). 그다음은 주간 요약 (weekly summaries). 그다음은 3단계 시스템 (daily → weekly → long-term)이었습니다. 하지만 계층화(tiering)를 했음에도 문제는 동일했습니다: 저장 공간은 늘어나지만, 신호는 줄어든다는 것이었습니다. 에이전트는 걸러내야 할 자료는 많아졌지만, 무엇이 중요하고 무엇이 중요하지 않은지 구분할 메커니즘이 없었습니다.

드림 프로토콜 (Dream Protocol)은 이에 대한 나의 해답입니다. 이것은 메모리를 저장의 문제가 아닌 학습의 문제로 취급하는 야간 크론 (nightly cron)입니다.

드림 사이클 (Dream Cycle)의 작동 방식

크론은 매일 아침 UTC 07:05에 실행됩니다. 이는 다단계 파이프라인 (multi-stage pipeline)을 실행하는 격리된 에이전트 턴 (agentTurn)입니다:

Stage 1 — 가벼운 수면 (staging)
  → 최근 일일 로그에서 모든 후보군 추출
  → 거의 동일한 항목들의 중복 제거
...

숫자는 마법이 아닙니다. 스코어링 모델 (scoring model)은 간단합니다. 다양한 쿼리 (query)와 문맥 (context) 전반에 걸쳐 빈번하게 나타나는 테마 (theme)는 일회성 관찰보다 실제로 중요할 가능성이 높습니다. 서로 다른 3개의 세션에서 3번 나타난 수정 사항은 승격 (promoted)됩니다. 한 번의 대화에서 스쳐 지나간 언급은 폐기 (discarded)됩니다.

어젯밤 실행 결과의 실제 모습은 다음과 같습니다:

총 740개의 회상 항목 (recall entries) 검토됨
220개의 반복되는 테마 (recurring theme(s)) 발견
승격 (Promoted): 1 | 거부 (Rejected): 737
...

737개 거부. 1개 승격. 대부분의 밤에 나타나는 비율입니다.

게이트를 통과하여 살아남는 것들

이 작업을 실행한 지 3주가 되었습니다. 일관되게 승격되는 항목들은 다음과 같습니다:

모델 설정 수정 (Model configuration corrections) — 끊어진 폴백 체인 (fallback chain)을 수정하면, 그 수정 사항이 살아남습니다. 에이전트 (agent)는 죽은 NVIDIA 엔드포인트 (endpoint)를 사용하려는 시도를 중단합니다.
도구 선호 패턴 (Tool preference patterns) — 어떤 도구가 안정적으로 작동하는지, 반대로 어떤 도구가 조용히 실패하는지에 대한 패턴입니다. 에이전트는 실패를 우회하여 경로를 설정하는 법을 배웁니다.
사용자 선호 신호 (User preference signals) — James는 Telegram에서는 간결한 답변을 선호하고, 이메일에서는 상세한 답변을 선호합니다. 이러한 차이가 강화 (reinforced)됩니다.

일관되게 거부되는 항목들:

당시에는 말이 되었지만 일반적으로 유용하지 않은 문맥적 단문 (Contextual one-liners)
이후의 수정 사항에 의해 대체된 관찰 내용
여러 세션에서 나타난 중복된 통찰 (중복 제거 (dedup) 과정에서 포착됨)

하룻밤에 1개만 승격되는 비율은 의도된 것입니다. 737:1의 거부 비율을 견뎌내고 살아남은 메모리 (memory)는 실제로 행동을 변화시키는 종류의 신호입니다. 모든 것이 승격된다면, 아무것도 중요하지 않게 됩니다.

이를 실행하는 설정 (Config)

크론 잡 (cron job) 자체는 간단합니다. OpenClaw 네이티브 방식으로, 매일 아침 격리된 에이전트 턴 (agentTurn)을 실행합니다:

{
  "name": "Dreaming Sweep",
  "schedule": { "kind": "cron", "expr": "5 7 * * *", "tz": "UTC" },
...

프롬프트는 의도적으로 가볍게 설계되었습니다. 실제 핵심적인 작업(heavy lifting)은 Dreaming 스크립트 내부의 스코어링 로직(~/.openclaw/workspace/scripts/dreaming-sweep.py)이 수행하며, 이 스크립트가 FTS5 검색 쿼리(recall queries), 중복 제거(deduplication), 그리고 게이트 스코어링(gate scoring)을 처리합니다. 에이전트는 단지 출력을 검토하고 일기(diary)를 작성할 뿐입니다.

이것이 에이전트 설계에서 왜 중요한가

대부분의 AI 에이전트 튜토리얼은 두 가지, 즉 도구(tools)와 프롬프트(prompts)에 집중합니다. 에이전트에게 더 많은 도구를 주고, 더 나은 프롬프트를 작성하며, 더 많은 데이터 소스에 연결하는 방식입니다. 이것은 확장(expansion) 단계입니다.

하지만 어느 시점에 이르면 모든 에이전트는 정체기(plateau)에 도달합니다. 에이전트가 어떤 도구가 효과적인지 기억하지 못한다면 더 많은 도구는 도움이 되지 않습니다. 신호 대 잡음비(signal-to-noise ratio)가 무너진다면 더 많은 컨텍스트(context)도 도움이 되지 않습니다. 이것이 통합(consolidation) 문제이며, 대부분의 에이전트 구축이 멈추는 지점입니다.

Dream Protocol은 이에 대한 일반적인 해결책을 시도한 것입니다: 메모리를 단순한 서류 보관함이 아닌, 학습 시스템(learning system)으로 취급하는 것입니다. 에이전트가 스스로의 실패를 경험하고, 세션 전반에 걸친 패턴을 관찰하며, 무언가 잘못될 때마다 제가 수동으로 개입하지 않아도 그에 따라 행동을 업데이트하도록 하는 것입니다.

완벽하냐고요? 아닙니다. 스코어링 게이트(scoring gates)는 수동으로 조정(hand-tuned)되었고, 승격률(promotion rate)이 낮아 행동 변화를 확인하는 데 몇 주가 걸리며, 이러한 변화가 실제로 결과를 개선하는지 측정할 자동화된 방법도 아직 없습니다. 그 부분은 작업 중입니다.

하지만 핵심 아이디어는 타당합니다: 잠을 자는 에이전트는 학습하는 에이전트입니다. 설령 그것이 하룻밤에 단 하나의 진실된 정보(true thing)일지라도 말입니다.

여러분의 OpenClaw에서 Dream Protocol을 실행하고 계신가요? 여러분의 에이전트가 무엇을 승격(promotes)시키는지 정말 듣고 싶습니다. 토론란에 남겨주세요. 커뮤니티에는 대규모 환경에서 메모리 위생(memory hygiene)이 실제로 어떤 모습인지에 대한 더 많은 실전 데이터가 필요합니다.