Claude Code를 처음 쓰다 보면 패턴 하나를 금방 알아챈다. 요청을 내리면 모델이 즉각 코드 작성에 뛰어든다. 빠르긴 한데, 방향이 틀리거나 맥락을 잘못 잡으면 되돌리는 데 더 많은 토큰이 들어간다. Superpowers는 이 실패 모드를 막겠다는 목적으로 만들어진 오픈소스 플러그인이다. 5월 4일 v5.1.0이 나왔다.
Jesse Vincent가 만들고 Prime Radiant 팀이 함께 개발하는 이 프로젝트는 MIT 라이선스로 공개되어 있다. Anthropic 공식 플러그인 마켓플레이스에도 등재됐고, Claude Code 외에 Codex CLI, Gemini CLI, Cursor, GitHub Copilot CLI에서도 설치된다. GitHub 스타는 이미 39k를 넘었다.
설치는 한 줄이다. Claude Code 사용자라면 채팅창에 다음을 입력하면 된다.
/plugin install superpowers@claude-plugins-official
다른 환경을 쓴다면 각 플랫폼에 맞는 명령이 있다. Gemini CLI는 gemini extensions install https://github.com/obra/superpowers`, Cursor는/add-plugin superpowers, GitHub Copilot CLI는copilot plugin install superpowers@superpowers-marketplace다. 설치 후 전역 적용이 필요하면claude skill install superpowers –global옵션도 지원한다. 설치가 완료되면 이후 대화에서 자동으로using-superpowers` 마스터 스킬이 활성화되어 요청 유형에 따라 적절한 스킬이 자동 라우팅된다.
무엇이 문제였는가
LLM 기반 코딩 에이전트의 근본적인 취약점은 “곧바로 구현에 뛰어든다”는 점이다. 요청이 모호하더라도 모델은 가장 그럴듯한 해석을 골라 코드를 생성하기 시작한다. 그 해석이 맞을 수도 있지만, 틀렸을 때는 이미 수백~수천 토큰을 태운 뒤다. 더 큰 문제는 틀린 방향으로 생성된 코드가 다시 컨텍스트에 쌓이면서 이후 수정도 그 방향을 기준으로 이뤄진다는 것이다. 코드가 아니라 방향이 잘못된 것인데 코드를 고치는 악순환이 이어진다.
Superpowers의 설계는 이 문제를 근본에서 차단하려 한다. 코드 작성 전에 반드시 다섯 단계를 거치게 만드는 것이다. 명확화(Clarify) → 설계(Design) → 계획(Plan) → 구현(Code) → 검증(Verify). 이 흐름을 14개의 스킬 파일로 구조화해두고, 에이전트가 각 단계에서 스킬을 호출해 강제로 프로세스를 따르도록 한다.
스킬 파일이 작동하는 방식
Superpowers의 스킬은 마크다운(Markdown) 파일이다. 특별한 런타임이나 새로운 도구가 아니라, 에이전트가 읽고 따르는 지시 문서에 가깝다. 그런데 이것이 실제로 동작하게 만드는 데 상당한 설계가 들어갔다.
프로젝트 리드는 스킬 파일의 준수율을 높이기 위해 로버트 치알디니(Robert Cialdini)의 설득 원칙 세 가지를 명시적으로 적용했다고 밝혔다. 첫째, 권위(Authority): 각 스킬 파일이 스스로를 “반드시 따라야 한다”고 선언한다. 모델은 이를 옵션이 아닌 규칙으로 등록한다. 둘째, 일관성(Consistency): 에이전트가 특정 스킬을 따르겠다고 선언하도록 유도한 뒤, 방금 선언한 것과 일관되게 행동하도록 nudge한다. 셋째, 사회적 증명(Social proof): 스킬 파일 안에 “다른 모든 스킬도 이렇게 작동한다”는 내용을 포함시켜 에이전트가 이를 표준으로 인식하게 만든다.
AI에게 지시를 내릴 때 심리학적 설득 원리가 효과가 있다는 사실이 흥미롭다. 이는 LLM이 훈련 데이터에서 인간의 사회적 행동 패턴을 학습했기 때문에, 인간 사이에서 작동하는 설득 기법이 모델에도 어느 정도 통한다는 것을 시사한다.
이미지 출처: Unsplash
14개 스킬, 각각의 역할
v5.1.0 기준으로 Superpowers는 14개의 스킬을 포함한다. 단순한 기능 목록이 아니라, 각각이 특정 실패 모드를 막는 방어선으로 설계돼 있다.
brainstorming — 기능 추가나 컴포넌트 구축 요청이 들어오면 가장 먼저 호출된다. “단순해 보여도 설계를 건너뛰지 않는다”는 게 첫 번째 규칙이다. 에이전트는 사용자에게 한 번에 하나씩만 질문하고, 2~3가지 접근법을 장단점과 함께 제시한 뒤 승인을 받아야 다음 단계로 넘어간다. 설계 문서는 docs/superpowers/specs/ 에 저장된다. 이 단계를 거치지 않으면 다음 스킬들로 넘어가지 않는다.
writing-plans — brainstorming으로 설계가 확정되면 곧바로 실행 계획을 문서화한다. 각 작업 단위를 2~5분 내에 끝낼 수 있는 크기로 쪼개고, 모든 코드 스텝에는 완전한 예시 코드와 정확한 파일 경로를 붙인다. “TBD”나 “TODO” 같은 플레이스홀더는 금지다. 계획을 읽는 사람이 맥락 없이도 각 작업을 독립적으로 이해할 수 있어야 한다는 게 원칙이다.
subagent-driven-development — 계획이 완성되면 이 스킬이 실행 을 맡는다. 각 작업마다 새로운 서브에이전트를 파견하고, 완료 후 두 단계 검토를 거친다. 첫 번째는 스펙 준수 검토(명세대로 만들어졌는가), 두 번째는 코드 품질 검토(코드 자체가 좋은가)다. 이 두 검토는 순서가 고정돼 있고, 이슈가 발견되면 “충분히 좋음”은 없다. 수정 후 재검토가 의무다.
test-driven-development — 스킬 파일에 박힌 원칙은 하나다. “NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.” 이미 코드를 작성했다면 삭제하고 처음부터 시작하라고 명시하고 있다. RED(실패하는 테스트 작성) → GREEN(최소한의 코드로 통과) → REFACTOR(테스트 유지하며 정리) 사이클을 강제한다. 테스트가 작성하자마자 바로 통과되면, 그건 새 동작을 검증하는 게 아니라 기존 동작을 문서화하는 것뿐이라며 재검토를 요구한다.
systematic-debugging — 버그를 만났을 때 에이전트가 빠지기 쉬운 패턴이 있다. 그럴듯해 보이는 곳을 하나씩 바꿔가며 원인을 추측하는 “랜덤 수정”이다. 이 스킬은 “근본 원인 조사 없이는 수정 제안 금지”를 첫 번째 규칙으로 박아둔다. 오류 메시지를 읽고, 재현 조건을 확인하고, 작동하는 케이스와 비교한 뒤, 단일 가설을 세우고 최소한의 변경으로 테스트한다. 세 번 이상 수정 시도가 실패하면 아키텍처 자체를 재검토하라는 신호로 해석한다. 시간 압박이 클수록 이 스킬이 더 필요하다고 파일에 명시하고 있다.
verification-before-completion — “완료됐습니다”를 말하기 전에 반드시 거쳐야 하는 체크포인트다. 성공 주장을 뒷받침할 명령을 실행하고, 출력을 실제로 읽고, 그 출력이 주장을 지지하는지 확인한다. “이전 실행에서 됐으니까”, “잘 됐을 것 같으니까”는 허용되지 않는다. 이전 성공이나 확신도 핑계로 인정하지 않는다는 표현이 파일 안에 그대로 적혀 있다.
dispatching-parallel-agents — 서로 다른 원인에서 비롯된 테스트 실패가 3개 이상 있고, 각 문제를 독립적으로 이해할 수 있을 때 활성화된다. 공유 상태가 없는 독립적인 실패들을 순차적으로 디버깅하는 건 시간 낭비라는 판단이다. 각 문제 영역에 범위와 목표가 명확한 에이전트를 파견해 병렬로 처리하고, 결과를 취합해 전체 테스트를 재실행한다. 관련된 실패들은 함께 조사해야 하기 때문에 이 스킬 적용 대상이 아니다.
requesting-code-review / receiving-code-review — 코드 리뷰를 요청하는 쪽과 받는 쪽을 각각 별도 스킬로 분리해둔 것이 눈에 띈다. 리뷰를 요청할 때는 계획 대비 실제 구현 차이를 명시하고, 심각도별로 이슈를 분류해 보고한다. 리뷰를 받는 쪽은 “기술적으로 의심스럽거나 불명확한 피드백은 맹목적으로 따르지 말고 검증하라”는 원칙을 담고 있다. AI 에이전트가 리뷰어의 피드백을 무조건 수용하는 것도 문제가 될 수 있다는 인식이다.
using-git-worktrees / finishing-a-development-branch — 작업 격리와 완료를 다루는 한 쌍이다. worktrees 스킬은 기능 작업을 시작하기 전에 현재 워크스페이스에서 격리된 Git 워크트리를 생성해 독립적인 실험 공간을 확보한다. finishing-a-development-branch는 구현이 끝난 뒤 테스트 검증, 병합 또는 PR 생성 여부를 결정하는 흐름을 안내한다.
using-superpowers / writing-skills — 마지막 두 스킬은 메타 레이어다. using-superpowers는 마스터 디스패처로, 사용자 요청의 성격에 따라 어떤 스킬을 어떤 순서로 호출해야 하는지 결정한다. writing-skills는 새 스킬을 만드는 방법 자체를 설명하는 스킬로, 팀이나 프로젝트 고유의 워크플로우를 Superpowers 체계 안에 추가할 수 있도록 설계돼 있다.
수치로 본 효과
공개된 사용자 데이터에 따르면, Superpowers 적용 후 첫 시도 코드 품질이 평균 40% 향상됐고 토큰 소비는 30% 감소했다. 명확화 단계에서 오해를 초기에 걸러내기 때문에, 방향 수정에 들어가는 비용이 줄어드는 효과다. 시각 디자인을 다루는 작업에서는 “Visual Companion” 기능이 브라우저 대시보드에 레이아웃 목업과 색상 옵션을 코딩 전에 보여줘, 스타일 관련 재작업이 거의 사라졌다는 보고도 있다.
단점도 명확하다. 간단한 수정 작업에도 5단계 프로세스가 붙으면 오버헤드가 상당하다. 스킬 파일이 컨텍스트 윈도우 약 8천 토큰을 차지한다는 점도 감안해야 한다. Claude Sonnet 이상의 모델을 권장하며, 무료 티어 모델에서는 스킬 준수율이 낮아진다.
더 넓은 의미
Superpowers가 흥미로운 건 단순히 “Claude Code를 더 잘 쓰는 방법”이기 때문만이 아니다. 이 프로젝트는 AI 에이전트에게 규율을 주입하는 방법론이 아직 표준화되지 않았다는 현실을 보여준다. 공식 API나 시스템 프롬프트만으로는 에이전트의 행동을 충분히 통제하기 어렵기 때문에, 커뮤니티가 직접 심리학적 설득 원리까지 동원한 마크다운 파일을 만들어내고 있는 것이다.
인간 개발자라면 암묵적으로 따르는 엔지니어링 문화 — 계획 먼저, 테스트 먼저, 검증 후 병합 — 를 AI 에이전트에게 이식하는 작업이 얼마나 비자명한지를 Superpowers의 설계가 역설적으로 드러낸다. v5.1.0이 나온 시점에서 GitHub 스타 39k를 넘었다는 사실은, 이 불편함을 느끼는 개발자가 적지 않다는 방증이다. 앞으로 이런 “에이전트 규율 레이어”가 IDE 수준으로 통합될지, 아니면 모델 자체가 이 규율을 내재화해 플러그인을 무용화할지가 흥미로운 관전 포인트다.
출처