에이전트 스킬셋 비교 Part 5: 프로세스를 누가 쥘 것인가

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1부터 Part 4까지 두 스킬셋을 단계별로 대조했습니다. 이번 편은 그 차이들이 어디서 나오는지, 그리고 실무에서 무엇을 고를지를 정리합니다.

1. 저자들이 서로를 반박합니다#

두 README 를 나란히 놓으면 같은 논점에서 정반대 결론이 나옵니다.

Matt Pocock 쪽:

Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve. These skills are designed to be small, easy to adapt, and composable.

superpowers 쪽:

Mandatory workflows, not suggestions.

superpowers 를 이름으로 지목하지는 않았지만, “프로세스를 소유하는 접근” 이라는 서술은 superpowers 에 그대로 들어맞습니다. 그리고 superpowers 는 그 소유를 결함이 아니라 기능 으로 내세웁니다.

마지막 줄이 중요합니다. Matt Pocock 쪽은 설치 방법을 두 가지로 나눠 두고 그 차이를 “두 가지 철학(Two ways in, two philosophies)” 이라고 부릅니다. 플러그인은 읽기 전용 구독이고, skills.sh 는 프로젝트에 파일을 복사해 마음대로 고치는 방식입니다.

Hack around with them. Make them your own.

반대로 이 블로그의 4부작 Part 4는 superpowers 쪽의 태도를 이렇게 정리했습니다.

저장소의 기여 가이드라인에서 강조하듯, Superpowers 의 스킬 내용은 평가/튜닝의 결과물 입니다. “내가 좀 더 좋게 만들 수 있어 보여” 라며 임의로 변형하면 효과가 떨어질 수 있습니다.

“고쳐 써라” 와 “함부로 고치지 마라” 입니다. 같은 종류의 파일을 두고 정반대 조언이 나옵니다.

둘 다 일리가 있습니다. 스킬 내용이 평가를 거쳐 튜닝된 것이라면 임의 변형은 손해입니다. 반대로 스킬이 작고 읽을 수 있다면 자기 상황에 맞추는 편이 낫습니다. 결국 “이 텍스트가 얼마나 검증된 것인가” 에 대한 서로 다른 믿음입니다.

2. 두 세계관#

시리즈 내내 나온 차이들을 한 축에 놓으면 그림이 하나로 모입니다.

flowchart LR
    H0[" "]:::hdr
    H1["superpowers"]:::hdr
    H2["mattpocock/skills"]:::hdr
    R1["전제"]:::hdr
    A["에이전트를 오래<br/>자율 실행시킨다"]
    B["사람이 각 단계를<br/>연다"]
    R2["그래서 필요한 것"]:::hdr
    C["격리 · 완료검증<br/>병렬 · 강제 주입"]
    D["라우터 · 프로토타입<br/>지도 · 인계"]
    R3["실패 대비"]:::hdr
    E["에이전트가 절차를<br/>건너뛰는 것"]
    F["사람이 수동적으로<br/>끄덕이는 것"]
    H0 ~~~ H1 ~~~ H2
    R1 ~~~ A ~~~ B
    R2 ~~~ C ~~~ D
    R3 ~~~ E ~~~ F
    classDef hdr fill:none,stroke:none,color:#dddddd
    style A fill:#87CEEB,color:#000000
    style B fill:#FFD700,color:#000000
    style C fill:#87CEEB,color:#000000
    style D fill:#FFD700,color:#000000
    style E fill:#FF9999,color:#000000
    style F fill:#FF9999,color:#000000

마지막 줄이 특히 대칭입니다.

superpowers 는 using-superpowers 에서 에이전트가 스킬을 회피하려는 생각 을 목록으로 만들어 반박합니다. “이건 간단한 질문일 뿐이야”, “이 스킬은 과하다”.

grill-me 문서는 사용자가 수동적으로 동의하는 것 을 실패 모드로 지목합니다. “동의, 동의, 동의” 로 마흔 개를 넘긴 세션.

한쪽은 에이전트를 의심하고, 다른 쪽은 사용자를 의심합니다. 각자가 자기 설계에서 가장 약한 고리를 정확히 알고 있다는 뜻이기도 합니다.

3. 의식 비용 — 외부와 내부가 같은 곳을 짚었습니다#

Alex Rusin 은 2026-08-07 글에서 이 계열 워크플로의 대가를 이렇게 정리합니다. 직접 써 본 후기가 아니라 개념 분석이라고 본인이 밝힌 글 이므로 그 점을 감안해 읽어야 합니다.

For a solo dev changing a form validation rule, running the full spine costs more than the change. The honest framing is that this is a gradient, not a default.

폼 검증 규칙 하나 고치는 데 전체 절차를 돌리면 변경보다 절차가 비쌉니다. 그리고 “기본값이 아니라 기울기” 라는 표현이 정확합니다. 작업 크기에 따라 절차의 양이 달라져야 한다는 것입니다.

그런데 같은 지적을 이 블로그의 4부작 Part 4가 3개월 먼저 했습니다.

“이 줄 띄어쓰기 하나만 고쳐줘” 같은 작업에도 brainstorming 이 발동되면 답답합니다. … 자동 트리거의 본질적 트레이드오프입니다.

두 글이 독립적으로 같은 지점을 짚었습니다. 그리고 그 지점이 정확히 mattpocock 이 설계로 답한 곳입니다.

대신 반대 비용을 냅니다. 필요할 때 사용자가 기억해서 쳐야 합니다. ask-matt 이 존재하는 이유가 그것이고, 그 첫 줄이 “You don’t remember every skill, so ask” 인 것도 그래서입니다.

자동 발동은 과한 절차를 부르고, 수동 발동은 안 쓰이는 스킬을 만듭니다. 어느 쪽도 공짜가 아닙니다.

4. 언제 무엇을 쓰나#

superpowers 가 맞는 경우#

• 혼자 또는 소수로 처음부터 끝까지 돌리는 프로젝트. 아이디어부터 병합까지 한 줄로 이어지는 게 이득입니다.
• 에이전트를 오래 자율 실행시키고 싶은 경우. 워크트리 격리·완료 검증·병렬 실행이 그 시나리오를 위한 장치입니다.
• 에이전트가 절차를 건너뛰는 게 반복적으로 문제인 경우. 훅 주입이 그걸 위한 설계입니다.
• TDD 를 강하게 강제하고 싶은 경우. 테스트 없이 쓴 코드를 삭제하라는 규정까지 있습니다.
• 여러 하네스를 쓰는 경우. Claude Code 외 실행 환경 지원이 넓습니다.

mattpocock/skills 가 맞는 경우#

• 작업 크기가 들쭉날쭉한 경우. 사소한 변경에 절차가 끼어들지 않습니다.
• UI·인터랙션·상태 모델처럼 봐야 아는 것을 만드는 경우. prototype 이 흐름에 정식으로 들어 있습니다.
• 한 세션에 안 담기는 큰 작업. wayfinder 가 그 자리를 위한 것입니다.
• 이슈 트래커를 실제로 쓰는 팀. to-spec·to-tickets·triage 가 트래커 연동을 전제합니다.
• 스킬을 직접 고쳐 쓰고 싶은 경우. 평균 64줄이라 읽고 고치는 비용이 낮습니다.
• 코드가 아닌 것에도 쓰고 싶은 경우. grill-me 는 저장소도 소프트웨어도 요구하지 않습니다.

같이 쓸 수 있나#

됩니다. 그리고 충돌 지점이 적습니다.

mattpocock 의 워크플로 뼈대 14개가 수동 전용이라, superpowers 의 훅이 주입하는 자동 활성 규칙과 경쟁하지 않습니다. 사용자가 슬래시 명령을 칠 때만 열립니다.

현실적인 조합은 이렇습니다. 막연한 단계에서 /grill-me 나 /wayfinder 로 생각을 정리하고, 소프트웨어로 확정되면 superpowers 의 자동 워크플로에 태웁니다.

다만 주의할 점이 셋입니다.

1. brainstorming 이 자동 발동하면 grilling 계열과 같은 자리를 두 번 밟습니다. 어느 쪽에 앞단을 맡길지 정해 두는 편이 낫습니다.
2. TDD 스킬이 둘 다 자동 발동 가능합니다. 그리고 Part 4에서 봤듯 리팩터링 위치에 대해 서로 다른 말을 합니다. 어느 쪽이 잡히느냐에 따라 루프가 달라집니다.
3. 상시 토큰이 합산됩니다. 약 2,775 토큰입니다.

둘 다 깔 거라면 CLAUDE.md 에 어느 쪽을 우선할지 한 줄 적어 두는 것을 권합니다. 4부작 Part 4 가 다룬 방법 그대로입니다.

5. 시리즈 총정리#

5부작을 쓰면서 가장 크게 바뀐 생각은 “크기 차이” 라는 인상이 틀렸다는 것입니다.

총 분량은 2,949줄과 2,945줄로 사실상 같았습니다. 다른 것은 그 분량을 몇 개의 파일에 어떻게 나누고, 언제 누구의 결정으로 읽히게 하느냐 였습니다. 그리고 그 배치의 차이가 결국 에이전트를 얼마나 믿을 것인가 라는 하나의 질문으로 수렴했습니다.

그 질문에 정답은 없습니다. 다만 자기가 어느 쪽 답을 택했는지 알고 쓰는 것과 모르고 쓰는 것은 다릅니다.

6. 읽고 나서 할 일#

시리즈를 마치며 실용적인 것 셋을 남깁니다.

① 깔기 전에 비용을 봅니다.

claude plugin details <플러그인 이름>

상시 토큰, 스킬별 호출 비용, 훅과 에이전트 개수가 한 번에 나옵니다. 소개 글 열 편보다 낫습니다.

② 진입점 스킬 하나는 읽습니다.

using-superpowers 87줄, ask-matt 90줄입니다. 각각 5분이면 됩니다. 그 묶음이 에이전트에게 무엇을 시키려 하는지가 거기 다 있습니다.

③ 설치 후 세션을 새로 시작합니다.

설치한 세션에서는 스킬이 잡히지 않습니다. Part 2에서 실제로 확인한 것입니다.

에이전트의 행동을 바꾸는 텍스트를 안 읽고 넣는 것은, 읽지 않은 의존성을 추가하는 것과 같습니다. 두 묶음 모두 SKILL.md 가 그냥 마크다운 파일이고 훅은 그냥 셸 스크립트입니다. 열어서 읽을 수 있고, 마음에 안 들면 고칠 수 있습니다.

References#

1차 자료

• obra/superpowers — https://github.com/obra/superpowers (MIT)
• mattpocock/skills — https://github.com/mattpocock/skills (MIT)
• 인용한 README 문구는 두 저장소의 원문입니다. 로컬 설치본은 superpowers v4.0.3, mattpocock-skills v1.2.3 입니다.

2차 자료 — 성격을 밝혀 인용합니다

• Alex Rusin, The Agentic Coding Pipeline Behind Matt Pocock’s Skills, 2026-08-07 — https://blog.alexrusin.com/agentic-coding-pipeline-matt-pocock-skills/
  • 3절의 “의식 비용” 인용 출처입니다. 필자가 “설치하지 않고 논지만 가져가도 된다” 고 명시한 개념 분석 글 이며 실사용 후기가 아닙니다.
• Richard MacManus, The /wayfinder Skill, Latent.Space, 2026-08-20 — https://www.latent.space/p/wayfinder-skill
  • Matt Pocock 인터뷰 기반이며 필자의 실사용 후기가 아닙니다.
• Reddit 스레드를 찾으려 했으나 검색 API 접근이 차단되어 원문 스레드를 확인하지 못했습니다. 확인하지 못한 것은 인용하지 않았습니다.

이 블로그의 관련 글

• Superpowers 플러그인 가이드 Part 1: 소개, 설치, 그리고 철학
• Part 2: 핵심 워크플로우
• Part 3: 품질 보증 스킬
• Part 4: 명시 호출 vs 자동 트리거 — 실전 가이드와 한계 — 3절에 인용한 한계 지적의 출처입니다.

밝혀 둘 것

• 이 시리즈는 설계와 설치 비용 비교 입니다. 두 묶음을 실제 프로젝트에 여러 세션 적용한 장기 사용기가 아닙니다.
• 두 플러그인 모두 실제로 설치해 토큰 비용·훅 구조·설치 동작을 쟀습니다. 다만 설치한 세션에서는 새 스킬을 호출할 수 없어(그 자체가 Part 2 의 결과입니다) 여러 라운드에 걸친 실제 grilling 세션 후기는 포함하지 못했습니다.
• 1절과 3절의 “둘 다 일리가 있다” 류의 판정은 필자의 견해 이며, 두 저장소 어느 쪽도 상대를 지목해 반박한 적이 없습니다. 원문에 있는 것은 각자의 규정과 일반화된 비판뿐입니다.

시리즈

• Part 1: superpowers 와 mattpocock/skills 의 지형도
• Part 2: 자동 활성은 셸 스크립트 한 개였다
• Part 3: 계획 단계 — 한 질문씩 vs 프론티어, 그리고 없는 프로토타입
• Part 4: 구현과 검증 — TDD 에서 정면으로 갈린다
• Part 5: 이 글