572 lines
15 KiB
Markdown
572 lines
15 KiB
Markdown
## Role Debate
|
|
|
|
다양한 전문성을 가진 역할이 토론하여 트레이드오프를 검토하고 최적해를 도출하는 명령어입니다.
|
|
|
|
### 사용법
|
|
|
|
```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 을 먼저 검토하세요
|