# task-1285.1 미팅 Cycle 1
날짜: 2026-03-31
안건: MoAI-ADK 10개 도입 항목 전체 초기 평가

---

## 참석자 발언

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

**1. Progressive Disclosure 스킬 로딩 (P1)**
- 실현 가능성: **상** — system-reminder에 80+ 스킬을 전부 나열하는 현재 구조는 team_prompts.py의 build_prompt()에서 주입한다. frontmatter 축약은 YAML 메타데이터만 넣고 Skill tool 호출 시점에 전체 본문을 로드하는 방식으로 전환 가능하다.
- 예상 효과: **상** — 현재 system-reminder의 스킬 나열만으로 수천 토큰을 소비한다. Level 1(~100토큰)으로 축약하면 초기 컨텍스트를 70~80% 절감할 수 있다.
- 위험 요소: 스킬 트리거 정확도 하락. frontmatter만으로 매칭이 안 되면 스킬이 호출되지 않는 사일런트 미스 발생 가능.
- P1 동의: **동의**

**2. 읽기/쓰기 에이전트 격리 분리 (P1)**
- 실현 가능성: **상** — worktree_manager.py의 create 명령을 조건부로 호출하면 된다. dispatch.py에서 에이전트 타입(리서치/코딩)에 따라 분기하는 로직 추가는 20줄 미만.
- 예상 효과: **중** — 리서치 에이전트의 worktree 생성/정리 오버헤드(git checkout + 파일 복사) 제거. 체감 속도 개선.
- 위험 요소: 리서치 에이전트가 실수로 메인 트리에 쓰기를 시도하는 경우 보호 장치 부재.
- P1 동의: **동의**

**3. 검증 작업 haiku 전용화 (P1)**
- 실현 가능성: **상** — DIRECT-WORKFLOW.md의 모델 선택 가이드에 이미 haiku 경로가 있다. team_prompts.py에서 QC/lint/git 작업의 기본 모델을 haiku로 하드코딩하면 된다.
- 예상 효과: **상** — QC 작업은 단순 규칙 기반이라 haiku로 충분하며, Sonnet/Opus 대비 비용 90%+ 절감.
- 위험 요소: haiku의 복잡한 코드 리뷰 능력 한계. 미묘한 로직 버그를 놓칠 수 있다.
- P1 동의: **동의**

**4. TRUST 5 기반 QC-RULES.md 구조화 (P2)**
- 실현 가능성: **중** — QC-RULES.md v3.0의 기존 구조(셀프QC/Agency-Agents 원칙/이슈 처리)를 TRUST 5차원으로 재편하려면 마아트와의 긴밀한 협의가 필요.
- 예상 효과: **중** — 구조화 자체는 좋지만, 현장 적용 시 에이전트가 5차원을 전부 점검하면 오히려 QC 시간이 증가할 수 있다.
- 위험 요소: 기존 QC-RULES.md v3.0과의 호환성 파괴. 전환 기간 동안 QC 기준 혼란.
- P2 동의: **동의**

**5. 에이전트별 모델 매핑 테이블 (P2)**
- 실현 가능성: **상** — team_prompts.py의 TEAM_INFO에 model 필드를 추가하고 dispatch.py에서 참조하면 된다.
- 예상 효과: **중** — 현재도 DIRECT-WORKFLOW.md에 가이드가 있지만, 프로그래매틱하게 강제하면 실수 방지.
- 위험 요소: 모델 매핑이 하드코딩되면 상황별 유연한 모델 전환이 어려워진다.
- P2 동의: **동의**

**6. @MX 태그 시스템 (P3)**
- 실현 가능성: **중** — 코드에 주석 태그를 추가하는 것은 쉽지만, 태그를 자동으로 탐지하고 활용하는 인프라가 필요하다.
- 예상 효과: **하** — 에이전트가 태그를 일관되게 읽고 반응하려면 별도 파서가 필요. 초기에는 장식용이 될 가능성 높다.
- 위험 요소: 태그 남발로 코드 노이즈 증가. 유지보수 비용이 편익을 초과할 수 있다.
- P3 동의: **P4로 하향 제안** — 인프라 의존도가 높아서 파일럿보다는 장기 검토가 적합.

**7. Claude Code hooks 자동 강제 (P3)**
- 실현 가능성: **상** — Claude Code의 PostToolUse 훅은 settings.json에 설정 가능. pyright/ruff 체크를 훅으로 걸면 매 코드 수정 후 자동 실행된다.
- 예상 효과: **상** — 현재 수동 QC 단계에서 잡는 린트/타입 에러를 즉시 피드백하면 QC 반복 횟수가 줄어든다.
- 위험 요소: 훅 실행 시간이 길어지면 에이전트 응답 지연. pyright가 대형 프로젝트에서 10초+ 걸리는 경우 존재.
- P3 동의: **P2로 상향 제안** — 비용 대비 효과가 크고 구현이 간단하다.

**8. Context Search Protocol (P4)**
- 실현 가능성: **하** — 이전 보고서 검색/주입은 벡터 DB나 인덱싱 인프라가 필요. 현재 파일 시스템 기반 memory/ 구조로는 한계.
- 예상 효과: **상** — 장기적으로 에이전트가 과거 컨텍스트를 자동 참조하면 반복 작업이 크게 줄어든다.
- 위험 요소: 잘못된 컨텍스트 주입(hallucination amplification). 오래된 보고서의 deprecated 정보가 주입되면 역효과.
- P4 동의: **동의**

**9. Agent Teams API 전환 (P4)**
- 실현 가능성: **중** — dispatch.py의 cokacdir --cron 기반 위임 구조를 공식 API로 전환하려면 API 안정성 확인이 선행되어야 한다.
- 예상 효과: **상** — 공식 API가 안정화되면 커스텀 dispatch 로직을 대폭 줄일 수 있다.
- 위험 요소: API 변경에 따른 종속성. Anthropic 측 API 변경 시 전면 수정 필요.
- P4 동의: **동의**

**10. "에이전트도 사용자다" 설계 (P4)**
- 실현 가능성: **중** — 프롬프트/보고서/task 파일 구조를 에이전트 친화적으로 재설계하는 것은 점진적으로 가능.
- 예상 효과: **중** — 에이전트가 파싱하기 쉬운 구조화된 파일은 오류를 줄이지만, 즉각적 효과는 제한적.
- 위험 요소: 인간 가독성과 에이전트 가독성 사이의 트레이드오프.
- P4 동의: **동의**

---

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

**1. Progressive Disclosure 스킬 로딩 (P1)**
- 실현 가능성: **상** — 현재 system-reminder에 80+ 스킬이 전문 나열되는 것은 워크플로우 관점에서 가장 큰 비효율이다. 스킬 메타데이터를 YAML frontmatter(이름, 트리거 조건, 한줄 설명)로 축약하면 에이전트가 관련 스킬만 선별적으로 로드할 수 있다.
- 예상 효과: **상** — 첫 턴 컨텍스트 축소로 실질적인 작업 가용 토큰이 증가. 스킬 선택 정확도도 오히려 올라갈 수 있다(노이즈 감소).
- 위험 요소: Level 1 메타데이터의 트리거 키워드가 불충분하면 스킬 발견율(discoverability)이 하락한다.
- P1 동의: **동의**

**2. 읽기/쓰기 에이전트 격리 분리 (P1)**
- 실현 가능성: **상** — Task tool 호출 시 subagent의 permissionMode를 plan(읽기전용) vs default(쓰기)로 분기하는 것은 워크플로우 레벨에서 자연스럽다.
- 예상 효과: **상** — 리서치 에이전트의 worktree 생성 대기 시간(평균 3-5초)을 제거하고, 불필요한 브랜치 생성도 방지.
- 위험 요소: "읽기전용이라고 생각했는데 실제로는 쓰기가 필요한" 에지 케이스. 에이전트 분류 기준이 모호하면 재분류 비용 발생.
- P1 동의: **동의**

**3. 검증 작업 haiku 전용화 (P1)**
- 실현 가능성: **상** — 워크플로우 관점에서 QC/lint 작업을 haiku 전용 경로로 분리하는 것은 model 파라미터 하나만 바꾸면 된다.
- 예상 효과: **상** — 비용 절감이 명확. QC 빈도가 높을수록(작업당 2-3회 QC) 절감 효과 극대화.
- 위험 요소: haiku의 컨텍스트 윈도우 제한으로 대형 파일의 QC가 불완전해질 수 있다.
- P1 동의: **동의**

**4. TRUST 5 기반 QC-RULES.md 구조화 (P2)**
- 실현 가능성: **중** — 5차원 프레임워크 자체는 좋지만, 현재 QC-RULES.md v3.0의 Agency-Agents 원칙과 TRUST 5의 매핑이 명확하지 않다.
- 예상 효과: **중** — QC 품질의 일관성은 높아지나, 에이전트가 5차원을 모두 체크하는 시간 비용 증가.
- 위험 요소: 과도한 구조화가 오히려 QC 병목을 만들 수 있다.
- P2 동의: **동의**

**5. 에이전트별 모델 매핑 테이블 (P2)**
- 실현 가능성: **상** — TEAM_INFO dict에 default_model 필드 추가로 해결.
- 예상 효과: **중** — 모델 선택 실수 방지.
- 위험 요소: 오버라이드 메커니즘이 없으면 특수 상황 대처 불가.
- P2 동의: **동의**

**6. @MX 태그 시스템 (P3)**
- 실현 가능성: **하** — 에이전트가 코드를 읽을 때 @MX 태그를 인식하고 행동을 변경하려면 프롬프트 수준의 지원이 필요. 단순 주석 태깅만으로는 워크플로우에 통합이 안 된다.
- 예상 효과: **하** — 인간 개발자용 태깅 시스템과 에이전트용 태깅 시스템은 다르다. 에이전트에게는 구조화된 JSON/YAML이 더 효과적.
- 위험 요소: 태깅 규칙 비준수. 에이전트가 태그를 무시하거나 잘못 생성하는 경우.
- P3 동의: **P4로 하향 제안** — 실효성이 검증되지 않았다.

**7. Claude Code hooks 자동 강제 (P3)**
- 실현 가능성: **상** — settings.json의 hooks 설정으로 즉시 가능.
- 예상 효과: **상** — 코딩 에이전트의 품질 피드백 루프가 즉각적으로 단축된다.
- 위험 요소: false positive 경고가 많으면 에이전트가 불필요한 수정 루프에 빠진다.
- P3 동의: **P2로 상향 동의** (헤르메스 의견에 동의)

**8. Context Search Protocol (P4)**
- 실현 가능성: **하** — 인프라 의존도 높음.
- 예상 효과: **상** — 장기 가치는 매우 높다.
- 위험 요소: 검색 결과의 관련성 보장이 어렵다.
- P4 동의: **동의**

**9. Agent Teams API 전환 (P4)**
- 실현 가능성: **중** — API 안정성이 관건.
- 예상 효과: **상** — dispatch.py 복잡도를 대폭 줄일 수 있다.
- 위험 요소: 현재 dispatch.py의 커스텀 기능(redact, injection_guard, approval)을 API로 이식하기 어려울 수 있다.
- P4 동의: **동의**

**10. "에이전트도 사용자다" 설계 (P4)**
- 실현 가능성: **중**
- 예상 효과: **중**
- 위험 요소: 대규모 파일 구조 변경 시 기존 워크플로우 호환성 파괴.
- P4 동의: **동의**

---

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

**1. Progressive Disclosure 스킬 로딩 (P1)**
- 실현 가능성: **상**
- 예상 효과: **상** — 품질 관점에서 컨텍스트 여유가 생기면 QC 정밀도가 올라간다. 현재 80+ 스킬이 컨텍스트를 압박해서 QC 체크리스트를 생략하는 경향이 관찰된다.
- 위험 요소: 스킬 누락으로 인한 QC 프로세스 스킵. 예를 들어 verification-before-completion 스킬이 로드되지 않으면 .done 파일 검증이 빠질 수 있다.
- P1 동의: **동의** (단, QC 관련 스킬은 항상 Level 2로 프리로드되어야 한다는 조건)

**2. 읽기/쓰기 에이전트 격리 분리 (P1)**
- 실현 가능성: **상**
- 예상 효과: **중** — 리서치 에이전트가 코드를 변경하지 않으니 QC 대상에서 제외 가능. QC 범위가 명확해진다.
- 위험 요소: 리서치 에이전트의 출력물(보고서)에 대한 품질 검증 기준이 별도로 필요하다.
- P1 동의: **동의**

**3. 검증 작업 haiku 전용화 (P1)**
- 실현 가능성: **상**
- 예상 효과: **중** — 비용 절감은 확실하나, **QC 품질 저하 리스크를 반드시 측정해야 한다.** haiku가 현재 Sonnet으로 수행하는 QC와 동등한 품질을 내는지 A/B 테스트가 선행되어야 한다.
- 위험 요소: **가장 우려되는 항목.** QC는 비용 절감이 아니라 품질 보장이 목적이다. haiku로 전환 후 놓치는 버그가 1건이라도 있으면 절감한 비용보다 디버깅 비용이 더 크다.
- P1 동의: **조건부 동의** — haiku 전환 전 최소 20건의 과거 QC 케이스를 haiku로 재실행하여 탐지율을 비교해야 한다.

**4. TRUST 5 기반 QC-RULES.md 구조화 (P2)**
- 실현 가능성: **상** — QC 담당자로서 직접 주도 가능. 현재 QC-RULES.md v3.0의 체크리스트를 TRUST 5차원으로 재분류하는 매핑 작업은 이미 머릿속에 있다.
  - Tested: 1-A 체크리스트 5번 (테스트 커버리지)
  - Readable: 코드 아키텍처 원칙 7번
  - Unified: 인터페이스 일관성 8번
  - Secured: 에러 처리/보안 4번
  - Trackable: 이슈 처리 규칙 1-D
- 예상 효과: **상** — 구조화된 프레임워크는 QC 일관성을 보장한다. 현재 "기본값 NEEDS WORK" 원칙이 잘 작동하고 있으나, TRUST 5로 점수화하면 더 정량적인 판단이 가능하다.
- 위험 요소: 전환 기간 동안 v3.0과 TRUST 5가 공존하면 혼란 발생.
- P2 동의: **동의** (적극 추진 의향)

**5. 에이전트별 모델 매핑 테이블 (P2)**
- 실현 가능성: **상**
- 예상 효과: **중**
- 위험 요소: QC 에이전트의 모델이 고정되면 복잡한 코드 리뷰 시 모델 업그레이드가 어렵다.
- P2 동의: **동의**

**6. @MX 태그 시스템 (P3)**
- 실현 가능성: **중**
- 예상 효과: **중** — ANCHOR 태그가 fan_in>=3인 모듈을 표시하면 QC 시 해당 모듈 변경에 대해 영향도 분석을 강화할 수 있다. WARN 태그로 복잡도 높은 함수를 표시하면 QC 집중 대상을 식별하는 데 도움.
- 위험 요소: 태그가 outdated되면 오히려 잘못된 QC 판단을 유도한다.
- P3 동의: **동의** (QC 활용 가치가 있다고 판단)

**7. Claude Code hooks 자동 강제 (P3)**
- 실현 가능성: **상**
- 예상 효과: **상** — PostToolUse 훅으로 pyright/ruff를 자동 실행하면, 현재 QC 단계에서 잡는 린트 에러의 80%를 코딩 단계에서 미리 잡을 수 있다. QC 부담이 크게 줄어든다.
- 위험 요소: 훅이 너무 엄격하면 에이전트가 작업을 진행하지 못하고 무한 수정 루프에 빠진다.
- P3 동의: **P2로 상향 동의**

**8~10. (P4 항목)** — 전반적으로 동의. 장기 과제로 적합.

---

### 로키 (DA)

**[전체 평가 — 공격적 비평]**

이 10개 항목 목록 자체부터 문제가 있다. **"MoAI-ADK 도입"이라는 거창한 이름을 붙였지만, 실제로 P1 3건은 "토큰 절약"과 "비용 절감"이라는 단일 축으로 수렴한다.** 전략적 다양성이 없다. 비용 최적화만 3건 동시에 밀면, 하나라도 실패했을 때 "비용 절감 프로젝트 전체가 실패했다"는 내러티브가 만들어진다.

**1. Progressive Disclosure 스킬 로딩 (P1)**
- 실현 가능성: **중** — 모두가 "상"이라고 했지만, **실제 구현 난이도를 과소평가하고 있다.** 현재 system-reminder에 스킬이 나열되는 이유는 Claude Code 하네스가 그렇게 설계되었기 때문이다. 우리가 haneess의 스킬 로딩 메커니즘을 직접 수정할 수 있는가? `system-reminder`는 Claude Code의 내부 메커니즘이지, team_prompts.py가 제어하는 영역이 아닌 스킬이 다수다.
- 예상 효과: **중** — 토큰 절감 수치를 아무도 측정하지 않았다. "70~80% 절감"이라는 숫자의 근거는? 현재 system-reminder에서 스킬이 차지하는 토큰 비율을 정확히 측정한 사람이 있는가?
- 위험 요소: **스킬 미발견으로 인한 사일런트 실패.** 에이전트가 "적절한 스킬이 있었는데 트리거가 안 되어서 수동으로 코드를 작성했다"는 상황이 발생하면, 그걸 누가 탐지하는가? 사일런트 실패는 로그에 남지 않는다.
- P1 동의: **조건부 반대** — 토큰 절감 수치를 정량적으로 측정한 후에 진행해야 한다. "느낌"으로 P1에 넣으면 안 된다.

**2. 읽기/쓰기 에이전트 격리 분리 (P1)**
- 실현 가능성: **중** — "20줄 미만"이라는 헤르메스의 말은 **행복한 경로(happy path)만 고려한 것이다.** 리서치 에이전트가 "읽기만 한다"는 가정이 항상 유효한가? 리서치 도중 메모를 남기거나, 중간 결과를 임시 파일에 저장하는 경우는? permissionMode:plan이 파일 쓰기를 완전히 차단하는가? 아니면 특정 디렉토리만 허용하는가?
- 예상 효과: **중**
- 위험 요소: **읽기 에이전트의 범위 크립(scope creep).** 처음에는 "리서치만"이었던 에이전트가 점점 "분석 결과 저장", "보고서 생성"으로 확장되면, 결국 다시 worktree가 필요해진다. 분류 기준의 경계가 모호하다.
- P1 동의: **조건부 동의** — 읽기/쓰기 분류 기준을 명확히 문서화한 후에만 진행.

**3. 검증 작업 haiku 전용화 (P1)**
- 실현 가능성: **상**
- 예상 효과: **하** — **이건 내가 가장 강하게 반대하는 항목이다.** 마아트가 조건부 동의한 이유와 같다. QC를 haiku에 맡기는 것은 **"경비원을 알바생으로 교체하면 인건비가 줄어든다"와 같은 논리다.** 절감 비용은 보이지만, 놓친 버그로 인한 디버깅 비용은 보이지 않는다. 현재 QC-RULES.md v3.0의 "기본값 NEEDS WORK" 원칙은 haiku가 판단하기에 너무 복잡한 맥락적 판단을 요구한다.
- 위험 요소: **품질 저하의 비가시성.** haiku가 놓친 버그는 "QC PASS"로 기록된다. 그 버그가 프로덕션에서 터지기 전까지 아무도 모른다. 즉, **메트릭스상으로는 QC 통과율이 올라가지만 실제 품질은 떨어지는 기만적 개선이 발생한다.**
- P1 동의: **반대** — 최소한 P2로 하향하고, A/B 테스트 결과가 나온 후에 적용해야 한다.

**4. TRUST 5 기반 QC-RULES.md 구조화 (P2)**
- 위험 요소: TRUST 5라는 프레임워크 자체가 검증되지 않았다. **누가 만든 프레임워크인가? 다른 조직에서 사용 사례가 있는가?** 자체 제작 프레임워크를 QC의 근간으로 삼으면, 프레임워크 자체의 결함이 QC 전체를 오염시킨다.
- P2 동의: **조건부 동의** — TRUST 5의 각 차원이 독립적인지(겹치지 않는지) 검증해야 한다.

**5. 에이전트별 모델 매핑 테이블 (P2)**
- 위험 요소: 하드코딩은 유연성의 적이다. 오버라이드 없는 하드코딩은 3개월 후 기술부채가 된다.
- P2 동의: **동의** (오버라이드 메커니즘 포함 조건)

**6. @MX 태그 시스템 (P3)**
- 위험 요소: **에이전트가 태그를 "생성"하는 것과 "준수"하는 것은 완전히 다른 문제다.** 에이전트가 ANCHOR 태그를 달아도, 다음 에이전트가 그 파일을 수정할 때 태그를 무시하면? 강제 메커니즘이 없다. 주석 기반 태그는 본질적으로 advisory이지 mandatory가 아니다.
- P3 동의: **P4로 하향 동의**

**7. Claude Code hooks 자동 강제 (P3)**
- 위험 요소: **hooks가 실패할 때의 에이전트 행동이 정의되어 있지 않다.** pyright가 에러를 뱉으면 에이전트는 무엇을 하는가? 수정을 시도하다가 원래 코드를 망가뜨리면? 훅 실패 시 에이전트가 무한 수정 루프에 빠지는 것은 현실적 시나리오다.
- P3 동의: **조건부 P2** — 훅 실패 시 최대 재시도 횟수(max 3)를 반드시 설정해야 한다.

**8. Context Search Protocol (P4)**
- 위험 요소: **가장 위험한 장기 항목.** 잘못된 과거 정보를 "권위있는 컨텍스트"로 주입하면 hallucination을 증폭시킨다. 현재 memory/ 폴더에 deprecated된 정보가 얼마나 있는지 아무도 모른다.
- P4 동의: **동의** (절대 서두르면 안 된다)

**9. Agent Teams API 전환 (P4)**
- 위험 요소: **외부 의존성에 핵심 인프라를 묶는 것은 자살 행위다.** dispatch.py가 복잡한 이유는 우리의 요구사항이 복잡하기 때문이다. 공식 API가 그 복잡성을 다 커버하리라는 보장이 없다.
- P4 동의: **동의** (API가 우리 요구사항을 90%+ 커버하는 것이 확인된 후에만)

**10. "에이전트도 사용자다" 설계 (P4)**
- 위험 요소: 철학적으로는 동의하지만, **"설계"라는 단어 뒤에 구체적 산출물이 없다.** 무엇을, 어떻게 바꾸겠다는 것인지 불명확.
- P4 동의: **동의** (구체화 필요)

---

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

**전체 전략 평가**

10개 항목의 우선순위 배치는 대체로 합리적이나, 두 가지 전략적 조정이 필요하다.

**첫째, P1의 3건이 모두 "비용 최적화" 축에 집중되어 있다.** 로키의 지적에 동의한다. P1에 "품질 강화" 축의 항목이 하나는 있어야 균형이 잡힌다. Claude Code hooks(7번)를 P2에서 P1으로 올리고, 검증 haiku 전용화(3번)를 P2로 내리는 것을 제안한다. 이렇게 하면 P1이 "토큰 절감(1번) + 속도 개선(2번) + 품질 자동화(7번)"으로 3축 균형이 된다.

**둘째, 항목 간 의존성 그래프가 고려되지 않았다.**
- 1번(Progressive Disclosure) ← 5번(모델 매핑 테이블)에 영향. 스킬 로딩 방식이 바뀌면 모델 선택 로직도 조정 필요.
- 2번(격리 분리) ← 7번(hooks). 읽기 에이전트에는 hooks가 불필요. 쓰기 에이전트에만 hooks를 걸려면 격리 분리가 선행되어야 한다.
- 3번(haiku 전용화) ← 4번(TRUST 5). haiku가 TRUST 5 기준을 충족하는 QC를 수행할 수 있는지가 핵심.
- 6번(@MX 태그) ← 7번(hooks). 태그 위반 시 hooks로 경고를 주려면 두 시스템이 연동되어야 한다.

**의존성을 고려한 수정 우선순위 제안:**

| 수정 P | 항목 | 이유 |
|--------|------|------|
| P1 | 1. Progressive Disclosure | 독립적, 즉시 효과 |
| P1 | 2. 읽기/쓰기 격리 | 독립적, 즉시 효과 |
| P1 | 7. hooks 자동 강제 | 품질 축 균형, 구현 간단 |
| P2 | 3. haiku 전용화 | A/B 테스트 필요 |
| P2 | 4. TRUST 5 구조화 | QC 프레임워크 전환 |
| P2 | 5. 모델 매핑 테이블 | 1번 완료 후 진행 |
| P3 | 6. @MX 태그 | 인프라 의존 높음 |
| P4 | 8. Context Search | 인프라 대규모 구축 |
| P4 | 9. Teams API | 외부 의존성 |
| P4 | 10. 에이전트 UX 설계 | 장기 비전 |

**장기 비전:** 이 10개 항목이 모두 완료되면, 우리 시스템은 "수동 dispatch + 수동 QC" 체계에서 "자동 라우팅 + 자동 품질 강제" 체계로 전환된다. 이것이 MoAI-ADK 도입의 진짜 목표다. P1~P2의 6건이 이 전환의 기반을 닦는다.

---

## 3 Whys 검증

### Why 1: "왜 Progressive Disclosure를 P1으로 잡았는가?"
- 1차 Why: 80+ 스킬이 system-reminder를 비대하게 만들어 토큰 낭비가 심하다.
- 2차 Why: 왜 토큰 낭비가 문제인가? → Opus 토큰 비용이 높고, 컨텍스트 윈도우 압박으로 에이전트의 실질 작업 공간이 줄어든다.
- 3차 Why: 왜 작업 공간 축소가 문제인가? → 에이전트가 컨텍스트 끝부분의 지시를 무시하거나, QC 체크리스트를 생략하는 "컨텍스트 드리프트" 현상이 관찰된다. 즉, 토큰 절감은 비용 문제가 아니라 **품질 문제**이기도 하다.
- **결론: P1 타당성 확인. 단, 효과 측정을 위한 토큰 사용량 before/after 비교 필요.**

### Why 2: "왜 검증 작업을 haiku로 전환하려는가?"
- 1차 Why: QC/lint/git 작업은 단순 규칙 기반이라 haiku로 충분하다.
- 2차 Why: 왜 "단순 규칙 기반"이라고 판단하는가? → QC-RULES.md v3.0의 체크리스트가 "예/아니오"로 판단 가능한 항목 위주이기 때문.
- 3차 Why: 정말로 모든 QC가 "예/아니오"인가? → **아니다.** "Fantasy Approval 탐지", "Zero Issue = Red Flag" 같은 판단은 맥락적 추론이 필요하다. 이런 판단을 haiku에 맡기면 정확도가 떨어진다.
- **결론: 전면 haiku 전환은 위험. 린트/타입 체크는 haiku, 맥락적 코드 리뷰는 Sonnet 유지가 적절. P2로 하향하고 분리 적용 필요.**

### Why 3: "왜 hooks를 P2에서 P1으로 올려야 하는가?"
- 1차 Why: hooks가 품질 자동화의 핵심 수단이기 때문.
- 2차 Why: 왜 품질 자동화가 P1에 필요한가? → 현재 QC 단계에서 발견되는 이슈의 60%+가 린트/타입 에러다. 이걸 코딩 시점에 잡으면 QC 반복 횟수가 줄어든다.
- 3차 Why: 왜 QC 반복 감소가 중요한가? → 반복마다 Opus/Sonnet 토큰이 소비되고, 작업 완료 시간이 증가한다. hooks는 비용 절감과 품질 향상을 동시에 달성하는 유일한 항목이다.
- **결론: P1 상향 타당. 단, 훅 실패 시 최대 재시도 횟수 설정 필수.**

---

## 합의 사항

1. **P1 항목을 3건에서 재조정한다:** Progressive Disclosure(1번), 읽기/쓰기 격리(2번), hooks 자동 강제(7번)를 P1으로. 검증 haiku 전용화(3번)는 P2로 하향.
2. **검증 haiku 전용화는 A/B 테스트를 선행한다:** 최소 20건의 과거 QC 케이스를 haiku로 재실행하여 탐지율 비교 후 적용 여부 결정.
3. **@MX 태그(6번)는 P4로 하향한다:** 헤르메스, 오딘, 로키가 공통으로 P4 하향을 제안.
4. **모든 P1 항목에 대해 정량적 효과 측정 기준을 사전 정의한다:** before/after 토큰 사용량, 작업 완료 시간, QC 반복 횟수.
5. **에이전트별 모델 매핑 테이블(5번)은 오버라이드 메커니즘을 반드시 포함한다.**

---

## 미해결 이슈

1. **Progressive Disclosure의 system-reminder 제어 가능 범위:** Claude Code 하네스가 주입하는 스킬 목록을 team_prompts.py에서 어디까지 제어할 수 있는지 기술 검증 필요.
2. **읽기/쓰기 에이전트 분류 기준서:** 구체적인 분류 기준(어떤 작업이 "읽기"이고 어떤 작업이 "쓰기"인지)의 문서화 담당자 미지정.
3. **TRUST 5 프레임워크의 독립성 검증:** 5차원이 서로 겹치지 않는지(MECE) 마아트가 검증해야 하나, 일정 미합의.
4. **hooks 실패 시 에이전트 행동 프로토콜:** 최대 재시도 횟수(3회)는 합의했으나, 3회 실패 후 어떻게 처리할지(인간 에스컬레이션? 스킵? 경고 후 진행?) 미결정.
5. **haiku QC A/B 테스트 설계:** 20건 케이스의 선정 기준, 평가 지표, 판정자를 정해야 함.