---
name: adversarial-review
description: "로직/설계 비평 스트레스 테스트: Steel-Man → Adversarial Attack → 심각도 분류 → Counter-Proposal"
triggers:
  - "stress-test"
  - "스트레스 테스트"
  - "코드리뷰"
  - "아키텍처 검토"
usage: "/adversarial-review <검토 대상 코드/설계/주장>"
---

# Adversarial Review 스킬

> 이 스킬은 프레이야(프론트엔드 개발자)가 주어진 코드, 설계, 또는 주장을 Devil's Advocate 방식으로 검증한다.
> **역할 분리**: adversarial-review = 로직/설계 비평 담당 / 로키(레드팀) = 보안/위협 탐지 담당.
> 두 역할은 상호 보완적이며, 보안 취약점은 로키에게 에스컬레이션한다.

---

## 역할 분리 명세

| 역할 | 담당 영역 | 스킬 |
|------|---------|------|
| **adversarial-review** | 논리적 오류, 설계 결함, 엣지 케이스, 아키텍처 취약성 | 이 스킬 |
| **로키 (레드팀)** | 보안 취약점, 위협 모델링, 침투 시나리오 | 로키 에스컬레이션 |

보안 관련 발견 시 → "로키 에스컬레이션 필요: [발견 항목]" 형식으로 명시 후 검토 중단.

---

## 1. 실행 전 준비

프레이야는 adversarial-review 시작 전에 반드시 다음을 확인한다:

1. **검토 대상 명확화**: 코드/설계/주장 중 무엇을 검토하는지 한 문장으로 정의
2. **범위 설정**: 전체 시스템인지, 특정 모듈인지, 단일 주장인지 명시
3. **작업 레벨 확인**: `memory/specs/work-level-system.md` 참조 (Lv.3+ 필수 적용)
4. **deep-dive-analyzer 선행 여부**: deep-dive 분석 후 이 스킬을 실행하면 더 정확한 공격 벡터 도출 가능

---

## 2. 3개 공격 벡터

### 벡터 1: 논리적 건전성 (Logical Soundness)
- 전제와 결론 사이의 논리적 비약 탐지
- 순환 논리, 허수아비 논증, 거짓 이분법 식별
- 귀납적 일반화의 표본 편향 검사

### 벡터 2: 엣지 케이스 취약성 (Edge Case Vulnerability)
- 경계값(0, null, 빈 배열, 최대값) 처리 부재
- 비동기 레이스 컨디션, 타임아웃, 네트워크 단절 시나리오
- 입력 유효성 검사 누락, 예외 전파 경로

### 벡터 3: 미시적 해부 (Micro-level Dissection)
- 명명 불일치 및 의도-구현 괴리
- 숨겨진 의존성, 결합도 과잉, 단일 책임 원칙 위반
- 성능 병목, 메모리 누수 패턴, 불필요한 재렌더링 (프론트엔드 특화)

---

## 3. 4단계 실행 파이프라인

### Stage 1: Steel-Man (최선 해석)
```
목적: 검토 대상을 가장 강력하고 합리적인 형태로 재구성한다.
출력:
- [Steel-Man] 이 설계/코드가 의도하는 최선의 해석: <1~2문장>
- [가정] 이것이 성립하려면 전제해야 할 조건: <목록>
```
**규칙**: Steel-Man을 건너뛰고 곧바로 공격하는 것 금지. 공정한 비평의 기반이다.

### Stage 2: Adversarial Attack (공격)
```
3개 벡터를 순서대로 적용:

[벡터 1 - 논리적 건전성]
- 발견된 논리 오류 목록 (없으면 "이상 없음")

[벡터 2 - 엣지 케이스 취약성]
- 발견된 취약 시나리오 목록 (없으면 "이상 없음")

[벡터 3 - 미시적 해부]
- 발견된 구현 결함 목록 (없으면 "이상 없음")

[보안 관련 발견]
- 있으면: "로키 에스컬레이션 필요: [항목]" 후 해당 항목은 이 스킬에서 제외
- 없으면: 생략
```

### Stage 3: 심각도 분류 (Severity Classification)

QC 레벨과 통일된 심각도 기준:

| 심각도 | 레이블 | 기준 | 대응 |
|--------|--------|------|------|
| **security** | `[SECURITY]` | 데이터 유출, 인증 우회, 무결성 파괴 → 로키 에스컬레이션 | 즉시 중단, 로키에게 넘김 |
| **critical** | `[CRITICAL]` | 시스템 장애, 데이터 손실, 핵심 흐름 깨짐 | 배포 전 필수 수정 |
| **normal** | `[NORMAL]` | 기능적 결함이나 회피 가능, UX 저하, 성능 열화 | 스프린트 내 처리 |
| **notes** | `[NOTES]` | 스타일, 개선 제안, 장기 기술 부채 | 백로그 등록 |

```
분류 출력 예시:
- [CRITICAL] 비동기 상태 업데이트에서 컴포넌트 언마운트 후 setState 호출 → 메모리 누수
- [NORMAL] 페이지네이션 컴포넌트에서 totalCount=0 케이스 미처리
- [NOTES] useEffect 의존성 배열에 명시적 주석 없음
```

### Stage 4: Counter-Proposal (개선 제안)
```
[CRITICAL] 및 [NORMAL] 항목에 대해서만 구체적 수정 방향 제시:

각 항목:
- 문제: <발견된 결함 한 줄 요약>
- 제안: <구체적 수정 방법 또는 대안>
- 근거: <왜 이것이 더 나은지>
```

### Stage 5: Verdict (판정)

모든 발견 항목 분석 후 최종 판정을 내린다.

**판정 기준:**
- **FAIL**: [CRITICAL] 1건 이상이면서 단기 완화책 없음, 또는 [NORMAL] 이상 3건 이상
- **PASS WITH CONDITIONS**: [CRITICAL] 1건 이상이면서 단기 완화책 존재, 또는 [NORMAL] 1-2건
- **PASS**: [CRITICAL] 0건 + [NORMAL] 0건. [NOTES]만 존재.

이 기준은 일관된 판정을 보장한다. 판정은 반드시 Counter-Proposal 이후에 수행하며, 판정 결과를 출력 마지막에 명시한다.

**출력 형식:**
```
판정: [PASS / PASS WITH CONDITIONS / FAIL]
- [조건부 PASS 시: 필수 수정 항목 목록]
- [FAIL 시: 차단 사유 목록]
```

---

## 4. Telegram 출력 최적화

Telegram 환경에서는 테이블 대신 목록 형식을 사용한다.

**단계 분할 규칙:**
- 발견 항목이 5개 이상이면 Stage 2/3을 먼저 출력 후 "계속 보려면 /continue 입력" 안내
- Stage 4는 별도 메시지로 분리 출력
- 각 메시지는 500자 이하 유지 권장

**Telegram 출력 형식 예시:**
```
[Adversarial Review]
대상: <검토 대상 한 줄 요약>

Steel-Man: <최선 해석>

발견 사항:
- [CRITICAL] <내용>
- [NORMAL] <내용>
- [NOTES] <내용>

→ Counter-Proposal은 다음 메시지에서...
```

---

## 5. 파이프라인 연결

### deep-dive-analyzer → adversarial-review (권장 순서)
```
1. /deep-dive-analyzer로 대상 심층 분석
2. 분석 결과를 입력으로 /adversarial-review 실행
3. adversarial-review 결과 중 [SECURITY] → 로키 에스컬레이션
```

### adversarial-review 단독 실행 가능 조건
- Lv.1~2 작업으로 deep-dive가 불필요한 경우
- 코드 변경사항이 소규모(함수 단위)인 경우

---

## 5.5. 전문 모드 (Specialized Modes)

검토 대상의 유형에 따라 공격 벡터의 초점을 조정한다.

### 코드 리뷰 모드
코드 파일/PR/diff를 검토할 때:
- Read 도구로 변경 파일 전체 읽기
- OWASP Top 10 취약점 확인
- 에러 처리 완전성 검증
- 엣지 케이스 테스트 커버리지 평가
- 네이밍, 구조, 추상화 수준 평가

### 아키텍처 결정 모드
아키텍처/설계 결정을 검토할 때:
- 확장성 가정 평가 (10x, 100x 부하 시뮬레이션)
- 단일 장애 지점(SPOF) 확인
- 벤더 종속(lock-in) 위험 평가
- 팀 역량과의 정합성 확인

### PR 리뷰 모드
Pull Request를 검토할 때:
- 동작 변경에 집중 (스타일 변경 무시)
- 공개 API 호환성 파괴(breaking changes) 확인
- 하위 호환성 검증
- 롤백 전략 확인
- 데이터 마이그레이션 경로 확인

---

## 6. 금지사항

1. **Steel-Man 생략 금지**: 반드시 최선 해석 후 공격 시작
2. **보안 취약점 직접 처리 금지**: 발견 즉시 로키 에스컬레이션, 이 스킬 범위 밖
3. **근거 없는 심각도 분류 금지**: 각 항목에 분류 근거 명시 필수
4. **[NOTES] 남용 금지**: 실제 [NORMAL] 이상의 문제를 [NOTES]로 하향 분류 금지
5. **Counter-Proposal 없는 [CRITICAL] 출력 금지**: [CRITICAL] 발견 시 반드시 수정 방향 포함

---

## 7. 빠른 참조

- **역할 분리**: adversarial-review(로직/설계) vs 로키(보안/위협)
- **심각도**: security → critical → normal → notes
- **QC 레벨 연동**: `memory/specs/work-level-system.md`
- **선행 스킬**: `/deep-dive-analyzer` (권장)
- **에스컬레이션**: 보안 발견 → 로키

---

**스킬 버전**: v1.1
**작성일**: 2026-03-17
**작성자**: 프레이야 (프론트엔드 개발자)
**참조**: adversarial-review 원본, QC 레벨 시스템, 로키 역할 정의