⚡
★ 86.6k

Chapter 10: 자주 묻는 질문 (FAQ)

일반

어디서부터 시작하면 될까요?

Superpowers를 처음 접하셨다면, 다음 읽기 순서를 추천합니다:

  1. Chapter 0: 환영합니다 — Superpowers가 무엇이고 누구를 위한 것인지 이해하기
  2. Chapter 1: 시작하기 — 환경 설정 및 첫 번째 skill 실행하기
  3. Chapter 2: 브레인스토밍 — 코드를 작성하기 전에 아이디어를 탐색하는 방법 배우기
  4. Chapter 3: 계획 작성 — 아이디어를 구조화된 구현 계획으로 전환하기
  5. Chapter 9: Iron Laws — 모든 것을 작동하게 만드는 핵심 원칙

이후 워크플로에 맞는 챕터를 살펴보세요: TDD (Chapter 5), 디버깅 (Chapter 6), 코드 리뷰 (Chapter 7), 또는 Git Worktrees (Chapter 8).

또한 실전 활용 사례 섹션을 확인하여 Superpowers가 실제 시나리오에서 어떻게 적용되는지 살펴보세요 — 솔로 기능 개발부터 팀 디버깅, 병렬 리팩토링까지.

Superpowers는 어떤 플랫폼을 지원합니까?

Superpowers는 여러 AI 코딩 플랫폼과 함께 작동하도록 설계되었습니다:

플랫폼상태참고 사항
Claude Code완전 지원주요 플랫폼; 모든 기능 사용 가능
Cursor완전 지원v4.3.1 (2026년 2월)에서 공식 지원 추가
Gemini CLI완전 지원v5.0.1 (2026년 3월)에서 extension 지원 추가
Codex실험적v3.3.0 (2025년 10월)부터 사용 가능
OpenCode지원됨v3.5.0에서 추가

각 플랫폼은 동일한 skill 파일과 CLAUDE.md 설정을 사용합니다. 플랫폼별 차이점(있는 경우)은 해당 지원을 도입한 버전의 릴리스 노트에 문서화되어 있습니다.

Superpowers는 일반 AI 코딩 agent와 어떻게 다릅니까?

Superpowers 없이 AI 코딩 agent를 사용하는 것은 안전 매뉴얼 없이 강력한 도구를 사용하는 것과 같습니다. Agent는 유능하지만 품질에 대한 강제된 규율이 없고, 체계적인 debugging 프로토콜도 없으며, 가장 일반적인 실패 모드에 대한 안전장치도 없습니다.

Superpowers를 사용하면:

  • 모든 기능은 실패하는 test로 시작합니다. "구현하고 바라는" 방식은 없습니다.
  • 모든 완료 선언은 증거를 필요로 합니다. "작동해야 합니다"는 없습니다.
  • 모든 버그는 근본 원인 조사를 필요로 합니다. 추측은 없습니다.
  • Skills는 도메인별 best practice를 강제합니다. Agent는 각 작업 유형에 맞는 올바른 접근 방식을 자동으로 따릅니다.
  • 코드를 작성하기 전에 계획을 작성합니다. 아키텍처 결정은 프로덕션이 아닌 계획 단계에서 이루어집니다.

결과는 더 느린 agent가 아닙니다 — 신뢰할 수 있는 작업을 하는 agent입니다. debugging, 되돌리기, 엉킨 codebase를 풀어내는 데 절약되는 시간이 초기 엄격함을 충분히 보상합니다.

팀에서 Superpowers를 사용할 수 있습니까?

예. Superpowers는 AI agent를 사용하는 모든 팀원에게 일관된 관행을 강제하기 때문에 팀 환경에 특히 적합합니다.

권장 팀 설정:

  1. CLAUDE.md를 repository에 commit하세요. 모든 팀원이 동일한 설정을 사용합니다. 프로젝트에서 작업하는 AI agent는 동일한 규칙을 적용합니다.
  2. .claude/skills/ 디렉토리를 commit하세요. Skills가 공유됩니다. 프로젝트를 위해 만든 custom skill은 모든 사람이 사용할 수 있습니다.
  3. Worktree 격리 정책을 시행하세요. 각 개발자와 각 AI agent는 격리된 worktree에서 작업합니다. Main branch 보호 규칙이 직접 commit을 방지합니다.
  4. PR 기반 code review를 사용하세요. Code review 프로토콜(Chapter 7)은 GitHub/GitLab workflow와 직접 통합됩니다.

이 설정으로 한 팀원을 위해 작업하는 AI agent는 다른 팀원을 위해 작업하는 AI agent — 또는 팀의 코딩 표준을 따르는 인간 개발자 — 와 동일한 기준을 따릅니다.

TDD & 품질

TDD는 필수입니까? 예외가 있습니까?

예. TDD는 필수입니다. 예외는 없습니다.

이것이 Iron Law 1입니다: "NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST."

예외에 대한 일반적인 주장과 그것이 거부되는 이유:

"작은 변경입니다." 작은 변경도 버그를 도입합니다. 작은 변경에 대한 test 작성 시간 비용은 분 단위로 측정됩니다. 테스트되지 않은 작은 변경으로 인한 regression을 debugging하는 시간 비용은 시간 단위로 측정됩니다.

"빠르게 진행 중입니다, 나중에 test를 추가하겠습니다." 구현 후에 추가된 test는 요구사항이 아닌 구현을 기반으로 형성됩니다. 코드가 해야 하는 것이 아닌 코드가 하는 것을 test합니다. 거짓 확신을 제공합니다. "나중에"는 거의 오지 않습니다.

"코드가 UI입니다, test하기 어렵습니다." UI 동작은 test할 수 있습니다. Component test, snapshot test, interaction test, end-to-end test 모두 존재합니다. 어려움은 면제가 아닙니다.

"이 코드가 올바르다는 것을 알고 있습니다." 이것이 가장 위험한 주장입니다. 미래의 자신이나 동료는 현재의 확신을 공유하지 않습니다. Test는 그 확신을 문서화하고 보존합니다.

각 작업 유형에 권장되는 모델은 무엇입니까?

모델 선택은 작업 요구사항에 따라 다릅니다:

작업 유형권장 모델이유
아키텍처 계획, 복잡한 추론Claude Opus 4.6 (Thinking 모드)확장된 추론이 더 나은 계획을 생성합니다
기능 구현, TDDClaude Sonnet 4.5속도와 품질의 균형
Code review, debuggingClaude Sonnet 4.5강력한 분석 능력
간단한 refactoring, 포맷팅Claude Haiku 3.5기계적 작업에 빠르고 비용 효율적
Multi-agent 병렬 작업Claude Haiku 3.5 (subagent)규모에서 비용 효율적

Gemini CLI 사용자: 구현 작업에는 Gemini 2.0 Flash를, 아키텍처 및 계획에는 Gemini 2.5 Pro를 권장합니다.

Cursor 사용자: 기능 작업에는 Cursor의 composer에서 Claude Sonnet 모델을 사용하세요. Cursor의 내장 chat은 빠른 질문에 더 작은 모델을 사용할 수 있습니다.

이 가이드에 설명된 Iron Laws와 프로토콜은 어떤 플랫폼을 사용하든 적용됩니다. 특정 호출 메커니즘은 다르지만 강제하는 동작은 동일합니다.

문제 해결

Skill이 올바르게 trigger되지 않습니다. 어떻게 해야 합니까?

  1. Skill 파일이 플랫폼에 맞는 올바른 위치에 있는지 확인하세요.
  2. Skill 파일의 trigger 설명을 확인하세요. Trigger 조건은 호출에 사용하는 언어와 일치해야 합니다.
  3. 명시적으로 하세요. Agent가 올바른 skill을 추론하기를 바라는 대신, 직접 이름을 지정하세요: "이것에 superpowers:systematic-debugging skill을 사용하세요."
  4. 충돌을 확인하세요. 두 개의 skill이 겹치는 trigger 조건을 가지고 있으면 agent가 잘못된 것을 선택할 수 있습니다. Skill 설정을 검토하세요.
  5. Skill 파일을 다시 읽으세요. Skills는 codebase가 변경될 때 오래될 수 있습니다. Skill이 올바르게 trigger되고 있지만 더 이상 적용되지 않는 조언을 생성할 수 있습니다.