Claude Superpowers Skills 브레인스토밍, 코드 설계, 코드 리뷰까지

결론부터 말하자면, Claude Code를 사용하는 사람이 obra(Jesse Vincent)가 만든 Superpowers 플러그인을 설치하지 않으면 진정한 의미의 손해다. 이 플러그인을 설치하기 전에는 Claude에게 "기능을 만들어 달라"고 하면 곧바로 코드부터 작성했지만, 설치한 이후에는 알아서 브레인스토밍부터 시작해 계획을 세우고, TDD로 구현하며, 발행 직전에는 코드 리뷰까지 수행한다. 이것이 Claude Superpowers 스킬의 핵심이다.

 

이 글에서는 IT에 익숙하지 않은 사람도 이해할 수 있도록, "스킬"이라는 개념이 무엇인지부터 obra superpowers가 다른 도구와 어떻게 다른지, 실제 비포/애프터 차이가 어떠했는지를 모두 풀어보고자 한다. AI 코딩 자동화를 한다며 ChatGPT 같은 것만 사용하던 사람이라면 끝까지 읽어보기를 권한다.

 

https://github.com/obra/superpowers

GitHub - obra/superpowers: An agentic skills framework & software development methodology that works.

 

Claude Superpowers 스킬, 도대체 무엇이기에 모두가 설치하라고 하는가

 

Claude Code의 "스킬"이라는 개념부터 정리한다

 

먼저 Claude의 "스킬(Skill)"이 무엇인지 살펴보자. 비유하자면 Claude에게 미리 입력해 둔 작업 매뉴얼이다. 회사에 신입이 들어오면 업무 매뉴얼을 제공하지 않는가? 그것과 유사하다. 다만 Claude는 사용자가 시키지 않아도 상황을 보고 알아서 매뉴얼을 꺼내 본다는 점이 다르다.

 

Anthropic 공식 Claude Code 문서를 보면 Skill이라는 도구가 있는데, 이는 일종의 "이 상황에서는 이렇게 일하라"는 지시서를 호출하는 도구다. 예를 들어 디버깅 스킬이 있다면, 사용자가 "버그가 발생했다"고 말하는 순간 Claude가 디버깅 매뉴얼을 펴고 그 절차대로 움직인다.

 

obra(Jesse Vincent)가 만든 플러그인 — 단순한 프롬프트 모음이 아니다

 

obra는 Perl 커뮤니티에서 RT를 만든 것으로 유명한 베테랑 개발자다. 이 사람이 Claude Code용으로 만든 것이 superpowers이며, 깃허브에서 github.com/obra/superpowers를 통해 코드를 모두 확인할 수 있다.

 

그런데 이것은 단순히 "프롬프트 모음"이 아니다. 진정한 차이는 자동 호출 메커니즘이다. 일반 프롬프트 모음은 사용자가 "이것을 사용해 달라"고 해야 동작하는데, superpowers는 "1%라도 적용 가능성이 있으면 무조건 스킬을 호출하라"는 강제 규약을 박아 놓았다.

 

핵심은 using-superpowers 진입 스킬이다

 

세션을 시작하면 가장 먼저 로드되는 것이 using-superpowers라는 진입 스킬이다. 이것이 무엇이냐 하면 Claude에게 "다른 스킬을 호출하지 않고 답하면 안 된다"고 박아 놓는 가이드다. 영어 원문에는 태그 안에 "이것은 협상 불가, 선택사항도 아니다"라고 명시되어 있다. 거의 군대 명령 수준이다.

 

쉽게 말하자면 Claude가 "이 정도는 그냥 작성해도 되겠지"라고 자기 마음대로 스킵하는 것을 차단하는 장치다. 이것이 obra superpowers의 진정한 무기다.

 

사용하지 않으면 어떻게 되는가 — 비포/애프터 시나리오

 

일반 Claude Code: 지시하면 곧바로 코드부터 작성한다

 

Superpowers가 설치되지 않은 상태에서 "결제 모듈을 만들어 달라"고 하면 보통 다음과 같이 흘러간다.

 

1. Claude가 즉시 파일을 만들기 시작한다
2. 의존성을 설치한다
3. 함수를 약 50줄가량 쭉 작성한다
4. "완료되었습니다"라며 종료한다

 

그런데 막상 실행해 보면 어떠한가? 엣지 케이스에 구멍이 나고, 테스트는 없으며, 요구사항 절반이 누락되어 있다. 결국 다시 지시하고 또 지시하는 핑퐁이 시작된다. 계획 단계가 통째로 빠져 있어서 그렇다.

 

Superpowers 설치된 Claude: 알아서 단계별로 진행한다

 

같은 요청을 superpowers가 설치된 상태에서 하면 흐름이 완전히 달라진다.

 

1. brainstorming 스킬 자동 호출 → "결제 모듈이라고 하셨는데 어떤 PG사를 사용할 것인가? 환불도 포함하는가? 멤버십 결제도 처리하는가?" 식으로 질문을 던진다
2. writing-plans 스킬 → 계획서를 마크다운 파일로 작성하고 사용자에게 컨펌을 요청한다
3. test-driven-development 스킬 → 테스트부터 작성하고, 그다음 구현한다
4. verification-before-completion 스킬 → 실제로 통과했는지 명령어를 실행하여 확인한다
5. requesting-code-review 스킬 → 리뷰를 받는다

 

직역하자면 "AI 페어 프로그래머"가 자신의 직무 매뉴얼대로 일하는 셈이다.

 

실제 워크플로우 비교

 

체감되는 차이는 커밋 히스토리에서 가장 잘 드러난다. 일반 Claude Code로 작업하면 커밋 메시지 한 줄에 변경사항 100개가 박힌 경우가 자주 나타난다. Superpowers를 사용하면 의도 단위로 분리된 커밋이 자연스럽게 생성된다. 왜일까? 계획 단계에서 작업 단위를 미리 나눠 두었기 때문이다.

 

PR 품질 또한 다르다. 평소에는 "이 부분을 좀 변경해 달라"는 코멘트가 5~6개씩 달리는데, superpowers를 거친 PR은 코멘트가 0~2개로 머지되는 경우가 많다.

 

진정한 무기 1: 브레인스토밍을 강제로 수행하게 한다

 

brainstorming 스킬은 어떤 트리거로 호출되는가

 

이 스킬의 정의를 보면 트리거 조건이 다음과 같이 박혀 있다. "기능 만들기, 컴포넌트 작성, 동작 변경 같은 창작 작업 전에는 무조건 호출할 것."

 

쉽게 말하자면 Claude가 코드 한 줄을 작성하기 전에 사용자 의도부터 캐묻게 만드는 장치다. "그것을 만들어 달라"고 하면 곧바로 시작하지 못하고, "잠시만, 진정으로 원하는 것이 무엇인지 함께 정리해보자"부터 시작한다.

 

"그냥 만들어 달라"고 했을 때 Claude가 갑자기 질문을 던지는 이유

 

처음에는 다소 짜증이 날 수도 있다. "그냥 빨리 작성해 달라"고 하는데 자꾸 질문을 던지기 때문이다. 그러나 이것이 단점이 아니라 장점인 이유는, 사람이 머릿속에서만 굴리던 요구사항을 강제로 끄집어내게 만든다는 점이다. 결과적으로 한 번에 제대로 만들 확률이 훨씬 높아진다.

 

브레인스토밍을 거치면 사용자가 미처 생각하지 못한 케이스도 함께 발굴된다. "환불 정책은 어떻게 할 것인가?", "결제 실패 시 재시도 정책이 있는가?", "이 로직을 다른 페이지에서도 사용할 일이 있는가?" — 이러한 것들을 미리 정리하고 들어간다.

 

결과물 비교

 

브레인스토밍을 거친 기능과 거치지 않은 기능의 차이는 요구사항 누락률에서 가장 크게 드러난다. 거치지 않으면 평균 30~40% 누락되는 것이, 거치면 5~10% 수준으로 떨어진다. 이것은 단순한 체감이 아니라 실제 PR 변경량을 비교해 보아도 그렇게 나타난다.

 

진정한 무기 2: Superpowers + 동반 플러그인 묶음으로 퍼블리싱·디자인까지

 

obra/superpowers 본체에 들어 있는 스킬은 코드 작업 위주다(브레인스토밍, 계획, TDD, 디버깅, 검증, 코드 리뷰, git worktree 등). 다만 같은 Claude Code 마켓플레이스에 frontend-design, to-prd, to-issues 같은 동반 플러그인이 별도로 존재하기 때문에 함께 설치하면 기획·디자인 단계까지 자연스럽게 하나의 흐름으로 묶인다. 아래의 스킬들은 obra/superpowers 코어가 아니라 별도 플러그인이지만, 워낙 짝꿍처럼 함께 사용되므로 묶어서 정리한다.

 

frontend-design 스킬 — 차별화된 UI를 뽑아내도록 강제한다

 

AI에게 UI를 만들어 달라고 하면 모두 비슷하게 나오는 것을 알 것이다. 회색 박스 + 둥근 모서리 + 파란 버튼. 이른바 "AI 디폴트 미감"이다.

 

frontend-design 스킬은 이러한 generic AI 디자인을 금지하고 차별화된 인터페이스를 뽑아내도록 만든다. 톤, 그리드, 컬러 시스템부터 잡고 들어가도록 강제한다. Claude가 "이것은 너무 뻔하다, 다른 컨셉을 시도해 보자"라고 자기 검열하는 모습이 신기할 정도다.

 

to-prd, to-issues 스킬 — 대화 맥락을 PRD/이슈로 자동 변환한다

 

대화로 "이런 기능을 만들고 싶다"고 하다 보면 어느새 요구사항이 산만해진다. 이때 to-prd 스킬을 호출하면 여태까지 나눈 대화 맥락을 PRD 문서로 자동 변환한다. 이슈 트래커에 곧바로 올릴 수 있도록 말이다.

 

to-issues 스킬은 한발 더 나아가 PRD를 독립적으로 잡아갈 수 있는 작은 이슈들로 분할해 준다. 이를 트레이서 불릿(tracer-bullet) 방식이라고 부르는데, 비유하자면 큰 프로젝트를 작게 자른 다음 끝에서 끝까지 한 번 관통하는 가는 줄기부터 만드는 방식이다. 그래야 진척도가 보이고 백로그가 막히지 않는다.

 

requesting-code-review, receiving-code-review 콤보

 

발행 직전 검증 루프다. requesting-code-review는 자신이 작성한 코드를 누군가에게 리뷰받게 하고, receiving-code-review는 받은 피드백을 어떻게 반영할지 가이드한다.

 

여기서 중요한 점은 receiving-code-review 스킬이 "퍼포먼스성 동의"를 막아 준다는 것이다. 즉 리뷰어가 "이것은 별로인 것 같다"고 하면 무조건 "네 알겠습니다"라며 수정하는 것이 아니라, 기술적으로 검증부터 하라고 박아 놓았다. 이것은 진정으로 영리한 설계다.

 

콘텐츠 파이프라인 관점

 

이를 묶어서 보면 기획 → 설계 → 구현 → 검증 → 발행이 하나의 흐름으로 진행된다. 평소에는 단계마다 사람이 "다음에는 이것을 하라"고 시켜야 했는데, superpowers를 설치하면 Claude가 알아서 다음 단계로 넘어간다. 콘텐츠 파이프라인을 자동화하는 셈이다.

 

진정한 무기 3: TDD/디버깅/검증을 우회하지 못하게 막는다

 

Rigid skill vs Flexible skill 분류

 

Superpowers의 스킬은 두 종류로 나뉜다.

 

• Rigid 스킬: 절대 우회할 수 없다. 정해진 순서를 그대로 따라야 한다. (예: TDD, debugging)
• Flexible 스킬: 원칙은 따르되 상황에 맞게 변형 가능하다. (예: 패턴 가이드)

 

비유하자면 Rigid는 운전면허 시험 코스이고, Flexible은 운전 매너다. 코스는 거치지 않으면 안 되지만, 매너는 상황을 보고 적용 강도를 조절할 수 있다.

 

test-driven-development가 Rigid라는 것은, Claude가 "그냥 빨리 작성하고 테스트는 나중에 붙이자" 같은 시도를 할 수 없다는 뜻이다. 무조건 빨강(실패하는 테스트) → 초록(통과시키기) → 리팩터링 순서다.

 

verification-before-completion — "완료되었다"는 거짓말을 방지한다

 

이것은 진정으로 천재적인 스킬이다. 비유하자면 숙제를 다 했다고 말하기 전에 실제로 풀어 봤는지 확인 도장을 받는 것이다.

 

Claude가 "구현 완료"를 외치기 전에, 실제로 검증 명령어를 실행하고 그 출력을 보아야 한다고 강제한다. 테스트가 통과했다고 말하기 전에 npm test 결과를 첨부해야 하고, 빌드되었다고 말하기 전에 tsc --noEmit 결과를 보여 주어야 한다. 증거 없이는 성공 주장 금지다.

 

이것이 빠지면 진정으로 자주 발생하는 것이 "다 고쳤다" → 실행하면 또 같은 에러가 나는 상황이다. Superpowers가 설치된 Claude는 이러한 행위가 불가능하다.

 

systematic-debugging — 버그를 만나면 일단 가설부터 세운다

 

이 스킬도 Rigid다. 버그를 만나면 재현 → 최소화 → 가설 → 계측 → 수정 → 회귀 테스트 순서로 진행한다.

 

평소에 Claude는 버그를 보면 어딘가 한 줄을 고쳐서 "되었을 것이다"라고 말하는 경우가 많은데, superpowers가 설치되면 가설을 세우지 않고는 코드를 만지지 못한다. "이것이 왜 발생하는지"를 먼저 정리하고, 그 가설을 검증하는 방식으로 움직인다.

 

설치 및 사용 방법 + 솔직한 단점

 

설치는 한 줄 명령어 수준이다

 

obra의 superpowers 깃허브 레포 README를 보면 설치 명령어가 친절하게 적혀 있다. Claude Code의 플러그인 시스템에 등록하는 방식이라 한 줄로 끝난다. 자세한 내용은 README를 보면 된다 — 이미 잘 정리되어 있어서 여기서 다시 옮겨 적을 필요는 없다.

 

설치 후에는 세션을 시작할 때 자동으로 using-superpowers 스킬이 로드되면서 다른 스킬들의 트리거가 활성화된다.

 

Skill 도구 + 슬래시 커맨드로 호출한다

 

수동으로 스킬을 호출하고 싶을 때는 /<스킬이름> 형태의 슬래시 커맨드로도 호출할 수 있다. 예를 들어 /brainstorming 같은 식이다.

 

다만 superpowers의 진정한 매력은 자동 호출이므로, 슬래시 커맨드는 거의 사용하지 않게 된다.

 

단점도 솔직하게 까보자면

 

1. 토큰 소모가 다소 더 많다. 매 세션마다 진입 스킬이 로드되고, 작업할 때마다 관련 스킬 매뉴얼을 읽기 때문에 입력 토큰이 늘어난다. 체감상 약 10~20% 정도다.

 

2. 학습 곡선이 존재한다. 어떤 스킬이 언제 호출되는지 감을 잡기까지 며칠이 걸린다. 처음에는 "왜 자꾸 질문을 던지는가?"라며 답답할 수 있다.

 

3. "그냥 빨리 작성하고 싶다"에는 오버스펙이다. 한 줄짜리 함수 하나를 추가하는데 브레인스토밍을 시키면 진정으로 짜증이 난다. 이런 경우에는 superpowers를 끄거나 스킬 트리거를 우회하는 방식으로 사용해야 한다.

 

그럼에도 사용하는 것이 이득인 이유

 

장기적으로 보면 코드 품질 + 페어 프로그래머급 동반자가 생긴다는 점이 압도적으로 크다. 특히 큰 프로젝트나 장기 프로젝트일수록 차이가 벌어진다. 단기 프로젝트에서는 오버스펙처럼 보이지만, 한두 달 가는 프로젝트라면 무조건 켜 두는 것이 이득이다.

 

결국 Claude Superpowers 스킬, 왜 무조건 설치해야 하는가

 

핵심을 3줄로 요약하면 다음과 같다.

 

1. Claude Superpowers 스킬은 단순한 프롬프트 모음이 아니라, Claude가 자기 마음대로 우회하지 못하게 만드는 강제 규약이다. using-superpowers 진입 스킬이 1%라도 적용되면 무조건 호출하도록 박아 놓았다.
2. 브레인스토밍 → 계획 → TDD → 디버깅 → 검증 → 코드 리뷰 → 발행/디자인까지 전 단계가 묶여 있다. 사람이 "다음에는 이것을 하라"고 시키지 않아도 알아서 다음 단계로 넘어간다.
3. 토큰을 더 사용하고 학습 곡선이 존재한다는 단점은 있으나, 장기 프로젝트라면 무조건 이득이다. 평소 PR 코멘트 5~6개가 달리던 것이 0~2개로 감소한다.

 

다음 액션 — obra superpowers 깃허브에 들어가 README를 한 번 읽어 보고, 자기 프로젝트에 설치해 보기를 권한다. 한 시간 안에 셋업이 끝난다.

 

후속 글로 "superpowers 스킬 직접 만들어 보기 (writing-skills)"를 다룰 예정이니, 자기만의 워크플로우를 스킬로 박제하고 싶은 사람은 기다려 보기를 바란다.

 

Claude Code를 처음 사용해 보는 사람이라면 Claude Code 입문 가이드부터 보면 좋고, TDD 자동화 흐름이 궁금하다면 AI 코딩 TDD 워크플로우 글도 함께 보면 된다. Plan 모드가 헷갈린다면 Claude Plan 모드 활용 글도 추천한다.

 

이 글을 한 줄로 요약하자면 다음과 같다 — Claude Superpowers 스킬을 사용하지 않는 것, 진정한 손해다.