gstack 슬래시 커맨드 BEST 10가지 — 기획부터 배포까지 순서대로

gstack 깔면 슬래시 커맨드가 스무 개 넘게 딸려와 뭐부터 써야 할지 막막합니다.
다 외우려다 시작도 못 하고, 막상 매일 손이 가는 핵심 몇 개를 모르면 도구만 깔린 채 방치됩니다.
gstack 시리즈 10편을 정리하고 직접 30분 MVP를 여러 번 돌려본 경험을 바탕으로 실제로 자주 쓰는 gstack 슬래시 커맨드만 추렸습니다.

다 읽으면 기획부터 배포까지 워크플로우 순서대로 BEST 10가지와 각각 언제 쓰는지가 정리됩니다.

왜 이 10개인가 — 스무 개 넘는 커맨드 중 매일 손이 가는 것만

gstack 슬래시 커맨드는 기획·구현·QA·배포·보안·문서까지 전 단계를 커버합니다. 다 좋지만 30분 MVP나 사이드 프로젝트 기준으로는 전부 쓸 일이 없습니다. 선별 기준은 세 가지였습니다.

기준	내용
사용 빈도	gstack 시리즈 작업하며 실제로 매번 호출한 커맨드
워크플로우 핵심	기획 → 구현 → QA → 배포 한 사이클을 거치는 데 필수
학습 비용	입력 한 줄로 효과 확인 가능, 부가 설정 없음

이 기준으로 추리면 전체 커맨드의 절반 이하만 남습니다.

한눈에 — gstack 슬래시 커맨드 BEST 10가지

단계	커맨드	한 줄 용도
기획	/office-hours	6가지 질문으로 기능 스코프 좁히기
기획	/plan-eng-review	아키텍처·데이터 흐름·엣지케이스·테스트 확정
기획	/autoplan	CEO·디자인·엔지니어링 리뷰 자동 실행
구현	/ship	동기화·테스트·커버리지·푸시·PR 한 번에
구현	/review	프로덕션 버그 잡는 스태프 엔지니어 리뷰
구현	/investigate	가설 테스트 기반 근본 원인 디버깅
QA	/qa	Playwright 기반 QA + 자동 회귀 테스트
QA	/browse	실제 Chromium으로 클릭·스크린샷
배포	/land-and-deploy	PR 머지·배포·프로덕션 헬스체크
멀티 AI	/codex	OpenAI 독립 리뷰로 세컨드 오피니언

기획 단계 — 코드 짜기 전에 스코프부터

1. /office-hours

워크플로우에서 가장 먼저 호출하는 커맨드. 만들려는 기능에 6가지 forcing question을 던져 "진짜 필요한 게 뭔지" 좁힙니다. 답을 평범한 한국어로 적으면 더 날카로운 스코프가 나옵니다. 이 단계를 건너뛰면 /plan-eng-review가 풀스펙을 권유하는 함정에 빠지기 쉽습니다.

2. /plan-eng-review

/office-hours가 만든 기획서를 받아 아키텍처·데이터 흐름·다이어그램·엣지케이스·테스트를 확정합니다. 단순 MVP면 제약을 명시해야 합니다. "외부 DB·인증·캐시 없음, 단일 라우트" 식 한 줄을 안 적으면 프로덕션 풀스펙으로 산만해집니다.

3. /autoplan

/office-hours·디자인·엔지니어링 리뷰를 한 번에 돌립니다. 단계별로 따로 호출하기 번거로울 때 이 한 줄로 기획 단계를 압축합니다. 다만 자동인 만큼 결과를 한 번 검토하고 넘어가는 게 안전합니다.

구현 단계 — 실제 코드를 만들고 검증

4. /ship

gstack에서 가장 자주 쓰는 gstack 슬래시 커맨드입니다. 변경 사항 동기화 → 테스트 → 커버리지 점검 → 푸시 → PR 생성까지 한 번에 처리합니다. 한 번에 1만 줄 가까이 생성하는 큰 작업도 한 흐름으로 진행됩니다.

5. /review

푸시 전에 거치는 스태프 엔지니어 리뷰. 프로덕션을 깨뜨릴 만한 버그를 의심하는 관점에서 코드를 훑습니다. /ship이 자동 호출하기도 하지만, 큰 변경은 따로 한 번 더 돌리면 안심됩니다.

6. /investigate

버그 원인이 안 보일 때 호출합니다. 증상만 보고 패치하는 대신 가설을 세우고 하나씩 검증하는 근본 원인 디버깅을 합니다. 로그만 봐서는 안 잡히는 이슈에 특히 효과가 좋습니다.

QA 단계 — 브라우저에서 실제로 동작 확인

7. /qa

Playwright 기반 Chromium으로 플로우를 클릭하며 버그를 찾고, 회귀 테스트를 자동 생성한 뒤 수정 커밋까지 묶습니다. 첫 사용 시 Chromium 바이너리가 없으면 npx playwright install chromium 한 줄로 해결됩니다.

8. /browse

실제 Chromium 브라우저로 직접 클릭하고 스크린샷을 찍습니다. 명령당 100밀리초 수준으로 빠르고, UI가 의도대로 그려지는지 눈으로 확인할 때 씁니다.

배포·멀티 AI 단계

9. /land-and-deploy

PR을 머지하고 배포한 뒤 프로덕션 헬스체크까지 확인합니다. 배포 직후 콘솔 에러나 회귀가 없는지 한 번에 점검하므로, 배포 후 손으로 확인하던 단계를 줄입니다.

10. /codex

OpenAI 모델로 독립 리뷰를 받아 세컨드 오피니언을 얻습니다. Claude 단독 판단이 불안한 설계 결정에서, 다른 모델 시각을 한 번 더 받으면 놓친 부분이 보입니다.

실제 워크플로우 흐름 — 30분 MVP 기준

10개를 다 순서대로 쓰는 건 아닙니다. 30분 MVP 기준 실제 흐름은 짧습니다.

/office-hours → /plan-eng-review → /ship → /qa → /land-and-deploy

기획 2개, 구현 1개, QA 1개, 배포 1개. /autoplan·/review·/investigate·/browse·/codex는 작업이 커지거나 막힐 때 추가로 꺼내 쓰는 카드입니다.

자주 묻는 질문

Q. gstack 슬래시 커맨드는 전부 외워야 하나요?
A. 아닙니다. 위 흐름의 5개(/office-hours·/plan-eng-review·/ship·/qa·/land-and-deploy)만 손에 익으면 한 사이클이 돌아갑니다. 나머지는 필요할 때 찾아 쓰면 됩니다.

Q. /plan-eng-review가 자꾸 풀스펙을 권유합니다.
A. 프롬프트 첫 줄에 제약을 명시하세요. "30분 MVP, 외부 DB·인증·캐시 없음, 단일 라우트" 식으로 적으면 기준이 잡힙니다. gstack 트러블슈팅 글에서 이 사례를 더 자세히 다뤘습니다.

Q. /qa 실행 시 브라우저 에러가 납니다.
A. Chromium 바이너리 미설치 케이스가 흔합니다. npx playwright install chromium 한 줄로 대부분 해결됩니다. 회사 보안 정책으로 다운로드가 막히면 시스템 브라우저 옵션을 확인하세요.

Q. /ship과 /land-and-deploy 차이가 뭔가요?
A. /ship은 PR을 여는 단계까지, /land-and-deploy는 그 PR을 머지하고 실제 배포·헬스체크까지입니다. 두 커맨드 사이에 리뷰를 한 번 끼우는 흐름이 안전합니다.

Q. /codex는 OpenAI 구독이 따로 필요한가요?
A. 독립 리뷰를 받으려면 해당 모델 접근이 필요합니다. 없으면 이 커맨드는 건너뛰고 나머지 9개로도 한 사이클은 충분히 돌아갑니다.

정리 — 단계별 핵심 커맨드

단계	핵심 1개	보조
기획	/office-hours	/plan-eng-review, /autoplan
구현	/ship	/review, /investigate
QA	/qa	/browse
배포	/land-and-deploy	/codex

스무 개 넘는 커맨드를 다 외우는 것보다 위 흐름 한 줄을 손에 익히는 게 빠릅니다. 비슷한 환경이면 위 가이드만으로 충분합니다.

---

📎 이 카테고리의 다른 글

• gstack 트러블슈팅 5가지 — 1~2시간 날리기 전에 확인할 것들 — 2026-05-17
• gstack 실전 사례 — 30분 안에 MVP 만들기 (Pomodoro 타이머 + 통계 위젯) — 2026-05-11
• Claude Code 활용법 정리 — 망치는 습관 3개와 살리는 습관 7개 — 2026-04-26

같은 gstack 시리즈에서 이어서 읽기

---

검증 환경: Windows 11 (24H2), WSL2 + Ubuntu 24.04, Bun 1.3.11, Node v24, Claude Max + gstack