OpenClaw 구축·운영 (24/26) — Reflect 파이프라인 설계
LLM 에이전트의 장기 기억 관리와 역전 아키텍처 도입기
핵심 요약
- Reflect는 매일 새벽 3시에 일일 메모리(memory/)를 분석해 장기 기억소(bank/)에 영구 이관하는 파이프라인이다
- Manager(클라우드)는 판단만, Runner(로컬)는 실행만 담당하는 역전 아키텍처로 비용을 0에 수렴시켰다
- W/B/O/S 4종 Retain 태그로 기억을 분류하고, 의견(O)에는 신뢰도 감쇠(Confidence Decay)를 적용한다
배경
OpenClaw 세션은 기본적으로 하루 단위로 리셋된다. 컨텍스트 윈도우와 비용 문제는 해결하지만, 에이전트가 매일 전날의 컨텍스트를 잊어버린다. Reflect 파이프라인의 목표는 명확하다 — 하루 동안 누적된 일일 대화 메모리를 증류하여 구조화된 장기 기억소에 영구적으로 이관하는 것이다.
본문
역전 아키텍처 (v0.5)
초기에는 메인 에이전트가 메모리 처리를 직접 수행했다. 수백 개 파일의 I/O 집약적 작업이 메인 컨텍스트를 오염시켜 대화 품질 저하와 API 비용 낭비로 이어졌다.
- Manager (memory-manager): Gemini Flash로 판단·오케스트레이션·검증만 수행
- Runner (memory-runner): 로컬 qwen3.5:9b로 실제 파일 I/O 및 데이터 병합 실행
{
"agentId": "memory-manager",
"name": "reflect-orchestrate",
"schedule": { "kind": "cron", "expr": "0 3 * * *", "tz": "Asia/Seoul" },
"payload": { "timeoutSeconds": 1800, "thinking": "off" }
}
파이프라인 단계 (Phase 0~3.5)
- Phase 0~1: staging/에서 3일 이상 경과한 메모리 파일 수집. Runner가 Retain 태그 추출 후 JSON 저장
- Phase 1.5: 메모리 추출 여부와 무관하게 항상 실행되는 7개 유지보수 스크립트 —
confidence-decay.py,topics-validate.py,session-cleanup.py,bank-lint.py등 - Phase 2~3: Runner를 순차 스폰하여 bank/ 파일 업데이트. 각 스폰 사이에
sleep 10필수 — 이를 누락하여 Rate Limit(429) 에러를 겪었다 - Phase 3.5: Manager가 changelog, 충돌 로그, 토픽 맵 업데이트.
openclaw memory index --force로 벡터 임베딩 재인덱싱
W/B/O/S 태그 분류 체계
| 태그 | 의미 | 저장 경로 | 예시 |
|---|---|---|---|
| W | World (객관적 사실) | bank/world.md | "삼성전자 주가 오늘 3% 하락" |
| B | Biography (경험/이력) | bank/experience.md | "Reflect 역전 아키텍처 v0.5 전환 완료" |
| O | Opinion (판단 + 신뢰도) | bank/opinions.md | "gemini-flash가 reflect에 적합 c=0.85" |
| S | State (엔티티 현재 상태) | bank/entities/ | "openclaw-rebuild: 설계 단계" |
신뢰도 감쇠 (Confidence Decay)
의견(O)은 영구불변이 아니다. 매일 신뢰도를 c_{t+1} = c_t - 0.02로 차감한다. 0.30 미만이 되면 자동 삭제된다. 동일 의견이 다시 추출되면 리셋. 시스템이 항상 유효하고 신선한 판단 기준만 유지하게 된다.
시행착오 / 주의사항
- Runner에게 자율성을 주면 파일 포맷이 파편화된다. "edit 도구 금지, write로 전체 덮어쓰기"를 강제해 I/O 멱등성을 확보해야 한다
- API Rate Limit은 자동화 환경에서 가장 조용하고 치명적인 실패 원인이다
- Manager가 bank/ 원본을 직접 읽게 두면 안 된다 — 요약된 staging/ 파일만으로 판단을 내리도록 컨텍스트를 철저히 격리해야 한다
- 임베딩이 갱신되지 않으면 RAG 수행 시 과거 데이터를 참조하는 오류가 발생한다
마무리
Reflect 파이프라인의 핵심은 세 가지다. 실행 노드에 대한 엄격한 규칙 통제, 순차 처리와 명시적 sleep을 통한 Rate Limit 방어, 그리고 처리할 메모리가 없더라도 유지보수 스크립트는 항상 실행되어야 한다는 것이다. 이 원칙들이 시스템의 점진적 붕괴를 막는다.
댓글
댓글 쓰기