Garry Tan의 gstack: 60일간 60만 줄의 비밀
“우리는 지금 진짜 새벽에 서 있다. 과거에는 팀 스무 명이 필요했던 규모를, 이제 한 사람이 해낸다.” — Garry Tan, gstack README 中
목차
- 누가, 왜 만들었는가
- 숫자가 말하는 것들
- gstack이란 무엇인가
- 전체 스프린트 사이클 — 7단계 상세 해부
- 파워 툴 6종 심층 분석
- 병렬 스프린트: Conductor의 작동 원리
- 브라우저 자동화: /qa의 혁명
- gstack과 ECC의 차이
- 설치 방법 및 요구사항
- 커뮤니티의 반응: 사랑과 논쟁
- 기술적 구조 심층 이해
- 무엇이 진짜 혁신인가
1. 누가, 왜 만들었는가
Garry Tan이라는 인물
Garry Tan은 현재 Y Combinator(YC)의 대표이자 사장이다. 하지만 그의 이력은 단순한 투자자나 경영자에 머물지 않는다. 그는 Palantir의 초기 엔지니어링 매니저이자 PM, 디자이너였으며, 실제로 Palantir의 로고를 직접 디자인한 인물이기도 하다. 이후 블로그 플랫폼 Posterous를 공동 창업해 Twitter에 매각했고, YC의 내부 소셜 네트워크인 Bookface를 2013년에 직접 구축했다.
그가 YC에서 함께 성장을 지켜본 스타트업들의 면면은 더욱 놀랍다. Coinbase, Instacart, Rippling이 차고에서 창업자 한두 명으로 시작할 때부터 손을 잡았고, 이 기업들은 현재 수백억 달러 규모의 회사로 성장했다. 오랜 기간 제품을 만들고, 팀을 이끌고, 투자를 판단해온 그가 갑자기 직접 대량의 코드를 작성하기 시작했다.
gstack 공개의 배경
2026년 3월 12일, Garry Tan은 자신이 사용하는 Claude Code 설정을 통째로 오픈소스로 공개했다. 발단은 간단했다. 그가 X(구 트위터)에 올린 글은 이렇다. “Claude Code를 너무 즐겁게 쓰고 있어서, 내 정확한 설정을 여러분도 쓸 수 있도록 공유하고 싶었습니다.” 그는 이 설정 묶음을 ‘gstack’이라고 명명했다.
공개 직전, 그는 SXSW의 무대에서 동료 VC 빌 걸리와의 대담에서 이렇게 말했다. “저는 지금 하룻밤에 네 시간밖에 못 자고 있어요. AI 에이전트들이 어떻게 돌아가고 있는지 보러 새벽에 일어나게 됩니다. 지금 동시에 세 개 프로젝트가 진행 중이에요.” 그는 자신의 상태를 스스로 ‘사이버 사이코시스(cyber psychosis)’라고 농담처럼 표현했다.
그 이전에도 그는 Mega Plan Review Mode라는 단일 Gist 형태의 스킬을 공유한 바 있었다. 코드 플랜을 확장(Expansion), 현행 유지(Hold Scope), 축소(Reduction) 세 가지 모드로 검토하는 단순한 도구였다. gstack은 그것의 완전한 진화형이다. 연필 한 자루에서 사무실 전체로, 단일 스킬에서 전체 소프트웨어 팩토리로.
2. 숫자가 말하는 것들
gstack의 핵심을 이해하기 위해서는 먼저 Garry Tan이 제시한 숫자들을 직시해야 한다.
- 60일간 60만 줄 이상의 프로덕션 코드 작성
- 하루 1만~2만 줄의 유의미한 코드 생산
- 전체의 35%가 테스트 코드
- YC CEO의 정규 업무를 수행하면서 파트타임으로 달성
- 최근 7일간 통계(
/retro기준): 3개 프로젝트에서 140,751줄 추가, 362개 커밋, 순증 약 115,000줄 - GitHub 공개 후 빠르게 26,000개 이상의 스타, 3,100개 이상의 포크 기록
이 숫자들이 처음에는 믿기 어렵게 느껴질 수 있다. 실제로 커뮤니티의 일부는 즉각 반발했다. 그러나 핵심은 단순히 코드 줄 수가 아니다. 핵심은 어떻게 이것이 가능했는가, 그 구조가 무엇인가이다. gstack은 그 질문에 대한 Garry Tan의 공개적인 답이다.
3. gstack이란 무엇인가
개념적 정의
gstack의 공식 설명은 간결하다. “Claude Code를 여러분이 실제로 관리할 수 있는 가상 엔지니어링 팀으로 전환하는 오픈소스 소프트웨어 팩토리.” 하지만 이 문장을 제대로 이해하려면 조금 더 분해해야 한다.
일반적으로 Claude Code를 사용하는 방식은 자유로운 채팅에 가깝다. 사용자가 맥락을 제공하고, AI가 응답하고, 사용자가 수정 요청을 하는 방식이다. 이 접근법의 문제는 구조가 없다는 것이다. AI는 매번 새로운 판단을 해야 하고, 사용자는 매번 충분한 맥락을 제공해야 하며, 일관성 있는 품질을 유지하기가 어렵다.
gstack은 이 문제를 역할(Role) 기반 구조로 해결한다. 소프트웨어 개발의 각 단계마다 전문 역할을 가진 AI 스페셜리스트를 소환하는 것이다. CEO처럼 제품을 바라보는 시각, 엔지니어링 매니저처럼 아키텍처를 잠그는 시각, 디자이너처럼 UX의 허점을 찾는 시각, QA 리드처럼 실제 브라우저를 클릭하며 버그를 찾는 시각. 이 모든 역할이 슬래시 커맨드(/) 하나로 호출된다.
구성 요소
gstack은 크게 두 가지로 구성된다.
첫째는 스프린트 사이클 스킬이다. 생각하기 → 계획하기 → 만들기 → 리뷰하기 → 테스트하기 → 배포하기 → 돌아보기의 7단계를 커버하는 순서형 슬래시 커맨드들이다. 각 스킬은 이전 스킬이 생성한 문서와 컨텍스트를 자동으로 이어받는다.
둘째는 파워 툴이다. 스프린트 사이클 밖에서 언제든 호출 가능한 도구들로, 크로스모델 리뷰(/codex), 안전장치(/careful, /freeze, /guard), 브라우저 자동화(/browse), 보안 감사(/cso) 등이 포함된다.
MIT 라이선스로 완전 무료이며, 모든 스킬은 슬래시 커맨드이자 마크다운 파일 형태이다.
4. 전체 스프린트 사이클 — 7단계 상세 해부
1단계: 생각하기 — /office-hours
스프린트의 시작점은 /office-hours다. 이름 그대로, YC의 오피스아워를 시뮬레이션한다. 스타트업 창업자가 투자자 앞에서 아이디어를 발표하듯, 사용자가 만들고 싶은 것을 설명하면 AI가 YC 심사위원처럼 질문을 던진다.
중요한 점은 이 질문들이 단순한 확인이 아니라는 것이다. 6개의 강제 질문이 사용자의 전제를 흔든다. 예컨대 “일일 브리핑 앱을 만들고 싶어요”라고 하면, AI는 “당신이 진짜 만들려는 건 개인 비서 AI 아닙니까?”라고 되물으며 아이디어의 본질을 재정의한다. 이어서 대안 3개를 제시하고, 그 과정에서 만들어진 디자인 문서는 다음 단계로 자동 전달된다.
이 스킬의 철학은 명확하다. 코드 한 줄을 쓰기 전에 올바른 것을 만들고 있는지 검증하라는 것이다.
2단계: 계획하기 — /plan-ceo-review, /plan-eng-review, /plan-design-review
계획 단계는 세 가지 서로 다른 렌즈로 나뉜다. 각 렌즈는 동일한 계획을 전혀 다른 시각으로 바라본다.
/plan-ceo-review는 큰 그림을 본다. “10성급 제품”이란 무엇인가라는 질문을 중심으로 시장 적합성, 사용자 가치, 기능 범위를 검토한다. 이전의 Mega Plan Review Mode가 이 스킬에 통합되어 있으며, 확장/현행 유지/축소 세 가지 모드로 플랜을 평가한다.
/plan-eng-review는 엔지니어링 매니저의 눈으로 계획을 해부한다. 아키텍처를 확정하고, ASCII 다이어그램으로 시스템 구조를 시각화하며, 엣지 케이스와 잠재적 기술 부채를 미리 식별한다. 기술적 결정에 대한 명확한 근거를 요구하고, 모호한 부분은 구체화하도록 강제한다.
/plan-design-review는 디자이너의 관점에서 각 항목을 0점에서 10점 사이로 채점한다. 특히 이 스킬에서 주목할 부분은 “AI Slop” 감지 기능이다. AI가 만든 티가 나는 디자인, 즉 제네릭하고 무개성하며 실제 사용자를 고려하지 않은 디자인을 자동으로 식별하고 지적한다.
이 세 단계는 순서대로 실행될 수도 있고, 각각 독립적으로 호출될 수도 있다. 중요한 것은 이 단계에서 생성된 디자인 문서와 테스트 매트릭스가 이후 모든 단계의 컨텍스트로 자동 제공된다는 것이다.
3단계: 만들기 — 구현 단계
실제 코드가 생성되는 단계다. 이 단계의 가장 중요한 특징은 이전 단계들에서 생성된 디자인 문서, 아키텍처 결정, 테스트 매트릭스가 이미 AI의 컨텍스트에 포함되어 있다는 점이다.
일반적인 AI 코딩 도구는 매 세션마다 처음부터 맥락을 재구성해야 한다. gstack에서는 /office-hours가 정의한 제품 방향, /plan-eng-review가 확정한 아키텍처, /plan-design-review가 지정한 디자인 원칙이 구현 단계에 자동으로 이어진다. AI가 임의적으로 다른 방향으로 구현하거나, 이미 논의된 트레이드오프를 무시하는 일이 방지된다.
4단계: 리뷰하기 — /review, /investigate
코드가 작성된 후에는 두 가지 리뷰 도구가 작동한다.
/review는 CI(지속적 통합)를 통과하지만 프로덕션 환경에서 문제가 될 수 있는 버그를 집중적으로 탐색한다. 명백한 오류는 자동으로 수정하지만, 비즈니스 판단이 필요한 사항은 사람에게 물어본다. 이는 의도적인 설계다. 모든 것을 자동화하는 것이 목표가 아니라, 자동화할 수 있는 것은 자동화하고 판단이 필요한 것은 사람이 처리하는 구조를 만드는 것이다.
/investigate는 “조사 없이 수정 없음(No fix without investigation)”을 철칙으로 삼는다. 버그의 증상이 아니라 근본 원인을 파악하는 것이 목표다. 데이터 플로우를 추적하고, 가설을 세우고, 검증 실험을 설계한다. 중요한 안전장치가 있는데, 같은 문제에 대해 3번 연속으로 수정 시도가 실패하면 자동으로 멈추고 사람에게 에스컬레이션한다. AI가 무한 루프에 빠져 엉뚱한 방향으로 수정을 계속하는 것을 방지하는 메커니즘이다.
5단계: 테스트하기 — /qa, /qa-only
gstack에서 가장 기술적으로 인상적인 부분이다. /qa는 단순히 코드를 분석하는 것이 아니라, 실제 Chromium 브라우저를 실행해 실제 사용자처럼 앱과 상호작용한다.
스테이징 URL을 제공하면 AI가 브라우저를 열어 페이지를 로드하고, 버튼을 클릭하고, 폼을 작성하고, 스크린샷을 촬영한다. “이 버튼을 클릭했더니 예상과 다른 결과가 나왔다”는 것을 AI가 시각적으로 확인한다. 버그를 발견하면 코드를 수정하고, 수정된 사항에 대한 회귀 테스트를 자동 생성한 뒤, 다시 브라우저를 열어 수정이 적용되었는지 검증한다. 커맨드 실행당 평균 속도는 약 100ms다.
/qa-only는 코드를 수정하지 않고 버그 리포트만 생성하는 모드다. 현재 코드베이스를 건드리지 않고 품질 현황만 파악하고 싶을 때 유용하다.
인증이 필요한 페이지를 테스트할 경우에는 /setup-browser-cookies 스킬을 통해 Chrome, Arc, Brave, Edge 등 주요 브라우저에서 인증 쿠키를 가져올 수 있다.
6단계: 배포하기 — /ship, /land-and-deploy, /canary
/ship은 하나의 커맨드로 전체 배포 파이프라인을 실행한다. main 브랜치와 동기화, 테스트 실행, 코드 커버리지 감사, 원격 저장소 푸시, Pull Request 생성까지 순서대로 처리된다. 만약 프로젝트에 테스트 프레임워크가 설정되어 있지 않다면, gstack이 프로젝트 특성에 맞는 테스트 프레임워크를 알아서 선택하고 설정한다.
/land-and-deploy는 PR 병합부터 실제 배포까지를 자동화하는 고급 배포 스킬이다. /canary는 카나리 배포 전략을 지원하는데, 전체 사용자가 아닌 일부에게 먼저 배포하고 문제가 없을 때 전체로 확장하는 방식이다. 프로덕션 장애 위험을 최소화하기 위한 도구다.
7단계: 돌아보기 — /retro
주간 회고 보고서를 자동 생성한다. 단순한 숫자 집계가 아니다. 배포 연속 기록(Deployment Streak), 테스트 건강도 트렌드, 주요 성과, 그리고 개선 기회까지 포함한다. Garry Tan이 공개한 최근 7일 회고 데이터(140,751줄 추가, 362 커밋, ~115k 순증)가 바로 이 /retro에서 생성된 것이다.
5. 파워 툴 6종 심층 분석
스프린트 사이클과는 별도로, gstack에는 언제든 필요할 때 호출 가능한 전문 도구들이 있다.
/codex — 크로스 모델 코드 리뷰
가장 독창적인 파워 툴이다. Claude Code 안에서 OpenAI의 Codex CLI를 호출해 독립적인 코드 리뷰를 받는다. AI가 AI를 검토하는 구조다.
세 가지 모드가 있다. 첫 번째는 통과/불합격 게이트(Pass/Fail Gate)로, 코드가 배포 기준을 충족하는지 이진적으로 판단한다. 두 번째는 적대적 도전(Adversarial Challenge)으로, 코드를 깨뜨리려는 시도를 통해 취약점을 발견한다. 세 번째는 자유 상담(Free Consultation)으로, 코드 구조와 설계에 대한 개방적인 피드백을 제공한다.
/review(Claude)와 /codex(OpenAI)를 모두 실행하면, 두 AI의 의견이 교차 분석된다. 두 AI 모두 지적한 공통 문제, Claude만 발견한 문제, Codex만 발견한 문제가 각각 분류되어 제공된다. 서로 다른 AI 모델의 강점과 약점을 활용해 단일 AI 리뷰의 한계를 보완하는 방식이다.
/careful — 파괴적 명령어 안전장치
Claude Code에게 “be careful”이라고 입력하면 활성화된다. 활성화 후에는 파괴적인 결과를 초래할 수 있는 명령어를 실행하기 전에 반드시 경고를 표시하고 확인을 요청한다. rm -rf 같은 대규모 파일 삭제, DROP TABLE 같은 데이터베이스 테이블 삭제, git push --force 같은 강제 푸시, git reset --hard 같은 하드 리셋이 대표적인 대상이다.
/freeze — 편집 범위 잠금
디버깅 중에 AI가 관련 없는 파일까지 수정해버리는 문제를 방지한다. /freeze를 실행하면 파일 편집이 특정 디렉토리나 모듈로 제한된다. AI가 A 모듈의 버그를 디버깅하다가 B 모듈을 무단으로 “개선”하는 일이 차단된다. 특히 /investigate 스킬은 실행 시 자동으로 조사 대상 모듈에 편집 잠금을 건다.
/guard — 최고 안전 설정
/careful과 /freeze를 동시에 적용하는 복합 안전 커맨드다. 프로덕션 환경에서 직접 작업하거나 영향 범위가 큰 변경을 할 때 권장된다. 단 한 번의 커맨드로 모든 안전장치를 켤 수 있다.
/browse — AI에게 눈을 주다
실제 Chromium 브라우저를 실행해 웹 페이지를 탐색하는 도구다. /qa가 테스트에 특화된 브라우저 자동화라면, /browse는 범용 웹 탐색을 위한 도구다. AI가 화면을 실제로 보면서 정보를 수집하고, 상호작용하고, 판단할 수 있다.
CAPTCHA나 로그인 벽처럼 자동화가 불가능한 상황에서는 $B handoff 메커니즘을 통해 사람에게 제어권을 넘긴다. 사람이 인증을 완료하면 $B resume 명령으로 AI가 다시 탐색을 이어받는다. 자동화와 인간 판단의 경계를 명확하게 정의한 설계다.
/cso — 보안 감사
OWASP Top 10과 STRIDE 위협 모델링을 결합한 자동화 보안 감사 도구다. 이 스킬의 설계에서 주목할 점은 거짓 양성(False Positive) 억제에 많은 신경을 썼다는 것이다. 총 17개의 제외 규칙이 내장되어 있어 흔히 오탐이 발생하는 케이스를 걸러낸다. 또한 신뢰도 8/10 이상으로 판단되는 취약점만 리포트에 포함시킨다. 단순히 취약점 목록을 나열하는 것이 아니라, 각 취약점에 대한 구체적인 익스플로잇 시나리오도 함께 제공해 실제 위험도를 직관적으로 파악할 수 있게 한다.
이 스킬이 실제 가치를 증명한 사례가 공개된 바 있다. Garry Tan의 CTO 지인이 gstack을 처음 사용했을 때, 자신의 팀도 인지하지 못하고 있던 크로스사이트 스크립팅(XSS) 취약점을 /plan-eng-review 스킬이 발견했다고 밝혔다.
6. 병렬 스프린트: Conductor의 작동 원리
하루 1만~2만 줄의 코드가 가능한 비결은 단순히 AI가 빠르기 때문이 아니다. 핵심은 병렬화다.
Conductor란
Conductor는 여러 Claude Code 세션을 격리된 워크스페이스에서 동시에 실행하는 도구다. 각 세션은 독립된 환경에서 작동하며, 서로 간섭하지 않는다.
Garry Tan은 이렇게 설명한다. “한 세션은 /office-hours로 새 아이디어를 탐색하고, 다른 세션은 /review로 PR을 검토하고, 세 번째는 기능을 구현하고, 네 번째는 /qa로 스테이징 테스트를 돌린다. 전부 동시에.”
실제로 그는 10개에서 15개의 스프린트를 동시에 운영한다고 밝혔다. /qa 도입 이후에는 병렬 워커를 기존 6개에서 12개로 늘릴 수 있었다고 한다. AI가 독립적으로 시각적 검증을 할 수 있게 되자, 사람이 중간에 개입해야 하는 빈도가 급격히 줄었기 때문이다.
왜 구조가 병렬화를 가능하게 하는가
구조 없이 AI 에이전트 10개를 동시에 돌리면 혼돈이 10배가 된다. 각 에이전트가 무엇을 해야 하는지, 언제 멈춰야 하는지, 무엇을 다음 단계로 넘겨야 하는지 알 수 없기 때문이다.
gstack의 스프린트 구조는 이 문제를 해결한다. 각 스킬은 명확한 입력, 명확한 출력, 명확한 종료 조건을 가진다. 에이전트는 자신의 역할이 무엇인지 알고, 언제 끝내야 하는지 알고, 무엇을 다음 스킬에 전달해야 하는지 안다.
Garry Tan의 표현을 빌리면, “CEO가 팀을 관리하는 것처럼 관리한다. 중요한 결정만 직접 확인하고, 나머지는 돌아가도록 내버려둔다.”
7. 브라우저 자동화: /qa의 혁명
전통적인 자동화 테스트의 한계
기존의 자동화 테스트, 예를 들어 Selenium이나 Playwright 기반 테스트는 코드를 통해 브라우저를 제어한다. 이 접근법은 강력하지만, 테스트 코드 자체를 작성하고 유지 관리해야 하는 부담이 있다. UI가 변경되면 테스트도 깨진다.
gstack /qa의 접근법
gstack의 /qa는 다른 방식으로 작동한다. AI가 화면을 실제로 보고 판단한다. 스테이징 URL을 주면 Chromium이 뜨고, AI는 화면을 분석해 “다음에 어떤 행동을 해야 하는가”를 스스로 결정한다. 버튼을 클릭하고, 결과를 관찰하고, 예상과 다르면 버그로 기록한다.
버그를 발견하면 코드를 수정하고, 그 수정이 실제로 작동하는지 다시 브라우저로 돌아가서 확인한다. 수정이 확인되면 해당 버그에 대한 회귀 테스트를 자동 생성한다. 다음에 같은 버그가 재발하면 테스트가 자동으로 잡아낸다.
이 방식의 핵심 강점은 의도 기반 테스트다. “버튼을 클릭하면 모달이 열린다”는 구체적인 코드 대신, “사용자가 체크아웃 프로세스를 완료할 수 있어야 한다”는 의도 수준의 테스트가 가능하다.
8. gstack과 ECC의 차이
ECC(Everything Claude Code)란
ECC는 Claude Code를 위한 또 다른 오픈소스 확장팩이다. 에이전트 28개, 스킬 116개, 12개 프로그래밍 언어, 5개 도구 크로스 플랫폼을 지원한다. 광범위하고 깊은 커버리지를 가진 범용 도구 상자다. 필요한 조각만 골라서 사용하는 구조로 설계되어 있다.
핵심 차이점
철학의 차이가 가장 크다. ECC는 다양한 상황에서 사용할 수 있는 광범위한 도구 모음을 지향한다. 개발자가 필요에 따라 선택하고 조합한다. 반면 gstack은 Garry Tan이 실제로 매일 사용하는 워크플로우를 그대로 복제하는 것을 목표로 한다. “YC 대표가 쓰는 그 설정 그대로”라는 개념이다.
구조의 차이도 중요하다. ECC는 모듈식이다. gstack은 파이프라인 구조다. gstack에서는 스프린트의 순서가 정해져 있고, 각 스킬은 이전 스킬의 산출물을 입력으로 받는다. 단절이 없다.
멀티 AI 지원도 차이점 중 하나다. gstack은 /codex를 통해 OpenAI Codex CLI를 직접 호출하여 크로스 모델 리뷰를 제공한다. Claude가 놓친 부분을 다른 AI가 잡을 수 있는 구조다. ECC에는 이런 멀티 AI 리뷰 기능이 없다.
반대로 ECC에는 AgentShield(전문 보안 스캐너), 12개 언어별 특화 규칙, 5개 도구 크로스 플랫폼 지원 같이 gstack에 없는 기능들이 있다.
비유하자면, ECC가 공구 상자라면 gstack은 조립 라인이다. 둘은 경쟁 관계가 아니라 보완 관계다. gstack을 스프린트 흐름의 기반으로 사용하고, ECC의 특화 스캐너나 언어별 규칙을 위에 얹는 방식으로 함께 사용하는 것도 가능하다.
9. 설치 방법 및 요구사항
시스템 요구사항
- Claude Code (필수)
- Git (필수)
- Bun v1.0 이상 (필수, Windows에서는 추가로 Node.js 필요)
- 활성 Anthropic API 계정
개인 설치 (한 줄 커맨드)
Claude Code를 열고 다음 한 줄을 붙여넣으면 된다.
1
git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup
Claude가 나머지를 자동으로 처리한다. 테스트 환경이 이미 설정된 리포지토리라면 5분 내에 첫 번째 유용한 실행이 가능하다.
팀 공유 설치
팀원들도 동일한 설정을 사용하게 하려면 프로젝트 리포지토리에 직접 파일을 커밋한다.
1
cp -Rf ~/.claude/skills/gstack .claude/skills/gstack && rm -rf .claude/skills/gstack/.git && cd .claude/skills/gstack && ./setup
git submodule 방식이 아니라 실제 파일을 리포지토리에 커밋하는 방식을 사용한다. 덕분에 팀원이 리포지토리를 클론하면 gstack이 바로 작동한다. 별도 설정이 필요 없다.
CLAUDE.md 설정
설치 후 프로젝트의 CLAUDE.md 파일에 gstack 섹션을 추가해야 한다. 이 섹션은 Claude에게 사용 가능한 스킬 목록과 웹 브라우징 시 /browse 스킬을 사용하도록 지시한다.
호환성
gstack은 Claude Code 전용으로 설계되어 있으나, SKILL.md 표준을 지원하는 다른 도구에서도 작동한다. OpenAI Codex CLI, Google Gemini CLI, Cursor 등에서도 호환 가능하다.
업그레이드
/gstack-upgrade 커맨드 하나로 최신 버전으로 업데이트할 수 있다. ~/.gstack/config.yaml에서 auto_upgrade: true를 설정하면 자동 업그레이드도 가능하다.
10. 커뮤니티의 반응: 사랑과 논쟁
폭발적인 초기 반응
gstack의 공개는 즉각적인 반응을 불러왔다. X(구 트위터)에서 바이럴이 되었고, Product Hunt에서 트렌딩에 올랐다. GitHub 스타는 출시 직후 빠르게 누적되어 26,000개를 넘겼고, 3,100개 이상의 포크가 생성됐다.
현실적으로 gstack이 화제가 된 데는 Garry Tan의 위치가 상당한 역할을 했음을 부정하기 어렵다. YC의 현직 대표가 자신의 도구를 공개했다는 사실 자체가 주목을 끌었다.
비판과 반발
그러나 동시에 강한 비판도 있었다. Garry Tan이 CTO 지인의 “god mode” 발언을 트윗하자 반발이 쏟아졌다. 한 창업자는 X에 “그 CTO는 즉시 해고되어야 한다”고 썼다.
vlogger Mo Bitar는 “AI가 CEO들을 망상에 빠뜨리고 있다”는 제목의 영상에서 gstack이 본질적으로 “텍스트 파일에 담긴 프롬프트 묶음”에 불과하다고 비판했다. Claude Code를 이미 사용하는 개발자들은 이미 자신만의 유사한 설정을 갖고 있다는 지적도 나왔다. Product Hunt의 한 사용자는 “Garry가 YC CEO가 아니었다면 이것은 Product Hunt에 올라오지도 않았을 것”이라고 직설적으로 말했다.
전문가들의 평가
TechCrunch의 취재에 따르면, Claude, ChatGPT, Gemini 세 AI 모두에게 gstack을 평가해달라고 요청했다. ChatGPT는 gstack을 “합리적으로 정교한 프롬프트 워크플로우이지만 마법은 아니다”라고 평했다. Gemini는 “정교한 구성”이라고 하며 “쉬운 코딩보다는 올바른 코딩을 위한 도구”라고 덧붙였다. Claude는 “실제로 heavy하게 사용하는 사람이 만든 성숙하고 의견이 담긴 시스템”이라고 평가했다.
Hacker News에서의 개발자 커뮤니티 반응은 더 기술적이었다. 자동 업데이트 구현 패턴에 대한 긍정적 평가, 계획 단계 스킬의 실용적 가치 인정, 하지만 CEO 스킬의 실효성에 대한 의문 등 기술적 관점에서 분석이 이루어졌다.
논쟁의 본질
비판의 핵심은 “결국 프롬프트 파일이 아니냐”는 것이고, 옹호의 핵심은 “구조화된 워크플로우와 역할 분리가 실질적인 차이를 만든다”는 것이다. 두 입장 모두 틀리지 않다. gstack은 기술적 혁신이 아니라 워크플로우의 혁신이다. 새로운 알고리즘이나 모델을 발명한 것이 아니라, 기존 도구를 체계적으로 조직화하는 방법을 제시한 것이다.
11. 기술적 구조 심층 이해
SKILL.md 표준
gstack의 기반은 SKILL.md 파일 형식이다. 각 스킬은 마크다운 형태의 .md 파일로, Claude Code의 커스텀 슬래시 커맨드 기능을 활용해 특정 AI 행동 방식을 정의한다. 파일 자체가 AI에 대한 명령어이자 설정이다.
이 구조의 장점은 투명성이다. 모든 스킬의 내용을 텍스트 편집기로 직접 열어볼 수 있고, 수정할 수 있고, 팀 내 버전 관리 시스템에서 추적할 수 있다. 블랙박스가 없다.
컨텍스트 체인
각 스킬은 이전 스킬의 출력을 다음 스킬의 입력으로 자동 전달하는 컨텍스트 체인을 형성한다.
/office-hours가 생성한 디자인 문서 → /plan-ceo-review가 읽고 평가 → /plan-eng-review가 아키텍처 결정 추가 → /plan-design-review가 UX 평가 추가 → 구현 단계에서 전체 컨텍스트 사용 → /review가 계획 대비 구현 검토 → /qa가 테스트 플랜 기반으로 검증 → /ship이 전체 체크리스트 확인 후 배포
이 체인이 끊어지지 않기 때문에 AI가 임의로 방향을 바꾸거나 이전 결정을 무시하는 일이 방지된다.
텔레메트리와 프라이버시
gstack은 옵트인 방식의 익명 사용 데이터 수집 기능이 있다. 기본값은 비활성화다. 활성화하더라도 코드나 개인 정보는 전송되지 않는다. 로컬 분석은 항상 사용 가능하며, gstack-analytics 명령으로 로컬 JSONL 파일 기반의 개인 사용 대시보드를 볼 수 있다.
12. 무엇이 진짜 혁신인가
gstack을 둘러싼 논쟁에서 가장 중요한 질문은 이것이다. “이것이 진짜 새로운 것인가?”
기술적으로만 보면, gstack은 Claude Code의 기존 슬래시 커맨드 기능과 마크다운 파일, Bun 런타임, Chromium 자동화를 조합한 것이다. 새로운 알고리즘도, 새로운 모델도, 새로운 프로토콜도 아니다.
그러나 그것이 전부라고 보는 것은 바라보는 시각이 너무 협소하다. 스프레드시트 프로그램도 처음 등장했을 때 “그냥 전자 계산기 아니냐”는 비판이 있었다. 중요한 것은 그 조합이 만들어내는 새로운 가능성이다.
gstack이 제시하는 핵심 아이디어는 세 가지다.
첫째, AI를 단일 에이전트가 아니라 역할 기반 팀으로 운영한다. 동일한 AI 모델도 역할에 따라 완전히 다른 방식으로 사고하도록 프레이밍할 수 있다.
둘째, 워크플로우 자체를 소프트웨어로 만든다. 개발 프로세스를 버전 관리 가능하고, 팀 전체가 공유할 수 있고, 점진적으로 개선할 수 있는 코드로 정의한다.
셋째, 구조가 병렬화를 가능하게 한다. 명확한 역할과 종료 조건이 있기 때문에 에이전트를 10개, 15개 동시에 운영할 수 있다. 구조 없는 자동화는 혼돈을 증폭시키지만, 구조 있는 자동화는 생산성을 곱셈으로 증폭시킨다.
Garry Tan은 gstack README의 마지막을 이렇게 마무리했다.
“모델은 매주 더 좋아지고 있다. 지금 이 도구들과 함께 진정으로 일하는 법을 터득하는 사람들이, 단순히 시험삼아 쓰는 수준이 아니라 진짜로 일하는 법을 익히는 사람들이 엄청난 우위를 가지게 될 것이다. 지금이 바로 그 시간이다.”
참고 링크
- gstack GitHub: https://github.com/garrytan/gstack
- TechCrunch 분석 기사: https://techcrunch.com/2026/03/17/why-garry-tans-claude-code-setup-has-gotten-so-much-love-and-hate/
- Product Hunt: https://www.producthunt.com/products/gstack
- Hacker News 토론: https://news.ycombinator.com/item?id=47418576
- YC Software (채용): https://ycombinator.com/software
이 문서는 2026년 3월 기준으로 작성되었습니다. gstack은 활발하게 업데이트 중이며, 최신 정보는 공식 GitHub 리포지토리를 참고하세요.