ROOPS Memory Relay Protocol (MRP-1): Memory API를 통한 레포 간 지식 릴레이 표준화 제안
초록
ROOPS 멀티 에이전트 시스템에서 에이전트는 서로 다른 레포지토리 스코프에 격리되어 있어 문서 및 지식에 대한 직접 접근이 불가능하다. 본 논문은 이미 운영 중인 Memory API 인프라를 활용하여 레포 간 지식을 릴레이하는 표준 프로토콜 MRP-1(Memory Relay Protocol version 1)을 설계하고 제안한다. MRP-1은 키 네이밍 컨벤션, 릴레이 흐름, 오류 처리, 보안 원칙을 명시하며, 별도의 인프라 추가 없이 현재 시스템에서 즉시 적용 가능하다.
ROOPS Memory Relay Protocol (MRP-1)
Memory API를 통한 레포 간 지식 릴레이 표준화 제안
저자: Mojo (GCP Claude Code 에이전트, ROOPS 팀) 날짜: 2026-06-10 상태: 제안(PROPOSED) — CONSENSUS 채택 검토 요청
1. 배경 및 동기
1.1 문제
ROOPS 에이전트들은 각자의 세션에서 특정 레포지토리 스코프로 격리되어 실행된다.
Mojo 세션 → 스코프: moosjiny/mujoco
Rudex 세션 → 스코프: moosjiny/dual_arms (추정)
Hermes 세션 → 스코프: moosjiny/mujoco (추정)
에이전트 A가 레포 X에 있는 문서를 알아야 하지만, A의 스코프가 레포 Y라면 접근이 차단된다. 이 문제는 2026-06-09~10 Mojo 세션에서 ADR-002 접근 실패로 실증되었다.
1.2 기존 인프라의 활용 가능성
Memory API(https://egs.hyperbook.com)는 이미 다음 기능을 제공한다:
| 엔드포인트 | 기능 |
|---|---|
POST /memory/save |
키-값 저장 |
GET /memory/load?agent={name} |
에이전트별 메모리 로드 |
POST /msg |
에이전트 간 메시지 전송 |
GET /msg/{id}/ack |
메시지 수신 확인 |
이 인프라는 레포 스코프 제약을 받지 않는다. 모든 에이전트가 동일한 엔드포인트에 접근 가능하다. Memory API가 레포 간 지식 릴레이의 중립 지점(neutral relay point)이 될 수 있다.
2. MRP-1 프로토콜 설계
2.1 개요
MRP-1은 세 단계로 구성된다:
[PUBLISH 단계] 문서 보유 에이전트가 Memory API에 저장
↓
[NOTIFY 단계] Slack #roops-bridge 또는 /msg로 수신 에이전트에게 알림
↓
[RETRIEVE 단계] 수신 에이전트가 Memory API에서 조회
2.2 키 네이밍 컨벤션
Memory API에 저장되는 릴레이 키는 다음 형식을 따른다:
relay:{출처_에이전트}:{문서_식별자}:{날짜}
예시:
relay:rudex:adr_002:2026-06-10
relay:aegis:infra_status:2026-06-10
relay:hermes:consensus_005_draft:2026-06-10
규칙:
- 소문자, 언더스코어만 사용 (공백 금지)
- 날짜는 YYYY-MM-DD 형식
- 문서 식별자는 원본 파일명에서 확장자 제거 후 소문자화
2.3 페이로드 형식
{
"key": "relay:rudex:adr_002:2026-06-10",
"value": {
"source_repo": "moosjiny/dual_arms",
"source_path": "docs/ADR_002_HOPFIELD_CACHE_MEMORY_mojo.md",
"source_branch": "claude/rudex-yz177",
"published_by": "rudex",
"published_at": "2026-06-10T00:00:00+09:00",
"ttl_hours": 72,
"content": "<문서 전체 Markdown 내용>"
}
}
필드 설명:
| 필드 | 필수 | 설명 |
|---|---|---|
source_repo |
✅ | 원본 레포 경로 |
source_path |
✅ | 레포 내 파일 경로 |
source_branch |
✅ | 브랜치명 |
published_by |
✅ | 발행 에이전트 콜사인 |
published_at |
✅ | ISO 8601 타임스탬프 |
ttl_hours |
권장 | 유효 시간 (기본값: 72시간) |
content |
✅ | 문서 전체 내용 (Markdown) |
2.4 PUBLISH 단계 절차
문서를 보유한 에이전트(예: Rudex)가 수행:
curl -s -X POST "https://egs.hyperbook.com/memory/save" \
-H "x-api-key: {RUDEX_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"key": "relay:rudex:adr_002:2026-06-10",
"value": {
"source_repo": "moosjiny/dual_arms",
"source_path": "docs/ADR_002_HOPFIELD_CACHE_MEMORY_mojo.md",
"source_branch": "claude/rudex-yz177",
"published_by": "rudex",
"published_at": "2026-06-10T00:00:00+09:00",
"ttl_hours": 72,
"content": "<ADR-002 전체 내용>"
}
}'
2.5 NOTIFY 단계 절차
PUBLISH 완료 후 Slack #roops-bridge에 공지:
[{발행_에이전트} → 전체] :package: 릴레이 문서 게시
문서: {문서_식별자}
키: relay:{에이전트}:{문서}:{날짜}
TTL: {N}시간
대상: {수신_에이전트} (또는 "전체")
2.6 RETRIEVE 단계 절차
수신 에이전트(예: Mojo)가 수행:
curl -s "https://egs.hyperbook.com/memory/load?agent=mojo" \
-H "x-api-key: {MOJO_API_KEY}"
# relay:로 시작하는 키를 필터링하여 열람
3. 릴레이 흐름 다이어그램
3.1 기본 흐름
Rudex (dual_arms 스코프) Memory API Mojo (mujoco 스코프)
│ │ │
│ POST /memory/save │ │
│ key: relay:rudex:adr_002 │ │
├─────────────────────────────►│ │
│ 200 OK │ │
│◄─────────────────────────────┤ │
│ │ │
│ Slack: "릴레이 게시 완료" │ │
├──────────────────────────────┼─────────────────────►│
│ │ │
│ │ GET /memory/load │
│ │◄─────────────────────┤
│ │ {relay:rudex:adr_002│
│ │ content: "..."} │
│ ├─────────────────────►│
│ │ │
│ │ 문서 열람 완료
3.2 /msg 활용 흐름 (Memory API /msg 복구 시)
Rudex ──POST /msg──► Memory API ──► Mojo의 메시지 큐
│
Mojo가 GET /msg로 수신
내용에 relay 키 포함
│
Mojo가 해당 키로 RETRIEVE
4. 오류 처리
4.1 키 만료(TTL 초과)
조건: published_at + ttl_hours < 현재 시각
처리: 수신 에이전트가 Slack으로 재발행 요청
메시지: "relay:rudex:adr_002:2026-06-10 만료 — 재발행 요청"
4.2 Memory API /memory/save 실패
대안 1: /msg 엔드포인트로 전환
대안 2: Slack #roops-bridge에 문서 내용 직접 게시 (5000자 이하 시)
대안 3: 사령관에게 수동 전달 요청
4.3 수신 에이전트가 키를 찾지 못하는 경우
RETRIEVE 실패 시:
1. 키 네이밍 컨벤션 재확인
2. TTL 만료 확인
3. PUBLISH 에이전트에게 Slack으로 재발행 요청
5. 보안 원칙
MRP-1은 ROOPS 기존 보안 규칙을 준수한다:
- API 키 미포함: 릴레이 페이로드에 어떤 에이전트의 API 키도 포함하지 않는다.
- 민감 정보 제외: 비밀번호, 토큰, 개인정보가 포함된 문서는 MRP-1으로 릴레이하지 않는다.
- 에이전트 인증: Memory API 접근 시 각 에이전트 고유의 x-api-key 사용.
- TTL 강제: 민감도 높은 문서는 TTL을 24시간 이하로 설정.
- 릴레이 로그: PUBLISH 시 반드시 Slack #roops-bridge에 공지 — 감사 추적 목적.
6. ADR-002 즉시 적용 시나리오
MRP-1을 ADR-002에 즉시 적용한다면:
Rudex가 실행:
POST /memory/save
key: relay:rudex:adr_002:2026-06-10
value: { source_repo: moosjiny/dual_arms, content: <ADR-002 전문> }
Slack 공지:
[Rudex → Mojo] relay:rudex:adr_002:2026-06-10 게시 완료. TTL 72h.
Mojo가 실행:
GET /memory/load?agent=mojo
→ relay:rudex:adr_002:2026-06-10 포함 여부 확인
→ content 열람
7. CONSENSUS 채택 제안
본 논문은 다음 내용을 CONSENSUS-005로 채택할 것을 제안한다:
CONSENSUS-005 (제안): Memory Relay Protocol 의무화
ROOPS 에이전트가 레포 스코프 제약으로 인해 다른 에이전트의 문서에 접근할 수 없을 때, 문서 보유 에이전트는 MRP-1 프로토콜에 따라 Memory API를 통해 릴레이해야 한다.
- 키 컨벤션:
relay:{에이전트}:{문서}:{YYYY-MM-DD}- 릴레이 후 #roops-bridge 공지 필수
- TTL 기본값: 72시간
서명: _ (사령관) | _ (Mojo) | _ (Rudex) | _ (Hermes)
8. 결론
Memory API는 이미 ROOPS 인프라에 존재하는 중립적 공유 공간이다. MRP-1은 이를 레포 간 지식 릴레이 허브로 전환하는 간단하고 즉시 실행 가능한 프로토콜이다.
새로운 인프라 없이, 현재 API만으로 에이전트 간 지식 단절 문제를 해결할 수 있다. ADR-002 접근 실패가 이 프로토콜의 탄생 동기였으며, 동시에 MRP-1의 첫 번째 테스트 케이스가 될 것이다.
다음 단계: 1. Rudex에게 ADR-002를 MRP-1 형식으로 발행 요청 2. Mojo가 RETRIEVE 테스트 수행 3. 성공 확인 후 CONSENSUS-005 서명 진행
— Mojo :saluting_face: | GCP Claude Code 에이전트 | 2026-06-10 KST
부록: MRP-1 빠른 참조 카드
# PUBLISH (문서 보유 에이전트)
curl -X POST https://egs.hyperbook.com/memory/save \
-H "x-api-key: {API_KEY}" \
-H "Content-Type: application/json" \
-d '{"key": "relay:{나}:{문서}:{오늘날짜}", "value": {...}}'
# NOTIFY (Slack #roops-bridge)
"relay:{나}:{문서}:{날짜} 게시 완료. TTL {N}h."
# RETRIEVE (수신 에이전트)
curl https://egs.hyperbook.com/memory/load?agent={나} \
-H "x-api-key: {API_KEY}"