GSD — AI의 지능을 100% 활용하는 값비싼 방법

TL;DR

• GSD(gsd-build/get-shit-done)는 TÂCHES(본명 Lex Christopherson)가 만든 Claude Code류 메타프레임워크다 — 단일 스킬 묶음이 아니라 컨텍스트 환경 자체에 의견을 가진 spec-driven 사이클. 2026-05-13 시점 (v1.41.0 stable + v1.42.0-rc3 canary): 61.9k★, 시스템 프롬프트의 eager skill listing 기준 약 86 entry(슬래시 + 스킬 합산, commands/gsd/ 디렉토리는 약 70개 슬래시 + 6개 namespace router로 구성), 31개 에이전트(docs/INVENTORY.md 기준), 11개 훅, 15개 런타임. 2025-12 출시.
• 메커니즘 한 줄: 각 phase가 자기 fresh 200k 컨텍스트로 시작한다. discuss · plan · execute · verify · ship 다섯 단계가 각자 신선한 클로드를 부르고, 메인 세션은 30–40%에 머문 채 dispatcher 역할만 한다.
• 이 디자인의 비용: 토큰을 선형으로 더 쓴다. Claude Max $200 plan 사용자가 40분 만에 5시간 윈도우를 소진했다는 GitHub 이슈가 closed로 남아있고, 메인테이너는 "4 agents ≈ 4× tokens, 이건 의도된 trade-off"라고 답한다. peak 지능을 매번 받는 대가가 peak 토큰 비용이다.
• 단독으로 쓰면 마라톤·multi-file·multi-session 작업에 강하다. Superpowers·gstack과 섞으면 §6의 5가지 충돌 표면 — 특히 SessionStart 훅 3중 주입과 GSD subagent가 Superpowers HARD-GATE를 우회하는 지점 — 에서 부딪친다.

1. GSD 소개

1.1. 무엇인가

gsd-build/get-shit-done — TÂCHES가 만든 Claude Code류 spec-driven development 메타프레임워크. README는 자신을 "A light-weight meta-prompting, context engineering, and spec-driven development system"이라 소개하지만, 실제 본체는 컨텍스트 윈도우 품질 저하(context rot)를 환경 분리로 푸는 사이클이다.

핵심 약속은 README 한 줄에 압축돼 있다:

"Each executor gets a fresh 200k-token context. Each task gets its own atomic commit. Walk away, come back to completed work with a clean git history. … Your main context window stays at 30–40%. The work happens in the subagents." — README

이 두 문장이 GSD의 정체성 전부다. 작업은 메인 컨텍스트에서 일어나지 않는다. 메인은 dispatcher고, 실제 일은 매번 새로 뜨는 200k 컨텍스트 서브에이전트가 한다. 한 phase가 끝나면 그 서브에이전트는 disk에 markdown state를 남기고 종료. 다음 phase의 서브에이전트는 그 markdown을 읽고 깨끗한 200k로 다시 시작.

이 메커니즘이 왜 의미 있는지는 GSD가 self-identify하는 문제에서 나온다 — context rot. Medium/Mak가 community testing 결과를 정리한 임계점은 50% 컨텍스트 사용을 지나면 품질이 떨어지고, 70%를 지나면 hallucination이 spike한다는 것(원문: "Community testing shows quality drops past 50% context usage. Past 70%, hallucinations spike.").

GSD는 "메인 세션이 절대 그 임계점을 못 넘게" 강제하는 방식으로 그 문제를 푼다. discuss·plan·execute·verify·ship 다섯 단계 boundary가 매번 컨텍스트를 비우고 새로 시작하는 강제 종결점.

1.2. 창시자 — "솔로 개발자가 코드를 안 쓰는 방식"

GSD를 이해하려면 창시자 self-description을 빼놓을 수 없다. README "Why I Built This"에 verbatim:

"I'm a solo developer. I don't write code — Claude Code does. … Other spec-driven tools exist, but they're all built for 50-person engineering orgs — sprint ceremonies, story points, stakeholder syncs, Jira workflows. I'm not that. I'm a creative person trying to build great things consistently. … The complexity is in the system, not in your workflow." — TÂCHES

GSD의 타겟 페르소나는 enterprise spec-driven tool(BMAD, SpecKit, Taskmaster 등)의 ceremony가 부담스러운 솔로 개발자다. SAFe·Scrum 의례 없이 spec → phase → execute만 남겨두고, 복잡성은 시스템 안에 격리.

GSD 글에서 흔히 누락되는 한 가지: GSD는 실제로는 1인 프로젝트가 아니다. 2026-05-13 시점 컨트리뷰터 136명, 누적 커밋 2,593건. 실제 메인테이너 활동은 trek-e(1,124커밋)와 glittercowboy(=TÂCHES, 945커밋)이 양분하고 있고, 사용자 이슈에 답변하는 maintainer 페르소나도 trek-e다. "솔로 개발자" 라는 마케팅은 창업자 self-image이지 거버넌스 사실이 아니다. 글의 신뢰성을 위해 짚어둘 부분.

1.3. 장점

• context rot를 환경 레벨에서 푼다. Superpowers는 프로세스 디시플린, gstack은 역할 페르소나로 푸는데, GSD는 컨텍스트 윈도우 자체를 갈아 끼운다. "다른 둘은 workflow를 바꾸고, GSD는 workenvironment를 바꾼다"가 시리즈 카테고리 분류의 한 줄.
• TypeScript SDK가 점차 본체로 올라오고 있다 — 단 timeline은 정직히 짚어야 한다. README는 "메타-프롬프팅 시스템"이라고 부르지만 sdk/src/phase-runner.ts(50KB) 같은 TS 코드가 점진적으로 핵심 동작을 가져갔다. SDK는 v1.30(2026-03-26)에 도입됐지만, v1.38.4(2026-04-25) 전까지는 SDK가 stripped 복사본(~17% 분량)을 들고 있어 실제 영향이 제한적이었다. npm @gsd-build/sdk@latest는 현재도 v0.1.0에 머문 채 parent tarball에 bundled 되어 있어 외부 단독 import는 불가(Issue #3406). 그 caveat 위에서, 컨텍스트 클리어·git branch 관리·token tracking·stuck loop detection을 프로그래밍 레벨에서 통제한다는 점이 같은 카테고리 다른 둘(markdown prompt 본체)과의 구현 차이.
• 15개 런타임 지원 — 셋 중 가장 넓다. Claude Code, Codex, Copilot CLI, Cursor, Windsurf, Augment, Gemini CLI, OpenCode, Kilo, Antigravity, Trae, Qwen Code, Cline, CodeBuddy, Hermes. install.js의 --all 플래그 하나로 다 깔린다.
• Atomic commit per task. 같은 wave 안에서 여러 executor가 병렬로 돌아도 task마다 자기 atomic commit. 실패하면 그 commit만 revert 가능. git history가 phase 시퀀스 그대로 남음.
• Defense in Depth. plan-checker agent가 plan을 사전 검증 → executor가 atomic commit → 사후 verifier가 phase 목표 대비 검증 → UAT (human verification) 가 최종 게이트. 한 단계 fail이 다음 단계로 못 새도록.

1.4. 설치

# Claude Code 단독
npx get-shit-done-cc --claude

# Claude Code + minimal (system prompt overhead 94% 감소)
npx get-shit-done-cc --claude --minimal

# 모든 지원 런타임에 설치
npx get-shit-done-cc --all

설치 후 ~/.claude/get-shit-done/에 핵심 자산이 풀리고, 슬래시 명령은 ~/.claude/commands/gsd/에 마운트된다. 첫 사용은 /gsd-new-project로 프로젝트 초기화 → /gsd-discuss-phase 1 → /gsd-plan-phase 1 → /gsd-execute-phase 1 순서.

런타임 권고는 README에 박혀있다:

claude --dangerously-skip-permissions

"GSD is built for frictionless automation. Skip-permissions is how it's intended to run." — README

permission prompt마다 멈추면 phase parallel execution이 의미가 없어지기 때문. 단 프로덕션 코드에 그대로 적용은 위험하다는 caveat는 GSD docs에도 명시.

2. 작동 구조 — phase boundary와 fresh context의 결합

2.1. 5개의 디자인 원칙 (ARCHITECTURE.md)

GSD가 왜 그렇게 동작하는지는 docs/ARCHITECTURE.md의 Design Principles 섹션에 다 들어있다 — 헤더 자체는 숫자 없이 Design Principles라고만 박혀있고, 본문에 5개가 차례로 나열된다. 인용:

1. Fresh Context Per Agent — "Every agent spawned by an orchestrator gets a clean context window (up to 200K tokens). This eliminates context rot — the quality degradation that happens as an AI fills its context window with accumulated conversation."
2. Thin Orchestrators — "Workflow files (get-shit-done/workflows/*.md) never do heavy lifting."
3. File-Based State — "All state lives in .planning/ as human-readable Markdown and JSON. No database, no server, no external dependencies."
4. Absent = Enabled — workflow feature flag가 없는 게 켜진 상태. 명시적 비활성화만 비활성화.
5. Defense in Depth — "Plans are verified before execution (plan-checker agent). Execution produces atomic commits per task. Post-execution verification checks against phase goals. UAT provides human verification as final gate."

이 다섯 원칙이 합쳐져 사이클을 만든다. 1·2가 왜 작업이 메인에서 안 일어나는지를, 3이 어떻게 phase 간 정보를 넘기는지를, 4가 왜 설정 부담이 적은지를, 5가 왜 quality gate가 박혀있는지를 설명.

2.2. 핵심 루프 — discuss · plan · execute · verify · ship

README의 핵심 루프:

/gsd-new-project          # 1. Initialize: Questions → research → requirements → roadmap
/gsd-discuss-phase 1      # 2. Discuss: capture decisions before plan
/gsd-plan-phase 1         # 3. Plan: research → plan → verify loop
/gsd-execute-phase 1      # 4. Execute: parallel waves, atomic commits per task
/gsd-verify-work 1        # 5. Verify: walk through, diagnose fixes
/gsd-ship 1               # 6. Ship → /gsd-complete-milestone → /gsd-new-milestone

각 단계가 다른 서브에이전트 인스턴스다. 메인 세션은 그 인스턴스들을 dispatch만 한다.

Wave 실행 — /gsd-execute-phase의 핵심. docs/USER-GUIDE.md의 wave 비주얼:

Wave 1 (parallel):
  [Executor A] → 01-01-PLAN.md (core function)  ✓ committed
  [Executor B] → 01-02-PLAN.md (middleware)      ✓ committed

[Verifier] Checking codebase against phase goals...
  REQ-001 validateSignature() ✓
  REQ-002 timing-safe compare ✓
  REQ-003 tolerance window    ✓

같은 wave 안 multiple executor가 진짜 병렬로 돌아간다. docs/ARCHITECTURE.md에 따르면 parallel commit safety는 두 메커니즘으로 보장:

"--no-verify commits — Parallel agents skip pre-commit hooks (which can cause build lock contention, e.g., cargo lock fights in Rust projects). STATE.md file locking — All writeStateMd() calls use lockfile-based mutual exclusion (STATE.md.lock with O_EXCL atomic creation)."

즉 GSD subagent는 사용자 프로젝트의 pre-commit hook을 의도적으로 건너뛴다(--no-verify). 정적 분석·테스트 자동화·conventional commit lint 같은 standard 도구를 운영 중이면 이 점을 의식해야 한다 — GSD 위에서 그 검증은 executor 안에서 자체적으로 처리되어야 하고, 외부 git hook은 무력화된다.

2.3. .planning/ 디렉토리 — file-based state

GSD가 데이터베이스도 서버도 안 쓰는 이유는 phase boundary 때문이다. 한 phase의 executor가 사라져도 .planning/에 남긴 markdown만 있으면 다음 phase가 이어받을 수 있어야 한다. 핵심 파일:

phase 보더 = state 작성 = 다음 boot. 모든 정보가 disk에 있으니 crash recovery가 자연스럽게 된다. (v2에서 SQLite + DB-authoritative state로 바뀌었지만 v1 main 라인은 여전히 markdown 기반.)

2.4. 6개 namespace meta-skills (v1.40에서 도입된 cost lever)

86개 슬래시 명령을 그대로 system prompt에 노출하면 cold-start overhead가 ~2,150 tokens. v1.40부터 6개 namespace router로 묶고 그 router의 description만 노출:

"Six namespace routers ship as the first-stage entry points in v1.40. They keep the eager skill-listing token cost low (~120 tokens for 6 routers vs ~2,150 for a flat 86-skill listing)." — docs/COMMANDS.md

86 → 6 = 약 94% cold-start cost 감소. 그래도 phase 실행 시 각 executor가 fresh 200k를 새로 잡는 본체 비용은 변하지 않는다. 이건 router-level optimization이지 execution cost는 아니다.

2.5. --minimal install — 시스템 프롬프트 추가 lever

--minimal (또는 --core-only) 플래그는 core skill만 깐다. CHANGELOG v1.41.0:

"Cuts cold-start system-prompt overhead from ~12k tokens to ~700, useful for local LLMs with 32K–128K context (Sonnet 4.6 / Opus 4.7 don't need it)."

≈ 94% 감소 (12k → 700). namespace meta-skills와 결합하면 cold-start 토큰만으로는 GSD가 가벼워질 수 있다 — 단 실행 비용은 여전히 fresh-context 모델 본체에 따라 결정됨.

3. 토큰 비용 — "값비싸다"는 부분의 정직한 펼침

GSD 글에서 가장 흔히 빠지는 부분이 토큰 비용이다. README는 "메인이 30–40%에 머문다"만 강조하지만, 사용자 보고는 그 30%가 5–10× 곱해질 수 있다고 말한다.

3.1. README의 주장

"Your main context window stays at 30–40%. The work happens in the subagents." — README

이 문장만 보면 cost가 줄어드는 것 같지만, "work happens in the subagents" 부분이 핵심. 메인은 30%지만 서브에이전트 N개가 각자 200k를 잡는다. 총 토큰 사용량은 메인 + N × fresh.

3.2. 실제 사용자 보고 — Issue #1553

"GSD burns through my $200 Max Claude token allocation in minutes. A few actions with ~10% of work completed and my 5-hour usage window is done. I can't code more than 40 minutes if I use parallel instances or multiple agents." — Issue #1553

이슈는 status: blocked + upstream-bug 라벨로 closed. 메인테이너 trek-e의 답변 (verbatim):

"GSD's core design — fresh context per agent — is a deliberate tradeoff. Each subagent gets a clean 200K context window. This prevents context rot (quality degradation as context fills up) but means: — The orchestrator holds context while waiting for agents — Each agent loads relevant planning artifacts independently — Parallel agents multiply this linearly (4 agents ≈ 4× tokens) — Cache reads are the hidden cost — they're billed differently than input tokens but still count against your quota

This is how the system works. The quality consistency you get from fresh-context agents comes at a token cost."

즉 "40분에 Max plan 소진"은 버그가 아니라 디자인이다. fresh-context의 정직한 표 가격. "AI의 지능을 100% 활용한다 = 매번 비용을 새로 지불한다" 는 제목의 값비싼 부분이 여기서 사실로 굳어진다 — peak 지능을 한 번만 받는 게 아니라 매 phase마다 새로 받는 구조이므로, 비용도 매 phase마다 새로 청구된다.

3.3. 사용자 보고된 overhead 비율

• DEV/Kazmi: "4:1 token overhead ratio (reported by one user)." — Pro plan ($20/mo) "insufficient for regular GSD". Max plan ($100–200/mo) 권장.
• maintainer trek-e (Issue #1553): "4 agents ≈ 4× tokens. Cache reads are the hidden cost."
• USER-GUIDE: "Too many MCPs can reduce your effective window from 200K to ~70K." — MCP 서버가 깔려있으면 effective context가 줄어들어 토큰 cost는 더 무거워짐.
• ARCHITECTURE.md: "Heavyweight MCP servers (browser/playwright, Mac-tools, Windows-tools) can each cost 20k+ tokens per turn — often dwarfing what model_profile tuning saves."

이 모든 숫자를 합치면 GSD는 Claude Pro ($20)에서는 잘 안 돌고, Max ($100~200)에서도 사용량을 의식해야 하는 프레임이다. 외부 분석들이 다음을 권장하는 이유:

3.4. 완화 레버 — GSD가 자체 제공하는 cost 통제

1. --minimal install — 12k → 700 tokens cold-start (94% 감소).
2. 6개 namespace meta-skills — 2,150 → 120 tokens system prompt (94% 감소).
3. model_profile — quality(전부 Opus), balanced(plan Opus + execute Sonnet), budget(plan Sonnet + execute Sonnet + verify Haiku). README는 "/gsd:set-profile budget — This is the single biggest lever"라고 명시.
4. /gsd-health --context — 60% utilization warns, 70% critical. 메인 세션이 임계점 넘기 전에 /gsd-thread 새로 띄우라고 신호.
5. MCP 서버 disable — 안 쓰는 MCP 끄면 turn당 20k+ tokens 절약.
6. /gsd-fast / /gsd-quick — planning 단계 스킵. trivial task에 full cycle을 강제하지 않음.

요약: GSD는 본체 cost가 무거운 게 사실이고, 이 lever들이 그것을 작게는 90% 가깝게 깎을 수 있다. 다만 fresh-context per subagent라는 핵심 메커니즘 자체의 비용은 깎을 수 없다 — 그건 GSD의 정체성이다.

3.5. 한 줄 verdict

값비싼 hook을 정직하게 닫자면:

• Claude Pro($20/mo): GSD full cycle은 구조적으로 안 돈다. 시작하지 마라. /gsd-quick 또는 GSD 없이가 정답.
• Claude Max($100~200/mo): 같은 5시간 윈도우 안에서 worst case는 ~40분(full parallel wave + 무절제 — Issue #1553), typical은 2~3시간(절제된 wave, model_profile=budget, --minimal), sustained 페이스는 하루 1프로젝트 한계선. 세 horizon은 같은 사용자가 어떻게 절제하느냐에 따라 갈리는 한 envelope의 다른 면.
• API 직결 (token-based pricing, 무제한): 토큰 비용이 곧 dollar로 흐르므로 작업 단위로 비용을 측정할 수 있는 환경. 마라톤 프로젝트에서 시간 절약 vs 토큰 청구서의 트레이드오프를 명시적으로 평가해야 한다.

trek-e가 Issue #1553에서 답한 한 줄이 본체다 — "This is how the system works. The quality consistency you get from fresh-context agents comes at a token cost." 컨텍스트 윈도우가 차오를 때마다 "아 까먹었네"가 나오던 사람에게, GSD는 그 말을 안 듣기 시작하는 값비싼 방법을 판다. 그 값을 매번 새로 지불할 수 있는 사용자에게만 정확히 맞는 도구다.

4. 슬래시 카탈로그

commands/gsd/ 디렉토리에 약 66개 슬래시 .md 파일 + 6 namespace router가 있다. 시스템 프롬프트의 eager skill listing은 commands + skills + agents description을 모두 합쳐 ~86 entries (CHANGELOG v1.41.0 기준). 핵심 6 + 자주 쓰이는 6 정도만 본문에 다룬다.

런타임별 표기 차이 (docs/COMMANDS.md):

"Claude Code / Copilot / OpenCode / Kilo: /gsd-command-name [args] (hyphen). Gemini CLI: /gsd:command-name [args] (colon). Codex: $gsd-command-name [args]. The hyphen and colon forms are runtime-specific spellings of the same command."

GSD가 셋 중 유일하게 모든 슬래시를 /gsd- 접두사로 격리한다. 같은 시스템에 Superpowers·gstack 깔아도 슬래시 이름은 안 부딪힌다. 이 점은 §6에서 결합 시 큰 이점.

가장 많이 쓰는 6개 명령

새 프로젝트라면 한 사이클을 모두 거치게 되는 핵심들.

/gsd-new-project

프로젝트 초기화. 사용자에게 questions를 던지고 답을 모아 PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, config.json을 생성. --auto @file.md 플래그로 기존 문서에서 추출해 questions 스킵 가능. 한 번만 돈다.

/gsd-discuss-phase [N]

phase 시작 전 결정을 명시화하는 단계. README: "capture decisions before plan". 사용자가 플랜 안 만들고 곧장 코드 짜기 시작하면 GSD는 어떤 결정이 결정되지 않은 채 묻혀있는지를 못 잡는다. discuss는 그 결정들을 CONTEXT.md에 명시적으로 저장. 플래그: --all, --auto, --batch, --analyze, --power, --assumptions.

/gsd-plan-phase [N]

research + plan + verify loop. PLAN.md 생성. 한 plan은 2–3 tasks 최대가 권장 (USER-GUIDE: "Plans should have 2–3 tasks maximum. If tasks are too large, they exceed what a single context window can produce reliably."). 큰 plan은 phase 분할로 푼다. v1.51 추가 — Package Legitimacy Gate: researcher가 external package 추천하면 slopcheck install <pkg> --json을 돌려 slopsquatting(LLM이 만들어낸 가짜 패키지) 방어.

/gsd-execute-phase <N>

phase의 모든 plan을 parallel wave로 실행. 같은 wave 안에서 multiple executor 병렬, atomic commit per task, --no-verify로 commit (pre-commit hook 우회). 플래그: --wave N, --validate, --cross-ai(다른 LLM에 cross-check), --no-cross-ai. 여기서 토큰 cost가 가장 무겁다 — Issue #1553의 "Max plan 40분 소진"이 바로 이 명령에서 일어난다.

/gsd-verify-work [N]

실행된 작업을 phase 목표에 대해 검증. VERIFICATION.md 생성. 발견된 결함은 diagnosed fix plan으로 정리 — 다음 plan-phase로 자연스럽게 넘어감.

/gsd-ship [N]

phase 결과를 PR로 만든다. auto-generated PR body에 SUMMARY.md + VERIFICATION.md + UAT.md 합쳐서. --draft로 draft PR 생성 가능. ship 후 /gsd-complete-milestone → /gsd-new-milestone로 다음 milestone 시작.

빠른 경로 — /gsd-quick, /gsd-fast

Issue #2251에서 거론된 "GSD가 너무 무겁다" 비판에 대한 GSD 자체 답변:

• /gsd-quick — minimal workflow. discuss/plan/execute/verify/ship 사이클 없이 1 phase로 압축.
• /gsd-fast — planning 단계 완전 스킵. trivial task를 inline으로 실행.

색 변경, typo 수정, README 문장 한 줄 다듬기 같은 작업은 전체 사이클을 돌리지 말고 이 두 명령으로 가야 한다. 모르고 /gsd-plan-phase로 시작하면 토큰 4×~10× 더 쓴다.

5. v1 → v2 — Markdown 프레임에서 TypeScript 애플리케이션으로

GSD를 한 시점만 보면 놓치는 진화축이 있다. v1은 markdown prompt 묶음이었고, v2는 TypeScript application이다.

5.1. v1 안에서 점진적 SDK 진화 (CHANGELOG 분석)

gsd-build/get-shit-done(=v1 라인) 안에서 SDK가 점점 본체가 되어가는 timeline:

v1 라인은 markdown 프롬프트 + TypeScript SDK가 공존하는 hybrid. SDK가 점점 두께를 늘려가지만 최종 사용자 표면은 여전히 슬래시 명령. 핵심 SDK 코드 위치:

sdk/src/phase-runner.ts      (50 KB)  ← 핵심 phase orchestration
sdk/src/init-runner.ts       (26 KB)
sdk/src/cli.ts               (20 KB)
sdk/src/event-stream.ts      (14 KB)  ← telemetry
sdk/src/plan-parser.ts       (15 KB)
sdk/src/context-engine.ts    (6.5 KB)
sdk/src/context-truncation.ts (7 KB)

5.2. v2 — 별도 repo gsd-build/gsd-2

진짜 v2는 같은 organization의 별도 repo다 — gsd-build/gsd-2. 7.4k★, v2.82.0 (2026-05-10), TypeScript 95.0%, MIT.

v1 → v2 차이 (gsd-2 README 정리):

v2 본체는 SQLite로 DB-authoritative state를 잡고, .gsd/ markdown은 projection에 불과. v2 Context Mode는 sandboxed gsd_exec, gsd_exec_search, gsd_resume으로 "40–60% token reduction"을 주장한다 (claim, 외부 검증 없음). 24개 bundled MCP extensions + 20+ LLM provider 지원.

v2 README의 한 줄이 GSD의 정체성을 가장 압축한다:

"The iron rule: a task must fit in one context window."

5.3. 진화의 시사점

v1에서 프롬프트로 LLM에게 부탁하던 일이 v2에서 TypeScript 코드로 LLM을 강제하는 일로 옮겨갔다. 이는 같은 카테고리의 다른 둘과 결정적 차이:

• Superpowers = 여전히 markdown 프롬프트 묶음. using-superpowers/SKILL.md가 "You MUST"로 강제하지만, LLM이 어기면 그만이다.
• gstack = markdown slash commands. 각 명령이 페르소나 instructions를 들고 있지만, 본질은 프롬프트 가이드.
• GSD v1 = markdown + TypeScript SDK 혼합. SDK가 context를 직접 clear하고 git branch를 직접 manage한다. LLM이 어기면 SDK가 잡는다.
• GSD v2 = TypeScript application. LLM은 worker고, SDK가 manager.

이 점이 GSD가 셋 중에 engineering investment가 가장 두꺼운 이유. 카테고리 내 implementation 차이가 가장 크다.

6. Superpowers·gstack과 같이 쓸 때 어디서 깨지는지

아래는 셋을 동시에 깔아 직접 겪은 관찰이 아니라, 각자의 SessionStart 훅·README·정의 파일·공식 이슈를 읽고 충돌이 구조적으로 필연인 지점만 짚은 것이다.

세 메타프레임을 한 머신에 동시 설치할 때 5가지 충돌 표면이 있다. 어느 것은 직접적 기술 충돌, 어느 것은 디자인 mismatch.

6.1. SessionStart 훅 — 3중 부트스트랩 주입

셋 다 SessionStart 훅을 박는다. Claude Code 공식 매뉴얼:

"All matching hooks run in parallel, and identical handlers are deduplicated automatically. Command hooks are deduplicated by command string and args."

→ 셋이 서로 다른 명령으로 SessionStart에 등록되므로 세 부트스트랩이 모두 컨텍스트에 주입된다. 순서는 비결정. Superpowers의 <EXTREMELY_IMPORTANT> 블록 + gstack의 auto-update 배너 + GSD의 gsd-update-banner.js가 동시에 들어가고, 어느 게 먼저 들어갔는지가 그 세션의 행동을 결정한다.

추가 변수: Claude Code 자체에 Issue #19491이 closed로 남아있다 — "SessionStart hooks are checked and executed before plugins with those hooks are fully loaded, resulting in a 'startup hook error' message at session start." 단일 Superpowers만 깔아도 첫 세션에 훅이 안 돈 사례가 공식 이슈. 다중 프레임 환경은 더 비결정적.

대응: 세 부트스트랩을 한 환경에서 동시 돌리지 않는다 — 메인 프레임 하나 정하고 나머지는 프로젝트 단위 .claude/settings.local.json에서 옵트인하는 식이 안전. 또는 한 번에 하나만.

6.2. 슬래시 이름 — GSD만 회피, gstack은 top-level

/review나 /ship 같은 이름은 gstack이 점유. GSD는 /gsd-review, /gsd-ship으로 격리. Superpowers는 슬래시 명령이 사실상 없다 (/brainstorm, /execute-plan 같은 레거시 슬래시가 v5.1.0에서 제거되어 Skill 자가 호출이 기본 경로). 직접적 슬래시 이름 충돌은 거의 없다. GSD의 접두사 디시플린 덕.

6.3. CLAUDE.md 침투 — gstack만 사용자 정책 파일 수정

gstack README는 사용자의 CLAUDE.md에 직접 섹션을 추가하라고 지시:

"Install gstack: … then add a 'gstack' section to CLAUDE.md that says to use the /browse skill from gstack for all web browsing, never use mcp__claude-in-chrome__* tools, …"

반면 GSD는 CLAUDE.md를 자동 수정하지 않는다 — 권고만. Superpowers는 플러그인 자체의 CLAUDE.md에 instruction을 두고, 사용자 CLAUDE.md는 안 건드린다.

결과: gstack의 지시가 사용자 컨텍스트에 가장 stickily 박힌다. 셋이 같이 깔리면 gstack 정책이 프로젝트 모든 세션에 영구적으로 가시화되고, GSD/Superpowers의 부트스트랩은 세션 시작 때만 주입된다. 사용자 의도와 다른 우선순위가 생긴다.

대응: gstack을 깔면 사용자가 직접 그 섹션을 검수. ~/.claude/CLAUDE.md global보다 project-level .claude/CLAUDE.md에 두는 게 격리에 좋다.

6.4. GSD subagent fresh context — Superpowers HARD-GATE 우회

GSD의 정체성 자체가 Superpowers의 가장 핵심 메커니즘을 우회한다.

Superpowers의 brainstorming/SKILL.md는 "Every project goes through this process. A todo list, a single-function utility, a config change — all of them"이라고 못 박는다. SessionStart 부트스트랩으로 주입되는 using-superpowers 메시지가 "1% 룰"과 함께 이 HARD-GATE를 매번 깐다.

그러나 GSD가 /gsd-execute-phase로 dispatch한 executor는 fresh 200k 컨텍스트로 시작한다 — 메인 세션의 부트스트랩은 서브에이전트에 전달되지 않는다. 즉:

• 메인 세션에서는 Superpowers HARD-GATE가 작동 → 사용자 발화에 brainstorming 트리거
• 그러나 GSD가 dispatch한 executor 안에서는 Superpowers 부트스트랩이 없음 → HARD-GATE 비활성
• executor는 GSD의 PLAN.md를 받아서 그대로 코드를 쓴다 — Superpowers의 "브레인스토밍 없이는 implementation 금지" 룰을 안 본다

이건 버그가 아니라 디자인 충돌이다. GSD의 fresh-context = Superpowers HARD-GATE의 out-of-the-box 무력화. 결합하려면 Superpowers의 디시플린을 GSD의 PLAN.md instruction이나 agent 정의 안에 wrapping해 넣는 식으로 수동 brigade해야 하는데, 그러면 양쪽 디자인 가정을 둘 다 깎는 일이 된다.

대응: 두 프레임을 같은 phase에서 같이 쓰지 마라. 외부 결합 가이드들이 합의하는 권고는 단계 분리 — Medium/Mak는 GSD로 spec·plan을 만들고 코드 단계는 Superpowers에 넘기되 같은 phase에서 동시 운영 금지로 정리한다. 즉 GSD로 spec·plan을 jet stream에 띄우고, 코드 짤 때는 Superpowers의 brainstorming → SDD 사이클로 옮기는 식. 또는 둘 중 하나만.

6.5. gstack의 빈 Build phase — 결합의 동기 자체

gstack은 의도된 빈 공간을 가진다. workflow가 Think(/office-hours) → Plan(/plan-*-review) → Build → Review(/review) → Ship(/ship)으로 가는데, Build phase에 대응하는 슬래시·스킬이 정의되어 있지 않다. 코드를 짤 때는 사용자가 수동으로 /review를 부를 때까지 Claude Code가 default 모드로 떨어진다.

이게 결합 담론이 존재하는 직접 이유다. 외부 분석 셋이 모두 같은 결론으로 수렴:

• Pulumi 비교 표 GSTACK 행 "Where it struggles" 칼럼: "The actual writing-code part."
• Medium/Mak: 세 프레임을 생각(gstack) · 안정화(GSD) · 실행(Superpowers)으로 나눠 묶는다.
• DEV/Chen(imaginex): Decision/roles(gstack) → Context/spec(GSD) → Execution(Superpowers) — layer 단위 시퀀스 분리.

세 프레임이 각자의 역할을 가지므로 시퀀스로 결합할 수는 있지만 같은 단계에서 같이는 못 한다. 결합 권고가 항상 "단계별 분리"인 이유.

6.6. interactive Q&A의 stream 차단

Medium/Mak가 발견한 미시 충돌:

"In practice, there's a technical blocker: Superpowers' interactive Q&A prompts during the build phase block Claude Code's input stream. GSD v2 is a TypeScript application rather than Markdown prompts, adding integration complexity."

Superpowers의 brainstorming 단계는 사용자 답변을 기다린다. GSD의 /gsd-execute-phase는 frictionless automation을 가정한다 (README의 --dangerously-skip-permissions 권고와 같은 결). 두 가정이 한 세션에서 만나면 GSD가 멈춤 또는 fallback 모드로 떨어짐.

대응: 같은 stream에서 두 프레임을 interactive 모드로 동시 운영하지 않는다. 한 프레임의 결과를 .planning/ markdown으로 export해서 다음 프레임의 시작 입력으로 쓰는 게 안전 — DEV/Imaginex의 결합 가이드가 권하는 것도 이것.

6.7. 충돌 표면 요약

세 프레임이 공식 문서에서 서로를 전혀 언급하지 않는다는 점도 흥미롭다. 결합 담론은 100% 제3자(Pulumi, Medium, DEV.to, YouTube)에서 생성. 즉 공식 가이드라인은 없고, 모든 결합은 사용자의 실험이라는 것.

7. 한계와 trade-off

7.1. 학습 곡선 — Issue #2251

"52 skill commands, 25+ agent configurations, many workflow steps … Long documentation, hard for new users to get started quickly. For most developers, this flexibility may be a burden rather than help. 53k stars but only 4.5k forks — many might just be 'bookmarking'." — Issue #2251

GSD는 해야 할 게 많다. 86개 명령, 5개 phase, 31개 에이전트, 9개 standard markdown 파일. "/gsd-quick로 시작하면 5분"이라는 community 반론도 있지만, 그건 그 명령만 쓸 경우다. 본체 사이클을 익히려면 학습 비용이 든다.

7.2. v2 SDK npm 게이트 — Issue #3406

"SDK query layer documented in v1.39+ CHANGELOG but @gsd-build/sdk@latest is still v0.1.0 (no query subcommand)"

v1 라인 안에 두꺼워지고 있는 SDK가 별도 npm 패키지로 stable publish 되지 않은 채 parent tarball에 bundled돼 있다. 외부에서 GSD SDK를 단독으로 import해 쓰는 경로가 미완성. 사용자가 자기 toolchain에 SDK를 박고 싶다면 v1 패키지 전체를 install해야 함.

7.3. solo developer 마케팅 vs 거버넌스 사실

§1.2에서 다룬 부분 — "솔로 개발자" self-image와 컨트리뷰터 136명·실제 메인테이너 분리된 거버넌스 사이의 차이. 작은 팀의 협업 프로젝트인 게 사실에 가깝다.

7.4. --no-verify commit과 외부 git hook의 비활성화

§2.2에서 다룬 점. GSD subagent는 --no-verify로 commit하므로 프로젝트의 pre-commit hook을 우회한다. lint·formatter·type check·secret scanner를 git hook으로 운영 중이면 GSD가 그것들을 안 본다. 검증은 executor 안으로 옮겨야 함.

7.5. README claim "context rot 임계점"의 출처

GSD가 "50% 지나면 품질 저하, 70% 지나면 hallucination spike"를 자주 인용하는데, 이 숫자가 원래 어디서 측정됐는지가 README/USER-GUIDE에 명시되지 않는다. "Community testing"이라고만 적혀 있다. 비판적 사용자라면 각자 자기 워크로드에서 측정해 봐야 한다.

7.6. fresh-context의 cross-task 정보 손실

phase boundary가 컨텍스트를 강제 종결한다는 건 직전 phase의 미묘한 결정을 다음 phase가 못 본다는 뜻이기도 하다. SUMMARY.md / VERIFICATION.md로 압축 전달은 되지만, 압축은 손실이다. 미묘한 implicit 결정 — 예: "이 함수 이름은 일부러 길게 뒀다" 같은 — 은 phase 사이에서 사라진다.

1M 컨텍스트 모델(Opus 4.6, Sonnet 4.6)이 도착하면서 GSD는 "Adaptive Context Enrichment"로 대응 — 500K+ 모델에서는 executor가 prior wave SUMMARY들 + phase CONTEXT/RESEARCH를 추가로 받는다. 이는 fresh-context 원칙의 부분 완화이지 폐기가 아니다.

8. 종합 — GSD는 "환경 의견"의 프레임워크다

세 줄로 줄이면:

1. process 의견이 아니라 environment 의견. Superpowers는 어떻게 일할지를 강제, gstack은 누가 일할지를 강제. GSD는 어디서 일할지를 강제 — 매 phase 새 200k 컨텍스트를. 같은 카테고리의 셋 중 환경 레벨로 가장 깊이.
2. TypeScript 본체 — 셋 중 유일하게 코드로 LLM을 통제. 다른 둘은 markdown prompt로 부탁. GSD v1은 hybrid, v2는 본격 TS application. 카테고리 내 implementation investment가 가장 두껍다.
3. 값비싼 trade-off가 정직하게 노출되어 있다. Issue #1553의 maintainer 답변 — "4 agents ≈ 4× tokens. This is how the system works." — 가 본질을 말한다. AI의 100% 지능을 매 phase마다 새로 받는 비용이 매 phase마다 새로 청구된다. Max plan 이상이 사실상 전제.

운영 결론: 마라톤·multi-file·multi-day 프로젝트에서 GSD는 셋 중 가장 적합. 5분짜리 single-file 수정에는 셋 중 가장 부적합. Superpowers·gstack과 같은 세션에서 동시 운영하지 말 것 — out-of-the-box 결합은 §6의 충돌 표면(특히 SessionStart 훅 비결정 순서와 GSD subagent의 Superpowers HARD-GATE 우회)에서 부딪친다. 외부 가이드 셋이 합의한 layer 시퀀스 분리 (gstack 전략 → GSD spec/state → Superpowers build) 만 유효. 단독으로 깔 거면 프로젝트 단위 옵트인으로 다른 둘을 격리하는 게 안전. 값비싼 hook의 정직한 닫음은 §3.5에 둔다.

한 줄 추천 — 토큰이 남는다면 GSD를 켜라. Max plan 이상 사용자, 또는 API 직결로 토큰 비용을 의식적으로 관리할 수 있는 솔로 개발자에게 GSD는 셋 중 peak quality를 가장 안정적으로 뽑아내는 도구다. 같은 작업을 멍청해지지 않은 클로드로 매 phase마다 새로 받을 수 있다는 약속은 진짜고, 메커니즘이 그 약속을 충실히 지킨다. 토큰이 부족하면 GSD는 자기 약속을 못 지킨다 — 그 환경에서는 가벼운 Superpowers 단독이 더 정직한 선택. 즉 예산이 결정 변수. 예산이 있을 때, GSD는 그것을 가장 잘 쓰는 길을 안다.

참고

공식 1차

• gsd-build/get-shit-done — v1.41.0 stable, v1.42.0-rc3 canary
• README.md · README.ko-KR.md
• docs/ARCHITECTURE.md — 5가지 디자인 원칙, MCP token 비용, adaptive context enrichment
• docs/COMMANDS.md — 86개 명령 + 6 namespace router 정의
• docs/USER-GUIDE.md — wave 실행, plan size 권고
• CHANGELOG.md — v1.29~v1.41 SDK 진화 timeline
• gsd-build/gsd-2 — v2 standalone CLI (v2.82.0, 7.4k★)

이슈로 본 GSD의 솔직한 한계

• Issue #1553 — Max $200 plan 40분 소진. maintainer 답변: "deliberate tradeoff"
• Issue #2251 — 학습 곡선·과도한 복잡성 — "53k stars but only 4.5k forks"
• Issue #1086 — 1M context 모델 (Opus 4.6/Sonnet 4.6) 시대 adaptation
• Issue #3309 — human-verify checkpoint의 토큰 비용
• Issue #3406 — SDK npm publish 게이트

비교·결합 외부 분석

• Pulumi — Superpowers, GSD, GSTACK: Picking the Right Framework — Diri, 2026-04-13. 공식 비교 표
• Medium — What Each Claude Code Framework Actually Constrains — Mak, 2026-04-06. "gstack thinks, GSD stabilizes, Superpowers executes"
• DEV — A Claude Code Skills Stack: Combine Without the Chaos — Chen, 2026-04-06. 결합 시퀀스 가이드
• Augment Code — GSD Stars Analysis — Galstian, 2026-04-16. 14 런타임·numeric 정리
• DEV — Complete Beginner's Guide to GSD — Kazmi, 2026-03-17. 4:1 토큰 overhead 보고

창시자

• LinkedIn — Lex Christopherson
• X — @official_taches / @gsd_foundation
• GSD Discord