Claude Code에서 gstack 슬래시 커맨드를 팀 규모별로 골라 쓰는 법 — 스타트업 5개·엔터프라이즈 계층형 CLAUDE.md 실전 템플릿
Airbnb·Stripe의 초기 투자자이자 Y Combinator CEO인 Garry Tan이 본인의 실제 개발 워크플로우를 오픈소스로 공개했습니다. gstack이라는 이름의 이 슬래시 커맨드 팩은 GitHub 공개 48시간 만에 1만 스타를 돌파했고, 2026년 4월 현재 50,000개 이상의 스타를 기록 중입니다. CEO·디자이너·시니어 엔지니어·보안 오피서·QA 리드까지 28개 역할을 /커맨드명 하나로 소환할 수 있다는 점이 개발자 커뮤니티의 폭발적인 반응을 이끌었습니다.
그런데 문제가 있습니다. gstack은 솔로 개발자의 워크플로우에서 시작했고, 커맨드 수가 9개에서 28개로 빠르게 늘어났습니다. 3명짜리 스타트업과 200명짜리 엔터프라이즈가 똑같이 설치해 똑같이 쓴다면, 효율보다 혼란이 먼저 옵니다. 이 글에서는 Claude Code를 이미 사용 중이거나 도입을 검토 중인 개발자를 대상으로, 팀 규모별 gstack 커맨드 서브셋 선택법과 CLAUDE.md 설계 전략을 실전 템플릿과 함께 안내합니다.
Claude Code를 처음 접하는 분들은 Claude Code 공식 문서를 먼저 살펴보시면 이 글의 내용을 더 깊이 이해하는 데 도움이 됩니다.
gstack이란 무엇이고, 왜 CLAUDE.md와 함께 써야 하는가
gstack: 역할 기반 가상 팀을 소환하는 슬래시 커맨드 팩
gstack은 Claude Code의 .claude/commands/ 디렉터리에 마크다운 파일로 정의된 역할 기반 슬래시 커맨드 팩입니다. /커맨드명을 입력하면 해당 파일의 프롬프트가 Claude에게 자동으로 주입되어, 단일 AI 어시스턴트가 순식간에 CEO·시니어 엔지니어·보안 오피서 역할로 전환됩니다.
아래는 28개 전체 커맨드 중 팀에서 가장 자주 쓰이는 대표 커맨드를 카테고리별로 정리한 목록입니다. 전체 목록은 공식 skills.md에서 확인할 수 있습니다.
| 카테고리 | 대표 커맨드 | 역할 |
|---|---|---|
| 계획 검토 | /plan-ceo-review, /plan-eng-review, /plan-design-review |
제품·아키텍처·UX 관점 검토 |
| 코드 품질 | /review, /careful, /guard |
코드 리뷰·OWASP 보안 감사 |
| 배포·릴리스 | /ship, /freeze, /unfreeze, /document-release |
안전한 PR 머지·배포 |
| 테스트·QA | /qa, /qa-only, /browse |
실제 브라우저 기반 E2E 테스트 |
| 조사·문서화 | /investigate, /retro, /office-hours |
레트로스펙티브·코드베이스 분석 |
| 코드베이스 분석 | /codex |
레거시 코드 탐색 및 분석 |
참고:
/codex는 코드베이스 분석용 커맨드입니다. OpenAI의 Codex 서비스와 이름이 동일하지만 전혀 무관합니다. 팀 내에서 혼동 방지를 위해 주석이나 팀 위키에 한 줄 메모를 남겨두면 좋습니다.
슬래시 커맨드(Slash Command): Claude Code에서
/로 시작하는 단축 명령어입니다..claude/commands/디렉터리에 마크다운 파일로 정의되며, 호출 시 해당 파일의 프롬프트가 Claude에게 자동으로 주입됩니다.
CLAUDE.md: gstack의 진짜 힘을 끌어내는 설정 파일
gstack의 진짜 힘은 슬래시 커맨드 자체보다 CLAUDE.md와의 결합에 있습니다. CLAUDE.md는 Claude Code가 프로젝트를 시작할 때 자동으로 읽는 마크다운 설정 파일로, 코딩 컨벤션·금지 패턴·빌드 커맨드·역할 지시 등을 세션 내내 영구적으로 주입합니다.
# CLAUDE.md 기본 구조 예시
# Project Context
Stack: Next.js 15 + Supabase
Team: 5 engineers
# Commands
- Build: pnpm build
- Test: pnpm test
# Conventions
- English variable names only
- Prefer small PRs (<400 LOC)
# Guardrails
- NEVER commit .env files
- Ask before touching auth/ directory2026년 현재 CLAUDE.md는 3단계 계층 구조로 관리하는 방식이 업계 표준으로 자리잡았습니다.
| 계층 | 경로 | 적용 범위 |
|---|---|---|
| 글로벌 | ~/.claude/CLAUDE.md |
모든 프로젝트에 공통 적용 |
| 프로젝트 | .claude/CLAUDE.md |
팀 공용, git에 커밋 |
| 로컬 | .claude.local.md |
개인 오버라이드, .gitignore |
컨텍스트 길이 주의: 커뮤니티 실험에서 CLAUDE.md가 200줄을 초과하면 Claude가 후반부 내용을 무시하는 경향이 관찰되고 있습니다(Anthropic 공식 문서에 명시된 제약은 아니며, 실험적으로 확인된 경향입니다).
@파일경로임포트 패턴으로 모듈화하는 방식이 이 문제를 우회하는 데 효과적이며, 커뮤니티에서 널리 사용되는 패턴입니다.
Claude Code 생태계에서 gstack의 위치
gstack 외에도 여러 프레임워크가 경쟁 중이며, 팀의 성격에 따라 선택지가 다릅니다.
| 도구 | 스타 수 | 특징 | 적합 대상 |
|---|---|---|---|
| gstack | 50K+ | 역할 기반 가상 팀, 빠른 배포 | 솔로·스타트업 |
| Superpowers | 94K+ | TDD 강제, 7단계 파이프라인 | 품질 중심 팀 |
| GSD | 35K+ | 안정성·재시도 로직 | 레거시 프로젝트 |
| Hermes | — | Human-in-the-loop 체크포인트 | 엔터프라이즈 |
팀 규모별 실전 설정: 스타트업·중견·엔터프라이즈
예시 1: 스타트업 팀(1~10명) — 속도 우선 린 서브셋
스타트업에서 28개 커맨드를 모두 도입하면 오히려 인지 부하가 늘어납니다. 핵심 5~7개만 선택해 팀 전체가 숙지하는 방식이 훨씬 효과적입니다. Garry Tan 본인도 gstack으로 50일간 주당 10,000 LOC·100개 PR을 유지했는데, 이는 커맨드 전체가 아닌 린 서브셋의 반복 숙달 덕분입니다.
권장 커맨드 서브셋 — 5개로 시작하기:
/plan-ceo-review # 기능 스코프 검토 — 빌드 시작 전 활용
/review # PR 병합 전 코드 리뷰
/ship # 자동 PR 생성·머지
/qa # 실제 브라우저 E2E 테스트
/retro # 스프린트 종료 회고이 5개를 선택한 이유: /review와 /qa는 PR 품질과 버그 방지에서 즉각적인 ROI를 확인할 수 있는 커맨드입니다. /plan-ceo-review는 잘못된 방향으로 빌드하는 낭비를 사전에 막아줍니다.
스타트업용 CLAUDE.md 템플릿:
# Project Context
Stack: Next.js 15 + Supabase + Vercel
Team: 3 engineers, move fast, ship weekly
# Commands
- Build: pnpm build
- Test: pnpm test
- Deploy: git push origin main (auto-deploys)
# Conventions
- English variable names, comments in any language
- No premature abstraction — 3 instances before extracting
- Prefer small PRs (<400 LOC)
# Active gstack Commands
- /plan-ceo-review → scope check before build
- /review → pre-merge review
- /ship → PR creation and merge
- /qa → E2E browser test
- /retro → sprint retrospective
# Guardrails
- NEVER drop database tables without /guard approval
- NEVER commit .env files
- Ask before touching auth/ directory| 설정 항목 | 설명 |
|---|---|
Stack |
Claude가 기술 선택 시 일관성을 유지합니다 |
Commands |
빌드·테스트·배포 커맨드를 명시해 할루시네이션을 방지합니다 |
Active gstack Commands |
현재 팀이 사용 중인 커맨드만 명시해 혼동을 최소화합니다 |
Guardrails |
되돌리기 어려운 작업에 대한 사전 차단 규칙입니다 |
예시 2: 중견 팀(10~50명) — 하이브리드 전략
중견 팀은 스타트업의 속도와 엔터프라이즈의 안전망을 모두 필요로 합니다. /freeze와 /guard를 필수로 추가하되, CLAUDE.md는 아직 단일 파일로 유지하는 것이 관리 부담을 줄이는 데 적합합니다.
# [MID-TEAM] CLAUDE.md
Stack: React + Node.js + PostgreSQL
Team: 25 engineers, 4 squads
# Active gstack Commands
- /guard → 필수: 파괴적 명령 차단
- /freeze → 필수: 릴리스 전 배포 동결
- /plan-eng-review → 아키텍처 변경 시 활용
- /review → PR 병합 전 코드 리뷰
- /ship → PR 생성·머지
- /qa → E2E 테스트
- /retro → 격주 스프린트 회고
# Guardrails
- DB 마이그레이션: /guard 승인 필수
- auth/, payments/ 디렉터리: 시니어 리뷰 필수
- 금요일 오후 3시 이후 프로덕션 배포 금지예시 3: 엔터프라이즈 팀(50명 이상) — 거버넌스 우선 계층형 구조
엔터프라이즈에서 단일 CLAUDE.md로 50명 이상을 관리하면 규칙 충돌과 거버넌스 문제가 발생합니다. 계층형 분리와 @임포트 패턴이 핵심 해법입니다.
거버넌스 원칙 — 누가 CLAUDE.md를 관리하는가:
엔터프라이즈 도입에서 실무자들이 가장 먼저 부딪히는 질문은 "누가 루트 CLAUDE.md를 변경할 수 있는가"입니다. 권장하는 접근 방식은 다음과 같습니다.
| 계층 | 변경 권한 | 변경 프로세스 |
|---|---|---|
글로벌 ~/.claude/CLAUDE.md |
개인 | 개인 설정, 자유롭게 변경 |
프로젝트 .claude/CLAUDE.md |
테크 리드 또는 엔지니어링 매니저 | PR 리뷰 필수, 팀 합의 후 머지 |
로컬 .claude.local.md |
개인 | .gitignore, 개인 오버라이드 |
디렉터리 구조:
.claude/
CLAUDE.md # 팀 공용 (git commit)
CLAUDE.local.md # 개인 오버라이드 (.gitignore)
docs/
conventions.md # 언어별 코딩 스타일
security-policy.md # OWASP 체크리스트
deploy-rules.md # 배포 금지 시간대·절차엔터프라이즈용 루트 CLAUDE.md 템플릿:
# [ENTERPRISE] Root CLAUDE.md
# Governance: Changes require PR review from Engineering Manager
# Last updated: 2026-04-17
# 모듈화 임포트 (community-supported pattern)
@./docs/conventions.md
@./docs/security-policy.md
@./docs/deploy-rules.md
# Team Context
Org: 200-person eng team
Compliance: SOC2 Type II, GDPR
Oncall rotation: PagerDuty (see #oncall Slack)
# Active gstack Commands
- /guard → destructive command pre-check
- /freeze → deployment freeze before release cut
- /plan-eng-review → architecture change review
- /document-release → automated release notes
- /codex → legacy codebase analysis
- /investigate → incident RCA
# Non-negotiables (hooks enforced)
- No secrets in code (enforced by pre-commit hook)
- All DB migrations require /guard sign-off
- /freeze active during release windows
# MCP Servers
- mcp__jira: ticket creation and status lookup
- mcp__datadog: incident lookup and alert history
- mcp__slack: #incidents channel notificationdocs/security-policy.md 예시 (출발점 — 실제 적용 시 보안팀과 함께 확장하는 것을 권장합니다):
# Security Policy
# NOTE: This is a starting template. Expand with your security team.
## OWASP Top 10 Checklist (Abbreviated)
- SQL Injection: parameterized queries required
- XSS: use DOMPurify or framework-native escaping
- Broken Auth: JWT expiry <= 24h
## Access Control
- RBAC changes require /guard approval
- All DB write operations must have audit logging
- API endpoints require authentication unless explicitly marked publicMCP(Model Context Protocol): Claude가 외부 도구(Jira, Slack, Datadog 등)와 통신할 수 있게 해주는 표준 프로토콜입니다. 2026년 초 이후 Claude Code에서 멀티에이전트 오케스트레이션과 결합되어 엔터프라이즈 워크플로우 자동화가 가능해졌습니다.
장단점 분석
장점
| 항목 | 내용 |
|---|---|
| 즉시 적용 | 설치 한 번으로 전문가 역할을 즉시 활용할 수 있습니다 |
| 프로세스 표준화 | 팀 전체가 동일한 리뷰·배포 프로세스를 따르게 됩니다 |
| 사전 안전 장치 | /guard가 rm -rf, DROP TABLE, force-push 등을 사전에 차단합니다 |
| 확장성 | 커스텀 슬래시 커맨드로 도메인 특화 워크플로우를 추가할 수 있습니다 |
| 무료 오픈소스 | MIT 라이선스로 자유롭게 fork·수정이 가능합니다 |
단점 및 주의사항
| 항목 | 내용 | 대응 방안 |
|---|---|---|
| 개인 최적화 편향 | Garry Tan 개인 워크플로우 기반으로, 팀 규모가 커질수록 의견 충돌이 생길 수 있습니다 | 내부 fork 후 팀 규칙에 맞게 수정하는 방식이 권장됩니다 |
| 컨텍스트 비용 | CLAUDE.md가 길수록 토큰을 소비하고 200줄 초과 시 후반부가 누락되는 경향이 있습니다 | @파일경로 임포트로 모듈화하여 루트 파일은 핵심 규칙만 담는 것이 좋습니다 |
| 학습 곡선 | 28개 커맨드의 역할을 팀 전체가 숙지해야 효과가 납니다 | 팀 규모별 서브셋을 먼저 정하고 단계적으로 확장하는 방식이 적합합니다 |
| 거버넌스 부재 | 단일 CLAUDE.md로 50명 이상 관리 시 규칙 충돌 위험이 있습니다 | 3단계 계층 구조와 PR 기반 변경 프로세스를 도입하는 것이 효과적입니다 |
| 업데이트 추적 | 커맨드가 빠르게 늘어나 버전 관리가 필요합니다 | 팀 채택 커맨드 목록을 CLAUDE.md에 명시하고 변경 시 PR로 관리하는 방식을 권장합니다 |
| Claude 의존성 | Anthropic 모델 변경 시 커맨드 동작이 달라질 수 있습니다 | 중요 커맨드는 정기적으로 실제 동작을 검증하는 것이 좋습니다 |
OWASP(Open Web Application Security Project): 웹 애플리케이션 보안의 국제 표준 기준으로,
/guard커맨드의 보안 감사 체크리스트 기반이 됩니다. 자세한 내용은 owasp.org에서 확인할 수 있습니다.
실무에서 가장 흔한 실수
- 모든 커맨드를 한꺼번에 도입하는 것: 팀이 28개 커맨드의 역할을 숙지하기 전에 전량 도입하면 혼란이 가중됩니다. 팀 규모별 서브셋으로 시작해 점진적으로 확장하는 방식이 안전합니다.
- CLAUDE.md를 단일 파일로 무한정 늘리는 것: 200줄을 초과하면 Claude가 후반부를 읽지 않는 경향이 있습니다.
@임포트패턴으로 분리하고, 루트 파일은 핵심 규칙만 담는 것이 좋습니다. /guard없이 엔터프라이즈 배포에 gstack을 사용하는 것:/guard는 파괴적 명령의 사전 차단 역할을 합니다. 중견 팀 이상에서는/guard와/freeze를 팀 정책으로 강제하는 것을 권장합니다.
마치며
gstack은 팀 규모와 성숙도에 맞는 커맨드 서브셋과 계층형 CLAUDE.md 설계가 결합될 때 진짜 생산성 도구가 됩니다.
지금 바로 시작할 수 있는 3단계:
- gstack을 설치하고 팀 규모에 맞는 커맨드 서브셋부터 정하는 것이 시작점입니다. 공식 저장소를 clone한 뒤, 스타트업이라면
/plan-ceo-review,/review,/ship,/qa,/retro5개로, 중견·엔터프라이즈라면 여기에/guard,/freeze를 추가하는 방식으로 접근해보시면 좋습니다. - 프로젝트 루트에
.claude/CLAUDE.md를 생성하고 위 템플릿을 팀 스택에 맞게 수정하는 것을 권장합니다. 200줄 이내를 유지하고, 보안 정책이나 컨벤션은docs/서브 파일로 분리한 뒤@임포트로 연결하는 방식이 장기 관리에 유리합니다. - 첫 주는
/review와/qa두 가지 커맨드만 실제 PR에 써보는 것이 좋습니다. PR 품질과 버그 방지에서 즉각적인 효과를 체감할 수 있어 팀 전체의 수용도를 높이기 가장 좋은 시작점입니다. 익숙해지면/ship,/guard,/investigate순으로 단계적으로 확장하는 방식으로 진행할 수 있습니다.
다음 글: Claude Code Hooks와 MCP 서버를 연결해 Jira 티켓 생성부터 Datadog 인시던트 조회까지 자동화하는 엔터프라이즈 워크플로우 구축 실전 가이드
참고 자료
- garrytan/gstack 공식 GitHub 저장소
- gstack/CLAUDE.md 공식 템플릿
- gstack/docs/skills.md 커맨드 전체 목록
- GStack Tutorial: 10K LOC/Week 개발 워크플로우 | SitePoint
- GStack vs Superpowers vs Hermes 비교 | MindStudio
- gstack은 솔로 개발자 전용인가, 엔터프라이즈에도 유효한가 | BSWEN
- 엔터프라이즈 팀을 위한 CLAUDE.md 가이드 | Big Hat Group
- CLAUDE.md Best Practices | ClaudeCodeLab
- Claude Code Best Practices 공식 문서
- Superpowers + gstack + GSD 조합 운용법 | DEV Community
- awesome-claude-code 커뮤니티 컬렉션