지난 60일간 60만 줄의 프로덕션 코드. 하루 최대 2만 줄. YC 대표 업무를 병행하면서. 개리 탄이 README에 직접 적어놓은 숫자입니다. 믿기 어렵지만, 그가 3월 12일 공개한 Claude Code 세팅 ‘gstack’은 GitHub 스타 2만 개, 포크 2,200개를 기록하며 순식간에 화제가 됐습니다.

TechCrunch가 이 논쟁을 정리한 글을 발표했습니다. 개리 탄이 오픈소스로 공개한 gstack은 Claude Code용 스킬 파일 묶음으로, 현재 15개의 슬래시 커맨드가 담겨 있습니다. Product Hunt에서도 트렌딩에 올랐습니다.

출처: Why Garry Tan’s Claude Code setup has gotten so much love, and hate – TechCrunch

gstack은 어떻게 작동하나요?

gstack의 핵심은 ‘스킬(skill)’입니다. AI가 특정 역할로 행동하도록 지시하는 재사용 가능한 프롬프트로, .md 파일로 저장됩니다.

설계 철학은 하나의 스타트업 조직을 그대로 시뮬레이션하는 것입니다. 스프린트 흐름은 이렇습니다: 아이디어 정의 → 계획 → 개발 → 코드 리뷰 → QA → 배포 → 회고. 각 단계마다 전담 전문가 역할이 있습니다.

• /office-hours — YC 오피스아워처럼 아이디어의 전제를 질문으로 뒤흔들고 설계 문서를 만들어 냅니다
• /plan-ceo-review — CEO 시각으로 기획을 검토하고, 범위를 확장하거나 줄일 시점을 판단합니다
• /plan-eng-review — 엔지니어링 매니저 역할로 아키텍처, 데이터 흐름, 테스트 매트릭스를 설계합니다
• /review — 스태프 엔지니어 역할로 CI는 통과하지만 프로덕션에서 터질 버그를 잡아냅니다
• /qa — 실제 Chromium 브라우저를 열어 앱을 클릭하며 테스트하고, 버그를 발견하면 직접 수정합니다
• /ship — 테스트 실행부터 PR 오픈까지 한 번에 처리합니다

각 스킬은 이전 단계의 산출물을 읽고 다음 단계로 넘깁니다. /office-hours가 만든 설계 문서를 /plan-ceo-review가 읽고, /plan-eng-review가 작성한 테스트 계획을 /qa가 이어받는 식입니다. 개리 탄은 이 스프린트를 10~15개 병렬로 실행해 하루 생산량을 끌어올린다고 설명합니다.

왜 이렇게 반응이 극단적으로 갈렸을까?

열광하는 쪽의 논리는 단순합니다. Claude Code를 쓰는 개발자라면 누구나 비슷한 프롬프트를 직접 만들어야 했는데, 실전에서 검증된 형태로 공개해줬다는 것입니다. ChatGPT는 gstack을 두고 “AI 코딩은 단순히 ‘이걸 만들어줘’가 아니라 엔지니어링 조직 구조를 시뮬레이션할 때 가장 잘 작동한다는 인사이트를 담고 있다”고 평가했습니다. Claude 자신도 “실제로 많이 쓰는 사람이 만든 성숙한 시스템”이라고 호평했고요.

비판하는 쪽의 요지도 명확합니다. Claude Code를 이미 쓰고 있는 개발자들은 각자 비슷한 프롬프트 세팅을 갖고 있다는 것입니다. 한 창업자는 “개리 탄이 YC 대표가 아니었다면 이게 Product Hunt에 올라왔겠냐”고 직격했고, “결국 텍스트 파일 묶음”이라는 평도 나왔습니다. 개리 탄이 “CTO 친구가 이걸로 보안 취약점을 즉시 발견했다”고 트윗한 것도 불씨를 당겼는데, 이미 잘 알려진 도구들로도 충분히 가능하다는 반박이 따라붙었습니다.

이 논쟁이 드러내는 것

gstack 자체의 품질보다 더 흥미로운 건, 이 논쟁이 AI 에이전트 코딩의 현재를 보여준다는 점입니다.

Claude Code 같은 에이전트 코딩 도구는 이미 충분히 강력하지만, “어떻게 쓰느냐”는 아직 표준화되지 않았습니다. 잘 쓰는 사람과 그렇지 않은 사람의 결과물 차이가 크고, 그 노하우가 개인의 경험 속에 흩어져 있습니다. gstack이 주목받은 건 단순히 유명인의 세팅이기 때문이 아니라, 그 흩어진 노하우를 가시화했기 때문입니다.

비판이 맞든 칭찬이 맞든, gstack이 촉발한 논의 자체는 의미 있습니다. 텍스트 파일 묶음이라는 비판도, 2만 개의 GitHub 스타도 결국 같은 말입니다. 지금 AI 에이전트 코딩을 어떻게 쓸지 아직 아무도 정답을 모른다는 것. 직접 써보고 판단하는 게 가장 빠릅니다.

참고자료: gstack – GitHub / garrytan