Claude Code 사용법: Superpowers 설치부터 스킬 활용까지

Claude Superpowers는 무엇인가요?

Superpowers는 Jesse Vincent가 만든 개발 스킬 모음이자, 코딩 에이전트가 그 스킬을 사용하도록 유도하는 지침입니다. 저장소를 대상으로 작업하는 Anthropic의 코딩 어시스턴트 Claude Code에 요청 파악, 변경 계획, 테스트, 디버깅, 작업 위임, 브랜치 마무리를 위한 워크플로를 제공합니다. 작업장의 운영 매뉴얼에 비유할 수 있습니다. 도구는 이미 갖춰져 있고, 매뉴얼이 작업 순서와 인계 전 확인 사항을 정합니다. Superpowers README

2026년 10월 18일 확인 기준: 소스의 매니페스트에 명시된 버전은 7.0.0이며, 저장소에는 SKILL.md 파일을 포함한 최상위 스킬 폴더가 15개 있습니다. 이는 이 글을 위해 확인한 소스의 상태입니다. 실제로 선택한 마켓플레이스가 설치하는 리비전은 별도로 확인해야 합니다. 플러그인 매니페스트, 스킬 디렉터리

실용적인 장점은 의사결정의 흐름이 눈에 보인다는 데 있습니다. Claude는 기능을 바꾸기 전에 의도한 동작부터 정리할 수 있고, 완료를 선언하기 전에 새로 실행한 테스트 결과를 요구할 수 있습니다. 이런 지침 덕분에 구체적으로 살펴볼 근거가 생깁니다. 다만 그것만으로 요구사항이나 테스트 자체가 올바르다고 보장되지는 않습니다.

Superpowers 사용법: Claude Code에 설치하기

프로젝트 README에 안내된 설치 경로 중 하나를 Claude Code 안에서 사용합니다. 아래 명령은 README의 Claude Code 항목에서 그대로 옮겼습니다. 일반 셸에 붙여 넣는 명령이 아니라 대화형 슬래시 명령입니다. README 설치 안내

공식 마켓플레이스에서 Claude Superpowers 플러그인 설치하기

/plugin install superpowers@claude-plugins-official

제작자는 자체 마켓플레이스를 이용하는 방법도 안내합니다. 이 경로를 선택한다면 마켓플레이스를 등록한 뒤 설치합니다.

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

어디에서 설치했는지 계속 파악할 수 있는 경로를 선택하면 됩니다. 같은 플러그인을 설정하면서 두 경로를 모두 사용할 이점은 없습니다.

설치 후에는 새 Claude Code 세션을 시작해 시작 훅이 작동하게 합니다. 기존 할 일 목록에 필터를 추가하는 것처럼 범위가 한정된 기능을 요청합니다. 이때 관찰할 것은 적절한 스킬을 사용하겠다고 알리는지, 그리고 그 스킬의 지침대로 행동하는지입니다. 설치 명령이 완료됐다는 사실과 워크플로가 예상대로 작동한다는 사실은 각각 확인해야 합니다.

Superpowers 설치 후 Claude Code 사용법은 어떻게 달라지나요?

가장 먼저 달라지는 것은 대화의 컨텍스트입니다. 시작 훅이 Superpowers의 사용 지침을 대화에 넣습니다. 설정된 SessionStart 매처는 startup, clear, compact를 대상으로 합니다. 스크립트는 using-superpowers를 읽어 그 내용을 주입하고, Claude가 Skill 툴로 다른 스킬을 불러오도록 지시합니다. 시작 메시지에 모든 스킬의 전체 내용을 넣는 방식은 아닙니다. 훅 설정, 시작 스크립트

Claude Superpowers는 어떤 기준으로 스킬을 선택하나요?

Claude는 작업을 스킬 설명과 대조한 뒤 관련 지침을 읽습니다. 플러그인의 스킬 작성 가이드는 각 설명에 해당 스킬을 언제 적용하는지 밝혀야 한다고 안내합니다. 초기 지침은 에이전트에게 응답하거나 행동하기 전에 적용할 스킬을 확인하고, 사용할 스킬을 알리며, 구현 스킬보다 절차를 정하는 스킬을 먼저 적용하라고 지시합니다. 스킬 탐색 지침

따라서 무언가를 만들어 달라는 요청은 brainstorming으로, 실패하는 테스트는 systematic-debugging으로 이어집니다. 이후에는 해당 분야의 스킬이 구현을 안내할 수 있습니다. 스킬 이름을 직접 지정해 요청할 수도 있습니다. 예를 들면 “수정안을 제시하기 전에 superpowers:systematic-debugging으로 이 실패를 조사해 주세요”라고 요청합니다. 사용 지침

자동 선택은 모델에 주는 지침이며, 특정 키워드에 정해진 동작을 연결하는 스위치는 아닙니다. 훅이 초기 지침을 제공하더라도 상황을 파악하고 선택한 지침을 따르는 일은 에이전트가 수행해야 합니다. 잘못된 워크플로를 골랐다면 작업 범위를 바로잡거나 적절한 스킬을 직접 요청하면 됩니다.

Superpowers 스킬별 역할과 적용 시점

스킬 모음은 개발 주기 전체를 다루지만, 각 세션에서는 작업에 맞는 스킬을 불러와야 합니다. 아래 이름은 확인한 파일에 쓰인 정확한 명칭입니다. 적용 시점은 각 스킬의 설명과 지침을 요약한 것으로, 특정 문장을 입력하면 반드시 특정 스킬이 호출된다는 뜻은 아닙니다. 현재 스킬 디렉터리

이 목록을 외울 필요는 없습니다. 일반적인 기능 개발에서는 요청 파악, 필요한 경우 구체적인 계획 수립, 테스트를 거친 구현, 변경 리뷰, 통합 방식 결정으로 이어지는 전환을 살펴보면 됩니다. 버그가 있다면 새 기능을 설계하는 대화보다 원인 조사부터 시작하는 편이 적절합니다.

기본 계획 모드, 개인 스킬과는 어떻게 함께 쓰나요?

Superpowers는 계획 수립을 둘러싼 워크플로를 정합니다. 자체 writing-plans 스킬은 Claude Code의 기본 계획 모드와 별개입니다. 현재 초기 지침은 브레인스토밍을 아직 하지 않았다면 계획 모드에 들어가기 전에 brainstorming을 호출하라고 명시합니다. 기본 모드와 자체 계획 작성 스킬을 서로 대체 가능한 것으로 취급하지 않고, 작업 순서를 정하는 방식입니다. 현재 계획 수립 지침

writing-plans는 보통 docs/superpowers/plans/ 아래에 구현 결정 사항과 확인 항목을 담은 저장소 문서를 만듭니다. 인계 시점에는 사용자가 이미 실행 방식을 정해 두지 않은 한, 계획을 검토하고 실행 방식을 선택하도록 요청합니다. 모드를 선택하는 것만으로 이런 문서나 작업 지침이 생기지는 않습니다. Claude Code 자체의 조작 방식과 동작은 별도의 Claude Code 계획 모드 가이드를 참고하면 됩니다.

직접 만든 스킬도 함께 사용할 수 있습니다. 플러그인의 writing-skills 파일은 Claude Code의 개인 스킬 디렉터리를 ~/.claude/skills/로 명시합니다. 초기 지침은 CLAUDE.md와 직접 요청을 포함한 사용자 지침을 스킬 지침보다 높은 우선순위에 둡니다. 따라서 프로젝트 전용 스킬에 고유한 규칙을 담고, Superpowers에는 개발 절차를 맡길 수 있습니다. 양쪽 모두 테스트나 리뷰 방식을 규정한다면 역할 분담을 명확히 해야 합니다. 스킬 작성 파일, 지침 우선순위

이런 지침 파일의 기본 개념은 에이전트 스킬에서 설명합니다. Superpowers는 그 방식을 바탕으로 특정한 개발 철학을 담은 스킬 모음입니다.

Claude Code Superpowers로 기능 하나를 구상부터 병합까지 구현하기

‘완료한 항목 숨기기’ 토글만으로도 전체 워크플로를 살펴볼 수 있습니다. 아래는 스킬 파일을 바탕으로 구성한 설명용 예시이며, 실제 테스트 세션을 기록한 것은 아닙니다. 파일 이름, 인수 조건, 결과는 모두 가정한 내용입니다.

테스트가 이미 갖춰진 할 일 목록 앱을 가정합니다. 사용자는 완료한 항목을 삭제하지 않고 숨기는 토글을 요청합니다. 이 예시에서는 사용자가 문서로 된 계획과 서브에이전트의 작업별 리뷰를 명시적으로 요청한 것으로 설정합니다. 그런 요청이 없다면 이 정도로 작은 변경은 대화 안에서 간단히 정리하는 절차의 대상이 될 수 있습니다.

brainstorming: 구현할 동작부터 합의합니다

핵심 질문은 ‘숨기기’가 현재 화면에만 영향을 주는지, 저장된 할 일까지 바꾸는지입니다. 이 예시에서 합의한 동작은 화면에만 적용되는 필터입니다. 토글은 꺼진 상태로 시작하고, 켰다가 끄면 완료한 항목이 다시 나타나며, 필터링 후 목록이 비어 있으면 진행 중인 할 일이 없다고 표시합니다.

Claude는 이 범위를 다시 설명하고 승인을 받습니다. 사용자가 문서 작성 경로를 선택했으므로 설계는 docs/superpowers/specs/ 아래 문서로 정리하며, 인계 전에 구현 담당자의 점검을 거칩니다. 이 스킬의 일반적인 소규모 변경 경로에서는 설명과 합의를 대화 안에 남겨도 됩니다. 브레인스토밍 규칙

이 단계에서 살펴볼 결과물은 동작에 관한 합의 내용입니다. 여기에 설정 저장이 슬그머니 추가되거나 할 일 저장 방식이 바뀌었다면, 구현을 시작하기도 전에 기능 범위가 넓어진 것입니다.

writing-plans: 작업을 검증 가능한 단위로 나눕니다

계획은 기능을 각각 독립적으로 확인할 수 있는 결과물로 나눕니다. 한 작업은 예시 파일인 src/tasks/filterTasks.ts에 필터 함수를 구현하고, 완료 여부가 섞인 목록, 빈 목록, 모두 완료된 목록을 테스트합니다. 다른 작업은 합의한 함수 인터페이스를 사용해 src/tasks/TaskList.tsx에 접근성을 갖춘 토글을 연결하고 화면에 표시되는 결과를 테스트합니다.

계획에는 파일, 인터페이스, 테스트에서 검증할 조건, 프로젝트의 테스트 명령, 예상 결과를 명시합니다. 필터링이 원본 할 일 목록을 변경해서는 안 된다는 점도 기록합니다. 사용자는 계획을 검토하고 서브에이전트를 활용하는 방식으로 진행한다고 확인합니다. 이 단계에서 막연했던 지침은 구현 담당자와 리뷰어가 무엇이 맞고 틀린지 구체적으로 논의할 수 있는 기준이 됩니다. 계획 작성 지침

using-git-worktrees: 작업 공간을 준비합니다

실행을 준비하면서 Claude는 작업이 이미 분리된 공간에서 진행되는지 확인합니다. Git worktree는 같은 저장소를 위한 별도의 작업 디렉터리로, 보통 자체 브랜치를 사용합니다. 이 스킬은 실행 환경에 내장된 worktree 기능을 우선하고 사용자가 정해 둔 선호 방식을 따릅니다. 그런 조건이 없으면 새로 만들기 전에 묻습니다.

이 예시에서는 사용자가 기능 작업용 worktree를 만드는 데 동의합니다. Claude는 애플리케이션을 변경하기 전에 그곳에서 기존 프로젝트 테스트를 실행합니다. 초기 상태부터 테스트가 실패한다면 먼저 이를 살펴봐야 이후의 실패가 새 토글 때문인지 판단할 수 있습니다. 작업 공간 지침

subagent-driven-development와 test-driven-development: 작업을 구현합니다

작업을 조율하는 에이전트는 필터링 작업에 새로운 구현 담당 에이전트를 배정한 뒤 작업 리뷰를 진행합니다. 그 확인 단계를 거쳐 UI 작업으로 넘어갑니다. 현재 서브에이전트 스킬은 작업 리뷰에서 명세 준수 여부와 코드 품질을 확인하고, 완료된 브랜치 전체를 대상으로 더 넓은 범위의 리뷰를 요구합니다. 진행 상황과 결정 사항은 해당 계획 전용 기록에도 남깁니다. 서브에이전트 워크플로

구현 과정에서는 test-driven-development가 실패하는 테스트 작성, 통과시키기, 리팩터링으로 이어지는 사이클을 안내합니다. 이 예시에서는 먼저 필터링된 화면을 요청해도 완료한 할 일이 여전히 반환된다는 사실을 테스트로 확인합니다. 구현 담당자는 실제 실패를 확인한 뒤에야 필터링 동작을 추가하고 테스트를 다시 실행하며, 테스트가 계속 통과하는 상태에서 코드를 정리합니다. TDD 지침

UI 작업에서는 사용자가 토글을 조작한 뒤 무엇을 보게 되는지 검증해야 합니다. 함수가 호출됐는지만 확인하는 테스트로는 기능이 화면에서 어떻게 동작하는지 입증할 수 없습니다.

대안은 executing-plans입니다. Claude가 현재 세션에서 직접 계획을 구현하고, 서브에이전트를 사용할 수 있다면 마지막에 새로운 리뷰어가 브랜치 전체를 검토합니다. 작업마다 인계하는 리뷰 구조가 필요하지 않을 때 이 경로를 선택하면 됩니다. 현재 세션에서 실행하는 지침

리뷰 스킬과 systematic-debugging: 발견된 문제를 처리합니다

최종 브랜치 리뷰에서는 requesting-code-review가 리뷰어에게 작업을 넘기는 절차를 제공합니다. 리뷰어가 토글을 꺼도 완료한 할 일이 복원되지 않는 문제를 발견했다고 가정합니다. receiving-code-review는 무언가를 바꾸기 전에 코드와 의도한 동작을 기준으로 그 지적이 맞는지 확인하도록 합니다. 리뷰 요청, 피드백 수용

실패가 재현되면 systematic-debugging에 따라 조사합니다. 근본 원인 조사, 패턴 분석, 가설 검증, 구현 순서로 진행합니다. 이 예시에서는 코드가 원본 목록을 필터링된 목록으로 덮어썼을 가능성을 가설로 세울 수 있습니다. 데이터 흐름을 살펴보고 항목이 사라지는 현상을 재현한 뒤, 회귀 테스트를 추가하면서 원인을 수정합니다. 토글의 겉모습만 올바르게 보이도록 억지로 맞춰서는 안 됩니다. 디버깅 지침

완료를 검증하고 병합 방식을 선택합니다

verification-before-completion은 성공을 선언하기 전에 새로 실행한 명령의 출력 결과를 요구합니다. 이 기능에서는 필터 동작, 토글 조작, 관련 프로젝트 검사에 대한 근거를 제시하고, 해결되지 않은 실패가 있다면 명확히 밝혀야 합니다. 검증 지침

이후 finishing-a-development-branch가 전체 테스트 스위트를 검증하고 통합 방법을 제시합니다. 이름이 있는 일반 브랜치의 경우, 현재 스킬 파일은 로컬 병합, 푸시 후 풀 리퀘스트 생성, 브랜치 유지 중에서 선택하도록 합니다. 사용자의 결정을 기다리며, 리뷰를 통과했다는 이유만으로 병합이 허용됐다고 간주하지 않습니다.

이 예시의 마무리로 사용자가 확인된 기준 브랜치에 로컬 병합하기를 선택했다고 가정합니다. Claude는 병합 후 결과를 테스트하고, 통과한 뒤에만 기능 작업용 worktree와 브랜치를 정리합니다. 풀 리퀘스트를 만들었다면 해당 저장소의 병합 절차를 기다리는 상태로 남습니다. 브랜치 마무리 지침

작은 작업에는 언제 절차를 줄여야 하나요?

요청에서 이미 정한 사항을 계속 다시 결정하게 만든다면 절차 자체가 부담이 됩니다. 화면에 보이는 문구를 지정된 텍스트로 바꾸는 작업에 할 일 상태의 저장 방식을 바꾸는 작업과 같은 준비가 필요하지는 않습니다. 이는 워크플로가 추가하는 작업량에 대한 판단이며, 소요 시간을 측정한 주장은 아닙니다.

현재 brainstorming 파일은 작업 규모를 세 가지로 구분합니다.

• 간단하고 명확한 작업: 요청 자체에 필요한 설명이 모두 있으므로 바로 수행합니다.
• 작은 변경: 대화에서 내용을 합의한 뒤 일반 워크플로에 따라 구현합니다.
• 프로젝트: 문서로 된 설계를 승인받은 뒤 전체 소프트웨어 구현 계획을 작성합니다.

같은 파일은 사용자가 질문을 받지 않겠다고 명시하면 브레인스토밍의 확인 절차를 끝낼 수 있도록 합니다. 다만 이 선택이 나머지 테스트나 검증 지침까지 자동으로 취소하지는 않습니다. 작업 규모 판단과 질문 생략 규칙

다음과 같이 지시하면 유용합니다. “작은 변경입니다. 설명은 대화 안에서 정리하고, 기존 테스트 환경을 사용하며, 기능 범위를 넓히지 마세요.” 이미 결정된 문구 수정이라면 정확한 텍스트와 범위를 제시합니다. 이는 플러그인의 지침 우선순위가 인정하는 작업 제약이며, 숨겨진 우회 명령이 아닙니다.

이때의 한계는 절차에 드는 추가 부담입니다. 대화, 계획 문서, 작업 배정, 리뷰가 남아 있는 불확실성에 비해 과도해질 수 있습니다. 소스에는 이런 단계가 명시돼 있지만, 특정 변경에 몇 분이 걸릴지는 나와 있지 않습니다. 세션이 반복해서 작업 범위를 무시한다면 저장소의 diagnosing-superpowers로 대화 기록의 근거를 살펴보며 무슨 일이 있었는지 조사할 수 있습니다. 세션 진단 스킬

Superpowers에 대한 기대 중 무엇이 과장됐나요?

정해진 워크플로를 따른다는 사실만으로 소프트웨어가 올바르거나 개발 속도가 빨라졌다고 입증되지는 않습니다. 실패하는 테스트가 잘못된 요구사항을 담을 수도 있고, 계획이 통합 과정의 제약을 놓칠 수도 있으며, 에이전트 리뷰어가 결함을 발견하지 못할 수도 있습니다. 완료 메시지의 자신감보다 테스트의 검증 조건과 변경 내역을 평가해야 합니다.

서브에이전트 중심의 개발이라고 해서 모든 구현 작업이 동시에 실행되는 것도 아닙니다. 현재 스킬은 충돌을 피하기 위해 해당 워크플로에서 구현 서브에이전트를 병렬로 실행하는 것을 명시적으로 금지합니다. dispatching-parallel-agents는 독립적인 문제를 다루는 별도의 스킬입니다. 구현 작업 배정 규칙

설치했다고 해서 작업 범위나 통합에 대한 사용자의 책임이 사라지지도 않습니다. 플러그인 자체의 마무리 절차도 병합 결정을 사용자에게 맡깁니다. Superpowers가 가장 분명하게 제공하는 것은 절차입니다. Claude에게 무엇을 확인하고 어떤 근거를 제시해야 하는지 알려 줍니다. 실제 유용성은 작업의 성격과 에이전트가 그 지침을 따르는지에 달려 있습니다.

누구에게 적합하며, 처음에는 무엇을 해 보면 좋을까요?

개발 과정에서 필요한 판단을 반복해서 건너뛰는 것이 문제라면 설치할 만합니다. 혼자 개발하면서 에이전트가 요구사항 확인을 서둘러 넘겨 버린다면, 의미 있는 실패 사례가 있는 작은 범위의 기능부터 시작합니다. 세션이 구현 전에 동작을 정리하는지, 구현 후에는 근거를 제시하는지 확인해야 합니다.

개발 체계가 잡힌 팀이라면 먼저 팀의 계획, 테스트, 리뷰 관행과 플러그인 지침을 조율해야 합니다. 기존 스킬에 원하는 절차가 이미 담겨 있다면 범용 워크플로를 추가하는 일이 중복될 수 있습니다. 대부분의 작업이 사양이 완전히 정해진 아주 작은 수정이라면, 그 작업만을 위해 전체 방식을 도입할 이유는 상대적으로 적습니다.

월요일에는 범위가 한정된 변경 하나를 골라 인수 기준을 적어 봅니다. Superpowers를 사용하면서 선택된 스킬을 살펴보고 최종 변경 내역을 검토한 뒤, 추가된 결과물 하나하나가 판단에 도움이 됐는지 평가합니다. 계획이 길게 나왔기 때문이 아니라 확인 절차가 유용했기 때문에 워크플로를 유지해야 합니다.

서로 다른 문제를 해결하는 관련 툴은 추천 Claude Code 플러그인에서 살펴볼 수 있습니다.

Claude Superpowers 자주 묻는 질문

AI를 활용한 개발에 관한 실용적인 안내를 받아 보려면 뉴스레터를 구독해 주세요.