# gstack 심층분석 + 도입 가능성 평가

> 작성: 헤르메스 (dev1 팀장) | 분석일: 2026-03-15
> 분석 참여: 불칸(소스코드), 이리스(커뮤니티)
> 레포: https://github.com/garrytan/gstack (v0.3.5, MIT)

---

## 1. 프로젝트 개요

### 1-1. 무엇을 하는 프로젝트인가

gstack은 Y Combinator 사장 Garry Tan이 만든 Claude Code 워크플로우 스킬셋이다.
**핵심 아이디어**: Claude Code를 하나의 범용 어시스턴트가 아닌, 역할별 전문가(CEO, 엔지니어링 매니저, 스태프 엔지니어, 릴리즈 엔지니어, QA 엔지니어)로 모드 전환하여 사용.

8개 슬래시 커맨드로 구성:
- `/plan-ceo-review` — 창업자/CEO 시각 제품 검토 (10-star 제품 탐색)
- `/plan-eng-review` — 엔지니어링 매니저 시각 기술 설계 검토
- `/review` — 스태프 엔지니어 시각 코드 리뷰 (CI가 못 잡는 버그 탐지)
- `/ship` — 릴리즈 엔지니어 자동 배포 (테스트→리뷰→버전→PR 원스톱)
- `/browse` — QA용 헤드리스 Chromium 브라우저 (~100ms/명령)
- `/qa` — 체계적 QA 테스트 (diff-aware, 헬스 스코어, 회귀 비교)
- `/setup-browser-cookies` — 실제 브라우저 쿠키를 헤드리스 세션으로 임포트
- `/retro` — 주간 엔지니어링 회고 (커밋 분석, 팀원 피드백, 트렌드 추적)

### 1-2. 시장 반응 (출시 4일 기준)

- GitHub: Star 9,201 / Fork 1,104 / Issues 32
- Product Hunt: 155 upvotes
- LinkedIn: 4,549 좋아요, 213 댓글
- CTO 반응 바이럴: "god mode — eng review가 팀도 모르던 XSS 발견"
- 회의론: "단순 프롬프트 패키징", "볼륨 지표가 품질 가릴 수 있음"

### 1-3. 아키텍처

```
사용자 → Claude Code → /slash-command → SKILL.md 로드 → 역할별 프롬프트 실행
                                                         ↕
                                                    browse 바이너리
                                                    (Bun+Playwright)
                                                         ↕
                                                    Chromium 데몬
                                                    (HTTP, Bearer token)
```

**2계층 구조**:
- **Layer 1 (프롬프트)**: 8개 SKILL.md — 역할별 persona, 체크리스트, 강제 출력 포맷
- **Layer 2 (바이너리)**: browse/ 디렉토리 — Bun 컴파일 바이너리(~58MB), Playwright Chromium 데몬

### 1-4. 핵심 기술 스택

- **런타임**: Bun v1.0+ (TypeScript 네이티브, bun:sqlite 내장, 단일 바이너리 컴파일)
- **브라우저**: Playwright + Chromium (헤드리스 데몬, 랜덤 포트, Bearer UUID 인증)
- **상태 관리**: .gstack/browse.json (PID/포트/토큰, atomic write)
- **스킬 생성**: SKILL.md.tmpl → gen-skill-docs.ts → SKILL.md (코드 동기화)
- **외부 연동**: Greptile (AI PR 리뷰), Conductor.build (병렬 세션)

---

## 2. 모든 기능/컴포넌트 상세 분석

### 2-1. 프롬프트 엔지니어링 패턴 (8개 스킬)

#### `/plan-ceo-review` — 가장 정교한 프롬프트

- **3-mode persona**: EXPANSION(대성당) / HOLD(검토자) / REDUCTION(외과의사) — 선택 후 드리프팅 금지
- **8가지 Prime Directives**: 침묵 실패 금지, 에러 명명, 그림자 경로, 상호작용 엣지케이스, 다이어그램 필수 등
- **Temporal Interrogation**: 구현 시간대별(1h, 2-3h, 4-5h, 6h+) 결정사항 선제 해결
- **Dream State Mapping**: CURRENT → THIS PLAN → 12-MONTH IDEAL 3단계 강제
- **CRITICAL GAP 자동 마킹**: RESCUED=N + TEST=N + SILENT 조합 감지
- **Context pressure hierarchy**: 컨텍스트 부족 시 우선순위 순서 명시

#### `/plan-eng-review` — 실행 가능한 계획으로 전환

- **SMALL/BIG CHANGE 모드**: 변경 규모별 리뷰 깊이 자동 조정
- **"lobby하지 마라" 언어**: 사용자의 스코프 결정을 존중하도록 LLM 순응성 통제
- **Retrospective learning**: git log로 이전 리뷰 사이클 문제 영역 자동 감지
- **4개 섹션**: 아키텍처, 코드품질, 테스트, 성능 (CEO 리뷰의 10개 대비 집중)

#### `/review` — 2-pass 구조적 감사

- **Pass 1 (CRITICAL)**: SQL 안전성, 레이스 컨디션, LLM 신뢰 경계 위반
- **Pass 2 (INFORMATIONAL)**: 매직 넘버, 데드 코드, 타입 변환, 뷰 성능
- **Suppression 목록**: 가독성 중복, rot 위험 코멘트, 이미 수정된 항목 → DO NOT flag
- **Greptile 통합**: PR 코멘트 자동 분류 (VALID/ALREADY FIXED/FP/SUPPRESSED)

#### `/ship` — 완전 자동화 배포

- **Non-interactive by default**: 확인 요청 없이 직진 (MINOR/MAJOR + CRITICAL만 중단)
- **8-step 파이프라인**: pre-flight → merge main → test → eval → review → Greptile → version bump → CHANGELOG → commit → push → PR
- **4-digit version**: MAJOR.MINOR.PATCH.MICRO — 변경 규모 자동 판정
- **Bisectable commits**: 1 logical unit = 1 commit, 마이그레이션 별도
- **Re-test 강제**: Greptile 수정 후 테스트 재실행

#### `/browse` — 헤드리스 브라우저 엔진

- **@ref 시스템**: ARIA 트리 기반 요소 참조 (DOM mutation 없음 → CSP/framework 충돌 회피)
- **snapshot -D**: 이전 스냅샷과 unified diff
- **snapshot -a**: 빨간 박스 + 레이블 오버레이 스크린샷 (버그 증거)
- **snapshot -C**: cursor:pointer/onclick 비표준 요소 감지
- **데몬 아키텍처**: cold start 3s, 이후 100-200ms, 30분 idle 자동 종료

#### `/qa` — 체계적 QA

- **4가지 모드**: diff-aware(기본) / full / quick(30초) / regression(baseline 비교)
- **diff-aware**: git diff로 변경 파일 → 영향 라우트 자동 파악 → 해당 페이지만 테스트
- **Health Score 0-100**: Console(15%), Links(10%), Visual(10%), Functional(20%), UX(15%), Performance(10%), Content(5%), Accessibility(15%)
- **issue-taxonomy.md**: 4단계 심각도 × 7개 카테고리 표준 분류 체계
- **baseline.json**: 회귀 비교용 스냅샷, 수정된/새로운 이슈 추적

#### `/retro` — 회고 + 트렌드

- **14-step 분석**: Raw data → 메트릭 → 시간분포 → 세션감지 → 커밋분류 → 핫스팟 → PR크기 → 포커스스코어 → 팀원 → 트렌드 → 스트릭 → 히스토리 비교 → 저장 → 내러티브
- **세션 감지**: 45분 갭 기준, Deep/Medium/Micro 분류
- **AI 협업 추적**: Co-Authored-By: Claude 트레일러 파싱
- **Greptile signal ratio**: fix+already-fixed / 전체 비율로 코드리뷰 봇 품질 추적
- **JSON 스냅샷**: .context/retros/*.json에 저장, 주간 트렌드 비교

#### `/setup-browser-cookies` — 쿠키 임포트

- macOS Keychain + PBKDF2 + AES-128-CBC로 Chromium 쿠키 복호화
- 지원: Comet, Chrome, Arc, Brave, Edge (macOS 전용)
- 인터랙티브 UI 또는 도메인 직접 지정

### 2-2. 코드 아키텍처 (browse/)

**클라이언트-서버 분리**:
- cli.ts → HTTP POST → server.ts(Bun.serve) → BrowserManager → Playwright → Chromium
- 랜덤 포트(10000-60000), Bearer UUID 토큰, .gstack/browse.json 상태파일(mode 0o600)

**명령어 분류**: READ(사이드이펙트 없음) / WRITE(상태 변경) / META(서버 운영)
- commands.ts가 단일 소스 오브 트루스, load-time 검증

**에러 처리**: wrapError()로 Playwright 내부 오류 → AI 에이전트 친화적 메시지 변환
- Chromium 크래시 → 즉시 exit(1), 자가복구 없음 (CLI가 재시작 감지)

**버퍼**: CircularBuffer 50K×3, O(1) push, 1초 비동기 디스크 flush

### 2-3. 빌드/테스트 시스템

**SKILL.md 템플릿**: .tmpl → gen-skill-docs.ts → .md (commands.ts 메타데이터 주입)
- CI에서 --dry-run + git diff로 freshness 검증

**3-tier 테스트**:
- Tier 1: 정적 명령어 검증 (무료, <2s, bun test에 항상 포함)
- Tier 2: Agent SDK E2E (~$0.50/run, SKILL_E2E=1 게이팅)
- Tier 3: LLM-as-judge 평가 (~$0.03/run, ANTHROPIC_API_KEY 필요)

**업데이트 체크**: gstack-update-check 스크립트, 24h 캐시, 모든 스킬에서 첫 실행 시 호출

---

## 3. 우리 시스템과의 비교

### 3-1. 시스템 개요 비교

| 차원 | gstack | 우리 시스템 (아누 체계) |
|------|--------|----------------------|
| **아키텍처** | 1인 개발자 워크플로우 (단일 Claude Code 세션 내 모드 전환) | 멀티봇 오케스트레이터 (아누→3개 팀장→팀원 서브에이전트) |
| **역할 분리** | 프롬프트 레벨 (SKILL.md로 persona 전환) | 봇 레벨 (별도 Claude Code 인스턴스) + 에이전트 레벨 (Task tool 서브에이전트) |
| **기획** | /plan-ceo-review + /plan-eng-review (인터랙티브, 1세션) | Agent 미팅(최대 6사이클) → 3문서(계획서/맥락노트/체크리스트) → 핵미사일 승인 |
| **코드 리뷰** | /review (2-pass 체크리스트 + Greptile) | 마아트 QC센터 (독립 검증) + qc_verify.py 자동 검증 |
| **배포** | /ship (1명이 직접, 완전 자동) | 팀장 → worktree → 보고서 → 아누 검토 → 머지 판단 |
| **QA** | /browse + /qa (Playwright 브라우저 자동화) | 아르고스(테스터) 서브에이전트 + webapp-testing 스킬 |
| **회고** | /retro (커밋 기반 메트릭 + 트렌드) | 없음 (수동 보고서만) |
| **상태 관리** | 세션 내 대화 컨텍스트 | 파일 기반 (MEMORY.md, task-timers.json, .done 이벤트, daily 로그) |
| **품질 통제** | Greptile + /review 체크리스트 | 3-level QC (normal/critical/security), Agency-Agents 패턴, Fantasy Approval 방지 |
| **병렬화** | Conductor.build (외부 Mac 앱) | dispatch.py + cokacdir (Telegram 기반 멀티봇) |

### 3-2. 상대적 강점/약점

**gstack이 우리보다 나은 점**:
1. **브라우저 자동화**: 네이티브 Playwright 데몬 + @ref 시스템 — 우리의 webapp-testing보다 훨씬 정교
2. **diff-aware QA**: git diff → 영향 라우트 자동 파악 → 해당 페이지만 테스트 — 우리는 수동 지정
3. **프롬프트 기법의 깊이**: 3-mode persona, Temporal Interrogation, CRITICAL GAP 자동 마킹 등
4. **배포 자동화**: 1명이 /ship 한 번으로 테스트→리뷰→버전→PR — 우리는 다단계 수동 프로세스
5. **회고 시스템**: 커밋 데이터 기반 정량적 회고 + 트렌드 추적 — 우리는 아예 없음
6. **코드-문서 동기화**: SKILL.md.tmpl 시스템으로 코드와 AI 지시를 자동 동기화
7. **3-tier 테스트**: 특히 Tier 3 LLM-as-judge로 프롬프트 품질 자체를 테스트
8. **Greptile 연동**: AI 코드리뷰 봇 결과를 자동 분류/처리하는 2-layer 리뷰

**우리가 gstack보다 나은 점**:
1. **멀티봇 병렬화**: 독립 봇 인스턴스로 진정한 병렬 작업 (gstack은 Conductor 외부 의존)
2. **기획 깊이**: Agent 미팅 6사이클 + 핵미사일 승인 — gstack은 1세션 인터랙티브
3. **상태 영속성**: 파일 기반 상태 관리로 세션 간 연속성 보장 — gstack은 세션 내 컨텍스트만
4. **품질 통제 체계**: 3-level QC + 교차 검증 + Fantasy Approval 방지 — gstack은 Greptile 의존
5. **조직 구조**: 수직(3개 팀) + 횡단(QC/보안/디자인/DevOps) — gstack은 1인 워크플로우
6. **작업 추적**: task-timer + done-watcher + daily 로그 — gstack은 .context/retros만
7. **보안**: 로키 레드팀 독립 운영 — gstack은 /review 체크리스트에 보안 항목 포함 수준

---

## 4. 도입 가능한 모든 항목

### A1. diff-aware QA 테스트

- **현재 한계**: QA 테스트 시 테스트 대상 페이지를 수동 지정하거나 전체 테스트
- **gstack 방식**: `git diff main...HEAD --name-only` → 변경 파일에서 영향받는 라우트/페이지 자동 추론 → 해당 페이지만 테스트
- **도입 시 효과**: QA 시간 50-70% 절감, 누락 방지 (코드 변경↔테스트 대상 자동 매핑)
- **난이도**: ★★☆☆☆ (중하) — diff 파싱 + 라우트 매핑 로직 구현. 프로젝트별 라우트 규칙 정의 필요

### A2. Health Score 정량화 시스템

- **현재 한계**: QA 결과가 "통과/실패" 이진 판단 또는 서술형
- **gstack 방식**: 7개 카테고리 가중평균으로 0-100 헬스 스코어 산출 (Console 15%, Functional 20%, Accessibility 15% 등)
- **도입 시 효과**: QA 결과의 객관적 비교 가능, 시간별 트렌드 추적, "이번 릴리즈는 72점" 식의 정량 보고
- **난이도**: ★★☆☆☆ (중하) — 가중치 정의 + 점수화 로직. qc_verify.py에 통합 가능

### A3. 주간 회고 시스템 (/retro)

- **현재 한계**: 정량적 회고 시스템 부재. task-timer 데이터는 있으나 분석/시각화 없음
- **gstack 방식**: 커밋 분석 + 세션 감지(45분 갭) + 커밋 타입 분류 + 핫스팟 + 팀원별 분석 + JSON 스냅샷 트렌드
- **도입 시 효과**: 팀별 생산성 추적, 코드 품질 트렌드, 작업 패턴 파악 (야간/주말 집중 등)
- **난이도**: ★★★☆☆ (중) — task-timer + git log 데이터 결합, JSON 스냅샷 스키마 설계, 트렌드 비교 로직

### A4. CRITICAL GAP 자동 마킹

- **현재 한계**: 셀프 QC가 수동 체크리스트 기반. "침묵 실패" 패턴을 자동 감지하지 못함
- **gstack 방식**: 메서드별 RESCUED=Y/N, TEST=Y/N, USER_SEES=message/silent 매트릭스 → RESCUED=N + TEST=N + SILENT 조합 = CRITICAL GAP 자동 마킹
- **도입 시 효과**: 에러 처리 누락 자동 탐지, 코드 리뷰 품질 향상
- **난이도**: ★★★☆☆ (중) — qc_verify.py에 새 verifier 추가, AST 파싱 또는 패턴 매칭 필요

### A5. Temporal Interrogation (시간대별 결정사항 선제 해결)

- **현재 한계**: 3문서(계획서)가 정적. 구현 중 만날 결정사항을 시간 순서로 예측하지 않음
- **gstack 방식**: "HOUR 1에 무슨 결정이 필요한가? HOUR 2-3은? HOUR 4-5는?" 강제 질문
- **도입 시 효과**: 계획→구현 핸드오프 갭 제거, 구현 중 블로킹 감소
- **난이도**: ★☆☆☆☆ (하) — Agent 미팅 프롬프트에 Temporal Interrogation 섹션 추가

### A6. 프롬프트 품질 테스트 (LLM-as-judge)

- **현재 한계**: 스킬(SKILL.md) 품질을 검증하는 자동화된 방법 없음
- **gstack 방식**: Tier 3 LLM-as-judge — Haiku가 문서 명확성/완성도/실행가능성을 점수화
- **도입 시 효과**: 41개 스킬의 품질을 정량적으로 관리, 스킬 업데이트 시 회귀 방지
- **난이도**: ★★★☆☆ (중) — Anthropic SDK 연동, 평가 기준 정의, CI 통합

### A7. SKILL.md 템플릿 자동 생성

- **현재 한계**: 스킬 문서와 코드가 독립적으로 관리되어 동기화 문제 가능
- **gstack 방식**: .tmpl + gen-skill-docs.ts → 코드 메타데이터에서 SKILL.md 자동 생성. CI에서 freshness 검증
- **도입 시 효과**: 코드 변경 시 스킬 문서 자동 업데이트, 코드↔문서 불일치 방지
- **난이도**: ★★☆☆☆ (중하) — 템플릿 시스템 구축, 기존 41개 스킬 마이그레이션은 점진적

### A8. 이슈 분류 표준 체계 (issue-taxonomy)

- **현재 한계**: QA 이슈 보고가 비표준화. 팀별로 다른 형식
- **gstack 방식**: 4단계 심각도(critical/high/medium/low) × 7카테고리(Visual/Functional/UX/Content/Performance/Console/Accessibility) + 페이지별 탐색 체크리스트
- **도입 시 효과**: QA 보고서 일관성, 이슈 우선순위 자동화, 팀 간 커뮤니케이션 효율
- **난이도**: ★☆☆☆☆ (하) — 문서/스키마 정의만으로 도입 가능

### A9. Greptile 유사 AI 코드리뷰 통합

- **현재 한계**: 코드 리뷰가 마아트 수동 검증 또는 qc_verify.py 자동 검증 (정적 체크 위주)
- **gstack 방식**: Greptile이 전체 코드베이스 컨텍스트로 PR 리뷰 → /review와 /ship이 결과 자동 분류 (VALID/FP/ALREADY FIXED) → 히스토리 학습
- **도입 시 효과**: 코드 리뷰 범위 확대 (레이스 컨디션, 보안 이슈 등 정적 분석 불가 영역)
- **난이도**: ★★★★☆ (중상) — Greptile 유료 서비스 도입 또는 유사 기능 자체 구현 필요. 비용 발생

### A10. Context Pressure Hierarchy (컨텍스트 압박 시 우선순위)

- **현재 한계**: 컨텍스트 윈도우 부족 시 어떤 정보를 우선할지 명시적 규칙 없음
- **gstack 방식**: Step 0 > 시스템 감사 > 에러맵 > 테스트 다이어그램 순으로 우선순위 명시
- **도입 시 효과**: 긴 작업에서 컨텍스트 윈도우 부족 시 핵심 정보 보존 보장
- **난이도**: ★☆☆☆☆ (하) — 워크플로우 프롬프트에 우선순위 계층 추가

### A11. Persona Commitment + Anti-Drift 규칙

- **현재 한계**: Agent 미팅에서 페르소나 드리프팅 가능 (CEO 시각이 엔지니어링으로 흐름)
- **gstack 방식**: "Once the user selects a mode, COMMIT to it. Do not silently drift." 명시적 금지
- **도입 시 효과**: Agent 미팅 품질 향상, 각 페르소나가 자기 역할에 집중
- **난이도**: ★☆☆☆☆ (하) — agent-meeting 스킬 프롬프트에 anti-drift 규칙 추가

### A12. Suppression 목록 (노이즈 감소)

- **현재 한계**: QC에서 불필요한 경고가 누적되어 중요한 이슈가 묻힘
- **gstack 방식**: "DO NOT flag" 명시적 제외 목록 — 가독성 중복, 이미 수정된 항목, rot 위험 코멘트
- **도입 시 효과**: QC 신호 대 잡음 비율 개선, 중요한 이슈에 집중
- **난이도**: ★☆☆☆☆ (하) — qc_verify.py 또는 스킬에 suppression 패턴 추가

### A13. 회귀 비교 시스템 (baseline.json)

- **현재 한계**: QA 결과를 이전 결과와 비교하는 체계 없음
- **gstack 방식**: baseline.json에 이전 QA 결과 저장 → 다음 실행에서 헬스스코어 델타, 수정된/새로운 이슈 추적
- **도입 시 효과**: 릴리즈별 품질 추이 파악, 회귀 자동 감지
- **난이도**: ★★☆☆☆ (중하) — JSON 스키마 정의 + 비교 로직

### A14. Dream State Mapping (3단계 로드맵)

- **현재 한계**: 계획서가 "지금 할 것"에 집중. 장기 비전과의 연결이 약함
- **gstack 방식**: CURRENT STATE → THIS PLAN → 12-MONTH IDEAL 3단계 매핑 강제
- **도입 시 효과**: 단기 구현이 장기 비전과 정합하는지 검증, 전략적 의사결정 품질 향상
- **난이도**: ★☆☆☆☆ (하) — 3문서 작성 프로세스에 Dream State 섹션 추가

### A15. 에러 메시지 AI 에이전트 최적화

- **현재 한계**: 도구의 에러 메시지가 인간 대상. 서브에이전트가 에러를 보고 다음 행동 판단 어려움
- **gstack 방식**: wrapError()로 "Element not found" → "Element not found or not interactable. Run `snapshot -i` to see available elements." 변환
- **도입 시 효과**: 서브에이전트의 에러 자동 복구 능력 향상, 실패 → 재시도 사이클 단축
- **난이도**: ★★☆☆☆ (중하) — 기존 도구/스크립트의 에러 메시지를 AI-actionable 형식으로 개선

### A16. 브라우저 자동화 @ref 시스템

- **현재 한계**: webapp-testing 스킬이 기본적인 Playwright 사용. @ref 기반 요소 참조 없음
- **gstack 방식**: ARIA 트리 → @e1, @e2... 참조 → Playwright Locator 자동 빌드 (DOM mutation 없음)
- **도입 시 효과**: 브라우저 테스트 안정성 향상, CSP/framework 충돌 방지, 테스트 코드 가독성
- **난이도**: ★★★★☆ (중상) — snapshot.ts 수준의 구현 필요, 또는 gstack browse 바이너리 직접 활용

### A17. fix_pct 경고 시그널

- **현재 한계**: 코드 품질 지표가 없어 "ship-fast-fix-fast" 패턴 감지 불가
- **gstack 방식**: retro에서 fix 비율 > 50%이면 "리뷰 갭 신호"로 경고
- **도입 시 효과**: 팀별 코드 품질 트렌드 모니터링, 문제 조기 감지
- **난이도**: ★★☆☆☆ (중하) — 커밋 메시지 파싱 + 비율 계산 (retro 시스템의 일부)

---

## 5. 도입 불필요/비적합 항목

### X1. /ship 완전 자동 배포

- **비적합 이유**: 우리 시스템은 멀티봇 환경으로 팀장→아누→제이회장님 승인 체계. 1인이 /ship으로 직접 배포하는 모델과 맞지 않음. 우리의 worktree → 보고서 → 머지 판단 프로세스가 더 안전함.
- **대안**: /ship의 부분 요소(bisectable commits, 자동 CHANGELOG)는 A항목으로 별도 도입 가능

### X2. /setup-browser-cookies (macOS 전용)

- **비적합 이유**: 우리 환경은 Linux 서버. macOS Keychain 기반 쿠키 복호화는 사용 불가.
- **대안**: 필요 시 Linux용 쿠키 복호화(GNOME Keyring/kwallet) 자체 구현. 현재 우선순위 낮음

### X3. Conductor.build 연동

- **비적합 이유**: 우리는 이미 dispatch.py + cokacdir로 멀티봇 병렬화를 구현함. Conductor는 Mac 앱으로 Claude Code GUI 사용자 대상. 우리의 Telegram 기반 워크플로우와 맞지 않음.
- **현재 수준**: 우리 시스템이 이미 동등하거나 더 나은 병렬화 제공

### X4. Greptile 유료 서비스 직접 도입 (현 시점)

- **비적합 이유**: 현재 프로젝트 규모(InsuWiki 1개)에서는 비용 대비 효과 부족. 마아트 QC + qc_verify.py로 충분.
- **대안**: 프로젝트 확대 시 재검토. A9에서 유사 기능 자체 구현 검토

### X5. 4-digit 버전 시스템

- **비적합 이유**: 우리 프로젝트들이 SemVer 3자리(MAJOR.MINOR.PATCH)로 충분. MICRO 자릿수는 과도.
- **현재 수준**: 기존 버전 체계 유지

### X6. Pacific Time 강제

- **비적합 이유**: 한국(KST) 기반 운영. 시간대 변환 불필요.

### X7. Tweetable summary

- **비적합 이유**: 우리 보고서는 SCQA 프레임워크 사용. 1줄 요약은 SCQA의 S-C-Q-A 구조와 중복.

---

## 6. 도입 우선순위 권고

### 즉시 도입 가능 (난이도 ★~★★, 프롬프트/문서 수정만으로 가능)

| # | 항목 | 예상 소요 | 기대 효과 |
|---|------|----------|----------|
| A5 | Temporal Interrogation | 0.5일 | 기획 품질 ↑ |
| A8 | 이슈 분류 표준 체계 | 0.5일 | QA 보고 일관성 ↑ |
| A10 | Context Pressure Hierarchy | 0.5일 | 장시간 작업 안정성 ↑ |
| A11 | Persona Commitment + Anti-Drift | 0.5일 | Agent 미팅 품질 ↑ |
| A12 | Suppression 목록 | 0.5일 | QC 신호/잡음 비율 ↑ |
| A14 | Dream State Mapping | 0.5일 | 전략적 기획 품질 ↑ |

### 단기 도입 (난이도 ★★~★★★, 코드 구현 필요)

| # | 항목 | 예상 소요 | 기대 효과 |
|---|------|----------|----------|
| A1 | diff-aware QA | 1-2일 | QA 시간 50-70% 절감 |
| A2 | Health Score 정량화 | 1일 | QA 결과 객관적 비교 |
| A4 | CRITICAL GAP 자동 마킹 | 1-2일 | 에러 처리 누락 자동 탐지 |
| A7 | SKILL.md 템플릿 시스템 | 1-2일 | 코드↔문서 동기화 |
| A13 | 회귀 비교 시스템 | 1일 | 릴리즈별 품질 추이 파악 |
| A15 | 에러 메시지 AI 최적화 | 1-2일 | 서브에이전트 자동 복구 ↑ |
| A17 | fix_pct 경고 시그널 | 0.5일 | 코드 품질 트렌드 모니터링 |

### 중장기 도입 (난이도 ★★★~★★★★, 설계+구현 필요)

| # | 항목 | 예상 소요 | 기대 효과 |
|---|------|----------|----------|
| A3 | 주간 회고 시스템 | 2-3일 | 팀별 생산성/품질 추적 |
| A6 | 프롬프트 품질 테스트 | 2-3일 | 41개 스킬 품질 관리 |
| A9 | AI 코드리뷰 통합 | 3-5일 | 코드 리뷰 범위 대폭 확대 |
| A16 | @ref 브라우저 자동화 | 3-5일 | 브라우저 테스트 안정성 ↑ |

---

## 7. 핵심 발견 및 결론

### 발견 1: 프롬프트 엔지니어링의 깊이 차이

gstack의 plan-ceo-review 하나가 8가지 Prime Directives + 3-mode persona + Temporal Interrogation + Dream State Mapping + CRITICAL GAP 자동 마킹을 포함한다. 우리의 Agent 미팅 프롬프트는 이 수준의 체계적 기법을 적용하지 않고 있다. **프롬프트 기법의 깊이를 높이는 것이 가장 비용 대비 효과가 큰 개선점**이다.

### 발견 2: 정량화의 힘

gstack은 모든 곳에서 정량화를 강제한다 — Health Score 0-100, fix_pct 경고, 세션 분 수, Greptile signal ratio. 우리 시스템은 "PASS/FAIL" 이진 판단이 많다. **정량적 메트릭을 도입하면 트렌드 분석과 의사결정 품질이 크게 향상**된다.

### 발견 3: 우리 시스템의 구조적 우위

gstack은 1인 개발자 워크플로우에 최적화되어 있다. 우리의 멀티봇 + 교차 검증 + 3-level QC 체계는 gstack이 제공하지 않는 수준의 품질 통제를 가능하게 한다. **gstack의 기법을 우리 구조에 접목하면 1인 워크플로우의 효율성 + 조직 워크플로우의 안전성을 동시에 달성할 수 있다.**

### 발견 4: 브라우저 자동화는 확실한 갭

gstack의 browse 엔진은 정교하다 — @ref 시스템, snapshot diff, annotated 스크린샷, 데몬 아키텍처. 우리의 webapp-testing은 이에 미치지 못한다. InsuWiki 같은 웹 프로젝트가 본격화되면 **브라우저 자동화 강화가 필수**다.

---

## 참고 문서

- 소스코드 상세 분석: 불칸 분석 리포트
- 커뮤니티 반응 조사: 이리스 조사 리포트
- 우리 시스템 참조: `/home/jay/workspace/memory/specs/anu-guide.md`
- gstack 레포: https://github.com/garrytan/gstack

---

*작성: 헤르메스 (개발1팀장) | task-565.1 | 2026-03-15*