Garry Tan의 Gstack 소개

Gstack은 Garry Tan이 공개한 AI 개발 워크플로우로, 하나의 코딩 어시스턴트를 여러 역할의 팀처럼 쓰게 하려는 시도로 볼 수 있다.¹ 단순히 "코드를 잘 짜게 하는 도구"라기보다, 기획·리뷰·QA·배포를 서로 다른 모드로 분리해 개발 품질을 높이려는 운영 방식에 가깝다.²

Garry Tan은 누구인가

Garry Tan은 현재 Y Combinator의 President & CEO로 알려져 있고, 과거에는 YC 파트너, Initialized Capital 공동창업자, Posterous 공동창업자 등으로 활동해온 인물이다.³ 스타트업 투자자이면서 동시에 직접 만드는 사람이라는 점이, Gstack을 이해하는 데 꽤 중요한 배경으로 보인다.

Gstack이 무엇인가

Gstack은 Garry Tan이 자신의 Claude Code 작업 방식을 바탕으로 공개한 오픈소스 설정이자 스킬 묶음이다.¹ 핵심은 AI에게 모든 일을 한 번에 시키지 않고, CEO·Designer·Eng Manager·Reviewer·QA Lead·Security Officer·Release Engineer 같은 역할을 분리해 하나의 어시스턴트를 가상 엔지니어링 팀처럼 쓰게 만드는 데 있다.¹² 그래서 Gstack은 단순한 프롬프트 모음이라기보다, Claude Code 위에 얹는 오픈소스 소프트웨어 팩토리에 가깝다.¹

공식 설명에서도 Gstack은 Claude Code를 "가상 소프트웨어 개발 팀"으로 바꾸는 접근으로 소개된다.¹² 같은 모델을 더 구조적으로 운영하게 만드는 레이어라는 뜻이며, 계획 검토부터 구현, 보안 점검, QA, 배포까지 서로 다른 전문 역할을 오가며 작업 흐름을 분리하는 것이 핵심이다. GitHub 저장소 기준으로는 Claude Code뿐 아니라 SKILL.md 표준을 따르는 Codex, Gemini CLI, Cursor 계열 에이전트에도 연결되는 방향을 제시한다.¹

이 점이 흥미롭다. 많은 사람이 AI 코딩을 "잘 프롬프트하는 법" 정도로 생각하지만, Gstack은 오히려 사람 팀의 협업 구조를 AI 안으로 가져오려는 시도에 가깝다. 그래서 도구라기보다 일하는 방식의 템플릿처럼 읽힌다.

Gstack은 어떻게 굴러가는가

Gstack은 역할만 나누는 데서 끝나지 않고, 스프린트 전체를 Think → Plan → Build → Review → Test → Ship → Reflect 흐름으로 묶는다.¹ 중요한 점은 각 단계가 앞 단계의 산출물을 이어받는다는 것이다. 예를 들어 /office-hours가 문제 정의와 디자인 문서를 만들면, /plan-ceo-review와 /plan-eng-review가 그 문서를 바탕으로 범위와 구조를 다시 검토하고, 이후 /qa와 /ship 단계도 앞선 계획과 수정 내역을 이어받아 검증과 출하를 진행한다.¹ 이 연결 구조 덕분에 "한 번 잘 말해보자"식 프롬프트보다, 짧은 스프린트를 반복하는 작업 방식에 더 가깝게 느껴진다.

주요 명령 예시

자주 언급되는 명령을 보면 Gstack의 성격이 더 분명해진다. /office-hours는 출발점에서 문제 정의를 다시 묻는 역할이고, /plan-ceo-review는 창업자 관점에서 범위와 방향을 재해석한다.¹ /plan-eng-review는 아키텍처, 데이터 흐름, 테스트 관점을 정리하고, /plan-design-review는 화면과 상호작용의 완성도를 디자인 관점에서 점검한다.¹ 구현 이후에는 /review가 프로덕션에서 터질 수 있는 버그와 완성도 문제를 살피고, /qa는 실제 브라우저 기반 검증과 회귀 테스트 생성을 돕는다.¹ /cso는 보안 관점의 위협 모델과 취약점 검토를 맡고, /ship은 테스트와 PR 생성까지 포함한 출하 흐름을 정리하며, /land-and-deploy는 승인된 변경을 머지하고 배포 후 상태까지 확인하는 쪽에 가깝다.¹ 마지막으로 /retro는 한 주의 변경과 테스트 상태, 작업 흐름을 되돌아보게 해주는 회고 도구다.¹

왜 스타트업과 개인 창업자에게 매력적인가

초기 스타트업이나 1인 창업자는 늘 사람이 부족하다. 기획도 해야 하고, 화면도 만들어야 하고, 코드 리뷰도 해야 하고, 테스트와 배포까지 직접 챙겨야 한다. Gstack은 이 부족한 역할들을 AI의 여러 모드로 분해해서 보완하려는 발상이라서 특히 매력적으로 느껴질 수 있다.¹²

기존에는 AI에게 긴 문장을 한 번 던지고, 그 결과가 마음에 안 들면 다시 손으로 조정하는 식이 많았다. 그런데 Gstack은 역할별로 사고방식을 분리해두기 때문에, 적어도 "지금 무엇을 기대해야 하는지"가 분명해진다.² 초기 창업자 입장에서는 이 구조화 자체가 큰 가치가 될 수 있다.

빠른 시작

• 먼저 gstack을 설치한다. 저장소 안내 기준으로 설치 자체는 매우 짧게 끝나는 편이라, 일단 세팅부터 해두고 흐름을 체험해보는 것이 좋다.¹

• 설치가 끝나면 /office-hours를 실행해 지금 만들고 있는 것과 해결하려는 문제를 설명한다.¹

• 기능 아이디어가 조금 더 또렷해졌다면 /plan-ceo-review로 넘어가 범위와 우선순위를 다시 점검한다.¹

• 실제로 변경 사항을 만든 브랜치에서는 /review를 실행해 코드와 완성도를 한 번 더 확인한다.¹

• 스테이징 URL이 준비되어 있다면 /qa를 실행해 브라우저 기반 검증까지 이어간다.¹

• 처음부터 모든 명령을 다 쓰려고 하기보다, 우선 이 정도만 한 바퀴 돌려보면 된다. 자신에게 맞는 작업 방식인지도 비교적 빨리 감이 온다.¹

또 하나의 매력은 속도다. 창업 초기에 중요한 것은 완벽한 조직보다 빠른 학습인데, Gstack은 사람을 당장 다 채용하지 않아도 기획 검토, 구현, 검수, 배포 흐름을 어느 정도 압축해서 돌릴 수 있게 해준다.¹ 물론 실제 팀을 완전히 대체한다고 보기는 어렵지만, 아주 작은 팀이 더 큰 팀처럼 움직이게 만드는 보조 장치로는 충분히 매력적이다.

기존 웹사이트 제작 방식, SaaS 조합 방식과 비교하면

전통적인 웹사이트 제작 방식은 보통 직접 개발하거나, 외주를 맡기거나, 노코드 빌더를 쓰는 식으로 나뉜다. SaaS 조합 방식은 여기에 예약, 결제, 이메일, CRM 같은 서비스를 붙여 빠르게 운영하는 접근이라고 볼 수 있다. 이 방식들의 장점은 검증된 기능을 빠르게 가져다 쓸 수 있다는 점이다.

반면 Gstack은 완성된 기능을 이어 붙이는 방식보다는, AI를 통해 제품 자체를 더 유연하게 설계하고 구현하는 쪽에 가깝다.² 쉽게 말해 SaaS 조합이 "있는 블록을 잘 고르는 일"이라면, Gstack은 "필요한 블록을 더 빨리 직접 만드는 일"에 가깝다.

이 차이는 꽤 크다. 웹사이트 빌더나 SaaS 조합은 빠르게 시작하기 좋지만, 흐름이 조금만 복잡해져도 여러 도구 사이를 맞추는 비용이 커질 수 있다. 반대로 Gstack은 처음부터 더 많은 자유도를 주는 대신, 그 자유도를 다룰 역량도 함께 요구한다.¹ 그래서 "무조건 더 쉽다"기보다, "더 깊게 만들 수 있다"는 쪽으로 이해하는 편이 맞다.

활용 예시

첫 번째는 MVP 제작이다. GitHub 예시에 나온 daily briefing app 사례가 이를 잘 보여준다.¹ 사용자는 처음에 "캘린더를 위한 일일 브리핑 앱"을 떠올리지만, /office-hours 같은 단계는 그 요청을 그대로 받지 않고, 실제 불편이 무엇인지 다시 묻는다. 그 과정에서 단순한 브리핑 앱이 아니라 일정 맥락을 정리해주는 개인 비서형 문제로 재정의될 수 있고, 이어서 여러 구현 대안과 예상 작업량, 당장 검증할 수 있는 가장 좁은 MVP 범위까지 추천받는 식이다.¹

두 번째는 기존 서비스 개선이다. 이미 운영 중인 웹앱이 있을 때도 Gstack은 곧바로 기능 추가로 들어가기보다, 먼저 제품 관점에서 이 기능이 진짜 필요한지 다시 묻고, 그다음 엔지니어링 관점에서 구조와 실패 시나리오를 점검하게 만든다.¹⁴ 이런 흐름은 스타트업이 자주 겪는 "만들었지만 효과가 약한 기능"을 줄이는 데 도움이 된다. 특히 계획 단계에서 범위를 줄이고, 이후 리뷰와 QA가 그 결정을 이어받는 구조가 실무적으로 유용하다.¹

세 번째는 QA와 배포 자동화다. Gstack은 QA와 shipping을 별도 역할로 다루고, 실제 브라우저 검증과 회귀 테스트, PR 생성, 배포 확인 같은 단계를 분리해 놓는다.¹² 혼자 개발하는 사람이 막판 테스트와 배포에서 자주 놓치는 부분을 줄이는 보조 체계로 쓸 수 있고, 특히 프론트엔드가 있는 제품에서는 이 분리가 꽤 실용적으로 느껴질 수 있다.

한계와 주의할 점

Gstack을 너무 마법처럼 보면 곤란하다. 역할을 나눈다고 해서 판단의 책임까지 사라지는 것은 아니다. AI가 CEO 모드, 리뷰어 모드, QA 모드처럼 보이더라도, 결국 결과를 채택할지 말지는 사람이 결정해야 한다.²

또 하나는 기대치 조절이다. 저장소 소개는 혼자서도 매우 큰 규모의 코드를 빠르게 생산할 수 있다는 강한 생산성 서사를 제시한다.¹ 다만 이런 수치는 작성자의 숙련도, 사용하는 모델과 개발 환경, 문제의 난도, 도메인 특성에 따라 크게 달라질 수 있다. 따라서 Gstack의 가치는 특정 생산성 숫자를 그대로 재현하는 데 있다기보다, 작은 팀의 작업 흐름을 더 구조화하고 반복 가능하게 만드는 데서 찾는 편이 균형 잡힌 해석에 가깝다.

또 Gstack은 구조를 제공하지만, 도메인 이해까지 자동으로 보장하지는 않는다. 헬스케어, 금융, 보안처럼 실수 비용이 큰 영역에서는 AI가 만든 제안이나 코드, 테스트를 그대로 신뢰하기 어렵다. 이 경우 Gstack은 생산성 도구일 수는 있어도, 최종 책임 체계 자체를 대신해주지는 못한다.

마지막으로, 이 방식은 어느 정도 개발 환경과 도구 사용에 익숙한 사람에게 더 잘 맞아 보인다.¹ 웹사이트 빌더처럼 바로 화면을 끌어다 놓는 경험과는 다르기 때문이다. 그래서 비개발자에게는 "생산성을 높여주는 프레임"이 아니라, 오히려 새로 배워야 할 추상화 계층처럼 느껴질 수도 있다.

마무리

Gstack은 AI에게 일을 많이 시키는 방법이라기보다, AI와 함께 일하는 구조를 설계하는 방법으로 이해하면 더 정확하다.¹² 스타트업과 개인 창업자에게 매력적인 이유도 여기에 있다. 사람 수는 적어도, 생각의 역할은 나눌 수 있게 해주기 때문이다.

결국 Gstack의 가치는 "AI가 다 해준다"는 환상보다, "좋은 팀의 일하는 방식을 작은 팀도 흉내 낼 수 있게 한다"는 데 있는 것으로 볼 수 있다. 그 점에서 Gstack은 하나의 툴이라기보다, AI 시대의 스타트업 운영 감각을 보여주는 사례에 더 가깝다.

참고

¹Garry Tan의 gstack GitHub 저장소 소개. (github.com)

²GStack 공식 소개 페이지와 스킬 설명. 역할 분담과 작업 흐름의 기본 개념을 설명한다. (gstacks.org)

³Y Combinator의 Garry Tan 소개 페이지. (ycombinator.com)

⁴GStack의 계획 검토 및 설치/활용 가이드 설명. 설치 흐름과 실제 사용 맥락을 보완한다. (gstacks.org)