[심층분석] AI 한 명에게 회사 조직 전체를 시킨다고? 게리 탄의 'gstack' 뜯어보기

와이콤비네이터 대표가 자기 작업 세팅을 통째로 공개했어요

게리 탄(Garry Tan)이라는 이름, 한 번쯤 들어보셨을 수도 있어요. 실리콘밸리에서 가장 유명한 스타트업 사관학교라고 불리는 Y Combinator(와이콤비네이터, 줄여서 YC)의 현 대표거든요. Airbnb, Dropbox, Stripe, Coinbase 같은 회사들이 다 여기를 거쳐 갔어요. 그런 사람이 자기가 실제로 매일 쓰는 Claude Code 세팅을 통째로 공개했는데, 그게 바로 gstack이에요.

"개발 세팅 하나 공개한 게 뭐가 대단해?" 싶을 수 있는데요. 핵심은 이게 단순한 단축키 모음이 아니라는 거예요. AI에게 회사 조직 하나를 통째로 흉내 내게 만드는 구조거든요. CEO, 디자이너, 엔지니어링 매니저, 릴리스 매니저(배포 담당), 문서 엔지니어, QA(품질 검수)까지. 회사에 있을 법한 역할 23개를 AI 도구로 만들어 놨어요.

먼저 배경부터 짚고 갈게요. AI로 코딩하는 방식은 지난 몇 년간 계속 진화해 왔어요. 처음엔 깃허브 코파일럿처럼 자동완성(타이핑하면 다음 줄을 추천해 주는 것)이 전부였죠. 그다음엔 챗봇한테 "이 함수 고쳐줘" 하고 물어보는 단계로 넘어갔고요. 그리고 지금은 에이전트(Agent) 시대예요. 에이전트가 뭐냐면, 쉽게 말해서 사람이 일일이 시키지 않아도 스스로 여러 단계를 알아서 처리하는 AI예요. 파일을 읽고, 코드를 고치고, 테스트를 돌리고, 결과를 보고 다시 수정하는 걸 혼자 반복하는 거죠. Claude Code가 바로 그런 터미널(검은 화면에 명령어 치는 그 창) 기반 에이전트고요.

gstack은 이 Claude Code를 "날것 그대로" 쓰는 게 아니라, 게리 탄 본인의 일하는 방식과 취향(그래서 'opinionated', 즉 '고집 있는'이라는 표현을 써요)을 잔뜩 발라 놓은 세팅이에요.

안을 들여다보면: 23개의 '직원'이 들어있어요

저장소(repository, 코드를 모아두는 폴더라고 생각하면 돼요)를 열어보면 폴더 이름만 봐도 무슨 일을 하는 도구인지 감이 와요. 몇 개만 골라볼게요.

• plan-ceo-review, plan-eng-review, plan-design-review — 계획을 CEO 관점, 엔지니어 관점, 디자인 관점에서 각각 검토
• design-review, design-consultation, design-shotgun — 디자인 리뷰와 시안 여러 개 한꺼번에 뽑기
• qa, qa-only, ios-qa — 품질 검수
• ship, land-and-deploy, setup-deploy — 배포(만든 걸 실제 서비스에 올리는 것)
• retro, investigate, health — 회고, 문제 조사, 상태 점검
• document-generate, document-release — 문서 자동 생성

여기에 더해 서브에이전트(subagent)라는 개념이 핵심이에요. 이게 뭐냐면, 메인 AI가 자기 혼자 다 하는 게 아니라 별도의 깨끗한 작업 공간을 가진 보조 AI를 불러다 일을 맡기는 거예요. 왜 이게 중요하냐면, AI는 한 대화에 너무 많은 내용이 쌓이면 앞에서 했던 말을 헷갈리거나 잊어버리거든요(이걸 '컨텍스트가 오염된다'고 표현해요). 그래서 QA 검수는 QA 전용 서브에이전트한테, 디자인 검토는 디자인 전용 서브에이전트한테 따로 시키면, 각자 자기 일에만 집중하니까 결과물이 훨씬 깔끔해져요.

이렇게 여러 AI에게 역할을 나눠주고 순서대로 일을 시키는 걸 오케스트레이션(orchestration)이라고 불러요. 쉽게 말하면 지휘자가 오케스트라 단원들에게 각자 파트를 연주시키는 것과 똑같아요. gstack은 "기획 → CEO 검토 → 엔지니어 검토 → 디자인 검토 → 구현 → QA → 배포"라는 회사의 일하는 흐름 자체를 AI 명령어 파이프라인으로 옮겨놓은 셈이에요.

저장소 안에 CLAUDE.md, ARCHITECTURE.md, DESIGN.md, ETHOS.md 같은 파일이 보이죠? 이 중 CLAUDE.md가 특히 중요해요. 이건 AI의 '사내 규정집'이에요. "우리 프로젝트는 이런 원칙으로 코딩한다, 이런 건 절대 하지 마라" 같은 걸 적어두면 AI가 매번 그걸 읽고 따라요. 사람 신입한테 온보딩 문서 쥐여주는 거랑 똑같죠.

다른 방식들과 뭐가 다를까

요즘 AI 코딩 도구가 정말 많잖아요. 비교해서 차이를 잡아볼게요.

커서(Cursor)나 코파일럿은 똑똑한 '도구'예요. 망치나 드릴 같은 거죠. 성능은 좋지만, 그걸로 집을 어떻게 지을지는 전적으로 사람이 정해야 해요. 반면 gstack은 도구가 아니라 작업 매뉴얼이 딸린 작업팀에 가까워요. 망치를 주는 게 아니라 "이런 순서로, 이런 검수를 거쳐서 지어라"라는 공정표까지 같이 주는 거죠.

또 요즘 뜨는 게 스펙 기반 개발(spec-driven development)이에요. 이게 뭐냐면, 코드부터 짜는 게 아니라 먼저 무엇을 만들지 명세서(spec)를 자세히 쓰고, AI가 그 명세대로 만들게 하는 방식이에요. gstack에도 spec 폴더와 autoplan(자동 기획) 같은 게 있는 걸 보면 이 흐름을 충실히 따르고 있어요. "AI한테 바로 코드 시키지 말고, 계획부터 여러 관점으로 검토해라"가 이 세팅의 일관된 철학이거든요.

gstack 방식의 장점은 분명해요. 혼자 일하는 1인 개발자나 작은 스타트업도, 마치 CEO·디자이너·QA가 다 있는 큰 팀처럼 여러 관점의 검토를 받을 수 있다는 거예요. 게리 탄이 보여주고 싶은 게 바로 이거죠. "AI를 잘 엮으면 한 사람이 한 팀의 결과물을 낸다."

반면 단점이자 주의점도 있어요. 첫째, 이건 철저히 '게리 탄의 취향'이에요. 그의 일하는 방식, 그가 쓰는 기술 스택(이 안엔 Supabase 연동 같은 것도 들어있어요)에 맞춰져 있어서, 내 상황과 안 맞으면 오히려 거추장스러워요. 둘째, 도구가 23개나 되니까 배보다 배꼽이 커질 수 있어요. 간단한 버그 하나 고치는데 CEO 리뷰, 디자인 리뷰 다 돌리면 시간과 비용(AI 호출은 다 돈이에요)이 만만치 않거든요. 셋째, 검토 단계가 많다고 결과가 항상 좋은 건 아니에요. AI 여러 명이 서로 어설프게 동의해 버리는 'AI 메아리방'이 생길 수도 있어요.

한국 개발자라면 이렇게 활용해 보세요

그럼 우리는 이걸 어떻게 써먹을 수 있을까요. gstack을 통째로 가져다 쓰는 건 추천하지 않아요. 대신 아이디어를 훔쳐오는 게 핵심이에요.

시나리오 1 — 혼자 사이드 프로젝트 하는 분. 지금 Claude Code나 비슷한 에이전트를 쓰고 있다면, gstack의 plan-eng-review 발상만 가져와 보세요. 코드를 짜기 전에 "이 계획의 허점을 까다로운 시니어 엔지니어 입장에서 지적해줘"라는 슬래시 커맨드 하나만 만들어 두는 거예요. 이거 하나로도 혼자 놓치던 설계 실수를 꽤 잡을 수 있어요. 만드는 데 5분이면 돼요.

시나리오 2 — 작은 팀에서 코드 리뷰가 항상 밀리는 곳. review나 devex-review(개발자 경험 검토) 발상을 빌려서, 배포 전에 AI가 1차 리뷰를 하게 해보세요. 사람 리뷰어의 부담을 덜어주는 '예비 검수원'으로 쓰는 거죠. 사람을 대체하는 게 아니라 사람이 볼 시간을 아껴주는 용도로요.

시나리오 3 — 문서 작성이 늘 뒷전인 곳. document-generate, document-release 아이디어대로, 기능을 만들고 나면 자동으로 변경 내역(CHANGELOG)과 릴리스 노트를 뽑게 해보세요. 다들 싫어하는 일이라 자동화 효과가 제일 큰 영역이거든요.

학습 로드맵을 제안하자면 이래요. (1) 먼저 CLAUDE.md 한 장 잘 쓰는 것부터 시작하세요. 이게 8할이에요. 프로젝트 규칙을 또박또박 적어두는 것만으로 AI 결과물이 확 좋아져요. (2) 그다음 자주 반복하는 지시를 슬래시 커맨드 2~3개로 만들어 보세요. (3) 그게 익숙해지면 검토 단계를 서브에이전트로 분리하는 데 도전하고요. 처음부터 23개를 다 만들 필요 전혀 없어요. 내 일에 맞는 3개가 게리 탄의 23개보다 나아요.

마무리: '코더'에서 '오케스트레이터'로

gstack이 진짜 던지는 메시지는 "이 도구 좋으니까 깔아라"가 아니에요. "개발자의 역할이 바뀌고 있다"는 신호예요. 앞으로 잘하는 개발자는 코드를 한 줄 한 줄 잘 치는 사람이 아니라, 여러 AI에게 역할을 잘 나눠주고 그 결과를 잘 검수하는 사람, 즉 지휘자(오케스트레이터)에 가까워질 거예요. 게리 탄이 자기 세팅을 굳이 공개한 것도, 이 변화의 방향을 먼저 보여주고 싶었던 거라고 봐요.

물론 반론도 있어요. "역할 흉내만 내는 AI 23개보다, 진짜 잘 짜인 도구 하나가 낫다"는 의견도 충분히 일리가 있고요. 결국 정답은 내 프로젝트 규모와 손에 익는 정도에 달려 있겠죠.

여러분은 어떠세요? AI에게 '직원처럼 역할을 부여하는' 이 방식이 실제 생산성을 높여준다고 보시나요, 아니면 화려해 보이는 오버엔지니어링(필요 이상으로 복잡하게 만드는 것)이라고 보시나요? 혹시 이미 나만의 슬래시 커맨드나 AI 검토 루틴을 만들어 쓰고 계신 분 있다면, 어떤 명령을 자동화했을 때 가장 효과가 좋았는지 댓글로 공유해 주세요. 🙌