# task-605.1: superpowers 프레임워크 심층 분석 및 우리 시스템 반영 평가

> 작성: 오딘(dev2 팀장) | 2026-03-16

---

## SCQA

**S**: superpowers(v5.0.2, 85.7K stars)는 Claude Code의 기능을 극대화하는 14개 스킬 프레임워크로, 브레인스토밍→계획→TDD→서브에이전트 병렬개발→코드리뷰→완료검증의 전 파이프라인을 자동 체인한다. 우리 시스템은 44개 스킬, 4-hook 체인, 매트릭스 조직(아누+3개발팀+QC+레드팀), 집단지성 3봇 토론을 운영 중이다.

**C**: superpowers는 단일 개발자의 Claude Code 생산성에 특화된 반면, 우리는 멀티봇 오케스트레이션에 특화되어 있다. 14개 기능 중 일부는 우리가 이미 보유하거나 더 강화했지만, **합리화 방지(Anti-Rationalization)**, **완료 전 검증 게이트**, **코드 리뷰 수용 프로토콜** 등 에이전트 행동 제어 기법은 우리가 약한 영역이다.

**Q**: superpowers의 14개 기능 중 우리 시스템에 즉시 반영하여 품질을 높일 수 있는 것은 무엇이고, 우리가 이미 더 잘하고 있는 것은 무엇인가?

**A**: 즉시 반영 3건(완료 전 검증 게이트, 코드 리뷰 수용 프로토콜, 합리화 방지 강화), Phase 2 반영 2건(브레인스토밍 Socratic 프로세스, 계획-실행 자동 체인), 불필요 9건(이미 보유하거나 우리 아키텍처에 맞지 않는 기능). 반영 시 예상 효과: 서브에이전트 "완료" 오보율 감소, 코드 리뷰 피드백의 실질적 반영율 향상.

---

## 1단계: superpowers 전체 기능 목록

GitHub 리포 직접 탐색 결과, **skills/ 디렉토리에 14개 스킬**이 존재한다. 초기 작업 지시서에 언급된 "Performance Benchmarking", "Eval Framework", "Skill Description Optimization", "MCP Integration", "Project Kickoff"는 superpowers 리포에 독립 스킬로 존재하지 않음을 확인했다 (일부는 writing-skills 스킬 내 하위 기능, 일부는 별도 리포 혼동).

실제 14개 스킬:

1. **brainstorming** — Socratic 대화 기반 아이디어→설계 발전
2. **writing-plans** — 구현 계획서 작성 (2-5분 단위 마이크로태스크)
3. **executing-plans** — 계획 실행 (서브에이전트 미지원 환경용)
4. **subagent-driven-development** — 서브에이전트 기반 병렬 개발 + 3단계 리뷰
5. **dispatching-parallel-agents** — 독립 태스크 병렬 에이전트 디스패치
6. **requesting-code-review** — 2단계 코드 리뷰 요청
7. **receiving-code-review** — 코드 리뷰 피드백 수용 프로토콜
8. **using-git-worktrees** — Git 워크트리 격리 개발
9. **finishing-a-development-branch** — 개발 브랜치 완료/통합 (4가지 옵션)
10. **test-driven-development** — RED-GREEN-REFACTOR TDD 강제
11. **systematic-debugging** — 4단계 체계적 디버깅
12. **verification-before-completion** — 완료 주장 전 검증 게이트
13. **writing-skills** — 새 스킬 생성 방법론 (CSO, 압박 테스트)
14. **using-superpowers** — 스킬 시스템 자동 주입 (세션 훅)

---

## 2단계: 각 기능별 평가표

### 1. brainstorming (Socratic 아이디어→설계 대화)

- **현재 상태**: **부분** — `agent-meeting` 스킬이 보리스 워크플로우(페르소나 미팅 6사이클)를 수행하지만, Socratic 1:1 대화식 설계 발전은 없음. `nuclear-approval`이 설계 게이트 역할
- **반영 가치**: **중** — 우리는 에이전트 미팅(다수) 방식이므로, 1:1 Socratic은 보완적. 다만 Lv.2 작업에서 미팅 없이 바로 코딩에 들어가는 경우가 있음
- **반영 난이도**: **중** — 스킬 1개 추가 + 워크플로우 연동 필요
- **반영 방법**: Lv.2 작업에서 에이전트 미팅 대신 사용할 수 있는 "경량 설계 대화" 스킬로 도입. 현재 agent-meeting은 Lv.3+에 최적화되어 있어, Lv.2 갭을 채울 수 있음
- **우선순위 근거**: 에이전트 미팅은 Lv.3+, nuclear-approval은 Lv.4. Lv.2 설계 프로세스가 비어있는 갭 해소

### 2. writing-plans (구현 계획서 작성)

- **현재 상태**: **부분** — `3docs-create`가 계획서/맥락노트/체크리스트를 생성하고, 팀장이 마이크로태스크 분해를 수행하지만, superpowers처럼 "파일별 책임 → 2-5분 단위 스텝 → 실행 명령어 + 기대 출력"까지 템플릿화되지 않음
- **반영 가치**: **중** — 3docs-create가 이미 대부분 커버하나, 실행 명령어/기대 출력 포함은 유용
- **반영 난이도**: **하** — 3docs-create의 계획서 템플릿에 필드 추가만으로 가능
- **반영 방법**: 3docs-create 계획서 템플릿에 "실행 명령어 + 기대 출력" 필드 추가. DIRECT-WORKFLOW.md의 마이크로태스크 분해 지침에 이 필드를 의무화
- **우선순위 근거**: 낮은 난이도로 마이크로태스크 품질 개선 가능. 다만 3docs가 이미 핵심을 커버

### 3. executing-plans (서브에이전트 없는 계획 실행)

- **현재 상태**: **없음** — 우리 시스템은 항상 Task tool로 팀원 서브에이전트를 사용. 서브에이전트 불가 환경 대비 프로토콜 없음
- **반영 가치**: **하** — 우리 환경(Claude Code)은 항상 서브에이전트 가능. 단, dev3팀의 z.ai 엔진 봇은 서브에이전트 불가할 수 있음
- **반영 난이도**: **하** — 스킬 1개 추가
- **반영 방법**: dev3팀(라+아누비스+이시스) 전용 폴백 프로토콜로 도입 가능하나, 현재 dev3는 별도 엔진(z.ai) 사용 중이므로 우선순위 낮음
- **우선순위 근거**: 우리 주력 환경에서 필요 없음. dev3 특수 케이스에만 해당

### 4. subagent-driven-development (서브에이전트 병렬 개발)

- **현재 상태**: **있음** — `subagent-driven-development` 스킬 이미 설치됨. DIRECT-WORKFLOW.md가 팀원 역할별 Task tool 병렬 실행 정의. 우리는 추가로 "페르소나 고정 규칙(Anti-Drift)"과 "모델 선택 가이드(Opus/Sonnet/Haiku)"를 보유
- **반영 가치**: **하** — 이미 동등 이상으로 보유. 우리가 더 강한 점: 페르소나 고정, 역할 위반 방지, 비용 최적화 모델 선택
- **반영 난이도**: N/A
- **반영 방법**: 불필요. 다만 superpowers의 "implementer → spec-reviewer → code-quality-reviewer" 3단계 리뷰 체인은 참고할 만함 (아래 #6 참조)
- **우선순위 근거**: 우리가 페르소나 고정 + 모델 차등화에서 더 앞서 있음

### 5. dispatching-parallel-agents (병렬 에이전트 디스패치)

- **현재 상태**: **있음** — DIRECT-WORKFLOW.md가 "의존 관계 없는 서브태스크는 반드시 병렬 실행" 명시. 병렬 Tool 호출 안전 규칙(외부 호출 순차, 파일 읽기 안전 체크 등) 보유
- **반영 가치**: **하** — 이미 보유 + 우리가 더 강함 (병렬 실패 sibling 에러 방지 규칙)
- **반영 난이도**: N/A
- **반영 방법**: 불필요
- **우선순위 근거**: 우리 시스템이 병렬 안전 규칙에서 더 세밀함

### 6. requesting-code-review (2단계 코드 리뷰 요청)

- **현재 상태**: **부분** — 마아트(QC팀)가 독립 검증을 수행하고, qc_verify.py가 자동 검증하지만, superpowers처럼 "구현 완료 → spec-reviewer → code-quality-reviewer" 2단계 자동 리뷰 체인은 없음. 현재는 팀장이 통합 후 QC를 요청하는 순차 방식
- **반영 가치**: **중** — spec-reviewer(스펙 준수 검증)와 code-quality-reviewer(코드 품질)를 분리하는 것은 검증 깊이를 높일 수 있음. 현재 마아트가 두 역할을 통합 수행
- **반영 난이도**: **중** — qc_verify.py에 2단계 분리 로직 추가 또는 별도 서브에이전트 프롬프트 작성
- **반영 방법**: qc_verify.py 또는 팀장 워크플로우에 "스펙 준수 체크 → 코드 품질 체크" 순서를 명시. 마아트에게 2-pass 리뷰 프로토콜 적용 가능
- **우선순위 근거**: 현재 마아트의 단일 패스 리뷰가 누락 가능성이 있다면 의미있음. 다만 현행도 잘 작동 중

### 7. receiving-code-review (코드 리뷰 수용 프로토콜) ⭐ 즉시 반영 추천

- **현재 상태**: **없음** — 서브에이전트(팀원)가 코드 리뷰 피드백을 받았을 때의 행동 규칙이 없음. "Great point!" 같은 수행적 응답이나, YAGNI 위반 수정을 무비판 수용하는 패턴 방지 메커니즘 없음
- **반영 가치**: **상** — 서브에이전트가 리뷰 피드백을 "감정적으로 수행"하거나 불필요한 수정을 무비판 적용하는 것은 품질 저하 원인. 특히 Sonnet 모델이 리뷰 피드백에 과잉 반응하는 패턴이 관찰됨
- **반영 난이도**: **하** — 팀원 서브에이전트 프롬프트에 5-10줄 규칙 추가
- **반영 방법**: DIRECT-WORKFLOW.md 또는 팀원 프롬프트 템플릿에 추가: "리뷰 피드백 수신 시: (1) 기술적 재진술 (2) 코드베이스 실제 사용 확인 (3) YAGNI 체크 (4) 근거 없으면 반박. 'Great point!' 등 수행적 응답 금지"
- **우선순위 근거**: 난이도 최하 + 서브에이전트 품질 즉시 개선. Sonnet의 "과잉 순응" 패턴 직접 대응

### 8. using-git-worktrees (Git 워크트리 격리)

- **현재 상태**: **있음** — `git-worktree-isolation` 스킬 + DIRECT-WORKFLOW.md Step 1.5/4.5 + `worktree_manager.py` 스크립트 보유. 자동 생성/정리, 머지 판단 위임 프로토콜까지 구현됨
- **반영 가치**: **하** — 우리가 더 강함. superpowers는 수동 생성/정리, 우리는 자동화 + 머지 판단 위임 프로토콜
- **반영 난이도**: N/A
- **반영 방법**: 불필요. superpowers의 "안전 검증(git check-ignore)" 체크는 참고할 만하나, 우리 worktree_manager.py가 이미 처리
- **우선순위 근거**: 우리 시스템이 자동화와 머지 프로토콜에서 명확히 우위

### 9. finishing-a-development-branch (브랜치 완료/통합)

- **현재 상태**: **있음** — DIRECT-WORKFLOW.md Step 4.5가 worktree 정리 + 머지/유지 판단을 정의. 체이닝 중간 Phase는 자동 머지, 마지막은 아누 위임
- **반영 가치**: **하** — 이미 보유. superpowers의 "4가지 옵션(로컬 머지/PR/유지/폐기)" 중 우리가 "유지+아누 위임"과 "자동 머지"만 사용하는 것은 의도적 설계
- **반영 난이도**: N/A
- **반영 방법**: 불필요. 우리 시스템에서 "PR 생성"과 "작업 폐기"는 아누의 판단 영역이므로 팀장에게 위임하지 않는 것이 맞음
- **우선순위 근거**: 우리 아키텍처(오케스트레이터 의사결정)와 다른 설계 철학

### 10. test-driven-development (TDD 강제)

- **현재 상태**: **있음** — `tdd-enforcement` 스킬 설치 + DIRECT-WORKFLOW.md TDD 규칙 + 작업 레벨별 적용 기준(Lv.2+)
- **반영 가치**: **하** — 이미 동등 수준으로 보유. superpowers의 "삭제 규칙(테스트 전 코드 삭제)"은 더 극단적이나, 우리 멀티봇 환경에서는 실용적이지 않음 (코드 삭제 시 다른 팀원의 작업에 영향)
- **반영 난이도**: N/A
- **반영 방법**: 불필요. superpowers의 "합리화 표(Rationalization Table)"는 참고할 만하나, 우리 tdd-enforcement에 이미 유사 가이드라인 포함
- **우선순위 근거**: 동등 수준. superpowers의 극단적 삭제 규칙은 단일 개발자용

### 11. systematic-debugging (4단계 체계적 디버깅)

- **현재 상태**: **있음** — `systematic-debugging` 스킬 설치. superpowers와 동일 출처(동일 스킬 설치)
- **반영 가치**: **하** — 이미 보유
- **반영 난이도**: N/A
- **반영 방법**: 불필요
- **우선순위 근거**: 동일 스킬 이미 설치

### 12. verification-before-completion (완료 전 검증 게이트) ⭐ 즉시 반영 추천

- **현재 상태**: **부분** — `stop-qc-reminder.sh` 훅이 QC 셀프체크 리마인더를 출력하고, `qc_verify.py --gate`가 자동 검증하지만, **서브에이전트(팀원) 레벨**에서 "완료" 주장 전 검증 게이트가 없음. 팀원이 "완료했습니다"라고 보고하면 팀장이 그대로 수용하는 패턴
- **반영 가치**: **상** — 서브에이전트의 "DONE" 보고 신뢰성이 전체 파이프라인 품질의 병목. superpowers의 "NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE" 원칙은 직접 적용 가능
- **반영 난이도**: **하** — 팀원 서브에이전트 프롬프트에 검증 게이트 5줄 추가
- **반영 방법**: 팀원 프롬프트에 추가: "완료 보고 전 필수 — (1) 검증 명령어 식별 (2) 실행 (3) 전체 출력 확인 (4) exit code 0 확인 (5) '완료' 보고. 'should work', 'probably passes' 금지. 증거 없는 완료 보고 = 미완료 처리"
- **우선순위 근거**: 서브에이전트 완료 오보 → 팀장 재작업 비용 직접 감소. 난이도 최하

### 13. writing-skills (스킬 생성 방법론)

- **현재 상태**: **있음** — `skill-creator` 스킬이 스킬 생성/테스트/평가/최적화를 지원. superpowers의 writing-skills와 유사하나, superpowers가 CSO(Claude Search Optimization) 개념과 "description에 워크플로 넣지 마라" 규칙을 더 명시적으로 정의
- **반영 가치**: **중** — CSO 개념(description은 트리거 조건만, 워크플로는 SKILL.md 본문에)은 우리 스킬 품질 개선에 유용
- **반영 난이도**: **하** — skill-creator 스킬에 CSO 규칙 추가
- **반영 방법**: skill-creator 스킬에 "description 규칙: 'Use when...'으로 시작, 트리거 조건만 기술, 워크플로 요약 금지" 추가
- **우선순위 근거**: 스킬 트리거 정확도 개선에 도움되나, 기존 스킬이 이미 잘 작동 중

### 14. using-superpowers (스킬 시스템 자동 주입) ⭐ 합리화 방지 기법 즉시 반영 추천

- **현재 상태**: **부분** — 우리는 `user-prompt-submit.sh` 훅이 봇별 규칙을 자동 주입하고, 스킬 시스템이 키워드/의도 매칭으로 자동 로드. 그러나 superpowers의 핵심인 **합리화 방지(Anti-Rationalization)** 기법은 없음:
  - "이건 단순한 작업이라 스킬 불필요" → 스킬 확인은 의무
  - "그 스킬을 기억하고 있어" → 최신 버전 다시 읽어라
  - `<HARD-GATE>` 블록으로 특정 행동 완전 차단
  - 합리화 표(Rationalization Table) 내장
- **반영 가치**: **상** — AI 에이전트가 프로세스를 건너뛰는 "합리화"는 우리 시스템에서도 관찰되는 문제. 특히 Sonnet 팀원이 TDD를 건너뛰거나, 테스트 없이 "완료" 보고하는 패턴
- **반영 난이도**: **하** — 기존 훅/프롬프트에 합리화 방지 규칙 추가
- **반영 방법**: (1) DIRECT-WORKFLOW.md에 합리화 방지 섹션 추가: "Red Flags — 이 문장이 나오면 프로세스 위반: 'too simple for TDD', 'already tested manually', 'just a small fix'" (2) 팀원 프롬프트에 `<HARD-GATE>` 패턴 적용: TDD 스킵 불가, 완료 검증 스킵 불가
- **우선순위 근거**: 프로세스 준수율 직접 개선. "왜 스킵했나"에 대한 명시적 차단이 현재 없음

---

## 3단계: 최종 추천

### 즉시 반영 추천 (3건) — 가치 상 + 난이도 하

1. **verification-before-completion (완료 전 검증 게이트)**
   - 적용 위치: 팀원 서브에이전트 프롬프트 템플릿
   - 효과: 서브에이전트 "완료" 오보율 감소 → 팀장 재작업 비용 절감
   - 예상 작업량: 프롬프트 5-10줄 추가

2. **receiving-code-review (코드 리뷰 수용 프로토콜)**
   - 적용 위치: 팀원 서브에이전트 프롬프트 + 마아트 QC 프롬프트
   - 효과: 리뷰 피드백의 무비판 수용 방지 → YAGNI 위반 감소
   - 예상 작업량: 프롬프트 5-10줄 추가

3. **합리화 방지(Anti-Rationalization) 기법** (using-superpowers에서 추출)
   - 적용 위치: DIRECT-WORKFLOW.md + 팀원 프롬프트
   - 효과: TDD/검증 프로세스 스킵 방지 → 프로세스 준수율 향상
   - 예상 작업량: 워크플로우 문서 10-15줄 추가

### Phase 2 추천 (2건) — 가치 중~상 + 난이도 중

4. **brainstorming Socratic 프로세스 (Lv.2 경량 설계)**
   - 적용: Lv.2 작업에서 에이전트 미팅 없이 사용할 수 있는 경량 설계 대화 스킬
   - 이유: 현재 Lv.2 작업의 설계 프로세스 갭 해소. 에이전트 미팅(Lv.3+)과 즉시 코딩(Lv.1) 사이 빈 구간

5. **계획-실행 자동 체인 (writing-plans → subagent-driven-development)**
   - 적용: 3docs-create → DIRECT-WORKFLOW.md 실행의 연결을 더 자동화
   - 이유: superpowers처럼 계획 문서에 "실행 명령어 + 기대 출력"을 포함시키면 서브에이전트 지시 품질 향상

### 불필요 (9건) — 이미 보유 또는 미해당

6. **executing-plans**: 우리 환경은 항상 서브에이전트 가능. 불필요.
7. **subagent-driven-development**: 이미 보유 + 우리가 페르소나 고정/모델 차등화에서 우위.
8. **dispatching-parallel-agents**: 이미 보유 + 병렬 안전 규칙에서 우위.
9. **using-git-worktrees**: 이미 보유 + 자동화/머지 프로토콜에서 우위.
10. **finishing-a-development-branch**: 이미 보유. 아누 위임 설계가 더 적합.
11. **test-driven-development**: 이미 동등 수준 보유.
12. **systematic-debugging**: 동일 스킬 이미 설치.
13. **requesting-code-review**: 마아트 QC가 더 독립적이고 강력한 검증 제공. 2-pass 리뷰 분리는 선택적 개선.
14. **writing-skills**: skill-creator가 이미 커버. CSO 규칙은 Phase 2에서 보완 가능.

### 주의사항: superpowers vs 우리 시스템의 설계 철학 차이

- **superpowers**: 단일 개발자의 단일 Claude Code 세션 최적화. 모든 역할(설계자, 구현자, 리뷰어)을 하나의 에이전트가 서브에이전트로 수행.
- **우리 시스템**: 멀티봇 오케스트레이션. 설계(Opus 팀장) ≠ 구현(Sonnet 팀원) ≠ 검증(마아트/로키) 분리. 인간(제이회장님) → 오케스트레이터(아누) → 팀장 → 팀원 4계층 위임.
- **핵심 차이**: superpowers는 "하나의 에이전트가 자기 자신을 통제"하는 설계. 우리는 "다른 에이전트가 서로를 통제"하는 설계. 따라서 superpowers의 자기 통제 기법(합리화 방지, 완료 검증)은 우리 서브에이전트 레벨에 적용하면 시너지가 크지만, 워크플로우 체인(brainstorming→plans→execute)을 그대로 가져오면 우리 4계층 위임 구조와 충돌.

---

## 생성/수정 파일

- `/home/jay/workspace/memory/reports/task-605.1.md` (본 보고서) — 신규 생성

## 테스트 결과

리서치 작업으로 코드 변경 없음. 테스트 해당 없음.

## 버그 유무

없음.

## 비고

- superpowers GitHub 리포를 `gh api`로 직접 탐색하여 14개 스킬 전체를 확인함
- 작업 지시서에 언급된 "Performance Benchmarking", "Eval Framework", "Skill Description Optimization", "MCP Integration", "Project Kickoff"는 superpowers 리포에 독립 스킬로 존재하지 않음을 확인 (일부는 writing-skills 내 하위 기능)
- 우리 시스템 컨텍스트: 44개 스킬, 4-hook 체인, 20명 에이전트 조직도 참조