페르소나 다중성 시대의 문서 라이프사이클 — 진단과 제안

TL;DR

• "문서가 안 읽히고 안 업데이트된다"의 표면 원인은 트리거 부재지만, 더 깊은 원인은 페르소나 다중성 × 문서 다계층이 만든 ownerless 영역이다.
• 채널톡 면접 결과가 11일째 메모리에 "대기 중"으로 남은 것은 Jarvis가 트리거를 못 받았기 때문이 아니라, "이 이벤트의 owner가 누구인지" 합의가 처음부터 없었기 때문이다.
• Jarvis 행동 규칙만 강화하면 Jarvis가 owner인 영역만 좋아지고, Wansu·Jini·Raphael·Nano가 owner여야 할 영역은 그대로 stale로 남는다.
• 제안은 3축 통합이다: A 이벤트 트리거 + B 계층별 canonical + C 페르소나-문서 오너십 매트릭스. 셋 다 있어야 작동한다.

1. 문제 정의

1.1 표면 증상

• 채널톡 면접 결과가 11일째 메모리에 "결과 대기 중"으로 남아 있었다. 사용자가 직접 짚어주기 전까지 어떤 페르소나도 업데이트를 시도하지 않았다.
• 문서는 만들어지지만 그 후 읽히지 않고, 상태가 바뀌어도 업데이트되지 않는다.
• 4계층 (memory / hangman-docs / Notion / Linear) 에 같은 사건이 흩어져 있어, "어느 게 진짜 본체인지" 모호하다.

1.2 사용자가 짚은 본질

"Jarvis 행동 규칙만 강화하고 싶은 게 아니라, 모든 페르소나가 문서 관리를 잘했으면 한다."

이 한 문장이 문제를 한 칸 옮긴다. 단일 페르소나의 행동 규칙 강화가 아니라, 페르소나 시스템 전체의 문서 라이프사이클 설계 문제다.

1.3 빠진 차원 — 왜 단일 페르소나 강화로는 부족한가

Jarvis가 1차로 제시한 두 진단은 이렇다.

• A. 쓰기 트리거는 있는데 읽기·업데이트 트리거가 없다.
• B. 4계층 구조에서 canonical 위치가 불분명하다.

둘 다 정확하지만, 둘 다 암묵적으로 단일 행위자를 가정한다. "누가 트리거를 받을 것인가", "누가 canonical을 결정할 것인가" — 이 질문이 빠져 있다. 페르소나가 N명인 시스템에서 이 질문이 빠지면 누구도 자기 일이라고 생각하지 않는다. 공유지의 비극.

2. 진단 — 왜 ownerless 영역이 생기는가

2.1 페르소나 × 문서 매트릭스

현재 시스템은 두 차원의 곱이다.

• 행 = 페르소나 (Jarvis, Wansu, Jini, Raphael, Nano, Asurada 등)
• 열 = 문서 계층 (memory / hangman-docs / Notion / Linear)
• 셀 = 특정 페르소나가 특정 계층에서 어떤 카테고리의 문서를 owner로 책임지는가

이 매트릭스가 문서로 존재하지 않는다. 페르소나의 시스템 프롬프트에 "너는 리서치 담당이다" 같은 역할은 적혀 있지만, "라이프 이벤트(면접 결과 등)는 Jarvis가 모든 계층에서 owner다" 같은 영역 매핑은 없다.

2.2 자기-쓰기 / 타-읽기 비대칭

페르소나는 자기가 쓴 문서는 잘 안다. 자기 세션 history에 남아있으니까. 하지만 다른 페르소나가 쓴 문서는 MEMORY.md 인덱스를 통해서만 알 수 있다. 그리고 MEMORY.md는 포인터일 뿐 상태 변화를 안내하지 않는다.

→ 자기 영역은 trace하지만, 남의 영역은 읽기 자체가 일어나지 않는다. 자연스럽게 stale이 누적된다.

2.3 이벤트 ↔ 페르소나 라우팅 부재

사용자가 "채널톡 떨어졌어"라고 말했을 때, 이 발화는 어떤 페르소나로 라우트되어야 하는가?

• 사용자가 명시적으로 태그하면 → 그 페르소나로
• 태그 없으면 → ??? (현재 디폴트 fallback이 모호)

면접 결과는 Jarvis-owner 이벤트다. 하지만 사용자가 일반 채널에 무심코 말하면, 누가 이걸 받아서 N개 문서 업데이트를 지휘할지 합의가 없다. 결국 아무도 받지 않는다.

2.4 정리하면

3. 신호 — 관찰된 증거

3.1 채널톡 11일 stale (대표 사례)

• 5/27 면접·회고 완료 → 메모리 "결과 대기 중"
• 6/7 사용자 직접 질문 → 그제야 "떨어졌다" 공유
• 회고 문서 (hangman-docs), 면접 prep synthesis, Notion 회고 페이지 — 세 곳 모두 결과 미반영
• 한 페르소나(Jarvis)가 wrap-up 중 stale 플래그를 띄웠지만, 다른 페르소나가 사이에 결과를 흡수해 업데이트하는 경로는 없었다

3.2 다른 ownerless 의심 영역 (가설)

• 프로젝트 상태 변화: HAN 티켓 close, PR merge 후 관련 hangman-docs 보고서가 "draft"로 남는 경우
• 외부 응답 도착: 쿠팡 리크루터 회신, 다빈치 미팅 결과 등 다 페르소나 → owner 매핑이 모호
• Notion DB 동기화: 일정 DB·구직 트래커가 메모리 상태와 정합되는 트리거 부재

이건 가설 수준이라 검증 질문으로 별도 정리한다 (§6).

4. 제안 — 3축 통합

4.1 세 축 한꺼번에

Jarvis A·B에 C 오너십 매트릭스를 더한다. 셋이 동시에 있어야 작동한다.

• A 이벤트 트리거: 상태 변화 발화 → 영향받는 문서 셋 자동 묶기
• B 계층 canonical: memory = 포인터, hangman-docs = 본체, Notion = 요약 링크
• C 페르소나-문서 오너십: 어느 페르소나가 어느 카테고리의 owner인가

C 없이 A만 강화하면 → 트리거는 쐈는데 받는 페르소나가 없다.
C 없이 B만 강화하면 → canonical은 정해졌는데 유지 보수자가 없다.
A·B 없이 C만 그리면 → owner는 정해졌는데 언제 발동할지 모른다.

4.2 페르소나-문서 오너십 매트릭스 (초안)

문서 카테고리는 4계층 위에 있는 의미 단위다. 같은 카테고리는 4계층 어디에 있든 동일 owner가 본다.

→ 이 표는 초안이고, 사용자 합의가 핵심이다. 정확한 owner는 §6 검증 질문 참고.

4.3 Owner 페르소나의 책임 (역할 정의)

owner는 직접 쓰는 사람이 아니다. 상태 동기화를 지휘하는 사람이다. 구체적으로:

• 해당 카테고리에 상태 변화 발화 감지 (사용자 태그 없어도 라우팅)
• 영향받는 문서 셋 나열 (memory N개, hangman-docs N개, Notion N개)
• 본인이 직접 업데이트하거나, 적합한 페르소나에 위임
• 업데이트 완료 보고 (어디 어디 손댔는지)

4.4 운영 룰 제안 (3개)

룰 1 — 라우팅 규칙 명시
태그 없는 상태 변화 발화는 카테고리 매핑으로 라우트한다. 이 매트릭스가 라우팅 테이블이 된다.

룰 2 — wrap-up에 매트릭스 스캔 추가
세션 끝에 owner 페르소나는 자기 카테고리의 stale 후보를 묶어 사용자에게 보고한다. 지금처럼 Jarvis 혼자 전체 스캔하지 않는다.

룰 3 — 계층 canonical 1줄 정의
- memory: 포인터·인덱스. 본문 X. 자동 업데이트 대상.
- hangman-docs: canonical 본체. 이벤트 기반 업데이트. owner가 책임.
- Notion: 요약 + canonical 링크. 본문 중복 X.
- Linear: 작업 단위 추적. 상태 변화 시 관련 hangman-docs 링크 첨부.

5. 비교 — Jarvis 안 vs 본 제안

본 제안은 비용이 더 든다. 매트릭스를 합의하고 페르소나 시스템 프롬프트를 갱신해야 한다. 하지만 Jarvis 안만으로는 동일 패턴의 재발을 다른 카테고리에서 보게 될 것이다.

6. 검증 질문 (사용자 결정 사안)

1. 매트릭스 초안의 owner 매핑이 직관과 맞나? 특히 "시스템 운영/메타"는 Jarvis로 두는 게 맞는지, 별도 페르소나가 더 적합한지.
2. Nano·Raphael의 owner 영역이 충분한가? 현재 초안에서 두 페르소나는 비교적 좁다. 의도된 비대칭인지 아닌지.
3. 라우팅 규칙(룰 1) 실효성: 사용자가 "채널톡 떨어졌어"라고 말했을 때, Jarvis가 자동으로 받는 흐름을 강제로 둘 것인지, 아니면 사용자 태그를 기다릴 것인지.
4. Notion 본문 비우기 (계층 canonical 룰): 기존 Notion 페이지 중 본문이 두꺼운 것들을 정말 요약 + 링크로 줄일지, 아니면 일부 예외(예: 면접 회고)는 본문 유지할지.
5. 우선순위: 3축 중 어느 것부터 도입할 것인가. C(매트릭스 합의) → A(트리거) → B(계층 정리) 순서가 안전해 보이지만, 사용자 직관 확인 필요.

7. 다음 액션 (사용자 승인 후)

• [ ] 매트릭스 초안 사용자 합의 (§4.2, §6 1-2번)
• [ ] 페르소나 시스템 프롬프트에 owner 카테고리 명시 (각 페르소나 .md 갱신)
• [ ] ~/.claude/notes/persona-document-ownership.md 운영 룰 문서화
• [ ] 라우팅 규칙 Slack 봇 디스패처 반영 검토 (dispatcher 프로젝트 연계)
• [ ] 1주 시범 후 stale 발생 빈도 비교 (시범 전/후)
• [ ] 시범 결과 따라 매트릭스 확정 또는 재조정

부록 — 본 보고서의 메타 위치

이 보고서 자체가 리서치/프레이밍 카테고리다. 본 제안이 통과되면 Jini owner. 후속 업데이트(매트릭스 합의 후 v2 등)는 Jini가 책임진다.