대화가 쌓일수록 기억이 흐려진다 — OpenClaw가 잠을 자며 기억을 정리하는 방법

오픈소스 개인 AI 어시스턴트 OpenClaw를 집 서버에 올려 쓰면서 메뉴들을 하나씩 뜯어봤다. 그중 가장 낯설고 흥미로웠던 게 "Dreaming(드리밍)" 메뉴였다. 화면에는 별이 깔린 밤하늘과 자고 있는 바닷가재(OpenClaw의 마스코트) 한 마리가 떠 있고, 머리 위 말풍선에는 "기억을 통합하는 중…", "느슨한 생각을 정리하는 중…" 같은 문구가 6초마다 바뀐다. 처음엔 그냥 귀여운 장식인 줄 알았는데, 알고 보니 이건 에이전트가 유휴 시간에 자기 기억을 정리하는 실제 백그라운드 작업의 상태창이었다. 이 글은 "왜 AI 에이전트가 잠을 자야 하는가"라는 질문을 따라간다.

배경 — 에이전트의 기억은 그냥 마크다운 파일이다

OpenClaw가 세션을 넘어 무언가를 "기억"하는 방식은 의외로 단순하다. 숨겨진 신경망 상태 같은 게 아니라, 에이전트 작업 폴더에 쓰이는 평범한 마크다운 파일이다. 모델은 디스크에 저장된 것만 기억한다 — 안 적으면 잊는다. 기억은 세 층으로 나뉜다.

다이어그램 설명. 이 그림은 OpenClaw 기억의 세 층과 그 사이의 흐름을 보여준다. 맨 위 일일 노트는 그날 오간 대화와 관찰을 거의 그대로 받아 적는 원본 로그고, 매 턴 프롬프트에 자동으로 끼지는 않지만 검색(memory_search)으로는 찾을 수 있다. 가운데 MEMORY.md는 매 대화 시작 때 모델 맥락에 통째로 주입되는 압축된 큐레이션 층이라, 검증된 사실과 선호만 짧게 담아야 한다. 핵심은 위에서 아래로 가는 "증류(distill)" 화살표다 — 일일 노트에 흩어진 유용한 조각을 골라 장기 기억으로 옮기는 작업이 따로 필요하다는 뜻이다. 놓치기 쉬운 함정은 "그냥 다 MEMORY.md에 적으면 되지 않나"라는 생각인데, 그러면 매 대화마다 그 비대한 파일이 통째로 프롬프트에 실려 들어가 토큰을 잡아먹는다. 그래서 무슨 가치가 있나 — 기억을 층으로 나눈 덕에 "자주 쓰는 핵심"과 "찾으면 나오는 원본"을 분리해 둘 수 있다.

핵심 문제 — 로그는 쌓이는데 정리는 아무도 안 한다

문제는 위 그림의 "증류" 화살표를 누가 언제 당기느냐다. 에이전트를 며칠만 써 봐도 일일 노트는 빠르게 불어난다. 어제 얘기한 라우터 설정, 그제 잡담한 영화, 지난주 디버깅 로그가 전부 같은 폴더에 날짜별로 쌓인다. 그런데 이 더미에서 "장기적으로 기억할 가치가 있는 사실"을 골라 MEMORY.md로 옮기는 작업은 자동으로 일어나지 않는다. 그러면 두 가지가 동시에 나빠진다.

다이어그램 설명. 이 그림은 정리되지 않은 기억이 만드는 세 갈래 문제를 보여준다. 첫째, 원본 로그가 비대해질수록 정작 중요한 사실(예: "사용자는 TypeScript를 선호한다")이 잡담과 중복된 문장 사이에 묻혀, 의미 기반 검색을 돌려도 노이즈에 점수가 분산돼 회상 품질(질문에 맞는 기억을 정확히 길어 올리는 능력)이 떨어진다. 둘째, 만약 모든 걸 장기 기억에 욱여넣으면 MEMORY.md가 프롬프트 주입 예산을 넘겨, OpenClaw가 파일은 그대로 둔 채 모델에 넣는 사본만 잘라낸다 — 결국 일부 기억은 있어도 안 보인다. 셋째가 가장 현실적인데, "그럼 사람이 가끔 정리하면 되잖아"라는 해법은 거의 지켜지지 않는다는 점이다. 세 화살표가 한 근원("누적")에서 갈라지는 게 핵심이다 — 단순히 저장 공간 문제가 아니라 정리 주체의 부재가 회상·효율·운영을 한꺼번에 무너뜨린다. 그래서 무슨 가치가 있나 — 이 그림은 "기억을 적는 것"과 "기억을 정리하는 것"이 별개의 작업이고, 후자를 자동화하지 않으면 시간이 갈수록 에이전트가 더 멍청해진다는 걸 말해 준다.

해결 방법 — 사람이 자듯, 유휴 시간에 기억을 정리한다

OpenClaw의 답은 이름 그대로다. 사람이 자는 동안 뇌가 그날의 기억을 정리·통합한다는 수면 과학의 발상을 그대로 빌려, 에이전트가 한가한 시간(기본값 매일 새벽 3시)에 기억을 정리하는 백그라운드 작업을 돌린다. 이걸 "Dreaming(꿈꾸기)"이라 부르고, 기본은 꺼져 있는 옵트인(사용자가 직접 켜야 동작) 기능이다. 한 번의 정리 작업(sweep)은 사람의 수면 단계를 본떠 세 국면을 순서대로 거친다.

다이어그램 설명. 이 그림은 한 번의 꿈 sweep이 거치는 세 단계와, 오직 마지막 단계만 장기 기억에 쓴다는 구조를 보여준다. 위에서부터 읽으면 — 얕은 잠은 최근 일일 노트와 회상 기록을 모아 중복을 걷어내고 후보 줄을 추려 두기만 한다(장기 기억엔 안 씀). 렘수면은 흩어진 자료에서 반복되는 주제와 성찰을 뽑아 요약한다(역시 안 씀). 마지막 깊은 잠만이 후보들을 점수로 매겨 기준을 넘는 것만 MEMORY.md에 올린다. 점선 두 개가 중요한데, 앞 두 단계가 남긴 "강화 신호"(이 항목이 얼마나 자주·다양한 맥락에서 떠올랐는지)가 마지막 점수 계산에 보태진다는 뜻이다. 여기서 노드 ID가 아니라 단계 이름으로 말하자면, 왜 정리(얕은 잠)와 반성(렘수면)을 승격(깊은 잠)과 분리했을까 — "무엇을 후보로 볼지"와 "무엇을 진짜 기억할지"를 나누면, 정리 과정이 함부로 장기 기억을 오염시키지 않기 때문이다. 놓치기 쉬운 함정은 이 세 단계를 "사용자가 고르는 모드"로 오해하는 것인데, 실제로는 사용자에게 안 보이는 내부 구현일 뿐 하나의 sweep이 항상 셋을 순서대로(얕은 잠 → 렘수면 → 깊은 잠) 다 거친다. 그래서 무슨 가치가 있나 — 정리·반성은 자유롭게 하되 장기 기억은 단 하나의 관문(깊은 잠)을 통해서만 바뀌므로, 자동 정리를 켜도 기억이 엉망이 될 위험이 통제된다.

승격 관문 — 아무거나 장기 기억이 되지 않는다

깊은 잠이 "기억할 가치"를 어떻게 판단하는지가 이 시스템의 신뢰성을 좌우한다. 단순히 "자주 나왔으니 기억"이 아니라, 여섯 개의 가중 신호를 합산한 점수가 임계값을 넘어야 하고, 추가로 최소 회상 횟수와 최소 질의 다양성 같은 게이트도 통과해야 한다.

다이어그램 설명. 이 그림은 단기 후보 하나가 장기 기억으로 승격될지 결정되는 채점·관문 구조를 보여준다. 가운데 점수 계산은 여섯 신호의 가중합인데, 가중치를 보면 설계 의도가 읽힌다 — 가장 높은 0.30은 "평균 검색 품질"(이 기억이 실제 질문에 얼마나 잘 들어맞았나)이고, 그다음 0.24가 "누적 신호 수"다. 즉 자주 떠오르되, 떠오를 때마다 실제로 쓸모 있었던 항목을 우대한다. 아래쪽 마름모가 관문인데, 점수만으로는 부족하고 최소 회상 횟수와 질의 다양성까지 함께 넘어야 통과한다 — 한 번 우연히 높은 점수를 받은 게 아니라 여러 맥락에서 반복 확인된 것만 거르려는 장치다. 통과한 후보도 곧장 쓰지 않고 라이브 일일 파일에서 원문을 다시 확인하는데, 그사이 삭제·변경된 낡은 조각이 장기 기억에 박히는 걸 막기 위함이다. 놓치기 쉬운 함정은 "점수가 높으면 무조건 승격"이라는 오해다 — 실제로는 점수와 게이트라는 두 겹의 문을 모두 통과해야 한다. 그래서 무슨 가치가 있나 — 이 다단계 관문 덕에 잡담 한마디나 일회성 사실이 영구 기억으로 굳는 일을 막아, 장기 기억을 계속 "고신호(high signal)" 상태로 유지한다.

꿈 일기 — 사람이 검토할 수 있게 서술로 남긴다

정리가 기계 내부에서만 일어나면 사용자는 "에이전트가 뭘 기억했는지" 알 수 없다. OpenClaw는 그래서 각 단계가 끝날 때마다 꿈 일기(Dream Diary)를 DREAMS.md에 서술 형태로 덧붙인다. 백그라운드 서브에이전트(별도 모델 턴)가 "오늘 무슨 일이 있었고, 무엇을 반성했고, 어떤 후보가 떠올랐는지"를 사람이 읽을 수 있는 짧은 글로 적어 둔다.

다이어그램 설명. 이 그림은 꿈 일기가 만들어져 사람에게 닿는 경로와, 그것이 장기 기억과 분리돼 있다는 점을 보여준다. 각 단계가 끝나면 별도 모델 턴이 한 번 돌아 그날의 정리·반성을 산문으로 적고, 그 결과가 DREAMS.md에 쌓여 Control UI의 Dreams 탭에서 읽힌다. 가장 중요한 건 오른쪽 아래로 빠지는 점선이다 — 이 일기는 사람이 읽으라고 만든 것이지 승격의 근거가 아니다. 꿈이 지어낸 서술이 다시 장기 기억의 입력으로 들어가면, 모델이 자기 요약을 사실로 착각하는 자기참조 오염이 생길 수 있다. 그래서 일기·리포트 같은 꿈 산출물은 단기 승격 대상에서 명시적으로 제외되고, 오직 근거 있는(grounded) 원본 기억 조각만 MEMORY.md 승격 자격을 얻는다. 놓치기 쉬운 함정이 바로 이 분리인데, "일기에 적혔으니 에이전트가 그걸 기억하겠지"라고 믿으면 안 된다 — 일기는 거울일 뿐, 기억의 본체가 아니다. 그래서 무슨 가치가 있나 — 정리 과정을 설명 가능하고 검토 가능하게 만들어, 사용자가 승격 결과를 신뢰할지 직접 눈으로 보고 판단할 수 있다.

Dreaming 메뉴 — 켜고 끄고, 꿈 일기를 들여다본다

Control UI의 Dreaming 메뉴는 이 모든 걸 사람이 조작·관찰하는 창이다. 세 개의 하위 탭으로 나뉜다. 첫 탭은 별 깔린 밤하늘과 자는 가재가 있는 장면(Scene)으로, 지금 꿈을 꾸는 중인지(active/idle), 오늘 몇 개가 승격됐는지, 다음 sweep이 언제인지를 보여준다. 둘째 탭은 꿈 일기(Diary) 열람으로, 날짜별 칩을 눌러 그날의 일기를 읽는다. 셋째 고급(Advanced) 탭은 승격 대기 중인 단기 항목들을 신호·최근순으로 정렬해 보여주고, 중복 제거·백필·리셋 같은 운영 버튼을 제공한다.

다이어그램 설명. 이 그림은 Dreaming 메뉴가 세 탭으로 역할을 나눈 구조와, 별도의 슬래시 명령으로도 켜고 끌 수 있다는 점을 보여준다. 왼쪽부터 — 현재 상태를 한눈에 보는 장면 탭, 과거 정리 내역을 산문으로 읽는 일기 탭, 그리고 실제 승격 후보 데이터를 들여다보며 손볼 수 있는 고급 탭으로 점점 "관찰"에서 "조작"으로 무게가 옮겨간다. 일기 탭은 보여줄 때 [memory/2026-04-09.md:9] 같은 출처 인용과 "What Happened" 같은 내부 구현용 제목을 떼어 내고 순수 산문 문단만 렌더한다 — 사용자에게는 결과 서술만 깔끔히 보이게 하려는 의도다. 아래 점선의 슬래시 명령(/dreaming on, off, status)은 UI를 안 열고도 채팅창에서 바로 드리밍을 토글하는 경로다.

결과 — 무엇이 좋아졌나

드리밍이 들어오면서 앞서 본 세 문제가 이렇게 정리된다.

드리밍 없을 때	드리밍 켰을 때
중요한 사실이 잡담·중복에 묻혀 회상 품질 저하	유휴 시간에 중복 제거·점수화 → 고신호 항목만 장기 기억으로
다 욱여넣으면 MEMORY.md 비대 → 프롬프트에서 잘림	임계값 관문이 일회성·잡담을 거르고 압축된 큐레이션 층 유지
사람이 손으로 정리해야 → 현실적으로 방치	매일 새벽 자동 sweep + 슬래시 명령으로 토글
에이전트가 뭘 기억했는지 불투명	꿈 일기로 서술 기록 → Dreams 탭에서 검토 가능

정리하면, OpenClaw의 드리밍은 "적는 것"과 "정리하는 것"을 분리해, 후자를 에이전트가 잠자듯 알아서 하게 만든 장치다. 사람이 자는 동안 그날의 경험에서 쓸 것만 추려 장기 기억으로 옮기듯, 에이전트도 한가한 새벽에 일일 로그를 훑어 반복 확인된 사실만 골라 올리고 나머지는 검색 가능한 원본으로 남겨 둔다. 화려한 대화 능력보다 이런 "기억을 스스로 관리하는 능력"이 사실 오래 쓰는 개인 비서의 진짜 조건이다 — 시간이 갈수록 똑똑해지는 비서와 점점 산만해지는 비서를 가르는 건, 결국 잊을 것을 잊고 기억할 것을 기억하는 정리 습관이기 때문이다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.