스타 280,000개의 플러그인
Superpowers는 1990년대부터 오픈소스 개발 도구를 만들어 온 Jesse Vincent가 작성한 Claude Code용 플러그인입니다. 그는 10월에 이 플러그인을 공개했고, 1년도 지나지 않아 저장소는 스타 280,000개와 포크 25,000개를 기록했으며, 마지막 푸시는 저희가 녹화하기 이틀 전에 올라왔습니다. 프로젝트는 이미 여섯 번째 메이저 버전이고 메인 브랜치에 커밋이 681개 쌓여 있으니, 출시 때 잠깐 반짝하고 버려진 프롬프트 모음집은 아닙니다.
| 지표 | 값 |
|---|---|
| GitHub 스타 | 280,000 |
| 포크 | 25,000 |
| 메이저 버전 | 6 |
| 메인 브랜치 커밋 | 681 |
| 열린 이슈 | 125 |
Vincent의 승부수는 한 문장으로 정리됩니다. 코딩 에이전트에게 부족한 것은 능력이 아니라 규율이라는 것입니다. 그 규율은 누구나 읽고, 포크하고, 고쳐 쓸 수 있는 평범한 마크다운 파일 형태로 제공됩니다. 저희는 플러그인을 설치하고 14개 스킬을 한 줄 한 줄 모두 읽은 뒤, 생산성, 코드 신뢰성, 토큰 소비, 문서화라는 네 가지 측면에서 무엇이 달라지는지 살펴봤습니다.
Superpowers는 실제로 무엇인가
Superpowers는 Claude Code용 무료 오픈소스 플러그인입니다. Anthropic 공식 플러그인 마켓플레이스에 올라와 있고 명령어 한 줄로 설치됩니다. 같은 방법론이 Cursor, Codex, Gemini를 포함한 열두 개 이상의 다른 하네스에도 존재하며, 각각 별도의 설치 경로를 갖습니다.
핵심은 14개의 스킬입니다. 상황이 맞을 때마다 에이전트가 불러오는 마크다운 지시 파일입니다. 브레인스토밍, 플랜 작성, 서브에이전트 주도 개발, 테스트 주도 개발, 체계적 디버깅은 각각 자체 체크리스트와 가드레일을 갖춘 완전한 작업 방식을 담고 있습니다. 디버깅 스킬은 근본 원인을 분리하기 전에 수정안을 제시하는 것을 금지합니다. 검증 스킬은 에이전트가 작업이 끝났다고 주장하는 대신 끝났음을 증명하게 만듭니다. 각 스킬은 로드될 때 스스로를 알리기 때문에 에이전트가 지금 어떤 모드로 일하는지 항상 알 수 있습니다.
세션 시작 시 실행되는 훅은 Claude가 모든 작업 전에 이 스킬 중 해당되는 것이 있는지 확인하도록 강제합니다. 규칙은 진입 스킬에 명시되어 있습니다. 스킬이 관련될 확률이 1%라도 있으면 에이전트는 그 스킬을 로드해야 합니다. 그 결과는 도구 상자보다는 에이전트에 주입된 개발 방법론에 가깝게 동작합니다.
Vincent는 블로그에서 탄생 배경을 설명합니다. 그는 자신의 에이전트들이 배운 교훈이 담긴 2,249개의 마크다운 파일을 분석해 스킬을 만들었고, 초안을 같은 아카이브에 다시 대조하여 압박 테스트했습니다. 이 방법론은 이론에서 쓴 것이 아니라 실제 에이전트의 실패에서 추출한 것입니다.
브레인스토밍: 코드 전의 관문
브레인스토밍은 모든 것이 거쳐 가는 스킬입니다. 기능을 요청하는 순간 Claude가 이 스킬을 로드하고, 틀을 잡는 대화가 이어지는 동안 요구사항 전문가로 행동합니다. 방법 전체가 읽기 쉬운 파일 하나에 들어갑니다.
파일은 강한 게이트로 시작합니다. 명시적인 의도를 승인하기 전에는 코드도, 스캐폴딩도, 어떤 종류의 구현 스킬도 허용되지 않습니다. 감으로 만드는 것은 없으며, 아무리 작아 보이는 작업이라도 게이트가 적용됩니다. 그다음 스킬은 모든 요청을 세 가지 경로 중 하나로 분류합니다.
| 경로 | 정의 | 결과물 |
|---|---|---|
| 스파이크 | 실현 가능성에 대한 질문 | 답, 남겨 두는 코드가 아님 |
| 바운디드 | 저장소에 이미 있는 흐름에 대한 작은 변경 | 범위가 정해진 변경 |
| 아키텍처럴 | 프로젝트 구조를 다시 짜는 모든 것 | 여러분이 검증하는 스펙, 그다음 구현 플랜 |
에이전트는 분류를 말로 밝히므로 여러분이 뒤집을 수 있고, 래칫은 한 방향으로만 돌아갑니다. 작업 중간에 드러난 숨은 복잡성은 경로를 올리기만 하고, 반대는 절대 없습니다. 파일에는 위험 신호 표가 들어 있습니다. "이건 너무 단순해서 설계까지는 필요 없다" 같은 생각과 그 반박이 바로 옆에 놓여 있습니다. 단순한 작업이야말로 검토하지 않은 가정이 가장 큰 대가를 치르는 곳이라는 것입니다. 스파이크도 가드레일을 유지합니다. 질문에 답하기 위해 에이전트가 만든 것은 모두 일회용으로 표시되고, 그 코드를 남기는 것은 다시 분류해야 할 새 요청이 됩니다.
대화 동안 에이전트는 리드 엔지니어가 물을 질문을 던지고 설계를 소화하기 쉬운 단락으로 나누어 보여줍니다. 저희 파이프라인에서도 이 단계 덕분에 헛수고가 되었을 기능들을 이미 걸러냈습니다.
환각을 일으킬 수 없을 만큼 작은 작업으로 짠 플랜
플랜 작성 스킬은 분위기를 정하는 지시문으로 시작합니다. 여러분의 코드베이스에 대한 맥락이 전혀 없고, 파일의 표현을 그대로 빌리면, 취향도 미심쩍은 숙련 개발자를 위해 플랜을 쓰라는 것입니다.
구체적으로, 작업은 각 스텝이 2분에서 5분이면 끝나는 단위로 잘립니다. 실패하는 테스트를 작성하고, 실행해서 실패를 확인하고, 통과하는 최소 코드를 작성하고, 테스트를 다시 돌리고, 커밋합니다. 행동 하나, 검증 하나, 그리고 작업은 잦은 커밋으로 나아갑니다. 이것은 플러그인의 다른 스킬이 강제하는 테스트 주도 개발 사이클이며, 그래서 모든 작업에 자체 테스트 사이클이 붙습니다.
각 작업은 만들거나 건드릴 파일을 줄 번호까지 정확히 나열합니다. 플랜은 필수 헤더로 시작합니다. 한 문장으로 된 목표, 두세 문장으로 된 아키텍처, 기술 스택, 스펙 링크, 그리고 글자 그대로 복사한 프로젝트 전역 제약입니다. 스펙이 독립된 서브시스템 여러 개를 다루면 스킬은 서브시스템당 하나씩 별도의 플랜을 요구하며, 각 플랜은 따로 테스트 가능한 소프트웨어를 산출해야 합니다.
작업 크기 조절이 신뢰성 논리의 핵심입니다. 짧은 작업이란 에이전트가 컨텍스트 윈도우가 아직 거의 비어 있는 상태로 작업을 끝낸다는 뜻입니다. 세션이 넘치고, 에이전트가 맥락을 잃고, 존재하지 않는 함수를 지어내기 시작하는 순간에 절대 도달하지 않습니다. 5분짜리 데모에서는 이 문제가 드러나지 않지만 실제 프로젝트에서는 모든 것을 결정합니다. 세션 끝에서의 에이전트 품질은 첫 프롬프트에서의 품질과 아무 관계가 없습니다. 컨텍스트가 덜 차 있으면 환각은 기계적으로 줄어들고, 코드는 플랜에 적힌 대로 동작합니다.
작업마다 서브에이전트 하나, 매번 리뷰 하나
실행 시점에는 전용 스킬이 작업을 git worktree, 즉 저장소의 별도 작업 복사본에 격리하므로, 여러분이 옆에서 하는 일을 건드리지 않고 플랜이 실행됩니다.
실행 스킬은 서브에이전트를 통해 개발을 이끕니다. 원칙은 파일의 한 줄에 담겨 있습니다. 작업마다 새 서브에이전트, 작업마다 리뷰, 그리고 마지막에 브랜치 전체에 대한 넓은 리뷰입니다. 메인 세션은 오케스트레이터가 됩니다. 더는 코딩하지 않고 배분만 합니다. 각 서브에이전트는 자기 작업에 필요한 컨텍스트만 받고 세션 기록은 절대 받지 않습니다. 이렇게 하면 컨텍스트 오염을 피하고 여러분의 윈도우는 조율 작업용으로 비워 둘 수 있습니다.
서브에이전트는 시작 전에 질문할 수 있고, 그다음 구현하고, 테스트하고, 커밋하고, 자기 작업을 스스로 리뷰합니다. 작업이 끝나면 오케스트레이터가 두 단계로 리뷰를 실행합니다. 먼저 스펙 준수, 그다음 코드 품질이며, 작업마다 전담 리뷰어 자리가 있습니다. 즉흥적인 것은 없습니다. 스킬은 모든 역할(구현자, 작업 리뷰어, 수정을 재검토하는 리뷰어)에 대해 템플릿 프롬프트를 제공하고, 오케스트레이터가 거기에 작업 컨텍스트를 채워 넣습니다.
| 리뷰 결과 | 일어나는 일 |
|---|---|
| 통과 | 오케스트레이터가 완료를 장부에 기록하고 플랜의 다음 작업으로 넘어간다 |
| 실패, 1~3라운드 | 원래 구현자가 이어서 작업한다, 코드와 자기 선택을 이미 알고 있기 때문이다 |
| 실패, 4라운드 | 더 강한 모델로 새 구현자를 배분한다 |
| 실패, 5라운드 | 차단기가 내려가고 오케스트레이터가 남은 지적을 직접 판결한다 |
스킬은 반대쪽 과잉도 피합니다. 작은 기계적 작업 묶음은 하나의 그룹으로 배분되고 한 단위로 리뷰됩니다. 리뷰어를 거치지 않고 머지되는 것은 없습니다. 결과는 사람 팀이 코드 리뷰 프로세스라고 부르는 것인데, 다만 작업마다 스스로 돌아간다는 점이 다릅니다.
작업마다 알맞은 모델
이 배분 시스템은 세 번째 이점인 토큰 경제학으로 이어집니다. 스킬의 모델 선택 섹션은 규칙 하나로 시작합니다. 각 역할을 감당할 수 있는 가장 약한 모델을 쓰라는 것입니다. 오케스트레이터는 플랜의 모든 작업 난이도를 가늠하고 거기에 맞는 모델을 배정합니다.
| 작업 | 모델 등급 |
|---|---|
| 파일 한두 개를 건드리는 명확한 기계적 작업, 또는 작성할 코드가 이미 들어 있는 플랜 | 가장 싼 등급 (구현은 받아쓰기와 테스트가 된다) |
| 여러 파일에 걸친 조율, 디버깅 | 표준 모델 |
| 아키텍처, 최종 브랜치 리뷰 | 사용 가능한 가장 강한 모델 |
파일은 두 가지 세부 사항을 덧붙입니다. 첫째, 배분할 때는 항상 모델을 명시해야 합니다. 모델이 지정되지 않은 서브에이전트는 세션의 모델을 물려받는데, 보통 가장 비싼 모델이라서 이 섹션 전체가 조용히 무너집니다. 둘째, 턴 수가 토큰 단가를 이깁니다. 가장 싼 모델은 단계가 많은 작업에서 턴을 더 쓰고 결국 총비용이 더 나옵니다. 그래서 산문을 바탕으로 작업하는 리뷰어와 구현자는 최저가 대신 한 등급 위를 하한선으로 받습니다.
이 구성은 직관에 반하는 것을 가능하게 합니다. 카탈로그에서 가장 비싼 모델인 Opus나 Fable을 20달러 Pro 플랜으로 돌리는 것입니다. 비싼 모델은 그럴 가치가 있는 몇 가지 결정에만 쓰이고, 나머지 플랜은 쿼터를 조금만 소비하는 모델로 돌아갑니다.
커밋되는 플랜: 공짜로 얻는 문서
마지막 이점은 플러그인을 설치할 때 아무도 생각하지 않는 것입니다. 스펙과 플랜은 세션이 끝나면 사라지는 채팅 메시지가 아닙니다. 저장소 안에 저장되고 작업과 함께 커밋되는 마크다운 파일입니다. 스킬은 위치도 정해 둡니다. 날짜가 붙은 plans 폴더, 기능당 파일 하나, 헤더에는 목표, 아키텍처, 스펙 링크가 들어갑니다.
스펙은 플랜과 함께 움직이고, 둘 사이의 충돌은 스펙을 기준으로 해결됩니다. 권위는 에이전트의 기억이 아니라 문서에 있습니다. git 히스토리는 더 이상 무엇이 바뀌었는지만 알려주지 않습니다. 왜 바뀌었는지, 그때 에이전트가 무엇을 결정했는지도 알려줍니다. 6개월 뒤 프롬프트에서 플랜 파일을 언급하면 에이전트는 원래 기능의 맥락을 바로 다시 집어 들고, 같은 서브시스템을 건드리는 새 기능은 지형을 다시 탐색하는 대신 기존 스펙 위에 쌓입니다.
추적되지 않는 작업이라는 것은 더 이상 없습니다. 에이전트가 코드베이스에 한 모든 일은 첫 브레인스토밍부터 마지막 커밋까지 문서를 남깁니다. 프로젝트는 철학을 두 가지 원칙으로 요약합니다. 즉흥보다 체계, 주장보다 증거. 문서는 프로세스에서 저절로 나옵니다.
실제로 지불하는 비용
한계는 실제로 있고, 저장소는 이를 광고하지 않습니다. 이 모든 규율에는 고정 비용이 있고, 그 비용은 절대 꺼지지 않습니다. 진입 스킬은 단호합니다. 조금이라도 의심되면 에이전트는 스킬을 로드해야 하고, 브레인스토밍 파일은 의식은 작업 크기에 맞춰 줄어들지만 사람의 승인은 절대 줄지 않는다고 명시합니다.
두 줄짜리 수정에서도 틀을 잡는 질문에 답하고, 두 문장짜리 설계를 승인하고, 수정을 보기 전에 전체 사이클을 기다려야 한다는 뜻입니다. 설정 파일의 오타 하나에는 전체 프로세스가 직접 고치는 것보다 그냥 느립니다. 오케스트레이션 자체도 토큰을 소비합니다. 배분 브리프, 작업당 리뷰 두 번, 장부는 매번 지불하는 비용이며, 가장 작은 작업에서 가장 크게 느껴집니다.
반대 증상도 있고, 이것이 Reddit의 질문에 직접 답합니다. 사용 통계에서 플러그인이 몇 퍼센트에 그친다면 여러분의 요청이 스킬을 거의 건드리지 않는다는 뜻이고, 이득은 전혀 보지 못한 채 세션마다 입장료만 내는 셈입니다. 다섯 라운드를 모두 도는 수정 루프는 디프 다섯 개, 리뷰 다섯 번 추가, 판결 한 번인데, 몇 분이면 끝났어야 할 작업에 대한 것입니다. 프로젝트는 가만히 있지도 않습니다. 첫 버전에서 여섯 번째 버전까지 1년도 안 되어 갔고 아직 열린 이슈가 125개이므로, 오늘 읽은 스킬은 다음 업데이트에서 달라져 있을 것입니다.
플러그인은 스스로 출구를 마련해 둡니다. 지시문은 여러분의 명령을 스킬보다 위에 두므로, 에이전트에게 프로세스를 건너뛰라고 명시적으로 말할 수 있습니다. 저희의 규칙은 이렇습니다. 기능 작업에는 Superpowers를 기본으로 켜고, 작은 수정에는 의도적으로 skip합니다.
저희의 평가
| 여러분의 Claude Code 사용 방식 | 평가 |
|---|---|
| 몇 시간이 걸리는 기능 | 설치하세요. 틀 잡기가 잘못된 것을 구현하는 일을 막아주고, 짧은 작업이 에이전트를 컨텍스트 포화에서 지켜주고, 모델 선택이 쿼터를 늘려주며, 직접이라면 절대 쓰지 않았을 문서까지 물려받습니다 |
| 일회용 스크립트와 작은 수정 | 지나치세요. 필요 없는 작업에 프로세스의 고정 비용을 내게 됩니다 |
| 그 중간 | 설치하고 skip이라고 말하는 법을 익히세요. 프롬프트 한 문장이면 통제권이 여러분에게 돌아옵니다 |
전부 도입하지 않고 시험만 해보고 싶다면 브레인스토밍 스킬만 며칠 돌려 보세요. 이득의 대부분은 거기에 있고, 다른 스킬은 그 뒤에 자연스럽게 붙습니다. 플러그인은 의식에 걸맞은 기능을 먹여주는 한 네 가지 약속을 지킵니다. 이제 저희 프로젝트에서도 돌아가고 있으며, 브레인스토밍 단계는 더는 끄지 않을 것입니다. 저장소는 무료 오픈소스이고, 여러분 앞에 280,000명이 줄 서 있습니다.
AIDive