gstack 누적 사용 후기 — 매일 손이 가는 패턴 7가지

gstack를 매일 쓰면서 결국 손이 가는 명령은 정해져 있더라는 게 결론입니다.
스무 개 넘는 슬래시 커맨드를 다 외우려다 시간만 날리고, 막상 매일 돌리는 루틴은 안 잡힙니다.

gstack 시리즈 7편을 발행하면서 본업과 사이드 프로젝트 양쪽에서 누적으로 매일 돌려본 입장에서 실제 손이 가는 패턴만 골랐습니다. 여기까지 보면 워크플로우에 gstack를 어떻게 정착시킬지 판단이 섭니다.

매일 손이 가는 명령만 추렸습니다

gstack 시리즈를 처음 시작했을 때는 슬래시 커맨드를 가능한 한 다 써보려고 했습니다. 결과부터 말하면 그건 도구 학습이지 일이 아니었습니다. 누적해서 쓰다 보니 실제 작업 시작부터 PR 머지까지 손이 가는 명령은 7개 정도로 좁혀집니다. 나머지는 "있다는 걸 알면 충분"하고, 정말 막힐 때만 한 번씩 꺼냅니다.

선별 기준은 단순합니다.

기준	내용
사용 빈도	매일 또는 한 사이클당 최소 1회 호출
대체 어려움	직접 명령으로 풀어 쓰기 번거로워 결국 다시 슬래시 커맨드로 돌아감
토큰 효율	같은 작업을 직접 프롬프트로 풀 때 대비 토큰 절약 체감이 있음

본업이 풀스택(웹 + 모바일 앱)이라 작업 종류가 자주 바뀌는데, 그런 환경에서도 7개는 거의 그대로 유지됩니다.

매일 손이 가는 패턴 7가지

1. /office-hours — 작업 시작 0번째 커맨드

오늘 뭘 만들지 정해졌다고 생각해도 막상 코드 짜기 시작하면 스코프가 흐려집니다. /office-hours는 6가지 질문으로 "진짜 만들어야 하는 게 뭔지" 좁힙니다. 작업이 1시간을 넘기는 모든 경우에 이걸 먼저 돌립니다. 안 돌리고 시작한 작업은 절반 이상이 중간에 한 번 갈아엎습니다.

2. /plan-eng-review — 기획서 → 아키텍처 확정

/office-hours 결과를 받아 데이터 흐름·엣지케이스·테스트 시나리오까지 잡는 명령입니다. 정직하게 말하면 처음엔 이 단계가 과한 줄 알았습니다. 매번 풀 아키텍처 다이어그램을 그려주니까. 그런데 막상 이 단계를 건너뛴 날은 구현 중에 "DB 모델 또 갈아엎어야 하나" 하는 순간이 옵니다. 짧은 작업은 "MVP, 외부 DB 없음" 한 줄 제약을 명시하면 기준이 잡힙니다.

3. /ship — 가장 자주 누르는 커맨드

이건 사실상 매일 손이 가는 명령입니다. 변경 동기화 → 테스트 → 커버리지 → 푸시 → PR까지 한 번에 처리합니다. 직접 명령으로 풀어 쓰면 5~6줄인데 /ship 한 줄로 끝나니 누적되는 시간 절약이 큽니다. 풀스택 작업처럼 프론트·백 양쪽을 같이 건드리는 경우 효과가 더 큽니다.

4. /investigate — 로그 봐서 안 풀리는 버그

증상은 보이는데 원인이 안 잡히는 케이스. 직접 디버깅할 때는 "이 줄이 의심된다" 같은 직감으로 패치하는데, /investigate는 가설을 명시적으로 세우고 하나씩 검증합니다. 같이 정리한 gstack 트러블슈팅 5가지의 케이스 몇 개도 이 명령으로 풀었습니다. 단순 NullReference 같은 거 말고, 비동기 타이밍이나 상태 관리 문제일 때 특히 잘 잡습니다.

5. /review — 큰 PR 직전 한 번 더

/ship이 자동으로 가벼운 리뷰를 끼우긴 하지만, 변경 라인 수가 500줄을 넘어가면 따로 /review를 한 번 더 돌립니다. 스태프 엔지니어 관점에서 "프로덕션을 깨뜨릴 만한 게 있나"를 의심하는데, 사람 리뷰에서 자주 놓치는 패턴(에러 핸들링 빠진 경로, 캐시 무효화 누락)을 꽤 잡아줍니다.

6. /qa — 배포 전 마지막 관문

Playwright 기반으로 브라우저에서 실제 클릭하며 도는 회귀 테스트입니다. 사이드 프로젝트면 생략하고 싶다는 유혹이 있는데, 한 번 안 돌리고 배포했다가 회원가입 플로우 막힌 적이 있어서 그 이후로 꼬박꼬박 돌립니다. UI 변경이 있는 PR이면 거의 100% 이 단계를 거칩니다.

7. /land-and-deploy — PR 머지 + 헬스체크

머지·배포·프로덕션 헬스체크까지 한 흐름. 직접 하면 GitHub 머지 → CI 모니터링 → 배포 환경 콘솔 확인 세 단계로 컨텍스트가 끊깁니다. 한 줄로 묶이니까 다음 작업으로 바로 넘어가기가 자연스럽습니다.

처음에 깨닫지 못한 함정 3가지

누적으로 쓰다 보니 보이는 함정들. 처음 시작하는 분은 미리 피하시면 시간을 절약합니다.

함정 1 — 슬래시 커맨드 다 외우려다 망함

처음 한 달은 새 커맨드 발견할 때마다 다 써보려고 했습니다. 결과는 어느 것 하나 손에 익지 않은 상태. 3~5개로 좁히고 그것만 반복하니 비로소 워크플로우가 잡혔습니다. 위 7개도 자기 작업 패턴에 따라 5개로 줄어도 됩니다.

함정 2 — workflow 명령에서 토큰 급증

/autoplan처럼 여러 단계를 묶는 명령은 편한 만큼 토큰이 빠르게 소모됩니다. Claude Max 사용자라면 체감이 덜하지만, 사이드 프로젝트로 Pro 플랜만 쓰는 분이라면 큰 작업에서 한도 빨리 도달합니다. 단계를 쪼개서 호출하는 게 누적 토큰 면에서 유리합니다.

함정 3 — 자동 커밋 켰다가 노이즈 급증

/ship이 자동으로 커밋·푸시까지 처리하는 게 편한데, 큰 변경에서 의미 단위로 커밋이 안 쪼개집니다. PR 단일 커밋으로 1만 줄짜리가 들어가면 코드 리뷰가 사실상 불가능합니다. 큰 작업은 중간중간 수동 커밋을 끼우는 게 정답이라는 결론입니다.

안 쓰게 된 기능 2가지

정직하게, 누적해서 써본 결과 손이 안 가는 기능도 있습니다.

/browse — 단순 스크린샷 용도라면 직접 브라우저 열어 찍는 게 빠릅니다. /qa가 회귀 테스트까지 묶어주니 시각 검증은 거기로 통합되고, 별도 /browse 호출 빈도는 거의 0으로 줄었습니다.

/autoplan — 기획·디자인·엔지니어링 리뷰를 한 번에 거치는 명령인데, 결과를 한 번에 다 보면 검토 피로도가 높습니다. /office-hours → /plan-eng-review 두 단계로 끊어서 보는 게 결과 품질이 더 좋다는 게 제 경험. 자동이라고 다 좋은 건 아닙니다.

누구에게 추천 / 비추천

환경	추천 여부	이유
1인 사이드 프로젝트 / MVP 단계	✅ 강력 추천	워크플로우 한 줄로 돌아가는 효과가 가장 큼
풀스택 본업 (웹·앱 같이)	✅ 추천	컨텍스트 전환 비용 크게 줄어듦
학습용 토이 프로젝트	✅ 추천	기획·QA 단계 자동화로 좋은 습관 정착
단순 1줄 코드 수정	❌ 비추천	슬래시 커맨드 호출이 오히려 오버헤드
정규 팀 코드 리뷰만 필요	❌ 비추천	팀 리뷰 프로세스가 이미 있으면 중복
토큰 절약이 1순위	❌ 비추천	workflow 명령은 토큰 소비 큼

본업에서는 큰 PR에 /ship + /review, 사이드 프로젝트에서는 /office-hours + /ship이 거의 고정입니다. 이 차이를 알고 시작하면 정착 시간이 짧아집니다.

이런 질문 자주 받습니다

Q. 처음 셋업은 어떻게 하나요?
A. 시리즈 2편 gstack 설치 가이드 (Windows)부터 보시면 됩니다. Windows 11 + WSL2 + Node v24 + Bun 1.3.11 환경 기준으로 막힘없이 진행됩니다. 설치 자체는 10분 안쪽으로 끝납니다.

Q. Claude Code랑 어떻게 다른가요?
A. gstack는 Claude Code 위에 슬래시 커맨드·워크플로우·QA 자동화를 얹은 도구로 보시면 됩니다. Claude Code가 "범용 AI 코딩 셸"이라면, gstack는 "기획-구현-QA-배포 사이클이 미리 정의된 워크플로우 패키지"에 가깝습니다. Claude Code만으로도 동일 작업이 가능하지만, gstack는 그 흐름을 한 줄 명령으로 묶어주는 차이입니다.

Q. 유료인가요?
A. gstack 자체는 오픈 소스이고, 백엔드 LLM 호출에 Claude API 또는 Claude Max 같은 구독이 필요합니다. 사이드 프로젝트로 가볍게 돌리려면 API 종량제, 매일 본업에 붙이려면 Max 구독이 누적 비용 면에서 유리합니다.

Q. 한국어로 잘 작동하나요?
A. 프롬프트와 답변 모두 한국어로 무리 없이 돕니다. 슬래시 커맨드 이름·옵션은 영어지만 본문은 한국어로 적어도 같은 품질이 나옵니다. 본업 코멘트·문서가 한국어인 환경에서 그대로 써왔습니다.

Q. 팀 단위로 쓸 수 있나요?
A. 개인 도구 성격이 강합니다. 슬래시 커맨드 결과·PR 컨벤션이 사람마다 살짝씩 달라서, 팀 도입은 사전에 규칙을 합의해야 합니다. 5인 이하 작은 팀에서 동일 워크플로우를 공유하기로 미리 정한 경우에만 권장합니다. 그 이상이면 일관성 비용이 누적됩니다.

정리

스무 개 넘는 커맨드를 다 외우는 게 아니라, 자기 작업 패턴에 맞는 5~7개를 정착시키는 게 gstack를 잘 쓰는 길입니다. 위 7가지는 시리즈 7편을 누적해서 발행하면서 본업과 사이드 양쪽에서 살아남은 명령이고, 함정 3가지는 같은 시간 낭비를 피하라고 적었습니다. 같은 조건이면 위 판단 기준이 정답입니다.

---

📚 gstack 시리즈 흐름 — 기획부터 배포까지

1. gstack 소개 — 혼자서 20인분 개발하기 — 입문
2. gstack 설치 가이드 (Windows) — 설치
3. gstack 기획 & 플래닝 가이드 — 기획
4. gstack 개발 & 코드 품질 가이드 — 개발
5. gstack 디자인 가이드 — 디자인
6. gstack QA & 배포 가이드 — QA/배포
7. gstack 실전 워크플로우 — 실전
8. gstack 실전 사례 — 30분 MVP — 사례
9. gstack 트러블슈팅 5가지 — 트러블슈팅
10. gstack 슬래시 커맨드 BEST 10가지 — 정리
11. 👉 현재 글 — gstack 누적 사용 후기 — 매일 손이 가는 패턴 7가지

처음 보시는 분은 gstack 소개 — 혼자서 20인분 개발하기부터 보세요.

---

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