spec-kit vs superpowers: 코딩 에이전트에게 “프로세스”를 주는 두 가지 방식

분석 일자: 2026-06-01 spec-kit 대상 커밋: 3617cd9c0219092d778f81118110daf127918baf (main) spec-kit 저장소: https://github.com/github/spec-kit spec-kit 로컬 경로: ~/workspace/opensources/spec-kit superpowers 대상 버전: 5.0.7 (claude-plugins-official) superpowers 로컬 경로: ~/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7

This article is partially written by Claude.

목차

1. 왜 이 둘을 같이 보나
2. 한 문장 요약
3. 배포 모델: CLI냐 플러그인이냐
4. 워크플로우 매핑
5. 산출물 철학: 파일이냐 규율이냐
6. 토큰·컨텍스트 비용
7. 확장성: 후크·프리셋·인티그레이션
8. 강제 메커니즘: 게이트와 “Iron Law”
9. 어느 쪽을 골라야 하나
10. 결론

1. 왜 이 둘을 같이 보나

코딩 에이전트가 한 줄 입력만 받고도 코드를 쏟아내는 시대에, “바이브 코딩(vibe coding)”을 어떻게 막을지가 새로운 도구의 주제가 됐습니다. 두 프로젝트는 같은 문제를 정확히 반대 방향에서 풉니다.

• GitHub spec-kit은 명세 자체를 산출물로 만듭니다. .specify/ 디렉토리에 헌법(constitution), 스펙, 플랜, 태스크, 체크리스트가 파일로 남고 git에 커밋됩니다. 코드는 그 명세의 “마지막 마일” 결과물입니다.
• superpowers는 에이전트의 규율 자체를 도구로 만듭니다. 산출물은 디자인 문서 한 장과 플랜 한 장 정도로 가볍고, 대신 brainstorming · TDD · systematic-debugging 같은 스킬 프롬프트가 작업 단계마다 호출됩니다.

둘 다 “Claude Code(또는 다른 에이전트)에게 프로세스를 입히는” 도구지만, 그 프로세스가 어디에 거주하는지가 다릅니다. 한 쪽은 레포 안에, 다른 쪽은 에이전트의 도구 호출 시점에.

2. 한 문장 요약

spec-kit은 spec-as-artifact 를, superpowers는 discipline-as-tool 을 제공합니다.

이 한 문장이 나머지 차이를 전부 설명합니다.

3. 배포 모델: CLI냐 플러그인이냐

spec-kit — 외부 Python CLI

spec-kit은 uv tool install 로 설치하는 specify라는 Python CLI입니다. 프로젝트 루트에서 specify init my-project --integration copilot 같은 명령으로 시작하고, 다음을 프로젝트 디렉토리에 풀어 둡니다.

my-project/
├── .claude/commands/        # 슬래시 명령 파일 (claude 통합 시)
├── .specify/
│   ├── memory/constitution.md
│   ├── templates/
│   └── extensions.yml       # 사용자 정의 후크
└── specs/
    └── 001-user-auth/
        ├── spec.md
        ├── plan.md
        ├── tasks.md
        ├── research.md
        ├── data-model.md
        ├── contracts/
        ├── quickstart.md
        └── checklists/

소스 트리(src/specify_cli/)에는 워크플로우 엔진(workflows/engine.py), 인티그레이션 카탈로그(integrations/), 프리셋(presets/), 익스텐션(extensions.py) 같은 본격적인 모듈이 들어 있습니다. 즉 spec-kit은 프로젝트 안에 거주하는 메타-프레임워크 입니다.

superpowers — Claude Code 플러그인

superpowers는 마켓플레이스에서 설치되는 Claude Code 플러그인입니다. 설치 위치는 사용자 홈입니다.

~/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/
├── skills/
│   ├── brainstorming/SKILL.md
│   ├── writing-plans/SKILL.md
│   ├── executing-plans/SKILL.md
│   ├── test-driven-development/SKILL.md
│   ├── systematic-debugging/SKILL.md
│   ├── subagent-driven-development/SKILL.md
│   ├── verification-before-completion/SKILL.md
│   └── ... (총 14개)
├── commands/
│   ├── brainstorm.md
│   ├── write-plan.md
│   └── execute-plan.md
├── hooks/session-start
└── agents/

프로젝트 디렉토리에는 아무것도 설치되지 않습니다. brainstorming 스킬이 디자인 문서를 만들 때만 docs/superpowers/specs/에 마크다운 한 장이 떨어지는 정도입니다. superpowers는 에이전트에 거주하는 메타-스킬 셋 입니다.

4. 워크플로우 매핑

핵심 단계는 거의 1:1로 대응됩니다.

다만 세부 사상 이 다릅니다.

• spec-kit은 명세를 다중 문서로 쪼갭니다. /speckit.plan은 plan.md 하나만이 아니라 research.md(기술 결정 기록), data-model.md(엔티티/관계), contracts/(API 명세), quickstart.md(통합 시나리오)까지 생성합니다. tasks.md에는 사용자 스토리별로 P1/P2/P3 우선순위가 붙어 각 스토리가 독립적으로 MVP 가 되도록 분해됩니다.
• superpowers는 명세를 한 장에 응축합니다. docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 와 docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md 정도. 대신 brainstorming 스킬은 “2-3개 접근법 제안 → 트레이드오프 설명 → 사용자 승인 후에만 다음 단계로”라는 대화 절차 를 강제합니다.

다시 말해 spec-kit은 문서 구조로, superpowers는 대화 구조로 같은 분해를 수행합니다.

5. 산출물 철학: 파일이냐 규율이냐

가장 큰 차이는 “명세가 어디에 사는가”입니다.

spec-kit의 사상: 명세는 git에 산다

spec-driven.md에 정리된 SDD(Spec-Driven Development)의 첫 문장은 직설적입니다.

Spec-Driven Development flips the script on traditional software development. Specifications don't serve code—code serves specifications.

이 문장이 spec-kit의 모든 설계 결정을 끌어냅니다.

• 헌법(constitution) 은 프로젝트 원칙을 영구 파일 로 둡니다. /speckit.plan 의 플랜 템플릿에는 Constitution Check 게이트가 명시되어 있고, “Phase 0 research 전에 통과해야 하며, Phase 1 design 후에 재검토한다”라는 규칙이 박혀 있습니다.
• 명세는 브랜치 기반입니다. 각 피처는 specs/<NNN>-<short-name>/ 디렉토리로 격리되고, git 브랜치 번호와 매칭됩니다(branch_numbering: sequential 또는 timestamp).
• 명세 변경 = 코드 재생성입니다. PRD 한 줄을 바꾸면 영향받는 기술 결정이 자동으로 플래그됩니다. “수정 = 명세 갱신 후 재생성”이 정상 흐름입니다.

이 사상은 산출물 파일 수에서 그대로 드러납니다. 한 피처당:

spec.md  +  plan.md  +  tasks.md  +  research.md
       +  data-model.md  +  contracts/*  +  quickstart.md
       +  checklists/*.md  +  (memory/constitution.md, 공용)

총 8~10개 마크다운이 정상 산출물입니다.

superpowers의 사상: 규율은 에이전트에 산다

superpowers의 핵심 단어는 “gate”와 “iron law”입니다. brainstorming SKILL.md에는 이런 가드가 있습니다.

<HARD-GATE>
Do NOT invoke any implementation skill, write any code,
scaffold any project, or take any implementation action
until you have presented a design and the user has approved it.
</HARD-GATE>

test-driven-development SKILL.md에는 “Iron Law”가 박혀 있습니다.

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

systematic-debugging도 동일합니다.

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

이 강제는 파일이 아니라 프롬프트 안에 살고 있습니다. 한 피처가 끝나도 디스크에는 디자인/플랜 문서 두 장 정도만 남습니다. spec-kit에서 8~10개 파일이 git에 영구히 박히는 것과 정확히 반대입니다.

비유하자면 spec-kit은 감사 가능한 폭포수의 부활 입니다. 모든 결정이 문서로 남고, 변경은 명세를 통해 일어납니다. superpowers는 Test-First와 Root-Cause-First를 신조로 삼는 페어 프로그래머 입니다. 산출물보다 절차의 일관성을 봅니다.

6. 토큰·컨텍스트 비용

이 차이는 토큰 비용에 그대로 반영됩니다.

spec-kit의 비용 구조

spec-kit의 슬래시 명령 파일은 정적 입니다. .claude/commands/ 안에 풀린 명령 마크다운은 사용자가 해당 슬래시 명령을 호출하면 거의 통째로 모델 컨텍스트에 실립니다.

templates/commands/specify.md   341 lines
templates/commands/checklist.md 366 lines
templates/commands/clarify.md   282 lines
templates/commands/analyze.md   252 lines
templates/commands/implement.md 216 lines
templates/commands/plan.md      164 lines
templates/commands/tasks.md     216 lines
templates/commands/constitution.md 150 lines
templates/commands/taskstoissues.md 100 lines
                       총       ≈ 2,087 lines (commands only)

여기에 /speckit.implement 가 시작되면 추가로 다음을 전부 읽어 들입니다.

- tasks.md       (REQUIRED)
- plan.md        (REQUIRED)
- data-model.md  (IF EXISTS)
- contracts/*    (IF EXISTS)
- research.md    (IF EXISTS)
- memory/constitution.md (IF EXISTS)
- quickstart.md  (IF EXISTS)

실제 피처 하나에서 810개 마크다운 파일 합계는 보수적으로 잡아도 **1540KB(약 515K 토큰)** 가 됩니다. 거기에 명령 자체의 200340줄 프롬프트가 더해지죠. 구현 단계가 길어지면 매 턴 재참조되어 누적됩니다.

superpowers의 비용 구조

superpowers는 Claude Code의 Skill 도구로 지연 로딩 합니다. 시스템 프롬프트에 들어가는 것은 짧은 설명 한 줄입니다.

- superpowers:brainstorming: You MUST use this before any creative work...
- superpowers:writing-plans: Use when you have a spec or requirements...
- superpowers:executing-plans: Use when you have a written implementation plan...
...

스킬 본문은 호출될 때만 컨텍스트에 들어옵니다. 본문 라인 수는 적지 않지만(전체 14개 스킬 합 ≈ 3,159 lines), 동시에 모두 로딩되는 일은 없습니다. brainstorming 단계에서는 brainstorming SKILL.md 164줄만, TDD 단계에서는 TDD SKILL.md 371줄만 들어옵니다.

비교

요약: spec-kit은 “모든 결정을 문서로 남기는” 대가로 토큰을 쓰고, superpowers는 “지연 로딩과 짧은 산출물”로 토큰을 아낍니다.

이 차이는 좋고 나쁨이 아니라 목적 의 차이입니다. spec-kit이 비싼 만큼, 그 산출물은 사람도 읽고 PR 리뷰에도 들어갑니다. 팀 단위 합의 도구로 쓸 때 그 비용은 합리적입니다.

7. 확장성: 후크·프리셋·인티그레이션

spec-kit의 확장 지점

spec-kit은 본격적인 확장 시스템을 갖췄습니다.

• .specify/extensions.yml — 각 명령 단계(before_specify, before_plan, before_tasks, before_implement, after_*)에 사용자 정의 후크를 끼울 수 있습니다. 각 명령 템플릿에는 후크 체크 절차가 30~40줄씩 인라인 되어 있습니다(optional vs mandatory 분기, condition 표현식, EXECUTE_COMMAND 출력 형식까지).
• presets/ — lean, scaffold, self-test 같은 사전 정의 구성. 프로젝트 카탈로그(catalog.json)와 커뮤니티 카탈로그(catalog.community.json)가 분리되어 있습니다.
• integrations/ — 30+ 에이전트 통합. 같은 명령 템플릿을 사용하지만 __SPECKIT_COMMAND_PLAN__ 같은 플레이스홀더가 에이전트별로 치환됩니다.
• workflows/ — engine.py, expressions.py, catalog.py로 구성된 워크플로우 엔진. 명령을 단순한 마크다운이 아니라 그래프 로 표현합니다.

플랫폼화에 신경 쓴 흔적이 보입니다. GitHub가 만든 도구답게 다양한 에이전트를 한 워크플로우로 통합 하는 것을 1차 목표로 둡니다.

superpowers의 확장 지점

superpowers는 더 얄팍한 확장만 제공합니다.

• hooks/session-start — 세션 시작 시 “using-superpowers” 스킬 안내를 주입. 이 문서 상단에 보이는 SessionStart hook success: OK 가 그것입니다.
• commands/brainstorm.md, write-plan.md, execute-plan.md — 각 5줄짜리 얇은 슬래시 명령. 실제 로직은 모두 스킬 안에 있습니다.
• agents/ — 서브에이전트 정의(코드 리뷰어 등).
• writing-skills 스킬 — 스킬을 더 쓰기 위한 메타 스킬. 사용자가 자기 프로젝트에 맞는 스킬을 추가할 수 있습니다.

superpowers는 “플랫폼”이 아니라 “규율 모음”입니다. 확장은 사용자 측 스킬 추가 또는 Claude Code 설정으로 해결합니다.

8. 강제 메커니즘: 게이트와 “Iron Law”

두 프로젝트 모두 LLM이 절차를 건너뛰지 못하게 막는 장치 를 명시적으로 둡니다. 하지만 메커니즘이 다릅니다.

spec-kit — 게이트는 템플릿에 박힌다

• 플랜 템플릿의 Constitution Check 섹션: “GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.”
• 구현 명령은 시작 전에 체크리스트 통과 여부 를 강제합니다. 불완전한 체크리스트가 있으면 “proceed with implementation anyway? (yes/no)”를 묻고 사용자 응답을 기다립니다.
• 명령 사이 이동은 handoffs 메타데이터로 명시됩니다. /speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement 가 “send: true” 핸드오프로 연결됩니다.

게이트가 문서의 구조 자체 입니다. 모델이 무시하기 어렵습니다.

superpowers — 게이트는 자연어로 박힌다

• <HARD-GATE> 태그가 brainstorming 스킬 머리에 박혀 있습니다.
• Iron Law 라는 이름의 절대 규칙이 TDD와 systematic-debugging 스킬에 있습니다.
• “Violating the letter of the rules is violating the spirit of the rules.” 같은 문장이 반복됩니다.
• using-superpowers 스킬은 “1% 가능성만 있어도 스킬을 호출하라”는 강한 명령으로 시작합니다.

게이트가 프롬프트의 수사 입니다. 모델이 도구 호출 시점에 그 수사를 읽고 따릅니다.

즉 spec-kit은 컴파일러처럼, superpowers는 코치처럼 작동합니다. 전자는 형식이 맞지 않으면 다음 단계로 못 가고, 후자는 “이건 이렇게 하셔야 합니다”를 매번 다시 말합니다.

9. 어느 쪽을 골라야 하나

겹치는 영역이 크기 때문에 둘 다 풀로 켜는 것은 권장하지 않습니다. 두 시스템 모두 “프로세스를 통제하는 메타 레이어”라 같이 켜면 어느 쪽 규율을 따를지 모델이 흔들립니다. 보완재가 아니라 대체재 에 가깝습니다.

spec-kit이 더 맞는 경우

• 팀 단위 작업, 리뷰 가능한 명세가 필요한 경우. 산출물 자체가 PR/감사 산출물입니다.
• 요구 변경이 잦고, 변경의 추적성이 중요한 경우. 명세 변경 = 코드 재생성이라는 사상이 자연스럽게 맞습니다.
• 여러 에이전트(Claude/Copilot/Cursor)를 같은 워크플로우로 묶어야 하는 경우. 인티그레이션 카탈로그가 강점입니다.
• 사용자 스토리 P1/P2/P3 분해, MVP 우선 개발 같은 제품 개발 패턴을 강제하고 싶을 때.

superpowers가 더 맞는 경우

• 1인 또는 소수 작업, 산출물보다 절차 일관성이 중요한 경우.
• TDD/근본 원인 분석 같은 규율을 LLM에게 강제하고 싶은 경우. Iron Law 패턴이 직접적입니다.
• 토큰 비용에 민감한 경우. 지연 로딩으로 베이스라인이 거의 0입니다.
• Claude Code/Codex/Gemini CLI 등 Skill 호환 환경에서 가볍게 시작하고 싶을 때.

절충안: spec-kit으로 문서를, superpowers로 구현을

실험적으로 가능한 조합은 이런 형태입니다.

• /speckit.specify + /speckit.plan 까지만 사용해서 리뷰용 문서 를 생성.
• 실제 구현은 /speckit.implement 대신 superpowers의 test-driven-development · systematic-debugging · verification-before-completion를 전술적으로 사용.

단, /speckit.implement 와 superpowers의 executing-plans/subagent-driven-development 를 동시에 켜는 것은 피하세요. 둘 다 “구현 전체 흐름을 통제”하는 스킬이라 충돌합니다.

10. 결론

spec-kit과 superpowers는 “코딩 에이전트에 어떻게 규율을 입힐 것인가”라는 같은 질문에 대해, 명세를 산출물로 만들 것이냐(spec-kit) vs 규율을 도구로 만들 것이냐(superpowers) 라는 두 가지 답을 내놓습니다.

• spec-kit은 명세 = 진실의 원천 이라는 SDD 철학을 파일 시스템과 워크플로우 엔진으로 구현합니다. 산출물이 풍부한 만큼 토큰과 디스크 비용이 큽니다.
• superpowers는 규율 = 도구 호출 시점의 프롬프트 라는 사상으로 Iron Law와 HARD-GATE를 직접 LLM에 박습니다. 산출물이 가벼운 만큼 토큰 비용이 낮고, 1인 워크플로우에 더 맞습니다.

선택의 기준은 “팀에서 명세를 함께 보고 싶은가, 혼자서 규율 있는 에이전트를 갖고 싶은가”에 가깝습니다. 그리고 둘을 섞는다면, 서로의 핵심 단계(구현 통제)를 동시에 켜지 않기 가 가장 중요한 규칙입니다.