AIDive

영상 팩

Claude Code용 Superpowers: 판정표, 출처, 체크리스트, 더 알아보기 가이드

읽는 데 9분

TL;DR

  • Superpowers는 도구 모음이 아니라 프로세스입니다. 마크다운 스킬 14개가 모든 기능 작업을 브레인스토밍 세션, 작성된 계획, 리뷰를 거치는 새 서브에이전트 체인 뒤에 두는 방식입니다.
  • Claude Code 세션에서 몇 시간짜리 기능을 만든다면 설치하세요. 일회성 스크립트나 두 줄짜리 수정이 주된 사용이라면 건너뛰세요. 진입 체크는 모든 작업에서 실행되고 꺼지지 않습니다.
  • 토큰 절약 주장은 사실이지만, 스킬 하나의 한 섹션인 Model Selection에서 나옵니다. 오케스트레이터가 그 역할을 맡을 수 있는 가장 저렴한 모델을 배정하기 때문에, 비싼 모델은 아키텍처와 마지막 브랜치 리뷰에만 쓰입니다.
  • 저장소는 건강합니다. 별 280,597개, 포크 25,138개, main 커밋 681개, 2026-08-12 릴리스 v6.3.0, 생성일 2025-10-09입니다.
  • 이 영상의 발단이 된 불만, 즉 사용량 통계가 1~3%라는 것은 버그가 아닙니다. 스킬이 당신의 작업에서 한 번도 발동하지 않아서 게이트 비용만 내고 얻는 것은 없다는 뜻입니다.
  • 절충안은 프롬프트의 한 문장입니다. 사소한 수정에서는 프로세스를 건너뛰라고 에이전트에게 말하고, 며칠 동안은 브레인스토밍만 돌려 본 뒤 나머지를 도입하세요.

자료가 말하는 것

저장소 수치는 2026-09-02에 확인했습니다. 별 280,597개, 포크 25,138개, main 브랜치 커밋 681개이고, main의 마지막 커밋은 2026-08-12(v6.3.0)이며 2026-08-31에 main이 아닌 브랜치에 푸시가 한 번 더 있었습니다 s1. 같은 날 Issues 탭에는 열린 이슈가 125개였습니다. API가 돌려주는 350이라는 수치에는 열린 풀 리퀘스트 225개가 포함되어 있으니, 다른 플러그인과 비교할 때는 API 값이 아니라 탭의 값을 인용하세요 s6. 프로젝트는 2025-10-09에 만들어졌고 스킬 14개를 제공합니다 s2. 작성자의 출시 글은 이 프로젝트의 베팅을 한 줄로 설명합니다. 코딩 에이전트에게 부족한 것은 능력이 아니라 규율이고, 그 규율은 누구나 읽고 포크하고 고칠 수 있는 평범한 마크다운 파일로 배포할 수 있다는 것입니다 s5. 이 플러그인은 공식 마켓플레이스에 올라 있어서 설치는 명령 한 줄이고 업데이트도 마켓플레이스를 따라갑니다 s4.

진입점은 세션 시작 훅이 가장 먼저 불러오는 스킬입니다. 이 스킬은 에이전트에게, 어떤 스킬이 적용될지 조금이라도 의심스러우면 답하거나 코드를 쓰기 전에 그 스킬을 불러와 확인하라고 알려 줍니다. 이 규칙이 이점과 고정 비용을 모두 만들어 냅니다 s14.

브레인스토밍은 HARD-GATE로 시작합니다. 명확한 의도를 승인하기 전에는 코드도, 스캐폴딩도, 구현 스킬도 없습니다. 그런 다음 요청을 세 경로 중 하나로 분류합니다. 결과물이 코드가 아니라 답일 때는 spike, 저장소에 이미 있는 흐름 안의 작은 변경은 bounded, 프로젝트 구조를 바꾸는 모든 것은 architectural입니다. 에이전트는 분류를 알려 주므로 이의를 제기할 수 있고, 이 래칫은 한 방향으로만 움직입니다. 작업 도중 숨은 복잡성이 드러나면 경로는 올라가기만 하고 내려가지 않습니다 s9.

계획 작성 스킬은 당신의 코드베이스를 전혀 모르는 유능한 개발자, 파일의 표현을 빌리면 취향이 의심스러운 개발자를 위해 계획을 쓰라고 요구합니다. 작업은 단계마다 2~5분이 걸리는 태스크로 쪼개집니다. 실패하는 테스트 작성, 실패 확인을 위한 실행, 최소한의 코드 작성, 테스트 재실행, 커밋 순서입니다. 각 태스크에는 만들거나 수정할 정확한 파일이 줄 번호 수준까지 적히고, 계획은 필수 헤더로 시작합니다 s10.

실행은 서브에이전트 주도 개발 스킬이 맡습니다. 태스크마다 새 서브에이전트 하나, 태스크마다 리뷰 한 번, 마지막에 브랜치 전체 리뷰입니다. 메인 세션은 코딩을 멈추고 작업을 배분합니다. 각 서브에이전트는 자기 태스크의 컨텍스트만 받고 당신의 세션 이력은 받지 않으므로, 당신의 윈도우는 조율을 위해 비어 있습니다. 서브에이전트가 구현, 테스트, 커밋, 자기 리뷰를 마치면 오케스트레이터가 두 부분으로 된 리뷰를 돌립니다. 스펙 준수가 먼저, 코드 품질이 그다음이며, 태스크마다 리뷰어 자리가 따로 잡혀 있습니다. 이 파일은 루프를 태스크당 최대 5라운드로 제한합니다 s11. 작업 자체의 격리는 워크트리 스킬에 맡겨져 있어서, 계획이 현재 체크아웃 위에서 실행되는 일은 없습니다 s13.

Model Selection 섹션은 한 가지 규칙으로 시작합니다. 그 역할을 맡을 수 있는 가장 덜 강력한 모델을 쓰라는 것입니다. 파일 한두 개를 건드리는 명세가 잘 된 기계적 작업은 작은 모델로 가고, 계획에 이미 작성할 코드가 들어 있다면 구현은 옮겨 적기와 테스트일 뿐이므로 가장 저렴한 티어로 충분합니다. 여러 파일에 걸친 조율과 디버깅은 표준 모델로 갑니다. 아키텍처와 마지막 브랜치 리뷰에는 쓸 수 있는 가장 강력한 모델을 요구합니다. 실무에서 중요한 세부 사항이 둘 있습니다. 배분할 때마다 모델을 명시적으로 지정하고, 모델을 고르기 전에 오케스트레이터가 각 태스크의 난이도를 평가하게 하는 것입니다 s12. 월 20달러 Pro 플랜에서 비싼 모델을 감당할 수 있게 해 주는 메커니즘이 바로 이것입니다. 그럴 만한 결정에만 비싼 모델이 일합니다.

문서화 이득은 프로세스의 부산물입니다. 스펙과 계획은 사라지는 채팅 메시지가 아니라 저장소에 저장되고 작업과 함께 커밋되는 마크다운 파일이라서, 나중에 리뷰어는 무엇이 바뀌었는지만이 아니라 왜 바꿨는지를 읽을 수 있습니다 s3.

비용은 저장소가 내세우지 않는 부분입니다. 이 영상의 계기가 된 스레드는 사용량 통계가 1~3%라고 보고하며, 안 쓰는 것 말고 단점이 뭐냐고 묻습니다 s7. 파일에서 찾은 답은, 브레인스토밍이 작업 규모에 맞춰 의식의 크기를 조절하지만 사람의 승인을 건너뛰는 일은 없다는 것입니다 s9. 두 줄짜리 수정에서도 프레이밍 질문에 답하고, 두 문장짜리 설계를 승인하고, 전체 사이클이 끝나기를 기다려야 합니다. 배분용 브리프, 태스크당 두 번의 리뷰, 추적 장부는 매번 내는 토큰이고, 가장 작은 작업에서 그 부담이 가장 크게 드러납니다. 사용량 통계가 낮다는 것은 스킬이 당신의 작업과 맞지 않는다는 뜻이고, 읽어야 할 진짜 신호는 그것입니다.

사용 유형별 판정

Claude Code 사용 방식 설치? 이유
몇 시간씩 걸리고 파일이 여러 개이며 브랜치를 쓰는 기능 예 프레이밍이 엉뚱한 것을 만드는 일을 막고, 짧은 태스크가 에이전트를 컨텍스트 포화에서 멀리 두며, 모델 선택이 쿼터를 늘려 주고, 문서가 프로세스에서 저절로 나옵니다
혼합: 어떤 날은 기능, 대부분의 날은 수정 예, 건너뛰기 규칙과 함께 기능에는 게이트를 유지하고, 프롬프트에서 작은 수정은 프로세스를 건너뛰라고 에이전트에게 말합니다
일회성 스크립트, 설정 오타, 두 줄짜리 수정 아니요 필요 없는 작업에서도 게이트의 고정 비용이 실행됩니다
궁금하지만 방법론 전체를 도입할 준비는 안 됨 브레인스토밍만 이득의 대부분을 담고 있고, 나머지 스킬은 나중에 자연스럽게 붙습니다

월요일에 할 일

  • 공식 마켓플레이스에서 설치하고 플러그인 캐시를 열어 보세요. SKILL.md 14개를 한 번씩 읽으세요. 짧고, 그게 제품의 전부입니다.
  • 실제 기능 하나를 게이트에 처음부터 끝까지 통과시키세요. 브레인스토밍, 계획, 서브에이전트 배분, 브랜치 리뷰입니다. 수정 작업이 아니라 이 기능으로 프로세스를 판단하세요.
  • 일주일 뒤에 사용량 통계를 확인하세요. 몇 퍼센트 아래라면 스킬이 당신의 작업과 맞지 않는 것입니다. 작업이 너무 작거나, 요청을 기능 단위로 표현해야 합니다.
  • 프로젝트 지침에 건너뛰기 규칙을 추가하세요. 몇 줄 이하의 단일 파일 수정은 브레인스토밍 없이 바로 변경으로 갑니다.
  • 플러그인을 버리더라도 Model Selection 사다리는 직접 쓰는 서브에이전트 프롬프트에 복사해 두세요. 배분할 때마다 모델을 명시적으로 지정합니다.
  • 플러그인이 쓴 스펙과 계획을 지우지 말고 커밋하세요. 그것이 당신의 설계 기록입니다.
  • 이 프로젝트를 다른 플러그인과 비교하기 전에, 열린 이슈 수는 API 수치가 아니라 Issues 탭에서 세어 보세요.

더 알아보기

  • 스킬 파일보다 먼저 출시 글을 읽고 설계 의도를 파악하세요. 규율이 왜 코드가 아니라 마크다운으로 배포되는지 설명합니다 s5.
  • README의 philosophy 섹션은 방법론의 짧은 버전이며, 이미 쓰고 있는 작업 방식에 맞는지 확인하기 좋은 곳입니다 s3.
  • 스킬 라이브러리 섹션에는 14개 스킬이 한 줄 설명과 함께 나열되어 있어 디렉터리를 뒤지는 것보다 빠릅니다 s16.
  • 서브에이전트 스킬의 태스크당 최대 5라운드는 직접 짜는 어떤 오케스트레이션에도 그대로 가져다 쓸 만한 강제 중단 조건입니다 s11.
  • 한 스레드는 이런 종류의 플러그인이 더 강한 모델에서도 살아남는지 묻습니다. 살아남는 것은 프레이밍 게이트와 커밋된 계획이고, 모델이 흡수하는 것은 메커니즘입니다 s19.
  • 오케스트레이션 의식 때문에 주간 사용 한도가 소진되었다는 보고는, 작은 작업에 도입하기 전에 읽어야 할 반대 사례입니다 s20.
  • 경쟁 지침 세트와의 비교는 트레이드오프를 보여 줍니다. 적고 엄격한 스킬이냐, 방대한 규칙 카탈로그냐입니다 s18.
  • 열린 이슈 목록은 지금 다른 사용자들에게 무엇이 깨지는지 가장 빨리 읽는 방법입니다 s6.

출처

FAQ

Superpowers는 토큰을 아끼나요, 태우나요?

둘 다입니다. 기능 작업에서는 모델 선택이 기계적 태스크를 작은 모델로 보내고 비싼 모델은 아키텍처와 브랜치 리뷰에만 쓰므로 쿼터가 늘어납니다. 작은 수정에서는 브리프, 태스크당 두 번의 리뷰, 장부가 순수한 오버헤드입니다.

사용량 통계가 1~3%라는 건 무슨 뜻인가요?

스킬은 상황이 맞아떨어질 때만 발동합니다. 수치가 낮다는 것은 당신의 작업이 이 플러그인이 말하는 기능이 아니라는 뜻이고, 그래서 진입 체크 비용만 내고 보상이 있는 구간에는 도달하지 못합니다.

일부만 쓸 수 있나요?

네. 브레인스토밍만으로도 이득의 대부분을 얻고, Model Selection 사다리는 직접 쓴 어떤 서브에이전트 프롬프트에서도 작동합니다. 사소한 수정에서는 프로세스를 건너뛰라고 에이전트에게 말하면 통제권을 유지할 수 있습니다.