gstack — 1인 코더가 23명짜리 팀을 굴리는 법

TL;DR

• gstack(garrytan/gstack)는 Y Combinator의 President & CEO Garry Tan이 자기 Claude Code 셋업을 그대로 오픈소스로 공개한 메타프레임워크다. 2026-03-11 출시 2개월 만에 95.9k★·14.3k fork·1,200+ 이슈, v1.34.1.0(2026-05-13) 시점 누적 14,965개 unique 설치 + 305,309회 skill invocation(opt-in 텔레메트리). 셋 중 가장 조직 메타포가 명시적인 프레임이다.
• 메커니즘 한 줄: 23개 슬래시 + 8개 power tools가 각각 역할에 매핑된다. /office-hours(YC Office Hours 페르소나), /plan-ceo-review(CEO·Founder), /plan-eng-review(Eng Manager), /plan-design-review(Senior Designer), /qa(QA Lead), /cso(Chief Security Officer), /ship(Release Engineer), /canary(SRE) — 가상 회사의 조직도가 슬래시 명령이다. 한 명의 코더가 그 23명을 돌려가며 부른다.
• 동작 구조: sprint 시퀀스가 본체. Think(/office-hours) → Plan(/plan-*-review) → Build → Review(/review) → Test(/qa) → Ship(/ship) → Reflect(/retro). 각 슬래시는 이전 단계의 결과물을 읽고 다음 단계에 넘긴다 — 디자인 doc이 plan에 흐르고, plan이 test matrix를 만들고, test가 ship의 회귀 검증으로 흐른다.
• 셋 중 가장 실제 코드가 두꺼운 프레임이기도 하다. /qa 뒤에 Playwright 기반 2,000+줄 브라우저 서버, /design-html 뒤에 Pretext 컴퓨티드 레이아웃 엔진, 22MB 로컬 ML classifier로 sidebar agent의 prompt injection 방어. markdown prompt 묶음 그 이상이다.
• 단독으로 쓰면 제품을 끝까지 끌고 가는 작업에 강하다. 디자인 시스템 구축, 실제 브라우저로 QA, PR 자동화까지 한 사이클이 닫혀있다. Superpowers·GSD와 섞으면 §6의 5가지 충돌 표면 — 특히 /office-hours가 Superpowers brainstorming HARD-GATE와 같은 자리를 점유하는 점, 그리고 셋 중 유일하게 사용자 CLAUDE.md를 직접 수정하는 침투 디자인 — 에서 부딪친다.

1. gstack 소개

1.1. 무엇인가

garrytan/gstack — Y Combinator President & CEO Garry Tan이 자기 Claude Code 셋업을 그대로 공개한 메타프레임워크. README의 한 줄이 정체성을 압축한다:

"gstack is how I do it. It turns Claude Code into a virtual engineering team — a CEO who rethinks the product, an eng manager who locks architecture, a designer who catches AI slop, a reviewer who finds production bugs, a QA lead who opens a real browser, a security officer who runs OWASP + STRIDE audits, and a release engineer who ships the PR." — README

23개 슬래시 + 8개 power tools가 조직도 그대로 매핑되어 있다. Superpowers가 작업 순서에, GSD가 작업 환경에 의견을 가진다면, gstack은 작업의 주체에 의견을 가진다 — 한 명의 코더가 23명을 돌려가며 부른다는 메타포가 본체.

1.2. 창시자 — Garry Tan과 1인 코더의 가상 회사

gstack을 이해하려면 창시자 narrative를 빼놓을 수 없다. README "Why I Built This"에 본인이 직접 정리한 맥락:

• Y Combinator President & CEO. YC 합류 전 Palantir 초기 엔지니어·PM·디자이너, Posterous 공동창업(Twitter 인수), YC 내부 소셜 Bookface 구축.
• 2026년 1~4월 사이 part-time YC 직무를 유지하면서 3개 프로덕션 서비스 + 40+ 신기능 출시. "logical code change" 기준 2013년 페이스 대비 810×(11,417 vs 14 logical lines/day).
• 이 클레임에 대한 LOC 논란은 본인이 docs/ON_THE_LOC_CONTROVERSY.md에 따로 정리. AI 인플레이션 2× 디플레이션 적용 후 408×, 5× 디플레이션 시 162×, 10× pathological case에서도 81×. "계수의 크기 논쟁은 결론을 바꾸지 않는다"는 본인의 정리.
• 동기: Andrej Karpathy의 "I don't think I've typed like a line of code probably since December"(No Priors podcast, 2026-03)와 Peter Steinberger의 OpenClaw(247K★, 사실상 솔로 빌드)에 대한 자기 답이 gstack이라는 명시.

gstack 글에서 흔히 누락되는 한 가지: gstack은 1인 프로젝트가 아니다. 2026-05-13 시점 1,200+ closed issue, 50+ 커뮤니티 기여자, fix-wave 단위 PR 배치 머지(v1.31에서 21개, v1.32에서 12개 community PR을 한 번에 머지)가 일상화돼 있다. Garry Tan의 self-image가 솔로 코더이지만, gstack 자체는 협업 프로젝트. 글의 정확성을 위해 짚어둘 부분.

1.3. 장점

• 역할 페르소나를 슬래시에 1:1 매핑한다. Superpowers는 프로세스 게이트, GSD는 맥락 분리를 첫 시민으로 두는데, gstack은 역할을 첫 시민으로 둔다. /plan-ceo-review를 부르면 CEO 모드의 reviewer가 scope expansion·reduction·hold의 3 모드를 가지고 plan을 다시 본다. /cso를 부르면 OWASP Top 10 + STRIDE 위협 모델로 코드를 본다. 어느 페르소나를 부를지가 워크플로 선택이라는 점이 같은 카테고리 다른 둘과의 결정적 차이.
• 셋 중 가장 실제 코드가 두껍다. gsd-2를 제외하면 gstack이 카테고리 내 engineering investment가 가장 큰 프레임이다. Playwright 기반 브라우저 서버(browse/src/, 2,000+줄), Pretext 컴퓨티드 레이아웃 엔진(design-html/), 22MB 로컬 ML classifier(prompt injection 방어), sidebar agent의 isolated session — 전부 markdown prompt가 아닌 실제 시스템 코드. .tsx 위주 TypeScript 본체가 명령들 뒤에 깔려있다.
• sprint 시퀀스가 한 사이클로 닫힌다. README의 핵심 흐름: /office-hours(design doc 생성) → /autoplan 또는 /plan-*-review 3개(plan에 CEO·design·eng 리뷰 누적) → 코드 작성(Build) → /review(staff engineer pass) → /qa(real browser QA + 회귀 테스트 자동 생성) → /ship(PR + 커버리지 감사) → /canary(post-deploy 모니터링) → /retro(주간 회고). 디자인 doc이 plan에 흐르고, plan이 test matrix를 만들고, test가 ship의 회귀 검증으로 흐른다 — 각 단계가 다음 단계의 입력을 만든다.
• 10개 AI 에이전트 하네스 지원. Claude Code 외에 Codex CLI / OpenCode / Cursor / Factory / Slate / Kiro / Hermes / GBrain (자체 mod) / OpenClaw (ACP via Claude Code session). ./setup 한 번이 설치된 하네스를 자동 감지해 분기 설치. 하네스 추가는 TypeScript config 한 파일로 끝나도록 설계.
• Team mode — 공유 저장소 자동 배포. ./setup --team + gstack-team-init required로 vendored 파일 없이 자동 업데이트를 강제 설정. 한 시간에 한 번 throttled, 네트워크 실패 시 silent, 변경 시 commit. Superpowers·GSD에는 team-onboarding 메커니즘이 없다 — 이 점은 gstack이 조직 도입을 가정한 첫 프레임임을 뜻한다.

1.4. 설치

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

./setup은 설치된 하네스(Claude Code / Codex / Cursor / OpenCode / Factory / Slate / Kiro / Hermes / GBrain)를 자동 감지해 각자의 skills 디렉토리에 분기 설치한다. 단일 하네스 타겟은 ./setup --host <name>.

팀 도입의 정식 경로 — 저장소 안에서:

(cd ~/.claude/skills/gstack && ./setup --team) \
  && ~/.claude/skills/gstack/bin/gstack-team-init required \
  && git add .claude/ CLAUDE.md \
  && git commit -m "require gstack for AI-assisted work"

team-init required는 모든 팀원의 세션 시작 시점에 gstack을 강제 활성화, optional은 nudge만. 둘 다 프로젝트 CLAUDE.md를 수정해 gstack 섹션을 추가한다. 이 침투가 §6.3의 디자인 충돌 표면이 된다.

추가 요구사항: Bun v1.0+ 필수. Node.js는 Windows에서만. Chromium은 /qa·/browse를 쓸 때 Playwright가 자동 인스톨.

2. 작동 구조 — 23명의 가상 팀과 sprint 시퀀스

2.1. 핵심 메타포 — "Think → Plan → Build → Review → Test → Ship → Reflect"

gstack의 본체는 sprint다. README의 한 줄:

"gstack is a process, not a collection of tools. The skills run in the order a sprint runs." — README

각 단계가 이전 단계의 산출물을 입력으로 받는다. /office-hours가 design doc을 쓰고, /plan-*-review 셋이 그 doc을 읽어 plan에 리뷰를 누적하고, /plan-eng-review가 만든 test matrix를 /qa가 picks up하고, /review가 찾은 버그를 /ship이 회귀 검증한다. 떨어지는 정보가 없도록 단계 간 인터페이스가 markdown 파일로 명시되어 있다.

이 시퀀스가 같은 카테고리 다른 둘과의 결정적 차이를 만든다. Superpowers는 모든 코드 변경 전 brainstorming을 강제하는 순서 디시플린에 가깝고, GSD는 각 phase가 자기 fresh 200k 컨텍스트로 시작하는 환경 디시플린. gstack은 같은 컨텍스트 안에서 페르소나만 바꿔가며 시퀀스를 돈다 — 컨텍스트 분리 없이 역할만 분리하는 디자인.

2.2. 23개 슬래시 = 가상 팀의 조직도

명령 카탈로그 부정확성 주의 — README의 install snippet은 23+개를 나열하고, 본 글의 정리도 README "Specialists" 표를 기준으로 한다. v1.34 기준 실제 슬래시 수는 30+에 도달했고 (/learn·/freeze·/guard·/codex·/pair-agent·/setup-* 등), CHANGELOG가 매주 1~2개씩 추가 중이다. README의 "23 + 8" 숫자는 Garry Tan의 marketing tagline이 점차 사실과 어긋나는 대목이기도 하다.

2.3. /autoplan — 자동 라우팅의 본체

23개 명령을 다 외울 필요는 없다. /autoplan 하나가 어떤 리뷰를 누구에게 보낼지를 자동 결정한다:

"Just like at a well-run startup: CEO doesn't have to look at infra bug fixes, design review isn't needed for backend changes. gstack tracks what reviews are run, figures out what's appropriate, and just does the smart thing." — README

/autoplan은 CEO → design → eng → DX 리뷰를 자동 라우팅. 영향받는 영역(UI / API·CLI·SDK / 아키텍처 등)에 따라 어느 리뷰가 필요한지 결정하고, 사용자가 결정해야 하는 taste 결정만 AskUserQuestion으로 surface. 23개 슬래시를 익히지 않고 입문할 수 있는 진입점.

2.4. /qa와 real browser — Build phase의 실제 충전

gstack의 가장 두꺼운 실제 코드가 /qa 뒤에 있다. README의 본인 정리:

"gstack's core real-code feature — the thing that isn't just markdown prompts — is a Playwright-based CLI browser I wrote specifically so I could stop manually black-box testing my stuff. … 2,000+ lines of real systems code (server, CDP inspector, snapshot engine, content security, cookie management)." — ON_THE_LOC_CONTROVERSY.md

/qa가 하는 일: staging URL을 받아 실제 Chromium을 띄우고, 실제 사용자 흐름을 클릭하고, 발견된 버그를 fix하고, 해당 fix를 회귀 테스트로 자동 생성. 텔레메트리 기준 가장 많이 호출되는 슬래시(2026-05 시점 57,650회 — 다음 1위 /plan-eng-review 28,014회의 2배).

/open-gstack-browser — GStack Browser라는 자체 브랜드 Chromium을 띄운다. 사이드바 익스텐션·anti-bot stealth·custom branding(menu bar에 "GStack Browser" 표시, "Chrome for Testing" 아님)이 baked-in. 사용자 본 Chrome은 건드리지 않고, 별도 프로필. 사이드바에 자연어 입력 → child Claude 인스턴스가 isolated session에서 실행 → 화면 클릭·스크린샷·CSS 수정·데이터 추출.

이 real browser 본체가 GSD가 정리한 "gstack의 빈 Build phase" 분석과 어디서 어긋나는지가 §6.4의 대목.

2.5. /pair-agent와 cross-agent 협업

gstack에만 있는 디자인 — 다른 vendor의 AI 에이전트와 같은 브라우저를 공유. /pair-agent를 부르면 GStack Browser 창이 열리고, 다른 에이전트(OpenClaw / Hermes / Codex / Cursor)에 paste할 setup block을 출력. 그 에이전트가 자기 탭을 열어 같은 브라우저 안에서 동작한다 — scoped 토큰, 탭 격리, rate limit, 도메인 제한, activity attribution.

"This is the first time AI agents from different vendors can coordinate through a shared browser with real security." — README

ngrok이 설치되어 있으면 다른 머신의 에이전트도 연결 가능. 같은 머신은 zero-friction 모드(자격증명 직접 작성). 이 메커니즘이 gstack을 cross-agent orchestration layer로도 쓰이게 한다.

2.6. /learn과 도메인 스킬 — 누적 학습

gstack은 세션 사이에 학습을 누적하는 메커니즘을 두 가지로 가진다:

• /learn — 프로젝트별 패턴·함정·선호를 markdown으로 누적. 검색·prune·export. 코드베이스가 커질수록 gstack이 그 코드베이스에 대해 더 똑똑해진다는 본인의 클레임.
• $B domain-skill save — 브라우저 자동화에서 사이트별 노트를 자동 저장. 예: "LinkedIn의 Apply 버튼은 iframe 안에 있다". 같은 호스트네임 다시 방문 시 자동 fire. 3번 성공 후 active 승격, 옵션으로 프로젝트 간 promote-to-global.

/learn의 학습 retrieval은 v1.33.1.0(2026-05-12)에서 token-OR query + task-shaped retrieval로 보강됐다. 검색 정확도 개선이 매주 fix-wave에 포함되는 분야.

2.7. GBrain 통합 — 영속 지식 베이스

GBrain은 gstack과 별도의 AI 에이전트용 영속 지식 베이스. gstack과의 결합은 /setup-gbrain(3 경로: Supabase 기존 URL / Supabase 자동 프로비저닝 / PGLite 로컬) + /sync-gbrain(repo 코드를 gbrain에 색인). 가장 인상적인 디자인:

"After init, the skill offers to register gbrain as an MCP server for Claude Code so gbrain search, gbrain put_page, etc. show up as first-class typed tools — not bash shell-outs." — README

즉 gstack은 MCP 서버를 활용만 하지 않고 생산한다. /sync-gbrain이 프로젝트 CLAUDE.md에 ## GBrain Search Guidance 블록을 자동 추가/제거해 에이전트가 Grep 대신 gbrain search·code-def·code-refs를 우선 쓰게 만든다. 같은 카테고리 다른 둘에는 MCP 생산 메커니즘이 없다.

3. 도드라지는 디자인 — "Vibe coding safe"

3.1. AI Slop 디텍션과 디자인 차원 0-10 평가

gstack의 디자인 리뷰 메커니즘은 디자인 차원마다 0-10 점수를 매기고 10이 무엇인지 정의한다. /plan-design-review·/design-review 둘 다 이 평가표를 쓴다. AI가 만든 mockup의 Slop(과한 그라데이션·일관성 없는 패딩·의미 없는 강조 등)을 정의에 박힌 dimension으로 잡는다.

이 평가표가 Ben Vinegar(Sentry 창업 엔지니어)의 slop-scan(deterministic AI 코드 패턴 룰)과 별도라는 점도 본인이 정직하게 짚는다. gstack 자체는 slop-scan에서 Vinegar가 측정한 것 중 worst인 5.24를 받은 적이 있고, 한 세션에 62%를 깎아 대응. 텔레메트리상 bun test가 2,000+ 테스트를 1.65s에 통과(v1.34.1 기준).

3.2. Confusion Protocol — 추측 차단

gstack은 Confusion Protocol이라는 메커니즘으로 Claude가 아키텍처 결정을 추측하지 않게 한다. Superpowers의 brainstorming HARD-GATE와 비슷한 의도지만 발화 트리거가 아니라 런타임 트리거에 가깝다 — 모호한 명령이 들어오면 AskUserQuestion으로 surface. v1.27.0.0(2026-05-07)에서 plan- 스킬 전체에 gate-tier AskUserQuestion floor를 강제했고, v1.31.0.0(2026-05-10)에서 AskUserQuestion fallback 삭제가 일어났다("forever war의 root cause"라는 CHANGELOG 표현).

3.3. Test-first 강제 — "vibe coding"을 "yolo coding"이 아니게

"100% test coverage is the goal — tests make vibe coding safe instead of yolo coding." — README

/ship이 테스트 프레임워크가 없으면 부트스트랩해서 만든다. 모든 /qa 버그 fix가 회귀 테스트를 생성. 모든 /ship 실행이 coverage audit를 PR body에 첨부. 2026-01 ~100개 테스트 → 2026-05 2,000+ 테스트가 gstack 자체의 텔레메트리. 이 디자인이 AI가 자신감 있게 쓴 garbage를 verification loop로 잡아낸다는 본인의 정리와 맞물린다.

3.4. Prompt injection 방어 스택

sidebar agent가 hostile 웹페이지를 만났을 때의 방어:

1. 22MB 로컬 ML classifier — 모든 페이지·도구 출력을 로컬 스캔
2. Claude Haiku transcript check — 대화 전체 형태에 대해 vote
3. Canary token — 시스템 프롬프트에 random 토큰을 박고 텍스트·도구 인자·URL·파일 쓰기에서 exfil 시도 감지
4. Verdict combiner — 두 classifier가 agree해야 block(single-model false positive 회피)
5. Opt-in 강화 — GSTACK_SECURITY_ENSEMBLE=deberta로 721MB DeBERTa-v3 ensemble 2-of-3 agreement
6. Kill switch — GSTACK_SECURITY_OFF=1

사이드바 헤더에 shield icon으로 status 표시(green/amber/red). 셋 중 prompt injection 방어 스택을 가진 유일한 프레임. Superpowers·GSD에는 brainstorming/process 게이트는 있어도 실행 가능한 외부 입력에 대한 방어가 없다.

3.5. Continuous checkpoint mode — WIP 자동 커밋

gstack-config set checkpoint_mode continuous로 활성화 시 스킬들이 작업 중 자동 commit:

• WIP: 프리픽스 + 구조화된 [gstack-context] body(결정·남은 작업·실패한 접근)
• crash·컨텍스트 스위치 생존
• /context-restore가 commit들을 읽어 세션 state 재구성
• /ship이 filter-squash로 WIP commit을 자동 정리해 bisect 시 깨끗하게 유지
• push는 opt-in(checkpoint_push=true) — 기본은 로컬 only라 매 WIP commit이 CI를 trigger하지 않음

이 메커니즘이 gstack을 crash recovery가 자연스러운 프레임으로 만든다. GSD의 .planning/ markdown state와 비슷한 동기지만, gstack은 git commit 자체가 state다.

4. 슬래시 카탈로그

§2.2의 23 + 8 표 외에, v0.19부터 ship된 standalone CLI가 추가된다(슬래시가 아닌 binary):

Cross-model benchmark가 standalone binary로 떨어져 있다는 점은 gstack이 Claude 단독에 갇힌 프레임이 아님을 분명히 한다. 같은 도구가 세 모델을 동시에 평가.

5. Parallel sprints — Conductor와의 결합

gstack의 transformative 사용 패턴은 parallel sprint다. Conductor가 여러 Claude Code 세션을 격리된 worktree에 띄우는 도구고, gstack 워크플로가 그 세션 각각의 작업 흐름을 정의한다. 본인의 운영 클레임:

"I regularly run 10-15 parallel sprints — that's the practical max right now." — README

각 세션이 자기 sprint 단계에 있다 — 하나는 /office-hours로 새 아이디어, 하나는 /review로 PR, 하나는 feature 구현, 하나는 /qa로 staging 검증, 여섯 개는 다른 브랜치. sprint 구조가 없으면 10개 에이전트는 10개의 카오스라는 본인의 정리가 핵심 — 없으면 안 되는 메커니즘이 process discipline이라는 대목.

이 점이 카테고리 내 운영 도구와의 결합에서 gstack의 위치를 드러낸다. Superpowers·GSD는 단일 세션 안의 자기 사이클을 다듬는 디자인. gstack은 N개 세션을 동시 운영하는 사람에게 각 세션을 같은 process로 통일시키는 도구. 솔로 코더가 가상 회사를 굴리는 메타포가 여기서 사실로 굳어진다.

단 10~15 parallel sprint는 본인 환경의 클레임이고, 일반 사용자에게는 Max plan 이상 + 충분한 disk space + 익숙한 conductor 운영이 전제다. practical max라는 표현이 정직한 표시.

6. Superpowers·GSD와 같이 쓸 때 어디서 깨지는지

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

세 메타프레임을 한 머신에 동시 설치할 때의 충돌 표면. 각 표면은 디자인 가정의 차이에서 나온다.

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." — Claude Code docs

서로 다른 명령으로 등록되므로 세 부트스트랩이 모두 컨텍스트에 주입되고, 순서는 비결정. Superpowers의 <EXTREMELY_IMPORTANT> 블록 + GSD의 gsd-update-banner.js + gstack의 team-mode auto-update banner가 동시에 들어가고, 어느 게 먼저 들어갔는지가 그 세션의 행동을 결정. 대응: 메인 프레임 하나 정하고 나머지는 프로젝트 단위 .claude/settings.local.json에서 옵트인.

6.2. /office-hours vs Superpowers brainstorming — 같은 자리의 두 게이트

gstack의 /office-hours와 Superpowers의 brainstorming은 디자인 의도가 거의 동일하다 — 코드 짜기 전 의도·요구사항·디자인을 사용자와 합의. 차이는:

• Superpowers: 자동 트리거(description 매칭). "X 만들어줘" 발화에 자동 호출. 예외 없음 디자인.
• gstack: 사용자 명시(/office-hours 슬래시). 명시적으로 안 부르면 안 돌아감.

둘이 한 환경에 있으면 Superpowers의 자동 트리거가 gstack의 슬래시 결정을 선점. 사용자가 /office-hours를 부를 의도였더라도 Superpowers brainstorming이 먼저 발동해 같은 자리의 두 페르소나(YC Office Hours vs Superpowers 디자인 게이트)가 충돌. 대응: 둘 중 하나의 트리거 메커니즘을 비활성. Superpowers를 메인으로 쓰면 gstack은 Plan/Review/Test/Ship 위주로 쓰고, gstack을 메인으로 쓰면 Superpowers의 brainstorming description 매칭을 AGENTS.md에서 비활성.

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

gstack README install snippet은 사용자의 CLAUDE.md에 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, and lists the available skills…" — README install snippet

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

결과: gstack의 지시가 사용자 컨텍스트에 가장 stickily 박힌다. 셋이 같이 깔리면 gstack 정책이 프로젝트 모든 세션에 영구적으로 가시화되고, GSD/Superpowers의 부트스트랩은 세션 시작 때만 주입된다. 사용자 의도와 다른 우선순위가 생길 수 있고, 팀 모드 자동 업데이트가 팀원 합의 없이 정책을 새로고침할 가능성도 같은 표면.

대응: gstack을 깔면 사용자가 직접 그 섹션을 검수. 프로젝트 레벨 .claude/CLAUDE.md에 두는 게 global ~/.claude/CLAUDE.md보다 격리에 유리. 조직 도입 시: team-mode required보다 optional이 합의 비용이 낮다.

6.4. "gstack의 빈 Build phase"는 정확히 사실인가

GSD 글이 gstack의 빈 Build phase를 결합 동기로 정리했다. 본문 재확인이 필요한 지점.

"gstack은 의도된 빈 공간을 가진다. workflow가 Think(/office-hours) → Plan(/plan-*-review) → Build → Review(/review) → Ship(/ship)으로 가는데, Build phase에 대응하는 슬래시·스킬이 정의되어 있지 않다." — GSD 글 §6.5

좁은 의미에서는 사실이다 — plan과 review 사이에 "/build"라는 슬래시가 없다. 그러나 넓은 의미에서는 부분 사실이다:

• /design-html — mockup을 production HTML/CSS로 변환. 30KB Pretext 엔진. 코드 출력은 shippable.
• /design-shotgun — mockup 4-6 variant를 GPT Image로 생성, 비교판에서 선택, 반복 학습.
• /qa — staging URL에 실제 브라우저를 띄우고 버그를 직접 fix하고 회귀 테스트 생성. 즉 코드를 쓴다.
• /setup-deploy·/setup-gbrain·/setup-browser-cookies — 환경 부트스트랩 코드.
• /learn·$B domain-skill save — 코드는 아니지만 학습 산출물을 누적 코드처럼 다룸.

GSD 글의 정리는 plan과 review 사이의 명시적 "코드 작성 슬래시"가 없다는 점에서 정확하지만, gstack의 Build phase가 비어있다는 표현은 오해를 부른다 — 디자인·QA·부트스트랩·학습 코드가 그 자리를 채운다. 정확히 옮기면 "gstack은 코드 작성을 별도 슬래시로 분리하지 않고, 디자인·QA·세팅 명령이 코드를 만든다". 결합 분석은 그 정정 위에서 다시 해야 한다.

6.5. 컨텍스트 분리 vs 페르소나 전환 — 메타 가정의 충돌

GSD는 fresh 200k 컨텍스트 subagent가 본체. gstack은 같은 컨텍스트에서 페르소나만 전환. 두 가정이 한 세션에서 만나면:

• GSD가 dispatch한 executor 안에서는 gstack 슬래시가 작동하지 않는다 — gstack 부트스트랩이 fresh context에 주입되지 않으므로. 즉 GSD subagent는 gstack의 23개 페르소나를 못 본다.
• 반대로 gstack 세션 안에서 GSD /gsd-execute-phase를 부르면 현재 gstack 컨텍스트가 GSD subagent로 전달되지 않는다 — plan에 누적된 CEO/design/eng 리뷰가 사라진다.

대응: 두 프레임을 같은 sprint에서 같이 쓰지 마라. 외부 결합 가이드들이 합의한 layer 시퀀스 분리 — gstack 전략 → GSD spec/state → Superpowers build 또는 그 역순 — 만 유효. 동시 운영은 out-of-the-box에서 부딪친다.

6.6. 충돌 표면 요약

세 프레임이 공식 문서에서 서로를 거의 언급하지 않는다는 점도 같다. 결합 담론은 전부 제3자(Pulumi · Medium · DEV.to)에서 생성. 공식 가이드가 없는 결합은 사용자의 실험.

7. 한계와 trade-off

7.1. LOC 클레임의 정직한 한계 — 본인이 짚은 부분

§1.2에서 다룬 810× 클레임에 대해 본인이 docs/ON_THE_LOC_CONTROVERSY.md에 self-concede한 항목:

• Greenfield vs maintenance — 2026 수치는 신규 프로젝트 위주. 10M LOC 레거시 유지보수에는 그대로 안 옮겨감.
• 2013 baseline의 survivorship bias — 공개 활동이 낮았던 해라 비교 기준이 낮게 잡혔을 가능성.
• Quality-adjusted productivity — 깨끗한 버그 밀도 비교가 없음. revert rate 2.0%·fix rate 6.3%·테스트 2,000+ 같은 간접 지표는 있지만 직접 비교는 아님.
• "Shipped"의 의미가 시대마다 다름 — 2년 뒤 80%가 죽으면 비판이 유효.

이 self-concede가 셋 중 gstack만 가지는 정직성. Superpowers·GSD는 productivity 클레임 자체를 안 한다.

7.2. CLAUDE.md 침투 — 거버넌스 우려

§6.3에서 다뤘다. 팀 모드 required는 팀원 합의 없이 정책을 매시간 새로고침할 수 있는 권한을 gstack에 위임한다. 보안·컴플라이언스 의식이 있는 조직은 required 대신 optional, 글로벌 대신 프로젝트 레벨로 격리해야 한다.

7.3. Bun·Chromium 의존성

gstack의 real-code 본체가 Bun·Playwright Chromium에 의존. Python 환경·nix 등 declarative 환경에서는 의존성이 무겁다. 특정 하네스(Codex·OpenCode·Cursor 등)는 bun이 없는 클라우드 IDE에서 일부 명령이 fallback이 없는 채로 실패. v1.31.0.0에서 AskUserQuestion fallback 삭제 후 harness primitive가 이 자리를 부분 채우는 중.

7.4. 학습 곡선 — 23 명령의 위로는 /autoplan

23+개의 슬래시는 익히기 부담이다. README가 install snippet에 모든 슬래시를 카탈로그 형태로 강제 등록시키는 디자인도 처음 사용자에게 컨텍스트 부담. v1.29~v1.34 fix-wave가 learning retrieval·AskUserQuestion floor·plan-tune 같은 명령을 다시 단순하게 만드는 작업에 대부분 할애된다 — 카탈로그가 커지는 만큼 완화 레버도 같이 만들어가는 중. 입문은 /autoplan 하나로 충분.

7.5. YC 채용 lure로서의 부산물

README 하단에 "We're hiring. Come work at YC" 블록이 박혀있다. gstack은 오픈소스 도구인 동시에 YC Software 채용 lure다. 이것 자체는 문제가 아니지만 — Garry Tan의 인센티브가 channel-pure tool-maker와 VC fund recruiter의 두 축을 동시에 가진다는 점은 마케팅 톤과 self-presentation 의 일부를 비판적으로 읽어야 한다는 신호. 810× productivity는 기술 클레임이기도 하고 VC funnel을 위한 narrative이기도 하다.

7.6. fix-wave 의존 — 매주 v1.x.x.0이 올라온다

CHANGELOG를 보면 v1.25(2026-05-02) → v1.34(2026-05-13)까지 11일에 10 버전. 매주 fix wave가 community PR을 batch merge. 안정성은 batch에 무엇이 들어가느냐에 따라 흔들린다. v1.33.2.0(2026-05-12)의 Conductor worktree pollution 같은 회귀가 다음 버전에 잡힌다. long-running 프로덕션에 굳히려면 fix-wave의 한 박자 뒤에 머무는 게 안전.

8. 종합 — gstack은 "역할 분담"의 프레임워크다

세 줄로 줄이면:

1. process 의견도 environment 의견도 아닌 role 의견. Superpowers는 어떻게 일할지, GSD는 어디서 일할지를 강제. gstack은 누가 일할지를 강제 — 한 명의 코더가 23명을 돌려가며 부른다. 같은 카테고리 셋 중 역할 메타포가 가장 명시적.
2. 셋 중 실제 코드가 가장 두껍다. Playwright 서버, Pretext 엔진, 로컬 ML classifier, gbrain MCP 통합. markdown prompt 묶음 그 이상. 카테고리 내 engineering investment가 가장 큰 프레임.
3. CLAUDE.md 침투가 강하다. 셋 중 유일하게 사용자 정책 파일을 수정하고 팀 모드 자동 업데이트를 디폴트화. 거버넌스 의식이 있는 사용자는 project-level 격리가 안전.

운영 결론: 제품을 한 사람이 끝까지 끌고 가는 사이클(디자인 시스템 → mockup → HTML → QA → ship → canary)에서 gstack은 셋 중 가장 적합. 순수 코드 디시플린·맥락 분리만 필요한 사용에는 Superpowers·GSD 단독이 더 가볍다. Superpowers·GSD와 같이 쓸 때: §6의 5가지 충돌 표면 — 특히 /office-hours vs brainstorming 같은 자리, CLAUDE.md 침투, 컨텍스트 모델 직교 — 에서 부딪친다. 외부 분석 셋이 합의한 layer 시퀀스 분리(gstack 전략 → GSD spec → Superpowers build)만 유효.

한 줄 추천 — 1인이 제품 회사를 굴리듯 코딩하고 싶다면 gstack을 켜라. Garry Tan이 자기 셋업을 팔지 않고 공개했다는 점 자체가 카테고리 모먼트의 일부 — YC President가 자기 도구를 GitHub에 그대로 던지는 자리가 2026 Q1 메타프레임 동시 폭증의 시그널이다. 23개 슬래시의 카탈로그가 부담이라면 /autoplan 하나로 시작하면 된다. 조직 도입은 required보다 optional, 글로벌보다 프로젝트 레벨로 격리. 셋 중 가장 조직 메타포에 충실한 도구이므로, 솔로 코더가 가상 회사를 굴리는 메타포가 와 닿는다면 정확히 그 자리에서 가장 잘 작동한다.

참고

공식 1차

• garrytan/gstack — v1.34.1.0 stable, 95.9k★(2026-05-13 기준)
• README.md — install snippet · 23+8 카탈로그 · sprint 시퀀스
• ETHOS.md — 6개 원칙(Boil the Lake · Search Before Building · User Sovereignty 등)
• CHANGELOG.md — v1.25 → v1.34 fix-wave timeline
• docs/ON_THE_LOC_CONTROVERSY.md — 810× 클레임의 self-concede
• docs/skills.md — 각 스킬별 deep dive
• docs/domain-skills.md — $B domain-skill save 메커니즘
• USING_GBRAIN_WITH_GSTACK.md — gstack ↔ gbrain MCP 통합
• garrytan/gbrain — 영속 지식 베이스(별도 repo)

비교·결합 외부 분석

• Pulumi — Superpowers, GSD, GSTACK: Picking the Right Framework — Diri, 2026-04-13
• Medium — What Each Claude Code Framework Actually Constrains — Mak, 2026-04-06
• DEV — A Claude Code Skills Stack: Combine Without the Chaos — Chen, 2026-04-06

창시자 narrative

• Andrej Karpathy, No Priors podcast, 2026-03 — "I don't think I've typed like a line of code probably since December"
• Peter Steinberger / OpenClaw — 247K★, 사실상 솔로 빌드
• Ben Vinegar / slop-scan — gstack 5.24 → 62% 절감 측정 도구
• Garry Tan — Twitter / X

시리즈 내 다른 글

• Agent Framework 카테고리 개요 — Superpowers · GSD · gstack 세 프레임의 위치
• Superpowers — 프로세스 게이트 축
• GSD — 맥락 분리 축