YC 대표 Garry Tan이 60일 동안 60만 줄 넘는 코드를 만들었다는 문장은 자극적이다. 하지만 메이커 에반 영상의 진짜 핵심은 “혼자서 많이 만들었다”가 아니다. AI에게 코딩만 시키지 말고, 기획부터 디자인 리뷰·QA·보안·배포까지 역할을 나눠 팀처럼 굴려라는 쪽에 있다. 그 운영 방식을 Garry Tan은 gstack이라고 부른다.
gstack README는 이 시스템을 Claude Code를 가상 엔지니어링 팀으로 바꾸는 방식이라고 설명한다. README에는 CEO, 엔지니어링 매니저, 디자이너, 리뷰어, QA, 보안 담당, 릴리스 엔지니어 같은 역할이 등장하고, 영상에서는 총 28개 전문가 역할로 소개된다. 숫자보다 중요한 건 메시지다. AI 하나를 만능 비서처럼 쓰지 말고, 역할을 쪼개 전문성을 흉내 내게 하라는 것이다.
왜 기존 AI 코딩이 늘 찝찝했을까
영상 초반 비유가 좋다. 식당은 요리사만 있다고 돌아가지 않는다. 메뉴, 위생, 인테리어, 회계, 서빙이 다 있어야 한다. 소프트웨어도 비슷하다. 그런데 많은 사람은 AI에게 “코드만” 시킨다. 그래서 결과물이 돌아가긴 하는데 품질을 확신하기 어렵고, 디자인은 비슷비슷하고, 보안 구멍은 숨어 있고, 출시 후 문제가 터진다.
즉 기존 AI 코딩의 문제는 모델 지능 부족만이 아니라, 업무 공정이 잘려 있다는 것이다. gstack은 바로 그 잘린 공정을 다시 이어 붙이는 시도라고 보면 이해가 쉽다.
G-Stack에서 가장 중요한 기능 1: Office Hours
영상에서 가장 강하게 밀어주는 기능은 /office-hours다. 이 단계에서는 코드를 한 줄도 쓰지 않는다. 대신 AI가 질문을 던진다. 그것도 좋은 아이디어라고 맞장구치는 질문이 아니라, 정말 수요가 있는지부터 의심하는 질문이다.
영상 자막 기준으로 핵심 질문은 이런 흐름이다.
- 진짜 수요가 있는가
- 지금 사람들은 이 문제를 어떻게 해결하고 있는가
- 구체적으로 누구에게 필요한가
- 이번 주 안에 돈을 낼 정도로 작은 시작은 무엇인가
- 사용자가 실제로 쓰는 장면을 직접 본 적이 있는가
- 3년 뒤에도 더 필요한가
이 질문 구조는 YC의 Office Hours 문화와도 닿아 있다. YC 블로그도 Office Hours를 “답을 주기보다 질문으로 방향을 좁히는 시간”으로 설명한다. 결국 gstack의 첫 단계는 코딩 보조가 아니라 아이디어 압축기에 가깝다.
미니 케이스:
- “일정 앱 만들고 싶다”는 말만으로는 모호하다.
- 하지만 질문을 따라가다 보면 “사실 필요한 건 알림 앱이 아니라 개인 비서형 AI”처럼 제품 정의가 달라질 수 있다.
G-Stack에서 중요한 기능 2: AI slop를 잡는 디자인 리뷰
영상에서 인상적인 또 하나는 디자인 리뷰다. AI가 만든 웹 화면은 종종 “딱 AI가 만든 티”가 난다. 보라색 그라데이션, 둥근 아이콘 3개, 영어 슬로건, 비슷비슷한 카드 레이아웃 같은 패턴 말이다. 영상은 이걸 AI slop이라고 부른다.
gstack 흐름에서는 디자인 리뷰가 실제 브라우저를 열고 화면을 돌아다니며 체크리스트 기반으로 품질을 본다. 영상에서는 글꼴, 색상, 간격, 버튼 반응, 반응형 대응뿐 아니라 AI slop 전용 항목까지 별도로 점검한다고 설명한다. 중요한 건 미감 그 자체보다, “AI가 대충 그럴싸하게 만든 흔적”을 잡아내는 품질 게이트가 있다는 점이다.
이건 실제로 꽤 실용적이다. AI가 빠르게 초안을 뽑는 시대일수록, 차이는 생성 능력이 아니라 촌스러움을 걷어내는 검수 루틴에서 생기기 때문이다.
G-Stack의 진짜 가치는 끝까지 이어지는 워크플로우
영상 후반에서 드러나는 핵심은 gstack이 단일 프롬프트 모음이 아니라는 점이다. 흐름이 이어진다.
/office-hours로 기획을 검증하고- 대표/기술 관점 리뷰로 범위를 조정하고
- 구현 후
/review로 코드 검수를 하고 /qa로 실제 브라우저에서 테스트하고/cso계열 보안 점검을 하고/ship,/land-and-deploy,/canary,/retro로 출시와 회고까지 묶는다
즉 이 시스템은 “좋은 코드 한 번 뽑기”보다 생각 → 설계 → 구현 → 검수 → 출시 → 회고를 하나의 습관으로 만드는 데 가깝다. 솔로 개발자에게 특히 매력적인 이유도 여기 있다. 사람 팀은 없지만, 팀의 사고 순서를 흉내 낼 수 있기 때문이다.
누가 읽으면 가장 도움이 될까
이 방식은 특히 아래 사람에게 잘 맞는다.
- 혼자 제품을 만드는 개발자
- 개발 배경이 있는 PM/PO
- AI에게 일을 시키면 항상 방향이 틀어져 재작업이 많은 사람
- “코드 생성”보다 “제품 완성도”를 높이고 싶은 사람
반대로 아주 작은 수정만 자주 하는 사람에게는 다소 과할 수 있다. 역할이 많아질수록 좋아지는 게 아니라, 적절한 단계 분리가 필요할 때 강한 시스템이기 때문이다.
한 줄 정리
이 영상의 핵심은 “YC 대표가 코드를 많이 쳤다”가 아니다. AI 하나를 개발 팀처럼 조직화하는 방법, 바로 그 운영 체계를 보여준다는 데 가치가 있다. 그래서 gstack을 볼 때는 코드 양보다, 질문과 검수 루프가 얼마나 강한지를 보는 편이 맞다.
관련 글
참고 링크
영상 메타
- 채널: 메이커 에반 | Maker Evan
- 제목: 혼자서 60만 줄… YC 대표의 AI 비밀 도구
- 게시 시각(원문): 2026-03-27
- 영상: https://www.youtube.com/watch?v=7ozueqcLWt0
- 썸네일: https://i4.ytimg.com/vi/7ozueqcLWt0/hqdefault.jpg
이 글은 AI를 활용해 초안을 정리한 뒤, 원영상 자막과 gstack 공개 README, YC 공개 자료를 교차 확인해 다듬었습니다.