🎬 I Fixed OpenClaw's Biggest Problem (Memory)

▶️ 유튜브

• 원본 링크: https://youtu.be/rUbQy05Boto?si=jjsYR_wyYvW3MZJY

🖼️ 4컷 인포그래픽

💡 한 줄 결론

OpenClaw 메모리의 성패는 저장량이 아니라 회수율과 관계 해석 능력에 달려 있으며, 장기 운용에서는 기본 설정만으로 정확도가 빠르게 무너진다. 실전에서는 memoryFlush 신호를 먼저 정교화하고, 이후 session indexing·QMD·Mem0·Cognee를 문제 유형에 맞춰 단계적으로 붙이는 전략이 핵심이다.

📌 핵심 요점

1. MEMORY.md와 daily logs로 나뉜 기본 저장 구조는 단순하지만, 실제 품질은 무엇을 얼마나 저장했는지보다 필요한 청크를 얼마나 정확히 다시 불러오느냐에 더 크게 좌우된다.
2. 기본 메모리 시스템은 저장 판단을 모델에 맡기기 때문에 장기 선호·핵심 결정·사람-역할 관계 같은 중요한 정보는 빠뜨리고, 반대로 주변 잡음은 장기 기억에 남길 위험이 크다.
3. session indexing은 과거 대화까지 검색 범위를 넓혀 회상 범위를 키우지만, flush 신호가 정제되지 않으면 coverage 확대보다 noise 확대 효과가 더 크게 나타날 수 있다.
4. 메모리 규모가 커질수록 기본 검색은 정확도가 떨어지며, QMD처럼 키워드·의미 검색·재정렬을 결합한 검색 백엔드가 대용량 환경에서 더 현실적인 업그레이드 경로가 된다.
5. Mem0는 저장·회상 자동화로 missed write와 compaction 손실을 줄이고, Cognee는 ownership·dependency 같은 관계 추론을 보완하지만, 개인용 단순 셋업에서는 복잡도 대비 효용을 먼저 따져야 한다.

🧠 상세 요약

1) 배경과 문제 정의

에이전트를 오래 굴릴수록 문제는 모델 자체보다 메모리 운영 품질에서 터진다. 무엇을 남길지, 나중에 무엇을 다시 찾을지, 그리고 흩어진 사실들을 어떻게 연결할지가 성능을 가르기 때문이다. 이 영상은 OpenClaw 메모리가 초반엔 버틸 수 있어도 장기 운용에서 왜 누락·잡음·관계 추론 실패가 쌓이는지, 그리고 이를 어떤 순서로 보강해야 하는지를 짚는다.

2) 섹션별 상세 정리

1. 메모리는 에이전트 품질을 좌우하는 핵심 인프라다 [00:00]

• 발표자는 가장 많이 받은 질문이 메모리 개선법이었다고 밝히며, 에이전트 시스템에서 메모리가 사실상 성능의 중심축이라고 전제한다.
• 이번 영상의 초점은 OpenClaw 메모리의 구조 설명이 아니라, 왜 기본 상태로는 오래 못 버티는지와 실전 보강 경로를 단계별로 제시하는 데 있다.

2. OpenClaw 메모리는 저장층과 검색층으로 나뉜다 [00:22]

• 메모리의 저장층은 로컬 Markdown 파일이며, 대표적으로 장기 기억용 MEMORY.md와 일자별 기록인 daily logs가 핵심 역할을 맡는다.
• 다음 달에도 남아야 할 정보는 MEMORY.md, 당일 맥락 중심 정보는 daily logs로 가는 구조인데, 이 파일 자체는 원본 기록일 뿐 실제 성능은 검색층이 얼마나 잘 꺼내오느냐에 달려 있다.

3. 회상은 전체 읽기가 아니라 하이브리드 검색으로 이뤄진다 [01:01]

• 에이전트는 메모리 파일 전체를 프롬프트에 넣지 않고, exact keyword search와 semantic search를 결합해 관련 청크만 가져온다.
• 그래서 메모리 문제는 저장 공간 부족보다 retrieval 품질 문제에 가깝고, 장기 운용에서 병목도 결국 검색 정확도로 이동한다.

4. 중간에 MaxClaw 배포 옵션이 스폰서로 소개된다 [01:17]

• 발표자는 직접 인프라를 세팅하기 어려운 사용자를 위해 MiniMax의 MaxClaw를 OpenClaw 배포 대안으로 제시한다.
• 24시간 동작, 19달러 원클릭 배포, 모바일 앱 및 Telegram·Discord·Slack 연동 가능성 등을 소개한 뒤 본론인 메모리 문제로 복귀한다.

5. 기본 메모리는 저장 단계부터 신호가 불안정하다 [02:05]

• 기본 시스템의 첫 번째 약점은 무엇을 저장할지에 대한 판단을 모델에게 맡긴다는 점이다.
• 이 구조에서는 장기 선호, 핵심 의사결정, 관계 정보처럼 중요한 항목이 누락되기 쉽고, 반대로 사용자가 원치 않는 주변 문장이 장기 메모리에 남을 수 있다.

6. 저장돼도 활용되지 않거나 compaction 과정에서 손실된다 [02:18]

• 정보가 파일에 저장돼 있어도 실제 답변 시 메모리 검색보다 현재 컨텍스트만 보고 응답하는 경우가 있어 저장과 활용이 분리된다.
• compaction 과정도 문제다. 기본 memoryFlush는 정말 중요한 사실보다 일반 잡음을 더 저장하는 경향이 있고, 기본 설정만으로는 과거 세션 전체를 탐색하지 못해 회상 범위도 좁다.

7. 메모리가 커질수록 검색 정확도와 관계 이해가 동시에 무너진다 [02:40]

• 초기에는 잘 맞아 보이던 검색도 파일과 청크가 늘어나면 엉뚱한 조각을 상위로 끌어올리는 일이 많아진다.
• 더 큰 한계는 관계 추론이다. “Sarah가 백엔드를 관리한다”와 “API는 누가 담당하나” 같은 질문 사이의 ownership 연결을 기본 메모리는 잘 해석하지 못한다.

8. 첫 번째 보강은 memoryFlush 기준을 구체화하는 것이다 [03:07]

• memoryFlush는 컨텍스트에서 사라지기 전 중요한 정보를 메모리로 옮기는 장치지만, 기본 프롬프트인 “Store durable memories”만으로는 무엇이 durable한지 정의하지 못한다.
• 장기 선호, 반복 규칙, 프로젝트 상태 변화, 사람-역할 관계, 핵심 결정처럼 저장 대상 범주를 명시하면 품질이 개선되지만, 기준을 느슨하게 잡으면 이후 retrieval noise도 함께 증가한다.

9. 두 번째 보강은 과거 세션 검색을 여는 session indexing이다 [03:51]

• session indexing을 켜면 메모리 파일뿐 아니라 과거 대화까지 검색 가능해져 recall coverage는 확실히 넓어진다.
• 다만 불완전한 과거 발화와 잡음도 함께 유입되므로, 이 단계에서는 flush 신호 품질 관리가 더 중요해진다. 넓은 검색 풀이 항상 더 좋은 메모리를 뜻하지는 않는다.

10. 현실적으로 가장 안전한 운영은 수동 저장과 정기 정리다 [04:10]

• 발표자는 꼭 남겨야 할 정보는 사용자가 직접 저장 지시를 내리는 방식이 가장 안정적이라고 본다.
• 중요한 세션 후 핵심 결정을 정리해 선별 저장하고, 최소 주 1회 메모리 파일을 검수해 불필요한 내용을 걷어내는 습관을 권한다. 도구로는 Obsidian 같은 Markdown 편집 환경을 추천한다.

11. 메모리가 커지면 검색 엔진 자체를 바꿔야 할 수 있다 [04:41]

• 초반에는 프롬프트 수정과 수동 관리만으로도 충분할 수 있지만, 메모리 규모가 커지면 병목은 저장 규칙이 아니라 검색 백엔드 성능이 된다.
• 기본 검색은 대규모 메모리 운용을 전제로 설계된 것이 아니어서, 일정 규모를 넘기면 구조적으로 정확도 저하가 불가피하다는 진단이다.

12. QMD는 대용량 메모리용 현실적인 검색 업그레이드다 [04:56]

• QMD는 키워드 검색과 의미 검색을 결합하고 re-ranking까지 수행해 대량 메모리에서 더 적절한 결과를 상위에 올리는 구조를 가진다.
• 설치 난도는 있지만, 메모리 백엔드를 qmd로 바꾸는 것만으로도 retrieval 품질을 끌어올릴 수 있는 현실적 선택지로 제시된다.

13. Mem0는 저장과 회상을 별도 레이어로 자동화한다 [05:15]

• Mem0는 무엇을 저장할지, 언제 다시 불러올지를 에이전트 본체의 즉흥적 판단 밖으로 분리해 자동화하는 메모리 계층이다.
• 이 방식은 missed write와 compaction 손실을 줄이고, 응답 전에 relevant memory를 재호출해 저장과 회상의 단절 문제를 동시에 완화한다.

14. Cognee는 관계형 지식 추론을 보완한다 [05:51]

• Cognee는 단순 유사도 검색을 넘어서 문서 간 관계를 그래프로 연결해 ownership, dependency, 책임 구조 같은 관계형 질의를 더 잘 처리하게 돕는다.
• 다만 기업 지식베이스나 멀티에이전트 환경처럼 관계 정보가 복잡한 경우에 특히 유효하며, 단순한 개인용 OpenClaw 셋업에는 과한 선택일 수 있다고 선을 긋는다.

✅ 액션 아이템

• 현재 OpenClaw 설정에서 memoryFlush 프롬프트를 열어 장기 선호, 핵심 의사결정, 사람-역할 관계, 반복 운영 규칙 4개 범주를 명시한 버전으로 바꾸고, 같은 대화 샘플로 저장 결과를 전후 비교한다.
• 최근 1~2주 세션에서 MEMORY.md와 daily logs를 샘플링해 누락 항목 10개, 과잉 저장 항목 10개를 분류하고, 자동 저장이 특히 약한 정보 유형을 태깅 기준으로 정리한다.
• session indexing 활성화 전후로 동일한 질의 세트 5~10개를 만들어 recall coverage, 상위 결과 noise 비율, 실제 답변 반영률을 함께 측정해 precision 악화 여부를 확인한다.
• 메모리 규모가 이미 커진 환경이라면 기본 검색과 QMD를 같은 질문 묶음으로 비교해 상위 결과 정확도, 관계 정보 회수율, 오답 빈도를 로그 단위로 기록한다.
• “누가 무엇을 책임지는가”, “어떤 시스템이 무엇에 의존하는가” 같은 질문이 자주 나오는 워크플로라면, Mem0 도입 전에는 저장·회상 누락 사례를, Cognee 검토 전에는 관계 추론 실패 사례를 각각 따로 수집해 어느 레이어가 병목인지 먼저 판별한다.

❓ 열린 질문

• session indexing이 recall을 실제로 높이는 것과 사용자가 “기억을 잘한다”고 느끼는 체감을 어떻게 분리해 측정할 수 있을까?
• QMD 도입 후에도 관계형 질의 실패가 계속된다면, 병목은 검색 엔진이 아니라 메모리 표현 형식과 관계 모델링 부재에 있는 것 아닐까?
• Mem0가 저장·회상을 자동화할 때 사용자에게 불필요한 정보까지 장기 메모리화되는 위험은 어떤 정책과 필터로 통제해야 할까?
• Cognee 같은 관계형 지식 엔진은 프로젝트 수, 사람 수, 책임 관계 복잡도가 어느 수준을 넘을 때부터 개인용 셋업에서도 투자 가치가 생길까?