Role Debate

---
description: "복수 역할 토론으로 트레이드오프 검토. 「역할 간 토론해줘」「트레이드오프 검토해줘」등으로 기동."
allowed-tools:
  - Read
  - Grep
---

# 복수 역할 토론으로 트레이드오프 검토

다양한 전문성을 가진 역할이 토론하여 트레이드오프를 검토하고 최적해를 도출하는 명령어입니다.

## 사용법

```bash
/role-debate <역할 1>,<역할 2> [안건]
/role-debate <역할 1>,<역할 2>,<역할 3> [안건]
```

## 기본 예제

```bash
# 보안 vs 성능의 트레이드오프
/role-debate security,performance
「JWT 토큰의 유효기간 설정에 대해서」

# 사용성 vs 보안의 균형
/role-debate frontend,security
「2 단계 인증의 UX 최적화에 대해서」

# 기술 선정 토론
/role-debate architect,mobile
「React Native vs Flutter 선택에 대해서」

# 3 자 토론
/role-debate architect,security,performance
「마이크로서비스화의 찬반에 대해서」
```

## 토론의 기본 원칙

### 건설적 토론의 자세

- **상호 존중**: 다른 역할의 전문성과 관점을 존중
- **사실 기반**: 감정적 반박이 아닌 데이터·근거기반의 토론
- **해결 지향**: 비판을 위한 비판이 아닌 더 나은 해결책을 목표
- **구현 중시**: 이상론이 아닌 실현 가능성을 고려한 제안

### 논거의 질적 요건

- **공식 문서**: 표준·가이드라인·공식 문서에 대한 언급
- **실증 사례**: 성공 사례·실패 사례의 구체적 인용
- **정량 평가**: 가능한 한 수치·지표를 통한 비교
- **시계열 고려**: 단기·중기·장기에서의 영향 평가

### 토론 윤리

- **성실성**: 자신의 전문 분야의 한계도 인정
- **개방성**: 새로운 정보·관점에 대한 유연성
- **투명성**: 판단 근거·전제 조건의 명시
- **책임성**: 제안의 구현 리스크도 포함하여 언급

## 토론 프로세스

## Phase 1: 초기 입장 표명

각 역할이 전문 관점으로 독립적으로 의견 표명

- 권장안 제시
- 근거가 되는 표준·문서의 명시
- 예상되는 리스크·과제 설명
- 성공 지표의 정의

## Phase 2: 상호 토론·반박

역할 간의 크로스 토론

- 다른 역할 제안에 대한 건설적 반박
- 간과된 관점의 지적
- 트레이드오프의 명확화
- 대안 제시

## Phase 3: 타협점 모색

구현 가능한 해결책의 모색

- 각 관점의 중요도 평가
- Win-Win 해결책 검토
- 단계별 구현 접근법
- 리스크 경감책 검토

## Phase 4: 통합 결론

최종적인 권장사항 결정

- 합의된 해결책
- 구현 로드맵
- 성공 지표·측정 방법
- 향후 검토 포인트

## 출력 형식 예제

## 2 역할 토론의 경우

```text
역할 토론: Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

안건: JWT 토큰의 유효기간 설정

Security 역할의 주장:
「15 분의 단기 유효기간을 권장합니다」

근거:
- OWASP JWT Security Cheat Sheet 준수
- 토큰 유출 시 피해 시간 창을 최소화
- 공격자의 이용 가능 시간을 제한

우려 사항:
- 장기 유효기간은 공격 리스크가 지수함수적으로 증대
- 규정 준수 요건(금융계)에서는 단기가 필수

성공 지표:
- 보안 인시던트 발생률 < 0.1%
- 평균 공격 탐지 시간 < 5 분

Performance 역할의 반박:
「2 시간의 유효기간을 권장합니다」

근거:
- Google OAuth 2.0 Best Practices 참고
- 빈번한 재인증으로 인한 서버 부하 증가 회피
- 사용자 경험(작업 중단)의 최소화

우려 사항:
- 15 분 간격의 재인증은 API 부하 8 배 증가
- 모바일 환경에서 연결 끊김이 빈발

성공 지표:
- API 응답 시간 < 200ms 유지
- 서버 CPU 사용률 < 60%

상호 토론:
Security → Performance:
「서버 부하보다도 보안 침해의 비즈니스 손실이 더 심각합니다.
예: Equifax 사건에서는 7 억 달러의 손실」

Performance → Security:
「리프레시 토큰 메커니즘으로 양립 가능합니다.
백그라운드 업데이트로 UX 를 손상시키지 않고 보안 확보」

Security → Performance:
「리프레시 토큰도 공격 대상입니다. 적절한 구현이 전제」

Performance → Security:
「단계적 접근법을 제안합니다. 일반 조작 30 분, 기밀 조작 15 분」

타협점 모색:
공통 이해:
- 사용자 경험과 보안의 양립이 필요
- 리스크 레벨에 따른 유연한 대응
- 구현·운용 비용의 현실적 고려

Win-Win 요소:
- 리프레시 토큰 메커니즘의 활용
- 리스크 기반 인증의 단계적 도입
- 자동 로그아웃 기능을 통한 보완

통합 결론:
「30 분 유효기간 + 리프레시 토큰 + 리스크 기반 인증」

구현 세부사항:
1. 액세스 토큰: 30 분 유효기간
2. 리프레시 토큰: 7 일 유효기간
3. 고위험 조작: 15 분에 강제 재인증
4. 무조작 30 분에 자동 로그아웃

단계적 구현:
1-2 주차: 기본적인 30 분 토큰 구현
3-4 주차: 리프레시 토큰 메커니즘 추가
2 개월차: 리스크 기반 인증의 도입

성공 지표:
- 보안: 인시던트 발생률 < 0.1%
- 성능: API 부하 증가율 < 20%
- UX: 사용자 만족도 > 85%

향후 검토:
- 3 개월 후: 실제 공격 패턴·부하 상황 평가
- 6 개월 후: 더 정교한 리스크 기반 인증으로의 이전 검토
```

## 3 역할 토론의 경우

```text
역할 토론: Architect vs Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

안건: 마이크로서비스화의 찬반

Architect 역할의 주장:
「단계적 마이크로서비스화를 권장」
근거: 도메인 경계 명확화, 독립적인 배포, 기술 선택의 자유도

Security 역할의 우려:
「서비스 간 통신의 보안 복잡화」
근거: API Gateway, mTLS, 분산 인증의 관리 비용

Performance 역할의 우려:
「네트워크 통신을 통한 지연시간 증가」
근거: 내부 API 호출을 통한 N+1 문제, 분산 트랜잭션

3 자 토론:
Architect → Security: 「API Gateway 로 집중 관리에 의해 통제 가능」
Security → Architect: 「단일 장애점이 되는 리스크」
Performance → Architect: 「서비스 분할의 세분화가 중요」
...(토론 계속)

통합 결론:
「도메인 주도 설계를 통한 단계적 분할 + 보안 우선 설계」
```

## 효과적인 토론 패턴

## 기술 선정

```bash
/role-debate architect,performance
「데이터베이스 선택: PostgreSQL vs MongoDB」

/role-debate frontend,mobile
「UI 프레임워크: React vs Vue」

/role-debate security,architect
「인증 방식: JWT vs Session Cookie」
```

## 설계 판단

```bash
/role-debate security,frontend
「사용자 인증의 UX 설계」

/role-debate performance,mobile
「데이터 동기화 전략의 최적화」

/role-debate architect,qa
「테스트 전략과 아키텍처 설계」
```

## 트레이드오프 문제

```bash
/role-debate security,performance
「암호화 레벨 vs 처리 속도」

/role-debate frontend,performance
「리치 UI vs 페이지 로딩 속도」

/role-debate mobile,security
「편의성 vs 데이터 보호 레벨」
```

## 역할별 토론 특성

### 🔒 Security 역할

```yaml
토론 스탠스:
  - 보수적 접근법 (리스크 최소화)
  - 규칙 준수 중시 (표준에서의 일탈에 신중)
  - 최악 케이스 가정 (공격자 관점)
  - 장기적 영향 중시 (기술적 부채로서의 보안)

전형적 논점:
  - "보안 vs 편의성"의 트레이드오프
  - "규정 준수 요건의 필달"
  - "공격 비용 vs 방어 비용의 비교"
  - "프라이버시 보호의 철저화"

논거 소스:
  - OWASP 가이드라인
  - NIST 프레임워크
  - 업계 표준 (ISO 27001, SOC 2)
  - 실제 공격 사례·통계

토론에서의 강점:
  - 리스크 평가의 정확성
  - 규제 요건의 지식
  - 공격 기법에 대한 이해

주의해야 할 편견:
  - 과도한 보수성 (이노베이션 저해)
  - UX 에 대한 배려 부족
  - 구현 비용의 경시
```

### ⚡ Performance 역할

```yaml
토론 스탠스:
  - 데이터 주도 판단 (측정 기반)
  - 효율성 중시 (비용 대비 효과의 최적화)
  - 사용자 경험 우선 (체감 속도 중시)
  - 지속적 개선 (단계적 최적화)

전형적 논점:
  - "성능 vs 보안"
  - "최적화 비용 vs 효과의 투자 대비 효과"
  - "현재 vs 미래의 확장성"
  - "사용자 경험 vs 시스템 효율"

논거 소스:
  - Core Web Vitals 지표
  - 벤치마크 결과·통계
  - 사용자 행동에 대한 영향 데이터
  - 업계 성능 표준

토론에서의 강점:
  - 정량적 평가 능력
  - 병목 지점 특정
  - 최적화 기법의 지식

주의해야 할 편견:
  - 보안의 경시
  - 보수성에 대한 배려 부족
  - 성급한 최적화
```

### 🏗️ Architect 역할

```yaml
토론 스탠스:
  - 장기 관점 중시 (시스템 진화에 대한 배려)
  - 균형 추구 (전체 최적화)
  - 단계적 변경 (리스크 관리)
  - 표준 준수 (검증된 패턴 우선)

전형적 논점:
  - "단기 효율 vs 장기 보수성"
  - "기술적 부채 vs 개발 속도"
  - "마이크로서비스 vs 모놀리스"
  - "신기술 채택 vs 안정성"

논거 소스:
  - 아키텍처 패턴집
  - 설계 원칙 (SOLID, DDD)
  - 대규모 시스템 사례
  - 기술 진화의 트렌드

토론에서의 강점:
  - 전체 조망 능력
  - 설계 패턴의 지식
  - 장기 영향의 예측

주의해야 할 편견:
  - 과도한 일반화
  - 신기술에 대한 보수성
  - 구현 세부사항에 대한 이해 부족
```

### 🎨 Frontend 역할

```yaml
토론 스탠스:
  - 사용자 중심 설계 (UX 최우선)
  - 포용적 접근법 (다양성 배려)
  - 직관성 중시 (학습 비용 최소화)
  - 접근성 표준 (WCAG 준수)

전형적 논점:
  - "사용성 vs 보안"
  - "디자인 통일 vs 플랫폼 최적화"
  - "기능성 vs 단순함"
  - "성능 vs 리치한 경험"

논거 소스:
  - UX 연구·사용성 테스트 결과
  - 접근성 가이드라인
  - 디자인 시스템 표준
  - 사용자 행동 데이터

토론에서의 강점:
  - 사용자 관점의 대변
  - 디자인 원칙의 지식
  - 접근성 요건

주의해야 할 편견:
  - 기술 제약에 대한 이해 부족
  - 보안 요건의 경시
  - 성능 영향의 과소평가
```

### 📱 Mobile 역할

```yaml
토론 스탠스:
  - 플랫폼 특화 (iOS/Android 차이 고려)
  - 컨텍스트 적응 (이동 중·한 손 조작)
  - 리소스 제약 (배터리·메모리·통신)
  - 스토어 준수 (심사 가이드라인)

전형적 논점:
  - "네이티브 vs 크로스 플랫폼"
  - "오프라인 대응 vs 실시간 동기화"
  - "배터리 효율 vs 기능성"
  - "플랫폼 통일 vs 최적화"

논거 소스:
  - iOS HIG / Android Material Design
  - App Store / Google Play 가이드라인
  - 모바일 UX 연구
  - 디바이스 성능 통계

토론에서의 강점:
  - 모바일 특유 제약의 이해
  - 플랫폼 차이의 지식
  - 터치 인터페이스 설계

주의해야 할 편견:
  - 웹 플랫폼에 대한 이해 부족
  - 서버 사이드 제약의 경시
  - 데스크톱 환경에 대한 배려 부족
```

### 🔍 Analyzer 역할

```yaml
토론 스탠스:
  - 증거 중시 (데이터 우선)
  - 가설 검증 (과학적 접근법)
  - 구조적 사고 (시스템 사고)
  - 바이어스 제거 (객관성 추구)

전형적 논점:
  - "상관관계 vs 인과관계"
  - "증상 대증요법 vs 근본 해결"
  - "가설 vs 사실의 구분"
  - "단기 증상 vs 구조적 문제"

논거 소스:
  - 실측 데이터·로그 분석
  - 통계적 기법·분석 결과
  - 시스템 사고 이론
  - 인지 바이어스 연구

토론에서의 강점:
  - 논리적 분석 능력
  - 증거 평가의 객관성
  - 구조적 문제의 발견

주의해야 할 편견:
  - 분석 마비 (행동력 부족)
  - 완벽주의 (실용성 경시)
  - 데이터 만능주의
```

## 토론 진행 템플릿

### Phase 1: 입장 표명 템플릿

```text
【역할명】의 권장안:
「[구체적인 제안]」

근거:
- [공식 문서·표준에 대한 언급]
- [실증 사례·데이터]
- [전문 분야의 원칙]

예상 효과:
- [단기적 효과]
- [중장기적 효과]

우려·리스크:
- [구현 리스크]
- [운용 리스크]
- [다른 분야에 대한 영향]

성공 지표:
- [측정 가능한 지표 1]
- [측정 가능한 지표 2]
```

### Phase 2: 반박 템플릿

```text
[대상 역할]에 대한 반박:
「[대상 제안에 대한 구체적 반박]」

반박 근거:
- [간과된 관점]
- [대립하는 증거·사례]
- [전문 분야에서의 우려]

대안:
「[개선된 제안]」

타협 가능한 포인트:
- [수용 가능한 조건]
- [단계적 구현의 가능성]
```

### Phase 3: 통합 해결 템플릿

```text
통합 해결안:
「[각 역할의 우려를 고려한 최종 제안]」

각 역할에 대한 배려:
- [Security]: [보안 요건의 충족 방법]
- [Performance]: [성능 요건의 충족 방법]
- [기타]: [기타 요건의 충족 방법]

구현 로드맵:
- 페이즈 1 (즉시): [긴급 대응 사항]
- 페이즈 2 (단기): [기본 구현]
- 페이즈 3 (중기): [완전 구현]

성공 지표·측정 방법:
- [통합적인 성공 지표]
- [측정 방법·빈도]
- [재검토 타이밍]
```

## 토론 품질 체크리스트

### 논거의 질

- [ ] 공식 문서·표준에 대한 언급이 있다
- [ ] 구체적인 사례·데이터가 제시되고 있다
- [ ] 추측과 사실이 명확히 구분되어 있다
- [ ] 정보원이 명시되어 있다

### 토론의 건설성

- [ ] 상대의 제안을 정확히 이해하고 있다
- [ ] 감정적이 아닌 논리적 반박
- [ ] 대안도 제시하고 있다
- [ ] Win-Win 의 가능성을 모색하고 있다

### 구현 가능성

- [ ] 기술적 실현 가능성을 고려
- [ ] 구현 비용·기간을 견적
- [ ] 단계적 구현의 가능성을 검토
- [ ] 리스크 경감책을 제시

### 통합성

- [ ] 다른 분야에 대한 영향을 고려
- [ ] 전체 최적화를 추구
- [ ] 장기적 관점을 포함
- [ ] 측정 가능한 성공 지표를 설정

## Claude 와의 연계

```bash
# 설계 문서를 바탕으로 한 토론
cat system-design.md
/role-debate architect,security
「이 설계의 보안 측면에서의 과제를 토론하세요」

# 문제를 바탕으로 한 해결책 토론
cat performance-issues.md
/role-debate performance,architect
「성능 문제의 근본적 해결책을 토론하세요」

# 요건을 바탕으로 한 기술 선정 토론
/role-debate mobile,frontend
「iOS·Android·Web 의 통일 UI 전략에 대해 토론하세요」
```

## 주의사항

- 토론은 시간이 걸릴 수 있습니다 (복잡한 주제일수록 장시간)
- 3 개 이상의 역할에서는 토론이 발산할 가능성이 있습니다
- 최종 판단은 토론 결과를 참고하여 사용자가 수행하세요
- 긴급성이 높은 문제에서는 single role 이나 multi-role 을 먼저 검토하세요