# Agent 미팅: 검증 시나리오 발산 + 물리적 테스트 시스템 설계

**날짜**: 2026-04-13
**소집 이유**: 코드 수정 후 시행착오 반복 (드롭다운 3회 왕복, 월 필터 미적용, polling 미동작) — 물리적 검증 시스템 필요
**참여 페르소나**: 오딘(팀장), 프레이야(FE), 토르(BE), 아르고스(QA), 로키(RedTeam), Gemini(외부), ChatGPT(업계)
**미팅 모드**: hybrid
**토론 깊이**: thorough
**총 사이클 수**: 2 + DA

---

## Cycle 1 (Independent — 7명 병렬)

### 주요 의견

**오딘**: 3단계 파이프라인 (시나리오 발산→테스트 실행→게이트). 티어링 필수 (P0만 게이트). Lv.1-2도 5~10개 적용. 비관습적 대안: 레드팀(로키)이 적대적 시나리오 발산.

**프레이야**: 프론트엔드 6분류 (렌더링/인터랙션/데이터바인딩/CSS클리핑/반응형/에러상태). Firebase Auth는 storageState 방식. overflow 감지: boundingBox + 조상 overflow 검사. 비관습적 대안: CSS 린트로 빌드 타임 경고.

**토르**: 경계별 입출력 계약(contract) 테스트. subprocess cmd 검증은 mock/patch. 월 필터는 물리적 검증 필요 (테스트 DB + assert). 비관습적 대안: subprocess 제거, Python 직접 호출로 타입 에러 컴파일 타임 캐치.

**아르고스**: HICCECC 프레임워크로 축별 4~7개 발산. YAML + 자연어 하이브리드. pytest parametrize 자동 주입. 자동 70% / 수동 30%. 시간 예산: Lv.3=90초, Lv.4=3.5분. 비관습적 대안: 변이 테스트(mutation testing) 10개가 시나리오 50개보다 버그 검출률 높을 수 있음.

**로키(DA)**: 5가지 공격 — 시나리오 인플레이션(80% trivial), LLM 자기참조, qc_verify 게이트 병목, LLM은 인프라 장애 상상 못함, 시나리오→코드 변환이 가장 약한 고리.

**Gemini**: 변경 영향 분석이 시나리오 발산보다 우월. 봇 프롬프트에 테스트 3개 의무화 + 정적 분석 도입이 정답. LLM 시나리오 기계 구축은 과잉.

**ChatGPT**: 기존 도구(Meticulous/Codium)는 기록 기반이라 부적합. YAML→pytest parametrize가 현실적. 병렬 10워커로 50개 15초 가능.

### 합의 영역
- 시나리오 YAML 형식 (id, category, steps, expected, automatable, priority)
- qc_verify.py에 scenario_gate verifier 추가
- 티어링: P0(필수) + P1(WARN)
- 5분 Hard limit

### 쟁점
1. 누가 시나리오를 발산하는가? (사람 vs LLM vs 레드팀)
2. 자동 테스트 변환의 신뢰성
3. LLM 시나리오 발산 vs 정적 영향 분석

---

## Cycle 2 (Sequential — 오딘 최종 제안 + 로키 DA)

### 오딘 최종 제안
"정적 영향 분석(AST) + 사람 작성 YAML + pytest parametrize + qc_verify 게이트"
- LLM 시나리오 발산 배제, 사람만 작성
- 변환 없음: YAML이 곧 실행 스펙
- impact_analyzer.py + scenario_runner.py 신규

### Devil's Advocate (로키)
1. **실패 시나리오**: "사람이 YAML 안 씀 → 빈 YAML → SKIP → 시스템 무력화"
2. **6개월 후 후회**: 8팀 변경 속도가 YAML 작성 속도 압도. LLM 초안 없이 스케일 불가.
3. **더 단순한 대안**: "기존 pytest 363개를 변경 파일 기준으로 자동 필터링하는 것이 80% 커버. 새 YAML + 새 게이트 + 새 도구 동시 도입이 리스크."

### 반박 수용
로키의 3번(기존 테스트 활용)은 타당. 신규 시스템 전에 기존 자원을 최대 활용해야 함.
로키의 2번(LLM 초안)도 수용 — 완전 배제 대신 "LLM 초안 + 사람 승인" 채택.

---

## 최종 합의 사항

### 3계층 시스템 (Phase별 도입)

**Layer 1 — Smart Test Filtering (즉시 적용)**
- 변경 파일 기반 기존 pytest 자동 필터링
- qc_verify.py의 test_runner가 --check-files 기반 추론 이미 지원
- 추가 개발: import 의존성 그래프 기반 확장 필터링

**Layer 2 — 시나리오 게이트 (신규 핵심)**
- impact_analyzer.py: AST + grep으로 변경 영향 파악
- scenario_runner.py: YAML 시나리오 실행 (curl/pytest/subprocess)
- 시나리오 YAML: LLM 초안 생성 → 아누/제이회장님 승인 → scenarios/ 저장
- qc_verify.py에 scenario_gate verifier 추가
- 빈 시나리오 허용 금지 (0건 = FAIL)

**Layer 3 — E2E Smoke (Lv.3+ 전용)**
- Playwright 인증 세션(storageState) 기반
- P0 시나리오 5~10개만 필수 게이트
- boundingBox + overflow 조상 검사 포함

### 시나리오 YAML 스키마
```yaml
- id: SC-001
  category: data-flow  # data-flow | rendering | interaction | error | integration
  target: ["server.py:5637", "knowledge_extractor_v2.py:890"]
  type: subprocess  # curl | pytest | subprocess | playwright
  steps:
    - action: "POST /api/wiki/refine/start with selectedMonth=2026-03"
      expect: "subprocess cmd에 --month 2026-03 포함"
    - action: "ps aux | grep kakao_knowledge"
      expect: "--month 2026-03 인자 존재"
  priority: must  # must | should | could
  automatable: true
```

### 시나리오 수량 기준
- Lv.1: 3~5개 (아누가 task 파일에 직접 작성)
- Lv.2: 5~10개 (아누 작성)
- Lv.3: 15~30개 (LLM 초안 + 아누 승인)
- Lv.4: 30~50개 (LLM 초안 + 아누 승인 + 레드팀 적대적 추가)

### 파일 구조
```
teams/shared/qc/
  impact_analyzer.py      # 정적 영향 분석 (AST + grep)
  scenario_runner.py      # YAML → 테스트 실행
  scenarios/              # 프로젝트별 시나리오 YAML
    insuwiki/
    threadauto/
    dashboard/
  auth/
    storageState.json     # Playwright 인증 세션
```

### 실행 흐름
```
qc_verify.py --gate
  ├─ (기존) file_check, data_integrity, test_runner, pyright_check, ...
  └─ (신규) scenario_gate
       ├─ impact_analyzer.py (30초)
       │   → impact.json: affected files/functions/endpoints
       ├─ scenario_runner.py (4분)
       │   → scenarios/*.yaml 중 target 매칭된 것만 실행
       │   → pytest parametrize로 주입 + 병렬 실행
       └─ 결과 판정
           → must 시나리오 1개라도 FAIL → GATE FAIL
           → should 시나리오 FAIL → WARN
           → 전부 PASS → GATE PASS
```

---

## 미해결 항목
- Playwright storageState 갱신 주기 (Firebase ID Token 1시간 만료)
- 기존 363개 테스트의 import 의존성 그래프 초기 구축 비용
- scenarios/ 디렉토리 초기 시드 데이터 범위

## 다음 단계
1. Layer 1(Smart Test Filtering)은 즉시 적용 가능 — 기존 인프라 활용
2. Layer 2(시나리오 게이트)는 Lv.3 작업으로 구현 위임
3. Layer 3(E2E Smoke)는 Layer 2 안정화 후 추가