
이런 분들께 추천
- 혼자 사이드 프로젝트나 창업을 준비하는 분
- AI로 기획 · 설계 · 구현사이클을 돌리는데 매번 프롬프트를 새로 조합하느라 지친 분
- Claude Code를 쓰고 있지만 더 체계적인 워크플로우가 필요한 분
- Y Combinator와 Garry Tan 쪽 이야기에 관심 있는 분
gstack이 무엇인가?
한 문장으로 정의하면 다음과 같습니다.
혼자 일하는 사람이 Claude Code 하나로 CEO, 엔지니어, 디자이너, QA가 있는 팀처럼 일할 수 있게 해주는 스킬팩.
Y Combinator 대표 Garry Tan이 2026년 3월에 공개한 오픈소스 프로젝트입니다.
Claude Code 터미널에서 /office-hours, /plan-ceo-review, /qa 같은 슬래시 커맨드를 입력하면 Claude가 각 역할을 맡아 응답합니다.
| 항목 | 내용 |
| 만든 사람 | Garry Tan (YC 대표) |
| 공개 시점 | 2026년 3월 |
| 라이선스 | MIT (무료, 오픈소스) |
| GitHub | garrytan/gstack |
| 스타 수 | 72,000+ (2026년 4월 기준) |
| 구성 | 전문가 23명 + 파워 툴 8개 |
내가 AI를 어떻게 쓰는지
gstack 기능 설명에 들어가기 전에, 제가 원래 AI를 어떻게 쓰고 있었는지 먼저 적어두는 게 이 글을 이해하는 데 도움이 될 것 같습니다. 같은 도구를 써도 어떤 사람에게 어떻게 맞는지가 다르니까.
아이디어 검증부터 시작한다
나는 일상이나 산업에서 불편함이나 니즈를 발견하면 일단 AI로 한번 돌려보는 편입니다.. 이게 사업이 될까? 누구의 문제를 해결하는 거지? 이미 비슷한 게 있나? 타겟은 누구로 좁혀야 하지? 구현한다면 어떤 모양이어야 할까? 이 사이클이 꽤 자주 돕니다.
괜찮은 건 뒷단까지 간다
아이디어가 검증되면 기획과 설계까지 가고, 그 중 일부는 구현, 리뷰, 회고 단계까지 끌고 가본 적이 있습니다. 앞으로 이 뒷부분도 AI로 더 본격적으로 다뤄볼 생각입니다.
팀이 할 일을 혼자 해야 한다는 것
이 모든 과정이 혼자 돌아갑니다. 원래는 팀이 있어야 제대로 되는 일들이다. 기획자가 사업성을 체크하고, PM이 스코프를 조율하고, 디자이너가 사용성을 검토하고, 엔지니어가 아키텍처를 설계하고, QA가 테스트하고, 회고에선 다들 모여 돌아봅니다.
혼자 하면 관점이 하나로 갇힐 위험이 있습니다. 내가 짠 기획을 내가 검토하니 객관적이기 어려운 경우입니다.
그래서 AI를 "역할 단위"로 썼다
그래서 각 단계마다 AI에게 다른 역할을 주고 대화했습니다. "너는 시니어 PM이야", "너는 엔지니어야", "너는 디자인 리드야" 같은 식으로 페르소나를 부여하고 프롬프트를 정교하게 짜면, 각 관점에서 피드백을 받을 수 있었다. 괜찮은 프롬프트는 템플릿으로 저장해서 재사용했습니다.
그러다 보니 관리가 피곤해졌다. 템플릿이 어디 저장되어 있는지 매번 찾고, 복사-붙여넣기하고, 단계 넘어갈 때마다 맥락을 다시 입력하고. 매크로처럼 한 번에 불러올 수 있으면 좋겠다는 생각이 들었다.
그 지점에서 gstack을 만났다
친한 동생과 요즘 내가 어떻게 AI를 쓰고있는지 대화하다가, 동생이 gstack을 추천했고, 열어보니 내가 하던 방식과 겹치는 부분이 많았습니다. 역할별로 AI를 나누고, 각 역할이 자기 관점에서 검토하고, 그 결과가 다음 단계로 이어지는 구조.
이 도구가 "나 같은 사람을 위해 설계됐다"고 주장할 생각은 없다. 실제 주 타겟은 창업가와 엔지니어입니다. 다만 혼자서 여러 역할을 돌려야 하는 내 상황에도 써볼 만해 보였습니다. 이미 내가 수동으로 하던 걸 훨씬 잘 구조화해놓은 도구라는 인상이었습니다.
아직 깊게 써본 건 아닙니다. 앞으로 실제로 돌려보면서 나한테 맞는지 확인해볼 생각입니다.
왜 "혼자 쓰는 AI 팀"인가
Garry Tan이 README에서 반복하는 문장이 있습니다..
"gstack turns Claude Code into a virtual engineering team."
(gstack은 Claude Code를 가상 엔지니어링 팀으로 바꾼다.)
이 표현이 단순 마케팅 문구가 아닌 이유는, 그가 실제로 이 방식으로 60일 동안 60만 줄의 코드를 썼기 때문입니다.
이제 AI 도구가 충분히 발전하면서 "어떻게 AI에게 시키는가"가 결과를 가른다고 생각됩니다. gstack은 그 "어떻게"를 23개의 역할로 구조화한 것입니다.
23명의 AI 전문가
스프린트가 돌아가는 순서(Think → Design → Build → Test → Ship → Reflect)로 묶입니다.
🧠 Think — 아이디어 정리
| 스킬 | 역할 |
| /office-hours | YC 오피스 아워 호스트. 6가지 forcing questions로 제품을 재정의 |
| /plan-ceo-review | CEO / 창업자. 스코프 챌린지 (확장·축소·유지) |
| /plan-eng-review | 엔지니어링 매니저. 아키텍처와 데이터 플로우 확정, ASCII 다이어그램 생성 |
| /plan-design-review | 시니어 디자이너. 디자인 방향을 0~10점으로 평가 |
| /plan-devex-review | DX 리드. 개발자 경험 관점으로 검토 |
| /autoplan | 리뷰 파이프라인. 위 리뷰들을 자동 연쇄 실행 |
🎨 Design — 디자인 시스템
| 스킬 | 역할 |
| /design-consultation | 디자인 파트너. 디자인 시스템을 처음부터 구축 |
| /design-shotgun | 디자인 탐험가. AI 목업 4~6개 생성, 비교하며 반복 |
| /design-html | 디자인 엔지니어. 목업을 production HTML로 변환 |
| /design-review | 코딩하는 디자이너. 실제 화면 감사 후 자동 수정 |
🛠 Build / Review — 구현과 검토
| 스킬 | 역할 |
| /review | 스태프 엔지니어. 프로덕션에서 터지는 버그를 잡고 자동 수정 |
| /investigate | 디버거. "조사 없이 수정 금지" 원칙의 근본 원인 분석 |
| /codex | 2차 의견. OpenAI Codex CLI로 독립적 리뷰 |
| /cso | 보안 책임자. OWASP Top 10 + STRIDE 감사 |
🧪 Test / Ship — 테스트와 배포
| 스킬 | 역할 |
| /qa | QA 리드. 실제 브라우저로 클릭 테스트, 회귀 테스트 자동 생성 |
| /ship | 릴리스 엔지니어. 테스트·커버리지·PR 자동화 |
| /land-and-deploy | 릴리스 엔지니어. 머지 → CI → 배포까지 확인 |
| /canary | SRE. 배포 후 30분 모니터링 |
| /benchmark | 성능 엔지니어. Core Web Vitals 측정 |
🔄 Reflect — 회고와 문서
| 스킬 | 역할 |
| /retro | 엔지니어링 매니저. 주간 회고, 멀티 프로젝트 지원 |
| /document-release | 테크니컬 라이터. 문서 자동 동기화 |
| /learn | 메모리. 세션 간 학습 내용 관리 |
⚙️ 파워 툴 (전문가 스킬을 더 안전하고 편하게 쓰도록 보조하는 유틸리티)
| 스킬 | 역할 |
| /careful /freeze /guard /unfreeze | 안전장치 (rm -rf, force-push 등 위험 명령 경고) |
| /browse /open-gstack-browser | 실제 브라우저 조작 |
| /pair-agent | 다른 AI 에이전트와 협 |
| /gstack-upgrade | gstack 자체 업데이트 |
gstack의 철학 — ETHOS
이 스킬들을 관통하는 세 가지 원칙이 ETHOS.md에 정리되어 있습니다.
Garry Tan은 이것이 gstack의 영혼이라고 말합니다.
0. The Golden Age — 황금기
"한 사람이 AI와 함께, 예전 팀 20명이 하던 일을 할 수 있는 시대가 왔다."
Garry는 이것을 예측이 아니라 지금 벌어지고 있는 현실이라고 봅니다.
"팀이 예전엔 시간 없어서 스킵하던 '완성도의 마지막 10%', 이제는 몇 초 비용이다."
AI 덕분에 "꼼꼼하게 만드는 비용"이 싸졌습니다.
비유하자면 이렇습니다. 발표 자료를 만들 때, 핵심 슬라이드 10장(80%)과 부록·예시·출처까지 포함한 30장(100%)을 선택할 수 있다고 해봅시다. 예전엔 둘 차이가 반나절 vs 이틀이어서, 다들 10장으로 만족했습니다.
지금은 AI가 도와주면 이 차이가 10분입니다. 그럼 10장으로 내놓을 이유가 없습니다. 처음부터 30장짜리 완성본을 내면 됩니다.
"90% 되면 출시하자"는 말은, 사람 시간이 부족하던 시절의 타협입니다. 더 이상 그 제약이 없습니다.
1. Boil the Lake — 호수를 끓여라
영어 관용구 "Boil the ocean(바다를 끓인다)"은 "불가능할 만큼 큰 일"이라는 부정적 의미로 쓰입니다. Garry는 이 표현을 뒤집습니다. 바다는 아니지만 호수는 끓일 수 있다는 의미입니다.
완전한 것과 축약형의 비용 차이가 몇 분이라면, 무조건 완전한 쪽을 선택하라는 것이 핵심입니다. "90% 되면 출시하자"는 인간 엔지니어링 시간이 병목이던 시절의 사고방식이라는 뜻입니다.
2. Search Before Building — 만들기 전에 검색하라
뛰어난 엔지니어의 첫 본능은 "처음부터 설계하자"가 아니라 "누가 이미 푼 거 아닌가?". Garry는 지식을 세 레이어로 나눕니다.
- Layer 1 (검증된 것): 이미 다들 쓰는 표준. 토스, 뱅크샐러드, 카카오뱅크 가계부가 있습니다. 카드 연동, 자동 분류 같은 기본 기능은 다 비슷하게 구현되어 있어요. 대부분 이미 알고 있는 영역입니다.
- Layer 2 (유행하는 것): 요즘 뜨는 방식. "AI 기반 지출 분석", "음성으로 가계부 입력", "Notion처럼 커스터마이즈 가능" 같은 트렌드가 있습니다. 블로그와 프로덕트 헌트에 자주 등장합니다. 하지만 유행이 진짜 해답인지는 따로 검증해야합니다.
- Layer 3 (제1원리): 구체적 문제에서 나오는 독창적 관찰. 예를 들어 "바쁜 직장인은 카드 명세서를 '분류'하는 게 아니라 '한 달에 외식비로 얼마 쓰는지' 한 문장만 궁금해한다"는 통찰. 아무도 이 관점으로 만들지 않았다면, 이게 가장 귀한 발견입니다.
가장 탁월한 순간은 Layer 1과 2를 이해한 뒤 제1원리(Layer3)로 관습을 뒤집는 지점입니다.
(다들 당연하다고 여기는 방식 말고, 다른 관점으로 가라.)
3. Build for Yourself — 자기 자신을 위해 만들어라
"최고의 툴은 자기 문제를 푸는 툴이다."
gstack 자체가 그 예입니다. Garry Tan이 자기가 쓰려고 만들었고, 모든 기능이 "요청받아서"가 아니라 "필요해서" 만들어졌습니다. 현실 문제의 구체성은 가상 문제의 일반성을 항상 이깁니다.
만든 사람 — Garry Tan
| 역할 | 내용 |
| 현재 | Y Combinator 대표 (President & CEO) |
| 배경 | Palantir 초창기 엔지니어·PM·디자이너 (Palantir 로고 디자인) |
| 창업 | Posterous 공동창업 → Twitter 인수 |
| 투자 | Initialized Capital 공동창업 (Coinbase, Instacart, Rippling 초기 투자) |
| 2013년 | YC 내부 소셜 네트워크 Bookface를 혼자 구축 |
핵심은 그가 코드를 쓸 줄 아는 투자자이자 CEO라는 점입니다.
그래서 gstack은 "개발자가 만든 개발자 도구"보다는 "빌더가 만든 빌더 도구"에 가깝다고 생각됩니다.
한계와 주의점
미리 알아둘 것들.
- Claude Code 필수: Anthropic 구독이 필요하다 (무료 티어는 제한적)
- 터미널 친숙도 필요: GUI 없음
- Windows 설치 복잡: WSL을 써야 하고 설치 중 에러 발생 가능 (다음 글에서 다룰 예정입니다.)
- 영어 기반: 스킬 프롬프트가 영어. 한국어로 대화해도 잘 동작한다고 생각하지만 뉘앙스 차이는 있을 수 있음
- 작은 작업엔 과함: 3분짜리 작업을 gstack으로 돌리면 오버엔지니어링
정리
gstack은 도구 모음이 아니라 프로세스입니다. 혼자 일하는 사람을 위해 구조화된 AI 팀의 형태로 제공됩니다.
저는 이걸 쓸지 말지 고민하는 단계에서 깊이 써보지도 않고 확신하는 건 피하고 싶습니다. 다만 이미 수동으로 하던 걸 훨씬 잘 정돈해놓은 도구라는 점에서, 한동안 이걸 주로 사용하여 돌려볼 가치는 있어 보입니다. 안 맞으면 빠지면 되고, 맞으면 계속 쓰면 됩니다.
다음 글 예고
다음 글에서는 이 gstack을 Windows PC에 실제로 설치하는 과정을 정리할 예정입니다. 공식 문서가 Windows 사용자에게 딱 3줄만 남겨서, 실제로 설치하면 여러가지 에러를 만나게 됩니다. 그 해결 과정을 기록했습니다.
참고 링크
'IT > 스크랩(제품,도구)' 카테고리의 다른 글
| [gstack #2] Windows에서 gstack 설치하기 (Git Bash와 WSL 둘 다) (1) | 2026.04.19 |
|---|---|
| 브라우저에서 회로 만들고 시뮬레이션까지 — Diode (0) | 2026.02.25 |