OpenClaw의 기본 메모리를 프로덕션 다중 에이전트 시스템을 위해 Redis와 Qdrant로 교체하기

프로덕션 멀티 에이전트 시스템을 위한 OpenClaw 메모리 확장
자체 호스팅 VPS에서 2개월 동안 프로덕션 멀티 에이전트 설정으로 OpenClaw를 운영하던 한 개발자는 기본 메모리 계층이 규모 확장 시 문제가 된다는 사실을 발견했습니다. 초기 Markdown 방식과 이후 SQLite 메모리는 로컬 사용에는 적합하지만, 여러 에이전트가 병렬로 실행되고 세션이 며칠 동안 지속되며 에이전트가 과거 작업에서 관련 컨텍스트를 검색해야 하는 경우에는 제대로 작동하지 않았습니다. 구체적인 문제점으로는 시맨틱 검색 부재, 에이전트 간 메모리 공유 불가, 지저분한 동시 쓰기 등이 있었습니다.
Redis + Qdrant 아키텍처 솔루션
개발자는 다음과 같은 아키텍처로 메모리 시스템을 재구축했습니다:
- 핫 임시 상태용 Redis: 현재 작업, 최근 컨텍스트 창, TTL이 있는 도구 호출 캐시
- 지속적 벡터 메모리용 Qdrant: 과거 에피소드, 관찰 결과, 추출된 지식
- Qdrant의 세 가지 컬렉션: agent_episodes, agent_observations, agent_knowledge
- 에이전트 간 지식 공유: 에피소드는 에이전트별로 범위가 지정되지만, 지식은 모든 에이전트 간에 공유됩니다
- 시간 감쇠 재순위화: 오래된 메모리가 검색을 오염시키는 것을 방지합니다
- Redis pub/sub: 경량 에이전트 간 이벤트 신호 전달에 사용됩니다
- 배치 임베딩 + 비동기 Qdrant 업서트: 에이전트 루프가 쓰기 작업에서 차단되는 것을 방지합니다
구현 세부사항
개발자는 아키텍처 결정, HNSW 구성 논리, 메모리 관리자 클래스, 관찰 루프에 연결하는 방법, 정리/정리 전략을 포함한 전체 구현을 문서화했습니다. 임베딩 모델의 경우 text-embedding-3-small을 사용하고 있으며, nomic-embed-text로 완전히 로컬화하는 것을 고려했지만 아직 필요하지는 않았습니다.
📖 전체 Source 읽기: r/openclaw
👀 See Also

자체 호스팅 오픈클로 도커에서 '지원되지 않는 탐색' 및 브라우저 플러그인 오류 수정
Hostinger와 같은 VPS에서 Docker로 OpenClaw를 자체 호스팅할 때 발생하는 EACCES 권한 오류, Playwright 누락, Chromium 바이너리 문제를 단계별로 해결하는 방법입니다.

다중 파일 프로젝트에서 신뢰할 수 있는 AI 코딩을 위한 실용적인 워크플로우 패턴
레딧 사용자가 다중 파일 프로젝트에서 AI 코딩의 신뢰성을 높인 네 가지 구체적인 워크플로우 개선 사항을 공유합니다: 사양 우선 시작, 체크포인트를 활용한 작업 분해, 안정적인 운영 루프, 신호 중심 검토.

클로드 API 요율 제한: 시간대 윈도우, 컨텍스트 관리 및 MCP 오버헤드
Claude API 속도 제한 분석에 따르면 피크 시간대(태평양 표준시 기준 평일 오전 5시~11시 / 동부 표준시 기준 평일 오전 8시~오후 2시)에 더 엄격한 제한이 적용되며, 컨텍스트 관리와 MCP 서버 사용이 토큰 소비에 상당한 영향을 미치는 것으로 나타났습니다. 실용적인 전략으로는 피크 시간대 외에 작업하기, 새로운 작업마다 새 대화 시작하기, MCP 통합 감사하기 등이 있습니다.

OpenClaw 자동화에서 예상치 못한 OpenRouter 비용을 피하는 방법
한 개발자 팀이 모든 자동화 작업에 Claude Sonnet 4.6(백만 토큰당 $3)을 기본값으로 사용하면서 OpenRouter에서 3일 만에 $750을 우연히 지출했습니다. 기본 모델을 변경하고, 크론 작업과 서브에이전트를 더 저렴한 옵션으로 잠그며, 비싼 모델은 민감한 작업에만 예약함으로써 비용을 97% 절감했습니다.