Hermes Agent: 세션이 끊겨도 학습 내용이 누적되는 자기 개선형 AI 에이전트

솔직히 말하면, AI 에이전트 툴을 처음 써볼 때마다 느끼는 감정이 있습니다. "세션 닫으면 또 처음부터 설명해야 하겠지." 코드베이스 구조 알려주고, 팀 컨벤션 설명하고, 쓰는 스택 얘기하고 — 매번 같은 내용을 반복하다 보면 도구인지 짐인지 헷갈릴 때가 있죠. Nous Research가 2026년 2월에 공개한 Hermes Agent는 이 문제를 아키텍처 레벨에서 다르게 접근합니다. 세션이 끊겨도 학습 내용이 남고, 어려운 문제를 풀수록 스스로 더 나은 에이전트가 되는 구조입니다.

공개 3개월 만에 GitHub 스타 14만을 돌파하고 OpenRouter 발표 기준으로 세계에서 가장 많이 사용되는 에이전트가 된 건 단순한 마케팅이 아닙니다. NVIDIA와 협업해 RTX PC 로컬 추론을 공식 지원하고, MIT 라이선스에 텔레메트리가 없다는 점에서 기업 환경에서도 진지하게 검토할 수 있는 옵션이 됐습니다. 이 글에서는 Hermes Agent의 작동 원리부터 팀 환경에서 실제로 쓸 수 있는 시나리오, 그리고 솔직한 한계까지 함께 살펴봅니다.

핵심 개념

자기 개선형 에이전트란 무엇인가

기존 AI 도구들은 대부분 상태가 없습니다(stateless). GPT 기반 코파일럿이든 Claude CLI든, 세션이 끝나면 그 대화에서 일어난 일은 사라집니다. Hermes Agent는 여기서 출발점이 다릅니다.

Self-Improving Agent: 문제를 해결할 때마다 재사용 가능한 Skill 문서를 자동으로 생성하고, 이를 다음 세션에 불러와 활용하는 에이전트. 시간이 지날수록 같은 유형의 문제를 더 빠르고 정확하게 처리하게 됩니다.

핵심 아키텍처는 세 가지 원칙으로 이루어져 있습니다:

저도 처음엔 "메모리 파일 관리를 에이전트한테 시키는 거잖아, 그게 그거 아닌가?" 싶었는데, 실제로 써보면 차이가 납니다. MEMORY.md에 "우리 팀은 pnpm을 씁니다, 브랜치 전략은 이렇습니다"라고 한 번 정의해두면, 이후 세션부터는 그걸 전제로 대화가 시작됩니다. 매번 컨텍스트 셋업에 쓰던 시간이 사라지는 거죠.

Skill 시스템: 에이전트가 스스로 지식을 쌓는 방식

Hermes Agent에서 가장 독특한 부분이 바로 Skills입니다. Skill 생성에는 두 가지 경로가 있습니다. 사용자가 명시적으로 저장을 요청하는 경우와, 에이전트가 다단계 추론이 필요한 문제를 풀고 난 뒤 스스로 "이건 다음에도 써먹을 수 있겠다"고 판단해서 자동으로 문서를 만드는 경우입니다. 즉, 매번 수동으로 관리하지 않아도 에이전트가 경험을 쌓아가는 구조입니다.

예를 들어 에이전트가 "NestJS에서 커스텀 exception filter를 만들어서 에러를 Sentry로 보내는 방법"을 처음으로 해결했다면, 그 과정을 Skill 문서로 정리해 .hermes/skills/ 폴더에 저장합니다. 다음에 비슷한 작업이 생기면 처음부터 추론하지 않고 저장된 Skill을 먼저 참조합니다.

# .hermes/skills/nestjs-sentry-exception-filter.md 예시 구조
---
name: nestjs-sentry-exception-filter
description: NestJS에서 전역 exception filter로 Sentry 에러 리포팅 연동
tags: [nestjs, sentry, error-handling]
---
 
## 문제
NestJS 앱에서 처리되지 않은 예외를 Sentry로 자동 전송해야 하는 경우
 
## 해결 패턴
1. @Catch() 데코레이터로 AllExceptionsFilter 구현
2. SentryService 주입 후 captureException 호출
3. APP_FILTER 토큰으로 전역 등록
 
## 코드
(에이전트가 작성한 실제 코드 스니펫)

이 Skills는 커뮤니티 공유 오픈 표준으로 설계되어 있습니다(공유 플랫폼은 현재 출시 준비 중입니다). 팀 내부 Skills는 사내 서버에 보관하고, 범용적인 것만 커뮤니티에 기여하는 식으로 운용할 수 있습니다.

실전 적용

기반 설정: MCP 서버 연결

실전 예시로 들어가기 전에, 모든 예시의 바탕이 되는 MCP 연결 설정을 먼저 살펴보면 좋습니다. Model Context Protocol(MCP)은 Anthropic이 주도해 만든 AI 에이전트-도구 연결 표준으로, 에이전트 측에서 매번 커스텀 연동 코드를 작성하지 않아도 GitHub·DB·클라우드 인프라 등 외부 시스템과 이야기할 수 있게 해줍니다. REST API처럼 인터페이스를 표준화한다고 생각하면 빠릅니다.

Hermes Agent는 config 한 줄로 어떤 MCP 서버든 연결할 수 있습니다:

// hermes.config.json
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "linear": {
      "command": "npx",
      "args": ["-y", "@linear/mcp-server"],
      "env": {
        "LINEAR_API_KEY": "${LINEAR_API_KEY}"
      }
    }
  }
}

이 설정을 한 번 해두면, 이후 예시들처럼 에이전트가 자연어 지시만으로 GitHub이나 Linear를 직접 조작하는 워크플로우를 구성할 수 있습니다.

예시 1: 팀 일일 스탠드업 자동화

가장 실용적인 활용 사례 중 하나입니다. 매일 아침 캘린더, GitHub, Linear를 조회해서 팀 채널에 요약을 올리는 작업은 반복적이지만 컨텍스트가 중요한 일입니다. 아래는 개념을 보여주는 의사 코드입니다 — 실제 API 형태는 공식 문서에서 확인하는 것을 권장합니다.

# 개념 예시 코드 — 실제 API 형태는 공식 문서를 참고하세요
from hermes import Agent
 
agent = Agent(
    memory_path=".hermes/MEMORY.md",
    user_path=".hermes/USER.md"
)
 
@agent.schedule("0 9 * * 1-5")  # 평일 오전 9시
async def daily_standup():
    # MCP 도구 호출로 여러 소스에서 데이터 수집
    context = await agent.gather([
        "github:list_pull_requests",
        "linear:list_issues",
        "calendar:get_today"
    ])
 
    summary = await agent.run(
        task="어제 머지된 PR, 오늘 진행 중인 이슈, 오늘 미팅 일정을 팀 스탠드업 형식으로 요약해줘",
        context=context
    )
 
    await agent.send(
        channel="slack://team-standup",
        message=summary
    )

실무에서 자주 맞닥뜨리는 상황인데, 스탠드업 봇이 "PR 번호만 나열하는" 수준에서 그치는 경우가 많죠. 저도 처음엔 그냥 리스트만 뽑아오길래 "이게 다야?" 싶었는데, USER.md와 MEMORY.md에 팀 컨텍스트가 쌓일수록 달라집니다. 3주 차쯤 됐을 때 PR 요약이 "이슈 #42가 블로킹되어 있어서 이 PR들이 지연 중"이라는 식으로 나오기 시작하면 체감이 확실히 다릅니다.

예시 2: 인프라 모니터링과 장애 알림

5분마다 서비스 헬스체크를 돌리고, 실패 시 알림을 보내는 것도 흔한 패턴입니다. Hermes Agent의 차별점은 단순 HTTP 200 체크를 넘어, 장애 패턴을 학습해 "이 에러는 보통 DB 커넥션 풀 문제일 때 나온다"는 식의 컨텍스트를 덧붙일 수 있다는 점입니다.

# hermes-monitor.yaml
monitors:
  - name: api-health
    url: https://api.yourservice.com/health
    interval: "*/5 * * * *"
    on_failure:
      - notify:
          channel: telegram://oncall-alerts
          message_template: |
            🚨 {{service_name}} 응답 없음 ({{status_code}})
            마지막 정상: {{last_success_at}}
            연속 실패: {{failure_count}}회
      - run_skill: diagnose-api-failure  # 저장된 Skill 자동 실행
    checkpoint: true  # 마지막 완료 지점부터 재개

checkpoint 옵션: 긴 파이프라인이 중간에 실패하더라도 마지막으로 성공한 지점부터 재시도할 수 있습니다. 네트워크 불안정 환경에서 처음부터 다시 돌아가는 상황을 방지합니다.

run_skill: diagnose-api-failure처럼 장애 진단 Skill을 미리 정의해두면, 알림만 보내는 게 아니라 에이전트가 직접 원인 분석을 시작합니다. 초기에 만들어둔 Skill이 쌓일수록 "같은 증상이면 이걸 먼저 확인해라"는 체계가 자연스럽게 만들어집니다.

예시 3: 로컬 LLM으로 비용 없이 운용하기

Hermes Agent의 Model-Agnostic 특성을 활용해 Ollama + 로컬 GPU로 완전히 오프라인 구성도 가능합니다. 8GB VRAM 이상의 GPU가 있다면 Hermes-3 8B 모델을 Ollama로 실행할 수 있고, Nous Research 자체 벤치마크 기준으로 도구 호출 정확도가 91% 수준입니다.

# Ollama로 Hermes-3 로컬 실행
ollama pull nous-hermes3:8b

// hermes.config.json — provider를 ollama로 변경
{
  "model": {
    "provider": "ollama",
    "name": "nous-hermes3:8b",
    "base_url": "http://localhost:11434"
  }
}

# 에이전트 시작
hermes start --config hermes.config.json

API 비용이 신경 쓰이는 개인 프로젝트나, 데이터를 외부로 보내면 안 되는 사내 환경에서 이 구성이 특히 유용합니다.

장단점 분석

장점

아쉬운 점 — 그리고 대응 방법

비교를 위해 잠깐 언급하면, OpenClaw는 Hermes Agent와 비슷한 시기에 등장한 또 다른 오픈소스 에이전트 프레임워크입니다. Skills 생태계 규모 면에서는 OpenClaw 쪽이 앞서 있지만, 보안과 라이선스 측면에서는 Hermes Agent가 더 유리한 상황입니다.

Atropos RL 프레임워크: Nous Research가 Hermes-3 학습에 사용한 강화학습 프레임워크. 도구 호출 정확도를 높이는 데 특화되어 있으며, 에이전트가 외부 API나 명령을 잘못 호출하는 빈도를 줄이는 역할을 합니다.

Honcho User Modeling: 사용자의 행동 패턴, 선호, 작업 스타일을 점진적으로 학습하는 사용자 모델링 시스템. Hermes Agent와 통합하면 에이전트 응답이 시간이 지날수록 개인화됩니다.

실무에서 자주 빠지는 함정

1. Skills를 처음부터 완벽하게 만들려는 것 — 저도 초기에 모든 팀 패턴을 수동으로 Skill 문서로 만들어보려 했는데, 결국 유지보수 포인트만 늘어났습니다. Skill 문서는 에이전트가 실제 문제를 풀면서 자동으로 만들어주는 것이 기본 설계입니다. 처음엔 불완전해도 괜찮고, 시간이 지나면서 에이전트가 직접 다듬어갑니다.

2. 8B 모델로 5단계 이상 체인을 돌리려는 것 — 로컬 8B 모델은 단순 반복 작업에는 충분하지만, 복잡한 다단계 계획이 필요한 작업에선 한계가 명확합니다. "왜 이렇게 자꾸 틀리지?" 싶을 때 모델 크기를 먼저 의심해보시면 좋습니다. 70B 모델이나 클라우드 모델로 전환하면 결과 품질이 눈에 띄게 달라집니다.

3. MEMORY.md를 비워두고 시작하는 것 — 에이전트를 설치하고 바로 질문부터 던지면, 첫 몇 주는 답변이 맥락 없이 일반적인 수준에 머뭅니다. Persistent Memory의 가치는 처음에 컨텍스트를 얼마나 잘 심어두느냐에서 시작합니다. 팀 스택, 코딩 컨벤션, 자주 쓰는 패턴을 MEMORY.md에 명시적으로 기록해두는 것을 먼저 권장합니다.

마치며

Hermes Agent는 오픈소스 에이전트 중 가장 빠르게 성장하며 세션 간 학습 누적을 실용적인 수준에서 구현한 프레임워크입니다. 세션 단절 문제, 반복 컨텍스트 입력, 로컬 실행 비용 — 에이전트를 실무에 붙이면서 맞닥뜨리는 현실적인 문제들을 아키텍처 수준에서 다르게 접근했고, 그게 실제 채택으로 이어지고 있습니다.

지금 바로 시작해볼 수 있는 3단계:

1. 로컬 환경에 설치해서 MEMORY.md 세팅해보기 — 공식 퀵스타트 가이드에서 설치 명령어를 확인한 뒤 hermes init을 실행하면 대화형으로 MEMORY.md와 USER.md를 만들 수 있습니다. 팀 스택과 코딩 컨벤션을 여기에 기록해두는 것만으로도 이후 세션의 품질이 달라집니다.

2. 작은 자동화 하나를 MCP 연결로 만들어보기 — GitHub MCP 서버를 연결하고 "이번 주 오픈된 PR을 요약해줘"처럼 실제로 쓰는 단순한 작업부터 시작해보시면 좋습니다. 작업을 마치고 나면 .hermes/skills/ 폴더에 Skill 문서 하나가 생겨있는 걸 확인할 수 있는데, 바로 그게 Hermes Agent가 스스로 학습하는 방식입니다.

3. 팀 채널 하나와 연결해 스탠드업 요약 파이프라인 구성해보기 — Slack이나 Telegram을 연결하고 GitHub + Linear를 MCP로 붙인 뒤 매일 아침 스탠드업 요약이 올라오도록 구성해볼 수 있습니다. 2~3주 운용 후 MEMORY.md가 어떻게 변해있는지 비교해보시면 자기 개선 루프가 실제로 어떻게 동작하는지 직접 확인하실 수 있습니다.

참고 자료

• Hermes Agent 공식 사이트 | Nous Research
• Hermes Agent 공식 문서
• GitHub - NousResearch/hermes-agent
• Hermes Agent 퀵스타트 가이드
• Persistent Memory 문서
• User Stories & Use Cases 문서
• NVIDIA Blog: Hermes Unlocks Self-Improving AI Agents
• Analytics Vidhya: Hermes Agent Guide
• DEV Community: Hermes Agent - A Self-Improving AI Agent That Runs Anywhere
• Turing Post: Hermes Agent vs OpenClaw 전체 비교
• GitHub - NousResearch/Hermes-Function-Calling
• OpenRouter: Hermes Agent 통합 문서
• Ollama: Hermes Agent 통합 문서
• DeepWiki: NousResearch/hermes-agent
• Firecrawl: Hermes Agent 활용 가이드