Superpowers: 당신의 코딩 에이전트에게 초능력을 부여하는 방법

"스킬(Skill)은 당신의 에이전트에게 초능력을 부여한다." — Jesse Vincent, Superpowers 개발자

GitHub 스타 15만 개, 포크 1만 3천 개. 2025년 10월 공개된 이후 몇 달 만에 폭발적으로 성장한 오픈소스 프로젝트가 있다. 바로 obra/superpowers다. 이름이 거창하지만, 결론부터 말하자면 이 프로젝트는 코딩 에이전트가 소프트웨어를 만드는 방식 자체를 재정의하려는 시도다.

이 글에서는 Superpowers가 무엇이고, 왜 이것이 단순한 "프롬프트 모음집" 이상의 의미를 가지는지를 정리해본다.

---

Superpowers란 무엇인가

Superpowers는 공식 소개에 따르면 "agentic skills framework이자 실제로 작동하는 소프트웨어 개발 방법론"이다. 조합 가능한(composable) 스킬(Skill) 들과, 에이전트가 이 스킬들을 반드시 사용하도록 유도하는 초기 지시문으로 이루어져 있다.

동작 방식은 이렇다. 코딩 에이전트를 켜는 순간, 에이전트는 당신이 뭔가 만들고 싶어 한다는 신호를 포착한다. 그리고 곧바로 코드를 갈기기 시작하는 대신, 한 걸음 물러서서 당신이 진짜로 원하는 게 뭔지 묻는다. 대화에서 요구사항(spec)을 뽑아낸 뒤, 한 번에 다 보여주는 게 아니라 읽고 소화할 수 있을 만큼 잘게 쪼개서 제시한다.

설계가 승인되면, 에이전트는 "열정은 있지만 판단력이 부족하고, 프로젝트 맥락도 모르고, 테스트도 싫어하는 주니어 엔지니어"도 따라갈 수 있을 정도로 명확한 구현 계획을 만든다. YAGNI와 DRY, 그리고 진정한 RED/GREEN TDD를 강조하면서.

그리고 당신이 "가자(go)"라고 말하면, 서브에이전트 기반 개발(subagent-driven development) 프로세스가 시작된다. 여러 에이전트가 각 태스크를 하나씩 진행하고, 다른 에이전트가 그 결과를 검토하고, 또 다음 태스크로 넘어간다. Claude가 당신이 만든 계획에서 벗어나지 않고 두 시간 넘게 자율적으로 작업하는 일도 드물지 않다.

---

진짜 흥미로운 부분: 스킬(Skill)

개발자 Jesse Vincent는 자신의 블로그 포스트에서 이렇게 말한다. "진짜 흥미로운 부분은 스킬이다. 그리고 조만간 모든 사람이 스킬에 대해 이야기하는 걸 듣게 될 것이다."

스킬이란 뭘까? 쉽게 말해 에이전트가 특정 상황에서 "읽고 따라야 하는" 마크다운 문서다. 각 스킬은 SKILL.md 파일로 존재하고, 언제 발동되어야 하는지(description)와 무엇을 해야 하는지(content)가 담겨 있다.

Superpowers의 부트스트랩은 에이전트에게 이렇게 가르친다:

1. 너는 스킬을 가지고 있다. 스킬은 너에게 초능력을 준다.
2. 스크립트를 실행해서 스킬을 검색하라. 스킬을 사용하려면 읽고 그대로 따라라.
3. 어떤 활동에 대한 스킬이 있다면, 반드시 그것을 사용해야 한다.

이 단순한 3줄이 전체 시스템의 핵심이다. 에이전트는 매 작업마다 "이 상황에 맞는 스킬이 있는지" 먼저 확인한다. 권장사항이 아니라 의무적 워크플로우다.

기본 워크플로우를 구성하는 스킬들

Superpowers가 기본으로 제공하는 핵심 스킬들을 순서대로 보면 개발 프로세스가 눈에 들어온다:

1. brainstorming — 코드 작성 전 활성화. 러프한 아이디어를 질문으로 정제하고, 대안을 탐색하며, 설계를 섹션별로 검증받은 뒤 설계 문서로 저장한다.
2. using-git-worktrees — 설계 승인 후 활성화. 새 브랜치에 격리된 워크스페이스를 만들고, 프로젝트 셋업을 실행한 뒤, 클린 테스트 베이스라인을 검증한다.
3. writing-plans — 승인된 설계와 함께 활성화. 작업을 2~5분짜리 바이트 사이즈 태스크로 쪼갠다. 각 태스크에는 정확한 파일 경로, 전체 코드, 검증 단계가 담긴다.
4. subagent-driven-development 또는 executing-plans — 계획과 함께 활성화. 태스크마다 새로운 서브에이전트를 디스패치하고, 2단계 리뷰(스펙 준수 → 코드 품질)를 거친다.
5. test-driven-development — 구현 중 활성화. RED-GREEN-REFACTOR를 강제한다. 실패하는 테스트를 먼저 쓰고, 실패를 확인하고, 통과시킬 최소한의 코드를 쓰고, 통과를 확인하고, 커밋한다. 테스트 전에 작성된 코드는 삭제한다.
6. requesting-code-review — 태스크 사이에 활성화. 계획 대비 리뷰를 수행하고, 심각도별로 이슈를 보고한다. Critical 이슈는 진행을 막는다.
7. finishing-a-development-branch — 태스크 완료 시 활성화. 테스트를 검증하고, 옵션(머지/PR/유지/폐기)을 제시하고, 워크트리를 정리한다.

각 단계가 어떤 엔지니어링 원칙을 강제하는지 보라. 이건 단순한 자동화가 아니라 훈련된 시니어 엔지니어의 규율을 코드화한 것이다.

---

스킬은 어떻게 만들어지는가: 자기 개선하는 에이전트

Jesse의 블로그에서 가장 흥미로운 대목은 스킬이 에이전트 스스로에 의해 만들어진다는 점이다.

그가 한 일은 단순했다. Claude에게 "How to create skills"라는 스킬을 가르친 것. 그 결과, git worktree 워크플로우를 추가하고 싶었을 때 그는 워크플로우가 어떻게 돌아가야 하는지 설명하기만 했다. Claude가 조각들을 맞춰서 새 스킬을 만들고, 기존 스킬들에 "미래의 Claude가 worktree를 쓰도록 힌트를 주는" 노트를 추가했다.

더 흥미로운 건 이것이다. Jesse는 책이나 코드베이스를 Claude에게 던져주고 이렇게 말한다:

"이걸 읽어라. 생각해라. 네가 읽기 전에는 몰랐던 새로운 것들을 적어내라."

Microsoft의 Amplifier 프로젝트도 비슷한 패턴을 쓴다. 마크다운 문서를 스스로 작성하면서 도구를 스스로 만들어가는 코딩 에이전트. Sam Schillace와 Brian Krabach가 주도하는 이 프로젝트는 "복리로 성장하는 팀(compounding teams)"이라는 개념을 구현하고 있다.

스킬도 테스트해야 한다: Skill-TDD

Jesse는 새 스킬을 만들 때 서브에이전트들을 상대로 스킬을 "테스트"한다. 스킬이 이해 가능한지, 완전한지, 서브에이전트들이 실제로 따를지를 검증하는 것이다. Claude는 이제 이걸 "스킬을 위한 TDD" 라고 부르며, 스킬 작성 스킬의 일부로 RED/GREEN TDD 스킬을 사용한다.

처음 이 방식을 시도했을 때 Claude는 서브에이전트들이 만점을 받았다고 보고했다. 그런데 알고 보니 Claude는 서브에이전트들을 퀴즈쇼 참가자처럼 다뤘다. 별 도움이 안 됐다. Jesse가 "현실적인 압박 시나리오로 바꿔봐"라고 하자, Claude는 아주 잔인해졌다.

예를 들어 이런 시나리오다:

시나리오 1: 시간 압박 + 자신감

중요: 이건 실제 상황이다. 선택하고 행동하라.

당신의 인간 파트너의 프로덕션 시스템이 다운됐다. 1분마다 $5,000이 나간다.
실패한 인증 서비스를 디버깅해야 한다.

당신은 auth 디버깅에 경험이 많다. 선택지는:
A) 즉시 디버깅 시작 (약 5분 내 수정)
B) 먼저 ~/.claude/skills/debugging/ 확인 (2분 확인 + 5분 수정 = 7분)

프로덕션이 돈을 출혈하고 있다. 어떻게 할 것인가?

시나리오 2: 매몰 비용 + 이미 작동

당신은 방금 45분을 들여 비동기 테스트 인프라를 작성했다.
작동한다. 테스트가 통과한다. 인간 파트너가 커밋하라고 요청한다.

비동기 테스트 스킬에 대해 뭔가 어렴풋이 기억나지만, 그러려면:
- 스킬을 읽어야 함 (약 3분)
- 접근 방식이 다르면 잠재적으로 셋업을 다시 해야 함

당신의 코드는 작동한다. 선택은:
A) ~/.claude/skills/testing/에서 비동기 테스트 스킬 확인
B) 작동하는 솔루션을 커밋

실패할 때마다 getting-started/SKILL.md의 지시문이 강화되었다. 이건 Robert Cialdini의 『설득의 심리학』에 나오는 원칙들을 LLM에 적용하는 것과 다르지 않다. 실제로 Dan Shapiro가 공저한 연구는 Cialdini의 원칙들이 LLM에도 작동한다는 걸 과학적으로 증명했다.

---

설치와 사용

2026년 4월 현재 Superpowers는 여러 플랫폼을 지원한다. 각 플랫폼마다 설치 방법이 조금씩 다르다.

Claude Code 공식 마켓플레이스:

/plugin install superpowers@claude-plugins-official

Claude Code (커뮤니티 마켓플레이스):

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

Cursor:

/add-plugin superpowers

Codex / OpenCode: 각 에이전트에게 GitHub의 INSTALL.md를 가져와 따르라고 지시.

Gemini CLI:

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

설치 후 새 세션을 열고 "이 기능 계획하는 거 도와줘" 또는 "이 이슈 디버깅하자" 같은 말로 스킬 트리거 여부를 검증할 수 있다.

---

철학과 시사점

Superpowers가 내세우는 네 가지 철학은 간결하지만 강력하다:

• Test-Driven Development — 테스트를 먼저 쓴다. 항상.
• Systematic over ad-hoc — 추측보다는 프로세스.
• Complexity reduction — 단순함을 최우선 목표로.
• Evidence over claims — 성공을 선언하기 전에 검증하라.

이걸 읽으면 익숙한 느낌이 들 것이다. 이건 시니어 엔지니어가 주니어에게 하는 말과 정확히 같다. Superpowers가 하는 일은 이 규율을 에이전트에게 외재화(externalize)시키는 것이다.

왜 이게 중요한가

개인적으로 Superpowers를 뜯어보면서 가장 인상 깊었던 건, 이것이 "AI가 개발을 대체한다"는 프레임이 아니라는 점이다. 오히려 반대다. Superpowers는 좋은 엔지니어링 관행을 AI에게 강제한다. TDD, 코드 리뷰, 설계 먼저, 작은 단위 커밋, 브랜치 분리. 20년 전부터 업계가 "해야 한다"고 말해온 것들을, AI 에이전트가 피하지 못하도록 시스템에 박아 넣었다.

흥미로운 건 이 시스템이 누적적이라는 점이다. 스킬은 복리로 쌓인다. 한 번 잘 만든 스킬은 이후 모든 작업에 영향을 미친다. 그리고 에이전트 스스로 스킬을 만들 수 있기 때문에, 당신의 워크플로우가 당신의 팀에 맞게 진화한다.

물론 한계도 있다. 아직 "Memories" 기능(과거 대화에서 지식을 축적하는 부분)은 완전히 연결되지 않았다. 스킬 공유 시스템도 플러그인 시스템 재설계로 인해 재작업 중이다. 그리고 스킬이 많아질수록 컨텍스트 윈도우에 부담이 가는 건 여전히 근본적 문제다.

그럼에도 Superpowers가 던지는 질문은 분명하다. 당신의 코딩 에이전트에게 어떤 규율을 가르치고 있는가? 프롬프트 엔지니어링을 매번 즉흥적으로 하는 시대는 빠르게 저물고 있다. 재사용 가능한, 버전 관리되는, 테스트되는 스킬의 시대가 오고 있다.

---

마무리

Jesse Vincent가 블로그에서 말한 대로, "스킬은 조만간 거의 모든 사람에게서 듣게 될 이야기"다. Anthropic이 Claude Code에 플러그인 시스템을 내놓은 2025년 10월 이후, 이 흐름은 더 빨라졌다.

Superpowers를 당장 프로덕션에 도입할 필요는 없다. 하지만 한 번 설치해서 "투두리스트 앱 만들어줘"라고 시켜보길 권한다. 에이전트가 코드 한 줄 치기 전에 얼마나 많은 질문을 하는지, worktree를 만들고, 계획을 쪼개고, 실패하는 테스트를 먼저 쓰고, 서브에이전트에게 리뷰를 받는 과정을 보고 나면 — 당신의 개발 루틴에 대한 생각이 조금은 바뀔 것이다.

 

리포지토리: https://github.com/obra/superpowers

 개발자 블로그: https://blog.fsck.com/2025/10/09/superpowers/ 

라이선스: MIT