Y Combinator의 AI 에이전트 사용법 완벽 정리 - Gstack

요약

gstack은 Claude Code에 역할별 전문가 모드를 부여하는 오픈소스 스킬 모음이고, 이 페이지가 다루는 자료는 그 사용법을 한국어로 풀어 쓴 가이드다. 저자는 GPTERS의 editor_소연이며, 원문은 gpters.org의 "에이전트 / 노코드 자동화" 카테고리에 실렸다. gstack을 만든 사람은 Y Combinator의 CEO Garry Tan으로, 원문은 그가 직접 만들어 GitHub에 공개했다고 소개한다.

가이드의 구성은 네 부분이다. 먼저 gstack이 왜 필요했는지를 설계 동기로 설명하고, 이어 9개 슬래시 커맨드를 하나씩 풀며, 요약표로 스킬과 역할을 대응시킨 다음, 비용과 환경 요건을 FAQ로 마무리한다.

이 글이 가장 자세히 파고드는 대목은 브라우저 기반 QA 스택이다. 원문 스스로도 해당 절에 "가장 기술적으로 인상적"이라는 표시를 달았다. Playwright 기반 헤드리스 Chromium을 장기 실행 데몬으로 운용한다는 점, 콜드 스타트 35초 이후에는 호출이 100200ms로 줄어든다는 점, git diff를 읽어 변경된 페이지만 테스트한다는 점을 수치와 함께 서술한다.

다만 이 자료는 소개 성격의 가이드다. 성능 수치의 측정 방법과 환경이 적혀 있지 않고, 명령어를 직접 실행해 검증한 기록도 없다. 따라서 gstack의 효과를 재는 근거가 아니라 도구의 구성과 사용 순서를 파악하는 안내로 읽는 것이 적절하다.

배경

한 가지 모드로만 동작하는 기본 Claude Code

원문의 출발점은 기본 Claude Code의 동작 방식이다. 저자는 Claude Code가 똑똑하지만 한 가지 모드로만 동작한다고 본다. 코드를 짜달라고 하면 곧바로 짜기 시작할 뿐, 원문의 표현을 빌리면 "이거 진짜 만들어야 하는 게 맞아?"라고 먼저 묻지 않는다.

Garry Tan은 이 지점을 역할의 부재 문제로 봤다. 작업을 수행하는 능력이 모자란 것이 아니라, 어떤 관점에서 그 작업을 볼지가 정해져 있지 않다는 진단이다. 같은 모델이라도 검토자의 자리에 서느냐 구현자의 자리에 서느냐에 따라 내놓는 답이 달라지기 때문이다.

실제 팀의 역할 분담

해법의 모형은 실제 소프트웨어 팀이다. 원문은 팀 안에서 누가 어떤 질문을 담당하는지를 먼저 정리하고, 그 자리마다 슬래시 커맨드를 하나씩 배정한다.

이 구조에서 사용자는 상황에 맞는 관점을 골라 호출하는 방식으로 일한다. 원문은 그 경험을 "한 사람이 8명의 전문가를 데리고 일하듯" 개발하는 것이라고 표현한다.

핵심 개념

skill pack. gstack은 Claude Code용 스킬 모음이다. 스킬은 특정 작업 절차를 담아 에이전트에 제공하는 지침 패키지를 뜻한다. 별도의 서버나 서비스가 아니라 파일 묶음이므로, 설치는 저장소를 Claude Code의 스킬 디렉터리로 clone하고 ./setup을 실행하는 것으로 끝난다.

역할 분리. 하나의 범용 어시스턴트에게 모든 요청을 보내는 대신, 요청의 성격에 맞는 역할을 먼저 고르는 설계다. 원문 FAQ는 이 차이를 일반 Claude Code가 같은 모드로 동작하는 범용 어시스턴트인 반면 gstack은 역할별 페르소나를 부여한다는 대비로 정리한다.

Diff-Aware 실행. git diff가 알려주는 변경분을 읽어 작업 범위를 좁히는 방식이다. QA에서는 변경된 페이지만 골라 테스트하고, 코드 리뷰에서는 main 브랜치 대비 diff만 분석한다. 프로젝트 전체를 매번 훑지 않으므로 실행 시간이 프로젝트 크기가 아니라 변경 규모를 따라간다.

장기 실행 데몬. 브라우저를 호출마다 새로 시작하지 않고 상주시키는 운용 방식이다. 프로세스가 살아 있으므로 쿠키, localStorage, 로그인 상태가 호출 사이에 유지되고 시작 비용도 최초 한 번만 든다. 뒤에 나오는 100~200ms라는 응답 시간은 이 상주 구조에서 나온 값이다.

방법

제품 방향 검토

/plan-ceo-review는 파운더와 CEO의 관점에서 계획을 다시 본다. 코드를 쓰기 전에 방향 자체가 맞는지 되묻는 자리이며, 요약표의 한 줄 설명은 "방향성 재검토, 10배 더 좋은 제품"이다.

이 명령은 하나의 답을 내지 않고 세 가지 모드를 제시한다.

세 모드는 범위를 넓히거나, 그대로 두거나, 좁히는 선택지에 각각 대응한다. 계획을 승인하거나 반려하는 이분법 대신 범위 조정이라는 기준으로 판단하게 만드는 구조다.

구현 설계 확정

/plan-eng-review는 "어떻게 만들지"를 확정하는 명령이다. 검토 대상은 아키텍처, 데이터 흐름, 다이어그램, 엣지 케이스, 테스트 커버리지, 성능이다. 방향이 정해진 뒤 구현 방식을 고정하는 단계이므로 앞의 /plan-ceo-review 다음에 오는 순서다.

이 명령의 성격을 원문은 opinionated 추천이라고 적는다. opinionated 추천은 선택지를 나열하고 판단을 사용자에게 미루는 대신 하나를 고르고 근거를 함께 내놓는 방식을 말한다. "알아서 해"가 아니라 "이렇게 하자, 이유는 이거야"에 해당한다는 것이 원문의 설명이다.

프로덕션 버그 탐색

/review는 스태프 엔지니어 역할로, main 브랜치 대비 diff를 분석한다. 겨냥하는 대상이 분명한데, CI는 통과했지만 프로덕션에서 문제가 되는 버그다. 검사 항목은 다음과 같다.

여기에 Greptile 연동이 붙는다. Greptile은 자동 코드 리뷰 코멘트를 생성하는 서비스이고, /review는 그 코멘트 가운데 진짜 문제와 오탐을 구별하는 데 이를 활용한다. 자동 리뷰 도구를 그대로 신뢰하지 않고 한 겹 더 판정한다는 뜻이다.

릴리스 실행

/ship은 릴리스 엔지니어 역할로, 배포에 필요한 여러 단계를 명령 한 줄로 실행한다. 원문이 제시하는 순서는 6단계다.

앞의 세 단계가 검증이고 뒤의 세 단계가 기록과 반영이다. 사람이 매번 같은 순서로 반복하던 릴리스 파이프라인 전체를 명령 하나에 묶은 형태다.

브라우저 기반 QA

/browse와 /qa 계열은 AI가 실제로 웹 페이지를 열고 테스트하게 한다. gstack은 이를 위해 Playwright 기반 헤드리스 브라우저를 약 58MB 규모로 내장한다. 헤드리스 브라우저는 화면 출력 없이 백그라운드에서 실행되는 브라우저를 말한다.

운용 방식의 특징은 세 가지다.

• 장기 실행 데몬: 호출마다 새로 시작하지 않는다. 그래서 쿠키, localStorage, 로그인 상태가 호출 사이에 유지된다.
• 응답 시간: 콜드 스타트는 35초가 걸리지만 이후 호출은 100200ms다. 즉 첫 호출 이후에는 0.1초에서 0.2초 사이에 응답을 받는다.
• Diff-Aware 테스트: git diff를 읽어 변경된 페이지만 골라 테스트한다.

세 명령은 개입 범위가 서로 다르다.

/qa와 /qa-only의 구분이 실무에서 중요하다. 수정 권한을 줄지 보고만 받을지를 명령 선택으로 정하기 때문이다.

로그인 상태 확보

/setup-browser-cookies는 QA의 걸림돌인 로그인 문제를 다룬다. 서비스의 대부분 화면이 로그인 뒤에 있으므로, 로그인하지 못하면 자동 테스트가 접근할 수 있는 범위가 공개 페이지로 제한된다.

해법은 사용자가 이미 로그인해 둔 실제 브라우저에서 쿠키를 가져오는 것이다. 지원 대상은 Chrome, Arc, Brave, Edge, Comet이며, 인터랙티브 UI로 어떤 도메인의 쿠키를 가져올지 고른다. 도메인을 선택하게 한다는 것은 필요한 범위만 넘긴다는 뜻이다.

팀 단위 회고

/retro는 커밋 히스토리, 작업 패턴, 코드 품질 메트릭을 분석해 회고를 만든다. 원문이 강조하는 것은 Team-Aware 모드로, 분석 단위를 개인에서 팀으로 넓힌다.

JSON 스냅샷을 남긴다는 점이 이 명령을 일회성 요약과 구별한다. 회고마다 같은 형식의 기록이 쌓이므로 지표가 어느 방향으로 움직이는지를 기간에 걸쳐 비교할 수 있다.

9개 스킬 카탈로그

원문은 마지막에 다룬 명령어를 한 표로 모은다. 각 스킬에 사람 역할의 이름을 붙여 놓은 것이 이 표의 특징이다.

9개의 분포는 계획 2개, 리뷰 1개, 릴리스 1개, QA 4개, 회고 1개다. QA 계열이 가장 많고, 이는 브라우저 스택에 지면을 많이 배정한 원문의 구성과 일치한다.

결과

브라우저 데몬 성능

원문이 제시하는 정량 수치는 브라우저 스택에 몰려 있다.

콜드 스타트와 이후 호출의 차이는 20배에서 50배 사이다. 브라우저를 매번 새로 시작하는 대신 상주시키는 설계가 무엇을 얻으려 했는지를 이 간격이 보여준다. 다만 원문에는 측정 환경과 방법이 적혀 있지 않으므로, 재현 가능한 벤치마크가 아니라 제시된 값으로 받아들여야 한다.

비용과 환경 요건

FAQ가 다루는 네 항목은 도입 판단에 필요한 실무 정보다.

비용 항목에서 확인할 점은 gstack 자체가 별도 과금 대상이 아니라는 것이다. 실행 비용은 Claude Code 구독에 포함되고, 추가로 드는 것은 설치 시간과 학습 시간뿐이다.

설치 방식

설치는 두 가지 범위 중 하나를 고른다.

# 글로벌 설치
git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack \
  && cd ~/.claude/skills/gstack && ./setup

# 프로젝트별 설치
cp -Rf ~/.claude/skills/gstack .claude/skills/gstack \
  && rm -rf .claude/skills/gstack/.git \
  && cd .claude/skills/gstack && ./setup

프로젝트별 설치에서 .git을 제거하는 이유는 스킬 저장소의 이력이 프로젝트 저장소 안에 중첩되는 것을 막기 위해서다. 이 방식으로 설치하면 스킬 파일이 프로젝트에 함께 커밋되므로 팀원이 같은 명령어 집합을 공유하게 된다.

한계

측정 근거가 없다. 콜드 스타트 35초와 이후 호출 100200ms는 측정 환경, 대상 페이지, 반복 횟수가 밝혀지지 않은 값이다. 독립 검증 결과가 아니므로 성능 비교의 기준으로 쓰기는 어렵다.

검증 기록이 없다. 이 자료는 명령어를 실행해 결과를 확인한 실험 보고가 아니라 사용법 안내다. 각 명령어가 실제로 어떤 출력을 내는지에 대한 예시가 본문에 없다.

숫자가 어긋난다. 원문은 도입부에서 "8명의 전문가를 데리고 일하듯"이라고 쓰고, 뒤의 요약표에는 9개 스킬을 싣는다. 두 숫자 가운데 어느 쪽이 의도된 값인지는 본문에서 확인되지 않는다.

저장소 명령어의 일부만 다룬다. 이 글이 설명하는 명령어는 9개다. 저장소가 제공하는 명령어 수는 9bow 해설(gstack: Y Combinator 대표 Garry Tan이 공개한, Claude Code로 20인 규모의 가상 엔지니어링 팀을 만드는 스킬 모음)이 28개로 기록하므로(저장소 README 자체는 총수를 적지 않는다), 안전 장치 계열(/careful, /freeze, /guard)이나 보안 감사(/cso), 디버깅(/investigate) 같은 명령은 이 가이드의 범위 밖이다. 전체 명령어 목록이 필요하면 저장소 페이지나 카탈로그 성격의 소개글을 함께 봐야 한다.

핵심 용어

관련 페이지

• gstack: AI-Powered Software Factory: 이 가이드가 설명하는 원 저장소. 주요 스킬과 텔레메트리 정책, 저자의 생산성 자기 보고 수치를 담고 있다. 명령어 수 28개는 9bow 해설의 값이다
• gstack 자료 지도와 명령어 출처 대조: gstack을 여러 한국어 자료와 함께 묶은 합성 overview
• gstack: Y Combinator 대표 Garry Tan이 공개한, Claude Code로 20인 규모의 가상 엔지니어링 팀을 만드는 스킬 모음: 같은 도구를 명령어 카탈로그 중심으로 정리한 한국어 소개
• gstack: Claude Code로 만드는 가상 엔지니어링 팀 (GeekNews): 대상 사용자 구분과 Conductor 병렬 스프린트에 초점을 둔 소개