한 줄 요약
Superpowers는 코딩 에이전트가 요구를 이해하고 설계를 합의한 뒤, 작은 구현과 테스트·리뷰로 이어가도록 돕는 개발 절차와 스킬 프레임워크입니다.
저장소: obra/superpowers
에이전트가 코드를 빠르게 만들었는데 정작 원했던 동작과 다르면, 수정하는 시간보다 요구를 다시 설명하는 시간이 더 길어집니다. Superpowers는 이 지점에서 살펴볼 만합니다. 무엇을 만들지 묻는 단계부터 구현 계획, 작업공간 준비, 테스트, 검토까지 하나의 흐름으로 연결합니다.
앞서 소개한 mattpocock/skills가 질문·용어·명세처럼 필요한 절차를 골라 적용하는 출발점이었다면, Superpowers에서는 그 절차들이 이어지는 순서에 주목해 보세요. 요구를 정리하는 특정 스킬이 필요한 팀은 기존 글부터, 설계 이후 구현과 리뷰 사이에서 자꾸 맥락이 끊기는 팀은 Superpowers부터 살펴보시면 좋겠습니다.
저희가 권하는 첫 작업은 작지만 판단할 조건이 있는 기능입니다. 예를 들어 목록 필터를 추가하면서 빈 결과와 기존 정렬을 함께 다루는 작업입니다. 설계에서 합의한 조건이 계획과 테스트에 어떻게 남는지 따라가면, 스킬 이름을 외우는 것보다 팀에 맞는지 판단하기 쉽습니다.
무엇을 할 수 있나
공식 README의 기본 흐름은 brainstorming, using-git-worktrees, writing-plans, 구현, 코드 리뷰, 브랜치 마무리로 이어집니다. 설계 승인을 받은 뒤 작업을 나누고, 구현 중에는 test-driven-development로 실패하는 테스트와 필요한 코드를 차례로 다룹니다. verification-before-completion은 완료를 말하기 전에 실제 검증 결과를 확인하는 역할입니다.
이 흐름의 장점은 검토할 대상을 단계마다 남긴다는 데 있습니다. 설계에서는 사용자 동작과 선택 이유를, 계획에서는 파일과 작업 순서를, 구현에서는 변경과 테스트를 읽을 수 있습니다. 담당자가 바뀌어도 “왜 이 조건을 넣었는지”를 대화 전체에서 다시 찾는 부담을 줄이는 방향입니다.
구현 방식도 구분합니다. README는 작업마다 새 에이전트와 검토를 사용하는 subagent-driven-development, 같은 세션에서 계획을 수행하고 마지막에 새 검토를 받는 executing-plans를 소개합니다. 둘은 검토 시점과 실행 비용이 다르므로 팀의 작업 크기와 예산에 맞춰 선택할 부분입니다. 여러 에이전트를 쓰는 것만으로 독립적인 검증이 완성되는 것은 아니며, 최종 변경을 읽을 담당자는 여전히 필요합니다.
전체 개발 흐름 외에 systematic-debugging처럼 문제 하나에 집중하는 스킬도 있습니다. 기능 개발이 급하지 않다면 반복되는 오류를 재현하고 원인을 좁히는 작업부터 시작해도 좋습니다. 공식 스킬 목록에서 현재 팀의 병목과 맞는 항목을 먼저 골라 보세요.
설치와 첫 대화
Claude Code를 사용한다면 대화창에서 공식 마켓플레이스의 플러그인을 설치할 수 있습니다. 다음은 README의 설치 안내에 있는 명령입니다.
/plugin install superpowers@claude-plugins-official
기존 Claude Code 실행 환경과 모델 연결을 준비한 뒤 진행합니다. 다른 코딩 도구를 쓴다면 README의 해당 도구 절을 따르세요. 여러 도구를 함께 쓰는 경우에는 도구별로 따로 설치하도록 안내하고 있습니다. 팀에서는 플러그인 이름뿐 아니라 설치 경로와 적용 버전도 남겨 두면 같은 동작을 비교하기 좋습니다.
설치 후에는 새 대화에서 만들고 싶은 작은 기능을 설명해 보세요. README도 React 할 일 목록 같은 요청으로 brainstorming이 시작되는지 살펴보는 예를 듭니다. 아래는 목록 필터 작업에 맞춘 대화 예시입니다.
고객 목록에 상태 필터를 추가하고 싶습니다.
현재 코드에서 목록과 상태가 어떻게 연결되는지 먼저 살펴보고,
사용자에게 필요한 동작과 아직 결정하지 않은 조건을 질문해 주세요.
설계를 합의한 뒤 구현 계획으로 넘어가겠습니다.
질문이 나왔다는 사실보다 질문의 내용이 중요합니다. 저장소에서 알 수 있는 내용을 다시 묻고 있지는 않은지, 실제 제품 판단이 필요한 조건을 드러내는지 살펴보세요. 명확한 작은 요청과 설계가 필요한 변경은 다르게 다루는 것이 brainstorming 가이드의 방향입니다. 모든 수정에 같은 길이의 설계 문서를 만드는 방식으로 받아들이지 않아도 됩니다.
활용 시나리오 1: 기능 요청을 검토 가능한 계획으로 만들기
“고객 목록에 상태 필터를 넣어 주세요”에는 여러 선택이 숨어 있습니다. 선택한 상태를 주소에 남길지, 상태를 바꾸면 페이지를 처음으로 돌릴지, 검색과 필터를 함께 적용할지 같은 조건입니다. 이때 brainstorming으로 사용자 동작을 좁히고, 합의한 설계를 writing-plans로 넘겨 보세요.
필터와 검색은 함께 적용하고 기존 정렬은 유지합니다.
필터 변경 시 첫 페이지로 이동하며, 결과가 없으면 빈 상태를 보여줍니다.
이 조건이 설계에 빠짐없이 들어갔는지 확인해 주세요.
승인한 설계를 기준으로 파일별 변경과 검증 순서를 계획해 주세요.
계획 스킬은 파일 위치, 인터페이스, 검증 단계를 구체적으로 적도록 안내합니다. 작업은 따로 검토할 가치가 있고 독립적으로 검증할 수 있는 결과를 중심으로 나눕니다. 화면 파일 수정과 그 동작을 증명하는 테스트를 서로 무관한 작업으로 흩어 놓지 않는지 읽어 보세요.
계획을 받으면 조건을 하나씩 따라가 봅니다. “검색과 함께 적용”이 구현 작업에만 있고 검증에서는 빠졌을 수 있습니다. 반대로 작은 필터 추가에 데이터 구조 변경까지 들어갔다면 범위가 커진 이유를 물어볼 차례입니다. 계획을 검토하는 시간은 에이전트가 무엇을 만들려는지 가장 적은 변경으로 바로잡을 수 있는 기회입니다.
작업공간을 준비할 때는 README에 소개된 Git worktree 흐름도 함께 살펴봅니다. 별도 브랜치에서 변경을 다루는 데 도움이 되지만, 같은 컴퓨터의 권한이나 외부 서비스 접근까지 분리해 주지는 않습니다. 저장소의 기존 브랜치 규칙과 시작 시점의 테스트 상태를 함께 확인해 두세요.
활용 시나리오 2: 반복되는 버그를 재현부터 좁히기
어떤 입력에서만 필터가 풀리는 오류라면 여러 파일을 한꺼번에 바꾸기 쉽습니다. systematic-debugging은 원인 조사, 정상 동작과의 비교, 가설 검증, 구현의 순서로 접근합니다. 먼저 증상을 일정하게 재현하고 최근 변경과 데이터 흐름을 살펴보는 방식입니다.
검색어를 입력한 뒤 상태 필터를 바꾸면 검색 조건이 사라집니다.
재현 순서와 기대 동작을 먼저 정리해 주세요.
입력 상태가 주소와 조회 조건으로 전달되는 경로를 따라가고,
근거가 있는 가설 하나씩 검증한 뒤 수정안을 제안해 주세요.
디버깅 가이드는 여러 구성 요소를 지나는 문제에서 경계마다 증거를 모으도록 설명합니다. 이 시나리오에서는 입력 상태, 주소 변경, 조회 조건을 구분해 보는 식으로 적용할 수 있습니다. 로그를 추가한다면 고객 데이터 대신 재현용 입력을 쓰고, 필요한 상태만 남기세요.
가설을 검증할 때는 한 번에 바꾸는 조건을 줄여 보세요. 검색어를 보존하는 수정과 필터 UI 정리를 함께 진행하면 무엇이 원인을 해결했는지 흐려집니다. 오류가 사라졌다는 결과와 그 이유를 분리해서 설명받고, 원래 재현 순서를 다시 통과하는지 확인합니다.
원인을 찾은 뒤에는 TDD 가이드를 따라 실패하는 테스트를 먼저 확인하고 최소 수정으로 이어갑니다. 테스트가 실제 사용자 동작을 다루는지 읽어 보세요. 내부 함수 이름만 확인하는 테스트보다 검색과 필터를 함께 썼을 때 유지해야 할 조건을 보여주는 테스트가 이 작업의 검토에 도움이 됩니다.
활용 시나리오 3: 완료 보고를 변경과 검증 근거로 읽기
계획대로 구현했다는 답을 받으면 테스트와 변경 범위를 함께 검토합니다. Superpowers의 코드 리뷰 흐름은 명세 준수와 코드 품질을 살펴보도록 구성돼 있습니다. 리뷰어가 요구 조건을 다시 읽을 수 있게 설계와 계획을 결과 옆에 두면 좋습니다.
승인한 설계의 각 조건을 변경 파일과 검증 결과에 연결해 주세요.
실행한 명령, 성공·실패 결과, 추가로 확인할 부분을 구분해 주세요.
계획에 없는 수정과 기존 동작에 영향을 줄 수 있는 경로도 찾아 주세요.
완료 전 검증 스킬은 검증 명령의 전체 결과와 종료 코드를 읽고 주장할 내용을 정하도록 안내합니다. 린트 성공이 기능 테스트 성공을 뜻하지 않고, 테스트 성공이 모든 요구 충족을 뜻하지도 않습니다. 팀이 원래 쓰던 검증 명령을 기준으로 어떤 근거가 어느 조건을 뒷받침하는지 살펴보세요.
브랜치 마무리 단계에는 병합과 PR 같은 선택지가 등장합니다. 조직의 승인 절차와 담당자를 여기에 연결해 두면 좋습니다. 에이전트가 다음 단계를 제안하더라도 실제 병합 기준은 저장소 정책으로 지켜야 합니다. 첫 파일럿에서는 작은 작업 하나의 설계, diff, 검증 결과를 사람이 함께 읽는 데 시간을 써 보세요.
어떤 팀에 맞나
장점: 에이전트가 구현을 시작하기 전에 판단할 조건을 드러내고, 그 조건을 계획과 테스트에 이어 붙일 수 있습니다. 여러 담당자가 기능을 넘겨받거나, 요청은 짧은데 예외 조건이 많은 기존 서비스를 유지보수하는 팀에서 살펴볼 만합니다. 설계 검토와 코드 검토 사이에 남는 문서도 도입 판단의 대상입니다.
운영 부담: 질문과 계획, 작업별 검토에는 시간이 들고 에이전트 호출 비용도 생깁니다. 아주 명확한 문구 수정까지 복잡한 절차로 다루면 검토가 밀릴 수 있습니다. 첫 작업에서는 질문이 도움이 됐던 지점과 반복 설명이 많았던 지점을 기록해 팀 절차와 비교해 보세요. 플러그인 업데이트로 지침이 바뀌는 경우도 살펴볼 담당자가 필요합니다.
실행 환경: 스킬은 에이전트의 작업 방식을 안내합니다. 파일 권한과 명령 실행, 모델에 보내는 코드 범위는 사용하는 코딩 도구와 주변 환경에서 정해야 합니다. README는 선택적인 시각 보조 기능의 로고 요청에 버전 정보가 포함된다고 안내하므로, 네트워크 정책을 검토하는 팀은 해당 절도 함께 읽어 보세요.
라이선스: 저장소는 MIT입니다. 수정·재배포 시 LICENSE의 조건을 확인하고, 연결하는 코딩 도구와 모델 서비스의 이용 조건도 함께 검토합니다. 팀의 기존 방식에 필요한 단계가 무엇인지 판단한 뒤 작은 작업부터 도입해 보시길 권합니다.
원문과 함께 읽기
- Superpowers 저장소와 설치 안내
- README
- 제작자의 최초 공개 소개
- LICENSE
- 함께 읽기: mattpocock/skills의 요구 정리, Hermes Agent의 기억과 반복 업무
마치며
하이프마크 빌더 커뮤니티는 앞으로도 이렇게 직접 살펴본 AI 도구와 오픈소스를 꾸준히 공유하려고 합니다. 빌더 여러분께 도움이 될 좋은 자료들을 계속 모아 나누겠습니다.