Superpowers 설치 방법: Claude Code·Codex CLI·Hermes Agent
Superpowers는 사용하는 코딩 에이전트마다 따로 설치한다. 이미 다른 하네스에 설치했더라도 현재 쓰는 도구에는 별도 설치가 필요하다. 아래에서 실제 사용하는 하네스 하나만 고른다.
Hermes Agent 설치 방법
hermes plugins install obra/superpowers --enable설치 뒤에는 현재 세션을 새로 시작한다. 그래야 작업 시작 시 관련 스킬이 자동으로 적용된다.
Claude Code 설치법
/plugin install superpowers@claude-plugins-official공식 플러그인 마켓플레이스에서 설치하는 경로다. 대안 마켓플레이스를 쓸 때는 /plugin marketplace add obra/superpowers-marketplace 뒤 /plugin install superpowers@superpowers-marketplace를 사용한다.
Codex CLI 설치 방법
/plugins플러그인 검색 화면에서 superpowers를 찾고 Install Plugin을 선택한다. 설치 후 새 세션에서 작은 변경 하나를 TDD 흐름으로 실행해, 스킬이 실제로 적용되는지 확인한다.
코딩 에이전트에게 “이 기능 만들어 줘”라고 말하면, 답변과 코드가 한 번에 쏟아진다. 작은 수정에는 편하지만, 요구가 바뀌거나 여러 파일이 얽히면 바로 앞 단계가 비어 있던 대가가 드러난다. 무엇을 성공으로 볼지, 어디까지 바꿀지, 실패를 어떻게 잡을지를 합의하지 않은 채 파일만 바꾸면 결과를 검토할 기준도 사라진다.
Superpowers는 Claude Code, Codex, Cursor, Hermes Agent 같은 코딩 에이전트에 붙이는 오픈소스 스킬 묶음이다. 모델을 바꾸거나 새 IDE를 설치하는 도구가 아니라, 에이전트가 작업을 시작하고 끝내는 순서를 정한다. 저장소는 대화에서 목적과 제약을 먼저 정리하고, 작업 규모에 따라 탐색·설계·계획을 나눈 뒤, 구현과 검증을 연결하는 방식을 제시한다.
문제는 코드 생성보다 ‘검토 가능한 다음 단계’다
예를 들어 결제 화면에 할인 규칙을 추가한다고 하자. 에이전트가 곧바로 코드를 쓰면 “할인”이 쿠폰인지, 회원 등급인지, 중복 적용되는지부터 모호하다. Superpowers의 brainstorming 스킬은 이때 작업을 짧은 조사(spike), 기존 흐름의 제한된 변경(bounded), 여러 구성요소를 바꾸는 설계 작업(architectural)으로 나누고, 규모에 맞는 질문과 승인 단계를 먼저 둔다. 질문을 길게 늘어놓으려는 장치가 아니라, 다음 행동을 고르기 위한 분류다.
이 구분은 “에이전트를 오래 돌릴수록 좋다”는 뜻이 아니다. 한 파일의 버그 수정에 새 설계 문서를 만들 필요는 없고, 반대로 새 서비스처럼 인터페이스와 데이터 흐름이 함께 바뀌는 일을 짧은 채팅 승인으로 넘기면 나중의 수정 비용이 커진다. 저장소의 규칙도 이 경계를 명확히 한다. bounded 작업은 기존 코드 흐름을 읽고 짧은 설계를 승인받은 뒤 구현하고, architectural 작업은 명세와 구현 계획을 거친다. 사람이 남기는 산출물은 코드가 아니라 “무엇을 바꾸며, 무엇으로 끝났다고 판단할지”라는 판단이다.
구현은 테스트의 실패를 먼저 보게 한다
Superpowers에는 테스트 주도 개발(TDD)을 강제하는 스킬도 있다. 핵심 순서는 간단하다. 기대 동작을 보여 주는 최소 테스트를 쓰고 실제로 실패하는지 확인한 뒤, 통과시키는 가장 작은 구현을 만들고, 마지막에 구조를 정리한다. 테스트가 처음부터 통과했다면 새 기능을 검증하는 것이 아니라 이미 있던 동작을 다시 확인한 것일 수 있다.
이 흐름은 에이전트가 만든 코드의 양을 줄이는 데도 쓸모가 있다. 먼저 실패 조건을 한 문장으로 고정하면 옵션, 설정, 추상 계층을 미리 쌓아 두기보다 필요한 동작만 통과시키는 쪽으로 좁혀진다. 다만 테스트가 제품의 모든 판단을 대신하지는 않는다. 문구의 적절성, 화면의 우선순위, 실제 고객이 이해하는 방식은 여전히 사람이 확인해야 한다. 테스트는 합의한 동작이 깨지지 않았는지 보는 장치다.
에이전트에게 맡길 일과 사람이 남길 일을 분리한다
저장소는 큰 구현을 여러 하위 작업으로 나누고, 하위 에이전트가 작업한 뒤 검토를 이어 가는 방식을 포함한다. 여기서 중요한 것은 병렬 실행 자체가 아니다. 사람은 목적, 범위, 승인, 최종 판단을 맡고, 에이전트는 저장소 탐색, 계획에 따른 변경, 테스트 실행, 결과 보고처럼 반복 가능한 실행을 맡는다. 계획이 불완전하면 에이전트 수를 늘려도 같은 모호함을 더 빨리 복제할 뿐이다.
처음 적용할 때는 모든 스킬을 외울 필요가 없다. 반복해서 “바로 수정해 달라”고 요청한 뒤 결과를 되돌리는 팀이라면, 먼저 요구를 짧게 적고 성공 조건을 확인하는 단계부터 써 볼 만하다. 변경이 여러 파일을 넘나들 때는 계획을 파일 목록과 검증 명령으로 남기고, 마지막에는 사람이 diff와 실제 동작을 읽는다. 반대로 단발성 질문에 답만 필요하거나 저장소를 바꿀 일이 없다면 이런 작업 흐름은 필요 없다.
Superpowers는 특정 에이전트의 추론 품질을 보장하지 않는다. 지원하는 각 하네스에 따로 설치해야 하며, 스킬이 제안하는 절차를 얼마나 지킬지는 해당 세션과 사용자의 승인 방식에 달려 있다. 그럼에도 결과물보다 작업 과정을 먼저 고정하려는 팀에는, 에이전트를 더 빠른 자동완성으로 쓰는 것과 검토 가능한 개발 동료로 쓰는 것 사이의 경계를 만드는 출발점이 된다.