Superpowers 플러그인 가이드 Part 4: 명시 호출 vs 자동 트리거

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

1편 에서 개요와 설치를, 2편 에서 핵심 워크플로우를, 3편 에서 품질 보증 스킬을 다뤘습니다. 마지막 4편에서는 실전에서 가장 자주 부딪히는 질문에 답합니다.

“이거 그냥 두면 알아서 다 해주는 건가요, 아니면 매번 /superpowers:xxx 로 호출해야 하나요?”

답은 “대부분 자동이지만, 의도적으로 명시 호출해야 더 잘 작동하는 케이스가 있다” 입니다. 이 글에서는 두 모드의 비교 분석, 트러블슈팅, 커스터마이즈 방법, 그리고 Java/Go 백엔드 개발 현장에서의 실용 팁과 한계를 정리합니다.

자동 트리거의 메커니즘 — 다시 짚기#

1편 에서 다룬 자동 트리거 메커니즘을 한 번 더 정리하면 다음과 같습니다.

세션 시작 시 using-superpowers 부트스트랩이 로드된다.
부트스트랩은 “관련 스킬이 있을 가능성이 1% 라도 있으면 무조건 먼저 호출하라” 는 규칙을 설치한다.
사용자 메시지가 들어올 때마다 에이전트는 각 스킬의 description 필드와 의도를 매칭한다.
매칭되는 스킬이 있으면 명시적으로 Skill 도구로 invoke 한 뒤 그 내용을 따른다.

따라서 사용자 입장에서는 보통 “기능 추가해줘”, “버그 잡아줘”, “테스트 짜줘” 같은 평범한 요청만으로도 적절한 스킬이 알아서 발동됩니다.

자동 트리거되는 케이스#

다음은 평소처럼 자연어로 말하기만 해도 적절한 스킬이 자동 호출되는 케이스입니다.

사용자 메시지 패턴	자동 트리거되는 주 스킬
“X 기능 추가해줘”, “Y 만들자”	`brainstorming` → `writing-plans` → `using-git-worktrees` → `subagent-driven-development`
“이 버그 잡아줘”, “테스트가 빨강이야”	`systematic-debugging`
“테스트 추가해줘”, “이 함수 TDD 로”	`test-driven-development`
“완료한 거 정리해줘”, “PR 만들어줘”	`finishing-a-development-branch`
“리뷰해줘” (변경분에 대해)	`requesting-code-review`
코드 변경 후 “다 됐어, 통과해”	`verification-before-completion`
독립적인 여러 문제 동시에	`dispatching-parallel-agents`

이 케이스들은 자동 트리거에 그대로 맡기는 게 가장 좋습니다. 사용자가 굳이 /superpowers:brainstorming 같은 명시 호출을 할 필요가 없습니다.

자동 트리거의 장점#

사용자가 스킬 이름을 외울 필요 없음
적절한 시점에 적절한 스킬이 발동
여러 스킬이 순차/병렬로 자연스럽게 연결됨

자동 트리거의 한계#

매칭이 모호한 메시지에서는 잘못된 스킬이 호출될 수 있음
사용자 의도와 description 매칭이 어긋날 때 우회됨 (“간단한 거니까 그냥 짜줘” 같은 합리화 표현)
세션이 길어지면 컨텍스트에 다른 신호들이 섞이면서 트리거 정확도가 떨어질 수 있음

명시 호출이 더 좋은 케이스#

다음은 /superpowers:xxx 형태(혹은 “use the X skill” 식의 명시적 지시) 로 호출하는 게 더 안정적인 케이스입니다.

1. 스킬을 재호출하고 싶을 때#

긴 세션이 진행되다 보면 에이전트가 이전에 호출한 스킬의 규칙을 점점 “잊어가는” 듯한 현상이 나타납니다. 그럴 때 사용자가 명시적으로 다시 invoke 시키는 것이 효과적입니다.

잠깐, /superpowers:test-driven-development 다시 호출해서 RED-GREEN 사이클로 가자.

2. 자동 트리거가 잘못 동작했을 때#

에이전트가 의도와 다르게 스킬을 건너뛰거나, 다른 스킬을 호출했을 때 명시 호출로 교정합니다.

이건 새 기능 추가가 아니라 디버깅이야. /superpowers:systematic-debugging 부터 시작해줘.

3. “체크포인트” 모드를 강제하고 싶을 때#

자율 실행(subagent-driven-development) 대신 한 배치씩 사용자가 직접 보고 싶을 때 다음과 같이 명시합니다.

이번 plan 은 /superpowers:executing-plans 로 가자. 자율 실행은 말고.

4. 메타 스킬을 의도적으로 학습/검증하고 싶을 때#

새 스킬을 만들거나 기존 스킬의 동작을 점검할 때:

/superpowers:writing-skills 의 가이드대로 새 스킬 한번 만들어보자.

5. 디버깅 — “왜 스킬이 발동 안 했지?”#

세션 동안 어떤 스킬이 발동했는지 사용자가 추적하고 싶을 때, 직접 호출해 보면 스킬 내용을 그대로 볼 수 있습니다.

/superpowers:using-superpowers 호출해서 현재 어떤 규칙들이 활성화돼있는지 보여줘.

명시 호출 vs 자동 트리거 — 한 표로 정리#

flowchart TB
    A[사용자 요청] --> B{명확한<br/>워크플로우 진입?}
    B -->|예<br/>'기능 추가해줘'| C[자동 트리거에 맡김]
    B -->|아니오<br/>모호함| D{스킬 행동을<br/>강제하고 싶은가?}
    D -->|예| E[명시 호출<br/>/superpowers:xxx]
    D -->|아니오| F[자연어로 의도 명확화<br/>'이건 디버깅이야']
    C --> G[정상 작동]
    E --> G
    F --> C

    style A fill:#FFB6C1,color:#000000
    style B fill:#FFD700,color:#000000
    style C fill:#90EE90,color:#000000
    style D fill:#FFD700,color:#000000
    style E fill:#87CEEB,color:#000000
    style F fill:#DDA0DD,color:#000000
    style G fill:#FFA07A,color:#000000

원칙은 단순합니다.

평범한 작업 → 자동 트리거에 맡긴다.
모호하거나 잘못 트리거된 작업 → 자연어로 의도를 분명히 한다.
그래도 안 되거나 강제하고 싶다 → 명시 호출.

대부분의 경우 첫 번째로 충분합니다. 두 번째와 세 번째는 가끔 필요합니다.

자동 트리거가 작동하지 않을 때의 트러블슈팅#

설치는 됐는데 자동 트리거가 안 일어나는 경우가 종종 있습니다. 다음 순서로 점검합니다.

1. 부트스트랩이 로드되었는지 확인#

가장 흔한 원인은 using-superpowers 부트스트랩이 세션 시작 시 로드되지 않은 경우입니다. 다음 acceptance test 로 확인합니다.

Let's make a react todo list

코드 작성 전에 brainstorming 이 자동 호출되지 않으면 부트스트랩이 죽어 있는 것입니다. Claude Code 라면 다음을 시도합니다.

/plugin list 로 superpowers 가 실제 설치되어 있는지 확인
세션을 새로 시작 (재시작이 부트스트랩을 다시 로드함)
플러그인 마켓플레이스에서 재설치

2. CLAUDE.md / AGENTS.md 가 충돌하는지 확인#

using-superpowers 스킬의 “Instruction Priority” 섹션에 따르면 우선순위는 다음과 같습니다.

사용자의 명시적 지시 (CLAUDE.md, GEMINI.md, AGENTS.md, 직접 요청) — 최상위
Superpowers 스킬 — 기본 시스템 동작을 오버라이드
기본 시스템 프롬프트 — 최하위

즉, CLAUDE.md 에 “don’t use TDD” 라고 적혀 있으면 TDD 스킬이 무력화 됩니다. 의도하지 않은 비활성화가 일어나고 있지 않은지 점검합니다.

3. 세션 컨텍스트 오염#

긴 세션에서는 이전 대화의 잡담이나 무관한 출력이 컨텍스트에 쌓이면서 스킬 매칭이 흐려집니다. 이때 가장 효과적인 방법은:

새 세션을 열고 의도만 명확히 다시 입력
또는 명시 호출로 정확히 어떤 스킬을 쓸지 지정

4. Description 매칭 실패#

사용자가 의도를 모호하게 표현하면 스킬이 매칭되지 않습니다. 예를 들어 “이거 좀 봐줘” 보다는 “이 함수에 새 분기 추가해줘” 가 훨씬 정확히 매칭됩니다. 의심스러우면 자연어를 좀 더 명확히 다듬어 봅니다.

CLAUDE.md / AGENTS.md 로 동작 조절하기#

프로젝트별로 Superpowers 동작을 미세 조정하고 싶다면, 프로젝트 루트의 CLAUDE.md (또는 AGENTS.md, GEMINI.md) 에 지시를 추가합니다.

워크트리 자동 생성 비활성화#

이 블로그 프로젝트처럼 단일 main 브랜치에서 가볍게 작업하는 경우, worktree 생성이 오히려 번거롭습니다.

## Superpowers 동작 조정

- `using-git-worktrees` 스킬은 호출하지 않는다. 모든 작업은 현재 디렉터리에서 직접 진행한다.

특정 스킬의 강도 조절#

TDD 가 너무 빡빡하다고 느낄 때 (예: throwaway prototype 작업):

## Superpowers 동작 조정

- 본 프로젝트는 prototype 성격이라 `test-driven-development` 스킬의 Iron Law 를 적용하지 않는다.
- 단, production 코드로 promote 할 때는 TDD 를 적용한다.

이렇게 작성하면 스킬의 우선순위 1번(사용자 지시) 이 발동되어 스킬을 우회할 수 있습니다. 단, 이건 정말 필요한 경우에만 쓰세요. Superpowers 의 가치 명제는 강제력에서 나오기 때문에, 무력화하기 시작하면 효과가 빠르게 사라집니다.

도메인 컨텍스트 주입#

Java/Spring 프로젝트라면:

## 프로젝트 컨텍스트

- 빌드: `./gradlew clean test`
- 통합 테스트: `./gradlew integrationTest`
- 코드 스타일: Google Java Format
- 데이터베이스: PostgreSQL 15 (마이그레이션: Flyway, 위치: `src/main/resources/db/migration/`)
- ORM: JPA + QueryDSL

이런 정보를 박아두면 writing-plans 가 만드는 task 들이 프로젝트 컨벤션에 맞게 자동 생성됩니다. 예를 들어 verification-before-completion 이 검증 명령으로 ./gradlew clean test 를 자동 선택합니다.

Java/Go 백엔드 개발자를 위한 실용 팁#

팁 1: 첫 사용은 작은 기능부터#

Superpowers 의 워크플로우는 처음 보면 “왜 이렇게 절차가 많지” 싶습니다. 큰 기능부터 시도하면 답답함이 누적됩니다. 새 API endpoint 하나 추가 정도의 작은 기능으로 끝까지 한번 가본 다음, 익숙해진 뒤 큰 작업으로 확장하는 게 좋습니다.

팁 2: Subagent 자율 실행은 자리 비울 때#

subagent-driven-development 모드는 사용자가 옆에서 보고 있으면 답답합니다. “왜 저렇게 잘게 쪼개서 일하지?”, “저 부분은 내가 하면 1분인데?” 라는 생각이 들기 쉽습니다. 점심시간이나 회의 시간처럼 사용자가 자리를 비울 수 있는 시간 에 맡기는 것이 정신건강에 좋습니다.

팁 3: 코드 리뷰 subagent 의 보고를 그대로 믿지 말 것#

3편에서 다뤘듯이 reviewer subagent 의 보고는 independent review 라는 점에서 가치가 있지만, 모델은 여전히 모델입니다. Critical 이슈로 보고된 항목 중 진짜 critical 인지 사람이 한 번 더 검토해야 합니다. 특히:

보안 관련 권고는 over-cautious 한 경우가 있음
성능 관련 권고는 측정 없이 단순 추측인 경우가 있음

팁 4: Plan 문서를 재사용하라#

writing-plans 가 만든 plan 문서는 docs/superpowers/plans/ 에 커밋됩니다. 이게 단순히 한 번 쓰고 버리는 게 아니라, 나중에 비슷한 작업을 할 때 참고용 으로 매우 유용합니다. 팀에서 자주 반복되는 패턴(예: “새 API endpoint 추가” plan template) 을 한 번 잘 만들어두면 다음 사람이 그대로 활용할 수 있습니다.

팁 5: Brainstorming 단계에서 충분히 시간을 쓸 것#

처음 써본 사람들이 가장 자주 하는 실수는 brainstorming 단계의 질문에 대충 답하는 것입니다. “응 그렇게 해” 류의 답변은 결국 모호한 spec 으로 이어지고, plan 도 모호해지고, 결과물도 어긋납니다. brainstorming 의 10분이 구현의 1시간을 절약 한다고 생각하고 차분히 답하는 게 좋습니다.

팁 6: 큰 기능은 sub-project 로 쪼개기#

brainstorming 스킬에는 “여러 독립 subsystem 으로 구성된 큰 요청은 먼저 sub-project 로 decompose 하라” 는 규칙이 있습니다. “사용자 시스템 만들어줘 (인증/프로필/팔로우/알림/검색…)” 같은 요청이 들어오면 에이전트는 거부합니다. 적절한 크기로 쪼개서 하나씩 가는 게 결과적으로 빠릅니다.

한계와 주의사항#

Superpowers 는 강력하지만 만능은 아닙니다. 다음 한계는 분명히 인지하고 써야 합니다.

1. 단순 일회성 작업에 과한 절차#

“이 줄 띄어쓰기 하나만 고쳐줘” 같은 작업에도 brainstorming 이 발동되면 답답합니다. 이런 경우 의도를 명확히 표현하면(format only, cosmetic change) 보통 우회되긴 하지만, 완전히 신뢰할 수는 없습니다. 자동 트리거의 본질적 트레이드오프입니다.

2. 학습 곡선#

처음 한두 번은 “왜 이렇게 길게 일하지” 싶은 답답함이 옵니다. 이 시기를 지나야 효용이 보입니다.

3. 모델 성능에 종속#

스킬의 강제력은 결국 모델이 그 규칙을 따라줄 때만 의미가 있습니다. 작고 빠른 모델일수록 Iron Law 같은 강한 규칙을 우회하는 경향이 있습니다. Claude Opus, GPT-5 같은 상위 모델에서 가장 안정적으로 작동합니다.

4. 비밀번호 같은 운영 데이터 접근#

자율 실행 모드에서 외부 시스템 접근(예: 운영 DB 마이그레이션) 이 필요한 경우 진행이 막힙니다. executing-plans 모드로 전환하고 사용자가 직접 그 단계만 처리하는 패턴이 안전합니다.

5. 팀 단위 도입의 어려움#

개인 차원에서는 효과가 빠르게 보이지만, 팀 단위로 도입하려면 합의가 필요합니다. 누군가는 “왜 이렇게 절차를 만들어야 하지” 라고 반대할 수 있습니다. 한 사람이 먼저 써보고 결과물의 품질을 보여주는 식의 점진 도입을 추천합니다.

6. 비공식 fork/변형 주의#

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

마치며#

4편에 걸쳐 Superpowers 플러그인을 다뤘습니다. 핵심 메시지를 다시 정리하면 다음과 같습니다.

Superpowers 는 방법론을 자동 적용되는 규칙 으로 주입하는 플러그인이다.
핵심 워크플로우는 brainstorming → writing-plans → subagent-driven-development → finishing-a-development-branch 이며, 평범한 자연어 요청만으로 자동 트리거된다.
품질 보증 스킬(test-driven-development, systematic-debugging, verification-before-completion, code review) 들의 Iron Law 가 에이전트의 합리화를 차단한다.
명시 호출(/superpowers:xxx) 은 자동 트리거가 잘못됐거나 강제하고 싶을 때만 쓴다.
CLAUDE.md/AGENTS.md 로 프로젝트별 동작을 조절할 수 있지만, 강제력을 약화시키는 변형은 효과를 줄인다.
작은 기능부터 시작하고, 자율 실행은 자리 비울 때 쓰며, brainstorming 단계에 충분히 시간을 쓰는 것이 실전 운영의 핵심이다.

Vibe coding 이 보편화될수록 “방법론 없이 모델 성능에만 기대는” 접근은 점점 한계가 보입니다. Superpowers 같은 도구가 보여주는 방향은 명확합니다 — 모델을 더 똑똑하게 만드는 것이 아니라, 모델이 따라야 할 규율을 명문화해서 그 위에서 일하게 한다. 결과적으로 같은 모델로도 훨씬 안정적인 산출물을 얻을 수 있습니다.

Java/Go 백엔드 개발 현장에 적용해 보면, 처음 1~2주는 적응 기간이지만 그 이후부터는 “사람이 옆에 붙어 있지 않아도 일정 품질이 나오는” 경험이 시작됩니다. 한 번 그 경험을 하면, 이전의 무방비 vibe coding 으로 돌아가기 어렵습니다.

References#

Superpowers 저장소: https://github.com/obra/superpowers
using-superpowers (부트스트랩 스킬): https://github.com/obra/superpowers/blob/main/skills/using-superpowers/SKILL.md
원작자 출시 발표: https://blog.fsck.com/2025/10/09/superpowers/
Claude Plugin 공식 마켓플레이스 페이지: https://claude.com/plugins/superpowers
1편: Superpowers 플러그인 가이드 Part 1: 소개, 설치, 그리고 철학
2편: Superpowers 플러그인 가이드 Part 2: 핵심 워크플로우
3편: Superpowers 플러그인 가이드 Part 3: 품질 보증 스킬

Superpowers 플러그인 가이드 Part 4: 명시 호출 vs 자동 트리거 — 실전 가이드와 한계