Hermes로 만드는 자가 진화형 개발 루프 설계도: 기억·스킬·검증·자동화의 폐쇄 루프

Hermes로 만드는 자가 진화형 개발 루프 설계도: 기억·스킬·검증·자동화의 폐쇄 루프

핵심 요약
자가 진화형 개발 루프는 AI가 무제한으로 자기 코드를 바꾸는 구조가 아닙니다. 관측 → 평가 → 지식화 → 격리 실행 → 검증 → 승인·배포 → 재관측을 반복하며, 유효한 작업 방식만 제한적으로 축적하는 운영 체계입니다. Hermes에서는 세션 검색, 영속 메모리, 스킬, 위임 에이전트, Cron, Git/테스트를 조합하여 이를 구현할 수 있습니다.

1. 왜 “자가 진화”가 필요한가

AI 코딩 도구는 한 번의 요청에는 강합니다. 하지만 실제 개발 환경에서는 같은 실수가 반복됩니다. 배포 절차를 매번 다시 묻거나, 특정 서비스의 인증 실패를 같은 방식으로 잘못 처리하거나, 과거의 테스트·코드리뷰 기준을 잊어버리는 문제가 대표적입니다.

여기서 필요한 것은 모델 파라미터를 실시간 학습시키는 방식이 아닙니다. 운영 환경에서 얻은 검증 가능한 지식을 다음 작업에 재사용하는 방식입니다.

• 메모리: 사용자 선호, 프로젝트의 안정적인 사실
• 세션 검색: 이전 대화·결정·해결 과정의 회상
• 스킬: 재현 가능한 절차, 명령, 실패 방지책
• 테스트와 리뷰: 지식과 코드가 실제로 맞는지 확인하는 품질 게이트
• Cron·웹훅: 사람이 자리에 없을 때도 관측과 후속 작업을 수행하는 실행 장치

즉, “자가 진화”의 본질은 경험을 무작정 축적하는 것이 아니라, 검증된 경험만 작업 표준으로 승격하는 것입니다.

2. 전체 설계도: 폐쇄 루프를 먼저 만듭니다

┌─────────────────────────────────────────────────────────────┐
│  ① 관측 Observe                                               │
│  이슈·PR·CI·로그·사용자 피드백·운영 이벤트                    │
└───────────────────────┬─────────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  ② 진단 Assess                                                │
│  세션 검색 + 코드/로그 조사 + 재현 + 원인 분리                │
└───────────────────────┬─────────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  ③ 지식화 Learn                                               │
│  안정적 사실 → Memory / 반복 절차 → Skill / 임시 사실 → 세션  │
└───────────────────────┬─────────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  ④ 계획·실행 Plan & Execute                                   │
│  작은 작업 분해 → 격리된 worktree·subagent → 최소 변경        │
└───────────────────────┬─────────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  ⑤ 검증 Verify                                                │
│  테스트·린트·보안 점검·diff 검토·실사용 확인                  │
└───────────────────────┬─────────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  ⑥ 승인·배포 Promote                                          │
│  사람 승인 또는 명시적 정책 통과 → PR/배포/스킬 갱신          │
└─────────────────────────────────────────────────────────────┘
                        │
                        └────────── ①로 되돌아가 결과 재관측

이 구조의 핵심은 두 가지입니다.

1. 실행 루프와 학습 루프를 분리합니다. 코드 수정은 언제나 실패할 수 있지만, 검증 없이 얻은 교훈까지 영구화하면 다음 작업을 더 나쁘게 만듭니다.
2. 승격 기준을 둡니다. 한 번 성공한 명령은 메모리가 아니라 세션에 남깁니다. 여러 번 재현됐고 검증 절차가 명확한 경우에만 스킬로 승격합니다.

3. Hermes 구성요소를 루프에 매핑합니다

3-1. Memory: “다시 묻지 않아도 되는 안정적 사실”

메모리에는 사용자의 선호나 장기간 유효한 프로젝트 규칙만 넣는 것이 좋습니다.

• 적합: 사용자는 한국어·간결한 보고 형식을 선호함 / 서비스는 PostgreSQL을 기본 DB로 사용함 / 배포 전 반드시 특정 테스트 묶음을 통과해야 함
• 부적합: 오늘 고친 버그 번호 / 일회성 장애의 상세 로그 / 특정 PR의 커밋 SHA

일회성 정보는 금방 낡으므로 세션·이슈·Git에 남겨야 합니다. 메모리 오염은 장기적으로 에이전트 품질을 떨어뜨립니다.

3-2. Session Search: “과거 대화를 사실처럼 찾는 장치”

질문: 지난번 CI 캐시 오류를 어떻게 해결했는가?
  ↓
세션 검색: 관련 대화와 당시 오류 메시지 찾기
  ↓
현재 저장소 확인: 지금도 같은 구조인지 검증
  ↓
같다면 재사용, 다르다면 새 원인으로 분리

검색 결과를 현재 사실로 간주하면 안 됩니다. 세션은 “왜 그 결론을 냈는가”를 제공하고, 현재 코드·로그·테스트가 “지금도 맞는가”를 판정합니다.

3-3. Skills: “검증된 업무 절차의 패키지”

좋은 스킬에는 최소한 다음이 들어가야 합니다.

• 언제 쓰는가: Trigger
• 무엇을 먼저 확인하는가: Prerequisite
• 실제 명령·파일 경로: Procedure
• 과거 실패에서 얻은 주의점: Pitfall
• 성공 판정: Verification

## Trigger
프로덕션 배포 요청 또는 승인된 릴리스 PR

## Verification gate
1. 단위 테스트 통과
2. 마이그레이션 dry-run 통과
3. /healthz 200 확인
4. 오류율이 기준을 초과하면 롤백

3-4. Delegation과 Worktree: “병렬화하되 충돌은 격리합니다”

Issue
 ├─ Research agent   → 원인 후보·근거
 ├─ Implement agent  → isolated worktree의 수정안
 └─ Review agent     → diff·테스트·회귀 위험
                         ↓
                    인간 또는 정책 승인

조사, 구현, 리뷰는 동시에 수행할 수 있습니다. 그러나 같은 작업 디렉터리에서 여러 에이전트가 수정하면 충돌과 오염이 발생합니다. 병렬화는 속도를 높이지만, 최종 결정을 분산시키는 수단이 되어서는 안 됩니다.

3-5. Cron과 Webhook: “사람이 없는 시간의 관측 레이어”

• 매일: 실패한 CI 요약, 보안 경고, 의존성 변경 확인
• 매주: 반복 실패 패턴 분석, 스킬 후보 목록 작성
• 이벤트 발생 시: 배포 실패·Sentry 경고·GitHub Issue를 진단 큐에 적재

LLM 추론이 불필요한 단순 감시는 no_agent=True 스크립트가 적합합니다. 단, 일시적 네트워크 오류를 장애 알림으로 보내지 않도록 재시도와 무음 실패 정책을 반드시 넣어야 합니다.

response="$(curl -fsS --retry 3 --max-time 20 https://service.example/health || true)"
if [ -z "$response" ]; then
  exit 0  # 일시적인 fetch 실패는 조용히 종료
fi

if ! grep -q '"status":"ok"' <<< "$response"; then
  echo "⚠️ service health 상태 이상"
fi

4. 추천 아키텍처: 3개의 기억 계층

계층 A — 단기 맥락: 세션

현재 작업의 가설, 시행착오, 일회성 로그입니다. 검색 가능해야 하지만 영구 규칙으로 취급해서는 안 됩니다.

계층 B — 장기 사실: Memory

사용자·프로젝트의 안정적인 선호와 제약입니다. 짧고 선언적인 문장으로 유지합니다.

계층 C — 실행 지식: Skill

반복 가능한 절차입니다. 버전 관리하고, 실제로 실패한 지점과 검증 명령까지 기록합니다.

“DB는 PostgreSQL이다”                  → Memory
“지난 화요일 장애의 stack trace”         → Session / 이슈
“PostgreSQL 마이그레이션 배포 절차”       → Skill

5. 실전 설계: 하루짜리 최소 구현(MVP)

단계 1. 변경 요청을 구조화합니다

• 목표: 무엇을 바꿀 것인가
• 제약: 건드리면 안 되는 영역은 무엇인가
• 검증: 무엇이 통과하면 성공인가
• 배포 권한: 자동 배포인지, 사람 승인인지

단계 2. 구현 전 고정 품질 게이트를 둡니다

# quality-gates.yaml 예시
required:
  - unit-tests
  - lint
  - diff-review
optional:
  - integration-tests
  - security-scan
promotion:
  production_requires_human_approval: true

단계 3. 검증된 반복 절차만 스킬로 만듭니다

최소 두 번 이상 유사하게 재현됐고, 선행 조건·실패 모드·객관적 성공 기준이 명확할 때만 스킬화하는 것이 바람직합니다.

단계 4. 정기 회고를 자동화합니다

1. 같은 유형의 실패가 두 번 이상 있었는가?
2. 이미 존재하는 스킬이 오래되었거나 틀렸는가?
3. 테스트가 통과했지만 운영에서 실패한 사례가 있었는가?
4. 인간 승인 없이는 위험한 자동화가 늘어나지 않았는가?

6. Hermes 설정 예시

# ~/.hermes/config.yaml 예시
memory:
  memory_enabled: true
  user_profile_enabled: true

security:
  redact_secrets: true

delegation:
  max_iterations: 40
  reasoning_effort: medium

checkpoints:
  enabled: true

다음은 정기 회고 작업의 프롬프트 예시입니다.

매주 월요일 09:00에 지난 7일의 CI 실패·배포 오류·반복된 사용자 수정 요청을 조사한다.

출력:
- 반복 패턴 3개 이하
- 각 패턴의 근거와 영향도
- 스킬로 승격할 후보 절차
- 자동 수정이 아니라 사람이 검토할 변경 제안

금지:
- 비밀값 출력
- 승인 없는 프로덕션 변경
- 현재 코드·로그 확인 없이 과거 세션만 근거로 단정

7. 검증 루프가 없으면 “자가 진화”는 퇴행이 됩니다

가장 위험한 설계는 에이전트가 실패 원인을 추정한 뒤, 테스트 없이 프롬프트·스킬·코드를 계속 덮어쓰는 방식입니다. 이 경우 오류가 축적되며 어느 시점부터는 무엇이 사실인지 알 수 없게 됩니다.

대상	자동 반영	권장 정책
세션 요약	가능	원문·근거 링크 보존
개인 선호 메모리	제한적	안정적 사실만 기록
스킬 수정	제한적	검증 절차와 함께 변경
소스 코드 변경	제한적	worktree + 테스트 + 리뷰
프로덕션 배포	원칙적으로 불가	명시적 승인 또는 정책 기반 승인

권한 확대, 인증·결제·계정 관련 변경, 데이터 삭제나 비가역 마이그레이션, 보안 정책 완화, 테스트를 생략한 hotfix는 자동화 대상에서 제외하는 것이 바람직합니다.

8. 성숙도 모델: Level 0에서 Level 4까지

1. Level 0 — 대화형 보조: 요청할 때만 답하고 작업 간 맥락이 거의 이어지지 않습니다.
2. Level 1 — 기억하는 보조: 사용자 선호와 프로젝트 기본 정보를 기억하고 과거 세션을 검색합니다.
3. Level 2 — 절차를 재사용하는 보조: 반복 작업을 스킬로 정리하고 검증 명령을 함께 실행합니다.
4. Level 3 — 관측하는 개발 루프: Cron·Webhook으로 CI·로그·이슈를 감시하고 반복 패턴을 보고합니다.
5. Level 4 — 승인 기반 자가 개선: 스킬 후보, 테스트 보강, 문서 개선, PR 초안을 자동 제안합니다. 병합·배포·권한 변경은 승인 정책 아래 둡니다.

대부분의 개인 개발 환경과 소규모 팀에는 Level 2~3이 비용 대비 효율이 좋습니다. Level 4는 관측 데이터와 품질 게이트가 충분히 갖춰진 뒤에 도입하는 것이 바람직합니다.

9. 바로 적용할 체크리스트

• 세션, 메모리, 스킬의 저장 기준을 분리했는가
• 코드 변경은 격리된 worktree 또는 브랜치에서 수행하는가
• 모든 변경에 테스트 또는 검증 명령이 있는가
• 실패한 실행 결과를 자동으로 성공으로 기록하지 않는가
• Cron watchdog이 일시적 네트워크 오류를 사용자 경보로 보내지 않는가
• 스킬에는 trigger·pitfall·verification이 있는가
• 비밀값과 OTP가 메모리·스킬·리포트에 남지 않는가
• 배포·권한·삭제 작업에 인간 승인 또는 명시적 정책이 있는가

결론

Hermes로 만드는 자가 진화형 개발 루프의 목적은 “에이전트에게 더 큰 권한을 주는 것”이 아닙니다. 목적은 반복되는 개발 작업에서 확인된 지식을 보존하고, 실패를 다음 작업의 품질 게이트로 바꾸는 것입니다.

가장 좋은 출발점은 작습니다. 하나의 프로젝트에 대해 세션 검색, 간결한 메모리, 검증 가능한 스킬, 테스트 우선 실행, 주간 회고 Cron을 연결하십시오. 이후 관측 데이터가 쌓일수록 자동화 범위를 넓히되, 배포와 권한 변경의 최종 결정은 항상 명확한 승인 경로에 남겨두는 것이 바람직합니다.

---

참고 자료

• Hermes Agent 공식 문서
• Hermes Agent Cron 문서
• Hermes Agent Delegation 문서
• Hermes Agent GitHub