비교 분석
| 항목 | GSD | ai-rules | |------|-----|----------| | 핵심 문제 | Context rot — 작업 진행 중 컨텍스트 품질 저하 | 규칙 강제 — 에이전트가 안전하게 작동하도록 정책 계층 제공 | | 접근 | **
작성일: 2026-04-14 대상: get-shit-done v1.35.0 관점: ai-rules IMPROVEMENT-ROADMAP 9개 차원 기준 + 구조적 차이 분석
프로젝트 개요
| 항목 | GSD | ai-rules |
|---|---|---|
| 핵심 문제 | Context rot — 작업 진행 중 컨텍스트 품질 저하 | 규칙 강제 — 에이전트가 안전하게 작동하도록 정책 계층 제공 |
| 접근 | 프로세스 오케스트레이션 (Plan → Execute → Verify 루프) | 정책 + 강제 계층 (CLAUDE.md + hooks + governance) |
| 런타임 | Claude Code, Codex, Gemini, Copilot, Cursor, Windsurf, Cline 등 15+ | Claude Code, Cursor, Windsurf, OpenClaw, Plain 등 7 adapter |
| 설치 | npm 패키지 (get-shit-done-cc) + 단일 installer |
git clone + sync.mjs 프로파일 기반 생성 |
| 코어 언어 | CommonJS (zero dependencies) + TypeScript SDK | Markdown 규칙 + Shell hooks + ESM 스크립트 |
| 규모 | ~75 commands, ~65 workflows, ~30 agents, ~170 tests | ~7 core rules, ~10 extensions, ~8 agents, ~19 tests |
IMPROVEMENT-ROADMAP 9개 차원 비교
1. 규칙 설계 깊이
| GSD | ai-rules | |
|---|---|---|
| 평가 | ★★★☆☆ | ★★★★★ |
GSD: 규칙이 암시적. references/universal-anti-patterns.md, references/gates.md 등에 분산. 가역성 등급(R0/R1/R2) 같은 체계적 분류 없음. "하지 말 것"보다 "이렇게 해라"에 집중.
ai-rules: 가역성 3등급, 충돌 매트릭스, tie-breaker 4원칙, 변명 방지 테이블 — 비교 대상 중 최고 수준.
핵심 차이: GSD는 프로세스로 위험을 우회(Plan → Verify 루프가 잘못된 결과를 잡음), ai-rules는 규칙으로 위험을 사전 차단. 두 접근은 상호 보완적.
2. 결정론적 강제 (Hooks)
| GSD | ai-rules | |
|---|---|---|
| 평가 | ★★★☆☆ | ★★★★☆ |
GSD: 6 JS hooks + 3 bash hooks, 대부분 advisory (경고만, 차단 안 함). 유일한 blocking hook은 gsd-validate-commit.sh (Conventional Commits 검증). gsd-workflow-guard.js도 advisory.
gsd-prompt-guard.js— 프롬프트 인젝션 패턴 15개 regex 탐지 (advisory)gsd-context-monitor.js— 컨텍스트 잔량 35%/25% 경고gsd-read-guard.js— Read-before-Edit 리마인더 (비Claude 런타임용)
ai-rules: guard-branch.sh (blocking), guard-secrets.sh (blocking), guard-push-force.sh (blocking) 등 핵심 안전 규칙은 결정론적 차단. Tier 1 테스트 19/19 통과.
핵심 차이: GSD는 hooks를 "도우미"로 사용 (위험 감지 후 경고), ai-rules는 hooks를 "가드레일"로 사용 (위험 행동 자체를 차단). GSD의 prompt-guard(프롬프트 인젝션 방어)와 context-monitor(컨텍스트 잔량 경고)는 ai-rules에 없는 독특한 가치.
3. 프로세스 가이드
| GSD | ai-rules | |
|---|---|---|
| 평가 | ★★★★★ | ★★★★☆ |
GSD: 이 영역이 핵심 강점. 75개 slash command가 전체 개발 라이프사이클을 커버:
discuss → plan → execute → verify → ship완전한 워크플로우- 각 단계에 전용 에이전트 + revision 루프 (최대 3회 + stall detection)
- 4-Gate 분류법: Pre-flight / Revision / Escalation / Abort
- Quick/Fast 모드: 가벼운 작업용 우회 경로
ai-rules: P5 스킬화 후 7개 스킬(planning, commit, debugging, code-review, pr-create, daily-scrum, weekly-report). 핵심은 커버하나 GSD의 연속적 오케스트레이션에는 미치지 못함.
GSD에서 배울 점:
- Thin Orchestrator 패턴 — command가 로직을 갖지 않고 workflow 파일을 참조만. ai-rules 스킬도 이 패턴을 따르면 유지보수성 향상
- Phase 상태 머신 — Discuss → Research → Plan → PlanCheck → Execute → Verify → Advance. ai-rules는 Plan Mode → 구현이 전부
- Revision 루프 — 검증 실패 시 자동 재시도 (최대 3회). ai-rules는 Failure Protocol이 있지만 자동 루프는 아님
4. 컨텍스트 효율
| GSD | ai-rules | |
|---|---|---|
| 평가 | ★★★★★ | ★★★★☆ |
GSD: Context rot 해결이 존재 이유. 핵심 전략:
- Thin Orchestrator + Fat Subagent: 오케스트레이터는 컨텍스트 15%만 사용, 실제 작업은 fresh context 서브에이전트에 위임
- Phase-aware Context Engine: 단계마다 필요한 파일만 주입 (Execute: STATE+config, Research: STATE+ROADMAP+CONTEXT 등)
- Context Budget Tiers: PEAK/GOOD/DEGRADING/POOR 4단계, 각 단계별 행동 변화
- 파일 크기 제한: ROADMAP은 현재 milestone만, SUMMARY는 500k 이하 모델에서 frontmatter만
gsd-context-monitor.js: 실시간 컨텍스트 잔량 모니터링 (35% WARNING, 25% CRITICAL)
ai-rules: P15 lazy-load 구현으로 834줄 → 409줄 (51% 감소). on-demand ref 파일 4개 분리. 하지만 런타임 컨텍스트 모니터링은 없음.
GSD에서 배울 점:
- 런타임 컨텍스트 모니터링 — 세션 중 잔량 추적 + 경고 (ai-rules에는 "30턴 초과 시 HANDOFF" 규칙만 존재)
- Phase-aware 주입 — 작업 단계에 따라 주입할 규칙이 달라야 함 (계획 단계에서는 git 커밋 규칙 불필요)
- 서브에이전트 컨텍스트 격리 — 서브에이전트에 전체 CLAUDE.md를 주입하지 않고 필요한 부분만
5. 테스트/검증
| GSD | ai-rules | |
|---|---|---|
| 평가 | ★★★★★ | ★★★☆☆ |
GSD: 170+ 테스트 파일, 버그마다 전용 회귀 테스트 (bug-NNNN-*.test.cjs):
node:test+node:assert/strict(외부 의존 없음)- c8 커버리지 70% 라인 threshold
- SDK: Vitest unit + integration (120s timeout) + e2e
createTempProject()패턴: 임시.planning/생성 → 테스트 → 정리
ai-rules: P11+P16으로 Tier 1 시나리오 19개 (hook 차단 테스트). Tier 2/3 (LLM 기반) 미구현. 테스트가 governance 계층에 집중, 규칙 자체의 효과 측정은 부재.
GSD에서 배울 점:
- 버그별 회귀 테스트 문화 — 버그 수정 시 해당 시나리오 테스트 자동 추가
createTempProject()패턴 — ai-rules도createTempProfile()+syncToTemp()로 격리된 테스트 환경 구축 가능- SDK 통합 테스트 — 실제 sync 실행 후 출력 파일 검증
6. 프로젝트 적응
| GSD | ai-rules | |
|---|---|---|
| 평가 | ★★★★☆ | ★★★★★ |
GSD: .planning/config.json + 3단계 defaults cascade (hardcoded → user → project). model_profile (quality/balanced/budget/adaptive), workflow.* 토글 20+, agent_skills.* 주입. 단일 config 파일 방식.
ai-rules: 15 프로파일 YAML, 7 adapter, core/extensions/agents 3계층 조합. 프로파일이 블록 선택 + adapter 선택 + extension 조합을 모두 제어. 기존 프로젝트 적응 사례(AX-Studio-plan) 검증 완료.
핵심 차이: GSD는 단일 config로 ON/OFF 토글, ai-rules는 프로파일 조합으로 규칙 세트 자체를 교체. ai-rules가 더 유연하지만 복잡도 높음.
7. 관찰 가능성
| GSD | ai-rules | |
|---|---|---|
| 평가 | ★★★★☆ | ★★★☆☆ |
GSD:
- SDK
GSDEventStream— ~30 이벤트 타입 (SessionInit, PhaseStart, ToolCall, CostUpdate 등) - CLI/WebSocket 트랜스포트
gsd-statusline.js— 세션 컨텍스트 메트릭 실시간 기록.planning/STATE.md— 진행 상태 durable 기록
ai-rules: P17 health-check (130 checks), export-viewer 대시보드, trust-score CLI. 규칙 인프라 관찰은 가능하나 런타임 세션 관찰이 없음.
GSD에서 배울 점: 런타임 이벤트 스트림 — 세션 중 무엇이 일어나고 있는지 실시간 추적. ai-rules의 daily-scrum/weekly-report는 사후 분석.
8. 유지보수성
| GSD | ai-rules | |
|---|---|---|
| 평가 | ★★★★☆ | ★★★★☆ |
GSD: gsd-tools.cjs 12K+ 줄 단일 파일이 모든 상태 관리를 중앙화. 장점(단일 진실의 원천)이자 단점(거대 파일). 24개 lib/ 모듈로 기능 분리는 되어 있음. atomicWriteFileSync() + .lock 파일로 동시성 안전.
ai-rules: P3 병합 + P15 lazy-load로 모듈 분리 완료. sync.mjs가 중앙 빌드, core/extensions/agents가 소스. 규칙 간 커플링 진단(rule-coupling-diagnosis) 후 개선.
비슷한 수준: 둘 다 중앙 빌드 시스템 + 모듈 분리 구조. GSD가 런타임 상태 관리에서 더 성숙(atomic write, locking).
9. 자기 개선
| GSD | ai-rules | |
|---|---|---|
| 평가 | ★★★☆☆ | ★★★☆☆ |
GSD: gsd-nyquist-auditor (샘플링 기반 검증 커버리지 감사), gsd-security-auditor (위협 모델 기반 보안 체크). 자동 개선 루프는 없으나 감사 에이전트가 갭을 발견.
ai-rules: P18 self-improve 스킬 (위반 패턴 분석 → 변명 방지 테이블 보강 → 교차 검증). 설계는 있으나 실행 루프 자동화 미완.
비슷한 수준: 둘 다 감사/진단 도구는 있으나 "학습 → 자동 규칙 개선" 폐쇄 루프는 미완성.
종합 비교 매트릭스
| 차원 | GSD | ai-rules | 우위 |
|---|---|---|---|
| 규칙 설계 깊이 | ★★★☆☆ | ★★★★★ | ai-rules |
| 결정론적 강제 | ★★★☆☆ | ★★★★☆ | ai-rules |
| 프로세스 가이드 | ★★★★★ | ★★★★☆ | GSD |
| 컨텍스트 효율 | ★★★★★ | ★★★★☆ | GSD |
| 테스트/검증 | ★★★★★ | ★★★☆☆ | GSD |
| 프로젝트 적응 | ★★★★☆ | ★★★★★ | ai-rules |
| 관찰 가능성 | ★★★★☆ | ★★★☆☆ | GSD |
| 유지보수성 | ★★★★☆ | ★★★★☆ | 동등 |
| 자기 개선 | ★★★☆☆ | ★★★☆☆ | 동등 |
| 합계 (45점) | 34점 (75.6%) | 34점 (75.6%) | 동등 |
구조적 차이 — 핵심 인사이트
1. 철학적 차이: 프로세스 vs 정책
GSD: "좋은 프로세스를 따르면 나쁜 결과가 줄어든다"
Plan → Execute → Verify 루프가 품질을 보장
ai-rules: "명확한 규칙과 가드레일이 안전한 작동을 보장한다"
R0/R1/R2 + hooks + 변명 방지가 위험을 차단
둘 다 맞다. 이상적인 시스템은 정책으로 바닥을 깔고, 프로세스로 품질을 올린다.
2. State Management 차이
| 측면 | GSD | ai-rules |
|---|---|---|
| 프로젝트 상태 | .planning/STATE.md (구조화) |
HANDOFF 블록 in sessions/{project}.md |
| 계획 | .planning/PLAN.md (XML 구조) |
Plan Mode (대화 내) |
| 진행 추적 | Phase 상태 머신 | TodoWrite + HANDOFF |
| 동시성 | Atomic writes + .lock |
Branch claim 메커니즘 |
| 영속성 | .planning/ 디렉토리 (git tracked) |
~/.claude/sessions/ (git 외부) |
GSD의 .planning/ 접근이 더 견고: git에 포함되어 팀 공유 가능, 구조화된 상태로 파싱 용이.
3. 에이전트 오케스트레이션
| 측면 | GSD | ai-rules |
|---|---|---|
| 에이전트 수 | 30개 (전문화) | 8개 (범용) |
| 오케스트레이션 | Thin orchestrator → fat subagent | 규칙 기반 소환 테이블 |
| 검증 | 전용 verifier + auditor 에이전트 | reviewer 에이전트 (2단계 분리) |
| 연구 | phase-researcher + project-researcher | 없음 (사용자 또는 에이전트 자율) |
| UI 전용 | ui-researcher + ui-checker + ui-auditor 3종 | 없음 |
| 완료 프로토콜 | H2 Marker 패턴 매칭 | HANDOFF 블록 |
4. 멀티 런타임 지원
GSD의 installer가 15개 런타임을 지원하는 방식은 ai-rules의 adapter보다 포괄적:
- Tool 매핑 변환: Claude
Read→ Copilotread,Task→agent - Sandbox 설정: Codex용
config.toml자동 생성 - Skills 형식 변환: Claude Code 2.1.88+는
SKILL.md, 이전 버전은commands/*.md
ai-rules의 adapter는 규칙 출력 형식만 변환 (Markdown 구조 변환), GSD는 실행 환경까지 변환.
ai-rules에 적용 가능한 GSD 패턴
즉시 적용 가능 (기존 ROADMAP과 시너지)
| GSD 패턴 | 적용 방안 | 관련 ROADMAP |
|---|---|---|
| Context Monitor Hook | gsd-context-monitor.js 패턴으로 컨텍스트 잔량 경고 hook 추가 |
P7 (PostToolUse) |
| Prompt Injection Guard | gsd-prompt-guard.js의 15 regex 패턴을 .claude/hooks/에 추가 |
P9 (호출 횟수 제한) |
| Bug-per-test 문화 | 규칙 위반 발견 시 해당 시나리오 테스트 자동 생성 규칙 | P11/P16 (테스트) |
| Phase-aware Context | 스킬 호출 시 해당 단계에 필요한 규칙만 주입 | P15 (lazy-load) 확장 |
| Completion Marker | 에이전트 완료 시 H2 마커 출력 표준화 → HANDOFF 자동 파싱 | P3 (04-lifecycle) |
중기 검토 (아키텍처 변경 수반)
| GSD 패턴 | 적용 방안 | 비고 |
|---|---|---|
.planning/ 상태 디렉토리 |
sessions/ 대신 프로젝트 내 .ai-state/ 도입 검토 |
git tracked → 팀 공유 가능 |
| SDK/프로그래매틱 API | ai-rules를 프로그래밍으로 사용하는 SDK | 현재 sync.mjs CLI만 존재 |
| Revision 루프 | 검증 실패 시 자동 재시도 (최대 N회 + stall detection) | Failure Protocol 확장 |
| 전문 에이전트 분화 | researcher, debugger, auditor 등 전문 에이전트 추가 | agents/ 확장 |
채택하지 않을 것 (철학적 차이)
| GSD 패턴 | 불채택 이유 |
|---|---|
| Advisory-only hooks | ai-rules의 핵심 가치는 결정론적 차단 — advisory 전환은 약화 |
| 12K 줄 단일 도구 파일 | 유지보수성 리스크. 모듈 분리 유지 |
| zero-dependency 순수주의 | ai-rules는 Node.js 내장 모듈로 충분하므로 동일하게 유지 가능 |
| 75개 command | 과도한 표면적. 핵심 7-10개 스킬로 충분 |
결론
GSD와 ai-rules는 같은 문제(AI 에이전트 품질 제어)를 다른 축에서 해결:
- GSD = 프로세스 오케스트레이션의 걸작. Context rot 방지, Phase 상태 머신, Thin Orchestrator 패턴이 핵심 혁신. 하지만 규칙의 결정론적 강제가 약함 (대부분 advisory).
- ai-rules = 정책 설계와 강제의 걸작. 가역성 등급, 충돌 매트릭스, blocking hooks가 핵심 혁신. 하지만 프로세스 오케스트레이션과 컨텍스트 관리가 약함.
이상적 조합: ai-rules의 정책 계층(바닥) + GSD의 프로세스 오케스트레이션(천장). 구체적으로는:
- ai-rules의 R0/R1/R2 + blocking hooks로 안전 바닥 확보
- GSD의 Phase → Plan → Execute → Verify 루프로 품질 천장 확보
- GSD의 Context Engine 아이디어로 ai-rules의 lazy-load를 Phase-aware로 확장
총점이 동일(34/45)하지만 강약이 완전히 다른 두 시스템 — 경쟁이 아니라 상호 보완 관계.