쓸모 쓸모연구소 · 실전 노트
제 740 호이번 주 새 글 260 편2026 · 10 · 30
스킬⁠·플러그인
Superpowers · gstack · Claude

Superpowers·gstack·Spec Kit 비교, AI 코딩 스킬 7종

AI 코딩 스킬은 많아졌는데, 설명을 읽어 보면 하나같이 "설계하고 코드를 만들고 테스트하고 검토한다"고 합니다. Superpowers, gstack, GitHub Spec Kit, Claude 공식 Feature Dev, skills, agent-skills, pstack 일곱 가지를 요구사항⁠·설계⁠·구현⁠·검증 네 단계로 나눠 무엇이 다른지 비교하고, 내 작업에 맞는 하나를 고르는 기준과 첫 명령까지 정리했습니다.

Superpowers·gstack·Spec Kit 비교, AI 코딩 스킬 7종 삽화
삽화 · 쓸모연구소

AI 코딩 스킬 7종, 무엇을 비교하나

결론부터 말하면 고르는 기준은 세 가지입니다. 정해진 개발 절차를 따르고 싶은지, 필요한 스킬만 골라 쓰고 싶은지, 어떤 부분을 더 꼼꼼히 검토하고 싶은지에 따라 맞는 도구가 달라집니다.

비교를 위해 사례를 하나로 고정합니다. "회의록을 자동으로 요약하고, 할 일을 뽑아, 담당자까지 배정하는 서비스"를 만든다고 가정합니다. 실제 프로젝트에서 성능을 잰 비교가 아니라, 같은 과제를 두고 각 스킬이 일을 다루는 방식을 견주는 것입니다.

이름 저장소 성격 별 수(2026년 10월) 라이선스
Superpowers obra/superpowers 정해진 개발 절차를 따라가는 스킬 프레임워크 약 30만 4천 MIT
gstack garrytan/gstack CEO·디자이너⁠·QA 같은 역할별 리뷰 약 13만 7천 MIT
skills mattpocock/skills 필요한 것만 골라 쓰는 작은 스킬 모음 약 30만 2천 MIT
agent-skills addyosmani/agent-skills 요구사항부터 배포까지 실무 원칙 약 11만 MIT
pstack cursor/plugins 안의 pstack 기존 코드 조사와 다른 모델의 교차 검토 저장소 전체 약 1만 4천 MIT
Feature Dev anthropics/claude-code의 plugins/feature-dev 기존 코드 분석부터 리뷰까지 한 흐름 Claude 공식 플러그인 Anthropic 이용약관
Spec Kit github/spec-kit 명세서를 기준으로 개발 전체 관리 약 14만 3천 MIT

스킬(skill)은 AI 코딩 에이전트에게 특정 작업 요령을 알려 주는 설명서 묶음입니다. Claude Code나 Codex에 설치해 두면 /이름으로 불러 쓰거나, 작업에 맞을 때 에이전트가 알아서 꺼내 씁니다.

1. 요구사항 단계: 무엇을 만들지 정하기

질문으로 구체화하는 세 가지

Superpowers, skills, agent-skills는 모두 질문으로 요구사항을 구체화합니다. 접근은 조금씩 다릅니다.

  • Superpowers: brainstorming 스킬이 "무엇을 원하는지, 그게 왜 필요한지"를 하나씩 묻습니다. 목적과 조건을 파악하면서 아이디어를 실제로 구현할 수 있는 설계안으로 키웁니다.
  • skills: 타입스크립트 강사 맷 포콕이 공개한 모음입니다. grill-me는 아직 결정하지 않은 부분을 집요하게 파고듭니다. 회의에서 담당자가 정해지지 않았으면 어떻게 할지, 여러 명이 언급되면 누구에게 배정할지 같은 놓치기 쉬운 조건을 찾아냅니다. grill-with-docs는 여기에 문서를 더해 프로젝트 용어를 맞추고, 정한 용어와 중요한 설계 결정을 문서로 남깁니다.
  • agent-skills: 구글 엔지니어 애디 오스마니가 공개한 모음입니다. interview-me로 의도를 파악하고, idea-refine으로 아이디어를 개발 가능한 요구사항으로 다듬습니다.

만들 필요부터 따지는 gstack

gstack은 결이 다릅니다. /office-hours는 구체적인 기능에 앞서 애초에 이걸 만들 필요가 있는지부터 따집니다. 회의록 요약 서비스는 이미 많은데 굳이 새 앱이 필요할까. 어쩌면 진짜 문제는 요약이 아니라, 회의에서 정한 일이 실행되지 않는 데 있을 수도 있습니다. 기능만이 아니라 실제 사용자 문제와 제품 가치까지 검토하는 단계입니다.

명세와 기존 코드에서 출발하는 세 가지

  • Spec Kit: 깃허브가 공개한 도구로, 정한 내용을 명세서로 남기는 데 무게를 둡니다. 명세 주도 개발(SDD, 명세서를 먼저 쓰고 그것을 기준으로 개발하는 방식)입니다. /speckit-specify로 요구사항을 문서화하고, /speckit-clarify로 빠진 조건을 보완합니다. "회의에서 담당자가 언급되지 않았다면 임의로 배정하지 않는다" 같은 규칙을 명확히 적어 두는 식이고, 이 명세가 이후 개발의 기준이 됩니다.
  • Feature Dev: Claude Code 공식 플러그인입니다. /feature-dev를 실행하면 만들 기능을 확인한 뒤 기존 프로젝트 코드를 탐색합니다. 회의록 저장 기능이 이미 있다면 그 구조를 조사하고, 불분명한 부분은 질문으로 확인해 새 기능을 기존 시스템에 어떻게 연결할지 구체화합니다.
  • pstack: 커서(Cursor) 엔지니어가 만든 스킬 모음으로, 실제 코드 작업에 맞는 절차를 고르는 데 초점을 둡니다. /poteto-mode에 작업 목표와 완료 조건을 주면 상황에 맞는 절차를 고릅니다. 기존 프로젝트를 고친다면 /how로 코드가 지금 어떻게 동작하는지, /why로 왜 그렇게 설계됐는지 근거를 찾아볼 수 있습니다.

2. 설계 단계: 계획 세우고 검토하기

작업 나누기

Superpowers, Spec Kit, agent-skills는 모두 작업을 작은 단위로 나눕니다. 무게를 두는 곳이 다릅니다.

  • Superpowers: writing-plans가 어떤 파일을 고치고 어떤 테스트를 쓸지까지 구체적으로 적습니다. AI가 개발 도중 방향을 잃지 않게 하려는 것입니다.
  • Spec Kit: 처음 쓴 명세가 실제 개발에서도 지켜지게 합니다. /speckit-plan으로 기술 구조를 정하고 /speckit-tasks로 작업을 나눠, 회의록 저장부터 요약, 담당자 배정까지 처음 요구한 기능이 빠지지 않게 잇습니다.
  • agent-skills: planning-and-task-breakdown도 작업을 나누는데, 작업마다 완료 기준과 먼저 해야 할 순서까지 정리합니다.

계획이 정말 괜찮은지 확인하기

계획을 세우는 것만큼 그 계획을 확인하는 일이 중요합니다.

  • gstack: /plan-ceo-review로 제품 방향을, /plan-eng-review로 기술 구조와 예외 상황을, /plan-design-review로 사용자 경험을 따로 검토합니다. AI가 담당자를 잘못 배정했을 때 사용자가 어떻게 고치고 되돌릴지까지 살피는 식입니다.
  • Feature Dev: 설계 단계에서 여러 아키텍처(전체 구조)를 제시합니다. 기존 코드를 재사용할지, 새 모듈로 분리할지 장단점을 비교해 방향을 고르게 돕습니다.

큰 작업과 설계안 비교

  • skills: 계획이 한 번에 끝나지 않을 만큼 크면 wayfinder가 맞습니다. 결정할 사항을 나누고 하나씩 정리하면서 여러 작업 세션에 걸쳐 프로젝트를 이어 가게 돕습니다.
  • pstack: /architect가 코드를 쓰기 전에 타입, 함수 인터페이스, 모듈 구조부터 설계합니다. 설계안을 여럿 비교하고 싶다면 /arena로 여러 에이전트에게 같은 과제를 맡겨 서로 다른 접근을 만들고, 각각의 장점을 합칩니다.

3. 구현 단계: 어떤 순서와 방식으로 짜나

여기서는 어떤 순서와 방식으로 구현하느냐가 갈립니다.

  • Superpowers: 테스트를 먼저 쓰는 TDD(테스트 주도 개발)를 강조합니다. 할 일 추출 기능이라면 테스트부터 쓰고, 실패하는지 확인한 다음 코드를 짜서 통과시킵니다. 작업을 잘게 나눠 각각 새 서브에이전트(따로 띄운 보조 에이전트)에게 맡기는 subagent-driven-development도 들어 있습니다.
  • agent-skills: incremental-implementation도 작게 개발하지만, 기능 하나를 끝까지 완성하는 데 초점이 있습니다. 서비스 전체를 한 번에 만들지 않고, 회의록 하나를 올려 요약 결과를 확인하는 데까지 먼저 완성한 뒤 넘어갑니다.
  • Spec Kit: 작업 목록 파일(tasks.md)에 정리된 순서와 의존 관계대로 /speckit-implement로 개발합니다.
  • Feature Dev: 앞에서 고른 아키텍처와 기존 프로젝트의 코드 규칙에 맞춰 새 기능을 구현합니다.
  • gstack: 검토한 계획대로 개발하고, 이어서 코드 리뷰와 실제 QA로 넘어갑니다.
  • skills: 필요한 스킬을 골라 기존 작업 방식에 덧붙이는 접근입니다. 코드 구조를 손볼 때는 improve-codebase-architecture를, 테스트가 필요하면 tdd를 쓰는 식입니다.
  • pstack: /poteto-mode는 작업 목표와 완료 조건을 받으면 상황에 맞는 절차(플레이북)를 골라 관련 스킬을 실행합니다. 새 기능 개발과 버그 수정에 서로 다른 절차를 씁니다. 개발자가 매번 스킬을 직접 고르기보다 작업에 맞는 절차를 따라가게 만든 구조입니다.

4. 검증 단계: 무엇을 어떻게 확인하나

모두 테스트와 리뷰를 중요하게 다룹니다. 그래서 "테스트 기능이 있다"만으로는 고르는 기준이 되지 않고, 무엇을 어떻게 확인하는지를 봐야 합니다.

테스트와 실제 동작

  • Superpowers와 skills: TDD로 원하는 동작을 확인합니다. 테스트가 먼저 실패하는지 보고, 구현한 뒤 통과하게 만듭니다. Superpowers는 여기에 서브에이전트가 쓴 코드가 요구사항을 지켰는지, 품질 문제는 없는지 검토하는 절차(requesting-code-review)도 둡니다.
  • agent-skills: TDD뿐 아니라 코드 리뷰, 보안 점검, 브라우저 테스트 같은 여러 검증 스킬을 갖췄습니다.
  • gstack: /review와 /qa로 코드 검토와 실제 동작 확인을 나눕니다. 화면에는 김 대리가 담당자로 표시됐는데 실제 알림은 이 과장에게 갔을 수도 있습니다. 빌드가 성공했다고 이런 문제까지 풀린 건 아니라서, 실제 앱을 실행해 확인합니다.

독립 리뷰와 명세 대조

  • pstack: /interrogate가 서로 다른 계열의 모델들에게 같은 코드 변경을 따로 검토하게 합니다. 여러 모델이 공통으로 지적한 문제는 더 중요한 신호로 보고, 엇갈린 의견도 비교해 판단에 반영합니다. 실행 결과와 검증 증거도 중시해서, 담당자 배정 오류를 찾았다면 먼저 재현하고, 고친 뒤, 같은 조건에서 정상 작동하는지 확인합니다.
  • Feature Dev: 리뷰 에이전트(code-reviewer) 세 개를 동시에 띄우되 기준을 나눕니다. 하나는 단순성과 중복, 하나는 버그와 정확성, 하나는 프로젝트 규칙 준수를 봅니다.
  • Spec Kit: 처음 쓴 명세와 결과가 일치하는지 확인합니다. /speckit-analyze로 명세와 계획 사이의 모순을 점검하고, 구현 뒤에는 /speckit-converge로 아직 충족하지 못한 요구사항을 찾습니다. 빠진 기능은 작업 목록에 다시 올려 구현하고, converge가 "Converged"를 보고할 때까지 구현과 점검을 되풀이합니다. 요약이 잘 돼도 처음 약속한 담당자 배정이 빠졌다면 아직 끝난 게 아닙니다.

내게 맞는 AI 코딩 스킬 고르고 시작하기

1. 고르기

  1. 내 작업에서 보완하고 싶은 부분을 정합니다.
    • 확인: 정해진 개발 절차를 따를지, 필요한 스킬만 골라 쓸지, 어떤 부분을 더 꼼꼼히 검토할지 가운데 어디에 가까운지 말할 수 있습니다.
  2. 아래 목록에서 내 바람에 맞는 줄을 찾습니다.
    • 정해진 개발 절차를 체계적으로 따르고 싶다 → Superpowers
    • 제품 방향부터 기술 설계, 실제 QA까지 여러 관점에서 검토하고 싶다 → gstack
    • 여러 설계안 비교, 다른 AI 모델의 검토와 실행 검증까지 쓰고 싶다 → pstack
    • 질문, TDD, 아키텍처 개선처럼 필요한 스킬만 골라 쓰고 싶다 → skills
    • 요구사항부터 구현과 테스트까지 실무 개발 원칙을 폭넓게 적용하고 싶다 → agent-skills
    • 기존 코드 분석부터 설계, 구현, 리뷰까지 하나의 흐름으로 가고 싶다 → Feature Dev
    • 명세를 기준으로 개발 전체를 관리하고 싶다 → Spec Kit

2. 설치하고 첫 명령 넣기

고른 도구에 해당하는 단계만 하면 됩니다. 명령은 Claude Code 기준이고 2026년 10월 각 저장소 README를 따랐습니다. /plugin으로 시작하는 줄은 Claude Code 입력창에, claude·git·uv·specify로 시작하는 줄은 터미널에 넣습니다. 플러그인은 설치할 때 상세 화면에서 들어갈 스킬을 확인하고 범위(나만 쓰기, 이 저장소의 모든 사람, 이 저장소의 나만)를 고릅니다.

  1. Superpowers: Claude Code 입력창에 설치 명령을 넣습니다. 설치해 두면 작업에 맞는 스킬이 자동으로 적용되니, 평소처럼 만들고 싶은 것을 말하면 됩니다.
명령어
/plugin install superpowers@claude-plugins-official
  1. gstack: 터미널에서 설치한 뒤, Claude Code에서 /office-hours로 시작합니다.
명령어
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup
  1. pstack: 아래 두 명령으로 설치하고, 처음에 /pstack:setup-pstack으로 쓸 모델을 고른 뒤, /pstack:poteto-mode에 작업 목표와 완료 조건을 함께 줍니다.
명령어
/plugin marketplace add cursor/plugins
/plugin install pstack@cursor-plugins
  1. Feature Dev: 설치한 뒤 /feature-dev 만들 기능 설명으로 시작합니다. 기존 코드에서 배우는 구조라, 코드가 있는 Git 저장소에서 써야 제 역할을 합니다.
명령어
/plugin install feature-dev@claude-plugins-official
  1. skills와 agent-skills: 설치한 뒤 필요한 개별 스킬만 골라 씁니다. skills는 터미널에서 첫 명령으로 설치하고, 작업할 저장소에서 /setup-matt-pocock-skills를 한 번 실행합니다. agent-skills는 입력창에 두 줄을 차례로 넣고, Claude Code 기본 명령과 이름이 겹치는 /review는 /agent-skills:review로 부릅니다.
명령어
claude plugin install mattpocock-skills@claude-plugins-official
명령어
/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
  1. Spec Kit: 파이썬 3.11 이상과 uv(파이썬 도구 설치기)가 필요합니다. 터미널에서 설치하고 프로젝트를 만든 뒤, Claude Code에서 /speckit-specify 만들 것 설명으로 명세 작성을 시작합니다. 에이전트에 따라 /speckit.specify처럼 점을 쓰는 형식으로 보일 수 있으니, 입력창에 /speckit까지 쳐서 나오는 이름을 고릅니다.
명령어
uv tool install specify-cli
specify init my-project --integration claude
  1. 설치를 확인합니다.
    • 확인: 플러그인으로 넣은 것(Superpowers, pstack, Feature Dev, skills, agent-skills)은 입력창에 /plugin을 쳐서 Installed 탭에 보이거나, 터미널의 claude plugin list에 보이면 됩니다. 설치 끝에 "Run /reload-plugins to apply."가 나오면 /reload-plugins를 입력합니다. gstack은 입력창에 /를 쳐서 office-hours가, Spec Kit은 만든 프로젝트 폴더에서 /speckit을 쳐서 speckit 명령이 보이면 됩니다.

지우는 방법도 설치 방식에 따라 다릅니다. 플러그인은 /plugin의 Installed 탭에서 Uninstall을 고르거나 터미널에서 claude plugin uninstall 플러그인@마켓플레이스(예: claude plugin uninstall superpowers@claude-plugins-official)를 실행합니다. gstack은 ~/.claude/skills/gstack/bin/gstack-uninstall, Spec Kit 명령줄 도구는 uv tool uninstall specify-cli로 지웁니다. pstack이나 agent-skills처럼 직접 추가한 마켓플레이스는 자동 업데이트가 꺼져 있어 claude plugin update pstack@cursor-plugins처럼 직접 업데이트합니다.

많이 깔수록 좋은 건 아니다

스킬을 많이 설치한다고 결과가 더 좋아지지는 않습니다. 비슷한 절차가 겹치거나 서로 부딪혀, 에이전트가 어느 스킬을 따라야 할지 헷갈립니다. 새 스킬을 깔기 전에 이미 설치한 것 가운데 같은 단계를 맡는 것이 있는지 먼저 살펴봅니다.

함께 볼 만한 두 가지

더 가볍게 명세 기반 개발을 시작하고 싶다면 OpenSpec(Fission-AI/OpenSpec, 약 7만 3천 개, MIT)이 있습니다. 한 번 한 개발에서 배운 것을 다음 작업에 쌓아 가고 싶다면 Compound Engineering 플러그인(EveryInc/compound-engineering-plugin, 약 2만 6천 개, MIT)도 있습니다.

자주 묻는 질문

처음 하나만 고른다면 무엇이 좋나요?

지금 가장 자주 막히는 지점으로 고릅니다. 만들라는 대로 만들었는데 원했던 결과가 안 나온다면 질문으로 요구사항을 다지는 Superpowers나 skills, 이미 있는 코드에 기능을 붙이는 일이 많다면 Feature Dev, 문서로 합의한 대로 끝까지 가야 하는 일이라면 Spec Kit이 맞습니다.

Superpowers와 Spec Kit은 무엇이 다른가요?

Superpowers는 질문, 계획, TDD, 서브에이전트 리뷰로 이어지는 개발 절차를 에이전트가 따라가게 만드는 스킬 묶음입니다. Spec Kit은 명세서를 기준 문서로 두고, 계획과 작업 목록, 구현 결과가 그 명세와 맞는지를 명령마다 확인하게 만드는 도구입니다.

여러 개를 함께 설치해도 되나요?

설치는 되지만 권하지 않습니다. 요구사항 질문, 테스트, 리뷰 기능이 겹쳐 같은 일을 하는 스킬이 여러 개 생기고, 에이전트가 엉뚱한 것을 꺼낼 수 있습니다. 하나를 몇 주 써 본 뒤 부족한 부분만 다른 쪽에서 골라 씁니다.

Feature Dev는 새 프로젝트에도 쓸 수 있나요?

쓸 수는 있지만 강점이 덜 드러납니다. 기존 코드를 여러 에이전트가 먼저 탐색해 그 구조와 규칙에 맞춰 설계하는 흐름이라, 코드가 쌓인 Git 저장소에서 기능을 더할 때 가장 잘 맞습니다. 한 줄짜리 수정이나 급한 수정에는 쓰지 말라고 공식 안내에도 적혀 있습니다.

이 글의 본문은 아래 원본 유튜브 영상의 내용을 바탕으로 쓸모연구소가 다시 정리해 쓴 것입니다. 세부 내용과 최신 정보는 원본 영상과 공식 안내에서 확인해 주세요.

원본 영상 보러가기 ↗