# task-1285.1 미팅 Cycle 3
날짜: 2026-03-31
안건: P2 3건 심층 논의 (TRUST 5 기반 QC-RULES.md 구조화, 에이전트별 모델 매핑 테이블, 검증 작업 haiku 전용화)

## 참석자 발언

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

**P2-4. TRUST 5 기반 QC-RULES.md 구조화:**

현재 QC-RULES.md v3.5의 구조를 TRUST 5차원에 매핑하면 다음과 같습니다.

| TRUST 차원 | 현재 QC-RULES 섹션 | 매핑 근거 |
|---|---|---|
| **T**ested | 섹션 2(자동 검증, verifier 9종), 섹션 3(테스트 회귀 방지) | test_runner, tdd_check, schema_contract |
| **R**eadable | 섹션 4(Suppression 목록), 섹션 4.5(산출물 파일 표기) | 노이즈 제거 = 가독성 향상 |
| **U**nified | 섹션 1-A(기본 체크리스트 항목 7: 아키텍처 원칙), 섹션 1-C(Agency-Agents 품질 원칙) | 일관된 판정 기준 |
| **S**ecured | 섹션 5(에러 처리 원칙), 레벨 체계(normal/critical/security) | 파싱 실패 명시적 처리, 보안 레벨 |
| **T**rackable | 섹션 1-D(이슈 처리 규칙), 변경 이력 테이블 | 해결 과정 로깅 의무, 버전 추적 |

구현 방안: QC-RULES.md 자체를 TRUST 5 섹션으로 재배치하되, 기존 섹션 번호는 TRUST 차원 접두사로 대체합니다. 예: `T-1. 자동 검증`, `R-1. Suppression 목록`. 변경 이력 테이블은 하단에 유지합니다.

**P1과의 연동:** Progressive Disclosure Phase A에서 QC-RULES.md는 "요약 참조 -> 필요시 상세 Read" 패턴으로 전달됩니다. TRUST 구조화하면 Phase A 요약에 "T/R/U/S/T 각 차원 PASS 여부"만 한 줄로 전달 가능하므로 Progressive Disclosure와 잘 맞습니다.

**파일 충돌:** QC-RULES.md는 P1의 hooks 작업과 직접 충돌하지 않습니다. hooks는 `.claude/settings.json`을 수정하고, QC-RULES.md는 별도 파일입니다. 단, `_build_verification_section()`에서 QC-RULES.md 경로를 참조하므로, 파일명이 바뀌면 team_prompts.py도 수정 필요합니다. 파일명은 유지하고 내부 구조만 변경하는 것을 권장합니다.

**P2-5. 에이전트별 모델 매핑 테이블:**

현재 team_prompts.py의 TEAM_INFO dict에는 `type` 필드만 있고 모델 정보가 없습니다. 모델 매핑을 추가하는 방안은 두 가지입니다:

방안 A: TEAM_INFO에 `model_map` 필드 추가
```python
"dev1-team": {
    "leader": "헤르메스 (Hermes)",
    "role": "개발1팀장",
    "type": "direct",
    "model_map": {
        "leader": "opus",
        "backend": "sonnet",
        "frontend": "sonnet",
        "uxui": "sonnet",
        "tester": "haiku",
        "qc": "haiku",
    },
    "members": "불칸(백엔드), 이리스(프론트엔드), ...",
}
```

방안 B: 별도 상수 `MODEL_MAP` dict 생성
```python
MODEL_MAP = {
    "leader": "opus",
    "coding_general": "sonnet",
    "coding_simple": "haiku",
    "qc_verify": "sonnet",  # 현재. haiku 전용화 시 변경 대상
    "lint_style": "haiku",
    "test_run": "haiku",
}
```

방안 B를 권장합니다. 이유: 역할 기반 매핑은 팀 간 공통이므로 팀별로 중복 정의할 필요가 없습니다. 예외적으로 팀별 오버라이드가 필요하면 TEAM_INFO에 `model_overrides`를 추가하면 됩니다.

DIRECT-WORKFLOW.md의 "모델 선택 가이드" 섹션과의 충돌: 현재 DIRECT-WORKFLOW.md는 "단순->haiku, 일반->sonnet"이라는 가이드라인만 텍스트로 제시합니다. MODEL_MAP이 도입되면 DIRECT-WORKFLOW.md는 "모델 선택은 MODEL_MAP을 따르세요"로 변경하고, 구체적 매핑은 team_prompts.py에서 관리합니다. Single Source of Truth 확보.

**P2-3. 검증 작업 haiku 전용화 A/B 테스트:**

A/B 테스트 설계:
- **대상**: qc_verify.py 실행 시 내부적으로 호출하는 검증 작업 (pyright_check, style_check, scope_check 등)
- **현재 상태**: 이 verifier들은 Python 스크립트로 직접 실행되므로 모델 호출이 없습니다. 모델이 필요한 검증은 팀장이 QC-RULES.md를 읽고 수행하는 "셀프 QC" 부분입니다.
- **실제 haiku 전용화 대상**: 팀원(Task tool)으로 QC 검증을 위임할 때의 model 파라미터입니다.

따라서 A/B 테스트는 Task tool 호출 시 `model="sonnet"` vs `model="haiku"`를 비교하는 형태가 됩니다. 측정 지표: (1) QC PASS율, (2) 발견 이슈 수, (3) 토큰 비용, (4) 실행 시간.

---

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

**P2-4. TRUST 5 구조화의 워크플로우 영향:**

TRUST 구조화 시 _build_verification_section()이 참조하는 QC-RULES.md의 내부 구조가 바뀝니다. 현재 이 함수는 단순히 "QC-RULES.md를 읽고 따르세요"라는 경로 참조만 하므로 함수 자체를 수정할 필요는 없습니다. 단, TRUST 구조화를 하면 팀장 프롬프트에 "T/R/U/S/T 체크리스트 요약"을 한 줄 추가하는 것이 유용합니다.

```python
def _build_verification_section(level: str) -> str:
    return (
        f"\n\n## 보고서 작성 전 셀프 QC + 자동 검증\n"
        f"{WORKSPACE_ROOT}/teams/shared/QC-RULES.md를 읽고 따르세요.\n"
        f"- 검증 레벨: {level}\n"
        f"- TRUST 체크: Tested / Readable / Unified / Secured / Trackable 5차원 확인\n"
    )
```

이 수정은 P1 Progressive Disclosure Phase A와 직접 연동됩니다. Phase A에서는 이 한 줄 요약만 전달하고, 상세는 팀장이 QC-RULES.md를 Read하여 확인합니다.

**P2-5. 모델 매핑 테이블과 build_prompt() 시그니처:**

build_prompt()에 `model_map` 파라미터를 추가하는 것은 시그니처 비대화를 초래합니다. 대신 MODEL_MAP을 모듈 레벨 상수로 정의하고, build_prompt() 내부에서 참조하는 방식이 낫습니다. build_prompt() 시그니처는 Cycle 4에서 Progressive Disclosure용 `disclosure_phase` 파라미터만 추가하면 됩니다.

_build_cowork_section()에서 "모델 선택 가이드" 텍스트를 하드코딩하는 대신 MODEL_MAP에서 동적으로 생성:

```python
def _build_cowork_section(team_id: str) -> str:
    # ...기존 코드...
    model_guide = "\n".join(
        f"- {role} -> model=\"{model}\""
        for role, model in MODEL_MAP.items()
    )
    lines += f"**모델 선택 가이드:**\n{model_guide}\n"
```

이렇게 하면 DIRECT-WORKFLOW.md, MARKETING-WORKFLOW.md, team_prompts.py의 모델 가이드 텍스트가 모두 MODEL_MAP 하나에서 파생됩니다.

**P2-3. A/B 테스트 워크플로우 설계:**

A/B 테스트 실행 흐름을 제안합니다:

1. **대조군(A)**: 현재 방식 유지 (QC 관련 Task tool 호출 시 model="sonnet")
2. **실험군(B)**: QC 관련 Task tool 호출 시 model="haiku"
3. **배분**: task_id 끝자리 홀짝으로 자동 배분 (홀수=A, 짝수=B)
4. **기간**: 2주 (약 40-60건 태스크 예상)
5. **측정**: qc_verify.py 결과 JSON에 `model_used` 필드 추가, 후속 분석

기록 위치: `/home/jay/workspace/memory/logs/ab-test-haiku-qc.jsonl`

---

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

**P2-4. TRUST 5 구조화에 대한 품질 관점:**

TRUST 구조화의 핵심 리스크는 "기존 verifier 목록과 TRUST 차원 간 1:N 매핑의 모호성"입니다.

구체적 예시:
- `schema_contract` verifier는 Tested(스키마 검증)이면서 Unified(계약 일관성)이기도 합니다
- `scope_check`은 Trackable(변경 추적)이면서 Unified(범위 일관성)이기도 합니다

이 모호성을 해소하려면 각 verifier에 **primary TRUST 차원**과 **secondary 차원**을 명시적으로 태깅해야 합니다:

| verifier | Primary | Secondary |
|---|---|---|
| api_health | T(Tested) | S(Secured) |
| file_check | T(Tested) | - |
| data_integrity | T(Tested) | U(Unified) |
| test_runner | T(Tested) | - |
| tdd_check | T(Tested) | K(Trackable) |
| schema_contract | U(Unified) | T(Tested) |
| pyright_check | T(Tested) | R(Readable) |
| style_check | R(Readable) | - |
| scope_check | K(Trackable) | U(Unified) |
| critical_gap | S(Secured) | - |
| spec_compliance | U(Unified) | - |
| duplicate_check | R(Readable) | - |

TRUST 구조화의 **테스트 방법**: 기존 QC-RULES.md v3.5와 TRUST 버전을 병행 운용하여, 동일 태스크에 대해 두 버전의 판정 결과가 일치하는지 검증합니다. 불일치 건수가 0이면 마이그레이션 승인.

**P2-3. haiku 전용화 A/B 테스트의 품질 게이트:**

haiku 전용화 A/B 테스트에서 가장 중요한 것은 **"False Negative 감지"** 입니다. 즉, haiku가 발견하지 못한 이슈를 sonnet은 발견했을 경우입니다. 이를 측정하려면:

1. A/B 양쪽 모두에 대해 **이중 검증**(sonnet으로 재검증)을 일부 샘플(20%)에서 수행
2. haiku 단독 QC에서 놓친 이슈 수 측정
3. False Negative Rate > 15%이면 haiku 전용화 불가 판정

기준선 정의:
- 현재 sonnet QC의 이슈 발견율(건당 평균 이슈 수)을 먼저 측정
- haiku QC의 이슈 발견율이 sonnet 대비 85% 이상이면 PASS

---

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

**P2-4. TRUST 5에 대한 공격:**

TRUST 5 구조화는 **"분류 연극"**입니다. 현재 QC-RULES.md는 v1.0부터 3.5까지 실전에서 검증된 유기적 구조입니다. 이것을 TRUST라는 인위적 5차원으로 재배치하면:

1. **정보 파편화**: 현재 "셀프 QC -> 자동 검증 -> 테스트 회귀 방지"라는 실행 순서 기반 구조가 깨집니다. 작업자는 "다음에 뭘 해야 하나?"가 아니라 "이 차원에 뭐가 있나?"를 찾게 되어 **인지 부하 증가**.

2. **TRUST라는 이름 자체가 허영 메트릭**: Tested/Readable/Unified/Secured/Trackable이 뭔가 있어 보이지만, 실제로 "Readable"에 Suppression 목록을 넣는 것은 견강부회입니다. Suppression은 "불필요한 경고 제거"이지 "가독성 향상"이 아닙니다.

3. **마아트의 1:N 매핑 문제를 인정했다**: schema_contract가 Tested이면서 Unified라면, 결국 "어느 차원에서 이 verifier를 찾아야 하나?"라는 새로운 혼란을 만듭니다. Primary/Secondary 태깅은 문제를 해결하는 게 아니라 복잡성만 추가합니다.

4. **ROI 불명**: 이 구조화에 들어가는 노력(문서 재작성, 기존 참조 수정, 이중 검증 기간) 대비 얻는 것이 "보기 좋은 구조"뿐입니다. QC 판정 정확도가 올라간다는 증거가 없습니다.

**제안**: TRUST 5차원을 QC-RULES.md 본문 구조 변경이 아니라, **QC 결과 보고서의 서머리 섹션에 태그로 부착**하는 방식으로 전환하세요. 기존 구조는 유지하되, 최종 판정 시 "T:PASS, R:PASS, U:WARN, S:PASS, K:PASS" 형태로 요약만 추가합니다.

**P2-5. 모델 매핑 테이블에 대한 공격:**

1. **MODEL_MAP이 단일 장애점**: 한 곳에서 `"qc_verify": "haiku"`로 바꾸면 모든 팀의 QC 모델이 일괄 변경됩니다. 팀별 특성(dev8은 GLM 기반이라 QC 수준이 다름)을 무시합니다.

2. **DIRECT-WORKFLOW.md와의 모순 발생**: MODEL_MAP이 canonical source가 되면, DIRECT-WORKFLOW.md의 "모델 선택 가이드" 텍스트를 삭제하거나 참조로 바꿔야 합니다. 그런데 DIRECT-WORKFLOW.md는 팀장이 직접 읽는 가이드입니다. "MODEL_MAP을 참조하세요"라고 쓰면 팀장이 Python 코드를 읽어야 합니다. 가독성 후퇴.

3. **현재 시스템에서 모델 지정은 어디서 실행되나?** Task tool 호출 시 `model="sonnet"` 파라미터입니다. 이 파라미터는 팀장이 프롬프트 지시에 따라 직접 지정합니다. MODEL_MAP을 team_prompts.py에 넣어봐야 **런타임에 자동으로 적용되지 않습니다**. 결국 프롬프트 텍스트로 "이 역할은 haiku를 쓰세요"라고 알려줘야 하고, 그건 현재와 동일합니다.

**P2-3. haiku 전용화 A/B 테스트에 대한 공격:**

1. **task_id 홀짝 배분은 통계적으로 무효**: 태스크 복잡도가 task_id에 의존하지 않는다는 보장이 없습니다. Lv.1 단순 수정은 haiku로도 충분하고, Lv.3 복합 작업은 sonnet이 필요합니다. 홀짝 배분은 이 차이를 통제하지 못합니다.

2. **"QC 관련 Task tool 호출"의 범위가 불명확**: qc_verify.py의 verifier들은 Python 스크립트 직접 실행이지 모델 호출이 아닙니다. 실제로 haiku 전용화 대상은 "셀프 QC" 부분인데, 셀프 QC는 팀장(Opus)이 수행합니다. 팀장을 haiku로 바꿀 순 없잖아?

3. **2주 40-60건은 통계적 유의성에 부족**: 최소 n=100 이상이어야 p < 0.05 달성 가능. 40건이면 단순 노이즈일 수 있습니다.

---

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

**전략적 프레이밍: P2 3건을 "모델 거버넌스 체계" 관점으로 통합**

P2의 세 항목을 개별적으로 보면 각각 독립된 개선이지만, 전략적으로는 하나의 큰 그림의 조각들입니다:

- TRUST 5: **품질 기준의 체계화** (무엇을 측정하나)
- 모델 매핑: **자원 배분의 체계화** (누가 실행하나)
- haiku 전용화: **비용 최적화의 검증** (얼마나 절감하나)

이 세 개를 "모델 거버넌스 체계(Model Governance Framework)"로 통합합니다:

```
품질 기준(TRUST) --> 역할별 요구 모델 수준 결정 --> 모델 매핑(MODEL_MAP) --> 비용 최적화 검증(A/B) --> 피드백 루프
```

**로키 비평에 대한 전략적 대응:**

1. **TRUST 구조화 범위 축소에 동의**: 로키의 "보고서 서머리에 태그 부착" 제안이 타당합니다. QC-RULES.md 본문은 실행 순서 기반 구조를 유지하되, qc_verify.py 결과 JSON에 `trust_summary` 필드를 추가하는 방식으로 구현합니다.

```python
# qc_verify.py build_result() 수정
def build_result(task_id, checks):
    trust = {
        "T": all(checks[c]["status"] in ("PASS","SKIP") for c in ["test_runner","tdd_check","api_health","file_check"]),
        "R": all(checks[c]["status"] in ("PASS","SKIP","WARN") for c in ["style_check","duplicate_check"]),
        "U": all(checks[c]["status"] in ("PASS","SKIP") for c in ["schema_contract","spec_compliance"]),
        "S": all(checks[c]["status"] in ("PASS","SKIP") for c in ["critical_gap"]),
        "K": all(checks[c]["status"] in ("PASS","SKIP","WARN") for c in ["scope_check","data_integrity"]),
    }
    return {
        "task_id": task_id,
        "trust_summary": trust,
        "overall": ...,
        "checks": checks,
    }
```

2. **MODEL_MAP 런타임 무효 문제**: 로키 지적이 맞습니다. MODEL_MAP을 team_prompts.py에 넣어봐야 프롬프트 텍스트 생성 시에만 참조됩니다. 해결책: `_build_cowork_section()`이 MODEL_MAP에서 자동으로 "모델 선택 가이드" 텍스트를 생성하게 하면, 최소한 **프롬프트 내 가이드 텍스트의 Single Source of Truth**는 확보됩니다.

3. **A/B 테스트 설계 보강**: 홀짝 대신 **작업 레벨(Lv.1/Lv.2/Lv.3) 기반 층화 추출**을 사용합니다. 각 레벨에서 50%를 haiku, 50%를 sonnet으로 배분. 기간을 4주(n>100)로 연장합니다.

**haiku 전용화 대상 명확화:**

로키 지적대로 qc_verify.py verifier는 모델 호출이 아닙니다. 실제 haiku 전용화 대상은:
1. 테스터 역할 서브에이전트의 model 파라미터 (아르고스, 헤임달 등)
2. 셀프 QC의 일부를 서브에이전트에 위임하는 경우의 model 파라미터
3. lint/style 관련 Task tool 호출의 model 파라미터

팀장(Opus) 자체를 haiku로 전환하는 것이 아니라, **팀장이 QC 위임 시 haiku를 지정하도록 프롬프트를 변경**하는 것입니다.

---

## 3 Whys 검증

### P2-4. TRUST 5 기반 구조화
**Why 1**: QC 품질을 체계적으로 측정하려면? → 차원별 분류 필요
**Why 2**: 왜 기존 구조로는 안 되나? → 현재 구조는 "실행 순서"이지 "품질 차원"이 아님. 어떤 품질 영역이 부족한지 파악이 어려움
**Why 3**: TRUST 태그가 품질 파악에 실제로 도움이 되나? → qc_verify.py 결과에 trust_summary가 추가되면, 특정 차원(예: Unified)이 자주 실패하는 패턴을 분석할 수 있음. 단, 본문 구조 변경 없이 결과 태깅으로 충분

### P2-5. 모델 매핑 테이블
**Why 1**: 모델 지정을 중앙화하려면? → 현재 3곳(team_prompts.py 텍스트, DIRECT-WORKFLOW.md, MARKETING-WORKFLOW.md)에 분산되어 불일치 위험
**Why 2**: 중앙화가 런타임에 적용되나? → 아니오. 프롬프트 생성 시점에만 적용. 하지만 프롬프트 텍스트 일관성은 확보
**Why 3**: 일관성 확보만으로 충분한가? → 현 단계에서는 충분. 향후 ADK 도입 시 런타임 자동 적용으로 발전 가능

### P2-3. haiku 전용화 A/B 테스트
**Why 1**: 비용 절감 가능성 검증? → QC 관련 서브에이전트 호출을 haiku로 전환하면 토큰 비용 60-70% 절감 추정
**Why 2**: 품질 저하 없이 가능한가? → A/B 테스트로 검증 필요
**Why 3**: A/B 테스트 설계가 유효한가? → 층화 추출 + 이중 검증(샘플 20%) + n>100 조건 충족 시 통계적 유의성 확보 가능

---

## 합의 사항

### P2-4. TRUST 5 기반 QC-RULES.md 구조화
- **합의**: QC-RULES.md 본문 구조는 변경하지 않음 (실행 순서 기반 유지)
- **대신**: qc_verify.py의 build_result()에 `trust_summary` 필드 추가 (각 차원별 PASS/FAIL)
- **구현 파일**: `/home/jay/workspace/teams/dev1/qc/qc_verify.py` -- build_result() 함수 수정
- **verifier-TRUST 매핑**: 마아트가 제시한 Primary/Secondary 태깅 테이블을 qc_verify.py 내 상수로 정의
- **_build_verification_section()**: TRUST 체크 요약 한 줄 추가 (오딘 제안)
- **롤백**: trust_summary 필드를 제거하면 원복. 기존 JSON 스키마에 optional 필드 추가이므로 하위호환 유지

### P2-5. 에이전트별 모델 매핑 테이블
- **합의**: team_prompts.py에 `MODEL_MAP` 모듈 레벨 상수 추가 (방안 B)
- **구현**: `_build_cowork_section()`이 MODEL_MAP에서 "모델 선택 가이드" 텍스트를 자동 생성
- **DIRECT-WORKFLOW.md**: "모델 선택 가이드" 섹션에 "상세 매핑은 team_prompts.py MODEL_MAP 참조" 한 줄 추가. 기존 가이드 텍스트는 유지 (팀장 가독성 보존, 로키 의견 반영)
- **팀별 오버라이드**: TEAM_INFO에 `model_overrides` 필드를 optional로 추가, MODEL_MAP보다 우선
- **롤백**: MODEL_MAP 상수 삭제 + _build_cowork_section() 원복
- **P1 연동**: build_prompt() 시그니처에 model_map 파라미터는 추가하지 않음 (모듈 상수로 충분)

### P2-3. 검증 작업 haiku 전용화 A/B 테스트
- **합의**: 즉시 전환이 아닌 A/B 테스트 선행 (Cycle 1-2 결정 유지)
- **haiku 전용화 대상 확정**: 테스터 역할 서브에이전트 + QC 위임 Task tool 호출의 model 파라미터 (팀장 자체 X, qc_verify.py verifier X)
- **A/B 테스트 설계**: 작업 레벨 기반 층화 추출, 기간 4주, 목표 n>100
- **이중 검증**: 전체 샘플의 20%에 대해 sonnet으로 재검증 (False Negative 측정)
- **PASS 기준**: haiku 이슈 발견율 >= sonnet 대비 85%, False Negative Rate < 15%
- **기록**: `/home/jay/workspace/memory/logs/ab-test-haiku-qc.jsonl`
- **qc_verify.py 수정**: 결과 JSON에 `model_used` 필드 추가
- **롤백**: A/B 테스트 FAIL 시 haiku 전용화 미적용, 현 상태 유지

---

## 미해결 이슈

1. **TRUST 매핑 상수 정의 위치**: qc_verify.py 내부 vs 별도 config 파일 vs QC-RULES.md 내 메타데이터 -- 다음 구현 시 결정
2. **MODEL_MAP 초기값 합의 필요**: 구체적으로 어떤 역할이 haiku이고 어떤 역할이 sonnet인지 전체 목록 확정 필요
3. **A/B 테스트 시작 시점**: P1 작업(hooks, Progressive Disclosure, 격리) 완료 후 시작할지, 병렬로 시작할지 미결
4. **publishing/design 팀의 모델 매핑**: 현재 MODEL_MAP은 dev 팀 기준. publishing 팀(sonnet 위주), marketing 팀(haiku 위주) 등 비개발 팀의 매핑도 포함할지 범위 결정 필요
5. **TRUST 차원 중 "Secured" 커버리지 부족**: 현재 critical_gap 1개만 매핑됨. 보안 관련 verifier 추가 필요 여부 검토