Superpowers 살펴보기: 코딩 에이전트를 진짜 개발 프로세스로 묶는 스킬 프레임워크

코딩 에이전트는 분명 강력해졌습니다.
그런데 오래 쓰다 보면 같은 문제가 반복됩니다. 똑똑한데, 일하는 방식은 제멋대로라는 점입니다.

어떤 날은 훌륭한 코드를 내고, 어떤 날은 설계 없이 구현으로 뛰어들며, 테스트는 형식적으로 넘기고, 범위만 커진 뒤 “끝났다”고 말해놓고 실제로는 남은 일이 쌓이기도 합니다.
모델 성능이 좋아지는 것과 일관된 개발 프로세스가 생기는 것은 별개의 문제입니다.

이 지점에서 주목할 만한 프로젝트가 Superpowers입니다.
obra/superpowers는 프롬프트 모음이 아니라, 코딩 에이전트에게 특정 개발 방식을 몸에 익히게 하려는 스킬 프레임워크이자 개발 방법론에 가깝습니다.

Superpowers는 무엇인가요?

Superpowers는 코딩 에이전트를 위한 agentic skills framework입니다.
저장소 설명을 풀면, 조합 가능한 여러 skill과 이를 실제로 쓰게 만드는 초기 지침을 묶어 하나의 개발 워크플로우로 만든 시스템입니다.

핵심은 단순합니다.

• 에이전트가 곧바로 코드를 쓰지 않게 합니다
• 사용자 의도를 질문으로 다듬어 spec을 만듭니다
• 설계를 확인받은 뒤 구현 계획을 세웁니다
• 작업을 잘게 나눕니다
• subagent로 병렬·단계 실행을 진행합니다
• 리뷰와 검증을 거쳐 마무리합니다

“좋은 모델이 알아서 잘하겠지”가 아니라,
좋은 프로세스를 먼저 강제하는 쪽에 가깝습니다.

왜 이런 접근이 중요한가요?

코딩 에이전트를 써본 사람이라면 다 비슷한 경험이 있을 겁니다.

• 너무 빨리 코드를 쓰기 시작합니다
• 요구사항이 모호한데도 일단 구현합니다
• 테스트보다 추측을 먼저 합니다
• 수정은 했는데 검증은 약합니다
• 한 번 잘못 가기 시작하면 꽤 멀리 갑니다

모델이 멍청해서가 아닙니다.
기본 동작이 “바로 도와주기”에 맞춰져 있기 때문에 그렇게 보일 뿐입니다.

하지만 실제 개발에서는 이 순서가 더 중요합니다.

1. 문제를 이해하기
2. 설계하기
3. 작은 단위로 나누기
4. 테스트하기
5. 검증하기
6. 리뷰하고 정리하기

Superpowers는 이 흐름을 에이전트 쪽에 주입합니다.
“답변 품질”만이 아니라 개발 진행 방식의 안정성을 올리려는 시도로 읽힙니다.

Superpowers가 재밌는 이유는 “스킬”보다 “방법론”에 있습니다

겉으로 보면 이 프로젝트는 skill 모음입니다.
실제로도 여러 skill이 들어 있습니다.

예를 들면:

• brainstorming
• writing-plans
• test-driven-development
• systematic-debugging
• requesting-code-review
• using-git-worktrees
• subagent-driven-development
• finishing-a-development-branch

이걸 기능 목록으로만 보면 핵심이 흐려집니다.
Superpowers의 포인트는 개별 skill이 아니라, skill들이 이어져 하나의 개발 습관을 만든다는 데 있습니다.

“필요할 때 하나 꺼내 쓰는 도구함”이 아니라,
에이전트의 기본 행동 양식을 바꾸는 운영체제에 더 가깝습니다.

전체 흐름은 대략 이렇게 이해하면 됩니다

Superpowers가 의도하는 개발 플로우를 단순화하면 이렇습니다.

flowchart TB
    subgraph P1["① 정리·합의"]
        direction TB
        A(["문제·아이디어"]) --> B["brainstorming"]
        B --> C["설계 승인"]
    end

    subgraph P2["② 계획·구현"]
        direction TB
        C --> D["writing-plans"]
        D --> E["subagent-driven-development"]
        E --> F["test-driven-development"]
    end

    subgraph P3["③ 검증·마무리"]
        direction TB
        F --> G["requesting-code-review"]
        G --> H["verification-before-completion"]
        H --> I["finishing-a-development-branch"]
    end

이 흐름에서 중요한 점은 두 가지입니다.

1. 구현 전에 설계와 계획이 먼저 나온다는 것
2. 구현 후에도 곧바로 끝내지 않고 검증·정리 단계가 따로 있다는 것

에이전트 사용이 어긋나는 경우, 모델이 코드를 못 써서보다 너무 빨리 쓰기 시작해서 생기는 경우가 많습니다. 이 구조는 그 지점을 겨냥합니다.

핵심 skill 몇 개만 봐도 방향성이 분명합니다

1. brainstorming

이 skill은 코드를 쓰기 전에 작동합니다.
사용자의 아이디어를 질문으로 다듬고, 대안을 탐색하고, 작은 단위의 설계 문서를 만들어 확인받는 역할을 합니다.

에이전트가 “알아서 구현”으로 가는 걸 막고,
먼저 생각하게 만드는 브레이크 역할을 합니다.

2. writing-plans

설계가 승인되면, 이 skill이 작업을 아주 작은 단위로 나눕니다.
저장소 설명대로라면 2~5분 단위 태스크로 쪼개고, 각 태스크에 파일 경로·코드·검증 방법까지 붙이는 식입니다.

사람에게도 좋은 습관이지만, 에이전트에게는 더 중요합니다.
작업이 클수록 방향 이탈이 쉬워지기 때문입니다.

3. test-driven-development

Superpowers는 TDD를 꽤 강하게 밀고 있습니다.
단순히 “테스트도 있으면 좋다”가 아니라, RED-GREEN-REFACTOR를 중심에 놓습니다.

이 철학은 분명 취향을 타지만, 적어도 에이전트에게는 꽤 합리적입니다.
에이전트는 자신감 있게 틀릴 수 있기 때문에, 증거 없는 구현보다 실패하는 테스트부터 시작하는 방식이 안정적일 수 있습니다.

4. subagent-driven-development

이 부분이 특히 흥미롭습니다.
작업을 여러 subagent에게 분산하고, 단계별 리뷰를 거쳐 진행하는 구조입니다.

한 명의 만능 에이전트가 다 하는 구조가 아니라,
작업자·리뷰어·검증자에 가까운 역할 분담을 에이전트 안에서 재현하려는 시도입니다.

멀티에이전트 개발 워크플로우가 앞으로 어떻게 정리될지 보여 주는 사례 중 하나로 보입니다.

설치 방법

플랫폼마다 경로가 다릅니다. 아래 명령·절차는 Superpowers README ↗를 기준으로 했고, Claude Code UI가 바뀌면 공식 문서를 함께 확인하는 것이 좋습니다.

Claude Code

Anthropic 공식 마켓플레이스에서 쓰는 방법입니다. 플러그인 소개 페이지는 claude.com/plugins/superpowers ↗입니다.

Claude Code 안에서 슬래시 명령으로 설치합니다.

/plugin install superpowers@claude-plugins-official

Superpowers 마켓플레이스를 쓰는 방법입니다. 같은 저장소에서 관리하는 다른 플러그인까지 같이 쓰고 싶을 때 유용합니다.

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

위 둘 중 하나의 소스에서만 설치하면 됩니다. 조직 정책·업데이트 선호에 맞게 고르면 됩니다.

Cursor

Agent 채팅에서 아래처럼 추가하거나, 플러그인 마켓에서 superpowers를 검색해 설치합니다.

/add-plugin superpowers

OpenAI Codex CLI

/plugins

실행 후 검색창에서 superpowers를 찾아 Install Plugin을 선택합니다.

OpenAI Codex 앱

사이드바 Plugins → Coding 섹션의 Superpowers 옆 + 를 눌러 안내에 따라 설치합니다.

OpenCode

에이전트에게 아래 URL의 설치 안내를 따르라고 요청하거나, 해당 문서를 직접 열어 순서대로 진행합니다.

Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md

저장소에는 OpenCode용 보조 문서 ↗도 있습니다.

GitHub Copilot CLI

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

Gemini CLI

gemini extensions install https://github.com/obra/superpowers

업데이트할 때는 다음과 같습니다.

gemini extensions update superpowers

Claude Code에서는 어떻게 쓰나요?

Superpowers가 흥미로운 이유 중 하나는, 이론이 아니라 Claude Code 워크플로우에 플러그인으로 붙여 바로 쓸 수 있다는 점입니다.

설치는 위 「설치 방법」 절을 따르면 됩니다. 사용 측면의 핵심은 이렇게 정리할 수 있습니다.

• 별도 긴 주문문을 외울 필요는 없습니다. README 기준으로 에이전트는 작업에 앞서 관련 skill을 스스로 찾아 적용하는 흐름을 전제로 합니다. “제안”이 아니라 의무에 가까운 워크플로라고 읽는 편이 맞습니다.
• 평소처럼 무엇을 만들지·고칠지를 자연어로 말하면, brainstorming → 계획 → 구현 → 리뷰·검증 순으로 skill이 끼어들기 쉽습니다.

예를 들어 새 작업을 시작할 때 이렇게 말할 수 있습니다.

• “이 기능 설계부터 같이 해보자”
• “이 이슈 디버깅 도와줘”
• “이 기능 구현 계획 먼저 짜줘”
• “이 브랜치 작업 마무리하자”

Superpowers가 켜진 환경에서는 상황에 맞는 skill이 앞단에서 개입합니다.

공식 README가 제시하는 기본 워크플로

README에는 스킬 이름 기준으로 대략 아래 순서가 적혀 있습니다. 실제 세션에서는 단계가 겹치거나 순서가 바뀌기도 하지만, “무엇이 언제 개입하는지”를 이해하는 용도로 쓰면 됩니다.

1. brainstorming — 코드를 쓰기 전. 질문으로 아이디어를 다듬고, 대안을 탐색하며 설계를 짧은 단위로 보여 주고 검증받습니다.
2. using-git-worktrees — 설계가 승인된 뒤. 새 브랜치·격리 워크스페이스를 만들고, 프로젝트 셋업과 깨끗한 테스트 베이스라인을 확인합니다.
3. writing-plans — 승인된 설계를 바탕으로. 2~5분 단위 태스크로 쪼개고, 파일 경로·코드·검증 단계를 구체적으로 적습니다.
4. subagent-driven-development 또는 executing-plans — 계획이 잡힌 뒤. 태스크마다 새 subagent를 붙이거나, 배치 실행과 사람이 끊어 주는 체크포인트를 둡니다.
5. test-driven-development — 구현 중. RED → GREEN → REFACTOR를 전제로 하며, 테스트 없이 쓴 코드는 정리합니다.
6. requesting-code-review — 태스크 사이. 계획 대비로 리뷰하고 심각도별로 이슈를 나열하며, 치명적 문제는 진행을 막습니다.
7. finishing-a-development-branch — 태스크가 끝난 뒤. 테스트를 확인하고 merge·PR·유지·폐기 같은 선택지를 제시한 다음 worktree를 정리합니다.

README에는 “에이전트는 어떤 작업이든 관련 skill을 먼저 확인한다”고까지 적혀 있습니다. 사용자가 매번 스킬 파일 이름을 외울 필요는 적고, 지금 단계가 무엇인지(설계·계획·구현·디버깅·마무리)를 말로 분명히 해 주는 편이 잘 맞습니다.

한 줄로만 요약하면 정리 → 합의 → 계획 → 구현·테스트 → 리뷰·검증 → 브랜치 마무리에 가깝습니다.

이 흐름은 일반적인 Claude Code 사용 방식과 꽤 다릅니다.
보통은 사용자가 “이 파일 고쳐줘”라고 하면 곧바로 수정으로 들어가는데, Superpowers는 그 전에 정리 → 합의 → 계획 단계를 한 번 더 거치게 만듭니다.

Claude Code에서 체감되는 포인트

1. 바로 구현하지 않고 먼저 생각하게 만듭니다

이건 특히 좋을 때가 많습니다.
코딩 에이전트는 너무 빨리 움직이는 경우가 많은데, Superpowers는 그 속도를 일부러 한 번 늦춥니다.

예를 들어 사용자가 모호하게 요청해도 바로 파일을 건드리기보다:

• 진짜 원하는 결과가 뭔지 묻고
• 설계 범위를 좁히고
• 대안을 확인하고
• 그다음에 구현으로 넘어갑니다

Claude Code의 빠른 실행력 위에
엔지니어링에 가까운 절차를 한 겹 더 얹는 느낌입니다.

2. 긴 작업에서 덜 흔들립니다

짧은 수정은 원래도 Claude Code가 잘합니다.
하지만 길어질수록 종종 생기는 문제가 있습니다.

• 초반 합의가 흐려짐
• 범위가 커짐
• 테스트보다 구현이 앞섬
• 끝났다고 했는데 검증이 부족함

Superpowers는 이런 긴 작업을 상대적으로 더 안정적으로 끌고 가려는 구조입니다.
특히 subagent 기반 흐름과 계획 단위 실행이 들어가면, Claude Code가 몇 시간짜리 작업을 덜 무너지고 따라가게 만들려는 의도가 읽힙니다.

Claude Code에서 이런 식으로 쓰면 좋습니다

기능 설계부터 시작할 때

“이 기능 추가하고 싶은데, 바로 구현하지 말고 먼저 설계부터 같이 해줘.”

이런 요청은 brainstorming과 잘 맞습니다.
요구사항이 덜 정리된 상태라면 특히 효과가 큽니다.

구현 계획이 필요할 때

“설계는 됐고, 이제 구현 계획을 작은 단위로 쪼개줘.”

이런 요청은 writing-plans 흐름과 잘 맞습니다.
Claude Code가 큰 작업을 한 번에 물어뜯는 걸 줄일 수 있습니다.

디버깅할 때

“이 문제 원인부터 체계적으로 찾아줘. 추측 말고 단계적으로.”

이건 systematic-debugging 스타일과 잘 맞습니다.
Claude Code는 종종 성급하게 수정에 들어가는데, 이런 흐름을 주면 훨씬 낫습니다.

구현을 진짜 시작할 때

“이제 계획대로 하나씩 진행해줘. 각 단계마다 테스트와 검증 포함해서.”

이건 test-driven-development, executing-plans, requesting-code-review 쪽과 자연스럽게 연결됩니다.

마무리할 때

“이 브랜치 마무리 전에 테스트, 리뷰, 정리까지 다 확인해줘.”

이건 finishing-a-development-branch 감각으로 보면 됩니다.

이 프로젝트의 철학은 꽤 명확합니다

README를 읽어보면 Superpowers는 기술보다도 철학을 강하게 드러냅니다.

• Test-Driven Development
• Systematic over ad-hoc
• Complexity reduction
• Evidence over claims

이 네 줄만 봐도 성격이 보입니다.

이 프로젝트는 “빠르게 많이 만들기”보다
과정이 통제된 상태에서 덜 틀리게 만들기를 중시합니다.

이건 지금 AI 코딩 도구 흐름에서 꽤 의미 있는 포지션입니다.
대부분의 도구가 “더 빠른 생성”을 말할 때, Superpowers는 더 나은 진행 방식을 말하고 있기 때문입니다.

어디에 특히 잘 맞을까

제가 보기엔 Superpowers는 아래 같은 환경에 특히 잘 맞습니다.

1. 요구사항이 자주 흐려지는 팀

아이디어는 있는데 구현 전에 정리가 안 되는 팀이라면
brainstorming → spec → plan 흐름만으로도 꽤 도움을 받을 수 있습니다.

2. 에이전트가 너무 자주 엇나가는 경우

“분명 이걸 원한 게 아닌데 왜 여기까지 갔지?”
이런 경험이 많다면, Superpowers의 작은 태스크 단위 계획과 검증 플로우가 잘 맞을 수 있습니다.

3. 리뷰/검증이 중요한 코드베이스

테스트, 코드리뷰, 브랜치 정리가 중요한 프로젝트에서는
Superpowers가 단순한 생산성 도구보다 품질 보조 장치로 더 의미가 있습니다.

4. 멀티에이전트 워크플로우를 실험하고 싶은 경우

subagent 기반 개발 흐름을 체계적으로 써보고 싶다면
이 프로젝트는 꽤 좋은 출발점이 됩니다.

반대로 모든 사람에게 맞는 건 아닙니다

이런 접근은 분명히 장점이 있지만, 동시에 취향도 탑니다.

1. 빠른 프로토타입에는 무겁게 느껴질 수 있습니다

간단한 스크립트 하나 만들 때도 brainstorming, 계획, 리뷰 흐름을 다 거치면
오히려 답답하게 느껴질 수 있습니다.

2. TDD 중심 철학은 호불호가 있습니다

테스트 우선 개발을 좋아하는 사람에게는 강점이지만,
항상 그 방식이 최선이라고 보는 건 또 다른 문제입니다.

3. 도구보다 절차를 받아들여야 합니다

Superpowers는 “예쁜 기능 세트”라기보다 행동 규율에 가깝습니다.
그래서 이걸 잘 쓰려면 기능을 배우는 것보다, 그 철학을 받아들이는 편이 더 중요합니다.

플랫폼 지원도 꽤 현실적입니다

Superpowers는 Claude 전용처럼 보이지만, 실제로는 여러 코딩 에이전트를 README에 명시해 둡니다. 구체적인 명령과 절차는 위 「설치 방법」 절에 모아 두었습니다.

업데이트는 도구마다 다르고, 종류에 따라 자동으로 따라오는 경우도 README에 적혀 있습니다. 버전이 궁금하면 각 CLI의 플러그인·확장 목록을 확인하는 것이 가장 확실합니다.

중요한 포인트는 이것입니다.
“한 모델만 위한 프롬프트 세트”가 아니라,
여러 에이전트 환경에서 통하는 작업 방식을 만들려는 방향으로 읽힙니다.

Superpowers의 핵심 자산은 특정 모델보다 프로세스 자체일 가능성이 큽니다.

개인적으로 재미있는 부분

이 프로젝트가 특히 재미있는 건,
AI 코딩 도구의 다음 경쟁력이 어디에 있을지를 꽤 선명하게 보여준다는 점입니다.

지금까지는 대체로 이런 경쟁이 많았습니다.

• 누가 더 코드를 잘 생성하는가
• 누가 더 큰 컨텍스트를 다루는가
• 누가 더 똑똑해 보이는가

그런데 앞으로는 이런 질문이 더 중요해질 수도 있습니다.

• 누가 더 안정적으로 일하는가
• 누가 덜 엇나가는가
• 누가 더 좋은 프로세스를 강제하는가
• 누가 더 검증 가능한 방식으로 움직이는가

Superpowers는 이 질문에 대한 비교적 직설적인 답입니다.
“모델만 믿지 말고 workflow를 만들어라”에 가까운 태도입니다.

마무리

obra/superpowers는 단순한 프롬프트 모음집으로 보기엔 아깝습니다.
이 프로젝트는 코딩 에이전트에게 개발 습관과 작업 절차를 주입하려는 시도에 더 가깝습니다.

브레인스토밍, 계획, TDD, subagent 개발, 리뷰, 브랜치 마무리까지 이어지는 흐름은
단순 자동완성보다 훨씬 “엔지니어링 프로세스”에 가까운 감각을 만듭니다.

물론 모든 상황에 가볍게 맞는 도구는 아닙니다.
하지만 적어도 한 가지는 분명히 보여줍니다.

좋은 코딩 에이전트는 단순히 코드를 잘 쓰는 에이전트가 아니라, 좋은 순서로 일하는 에이전트일 수 있다는 점입니다.

그 기준에서 Superpowers는 꽤 흥미로운 프로젝트입니다.

관련 글

• npx skills: Vercel 실험에서 AI 에이전트 오픈 표준이 되기까지
• Claude Code Skills 실전 가이드

참고 자료

• GitHub: https://github.com/obra/superpowers ↗
• Superpowers for Claude Code: https://blog.fsck.com/2025/10/09/superpowers/ ↗
• Discord(README 기준): https://discord.gg/35wsABTejz ↗