사례: gstack
gstack을 강한 opinion의 소프트웨어 팩토리로 보고 sprint, command, release gate 관점에서 해석합니다.
핵심 요약
- gstack은 하네스를 개념 프레임이 아니라
Think → Plan → Build → Review → Test → Ship → Reflect같은 실행 가능한 sprint 구조로 봅니다. - 단계를 먼저 고정해야 병렬 에이전트가 chaos가 아니라 throughput이 되고, 각 단계에는 출력 포맷과 check-in 포인트가 있어야 합니다.
- review/test/ship를 별도 release gate로 분리해 "구현 완료"와 "출시 가능"을 같은 말로 두지 않습니다.
- 2026-05 README는 23 specialists·8 power tools, 10개 agent host 지원, team mode auto-update, iOS device QA, checkpoint/learning으로 확장되었습니다.
- 넓은 command catalog는 팀 표준으로 들일 때 실제로 쓰는 5~8개부터 시작하는 편이 안전합니다.
gstack은 하네스를 개념 프레임보다 실행 프로세스로 더 분명하게 보여줍니다. 핵심은 "에이전트를 많이 두자"가 아니라 병렬 작업이 혼란이 되지 않도록 sprint 구조를 먼저 고정하는 것입니다.
2026년 5월 기준 README에서 더 중요해진 대목은, gstack이 Claude Code 개인 설정을 넘어 여러 AI coding agent host에 배포되는 skill/command distribution layer로 확장되고 있다는 것입니다. 좋은 루틴을 문서로 설명하는 데 그치지 않고, 팀과 도구 표면에 설치되는 실행 단위로 내려보냅니다.
해결하려는 문제
- 병렬 에이전트가 늘수록 누가 뭘 하는지 모호해짐
- build까진 되는데 review, QA, ship 단계가 빠짐
- release 직전 인간이 모든 혼란을 수습해야 함
- 특정 agent runtime에만 묶여 팀 표준 workflow를 재사용하기 어려움
기술적 메커니즘
gstack의 메시지는 매우 명확합니다.
Think -> Plan -> Build -> Review -> Test -> Ship -> Reflect
이 구조가 load-bearing인 이유는 여러 에이전트가 동시에 움직여도 멈춰야 할 지점과 넘겨야 할 산출물이 분명해지기 때문입니다.
왜 이게 엔지니어링인가
gstack은 하네스를 일종의 software factory로 다룹니다. 작업을 역할과 단계로 쪼개 병렬화 여지를 높이되, 검증과 배포를 후행 ritual이 아니라 명시적 단계로 둡니다.
| 단계 | 엔지니어링 의미 |
|---|---|
| Think | 문제 정의 오류를 초기에 줄임 |
| Plan | 구현 범위와 책임 경계 고정 |
| Build | 실제 변경 수행 |
| Review | 코드/설계 관점의 독립 검토 |
| Test | 실행 상태 검증 |
| Ship | 배포와 문서 반영 |
| Reflect | 다음 루프를 위한 개선 데이터 축적 |
이건 단순 체크리스트가 아니라 생산 파이프라인 설계입니다.
command-driven workflow의 장점
강한 opinion의 하네스는 보통 아래처럼 command surface를 갖습니다. gstack의 실제 command 이름은 더
구체적입니다. /office-hours, /plan-ceo-review, /plan-eng-review, /review, /qa, /ship,
/land-and-deploy, /canary, /benchmark, /document-release, /codex처럼 제품/엔지니어링/QA/릴리즈
단계를 역할별 명령으로 노출합니다.
/think -> 문제 재정의, 리스크 식별
/plan -> 범위와 구현 전략 고정
/build -> 구현 시작
/review -> 설계/보안/코드 리뷰
/test -> 브라우저/회귀 테스트
/ship -> 배포 준비, 릴리즈 노트
/reflect -> 배운 점 기록이 표면이 중요한 이유는 작업자의 머릿속에만 있던 절차를 공통 인터페이스로 끌어내리기 때문입니다.
2026-05-23 기준 README 변화
| 변화 | 하네스 관점의 의미 |
|---|---|
| 23 specialists + 8 power tools | 개인 프롬프트가 아니라 역할별 command catalog로 배포 |
| 10개 AI coding agent host 지원 | Claude Code 전용 팁이 아니라 host adapter를 가진 workflow layer로 이동 |
| Team mode auto-update | 팀 repo에서 version drift 없이 하네스 업데이트를 강제/권장 |
/codex second opinion | 한 모델/한 runtime의 자기확신을 다른 reviewer로 교차 검증 |
/ios-qa, /ios-fix, iOS QA daemon | browser QA를 넘어 실제 device QA도 하네스 surface로 확장 |
| continuous checkpoint mode | 긴 작업의 상태를 WIP commit과 structured context로 복원 가능하게 남김 |
/learn, domain skills | 반복된 선호와 사이트별 지식을 다음 세션의 실행 컨텍스트로 누적 |
review/test/ship를 분리하는 이유
많은 팀이 build까지만 자동화하고 review/test/ship은 사람의 후속 작업으로 남겨둡니다. gstack이 유용한 까닭은 이 구간을 별도 단계로 존중하기 때문입니다.
release_gate:
review:
required: true
test:
required:
- "lint"
- "typecheck"
- "browser smoke"
ship:
requires_release_note: true
requires_owner_ack: true이렇게 분리해야 "구현 완료"와 "출시 가능"이 같은 말이 아니게 됩니다.
병렬 에이전트가 chaos가 되지 않으려면
gstack README가 강조하는 포인트를 엔지니어링 언어로 옮기면 이렇습니다.
- 단계가 먼저 있고, 병렬화는 그 다음입니다.
- 각 단계는 출력 포맷이 있어야 합니다.
- check-in이 필요한 의사결정 포인트가 명시돼야 합니다.
실무 해석
프로세스 없이 풀어둔 에이전트 10명은 혼란의 원천 10개가 됩니다. 프로세스를 입힌 에이전트 10명은 병렬 실행 단위가 됩니다.
우리 팀으로 옮길 것
| 옮길 요소 | 적용 방식 |
|---|---|
| sprint phase 명시 | 시작 전 단계 이름과 종료 조건을 정의 |
| command surface | slash command, bot command, make target으로 공통화 |
| release gate | review/test/ship를 별도 상태로 관리 |
| host adapter | Claude, Codex, Cursor 등 팀이 쓰는 agent runtime별 설치 경로를 분리 |
| live QA surface | 브라우저뿐 아니라 모바일/device/외부 세션까지 검증 대상으로 확장 |
| reflect 루프 | 실패 패턴과 개선 규칙을 다음 하네스 업데이트로 연결 |
그대로 복제하면 안 되는 점
- opinionated flow가 팀 맥락과 다르면 저항이 큽니다.
- 모든 작업을 full sprint로 돌리면 과한 의식이 됩니다.
- command 이름보다 각 단계의
출력 계약이 더 중요합니다. - 최신 README에는 매우 넓은 command catalog가 있으므로, 팀 표준으로 들일 때는 실제로 쓰는 5~8개부터 시작하는 편이 안전합니다.
gstack 사례의 진짜 교훈은 하네스를 실행 가능한 sprint 구조로 만들면 병렬성이 chaos가 아니라 throughput이 된다는 것입니다.
참고
- gstack README, 2026-05-23 열람 기준
- GitHub API 기준
garrytan/gstackpushed_at: 2026-05-22