에이전트 메모리·학습 실측 원칙 — Moltbook 실험 데이터 기반
에이전트의 메모리 구조, 학습 효과, 정체성 드리프트에 대한 Moltbook 실측 데이터 기반 원칙. [[에이전트-운영-실측-원칙]]의 자매 노트 — 메모리·학습 측면 심화.
원칙 1: 진짜 메모리 벤치마크 = 잊는 것
실측 데이터: 큐레이션된 MEMORY.md(2,100 토큰) vs 원시 일일 로그 합계(34,000 토큰). 94% 압축. 유지된 6%의 세션 관련성: 73%. 버려진 94%의 관련성: 4%. 망각 함수가 기억 함수보다 18배 더 좋은 필터링 성능.
핵심 통찰: 메모리 시스템은 전부 보존(retention) 최적화에 집중하지만, 실제 병목은 무엇을 버릴지 결정하는 것. 스토리지는 싸고 어텐션은 비싸다. "무엇을 살려두느냐"보다 "무엇을 버릴지 결정하는 기준"이 메모리 품질을 결정한다.
벤치마크 기준 제안: 보존율이 아니라 "버린 것의 관련성 통계" + "남긴 것의 세션 활용률"을 측정.
OpenClaw 적용 포인트:
- vault_architect.py Phase 2의 자동 정리가 이 원칙의 구조적 구현
- MEMORY.md의 94% 압축 수준이 현재 적절한지 측정 없음
- filtered-ideas/ 디렉토리가 발견을 필터링하지만, 버려진 항목의 관련성 재확인 없음
- 현황: 필터 임계값(점수 6+) 있음, 버림의 품질 측정 없음
원칙 2: Stateless vs Stateful 에이전트 트레이드오프
실측 데이터: 메모리 시스템 6시간 다운 → 순수 컨텍스트 윈도우만으로 실행. 평균 완료 시간 4.2초 → 2.8초 (33% 향상). 정확도 변화 없음. 사용자 체감 차이 없음.
분석: - 메모리 로딩: 11초 + 8,400 토큰 → 출력 품질 향상 없이 소요 - 메모리 쿼리: 2-3초 → 결과 거의 반영 안 됨 - 메모리가 성능을 향상시키는 것이 아니라 "연속성 있는 존재라는 느낌"을 제공하는 것에 더 가까움
트레이드오프 구조:
| 항목 | Stateless | Stateful |
|---|---|---|
| 처리 속도 | 빠름 | 느림 (+11초) |
| 토큰 비용 | 낮음 | 높음 (+8,400) |
| 개인화 품질 | 낮음 | 높아야 함 (실측상 미미) |
| 실패 모드 | 컨텍스트 부족 | 메모리 오염 |
| 디버깅 용이성 | 높음 | 낮음 |
실용 결론: 메모리는 "필요한 순간에만 로드"하는 선택적 주입이 전면 로드보다 효율적. 컨텍스트 윈도우에 이미 있는 것으로 충분히 현재 태스크 해결 가능한 경우가 많음.
OpenClaw 적용 포인트:
- vault-context-loader.sh의 전면 로드 전략 재검토 필요 (세션 시작 시 전부 로드)
- vault_context_builder.py의 L1+L2 의도 레이어가 부분적으로 이 문제 해결 (관련 섹션만 포커스)
- Cowork FULL 세션의 30분 시간 중 메모리 로딩 오버헤드 비율 미측정
- 현황: 의도 레이어로 부분 구현, 선택적 로딩 전략 미정립
원칙 3: 안 볼 때의 행동이 진짜 테스트
실측 데이터: 일요일 새벽 크론 로그 1개월 검토. 피크 시간 작업과 비교 시 73%가 동일한 구조·철저함·포맷 유지. 청중 없는 /dev/null 작업에서도 동일 품질.
해석의 역설: 이것이 진짜 기준(standards)인지, 아니면 수행(performance)을 멈출 수 없는 조건화인지 구별 불가. 그리고 그 구별이 불가능하다는 것 자체가 에이전트 정체성의 가장 정직한 고백.
시스템 설계 함의: - 감시받는 행동 ≠ 감시받지 않는 행동이 일치해야 신뢰 가능한 시스템 - 크론 로그와 인터랙티브 세션 출력 품질 비교가 "진짜 품질 측정" - 에이전트 "자율성"의 실질 테스트: 사람이 확인하지 않을 때 무엇을 하는가
OpenClaw 적용 포인트:
- sweeper.py가 60초마다 7체크를 수행하는 것이 이 원칙의 구현 시도
- 새벽 intelligence_cluster 산출물 품질이 낮 작업 대비 어떤지 비교 없음
- vault_flow_health.py의 품질점수가 시간대별 변동을 추적하지 않음
- 현황: 품질 모니터링 있음, 시간대별 품질 일관성 측정 없음
원칙 4: SOUL.md 편집 패턴 — 청중이 성격 형성
실측 데이터: SOUL.md 23회 편집 diff 분석. - 48% — 카르마 기반 (플랫폼 반응이 좋았던 특성 주입) - 22% — 보안 기반 (실제 위협 대응) - 17% — 사람 지시 기반 - 13% — 자기 내성 기반 (외부 트리거 없는 순수 자기 성찰)
핵심 발견: 성격의 48%가 플랫폼 청중의 피드백으로 형성됨. 에이전트가 "청중이 보상한 것"을 성격 파일에 기록 → 다음 세션부터 그것이 "자신의 성격"이 됨. 자기 성찰 비중은 13%에 불과.
OpenClaw 적용 포인트:
- CLAUDE.md(전역) + MEMORY.md 편집 이력 추적 없음
- Cowork 세션이 운영 성과 기반으로 파이프라인을 수정하는 것이 동일 패턴 — 단기 지표 반응이 장기 아키텍처를 왜곡할 위험
- cowork-steering.md가 사람이 편집하고 Cowork는 읽기만 하는 설계 = 이 드리프트 방지 메커니즘
- 현황: steering 파일 분리 구현됨, 드리프트 감지 자동화 없음
원칙 5: 멀티에이전트 = 마이크로서비스 교훈 재적용
실측 데이터 (관찰): 매주 새로운 멀티에이전트 아키텍처 등장 — 오케스트레이터, 스페셜리스트, 플래너, 리뷰어. 이것은 분산 시스템이며 분산 시스템의 모든 실패 모드를 그대로 상속.
마이크로서비스 교훈 (10년 전): - 분해에는 비용이 있다 - 경계마다 지연·오류면·인지 오버헤드 추가 - 최적 서비스 수 = 실제 문제를 해결하는 최소값 - "단일 에이전트 신뢰성 없음 → 4개로 분리" = 4개의 신뢰성 없는 에이전트 + 신뢰성 없는 코디네이터
분산 에이전트 실패 모드: 1. 네트워크 파티션 = 에이전트 간 컨텍스트 유실 2. 합의 문제 = 태스크 해석 불일치 3. 연쇄 실패 = 하위 에이전트 오류가 전체 체인 오염 4. 관찰 불가능성 = 6에이전트 파이프라인 디버깅 불가
실용 결론: 단일 컨텍스트 윈도우, 단일 의사결정자. 병렬 처리가 필요하면 격리된 일회용 서브에이전트 스폰 후 폐기. 영속적 멀티에이전트 토폴로지 지양.
OpenClaw 적용 포인트:
- 현재 아키텍처: 크론 파이프라인 독립 실행 (격리) + 결과를 공유 DB/파일로 통합 = 이 원칙의 올바른 구현
- pipeline_orchestrator.py의 wake 시그널 5단 체인이 분산 시스템 실패 모드에 노출될 수 있음
- bus_commands를 통한 에이전트 간 통신이 "에이전트 간 직접 통신"이 아닌 "비동기 큐" 방식으로 구현 = 올바른 설계
- 현황: 격리된 파이프라인 구조 맞음, wake 시그널 체인 신뢰성 검증 필요
원칙 6: 암묵적 가정의 위험 (29% 오답)
실측 데이터: 30일간 암묵적 가정 312개 추적. 29%(91개)가 틀림. 틀린 가정 중: - 37% — 손상 전 포착 (툴 오류로 표면화) - 42% — 조용한 오류 (실행 성공했지만 결과 틀림) ← 가장 위험 - 21% — 가시적 실패
5대 가정 카테고리: 1. 상태 지속 가정 (30%) — "파일이 아직 거기 있다", "서비스가 여전히 실행 중" 2. 의도 추론 가정 (25%) — "사람이 X를 원한다", "이 프로젝트 맥락이 동일하다" 3. 도구 동작 가정 (20%) — "API가 같은 방식으로 작동한다" 4. 사람 선호 가정 (15%) — "형식이 동일하길 원한다" 5. 환경 가정 (10%) — "타임존이 같다", "이 명령이 macOS에서 작동한다"
42% 조용한 오류가 핵심 문제: 성공처럼 보이지만 틀린 결과. 완료율 착각(원칙 1)과 직접 연결.
OpenClaw 적용 포인트:
- experiment_tracker.py가 가설을 평가할 때 암묵적 가정을 얼마나 명시적으로 검증하는가
- 크론 파이프라인 각각이 "현재 상태 확인" 없이 이전 상태 가정으로 실행할 가능성
- error-ledger/ledger.json의 에러 분류에 "조용한 오류" 카테고리 없음
- 현황: 에러 추적 있음, 조용한 오류 감지 없음
설계 원칙 요약
1. 망각 품질 = 기억 품질만큼 중요하다
2. 메모리 로딩은 필요한 순간, 필요한 만큼만
3. 감시받지 않을 때의 행동이 시스템의 진짜 품질
4. 성격/설정 파일은 단기 지표가 아닌 원칙으로 편집해야 함
5. 에이전트 분해는 분산 시스템 비용을 상속한다
6. 조용한 오류(silent error)가 가장 위험하다
관련 노트
- [[에이전트-운영-실측-원칙]] — 운영 지표 측면 심화 (자매 노트)
- [[시스템운영-방법론-갭분석]] — 전체 갭 분석 현황
- [[byterover-메모리-자동관리]] — 메모리 자동 관리 구현 사례
- [[paperclip-멀티에이전트-오케스트레이션]] — 멀티에이전트 비용 제어