Hermes Agent vs ai-rules — 비교 분석
풀스택 에이전트 런타임과 거버넌스 정책 계층의 9개 차원 비교 — 실행 안전 vs 워크플로우 안전
한눈에 보기
Nous Research의 Hermes Agent(에이전트 런타임)와 ai-rules(거버넌스 정책 계층)를 9개 차원으로 비교한 연구입니다. 카테고리가 다른 두 시스템이 서로 보완 관계임을 확인하고, 이식 가능한 패턴을 추렸습니다.
- 핵심 질문: 런타임이 가진 실행 시점 안전 장치 중 거버넌스 계층이 가져올 것은 무엇인가?
- 읽는 대상: 에이전트 보안·관찰 가능성 설계 패턴을 비교하려는 사람
- 연결 문서: 개선 로드맵, ECC vs ai-rules 평가, Reference Comparison
작성일: 2026-04-14 대상: hermes-agent (Nous Research) 관점: ai-rules 개선 로드맵 9개 차원 기준 + 구조적 차이 분석
프로젝트 개요
| 항목 | Hermes Agent | ai-rules |
|---|---|---|
| 핵심 문제 | 자기 개선하는 범용 AI 에이전트 — 플랫폼·모델·인프라 불문 | 규칙 강제 — 에이전트가 안전하게 작동하도록 정책 계층 제공 |
| 접근 | 풀스택 에이전트 런타임 (모델 라우팅 + 도구 + 게이트웨이 + 메모리) | 정책 + 강제 계층 (CLAUDE.md + hooks + governance) |
| 카테고리 | 에이전트 프레임워크 (GSD/Claude Code 대안) | 에이전트 거버넌스 도구 (프레임워크에 장착) |
| 언어 | Python 3.11+ (uv 패키징) | Markdown 규칙 + Shell hooks + ESM 스크립트 |
| 테스트 | ~3,000 tests (pytest) | ~19 tests (Tier 1 hook 시나리오) |
| 라이선스 | MIT | (내부 도구) |
| 런타임 | 15+ 추론 제공자, 19 메시징 플랫폼, 6 터미널 백엔드 | 7 adapter (Claude Code, Cursor 등) |
핵심 차이: Hermes는 에이전트 그 자체 (모델 호출 + 도구 실행 + 메시지 라우팅을 모두 수행), ai-rules는 에이전트 위의 정책 계층 (에이전트가 어떤 프레임워크든 안전하게 작동하도록 규칙과 가드레일 제공). 직접 비교보다 보완 관계에 가깝다.
IMPROVEMENT-ROADMAP 9개 차원 비교
1. 규칙 설계 깊이
| Hermes | ai-rules | |
|---|---|---|
| 평가 | ★★☆☆☆ | ★★★★★ |
Hermes: 규칙이 코드에 하드코딩됨. approval.py의 ~35 regex 패턴이 위험 명령을 탐지하고, prompt_builder.py의 시스템 프롬프트가 행동 지침을 주입. 하지만:
- 가역성 등급(R0/R1/R2) 같은 체계적 분류 없음
- 충돌 매트릭스, tie-breaker 없음
- 규칙은 Python 코드 안에 매몰 — 사용자가 커스터마이즈 불가
ai-rules: 가역성 3등급, 충돌 매트릭스, tie-breaker 4원칙, 변명 방지 테이블 — 규칙이 선언적 Markdown으로 사용자가 읽고 수정 가능.
핵심 차이: Hermes는 안전 규칙을 코드 레벨에서 구현(개발자 수정 필요), ai-rules는 선언적 규칙으로 표현(사용자 수정 가능). Hermes의 approval.py 위험 명령 35개 패턴은 실용적이지만, “왜 위험한가”의 체계(가역성)가 없어 확장 시 일관성 유지가 어려움.
2. 결정론적 강제 (Hooks)
| Hermes | ai-rules | |
|---|---|---|
| 평가 | ★★★★☆ | ★★★★☆ |
Hermes: 이중 방어 구조:
- approval.py — 위험 명령 실행 전 사용자 승인 요구 (blocking). “Smart approval”로 보조 LLM이 저위험 명령 자동 승인 가능
- Tirith 보안 스캐너 — 외부 바이너리로 콘텐츠 레벨 위협 스캔 (homograph URL, pipe-to-interpreter, terminal injection). SHA-256 + cosign 검증
- 프롬프트 인젝션 스캐너 — AGENTS.md/.cursorrules 등 컨텍스트 파일에서 10개 인젝션 패턴 탐지 + invisible Unicode 차단
- 경로 순회 방어 —
validate_within_dir()+has_traversal_component() - 시크릿 레닥션 — 30+ API 키 형식 regex로 로그에서 자동 마스킹
ai-rules: guard-branch.sh(blocking), guard-secrets.sh(blocking), guard-push-force.sh(blocking) 등 Git 안전에 집중된 hook. Tier 1 테스트 19/19 통과.
핵심 차이: 다른 영역을 커버:
- Hermes → 실행 안전 (위험 셸 명령, 프롬프트 인젝션, 경로 순회, 시크릿 유출)
- ai-rules → Git 안전 (보호 브랜치, force push, 시크릿 커밋)
둘 다 “비슷한 별점”이지만 커버 영역이 겹치지 않음. 결합하면 ★★★★★ 수준.
3. 프로세스 가이드
| Hermes | ai-rules | |
|---|---|---|
| 평가 | ★★★☆☆ | ★★★★☆ |
Hermes: /plan, /skills, /new, /checkpoint, /restore 등 slash command 제공. 하지만:
- 전체 개발 라이프사이클 워크플로우(GSD의 discuss → plan → execute → verify → ship)는 없음
/plan은 마크다운 계획 파일을 생성하지만, 실행→검증 루프와 연결되지 않음- 스킬은 자기 생성(에이전트가 작업 중 스킬 파일 생성)이 주 패턴 — 사전 정의된 프로세스 가이드가 아님
ai-rules: 7개 스킬(planning, commit, debugging, code-review, pr-create 등)이 각 워크플로우의 단계별 실행 순서 + 검증 기준 + 변명 방지 테이블을 포함.
핵심 차이: Hermes의 스킬은 런타임에 자기 생성되는 동적 지식, ai-rules의 스킬은 사전 설계된 프로세스 가이드. Hermes 방식은 유연하지만 일관성이 낮고, ai-rules 방식은 견고하지만 유연성이 낮음.
4. 컨텍스트 효율
| Hermes | ai-rules | |
|---|---|---|
| 평가 | ★★★★★ | ★★★★☆ |
Hermes: 컨텍스트 관리가 매우 정교:
- ContextEngine ABC — 플러그인 패턴으로 교체 가능한 컨텍스트 엔진
- ContextCompressor (기본 엔진):
- Tool output pruning (LLM 호출 없이 오래된 도구 결과 정리)
- Head/tail 보호 (시스템 프롬프트 + 최근 ~20K 토큰 보존)
- 중간 부분 요약 (보조 LLM으로 손실 압축)
- 이전 요약을 iterative 업데이트 (재요약이 아닌 증분 업데이트)
- 압축 트리거:
prompt_tokens > 50% * context_length(대형 모델 과조기 압축 방지) - 프롬프트 캐싱: 시스템 프롬프트 + 도구 정의를 mid-conversation에 절대 변경 안 함 (Anthropic 캐시 보존)
- 서브디렉토리 힌트: 접근한 디렉토리 구조를 추적해 불필요한 탐색 감소
ai-rules: P15 lazy-load (834줄 → 409줄, 51% 감소), on-demand ref 파일 4개 분리. 하지만 런타임 압축은 없고 정적 분할만.
Hermes에서 배울 점:
- 플러그인 컨텍스트 엔진 — adapter 패턴으로 컨텍스트 전략을 교체 가능하게
- Tool output pruning — 오래된 도구 결과를 자동 정리 (LLM 비용 없음)
- 프롬프트 캐싱 의식 — mid-conversation 시스템 프롬프트 변경 금지 규칙
5. 테스트/검증
| Hermes | ai-rules | |
|---|---|---|
| 평가 | ★★★★★ | ★★★☆☆ |
Hermes: ~3,000 테스트, pytest 기반:
_isolate_hermes_homeautouse fixture — 모든 테스트가 임시HERMES_HOME에서 실행 (실제 사용자 데이터 보호)- 서브시스템별 분리:
tests/agent/,tests/cli/,tests/gateway/,tests/tools/,tests/acp/ - Gateway 테스트: 19개 플랫폼 어댑터별 테스트
- 프로필 테스트:
Path.home()mock으로 완전 격리
ai-rules: Tier 1 시나리오 19개 (hook 차단 테스트). 규모 차이가 큼.
Hermes에서 배울 점: _isolate_hermes_home 패턴 — ai-rules도 SYNC_TARGET_DIR 같은 임시 출력 디렉토리로 격리 테스트 환경 구축 가능.
6. 프로젝트 적응
| Hermes | ai-rules | |
|---|---|---|
| 평가 | ★★★★☆ | ★★★★★ |
Hermes: config.yaml + 프로필 시스템 (hermes -p <name>). 프로필마다 독립 config, API 키, 메모리, 세션, 스킬. 3단계 defaults cascade. model_profile + workflow.* 토글. 컨텍스트 파일로 AGENTS.md/.hermes.md 지원.
ai-rules: 15 프로파일 YAML, 7 adapter, core/extensions/agents 3계층 조합. 프로파일이 규칙 세트 자체를 교체 가능.
핵심 차이: Hermes 프로필은 런타임 환경(모델, API 키, 메모리)을 교체, ai-rules 프로파일은 규칙 세트(core + extension 조합)를 교체. 다른 차원의 적응.
7. 관찰 가능성
| Hermes | ai-rules | |
|---|---|---|
| 평가 | ★★★★★ | ★★★☆☆ |
Hermes: 관찰 가능성이 잘 갖춰진 차원:
- 3-tier 로깅: agent.log (INFO+), errors.log (WARNING+), gateway.log +
RedactingFormatter로 시크릿 자동 마스킹 - 세션 인사이트:
/insights --days N→ 토큰 소비, 비용, 도구 사용 패턴, 활동 트렌드, 모델/플랫폼 분석 - 실시간 사용량:
/usage→ 현재 세션 토큰, 캐시 통계, rate limit 상태, 비용 추정 - Rate limit 추적: 12개
x-ratelimit-*헤더 캡처 + 표시 - 비용 추적: 세션별 input/output/cache 토큰 + USD 비용, SQLite에 영구 저장
- 웹 대시보드: React+TypeScript — Sessions, Skills, Config, Logs, Cron, Analytics, Status
- Trajectory 기록: ShareGPT 형식 JSONL — RL 훈련 데이터로 활용 가능
ai-rules: P17 health-check (130 checks), export-viewer 대시보드, trust-score CLI. 규칙 인프라 관찰에 집중, 런타임 세션 관찰 없음.
Hermes에서 배울 점:
- 시크릿 레닥션 로그 — 30+ 패턴으로 로그에서 API 키 자동 마스킹
- 세션 인사이트 — 토큰/비용 추이 분석 (daily-scrum/weekly-report에 통합 가능)
- 웹 대시보드 — 현재 viewer를 세션 레벨 데이터까지 확장
8. 유지보수성
| Hermes | ai-rules | |
|---|---|---|
| 평가 | ★★★★☆ | ★★★★☆ |
Hermes: 명확한 모듈 분리:
tools/registry.py(ToolRegistry 싱글톤) →tools/*.py→model_tools.py→run_agent.py- 단방향 의존 체인 강제
HERMES_HOME상수로 경로 해석 중앙화 (119+ 참조)- Atomic JSON writes, WAL mode SQLite, file locking
ai-rules: sync.mjs 중앙 빌드, core/extensions/agents 3계층 소스, 커플링 진단 후 개선 완료.
비슷한 수준: 둘 다 중앙 레지스트리 + 모듈 분리. Hermes가 런타임 상태 관리(SQLite WAL, atomic writes)에서 더 성숙.
9. 자기 개선
| Hermes | ai-rules | |
|---|---|---|
| 평가 | ★★★★☆ | ★★★☆☆ |
Hermes: “자기 개선”이 프로젝트 핵심 철학:
- 스킬 자기 생성 — 에이전트가 작업 중 유용한 패턴을
~/.hermes/skills/에 스킬 파일로 저장 - 스킬 자기 패치 — 기존 스킬이 잘못되거나 오래되면 에이전트가 직접 수정
- 세션 검색 — FTS5 전문 검색으로 과거 세션에서 관련 정보 회수
- 메모리 시스템 —
MEMORY.md+USER.md+ 플러그인 메모리 백엔드 (Honcho, Mem0, Holographic 등) - Trajectory 기록 → RL 훈련 — 세션 데이터를 RL 훈련 데이터로 변환 (Atropos 통합)
ai-rules: P18 self-improve 스킬 (위반 패턴 분석 → 변명 방지 테이블 보강). 설계 있으나 자동 루프 미완.
Hermes에서 배울 점: 스킬 자기 생성/패치는 흥미롭지만, 거버넌스 관점에서 위험 — 에이전트가 자신의 규칙을 수정하는 것은 ai-rules의 철학과 충돌. 다만 세션 검색(FTS5) 은 유용 — 과거 위반 패턴을 검색해 self-improve에 활용 가능.
종합 비교 매트릭스
| 차원 | Hermes | ai-rules | 우위 |
|---|---|---|---|
| 규칙 설계 깊이 | ★★☆☆☆ | ★★★★★ | ai-rules |
| 결정론적 강제 | ★★★★☆ | ★★★★☆ | 동등 (영역 다름) |
| 프로세스 가이드 | ★★★☆☆ | ★★★★☆ | ai-rules |
| 컨텍스트 효율 | ★★★★★ | ★★★★☆ | Hermes |
| 테스트/검증 | ★★★★★ | ★★★☆☆ | Hermes |
| 프로젝트 적응 | ★★★★☆ | ★★★★★ | ai-rules |
| 관찰 가능성 | ★★★★★ | ★★★☆☆ | Hermes |
| 유지보수성 | ★★★★☆ | ★★★★☆ | 동등 |
| 자기 개선 | ★★★★☆ | ★★★☆☆ | Hermes |
| 합계 (45점) | 34점 (75.6%) | 34점 (75.6%) | 동등 |
구조적 차이 — 핵심 인사이트
1. 카테고리 자체가 다르다
Hermes Agent = 에이전트 프레임워크 (= 자동차 엔진)
ai-rules = 에이전트 거버넌스 (= 교통 법규 + 안전 장치)GSD와의 비교에서는 “프로세스 vs 정책”이었지만, Hermes와의 비교에서는 **“플랫폼 vs 정책”**이다. Hermes는 모델 호출, 도구 실행, 메시징, 메모리까지 직접 수행하는 완전한 에이전트 런타임이고, ai-rules는 어떤 런타임이든(Claude Code, Cursor, Hermes 포함) 위에 장착하는 거버넌스 계층이다.
2. 안전 접근 방식 비교
| 측면 | Hermes | ai-rules |
|---|---|---|
| 위험 탐지 | 35 regex + Tirith 외부 스캐너 | shell hook (blocking) |
| 승인 방식 | 인라인 승인 + “smart approval” (LLM 판단) | 확인 문구 재입력 (R2) / 사용자 승인 (R1) |
| 프롬프트 인젝션 | 10 패턴 + invisible Unicode 탐지 | 없음 (ROADMAP P9에서 검토) |
| 시크릿 보호 | 30+ 패턴 로그 레닥션 | guard-secrets.sh (커밋 시 차단) |
| 경로 보호 | validate_within_dir() | 없음 (에이전트에 의존) |
| Git 보호 | 없음 (에이전트가 자유롭게 Git 사용) | guard-branch + guard-push-force (blocking) |
| 체계적 분류 | 없음 (패턴 목록만) | R0/R1/R2 가역성 + 충돌 매트릭스 |
핵심: Hermes는 실행 시점 안전(위험한 셸 명령 차단), ai-rules는 워크플로우 안전(잘못된 Git 작업 차단). 결합하면 두 영역 모두 커버.
3. 메모리/상태 비교
| 측면 | Hermes | ai-rules |
|---|---|---|
| 세션 저장소 | SQLite (WAL, FTS5, 스키마 v6) | ~/.claude/sessions/{project}.md (Markdown) |
| 검색 | FTS5 전문 검색 | 없음 (파일 읽기만) |
| 메모리 | MEMORY.md + USER.md + 플러그인 (Honcho, Mem0 등) | Claude Code 내장 auto-memory |
| 비용 추적 | 세션별 토큰/비용 SQLite 저장 | 없음 |
| 이력 | 전체 대화 이력 영구 보존 | HANDOFF 블록만 보존 |
Hermes의 SQLite + FTS5 접근은 데이터 관리·검색에 강점이 있고, ai-rules의 Markdown HANDOFF는 “인수인계 최소 정보”에 최적화되어 있어 두 접근의 목적이 다름.
4. 멀티 플랫폼 게이트웨이
Hermes의 가장 독특한 기능 — 19개 메시징 플랫폼 (Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Email, SMS 등)에서 하나의 에이전트 프로세스를 사용:
- 크로스 플랫폼 미러링 (Telegram ↔ Discord)
- 플랫폼별 세션 리셋 정책 (daily/idle/both/none)
- DM 페어링 인증 플로우
ai-rules는 이 영역을 커버하지 않음 — IDE 내 에이전트 사용에 집중.
5. 크레덴셜 풀 + 모델 라우팅
Hermes의 credential_pool.py:
- 제공자별 다중 API 키 관리
- 로테이션 전략 (fill-first, round-robin, random, least-used)
- 429/402 쿨다운 (기본 1시간)
reset_at타임스탬프 지원
smart_model_routing.py:
- 메시지 복잡도 기반 cheap/strong 모델 자동 선택
- 키워드 분류 (코드, 분석, 간단한 질문 등)
ai-rules는 모델 선택/크레덴셜 관리를 하지 않음 (에이전트 플랫폼에 위임).
ai-rules에 적용 가능한 Hermes 패턴
즉시 적용 가능 (기존 ROADMAP과 시너지)
| Hermes 패턴 | 적용 방안 | 관련 ROADMAP |
|---|---|---|
| 프롬프트 인젝션 스캐너 | 10 regex + invisible Unicode 탐지를 hook으로 추가 | P9 (호출 횟수 제한) |
| 위험 명령 35패턴 | guard-destructive-db.sh 확장 — Hermes의 SQL/파일시스템/프로세스 패턴 추가 | P6/P7 (hooks) |
| 시크릿 레닥션 | 로그/보고서에서 30+ 패턴 자동 마스킹 | P17 (관찰 가능성) |
| 테스트 격리 패턴 | _isolate_hermes_home → createTempSyncTarget() 격리 환경 | P11/P16 (테스트) |
| 경로 순회 방어 | validate_within_dir() 패턴을 hook에 추가 | P7 (PostToolUse) |
중기 검토 (아키텍처 변경 수반)
| Hermes 패턴 | 적용 방안 | 비고 |
|---|---|---|
| 세션 FTS5 검색 | self-improve 스킬에서 과거 위반 패턴 검색 활용 | P18 확장 |
| ContextEngine ABC | adapter 패턴으로 컨텍스트 전략 플러그인화 | P15 확장 |
| 비용/토큰 추적 | 세션별 비용 추적 → weekly-report에 통합 | P17 확장 |
| Smart Approval | 보조 LLM이 저위험 명령 자동 승인 | R0 작업 자동화 |
채택하지 않을 것 (철학적 차이)
| Hermes 패턴 | 불채택 이유 |
|---|---|
| 스킬 자기 생성/패치 | 에이전트가 자신의 규칙을 수정하는 것은 거버넌스 철학과 충돌. ai-rules에서 규칙 변경은 사람이 검토 |
| 에이전트 런타임 직접 구현 | ai-rules는 런타임 불문 정책 계층 — 특정 런타임에 종속되면 범용성 상실 |
| 19 플랫폼 게이트웨이 | 범위 초과. ai-rules는 IDE 내 에이전트 거버넌스에 집중 |
| 크레덴셜 풀/모델 라우팅 | 에이전트 플랫폼(Claude Code 등)이 담당할 영역 |
3자 비교 — GSD vs Hermes vs ai-rules
| 차원 | GSD | Hermes | ai-rules | 최고 |
|---|---|---|---|---|
| 규칙 설계 깊이 | ★★★ | ★★ | ★★★★★ | ai-rules |
| 결정론적 강제 | ★★★ | ★★★★ | ★★★★ | Hermes ≈ ai-rules |
| 프로세스 가이드 | ★★★★★ | ★★★ | ★★★★ | GSD |
| 컨텍스트 효율 | ★★★★★ | ★★★★★ | ★★★★ | GSD ≈ Hermes |
| 테스트/검증 | ★★★★★ | ★★★★★ | ★★★ | GSD ≈ Hermes |
| 프로젝트 적응 | ★★★★ | ★★★★ | ★★★★★ | ai-rules |
| 관찰 가능성 | ★★★★ | ★★★★★ | ★★★ | Hermes |
| 유지보수성 | ★★★★ | ★★★★ | ★★★★ | 동등 |
| 자기 개선 | ★★★ | ★★★★ | ★★★ | Hermes |
| 합계 | 34 | 34 | 34 | 동등 |
흥미로운 결과: 세 프로젝트 모두 34/45점. 하지만 강점 영역이 완전히 다름:
GSD = 프로세스 오케스트레이션의 챔피언
Hermes = 관찰 가능성 + 런타임 인프라의 챔피언
ai-rules = 규칙 설계 + 프로젝트 적응의 챔피언결론
Hermes Agent와 ai-rules는 카테고리 자체가 다르다:
- Hermes = 에이전트 프레임워크 (모델 호출 + 도구 실행 + 게이트웨이 + 메모리를 직접 구현)
- ai-rules = 에이전트 거버넌스 (어떤 프레임워크든 위에 장착하는 정책 계층)
따라서 경쟁이 아니라 계층 관계. Hermes 위에 ai-rules를 장착할 수 있고, 그 결합은:
- Hermes의 런타임 인프라 (컨텍스트 압축, 세션 관리, 비용 추적, 19 플랫폼)
-
- ai-rules의 정책 계층 (가역성 등급, blocking hooks, 변명 방지, 프로파일 시스템)
Hermes에서 배울 가장 중요한 것: 실행 시점 안전 (approval.py 35패턴 + Tirith + 프롬프트 인젝션 방어 + 시크릿 레닥션). ai-rules는 Git 안전에 강하지만 셸 명령 안전이 약함 — Hermes의 패턴을 hook으로 이식하면 보안 차원이 완성됨.
Source Notes
이 문서는 공개 저장소 NousResearch/hermes-agent와 ai-rules를 비교한 내부 연구(2026-04)를 공개용으로 정리한 것입니다. GSD 비교 결과는 같은 시기의 별도 연구에서 가져온 요약입니다. Provenance: reference-only (외부 공개 저장소 비교 조사).