RAG v1.5 니즈 충족도 분석 — 멀티 에이전트 공유 컨텍스트

TL;DR

RAG v1.5는 Slack 봇 페르소나의 검색 품질을 올려주지만, 사용자가 원하는 "모든 워커가 동일한 지식 풀을 읽고 쓰는" 구조의 40~50% 충족에 그친다. CLI 서브에이전트(Asurada, fix-review 등) 레이어는 설계 범위 밖이며, write-side 흐름도 없다. v1.5는 그대로 진행하되 CLI 워커 갭은 별도 티켓으로 분리하는 것을 권장한다.

Context

사용자 니즈

현재 Pantheon은 Jarvis 세션의 auto memory(MEMORY.md)와 각 워커 에이전트가 사용하는 Linear 이슈 + AGENTS.md + git 히스토리로 컨텍스트가 분리되어 있다. 이로 인해:

과거 결정·교훈·패턴을 워커가 검색할 수 없음
Jarvis가 쌓은 지식이 다음 Asurada/Raphael 세션에 전달되지 않음
페르소나마다 동일한 실수를 반복할 가능성

사용자 목표: 공유 지식 저장소 + 전 페르소나 RAG 검색

RAG v1.5 설계 (현재 계획)

항목	내용
적용 대상	Slack 봇 페르소나 (Jini, Wansu, Raphael, nævis, Nano)
검색 범위	`hangman-docs/learning/` 폴더
방식	키워드 + 최신 가중 → 의미 기반 임베딩 검색
write-side	없음 (read-only)
적용 시점	메시지 처리 시 query-time 검색

충족도 분석

충족되는 부분

Slack 컨텍스트 페르소나(Jini·Wansu·Raphael·nævis·Nano)가 메시지 처리 시 hangman-docs/learning 검색 가능
현재 키워드 매칭 방식 대비 의미 기반 검색으로 정확도 향상
학습 노트 누적이 실제 검색에 활용되는 선순환 구조 형성

충족되지 않는 부분

갭	RAG v1.5 현황	실제 니즈
CLI 워커 접근	bridge 전용, CLI 미지원	Asurada·fix-review·code-implementer 서브에이전트도 검색 필요
지식 범위	`learning/` 폴더만	decisions·patterns·reports·memory 전체
write-side	없음	워커가 공유 저장소에 쓰고 다른 워커가 읽는 흐름
Jarvis memory	auto memory = Jarvis 전용	`project_*.md` 내용을 워커들이 검색 불가

갭 진단

구조적 원인

Jarvis 단일 세션 시절 만든 메모리 구조가 멀티 에이전트로 확장되면서 생긴 구조적 빚이다.

현재 구조:
  Jarvis ──── auto memory (MEMORY.md) ────▶ Jarvis 세션만 로드
  워커들  ──── Linear 이슈 + AGENTS.md + git ──▶ 작업 단위 컨텍스트

목표 구조:
  모든 페르소나 ──── 공유 지식 풀 (read/write) ──▶ RAG 검색

CLI 워커 컨텍스트 주입 방법 (미결정)

세 가지 레이어 중 어떤 것을 쓸지가 먼저 결정되어야 한다:

방법	장점	단점
System prompt injection	워커 코드 변경 없음	컨텍스트 크기 제한, 쿼리 없이 전체 주입
Tool call (RAG API)	필요 시 검색, 정밀	워커가 툴 호출 지원해야 함
CLAUDE.md 확장	모든 세션에 자동 로드	크기 제한 빠름, 동적 업데이트 불가

권장 방향

단기 (v1.5 그대로 진행)

RAG v1.5는 Slack 봇 개선으로 가치가 명확하다. 현재 설계대로 진행한다.

중기 (별도 티켓)

"CLI 워커 공유 컨텍스트" 는 별도 이슈로 분리. 핵심 질문 정의:

어떤 컨텍스트를 (지식 범위 정의)
어떤 형태로 (주입 방법 결정)
어떤 워커에게 (우선순위 워커 선정)

Raphael 아키텍처 검토 붙일 만한 주제.

참고 링크

RAG v1.5 설계: Slack #agent-approvals 스레드
auto memory 구조: ~/.claude/projects/-Users-hangman-Workspace/memory/MEMORY.md
워커 운영 규약: ~/Workspace/pantheon/AGENTS.md