이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며#

Claude Code, Codex CLI, Cursor 등 코딩 에이전트(coding agent)를 매일 쓰는 백엔드 개발자라면 한 번쯤은 이런 경험이 있을 겁니다. “간단한 기능 하나만 추가해줘” 라고 했더니, 요구사항 정리 없이 코드를 우다다 쏟아내다가 절반쯤에서 길을 잃고, 테스트도 빠진 채 “완료했습니다” 라고 보고하는 경우 말입니다. 모델은 똑똑한데, 작업 방식이 들쭉날쭉해서 결과의 품질이 운에 좌우됩니다.

Jesse Vincent 가 만든 Superpowers 는 바로 이 지점을 노린 플러그인입니다. 모델을 더 똑똑하게 만드는 게 아니라, 모델이 언제, 어떤 순서로, 어떤 규율로 일해야 하는지를 강제하는 “방법론(methodology)” 자체를 플러그인 형태로 주입합니다.

이 시리즈는 4편으로 나누어 Superpowers 를 깊게 다룹니다. 1편에서는 무엇이고, 어떻게 동작하며, 어떻게 설치하는지 까지를 정리합니다. Java/Go 기반 백엔드 서비스를 Claude Code, Codex 등으로 개발하고 있는 중급 이상의 개발자를 가정하고 글을 씁니다.

Superpowers 란 무엇인가#

Superpowers 는 한 줄로 요약하면 “코딩 에이전트를 위한 완성된 소프트웨어 개발 방법론” 입니다. 저자 본인의 표현을 그대로 빌리자면:

Superpowers is a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them.

여기서 핵심 단어는 두 개입니다.

  • Composable skills: 잘게 쪼개진 단위 스킬들의 묶음. 각 스킬은 한 가지 작업(브레인스토밍, 계획 작성, TDD, 디버깅 등)을 어떻게 해야 하는지에 대한 규약과 체크리스트를 담고 있습니다.
  • Initial instructions that make sure your agent uses them: 에이전트 세션이 시작될 때 “관련 스킬이 있을 가능성이 1% 라도 있으면 무조건 먼저 호출하라” 고 강제하는 부트스트랩 지시문.

즉, Superpowers 는 “방법론 문서” 를 사람이 읽으라고 주는 게 아니라, 에이전트가 매 턴마다 자동으로 따라야 할 규칙으로 주입 합니다. 사용자가 매번 “이번엔 TDD 로 해줘”, “먼저 설계부터 같이 정리해줘” 라고 말하지 않아도, 에이전트가 알아서 그 흐름을 따라갑니다.

어떤 스킬들이 들어 있나#

저장소의 skills/ 디렉터리에는 다음과 같은 스킬들이 들어 있습니다.

프로세스 스킬(워크플로우 전체 흐름)

  • brainstorming — 코드 작성 전에 요구사항과 설계를 정리
  • writing-plans — 승인된 설계를 2~5분 단위의 태스크로 분해한 구현 계획서 작성
  • executing-plans — 사람이 중간 체크포인트를 두면서 계획을 실행
  • subagent-driven-development — 태스크별로 fresh subagent 를 띄워 자동 실행 + 2단계 리뷰
  • dispatching-parallel-agents — 서로 독립적인 작업을 병렬 서브에이전트로 분산
  • using-git-worktrees — 격리된 작업 공간(브랜치/worktree) 설정
  • finishing-a-development-branch — 완료 시 merge/PR/cleanup 결정 흐름

품질 보증 스킬

  • test-driven-development — RED-GREEN-REFACTOR Iron Law 강제
  • systematic-debugging — 4단계 root cause 조사 프로세스
  • verification-before-completion — “완료” 주장 전에 검증 명령 실행 강제
  • requesting-code-review / receiving-code-review — 코드 리뷰 의뢰와 응답 흐름

메타 스킬

  • using-superpowers — 모든 세션 시작 시 로드되는 부트스트랩 스킬
  • writing-skills — 새 스킬을 만들 때의 규약과 평가 방법

각 스킬의 구체적인 동작은 2편과 3편에서 다룹니다. 1편에서는 “이런 게 들어있구나” 정도만 알아두면 됩니다.

Hello, Superpowers — 첫 인상#

설치 직후 가장 인상적인 경험은 보통 이런 식입니다. Claude Code 에 다음과 같이 입력해 봅니다.

Let's make a react todo list

Superpowers 가 설치되지 않은 세션이라면, 에이전트는 곧장 package.json 을 만들고 컴포넌트 파일을 휘갈기기 시작합니다. 하지만 Superpowers 가 설치된 세션이라면, 코드를 한 줄도 쓰기 전에 다음과 같은 일이 일어납니다.

  1. using-superpowers 부트스트랩이 자동 로드되어 “스킬을 먼저 확인하라” 는 규칙이 활성화됩니다.
  2. “기능을 만들자” 는 의도가 감지되면 brainstorming 스킬이 자동으로 트리거됩니다.
  3. 에이전트가 코드를 쓰는 대신, 한 번에 하나씩 질문을 던지기 시작합니다 — “어떤 todo 항목을 다루나요? 그 항목의 필드는?”, “데이터는 메모리에만? 로컬스토리지? 서버?”, “스타일링 라이브러리는 정해두셨나요?” …
  4. 답변이 모이면 2~3개의 접근법을 비교 제시하고, 사용자 승인 후 설계 문서를 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 로 저장합니다.

이 과정을 사용자가 따로 요청하지 않아도 알아서 한다는 점이 Superpowers 의 출발점입니다.

왜 만들어졌는가 — 해결하려는 문제#

Superpowers 가 해결하려는 문제는 사실 코딩 에이전트를 깊게 써본 사람이라면 누구나 부딪히는 문제들입니다.

1. 코드부터 쓰고 보는 성급함#

요구사항을 충분히 파악하기 전에 키보드부터 두드리는 습관은 사람에게도, 에이전트에게도 있습니다. 에이전트의 경우 더 심각한 것이, 잘못된 가정으로 한 시간 작업한 결과물을 통째로 버려야 하는 일 이 종종 발생합니다. 컨텍스트도 그만큼 오염됩니다. brainstorming 스킬은 이 패턴을 깨기 위한 “hard gate” 로, 사용자가 명시적으로 설계를 승인하기 전까지 어떤 구현 액션도 차단합니다.

2. “테스트는 나중에”#

TDD 가 좋다는 건 누구나 알지만, 에이전트에게 시키면 거의 항상 코드 먼저 작성하고 마지막에 테스트를 끼워 맞춥니다. test-driven-development 스킬의 Iron Law 는 이를 다음과 같이 못박습니다.

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

테스트 없이 작성한 코드는 삭제하고 다시 시작 합니다. “참고용으로 남겨두지 말 것, 보지도 말 것” 까지 명시되어 있습니다. 이 정도로 강하게 박아두지 않으면 모델이 빠져나갈 구멍을 찾기 때문입니다.

3. 검증 없는 “완료” 보고#

에이전트가 “테스트 모두 통과합니다, 빌드 성공입니다” 라고 보고했는데 실제로는 명령을 한 번도 실행하지 않은 경우가 흔합니다. verification-before-completion 스킬은 다음을 강제합니다.

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

“이번 메시지에서 검증 명령을 실행하지 않았다면, 통과한다고 주장할 수 없다.” 라는 규칙입니다. Java 백엔드라면 ./gradlew test, Go 라면 go test ./... 의 신선한 출력을 보지 않은 채로는 완료 보고를 못 합니다.

4. 디버깅 시의 추측 남발#

버그가 발견되면 에이전트는 종종 “이게 원인 같다” 며 추측에 기반한 패치를 마구 던집니다. systematic-debugging 의 Iron Law:

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

증상 패치(symptom fix)는 실패로 간주되며, 4단계 root cause 조사 프로세스를 모두 거친 뒤에야 수정안을 제안할 수 있습니다.

5. 컨텍스트 오염#

긴 작업에서 가장 큰 적은 컨텍스트 오염입니다. 한 세션에서 5개 태스크를 연달아 처리하면, 3번째 태스크 즈음에는 이전 시도의 실패 흔적, 다른 파일의 무관한 코드, 사용자의 잡담까지 모두 모델의 판단을 흐립니다. subagent-driven-development 는 태스크마다 fresh subagent 를 띄워서 정확히 필요한 정보만 주입하고, 그 결과만 받아오는 방식으로 이를 해결합니다.

자동 트리거의 비밀 — using-superpowers 부트스트랩#

Superpowers 를 처음 써본 사람이 가장 신기해하는 부분은 “내가 아무것도 안 했는데 알아서 워크플로우를 따라간다” 는 점입니다. 이게 어떻게 가능한가요?

핵심은 using-superpowers 라는 메타 스킬입니다. 이 스킬은 세션이 시작되는 순간 로드되며, 다음과 같은 강력한 규칙을 에이전트의 행동 지침에 박아 넣습니다.

If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.

즉, 어떤 사용자 메시지를 받든 — 심지어 단순한 질문조차 — 에이전트는 먼저 관련 스킬이 있는지 확인 하고 호출해야 합니다. 그리고 각 스킬의 frontmatter 에는 description 필드에 “이 스킬을 언제 써야 하는지” 가 명시되어 있어, 에이전트가 사용자 의도와 매칭할 수 있게 되어 있습니다.

예를 들어 brainstorming 스킬의 description 은:

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

“기능 추가하자”, “이거 좀 바꿔보자” 류의 메시지가 들어오면 description 매칭으로 brainstorming 이 자동 호출되고, 코드 한 줄 쓰기 전에 hard gate 가 걸리는 구조입니다.

이 부트스트랩이 제대로 로드되었는지 여부가 “진짜 통합” 의 기준입니다. 저장소의 기여 가이드라인에서도 새 harness 지원 PR 에 대해 다음 수용 테스트를 명시하고 있습니다.

깨끗한 세션을 열고 정확히 이 메시지를 보낸다: “Let’s make a react todo list” 정상 통합이라면 코드 작성 전에 brainstorming 스킬이 자동 트리거된다.

설치 후 이 테스트만 통과하면 Superpowers 가 제대로 살아있는 것이고, 통과하지 못한다면 부트스트랩이 로드되지 않은 것입니다.

지원 환경과 설치#

Superpowers 는 단일 코딩 에이전트 도구에 종속되지 않습니다. 현재 다음 환경을 공식 지원합니다.

Harness 설치 명령
Claude Code (공식 마켓플레이스) /plugin install superpowers@claude-plugins-official
Claude Code (Superpowers 마켓플레이스) /plugin marketplace add obra/superpowers-marketplace 후 /plugin install superpowers@superpowers-marketplace
Codex CLI /plugins → superpowers 검색 → Install
Codex App Plugins 사이드바 → Coding 섹션에서 + 클릭
Factory Droid droid plugin marketplace add https://github.com/obra/superpowers 후 droid plugin install superpowers@superpowers
Gemini CLI gemini extensions install https://github.com/obra/superpowers
OpenCode OpenCode 채팅에 Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md 입력
Cursor Cursor Agent 채팅에서 /add-plugin superpowers
GitHub Copilot CLI copilot plugin marketplace add obra/superpowers-marketplace 후 copilot plugin install superpowers@superpowers-marketplace

주의: 한 머신에서 여러 harness 를 같이 쓴다면 각 harness 별로 따로 설치해야 합니다. 설치가 공유되지 않습니다.

Claude Code 사용자가 흔히 헷갈리는 두 마켓플레이스#

Claude Code 에는 Superpowers 가 두 마켓플레이스에 동시에 올라와 있습니다.

  • Anthropic 공식 마켓플레이스(claude-plugins-official): Anthropic 이 관리. 안정 버전 위주. 업데이트가 한 박자 느릴 수 있습니다.
  • Superpowers 마켓플레이스(superpowers-marketplace): 저자 Jesse Vincent 가 직접 관리. 최신 버전과 관련 추가 플러그인(예: 마켓플레이스의 다른 보조 도구) 접근 가능.

최신 기능을 빨리 받고 싶다면 Superpowers 마켓플레이스를, 안정성을 우선한다면 공식 마켓플레이스를 추천합니다. 둘을 동시에 설치하면 충돌 가능성이 있으니 하나만 선택하세요.

설치 직후 동작 확인 체크리스트#

설치 후 다음을 확인하면 부트스트랩이 살아있는지 알 수 있습니다.

  1. 깨끗한 새 세션을 시작한다 (이전 대화 컨텍스트가 없도록).
  2. Let's make a react todo list 와 같이 명확히 새 기능을 만들자 는 메시지를 보낸다.
  3. 에이전트가 코드를 쓰기 전에 brainstorming 스킬을 호출하고 질문을 던지면 정상.
  4. 곧장 package.json 을 만들거나 컴포넌트 코드를 작성하기 시작한다면, 부트스트랩이 로드되지 않은 것이므로 재설치가 필요합니다.

핵심 철학 — 네 줄로 요약#

Superpowers 가 명시적으로 표방하는 철학은 네 가지입니다.

  • Test-Driven Development — 테스트 먼저, 항상.
  • Systematic over ad-hoc — 추측보다는 프로세스.
  • Complexity reduction — 단순함을 일차 목표로.
  • Evidence over claims — 주장하기 전에 검증.

이 네 가지는 단순한 슬로건이 아니라, 각 스킬 안에서 “Iron Law” 라는 이름의 강한 규칙으로 구현되어 있습니다. 에이전트가 “이번엔 좀 빠르게 가자” 며 빠져나가려 해도 스킬 내부의 “Red Flags” 표가 그 합리화를 차단합니다. 예를 들어 using-superpowers 의 Red Flags 표 일부:

합리화하는 생각 실제로는
“이건 그냥 간단한 질문이잖아” 질문도 태스크다. 스킬을 확인하라.
“먼저 컨텍스트를 좀 더 모아야겠어” 스킬 확인이 질문보다 먼저다.
“코드베이스부터 살짝 둘러보자” 스킬이 어떻게 둘러볼지 알려준다. 먼저 확인하라.
“이 스킬은 오버킬이야” 단순한 일이 복잡해진다. 그냥 써라.
“한 번만 빨리 처리하고 나서…” 어떤 행동이든 전에 먼저 확인하라.

이런 규칙들이 빽빽하게 박혀있기 때문에, 사용자는 “이번엔 가볍게 가자” 고 굳이 말하지 않는 한 자연스럽게 규율 잡힌 워크플로우 안에 머물게 됩니다.

다음 편 미리보기#

1편에서는 Superpowers 가 무엇이고, 어떻게 자동 트리거되며, 어떻게 설치하는지를 다뤘습니다.

다음 편(Part 2)에서는 핵심 워크플로우 를 자세히 들여다봅니다.

  • brainstorming 이 실제로 던지는 질문의 형태와 design doc 산출물
  • using-git-worktrees 가 격리 작업 공간을 만드는 방식
  • writing-plans 가 작업을 2~5분 단위로 쪼개는 기준
  • subagent-driven-development 와 executing-plans 의 차이와 선택 기준
  • Go 백엔드 서비스에 새 API 엔드포인트를 추가하는 실전 시나리오

3편에서는 TDD/디버깅/검증 같은 품질 보증 스킬들을, 4편에서는 /superpowers:xxx 명시 호출과 자동 트리거의 비교 분석 및 Java/Go 백엔드 개발 현장에서의 활용 팁을 다룰 예정입니다.

References#