PM 혼자 바이브코딩할 때 gstack에서 먼저 써볼 8개

makewithai 2026. 7. 22. 14:30

지난 편에서 게리 탄(Garry Tan)이 공개한 Claude Code 툴킷 gstack의 전체 구조를 살펴봤다. 23개 전문 스킬과 8개 파워툴, 총 30개가 넘는 구성이다. 이걸 한 번에 다 익히려 들면 오히려 시작도 못 하고 지친다.

PM 출신으로 혼자 바이브코딩하는 입장에서, 실제로 먼저 손대볼 만한 8개만 추렸다.

우선순위 8개

순위스킬하는 일왜 먼저인가

1	office-hours	아이디어를 코드 짜기 전에 검증	요구사항 명확화는 PM에게 익숙한 작업과 겹친다
2	spec	막연한 의도를 5단계 실행 스펙으로 변환	"이거 만들어줘"의 모호함을 줄여준다
3	plan-eng-review	엔지니어링 매니저 관점 계획 리뷰	개발 지식이 부족한 부분을 AI가 대신 검토해준다
4	review	PR 랜딩 전 최종 코드 리뷰	혼자 개발할 때 놓치는 버그를 잡아준다
5	qa	웹앱 QA + 버그 직접 수정까지	배포 전 필수, 헤드리스 브라우저로 실사용을 흉내 낸다
6	ship	배포 원스톱 워크플로우	자동화 수익화 방향과 직결된다
7	context-save / context-restore	작업 컨텍스트 저장/복원	세션이 끊겨도 이어서 작업할 수 있다
8	retro	주간 엔지니어링 회고	PM 습관(회고)과 자연스럽게 연결된다

이 8개만 익혀도 기획 → 검증 → 개발 → QA → 배포의 최소 사이클이 완성된다.

왜 이 순서인가

office-hours와 spec을 가장 앞에 둔 이유는 단순하다. 바이브코딩에서 가장 많은 시간을 잡아먹는 건 코드 자체가 아니라 "내가 지금 뭘 만들려는 건지"가 흐릿한 상태에서 일단 프롬프트부터 던지는 습관이다. PM으로 일하면서 요구사항을 명확히 하는 훈련은 이미 되어 있으니, 이 두 스킬은 낯선 도구가 아니라 익숙한 작업을 AI에게 위임하는 느낌에 가깝다.

plan-eng-review와 review는 반대로 PM에게 약한 지점을 메워주는 용도다. 아키텍처 판단이나 코드 품질은 혼자 개발할 때 가장 놓치기 쉬운 부분인데, 이걸 엔지니어링 매니저 페르소나가 대신 검토해주는 구조다.

qa와 ship은 배포까지 가는 마지막 관문이다. 특히 ship은 브랜치 머지부터 버전업, CHANGELOG, PR까지 한 번에 처리해주기 때문에, 자동화 수익화를 목표로 한다면 이 스킬 하나로 배포 사이클 자체를 자동화하는 셈이 된다.

context-save/context-restore와 retro는 우선순위상 뒤에 있지만 실제 체감 효용은 크다. 세션이 끊겨서 맥락을 처음부터 다시 설명해야 하는 상황, 바이브코딩 해본 사람이라면 한 번쯤 겪었을 것이다. 그리고 주간 회고는 PM 업무에서 익숙한 루틴이라, 이 스킬은 그냥 그 습관을 개발 프로젝트에 옮겨오는 것뿐이다.

실제로 어떻게 쓰고, 뭐가 나오나

이론만으로는 감이 안 잡히니, 공식 문서 기준으로 대표적인 4개 스킬이 실제로 어떻게 동작하는지 정리했다.

/office-hours — 아이디어 검증

Claude Code에서 /office-hours라고 치거나, "이 아이디어 괜찮을까?" 같은 말을 하면 자동으로 실행된다. 두 가지 모드가 있다.

스타트업 모드: "수요가 진짜 있나, 지금은 어떻게 해결하고 있나, 구체적으로 누가 필요로 하나, 가장 좁게 시작할 수 있는 지점이 어디인가" 같은 6개의 압박 질문을 던진다. "헬스케어 기업들이 필요로 함" 같은 막연한 답은 계속 되돌려 받는다. 이름, 직무, 회사, 이유가 구체적으로 나올 때까지.
빌더 모드: 사이드 프로젝트나 해커톤용으로, 브레인스토밍 파트너에 가깝게 진행된다.

대화가 끝나면 ~/.gstack/projects/ 경로에 디자인 문서가 자동 저장되고, 이 문서가 다음 단계인 /plan-eng-review로 그대로 이어진다.

/spec — 막연한 아이디어를 실행 스펙으로

"이거 스펙으로 정리해줘", "GitHub 이슈로 만들어줘" 같은 말을 하면 자동 실행된다. 5단계(왜 하는지 → 범위 → 기술적 검토(코드 직접 읽기 필수) → 초안 → 파일링)를 거치는데, 특이한 건 품질 게이트가 있다는 점이다. 자체 점수가 7/10 미만이면 파일링을 막는다. 비밀키(API key 등)가 실수로 포함되지 않도록 자동 검열도 들어간다.

결과물로 GitHub 이슈가 생성되고, 기존 이슈와 중복되는지도 자동으로 체크해준다.

/review → /ship — 리뷰부터 배포까지

PR 머지 직전에 "리뷰해줘" 하면 /review가 코드 diff를 분석해서 문제점을 짚어주는 리뷰 코멘트를 생성한다. 여기서 문제없으면 바로 "배포해줘" 또는 /ship으로 넘어가는데, 이 한 번의 명령으로 브랜치 머지 → 테스트 실행 → 버전 업 → CHANGELOG 작성 → PR 생성까지 전부 처리된다. 사람이 클릭할 일이 거의 없다.

대표적인 전체 흐름

공식 문서에서 제시하는 대표적인 첫 루프는 이렇다.

/office-hours (또는 /spec) → 아이디어를 디자인 문서로 정리
     ↓
/plan-eng-review → 아키텍처 확정
     ↓
/ship → 배포까지 완료

이 세 개만 이어 붙여도 아이디어에서 배포까지 한 세션 안에서 끝나는 구조다. 공식 문서에서도 gstack은 이 루프 하나를 완주할 때 진가를 발휘한다고 강조한다.

한 가지 재밌는 점은, /로 직접 명령어를 치지 않아도 말하는 내용에 따라 gstack이 알아서 적절한 스킬을 골라 실행해준다는 것이다. "이거 좀 브레인스토밍 해볼까"라고 하면 자동으로 /office-hours가, "버그 있는 거 같은데"라고 하면 자동으로 /investigate가 실행되는 식이다.

자동화 수익화 관점에서 눈여겨볼 것

바이브코딩으로 자동화 수익화를 노리는 방향이라면 이렇게 조합해볼 수 있다.

spec → plan-eng-review → qa → ship, 이 4개만으로도 최소 사이클이 완성된다. 아이디어를 스펙으로 만들고, 검토받고, 테스트하고, 배포까지 — 사람이 개입하는 지점을 최소화하는 흐름이다.
scrape + skillify 조합은 반복 작업 흐름을 아예 재사용 스킬로 저장해두는 구조다. n8n 같은 자동화 툴과 결이 비슷해서, 자동화 파이프라인을 만들 때 참고할 만하다.
iOS 전용 스킬 5개는 네이티브 앱을 안 만들면 통째로 무시해도 된다. 전체 스킬 수가 많아 보여도 이쪽에 몰려있는 비중이 커서, 체감 개수는 실제로 더 적다.

시작하는 법

1편에서 다룬 설치 명령어로 gstack을 먼저 설치한다.

bash

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

그다음 위 8개 순서대로 하나씩 실제 프로젝트에 적용해보는 걸 추천한다. autoplan이나 design-shotgun 같은 무거운 스킬은 러닝커브가 있으니, 이 8개를 1~2주 정도 써보고 익숙해진 다음 확장하는 편이 낫다.

이전 편: [gstack이 뭐길래 난리인가 — 게리 탄이 공개한 Claude Code 툴킷 뜯어보기]