스스로 배우는 AI 에이전트, Hermes Agent 리뷰: Nous Research의 자기 개선 학습 루프 해부

들어가며: 스스로 배우는 에이전트라는 약속

대부분의 AI 에이전트는 매번 같은 자리에서 다시 시작합니다. 어제 당신을 도와 복잡한 배포 스크립트를 짜 줬더라도, 오늘 같은 일을 시키면 처음부터 똑같이 추론합니다. 쌓이는 것이 없습니다. Nous Research가 만든 Hermes Agent는 바로 이 지점을 정면으로 겨냥합니다. README의 첫 문장이 그 야심을 단번에 드러냅니다.

The self-improving AI agent built by Nous Research. It's the only agent with a built-in learning loop.

이 글은 Hermes Agent 저장소(NousResearch/hermes-agent)의 README와 개발 가이드(AGENTS.md)를 직접 읽고, 외부 리서치를 더해 "자기 개선(self-improving)"이라는 표현이 마케팅 수사인지 실제 아키텍처인지를 검증하는 리뷰입니다. 결론부터 말하면, Hermes의 학습 루프는 구체적인 서브시스템으로 구현되어 있으며, 그 설계에는 분명한 공학적 판단이 담겨 있습니다. 2026년 2월 25일 출시된 이 프로젝트는 4개월도 안 돼 GitHub 스타 18만 개를 넘기며 그해 가장 빠르게 성장한 오픈소스 에이전트 프레임워크가 됐고, OpenRouter 글로벌 랭킹에서 1위에 올랐습니다.

배경: Nous Research, 그리고 OpenClaw라는 출발선

Hermes Agent를 이해하려면 두 가지 맥락을 알아야 합니다.

첫째, 만든 주체입니다. Nous Research는 오픈소스 AI 연구로 알려진 집단으로, Hermes라는 이름은 원래 그들이 공개해 온 오픈웨이트 언어모델 시리즈에서 왔습니다. 그래서 Hermes Agent는 단순한 사용자 도구가 아니라 "다음 세대 도구 호출(tool-calling) 모델을 학습시키기 위한 데이터 생성 장치"라는 연구적 정체성을 함께 지닙니다. 이 점은 뒤에서 다룰 trajectory 생성·압축 기능에서 분명해집니다.

둘째, 출발선입니다. Hermes는 OpenClaw와 같은 계보에서 갈라져 나왔습니다. README에는 hermes claw migrate라는 명령이 있고, 별도 문서는 OpenClaw에서 넘어오는 마이그레이션을 상세히 안내합니다. 가져오는 항목이 구체적입니다.

• SOUL.md — 페르소나 파일
• 메모리 — MEMORY.md와 USER.md 항목
• 스킬 — 사용자가 만든 스킬을 ~/.hermes/skills/openclaw-imports/로
• 명령 허용목록(allowlist) — 승인 패턴
• 메시징 설정과 API 키 — 허용된 비밀값(Telegram, OpenRouter, OpenAI, Anthropic, ElevenLabs)

즉 Hermes는 OpenClaw 사용자를 직접 흡수하도록 설계됐습니다. 두 프로젝트가 같은 문제(개인이 자기 인프라에서 돌리는 다채널 AI 비서)를 풀되, Hermes는 거기에 "학습 루프"라는 차별점을 얹은 후발 주자입니다.

무엇이 다른가: 일곱 개의 기둥

README는 Hermes의 특징을 표로 압축합니다. 그중 이 프로젝트의 성격을 규정하는 핵심을 정리하면 다음과 같습니다.

• 진짜 터미널 인터페이스: 멀티라인 편집, 슬래시 명령 자동완성, 대화 히스토리, 중단·재지시(interrupt-and-redirect), 스트리밍 도구 출력을 갖춘 완전한 TUI.
• 당신이 있는 곳에 산다: Telegram·Discord·Slack·WhatsApp·Signal·CLI를 단일 게이트웨이 프로세스로. 음성 메모 전사와 크로스 플랫폼 대화 연속성 포함.
• 닫힌 학습 루프: 에이전트가 큐레이션하는 메모리와 주기적 넛지(nudge), 복잡한 작업 뒤 자율적 스킬 생성, 사용 중 스킬의 자기 개선, FTS5 세션 검색.
• 예약 자동화: 내장 cron 스케줄러가 어떤 플랫폼으로든 결과를 배달.
• 위임과 병렬화: 격리된 서브에이전트를 띄워 병렬 작업.
• 어디서나 실행: 로컬·Docker·SSH·Singularity·Modal·Daytona 여섯 가지 터미널 백엔드. Modal·Daytona는 서버리스 영속성을 제공해 유휴 시 비용이 거의 0.
• 연구 준비 완료: 배치 trajectory 생성, 다음 세대 도구 호출 모델 학습을 위한 trajectory 압축.

특히 마지막 두 항목은 OpenClaw에는 없는 Hermes만의 색깔입니다. 모델 학습 데이터를 만드는 도구라는 정체성, 그리고 "노트북에 묶이지 않는다"는 인프라 철학입니다.

모델에 묶이지 않는다: Nous Portal과 공급자 중립성

Hermes의 첫 번째 설계 신념은 모델 중립성입니다. README는 "원하는 어떤 모델이든 쓰라"고 강조하며 Nous Portal, OpenRouter(200+ 모델), NVIDIA NIM(Nemotron), Xiaomi MiMo, z.ai/GLM, Kimi/Moonshot, MiniMax, Hugging Face, OpenAI, 그리고 자체 엔드포인트까지 나열합니다. 전환은 hermes model 한 번이면 끝나며 코드 변경도, 락인도 없습니다.

여기에 Nous Research는 Nous Portal이라는 자체 게이트웨이를 더했습니다. 모델·웹 검색·이미지 생성·TTS·클라우드 브라우저를 각각 다른 API 키로 모으는 번거로움을 하나의 구독으로 대체하는 서비스입니다. 핵심은 README가 분명히 밝히는 다음 문장입니다.

You can still bring your own keys per-tool whenever you want — the gateway is per-backend, not all-or-nothing.

즉 Portal은 편의를 위한 선택지일 뿐, 백엔드별로 자기 키를 가져오는 길이 항상 열려 있습니다. 공급자 중립성이라는 원칙을 자사 서비스로 훼손하지 않으려는 설계입니다.

핵심 아키텍처: 12,000줄짜리 AIAgent 루프

Hermes의 심장은 run_agent.py의 AIAgent 클래스입니다. 개발 가이드는 이 파일이 약 1만 2천 줄에 이른다고 밝힙니다. 생성자는 약 60개의 매개변수(자격증명, 라우팅, 콜백, 세션 컨텍스트, 예산, 자격증명 풀 등)를 받지만, 본질은 run_conversation() 안의 동기식 루프입니다. 개발 가이드가 제시하는 골격은 다음과 같습니다.

while (api_call_count < self.max_iterations and self.iteration_budget.remaining > 0) \
        or self._budget_grace_call:
    if self._interrupt_requested: break
    response = client.chat.completions.create(model=model, messages=messages, tools=tool_schemas)
    if response.tool_calls:
        for tool_call in response.tool_calls:
            result = handle_function_call(tool_call.name, tool_call.args, task_id)
            messages.append(tool_result_message(result))
        api_call_count += 1
    else:
        return response.content

이 짧은 루프에 Hermes의 운영 철학이 응축돼 있습니다. 반복 횟수 상한(max_iterations, 기본 90)과 별도의 토큰 예산(iteration_budget)이라는 이중 제동 장치가 걸려 있고, 매 반복마다 사용자의 중단 요청을 확인하며, 예산이 소진돼도 한 번의 유예 호출(_budget_grace_call)을 허용해 작업을 정리할 기회를 줍니다. 메시지는 OpenAI 포맷(system/user/assistant/tool)을 따르고, 추론 내용은 assistant_msg["reasoning"]에 저장됩니다.

도구는 임포트 시점에 자동 등록되는 구조입니다. tools/registry.py가 의존성 없는 최하단에 있고, 각 tools/*.py가 임포트될 때 registry.register()를 호출하며, model_tools.py가 이를 모아 도구 발견을 촉발합니다. 현재 toolset 키는 browser·code_execution·delegation·memory·terminal·search·session_search·skills·vision·web 등 30종에 이르고, 플랫폼 어댑터가 각자 기본 toolset을 고릅니다.

학습 루프의 해부: 스킬, 큐레이터, 그리고 메모리

"자기 개선"이라는 표현의 실체가 여기 있습니다. Hermes의 학습 루프는 세 개의 서브시스템이 맞물려 돌아갑니다.

스킬: 경험에서 태어나는 절차적 메모리

Hermes의 스킬은 두 표면으로 나뉩니다. 저장소에 기본 포함되어 바로 로드되는 skills/(카테고리별 디렉터리)와, 함께 배포되지만 기본 비활성인 무겁거나 틈새 스킬 optional-skills/입니다. 후자는 hermes skills install official/<category>/<skill>로 명시적으로 설치합니다.

중요한 것은 스킬이 정적 파일에 그치지 않는다는 점입니다. 외부 리뷰들이 지적하듯, Hermes는 복잡한 작업을 마친 뒤 반복되는 패턴을 감지하면 스스로 스킬 파일을 생성합니다. 작업 실행 후 평가 계층이 결과의 성공 여부를 판단하고, 재사용 가능한 추론 패턴을 추출해 스킬로 저장합니다. 다음에 비슷한 작업을 만나면 처음부터 추론하는 대신 해당 스킬을 끌어옵니다. OpenClaw의 스킬이 사람이 쓰고 유지하는 정적 파일이라면, Hermes의 스킬은 에이전트가 사용 중에 만들고 다듬으며 세션을 넘어 복리로 쌓이는 자산이라는 점이 두 프로젝트의 결정적 차이입니다.

스킬이 컨텍스트를 잡아먹지 않도록 Hermes는 점진적 공개(progressive disclosure) 패턴을 씁니다. 에이전트는 처음에 스킬 목록만 가볍게 보고, 실제로 필요할 때만 본문을 끌어옵니다. 세 단계로 나뉩니다.

Level 0: skills_list()           → [{name, description, category}, ...]  (~3k 토큰)
Level 1: skill_view(name)        → 전체 본문 + 메타데이터               (가변)
Level 2: skill_view(name, path)  → 특정 참조 파일                       (가변)

수십 개의 스킬이 있어도 항상 드는 비용은 이름·설명 수준의 약 3천 토큰뿐이고, 무거운 절차·참조 파일은 호출 시점에만 로드됩니다. 설치된 모든 스킬은 자동으로 슬래시 명령(/<skill-name>)으로도 노출되며, 이 형식은 agentskills.io 오픈 표준과 호환됩니다.

흥미롭게도 Hermes는 스킬 작성에 엄격한 표준을 강제합니다. 개발 가이드의 "HARDLINE" 항목은 모든 스킬의 description이 한 문장, 60자 이하, 마침표로 끝나야 한다고 못 박습니다. 그 이유가 명확합니다.

Long descriptions bloat skill listings and dilute the model's attention when many skills are loaded.

즉 설명이 길면 스킬 목록이 비대해지고, 여러 스킬이 동시에 로드될 때 모델의 주의(attention)가 분산된다는 것입니다. 자기 개선 시스템이 무절제하게 스킬을 양산하면 컨텍스트가 오염된다는 위험을, 형식 규율로 방어하는 셈입니다.

큐레이터: 스킬의 생애주기 관리

에이전트가 스킬을 자동 생성한다면, 자연히 "쓰지 않는 스킬이 쌓이는" 문제가 생깁니다. Hermes는 이를 큐레이터(curator)라는 백그라운드 시스템으로 풉니다. agent/curator.py가 에이전트가 만든 스킬의 사용량을 추적하고, 오래 쓰이지 않은 것을 자동 보관(archive)합니다. 핵심 불변식이 사려 깊습니다.

• 큐레이터는 created_by: "agent" 출처의 스킬만 건드립니다. 번들 스킬과 허브 설치 스킬은 손대지 않습니다.
• 절대 삭제하지 않습니다. 가장 파괴적인 동작이 보관이며, 보관본은 ~/.hermes/skills/.archive/에 남아 복원 가능합니다.
• 핀(pin) 고정된 스킬은 모든 자동 전이와 LLM 리뷰에서 면제됩니다.

사용량은 ~/.hermes/skills/.usage.json 사이드카가 스킬별 사용 횟수·조회·패치·마지막 활동 시각·상태(active/stale/archived)로 기록합니다. 사용자는 hermes curator status|run|pause|pin|archive|restore 같은 명령으로 이 생애주기에 개입합니다. 자동으로 자라는 시스템에 "사용자가 스킬을 잃지 않는다"는 안전장치를 둔 설계입니다.

넛지와 백그라운드 리뷰: 자기개선을 발동시키는 방아쇠

스킬과 메모리가 "무엇을" 쌓는지는 봤지만, "언제·어떻게" 발동하는지가 자기개선의 실제 심장입니다. 그 장치가 agent/background_review.py의 백그라운드 리뷰 포크입니다. 파일 docstring이 성격을 압축합니다.

After every turn, AIAgent.run_conversation may call spawn_background_review to fire off a daemon thread that replays the conversation snapshot in a forked AIAgent and asks itself "should any skill/memory be saved or updated?". Writes go straight to the memory + skill stores. Main conversation and prompt cache are never touched.

작동은 카운터 두 개로 요약됩니다. 유저 턴마다 _turns_since_memory가, 한 턴 안의 툴 반복마다 _iters_since_skill이 1씩 오릅니다(agent/turn_context.py, agent/conversation_loop.py). 턴이 끝나면 agent/turn_finalizer.py가 임계를 넘었는지 확인하고, 응답을 유저에게 전달한 뒤에 리뷰 포크를 띄웁니다 — "유저의 작업과 모델 주의를 다투지 않도록" 일부러 응답 이후로 미룹니다.

리뷰 포크는 격리돼 있습니다. 부모의 런타임(공급자·모델·인증·캐시된 시스템 프롬프트)을 상속해 같은 prefix 캐시를 때리므로 저렴하고(다른 모델로 라우팅하면 전체 대신 압축 digest만 replay), 툴 화이트리스트가 memory·skill_manage로만 제한돼 다른 도구는 런타임에서 거부됩니다. 무엇을 저장할지는 두 개의 리뷰 프롬프트가 정합니다. 메모리 리뷰는 "유저가 자신의 페르소나·선호를 드러냈나, 행동 방식에 대한 기대를 표현했나"를 묻고, 스킬 리뷰는 스타일·워크플로 교정이나 새 기법이 나왔는지를 봐 로드된 스킬 패치 → 기존 umbrella 패치 → 지원 파일 추가 → 새 스킬 생성의 우선순위로 처리합니다.

여기서 두 가지를 코드로 분명히 해 둘 만합니다. 첫째, 이 "적극성"은 설계자의 취향이 아니라 프롬프트에 못박힌 지침입니다. 스킬 리뷰 프롬프트(_SKILL_REVIEW_PROMPT)는 이렇게 시작합니다.

Be ACTIVE — most sessions produce at least one skill update, even if small. A pass that does nothing is a missed learning opportunity, not a neutral outcome.

즉 시스템은 "대부분의 세션은 스킬 하나는 갱신해야 하고, 아무것도 안 한 패스는 손해"라고 스스로에게 종용합니다. 둘째, 발동 임계는 어디서 도출한 값이 아니라 하드코딩된 상수입니다. _memory_nudge_interval과 _skill_nudge_interval은 기본값 10으로 박혀 있고(agent/agent_init.py), config의 memory.nudge_interval·skills.creation_nudge_interval로만 덮어씁니다. 경험적 근거나 적응적 로직은 코드에 없습니다 — 유저 프롬프트 10개마다 메모리를, 한 턴에서 툴 반복 10회마다 스킬을 회고하라는 임의의 기본 주기일 뿐입니다.

마지막으로 문서와 코드의 결을 하나 맞춰 둡니다. 앞서 외부 리뷰를 인용해 "평가 계층이 결과의 성공 여부를 판단한 뒤 스킬로 저장한다"고 적었지만, 실제 트리거 코드에는 성공 판정이 없습니다. 리뷰는 작업의 성패와 무관하게 순전히 턴·반복 카운터로 발동합니다(응답이 있고 중단되지 않았으면 그만). 따라서 자기개선의 품질은 "성공한 궤적만 골라 학습하는" 필터가 아니라, 회고 프롬프트의 판단력과 "적극적으로 남기라"는 종용에 통째로 달려 있습니다. 큐레이터의 보관 장치와 스킬 설명 60자 규율이 왜 필요한지도 이 지점에서 분명해집니다 — 무조건 발동하고 적극적으로 쓰라는 시스템이라면, 무절제한 축적을 사후에 걸러 낼 안전장치가 반드시 뒤따라야 하기 때문입니다.

학습 루프의 세 번째 축인 메모리는 그 자체로 한 장을 차지할 만큼 정교하므로, 절을 바꿔 따로 다루겠습니다.

기억하는 에이전트: 두 파일, 그리고 무한한 세션 검색

Hermes가 "당신과 함께 성장한다"고 말할 때 그 토대가 메모리입니다. 핵심 설계는 의외로 단순하고 투명합니다. 에이전트의 영속 기억은 ~/.hermes/memories/에 놓인 두 개의 마크다운 파일로 구성됩니다.

이 분리가 의미심장합니다. 에이전트가 "환경에 대해 아는 것"(MEMORY.md)과 "당신이 누구인지"(USER.md)를 구분해 관리한다는 뜻입니다. 전자에는 "이 서버는 Debian 12에 PostgreSQL 16", "Docker 명령에 sudo 쓰지 말 것 — 사용자는 docker 그룹 소속" 같은 사실이, 후자에는 "TypeScript를 선호", "장황한 설명을 싫어함" 같은 프로필이 들어갑니다. 문서는 에이전트가 이를 알아서 저장한다고 강조합니다. 사용자가 "기억해"라고 말할 필요 없이, 선호·환경 사실·교정·규약·완료한 작업을 학습하는 순간 능동적으로 적습니다.

동결 스냅샷: 메모리와 캐시의 타협

메모리 설계에서 가장 영리한 부분은 시스템 프롬프트로 주입되는 방식입니다. 두 파일은 세션 시작 시 동결 스냅샷(frozen snapshot)으로 한 번 캡처되어 시스템 프롬프트에 박히고, 세션 도중에는 절대 바뀌지 않습니다. 주입 형태는 어느 저장소인지, 용량을 몇 퍼센트 썼는지(예: 67% — 1,474/2,200 chars), 그리고 § 구분자로 나뉜 개별 항목까지 보여 줍니다.

여기서 중요한 절충이 드러납니다. 에이전트가 세션 중에 기억을 추가·제거하면 그 변경은 디스크에 즉시 저장되지만, 시스템 프롬프트에는 다음 세션이 시작될 때까지 반영되지 않습니다. 왜 이런 불편을 감수할까요? 프롬프트의 프리픽스 캐시(prefix cache)를 보존하기 위해서입니다. 시스템 프롬프트를 세션 중간에 바꾸면 캐시가 깨지고 비용이 치솟습니다. 도구 응답은 항상 최신 상태를 보여 주므로, 에이전트는 방금 적은 기억을 도구 결과로는 즉시 확인할 수 있습니다.

memory 도구의 동작도 이 제약에 맞춰 설계됐습니다. add·replace·remove 세 액션만 있고 read는 없습니다. 메모리가 이미 시스템 프롬프트에 들어와 있어 따로 읽을 필요가 없기 때문입니다. replace와 remove는 전체 텍스트가 아니라 짧은 고유 부분 문자열(substring)로 항목을 식별합니다.

# 메모리에 "User prefers dark mode in all editors" 가 있을 때
memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

강제된 절제: 용량이 차면 통합한다

문자 제한은 단순한 제약이 아니라 철학입니다. 문서의 표현대로 "제한이 메모리를 집중시킨다(keep memory focused)". 용량을 넘기는 항목을 추가하려 하면 도구가 그냥 실패하지 않고, 현재 항목 목록과 함께 "지금 통합하라(consolidate now)"는 구체적 지시를 돌려줍니다. 에이전트는 그 자리에서 겹치는 항목을 더 짧게 병합하거나 낡은 항목을 지운 뒤 다시 추가해야 합니다. 자기 개선 시스템이 기억을 무한정 부풀리지 못하도록, 망각과 통합을 강제로 루프에 넣은 것입니다. 정확히 중복되는 항목은 자동으로 거부됩니다.

한 가지 더 주목할 점은 보안 스캔입니다. 메모리 항목은 시스템 프롬프트에 주입되므로, 받아들이기 전에 프롬프트 인젝션·자격증명 유출·SSH 백도어 같은 위협 패턴과 보이지 않는 유니코드 문자를 검사해 차단합니다. 기억이 곧 공격 표면이 될 수 있다는 점을 설계에 반영한 것입니다.

세션 검색: 토큰을 쓰지 않는 무한 기억

영속 메모리가 "항상 들고 다니는 핵심 사실"이라면, 세션 검색(session_search)은 "필요할 때 꺼내 보는 무한 아카이브"입니다. 모든 CLI·메시징 세션은 SQLite(~/.hermes/state.db)에 FTS5 전문 검색과 함께 저장됩니다. 에이전트는 몇 주 전 논의한 내용도 찾아낼 수 있고, 찾은 세션 안에서 앞뒤로 스크롤할 수도 있습니다. 두 메모리 방식의 성격 차이가 분명합니다.

핵심은 세션 검색이 LLM 호출 없이 DB 질의만으로 동작해 공짜라는 점입니다. 항상 들고 다니기엔 비싼 정보를 디스크에 무한히 쌓아 두고, 필요할 때만 약 20ms 비용으로 끌어오는 구조입니다.

외부 메모리 공급자: Honcho와 변증법적 사용자 모델링

기본 메모리 위에, Hermes는 8종의 외부 메모리 공급자 플러그인(Honcho, Mem0, Supermemory, OpenViking 등)을 제공합니다. 한 번에 하나만 활성화되며 기본 메모리는 항상 함께 돕니다. 외부 공급자가 켜지면 Hermes는 매 턴 전에 관련 기억을 백그라운드로 프리페치하고, 응답 후 대화를 동기화하며, 세션 종료 시 기억을 추출합니다.

그중 Honcho가 특히 흥미롭습니다. 변증법적(dialectic) 추론으로 세션을 넘나드는 사용자 모델을 만드는데, 두 층위의 컨텍스트 주입을 씁니다. 세션 요약·사용자 표상·피어 카드로 이뤄진 기본 층과, LLM이 합성하는 변증법 보충 층입니다. 비용과 깊이를 독립적으로 조절하도록 세 개의 직교 노브를 제공합니다. 기본 층 갱신 빈도(contextCadence), 변증법 LLM 발화 빈도(dialecticCadence), 그리고 한 번의 변증법 호출당 추론 패스 수(dialecticDepth, 1~3)입니다. 세션을 거듭할수록 "당신이 누구인지"에 대한 모델이 깊어지는 구조입니다.

캐시를 깨뜨리지 마라: 비용을 지배하는 규율

개발 가이드에서 가장 실무적으로 중요한 정책 하나는 프롬프트 캐싱입니다. 가이드는 단호하게 경고합니다.

Prompt Caching Must Not Break.

Hermes는 대화 내내 캐싱이 유효하도록 보장하며, 다음을 금지합니다. 과거 컨텍스트를 대화 중간에 바꾸는 것, toolset을 대화 중간에 바꾸는 것, 메모리를 다시 로드하거나 시스템 프롬프트를 중간에 재구성하는 것입니다. 캐시가 깨지면 비용이 극적으로 치솟기 때문입니다. 컨텍스트를 바꾸는 유일하게 허용된 순간은 컨텍스트 압축(context compression)뿐입니다.

이 원칙은 슬래시 명령 설계에까지 침투합니다. 스킬·도구·메모리 같은 시스템 프롬프트 상태를 바꾸는 명령은 기본적으로 "지연 무효화(deferred invalidation)"를 택해 변경이 다음 세션부터 적용되게 하고, 즉시 적용이 필요하면 --now 플래그를 명시적으로 붙이게 합니다. 자기 개선 에이전트가 끊임없이 상태를 바꾸려는 본성과, 캐시 안정성이라는 비용 현실 사이의 긴장을 정교하게 중재하는 설계입니다.

위임, 크론, 칸반: 단일 에이전트를 넘어서

Hermes는 한 에이전트의 루프에 머물지 않습니다.

위임(delegate_task)은 격리된 컨텍스트와 터미널 세션을 가진 서브에이전트를 띄웁니다. 동기식이라 부모가 자식의 요약을 받을 때까지 기다리며, 부모가 중단되면 자식도 취소됩니다. 단일 작업과 병렬 배치 두 형태가 있고, 동시 자식 수는 기본 3으로 제한됩니다. 역할도 나뉘는데, 기본 leaf는 더 위임할 수 없는 집중형 작업자이고, orchestrator는 자기 작업자를 다시 띄울 수 있되 생성 깊이가 기본 2로 묶입니다. 가이드는 중요한 단서를 답니다. 위임은 내구적(durable)이지 않으므로, 현재 턴을 넘겨 살아남아야 하는 장기 작업에는 cronjob이나 백그라운드 터미널을 쓰라는 것입니다.

크론(cron)은 내장 스케줄러입니다. 흥미로운 일화가 저장소에 문서로 남아 있습니다. hermes-already-has-routines.md는 Anthropic이 발표한 Claude Code Routines(예약 작업·GitHub 이벤트 트리거·API 트리거)에 대해 "좋은 기능이지만 우리는 두 달 전에 출시했다"고 응수합니다. Hermes의 크론은 5필드 cron 표현식뿐 아니라 "30m"·"every monday 9am" 같은 사람이 읽는 간격을 받고, 작업 전에 Python 스크립트를 실행해 그 stdout을 프롬프트에 주입하며(--script), 여러 스킬을 엮고, Telegram·Discord·Slack·SMS·이메일·로컬 파일 등 어디로든 배달합니다. 하루 실행 한도가 없고 모델도 자유롭게 고른다는 점을 차별점으로 내세웁니다. 운영 안전을 위해 크론 세션에는 3분 하드 인터럽트가 걸려 폭주 루프가 스케줄러를 독점하지 못하게 합니다.

칸반(kanban)은 여러 프로필·워커가 공유 작업을 협업하는 SQLite 기반 보드입니다. 보드를 하드 경계로 삼아 워커는 다른 보드를 볼 수 없고, 같은 작업에서 연속 실패가 한도(기본 2)를 넘으면 디스패처가 자동으로 작업을 차단해 무한 재시도를 막습니다.

연구 도구로서의 Hermes: trajectory 압축

앞서 언급한 Hermes의 연구적 정체성이 가장 잘 드러나는 곳이 trajectory_compressor.py입니다. 이 모듈은 완료된 에이전트 trajectory(에이전트가 작업을 수행하며 남긴 대화·도구 호출의 전체 기록)를 학습 신호 품질을 보존하면서 목표 토큰 예산 안으로 압축합니다. 모듈 상단의 설명이 그 전략을 명확히 밝힙니다.

압축은 무차별적이지 않습니다. 첫 턴들(system, human, 첫 gpt, 첫 tool)을 보호하고, 마지막 N개 턴(최종 행동과 결론)을 보호하며, 중간 턴만 두 번째 도구 응답부터 압축하되 목표 예산에 맞을 만큼만 줄입니다. 압축된 구간은 하나의 human 요약 메시지로 대체되고, 나머지 도구 호출은 그대로 둬서 모델이 요약 이후에도 작업을 이어 가게 합니다. 이는 Hermes가 단지 비서가 아니라, 자신이 만들어 낸 작업 기록을 다음 세대 도구 호출 모델의 학습 데이터로 재활용하는 파이프라인의 한 단계임을 보여 줍니다. 배치 trajectory 생성(batch_runner.py)과 짝을 이루는 기능입니다.

실전 가이드: 설치와 첫 대화

Hermes는 설치 스크립트 한 줄로 시작합니다. 저장소가 제시하는 경로는 다음과 같습니다.

# Linux, macOS, WSL2, Termux
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

설치 스크립트는 uv, Python 3.11, Node.js, ripgrep, ffmpeg를 모두 처리하며, Windows에서는 시스템 Git과 격리된 휴대용 Git Bash(MinGit)까지 자동으로 갖춥니다. 설치 후 흐름은 간결합니다.

source ~/.bashrc    # 셸 리로드 (또는 ~/.zshrc)
hermes              # 대화 시작

핵심 명령들은 직관적입니다. hermes model로 공급자·모델을 고르고, hermes tools로 활성 도구를 설정하며, hermes gateway로 메시징 게이트웨이를 띄우고, hermes setup으로 전체 설정 마법사를 한 번에 돌립니다. OpenClaw에서 넘어오는 경우 hermes claw migrate --dry-run으로 무엇이 옮겨질지 먼저 미리 볼 수 있습니다.

기여자라면 setup-hermes.sh로 클론 즉시 개발 환경을 갖춥니다.

git clone https://github.com/NousResearch/hermes-agent.git
cd hermes-agent
./setup-hermes.sh   # uv 설치, venv 생성, .[all] 설치, ~/.local/bin/hermes 심볼릭 링크
./hermes            # venv 자동 감지

사용자 설정은 ~/.hermes/config.yaml(설정)과 ~/.hermes/.env(API 키 전용)로 분리되고, 로그는 ~/.hermes/logs/에 agent.log·errors.log·gateway.log로 남아 hermes logs --follow로 추적합니다. 테스트 스위트는 2026년 5월 기준 약 900개 파일에 1만 7천여 개의 pytest 테스트로, 빠르게 자라는 프로젝트치고는 견고한 검증 기반을 갖췄습니다.

정리하며

Hermes Agent를 한 문장으로 요약하면, "당신과 함께 성장하는, 당신의 인프라 위에서 돌아가는 모델 중립적 에이전트"입니다. 기술적으로 이 프로젝트가 증명한 것을 세 가지로 정리합니다.

첫째, "자기 개선"은 수사가 아니라 세 서브시스템의 협업으로 구현된 실체였습니다. 경험에서 스킬을 생성하고(스킬 시스템), 쓰이지 않는 스킬을 안전하게 정리하며(큐레이터), 세션을 넘어 사용자와 맥락을 회상합니다(메모리·FTS5·Honcho). 자동으로 자라는 시스템에 "삭제하지 않는다", "60자 제한" 같은 절제의 규율을 함께 설계한 점이 인상적입니다.

둘째, Hermes는 비용과 운영 현실을 정면으로 다룹니다. 프롬프트 캐시를 깨지 않는다는 강박에 가까운 규율, 반복·토큰 이중 예산과 유예 호출, 크론의 3분 하드 인터럽트, 위임 깊이 제한, 칸반의 자동 차단까지 — 폭주와 비용 폭발을 막는 제동 장치가 곳곳에 박혀 있습니다.

셋째, Hermes는 연구 도구이자 사용자 도구라는 이중 정체성을 지닙니다. trajectory 생성과 압축은 이 에이전트가 만들어 내는 작업 기록을 다음 세대 도구 호출 모델의 학습 자원으로 되먹이는 파이프라인의 일부입니다. 사용자가 일을 시킬수록 모델 생태계가 성장하는 구조입니다.

OpenClaw가 같은 계보의 출발선이었다면, Hermes는 거기에 "학습 루프"라는 차별점을 얹어 OpenRouter 1위까지 올라선 후발 주자입니다. 두 프로젝트가 보여 주는 것은 분명합니다. 2026년의 개인 AI 에이전트 경쟁은 "더 큰 모델"이 아니라 "기억하고, 배우고, 자기 인프라 위에서 끈질기게 돌아가는" 능력으로 옮겨 가고 있다는 사실입니다.

참고: 본문의 아키텍처·기능 서술은 NousResearch/hermes-agent 저장소의 README, AGENTS.md, trajectory_compressor.py, hermes-already-has-routines.md를 직접 인용·요약했으며, 채택·비교 관련 외부 맥락은 아래 출처를 참고했습니다.

• GitHub — NousResearch/hermes-agent
• Hermes Unlocks Self-Improving AI Agents — NVIDIA Blog
• OpenClaw vs Hermes Agent: Why Nous Research's Self-Improving Agent Now Leads OpenRouter's Rankings — MarkTechPost
• Migrate from OpenClaw — Hermes Agent Docs