gstack이 뭔지, 한 줄로 정리해봤습니다

gstack은 Claude Code 위에 얹는 역할 기반 워크플로우 팩입니다. Y Combinator CEO Garry Tan이 2026년 3월 14일 오픈소스로 공개했고, 공개 직후 48시간 만에 GitHub Star 23,400개를 넘겼습니다.
(출처: github.com/garrytan/gstack, 2026.03.18 확인)

한마디로 하면 이렇습니다. Claude Code에 /plan-ceo-review, /review, /qa, /ship 같은 슬래시 명령어 15개를 추가해서, Claude가 매번 다른 역할로 응답하게 만드는 것입니다.

“그냥 프롬프트 모음 아닌가?”라는 반응이 바로 나올 텐데, 실제로는 그게 맞습니다 — 그런데도 효과가 나오는 이유가 따로 있습니다. 다음 섹션에서 바로 설명합니다.

Markdown 파일인데 60만 줄이 나온다? 이 수치가 의미하는 것

대부분의 블로그가 “gstack은 15개 슬래시 커맨드 팩”이라고 소개하고 끝냅니다. 근데 공식 README를 직접 읽어보면 Garry Tan이 직접 남긴 수치가 들어있습니다. 그 수치가 생각보다 당황스럽습니다.

핵심은 이겁니다. gstack의 각 슬래시 명령어는 Claude Code에 “역할의 경계”를 심어줍니다. /plan-ceo-review를 실행하면 Claude는 제품 가치와 범위 조정에만 집중하고, 코드 구현은 건드리지 않습니다. /plan-eng-review는 아키텍처·데이터 흐름·장애 모드만 다룹니다.

이 역할 분리가 왜 생산성과 연결되냐면, AI에 “무엇이든 다 해줘”라고 시키면 모델이 컨텍스트 전체를 이해하려다 추론 품질이 떨어지기 때문입니다. 역할을 좁히면 같은 모델에서 더 정밀한 출력이 나옵니다. 단순히 “더 좋은 모델”이 아니라 “더 좁은 질문”이 핵심이라는 게 기존 블로그가 잘 짚지 않는 부분입니다.

실제 공식 예시 시나리오를 보면, /plan-ceo-review 단계에서 “사진 업로드 기능”을 요청하자 Claude가 “그게 진짜 기능이 아닙니다. 리스팅 자동화가 10점짜리 제품입니다”라고 제안을 뒤집었습니다. 이건 일반 ChatGPT 사용 방식에서는 잘 나오지 않는 종류의 응답입니다. 역할 컨텍스트가 응답 방향을 바꾼 것입니다.

15개 역할, 실제로 언제 쓰나요?

gstack v0.3.3 기준으로 현재 15개의 슬래시 커맨드가 제공됩니다. 이 중 처음 사용할 때 실제로 가장 자주 쓰게 되는 것은 4~5개 정도입니다. 전체 흐름을 아래 표로 정리했습니다.

※ 나머지 6개(/design-consultation, /design-review, /qa-only, /setup-browser-cookies, /debug, /document-release)는 고급 사용 시나리오에 해당합니다.

처음 10분 빠른 시작으로는 /plan-ceo-review → /review → /qa 순서를 권장합니다 (공식 README 기준). 이 세 단계만 돌려봐도 gstack이 맞는 워크플로우인지 파악됩니다.

주목할 부분은 /office-hours입니다. 코딩 도구에 “스타트업 제품 검토” 모드가 들어 있다는 게 독특한데, Garry Tan이 YC에서 실제로 창업자와 나누는 방식을 명령어로 만든 것입니다. 기술 도구가 아니라 YC 피드백 세션을 코드 편집기에 박아 넣은 겁니다.

브라우저 데몬이 핵심이라는 말이 맞는 이유

gstack을 소개하는 글들이 공통으로 슬래시 커맨드 목록만 나열하고 끝납니다. 근데 공식 아키텍처 문서를 보면 Garry Tan이 직접 “브라우저가 진짜 어려운 부분이고, 나머지는 거의 Markdown“이라고 적어놨습니다. (출처: 공식 ARCHITECTURE.md)

이게 실제 개발에서 왜 중요하냐면, 기존 AI 코딩 에이전트가 브라우저를 쓸 때는 “스크린샷을 찍거나 외부 디버깅 도구를 연결하는” 방식이 많았습니다. gstack의 /qa는 다릅니다 — 브랜치 diff를 분석해서 변경된 라우트를 특정하고, 그 라우트만 실제 앱 인스턴스에서 클릭해서 테스트합니다. 코드 변경과 실제 브라우저 동작이 연결된 겁니다.

또 하나의 특이한 기술 선택이 Bun 사용입니다. Node.js 대신 Bun을 쓴 이유가 공식 문서에 4가지로 나와 있습니다: 컴파일 바이너리 지원, 네이티브 SQLite 접근 (Chromium의 쿠키 DB 직접 읽기), 네이티브 TypeScript 실행, 내장 HTTP 서버. 이 중 Chromium SQLite 쿠키 DB를 직접 읽는다는 부분이 핵심입니다 — /setup-browser-cookies 명령어로 로컬 Chrome/Arc/Brave에서 쿠키를 헤드리스 세션으로 바로 가져올 수 있습니다.

결론적으로, gstack을 “프롬프트 모음”으로 보면 반쪽짜리 이해입니다. 브라우저 데몬과 Bun 기반 SQLite 연동이 없으면 /qa가 작동하지 않습니다. 그 구조가 있어야 “에이전트가 눈을 가졌다”는 말이 성립합니다.

설치 30초, 그런데 이 조건이 빠져 있습니다

공식 README에는 설치가 30초라고 나와 있습니다. 맞습니다 — 단, 아래 세 가지가 이미 준비된 상태일 때의 이야기입니다.

특히 Bun 미설치 상태에서 /browse를 실행하면 에러로 멈춥니다. 공식 트러블슈팅 문서에서 가장 많이 언급되는 케이스입니다. cd ~/.claude/skills/gstack && bun install && bun run build로 직접 빌드해야 해결됩니다. (출처: 공식 README Troubleshooting 섹션)

또 하나, macOS/Linux에서만 지원됩니다. /browse가 컴파일하는 네이티브 바이너리는 x64와 arm64를 지원하는데, Windows는 공식 지원 목록에 없습니다. (확인 필요: WSL2 환경에서의 작동 여부는 공식 문서에서 보장하지 않음)

설치 자체는 Claude Code 터미널에 아래 한 줄을 붙여넣으면 됩니다. Claude가 나머지를 알아서 처리합니다.

gstack이 안 맞는 상황도 있습니다

솔직히 말하면, gstack을 둘러싼 반응이 반반으로 갈립니다. TechCrunch가 “love and hate”라고 표현했을 정도입니다. 긍정적인 쪽은 이미 위에서 충분히 설명했으니, 여기서는 비판적인 시각을 정리합니다.

비판 측에서 가장 자주 나오는 말은 “this is just prompts in a trench coat(트렌치코트 입은 프롬프트 모음)”입니다. 틀린 말은 아닙니다. 기술적으로 보면 Markdown 파일 묶음이 맞습니다. 문제는 “Markdown이라서 가치가 없다”는 논리가 성립하지 않는다는 겁니다 — 체크리스트도 결국 텍스트입니다.

단, 아래 상황이라면 gstack보다 다른 접근이 더 나을 수 있습니다: ① 이미 자신만의 단단한 AI 코딩 워크플로우가 있는 시니어 엔지니어 — 남의 워크플로우 구조가 오히려 방해가 될 수 있습니다. ② 의료·금융·항공 같은 규제 환경 — “꽤 좋은” 계획이 위험한 경우에는 구조화된 체크리스트가 오히려 과신을 유도할 수 있습니다. ③ 팀 내 기존 SDLC가 잘 작동 중인 조직 — 추가 계층이 프로세스 복잡도만 높일 수 있습니다.

그리고 구조화된 출력이 “더 그럴싸하게 보여서” 검토를 덜 꼼꼼히 하게 만드는 과신 증폭 효과는 실제 리스크입니다. 형식이 예뻐도 내용이 틀릴 수 있다는 점을 잊으면 안 됩니다.

자주 나오는 질문 5가지

마치며

gstack에서 생각해볼 만한 지점은 기술 자체보다 방향입니다. 지금까지 AI 코딩 도구의 경쟁은 “더 좋은 모델”이 중심이었습니다. gstack은 그 축을 “더 좋은 프로세스”로 옮기려는 시도입니다. Garry Tan이 공식 README에 남긴 수치 — 60일에 60만 줄, 하루 1~2만 줄 — 는 모델이 좋아졌기 때문이 아니라 워크플로우가 표준화됐기 때문이라는 게 핵심 주장입니다.

실제 사용자 커뮤니티 반응이 절반은 “천재적”이고 절반은 “과잉 포장된 프롬프트”로 갈린다는 사실이 오히려 솔직합니다. 프롬프트 모음이 맞습니다. 그게 효과가 없다는 의미는 아닙니다. 중요한 건 내 개발 환경이 “표준화된 체크포인트가 필요한 상황”인지 아닌지를 먼저 판단하는 겁니다.

Claude Code와 Bun이 이미 세팅된 환경이라면, 설치 30초 들여서 /plan-ceo-review 하나만 실행해봐도 맞는지 아닌지 금방 알 수 있습니다. 그 정도 비용은 안 드는 실험입니다.

본 포스팅 참고 자료

1. garrytan/gstack 공식 GitHub README (github.com/garrytan/gstack) — 2026.03.14 공개, 2026.03.18 확인
2. 공식 ARCHITECTURE.md — 브라우저 데몬 설계 및 Bun 선택 근거 (링크)
3. 공식 BROWSER.md — Cold start 3~5초 vs 이후 100~200ms 수치 출처 (링크)
4. Marktechpost 기술 분석 (링크) — 2026.03.14
5. Goose AI vs gstack 비교 분석 — CodeConductor (링크) — 2026.03.16
6. gstack 확산 분석 — Junia.ai (링크) — 2026.03.17
7. SitePoint 설치·사용 심층 가이드 (링크) — 2026.03.13