나는 예전에 쓰던 superpowers 스킬셋을 mattpocock/skills로 갈아탔다. 둘 다 에이전트 작업 흐름을 정리해 주는 도구지만, 직접 써 보니 체감 차이가 꽤 컸다. superpowers는 hooks가 걸려 있어서 내가 따로 지시하지 않아도 brainstorming에서 write-spec, write-plans, execute-plan까지 자동으로 밀고 간다. software engineering 과정에 익숙하지 않은 사람에게는 꽤 친절하지만, 익숙한 입장에서는 단순한 일까지 너무 무겁게 만든다. 반대로 mattpocock/skills는 내가 언제 어떤 skill을 호출할지 직접 고를 수 있어서 더 가볍고 실용적이었다.
핵심 비교
| 비교 항목 | Superpowers | Matt Pocock Skills |
|---|---|---|
| 호출 방식 | Hooks로 자동 강제 실행 | 내가 필요한 때만 호출 |
| 토큰 소모 | 큼 (brainstorming, visual companion) | 경제적 |
| 적합 대상 | SW 공정에 익숙하지 않은 사람 | ”Real Engineers” |
| 주요 workflow | brainstorm → write-spec → write-plans → execute-plan | grill-with-docs → to-prd → to-issues → implement |
내가 느낀 문제
superpowers는 workflow를 강하게 통제한다. 처음에는 든든했지만, 시간이 지나면 간단한 문제도 괜히 복잡하게 만든다. 특히 brainstorming 단계와 visual companion은 생각보다 token을 많이 쓴다. 그래서 나는 이 방식이 강제적이고 token도 많이 먹는다는 쪽으로 정리하게 됐다.
내가 옮긴 방식
나는 먼저 superpowers의 hooks를 다 지웠다. 그래야 정말 필요할 때만 내가 직접 부를 수 있기 때문이다. 그다음에는 mattpocock/skills의 /grill-with-docs를 superpowers의 brainstorming과 섞어 써 봤는데, 질문-답변 방식이 더 가볍고 결과도 충분했다. visual companion은 데모나 인터랙션을 맞출 때는 도움이 됐지만, token 소모가 너무 커서 Fable 5가 돌아온 뒤에는 거의 쓰지 않게 됐다. 복잡한 시각 효과가 필요하면 /prototype로 먼저 간단한 원형을 만들고, 안 맞으면 버리는 편이 훨씬 낫다.
Matt Pocock의 이 스킬셋은 v1.0.0에서 이름을 일부 다듬고 ask-matt도 추가했다. 그래서 처음 설치한 뒤에는 어떤 상황에서 어떤 skill을 써야 하는지도 더 분명해졌다. 내가 쓰는 기본 흐름은 superpowers의 brainstorming → write-spec → write-plans → execute-plan과 비슷하지만, 실제 손이 가는 순서는 grill-with-docs → to-prd → to-issues → implement 쪽에 더 가깝다.
주요 Skills
| Skill | 용도 |
|---|---|
/grill-with-docs | 요구사항 분석. Agent가 진짜로 원하는 바를 이해하게 하는 Q&A |
/to-prd | PRD(Product Requirements Document) 작성 |
/to-issues | GitHub Issues 생성 |
/implement | 구현 실행 |
/tdd + /diagnosing-bugs | TDD 개발 + 디버깅 |
/improve-codebase-architecture | 코드베이스 리팩토링. HTML 시각화 차트 제공 |
/handoff | Claude ↔ Codex 등 모델/컨텍스트 전환 |
/prototype | 빠른 프로토타이핑. 필요 없으면 throwaway 가능 |
/ask-matt | v1.0.0에서 추가. 사용 시나리오 안내 |
Workflow 비교
단계별 흐름
graph TB subgraph sp[Superpowers<span> hooks 기반 자동</span>] direction LR s1[🧠<br/>/brainstorming] --> s2[📝<br/>/write-spec] s2 --> s3[📋<br/>/write-plans] s3 --> s4[⚙️<br/>/execute-plan] end sp -.->|"토큰 多 · SW 초보자 친화"| mp subgraph mp[Matt Pocock Skills<span> 필요할 때만 호출</span>] direction LR m1[🔍<br/>/grill-with-docs] --> m2[📄<br/>/to-prd] m2 --> m3[🎫<br/>/to-issues] m3 --> m4[🔧<br/>/implement] end style sp fill:#fff3e0,stroke:#e65100,stroke-width:2px style mp fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
특성별 대비
graph TB subgraph approach[접근 방식] a1["Superpowers<br/>Brainstorm → Spec → Plans → Execute"] a2["Matt Pocock Skills<br/>Grill → PRD → Issues → Implement"] end subgraph traits[핵심 차이] t1["🎛️ 호출: Hooks 자동 실행<br/>vs<br/>내가 필요할 때만 호출"] t2["💰 토큰: 큼 (brainstorming 등)<br/>vs<br/>경제적"] end a1 --> t1 a1 --> t2 a2 --> t1 a2 --> t2 style approach fill:#f3e5f5,stroke:#7b1fa2 style traits fill:#e3f2fd,stroke:#1565c0
왜 이 스킬들이 필요한가
Matt가 이 스킬들을 만든 이유도 결국 비슷했다. The Agent Didn't Do What I Want는 agent가 내가 원하는 걸 제대로 이해하지 못했다는 뜻이라서 /grill-with-docs로 질문을 주고받으며 요구사항을 맞춰야 한다. The Agent Is Way Too Verbose는 우리가 agent와 같은 언어를 쓰지 못하고 있다는 신호라서, agent가 스스로 용어와 맥락을 정리하게 만드는 쪽이 낫다. The Code Doesn't Work는 /tdd와 /diagnosing-bugs가 붙는 지점이고, We Built A Ball Of Mud는 /improve-codebase-architecture처럼 리팩토링을 도와주는 skill이 필요하다는 뜻이다.
또 /handoff는 Claude와 Codex를 오갈 때 특히 유용했다. 이런 도구가 있으면 내가 어디까지 진행했는지, 무엇을 남겼는지를 잊지 않게 된다. 개인 프로젝트를 GitHub issues 중심으로 굴리는 사람이라면 더 체감이 크다.
결론 및 인사이트
나는 결국 mattpocock/skills 쪽으로 완전히 옮겼다. token과 시간을 아끼면서도 기록은 GitHub issues에 남고, 내가 어디까지 진행했는지도 잊지 않게 된다. 요즘 AI 업계가 harness와 loop engineering 같은 말을 계속 만들어 내는 것도 같은 맥락으로 보인다. 모델이 약할 때는 어떻게 원하는 방향으로 몰아갈지가 중요하고, 모델이 강해질수록 긴 작업을 얼마나 안정적으로 넘기느냐가 더 중요해진다.
다만 사람의 taste는 여전히 중요하다. 제품을 다듬는 마지막 구간은 아직도 시간이 걸리지만, Fable 5를 보면서 그 구간도 더 빨라질 수 있겠다는 기대가 생겼다. 내 결론은 단순하다. 강하게 강제하는 도구가 항상 정답은 아니고, 내가 필요할 때 필요한 skill만 꺼내 쓰는 편이 훨씬 오래 간다.