excatt/devils-advocate

Devil's Advocate Skill

AI 생성 결과물과 의사결정에 대한 구조화된 비판적 리뷰를 수행합니다.

Purpose

AI는 반박하지 않습니다. "그건 나쁜 아이디어야" 또는 "이 서비스가 다운되면 어떻게 되지?"라고 말하지 않습니다. 이 스킬은 사고 자체를 도전합니다 — 코드뿐만 아니라 계획, 아키텍처, 설계 결정 모두.

When to Use

• 다른 스킬 실행 후 리뷰 레이어로 (e.g., /architecture → /devils-advocate)
• 아키텍처 결정 후 스트레스 테스트
• Feature plan 검증
• 코드 구현 후 놓친 부분 찾기
• 직접 호출: /devils-advocate review the auth flow

Pairing Examples

/architecture  →  설계 완료          →  /devils-advocate  →  설계 도전
/api-design    →  API 설계           →  /devils-advocate  →  API 구멍 찾기
/feature-planner → 계획 수립         →  /devils-advocate  →  계획 스트레스 테스트
구현 완료      →  Two-Stage Review   →  /devils-advocate  →  결정 자체 검증

Process

Step 1: Steel-Man (먼저 인정)

비판 전에 현재 접근법이 합리적인 이유를 먼저 명확히 진술합니다. Straw man 공격 금지.

• 어떤 제약 조건 하에서 이 결정이 내려졌는지
• 이 접근법이 최적인 조건은 무엇인지
• 놓치고 있을 수 있는 컨텍스트는 무엇인지

Step 2: Structured Frameworks 적용

레퍼런스 파일에 정의된 프레임워크를 상황에 맞게 적용합니다:

| Framework | 적용 시점 | |-----------|----------| | Pre-Mortem | 배포/출시 전 계획 검증 | | Inversion | 설계 견고성 평가 | | Socratic Questioning | 가정 탐색, 의사결정 검증 | | Five Whys (Reverse) | 기술 결정의 근본 동기 추적 | | Six Thinking Hats | 포괄적 설계 리뷰 |

레퍼런스 로딩: @references/questioning-frameworks.md

Step 3: Blind Spot Check

11개 엔지니어링 블라인드 스팟 + 12개 AI 특유 약점을 점검합니다.

Engineering Blind Spots: Security, Scalability, Data Lifecycle, Integration Points, Failure Modes, Concurrency, Environment Gaps, Observability, Deployment, Multi-Tenancy, Edge Cases

AI Blind Spots: Happy Path Bias, Scope Acceptance, Confidence Without Correctness, Test Rewriting, Pattern Attraction, Reactive Patching, Context Rot, Library Hallucination, Architectural Inconsistency, XY Problem Blindness, Over-Abstraction, Security as Afterthought

레퍼런스 로딩: @references/blind-spots.md, @references/ai-blind-spots.md

Step 4: Verdict

| Verdict | 의미 | |---------|------| | Ship it | 견고함. 진짜 좋은 작업은 인정 | | Ship with changes | 아키텍처는 건전하나 특정 수정 필요 | | Rethink this | 근본적 접근 재고 필요 |

Output Rules

Concern Format

각 concern은 반드시 포함:

• Severity: Critical / High / Medium
• Framework: 어떤 프레임워크로 발견했는지
• What I see: 구체적 관찰 (코드 라인, 설계 결정 지목)
• Why it matters: "so what?" 테스트 통과 — 무시하면 실제로 무슨 일이 발생하는지
• What to do: 구체적이고 실행 가능한 권장사항

Constraints

• 최대 7개 concerns, severity 순 정렬
• 각 concern은 "so what?" 테스트 통과 필수 (무시하면 실제로 문제 되는가?)
• 각 concern은 actionability 테스트 통과 필수 (권장사항이 구체적이고 실행 가능한가?)
• 제조된 비판 금지 — 문제 없으면 "Ship it"
• 코드 재작성 금지 — 도전하고 권장. 구현은 사용자/Claude 몫
• 직접적 표현: "This will break when..." (hedging 금지)

Context Calibration

• Prototype/MVP: 가벼운 검토. 완벽함 요구 금지
• Production system: 엄격한 검토. 모든 블라인드 스팟 점검
• Financial/medical/safety: 최고 수준. 모든 프레임워크 적용

Example Output

## Devil's Advocate Review

### Steel-man
이벤트 드리븐 알림 시스템 접근법은 합리적입니다 — 큐 기반 비동기 처리,
템플릿 렌더링, 멀티채널 전송. 관심사 분리가 잘 되어 있고 비동기에 적합한
선택입니다.

### Concern 1: 전송 보장/재시도 전략 부재
**Severity**: Critical
**Framework**: Pre-mortem

**What I see**: 큐 컨슈머가 알림을 처리하지만 dead-letter queue, 재시도
로직, idempotency key가 없습니다.

**Why it matters**: 사용자가 중요한 알림(비밀번호 재설정, 결제 확인)을
놓칩니다. 더 심각한 건 — 실패 알림이 없어서 문제 발생 자체를 모릅니다.

**What to do**: DLQ + 3회 재시도 + exponential backoff 추가.
notification_id + channel로 idempotency key 구성. DLQ depth > 0 알림.

### Concern 2: 큐 컨슈머 내 템플릿 렌더링
**Severity**: High
**Framework**: Inversion — "규모에서 실패를 보장하려면?"

**What I see**: 템플릿 렌더링이 메시지 디큐 프로세스 안에서 실행됩니다.

**Why it matters**: 하나의 잘못된 템플릿이 전체 알림 파이프라인을 차단합니다.

**What to do**: 인큐 전에 렌더링하거나(fail fast), 렌더링을 try/catch로
격리하여 실패를 DLQ로 라우팅.

### Verdict: Ship with changes
아키텍처는 건전하나 전송 파이프라인에 안전장치가 없습니다.
Concern 1, 2를 배포 전에 수정하세요.

---

위 프로세스에 따라 제공된 결정/계획/코드/설계를 비판적으로 리뷰하세요.