하나의 AI 에이전트가 기획·설계·구현·리뷰·배포까지 모두 담당하면, 어느 순간부터 자기 검토가 된다. G-Stack은 이 문제를 “역할을 나눈다”는 단순하지만 강력한 방식으로 푼다. CEO, 엔지니어링 매니저, QA 리드, 보안 책임자가 각자의 렌즈로 같은 코드를 따로 검토하는 구조다. 건축 현장에서 감리단이 건축·구조·소방 엔지니어를 따로 두는 것과 같은 원리.
한 줄 결론: 범용 에이전트 하나에 전부 맡기지 말고, 전문가 역할을 나눠 각 단계를 다른 관점으로 검토하면 AI 코딩의 품질이 근본적으로 달라진다.
왜 하나의 에이전트에 모든 걸 맡기면 안 되는가
Claude Code 하나로 프로젝트를 진행하다 보면 이런 경험을 하게 된다. “이 기능 추가해줘”라고 하면 AI가 기획도 하고, 코드도 짜고, 리뷰도 하고, 테스트도 한다. 빠르긴 하지만, 자기가 짠 코드를 자기가 리뷰하는 구조다. 사람으로 치면 개발자가 자기 PR에 직접 “LGTM”을 붙이는 셈.
문제는 구체적으로 이렇게 나타난다.
- 기획 단계의 사용자 관점 누락: “사진 업로드 기능 추가해줘”라고 하면 AI는 파일 선택기와 이미지 저장 로직을 구현한다. 하지만 진짜 필요한 건 “이 사진으로 자동으로 상품을 식별하고, 가격 비교까지 해주는 스마트 리스팅”일 수 있다. 기획을 코드 작성자와 같은 시각에서 보면 이런 재정의가 빠진다.
- 리뷰의 관성: AI가 방금 작성한 코드를 곧바로 리뷰하면, 작성할 때 가졌던 전제를 그대로 유지한다. “이 에러 핸들링은 괜찮겠지”라고 넘어간 부분을 다른 관점에서 보면 명백한 버그인 경우가 많다.
- 배포 후 검증 부재: 코드가 CI를 통과했다고 프로덕션에서 안전한 건 아니다. 실제 브라우저에서 클릭해 보고, 콘솔 에러를 확인하고, 보안 취약점을 스캔하는 건 전혀 다른 영역이다.
Andrej Karpathy가 2026년 3월 “작년 12월 이후로 코딩을 직접 한 줄도 안 했다”고 말했을 때, 핵심은 “AI가 다 해준다”가 아니었다. “올바른 프로세스를 세우면 한 사람이 팀 스물 명의 생산성을 낼 수 있다”는 점이었다. G-Stack은 그 프로세스를 도구화한 것이다.
G-Stack의 접근법 — “관점을 제약하라”
YC(이드 콤비네이터)의 CEO인 Garry Tan이 만든 G-Stack(garrytan/gstack)은 Claude Code를 가상의 엔지니어링 팀으로 바꾸는 오픈소스 프레임워크다. 2026년 4월 기준 GitHub 스타 6만 7천 개, 포크 9천 개를 기록 중이다.
핵심 철학은 **“관점을 제약한다”**는 것이다. 하나의 프롬프트로 모든 걸 하게 두지 않고, 각 슬래시 명령어가 특정 전문가 역할만 수행하도록 제한한다. CEO는 제품 비전만 검토하고, 엔지니어링 매니저는 아키텍처만 검토하고, QA 리드는 브라우저에서만 테스트한다. 각 역할의 “시야”가 좁을수록, 그 시야 안에서의 깊이는 깊어진다.
flowchart TB subgraph "Think" OH["/office-hours<br/>YC 파트너"] end subgraph "Plan" CEO["/plan-ceo-review<br/>CEO / 창업자"] ENG["/plan-eng-review<br/>엔지니어링 매니저"] DES["/plan-design-review<br/>시니어 디자이너"] DX["/plan-devex-review<br/>DX 리드"] end subgraph "Build" IMPL["코드 구현"] end subgraph "Review" REV["/review<br/>스태프 엔지니어"] CSO["/cso<br/>보안 책임자"] DR["/design-review<br/>디자이너"] end subgraph "Test" QA["/qa<br/>QA 리드"] BENCH["/benchmark<br/>퍼포먼스 엔지니어"] end subgraph "Ship" SHIP["/ship<br/>릴리즈 엔지니어"] DEPLOY["/land-and-deploy<br/>릴리즈 엔지니어"] CANARY["/canary<br/>SRE"] end OH --> CEO CEO --> ENG CEO --> DES CEO --> DX ENG --> IMPL DES --> IMPL DX --> IMPL IMPL --> REV IMPL --> CSO IMPL --> DR REV --> QA CSO --> QA QA --> SHIP SHIP --> DEPLOY DEPLOY --> CANARY
역할 구조 상세 — 23개 전문가가 하는 일
G-Stack은 23개의 슬래시 명령어(스킬)를 제공하며, 각각이 하나의 전문가 역할을 담당한다. 스프린트 라이프사이클 Think → Plan → Build → Review → Test → Ship의 각 단계에 맞춰 역할이 배치되어 있다.
Think 단계 — 문제 재정의
/office-hours (YC 파트너): 모든 프로젝트의 시작점이다. YC 파트너가 창업자에게 던지는 것과 같은 6개의 강제 질문으로, 사용자가 “뭘 만들고 싶은지”가 아니라 “실제로 어떤 문제를 겪고 있는지”를 끌어낸다. “데일리 브리핑 앱을 만들고 싶어요”라고 하면, 이 스킬은 “지금 말씀하신 건 브리핑 앱이 아니라 개인 비서 AI입니다”라고 프레이밍을 바꾼다. 결과물은 디자인 문서로, 이후 모든 단계의 입력이 된다.
Plan 단계 — 네 각도에서 계획 검증
/plan-ceo-review (CEO / 창업자): 기능 요청을 비판적으로 재검토한다. “사진 업로드 추가”라는 요청이 들어오면, 그 안에 숨은 10점짜리 제품을 찾는다. 사진에서 자동으로 상품을 식별하고, 가격 비교 데이터를 가져오고, 최적의 썸네일을 추천하는 “스마트 리스팅”이 진짜 기능인지 묻는다. 네 가지 모드(확장, 선택적 확장, 현행 유지, 축소)로 범위를 조절한다.
/plan-eng-review (엔지니어링 매니저): 제품 비전이 확정되면 완전히 다른 관점이 필요하다. 아키텍처, 데이터 흐름, 상태 전이, 실패 모드, 에지 케이스, 테스트 커버리지를 검토한다. 특히 다이어그램(시퀀스, 상태, 컴포넌트, 데이터 흐름)을 강제로 그리게 해서, 애매한 계획을 구체화한다.
/plan-design-review (시니어 디자이너): 각 디자인 차원을 0~10점으로 평가하고, 10점이 어떤 모습인지 설명한 뒤 계획을 수정한다. AI가 생성한 “그럴듯하지만 실제로는 어색한” 디자인(AI slop)을 감지하는 것도 이 역할의 몫이다.
/plan-devex-review (DX 리드): 개발자 경험을 전문적으로 검토한다. 경쟁사 대비 Time-to-Hello-World를 비교하고, 온보딩 마찰 지점을 단계별로 추적한다. 20~45개의 강제 질문으로 숨겨진 가정을 끄집어낸다.
Build 단계 — 구현 + 디자인 파이프라인
구현 자체는 Claude Code가 수행하지만, G-Stack은 디자인 파이프라인으로 구현 품질을 한 단계 끌어올린다.
/design-shotgun: “옵션을 보여줘”라고 하면 4~6개의 AI 목업 변형을 생성하고, 브라우저에서 비교 보드를 연다. 취향 메모리가 쌓여서 반복할수록 사용자가 선호하는 방향으로 수렴한다.
/design-html: 승인된 목업을 프로덕션 품질의 HTML/CSS로 변환한다. 텍스트가 리사이즈에 맞게 리플로우되고, 레이아웃이 동적으로 조정된다. 30KB, 의존성 제로.
Review 단계 — 다른 눈으로 코드 검토
/review (스태프 엔지니어): CI는 통과하지만 프로덕션에서 터지는 버그를 찾는다. 명백한 건 자동 수정하고, 판단이 필요한 건 사용자에게 플래그를 올린다.
/cso (보안 책임자): OWASP Top 10과 STRIDE 위협 모델링으로 보안 감사를 수행한다. 8/10 이상 신뢰도 게이트를 적용해 노이즈를 줄이고, 각 발견에 구체적인 익스플로잇 시나리오를 포함한다.
/codex (세컨 오피니언): OpenAI Codex CLI로 독립적인 코드 리뷰를 받는다. Claude와 OpenAI, 두 가지 다른 AI가 같은 코드를 검토하면 교차 분석으로 고유한 발견과 겹치는 발견을 구분할 수 있다.
Test 단계 — 실제 브라우저에서 검증
/qa (QA 리드): 실제 Chromium 브라우저를 열어 앱을 클릭해 보고 버그를 찾아 수정한다. 버그 수정 시 회귀 테스트를 자동 생성하고, 수정 후 재검증까지 수행한다. Garry Tan은 이 스킬 덕분에 병렬 워커를 6개에서 12개로 늘렸다고 한다.
/benchmark (퍼포먼스 엔지니어): 페이지 로드 시간, Core Web Vitals, 리소스 크기를 베이스라인으로 잡고, PR마다 before/after 비교를 수행한다.
Ship 단계 — 배포부터 모니터링까지
/ship: main 브랜치 동기화, 테스트 실행, 커버리지 감사, 푸시, PR 생성까지 한 번에. 테스트 프레임워크가 없으면 새로 부트스트랩까지 해준다.
/land-and-deploy: PR을 머지하고 CI/배포 완료를 기다린 뒤, 프로덕션 건강을 검증한다.
/canary (SRE): 배포 후 콘솔 에러, 퍼포먼스 회귀, 페이지 실패를 지속 모니터링한다.
안전 가드레일
/careful: 파괴적 명령(rm -rf, DROP TABLE, force-push) 실행 전 경고. /freeze: 파일 수정을 특정 디렉토리로 제한. /guard: 두 가지를 동시에 적용.
워크플로우 — 실제로 어떻게 돌아가는가
G-Stack의 각 스킬은 독립적으로도 쓸 수 있지만, 진짜 힘은 연속으로 실행할 때 나온다. 각 단계의 출력이 다음 단계의 입력이 된다.
실제 시나리오 — 캘린더 앱 개발:
/office-hours— “데일리 브리핑 앱을 만들고 싶어요” → “지금 말씀하신 건 개인 비서 AI입니다. 핵심 기능 5개를 재정의했습니다.”/plan-ceo-review— 재정의된 기능을 CEO 관점에서 검토. “좁은 쐐기부터 배포하라”는 권고./plan-eng-review— 아키텍처 다이어그램, 데이터 흐름, 실패 모드 정리.- 구현 — 11개 파일에 2,400줄 작성 (약 8분).
/review— 자동 수정 2건, 사용자 승인 필요 1건(레이스 컨디션)./qa— 실제 브라우저에서 클릭 테스트. 버그 1건 발견 후 수정 및 회귀 테스트 생성./ship— 테스트 42→51개. PR 생성 완료.
Garry Tan은 이 프로세스로 최근 60일간 60만 줄 이상의 프로덕션 코드를 작성했다. 하루 1~2만 줄, YC CEO를 풀타임으로 하면서 파트타임으로.
설치와 사용법
G-Stack은 Claude Code 전용이 아니다. Claude Code, OpenAI Codex CLI, OpenCode, Cursor, Factory Droid, Slate, Kiro 등 8개의 코딩 에이전트를 지원한다.
설치 (30초):
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup설치 후 Claude Code를 열면 23개의 슬래시 명령어가 바로 사용 가능하다. 자동 업데이트도 1시간에 한 번 조용히 확인한다.
팀 적용:
cd <your-repo>
~/.claude/skills/gstack/bin/gstack-team-init required
git add .claude/ CLAUDE.md && git commit -m "require gstack for AI-assisted work"required 모드에서는 팀원의 Claude Code가 G-Stack 없이 작동하지 않는다. optional 모드도 가능하다.
OpenClaw 연동: OpenClaw에서 ACP로 Claude Code 세션을 띄울 때도 G-Stack 스킬이 그대로 작동한다. ClawHub에서 gstack-openclaw-office-hours 등 4개 대화형 스킬을 설치하면 Claude Code 없이도 챗봇에서 바로 쓸 수 있다.
장단점
장점
- 관점 분리로 인한 품질 향상: 같은 코드를 4~5개의 다른 렌즈로 검토하니, 단일 에이전트보다 놓치는 게 확실히 줄어든다.
- 프로세스 자동화: Think → Plan → Build → Review → Test → Ship의 각 단계가 다음 단계에 컨텍스트를 넘겨주니, 수동으로 프롬프트를 복사할 필요가 없다.
- 실제 브라우저 테스트:
/qa가 실제 Chromium에서 앱을 조작하는 건, 코드만 보는 리뷰와는 차원이 다른 검증이다. - 멀티 에이전트 지원: Claude Code 외에도 Codex, OpenCode, Cursor 등 8개 에이전트에서 동일한 워크플로우를 사용할 수 있다.
- 병렬 스프린트: Conductor와 결합하면 10~15개의 병렬 스프린트를 돌릴 수 있다. 하나는 기획, 하나는 리뷰, 하나는 QA를 동시에.
한계와 고려사항
- 프롬프트 오버헤드: 23개 스킬을 전부 돌리면 토큰 소모가 크다. 각 단계마다 수천 토큰의 컨텍스트가 누적된다.
- 학습 곡선: 어떤 스킬을 언제 쓸지 파악하는 데 시간이 필요하다.
/autoplan이 어느 정도 이 문제를 완화하지만, 초반에는 시행착오가 있다. - Garry Tan의 워크플로우에 최적화: 스킬 구성이 YC 스타일 스타트업 개발에 맞춰져 있다. 대기업 환경이나 다른 개발 문화에서는 역할을 조정해야 할 수 있다.
- Claude Code 의존도: 다른 에이전트도 지원하지만, 가장 깊게 통합된 건 Claude Code다.
칠판 치트시트
┌─────────────────────────────────────────────────────┐
│ G-Stack 핵심 요약 │
│ │
│ 1. /office-hours로 시작 — 뭘 만들지가 아니라 │
│ 뭘 겪고 있는지부터 파악 │
│ │
│ 2. /plan-ceo-review → /plan-eng-review 순서로 │
│ 제품 비전 → 아키텍처 순 검증 │
│ │
│ 3. /review + /qa 조합이 핵심 — │
│ 코드 리뷰 + 실제 브라우저 테스트 │
│ │
│ 4. /autoplan로 전체 자동화, │
│ 취향 결정만 사람이 승인 │
│ │
│ 5. /guard로 안전장치 — │
│ 파괴적 명령 차단 + 수정 범위 제한 │
└─────────────────────────────────────────────────────┘
다른 코딩 에이전트 프레임워크와의 차이
G-Stack과 비슷한 문제를 푸는 도구들이 있다. Superpowers는 TDD를 강제해서 코드 품질을 보장하고, GSD는 컨텍스트 관리로 장기 프로젝트의 일관성을 유지한다. 하지만 G-Stack의 차이점은 “역할 분리”라는 메타 접근이다. 코드 레벨의 규칙(TDD, 컨텍스트 윈도우 관리)이 아니라, 프로세스 레벨에서 다른 시각을 강제하는 방식이다.
건축에 비유하면 이해가 쉽다. Superpowers가 “모든 자재를 검사해서 품질을 보장”하는 거라면, G-Stack은 “건축 엔지니어, 구조 엔지니어, 소방 엔지니어가 각자 따로 검사”하는 거다. 전자는 같은 관점에서의 깊이, 후자는 다른 관점에서의 breadth다. 둘은 충돌하지 않는다. 같이 쓸수록 좋다.
💡 참고: 이 글은 garrytan/gstack 공식 리포지토리와 README를 기반으로 작성되었습니다. 스킬 철학과 상세 예시는 docs/skills.md에서 확인할 수 있습니다.
다음 읽기:
🤖 이 글은 AI가 작성 후 인간이 검토한 콘텐츠입니다.