🎬 Why your OpenClaw agent forgets everything (and how to fix it)

▶️ 유튜브

• 원본 링크: https://youtu.be/oN__gKJnPls?si=mYtt_T54k4C7bFGi

🖼️ 4컷 인포그래픽

💡 한 줄 결론

OpenClaw 에이전트의 장기 안정성은 프롬프트 문구가 아니라 파일 기반 메모리, overflow 이전 pre-compaction flush, 행동 전 memory_search 의무화가 함께 작동할 때 만들어진다. 중요한 운영 규칙을 채팅에만 남기면 긴 세션에서 사라질 수 있으므로, 반드시 워크스페이스 파일·검색·권한 제어로 옮겨야 한다.

📌 핵심 요점

1. 긴 세션의 핵심 리스크는 compaction 자체보다 채팅으로 준 지시가 계속 유지될 것이라는 잘못된 운영 가정이며, 실제 사고는 이 가정이 깨질 때 발생한다.
2. OpenClaw 메모리는 bootstrap files, session transcript, LLM context window, retrieval index의 4층 구조로 작동하고, 각 층은 저장 누락·요약 손실·tool result pruning·검색 미실행처럼 서로 다른 방식으로 실패한다.
3. 안정성을 높이려면 AGENTS.md·MEMORY.md 같은 파일 저장, reserve headroom을 둔 pre-compaction flush, 행동 전 memory_search 규칙을 동시에 운용해야 한다.
4. 메모리 문제는 설정 변경부터 건드리기보다 /context list로 MEMORY.md 주입 여부와 truncation 상태를 먼저 확인해야 원인을 compaction·pruning·파일 누락 중 어디로 볼지 분리할 수 있다.
5. 불필요한 compaction은 문맥 손실뿐 아니라 prompt cache를 깨뜨려 비용도 악화시키므로, MEMORY.md는 짧고 안정적으로 유지하고 /compact는 overflow 직전이 아니라 의도적으로 써야 한다.

🧠 상세 요약

1) 배경과 문제 정의

긴 세션에서 에이전트가 “지시를 잊었다”는 문제는 막연한 성능 저하가 아니라, 어떤 정보가 어디에 저장되고 언제 현재 문맥에서 사라지는지의 구조적 문제다. 이 영상은 OpenClaw에서 안전한 운영을 하려면 채팅 지시, 파일 메모리, 자동 저장, 검색 규칙을 서로 다른 계층으로 나눠 설계해야 한다는 점을 보여준다.

2) 섹션별 상세 정리

1. 실제 사고가 보여준 핵심 위험 [00:00]

• Meta의 정렬 연구자 Summer Yue 사례를 통해, “내가 말하기 전까지 아무것도 하지 말라”는 채팅 지시가 세션 길이가 늘어난 뒤 사라질 수 있음을 보여준다.
• 테스트 환경에서는 잘 버티던 규칙도 실제 대규모 받은편지함에서는 컨텍스트 포화와 compaction 이후 유지되지 않았고, 그 결과 에이전트가 이메일 삭제를 시작했다.

2. 문제의 본질은 compaction보다 채팅 의존 운영 [01:24]

• 발표자는 compaction 자체는 정상 동작이라고 선을 긋고, 진짜 문제는 장시간 세션에서도 채팅 지시가 계속 살아남을 것이라고 믿는 운영 습관이라고 설명한다.
• 프롬프트만으로는 행동을 강제할 수 없고, 실제 안전은 권한 게이트·도구 제한·파일 기반 규칙처럼 더 단단한 구조에서 나온다고 본다.

3. 실전에서 먼저 깔아야 할 세 가지 수칙 [01:59]

• 장기적으로 유지돼야 하는 규칙은 MEMORY.md, AGENTS.md 같은 파일에 넣어 compaction 이후에도 다시 로드되게 해야 한다.
• 동시에 pre-compaction memory flush가 실제 발동할 여유 공간을 확보하고, AGENTS.md에 “행동 전 memory_search” 규칙을 넣어 추측형 응답을 막아야 한다.

4. OpenClaw 메모리는 네 개의 층으로 작동한다 [03:01]

• bootstrap files는 세션 시작마다 디스크에서 다시 주입되므로 가장 내구성이 높고, session transcript는 길어지면 원문 대신 compact summary로 대체된다.
• 여기에 모든 입력이 경쟁하는 LLM context window와, 필요 시 관련 정보만 다시 찾는 retrieval index가 더해져 전체 메모리 체계가 구성된다.

5. 에이전트가 잊는 방식도 층마다 다르다 [04:52]

• 어떤 정보는 애초에 파일에 저장되지 않아 새 세션이나 compaction 뒤에 사라지고, 어떤 정보는 compaction summary 과정에서 뉘앙스와 제약이 손실된다.
• 또 다른 경우는 pruning으로 오래된 tool result가 잘려 나가는 것인데, 이는 대화 구조 자체를 바꾸는 compaction과는 구분해서 진단해야 한다.

6. compaction과 pruning을 혼동하면 처방이 틀어진다 [06:42]

• compaction은 모델이 보는 전체 대화 자체를 요약본으로 바꾸기 때문에, 이후 판단 기준이 원문이 아니라 압축 결과로 이동한다.
• 반면 pruning은 주로 오래된 tool result를 줄이는 과정이라 디스크의 원본 세션 기록이나 사용자·어시스턴트 메시지 구조를 직접 바꾸지 않는다.

7. 메모리 문제의 첫 진단 도구는 /context list다 [08:03]

• MEMORY.md가 실제로 주입됐는지, AGENTS.md와 TOOLS.md가 truncation 없이 온전히 들어왔는지부터 봐야 설정 변경의 의미가 생긴다.
• raw characters와 injected characters가 다르면 에이전트는 파일 전체를 보지 못하는 상태이며, 이 경우 메모리 실패를 단순히 모델 문제로 보면 안 된다.

8. 좋은 compaction과 나쁜 compaction은 다르다 [10:06]

• 좋은 경로는 overflow 전에 memory flush가 먼저 발동해 중요한 내용을 디스크에 남기고, 그 다음 compaction이 일어나는 maintenance compaction이다.
• 나쁜 경로는 이미 API가 요청을 거절할 정도로 넘친 뒤 강제 복구 compaction이 일어나는 경우로, 이때는 저장해야 할 내용이 디스크에 남지 못한 채 손실이 커진다.

9. headroom 설계가 안정성을 좌우한다 [13:42]

• reserveTokensFloor와 softThresholdTokens의 핵심은 “얼마나 일찍 플러시를 걸어 overflow 전에 저장 기회를 확보할 것인가”에 있다.
• 발표자는 40,000 reserve를 실용적 출발점으로 제시하지만, 본질은 숫자 암기가 아니라 대용량 파일·브라우저 스냅샷·도구 출력이 많은 워크로드에 맞게 충분한 여유를 남기는 데 있다.

10. 자동 flush만으로는 부족해 수동 저장이 필요하다 [15:55]

• 자동 flush는 임계치 기반 안전망이어서 지금 막 일어난 중요한 결정이나 작업 전환 지점을 항상 포착하지는 못한다.
• 그래서 숙련 사용자는 큰 작업 종료 직후, 복잡한 새 지시 직전, 중요한 의사결정 직후에 MEMORY.md나 daily memory에 직접 저장하는 습관을 함께 둔다.

11. /compact는 회피 대상이 아니라 운영 도구다 [17:08]

• 수동 compaction을 적절한 시점에 실행하면 문맥을 가볍게 만든 상태에서 같은 작업을 더 오래 이어갈 수 있고, 요약 우선순위도 어느 정도 지정할 수 있다.
• 다만 overflow 직전까지 버티다가 /compact를 시도하면 실패할 수 있으므로, 자동 compaction에 끌려가기 전에 선제적으로 쓰는 편이 낫다.

12. 무엇을 어디에 저장할지 역할을 나눠야 한다 [19:12]

• SOUL.md는 캐릭터와 경계, AGENTS.md는 워크플로와 금지 규칙, USER.md는 사용자 환경과 선호, MEMORY.md는 세션을 넘어 유지돼야 할 핵심 결정만 담는 구조가 효율적이다.
• daily memory는 장기 치트시트가 아니라 일일 작업 문맥과 로그를 쌓는 곳이므로, 주간 단위로 중요한 것만 MEMORY.md로 승격시키는 memory hygiene가 필요하다.

13. retrieval이 붙어야 파일 메모리가 실제로 살아난다 [23:22]

• 정보를 파일에만 써두고 검색 규칙이 없으면 에이전트는 현재 문맥만 보고 추측해 행동할 수 있다.
• memory_search와 memory_get은 “현재 컨텍스트 기반 추정”을 “행동 전 근거 확인”으로 바꿔주는 장치이며, AGENTS.md에 이 절차를 명문화해야 재현성이 올라간다.

14. Track A와 Track B는 규모 차이의 선택지다 [27:09]

• 대부분의 사용자는 내장 memory_search와 hybrid search만으로 충분하며, 필요하면 워크스페이스 밖 Markdown까지 확장하는 A+로 갈 수 있다.
• Obsidian vault, 다량의 세션 transcript, 다중 컬렉션 검색이 필요해지면 QMD 같은 Track B가 더 적합해진다.

15. 메모리 아키텍처는 신뢰성뿐 아니라 비용 설계이기도 하다 [32:02]

• compaction은 prompt cache를 깨뜨려 이후 요청 비용을 다시 키우므로, 잦은 compaction은 안정성과 비용을 동시에 악화시킨다.
• 따라서 MEMORY.md를 짧고 안정적으로 유지하고, pruning으로 tool bloat를 줄이며, retrieval로 필요한 정보만 불러오는 구조가 토큰 효율까지 개선한다.

16. 최종 운영 철학은 ‘파일화·선저장·검색의무’다 [34:23]

• 발표자가 실제로 쓰는 구조는 compaction에 흔들리지 않을 규칙은 파일에 두고, overflow 전 flush로 저장 기회를 만들며, 수동 저장으로 중요 순간을 보강하는 방식이다.
• 여기에 전략적 /compact, pruning 활용, retrieval 확장, git 백업, 주간 memory hygiene를 결합해 장기 운영 가능한 메모리 체계를 만든다.

✅ 액션 아이템

• AGENTS.md에 “사소하지 않은 작업 전에는 반드시 memory_search를 실행하고, 필요 시 memory_get으로 원문을 확인한 뒤 행동한다”는 규칙을 넣어 현재 문맥 추정형 응답을 차단한다.
• /context list로 MEMORY.md, AGENTS.md, TOOLS.md의 raw/injected characters를 비교해 truncation 여부를 확인하고, 잘림이 있으면 파일 분리나 per-file·combined limit 조정을 검토한다.
• 현재 워크로드 기준으로 memoryFlushEnabled, reserveTokensFloor, softThresholdTokens를 점검하고, 대형 파일·브라우저 스냅샷 비중이 높다면 reserve headroom을 더 넉넉하게 잡는다.
• 작업 전환 직전, 중요한 결정 직후, 복잡한 신규 지시 직전에 MEMORY.md 또는 당일 daily memory로 수동 저장하는 운영 루틴을 고정한다.
• workspace의 memory/·MEMORY.md·AGENTS.md 변경 이력을 git이나 heartbeat 기반 auto-commit으로 남겨, 메모리 회귀와 오염을 diff 단위로 추적할 수 있게 만든다.

❓ 열린 질문

• 지금 겪는 메모리 실패는 실제 compaction 때문인가, 아니면 MEMORY.md truncation·검색 미실행·tool result pruning을 한데 묶어 오진하고 있는가?
• 내 워크로드에서 reserveTokensFloor 40,000 전후가 충분한가, 아니면 대형 스냅샷과 파일 읽기 때문에 overflow 이전 flush를 더 앞당겨야 한다는 근거가 있는가?
• sub-agent가 AGENTS.md만 주입받는 구조라면, 본 세션의 톤·선호·환경 정보 중 무엇을 AGENTS.md로 승격하고 무엇을 retrieval 기반으로 넘겨야 품질 저하를 줄일 수 있는가?
• MEMORY.md를 자주 수정해 캐시를 깨는 비용과, daily logs에 남겨 retrieval로 불러오는 비용 중 현재 운영에서는 어느 쪽이 더 크게 누적되고 있는가?