gstack

Posted on | In


gstack이란?

Garry Tan(YC 대표)이 만든 오픈소스 AI 소프트웨어 팩토리:

  • Claude Code를 23개 전문 AI 역할로 변환
  • 7단계 스프린트 워크플로우로 프로덕션 코드 출하
  • 혼자서 팀 수준의 생산성 달성 (60일간 60만줄 코드)
  • repo: github.com/garrytan/gstack

핵심 철학

“개발자 = CEO, 각 스킬 = 전문 팀원”

  • Claude Code를 대체하는 게 아니라, 빈 곳을 채운다
  • AI가 이미 잘하는 것(코드 구현) → 스킬 불필요
  • AI가 혼자선 부족한 것(제품 방향, 취향, 자기 리뷰) → 전문 스킬 필요

왜 23개로 쪼갰나?

자기가 짠 코드를 자기가 리뷰하면 같은 가정을 공유해서 실수를 못 본다

→ 역할을 분리해서 컨텍스트를 끊는다 → 각 스킬이 하나의 관점(렌즈)만 갖고 깊이 본다

1
2
3
4
5
6
7
8
9
10
11
AI가 이미 잘 하는 것     → 스킬 불필요 (그냥 Claude Code)
├─ 코드 구현
├─ 리팩터링
└─ 버그 수정

AI가 혼자선 부족한 것    → 전문 스킬 필요
├─ 제품 방향 검증        → /office-hours
├─ 스코프 판단           → /plan-ceo-review
├─ 디자인 취향 반영      → /design-shotgun
├─ 자기 코드 자기 리뷰   → /review (분리된 관점)
└─ 보안 감사             → /cso


스프린트 워크플로우 7단계

1
Think → Plan → Build → Review → Test → Ship → Reflect

Think — “뭘 만들지?” 검증

  • /office-hours: YC 오피스 아워처럼 6가지 강제 질문
  • 아이디어 자체를 검증하는 단계
  • 아웃풋: 디자인 독 (이 제품이 뭔지, 왜 필요한지)

Plan — “어떻게 만들지?” 확정

Think에서 나온 디자인 독을 받아서 4명의 전문가가 각자의 렌즈로 검토:

1
2
3
4
5
6
/office-hours 아웃풋 (디자인 독)
    │
    ├→ /plan-ceo-review    "스코프가 맞아? 너무 크거나 작지 않아?"
    ├→ /plan-eng-review    "기술적으로 어떤 구조로 만들지?"
    ├→ /plan-design-review "사용자 경험은 괜찮은지?"
    └→ /plan-devex-review  "개발자가 쓰기 편한지?" (API/SDK일 때)
  • “뭘”이 흔들리면 “어떻게”를 아무리 잘 짜도 소용없으니까 Think → Plan 순서가 중요
  • /autoplan: 위 4개를 자동 순차 실행, 취향 결정만 사람이 함

/plan-ceo-review 4가지 모드

모드 설명
Expansion 스코프 확장 — 더 큰 기회 발견
Selective Expansion 선택적 확장 — 핵심만 추가
Hold Scope 스코프 유지 — 현재 범위 고수
Reduction 스코프 축소 — MVP로 줄이기

혼자 개발하면 스코프 크리프 생기기 쉬운데, AI가 견제해주는 구조

Build — 디자인 + 코딩

스킬 기능
/design-consultation 디자인 시스템 처음부터 구축
/design-shotgun 목업 4-6개 한번에 생성해서 비교
/design-html 선택된 목업을 프로덕션 HTML/CSS로 변환
  • 코드 구현 스킬은 없다 — Claude Code가 이미 잘 하니까
  • gstack은 구조화된 프로세스가 필요한 영역(디자인)만 담당

Review — 분리된 관점으로 검증

스킬 뭘 보는가 비유
/review 코드 품질, 로직 버그, 구조 코드 리뷰어
/investigate 특정 버그 루트 코즈 탐정
/codex OpenAI로 세컨드 오피니언 외부 감사

/review 특징

  • 자동 수정 (뻔한 이슈) + 플래그 (판단 필요한 이슈) 구분
  • /codex와 조합하면 cross-model analysis (Claude + GPT 비교)

/investigate 규칙

  • Iron Law: 조사 없이 수정하지 않는다
  • 가설 세워서 검증 → 3번 연속 틀리면 자동 멈춤
  • 멈추고 접근 방식 자체를 재고하게 만듦

Test — 실제 브라우저로 QA + 보안

스킬 기능
/qa Chromium 브라우저 띄워서 실제 테스트 + 버그 수정 + 회귀 테스트 자동 생성
/qa-only 같은 테스트인데 리포트만 (코드 수정 없음)
/cso OWASP Top 10 + STRIDE 보안 감사, 신뢰도 8/10+ 게이트
/benchmark Core Web Vitals, 페이지 로드 성능 측정

/qa가 버그 발견하면

  1. 버그 수정 (원자적 커밋)
  2. 회귀 테스트 자동 생성
  3. 수정 후 재검증

Ship — 테스트 → PR → 배포 자동화

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
/ship
  → main 동기화
  → 테스트 전체 실행
  → 커버리지 감사
  → 테스트 프레임워크 없으면 자동 부트스트랩
  → PR 생성
  → /document-release 자동 호출 (문서 업데이트)

/land-and-deploy
  → PR 머지
  → CI 통과 대기
  → 프로덕션 배포
  → 헬스체크 검증

/canary
  → 배포 후 감시 루프
  → 콘솔 에러 / 성능 회귀 / 페이지 장애 감지
  • 스킵할 수 있는 단계가 없다 — “귀찮으니까 넘어가자”를 구조적으로 차단

Reflect — 회고

  • /retro: 주간 회고 (커밋 수, 테스트 건강도, 성장 기회)
  • /retro global: 모든 프로젝트 횡단 회고


전체 스킬 맵 (23개)

Think

스킬 역할
/office-hours YC 오피스 아워 — 6가지 강제 질문으로 아이디어 검증

Plan

스킬 역할
/plan-ceo-review CEO — 스코프 결정 (4가지 모드)
/plan-eng-review EM — 아키텍처 잠금, 테스트 매트릭스, 실패 모드
/plan-design-review 시니어 디자이너 — 디자인 차원별 0-10 점수
/plan-devex-review DX 리드 — 개발자 경험 감사
/autoplan 자동 파이프라인 — 모든 리뷰 순차 실행

Build

스킬 역할
/design-consultation 디자인 파트너 — 디자인 시스템 구축
/design-shotgun 디자인 탐색 — 목업 4-6개 변형 생성
/design-html 디자인 엔지니어 — 목업→프로덕션 HTML

Review

스킬 역할
/review 스태프 엔지니어 — 코드 리뷰 + 자동 수정
/investigate 디버거 — 체계적 루트 코즈 분석
/design-review 디자이너 — 디자인 감사 + 수정
/devex-review DX 테스터 — 라이브 DX 감사
/codex 세컨드 오피니언 — OpenAI로 독립 리뷰

Test

스킬 역할
/qa QA 리드 — 브라우저 테스트 + 수정 + 회귀 테스트
/qa-only QA 리포터 — 리포트만
/cso CSO — OWASP + STRIDE 보안 감사
/benchmark 성능 엔지니어 — Core Web Vitals 측정

Ship

스킬 역할
/ship 릴리스 엔지니어 — 테스트→PR
/land-and-deploy 릴리스 엔지니어 — 머지→배포→검증
/canary SRE — 배포 후 모니터링
/document-release 테크 라이터 — 문서 자동 업데이트

Reflect

스킬 역할
/retro EM — 주간 회고, 성장 기회


지원 도구

도구 기능 사용 시점
/browse Chromium 직접 제어 (~100ms) 웹 앱 디버깅, 실시간 확인
/pair-agent 다른 AI와 브라우저 공유 멀티 에이전트 협업
/careful 위험 명령 실행 전 경고 항상
/freeze 특정 폴더만 편집 허용 범위 제한 필요 시
/guard /careful + /freeze 합본 프로덕션 작업 시
/unfreeze /freeze 해제 잠금 해제 필요 시
/learn 세션 간 학습 패턴 저장 지식 축적


스킬 선택 가이드

만드는 것 Plan 단계 실시간 감사
엔드 유저 (UI/웹/모바일) /plan-design-review /design-review
개발자 (API/CLI/SDK/문서) /plan-devex-review /devex-review
아키텍처 (데이터 흐름/성능) /plan-eng-review /review
전부 다 / 모르겠으면 /autoplan —


설치

1
2
3
4
5
6
7
8
9
10
11
# 기본 설치 (30초)
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

# 팀 모드 (자동 업데이트)
cd ~/.claude/skills/gstack && ./setup --team

# 멀티 플랫폼
./setup --host codex    # OpenAI Codex
./setup --host cursor   # Cursor
./setup --host kiro     # Kiro

요구사항: Claude Code, Git, Bun v1.0+


실전 패턴

패턴 1: 풀 스프린트 (처음부터 끝까지)

1
/office-hours → /autoplan → (코딩) → /review → /qa → /cso → /ship → /retro

패턴 2: 빠른 기능 추가 (Plan 생략)

1
(코딩) → /review → /qa → /ship

패턴 3: 버그 수정

1
/investigate → (수정) → /review → /qa → /ship

패턴 4: 디자인 중심

1
/office-hours → /plan-design-review → /design-shotgun → /design-html → /review → /ship

패턴 5: 보안 감사 후 출하

1
/review → /cso → /qa → /ship

패턴 6: 프로덕션 안전 작업

1
/guard → (작업) → /review → /qa → /ship → /land-and-deploy → /canary


Phase 2: Think & Plan 심화

/office-hours — 6가지 강제 질문

바로 구현부터 들어가면 “3일 코딩 → 이게 아니었는데” 발생. /office-hours는 코딩 전에 AI가 강제로 “왜?”를 물어보는 도구

1
2
3
4
5
6
1. "이 제품이 해결하는 진짜 문제가 뭐야?"
2. "왜 기존 방법으로는 안 돼?"
3. "누가 이걸 쓸 거야?"
4. "성공하면 어떤 모습이야?"
5. "가장 위험한 가정이 뭐야?"
6. "가장 작게 시작하려면?"

아웃풋: 디자인 독 → 이후 모든 Plan 스킬의 입력이 됨

매번 쓸 필요는 없다

상황 /office-hours 필요?
새 프로젝트, 아이디어가 막연함 필수
새 기능인데 방향이 확실함 선택
버그 수정, 리팩토링 불필요 — 바로 /investigate나 /review
기존 기능 개선 선택

Plan 스킬 3종 — 같은 문서를 다른 눈으로

1
2
3
4
5
6
7
           같은 디자인 독
          ┌──────┴──────┐
          │              │
   /plan-ceo-review   /plan-eng-review   /plan-design-review
          │              │                       │
    "너무 크잖아,       "이 구조면              "이 UI 흐름은
     MVP로 줄여"       DB 2개 필요해"          3클릭이 너무 많아"
스킬 관점 핵심 질문
/plan-ceo-review 비즈니스 “이 스코프가 맞아?”
/plan-eng-review 기술 “이 구조로 만들 수 있어?”
/plan-design-review 사용자 “사용자가 이걸 쓸 수 있어?”

/plan-eng-review 산출물

단순 “괜찮다/안 괜찮다”가 아니라 구체적 산출물:

  • 아키텍처 다이어그램 확정
  • 테스트 매트릭스 (뭘 테스트해야 하는지)
  • 실패 모드 분석 (뭐가 터질 수 있는지)
  • 숨겨진 가정 노출

→ 나중에 /review, /qa할 때의 기준이 됨. Plan에서 정했으니 Ship할 때 빠뜨릴 수 없는 구조

/autoplan — 실전에서는 이거면 끝

1
2
3
4
5
/autoplan 한 번 치면:
  → 프로젝트 타입 자동 감지
  → 필요한 리뷰만 자동 선택 (웹앱이면 design, API면 devex)
  → CEO → design → eng → DX 순서로 자동 실행
  → 사람한테는 "취향 결정"만 물어봄

실전 공식: /office-hours → /autoplan 이 두 개면 Think+Plan 끝


SuperClaude vs gstack 비교

항목 SuperClaude gstack
목적 에이전트 + 도구 확장 스프린트 워크플로우
접근 기능별 명령어 역할별 전문가
강점 유연한 조합, 플래그 시스템 체계적 프로세스, 스킵 방지
약점 순서는 사용자가 결정 Build(코딩) 스킬 없음
핵심 메타포 도구상자 팀 조직도
코드 리뷰 /sc:analyze (같은 맥락) /review (분리된 관점) + /codex (다른 모델)
보안 /sc:analyze --focus security /cso (OWASP + STRIDE 전용)
배포 /sc:git /ship → /land-and-deploy → /canary 체인