들어가며: 실전 스프린트를 먼저 상상해보자 #
당신은 새벽 두 시, 머릿속에서 맴도는 아이디어 하나를 붙잡고 있다. “이걸 만들어볼까?” 생각만 해도 피곤해지는 과정들이 스쳐 지나간다. 요구사항 정리, 아키텍처 설계, 코드 작성, 리뷰, 테스트, 배포. 혼자라면 며칠이 걸릴 작업이다.
gstack을 설치하고 나면 그 그림이 달라진다. /office-hours로 아이디어를 제품 비전으로 다듬고, /plan-eng-review로 TDD 계획을 세운 뒤, Claude Code가 코드를 생성하고, /review가 스태프 엔지니어처럼 버그를 잡아낸다. /qa는 실제 Chromium 브라우저로 UI를 검증하고, /ship이 PR을 만들어 커버리지를 감사한다. 마지막으로 /land-and-deploy가 프로덕션에 올리고 헬스 체크까지 완료한다.
이 모든 과정이 하나의 도구로 연결된다. 이번 글에서는 gstack을 실제로 설치하고 첫 스프린트를 돌려보는 방법을 단계별로 안내한다.
사전 요구사항 #
gstack을 사용하기 전에 두 가지 도구가 필요하다.
Bun v1.0 이상
gstack의 스킬 실행 엔진은 Bun을 기반으로 한다. Node.js보다 빠른 JavaScript 런타임으로, 아직 설치하지 않았다면 공식 사이트(bun.sh)에서 설치하거나 다음 명령어로 바로 설치할 수 있다.
|
|
설치 후 버전을 확인한다.
|
|
Claude Code와 SKILL.md 지원
gstack은 Claude Code의 SKILL.md 프로토콜을 사용해 스킬을 로드한다. Claude Code가 설치되어 있고 최신 버전으로 업데이트되어 있어야 한다. claude --version으로 확인하고, /skills 명령이 응답한다면 SKILL.md 지원이 활성화된 것이다.
gstack 설치 (30초) #
사전 요구사항이 갖춰졌다면 설치는 정말로 30초다. 터미널을 열고 다음 두 줄을 실행한다.
|
|
--single-branch --depth 1 옵션 덕분에 전체 히스토리 없이 최신 스냅샷만 받아 속도가 빠르다. ./setup 스크립트는 필요한 의존성을 설치하고 Claude Code가 스킬을 인식할 수 있도록 등록한다.
설치가 완료되면 Claude Code 세션을 새로 시작하자. /office-hours를 입력했을 때 응답이 온다면 설치 성공이다.
팀 배포: 프로젝트에 gstack 벤더링 #
개인 개발 환경에 설치하는 것과 별개로, 팀 프로젝트에서 모든 팀원이 동일한 gstack 버전을 사용하려면 벤더링(vendoring) 이 필요하다. gstack은 이를 위한 전용 명령을 제공한다.
|
|
이 명령은 현재 디렉토리의 .claude/skills/gstack/ 폴더에 gstack을 복사한다. 이제 이 폴더를 git에 커밋하면 팀원 누구든 별도 설치 없이 동일한 스킬 셋을 사용할 수 있다. CI/CD 파이프라인에서도 gstack 스킬을 안정적으로 활용할 수 있다는 장점도 있다.
벤더링된 스킬은 글로벌 설치보다 우선순위가 높으므로, 프로젝트별로 다른 버전의 gstack을 핀닝할 수도 있다.
첫 번째 스킬: /office-hours — 제품 프레이밍
#
설치가 끝났다면 가장 먼저 사용할 스킬은 /office-hours다. 이름에서 알 수 있듯이, 이 스킬은 “교수님 면담 시간"처럼 당신의 아이디어를 혹독하게 검증한다.
Claude Code 세션에서 다음과 같이 시작한다.
|
|
스킬이 활성화되면 아이디어를 자유롭게 설명하라는 프롬프트가 뜬다. 예를 들어 “팀 회의 자동 요약 앱을 만들고 싶어. 음성 녹음을 받아서 요약하고, Slack으로 전송하는 기능이 필요해"라고 입력하면 된다.
그러면 /office-hours는 단순히 동의하지 않는다. 다음과 같은 강제 질문(forcing questions) 을 던진다.
- “회의 참가자가 앱을 직접 열어야 하는가, 아니면 자동으로 실행되어야 하는가?”
- “요약의 정확도가 95%라면 팀이 이를 신뢰하겠는가? 검토 프로세스가 필요한가?”
- “Slack 통합이 없다면 이 제품은 가치가 없는가, 아니면 MVP는 이메일로도 충분한가?”
이 질문들은 당신이 미처 생각하지 못한 가정들을 드러낸다. /office-hours의 목표는 당신이 틀렸다고 말하는 게 아니라, 제품이 실제로 무엇인지 명확히 정의하도록 돕는 것이다. 세션이 끝나면 검증된 제품 비전 문서와 핵심 기능 우선순위 목록이 산출된다.
계획 단계: /plan-ceo-review와 /plan-eng-review
#
제품 비전이 명확해졌다면 계획 단계로 넘어간다. gstack은 계획을 두 단계로 분리한다.
/plan-ceo-review: “정말 이게 필요한가?”
#
첫 번째 계획 스킬은 CEO 관점에서 범위를 검토한다.
|
|
이 스킬은 당신이 제안한 기능 목록을 받아 각각에 대해 날카롭게 묻는다. “이 기능을 빼면 MVP가 작동하지 않는가?” “이 기능은 두 번째 버전에서도 충분하지 않은가?” 비즈니스 논리로 범위를 최소화하는 것이 이 단계의 목적이다.
많은 개발자가 처음에는 이 과정이 가혹하다고 느끼지만, 실제로는 불필요한 복잡성을 사전에 제거해준다. 결과물은 축소되고 명확해진 기능 명세다.
/plan-eng-review: 아키텍처와 TDD 계획
#
두 번째 계획 스킬은 엔지니어링 관점에서 작동한다.
|
|
이 스킬은 CEO 리뷰를 통과한 기능 명세를 받아 구체적인 구현 계획으로 변환한다. 어떤 파일을 만들지, 어떤 의존성이 필요한지, 테스트는 어떻게 작성할지를 TDD(테스트 주도 개발) 원칙에 따라 계획한다.
산출물은 plan.md 파일로 저장되며, Claude Code가 이를 참조해 코드를 생성하게 된다. 파일 구조, 함수 시그니처, 예상 테스트 케이스까지 포함된 상세한 명세다.
개발 단계: Claude Code 네이티브 생성 #
계획이 준비되었다면 Claude Code에게 구현을 맡긴다. 이 단계는 gstack의 특정 스킬을 사용하는 게 아니라 Claude Code의 기본 기능을 활용하는 단계다.
|
|
Claude Code는 plan.md의 명세에 따라 코드를 생성하고, TDD 계획에 따른 테스트 파일도 함께 작성한다. 이 단계는 gstack이 이전 단계에서 쌓아놓은 컨텍스트 덕분에 훨씬 정확하고 일관된 코드가 나온다.
리뷰 단계: /review — 스태프 엔지니어 수준의 코드 리뷰
#
코드가 생성되었다면 /review를 실행한다. 이 스킬이 gstack의 핵심 가치 중 하나다.
|
|
/review는 단순히 문법 오류를 찾는 게 아니다. 스태프 엔지니어급 개발자가 PR 리뷰를 하듯 코드를 분석한다.
- 버그 탐지: 엣지 케이스, null 처리 누락, race condition 등
- 패턴 검증: plan.md의 명세와 실제 구현이 일치하는지 확인
- 보안 이슈: SQL 인젝션, XSS, 인증 누락 등
- 성능 문제: N+1 쿼리, 불필요한 재렌더링, 메모리 누수 등
- 자동 수정: 발견된 이슈 중 자동으로 수정 가능한 것들을 즉시 적용
리뷰가 끝나면 수정이 필요한 항목 목록과 이미 자동 수정된 코드 diff가 나온다. 사람이 보기 어려운 문제까지 잡아내는 능력이 인상적이다.
테스트 단계: /qa [url] — 실제 브라우저 테스트
#
코드 리뷰가 통과되면 실제 브라우저 테스트를 수행한다. /qa는 Playwright 기반의 실제 Chromium 브라우저를 구동해 UI 동작을 검증한다.
|
|
스테이징 URL을 제공하면 /qa는 다음을 수행한다.
- 실제 Chromium 브라우저 인스턴스 실행
- 자연어로 기술된 테스트 시나리오 수행
- 약 100ms 단위의 빠른 명령 실행 (클릭, 입력, 네비게이션)
- 문제 발견 시 스크린샷 자동 캡처
- 통과/실패 결과와 함께 수정 필요 항목 목록 생성
단위 테스트가 통과해도 실제 브라우저에서는 다르게 동작하는 경우가 많다. /qa는 그 간격을 메워주는 도구다. 특히 CSS 레이아웃 버그나 JavaScript 상태 관리 이슈처럼 코드만 봐서는 잡기 힘든 문제들을 효과적으로 포착한다.
배포 단계: /ship, /land-and-deploy, /canary
#
QA를 통과한 코드는 이제 배포 단계로 넘어간다. gstack은 배포 과정도 자동화한다.
/ship: PR 생성과 커버리지 감사
#
|
|
/ship은 다음을 수행한다.
- 테스트 파일과 소스 코드의 동기화 확인
- 테스트 커버리지 감사 리포트 생성 (미달 커버리지 경고)
- 커밋 히스토리를 기반으로 PR 자동 생성
- PR 설명에 변경 사항 요약, 테스트 결과, 커버리지 정보 포함
/land-and-deploy: 머지와 프로덕션 배포
#
|
|
PR이 승인되면 /land-and-deploy가 실행된다. 이 스킬은 단순히 머지 버튼을 누르는 게 아니다.
- 머지 실행
- 배포 파이프라인 트리거
- 배포 완료 후 헬스 체크 수행
- 주요 엔드포인트 응답 확인
- 에러율, 레이턴시 등 기본 메트릭 체크
배포 중 이상이 감지되면 즉시 알림을 준다.
/canary: 배포 후 지속 모니터링
#
|
|
배포가 완료된 이후에도 /canary로 지속적인 모니터링을 설정할 수 있다. 이상 트래픽 패턴, 에러 급증, 응답 시간 저하 등을 감지해 팀에 알림을 보낸다. 카나리 배포 전략을 사용하는 경우에는 단계적 트래픽 전환 상황도 모니터링한다.
주간 회고: /retro
#
매주 팀의 개발 활동을 리뷰하고 싶다면 /retro를 사용한다.
|
|
이 스킬은 한 주 동안의 스프린트 활동 메트릭을 집계한다. 얼마나 많은 기능을 출시했는지, 리뷰에서 얼마나 많은 이슈가 발견됐는지, QA 통과율은 어땠는지 등을 정리해 팀 회고 자료로 제공한다.
실전 팁: 각 스킬 활용 노하우 #
gstack을 실제로 사용해보면서 도움이 되는 팁들을 정리했다.
1. /office-hours는 건너뛰지 마라
바쁠 때 가장 먼저 건너뛰고 싶어지는 단계지만, 이 단계를 생략하면 나중에 훨씬 많은 시간을 낭비한다. 30분의 product framing이 3일의 재작업을 막는다.
2. /plan-ceo-review의 “축소” 제안을 진지하게 받아들여라
처음에는 “이 기능도 넣고 싶은데"라는 생각이 들겠지만, MVP 범위를 작게 유지하는 것이 장기적으로 유리하다. 두 번째 버전에서 추가해도 늦지 않다.
3. /review 후 바로 /qa를 실행하지 말고 수정을 먼저 적용하라
/review가 자동 수정을 했더라도, 수정된 코드를 한 번 확인하는 습관을 들이자. 자동 수정이 새로운 문제를 도입하는 경우가 드물게 있다.
4. /qa에는 구체적인 시나리오를 제공하라
“앱 테스트해줘"보다 “로그인 → 새 항목 생성 → 저장 → 목록에서 확인하는 플로우를 테스트해줘"처럼 구체적으로 지시할수록 더 의미 있는 결과를 얻는다.
5. /ship의 커버리지 경고를 무시하지 마라
커버리지가 낮은 부분은 나중에 버그의 온상이 된다. /ship이 경고하는 미커버 영역에 테스트를 추가하는 것이 장기적으로 코드베이스 품질을 높인다.
6. 팀 프로젝트라면 반드시 벤더링을 사용하라
글로벌 설치에 의존하면 팀원마다 다른 버전의 gstack을 사용하게 될 수 있다. gstack vendor로 버전을 고정해두는 것이 안전하다.
마무리 #
gstack의 핵심은 단순한 자동화가 아니다. 각 스킬이 이전 스킬의 출력을 입력으로 받아 파이프라인을 자동으로 구성하고, 사람이 개입해야 할 부분에서는 명확한 질문으로 결정을 유도한다. 혼자 일하는 개발자에게는 가상의 팀을, 실제 팀에게는 일관된 프로세스를 제공한다.
1부에서 gstack의 철학과 개요를 살펴봤다면, 이번 2부에서는 실제 설치와 스프린트 워크플로우를 다뤘다. 3부에서는 실제 프로젝트에 적용한 사례와 고급 설정 방법을 살펴볼 예정이다.
지금 바로 설치해보자. 30초면 충분하다.
|
|