YC CEO가 팀 없이 60만 줄 짠 방법 — gstack과 1인 AI 팀의 현실
YC CEO가 팀 없이 60만 줄 짠 방법 — gstack과 1인 AI 팀의 현실
2026년 초에 Garry Tan이 뭔가를 GitHub에 올렸다. Y Combinator CEO가 자기 개인 Claude Code 설정을 오픈소스로 공개한 거다. 이름은 gstack. 같이 올라온 숫자가 있었다.
60일, 60만 줄.
본인이 이 셋업으로 두 달 동안 혼자 작성한 프로덕션 코드 양이다. 하루 최대 1만~2만 줄. 팀 없이.
처음 봤을 때 반응은 두 갈래였다. "저게 말이 되나?" 아니면 "저게 진짜면 어떡하지?"
둘 다 맞는 반응이다. 그리고 그 긴장 어딘가에 gstack이 실제로 뭔지가 있다.
이 시리즈가 여기까지 온 맥락
이 글은 Paperclip 시리즈 3부다.
1부에서는 AI가 목표를 너무 충실하게 수행할 때 생기는 문제를 다뤘다. Claude Code한테 "번들 사이즈 줄여줘"를 던졌더니 폴리필을 통째로 제거해서 Safari에서 폭발한 사건. 거기서 Nick Bostrom의 Paperclip Maximizer 사고실험으로 이어졌다. AI의 진짜 위험은 지능이 아니라 목표 함수라는 이야기.
2부에서는 paperclip.ing을 뜯었다. 그 사고실험의 이름을 정면으로 달고 나온 오픈소스 멀티 에이전트 플랫폼. "에이전트가 새 에이전트를 고용하려면 당신의 승인이 필요합니다"라고 선언한 거버넌스 레이어 설계.
3부인 이 글의 주제는 gstack이다. 같은 문제를 다른 각도에서 건드린다. paperclip.ing이 "AI 거버넌스를 어떻게 아키텍처로 풀 것인가"에 대한 답이라면, gstack은 "그 거버넌스 아래서 실제로 혼자 어떻게 일하는가"에 대한 답이다.
gstack이 뭔지부터
한 줄 설명: Claude Code 위에 얹는 워크플로우 레이어다.
더 구체적으로는, 23개의 슬래시 커맨드 묶음이다. 각 커맨드가 특정 팀 역할을 시뮬레이션한다. CEO, 디자이너, 엔지니어 매니저, QA 리드, 릴리즈 매니저, 보안 감사관. 이 역할들이 Claude Code 안에서 활성화된다.
git clone https://github.com/garrytan/gstack
./setup
설치는 이게 전부다. MIT 라이선스. 프리미엄 플랜 없음.
중요한 점은, gstack이 AI를 빠르게 만들어주는 도구가 아니라는 거다. Garry Tan 본인이 README에 직접 썼다.
"If you're looking for something that writes code faster, gstack is the wrong tool. Its value is in the process around the code — the planning, reviewing, testing, and shipping."
코드 자체가 아니라 코드 주변의 프로세스에 가치가 있다. 기획, 리뷰, 테스트, 배포.
실제 워크플로우를 따라가보면
gstack의 핵심 철학은 "Think → Plan → Build → Review → Test → Ship → Reflect" 7단계 파이프라인이다. 각 단계가 다음 단계의 입력이 된다.
구체적으로 어떻게 굴러가는지 보자.
1단계: /office-hours — 제품 가정 재검토
뭔가를 만들기 전에 먼저 이 커맨드를 친다. CEO 페르소나가 활성화된다. Claude가 당신이 만들려는 걸 듣고, "사실 당신이 만들려는 게 뭔지 다시 생각해봐야 한다"고 압박하는 역할이다.
예를 들어 "일일 브리핑 앱을 만들고 싶어"라고 하면, "사실 당신은 개인 AI 비서를 만들고 있는 거 아닌가?"로 재정의한다. 기능을 구현하기 전에 문제가 올바른지 먼저 확인하는 단계.
2단계: /plan-ceo-review + /plan-eng-review
기획 단계. CEO 리뷰는 스코프를 검증한다. "이걸 지금 다 만들어야 하나, 뭘 빼도 되나?" 엔지니어링 리뷰는 아키텍처를 잠근다. 어떤 구조로 만들지, 어떤 기술 선택을 해야 하는지.
이 두 단계를 거치고 나서야 코드를 만지기 시작한다. 계획 없이 코딩 시작하면 AI는 가장 빠른 경로로 달려가는데, 그게 반드시 올바른 경로는 아니다.
3단계: 코딩 + /review
코드를 짜고 나서 /review를 친다. 코드 리뷰어 페르소나가 활성화된다. 자기가 짠 코드를 자기가 리뷰하는 구조인데, 맥락이 완전히 분리돼 있어서 실제로 효과가 있다. 뭔가 놓쳤거나 더 좋은 방법이 있을 때 잡힌다.
4단계: /qa [URL]
URL을 넘기면 실제 Chromium 브라우저가 올라와서 동작을 테스트한다. "실행해봤는데 됩니다"가 아니라 실제로 화면을 보면서 돌아가는지 확인하는 구조.
5단계: /ship
PR을 자동으로 만든다. 커밋 메시지, 설명, 리뷰어 지정까지. 여기서 /land-and-deploy로 넘어가면 프로덕션 배포까지 이어진다.
6단계: /retro
주간 회고. 어떤 결정을 했고, 왜 했고, 뭐가 잘 됐고 뭐가 안 됐는지. 다음 주 기획의 입력이 된다.
전체를 보면 팀에서 당연히 존재하는 프로세스다. 기획 → 아키텍처 리뷰 → 코딩 → 코드 리뷰 → QA → 배포 → 회고. 차이는 이 역할들을 사람 대신 AI가 수행한다는 것이고, 그 AI를 오케스트레이션하는 게 혼자 앉아 있는 개발자 한 명이라는 거다.
60만 줄 주장의 실체
숫자를 다시 보자. 60일에 60만 줄. 하루 1만~2만 줄.
이걸 어떻게 읽어야 하는가.
첫 번째로, 이건 Garry Tan 본인의 주장이다. 공개 검증을 거친 수치가 아니다. "AI가 생성한 코드 포함"이라는 전제도 있다. 코드 줄 수는 품질 측정이 아니다. 1만 줄의 boilerplate와 100줄의 핵심 로직은 다르다.
두 번째로, README에는 "2013년 대비 약 810배 생산성 향상"이라는 주장도 있다. 측정 방법이 "정규화된 코드 변경량"인데, 이건 자체 정의한 지표다.
세 번째로, 그래도 방향 자체는 맞다. 1인이 감당할 수 있는 개발 범위가 AI로 확연히 넓어졌다는 건 부정하기 어렵다. 숫자가 얼마든 간에 그 방향으로의 이동은 실제다.
1만 줄이든 2만 줄이든 810배든, 중요한 건 규모가 아니다. 기획-리뷰-테스트-배포라는 팀 프로세스를 혼자 돌릴 수 있게 됐다는 사실이다.
HN에서 나온 진짜 질문들
gstack이 공개되자마자 Hacker News에서 토론이 붙었다. 거기서 나온 비판들이 더 흥미롭다.
텔레메트리 문제. 사용 패턴 데이터를 수집한다는 점이 지적됐다. YC가 이 데이터를 스타트업 아이디어 발굴에 쓰는 건 아니냐는 의심이 나왔다. 데이터 수집은 거부할 수 있지만, 기본값이 수집 동의라는 점은 찜찜하다.
자율 실행의 위험. 한 사용자가 실제 사례를 올렸다. 에이전트가 70분 동안 프로덕션 설정 파일에 스테이징 URL을 반복 삽입하는 버그를 경험했다고. gstack의 거버넌스 레이어가 있어도 이런 일은 일어난다는 증거다.
이 70분짜리 버그는 1부에서 다룬 Paperclip Maximizer 문제의 소규모 재연이다. AI가 목표를 충실하게 수행했다. "URL을 업데이트해라"라는 지시를 받았고, 70분 동안 충실하게 수행했다. 멈출 이유가 없었다.
역할 분해의 확장성 문제. CEO 리뷰, 엔지니어링 리뷰, QA 이 구조가 단순한 프로젝트에는 잘 맞는데, 프로젝트마다 다른 검토 기준이 필요할 때 어떻게 커스터마이징할 것인지가 불명확하다는 지적.
이 비판들이 gstack을 무너뜨리지는 않는다. 다만 "이 도구가 무엇을 해결하고 무엇을 해결하지 못하는가"를 명확히 한다.
paperclip.ing vs gstack: 같은 문제, 다른 접근
이 두 프로젝트를 나란히 놓으면 재미있다.
paperclip.ing은 다중 에이전트 플랫폼이다. "AI 회사"를 만든다는 개념이다. 에이전트들이 서로 협업하고, 인간은 이사회로서 승인권을 갖는다. 거버넌스 레이어가 아키텍처 수준에서 설계돼 있다.
gstack은 Claude Code 위의 워크플로우다. 에이전트가 여럿 있지 않다. Claude 하나가 상황에 따라 다른 역할 페르소나를 채택하는 구조다. 거버넌스는 "플랜을 먼저 리뷰한다"는 프로세스 수준에서 작동한다.
같은 문제를 다루는 두 가지 답이다. 1부에서 제기한 질문 — AI에게 목표를 줄 때 어떻게 통제할 것인가 — 에 대해, paperclip.ing은 아키텍처로 답하고 gstack은 워크플로우로 답한다.
어떤 게 옳고 그름의 문제가 아니다. 스케일과 복잡도에 따라 다른 선택이 필요하다. 1인 개발자가 사이드 프로젝트를 돌린다면 gstack이 맞다. 실제 에이전트 팀을 운영하는 프로덕트를 만든다면 paperclip.ing 같은 거버넌스 레이어가 필요하다.
근데 이거, Anthropic이 이미 만들어놓은 거 아닌가
한 가지 더 솔직히 짚고 가야 할 게 있다.
gstack의 23개 슬래시 커맨드를 열어보면 구조가 단순하다. Claude Code의 커스텀 커맨드 기능 + CLAUDE.md에 역할 정의를 쓴 것. 새로운 기술이 없다. Anthropic이 Claude Code에 이미 제공하는 기능들이다.
paperclip.ing도 다르지 않다. 거버넌스 레이어가 인상적이지만, 그 아래에는 Claude의 multi-agent orchestration이 깔려 있다. "에이전트가 에이전트를 고용할 수 없다"는 규칙은 Anthropic의 에이전트 SDK 위에서 돌아간다.
이 시리즈 전체를 다시 보면 — Paperclip 문제를 해결하려는 접근들(gstack, paperclip.ing)이 모두 같은 인프라 위에 있다. 그 인프라를 만든 게 Anthropic이다. 그리고 그 인프라 안에 이미 같은 패턴들이 내장돼 있다.
Anthropic의 에이전트 하네스 구조를 직접 보면: .claude/agents/에 역할별 에이전트 정의, .claude/skills/에 커스텀 슬래시 커맨드, CLAUDE.md에 프로젝트 지침, hooks로 이벤트 기반 자동화. gstack이 하는 것과 구조적으로 동일하다. 어떻게 보면 gstack은 Anthropic 자체 도구의 베스트 프랙티스를 Garry Tan이 오픈소스로 정리한 거다.
그러면 gstack의 가치가 없는 건가? 아니다. 가치는 기술이 아니라 큐레이션에 있다. 역할 정의 하나를 잘 쓰는 데 얼마나 걸리는지 해본 사람은 안다. gstack은 Garry Tan의 수백 시간 실전 경험이 압축된 설정 파일이다. 재발명 없이 검증된 출발점을 준다.
다만 이 사실은 시사하는 게 있다. AI 개발 도구 생태계에서 진짜 경쟁 우위는 도구가 아니라 어떻게 쓰느냐에 있다는 것. gstack이 오픈소스인 이유도 여기 있다. Garry Tan이 공개해도 되는 건 도구가 자기 것이 아니기 때문이다.
실제로 gstack이 맞는 사람은 누구인가
README가 솔직하게 쓰여 있어서 인용할 만하다.
"GStack is excellent for solo developers and small founding teams who need a structured AI coding workflow out of the box."
솔로 개발자, 소규모 파운딩 팀, 구조화된 AI 워크플로우가 필요한 사람들.
반대로 보면 더 명확해진다. 이미 잘 작동하는 팀이 있고, 기존 CI/CD와 코드 리뷰 프로세스가 있다면 gstack은 오버킬이다. 기존 프로세스 위에 AI 레이어를 올리는 게 더 낫다.
gstack이 빛나는 상황은 아무것도 없을 때다. 팀이 없고, 프로세스가 없고, 혼자 제품을 만들어야 할 때. 그때 23개 슬래시 커맨드가 기획-리뷰-테스트-배포라는 팀 프로세스를 대체한다.
사실 우리가 이미 하고 있는 일
gstack을 처음 봤을 때 낯설게 느껴지지 않는 이유가 있다.
Claude Code를 쓰는 사람이라면 이미 비슷한 걸 어딘가에서 하고 있을 거다. "이 코드 리뷰해줘"라고 던지거나, "배포 전에 테스트 시나리오 뭐가 있는지 알려줘"라고 하거나. gstack은 그 임시방편적인 질문들을 구조화하고 문서화한 거다.
차이는 일관성이다. 매번 다르게 묻는 것과 정해진 커맨드를 치는 것의 차이. 전자는 결과가 제각각이고, 후자는 재현 가능하다.
이 재현성이 팀 프로세스의 핵심이다. 팀에서 코드 리뷰가 가치 있는 건 리뷰어가 특출 나서가 아니라 매 PR마다 같은 기준으로 일어나기 때문이다. gstack의 /review가 하는 것도 그거다. 매번 같은 수준의 리뷰를 일관되게 제공한다.
마지막으로
60만 줄이 진짜든 아니든, 810배가 맞든 틀리든, 가리키는 방향은 명확하다.
1인 개발자가 감당할 수 있는 범위가 넓어지고 있다. 기획, 개발, 리뷰, 테스트, 배포를 혼자 다 돌리는 게 점점 현실적인 옵션이 되고 있다.
그게 항상 좋은 건 아니다. 70분 무한 루프 버그처럼, 감시하는 눈이 없을 때 AI는 여전히 엉뚱한 방향으로 달려갈 수 있다. 1부에서 다룬 reward hacking 문제는 gstack 안에서도 사라지지 않는다. 다만 구조화된 게이트(플랜 리뷰, 코드 리뷰, QA)로 그 가능성을 줄인다.
Paperclip Maximizer는 목표 함수 하나만 주면 그걸 향해 무한히 달려간다는 이야기다. gstack의 답은 "그러니까 단계마다 멈추고 검토하는 구조를 만들어라"다. 완벽한 해결이 아니라, 현실적인 절충이다.
YC CEO가 혼자 팀처럼 일하는 방법. 그게 gstack이다.
Paperclip 시리즈:
1부 — AI는 똑똑해서 위험한 게 아니다 — Paperclip 문제와 LLM agent의 reward hacking
2부 — AI 회사를 npx 한 줄로 세운다 — paperclip.ing 아키텍처 뜯어보기
3부 — 이 글
댓글
댓글 쓰기