G스택이 AI 개발 방식을 바꾸는 이유
핵심 요약
- G스택은 AI를 28명 전문가 팀으로 쪼갠 시스템입니다.
- 코딩 전 오피스 아워로 아이디어부터 검증합니다.
- 디자인 리뷰로 진부한 ‘AI 티’ 디자인을 제거합니다.
- 7단계 워크플로우로 기획부터 배포까지 잇습니다.
- 1인 개발자·솔로 창업자에게 특히 유용합니다.
AI에게 “이런 앱 만들어 줘”라고 주문해 본 사람이라면, 돌아가긴 하는데 어딘가 불안한 결과물을 받아본 경험이 있을 겁니다. 기능은 있는 것 같은데 기획은 허술하고, 디자인은 ‘AI가 만든 티’가 역력하고, 보안은 믿기 어렵습니다. 이유는 단순합니다. 우리는 지금까지 AI에게 코딩만 시켜 왔기 때문입니다.
Related: 하네스 엔지니어링 완전 정복: 모델 무관 AI 코드 품질 가이드
Related: Claude MCP 완벽 가이드: Canva·Zapier·Stripe 워크플로우 자동화 | 실전 설정법
Related: 하네스 엔지니어링으로 LLM 코드 품질 멱등성 확보하기 | 실전 AX 가이드
Related: AI 네이티브와 지능 배분 전략: 에이전틱 AI 시대 비즈니스 가이드
Related: 팔란티어 AI 에이전트와 온톨로지: 진짜 엔터프라이즈 AI 아키텍처 가이드
Y Combinator 대표 게리 탄이 공개한 G스택(G-Stack) 은 이 문제를 정면으로 건드립니다. AI 하나를 28개의 전문가 역할로 쪼개, 실제 개발 조직처럼 기획–설계–구현–검수–테스트–보안–배포–회고까지 전 과정을 책임지게 만드는 시스템입니다. GitHub 공개 2주 만에 Star 4만 8천 개를 넘긴 이유도 여기에 있습니다.
G스택이 무엇이고 어떻게 동작하는지, 그리고 1인 개발자와 솔로 창업자에게 무엇을 바꿔주는지 구조와 사례를 중심으로 정리했습니다.
G스택이란 무엇인가?
G스택(G-Stack)이란 AI 하나를 28개의 전문가 역할로 분리해 실제 개발 팀과 유사한 협업 구조를 구현하는 오픈소스 AI 개발 팀 시스템입니다. 일반적인 AI 코딩 도구가 ‘무엇이든 해 주는 만능 비서’라면, G스택은 각 에이전트에게 직무·책임·워크플로우를 부여합니다.
YC 대표 게리 탄(Garry Tan) 이 실제 업무에 써온 방법론을 바탕으로 만들어졌습니다. 그는 이 구조로 60일 동안 혼자 60만 줄의 코드를 작성했다고 밝혔고, GitHub에 올라온 지 2주 만에 Star 4만 8천 개를 기록했습니다.
“AI한테 코딩만 시키니까 그래요. 코딩은 소프트웨어를 만드는 과정의 일부분일 뿐이거든요.”
28개 전문가 역할 구조
G스택이 나누는 역할은 대략 이렇습니다.
- 대표(CEO)
- 개발 팀장(Tech Lead)
- 디자이너(Designer)
- 품질 관리자(QA)
- 보안 담당자(Security)
- 출시 담당자(Launch Manager)
- 아이디어 검증 담당(Office Hours)
- 디자인 품질 검수(Design Review)
- 배포·모니터링·회고 담당 등
각 역할은 앞 단계 산출물을 자동으로 받아 다음 일을 이어서 수행합니다. 기획팀 문서를 개발팀이 넘겨받고, 다시 QA팀이 테스트하는 회사 구조를 그대로 AI 워크플로우로 옮겨놓은 셈입니다.
사용 방식과 도구 요구사항
채팅창에서 슬래시(/) 뒤에 역할 이름을 입력하면 해당 에이전트가 활성화됩니다.
/office-hours→ 아이디어 검증 및 기획서 작성/design-review→ 디자인 품질 점검 및 수정/review→ 코드 리뷰/qa→ 브라우저 기반 QA 테스트
필요한 건 두 가지입니다.
클로드 코드(Claude Code)계정GitHub계정
두 도구 모두 기본 기능은 무료이고, G스택 설치는 터미널에서 명령어 몇 줄로 30초 안에 끝납니다.
왜 AI에게 코딩만 시키면 실패하는가?
소프트웨어 개발이란 코드 작성이 아니라 여러 단계가 연결된 프로세스 전체를 의미하는 복합 작업입니다. G스택이 전제로 삼는 개발 생명 주기(SDLC)는 다음 7단계로 구성됩니다.
- 기획(Planning)
- 설계(Design)
- 구현(Implementation, Coding)
- 검수(Review)
- 테스트(Testing)
- 배포(Deployment)
- 회고(Retrospective)
대부분의 AI 사용 패턴은 “이런 앱 만들어 줘”라는 한 줄로 3단계(코딩)만 던져버립니다. 그러면 결과물은 일단 돌아가긴 하는데, 기획이 허술하고, 보안에 구멍이 있고, 디자인은 촌스럽고, 유지보수가 막막한 코드가 됩니다.
영상에서는 이걸 식당 운영에 빗댑니다. 요리사만 뛰어나다고 식당이 성공하는 게 아니듯, 소프트웨어도 코딩 외에 기획·설계·위생(보안)·서비스(QA)·회계(운영)가 함께 돌아가야 완성됩니다.
“생각이 먼저고 만드는 건 나중입니다.”
— G스택 오피스 아워의 핵심 원칙
직접 이 구조를 써보면 이 원칙이 단순한 구호가 아니라는 걸 금방 실감하게 됩니다. 아이디어를 바로 코드로 옮기려다 멈추고 6가지 질문을 받는 경험은 꽤 불편하지만, 그만큼 실질적입니다.
오피스 아워란 무엇인가?
오피스 아워(Office Hours)란 코드를 한 줄도 작성하기 전에, AI가 소크라테스식 6가지 질문으로 아이디어의 타당성을 검증하는 기능입니다. 실제 YC에서 운영하는 멘토링 세션을 AI로 옮긴 구조입니다.
YC 창립자 폴 그레이엄(Paul Graham) 은 오피스 아워를 이렇게 요약합니다.
“오피스 아워의 핵심은 가장 중요한 걸 찾고, 어떻게 할지 정하고, 결과를 어떻게 질지 정하는 것이다.”
답을 주는 멘토가 아니라, 질문으로 스스로 허점을 발견하게 만드는 멘토를 AI로 구현한 겁니다.
소크라테스식 문답법과 ‘바람직한 어려움’
오피스 아워의 철학적 뿌리는 소크라테스(Socrates) 문답법입니다. 그는 자신을 “지식의 산파”라고 불렀습니다. 지식은 밖에서 집어넣는 게 아니라 이미 안에 있는 것을 끌어내는 거라는 믿음 때문입니다.
- “그게 무슨 뜻인가요?”
- “근거가 뭔가요?”
- “누군가 반대한다면 어떻게 반박할 건가요?”
UCLA의 로버트 비어크(Robert Bjork) 교수 연구에 따르면, 스스로 답을 찾는 과정은 ‘바람직한 어려움(Desirable Difficulty)’ 을 만들어 단순 설명을 들은 사람보다 장기 기억 보유율이 60% 이상 높다고 합니다.
오피스 아워의 6가지 핵심 질문
-
진짜 수요가 있는가?
이 제품이 없어지면 화가 날 정도로 원하는 사람이 있는가? -
지금은 어떻게 해결하고 있는가?
현재 대안이 전혀 없다면 애초에 진짜 문제가 아닐 수도 있다. -
구체적으로 누구에게 필요한가?
“마케팅 팀”이 아니라, 특정 한 사람의 직업·고민·불면의 이유까지 들어가야 한다. -
가장 작은 시작은 무엇인가?
이번 주 안에 누군가가 돈을 지불할 수 있는 최소 버전은 무엇인가? -
직접 사용자를 본 적이 있는가?
예상과 다르게 행동한 부분은 무엇이었나? -
미래에도 필요한가?
3년 후 세상이 바뀌었을 때, 이 제품의 필요성은 더 커지는가, 줄어드는가?
오피스 아워의 출력물은 코드가 아니라 기획서(Specification Document) 입니다. 이 단계에서 코드는 단 한 줄도 생성하지 않는 게 원칙입니다.
아부 금지, 날카로운 피드백 강제
오피스 아워 설계에서 흥미로운 부분은 AI가 아부하지 못하도록 금지 규칙을 둔 겁니다.
- “좋은 아이디어네요”, “여러 방법이 있죠” 같은 말은 금지
- AI는 자기 입장을 분명히 밝히고, 명확한 근거를 제시한 뒤 사용자의 반박을 유도
실제로 한 사용자가 “일정 관리 앱을 만들고 싶다”고 하자, 오피스 아워는 이렇게 지적했습니다.
“당신이 실제로 묘사한 것은 알림 앱이 아니라 개인 비서 AI입니다.”
사용자 본인도 인식하지 못했던 제품의 본질을 짚어낸 사례입니다. “질문이 먼저, 코드는 나중”이라는 원칙이 그냥 나온 게 아닙니다.
디자인 리뷰란 무엇인가?
디자인 리뷰(Design Review)는 AI가 실제 웹 브라우저를 직접 열어 80개 항목 체크리스트로 UI/UX를 점검하고, 발견된 문제를 자동으로 수정하는 기능입니다.
G스택은 AI가 반복적으로 만들어내는 진부한 시각적 패턴을 ‘AI 슬롭(AI Slop)’ 이라고 부릅니다. 누가 봐도 “이거 AI가 만들었네” 싶은 디자인 말입니다.
AI 슬롭의 전형적인 패턴
디자인 리뷰가 잡아내는 패턴은 꽤 구체적입니다.
- 보라색·남색 그라데이션 배경
- 3열 구성의 아이콘 + 굵은 제목 + 두 줄 설명
- 색깔 원 안에 아이콘 배치
- 모든 요소의 중앙 정렬
- 과도하게 둥근 모서리
- 불필요한 물방울·물결 장식
- 제목의 로켓 이모지
- 카드 왼쪽의 색깔 강조선
- “Unlock the Power of …” 같은 상투적인 문구
- “히어로 → 기능 → 후기 → 가격 → CTA 버튼”의 판에 박힌 레이아웃
목록을 보면 웃음이 나올 수도 있는데, 실제로 이 패턴들이 얼마나 많은 AI 생성 UI에 그대로 박혀 있는지를 확인하고 나면 좀 씁쓸해집니다.
80개 체크리스트 구조와 자동 수정
80개 항목은 6개 카테고리와 AI 슬롭 전용 항목으로 나뉩니다.
- 글꼴(Typography) 15개
- 색상(Color) 10개
- 여백·배치(Spacing & Layout) 12개
- 인터랙션(Interaction) 10개
- 반응형(Responsive Design) 8개
- 애니메이션(Animation) 6개
- AI 슬롭 탐지 전용 10개
검사 결과는 A~F 등급으로 나오며, 일반 디자인 점수와 AI 슬롭 점수가 별도로 산출됩니다.
단순 리포트에서 끝나지 않는 게 이 기능의 핵심입니다.
- 디자인 코드를 직접 수정
- 수정 전·후 화면을 캡처해 비교 자료로 저장
- 마음에 들지 않으면 손쉽게 롤백(Rollback) 가능
- 여러 AI가 동시에 같은 디자인을 검토하는 교차 검증(Cross-Validation) 지원
단일 AI의 편향을 줄이고 보다 객관적인 결과를 얻을 수 있습니다.
7단계 통합 워크플로우란 무엇인가?
7단계 통합 워크플로우(Integrated Workflow)는 소프트웨어 개발의 전 과정을 하나의 파이프라인으로 연결하는 G스택의 핵심 구조입니다. 각 단계의 결과물이 자동으로 다음 단계의 입력값이 되는데, 이건 여러 AI 도구를 그냥 모아놓은 것과는 다른 수준의 통합입니다.
실제 회사에서 부서 간 “업무 인수인계”를 AI 사이에서 자동화했다고 보면 됩니다.
단계별 구체 흐름
1. /office-hours – 아이디어 검증 및 기획서 도출
소크라테스식 6가지 질문으로 아이디어를 검증하고 명시적인 기획서(Spec)를 생성합니다.
2. /plan-ceo-review – 대표 관점 범위 조율
CEO 시각으로 제품 범위를 키울지·줄일지·유지할지 결정합니다.
3. /plan-review – 기술 설계와 테스트 계획 수립
기술 설계(Technical Design)와 테스트 계획(Test Plan)을 함께 정의합니다.
4. /review – 시니어 개발자급 코드 검수
10년 차 개발자가 옆에서 코드를 보는 것처럼 눈에 잘 안 보이는 위험 요소까지 검토합니다.
5. /qa – 실제 브라우저 기반 QA
실제 웹 브라우저를 자동으로 열어 클릭·입력·캡처를 수행하며 품질을 검증합니다. 속도는 0.1초 클릭, 1초 내 결과 수준입니다.
6. /sco – 보안(Security) 점검
해커가 침투할 수 있는 취약점을 탐지합니다. 실제로 한 스타트업이 이 단계에서 자사 개발팀도 몰랐던 보안 취약점을 발견한 사례가 있습니다.
7. /launch-and-deploy, /canary, /retro – 배포·모니터링·회고
/launch-and-deploy로 배포를 실행하고, /canary로 배포 직후 5~10분간 실시간 모니터링을 진행합니다. /retro는 한 주 전체를 돌아보며 개선점을 회고합니다.
이 구조 덕분에 생각 → 기획 → 구현 → 검증 → 배포 → 학습이 하나의 루프로 이어집니다. 팀 없이 혼자 개발하는 사람에게는 전체 프로덕트 사이클을 강제하는 프레임이 되어줍니다.
설치 방법과 호환 도구는?
설치 방법이란 터미널 환경에서 G스택을 내려받고, 의존성을 설정해 약 30초 만에 실행 가능한 상태로 만드는 절차입니다. GitHub 클론과 AI 코딩 도구 연동 두 단계로 요약됩니다.
30초 설치 개요
- 터미널에서 G스택 GitHub 저장소를 클론(Clone)
- 제공된 설정 스크립트 실행
Claude Code및 사용 중인 AI 도구 키/연동 설정
터미널은 macOS·리눅스에는 기본 탑재되어 있고, 윈도우에서는 PowerShell이나 WSL을 쓰면 됩니다.
다양한 AI 코딩 도구와의 호환성
G스택은 클로드 코드 전용이 아닙니다. 다음 도구들과도 호환됩니다.
CodexGeminiCursor- 그 외 AI 코딩 도구들
설치 시 옵션 한 줄만 바꾸면 현재 사용하는 도구에 맞게 자동으로 설정이 조정됩니다. 팀 단위로도 쓸 수 있는데, 프로젝트 폴더 안에 G스택을 포함해두면 팀 전체가 같은 기준과 워크플로우로 협업하게 됩니다.
처음 사용할 때 추천 순서
처음 접한다면 이 순서가 권장됩니다.
/office-hours→ 아이디어 검증 및 기획서 작성/plan-review→ 기술 설계 확정- 코드 작성 후
/review→ 코드 품질 점검 /design-review→ 디자인 개선/launch→ 배포
이 5단계만 지켜도 단순 코드 생성 도구보다 훨씬 일관된 품질을 확보할 수 있습니다.
G스택의 한계와 적합한 사용자는?
G스택의 한계란 현재 버전이 구조적으로 가지는 제약입니다. 대표적으로 자동화 부족과 테스트 코드 지원 미흡 두 가지가 지적됩니다.
현재 드러난 한계점
자동 트리거(Auto-trigger) 미지원
코드 커밋 시 자동 /review, 배포 완료 후 자동 /canary 같은 이벤트 기반 자동 실행이 없어서 매 단계 수동 명령어 입력이 필요합니다.
테스트 코드 자동화의 부족
유닛 테스트·통합 테스트를 강제하거나 자동화하는 기능이 약합니다. “테스트 파이프라인까지 전부 자동화된 CI/CD 시스템”을 기대한다면 G스택 단독으로는 아쉬움이 남을 수 있습니다.
가장 큰 수혜를 보는 사용자 유형
반대로 G스택이 특히 강력하게 작동하는 사용자 유형도 분명합니다.
개발자 출신 1인 창업자(Solo Founder)
코딩은 할 줄 알지만 기획·디자인·QA·보안·배포까지 혼자 맡아야 하는 상황. G스택은 각 단계마다 “전문가 한 명이 옆에 앉아 있는 것 같은 효과”를 줍니다.
개발자 출신 PO/PM 전환자
기술 용어는 이해하지만 제품 기획과 검수의 틀을 스스로 잡아야 하는 역할. 오피스 아워의 6가지 질문은 바로 가져다 쓸 수 있는 제품 기획 프레임워크가 됩니다.
게리 탄이 이 시스템을 무료로 공개한 이유도 이 맥락에서 이해됩니다. YC에서 수천 개 스타트업을 지켜본 그는, 좋은 아이디어가 실행 체계의 부재 때문에 사라지는 장면을 누구보다 많이 봐 왔습니다. 국내 개발자 커뮤니티에서도 1인 개발·창업자들 사이에서 긍정적인 실험 사례가 늘어나고 있는 걸 보면, 이 판단이 틀리지 않았던 것 같습니다.
G스택이 제시하는 새로운 AI 패러다임은?
G스택이 제시하는 AI 개발 패러다임이란 “AI에게 모든 것을 한 번에 떠넘기는 방식”에서 “AI에게 역할과 책임을 나눠 주는 방식“으로의 전환입니다. 핵심은 “빠른 실행”보다 “올바른 실행” 입니다.
기존 AI 코딩 도구는 주로 이 두 가지에 집중했습니다.
- 최대한 빨리 코드를 짜 주는 것
- 자연어 명령 → 코드 생성의 속도
G스택은 다른 질문을 던집니다.
- 이게 올바른 문제 정의인가?
- 이 설계는 장기적으로 유지 가능한가?
- 이 디자인은 사용자에게 신뢰를 주는가?
- 이 제품은 보안·품질 기준을 충족하는가?
“지식은 밖에서 집어넣는 게 아니라 이미 안에 있는 걸 끄집어내는 거다.”
— 소크라테스(Socrates)
오피스 아워에서 보여주는 “질문이 먼저, 코드는 나중” 원칙은 2,500년 전 소크라테스 문답법을 현대 소프트웨어 개발 도구에 이식한 예입니다. UCLA 연구처럼, 스스로 질문에 답하는 과정은 개발자가 제품·사용자·문제 정의에 대한 이해를 훨씬 깊게 만드는 장치가 됩니다.
AI 개발 도구 경쟁 지형의 변화
G스택 이후 AI 개발 도구의 경쟁 구도도 달라지고 있습니다. 영상에서는 GitHub Star 10만 개를 넘어선 ‘Superpowers’라는 유사 프레임워크도 언급됩니다. 이제는 어떤 도구가 어떤 상황에 맞는지, 단순 코딩 보조 대 완전한 개발 팀 대체재를 비교 분석해야 하는 시점입니다. G스택은 그 변화의 첫 실질적 사례로 기록될 가능성이 큽니다.
자주 묻는 질문 (FAQ)
Q: G스택은 비개발자도 쓸 수 있나요?
A: 구조 자체는 비개발자에게도 도움이 되지만, 실제로는 개발 경험이 있는 사용자에게 더 맞습니다. 코드 리뷰, 보안 점검, QA 결과를 이해하려면 최소한의 기술적 맥락이 필요합니다.
Q: G스택과 일반 AI 코드 어시스턴트의 가장 큰 차이는 무엇인가요?
A: 일반 코드 어시스턴트는 코드 한 조각을 빠르게 써주는 데 집중합니다. G스택은 아이디어 검증–설계–코드–QA–보안–배포–회고까지 전체 프로덕트 사이클을 관리한다는 점에서 다릅니다.
Q: 테스트 자동화가 약하다는데, QA는 믿을 수 있나요?
A: G스택은 브라우저 자동 테스트와 시나리오 실행 측면에서는 꽤 강력합니다. 유닛 테스트·통합 테스트 코드를 체계적으로 생성·관리하는 기능이 부족하다는 의미이지, QA 자체가 무의미하다는 뜻은 아닙니다.
Q: 팀 환경에서 써도 괜찮나요, 아니면 1인 개발자용인가요?
A: 1인 개발자와 솔로 창업자에게 가장 큰 효용을 주지만, 프로젝트 폴더 내에 G스택을 포함해 팀 공통 도구로 쓰면 팀 전체 기준을 맞추는 데도 도움이 됩니다. 기존 CI/CD와의 통합은 아직 수동 설정이 필요합니다.
Q: G스택을 처음 도입할 때 최소한으로 써볼 만한 플로우는?
A: /office-hours → /plan-review → 코딩 → /review → /design-review → /launch 순서가 권장됩니다. 이것만 지켜도 단순 코드 생성 도구보다 훨씬 일관된 품질을 확보할 수 있습니다.
결론
G스택은 AI를 “코드를 빨리 써주는 도구”가 아니라 28명의 전문가로 구성된 가상의 개발 팀으로 재구성합니다. 오피스 아워의 6가지 질문은 “무엇을 만들 것인가”보다 먼저 “왜, 누구를 위해 만들 것인가”를 묻습니다. 디자인 리뷰와 7단계 통합 워크플로우는 기획부터 배포·회고까지 전 과정을 하나의 파이프라인으로 묶어줍니다.
정리하면 이렇습니다.
- 코딩은 전체 개발 과정의 일부일 뿐이라는 사실을 구조로 강제한다.
- 질문 기반 기획(오피스 아워)이 제품의 방향성을 선명하게 만든다.
- 디자인 리뷰로 ‘AI 티 나는’ 슬롭 디자인을 체계적으로 제거한다.
- 7단계 워크플로우를 통해 혼자서도 팀 수준의 개발 프로세스를 밟을 수 있다.
- 자동 트리거·테스트 자동화의 한계에도 불구하고, 1인 개발자·솔로 창업자·PO/PM 전환자에게는 매우 실질적인 도구다.
AI 개발 도구가 넘쳐나는 시대일수록, “얼마나 빨리 만들 수 있는가”보다 “얼마나 올바르게 만들 수 있는가”가 중요해지고 있습니다. 개인적으로는 이 방향 전환 자체가 G스택의 가장 큰 기여라고 봅니다. G스택은 그 질문에 대한 하나의 구체적인 답이고, 앞으로 등장할 AI 기반 개발 팀 시스템들의 기준점이 될 가능성이 큽니다.
Found this article helpful?
Get more tech insights delivered to you.
답글 남기기