Skip to content
푸땡로그
Go back

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

코딩 에이전트는 코드를 잘 쓰지만, 오래 쓰면 같은 문제가 반복됩니다. 결과물의 품질에 비해 일하는 순서가 일정하지 않습니다.

어떤 날은 좋은 코드를 내고, 어떤 날은 설계 없이 구현으로 뛰어듭니다. 테스트는 형식적으로 넘기고, 범위만 커진 뒤 “끝났다”고 말하지만 남은 일이 쌓이기도 합니다. 모델 성능이 좋아져도 일관된 개발 프로세스는 따로 만들어야 합니다.

Superpowers(obra/superpowers)는 이 문제를 다루는 프로젝트입니다. 코딩 에이전트가 특정 개발 방식을 따르도록 만드는 스킬 프레임워크이자 개발 방법론입니다. 이름만 보면 프롬프트 모음으로 오해하기 쉬워서, 이 글에서는 방법론 쪽을 중심으로 설명합니다.


Superpowers는 무엇인가요?

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

Superpowers가 에이전트에게 요구하는 동작은 다음과 같습니다.

Superpowers는 모델이 알아서 잘하기를 기대하지 않고, 개발 프로세스를 먼저 강제합니다.


왜 프로세스를 강제하나요?

코딩 에이전트를 써보면 다음과 같은 일이 자주 생깁니다.

모델 능력이 부족해서 생기는 문제는 아닙니다. 기본 동작이 “바로 도와주기”에 맞춰져 있어서 생깁니다.

실제 개발에서는 다음 순서를 지켜야 합니다.

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

Superpowers는 이 순서를 에이전트 쪽에 주입합니다. 답변 품질과 함께 개발 진행 방식의 안정성을 올리려는 시도입니다.


skill들이 이어져 하나의 개발 습관을 만듭니다

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
Tip 설치 후에는 해당 도구의 플러그인·확장 목록에 superpowers가 보이는지 확인합니다. 나중에 스킬이 동작하지 않을 때 원인을 좁히는 기준이 됩니다.

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

Superpowers는 Claude Code 워크플로우에 플러그인으로 붙여 바로 쓸 수 있습니다.

설치는 위 「설치 방법」 절을 따릅니다. 사용법은 다음 두 가지로 정리됩니다.

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

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

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

README에는 스킬 이름 기준으로 아래 순서가 적혀 있습니다. 실제 세션에서는 단계가 겹치거나 순서가 바뀌기도 합니다. 이 목록은 어떤 skill이 언제 개입하는지 이해하는 데 씁니다.

  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가 몇 시간짜리 작업에서도 계획을 따르게 하려는 장치입니다.

상황별 요청 예시

기능 설계부터 시작할 때

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

이 요청은 brainstorming으로 이어집니다. 요구사항이 덜 정리된 상태일 때 씁니다.

구현 계획이 필요할 때

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

이 요청은 writing-plans 흐름으로 이어집니다. Claude Code가 큰 작업을 한 번에 처리하려는 경향을 줄입니다.

디버깅할 때

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

이 요청은 systematic-debugging으로 이어집니다. Claude Code가 원인을 찾기 전에 수정부터 시작하는 일을 줄입니다.

구현을 진짜 시작할 때

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

이 요청은 test-driven-development, executing-plans, requesting-code-review로 이어집니다.

마무리할 때

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

이 요청은 finishing-a-development-branch로 이어집니다.

Tip 에이전트의 결과가 불안정하다면 프롬프트를 늘리기 전에 에이전트가 따를 작업 순서부터 정합니다. Superpowers는 작업 순서를 정하면 결과가 안정된다는 가설을 따르는 프로젝트입니다.

README가 밝힌 네 가지 원칙

README는 Superpowers의 원칙을 네 줄로 밝힙니다.

이 원칙에 따르면 Superpowers는 “빠르게 많이 만들기”보다 과정을 통제해 덜 틀리기를 우선합니다. 많은 AI 코딩 도구가 생성 속도를 내세우는 것과 달리, Superpowers는 진행 방식을 다룹니다.


어떤 환경에 맞나

Superpowers는 다음 환경에 맞습니다.

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

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

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

“분명 이걸 원한 게 아닌데 왜 여기까지 갔지?” 이런 경험이 많다면 Superpowers의 작은 태스크 단위 계획과 검증 흐름을 적용해 봅니다.

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

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

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

subagent 기반 개발 흐름을 체계적으로 써보고 싶다면 이 프로젝트로 시작할 수 있습니다.


맞지 않는 경우

절차를 강제하는 방식이라 맞지 않는 상황도 있습니다.

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

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

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

테스트 우선 개발을 선호하는 사람에게는 장점입니다. 다만 모든 작업에서 그 방식이 최선인지는 별개의 문제입니다.

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

Superpowers는 기능 세트보다 행동 규율에 가깝습니다. 잘 쓰려면 기능을 익히는 것과 함께 절차 자체를 받아들여야 합니다.

주의 Superpowers는 코딩 에이전트를 더 엄격한 절차 안에 넣습니다. 막히지 않고 빨리 진행하는 방식을 선호한다면 무겁게 느껴질 수 있습니다.

여러 코딩 에이전트를 지원합니다

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

업데이트 방식은 도구마다 다르고, README에 따르면 자동으로 따라오는 경우도 있습니다. 설치된 버전은 각 CLI의 플러그인·확장 목록에서 확인합니다.

Superpowers는 한 모델만을 위한 프롬프트 세트로 만들어지지 않았습니다. 여러 에이전트 환경에서 같은 작업 방식을 쓰도록 설계됐고, 이 프로젝트의 자산은 특정 모델보다 프로세스 자체에 있습니다.


코딩 에이전트를 평가하는 다른 기준

지금까지 코딩 에이전트는 주로 다음 기준으로 비교됐습니다.

Superpowers는 다른 기준을 제시합니다.

Superpowers의 답은 “모델만 믿지 말고 workflow를 만들어라”입니다.


마무리

obra/superpowers는 코딩 에이전트에게 개발 습관과 작업 절차를 주입합니다. 브레인스토밍, 계획, TDD, subagent 개발, 리뷰, 브랜치 마무리로 이어지는 흐름은 자동완성보다 “엔지니어링 프로세스”에 가깝습니다.

모든 상황에 가볍게 맞는 도구는 아닙니다. 그래도 이 프로젝트는 코드를 잘 쓰는 것과 좋은 순서로 일하는 것은 다른 능력이며, 에이전트에게는 후자도 필요하다는 점을 보여줍니다.

관련 글


참고 자료


Share this post on:

Previous Post
defuddle 살펴보기: 어떤 웹페이지든 깔끔한 Markdown으로 추출하는 오픈소스
Next Post
OpenPencil 살펴보기: Figma 파일을 그대로 열 수 있는 AI 네이티브 오픈소스 설계 에디터