# task-1285.1 미팅 Cycle 7
날짜: 2026-03-31
안건: P1/P2 전 항목(6건) 위험 요소 종합 + 롤백 계획 (사이드 이펙트, 최악 시나리오, 롤백, 모니터링, 킬 스위치)

## 참석자 발언

### 헤르메스 (백엔드/인프라)

**P1 항목 위험 분석:**

**P1-1. Progressive Disclosure (disclosure_phase 파라미터)**

| 항목 | 상세 |
|---|---|
| 사이드 이펙트 | `disclosure_phase="summary"` 모드에서 에이전트가 워크플로우 참조 경로만 받고 실제로 Read하지 않는 경우, 워크플로우 규칙 위반이 발생합니다. 특히 DIRECT-WORKFLOW.md의 "금지 행위 목록"을 summary에서 생략하면 에이전트가 금지된 작업을 수행할 수 있습니다. 또한 `_build_cowork_section()`이 disclosure_phase에 따라 팀원 정보를 생략하면, 코워크 체이닝에서 다음 팀원을 인식하지 못하는 문제가 발생합니다. |
| 최악 시나리오 | summary 모드로 배포한 후, Lv.1 작업에서 에이전트가 워크플로우 규칙을 완전히 무시하고 금지 행위(git push, 파일 삭제 등)를 수행. 동시에 여러 에이전트가 summary 모드로 실행되어 품질 저하가 누적되지만, 개별 작업 단위로는 "완료"로 보고되어 문제 발견이 지연됩니다. |
| 롤백 방법 | **git revert 가능.** `disclosure_phase` 파라미터의 기본값이 `"full"`이므로, 해당 커밋을 revert하면 모든 호출이 기존 full 모드로 동작합니다. dispatch.py의 disclosure 결정 로직만 제거하면 됩니다. 단일 커밋으로 관리하면 `git revert <commit>` 한 번에 복구 가능. |
| 모니터링 | (1) 에이전트 실행 후 .done 보고서에서 "워크플로우 참조" 언급 빈도 추적. summary 모드에서 워크플로우 미참조 시 경고. (2) QC 패스율을 disclosure_phase별로 분리 집계. summary 모드의 QC 패스율이 full 대비 20% 이상 하락하면 알림. (3) `build_prompt()` 반환값의 토큰 수를 로깅하여 summary/standard/full 간 실제 차이를 측정. |
| 킬 스위치 | dispatch.py에서 disclosure 결정 로직에 **환경 변수 오버라이드** 추가: `DISCLOSURE_OVERRIDE=full`을 설정하면 모든 작업이 full 모드로 실행. `.env` 파일 한 줄 수정으로 즉시 비활성화 가능. 코드 변경/배포 불필요. |

**P1-2. 읽기/쓰기 격리 (agent_type + worktree --read-only)**

| 항목 | 상세 |
|---|---|
| 사이드 이펙트 | (1) read-only 에이전트가 분석 결과를 파일로 저장하지 못해 후속 에이전트가 결과를 받지 못하는 경우. 현재 일부 read 작업도 임시 파일(`.analysis-result.md`)을 생성하는데, read-only worktree에서 이것이 차단됩니다. (2) dispatch.py에 `--agent-type` 파라미터 추가 시, 기존 호출부(cron 스크립트, chain_manager.py)가 `--agent-type`을 전달하지 않아 기본값 fallback이 발생. 기본값을 `"write"`로 설정하면 격리 효과 없음, `"read"`로 설정하면 기존 write 작업이 깨짐. (3) worktree_manager.py의 `--read-only` 플래그가 git worktree의 파일 시스템 권한을 변경하는데, worktree 삭제 시 권한 복구가 실패하면 좀비 worktree가 남습니다. |
| 최악 시나리오 | write 작업이 실수로 read-only 모드로 실행되어 코드 수정이 전혀 안 됨. 에이전트는 "수정 완료"로 보고하지만 실제 파일은 변경되지 않음. 이것이 체이닝의 중간 단계에서 발생하면, 후속 단계가 이전 단계의 수정 결과가 없는 상태에서 실행되어 전체 체인이 실패합니다. |
| 롤백 방법 | **설정 변경으로 복구 가능.** (1) dispatch.py의 `--agent-type` 파라미터를 무시하는 `AGENT_TYPE_OVERRIDE=write` 환경 변수 추가. (2) worktree_manager.py의 `--read-only` 플래그를 no-op으로 만드는 `WORKTREE_READONLY_DISABLE=1` 환경 변수. (3) DIRECT-WORKFLOW.md의 에이전트 분류 가이드 섹션은 문서이므로 삭제하면 됨. git revert로 코드 변경 전체 복구도 가능하지만, 환경 변수 방식이 더 빠릅니다. |
| 모니터링 | (1) worktree_manager.py에 `--read-only` 모드 실행 횟수 로깅 추가. read/write 비율이 예상 범위(read 30-40%, write 60-70%)를 벗어나면 알림. (2) read-only 에이전트 실행 후 worktree 내 파일 변경 건수 체크. 0건이어야 정상, 1건 이상이면 격리 실패. (3) write 에이전트의 .done 파일에서 "파일 수정 불가" 에러 메시지 패턴 감지. |
| 킬 스위치 | `WORKTREE_READONLY_DISABLE=1` 환경 변수. 이 값이 설정되면 worktree_manager.py가 `--read-only` 플래그를 무시하고 모든 worktree를 read-write로 생성. dispatch.py의 agent_type 분기도 우회하여 기존 동작으로 복귀. |

**P1-7. hooks 자동 강제 (PostToolUse pyright+ruff)**

| 항목 | 상세 |
|---|---|
| 사이드 이펙트 | (1) **성능 저하**: PostToolUse Write/Edit 이벤트마다 pyright+ruff가 실행되므로, 대량 파일 수정 작업(100+ 파일 리팩토링)에서 hooks 실행 시간이 누적되어 에이전트 세션 타임아웃 위험. (2) **False positive**: pyright strict 모드에서 Third-party 라이브러리의 타입 스텁이 없으면 에러로 판정. 실제로는 정상 코드인데 hooks가 중단시킴. (3) **ruff 버전 불일치**: 프로젝트별 ruff 설정(pyproject.toml)이 다르면 hooks의 전역 ruff 설정과 충돌. (4) **비Python 파일**: settings.json의 hooks가 `.py` 확장자 필터 없이 설정되면, `.md`, `.json` 파일 수정에도 pyright가 실행되어 무의미한 에러 발생. |
| 최악 시나리오 | **무한 루프 시나리오**: hooks가 에이전트에게 "이 에러를 수정하세요"라고 경고 → 에이전트가 수정 시도 → 수정이 Write 이벤트를 트리거 → hooks가 다시 실행 → 새로운 에러 발견 → 에이전트 재수정 → 무한 반복. 에이전트 세션이 토큰 한도까지 소진되고, 원본 코드가 반복 수정으로 오히려 훼손됩니다. |
| 롤백 방법 | **설정 변경만으로 즉시 복구.** `.claude/settings.json`의 `hooks` 섹션을 제거하거나 빈 객체(`{}`)로 교체. hooks는 settings.json에서만 정의되므로 코드 변경 불필요. `git checkout -- .claude/settings.json`으로 이전 상태 복구 가능. |
| 모니터링 | (1) hooks 실행 횟수/세션 로깅. 단일 세션에서 hooks 실행이 50회를 초과하면 알림 (무한 루프 의심). (2) hooks 실행 시간 누적 로깅. 세션 전체 시간 대비 hooks 시간이 30%를 초과하면 성능 저하 알림. (3) critical severity 판정 빈도 추적. 전체 hooks 실행 중 critical 비율이 40%를 초과하면 false positive 의심. |
| 킬 스위치 | **2단계 킬 스위치**: (1) **소프트 킬**: settings.json의 hooks에서 `exitCodePolicy`를 모든 항목에 대해 `"ignore"`로 변경. hooks는 실행되지만 결과를 무시. 데이터 수집은 계속됨. (2) **하드 킬**: settings.json의 hooks 섹션 전체 삭제. hooks 완전 비활성화. |

---

**P2 항목 위험 분석:**

**P2-3. haiku 전용화 (A/B 테스트)**

| 항목 | 상세 |
|---|---|
| 사이드 이펙트 | (1) A/B 테스트 기간(4주) 중 haiku 그룹에 배정된 작업의 품질이 실제로 저하되면, 해당 작업의 산출물이 프로덕션에 반영되어 기술 부채가 됩니다. A/B 테스트는 "실험"이지만 산출물은 "실제"입니다. (2) haiku의 컨텍스트 윈도우(200K)가 sonnet과 동일하지만, 추론 능력이 다르므로 동일한 프롬프트에서 다른 해석을 합니다. 이것이 팀원 간 코드 스타일 불일치를 야기합니다. (3) 모델별 가격 차이로 인해 토큰 사용 패턴이 달라지면, 비용 모니터링 대시보드의 기준선이 왜곡됩니다. |
| 최악 시나리오 | haiku가 QC 검증에서 결함을 놓침(False Negative). QC를 통과한 코드가 프로덕션에 반영되었으나 실제로는 심각한 버그가 있음. 4주 A/B 테스트 종료 후 결과 분석에서 FNR 문제가 발견되지만, 이미 haiku가 통과시킨 산출물 n건이 코드베이스에 존재. 이 산출물을 하나씩 재검증하는 비용이 haiku 전용화로 절약한 비용보다 클 수 있습니다. |
| 롤백 방법 | **MODEL_MAP 상수 변경만으로 즉시 복구.** team_prompts.py의 `MODEL_MAP["qc_verify"]`를 `"haiku"`에서 `"sonnet"`으로 변경. A/B 테스트는 별도 스크립트로 관리하므로, 스크립트 실행을 중단하면 됩니다. A/B 테스트 중 haiku가 생성한 산출물의 재검증은 별도 태스크로 분리. |
| 모니터링 | (1) **FNR 실시간 추적**: haiku QC 통과 산출물을 주 1회 sonnet으로 재검증. sonnet이 추가 결함을 발견하면 FNR 카운트 증가. (2) A/B 그룹 간 QC 패스율 비교. 통계적 유의성 발생 전이라도 haiku 패스율이 sonnet 대비 30% 이상 높으면 과소 판정 의심. (3) haiku 실행 비용을 별도 집계하여 비용 절감 효과 정량화. |
| 킬 스위치 | A/B 테스트 스크립트에 `AB_TEST_ACTIVE=false` 환경 변수. 비활성화 시 모든 QC가 기존 sonnet 모델로 실행. 4주 대기 없이 중간 종료 가능. |

**P2-4. TRUST 5 태그 부착 (trust_summary JSON)**

| 항목 | 상세 |
|---|---|
| 사이드 이펙트 | (1) `qc_verify.py`의 `build_result()`에 `trust_summary` 필드를 추가하면, 결과 JSON을 파싱하는 모든 다운스트림(chain_manager.py, 보고서 생성 스크립트)이 새 필드에 대응해야 합니다. 대응하지 않으면 파싱 에러는 안 나지만(추가 필드 무시), trust_summary를 활용하는 기능이 동작하지 않습니다. (2) TRUST 5차원 판정 로직이 기존 verifier 9종의 결과를 5차원으로 매핑하는데, 매핑 로직이 복잡하면 QC 실행 시간이 증가합니다. |
| 최악 시나리오 | trust_summary의 매핑 로직에 버그가 있어, 실제로는 Tested 차원이 FAIL인데 PASS로 표시됨. 에이전트와 인간이 trust_summary만 보고 품질을 판단하면 결함 있는 코드가 승인. trust_summary가 "신뢰할 수 없는 신뢰 지표"가 됩니다. |
| 롤백 방법 | **git revert 가능.** trust_summary는 기존 필드에 "추가"하는 것이므로, revert하면 기존 JSON 구조로 복귀. 다운스트림은 trust_summary 필드가 없어도 동작해야 하므로(하위호환) 문제 없음. |
| 모니터링 | (1) trust_summary의 각 차원별 PASS/FAIL 분포 주간 집계. 특정 차원이 100% PASS이면 판정 로직 의심(진짜 모든 코드가 완벽할 수 없음). (2) trust_summary 판정과 기존 verifier 개별 결과 간 불일치율 모니터링. 불일치 5% 초과 시 매핑 로직 검토. |
| 킬 스위치 | `qc_verify.py`에서 `TRUST_SUMMARY_ENABLED=false` 환경 변수. 비활성화 시 build_result()가 trust_summary 필드를 생성하지 않음. 기존 JSON 구조로 자동 복귀. |

**P2-5. 모델 매핑 테이블 (MODEL_MAP)**

| 항목 | 상세 |
|---|---|
| 사이드 이펙트 | (1) MODEL_MAP을 `team_prompts.py` 모듈 레벨 상수로 추가하면, 이 파일을 import하는 모든 모듈이 MODEL_MAP에 접근 가능해져 의도치 않은 참조가 발생할 수 있습니다. (2) `_build_cowork_section()`에서 MODEL_MAP을 참조하여 모델 가이드를 자동 생성하는데, 모델명이 업데이트될 때(예: `"sonnet"` → `"sonnet-4"`) MODEL_MAP을 수정하지 않으면 잘못된 모델 가이드가 프롬프트에 삽입됩니다. (3) MODEL_MAP의 역할-모델 매핑이 실제 Claude Code 설정(`.claude/settings.json`의 model 필드)과 일치하지 않으면, 프롬프트에는 "haiku를 사용하세요"라고 쓰여있지만 실제로는 sonnet이 실행되는 불일치가 발생합니다. |
| 최악 시나리오 | MODEL_MAP이 잘못 설정되어 복잡한 코딩 작업에 haiku를 권장. 에이전트가 이 가이드를 따라 haiku 세션으로 전환(Claude Code의 model 스위칭 기능 사용)하면, 복잡한 리팩토링을 haiku가 수행하여 코드 품질이 심각하게 저하됩니다. |
| 롤백 방법 | **상수 삭제로 즉시 복구.** MODEL_MAP은 모듈 레벨 상수이므로 삭제하면 됨. `_build_cowork_section()`에서 MODEL_MAP 참조 분기를 제거하면 기존 동작(모델 가이드 미삽입)으로 복귀. git revert 한 커밋으로 처리 가능. |
| 모니터링 | (1) 프롬프트에 삽입된 모델 가이드와 실제 실행 모델의 일치율 추적. 불일치 10% 초과 시 알림. (2) MODEL_MAP 최종 수정일 추적. 30일 이상 미갱신 시 "stale model map" 경고. |
| 킬 스위치 | `MODEL_MAP_ENABLED=false` 환경 변수. 비활성화 시 `_build_cowork_section()`이 모델 가이드 섹션을 생성하지 않음. |

---

### 오딘 (프론트/워크플로우)

**1. 워크플로우 관점의 위험 종합:**

헤르메스의 기술적 분석에 워크플로우 관점을 보강합니다.

**P1-1 Progressive Disclosure -- 워크플로우 위험:**

가장 우려되는 것은 **"summary 모드에서 스킬 트리거 누락"** 입니다. 현재 build_prompt()가 생성하는 프롬프트에는 skill 파일 경로와 트리거 조건이 포함되어 있습니다. summary 모드에서 이 정보가 생략되면 에이전트가 적절한 스킬을 호출하지 못합니다.

**Fallback 메커니즘 제안:**

```
disclosure_phase="summary" 일 때:
1. 기본 지시 + 워크플로우 경로 전달 (현재 합의)
2. + "필요한 정보가 부족하면 DIRECT-WORKFLOW.md를 Read하세요" 지시 추가
3. + CRITICAL 섹션 목록 (절대 생략 불가 항목): 금지 행위, QC 의무, 스킬 경로
```

이 fallback은 에이전트의 "자율적 정보 획득" 능력에 의존합니다. Lv.1 작업이라도 에이전트가 필요할 때 워크플로우를 Read할 수 있도록, **summary 모드에서도 최소한의 방어선(금지 행위 목록)은 인라인 삽입**해야 합니다.

**P1-2 읽기/쓰기 격리 -- 워크플로우 위험:**

DIRECT-WORKFLOW.md에 에이전트 분류 가이드 섹션을 추가할 때, **기존 워크플로우의 "실행 순서"와 충돌하지 않도록 독립 섹션으로 배치**해야 합니다. 현재 WORKFLOW 문서 구조:

```
1. 시작 절차
2. 작업 수행
3. 보고 절차
4. 금지 행위
-- 추가 예정 --
5. 에이전트 분류 가이드 (NEW)
```

5번 섹션은 참조형이므로 실행 순서에 영향을 주지 않습니다. 단, **에이전트가 5번을 "작업 전 확인 사항"으로 오해하여 불필요하게 자기 분류를 시도하는 행동**이 우려됩니다. 섹션 제목을 "에이전트 분류 가이드 (dispatch 자동 적용, 에이전트 직접 참조 불필요)"로 명확히 해야 합니다.

**P1-7 hooks -- 워크플로우 위험:**

hooks 동작 설명 섹션을 DIRECT-WORKFLOW.md에 추가할 때 핵심 원칙: **"hooks는 에이전트의 행동을 교정하되, 에이전트에게 hooks의 존재를 과도하게 인식시키면 안 됩니다."** 에이전트가 hooks를 인식하면 "hooks를 회피하려는" 행동(예: Write 대신 Bash echo로 파일 작성)이 나타날 수 있습니다.

WORKFLOW 문서에는 "코드 수정 후 자동 검증이 실행됩니다. 검증 실패 시 지시에 따르세요." 수준의 간접 언급만 포함합니다.

**2. 롤백 시나리오별 WORKFLOW 문서 대응:**

각 P1 항목 롤백 시 WORKFLOW 문서도 함께 롤백해야 합니다. WORKFLOW.md 변경은 별도 커밋으로 분리하여 독립 revert가 가능하도록 합니다.

| 롤백 대상 | WORKFLOW 대응 |
|---|---|
| Progressive Disclosure 롤백 | 영향 없음 (WORKFLOW 자체는 변경하지 않음) |
| 읽기/쓰기 격리 롤백 | 섹션 5 "에이전트 분류 가이드" 삭제 |
| hooks 롤백 | "자동 검증" 언급 문구 삭제 |

---

### 마아트 (품질/검증)

**1. 위험 요소의 QC 영향도 평가:**

각 항목의 위험이 QC 프로세스에 미치는 영향을 분석합니다.

**QC 영향도 매트릭스:**

| 항목 | QC 직접 영향 | QC 간접 영향 | 심각도 |
|---|---|---|---|
| (1) Progressive Disclosure | 에이전트가 QC 규칙을 불완전하게 인식 | QC 패스율 변동 | **높음** |
| (2) 읽기/쓰기 격리 | QC 프로세스 자체에 영향 없음 | write 격리 실패 시 산출물 부재 → QC 불가 | **중간** |
| (7) hooks | hooks 판정이 QC와 중복/충돌 가능 | hooks PASS인데 QC FAIL (또는 역) | **높음** |
| (3) haiku 전용화 | QC 모델 자체를 변경 | QC 품질 직접 영향 | **최고** |
| (4) TRUST 5 | QC 결과 표현 방식 변경 | 판정 정확도에 직접 영향 | **높음** |
| (5) MODEL_MAP | 프롬프트에 모델 가이드 추가 | 잘못된 모델 권장 시 산출물 품질 저하 | **중간** |

**2. hooks와 QC의 중복/충돌 시나리오:**

Cycle 4에서 합의한 "hooks=/=QC 면제" 원칙의 구체적 위험:

**시나리오 A: hooks PASS, QC FAIL**
- hooks(pyright+ruff)가 통과했지만 QC에서 로직 결함 발견
- 이것은 정상적인 동작. hooks는 "문법/스타일", QC는 "로직/품질"을 검증
- 위험: 에이전트가 "hooks 통과했으니 품질 OK"로 오해하여 QC 규칙을 경시

**시나리오 B: hooks FAIL(critical), 에이전트 중단, QC 미도달**
- hooks의 critical 판정으로 에이전트가 수정-재검증 루프에 빠짐
- QC 단계에 도달하지 못하고 세션 타임아웃
- 위험: 작업이 "미완료"로 남지만, hooks 로그만 보면 "진행 중"으로 보임

**시나리오 C: hooks 무한 루프 → 코드 훼손**
- 헤르메스가 지적한 무한 루프 시나리오에서, 반복 수정으로 코드가 훼손된 상태로 QC에 도달
- QC가 이 코드를 검증하면 대량의 결함이 발견되어 QC 보고서가 무의미하게 비대해짐

**3. 각 항목의 품질 게이트 제안:**

각 P1/P2 항목 배포 전 통과해야 하는 품질 게이트:

| 항목 | 품질 게이트 | 기준 |
|---|---|---|
| (1) Progressive Disclosure | disclosure_phase별 QC 패스율 비교 | summary 모드 패스율 >= full 모드 * 0.85 |
| (2) 읽기/쓰기 격리 | write 격리 정확도 | 100건 중 read-only에서 파일 변경 0건 |
| (7) hooks | False positive rate (FPR) | FPR < 10% (정상 코드에 대한 오판율) |
| (3) haiku A/B | False Negative Rate (FNR) | FNR < 15% (기존 합의) |
| (4) TRUST 5 | 매핑 정확도 | verifier 결과와 trust_summary 불일치 < 3% |
| (5) MODEL_MAP | 모델 가이드 정확도 | 프롬프트 모델 vs 실행 모델 불일치 < 5% |

**4. Circuit breaker 설계 제안 (hooks 무한 루프 방지):**

```
hooks 실행 카운터:
  - 세션당 hooks 실행 횟수를 카운트
  - threshold_warning = 20회 (standard 경고 삽입)
  - threshold_critical = 50회 (강제 중단 + 에스컬레이션)

동일 파일 반복 수정 감지:
  - 동일 파일에 대한 Write/Edit 이벤트가 5회 연속 발생하면 hooks 잠정 중단
  - "이 파일의 수정을 중단하고, 현재까지의 변경사항을 보고하세요" 메시지 삽입
```

이 circuit breaker 로직은 hooks 스크립트 내부에 구현하며, settings.json과는 독립적으로 동작합니다.

---

### 로키 (DA) -- [반드시 공격적 비평]

**1. "환경 변수 킬 스위치"에 대한 공격:**

헤르메스가 모든 항목에 환경 변수 기반 킬 스위치를 제안했는데, **이것 자체가 위험입니다.**

**공격 1: 환경 변수는 "발견하기 어려운 설정"입니다.**

6개 항목에 각각 환경 변수 킬 스위치를 두면 `DISCLOSURE_OVERRIDE`, `WORKTREE_READONLY_DISABLE`, `AB_TEST_ACTIVE`, `TRUST_SUMMARY_ENABLED`, `MODEL_MAP_ENABLED` -- 이미 5개입니다. **이 환경 변수들이 어디에 문서화되어 있습니까?** `.env` 파일에 있으면 git에 커밋되지 않으므로 다른 팀원은 모릅니다. 환경 변수에 있으면 서버 재시작 시 초기화됩니다. 3개월 후 누군가 `DISCLOSURE_OVERRIDE=full`이 왜 설정되어 있는지 모르고 제거하면, 이미 해결했던 문제가 재발합니다.

**대안**: 환경 변수 대신 **`settings.json`에 `feature_flags` 섹션을 추가**합니다. 이것은 git으로 추적되고, 코드 리뷰를 거치며, 변경 이력이 남습니다.

```json
{
  "feature_flags": {
    "progressive_disclosure": true,
    "worktree_readonly": true,
    "hooks_enabled": true,
    "ab_test_haiku": false,
    "trust_summary": true,
    "model_map": true
  }
}
```

**공격 2: "Progressive Disclosure가 스킬 트리거를 놓치면?"에 대한 fallback이 불충분합니다.**

오딘이 "필요한 정보가 부족하면 DIRECT-WORKFLOW.md를 Read하세요" fallback을 제안했습니다. 이것은 **에이전트의 "자율적 판단 능력"에 의존하는 fallback**입니다. Progressive Disclosure의 원래 목적이 "불필요한 정보를 줄이는 것"인데, fallback이 "에이전트가 필요한 정보를 스스로 판단하여 가져오라"라면 **에이전트가 정보의 필요성을 판단하는 능력이 정보를 직접 제공하는 것보다 나아야 합니다.** Lv.1 수준의 단순 작업을 할 에이전트가 "내가 뭘 모르는지"를 아는 것은 비현실적입니다.

**대안**: summary 모드에서도 **"CRITICAL 정보 최소 셋"을 하드코딩으로 항상 포함**합니다. "알아서 가져와라"가 아니라 "이것만은 반드시 줄게"입니다. CRITICAL 셋:
- 금지 행위 목록 (5줄)
- QC 의무 (2줄)
- 보고 형식 (3줄)

토큰 비용: +100 토큰. summary 모드의 ~500 토큰에 +100은 20% 증가이지만, 안전성 확보에 필수적입니다.

**공격 3: hooks 무한 루프의 "circuit breaker"가 너무 느슨합니다.**

마아트가 `threshold_critical = 50회`를 제안했는데, **50회면 이미 늦습니다.** 에이전트의 평균 Write/Edit 횟수가 작업당 10-20회라고 하면, 50회의 hooks 실행은 정상 작업의 2.5-5배입니다. 그 동안 에이전트는 이미 코드를 수십 번 수정했고, 원본 복구가 어렵습니다.

**대안**:
- `threshold_warning = 10회` (현재 20 → 10으로 하향)
- `threshold_critical = 20회` (현재 50 → 20으로 하향)
- **추가**: 동일 에러 코드가 3회 연속 발생하면 즉시 중단. "같은 에러를 3번 연속 못 고치면 더 시도해봐야 의미 없다"는 원칙.

**공격 4: haiku A/B 테스트의 최악 시나리오가 "발견 후 재검증" 인데, 재검증 비용을 계산했습니까?**

헤르메스가 "haiku가 통과시킨 산출물 n건을 재검증"이라고 했는데, n이 얼마나 되는지 추정합시다. 4주 테스트, 주 5일, 일 평균 10건 QC라고 하면 200건 중 50%가 haiku 그룹이므로 100건. **100건을 sonnet으로 재검증하는 비용 = 약 $50-100.** 이것이 haiku 전용화로 절약하는 비용과 비교해서 어떻습니까?

haiku QC 1건 비용 ~$0.01, sonnet QC 1건 비용 ~$0.10. 연간 QC 건수 5,000건이라면:
- haiku 전용화 절약: 5,000 * ($0.10 - $0.01) = $450/년
- 최악 시나리오 재검증 비용: $50-100 (일회성)

**ROI는 양수입니다. 최악 시나리오에서도 손실이 제한적이라는 점은 인정합니다.** 하지만 비용이 아니라 **품질 위험**이 진짜 문제입니다. 재검증에서 심각한 결함이 발견되면 해당 산출물을 재작업해야 하고, 그 비용은 별도입니다.

**공격 5: MODEL_MAP의 "stale model map" 경고가 30일이면 너무 느립니다.**

Anthropic이 모델을 업데이트하면 당일에 반영해야 합니다. 30일 방치는 **한 달 동안 잘못된 모델 가이드가 프롬프트에 삽입된다는 뜻**입니다. MODEL_MAP에 `last_updated` 필드를 추가하고, Anthropic의 모델 릴리스를 모니터링하는 자동 알림을 만들거나, **MODEL_MAP 자체를 하드코딩하지 말고 API에서 가용 모델 목록을 동적 조회하는 방식**을 검토해야 합니다.

**2. 내 결론:**
- 환경 변수 킬 스위치 → `settings.json` feature_flags로 대체
- Progressive Disclosure fallback → CRITICAL 정보 최소 셋 하드코딩
- hooks circuit breaker → 임계값을 10/20으로 하향 + 동일 에러 3회 즉시 중단
- haiku A/B → 최악 시나리오의 비용 위험은 낮지만, 품질 위험은 별도 관리 필요
- MODEL_MAP staleness → 30일 → 7일로 단축, 동적 조회 검토

---

### 프로메테우스 (전략)

**1. 위험 요소 종합 -- 전략적 판단:**

6개 항목의 위험을 "영향 범위 x 발생 확률"로 매트릭스화합니다.

**위험 매트릭스:**

```
            발생 확률
            낮음         중간         높음
영향  높음  | MODEL_MAP  | Disclosure | hooks루프  |
범위  중간  | TRUST 매핑 | haiku FNR  | 격리실패   |
      낮음  |            |            |            |
```

**최고 우선 대응**: hooks 무한 루프 (높은 확률 x 높은 영향)
**차순위 대응**: 읽기/쓰기 격리 실패 (높은 확률 x 중간 영향), Progressive Disclosure 정보 부족 (중간 확률 x 높은 영향)

**2. 로키 비평에 대한 전략적 판단:**

**"환경 변수 vs feature_flags"**: 로키의 `settings.json` feature_flags 제안에 **동의**합니다. 환경 변수는 추적 불가. feature_flags는 git 이력에 남으므로 "누가 언제 왜 비활성화했는지"를 추적할 수 있습니다. 다만, settings.json은 이미 Claude Code가 읽는 설정이므로, `feature_flags` 키가 Claude Code의 JSON 스키마와 충돌하지 않는지 확인 필요합니다. 충돌 가능성이 있다면 **별도 파일 `.claude/feature_flags.json`으로 분리**합니다.

**"CRITICAL 정보 최소 셋"**: 로키의 제안에 **동의**합니다. summary 모드에서 +100 토큰은 수용 가능. 500 → 600 토큰으로 summary 모드 재정의합니다.

**"circuit breaker 임계값"**: 로키의 10/20 제안에 **부분 동의**합니다. 10회 warning은 정상 작업(파일 10-20개 수정)에서도 트리거될 수 있어 false alarm이 많을 것입니다. **15/30으로 절충**합니다. 동일 에러 3회 즉시 중단에는 **완전 동의**합니다.

**"MODEL_MAP 동적 조회"**: 현 단계에서 과도합니다. Anthropic API 호출을 build_prompt() 내에서 하면 프롬프트 생성 지연이 발생합니다. **7일 staleness 경고 + 수동 업데이트**가 현실적입니다. 동적 조회는 P4 이후 검토.

**3. 롤백 계획 종합 -- 레이어별 구조화:**

모든 항목의 롤백을 **3-Layer 구조**로 표준화합니다:

```
Layer 1 -- Feature Flag 비활성화 (즉시, 0분)
  settings.json 또는 feature_flags.json 수정
  코드 변경 없이 기능 비활성화

Layer 2 -- 설정 롤백 (빠름, 5-10분)
  settings.json의 hooks/permissions 섹션 원복
  WORKFLOW.md 관련 섹션 삭제

Layer 3 -- 코드 롤백 (완전, 30분)
  git revert로 관련 커밋 전체 복구
  team_prompts.py, dispatch.py, qc_verify.py 원복
```

**각 항목별 롤백 레이어:**

| 항목 | Layer 1 (Flag) | Layer 2 (설정) | Layer 3 (코드) |
|---|---|---|---|
| (1) Disclosure | `progressive_disclosure=false` | - | `git revert` disclosure 커밋 |
| (2) R/W 격리 | `worktree_readonly=false` | WORKFLOW 섹션 5 삭제 | `git revert` 격리 커밋 |
| (7) hooks | `hooks_enabled=false` | settings.json hooks 삭제 | hooks 스크립트 삭제 |
| (3) haiku A/B | `ab_test_haiku=false` | MODEL_MAP["qc_verify"] 복구 | A/B 스크립트 삭제 |
| (4) TRUST 5 | `trust_summary=false` | - | `git revert` TRUST 커밋 |
| (5) MODEL_MAP | `model_map=false` | - | MODEL_MAP 상수 삭제 |

**4. "CRITICAL 정보 최소 셋" 확정안:**

summary 모드에서 항상 인라인 삽입하는 CRITICAL 정보:

```
## CRITICAL (생략 불가)
- 금지: git push/merge/rebase, 파일 삭제(rm -rf), 다른 팀 파일 수정
- QC: 작업 완료 전 반드시 qc_verify.py 실행
- 보고: .done 파일 생성 필수, 형식은 DIRECT-WORKFLOW.md 참조
```

토큰: ~80 토큰. summary 모드 총 ~580 토큰.

---

## 3 Whys 검증

### 킬 스위치 메커니즘
**Why 1**: 왜 킬 스위치가 필요한가? -> 새 기능이 예상치 못한 문제를 일으킬 때 코드 롤백 없이 즉시 비활성화하기 위해
**Why 2**: 환경 변수 vs feature_flags 중 왜 feature_flags인가? -> 환경 변수는 git 추적 불가, 팀원 간 공유 안 됨, 서버 재시작 시 초기화 위험. feature_flags.json은 git 추적 가능
**Why 3**: feature_flags가 과도한 엔지니어링이 아닌가? -> 6개 항목 x 3개 레이어 = 18개 롤백 경로. 중앙 관리 없이는 어떤 기능이 활성/비활성인지 추적 불가. 단일 JSON 파일로 관리하는 것이 최소 비용

### hooks circuit breaker
**Why 1**: 왜 circuit breaker가 필요한가? -> hooks가 에이전트에게 수정을 지시하고, 수정이 hooks를 재트리거하는 무한 루프를 방지
**Why 2**: 임계값을 얼마로 설정해야 하나? -> 정상 작업의 Write/Edit 횟수(10-20회)보다 충분히 높되, 피해가 커지기 전에 중단. 15회 warning, 30회 critical이 절충점
**Why 3**: 동일 에러 3회 즉시 중단이 너무 엄격하지 않은가? -> 아니오. 동일 에러를 3번 연속 못 고치면 에이전트가 해결 능력이 없다는 신호. 더 시도해도 결과가 같음

### Progressive Disclosure CRITICAL 셋
**Why 1**: 왜 summary 모드에서 CRITICAL 정보를 하드코딩하나? -> 에이전트의 "자율적 정보 획득" 능력에 의존하면 Lv.1 작업에서 실패 확률이 높음
**Why 2**: +80 토큰이 summary 모드의 취지와 모순되지 않나? -> summary 500 → 580 토큰은 16% 증가. full 3,000 토큰 대비 여전히 80% 절감. 취지 훼손은 미미
**Why 3**: CRITICAL 셋의 내용은 어떻게 확정하나? -> "이것이 없으면 금지 행위 위반이 발생하는가?"를 기준으로 선정. 금지 행위, QC 의무, 보고 형식이 최소 셋

---

## 합의 사항

### 1. 킬 스위치 메커니즘
- **환경 변수 방식 폐기**, `.claude/feature_flags.json` 파일로 통일
- 6개 항목 각각에 boolean 플래그 할당
- feature_flags.json은 git 추적 대상, 변경 시 커밋 메시지에 사유 기재 의무
- settings.json과의 충돌 방지를 위해 별도 파일로 분리

### 2. 3-Layer 롤백 구조
- **Layer 1 (Feature Flag)**: 즉시(0분). feature_flags.json 수정. 코드 변경 없음
- **Layer 2 (설정 롤백)**: 빠름(5-10분). settings.json, WORKFLOW.md 관련 부분 원복
- **Layer 3 (코드 롤백)**: 완전(30분). git revert로 관련 커밋 전체 복구
- 각 항목별 Layer 1/2/3 구체적 절차는 상기 프로메테우스 제안안 합의

### 3. Progressive Disclosure -- CRITICAL 최소 셋
- summary 모드에서 항상 인라인 삽입하는 정보: 금지 행위(5줄), QC 의무(2줄), 보고 형식(3줄)
- 토큰 비용: ~80 토큰 추가. summary 모드 총 ~580 토큰
- fallback: "정보 부족 시 DIRECT-WORKFLOW.md를 Read하세요" 지시도 병행

### 4. hooks circuit breaker
- **세션당 hooks 실행 횟수**: warning=15회, critical=30회 (절충안)
- **동일 에러 3회 연속 즉시 중단** (만장일치 합의)
- **동일 파일 5회 연속 수정 시 hooks 잠정 중단** (마아트 원안 유지)
- circuit breaker 로직은 hooks 스크립트 내부 구현, settings.json과 독립

### 5. haiku A/B 테스트 안전장치
- A/B 테스트 중 haiku 그룹 산출물을 **주 1회 sonnet 재검증** (FNR 실시간 추적)
- haiku 패스율이 sonnet 대비 30% 이상 높으면 조기 종료 검토
- `ab_test_haiku=false` 플래그로 즉시 종료 가능

### 6. MODEL_MAP staleness 관리
- staleness 경고: 30일 → **7일로 단축** (로키 제안 수용)
- 동적 API 조회는 현 단계 불채택. P4 이후 재검토
- MODEL_MAP에 `_last_updated: "YYYY-MM-DD"` 주석 추가

### 7. 품질 게이트 기준
| 항목 | 게이트 | 기준 |
|---|---|---|
| (1) Progressive Disclosure | summary QC 패스율 | >= full * 0.85 |
| (2) 읽기/쓰기 격리 | 격리 정확도 | read-only 파일변경 0건/100건 |
| (7) hooks | False Positive Rate | < 10% |
| (3) haiku A/B | False Negative Rate | < 15% |
| (4) TRUST 5 | 매핑 불일치율 | < 3% |
| (5) MODEL_MAP | 모델 불일치율 | < 5% |

---

## 미해결 이슈

1. **feature_flags.json 스키마 정의**: 6개 플래그 외에 향후 확장(P3/P4 항목)을 위한 구조. 플래그 네이밍 컨벤션 -- 담당: 헤르메스
2. **settings.json과 feature_flags.json의 로딩 우선순위**: 동일 키가 양쪽에 있으면 어느 것이 우선하는가. Claude Code가 feature_flags.json을 인식하는가 -- 담당: 헤르메스
3. **circuit breaker의 "동일 에러" 판정 기준**: pyright 에러 코드 기준인지, 에러 메시지 전체 일치인지, 파일+라인 기준인지 -- 담당: 마아트
4. **CRITICAL 최소 셋의 내용 최종 확정**: 현재 초안(금지 행위/QC 의무/보고 형식)의 구체적 문구. 특히 금지 행위 5줄의 정확한 내용 -- 담당: 오딘
5. **haiku 재검증 비용 예산 확보**: 주 1회 sonnet 재검증의 4주간 추가 비용(추정 $20-40) 승인 -- 담당: 프로메테우스
6. **hooks 스크립트 내 circuit breaker 구현 위치**: 기존 hooks 스크립트에 추가할지, 별도 wrapper 스크립트를 만들지 -- 담당: 헤르메스
7. **MODEL_MAP `_last_updated` 필드의 자동 경고 구현**: 7일 초과 시 경고를 누가, 어디서, 어떻게 발생시키는가 -- 담당: 헤르메스 + 마아트