원래 productize.life에 게시되었습니다.

빠른 답변: gstack은 Y Combinator의 회장인 Garry Tan이 매일 사용하는 오픈 소스 (MIT) 기술 세트(skill set)입니다. 이는 Claude Code를 CEO, 엔지니어, 디자이너, QA, 릴리스 엔지니어를 포함한 23명의 전문가 팀으로 변모시키며, 모든 변경 사항이 배포되기 전에 다각도의 검토(multi-lens review)를 거치도록 강제합니다. 핵심은 속도가 아니라, 소프트웨어에 기록된 '취향 (taste)'입니다.

지난주 저는 코딩을 위한 여러 기술(skills)을 모아놓은 저장소(repo)를 살펴보고 있었습니다. 대부분은 AI가 체계적이고 더 빠르게 코드를 작성하도록 돕는다는 하나의 공통된 주제를 공유하고 있었습니다.

하지만 그중 gstack이라는 이름의 저장소는 두 가지 이유로 저를 더 오래 머물게 했습니다. 첫째, 소유자인 Y Combinator의 회장이자 CEO인 Garry Tan이 자신이 실제로 매일 사용하는 스택을 무료로 공개했다는 점입니다. 둘째, 이 스택은 "더 빠른 코드 작성"을 파는 것이 아니라, **"배포 전 검토 (review before you ship)"**를 판매한다는 점입니다.

실제로 열어보니, 그것은 단순한 도구 상자가 아니라 제가 한동안 관심을 가져온 아이디어를 가장 명확하게 보여주는 사례 중 하나였습니다. AI가 코드를 매우 빠르게 작성할 수 있는 날이 오면, 작업의 병목 현상(bottleneck)은 더 이상 속도가 아닙니다.

저는 이를 세 부분으로 나누어 설명하겠습니다. gstack이 무엇인지로 시작하여, gstack이 믿는 가치를 살펴본 뒤, 단순히 코드를 쓰는 사람이 아닌 제품을 만드는 사람들을 위한 교훈으로 마무리하겠습니다.

여기에 모아둔 용어 정리

• 에이전트 기반 코딩 (agentic coding): AI 에이전트가 단순히 한 줄씩 자동 완성하는 것이 아니라, 계획부터 작성, 검토, 배포에 이르기까지 스스로의 단계에 따라 코딩 작업을 수행하게 하는 것.
• 기술 (skill): Claude Code와 같은 AI 에이전트가 호출할 수 있는 패키지화된 지침 세트로, 한 가지 일을 수행하는 방식을 묶어놓은 단축키와 같음.
• 검토 렌즈 (review lens): 하나의 작업물을 CEO, 엔지니어, 디자이너 등 여러 역할의 관점에서 검토하는 것.
• 취향 (taste): 무엇이 좋고 나쁜지, 무엇을 만들고 무엇을 배포하지 말아야 하는지에 대한 감각과 판단력. 여전히 인간의 영역으로 남아있는 부분.

파트 1: gstack이란 무엇인가

Garry Tan은 README에서 gstack을 자신이 일하는 방식이라고 담백하게 설명합니다.

"gstack은 Claude Code를 가상 엔지니어링 팀으로 변모시킵니다. 제품을 재고하는 CEO, 아키텍처 (architecture)를 확정하는 엔지니어링 매니저 (eng manager), AI의 저질 결과물 (slop)을 잡아내는 디자이너, 프로덕션급 (production-grade) 버그를 찾아내는 리뷰어, 실제 브라우저를 실행하는 QA 리드, OWASP와 STRIDE를 실행하는 보안 담당자, 그리고 PR을 배포하는 릴리스 엔지니어 (release engineer)까지 말이죠. 23명의 전문가와 8개의 강력한 도구로 구성되어 있으며, 모두 슬래시 커맨드 (slash commands)와 마크다운 (Markdown) 방식이며, 무료이며, MIT 라이선스를 따릅니다."

이를 읽어보면 이것이 단일 "코딩 어시스턴트 (coding assistant)"가 아니라 역할이 명확히 나뉜 팀이라는 것을 알 수 있습니다. 인원수보다 더 중요한 것은 배포하기 전에 다각도의 검토 (multi-lens review)를 거치도록 강제한다는 점입니다. CEO의 관점은 이것이 정말 10점짜리 제품인지, 아니면 겉만 번지르르한 3점짜리 제품인지를 묻습니다. 엔지니어의 관점은 아키텍처 (architecture)가 예외 케이스 (edge cases)를 견딜 수 있는지 묻습니다. 디자인의 관점은 당신이 무엇이 "좋은 것"인지조차 알고 있는지 묻습니다. 개발자 경험 (devex)의 관점은 다른 사람이 얼마나 쉽게 이를 이어받아 구축할 수 있는지를 묻습니다. 그런 다음 테스트, PR 배포, 그리고 배포 후 모니터링 단계로 마무리됩니다.

파트 2: gstack이 믿는 것

gstack은 단순히 도구들을 정리해 놓은 것이 아닙니다. gstack은 입장 (stance)을 가지고 있으며, 그 입장이 바로 이것을 흥미롭게 만드는 핵심입니다. Garry는 ETHOS 파일에 다음과 같이 적었습니다.

"엔지니어링의 장벽은 무너졌습니다. 남은 것은 취향 (taste), 판단력 (judgment), 그리고 전체 과정을 완수하려는 의지입니다."

그는 올해 자신이 13년 전보다 수백 배 더 빠르게 코드를 배포한다고 주장합니다 (이는 중앙 벤치마크가 아닌, 본인이 직접 측정한 수치입니다). 하지만 그의 요점은 속도에 관한 것이 아닙니다. 코드를 작성하는 비용이 거의 들지 않게 된 이상, 무엇을 만들지 결정하고 저질 결과물 (slop)의 배포를 거부하는 것이 업무의 전부가 된다는 것입니다.

그가 'Boil the Ocean(모든 것을 다 하려 하지 마라)'이라고 부르는 원칙에서도 이를 확인할 수 있습니다. 과거에는 엔지니어의 시간이 비쌌기 때문에 "전체를 다 하지 마라"는 조언이 통했습니다. 하지만 그 비용이 사라진 지금, 요령을 피우고 나중에 수정하는 방식은 부채 (debt)로 변합니다. 만약 완전한 버전을 만드는 데 몇 분만 더 걸린다면, 그냥 완전하게 만드세요.

하지만 제가 가장 좋아하는 원칙은 결정은 반드시 사람이 해야 한다는 점입니다. gstack은 이를 다음과 같이 표현합니다:

"AI 모델은 추천할 뿐이다. 결정은 사용자가 한다." 그리고 "두 개의 AI 모델이 변경 사항에 동의하는 것은 강력한 신호일 뿐, 명령(mandate)이 아니다."

이것이 바로 gstack의 다중 관점 리뷰 파이프라인 (multi-lens review pipeline)이 중요한 이유입니다. 각 관점 (lens)은 작업을 단순히 승인 (rubber-stamp)하기 위해서가 아니라, 작업에 이의를 제기 (challenge) 하기 위해 존재하며, 어떤 이의를 받아들일지 선택하는 것은 사람입니다. 달리 말하면, gstack은 소프트웨어에 기록된 '취향 (taste)'이자 결정의 우선순위입니다. 대부분의 팀은 이러한 관점들을 거의 완전히 건너뛰며, 1인 개발자들은 이를 모두 생략합니다. 그는 이를 필수적인 게이트 (gates)로 다시 도입했습니다.

파트 3: 제품 빌더를 위한 교훈

직업으로서 코드를 작성하지 않더라도, 여기서 세 가지는 가져갈 만한 가치가 있습니다.

• 혼자 일하더라도 스스로에게 리뷰 게이트 (review gates)를 부여하세요. 팀은 본질적으로 논쟁을 하지만, 1인 개발자에게는 반박해 줄 사람이 없습니다. 두세 개의 리뷰 관점 (review lenses)을 설정하고, AI가 각 역할을 맡아 당신의 작업에 의문을 제기하게 하세요: 비즈니스 관점, 사용자 관점, 그리고 나중에 이를 유지보수해야 하는 사람의 관점입니다. 이는 당신이 간과한 것을 정말로 잡아냅니다.
• 완전함의 비용이 저렴해진 지금, 완전하게 만드세요. 시간이 부족해서 짧게 끝냈던 작업들을 이제는 훨씬 적은 비용으로 완성할 수 있습니다. 완전한 버전을 만드는 데 시간이 아주 조금 더 걸릴 뿐이라면, 거친 버전을 출시하지 마세요.
• 최종 결정은 스스로 간직하세요. 특히 AI가 확신에 차 보이거나 두 모델이 동의할 때 더욱 그렇습니다. 그때가 바로 통제권을 내려놓고 싶어지는 유혹이 드는 순간이며, 바로 그 순간이 가장 주의해야 할 때입니다.

시작하는 법

gstack을 모두 설치할 필요는 없습니다. 우선 아이디어만 빌려 쓰는 것부터 시작해 보세요.

1. 다음에 무언가를 출시(ship)하기 직전, AI에게 단 하나의 역할(예: "CEO로서 이것을 검토해줘")을 부여하고, 당신이 미처 생각하지 못했던 질문을 AI가 무엇인지 확인해 보세요.
2. 작업을 단축하고 싶은 지점에 도달했을 때, 완성된 버전을 만드는 데 실제로 시간이 얼마나 더 걸리는지 스스로에게 물어보세요. 만약 단 몇 분밖에 걸리지 않는다면, 완성된 결과물을 만드세요.
3. 다음에 AI가 매우 확신에 찬 태도를 보일 때, 잠시 멈추고 스스로에게 먼저 물어보는 연습을 하세요: "내가 동의하는 이유가 그것이 옳기 때문인가, 아니면 AI가 자신감 있게 말하기 때문인가?"

Garry가 자신의 스택(stack)을 오픈 소스로 공개한 것은 작은 일이 아닙니다. 이는 수천 개의 스타트업을 지켜봐 온 누군가가 보내는 신호입니다. 즉, 구축(building)의 병목 현상이 "코드를 작성할 수 있는가?"에서 "무엇을 만들지 결정하고, 불필요한 잡동사니(slop)를 배제할 수 있는가?"로 이동했다는 신호입니다. 이것은 전문 지식을 기술(skills)로 응축해 놓은 저장소(repos)들을 살펴보는 일련의 과정 중 하나입니다. 더 많은 내용이 이어질 예정이며, 이 모든 것을 관통하는 핵심적인 기둥 역할을 하는 글이 마지막을 장식할 것입니다.

출처 및 참고 문헌

• gstack by Garry Tan (github.com/garrytan/gstack, MIT). "엔지니어링의 벽이 무너졌다...", "AI 모델은 추천하고, 사용자는 결정한다.", "두 AI 모델이 변경 사항에 대해 동의하는 것은 강력한 신호다. 그것은 명령이 아니다."라는 인용구와 'Boil the Ocean'은 ETHOS.md에서 가져왔습니다. 23가지 역할을 가진 팀에 대한 설명은 README에서 가져왔습니다.
• 생산성 수치(이전보다 수백 배 빠름)는 README/ETHOS에 명시된 Garry 본인의 측정값입니다. 이는 중앙 벤치마크가 아니며, 우리가 측정한 수치도 아닙니다.

다이어그램이 포함된 원문 보기: https://productize.life/blog/gstack/en

Claude Code 1주일 무료 체험: https://claude.ai/referral/uurAE0WKHQ