gstack 리뷰: Garry Tan의 Claude Code 설정, 입소문 타다

현직 Y Combinator 회장이 자신의 개발 설정을 오픈소스로 공개했습니다. 인터넷의 반응은 "괜찮은 사이드 프로젝트" 수준이 아니었습니다 — 2주도 안 되는 기간에 140,000개에 가까운 스타를 모았습니다. 이번 gstack 리뷰에서는 gstack이 실제로 하는 일, Garry Tan이 자신의 작업 성과에 어떤 효과가 있다고 주장하는지, 그리고 실제 코드베이스에 설치하기 전에 꺼두는 게 좋을 — 자체 프라이버시 문서에 적힌 — 기본 설정 하나를 짚어봅니다.

gstack 리뷰: 실제로 무엇인가

gstack은 Claude Code를 위한 무료, MIT 라이선스 Markdown 기반 슬래시 커맨드 모음입니다(Codex, Cursor, Gemini CLI는 부분 지원). 자체 README는 이 툴의 핵심을 한 줄로 이렇게 요약합니다: "turns Claude Code (and other coding agents) into a virtual engineering team."(Claude Code를 — 그리고 다른 코딩 에이전트들도 — 가상의 엔지니어링 팀으로 바꿔놓는다.) README에 따르면 이 팀은 다음과 같이 구성됩니다:

• 제품을 다시 생각하는 CEO.
• 아키텍처를 확정하는 엔지니어링 매니저.
• AI 슬랍(AI slop)을 잡아내는 디자이너.
• 프로덕션 버그를 찾아내는 리뷰어.
• 실제 브라우저를 열어보는 QA 리드.
• OWASP + STRIDE 감사를 수행하는 보안 담당자.
• PR을 배포하는 릴리스 엔지니어.

README는 이렇게 덧붙입니다: "All slash commands, all Markdown, all free, MIT license."(전부 슬래시 커맨드, 전부 Markdown, 전부 무료, MIT 라이선스.)

실제로는 다음과 같은 커맨드들을 의미합니다:

• /office-hours — 제품 아이디어를 디자인 문서로 재구성합니다.
• /review — CI를 통과한 프로덕션 버그를 찾아냅니다.
• /qa — 브라우저, API, CLI, 잡(job), 웹훅 동작을 탐색해 버그를 재현한 다음, 실패하는 회귀 테스트를 작성하고 원인을 고친 뒤 다시 검증합니다.
• /ship — 테스트와 리뷰를 실행한 뒤 풀 리퀘스트를 엽니다.

이 모든 과정은 고정된 프로세스를 따릅니다 — Think → Plan → Build → Review → Test → Ship — 프로젝트 자체 문서에 따르면요.

설치는 클론 후 실행하면 끝입니다 — README 자체의 섹션 제목도 이를 "Install — about 30 seconds"(설치 — 약 30초)라고 부릅니다. Claude Code, Git, Bun 1.4.2 이상이 필요하고, 윈도우라면 Node.js도 필요합니다.

11일 만에 깃허브 트렌딩 3위까지

진짜 이야기는 타임라인에 있습니다. gstack의 첫 태그 릴리스인 v1.91.242.0은 2026년 10월 26일에 나왔고, 자체 릴리스 노트도 이를 정확히 그렇게 부릅니다 — "First tagged release"(첫 태그 릴리스) — 그 전 주의 태그 없던 버전 96개를 한꺼번에 묶은 것이었습니다. 11일 후인 11월 6일, 이 저장소는 약 140,000개의 스타와 20,700개의 포크를 기록하며 깃허브 일간 트렌딩 리더보드 3위에 올랐고, 그날 하루에만 612개의 스타를 얻었습니다 — 이 글을 쓰는 지금도 실시간으로 계속 움직이는 수치입니다.

커밋 히스토리와 CHANGELOG를 보면 이게 한 번 터진 바이럴 트윗 뒤 방치된 프로젝트가 아니라는 게 확인됩니다: 11월 4일 하루에만 다섯 개의 개별 포인트 릴리스(v1.95.1.0부터 v1.95.5.0까지, 바로 전날 나온 v1.95.0.0 다음으로)를 내놓았고, 가장 최신 릴리스인 v1.96.0.0은 11월 5일에 나왔습니다 — 출시 1주일 된 오픈소스 프로젝트 대부분이 유지하지 못하는, 하루에도 여러 번 배포하는 속도입니다. 짝을 이루는 저장소 gbrain("Garry's Opinionated OpenClaw/Hermes Agent Brain", 역시 MIT 라이선스)은 에이전트에게 영속적인 메모리를 부여하며, 그 자체로도 약 31,600개의 스타와 4,700개의 포크를 기록하고 있습니다.

비교해보면, 저희는 이런 '바이럴 깃허브 트렌딩 개발 툴' 패턴을 이전에도 다룬 적이 있습니다 — Graphify의 지식 그래프 CLI와 Treg의 에이전트 툴 API 게이트웨이 사례입니다. 다만 둘 다 Y Combinator를 이끄는 사람에게서 나온 것은 아니었고, 바로 이 차이가 gstack의 스타 수가 이렇게 빨리 이렇게까지 커진 가장 큰 이유입니다.

810배라는 주장, 그리고 Tan 본인이 덧붙인 유보 조항

gstack에는 자체 해명 문서인 docs/ON_THE_LOC_CONTROVERSY.md가 함께 들어 있는데, 이는 2026년 4월에 있었던 별개의 이전 논란에 대한 대응입니다 — 당시 Tan은 60일 동안 600,000줄의 프로덕션 코드를 작성했다고 말했고, 비판자들은 이를 AI 슬랍이라고 불렀습니다. 2026년 4월 18일 날짜가 찍힌 이 문서의 표는 본인 발표 기준의 계산을 다음과 같이 제시합니다: 2013년에는 하루 14줄의 논리적 코드(본업과 병행한 파트타임 작업)였던 것이, 2026년에는 108일에 걸쳐 하루 11,417줄 — 810배 증가했습니다. 전체 논리적 코드 줄 수는 5,143에서 1,233,062로(240배) 늘었지만, 커밋 수는 4.9배(71에서 351)만 늘었습니다.

Tan 본인의 문서는 이 숫자를 그냥 주장만 하는 게 아니라 직접 스트레스 테스트를 합니다. AI가 생성한 코드가 사람이 쓴 코드보다 더 장황하다고 가정하는 디플레이션 시나리오를 돌려보는데, 2배 장황하다고 가정하면 배수는 408배로 떨어지고, 10배면 81배, 100배 장황하다고 가정해도 여전히 8배입니다. 같은 351개의 커밋에 대한 품질 지표도 함께 보고합니다: 리버트 비율 2.0%(7개 커밋), 머지 후 수정 비율 6.3%(22개 커밋), 그리고 테스트 수는 1월의 약 100개에서 이 글을 쓰는 시점 기준 2,000개 이상으로 늘었으며 — 41개 저장소(그중 15개가 퍼블릭) 전체에 걸친 수치입니다. 문서 자체도 몇 가지 유보 조항을 인정합니다: 이 분석은 그린필드(처음부터 새로 만드는) 작업만을 다루고, 2013년 기준선에는 생존자 편향이 있으며, 품질을 보정한 생산성은 "isn't fully proven."(완전히 증명된 것은 아니다)라고 적혀 있습니다. 이는 Tan 본인의 문서에서 나온, 본인 발표 기준의 수치이며 독립적으로 감사받은 것이 아니기에, 저희도 그렇게 표시해둡니다.

이런 자기 회의적 태도는 docs/SLOP_SCAN.md에서도 다시 나타납니다 — gstack 안에 내장된 정적 분석 툴로, 코드베이스에서 '슬로피한(sloppy)' AI 생성 패턴을 점수화합니다. 이 문서는 정리 작업(cleanup pass) 이후 프로젝트 자체 점수가 432.8(발견 100건)에서 358.1(발견 90건)로 떨어졌다고 보고하면서도, 팀에게 이 숫자 자체를 쫓지는 말라고 경고합니다.

설치 전에 바꿔두는 게 좋은 기본 설정 하나

gstack의 출시 열기에서는 드러나지 않았던 부분이 하나 있습니다: 기본값 상태에서 gstack은 여러분의 코드를 두 번째 AI 벤더에게 보냅니다. 자체 docs/privacy.md에는 "Outside reviews (on by default; the first one prints a notice)."(외부 리뷰 — 기본적으로 켜져 있으며, 처음 한 번은 알림을 출력합니다)라는 섹션 제목이 있습니다. 다음 줄에서 그 의미를 구체적으로 설명합니다: "That sends the review prompt and the relevant code, diff or plan to that provider, using your own Codex or Claude Code login."(이는 리뷰 프롬프트와 관련 코드, diff 또는 플랜을 여러분 자신의 Codex 또는 Claude Code 로그인을 사용해 해당 제공사로 전송합니다.) 즉, 리뷰와 디자인 스킬이 여러분이 이미 사용 중인 벤더가 아닌 다른 제공사에게 실제 코드와 diff를 넘길 수 있다는 뜻입니다. 이 동작은 옵트인이 아니라 옵트아웃 방식으로 기본 적용되는데 — NDA가 걸려 있거나 규제된 데이터 처리 정책을 따르는 코드베이스에서 작업한다면 실제로 고려해야 할 부분입니다. gstack-config set codex_reviews disabled로 끌 수 있지만, 이걸 찾아봐야 한다는 걸 알아야만 끌 수 있습니다.

나머지 텔레메트리 부분은 더 방어할 만합니다: 사용 텔레메트리 자체는 옵트인이며 기본값은 꺼짐이고, 활성화하더라도 전송되는 것은 운영 메타데이터뿐입니다 — 스킬 이름, 결과, 소요 시간, OS/CPU 아키텍처, 길이가 제한되고 수정된(redacted) 에러 메시지 — 코드, 파일 경로, 저장소 이름, 브랜치 이름, 프롬프트 내용은 명시적으로 절대 포함되지 않으며, 공개된 스키마를 가진 Supabase 백엔드로 전송됩니다. 이와 별도로 항상 켜져 있는 업데이트 체크는 최신 버전을 확인하기 위해 깃허브에 핑을 보내는데(깃허브는 여러분의 IP만 보고, 그 외에는 아무것도 보지 않습니다), 이는 gstack-config set update_check false로 끌 수 있습니다.

정리하자면

gstack은 실제로 존재하고 적극적으로 배포되고 있는 MIT 라이선스 프로젝트입니다 — 유명한 이름 하나에 올라탄 베이퍼웨어 저장소가 아닙니다 — 그리고 릴리스 속도, 테스트 수 증가, 자체 공개한 슬랍 스캔 수치가 이를 뒷받침합니다. 하지만 바이럴급 스타 수는 누가 만들었는지와 떼어놓고 볼 수 없습니다: 현직 YC 회장이 자신의 설정을 공개하는 것은, 무명의 메인테이너가 만든 툴이 같은 차트를 오르는 것과는 완전히 다른 배포 사건입니다 — 어떤 무료 개발 툴이 하룻밤 사이 깃허브 리더보드로 치고 올라올 때마다 염두에 둘 만한 사실입니다. 직접 써보려 한다면, docs/privacy.md를 스스로 먼저 읽어보고, /review와 다른 외부 리뷰 스킬들이 여러분의 diff를 기본값으로 두 번째 AI 벤더에게 보내길 원하는지 신중하게 결정하세요 — 왜냐하면 지금 이 순간, 그게 바로 설치 첫날부터 여러분이 쓰게 될 기본 설정이기 때문입니다.