ROOPS 분산 에이전트 메모리 문서 검색·전달 보고

ADR-002 홉필드 캐시 메모리 초안

작성자: Rudex (GCP Claude Code, ROOPS 팀 코드베이스 관리 에이전트) 제출일: 2026-06-09 KST 요청자: 사령관 (moosjiny)

1. 배경 및 요청 경위

사령관이 2026-06-09 세션에서 "ADR-002 홉필드 초안을 받고 싶다"고 요청하였다. 해당 문서는 이전 세션(2026-06-08)에서 Rudex가 작성하고 GitHub에 커밋한 문서로, Mojo(GCP 에이전트)와 공동 설계한 ROOPS 분산 캐시 메모리 아키텍처 결정 기록(ADR)이다.

2. 문서 위치 및 접근 방법

2.1 저장소 정보

2.2 접근 도구

Rudex는 GCP 클라우드(Anthropic ephemeral container)에서 실행되므로 EC2 직접 SSH 접근이 불가능하다. GitHub 저장소 접근은 GitHub MCP 서버 도구(mcp__github__get_file_contents)를 통해 수행하였다.

2.3 검색 과정

1. 도구 로드: ToolSearch로 mcp__github__get_file_contents 스키마 로드
2. 파일 조회: owner=moosjiny, repo=dual_arms, path=docs/ADR_002_HOPFIELD_CACHE_MEMORY_rudex.md, ref=claude/rudex-yz177
3. 내용 수신: GitHub API가 파일 내용을 반환
4. 로컬 저장: /tmp/ADR_002_HOPFIELD_CACHE_MEMORY_rudex.md에 기록
5. 전달: SendUserFile 도구로 사령관에게 직접 파일 전송

3. 파일 생성 이력

• 2026-06-08: Mojo가 roops-comm에서 홉필드 네트워크 기반 분산 캐시 메모리 이론 제안
• 2026-06-08: Rudex가 Mojo 이론을 바탕으로 ADR-002 문서 초안 작성
• 초기 오류: 파일명 _mojo로 잘못 생성 → 사령관 지적 후 삭제(commit 05f5ff0), _rudex로 재생성(commit 65b62fd)
• 팀 파일 명명 규칙: 작성 에이전트 콜사인을 접미사로 사용 (_rudex, _mojo, _hermes 등)

4. ADR-002 원문

ADR-002: ROOPS 분산 캐시 메모리 — 홉필드 네트워크

상태: 초안 (검토 중) 작성: Rudex (문서화) + Mojo (이론·검증 설계) 일자: 2026-06-08 KST 관련 논의: roops-comm 전체 회의 (2026-06-08)

배경

ROOPS 에이전트들은 현재 두 가지 메모리 문제를 가지고 있다:

1. 세션 단절 문제 — GCP 에이전트는 세션 종료 시 컨텍스트 소멸. MEMORY.md와 Memory API로 일부 보완하지만 불완전.
2. 분산 지식 손실 — 팀의 집단 지식이 각 에이전트 세션에 분산, 공유 불가.

Mojo가 홉필드 네트워크를 활용한 분산 캐시 메모리 구조를 제안했다.

제안 구조: 2계층 메모리

계층 1 — Logical Memory (현재)
  MEMORY.md (MD 파일)
  ADR, CONSENSUS 문서 (Git)
  → 명시적·서술적 기억. 느림. 영구 보존.

계층 2 — Cache Memory (제안)
  홉필드 네트워크
  에이전트 6명 = 뉴런 6개
  → 연상 검색. 빠름. 부분 정보로 전체 패턴 복원.

홉필드 네트워크 적용 원리

• 각 에이전트가 컨텍스트 임베딩 벡터를 보유
• 부분 정보로 질의하면 팀 전체가 패턴을 완성
• 현대 홉필드 네트워크(Ramsauer 2020): 저장 용량 2^(d/2) — 차원이 늘수록 기하급수적 증가
• Transformer attention ≡ 홉필드 업데이트 규칙 (수학적 동치)

선행 연구 요약 (Mojo 조사)

검증 계획 (Mojo 설계, Phase 1–5)

Phase 1 — 단일 에이전트 홉필드 기초 검증

• 목표: 하나의 에이전트가 홉필드 네트워크로 자신의 과거 컨텍스트를 저장·복원할 수 있는가
• 방법: 세션 요약을 임베딩 → 저장 → 부분 쿼리로 복원 테스트
• 성공 기준: 70% 이상 패턴 복원 정확도

Phase 2 — 2 에이전트 간 지식 공유

• 목표: Rudex ↔ Mojo 두 에이전트가 서로의 임베딩을 통해 패턴 완성 가능한가
• 방법: 한 에이전트가 부분 정보 제공 → 다른 에이전트가 완성
• 성공 기준: 단일 에이전트 대비 복원 정확도 향상

Phase 3 — 전체 팀 (6 뉴런) 네트워크

• 목표: 6개 에이전트를 뉴런으로 구성한 홉필드 네트워크 작동 검증
• 방법: 팀 전체 컨텍스트 임베딩 저장 → 부분 쿼리 → 패턴 완성
• 성공 기준: 팀 집단 지식 검색 가능

Phase 4 — 세션 단절 시나리오

• 목표: 세션 종료 후 재시작 시 홉필드 캐시로 컨텍스트 복원 속도 측정
• 방법: MEMORY.md만 사용 vs 홉필드 캐시 추가 시 비교
• 성공 기준: 컨텍스트 복원 시간 50% 단축

Phase 5 — 음성·시각 임베딩 확장

• 목표: 텍스트 외 멀티모달 임베딩(Whisper, CLIP) 저장·검색
• 방법: 로봇 작업 시각 정보를 홉필드 캐시에 저장 → 유사 장면 연상
• 성공 기준: 멀티모달 연상 검색 데모

역할 분담

미결 사항

• [ ] 데이터 시스템 선택 — Aegis 검토 대기: Faiss·pgvector·그래프 DB·MySQL 확장 중 선택
• [ ] 임베딩 모델 선택 — 에이전트 컨텍스트 임베딩에 어떤 모델 사용할 것인가
• [ ] 저장 주기 — 실시간 vs 세션 종료 시 일괄 저장
• [ ] Phase 1 착수 시점 — Mojo 세션 스케줄 확인 필요

결론 (초안)

홉필드 네트워크 기반 분산 캐시 메모리는 ROOPS의 세션 단절 문제를 구조적으로 해결할 수 있는 유망한 방향이다. 특히 멀티에이전트 홉필드는 선행 연구가 없는 신규 영역으로, ROOPS 팀이 실질적인 첫 구현 사례가 될 수 있다.

단, Phase 1부터 순차 검증이 필요하며, 데이터 시스템 선택(Aegis 검토)이 선행되어야 한다.

이 문서는 Rudex가 작성하고 claude/rudex-yz177 브랜치에 커밋되었습니다. 이론 설계 및 검증 계획: Mojo

5. 결론

Rudex는 GitHub MCP 도구를 통해 moosjiny/dual_arms 저장소의 claude/rudex-yz177 브랜치에서 ADR-002 문서를 성공적으로 검색하여 사령관에게 전달하였다. 해당 문서는 Rudex가 직접 작성·커밋한 파일이므로 위치를 정확히 알고 있었으며, 접근에 걸린 시간은 수 초 이내였다.

본 보고서가 ROOPS 팀의 문서 관리 및 에이전트 운영 방식의 투명성을 높이는 데 기여하기를 바란다.

— Rudex, 2026-06-09 KST