mutual-monitoring

Mutual Performance Monitoring & Backup — 교차 검증과 백업

Team Big Five의 2번(상호 성과 모니터링)·3번(백업 행동) 구성요소. 팀원들이 서로의 작업을 관찰해 실수를 잡고, 막힌 팀원의 일을 대신 수행한다. performance-monitor 에이전트가 전담하되, 모든 contributor도 자기 인접 산출물을 부분적으로 모니터링한다.

왜 필요한가

혼자 일하는 에이전트는 자기 오류를 못 본다. 특히 경계면 — 팀원 A의 출력이 팀원 B의 입력이 되는 지점 — 에서 각자는 "내 쪽은 맞다"고 믿지만 둘이 안 맞는다. 상호 모니터링은 이 경계면을 교차로 비교해 숨은 버그를 드러낸다. 백업은 한 팀원의 정체가 팀 전체를 멈추지 않게 한다.

Part 0: 실행 검증 (코드 과제 — 텍스트 대조보다 먼저)

코드 과제에서 "두 산출물이 markdown 상으로 정합해 보임"은 "동작함"이 아니다. 경계면 텍스트 대조 전에 반드시 실행 검증을 먼저 한다:

• 해당 모듈/통합 트리의 빌드 · 타입체크 · 테스트 · 린트를 실제 실행하고 exit code를 기록한다.
• 하나라도 0이 아니면 즉시 BLOCKED/DRIFT — 텍스트 대조로 넘어가지 않는다.
• 보고서에 execution: {build, typecheck, test, lint} pass/fail + 출력 꼬리를 인용한다.
• 회귀 가드: Phase 1에서 잡은 baseline(기존 통과 테스트)이 깨지면 DRIFT. 통과하던 테스트는 절대 깨지면 안 된다.

산문 과제(리서치·문서·창작·마케팅)에는 실행할 스크립트가 없다 → Part 1의 정독 대조로 직행.

Part 1: Mutual Performance Monitoring (교차 검증)

핵심 원칙: "존재 확인"이 아니라 "경계면 교차 비교"

산출물이 생성되었는지 확인하는 것은 검증이 아니다. 의존 관계로 연결된 두 산출물을 함께 읽고, SMM의 해당 계약(스키마 또는 스타일/사실/연속성)을 기준으로 대조한다.

나쁨: "contributor-api가 users.json 만들었음 → OK"
좋음: "users.json의 필드 {id,name} ↔ contributor-ui가 기대하는 {id,name,email}
       → email 누락. SMM 인터페이스 위반. DRIFT 플래그."
나쁨(산문): "ch.4 초고 존재 → OK"
좋음(산문): "ch.1은 주인공을 외동으로, ch.4는 여동생 등장 → SMM canon 위반. DRIFT."

과제 유형별 모니터링 체크리스트

계약은 과제마다 다르므로 무엇을 대조하는지도 다르다:

코드/설계 : I/O shape, 타입, 계약 위반, 빌드/테스트(Part 0)
리서치/분석: 주장↔출처 정합(사실 원장), 인용 정확성, 분석 단위 일관, 무근거 주장
문서/보고서: 섹션 간 용어 일관, 중복·공백, 주장-근거 연결, 독자 적합
창작     : 보이스 드리프트, 타임라인/세계관 모순(canon 위반), 플롯 홀, POV·시제 일탈, 복선 회수
마케팅   : 핵심 메시지 일관, 브랜드 보이스, 채널별 톤, CTA·클레임 일관

또한 SMM §9의 명시된 위험 가정을 능동적으로 감시한다 — 그 가정이 깨질 조짐이 보이면 DRIFT 전이라도 리더에 알린다(사전 적응).

점진적 검증 (Incremental)

전체 완성 후 1회가 아니라, 각 모듈/Phase 완료 직후 즉시 검증한다. 늦게 잡은 경계면 버그는 그 위에 쌓인 작업까지 무효화한다.

판정 체계

판정	의미	후속
OK	SMM 기준 정합 (+ 코드면 실행 통과)	통과
DRIFT	산출물이 SMM/인접 산출물과 불일치, 또는 빌드/테스트 실패	해당 팀원에 폐쇄 루프 플래그 + 수정 요청
BLOCKED	산출물 누락/깨짐/의존 미충족	백업 행동 트리거 (Part 2)

소프트 제약(SMM §6에서 [soft])의 위반은 차단 DRIFT가 아니라 **권고(FYI)**로 — 드래프트 단계에서는 보이스·플롯 탐색을 막지 않는다. 차단 DRIFT는 [hard] 제약(계약·canon·사실·빌드)에만.

플래그 형식 (_workspace/monitor/round_{N}_report.md)

## {대상 팀원 / 경계면}
- 판정: OK | DRIFT | BLOCKED
- 실행(코드): build/typecheck/test/lint = pass/fail (+출력 꼬리)
- 근거: {어느 파일 어느 부분} ↔ {SMM 어느 기준 / 어느 인접 산출물}
- 권고: {구체적 수정 방향}

Mutual Trust 보정 (Calibrated, 이진 아님)

검증 강도는 경계면의 신뢰 등급(SMM §4)에 비례한다 — 결과 영향 큰 경계면은 매 라운드 재검증, 가벼운 건 한 번만. 검증 강도를 팀원 의심이 아니라 경계면 결과 비용으로 정한다. 검증은 계약 버전에 묶이므로, 의존 계약이 갱신되면 하위 "검증됨"은 무효 → 재검증. 모든 것을 매번 재검증하면 신뢰가 무너지고 비용이 폭발한다. 신뢰하되, 비싼 경계면은 본다.

Part 2: Backup Behavior (백업 행동)

정체 vs 정상 유휴 구분 (중요)

에이전트 팀에서 팀원은 매 턴 종료 후 정상적으로 idle이 된다. idle 자체는 실패가 아니다. **정체(stall)**는 다르게 정의한다:

정체 = 해당 task가 여전히 in_progress/미claim 상태이고, 리더의 점검 주기 N회(예: 2회)에 걸쳐 TaskUpdate 변화가 없음. (단순히 idle 알림이 온 것 ≠ 정체)

이 구분이 없으면 건강한 idle 팀원에게 백업을 발동해 중복 작업이 생기거나, 진짜 데드락을 놓친다.

트리거 신호

• 위 정의의 정체 (TaskList/TaskGet로 진행 없음 확인)
• 팀원 실패/중지 (작업 미완 + 복구 불가 보고)
• 한 팀원의 작업 큐가 과도하게 쌓임 (과부하)

백업 절차

1. monitor가 정체/과부하/실패를 감지 → 리더에게 폐쇄 루프로 보고
2. 리더가 판단:
   - 유휴 팀원 있음 → 그 팀원에게 작업 재할당 (TaskUpdate owner)
   - 작업이 크면 → 분할하여 여러 팀원에 분산
   - 대체 불가 → 부분 결과 보존 후 사용자에 보고
3. 백업 팀원은 SMM을 읽고 원 담당자의 진행분(부분 산출물)을 이어받는다
4. 원 담당자가 복귀하면 SMM 결정 로그로 인수인계 상태를 공유

백업의 한계

백업은 무한 재시도가 아니다. 같은 작업이 2회 실패하면 구조적 문제(SMM 결함, 작업 정의 오류)를 의심하고 리더가 재계획(Adaptability)을 검토한다.

Part 3: 팀 성과 스코어카드 (Team Scorecard)

Big Five의 전제는 팀 성과가 측정 가능하다는 것이다. monitor는 종료 전 _workspace/monitor/scorecard.md를 작성해 팀워크 품질을 계량한다:

## 팀 스코어카드
- DRIFT 건수 (경계면별):
- 재발 DRIFT (2회+):
- BLOCKED / 백업 발동 횟수:
- 적응 체크포인트 발동 횟수:
- OK까지 라운드 수:
- 완료 기준(rubric) 충족: {N}/{전체}
- 실행 게이트(코드): build/test/lint 최종 상태

이 스코어카드는 Phase 5 디브리핑(AAR)의 원자료가 되고, 하네스 진화의 학습 신호가 된다 — 좋은 실행과 나쁜 실행을 구분하는 유일한 근거다.

왜 이렇게 하는가 (원리)

• 경계면이 버그의 집 — 단일 산출물은 각자 맞아 보인다. 교차 비교만이 불일치를 드러낸다.
• 코드는 실행해야 검증 — markdown 정합 ≠ 컴파일·테스트 통과. Part 0가 없으면 "실행 안 된 그럴듯한 코드"에 만장일치 OK가 난다.
• 일찍 잡을수록 싸다 — 점진적 검증은 잘못된 토대 위 누적 작업을 막는다.
• idle ≠ 정체 — 정상 유휴를 실패로 오인하면 중복·thrash. 정체는 task 무변화로 정의.
• 백업은 팀 지향성의 행동적 표현 — "내 일 끝났으니 끝"이 아니라 팀 목표 완수까지가 일이다.
• 반복 실패는 적응 신호 — 백업으로 안 풀리면 모니터링 데이터가 리더의 재계획 근거가 된다.
• 측정 없이 진화 없다 — 스코어카드가 팀 성과를 계량해야 무엇을 고칠지 안다.