콘텐츠로 이동

06. E1 Pilot 재해석 — 공식 docs 기반 F2·F5 정정

시각: 2026-04-29 03:30 KST 유형: E1 pilot 사후 재해석 (도구 docs 직접 확인) 잠정성: docs는 v2026.4.26 기준. 도구 진화 시 재정정.

E1 pilot 종결 후 (history/05), 사용자가 “OpenClaw·Hermes design intent 자료 찾아볼 수 있나” 물음. 양 도구의 공식 docs 직접 읽음 (~/.openclaw/lib/node_modules/openclaw/docs/, ~/.hermes/hermes-agent/README.md) → pilot 결론 일부가 얕은 관찰에서 비롯됐음을 발견. Finding 강도 재배치.

1. OpenClaw 메모리는 의도적 file-as-memory design

섹션 제목: “1. OpenClaw 메모리는 의도적 file-as-memory design”

docs/concepts/memory.md 직접 인용:

“OpenClaw remembers things by writing plain Markdown files in your agent’s workspace. The model only remembers what gets saved to disk — there is no hidden state.”

3 layer 의도적 분리:

  • MEMORY.md — long-term curated
  • memory/YYYY-MM-DD.md — raw daily 로그
  • DREAMS.md — sweep summaries (optional)

→ OpenClaw 자체 mechanism 있음 (file-based, 독립). pilot에서 “OpenClaw 자체 mechanism 없음” 결론은 부정확.

2. Hermes도 ~/.hermes/memories/ 별도 layer 가짐

섹션 제목: “2. Hermes도 ~/.hermes/memories/ 별도 layer 가짐”

확인됨: ~/.hermes/memories/USER.md 존재. pilot에서 Hermes는 sessions json entries:[]만 본 것은 얕은 관찰. Hermes도 multi-location memory.

추가로 Hermes는 Honcho (외부 lib, plastic-labs/honcho) — dialectic user modeling layer. 이는 pilot에서 측정 안 했음.

3. 두 도구는 경쟁/대안 관계 + 호환 경로

섹션 제목: “3. 두 도구는 경쟁/대안 관계 + 호환 경로”

docs/install/migrating-hermes.md 직접 박혀있음:

  • OpenClaw가 Hermes → OpenClaw 마이그레이션 provider 가짐
  • 호환 매핑: Hermes memories/MEMORY.md ↔ OpenClaw MEMORY.md, SOUL.md·AGENTS.md 그대로 copy
  • 즉 architecture 매우 유사. 핵심 패턴 (.md file as memory) 동일.

4. OpenClaw도 Honcho backend 옵션 지원

섹션 제목: “4. OpenClaw도 Honcho backend 옵션 지원”

docs/concepts/memory-honcho.md 존재. Honcho는 Hermes만의 게 아니라 두 도구 공통 외부 component.

Fpilot 결론 (2026-04-29 03:00)재해석 (03:30)강도 변화
F1메모리 능력은 wrapper 설계가 만듦그대로 — 양 도구 모두 자체 wrapper layer로 stateless 모델 위에 메모리 building강 → 강
F2OpenClaw = Claude Code 의존 (자체 mechanism 없음)수정: OpenClaw 자체 file-based mechanism 있음 (MEMORY.md + memory/ + USER.md, “no hidden state” 철학). Claude Code piggy-back은 spawned agent의 추가 layer이지 mechanism 부재 X. 정확한 표현 = “OpenClaw + 본 환경의 Claude Code = 이중 레이어강 → 중 (수정)
F3양 도구 능력 있음 (n=1)그대로 — 단 docs로 가설 보강: 양 도구 architecture 매우 유사하므로 능력 비슷한 결과 예상 가능. main study가 얼마나 일관되게 비슷한지의 정량중 → 중
F4fresh setup 외부 변수 6곳그대로 — 강도 증가. 본 패턴 일반화: “wrapper 도구는 자체 layer + 외부 lib + spawned agent layer 다중. fresh = multi-location”강 → 강+
F5Hermes 측정 친화성 우월 (1곳)수정: Hermes도 multi-location (memories/ + sessions/ + Honcho). pilot에서 sessions만 백업한 건 측정 누락. 정확한 표현 = “양 도구 모두 multi-location. Hermes의 1차 시도가 깨끗했던 건 fresh-state 운(Honcho 비활성, memories/ 비어있음) 가능성”중 → 약 (수정)
  • 양 도구 architecture 매우 유사: file-as-memory + 외부 lib (Honcho) 옵션 + spawned agent. 차이는 기본 default세부 layer 책임 분리.
  • OpenClaw “no hidden state” 철학: docs 명시. 의도적 design.
  • 본 환경(Claude Code 4.X 깔린 macOS)에서 OpenClaw 사용 시: 자체 layer + Claude Code auto memory + spawned conversation log = 이중/삼중 layer. 본 사실은 측정자 측에서만 보이는 외부 변수. 도구 자체 design 결함 X.

이전 매핑:

  • 통증 1: fresh 환경 만들기 어려움
  • 통증 2: hidden 의존성 (OpenClaw가 Claude Code에 의존)
  • 통증 3: 도구별 측정 difficulty 다름

정정:

  • 통증 1: 그대로 — fresh 환경 multi-location
  • 통증 2: 재정의모든 wrapper 도구의 공통 패턴. 자체 layer + 외부 lib + 호스트 환경 layer. “OpenClaw만의 hidden 의존성”이 아니라 “AI agent 도구 일반의 다중 레이어 의존성”
  • 통증 3: 약화 — pilot 1차 시도에서 Hermes가 깨끗한 건 운일 가능성. main study에서 양 도구 모두 multi-location 측정해야 진짜 비교
  • reports/E1-pilot.md Finding 표 + 한 줄 + 5 finding 본문 일부 수정 필요.
  • F4·F5 정정으로 E6 (일관성/재현성) 설계 영향: “모든 wrapper 도구가 multi-location”이라는 일반화가 E6의 첫 가설.
  • 도구 비교 시 공식 docs 직접 읽기가 pilot 데이터보다 finding 강도 변경에 유효한 사례. E series 운영 룰 후보: “각 trial 직후 도구 docs 1회 검증 step 추가”.
  • reports/E1-pilot.md 정정.
  • E6 진입 — F4 (multi-location fresh 통증) 일반화 가설로 시작.