AI Coding Workflow · 2026년 5월 27일 기준
Superpowers?
그래서 그게 뭔데?
obra/superpowers는 AI 코딩 에이전트에게 개발 방법론을 입히는 스킬 프레임워크다. 무엇을 해주는지, 어디서 유용한지, 실제 사용자들은 어떻게 평가하는지까지 1번에 정리한다.
2026년 5월 27일 API 기준
2026년 5월 27일 API 기준
2026년 5월 27일 페이지 기준
Section 1
요약
Superpowers는 이름만 보면 초능력 플러그인처럼 들리지만, 실제 정체는 훨씬 현실적이다. AI 코딩 에이전트에게 “일을 시작하기 전에 생각하고, 설계하고, 테스트하고, 검토하고, 증거를 확인하라”는 개발 절차를 스킬 묶음으로 주입하는 오픈소스 프로젝트다. 저장소 이름은 obra/superpowers이고, 설명은 “agentic skills framework & software development methodology”다. 즉 모델 자체를 바꾸는 것이 아니라, Claude Code, Codex, Cursor, OpenCode, Gemini CLI, GitHub Copilot CLI 같은 에이전트 도구가 특정 상황에서 따라야 할 작업 절차를 문서화한 스킬 라이브러리를 제공한다.
가장 짧게 말하면 Superpowers는 “AI에게 시니어 개발자의 작업 습관을 외부 규칙으로 붙이는 장치”다. 기능을 만들 때는 바로 코드를 쓰지 않고 brainstorming으로 요구사항을 좁힌다. 버그를 만나면 systematic-debugging으로 원인을 먼저 추적한다. 구현 단계에서는 test-driven-development로 실패하는 테스트를 먼저 만들게 한다. 큰 작업은 writing-plans, executing-plans, subagent-driven-development로 잘게 나누고, 요청한 작업이 끝났다고 말하기 전에는 verification-before-completion으로 실제 검증을 요구한다.
다만 이것을 “AI가 갑자기 완벽한 개발자가 되는 도구”로 이해하면 안 된다. 공개 후기를 보면 장점은 분명하다. 계획이 더 읽기 쉬워지고, 모델이 성급하게 구현으로 뛰어드는 습관을 줄이며, Brainstorming과 TDD 흐름이 특히 좋다는 반응이 많다. 동시에 단점도 뚜렷하다. 작은 수정에는 과하고, 토큰을 많이 쓰며, 도구별로 스킬 자동 호출이 안정적이지 않다는 이야기도 반복된다. 그래서 결론은 이렇다. Superpowers는 큰 기능, 복잡한 버그, 장기 세션, 품질이 중요한 코드베이스에는 도움이 될 가능성이 크다. 반대로 1줄 수정, 임시 스크립트, 빠른 실험에는 오히려 흐름을 무겁게 만들 수 있다.
Section 2
정확히 무엇인가
Superpowers의 핵심은 “스킬”이다. 여기서 스킬은 모델이 읽는 짧은 안내문이 아니라, 특정 상황에서 반드시 따라야 하는 절차 문서에 가깝다. 예를 들어 brainstorming 스킬은 창의적 작업이나 기능 변경 전에 현재 프로젝트 맥락을 확인하고, 사용자에게 질문하고, 여러 접근안을 제시하고, 설계를 승인받은 뒤 문서로 남기라고 지시한다. test-driven-development 스킬은 구현 코드보다 실패하는 테스트가 먼저 있어야 한다는 규칙을 강하게 요구한다. systematic-debugging 스킬은 해결책을 제안하기 전에 재현, 최근 변경 확인, 데이터 흐름 추적, 가설 검증을 거치라고 한다.
그래서 Superpowers는 라이브러리라기보다 작업 운영체제에 가깝다. 일반적인 프롬프트 팩은 “좋은 코드를 써줘”라고 말한다. Superpowers는 “좋은 코드를 쓰기 전에 어떤 대화와 검증 순서를 밟아야 하는지”를 정한다. 이 차이가 중요하다. AI 코딩 도구를 오래 쓰면 흔히 겪는 문제가 있다. 모델이 초반에는 그럴듯한 계획을 말하지만, 구현 중간에 맥락을 잃거나, 검증하지 않고 성공했다고 선언하거나, 버그의 원인보다 증상만 고치거나, 사용자가 원하지 않은 리팩터링까지 벌이는 문제다. Superpowers는 이런 행동을 절차로 눌러 잡으려는 시도다.
공식 README 기준 기본 흐름은 brainstorming, using-git-worktrees, writing-plans, subagent-driven-development 또는 executing-plans, test-driven-development, requesting-code-review, finishing-a-development-branch로 이어진다. 이 순서는 소프트웨어 팀의 실제 업무 흐름과 닮아 있다. 먼저 요구사항을 정리하고, 격리된 작업 공간을 만들고, 실행 가능한 계획을 쓰고, 작업을 나눠 구현하고, 테스트를 먼저 작성하고, 리뷰를 받고, 마지막에 브랜치를 어떻게 처리할지 정한다.
2026년 5월 27일 확인한 GitHub API 기준으로 obra/superpowers 저장소는 2025년 10월 9일 생성됐고, 207,926 stars와 18,534 forks를 기록했다. 라이선스는 MIT이고, 기본 브랜치는 main이다. 같은 날 Anthropic Claude 플러그인 페이지에서는 Claude Code 설치 대상으로 표시되며 681,792 installs가 노출됐다. 숫자는 계속 바뀔 수 있지만, 최소한 “실험용 작은 레포”라기보다는 이미 꽤 큰 관심을 받은 에이전트 워크플로 프로젝트로 보는 편이 정확하다.
Claude 플러그인 페이지
Section 3
작동 방식
작동 방식은 단순하다. Superpowers는 모델에게 “작업 전 관련 스킬을 확인하라”는 초기 지시와 여러 SKILL.md 문서를 제공한다. 에이전트는 사용자의 요청을 보고 해당되는 스킬을 읽은 뒤 그 절차에 맞춰 움직인다. 사용자가 “로그인 버그 고쳐줘”라고 말하면 systematic-debugging이 먼저 호출되어야 하고, 사용자가 “새 기능을 만들자”라고 하면 brainstorming이 먼저 호출되어야 한다. 이때 중요한 점은 Superpowers가 직접 코드를 실행하는 엔진이 아니라는 것이다. 실행은 여전히 Claude Code, Codex, Cursor, OpenCode 같은 호스트 도구가 한다. Superpowers는 그 도구 안에서 모델이 따라야 할 업무 규칙을 공급한다.
예를 들어 기능 개발 흐름은 이렇다. 먼저 에이전트가 코드베이스를 훑고 요구사항을 질문한다. 그 다음 2개에서 3개의 접근안을 제시하고, 장단점과 추천안을 말한다. 사용자가 방향을 승인하면 설계 문서를 작성한다. 그 설계를 기반으로 구현 계획을 만들고, 작업을 작은 단위로 나눈다. 구현 단계에서는 실패하는 테스트를 먼저 만들고, 그 실패를 확인한 뒤 최소 구현으로 통과시킨다. 이후 리팩터링하고 다시 테스트한다. 마지막에는 자체 리뷰나 별도 리뷰 에이전트로 계획 준수 여부와 코드 품질을 점검한다.
버그 수정 흐름은 더 엄격하다. systematic-debugging 스킬은 “원인 조사 없이 수정하지 말라”는 규칙을 둔다. 에러 메시지를 끝까지 읽고, 재현 방법을 고정하고, 최근 변경을 확인하고, 여러 컴포넌트 사이에서 데이터가 어디서 깨지는지 관찰한 뒤 가설을 세우라고 한다. 그리고 그 가설을 가장 작은 변화로 검증한다. 3번 이상 수정에 실패하면 단순 버그가 아니라 설계 문제일 수 있으니 아키텍처 자체를 의심하라는 지점까지 포함한다. 이 부분은 Superpowers가 단순 프롬프트 모음과 다른 대목이다. “빠르게 고쳐줘”가 아니라 “빠르게 고치기 위해 추측을 줄여라”는 쪽에 가깝다.
Superpowers가 강하게 밀어붙이는 철학은 4가지로 요약된다. 1번째는 테스트 주도 개발이다. 2번째는 임기응변보다 체계적인 절차다. 3번째는 복잡성을 줄이는 것이다. 4번째는 성공 선언 전에 증거를 확인하는 것이다. 이 철학은 AI에게 특히 중요하다. 사람 개발자는 눈치껏 멈추고 되묻지만, AI 에이전트는 그럴듯한 답을 만들어내는 방향으로 흐르기 쉽다. Superpowers는 그 관성을 줄이는 안전장치다.
Section 4
후기
실제 사용자 반응은 꽤 양면적이다. 긍정적인 후기는 “구조가 생긴다”는 말로 모인다. GitHub Issue #1015에서 한 사용자는 Superpowers가 OpenCode를 단순 코딩 보조에서 개발 방법론으로 끌어올린다고 평가했다. 특히 Brainstorming은 코드로 뛰어들기 전에 구조적 탐색을 강제해서 재작업을 줄이고, Systematic Debugging은 수정 전 조사를 습관화하게 하며, 계획 실행 흐름은 실제 출하 가능한 작업으로 이어지게 만든다고 적었다. 이 후기는 단순한 감탄이 아니라 어떤 스킬을 매일 쓰는지까지 구체적으로 언급한다는 점에서 참고할 만하다.
Evan Schwartz의 2026년 4월 2일 글은 더 노골적인 추천이다. 그는 Superpowers가 기본 Claude Code보다 생산성과 정확성을 높였다고 설명한다. 특히 기본 Plan mode는 1번에 긴 계획 문서를 내놓아 리뷰하기 어렵지만, Superpowers는 brainstorming, options and tradeoffs, plan sketch, design doc, implementation plan으로 단계를 나누기 때문에 사용자가 중간에 개입하기 쉽다고 말한다. 또 설계 문서가 저장소 안의 Markdown 파일로 남아 사용자가 자기 에디터에서 읽고 수정할 수 있다는 점을 장점으로 봤다.
Hacker News 댓글에서도 실제 사용 흐름이 나온다. 한 사용자는 brainstorming으로 Socratic method식 계획을 세우고, high-level design plan을 파일로 쓰고, implementation plan을 만든 뒤, worktree와 subagent-driven-development를 함께 사용한다고 적었다. 각 task는 구현, spec review, code review를 거치고, 전체 작업이 끝나면 PR을 만든다는 식이다. 다른 토론에서는 brainstorming skill이 좋고, self-review가 놓친 부분을 잡아낸다는 긍정 평가도 있었다.
반대로 비판도 꽤 선명하다. Reddit의 OpenCode 관련 토론에서는 Claude Code에서는 잘 작동하지만 OpenCode에서는 스킬이 너무 자주 호출되거나 의도와 충돌한다는 경험담이 있었다. 또 작은 스크립트나 단순 수정에는 brainstorming, planning, TDD가 과해져 토큰 비용과 시간이 커진다는 지적도 반복된다. Hacker News에서도 Superpowers가 좋은 아이디어를 담고 있지만 다소 과하게 구조화되어 있어 일부만 남겨 쓰게 됐다는 의견, “silver bullet이 아니다”라는 의견이 보인다.
이 후기들을 종합하면 Superpowers의 위치가 분명해진다. 장점은 “에이전트를 더 신중하고 절차적으로 만든다”는 것이다. 단점은 “그 절차 자체가 비용이 된다”는 것이다. 그래서 누구에게나 항상 켜두면 좋은 만능 도구라고 말하기는 어렵다. 하지만 AI 코딩 에이전트가 자꾸 섣부른 구현, 검증 없는 성공 선언, 무계획 리팩터링, 맥락 이탈을 한다면 Superpowers는 꽤 직접적인 처방이 될 수 있다.
GitHub Issue #1015
Hacker News 댓글
Hacker News 토론
Section 5
사용 예시
가장 현실적인 사용 예시는 새 기능 개발이다. 예를 들어 “Tistory 블로그 에디터에 자동 목차 기능을 추가해줘”라고 바로 구현을 맡기는 대신, Superpowers가 켜진 에이전트에게는 먼저 brainstorming을 쓰게 한다. 에이전트는 현재 에디터 구조를 확인하고, 목차 생성 기준이 h2만인지 h3까지인지, 모바일에서 접히는지, 기존 글에도 적용되는지, JavaScript 없이 동작해야 하는지 질문한다. 그 다음 접근안을 제시한다. 예를 들어 빌드 시점 생성, 저장 시점 생성, 클라이언트 렌더링 생성의 장단점을 비교한다. 사용자가 승인하면 설계 문서를 만들고, 그 뒤 구현 계획으로 넘어간다.
2번째 예시는 버그 수정이다. “검색 결과가 가끔 중복으로 떠”라는 요청이 들어오면 일반 에이전트는 dedupe 코드를 바로 넣을 수 있다. Superpowers 흐름에서는 먼저 재현 조건을 고정한다. 어떤 검색어에서, 어떤 API 응답에서, 프론트 상태 업데이트가 몇 번 발생할 때 중복이 생기는지 확인한다. 네트워크 응답이 중복인지, 서버 쿼리가 중복인지, 클라이언트 병합 로직이 중복인지 단계별로 본다. 원인이 클라이언트 병합 로직이라면 그 상황을 재현하는 실패 테스트를 만들고, 그 테스트가 실패하는 것을 확인한 뒤 최소 수정으로 통과시킨다.
3번째 예시는 큰 리팩터링이다. 예를 들어 오래된 결제 모듈을 Stripe 신규 API로 바꾸는 작업은 단일 프롬프트로 끝내기 위험하다. Superpowers는 작업을 설계 문서와 구현 계획으로 쪼갠다. API 클라이언트, 웹훅 검증, 결제 상태 모델, 마이그레이션, 테스트, 롤백 계획을 분리하고 각 단위에 검증 방법을 붙인다. worktree를 쓰면 기존 작업 공간과 분리된 브랜치에서 진행할 수 있고, subagent-driven-development를 쓰면 각 작은 task를 별도 맥락으로 처리한 뒤 리뷰 단계에서 다시 모은다.
4번째 예시는 코드 리뷰다. 작업이 끝났다고 모델이 말할 때 바로 믿지 않고 requesting-code-review 또는 verification-before-completion을 사용한다. 이때 에이전트는 변경된 파일, 테스트 결과, 계획 대비 누락된 요구사항, 과한 추상화, 불필요한 변경, 실패 가능한 경계 조건을 확인한다. 사람 개발자가 PR을 보기 전에 1차 필터를 걸어주는 셈이다. 공개 후기에서 code-review skill이 유용했다는 짧은 언급이 나온 것도 이 맥락과 맞다.
실제 프롬프트는 어렵지 않다. Codex App이나 Claude Code처럼 스킬 이름을 인식하는 환경에서는 “superpowers:brainstorming을 사용해서 이 기능 요구사항부터 정리해줘”처럼 명시하면 된다. 자동 호출이 불안정한 도구에서는 스킬을 직접 지칭하는 편이 낫다. 예시는 다음과 같다.
# 기능 개발 전
superpowers:brainstorming을 사용해서 이 기능의 요구사항과 접근안을 먼저 정리해줘.
# 버그 수정 전
superpowers:systematic-debugging을 사용해서 원인 조사부터 진행해줘. 수정안은 재현과 가설 검증 뒤에 제안해줘.
# 구현 계획 작성
superpowers:writing-plans를 사용해서 승인된 설계를 작은 작업 단위로 나눠줘. 각 작업에는 파일 경로, 테스트, 검증 명령을 포함해줘.
# 완료 전 검증
superpowers:verification-before-completion을 사용해서 실제로 끝났는지 확인해줘.Section 6
도입 판단
Superpowers를 도입할지 판단하는 기준은 작업 크기와 실패 비용이다. 작업이 크고, 요구사항이 모호하고, 테스트가 중요하고, 여러 파일을 건드리고, 리뷰 없이 merge하면 위험하다면 Superpowers가 맞다. 반대로 README 오타 수정, CSS 1줄 수정, 개인용 throwaway script, 실험성 프로토타입에는 부담이 더 클 수 있다. 공개 사용자들이 반복해서 말하는 토큰 비용 문제도 여기서 나온다. 절차는 품질을 올리지만, 절차 자체가 대화와 출력량을 늘린다.
또 하나의 기준은 사용자의 개발 습관이다. 이미 스스로 요구사항을 잘 쪼개고, 테스트를 먼저 쓰고, 작은 커밋으로 나누고, 리뷰 체크리스트를 갖고 있다면 Superpowers가 제공하는 가치가 상대적으로 작을 수 있다. 반대로 AI에게 1번에 큰 일을 맡기고 자주 “왜 이걸 만들었지?” 같은 결과를 받는다면 가치가 커진다. 초보자에게만 유용하다는 뜻은 아니다. 숙련자도 반복적인 절차를 에이전트에게 강제할 수 있다는 점에서 쓸모가 있다. 다만 숙련자는 전부 켜두기보다 brainstorming, systematic-debugging, code-review처럼 필요한 스킬만 골라 쓰는 방식이 더 잘 맞을 수 있다.
도구별 차이도 고려해야 한다. 공식 README는 Claude Code, Codex CLI, Codex App, Factory Droid, Gemini CLI, OpenCode, Cursor, GitHub Copilot CLI 설치 경로를 안내한다. 하지만 공개 후기에서는 도구마다 자동 호출 품질이 다르게 체감된다는 말이 있다. 특히 스킬이 “필요할 때만” 호출되지 않고 매번 과하게 개입하면 사용자는 답답함을 느낀다. 그래서 처음에는 전면 도입보다 특정 작업에서 명시 호출로 실험하는 편이 좋다.
추천 방식은 3단계다. 1단계로 새 기능 개발 때만 brainstorming을 켜 본다. 2단계로 버그 수정 때 systematic-debugging을 명시 호출한다. 3단계로 큰 구현 계획에서 writing-plans와 executing-plans를 써 본다. 이 3단계에서 코드 품질, 재작업 횟수, 테스트 누락, 토큰 비용을 비교하면 자신에게 맞는지 빨리 판단할 수 있다.
정리하면 Superpowers는 “AI 코딩 도구의 성능을 올리는 마법 버튼”이 아니라 “AI 코딩 도구가 좋은 개발 절차를 어기지 않게 하는 프로세스 레일”이다. 이 레일은 복잡한 작업에서는 유용하다. 하지만 좁은 길에서도 항상 레일을 깔면 느려진다. 핵심은 Superpowers를 숭배하거나 버리는 것이 아니라, 실패 비용이 큰 작업에서 절차를 강제하는 도구로 정확히 쓰는 것이다.
그래서 처음 써볼 때의 목표도 거창할 필요가 없다. 1일 정도 실제 업무에 붙여 보고, Superpowers를 쓴 작업과 쓰지 않은 작업의 재작업 횟수, 테스트 누락, 리뷰 지적, 대화 길이를 비교하면 된다. 그 결과가 좋아야 계속 쓸 이유가 생긴다.
FAQ
Q1. Superpowers는 코딩 에이전트인가요?+
아닙니다. Superpowers 자체가 모델이나 에이전트 런타임은 아닙니다. Claude Code, Codex, Cursor, OpenCode 같은 호스트 도구 안에서 에이전트가 읽고 따르는 스킬과 절차 묶음입니다.
Q2. 설치하면 AI가 자동으로 더 똑똑해지나요?+
모델의 지능이 바뀌는 것은 아닙니다. 다만 모델이 설계, 테스트, 디버깅, 리뷰 절차를 건너뛰지 않게 만들기 때문에 결과가 더 안정적으로 느껴질 수 있습니다.
Q3. 어떤 작업에 가장 잘 맞나요?+
요구사항이 모호한 새 기능, 여러 파일을 건드리는 변경, 재현이 어려운 버그, 테스트와 리뷰가 중요한 코드베이스에 잘 맞습니다.
Q4. 작은 작업에도 쓰는 게 좋나요?+
항상 그렇지는 않습니다. 공개 후기에서도 작은 스크립트나 단순 수정에는 토큰 사용량과 절차가 과하다는 지적이 있습니다.
Q5. Codex App에서도 쓸 수 있나요?+
README는 Codex CLI와 Codex App 설치 경로를 안내합니다. Codex App에서는 플러그인 사이드바의 Coding 섹션에서 Superpowers를 설치하는 방식으로 설명되어 있습니다.
'AI' 카테고리의 다른 글
| Nanoclaw 실사용후기: 개인 AI 에이전트로 써볼 만할까? (0) | 2026.05.28 |
|---|---|
| MCP 정확히 이해하기: AI 스킬과 도구 연결 표준의 차이 (0) | 2026.05.28 |
| DESIGN.md란 무엇이고 어떻게 사용하는가 (0) | 2026.05.27 |
| Gemini로 TOEIC 공부하자: YBM 퀴즈와 AI 피드백 루틴 (0) | 2026.05.27 |
| AI Skill 마켓플레이스 SkillsMP 사용법: 검색부터 개발까지 (0) | 2026.05.21 |
