🎬 The Massive OpenClaw Memory Mistake You're Making Right Now

▶️ 유튜브

• 원본 링크: https://youtu.be/LHoB1C2H3f0?si=6CIQ4BWoezYScecG

🖼️ 4컷 인포그래픽

💡 한 줄 결론

이 영상의 핵심은 “메모리를 많이 저장하는 것”이 아니라 메모리의 역할을 나누는 것입니다. 현재 작업은 Obsidian 같은 작업기억 계층에, 장기 회상은 하이브리드 검색 계층에, 틀리면 안 되는 사실은 SQLite 같은 결정론적 저장소에 분리해야 OpenClaw가 장기 운영 가능한 에이전트로 바뀐다는 주장입니다.

📌 핵심 요점

1. 유튜브에 많은 메모리 튜토리얼은 “다 저장하면 기억된다”는 식으로 접근하지만, 실제로는 토큰 낭비와 회상 실패를 동시에 만든다고 지적합니다.
2. 영상은 외부 메모리 서비스나 플러그인 대신, 100% 로컬에서 굴러가는 3계층 메모리 구조를 제안합니다.
3. 1단계는 Obsidian Vault 기반 작업기억으로, 에이전트의 현재 목표·일일 로그·활성 프로젝트를 사람이 직접 보고 감독할 수 있게 합니다.
4. 2단계는 OpenClaw 기본 하이브리드 검색으로, 벡터 검색과 BM25를 함께 써 의미 기반 회상과 정확 문자열 검색을 동시에 처리합니다.
5. 3단계는 SQLite 기반 결정론적 저장소로, API 엔드포인트·통계·재무 기록 같은 정답형 데이터를 벡터 추측에서 분리합니다.
6. 초기 장기기억 회수가 실패한 장면은 시스템 결함보다 인덱싱 지연 문제였고, sync.watch를 켠 뒤 즉시 회수가 가능해집니다.
7. 영상은 “메모리 계층 분리”가 단순 편의 기능이 아니라, 에이전트를 24/7 운영 시스템으로 바꾸는 핵심 아키텍처라고 봅니다.

🧠 상세 요약

1) 배경과 문제 정의

발표자는 먼저 많은 사용자가 겪는 전형적인 좌절을 꺼냅니다. 전날 몇 시간 동안 프로젝트 맥락, 코딩 선호도, 출력 구조를 OpenClaw에게 충분히 알려줬는데, 다음 날 다시 실행하면 에이전트가 “무슨 프로젝트인지 모르겠다”고 답하는 상황입니다. 이 문제를 그는 단순한 프롬프트 실패가 아니라, 메모리를 잘못 설계한 결과라고 봅니다.

이어 기존 튜토리얼들의 한계를 정면으로 비판합니다. 기본 메모리 검색은 질의할 때마다 외부 API 비용이 숨어들 수 있고, 외부 플러그인은 개인 코드베이스를 제3자 서버에 노출할 수 있으며, “큰 마크다운 폴더 하나에 다 넣어라” 식 접근은 결국 컨텍스트 창을 쓰레기 데이터로 채워 에이전트를 헷갈리게 만든다는 것입니다. 그래서 영상은 저장량보다 회상 구조와 경계 설계가 더 중요하다는 문제의식을 깔고 시작합니다.

2) 섹션별 상세 정리

1. 왜 기존 메모리 튜토리얼이 실패하는가 [00:00]

• 발표자는 실패 원인을 사용자의 사용법이 아니라 시스템 아키텍처 오해에서 찾습니다. 메모리 문제를 “더 많이 적어 넣으면 해결된다”는 수준으로 다루면, 실제로는 같은 정보를 계속 재주입하게 되고 비용과 혼선만 늘어난다고 설명합니다.
• 특히 기본 메모리 검색의 숨은 API 비용, 외부 플러그인의 프라이버시 리스크, 거대한 마크다운 저장소가 만드는 토큰 비대화(token bloat)를 한꺼번에 비판합니다. 여기서 핵심은 “기억을 저장하는 법”보다 “기억을 어떻게 호출하고 분리할지”가 먼저라는 점입니다.

2. 해법은 단일 도구가 아니라 3계층 아키텍처다 [01:22]

• 발표자는 곧바로 해법을 “100% 로컬, 0 API 토큰”의 3계층 구조로 정의합니다. 중요한 것은 특정 툴 하나를 찬양하는 것이 아니라, 각 계층에 서로 다른 책임을 부여해 기억의 혼선을 줄이는 것입니다.
• 커뮤니티에서 자주 나오는 “QMD가 MEM0를 대체하나?”, “Obsidian만 쓰면 되나?” 같은 질문도 같은 이유로 정리합니다. 현실에서는 단일 도구 만능론이 아니라, 엄격한 경계를 가진 시스템이 필요하다고 못 박습니다.

3. 왜 QMD 대신 OpenClaw 기본 하이브리드 검색인가 [02:00]

• 영상은 QMD를 흥미로운 실험적 검색 백엔드로 인정하지만, bun 설치, 별도 사이드카 실행, 독립 모델 다운로드 등 운영 복잡도가 높다고 봅니다. 즉, 성능 실험용으로는 의미가 있어도 기본 운영 구조로 쓰기엔 부담이 크다는 판단입니다.
• 대신 OpenClaw 기본 하이브리드 검색을 선택하는 이유는 로컬 모델과 직접 통합되고, 벡터 검색과 BM25를 동시에 사용하기 때문입니다. 발표자는 벡터 검색이 의미 이해에 강하고, BM25는 비밀번호·오류 코드·정확 키워드처럼 문자열 일치가 중요한 검색에 유리하다고 분리해 설명합니다.

4. 1단계: Obsidian은 저장소가 아니라 작업기억 인터페이스다 [03:00]

• 1단계는 인간의 작업기억에 해당하며, 영상에서는 이를 위해 Obsidian Vault를 사용합니다. OpenClaw 메모리가 본질적으로 마크다운 기반이기 때문에, 사람이 직접 에이전트의 상태와 생각 흔적을 보고 수정할 수 있는 시각적 프런트엔드가 필요하다는 논리입니다.
• 이 계층에는 일일 로그, 활성 프로젝트, 현재 진행 중인 작업이 들어갑니다. 발표자는 에이전트가 길을 잃거나 막혔을 때 사용자가 Vault에 들어가 soul, memory, user 같은 문서를 직접 손보며 ‘두뇌 감독자’ 역할을 할 수 있다는 점을 강하게 강조합니다.

5. 2단계: 장기 회상은 전체 주입이 아니라 필요한 문단만 회수해야 한다 [03:21]

• 2단계는 장기 회상을 위한 의미 검색 계층입니다. 과거 프로젝트 메모 50페이지를 매번 활성 컨텍스트 창에 넣는 대신, Vault에 보관해 두고 필요할 때 검색으로 관련 문단만 꺼내오는 구조를 제안합니다.
• 이 대목의 핵심은 저장보다 회수 전략입니다. 영상은 이렇게 해야 리콜은 유지하면서도 토큰 낭비를 줄일 수 있고, 작업 로그와 노트가 계속 쌓여도 운영 가능한 구조가 된다고 설명합니다. 즉, 장기 기억은 “많이 넣는 것”이 아니라 “정확히 찾아오는 것”이 중요하다는 논지입니다.

6. 3단계: 정확해야 하는 데이터는 SQLite로 분리해야 한다 [03:49]

• 발표자는 벡터 검색이 개념과 분위기 파악에는 훌륭하지만, 구조화된 질의에는 약하다고 분명히 선을 긋습니다. 예를 들어 “인증이 필요한 API 엔드포인트를 모두 보여줘” 같은 질문에 벡터 검색은 의미적 유사성으로 추측할 수 있지만, 이 영역에서는 추측이 곧 오류입니다.
• 그래서 3단계에는 SQLite를 둡니다. 영상은 파일 기반 SQLite가 Vault 안에 함께 존재할 수 있고, 나중에 에이전트가 정확한 SQL을 작성해 정답 행(row)을 반환하게 만들 수 있다고 보여줍니다. 이 계층은 개념 회상이 아니라 결정론적 사실 회수를 위한 장치입니다.

7. Vault 연결, 장기기억 테스트, 그리고 첫 실패의 의미 [04:19]

• 실제 데모에서는 새 Obsidian Vault를 만들고, 이를 OpenClaw 설정의 workspace 경로에 연결한 뒤 게이트웨이를 재시작합니다. 이후 에이전트에게 마크다운 파일을 만들게 해서 OpenClaw와 Obsidian이 제대로 연결되었는지 검증합니다.
• 이어 민감한 정보(예: 암호화 솔트)를 저장한 뒤 에이전트의 단기 기억을 비우고 장기기억만으로 회수하는 테스트를 합니다. 처음에는 메모리 검색이 실패하지만, 발표자는 이를 “시스템이 망가졌다”가 아니라 “벡터 인덱스가 아직 덜 구워진 상태”로 해석합니다. 이때 에이전트가 1단계 원시 마크다운 파일 읽기로 폴백하는 장면을 통해, 계층 분리가 실패 완충 장치로도 작동함을 보여줍니다.

8. sync.watch와 최종 구조 완성: 실시간 회상 + 자동 정리 + 24/7 운영 [11:39]

• 문제를 해결하는 핵심 조치는 sync.watch 활성화입니다. 발표자는 파일이 바뀌는 즉시 인덱싱을 강제하면 Vault가 사실상 ‘살아 있는 두뇌’처럼 동작한다고 설명합니다. 이후 같은 질문을 다시 했을 때는 메모리 검색이 정상 동작하고, 더 이상 원시 파일 폴백 없이 벡터 계층에서 바로 회수됩니다.
• 마지막 구간에서는 SQLite 테이블 생성과 데이터 삽입을 검증하고, 오래된 로그를 자동 정리하는 defrag 스크립트와 cron/Chrome 기반 야간 예약 작업까지 소개합니다. 결국 이 영상이 말하는 진짜 메시지는 “메모리가 생겼다”가 아니라, 작업기억·의미검색·정확데이터를 분리한 뒤 자동 정리까지 붙여야 에이전트가 장기 운영 가능한 시스템이 된다는 것입니다.

✅ 액션 아이템

• 현재 OpenClaw 운영 환경에서 작업기억/장기회상/정확데이터를 한 저장소에 섞어 쓰고 있다면, 먼저 workspace markdown, semantic recall, sqlite facts로 계층을 분리해 구조도를 다시 그린다.
• Obsidian Vault를 단순 노트 저장소로 두지 말고, daily logs, active projects, memory.md처럼 에이전트 상태를 사람이 직접 감독할 수 있는 작업기억 프런트엔드로 재설계한다.
• 장기 회상은 “전체 문서 주입” 대신 “문단 단위 검색 회수”로 테스트하고, 실제 토큰 사용량·응답 정확도·회상 성공률을 비교해본다.
• API 엔드포인트, 체크리스트, 성과 지표처럼 틀리면 안 되는 항목은 벡터 계층에서 빼서 SQLite 테이블로 옮기고, 실제 SQL 질의까지 검증한다.
• 새 메모를 넣고 바로 회상해야 하는 운영이라면 sync.watch 또는 동등한 즉시 인덱싱 설정을 켜고, 저장 직후 회수 성공 여부를 반복 확인한다.
• 오래된 일일 로그가 작업기억을 오염시키지 않도록 lock 파일 기반 정리 스크립트와 야간 스케줄을 붙여 1단계 계층을 가볍게 유지한다.

❓ 열린 질문

• 장기 회상 성공률을 높이는 것보다 더 중요한 운영 KPI는 무엇일까요? 예를 들어 “정답형 데이터에서 추측성 응답 0건” 같은 지표를 어떻게 측정할지 설계가 필요해 보입니다.
• sync.watch는 실시간성에는 유리하지만, 대규모 Vault에서 디스크 I/O와 인덱싱 부하를 얼마나 키울까요? 어느 시점부터는 배치 인덱싱이 더 유리할 수도 있습니다.
• 민감 정보 저장을 1단계/2단계 계층에 허용할지, 아니면 처음부터 암호화된 3단계 저장소로 강제 이동시킬지에 대한 보안 경계는 어떻게 정해야 할까요?
• 팀 단위 운영에서는 Obsidian 기반 작업기억이 큰 장점이 될 수 있지만, 동시에 문서 편집 규율이 무너지면 오히려 기억 오염원이 될 수 있습니다. 어떤 거버넌스 규칙이 함께 붙어야 할까요?