# gstack 워크플로우 심층 분석 & 적용 방안

> 작성일: 2026-03-23 | 작성자: 아누(직접) | 분석 근거: 3개 에이전트 병렬 심층 조사
> 소스: https://github.com/garrytan/gstack (MIT, Garry Tan/YC CEO)
> 기존 리서치: gstack-analysis.md, gstack-deep-analysis.md, gstack-test-strategy-adoption.md

---

## 핵심 발견: gstack이 우리와 다른 5가지

| 영역 | gstack | 우리 시스템 | 갭 |
|------|--------|-----------|-----|
| **병렬 실행** | Conductor + git worktree (10개 동시) | dispatch.py + cron (순차 위주) | ★★★ |
| **QA** | 실제 Chromium 브라우저 테스트 (100ms/cmd) | 정적 QC (qc_verify.py 7개 verifier) | ★★★ |
| **스프린트 사이클** | Think→Plan→Build→Review→Test→Ship→Reflect 7단계 | 위임→실행→.done→보고 4단계 | ★★ |
| **컨텍스트 전달** | artifact 파일 체인 (자동 발견) | .done + report 파일 (수동 확인) | ★★ |
| **크로스모델 리뷰** | /codex (Claude+OpenAI 교차 검증) | 비너스/아틀라스 (미활용) | ★ |

---

## 1. Conductor 병렬 실행 시스템

### 1.1 gstack의 구현

**핵심**: Conductor.build(macOS 앱) + git worktree로 완전 격리된 병렬 세션

```
Conductor 앱
├─ 워크스페이스 10개 생성 (각각 독립 git worktree)
├─ conductor.json의 setup hook → bin/dev-setup 자동 실행
│  ├─ .env 상속 (API key)
│  ├─ 의존성 설치
│  └─ 로컬 스킬 symlink
├─ 각 워크스페이스에서 Claude Code 세션 독립 실행
└─ archive hook → bin/dev-teardown 정리
```

**설계 특징:**
- `conductor.json`은 단 2줄 (setup/archive hook만)
- 나머지는 git worktree 격리 + 포트 충돌 방지 + 상태 파일 기반 server discovery
- 각 워크스페이스별 독립 Chromium 데몬 (포트 10000-60000 random)
- 30분 idle timeout 후 자동 종료

### 1.2 우리 시스템과의 비교

**우리의 현재 병렬 실행:**
- dispatch.py로 여러 팀 동시 위임 가능
- 각 팀은 cokacdir --cron으로 독립 세션 실행
- **단, git worktree 격리 없음** → 같은 파일 동시 수정 시 충돌 위험
- `git-worktree-isolation` 스킬이 존재하나 실무 적용 미흡

**갭 분석:**
- gstack: 10개 세션이 **동일 repo의 다른 branch**에서 동시 작업 → 충돌 0
- 우리: 같은 워크스페이스에서 팀별 작업 → **파일 충돌 위험** (3-2 규칙으로 수동 관리)

### 1.3 적용 방안

**즉시 적용 (I-1): dispatch.py에 worktree 옵션 추가**
```
dispatch.py --team dev1 --task-file xxx --worktree
→ 자동으로 git worktree 생성 → 팀 세션이 격리된 branch에서 작업
→ 완료 후 main에 merge (또는 PR 생성)
```

**효과:**
- 파일 충돌 위험 원천 제거
- 3-2 규칙(의존성 체크) 불필요해짐
- 진정한 병렬 위임 가능 (10팀 동시 투입도 안전)

**구현 난이도:** Lv.2 (dispatch.py + worktree 스크립트)

---

## 2. QA 브라우저 테스트 시스템

### 2.1 gstack의 구현

**핵심**: Playwright 기반 헤드리스 Chromium 데몬 + ARIA ref 시스템

**3계층 아키텍처:**
```
CLI (Bun 컴파일 바이너리, ~1ms startup)
  ↓ HTTP POST (localhost, 5ms)
Server (Bun.serve, 데몬)
  ↓ CDP (Chrome DevTools Protocol)
Chromium (headless, persistent)
```

**성능: 커맨드당 100-200ms** (per-command 방식 대비 12배 빠름)
- 첫 호출: 3초 (Chromium 시작)
- 이후: 100-200ms (데몬에 HTTP 요청만)
- 20개 명령 세션: 6초 (vs per-command 60초)

**52개 명령어 (3개 Set):**
- READ (15개): text, html, links, forms, accessibility, js, eval, css, console, network, cookies, storage, perf...
- WRITE (25개): goto, click, fill, select, hover, type, press, scroll, wait, viewport, cookie-import...
- META (12개): tabs, screenshot, pdf, responsive, chain, diff, handoff...

**ARIA Ref 시스템 (@e1, @e2...):**
- DOM 변경 없음 (CSP 안전, React/Vue 호환)
- Playwright getByRole() 기반 locator
- Stale ref 자동 감지 (~5ms)

**Cookie Import (인증된 페이지 테스트):**
- macOS Keychain에서 Chrome/Arc/Brave 쿠키 해독
- PBKDF2 + AES-128-CBC 디크립션
- 로그인 상태 유지한 채 QA 가능

### 2.2 우리 시스템과의 비교

**우리의 현재 QA:**
- `qc_verify.py` — 7개 정적 verifier (scope, pyright, style, tdd, file, data_integrity, test_runner)
- `마아트(Ma'at)` — 독립 QC 센터 (코드 레벨 검증)
- **webapp-testing 스킬** — Playwright MCP 기반 (이미 존재!)
- **원격 브라우저** — 제이회장님 윈도우 노트북 (100.116.204.95:9222)

**이미 있는 것:**
- Playwright MCP (`webapp-testing` 스킬)
- 원격 Chrome CDP 연결 (`scripts/browser.py --remote-cdp`)
- QC 자동 검증 파이프라인

**없는 것:**
- 데몬 모델 (매번 새 브라우저 → 느림)
- ARIA ref 시스템 (CSS selector 의존)
- Health Score 정량화 (8개 카테고리 × 가중치)
- 자동 회귀테스트 생성
- Cookie import (인증 페이지 테스트)

### 2.3 적용 방안

**Phase 1 (즉시): Health Score 도입**
- QC 보고서에 0-100 Health Score 추가
- 8개 카테고리: Console(15%), Links(10%), Visual(10%), Functional(20%), UX(15%), Performance(10%), Content(5%), Accessibility(15%)
- qc_verify.py에 health_score verifier 추가

**Phase 2 (1개월): 데몬 기반 브라우저 QA**
- webapp-testing 스킬을 데몬 모드로 전환
- 또는 gstack browse 바이너리 직접 도입 (MIT 라이선스)
- InsuWiki, InsuRo 등 웹 프로젝트에 /qa 워크플로우 적용

**Phase 3 (2개월): 전체 QA 파이프라인**
- /qa 스킬 커스텀 구현 (diff-aware 모드)
- 회귀테스트 자동 생성
- Health Score 트렌드 추적 (/retro 연동)

**구현 난이도:** Phase 1 = Lv.1, Phase 2 = Lv.2, Phase 3 = Lv.3

---

## 3. 스프린트 파이프라인 (7단계)

### 3.1 gstack의 구현

```
[Think] /office-hours → 설계 문서 생성 (YC 강제 질문 6개)
   ↓ artifact: ~/.gstack/projects/$SLUG/{user}-{branch}-design-{datetime}.md
[Plan-1] /plan-ceo-review → CEO 시각 10성급 제품 탐색
   ↓ artifact: ceo-plan-decisions.jsonl
[Plan-2] /plan-design-review → 디자인 0-10점 평가, AI Slop 탐지
   ↓ artifact: design review 통합
[Plan-3] /plan-eng-review → 아키텍처 lock-in, 15가지 인지 패턴
   ↓ artifact: 기술 리뷰, 테스트 레이아웃
[Build] 실제 코딩 (계획 문서가 자동 컨텍스트)
   ↓ 코드 변경
[Review] /review → 2-pass 감사 (Critical + Informational)
   ↓ artifact: review-findings, 자동 수정
[Test] /qa → Chromium 실제 테스트 + 버그 수정 + 회귀테스트
   ↓ artifact: qa-findings, health score
[Ship] /ship → main 동기화 → 테스트 → 커버리지 → VERSION bump → PR
   ↓ artifact: CHANGELOG, PR
[Reflect] /retro → 주간 회고 (커밋 분석, 트렌드, Eureka moment)
```

**핵심: /autoplan** — CEO/Design/Eng review를 자동 순차 실행하는 메타 스킬
- 6개 자동 결정 원칙 적용 (completeness, boil lakes, DRY, explicit, pragmatic, action bias)
- TASTE DECISION만 사용자에게 질문 (나머지 자동)
- Restore point 기능 (실패 시 롤백)

### 3.2 우리 시스템과의 비교

**우리의 현재 파이프라인:**
```
[접수] 제이회장님 지시 → 아누 레벨 판정
[설계] Lv.3+: 에이전트 미팅 → 3문서(계획서/맥락노트/체크리스트)
[위임] dispatch.py → 팀 실행
[검증] .done 감지 → 보고서 확인 → 통합 보고
```

**매핑 비교:**

| gstack 단계 | 우리 시스템 | 대응 수준 |
|------------|-----------|---------|
| /office-hours | 에이전트 미팅 (Lv.3+) | ★★☆ (Q1-Q6 강제 질문 부재) |
| /plan-ceo-review | 3문서 중 계획서 | ★★☆ (10성급 발견 모드 부재) |
| /plan-design-review | 아테나/미미르 UX 검토 | ★☆☆ (AI Slop 탐지 부재) |
| /plan-eng-review | 헤르메스/오딘 설계 | ★★★ (이미 강력) |
| /review | qc_verify.py + 마아트 | ★★☆ (2-pass 감사 부재) |
| /qa | webapp-testing 스킬 | ★☆☆ (데몬/Health Score 부재) |
| /ship | git push (수동) | ★☆☆ (자동 PR/CHANGELOG 부재) |
| /retro | 크로노스(회고분석 센터) | ★★☆ (트렌드 추적 부재) |

### 3.3 적용 방안

**A. 즉시 도입 — 킥오프 강제 질문 (office-hours 패턴)**

현재 `project-kickoff` 스킬에 gstack의 6가지 강제 질문 통합:
```
Q1: Demand Reality — 실제 누가 원하는가? (가설이 아닌 증거)
Q2: Status Quo — 현재 workaround은? (없으면 수요 의심)
Q3: Desperate Specificity — 가장 절박한 구체적 인물은?
Q4: Narrowest Wedge — 최소 viable 버전은?
Q5: Observation & Surprise — watch & learn에서 놀라운 발견?
Q6: Future-Fit — 3년 뒤에도 필수인가?
```

**B. 중기 도입 — 2-Pass Review 패턴**

qc_verify.py에 2-pass 감사 추가:
```
Pass 1 (CRITICAL, 자동 블록):
  - SQL & Data Safety
  - Race Conditions
  - LLM Output Trust Boundary
  - Enum/Value Completeness

Pass 2 (INFORMATIONAL, 경고만):
  - Conditional Side Effects
  - Magic Numbers
  - Dead Code
  - Test Gaps
  - Performance
```

**C. 장기 도입 — /ship 자동화**

배포 워크플로우 스킬 생성:
```
/ship → main 동기화 → 전체 테스트 → 커버리지 감사 → VERSION bump → CHANGELOG → git push → PR 생성
```

---

## 4. 컨텍스트 자동 전달 메커니즘

### 4.1 gstack의 구현

**핵심 원리: "세션은 죽을 수 있지만, 파일은 영원하다"**

```
~/.gstack/projects/$SLUG/
├── {user}-{branch}-design-{datetime}.md        ← 설계 문서 (ls -t로 최신 자동 발견)
├── $BRANCH-reviews.jsonl                       ← review 결정 히스토리
├── $BRANCH-ceo-plan-decisions.jsonl            ← CEO 리뷰 결정 로그
└── ceo-plans/                                  ← 확장 가능성 보관
```

**자동 발견 패턴:**
```bash
# 모든 plan 스킬이 공통으로 실행:
SLUG=$(gstack-slug)
BRANCH=$(git rev-parse --abbrev-ref HEAD | tr '/' '-')
DESIGN=$(ls -t ~/.gstack/projects/$SLUG/*-$BRANCH-design-*.md | head -1)
[ -n "$DESIGN" ] && cat "$DESIGN"  # 최신 설계 문서 자동 로드
```

**Review Readiness Dashboard:**
```
✓ CEO Review: DONE
✓ Eng Review: CLEAR
✗ Design Review: MISSING ← frontend 변경인데 디자인 리뷰 안 했음
```

### 4.2 우리 시스템 대응

**이미 있는 것:**
- `.done 프로토콜` — 완료 감지 (gstack의 artifact 발견과 유사)
- `memory/reports/{task_id}.md` — 산출물 경로 표준화
- `memory/tasks/dispatch-*.md` — 위임 지시서 (gstack의 design doc과 유사)
- `task-timers.json` — 작업 히스토리 (gstack의 JSONL과 유사)

**없는 것:**
- **자동 최신 문서 발견** (ls -t 패턴) — 현재 아누가 수동으로 경로 지정
- **Review Readiness Dashboard** — 어떤 검토가 완료/미완료인지 한눈에
- **JSONL 결정 히스토리** — 각 단계의 판단 근거 추적

### 4.3 적용 방안

**즉시 적용: 대시보드에 Review Readiness 추가**
```
프로젝트뷰에서 각 task의 진행 상태:
✓ 위임 완료 (dispatch-*.md 존재)
✓ 팀 실행 중 (timer active)
✓ 완료 보고 (.done 존재)
✗ QC 검증 (미실행)
✗ 통합 테스트 (미실행)
```

---

## 5. 크로스모델 리뷰 (/codex)

### 5.1 gstack의 구현

```
/codex → OpenAI Codex CLI 호출 → 독립 코드 리뷰
3가지 모드:
  1. Review: 통과/불합격 게이트 (P1 = FAIL)
  2. Challenge: 적대적 모드 (코드를 깨뜨리려는 시도)
  3. Consult: 자유 상담

교차 분석:
  /review (Claude) + /codex (OpenAI) 결과 비교
  → Both found / Only Codex / Only Claude / Agreement rate
```

### 5.2 우리 시스템 대응

**이미 있는 것:**
- 비너스(Venus) — Gemini 엔진 세컨드 오피니언
- 아틀라스(Atlas) — GPT 엔진 세컨드 오피니언
- 3대 엔진 합의도출 파이프라인 (출판팀에서 사용)

**차이점:**
- gstack: 코드 리뷰에 크로스모델 적용 (실용적, 즉각적)
- 우리: 출판(집필)에만 적용 (범위 제한)

### 5.3 적용 방안

**코드 리뷰에 크로스모델 적용:**
- critical/security 레벨 작업 완료 시 → 비너스 or 아틀라스에 독립 리뷰 요청
- 두 엔진의 발견 사항 교차 분석
- Agreement rate 보고

---

## 6. ETHOS 철학 — 우리 시스템에 흡수할 원칙

### 6.1 "Boil the Lake" (완성도 극대화)

> AI 시대에는 완성 비용이 거의 0. 지름길 대비 +10% 시간 = -90% quality debt

**적용:**
- 테스트 커버리지 "대충 80%"가 아니라 100% 목표
- Edge case "나중에 처리"가 아니라 즉시 처리
- Option A(완전, 150 LOC) vs Option B(90%, 80 LOC) → **무조건 A**

**현재 우리의 약점:** Fantasy Approval ("모든 것이 완벽합니다") — 이미 QC-RULES에서 금지했지만, "Boil the Lake" 철학으로 더 강화 가능

### 6.2 "Search Before Building" (3 Layer 지식)

```
Layer 1: Tried and True (표준 패턴) — 자명한 것도 질문
Layer 2: New and Popular (최신 트렌드) — mania에 빠지지 말 것
Layer 3: First Principles (원점 추론) — 기존 방식이 틀렸는지 확인

★ Eureka Moment: Layer 1+2 이해 후 Layer 3에서 "이 맥락에서 기존 패턴이 틀렸다" 발견
```

**적용:**
- 에이전트 미팅에 Layer 3 원점 추론 단계 추가
- Eureka Moment 발견 시 명명 + 기록
- 로키(레드팀) DA 역할에 "Layer 3 공격" 추가 (기존 가정 뒤집기)

### 6.3 "15가지 인지 패턴" (엔지니어링 리더십)

gstack의 /plan-eng-review에 있는 실무 패턴:
```
1. State Diagnosis — 지금 떨어지는 중? 정체? 빚 갚는 중? 혁신?
2. Blast Radius Instinct — 최악 시나리오는?
3. Boring by Default — 혁신 토큰 3개만 사용
4. Incremental > Revolutionary — Strangler fig pattern
5. Systems over Heroes — 3am에도 작동하는가?
```

**적용:** 아누의 레벨 판정 시 "State Diagnosis" + "Blast Radius" 추가 검토

---

## 7. 종합 적용 로드맵

### Phase 1 — 즉시 적용 (비용 $0, 문서/설정 수정만)

| 항목 | 내용 | 파일 | 난이도 |
|------|------|------|--------|
| I-1 | 킥오프 강제 질문 6개 (`project-kickoff` 스킬 보강) | skills/project-kickoff/SKILL.md | Lv.1 |
| I-2 | "Boil the Lake" 원칙을 QC-RULES에 추가 | teams/shared/QC-RULES.md | Lv.0 |
| I-3 | 에이전트 미팅에 Layer 3 원점추론 + Eureka Moment 추적 | memory/specs/anu-guide.md | Lv.0 |
| I-4 | /retro 주간 회고 스킬 생성 (크로노스 센터 활용) | skills/retro/ | Lv.1 |

### Phase 2 — 1개월 내 적용 (코드 수정 필요)

| 항목 | 내용 | 파일 | 난이도 |
|------|------|------|--------|
| A-1 | dispatch.py --worktree 옵션 (git worktree 격리) | dispatch.py | Lv.2 |
| A-2 | QC에 2-pass 감사 추가 (Critical + Informational) | qc_verify.py | Lv.2 |
| A-3 | Health Score verifier (8카테고리 × 가중치) | qc_verify.py | Lv.1 |
| A-4 | 대시보드 Review Readiness 표시 | dashboard/index.html | Lv.1 |

### Phase 3 — 2-3개월 내 적용 (신규 시스템)

| 항목 | 내용 | 파일 | 난이도 |
|------|------|------|--------|
| B-1 | 데몬 기반 브라우저 QA (gstack browse 포팅 또는 자체 구현) | services/browse/ | Lv.3 |
| B-2 | /ship 자동 배포 스킬 (테스트→커버리지→PR→CHANGELOG) | skills/ship/ | Lv.2 |
| B-3 | 크로스모델 코드 리뷰 (비너스/아틀라스 활용) | dispatch.py 확장 | Lv.2 |
| B-4 | JSONL 결정 히스토리 (각 단계 판단 근거 자동 기록) | memory/events/ | Lv.2 |

---

## 8. 핵심 인사이트 요약

### 8.1 gstack에서 배울 것 (우리에게 없는 것)

1. **Conductor 병렬화**: git worktree로 완전 격리 → 파일 충돌 원천 제거
2. **데몬 기반 QA**: 100ms/cmd, 인증된 페이지 테스트, Health Score 정량화
3. **artifact 체인**: 스킬 간 파일 기반 자동 연결 (ls -t 최신 자동 발견)
4. **자동 결정 원칙**: 6개 원칙으로 판단, TASTE DECISION만 사용자에게
5. **Eureka Moment 추적**: 기존 가정을 뒤집는 발견을 명명하고 기록

### 8.2 우리가 이미 강한 것 (gstack에 없는 것)

1. **다중 팀 오케스트레이션**: 15명+ 가상 엔지니어링 팀 (gstack은 1인 체제)
2. **레벨 시스템**: Lv.0~4 판정 → 적절한 리소스 배분 (gstack은 모든 작업 동일 취급)
3. **에이전트 미팅**: 다양한 관점(백엔드/UX/QA/레드팀) 합의 (gstack은 순차 1인 리뷰)
4. **보안팀(로키)**: 전담 레드팀 DA (gstack은 /codex 크로스모델만)
5. **작업 기록 시스템**: task-timer + audit-trail (gstack은 analytics만)

### 8.3 가장 임팩트 높은 3가지 (우선 추천)

```
1순위: dispatch.py --worktree (병렬 위임 안전성 ★★★)
2순위: 데몬 기반 브라우저 QA (웹 프로젝트 품질 ★★★)
3순위: 킥오프 강제 질문 6개 (기획 품질 ★★★, 비용 $0)
```

---

## 참고 파일

- gstack 클론: `/tmp/gstack/` (이미 클론 완료)
- 기존 분석 1: `/home/jay/workspace/memory/research/gstack-analysis.md`
- 기존 분석 2: `/home/jay/workspace/memory/research/gstack-deep-analysis.md`
- 기존 분석 3: `/home/jay/workspace/memory/research/gstack-test-strategy-adoption.md`
- conductor.json: `/tmp/gstack/conductor.json`
- browse 소스: `/tmp/gstack/browse/src/`
- 스킬 템플릿: `/tmp/gstack/*/SKILL.md.tmpl`