새소식
300x250
AI/Skills
"하네스 엔지니어링" - gstack(혼자서 팀처럼 개발하기) 리뷰 : Garry Tan의 Claude Code 셋업을 내 프로젝트에 적용하는 법
- -
728x90
안녕하세요! 갓대희 입니다.
Y Combinator(YC) 사장이자 CEO인 Garry Tan이 자신의 Claude Code 셋업을 오픈소스로 공개했다.
이름은 gstack. CEO, 디자이너, 엔지니어링 매니저, Release Engineer, Doc Engineer, QA 엔지니어 등 역할을 각각 담당하는 AI 에이전트들로 구성된 개발 워크플로우 툴킷이다. 공개 2주 만에 GitHub에서 56,000+개의 스타(2026-03-30 GitHub API 기준, 지속 증가 중)를 받으며 2026년 가장 빠르게 성장한 개발 도구 중 하나로 자리잡았다.
단순한 프롬프트 모음집이 아니다. Garry Tan 본인의 표현대로 "That is not a copilot. That is a team." — 각 개발 단계마다 다른 인지 모드를 스위칭하는 구조적 접근법이다. 처음 공개 시 6개 도구였으나 빠르게 성장하여 현재 29개의 스킬을 포함하며, Claude Code뿐 아니라 Codex CLI도 지원하고 SKILL.md 표준을 따르는 Python 에이전트 전반과 호환된다. 이 글에서는 gstack이 무엇인지, 어떻게 셋업하는지, 실제로 어떻게 활용하는지, 그리고 커뮤니티의 찬반 양론까지 살펴본다.
GitHub: https://github.com/garrytan/gstack
Stars: 56,000+ | Forks: 7,300+ (2026-03-30 GitHub API 조회 기준, 실시간 변동) | 언어: TypeScript | 요구사항: Claude Code(또는 Codex CLI) + Git + Bun v1.0+ (Windows는 Node.js 추가 필요)
Stars: 56,000+ | Forks: 7,300+ (2026-03-30 GitHub API 조회 기준, 실시간 변동) | 언어: TypeScript | 요구사항: Claude Code(또는 Codex CLI) + Git + Bun v1.0+ (Windows는 Node.js 추가 필요)
목차
- Garry Tan은 누구인가?
- gstack이란? — 탄생 배경과 철학
- 하네스 엔지니어링 관점에서 본 gstack
- 29가지 역할별 에이전트 스킬 해부
- YC Office Hours — /office-hours
- CEO 리뷰 모드 — /plan-ceo-review
- 엔지니어링 매니저 모드 — /plan-eng-review
- 디자인 리뷰 — /plan-design-review, /design-consultation, /design-review
- Staff Engineer 모드 — /review, /investigate
- Release & Deploy — /ship, /land-and-deploy, /canary, /benchmark
- QA Engineer — /browse, /qa, /qa-only
- 보안·안전 — /cso, /careful, /freeze, /guard, /unfreeze
- 유틸리티 — /codex, /retro, /document-release, /gstack-upgrade
- 설치 및 셋업 방법 (단계별 가이드)
- CLAUDE.md 및 설정 파일 구조
- Conductor와의 병렬 실행
- 이 방식의 장점과 한계
- 커뮤니티 반응 — 찬사와 논쟁
- 실전 활용: Codex 리밋 후 gstack + Claude Code 워크플로우
- 30분 핵심 튜토리얼: 처음 gstack 써보기
- 직접 따라하기 — 나만의 역할별 에이전트 셋업
- 결론
1. Garry Tan은 누구인가?
Garry Tan은 현재 Y Combinator(YC)의 President & CEO를 맡고 있다.
YC는 Airbnb, Dropbox, Stripe, Coinbase, Instacart, Rippling 등 수천 개의 스타트업을 배출한 세계 최고의 스타트업 액셀러레이터다.
Garry Tan은 Palantir의 초기 엔지니어/디자이너 출신이고, Posterous(트위터에 인수)를 창업한 경험이 있으며, YC 내부 SNS인 Bookface를 직접 개발한 실리콘밸리의 핵심 인물이다.
(출처: gstack README)
그는 기술과 제품에 대한 깊은 이해를 바탕으로 직접 코드를 작성하는 CEO로 알려져 있다.
이후 그의 CTO 친구가 "Your gstack is crazy. This is like god mode"라고 평가하며 바이럴되었다.
왜 CEO가 직접 Claude Code 셋업을 공개하는가?
Garry Tan은 "AI 코딩 도구를 단순히 사용하는 것"과 "제대로 활용하는 것" 사이에 큰 차이가 있다고 강조한다. gstack은 그가 실제로 YC 포트폴리오 회사들과 함께 일하면서, 그리고 개인 프로젝트를 진행하면서 다듬어온 실전 셋업이다. 단순한 프롬프트 튜닝이 아니라, 개발 프로세스 자체를 구조화하는 방법론이다.
2. gstack이란? — 탄생 배경과 철학
gstack의 공식 설명은 이렇다:
"Use Garry Tan's exact Claude Code setup:
15 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA
(Garry Tan의 Claude Code 설정을 그대로 사용하라:
CEO, Designer, Engineering Manager, Release Manager, Documentation Engineer, QA 역할을 수행하는 강하게 의견이 반영된(opinionated) 15개의 도구(tool) 구성)"
(출처: GitHub repo description )
핵심 철학은 한 문장으로 요약된다:
"Planning is not review. Review is not shipping. Founder taste is not engineering rigor."
기획은 리뷰가 아니다. 리뷰는 배포가 아니다. 창업자의 감각은 엔지니어링의 엄밀함이 아니다.
이 철학이 왜 중요한가?
많은 개발자들이 Claude Code(또는 다른 AI 코딩 어시스턴트)를 "만능 도구"처럼 사용한다. 기획, 코딩, 리뷰, 배포를 모두 같은 대화 창에서, 같은 프롬프트 스타일로 요청한다. 결과는 "어중간하게 다 하는" 범용 응답이다.
gstack은 이를 거부한다. 각 개발 단계마다 다른 인지 모드가 필요하다는 것을 인식하고, 명시적으로 모드를 스위칭하는 구조를 만든다. CEO처럼 10배 더 나은 제품을 상상할 때와, Staff Engineer처럼 프로덕션 버그를 사냥할 때는 다른 사고방식이 필요하다.
기술 스택과 요구사항
- Claude Code: Anthropic의 AI 코딩 어시스턴트 (필수)
- Git: 버전 관리 (필수)
- Bun v1.0+: JavaScript 런타임 — /browse 스킬의 브라우저 바이너리 컴파일에 필요
- macOS 또는 Linux (x64/arm64): /browse 스킬 지원 환경
- Conductor (선택): 병렬 Claude Code 세션 관리 (10개 동시 실행 시)
하네스 엔지니어링 관점에서 본 gstack
gstack을 "프롬프트 모음집"으로 보는 시각이 있다. 하지만 2026년 양대 AI 회사가 한 달 간격으로 발표한 공식 블로그 — OpenAI "Harness Engineering"(2026-02-11)과 Anthropic "Harness Design for Long-Running Apps"(2026-03-24) — 의 프레임으로 보면 전혀 다른 그림이 나온다. gstack은 개인 개발자를 위한 하네스(harness)다.
하네스란 프롬프트보다 넓은 개념이다. 에이전트가 작동하는 환경 전체 — 운영 규칙, 역할 분리 구조, 검증 루프, 안전 가드레일 — 를 포함한다. gstack의 구성 요소를 하네스 엔지니어링 원칙에 매핑하면 다음과 같다.
| 하네스 엔지니어링 원칙 | gstack 구현 | 참조 |
|---|---|---|
| 환경 설계 | CLAUDE.md의 gstack 섹션 — 세션 시작 시 항상 로드되는 운영 규칙. 사용 도구와 스킬 목록을 명시 | OpenAI: "에이전트가 접근할 수 없는 것은 존재하지 않는 것과 같다" |
| 역할 분리 | SKILL.md 기반 29개 역할을 명시적으로 분리. 각 스킬은 다른 평가 기준과 출력 형식을 가짐 | Anthropic: Planner / Generator / Evaluator 3-에이전트 구조 |
| 피드백 루프 | /autoplan(방향 설정) → 구현(Generator) → /review · /qa(Evaluator) | Anthropic: "생성기 자신에게 자기 결과를 평가하게 하면 편향이 생긴다" |
| 행동 가드레일 | /careful · /freeze · /guard — 파괴적 명령 차단 및 작업 범위 잠금 | 프롬프트가 아닌 구조화된 운영 규칙 레벨에서 작동 |
OpenAI가 말한 "Humans steer. Agents execute."는 gstack의 /office-hours에서 정확히 구현된다. 6가지 강제 질문으로 사람이 방향을 확정하면, 이후 에이전트가 설계·구현·검증을 실행한다. /review와 /qa를 구현 단계와 분리하는 것도 같은 이유다 — 자기 코드를 자기가 평가하면 맹점이 생긴다.
같은 모델, 다른 하네스 → 다른 결과
LangChain은 모델을 고정한 채 하네스만 변경하여 에이전트 벤치마크(Terminal Bench 2.0) 점수를 52.8 → 66.5로 끌어올렸다. (출처, 2026-02-17) gstack은 Claude를 더 좋은 모델로 바꾸는 도구가 아니라, 같은 모델이 더 일관되게 일하도록 행동 공간을 재설계하는 하네스다.
프롬프트 엔지니어링 vs 하네스 엔지니어링
gstack의 핵심은 프롬프트를 더 길게 쓰는 데 있지 않다. CLAUDE.md 같은 항상 로드되는 운영 규칙, SKILL.md 기반 역할 분리, 그리고 /review · /qa 같은 검증 루프를 통해 에이전트의 행동 자체를 재구성하는 데 있다. 프롬프트는 포크해서 바꿀 수 있지만, 이 구조적 설계는 쉽게 재발명되지 않는다. 단, 역할마다 별도 스킬을 호출하는 만큼 토큰과 운영 오버헤드가 늘어난다는 트레이드오프는 있다.
하네스 엔지니어링 개념 전체(OpenAI vs Anthropic 비교 분석)는 하네스 엔지니어링 완전 가이드에서 상세히 다룬다.
3. 29가지 역할별 에이전트 스킬 해부
gstack은 초기 6개 스킬에서 빠르게 확장하여 현재 약 29개의 슬래시 커맨드 스킬로 구성된다
(README는 "All 29 skills"로 표기, 2026-03-30 기준. 빠르게 추가/변경 중).
각 스킬은 특정 역할의 인지 모드로 AI 에이전트를 전환한다. 아래 표에서 카테고리별로 전체 구조를 파악할 수 있다.
(출처: gstack docs/skills.md, 2026-03-26 기준)
기획·리뷰 (Planning & Review)
| 스킬 명령어 | 역할 | 주요 기능 |
|---|---|---|
/office-hours |
YC Office Hours | 6가지 강제 질문으로 코드 작성 전 제품을 재정의. 전제를 도전하고 구현 대안을 생성 |
/plan-ceo-review |
창업자 / CEO | 10-star product 관점에서 문제 재정의. 4가지 모드: Expansion, Selective, Hold, Reduction |
/plan-eng-review |
엔지니어링 매니저 | 아키텍처 확정, 데이터 플로우, 에지 케이스 정의. 숨겨진 가정을 드러냄 |
/plan-design-review |
시니어 디자이너 | 인터랙티브 plan-mode 디자인 리뷰. 각 차원을 0~10점으로 평가하고 개선 |
/autoplan |
리뷰 파이프라인 | CEO → Design → Eng review를 자동 순차 실행. 판단이 필요한 "taste decisions"만 사용자에게 질문 |
디자인 (Design)
| 스킬 명령어 | 역할 | 주요 기능 |
|---|---|---|
/design-consultation |
디자인 파트너 | 디자인 시스템 구축. 창의적 리스크 제안, 실제 제품 목업 생성 |
/design-review |
코드하는 디자이너 | 라이브 사이트 시각 감사 + 수정 루프. 80항목 감사 후 atomic commit으로 수정 |
/design-shotgun |
디자인 탐색기 [신규 v0.13.5] | 여러 AI 디자인 변형을 생성하고, 브라우저에서 비교 보드를 열어 방향을 선택. 사용자 취향 메모리를 누적 학습 |
구현·테스트 (Implementation & Testing)
| 스킬 명령어 | 역할 | 주요 기능 |
|---|---|---|
/review |
Staff Engineer | CI를 통과하는 프로덕션 버그 탐색. 자동 수정 + 완전성 갭 표시 |
/investigate |
디버거 | 체계적 근본 원인 디버깅. 데이터 흐름 추적, 가설 테스트. 3회 실패 시 중단 |
/qa |
QA Lead | 앱 테스트 → 버그 발견 → atomic commit 수정 → 재검증. 회귀 테스트 자동 생성 |
/qa-only |
QA 리포터 | /qa와 동일 방법론이지만 코드 수정 없이 보고만 수행 |
/cso |
Chief Security Officer | OWASP Top 10 + STRIDE 위협 모델링 감사. Injection, 인증, 암호화, 접근 제어 스캔 |
/browse |
QA Engineer (시각) | 실제 Chromium 브라우저로 클릭, 스크린샷 (~100ms/명령) |
/connect-chrome |
Chrome 컨트롤러 [신규] | 실제 Chrome을 gstack이 제어하는 모드로 실행. Side Panel 확장으로 모든 동작을 실시간 관찰 가능 |
배포 (Deployment)
| 스킬 명령어 | 역할 | 주요 기능 |
|---|---|---|
/ship |
Release Engineer | main 싱크 → 테스트 → 커버리지 감사 → 푸시 → PR 생성. 원커맨드 |
/land-and-deploy |
배포 매니저 | PR 머지 후 프로덕션 배포까지 전체 흐름 실행 |
/canary |
SRE | 포스트-디플로이 모니터링 루프. console errors, 성능 저하, 페이지 장애를 감시 |
/benchmark |
성능 엔지니어 | 성능 벤치마크 실행 및 비교 |
/setup-deploy |
배포 설정 | 배포 환경 초기 설정 및 구성 자동화 |
안전·유틸리티 (Safety & Utilities)
| 스킬 명령어 | 역할 | 주요 기능 |
|---|---|---|
/careful |
안전 가드레일 | 파괴적 명령 전 경고. 일반 빌드 정리는 화이트리스트 |
/freeze |
편집 잠금 | 파일 편집을 단일 디렉토리로 제한. 경계 밖 Edit/Write 차단 |
/guard |
풀 세이프티 | /careful + /freeze 결합. 프로덕션 작업 시 최대 안전 모드 |
/unfreeze |
잠금 해제 | /freeze 경계 제거, 전체 편집 허용 |
/codex |
Second Opinion | OpenAI Codex 독립 리뷰. 3가지 모드: 코드 리뷰 게이트, 적대적 챌린지, 오픈 상담 |
/retro |
엔지니어링 매니저 | 팀 메트릭 기반 회고. 개인별 분석, 배포 스트릭, 테스트 건강도 트렌드 |
/document-release |
테크니컬 라이터 | 배포된 코드에 맞춰 프로젝트 문서 자동 업데이트 |
/setup-browser-cookies |
세션 매니저 | Chrome, Arc, Brave, Edge에서 쿠키 가져와 헤드리스 세션에 임포트 |
/gstack-upgrade |
셀프 업데이터 | gstack을 최신 버전으로 업그레이드. 글로벌/벤더 설치 자동 감지 |
3.1 YC Office Hours — /office-hours (신규)
gstack 워크플로우의 시작점이다. 코드를 한 줄도 쓰기 전에 6가지 강제 질문으로 제품을 재정의한다.
Garry Tan이 실제 YC Office Hours에서 창업자들에게 던지는 질문을 AI 에이전트가 대신 수행하는 구조다. 전제를 도전하고, 기존 프레이밍을 부수고, 구현 대안을 생성한다.
이 스킬이 만든 디자인 문서가 이후 /plan-ceo-review 등 모든 하위 스킬의 입력이 된다.
/office-hours가 만드는 가치
일반적인 AI 코딩 어시스턴트는 "이 기능 만들어줘"라고 하면 바로 코딩을 시작한다. /office-hours는 반대로 "이 기능이 정말 필요한가? 더 나은 방법은 없는가?"부터 묻는다. 디자인 문서에 revision chain이 기록되어, 아이디어가 어떻게 진화했는지 추적할 수 있다.
3.2 CEO 리뷰 모드 — /plan-ceo-review
이 스킬은 창업자의 시각으로 문제를 바라보는 인지 모드를 활성화한다.
단순히 요청된 기능을 구현하는 게 아니라, "이 문제를 해결하는 가장 탁월한 방법은 무엇인가?"를 먼저 묻는다.
4가지 동작 모드를 제공한다: Expansion(범위 확장), Selective Expansion(선택적 확장), Hold Scope(범위 유지), Reduction(범위 축소).
Garry Tan이 YC 창업자들에게 늘 강조하는 "10-star product" 개념이 여기에 녹아 있다.
Airbnb의 사례로 설명하면, 별 1개짜리 경험은 "호스트가 집 열쇠를 보내줬다"이고, 별 10개짜리 경험은 "공항에서부터 개인 컨시어지가 안내해주고 방에 선물이 준비되어 있다"이다.
이 스킬은 AI가 별 10개짜리 솔루션을 먼저 상상한 후, 현실적으로 가능한 범위를 좁히는 방식으로 작동한다.
/plan-ceo-review 사용 시점
- 새로운 기능 개발 시작 전
- 기존 접근법에 막혔을 때
- 사용자 경험(UX) 개선 방향을 정할 때
- 경쟁사 대비 차별화 전략을 구상할 때
3.3 엔지니어링 매니저 모드 — /plan-eng-review
CEO 리뷰가 "무엇을 만들 것인가"를 정한다면,
엔지니어링 매니저 모드는 "어떻게 만들 것인가"를 정한다.
아키텍처를 확정하고, 데이터 플로우를 다이어그램으로 문서화하고, 에지 케이스와 예외 상황을 미리 정의한다.
이 스킬이 실행되면 Claude Code는 엔지니어링 리드의 역할을 맡아 다음을 수행한다:
- 아키텍처 다이어그램: 컴포넌트 간 관계와 데이터 흐름을 Mermaid 또는 텍스트 다이어그램으로 표현
- 인터페이스 정의: API 계약, 데이터 스키마, 타입 정의
- 에지 케이스 목록화: "무엇이 잘못될 수 있는가"를 체계적으로 나열
- 구현 순서 정의: 의존성 기반 태스크 순서화
3.4 Staff Engineer 모드 — /review
이 스킬이 핵심이다. "CI를 통과하는 프로덕션 버그를 찾아라." 테스트가 모두 통과하고, 린터에도 걸리지 않지만 실제 서비스에서는 문제가 되는 버그들이 있다. Race condition, 메모리 누수, 타임아웃 처리 누락, 인증 우회 가능성 같은 것들이다.
/review 스킬은 특히 Greptile 통합이 인상적이다. Greptile은 자동화된 코드 리뷰 도구인데, PR 코멘트를 자동 생성한다. /review 실행 시 이 Greptile 코멘트를 가져와서 세 가지로 분류한다:
- 유효한 이슈: 실제로 수정이 필요한 문제
- 이미 수정됨: 다른 커밋에서 이미 해결된 문제
- False Positive: 실제로는 문제없는 오탐지
3.5 QA Engineer 모드 — /browse, /qa
gstack의 가장 독특한 기술적 특징이 여기에 있다.
/browse는 Claude Code에 실제 "눈"을 달아주는 스킬이다. Playwright를 컴파일한 바이너리를 통해 Claude Code가 실제 브라우저를 조작하고 화면을 확인할 수 있다.
단순한 스크린샷이 아니다. Claude Code가 직접 버튼을 클릭하고, 폼을 입력하고, 네트워크 요청을 확인하며 QA 테스트를 수행한다. 개발자가 "로그인 후 대시보드가 올바르게 표시되는지 확인해줘"라고 요청하면, Claude Code가 실제 브라우저를 열어 테스트한다.
/qa는 한 단계 더 나아간다. diff-aware testing — 코드 변경 사항을 분석해서, 변경으로 인해 영향받을 수 있는 페이지와 기능을 자동으로 식별하고, 그것들을 우선적으로 테스트한다. 변경하지 않은 기능까지 전수 테스트하는 낭비를 줄인다.
/browse 사용 시 주의사항
gstack 공식 가이드는 Chrome-specific MCP 도구 사용을 지양하고, 안정성과 속도를 위해 /browse 스킬 또는 $B <command> 직접 바이너리 호출을 권장한다. /browse는 macOS와 Linux(x64/arm64)에서만 지원된다.
3.6 Release Engineer 모드 — /ship
/ship은 배포의 전 과정을 담당하는 Release Engineer 모드다.
단순히 `git push`가 아니라, 배포 전 체크리스트를 체계적으로 실행한다:
# /ship 실행 시 자동으로 수행하는 단계들 (예상되는 단계 흐름)
1. git sync — 최신 upstream 변경사항 반영
2. 테스트 실행 — 전체 테스트 스위트 통과 확인
3. 코드 리뷰 코멘트 처리 — Greptile 및 팀원 코멘트 트리아지
4. PR 생성 — 제목, 설명, 변경 사항 요약 자동 작성
5. 최종 푸시 — 브랜치 푸시 및 PR 링크 출력
3.7 세션 매니저 — /setup-browser-cookies
인증이 필요한 페이지를 테스트할 때 필요한 스킬이다. 실제 브라우저의 쿠키와 세션 정보를 가져와서, Claude Code의 /browse 스킬이 로그인된 상태로 테스트를 수행할 수 있게 한다. 관리자 페이지, 사용자 대시보드 등 로그인 후에만 접근 가능한 화면을 자동화 테스트할 때 사용한다.
3.8 회고 매니저 — /retro
/retro는 엔지니어링 매니저 역할로서 팀 회고를 생성한다. 단순한 템플릿 채우기가 아니라, 실제 팀 메트릭(배포 횟수, 버그 발생률, PR 리뷰 시간 등)을 기반으로 팀별, 개인별 맞춤 피드백을 작성한다. 스프린트 회고를 자동화하고 싶은 팀에게 유용하다.
4. 설치 및 셋업 방법 (단계별 가이드)
gstack 설치는 Claude Code 내부에서 설치 커맨드를 붙여넣는 방식으로 진행된다. 설치 스크립트가 나머지를 자동으로 처리한다.
4.1 사전 준비
Claude Code가 처음이라면?
gstack은 Claude Code(Anthropic의 터미널 기반 AI 코딩 에이전트) 위에서 동작한다.
Claude Code는 유료 구독이 필요하며, Pro($20/월) 또는 Max($100/월 또는 $200/월) 플랜에서 사용 가능하다 (2026년 3월 기준). API 키(종량제)로도 사용할 수 있다. Claude Code 자체의 설치/구독이 먼저 되어 있어야 gstack을 사용할 수 있다.
설치 (공식 권장): curl -fsSL https://claude.ai/install.sh | bash
또는 npm: npm install -g @anthropic-ai/claude-code (deprecated, 아직 작동)
공식 가이드: docs.anthropic.com/en/docs/claude-code
"슬래시 커맨드"와 "스킬"이란?
Claude Code에서 /를 입력하면 사용 가능한 커맨드 목록이 나타난다. 이것이 슬래시 커맨드다.
스킬(Skill)은 ~/.claude/skills/ 디렉토리에 SKILL.md 파일로 정의되는 확장 기능이다.
gstack을 설치하면 이 디렉토리에 29개의 스킬이 추가되어, /office-hours, /review 등의 새로운 슬래시 커맨드를 사용할 수 있게 된다.
# 1. Bun 설치 (아직 없다면)
curl -fsSL https://bun.sh/install | bash
# ⚠️ 설치 후 터미널을 재시작하거나 아래 명령어 실행:
source ~/.bashrc # 또는 source ~/.zshrc (macOS 기본)
# 2. Bun 버전 확인
bun --version
# 1.0 이상이어야 함
# 3. Claude Code 설치 확인
claude --version
# 설치되어 있지 않다면: curl -fsSL https://claude.ai/install.sh | bash
4.2 글로벌 설치 (Claude Code — 개인 사용)
터미널에서 아래 커맨드를 실행한다.
git clone 후 setup 스크립트가 브라우저 바이너리 컴파일과 설정을 자동 처리한다.
(출처: gstack README)
# Claude Code 글로벌 설치 (개인)
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && \
cd ~/.claude/skills/gstack && ./setup설치 성공 확인 방법
설치가 완료되면 Claude Code를 재시작하고 /를 입력해본다. /office-hours, /review 등 gstack 스킬이 자동완성 목록에 나타나면 성공이다. 나타나지 않으면 cd ~/.claude/skills/gstack && ./setup을 다시 실행한다.
4.3 프로젝트별 팀 설치
팀 전체가 같은 셋업을 사용하고 싶다면 프로젝트 레벨로 복사한다.
바이너리와 의존성은 `.gitignore`에 추가되며, 팀원 각자가 setup 스크립트를 한 번씩 실행해서 로컬에 컴파일한다.
# 프로젝트별 설치 (팀 공유)
cp -Rf ~/.claude/skills/gstack .claude/skills/gstack && \
rm -rf .claude/skills/gstack/.git && \
cd .claude/skills/gstack && ./setup
4.4 Codex / Gemini CLI 설치 (신규)
gstack은 이제 Claude Code 외에도 OpenAI Codex CLI, Gemini CLI, Cursor를 지원한다.
SKILL.md 표준을 통해 호환되며, 설치 시 --host 플래그로 대상을 지정한다. --host auto를 사용하면 설치된 에이전트를 자동으로 감지한다.
(참고: Factory Droid 지원은 CHANGELOG v0.13.8.0(2026-03-29)에서 공식 제거되었다. README에 일부 흔적이 남아 있으나 현재는 미지원이다.)
# Codex CLI 설치 (레포 로컬)
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git .agents/skills/gstack && \
cd .agents/skills/gstack && ./setup --host codex
# Codex CLI 설치 (유저 글로벌)
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/gstack && \
cd ~/gstack && ./setup --host codex
# 에이전트 자동 감지 (Codex, Gemini, Cursor 등 설치된 것 자동 탐지)
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/gstack && \
cd ~/gstack && ./setup --host auto⚠️ 설치 커맨드 최신 확인
gstack은 빠르게 진화 중이다. 설치 방식이 업데이트될 수 있으므로 공식 README에서 최신 커맨드를 확인하는 것을 권장한다.
5. CLAUDE.md 및 설정 파일 구조
CLAUDE.md란?
CLAUDE.md는 Claude Code가 프로젝트를 이해하는 데 사용하는 설정 파일이다. 프로젝트 루트 또는 ~/.claude/ 디렉토리에 위치하며, 프로젝트 컨텍스트, 규칙, 사용 가능한 스킬 목록 등을 기술한다. Claude Code는 대화를 시작할 때 이 파일을 자동으로 읽어 컨텍스트로 활용한다. gstack을 설치하면 이 파일에 gstack 스킬 목록이 자동으로 추가된다.
gstack 설치 후 `~/.claude/` 또는 프로젝트의 `.claude/` 디렉토리 구조를 살펴보면 다음과 같다:
~/.claude/
├── CLAUDE.md # 메인 설정 파일 (gstack 스킬 목록 포함)
└── skills/
└── gstack/
├── CLAUDE.md # gstack 전용 개발 가이드
├── ARCHITECTURE.md # 시스템 아키텍처 문서
├── BROWSER.md # 브라우저 자동화 가이드
├── browse/ # Playwright 브라우저 CLI
├── qa/ # QA 자동화 스킬
├── plan-ceo-review/ # CEO 리뷰 스킬
│ └── SKILL.md
├── plan-eng-review/ # EM 리뷰 스킬
│ └── SKILL.md
├── review/ # Staff Engineer 리뷰 스킬
│ └── SKILL.md
├── ship/ # Release Engineer 스킬
│ └── SKILL.md
├── setup-browser-cookies/
│ └── SKILL.md
├── retro/
│ └── SKILL.md
└── .gstack/ # 세션 데이터 (병렬 실행 시)
CLAUDE.md 설정 예시
gstack이 설치되면 메인 `CLAUDE.md`에 스킬 목록이 자동으로 추가된다. 개발자가 직접 커스터마이징할 수 있는 형태는 대략 다음과 같다 (⚠️ 추정: 실제 형식은 공식 레포에서 확인):
# CLAUDE.md (예시 — ⚠️ 추정 기반 재구성)
## Project Context
[프로젝트 설명]
## gstack Skills
다음 슬래시 커맨드를 사용해 개발 워크플로우를 진행한다:
- /plan-ceo-review : 창업자 시각에서 문제 재정의 및 10배 솔루션 탐색
- /plan-eng-review : 아키텍처 확정, 데이터 플로우, 에지 케이스 정의
- /review : Staff Engineer 수준의 프로덕션 버그 탐색
- /ship : 싱크 → 테스트 → PR 생성 → 배포
- /browse : Playwright 브라우저로 실제 화면 확인
- /qa : diff 기반 자동화 테스트
- /retro : 팀 메트릭 기반 회고 생성
## Workflow Philosophy
Planning is not review. Review is not shipping.
Each skill activates a distinct cognitive mode — do not blend them.
## Tech Stack
[프로젝트 기술 스택]
## Key Rules
- /browse 사용 시 Chrome MCP 도구 금지, gstack 바이너리 사용
- SKILL.md 파일은 템플릿에서 자동 생성 — 직접 수정 금지
SKILL.md 파일 구조
gstack의 중요한 내부 규칙이 있다: SKILL.md 파일은 `.tmpl` 템플릿에서 자동 생성된다. 직접 편집하면 안 되고, 템플릿 파일을 수정한 후 생성 스크립트를 실행해야 한다. 이 구조는 일관성을 보장하고 실수를 방지한다.
# SKILL.md 수정 방법 (올바른 방법)
# 1. 템플릿 파일 수정
# ⚠️ 아래는 추정 기반 예시 — 실제 명령은 공식 레포 CONTRIBUTING.md 참조
vim plan-ceo-review/SKILL.md.tmpl
# SKILL.md 재생성 (정확한 명령은 레포에서 확인)
bun run gen:skill-docs # 또는 다른 빌드 스크립트일 수 있음
# 틀린 방법 (하면 안 됨)
# vim plan-ceo-review/SKILL.md ← 직접 수정 금지
6. Conductor와의 병렬 실행
gstack은 단독으로도 강력하지만, Conductor와 함께 사용할 때 진가를 발휘한다.
Conductor는 여러 Claude Code 세션을 격리된 워크스페이스에서 동시에 실행하는 도구다.
(Garry Tan은 10~15개의 병렬 스프린트를 동시에 실행한다고 밝혔다.)
gstack + Conductor 조합으로 가능한 것:
- 10개의 전문화된 Claude Code 세션 동시 실행
- 각 세션이 독립된 브라우저 인스턴스와 쿠키를 갖고 있어 포트 충돌 없음
- 세션별 로그와 상태가 .gstack/ 디렉토리에 분리 저장
- 예: CEO 리뷰 세션 + 코드 리뷰 세션 + QA 세션을 동시에 병렬 실행
병렬 실행 시나리오 예시
새로운 기능을 개발할 때:
세션 1 — /plan-ceo-review: "이 기능이 정말 사용자에게 필요한가? 더 나은 대안은?"
세션 2 — /plan-eng-review: 아키텍처 설계 및 데이터 플로우 작성
세션 3 — /review: 기존 코드베이스에서 영향받는 부분 분석
세션 4 — /qa: 현재 테스트 커버리지 확인 및 테스트 계획 수립
이 4개 세션이 동시에 병렬로 실행되어, 혼자서도 팀처럼 일하는 것이 가능하다.
7. 이 방식의 장점과 한계
장점
- 인지 모드 분리의 효과: 기획할 때는 기획자처럼, 리뷰할 때는 엔지니어처럼 사고하도록 강제함으로써 각 단계의 품질이 높아진다. "범용 모드"에서 발생하는 타협 없이 각 역할의 전문성을 최대한 끌어낸다.
- 일관성: 슬래시 커맨드 하나로 복잡한 워크플로우를 재현할 수 있다. 팀원이 바뀌어도, 시간이 지나도 동일한 프로세스를 따른다.
- 브라우저 자동화 통합: /browse와 /qa를 통해 실제 시각적 검증을 자동화할 수 있다. "화면에 버튼이 보이는지 확인해줘" 수준의 QA를 AI가 처리한다.
- Greptile 통합: 자동화된 코드 리뷰 도구를 트리아지하는 기능이 실전에서 매우 유용하다. 오탐지 필터링이 수동 리뷰 시간을 크게 줄인다.
- 검증된 생산성: Garry Tan 본인이 gstack으로 일당 10,000~20,000 LOC를 파트타임으로 유지했다고 밝혔다. 주간 회고 기준 140,751줄 추가, 362 커밋, 약 115K net LOC를 기록했으며, 총 600,000줄 이상의 프로덕션 코드(35%가 테스트)를 작성했다. (출처: gstack README — 자체 보고 수치)
- 멀티 에이전트 지원: Claude Code 전용이 아닌, Codex·Gemini CLI·Cursor까지 지원하여 도구 종속성을 줄인다.
--host auto플래그로 설치된 에이전트를 자동 감지한다. - 보안 스킬 내장: /cso(OWASP Top 10 + STRIDE), /careful, /freeze, /guard 등 안전 가드레일이 기본 내장되어 프로덕션 실수를 방지한다.
- 오픈소스 + YC의 신뢰: MIT 라이선스, 56,000+ 스타(2026-03-30 기준), YC CEO가 실제 사용하는 셋업이라는 점에서 실전 검증이 된 방법론이다.
한계 및 주의사항
- 진입 장벽: Bun 설치, 바이너리 컴파일, Claude Code 숙련도가 필요하다. 초보자에게는 어렵다.
- Windows 제한적 지원: /browse 스킬은 macOS와 Linux에서 가장 안정적이다. Windows 11에서는 Git Bash 또는 WSL을 통해 사용 가능하나, Bun 버그(bun#4253)로 인해 Node.js가 추가로 필요하다. (출처: README)
- 비용: 병렬 Claude Code 세션 실행은 API 비용이 빠르게 증가할 수 있다. gstack 자체 문서에서도 테스트 실행 비용을 명시적으로 언급한다 (eval 테스트 ~$4/회, E2E ~$3.85/회).
- Conductor 의존성: 병렬 실행의 진정한 가치는 Conductor와 함께 사용해야 나온다. 별도 도구 학습이 필요하다.
- 영어 중심: 스킬 파일이 영어로 작성되어 있으며, 한국어 맥락에서의 최적화는 별도 커스터마이징이 필요할 수 있다.
8. 커뮤니티 반응 — 찬사와 논쟁
gstack은 2026년 3월 공개 이후 48시간 만에 GitHub 스타 10,000개를 돌파하며 역대 가장 빠르게 성장한 개발 도구 중 하나가 되었다. 동시에 뜨거운 찬반 논쟁도 불러일으켰다.
TechCrunch가 "Why Garry Tan's Claude Code setup has gotten so much love, and hate"이라는 제목으로 보도할 정도였다.
긍정적 반응
| 출처 | 핵심 반응 |
|---|---|
| GitHub | 48시간 만에 10K+ 스타, 2주 만에 47,800+ 스타. 2026년 가장 빠른 개발 도구 성장 기록 (2026-03-26 기준) |
| Reddit 500+ 개발자 종합 (Dev.to) | "install staff engineer brain" — 체크리스트 기반 사고방식을 빌려오는 느낌이라 주니어 개발자에게 특히 유용 |
| 보안 커뮤니티 | 구조화된 리뷰 스킬이 실제 XSS 취약점을 발견한 사례 보고. 사람이 놓칠 수 있는 미묘한 보안 결함 탐지 (출처: Junia AI 종합 분석) |
| 스타트업 생태계 | 워크플로우 표준화 도구로서의 가치 인정. 팀원마다 AI 활용 격차가 큰 문제("같은 AI인데 왜 결과가 다르지?")를 해결 (출처: Agent Native Medium) |
| Product Hunt | #3 Day Rank, 457 업보트. "persistent browser daemon이 진짜 기술적 기여"라는 평가 (출처: Product Hunt 직접 조회, 2026-03-26) |
| Hacker News | 계획 리뷰와 코드 리뷰를 분리하는 설계가 아키텍처적으로 건전하다는 평가. gstack++ C++ 포크가 등장할 정도로 커뮤니티 확장 |
| 한국 Threads | @choi.openai, @github.awesome 등 한국 AI 인플루언서들이 설치 가이드 공유. "코딩 전에 두 개의 플래닝 스킬을 먼저 사용하는 구조"에 주목 |
| GeekNews (긱뉴스) | "Claude Code로 만드는 가상 엔지니어링 팀"으로 소개. 한국 개발자 커뮤니티에서 적극적 수용 |
| Xiao Tan (X.com) | "제 사소한 피드백이 실제로 반영될 줄 몰랐다. small indie founders에게 스타트업 멘토가 생긴 것 같다." — /office-hours를 더 엄격하게 해달라는 중국 커뮤니티 피드백이 실제 업데이트로 이어진 사례. 오픈소스 커뮤니티 피드백 루프의 실제 작동을 보여줌 |
| Garry Tan (X.com — Python 에이전트 지원) | "It works with any python agent! Neat. Had no idea." — Hacker News 토론에서 Claude Code 전용 여부 질문 후 Garry Tan이 직접 확인. gstack은 SKILL.md 표준을 따르는 모든 Python 에이전트에서 작동 (출처: Garry Tan X.com 직접 발언) |
부정적 반응 / 비판
| 출처 | 핵심 비판 |
|---|---|
| Mo Bitar (개발자/블로거) | "결국 텍스트 파일에 담긴 프롬프트 모음" — 이미 Claude Code 사용자 다수가 자체적으로 만들어 쓰던 것과 다르지 않다 (출처: CryptoRank 종합 보도) |
| Reddit/HN 회의론자 | YC CEO라는 지위가 도구의 독창성이 아닌 가시성을 만들었다는 비판. "같은 걸 무명 개발자가 올렸으면 100 스타도 못 받았을 것" |
| 시니어 엔지니어 그룹 | "시니어 판단력의 환상을 만든다" — 실제 이해 없이 체크리스트만 따르면 위험할 수 있다는 우려 (출처: Luong Nguyen Medium 분석) |
| 비용 우려 | 병렬 세션 실행 시 API 비용이 빠르게 증가. 개인 개발자에게는 부담스러울 수 있다 (출처: SitePoint 튜토리얼) |
| Product Hunt (Sherveen Mashayekhi) | "YC CEO가 아니었으면 PH에 올라오지도 못했을 것" — Free Agency 창업자의 직접적 비판 |
| AI Sycophancy 논쟁 | "전문가에게는 속도를 높이고, 초보자에게는 전문가인 듯한 착각을 만든다" — 3,000명 참가 연구에서 AI 챗봇이 과신을 증가시킨다는 결과를 gstack에 적용한 분석 |
| Hacker News — 에이전트 루프 버그 사례 | "에이전트가 70분간 루프에 빠져 스테이징 URL을 프로덕션 설정 파일에 반복 주입했다" — 자동화 스킬 사용 시 의도치 않은 파괴적 동작 가능성을 경고한 HN 댓글. gstack의 /careful·/freeze 가드레일이 필요한 이유를 역설적으로 보여주는 사례 (출처: HN item#47355173 댓글) |
| Hacker News — CTO 해고 역설론 | "AI 프롬프트 셋이 CTO보다 먼저 XSS 취약점을 발견했다면, 그 CTO는 해고되어야 한다" — Garry Tan의 CTO 친구가 gstack으로 XSS를 발견했다는 에피소드에 대한 역설적 반박. AI가 보완재가 아닌 대체재가 되는 상황에 대한 불편한 질문 |
| Reddit / HN — LOC 지표 비판 | "600,000줄 코드로 무엇을 만들었나?" — LOC(코드 줄 수)는 나쁜 성과 지표라는 오랜 공학 원칙을 들어, Garry Tan의 생산성 수치 자랑 자체를 문제 삼는 비판. AI가 생성하는 보일러플레이트 코드가 LOC를 인위적으로 부풀린다는 우려 포함 |
Garry Tan의 대응
비판에 대해 Garry Tan은 직접 반박했다. "This is exactly why I released gstack. Rather than assume I'm doing it wrong, how about you try and see it work for you. I'll give you a money back guarantee, which is easy because it's free open source."
(이것이 바로 내가 gstack을 공개한 이유다. 내가 잘못하고 있다고 단정하기보다는, 직접 사용해보고 너에게도 잘 맞는지 확인해보는 건 어떨까? 환불 보장(money back guarantee)도 해줄게 — 물론 무료 오픈소스(free open source)라서 환불도 아주 쉽지만 말이야.)
중국 커뮤니티의 피드백은 실제 기능 개선으로 이어졌다 — "Chinese Twitter said that /office-hours in gstack was not hard enough on founders, so I made them harder."
(“중국 트위터에서 gstack의 /office-hours 기능이 창업자들에게 충분히 엄격하지 않다고 하길래, 그래서 나는 그것을 더 빡세게 만들었다.”)
Garry Tan의 주목할 만한 추가 발언
공개 이후 Garry Tan은 X.com에서 gstack의 맥락을 이해하는 데 중요한 발언들을 추가로 남겼다.
"GStack은 실제 YC 배치의 10%에 불과하다"
"GStack is only 10% power of what it's like to actually come and go through a Y Combinator batch." — gstack이 YC 경험의 대체재가 아니라는 직접적인 한계 인정. /office-hours 스킬이 실제 YC 창업자 멘토링의 일부만 재현한다는 솔직한 자기 평가다. 이 발언은 gstack 과대 기대를 교정하는 중요한 맥락이다.
"어떤 Python 에이전트에서도 작동한다"
"It works with any python agent! Neat. Had no idea." — Hacker News 토론에서 Claude Code 전용 여부를 묻는 질문에 Garry Tan이 직접 답변. SKILL.md 표준을 따르는 Python 에이전트라면 모두 호환된다. Claude Code·Codex 외 더 광범위한 에이전트 생태계 지원이 확인된 셈이다.
"/autoplan이 권장 방법이다"
Garry Tan은 이후 /plan-ceo-review → /plan-eng-review 순차 실행 대신 /autoplan 단일 커맨드를 직접 권장하기 시작했다. CEO → Design → Eng 리뷰를 자동 순차 실행하며, "taste decisions"만 사용자에게 질문하는 방식이다. 처음 gstack을 접한다면 /autoplan이 가장 진입하기 쉬운 시작점이다.
병원 병상 옆에서 코딩한 인간적 맥락
"I am coding a lot, GStack is helping me do it, but also... last week my mom was in the hospital... I was coding by her bedside too." — gstack 공개 직후 Austin 폭설로 발이 묶인 상태, 어머니 입원이라는 개인적 어려움 속에서도 코딩을 이어간 에피소드. 도구 홍보 맥락과 별개로, AI 코딩 도구가 삶의 어떤 상황에서도 생산성을 유지할 수 있게 한다는 현실적 사례다.
이 반응들이 보여주는 것
찬반이 갈리는 핵심은 "구조화된 프롬프트가 실제 전문성을 대체할 수 있는가?"라는 질문이다. 긍정론은 "최소한 일관된 품질 바닥선을 만든다"는 입장이고, 부정론은 "바닥선이 아니라 천장의 환상을 만든다"는 입장이다. sycophancy 연구가 시사하듯, 같은 도구가 사용자 수준에 따라 다른 효과를 낳는다. 실용적 관점에서는, gstack의 가치는 도구 자체보다 "개발 프로세스를 명시적으로 구조화한다"는 방법론에 있다. 프롬프트는 포크해서 바꿀 수 있지만, 역할 분리라는 사고 습관은 코드로 옮기기 전에 먼저 체득해야 한다.
9. 실전 활용: Codex 주간 리밋 후 gstack + Claude Code 워크플로우
2026년 3월 현재, OpenAI Codex는 Plus 구독자에게 주간 사용량 제한을 적용하고 있다.
복잡한 프롬프트로 빠르게 사용량을 소진하거나, 주간 리밋에 도달했다는 사례가 커뮤니티에서 자주 보고된다. (참고: Codex Usage Limits 토론, OpenAI 공식 Codex 플랜 안내)
이 상황에서 커뮤니티에서 공유되는 워크플로우가 있다. Codex 리밋이 걸렸을 때 Claude Code + gstack으로 전환하여, 시간은 더 걸리더라도 품질 면에서 만족스러운 결과를 내는 방식이다. gstack이 Claude Code뿐 아니라 Codex까지 지원하게 되면서, 두 도구를 상호 보완적으로 쓰는 패턴이 자연스럽게 생겼다.
6단계 하이브리드 워크플로우
상황: Codex 주간 리밋 도달 → Claude Code로 전환
Step 1. gstack 설치 — Claude Code에 gstack 글로벌 설치
Step 2. /office-hours — gstack의 YC Office Hours 스킬로 구현 계획을 수립. 6가지 강제 질문으로 문제를 재정의하고 디자인 문서를 생성
Step 3. /plan-ceo-review · /plan-eng-review · /plan-design-review — 필요에 따라 CEO, 엔지니어링, 디자인 관점의 리뷰를 실행. 각 관점에서 계획의 빈틈을 찾아낸다
Step 4. 구현 실행 — 계획이 충분히 다듬어지면 Claude Code(또는 리밋이 풀린 Codex)로 구현. ralph-loop 등 자동화 도구를 활용하면 "이 계획 적용해줘" 한마디로 실행 가능
Step 5. /review — Staff Engineer 모드로 구현된 코드를 리뷰. CI를 통과하지만 프로덕션에서 문제가 될 수 있는 버그를 탐색
Step 6. /qa — diff-aware 테스트로 변경 사항의 영향 범위를 검증. /browse로 실제 화면 확인까지
왜 시간이 더 걸려도 품질이 만족스러운가?
핵심은 "계획에 투자하는 시간"이다. Codex는 빠르게 코드를 생성하지만, 그 전에 충분한 계획이 없으면 잘못된 방향으로 빠르게 달리는 셈이다.
gstack의 /office-hours → /plan-*-review 파이프라인은 코딩 전에 충분한 시간을 투자해서 문제를 정확히 정의한다. 이 "느린 시작"이 결과적으로 재작업을 줄이고 전체 품질을 높인다.
Garry Tan 본인도 "The sprint structure is what makes parallelism work — without process, ten agents equals ten sources of chaos"(스프린트 구조(sprint structure)가 바로 병렬성(parallelism)을 제대로 작동하게 만드는 핵심이다 — 프로세스(process)가 없다면, 10개의 에이전트는 곧 10개의 혼란의 원천이 될 뿐이다.)라고 설명한다.
(출처: gstack README)
gstack /codex 스킬: 크로스 모델 검증
흥미로운 점은 gstack 자체에 /codex 스킬이 내장되어 있다는 것이다. OpenAI Codex CLI를 통해 독립적인 Second Opinion을 받을 수 있다. 3가지 모드를 제공한다:
- Review 모드: 코드 리뷰 pass/fail 게이트. Claude의 /review와 Codex의 /codex를 모두 실행하면 크로스 모델 분석 제공
- Adversarial 모드: 적대적 챌린지. Claude가 작성한 코드를 Codex가 공격적으로 검증
- Open Consultation 모드: 특정 질문에 대해 다른 관점을 얻기 위한 오픈 상담
이 기능 덕분에 Codex 리밋 상황에서도 "계획은 gstack으로, 리밋이 풀리면 /codex로 크로스 체크"하는 전략이 가능하다.
10. 튜토리얼 : 처음 gstack 써보기
설치가 끝났다면 실제로 써보자.
아래 튜토리얼은 gstack 공식 docs/skills.md와 README의 예시를 기반으로 재구성했다.
(출처: gstack 공식 문서, 2026-03-26 기준)
시나리오: "일정 관리 앱에 일일 브리핑 기능 추가하기"
이 튜토리얼은 기존 프로젝트에 기능을 추가하는 시나리오다. 아직 프로젝트가 없다면, 간단한 테스트 프로젝트(예: npx create-next-app my-test-app)를 하나 생성한 뒤 진행하면 된다.
여러 Google 캘린더를 관리하다 보면 이벤트 정보가 오래되거나 장소가 틀린 경우가 있고, 미팅 준비 시간이 너무 오래 걸린다. 이 문제를 해결하는 "일일 브리핑 기능"을 추가하려 한다. gstack 전체 워크플로우를 처음부터 끝까지 따라가 본다.
Step 1: /office-hours — 문제 찾기 (5~10분)
코드 한 줄도 쓰기 전에 /office-hours로 시작한다. 6가지 강제 질문으로 "일일 브리핑 앱"이라는 생각을 검증한다.
Claude Code에 입력:
일정 관리 앱에 일일 브리핑 기능을 추가하려 한다.
/office-hoursClaude의 응답 (gstack README 공식 예시 기반):
잠깐. "일일 브리핑 앱"이라고 하셨는데, 실제로 묘사하신 것은 개인 비서 AI(personal chief of staff AI)에 가깝습니다.
몇 가지 구체적인 고통에 대해 더 파고들겠습니다:
1. 지금은 이 문제를 어떻게 처리하고 있나요?
2. 브리핑이 실패하는 구체적인 순간이 언제인가요?
3. 이 기능 없이 가장 불편했던 실제 사례는?
[답변 후 AI 분석]
제가 발견한 것:
- "일일 브리핑"이 아니라 준비 자동화 문제입니다
- 5가지 기능을 동시에 묘사하셨는데, 내일까지 배포 가능한 최소 버전은: 다음 미팅 10분 전 자동 알림입니다
- [3가지 구현 대안과 예상 작업량 제시]
권장: 가장 좁은 버전을 내일 배포하세요.
[디자인 문서를 ~/.gstack/projects/에 저장 완료]
무엇이 달라지는가? 범용 Claude Code에 같은 요청을 했다면 바로 코딩을 시작했을 것이다. /office-hours는 방향 자체를 재정의하고, 이 디자인 문서가 이후 모든 스킬의 입력이 된다.
Step 2: /autoplan — 기획·디자인·엔지니어링 리뷰 자동 실행 (5분)
/plan-ceo-review → /plan-design-review → /plan-eng-review를 수동으로 순차 실행하는 대신, /autoplan 하나로 자동화한다. 판단이 필요한 "taste decisions"만 사용자에게 질문한다. (출처: Garry Tan X.com)
Claude Code에 입력:
/autoplan실행 결과 — Review Readiness Dashboard (gstack docs/skills.md 공식 예시):
+====================================================================+
| REVIEW READINESS DASHBOARD |
+====================================================================+
| Review | Runs | Last Run | Status | Required |
|-----------------|------|---------------------|-----------|----------|
| Eng Review | 1 | 2026-03-16 15:00 | CLEAR | YES |
| CEO Review | 1 | 2026-03-16 14:30 | CLEAR | no |
| Design Review | 0 | — | — | no |
+--------------------------------------------------------------------+
| VERDICT: CLEARED — Eng Review passed |
+====================================================================+Eng Review가 유일한 필수(Required) 게이트다. CLEAR가 되면 구현을 시작할 수 있다.
계획이 확정됐다. 이제 Claude Code로 실제 구현을 진행한다 (gstack README 예시 기준: 약 8분, 11개 파일, 2,400줄 작성).
Step 3: /review — Staff Engineer 코드 감사 (3분)
코딩이 끝났다면 Staff Engineer 모드로 검토한다. CI를 통과하더라도 프로덕션에서 문제가 될 수 있는 버그를 찾는다. N+1 쿼리, 레이스 컨디션, 누락된 타임아웃, 잘못된 재시도 로직 등을 자동으로 탐색한다.
Claude Code에 입력:
/review실행 결과 (gstack README 공식 예시 기반):
[AUTO-FIXED] 2건 자동 수정됨
• auth/session.ts:147 — 만료 토큰 자동 갱신 누락
• api/calendar.ts:89 — API 타임아웃 처리 누락
[ASK] 판단이 필요한 항목 1건:
• services/sync.ts:203 — 두 캘린더 동기화 요청이 동시에 들어올 때 race condition 발생 가능.
뮤텍스(mutex)를 추가하면 안전하지만 성능이 약간 낮아집니다. 추가할까요? [Y/N]
포인트: [AUTO-FIXED]는 Claude가 판단 없이 고쳐도 되는 명확한 버그다. [ASK]는 트레이드오프가 있어 개발자의 결정이 필요한 항목이다 — 기술적 가능성을 제시하고 결정은 사람이 한다.
Step 4: /qa — 실제 브라우저 자동화 테스트 (5분)
코드 리뷰가 끝났다면 실제 Chromium 브라우저로 앱을 테스트한다. /qa는 diff-aware로 변경 사항이 영향을 미치는 페이지를 먼저 테스트하고, 버그를 발견하면 atomic commit으로 수정한 뒤 회귀 테스트까지 자동 생성한다.
Claude Code에 입력:
/qa https://localhost:3000실행 과정 (기능 설명 기반 예시, [ESTIMATE]):
git diff 분석 중... 브리핑 API, 알림 컴포넌트 변경 감지
실제 Chromium 시작 중... (첫 실행 ~3초, 이후 ~100ms/명령)
[1/4] /dashboard — 브리핑 카드 렌더링
[2/4] /settings/notifications — 알림 설정 저장
[3/4] /api/briefing/generate — 응답 2.3초 (권장: 2초 이하)
[4/4] 캘린더 연결 해제 시 fallback 화면 버그 발견
[AUTO-FIX] 오류 화면 → 빈 상태 UI로 수정 후 커밋
회귀 테스트 자동 생성: tests/calendar-disconnected.spec.ts
앱 건강 점수: 72/100 → 89/100
[ESTIMATE] 위 출력 형식은 /qa의 공식 기능(diff-aware 테스트, auto-fix, 회귀 테스트 생성, Health Score)을 기반으로 재구성한 예시입니다. 실제 출력 형식은 다를 수 있습니다.
팁 — 로그인이 필요한 페이지 테스트: 먼저
/setup-browser-cookies를 실행한다. Chrome/Arc/Brave/Edge의 실제 쿠키를 가져와 헤드리스 브라우저에 임포트하므로, 로그인된 상태로 대시보드·관리자 페이지를 테스트할 수 있다.
Step 5: /ship — PR 생성 및 배포 (2분)
주의: /ship은 실제로 코드를 push하고 PR을 생성한다
/ship은 데모가 아닌 실제 git push + PR 생성을 수행한다. 처음 gstack을 테스트한다면 별도의 테스트 레포를 만들어 사용하는 것을 권장한다. 프로덕션 레포에서 실수를 방지하려면 먼저 /careful 또는 /freeze를 실행하여 안전 가드레일을 활성화할 수 있다.
QA까지 통과했다면 이제 배포할 차례다. /ship이 main 싱크, 테스트 실행, 커버리지 감사, PR 생성을 한 번에 처리한다.
Claude Code에 입력:
/ship실행 결과 (gstack README 공식 예시):
main 최신화 중...
테스트 실행 중...
커버리지: 42 → 51 테스트 (+9 신규)
PR 생성 완료: https://github.com/you/calendar-app/pull/42
보너스: /retro — 주간 회고 (1분)
한 주가 끝나면 /retro로 팀 메트릭과 개인별 피드백을 확인한다. 팀원 전체를 다루려면 /retro global로 프로젝트 전체 집계도 볼 수 있다.
Claude Code에 입력:
/retro실행 결과 (gstack docs/skills.md 공식 예시):
3월 1일 주차: 47 커밋 (팀 3명) | 3,200 LOC | 테스트 비율 38% | PR 12개 | 피크: 오후 10시 | 스트릭: 47일
나의 이번 주
32 커밋, +2,400 LOC, 테스트 41%. 피크: 오후 9~11시
가장 큰 성과: 쿠키 임포트 시스템 (브라우저 복호화 + 피커 UI)
잘 한 것: 암호화, UI, 18개 유닛 테스트를 하나의 집중된 푸시로 완성
팀원 Alice
12 커밋, app/services/ 집중. 모든 PR 200 LOC 이하
기회: 테스트 비율 12% — 결제 기능이 복잡해지기 전에 보강 권장
전체 스프린트 워크플로우 요약
/office-hours 문제 재정의 (5~10분)
→ /autoplan CEO·디자인·엔지니어링 리뷰 자동화 (5분)
→ 구현 (시간 가변, Claude Code 기본 기능)
→ /review Staff Engineer 코드 감사 (3분)
→ /qa 브라우저 자동화 테스트 (5분)
→ /ship PR 생성 (2분)
→ /retro 주간 회고 (주 1회)
gstack 오버헤드: 약 25분 | 가장 큰 가치: /office-hours에서 방향을 제대로 잡는 10분
11. 직접 따라하기 — 나만의 역할별 에이전트 셋업
gstack을 그대로 사용하는 것 외에도, 이 철학을 응용해서 자신만의 역할별 CLAUDE.md를 만들 수 있다. gstack 없이도 핵심 아이디어를 적용하는 방법을 소개한다.
Step 1: 역할 매핑하기
내 프로젝트에서 어떤 역할이 필요한지 먼저 정의한다. 소규모 스타트업이라면 다음 정도가 실용적이다:
# 나만의 역할 정의 예시
역할 1: PM/기획 모드
→ "이 기능이 왜 필요한가? 사용자 가치는 무엇인가?"
→ 요구사항 명확화, 우선순위 결정
역할 2: 아키텍처 모드
→ "어떻게 구현할 것인가? 확장성은?"
→ 기술 스택 결정, 데이터 모델 설계
역할 3: 구현 모드 (일반 Claude Code 사용)
→ 실제 코드 작성
역할 4: 리뷰 모드
→ "버그는 없는가? 보안 이슈는? 성능은?"
→ 엄격한 시각으로 코드 재검토
역할 5: 배포 모드
→ 체크리스트 기반 배포 진행
Step 2: 역할별 CLAUDE.md 섹션 작성
단일 CLAUDE.md 파일 내에 역할별 섹션을 만들거나, 역할별로 별도 파일을 만들어 "지금은 이 모드로 동작해줘"라고 지정한다:
# CLAUDE.md — PM 모드 섹션 예시
## [PM 모드] 기획 단계 지침
이 모드에서는 제품 매니저의 시각으로 분석한다.
### 핵심 질문
1. 이 기능이 실제 사용자 문제를 해결하는가?
2. 더 간단한 방법은 없는가?
3. 이 기능 없이 MVP가 가능한가?
4. 성공 지표(metrics)는 무엇인가?
### 산출물
- 사용자 스토리 (User Story)
- 인수 기준 (Acceptance Criteria)
- 우선순위 결정 근거
---
## [아키텍처 모드] 설계 단계 지침
이 모드에서는 시니어 엔지니어의 시각으로 분석한다.
### 핵심 질문
1. 데이터 플로우는 명확한가?
2. 확장성 병목은 어디인가?
3. 에지 케이스는 무엇인가?
4. 기술 부채를 만들지 않는가?
### 산출물
- 아키텍처 다이어그램
- API 인터페이스 정의
- 에지 케이스 목록
Step 3: 실제 사용 — 모드 명시적 전환
Claude Code 대화에서 역할을 명시적으로 선언하고 시작한다:
# 사용 예시
# 기획 단계
"[PM 모드] 사용자 소셜 로그인 기능을 추가하려 한다.
CLAUDE.md의 PM 모드 지침에 따라 분석해줘."
# 아키텍처 단계
"[아키텍처 모드] 소셜 로그인 기능 구현 방법을 설계해줘.
데이터 플로우 다이어그램과 에지 케이스 목록을 포함해줘."
# 리뷰 단계
"[리뷰 모드] 방금 작성한 소셜 로그인 코드를 검토해줘.
CI를 통과하더라도 프로덕션에서 문제가 될 수 있는 부분을 중심으로."
gstack과 나만의 셋업, 뭘 선택해야 하나?
| 상황 | 추천 |
|---|---|
| 빠르게 시작하고 싶다 | gstack 그대로 설치 |
| 브라우저 자동화 QA가 필요하다 | gstack (/browse, /qa) |
| 팀과 공유하고 일관성이 중요하다 | gstack 팀 설치 |
| 내 프로젝트 특성에 맞게 커스터마이징하고 싶다 | 나만의 역할별 CLAUDE.md |
| Bun 설치가 번거롭다 | 나만의 역할별 CLAUDE.md (단순 텍스트) |
| 병렬 에이전트 실행이 필요하다 | gstack + Conductor |
12. 결론
언제 쓰고, 언제 쓰지 않는가?
| 상황 | gstack 추천 여부 | 이유 |
|---|---|---|
| 혼자 개발하는 스타트업 MVP | 강력 추천 | CEO·EM·QA 역할을 혼자 수행해야 할 때 가장 큰 가치를 발휘 |
| 팀의 AI 도구 활용 격차가 큰 경우 | 추천 | 표준화된 워크플로우로 일관된 품질 바닥선 확보 |
| Codex 리밋 소진 시 대안 필요 | 추천 | gstack + Claude Code로 계획·리뷰·QA 파이프라인 유지 가능 |
| 빠른 프로토타이핑만 필요한 경우 | 선택적 | 계획 단계가 오버헤드일 수 있음. /office-hours만 가볍게 사용 가능 |
| 이미 자체 CLAUDE.md가 잘 갖춰진 팀 | 선택적 | gstack의 철학을 참고하되, 기존 셋업에 필요한 부분만 차용 |
| AI 코딩 도구를 처음 접하는 입문자 | 주의 | Claude Code 자체에 먼저 익숙해진 후 도입하는 것이 적합 |
도입 플레이북
- 오늘: github.com/garrytan/gstack README를 읽고
/office-hours한 번 실행해본다. 현재 프로젝트의 가정을 도전해볼 기회다. - 이번 주:
/plan-ceo-review→/plan-eng-review→/review파이프라인을 실제 기능 개발에 적용한다. 역할 분리가 결과물에 어떤 차이를 만드는지 체감한다. - 운영 반영: 팀에 맞게 포크하고 커스터마이징한다. Garry Tan도 "Fork it. Improve it. Make it yours."라고 권한다.
gstack의 진정한 가치는 29개 프롬프트가 아니라, "개발 프로세스를 명시적으로 구조화한다"는 사고방식이다. 프롬프트는 시간이 지나면 바뀌겠지만, 역할 분리와 구조화된 리뷰라는 원칙은 어떤 AI 도구를 쓰든 유효하다.
300x250
'AI > Skills' 카테고리의 다른 글
Contents
소중한 공감 감사합니다