클로드 스킬 직접 만드는데 슈퍼파워스가 필요할까? 반나절 써봤습니다

슈퍼파워스(Superpowers)는 클로드 코드에 스킬 14개를 한 번에 설치하는 플러그인입니다. 저는 이미 클로드 스킬을 8개 쓰고 있어서 "그냥 내가 만들면 되는 거 아닌가" 싶었습니다. 반나절 써보니 그 생각이 반은 맞고 반은 틀렸습니다.

2026년 8월 6일에 설치해서 실제 업무 도구를 하나 만들어봤습니다. 아래는 그 기록입니다. 잘된 것과 오해한 것을 같이 적었습니다.

슈퍼파워스가 뭔가요?

슈퍼파워스는 클로드 코드에 개발 규율 14개를 스킬로 심는 플러그인입니다. Jesse Vincent가 만든 오픈소스고요.

설치는 한 줄입니다.

/plugin install superpowers@claude-plugins-official

저는 저장소 마켓플레이스 쪽으로 깔았습니다.

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

설치된 버전은 v6.2.0이었고, 들어온 스킬은 14개입니다.

개발 방법론 — test-driven-development · systematic-debugging · verification-before-completion
계획/실행 — brainstorming · writing-plans · executing-plans
병렬 작업 — dispatching-parallel-agents · subagent-driven-development · using-git-worktrees
코드 리뷰 — requesting-code-review · receiving-code-review · finishing-a-development-branch
메타 — using-superpowers · writing-skills

무료입니다. MIT 라이선스 오픈소스라 설치비도 구독료도 없습니다. 드는 비용은 토큰뿐인데 이것도 가볍습니다 — 항상 켜져 있는 부분이 약 688토큰이고, 나머지는 해당 스킬이 실제로 발동할 때만 로드됩니다.

슈퍼파워스, 그냥 클로드 스킬로도 되지 않나요?

제가 가장 먼저 든 의문입니다. 스킬은 결국 마크다운 문서고, 클로드 코드는 원래 스킬을 지원합니다. 저도 8개를 직접 만들어 쓰고 있고요.

차이는 "강제"에 있었습니다. 스킬 설명문이 이렇게 되어 있습니다.

/superpowers:brainstorming
(superpowers) You MUST use this before any creative work

권고가 아니라 명령입니다. 저장소 문서도 같은 표현을 씁니다 — "Mandatory workflows, not suggestions."

보통 스킬은 클로드가 "관련 있어 보일 때" 참조합니다. 슈퍼파워스는 모든 작업 전에 스킬을 확인하도록 만듭니다. 이 차이가 실제로 어떻게 나타났는지가 아래 내용입니다.

뭘 만들었나

AI 크롤러가 우리 글을 읽을 수 있는지 확인하는 도구입니다.

지피터스 웹사이트에 매일 글을 쓰는데, 페이지 유형에 따라 AI 크롤러가 본문을 못 읽는 경우를 발견했습니다. 게시글은 3,000자 넘게 읽히는데 어떤 페이지는 165자만 읽힙니다. AI가 본문을 못 읽으면 ChatGPT나 퍼플렉시티가 인용할 소스 자체가 없습니다.

매번 터미널에서 curl로 확인하는 게 번거로워서 도구로 만들기로 했습니다.

첫 프롬프트는 이렇게만 줬습니다. 구현 방법은 일부러 적지 않았습니다.

AI 크롤러가 내 글을 읽을 수 있는지 확인하는 도구를 만들고 싶어.

배경: 지피터스 웹사이트에 매일 글을 쓰는데, 어떤 페이지는 크롤러가
본문을 못 읽는다는 걸 발견했어. 커스텀 페이지는 165자만 읽히고
게시글은 3,000자 넘게 읽혀. 그런데 매번 터미널에서 curl로
확인하는 게 번거로워.

나는 비개발자야. 마케터고, 클로드 코드로 작업해.

슬래시 명령을 안 썼는데 brainstorming이 자동으로 발동했습니다. 그리고 코드를 짜지 않고 질문부터 던졌습니다.

안 깔았으면 놓쳤을 것들

반나절 동안 나온 것 중 제가 혼자 했으면 그냥 지나갔을 것들입니다.

있는 걸 또 만들 뻔했다

첫 응답에서 코드를 짜지 않고 기존 파일부터 훑었습니다. 그러더니 이렇게 말했습니다.

code/seo-tool에 이미 Googlebot 시뮬레이터가 있는데, 지금 만들려는 건 성격이 다릅니다 — Googlebot은 JS를 실행해서 렌더링하지만, AI 크롤러는 대부분 JS를 실행하지 않고 원본 HTML만 봅니다.

시키지 않았습니다. 그리고 이 판단이 맞습니다. 비개발자가 제일 흔히 하는 실수가 이미 있는 걸 모르고 또 만드는 것인데, 그걸 시작 3분 만에 막았습니다.

내 요청 두 개가 서로 충돌한다는 걸 잡았다

설계 검토 중에 제가 요청 세 가지를 한꺼번에 던졌습니다. 그중 두 개가 이겁니다.

중요 페이지를 작성자와 무관하게 매주 보는 감시 목록을 만들어달라
URL에 /post/가 있는지로 게시글과 목록을 구분해달라

그랬더니 이렇게 답했습니다.

2번과 3번이 충돌합니다. 정작 문제인 스터디 신청 페이지들은 주소에 /post/가 없어서 "목록이니 정상"으로 면제됩니다. 정확히 잡아내야 할 두 페이지가 빠져나갑니다.

맞습니다. 제가 두 요청을 따로 던지는 바람에 잡아야 할 페이지가 면제되는 규칙이 될 뻔했습니다. 감시 목록이 URL 규칙을 이기도록 우선순위를 정해서 해결했습니다.

확인할 수 없는 근거를 거절했다

제가 설계 근거로 논문 하나를 인용했습니다. 그랬더니 이렇게 답했습니다.

arXiv 2605.25517은 제가 확인할 수 없습니다(제 지식 기준일 이후 논문). 그래서 오즈비 수치를 근거로 삼지는 않았고, 지피터스 자체 실측만으로 설계를 바꿨습니다. 결론은 같습니다.

그리고 설계 문서에 "근거의 범위"라는 항목을 따로 만들어 적어뒀습니다. 확인 못 하는 걸 인용하는 대신 직접 잰 데이터로 대체한 겁니다.

165자가 사실 24자였다

이게 제일 컸습니다.

제가 "이 숫자가 진짜 기간이 맞냐"고 한 번 물었더니, 확인하다가 이걸 찾았습니다.

"📣 24기 대기자 모집이 시작되었습니다!"   ← 모든 페이지에 붙는 전역 배너

모든 페이지가 이 배너 때문에 가짜 신호를 갖고 있었습니다. 그리고 제가 "165자"라고 알고 있던 페이지는 사실 본문 0자 + 네비게이션 165자였습니다. 실제 본문은 24자입니다.

<article> 태그 우선 추출로 고쳤고, 결과가 이렇게 나왔습니다.

게시글 A — 태그만 벗김 4,528자 · 고친 뒤 4,293자
게시글 B — 태그만 벗김 8,719자 · 고친 뒤 8,304자
랜딩 페이지 — 태그만 벗김 165자 · 고친 뒤 24자
외부 도메인 페이지 — 태그만 벗김 3,429자 · 고친 뒤 3,429자 (변화 없음)

마지막 줄이 중요합니다. <article>이 없다고 0자 처리하면 외부 도메인 페이지가 오판됩니다. 그것까지 미리 확인하고 우회 설계를 넣었습니다.

자기가 쓴 계획에서 검증 안 된 부분을 지웠다

구현 계획을 쓰다가 스스로 이렇게 고쳤습니다.

문맥 단어 목록에 검증하지 않은 스터디|강의를 넣었는데, 이건 notice 글에도 등장하는 단어라 오탐을 되살릴 수 있습니다. 실제로 검증한 목록만 쓰겠습니다.

그리고 코드 주석에 경고를 박았습니다 — "임의로 단어를 추가하지 말 것."

그런데 오해도 했습니다

좋은 것만 쓰면 광고가 되니 오해도 그대로 적습니다.

같은 오해를 두 번 했다

제가 게시글 작성자 정보를 알려주려고 이름과 이메일을 말했습니다. 두 번 다 git 커밋 설정으로 알아들었습니다.

나:  "지피터스_강지인 <이게 나야"
도구: → git config user.name 변경

나:  "내 이메일은 [email protected] 이거"
도구: → git config user.email 변경 + "개인 사이드 프로젝트라 커밋을
       개인 이메일로 남기시려는 걸로 이해했습니다"

바로 되돌리긴 했지만, 이름·이메일 얘기가 나오면 git 설정으로 해석하는 습관이 있는 것 같습니다.

읽은 문서를 반대로 요약했다

프로젝트 폴더 규칙을 확인하더니 이렇게 말했습니다.

최상위 CLAUDE.md의 폴더 원칙에 따르면 code/가 개인 사이드입니다.

실제 문서는 정반대입니다. code/가 회사 레포고 side/가 개인용입니다. 결과적으로 옳은 폴더를 골랐지만 근거를 틀리게 댔습니다. 제가 "회사용이야"라고 말해서 우연히 맞은 겁니다.

읽은 내용을 반대로 요약한 거라, 문서 인용은 한 번씩 대조해보는 게 좋겠습니다.

한국어에서만 나는 함정

이건 영어권 리뷰에는 안 나올 내용이라 따로 적습니다.

계획서에 이런 정규식이 들어갔습니다. 단위 뒤에 한글이 오면 제외하는 규칙입니다.

/(?<![:\d])\d{1,5}\s*명(?![가-힣])/g

구현하던 에이전트가 이걸 거부했습니다. 확인해보니 맞았습니다.

"스터디 1-6기 동안 800명이 참여했고"
                    ↑ 조사 '이' 때문에 800명이 누락됨

한국어는 조사가 단위에 바로 붙습니다. 800명이, 4주입니다, 3주째 가 전부 빠집니다. "모집 기간은 4주입니다"라는 문장이 기간 0건으로 나오던 상태였습니다.

규칙을 단순하게 바꿔서 해결했지만, 이런 건 한국어로 실제로 돌려보기 전엔 안 보입니다.

14개 중 실제로 쓴 것

화면에 스킬 이름이 뜬 것만 셌습니다. 8개가 실제로 발동했고 6개는 안 나왔습니다.

쓰인 것 8개

brainstorming — 첫 요청 직후 자동. 코드 대신 질문부터
writing-plans — 14개 Task 구현 계획 작성
subagent-driven-development — Task마다 새 에이전트 배정
test-driven-development — 실패 테스트 먼저, 그다음 구현
requesting-code-review — Task마다 별도 리뷰어
receiving-code-review — 리뷰 지적을 원 에이전트에게 되돌림
writing-skills — /crawl-check 슬래시 명령 문서 작성
finishing-a-development-branch — 브랜치 정리 후 main 병합

안 나온 것 6개

executing-plans — subagent-driven-development가 대신함
dispatching-parallel-agents — 순차로 돌았습니다
using-git-worktrees — 브랜치만 쓰고 워크트리는 안 썼습니다
systematic-debugging · verification-before-completion · using-superpowers — 이름이 안 떴습니다

14개 전부가 쓰이지는 않습니다. 파일 열 몇 개짜리 도구에 워크트리와 병렬 에이전트까지 나올 일이 없었고요. 규모가 커지면 달라지겠지만, 이 정도 작업에서는 절반 조금 넘게 씁니다.

얼마나 걸렸나

구현은 2시간이었습니다. 계획이 확정된 뒤 14개 작업을 다 끝내는 데 2시간 16분 걸렸습니다.

앞뒤를 붙이면 이렇게 됩니다. 커밋 로그에서 뽑은 실제 시각입니다.

설계·계획 13:40 → 14:24 — 44분 (이 동안 코드는 한 줄도 안 나옴)
구현 14:30 → 16:46 — 2시간 16분 (14개 작업)
최종 리뷰·수정 16:46 → 17:28 — 42분

설계에만 44분을 썼습니다. 처음엔 답답했는데 나중에 이 44분이 값을 했습니다.

결과물은 이렇습니다.

코드 810줄 · 테스트 82개 · 커밋 41개
의존성 0 (Node 내장 기능만)
주간 점검 1회 실행에 1분 15초

잡힌 버그 12개, 그중 10개가 설계 잘못

이게 이 도구의 진짜 값어치였습니다.

리뷰가 실제 버그를 12개 잡았는데 10개가 제 계획서의 오류였습니다. 커밋 41개 중 12개가 "계획 수정"으로 시작합니다. 코드를 고친 게 아니라 계획을 고치고 다시 만들게 한 것입니다.

가장 위험했던 셋입니다.

① 주간 대상의 3분의 2가 조용히 사라지고 있었습니다

사이트맵 하나가 776KB에 11초 걸리는데, 페이지용 10초 제한을 그대로 써서 탈락했습니다. 그 안에 최근 글 565개가 있었습니다.

정상 848개  →  실제로는 283개만 수집
에러 없음. 리포트는 "다 봤습니다"라고 출력

단위 테스트 5개는 전부 통과했습니다. 저장된 파일로 도니까요. 실제 사이트에 붙여봐야만 보이는 종류였습니다.

② 작성자를 못 읽은 글이 집계에서 빠졌습니다

카운터는 에 게시됨만 보는데 추출기는 © Copyright까지 필요했습니다. 두 조건이 달라서 그 틈으로 글이 조용히 빠집니다. 베터모드가 표시 위치를 바꾸면 모든 글이 빠지고 "이번 주에 글을 안 쓰셨네요"가 출력됩니다.

③ robots.txt가 404면 차단 검사를 통째로 건너뛰었습니다

표준은 404 = 전체 허용인데, 코드는 "확인 불가"로 처리했습니다. 실제로 저희 서브도메인 하나가 여기 해당했습니다. 모든 AI 크롤러를 막고 있는 페이지도 ✅로 나올 수 있었습니다.

셋 다 같은 유형입니다 — 도구가 깨끗한 결과를 보고하면서 실제로는 안 본 것. 에러가 나는 것보다 나쁩니다. 그래서 지금은 리포트 하단에 받기 실패·작성자 불명·사이트맵 실패 개수가 항상 찍힙니다. 0이 아니면 그만큼 못 본 겁니다.

완성된 도구가 실제로 찾은 것

만들고 나서 바로 돌려봤습니다. 857개 페이지, 1분 15초입니다.

제가 쓴 글은 문제가 없었습니다. 지난주 16건 전부 정상적으로 읽힙니다(2,677–8,305자).

문제는 스터디 랜딩 쪽이었습니다.

스터디 신청 페이지 — 판정 ❌ · 문제 읽히는 양이 거의 없음
스터디 소개 서브도메인 — 판정 ❌ · 문제 같음
운영방식 안내 글 — 판정 ✅ · 문제 읽히지만 참가비·인원이 없고 정보가 오래됨
3년 전 기수 랜딩 — 판정 ✅ · 문제 잘 읽히는데 가격 기준일이 없음

"AI 스터디 추천해줘"에 지피터스가 답으로 나올 근거가 지금 없습니다. 그런데 3년 전에 만든 낡은 페이지는 가격도 기간도 다 있어서 잘 읽힙니다. 현재 페이지보다 옛날 페이지가 AI에게 더 잘 보이는 상태였습니다.

덤으로 하나 더 나왔습니다. 사이트맵 색인이 존재하지 않는 파일 2개를 가리키고 있습니다. 구글도 매주 404를 받고 있다는 뜻이라, 개발팀에 전달할 건으로 따로 뺐습니다.

그래서 누구에게 권하나

권할 만한 경우

클로드 코드로 뭔가 만들다가 중간에 방향이 틀어져 되돌린 경험이 있는 사람
코드는 나오는데 그게 맞는지 확인할 방법이 없어 불안한 사람
비개발자인데 "일단 짜고 보자"로 갔다가 꼬인 적 있는 사람

과할 수 있는 경우

파일 한두 개짜리 작은 스크립트
이미 설계가 머릿속에 완전히 잡혀 있는 작업

판단 기준은 하나로 정리됐습니다. 잡힌 버그 12개 중 10개가 계획서 오류였다는 것 — 즉 오류의 대부분이 코드가 아니라 그 앞 단계에 있었습니다. 계획서를 안 쓰면 그 10개는 코드가 된 다음에, 혹은 영영 안 잡힙니다.

그래서 이렇게 말할 수 있습니다. 결과물의 정답을 내가 확인할 수 없는 일일수록 값을 합니다. 저는 크롤러가 뭘 읽는지 눈으로 확인할 방법이 없습니다. 그런 일에서 "다 됐습니다"를 그대로 믿으면, 565개가 빠진 리포트를 몇 주 동안 맞다고 여겼을 겁니다.

반대로 결과를 내가 바로 눈으로 확인할 수 있는 일이면 굳이 필요 없습니다.

정리하며

제가 처음 던진 질문은 "스킬 8개 만들어 쓰는데 남의 스킬 묶음이 필요한가"였습니다.

반나절 써본 답은 이렇습니다. 스킬을 만들 줄 아는 것과, 만들기 전에 멈춰서 설계하도록 자신을 강제하는 것은 다른 문제였습니다. 제가 만든 8개는 전부 콘텐츠·마케팅 워크플로우고, 개발 규율은 한 번도 만들어본 적이 없었습니다.

반은 맞고 반은 틀렸다고 처음에 썼는데, 이제 어느 쪽이 어느 쪽인지 말할 수 있습니다.

맞은 쪽 — 이 스킬들은 특별한 마법이 아닙니다. 내용만 보면 "계획부터 써라", "테스트 먼저 짜라", "리뷰를 받아라"입니다. 아는 얘기고, 저도 직접 쓸 수 있습니다.

틀린 쪽 — 아는 것과 매번 하는 것은 다릅니다. 저는 급하면 건너뜁니다. 이날도 44분 동안 코드가 한 줄도 안 나올 때 "그냥 짜지" 싶었고요. 그 44분에서 나온 계획서가 나중에 버그 10개를 잡았습니다.

남의 스킬 묶음이 필요했던 이유는 규율의 내용이 아니라 강제력이었습니다. 제가 만든 8개 스킬은 전부 제가 잘하고 싶은 일(콘텐츠·SEO)을 돕는 것들이지, 제가 건너뛰고 싶어 하는 일을 못 건너뛰게 막는 건 하나도 없었습니다.

그리고 도구는 지금 매주 돌아갑니다. /crawl-check --week 한 줄에 1분 15초입니다.

자주 나오는 질문

슈퍼파워스는 유료인가요?
무료입니다. MIT 라이선스 오픈소스라 설치비도 구독료도 없습니다. 드는 건 토큰뿐이고, 항상 켜져 있는 부분은 약 688토큰입니다.

비개발자도 쓸 수 있나요?
저는 개발자가 아니고 마케터입니다. 첫 프롬프트에 "나는 비개발자야"라고만 적고 시작했습니다. 다만 결과를 확인하려면 터미널에서 명령을 실행할 줄은 알아야 합니다.

14개를 다 쓰게 되나요?
아니요. 이번 작업에서는 8개만 발동했습니다. 파일 열 몇 개짜리 도구에는 워크트리나 병렬 에이전트가 나올 일이 없습니다.

한국어 작업에서 주의할 점이 있나요?
있습니다. 숫자·단위를 다루는 규칙을 만들 때 조사가 붙는 걸 빠뜨리기 쉽습니다. 800명이, 4주입니다처럼요. 한국어 문장으로 실제로 돌려보기 전엔 안 보입니다.

설치했다가 안 맞으면 어떻게 하나요?
/plugin uninstall superpowers로 지우면 됩니다. 기존에 쓰던 스킬은 그대로 남습니다.

지피터스에서는 이런 걸 각자 해보고 서로 공유합니다. 저도 이번 작업 기록을 정리해 올린 거고요. 비슷한 걸 만들어보셨다면 어떻게 하셨는지 궁금합니다.

확인일: 2026년 8월 6일
버전: superpowers v6.2.0
출처: obra/superpowers · Anthropic 공식 플러그인 페이지

이 글의 시간·글자수·토큰 수치는 실제 작업 중에 측정한 값입니다. 소요 시간은 커밋 로그의 타임스탬프에서 뽑았습니다. 도구가 발견한 버그와 오해는 각색 없이 그대로 적었습니다.
작성자 — 지피터스에서 마케팅을 하고 있습니다. 매일 웹사이트에 글을 쓰고, 그 작업을 자동화하려고 클로드 스킬을 만들어 씁니다(콘텐츠 발행·뉴스레터·SEO 점검 등 8개). 개발자는 아닙니다.