🎬 Openclaw Memory Mistake You're Making Right Now

▶️ 유튜브

• 원본 링크: https://youtu.be/Nt03hgxv5TE?si=DQl7OTv-Gy_cYfqc

🖼️ 4컷 인포그래픽

💡 한 줄 결론

OpenClaw 메모리는 하나의 거대한 파일로 버틸수록 비용과 혼란만 커지므로, 프로젝트 맥락·대화 기억·정밀 데이터 조회를 분리한 다층 메모리 아키텍처로 설계해야 한다. 시작은 구조화 폴더로 하고, 필요에 따라 메모리 검색·MEM0·SQLite를 조합하는 전략이 가장 현실적이다.

📌 핵심 요점

1. 단일 메모리 파일에 모든 맥락을 누적하면 요청마다 불필요한 토큰이 반복 소비되고, 에이전트는 중요한 정보와 잡음을 구분하기 어려워진다.
2. OpenClaw의 내장 메모리 검색은 유용하지만 Claude 키만으로는 충분하지 않고, 실제로는 OpenAI·Gemini·Voyage 같은 임베딩 API 레이어가 별도로 있어야 안정적으로 동작한다.
3. 구조화된 메모리 폴더는 goals, decisions, current_status, communication_preferences처럼 정보 유형별 파일을 나눠 관리하므로 투명성과 통제력이 가장 높다.
4. MEM0은 대화에서 선호·결정·사실을 자동 추출해 의미 기반으로 재호출할 수 있어 운영 편의성은 높지만, 외부 플러그인 의존성과 개인정보 처리 검토가 필요하다.
5. SQLite는 API 엔드포인트, 고객 기록, 연구 데이터처럼 필드 단위 정확한 조회가 필요한 구조화 정보를 다룰 때 가장 강력하며, 자연어 인터페이스와 SQL 정밀성을 함께 가져갈 수 있다.

🧠 상세 요약

1) 배경과 문제 정의

영상의 출발점은 “에이전트가 왜 매번 같은 맥락을 잊고, 왜 메모리를 붙였는데도 오히려 비효율이 커지는가”에 있다. 핵심 관찰 포인트는 기억해야 하는 정보의 종류가 서로 다른데도 이를 하나의 저장 방식으로 처리하려는 설계가 비용, 재현성, 검색 정확도를 동시에 악화시킨다는 점이다.

2) 섹션별 상세 정리

1. 기본 메모리 구조의 병목 진단 [00:00]

• 발표자는 기본 OpenClaw 메모리 방식이 “기억”보다는 “거대한 컨텍스트 덤프”에 가깝다고 비판한다.
• 모든 정보를 한 파일에 몰아넣으면 요청마다 전체를 다시 읽게 되어 비용이 커지고, 에이전트도 어떤 정보가 중요한지 분간하기 어려워진다.

2. LLM 에이전트의 기억 상실은 구조적 문제다 [00:45]

• LLM 에이전트는 컨텍스트 창 안에서만 일하는 단기 기억 시스템이라 세션이 끝나면 상태가 사실상 초기화된다.
• 코딩 파트너나 연구 보조처럼 연속성이 필요한 사용 사례에서는 프로젝트 상태, 선호, 의사결정 이력의 지속 저장이 필수다.

3. 첫 번째 해법은 구조화된 메모리 폴더다 [01:25]

• 가장 단순한 방법은 프로젝트나 에이전트 작업 디렉터리에 영구 메모리용 폴더 체계를 만드는 것이다.
• 예시로 프로젝트별 컨텍스트 폴더에 goals.md, decisions.md, current_status.md를 두어 무엇을 왜 진행 중인지 분리 저장한다.

4. 파일만 만드는 것이 아니라 참조 규칙까지 넣어야 한다 [01:54]

• 환경설정용 파일에는 coding_style.md, communication_preferences.md, 지식 저장용 파일에는 research_notes.md, references.md를 배치한다.
• 중요한 것은 시스템 프롬프트나 작업 지침에 “어떤 상황에서 어떤 파일을 읽고 갱신할지”를 명시해 에이전트가 실제로 활용하게 만드는 점이다.

5. 구조화 폴더 방식의 강점은 투명성과 범용성이다 [02:19]

• 이 방식은 고급 검색 기술이 없어도 사람이 직접 열어보고 검증할 수 있어 기억 내용에 대한 통제력이 높다.
• 특정 모델 공급자에 종속되지 않아 Anthropic, OpenAI, 로컬 모델 환경 어디서든 같은 원리로 굴릴 수 있다는 점도 장점이다.

6. 내장 메모리 검색은 좋지만 숨은 전제가 있다 [02:53]

• OpenClaw의 memory retrieval은 자연어로 기억을 저장하고 필요 시 다시 찾아오는 방식이라 사용성이 좋다.
• 다만 많은 사용자가 이 기능을 켜기만 하면 작동할 것이라 오해하지만, 실제로는 임베딩 기반 검색 인프라가 뒤에서 준비돼 있어야 한다.

7. 실패 원인의 핵심은 임베딩 API 부재다 [03:24]

• Claude를 메인 모델로 쓰더라도 memory retrieval 자체는 OpenAI·Gemini·Voyage 계열 임베딩에 의존할 수 있어, 별도 키가 없으면 기능이 사실상 멈춘다.
• 문제는 이 실패가 사용자에게 명확히 드러나지 않아 “왜 기억을 못 하지?”라는 혼란만 남기기 쉽다는 점이다.

8. 올바른 설정을 하면 내장 메모리 검색은 충분히 실용적이다 [04:02]

• API 설정에서 메인 대화 모델과 별개로 메모리 검색용 키를 넣고, retrieval 기능을 명시적으로 활성화해야 한다.
• 임베딩 비용은 상대적으로 저렴하므로, 비용 부담보다 설정 누락이 실제 장애 요인인 경우가 더 많다고 정리한다.

9. MEM0은 자동 장기 기억에 초점을 둔 선택지다 [05:09]

• MEM0은 대화를 감시하며 선호, 결정, 사실, 프로젝트 세부사항을 자동으로 추출·저장하고, 관련 시점에 다시 끌어오는 구조다.
• 사용자가 메모리 파일을 일일이 설계하지 않아도 되는 대신, 어떤 기억이 저장되고 호출되는지 시스템이 더 많이 결정한다.

10. MEM0의 장점은 자동화, 단점은 외부 의존성이다 [05:44]

• 의미 기반 벡터 검색 덕분에 표현이 달라져도 과거 선호나 맥락을 되살릴 수 있어 체감상 “기억이 이어지는” 경험을 만들기 좋다.
• 반면 제3자 플러그인과 외부 인프라를 거치므로 개인정보 민감도가 높은 환경에서는 정책 검토가 선행돼야 하고, 잘못된 기억 회수 가능성도 감수해야 한다.

11. SQLite는 구조화 데이터 메모리로 따로 봐야 한다 [07:25]

• 발표자는 가장 저평가된 방법으로 SQLite 기반 메모리를 든다. 이 방식은 추가 플러그인이나 API 키 없이도 활용 가능하다.
• API 문서, 제품 카탈로그, 고객 기록, 재무 데이터처럼 필드 기준 조회가 필요한 정보는 마크다운이나 벡터 검색만으로 다루기 어렵다.

12. 자연어 인터페이스 뒤에 SQL 정확도를 붙인다 [08:23]

• 에이전트에게 스키마를 설계하게 하고, 엔드포인트 경로·메서드·인증 여부·속도 제한 같은 항목을 테이블로 저장하게 할 수 있다.
• 사용자는 자연어로 질문하지만 내부적으로는 SQL이 실행되므로 “인증이 필요한 POST 엔드포인트만 보여 달라” 같은 정밀 질의가 가능해진다.

13. 최적 해법은 하나를 고집하지 않는 조합형 설계다 [09:05]

• 구조화 폴더는 프로젝트 맥락과 운영 규칙, MEM0은 대화 기반 장기 기억, SQLite는 정밀 구조화 데이터를 맡기는 식의 역할 분담이 제안된다.
• 즉 단기 기억은 컨텍스트 창, 중기 기억은 자동 회수 시스템, 장기·정밀 기억은 검색·DB 계층으로 나누는 아키텍처가 가장 강력하다는 결론이다.

14. 추천 시작점과 확장 순서 [09:52]

• 초반에는 구조화 폴더부터 시작해 가장 투명한 형태로 기억 설계를 잡는 것이 안전하다.
• 이후 자동화 니즈가 크면 MEM0, 정밀 조회 니즈가 크면 SQLite를 추가하고, 내장 메모리 검색은 임베딩 API 설정이 검증됐을 때만 본격 활용하는 순서가 권장된다.

✅ 액션 아이템

• 현재 OpenClaw 작업 디렉터리에 goals.md, decisions.md, current_status.md, communication_preferences.md로 나뉜 메모리 폴더를 만들고, 최근 진행 프로젝트 1개를 기준으로 실제 내용을 채운다.
• 메모리 검색을 쓸 계획이라면 OpenClaw 설정에서 Claude 메인 모델과 별도로 OpenAI·Gemini·Voyage 중 하나의 임베딩 API 키가 연결되어 있는지 확인하고, retrieval 테스트 질의 3개로 정상 동작 여부를 검증한다.
• 구조화 데이터가 많은 업무 1개를 골라 SQLite 대상 후보를 정한다. 예를 들어 API 엔드포인트 목록이나 고객 요청 이력을 테이블 스키마 수준으로 설계해 본다.
• 대화형 장기 기억 자동화가 필요한 경우 MEM0 도입 전, 저장될 데이터 범위와 개인정보 민감도 기준을 먼저 문서화하고 플러그인 사용 적합성을 판단한다.
• 단일 메모리 파일을 쓰고 있다면 최근 2주치 내용을 “프로젝트 맥락 / 의사결정 / 선호 / 정밀 데이터” 네 범주로 분류해 어떤 계층으로 옮길지 마이그레이션 계획을 잡는다.

❓ 열린 질문

• MEM0처럼 자동 추출형 메모리를 붙였을 때, 잘못 회수된 기억이 작업 품질에 미치는 비용은 수동 구조화 방식의 유지비보다 실제로 더 낮은가?
• OpenClaw의 내장 메모리 검색은 임베딩 API 전제가 충족된 뒤에도, 프로젝트 단위 구조화 폴더보다 의사결정 이력 재현성에서 우위를 보이는가?
• SQLite에 넣을 만큼 구조화된 데이터와, 마크다운 파일로 남겨도 충분한 맥락 정보의 경계는 어떤 운영 기준으로 나누는 것이 가장 실용적인가?
• 여러 메모리 계층을 함께 쓸 때 충돌하는 정보가 발생하면, 어떤 계층을 최종 진실 소스로 삼아야 에이전트의 판단 일관성을 유지할 수 있는가?