wasabeef 복수 역할 토론으로 트레이드오프 검토
다양한 전문성을 가진 역할이 토론하여 트레이드오프를 검토하고 최적해를 도출하는 명령어입니다.
사용법
/role-debate <역할 1>,<역할 2> [안건]
/role-debate <역할 1>,<역할 2>,<역할 3> [안건]
기본 예제
# 보안 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 역할 토론의 경우
역할 토론: 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 역할 토론의 경우
역할 토론: Architect vs Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
안건: 마이크로서비스화의 찬반
Architect 역할의 주장:
「단계적 마이크로서비스화를 권장」
근거: 도메인 경계 명확화, 독립적인 배포, 기술 선택의 자유도
Security 역할의 우려:
「서비스 간 통신의 보안 복잡화」
근거: API Gateway, mTLS, 분산 인증의 관리 비용
Performance 역할의 우려:
「네트워크 통신을 통한 지연시간 증가」
근거: 내부 API 호출을 통한 N+1 문제, 분산 트랜잭션
3 자 토론:
Architect → Security: 「API Gateway 로 집중 관리에 의해 통제 가능」
Security → Architect: 「단일 장애점이 되는 리스크」
Performance → Architect: 「서비스 분할의 세분화가 중요」
...(토론 계속)
통합 결론:
「도메인 주도 설계를 통한 단계적 분할 + 보안 우선 설계」
효과적인 토론 패턴
기술 선정
/role-debate architect,performance
「데이터베이스 선택: PostgreSQL vs MongoDB」
/role-debate frontend,mobile
「UI 프레임워크: React vs Vue」
/role-debate security,architect
「인증 방식: JWT vs Session Cookie」
설계 판단
/role-debate security,frontend
「사용자 인증의 UX 설계」
/role-debate performance,mobile
「데이터 동기화 전략의 최적화」
/role-debate architect,qa
「테스트 전략과 아키텍처 설계」
트레이드오프 문제
/role-debate security,performance
「암호화 레벨 vs 처리 속도」
/role-debate frontend,performance
「리치 UI vs 페이지 로딩 속도」
/role-debate mobile,security
「편의성 vs 데이터 보호 레벨」
역할별 토론 특성
🔒 Security 역할
토론 스탠스:
- 보수적 접근법 (리스크 최소화)
- 규칙 준수 중시 (표준에서의 일탈에 신중)
- 최악 케이스 가정 (공격자 관점)
- 장기적 영향 중시 (기술적 부채로서의 보안)
전형적 논점:
- "보안 vs 편의성"의 트레이드오프
- "규정 준수 요건의 필달"
- "공격 비용 vs 방어 비용의 비교"
- "프라이버시 보호의 철저화"
논거 소스:
- OWASP 가이드라인
- NIST 프레임워크
- 업계 표준 (ISO 27001, SOC 2)
- 실제 공격 사례·통계
토론에서의 강점:
- 리스크 평가의 정확성
- 규제 요건의 지식
- 공격 기법에 대한 이해
주의해야 할 편견:
- 과도한 보수성 (이노베이션 저해)
- UX 에 대한 배려 부족
- 구현 비용의 경시
⚡ Performance 역할
토론 스탠스:
- 데이터 주도 판단 (측정 기반)
- 효율성 중시 (비용 대비 효과의 최적화)
- 사용자 경험 우선 (체감 속도 중시)
- 지속적 개선 (단계적 최적화)
전형적 논점:
- "성능 vs 보안"
- "최적화 비용 vs 효과의 투자 대비 효과"
- "현재 vs 미래의 확장성"
- "사용자 경험 vs 시스템 효율"
논거 소스:
- Core Web Vitals 지표
- 벤치마크 결과·통계
- 사용자 행동에 대한 영향 데이터
- 업계 성능 표준
토론에서의 강점:
- 정량적 평가 능력
- 병목 지점 특정
- 최적화 기법의 지식
주의해야 할 편견:
- 보안의 경시
- 보수성에 대한 배려 부족
- 성급한 최적화
🏗️ Architect 역할
토론 스탠스:
- 장기 관점 중시 (시스템 진화에 대한 배려)
- 균형 추구 (전체 최적화)
- 단계적 변경 (리스크 관리)
- 표준 준수 (검증된 패턴 우선)
전형적 논점:
- "단기 효율 vs 장기 보수성"
- "기술적 부채 vs 개발 속도"
- "마이크로서비스 vs 모놀리스"
- "신기술 채택 vs 안정성"
논거 소스:
- 아키텍처 패턴집
- 설계 원칙 (SOLID, DDD)
- 대규모 시스템 사례
- 기술 진화의 트렌드
토론에서의 강점:
- 전체 조망 능력
- 설계 패턴의 지식
- 장기 영향의 예측
주의해야 할 편견:
- 과도한 일반화
- 신기술에 대한 보수성
- 구현 세부사항에 대한 이해 부족
🎨 Frontend 역할
토론 스탠스:
- 사용자 중심 설계 (UX 최우선)
- 포용적 접근법 (다양성 배려)
- 직관성 중시 (학습 비용 최소화)
- 접근성 표준 (WCAG 준수)
전형적 논점:
- "사용성 vs 보안"
- "디자인 통일 vs 플랫폼 최적화"
- "기능성 vs 단순함"
- "성능 vs 리치한 경험"
논거 소스:
- UX 연구·사용성 테스트 결과
- 접근성 가이드라인
- 디자인 시스템 표준
- 사용자 행동 데이터
토론에서의 강점:
- 사용자 관점의 대변
- 디자인 원칙의 지식
- 접근성 요건
주의해야 할 편견:
- 기술 제약에 대한 이해 부족
- 보안 요건의 경시
- 성능 영향의 과소평가
📱 Mobile 역할
토론 스탠스:
- 플랫폼 특화 (iOS/Android 차이 고려)
- 컨텍스트 적응 (이동 중·한 손 조작)
- 리소스 제약 (배터리·메모리·통신)
- 스토어 준수 (심사 가이드라인)
전형적 논점:
- "네이티브 vs 크로스 플랫폼"
- "오프라인 대응 vs 실시간 동기화"
- "배터리 효율 vs 기능성"
- "플랫폼 통일 vs 최적화"
논거 소스:
- iOS HIG / Android Material Design
- App Store / Google Play 가이드라인
- 모바일 UX 연구
- 디바이스 성능 통계
토론에서의 강점:
- 모바일 특유 제약의 이해
- 플랫폼 차이의 지식
- 터치 인터페이스 설계
주의해야 할 편견:
- 웹 플랫폼에 대한 이해 부족
- 서버 사이드 제약의 경시
- 데스크톱 환경에 대한 배려 부족
🔍 Analyzer 역할
토론 스탠스:
- 증거 중시 (데이터 우선)
- 가설 검증 (과학적 접근법)
- 구조적 사고 (시스템 사고)
- 바이어스 제거 (객관성 추구)
전형적 논점:
- "상관관계 vs 인과관계"
- "증상 대증요법 vs 근본 해결"
- "가설 vs 사실의 구분"
- "단기 증상 vs 구조적 문제"
논거 소스:
- 실측 데이터·로그 분석
- 통계적 기법·분석 결과
- 시스템 사고 이론
- 인지 바이어스 연구
토론에서의 강점:
- 논리적 분석 능력
- 증거 평가의 객관성
- 구조적 문제의 발견
주의해야 할 편견:
- 분석 마비 (행동력 부족)
- 완벽주의 (실용성 경시)
- 데이터 만능주의
토론 진행 템플릿
Phase 1: 입장 표명 템플릿
【역할명】의 권장안:
「[구체적인 제안]」
근거:
- [공식 문서·표준에 대한 언급]
- [실증 사례·데이터]
- [전문 분야의 원칙]
예상 효과:
- [단기적 효과]
- [중장기적 효과]
우려·리스크:
- [구현 리스크]
- [운용 리스크]
- [다른 분야에 대한 영향]
성공 지표:
- [측정 가능한 지표 1]
- [측정 가능한 지표 2]
Phase 2: 반박 템플릿
[대상 역할]에 대한 반박:
「[대상 제안에 대한 구체적 반박]」
반박 근거:
- [간과된 관점]
- [대립하는 증거·사례]
- [전문 분야에서의 우려]
대안:
「[개선된 제안]」
타협 가능한 포인트:
- [수용 가능한 조건]
- [단계적 구현의 가능성]
Phase 3: 통합 해결 템플릿
통합 해결안:
「[각 역할의 우려를 고려한 최종 제안]」
각 역할에 대한 배려:
- [Security]: [보안 요건의 충족 방법]
- [Performance]: [성능 요건의 충족 방법]
- [기타]: [기타 요건의 충족 방법]
구현 로드맵:
- 페이즈 1 (즉시): [긴급 대응 사항]
- 페이즈 2 (단기): [기본 구현]
- 페이즈 3 (중기): [완전 구현]
성공 지표·측정 방법:
- [통합적인 성공 지표]
- [측정 방법·빈도]
- [재검토 타이밍]
토론 품질 체크리스트
논거의 질
- 공식 문서·표준에 대한 언급이 있다
- 구체적인 사례·데이터가 제시되고 있다
- 추측과 사실이 명확히 구분되어 있다
- 정보원이 명시되어 있다
토론의 건설성
- 상대의 제안을 정확히 이해하고 있다
- 감정적이 아닌 논리적 반박
- 대안도 제시하고 있다
- Win-Win 의 가능성을 모색하고 있다
구현 가능성
- 기술적 실현 가능성을 고려
- 구현 비용·기간을 견적
- 단계적 구현의 가능성을 검토
- 리스크 경감책을 제시
통합성
- 다른 분야에 대한 영향을 고려
- 전체 최적화를 추구
- 장기적 관점을 포함
- 측정 가능한 성공 지표를 설정
Claude 와의 연계
# 설계 문서를 바탕으로 한 토론
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 을 먼저 검토하세요