Hermes Agent vs HyperAgents 2026 — 오래 쓸수록 더 나아지는 쪽은 누구고 실사용에선 뭐가 다른가

Posted on by

2026년 4월 13일 기준 Hermes Agent 공식 문서는 memory, skills, sessions, messaging, cron을 운영 기능의 중심으로 설명한다.

같은 날짜 기준 HyperAgents는 arXiv 2603.19461 논문과 공식 GitHub 레포에서 task agent와 meta agent를 하나의 editable program으로 묶는 자기개선 프레임워크로 소개된다.

문제는 여기서 시작된다.

둘 다 설명만 보면 점점 더 나아지는 에이전트 처럼 들린다.

그래서 처음 보면 같은 카테고리의 경쟁 제품처럼 읽히기 쉽다.

근데 실제로는 다르다.

Hermes는 에이전트를 더 오래, 더 자주, 더 자연스럽게 쓰게 만들면서 점점 실무 성능이 좋아지는 쪽이다.

반면 HyperAgents는 에이전트가 자기 자신과 자기개선 절차를 어떻게 더 잘 고칠 수 있는지를 실험하는 쪽이다.

즉 하나는 운영형 성장,

다른 하나는 구조적 자기개선 이다.

이 차이를 놓치면 Hermes를 개인 비서가 아니라 연구 프레임워크처럼 오해하고, HyperAgents를 오늘 바로 쓸 수 있는 런타임처럼 오해하게 된다.

그래서 이 글은 이름이 비슷하다는 수준의 비교가 아니라 동작 방식, 사용 흐름, 기억 구조, 자동화 방식, 실무 적합도 기준으로 둘을 정면 비교해보려는 글이다.

지금 결론

질문 Hermes Agent HyperAgents
정체가 뭔가 운영형 에이전트 런타임 자기개선 연구 프레임워크
무엇이 쌓이면서 좋아지나 기억, 세션, 스킬, 사용자 모델 에이전트 코드와 메타 수정 절차
사용 시작점은 뭔가 hermes CLI, gateway, cron, skills setup_initial.sh, generate_loop.py, 도메인 평가
주 사용자는 누구인가 오래 일하는 비서형 에이전트를 원하는 사람 자기개선 루프를 실험하려는 연구자/엔지니어
실무에서 바로 쓰기 쉬운 쪽은 높음 낮음
하네스 관점에서 더 자극적인 쪽은 부분적 HyperAgents
내 볼트/Jarvis 체계와 더 닮은 쪽은 Hermes의 운영 느낌 + 하네스 외곽 HyperAgents의 메타 루프 아이디어

짧게 줄이면 이렇다.

  • Hermes는 더 잘 기억하는 운영형 집사다.
  • HyperAgents는 더 잘 자기 자신을 고치려는 실험실이다.
  • 둘 다 성장한다는 말을 쓰지만,
    하나는 운영형 성장이고, 다른 하나는 구조적 자기개선이다.

3초 선택법도 가능하다.

  • 오늘부터 AI 비서를 붙여 보고 싶다 -> Hermes 쪽이다.
  • 에이전트가 자기 하네스까지 스스로 개선하는 구조가 궁금하다 -> HyperAgents 쪽이다.
  • 둘 다 욕심난다 -> 운영은 Hermes 감각으로 보고, 메타 개선은 HyperAgents 감각으로 따로 가져가는 편이 덜 꼬인다.

이런 상황이면 이 비교가 바로 필요하다

  • 요즘 헤르메스가 점점 똑똑해진다는 말을 들었는데 그게 memory인지 학습인지 헷갈리는 사람
  • HyperAgents를 보고 이거 개인 비서처럼 바로 쓰는 제품인가 하고 궁금했던 사람
  • Obsidian, Codex, Telegram, cron 같은 운영형 AI 비서를 만들고 싶은 사람
  • 하네스를 사람이 계속 손으로 짜야 하나, 에이전트가 스스로 개선하게 만들 수는 없나 고민하는 사람
  • 제품 고르기보다 어느 층의 문제를 푸는 도구인가를 먼저 정리하고 싶은 사람

왜 자꾸 같은 말처럼 들릴까

둘 다 설명문에서 self-improving, memory, skills, agent 같은 단어를 자주 쓴다.

그러니 처음 보면 당연히 같은 계열처럼 보인다.

하지만 이건 클라우드랑 쿠버네티스를 한 덩어리로 보는 느낌에 가깝다.

둘이 만나는 지점은 있어도, 직접 비교할 때는 어느 층의 문제를 푸는지부터 갈라야 한다.

네가 원하는 게 텔레그램에서도 부를 수 있고, 예전 대화도 기억하고, 예약 업무도 돌리는 AI 비서 라면 Hermes 쪽 질문이다.

반대로 네가 원하는 게 에이전트가 자기 task loop와 meta loop를 반복적으로 고치면서 더 나은 버전으로 가는 구조 라면 HyperAgents 쪽 질문이다.

겉모습은 둘 다 에이전트인데, 현장에서 만지는 레버는 완전히 다르다.

내가 직접 본 범위와 문서로 확인한 범위

이 비교는 여기서 선을 먼저 긋는 게 맞다.

내가 직접 오래 굴려본 건 Hermes와 HyperAgents 그 자체라기보다, Jarvis + Harness + LLM Wiki + Obsidian 조합에 더 가깝다.

그래서 이 글은 내가 두 제품을 동일 조건에서 수주 동안 프로덕션 운영했다 는 후기가 아니다.

대신 아래 범위는 꽤 분명하다.

  • Hermes는 2026년 4월 13일 기준 공식 docs와 README가 무엇을 핵심 기능으로 밀고 있는지 확인했다.
  • HyperAgents는 2026년 3월 19일 제출된 arXiv 2603.19461 초록과 공식 GitHub 레포 구조를 확인했다.
  • 그리고 그 내용을
    내가 실제로 운영 중인 하네스 감각에 대입해 실무에서 어떤 종류의 도구로 읽히는가 기준으로 번역했다.

이 선을 분리해두는 이유는 간단하다.

이 글의 목적은 과장된 승부 예측이 아니라, 둘이 어디서 다르고 어떤 사람에게 각각 맞는지 헷갈리지 않게 정리하는 데 있다.

한 줄 정의부터 다시 놓자

Hermes Agent는 모델 자체가 아니라 여러 모델 위에 기억, 도구, 세션, 스킬, 메신저, 예약 실행을 얹어 오래 일하는 에이전트처럼 굴리게 만드는 런타임이다.

HyperAgents는 task agent와 meta agent를 하나의 수정 가능한 프로그램으로 통합해 자기 자신과 자기개선 절차를 함께 고치는 구조를 실험하는 프레임워크다.

이 정의만 이해해도 둘이 왜 같은 선상에서 1대1 제품 비교가 잘 안 되는지 감이 온다.

Hermes는 이미 사용자를 향해 있다.

HyperAgents는 여전히 에이전트 자체를 향해 있다.

즉 Hermes는 나한테 어떤 경험을 주나 가 중심이고,

HyperAgents는 에이전트 시스템을 어떻게 더 나은 구조로 만들 수 있나 가 중심이다.

핵심 차이를 한 장으로 보면

축 Hermes Agent HyperAgents
중심 질문 에이전트를 오래, 안전하게, 여러 채널에서 어떻게 굴릴까 에이전트가 자기 자신과 수정 절차를 어떻게 개선할까
성장 메커니즘 기억 축적, 세션 회수, 스킬 자산화, 채널 확장 수정본 생성, 평가, 선택, 메타 절차 수정
실행 단위 대화 세션, cron job, gateway target generation loop, domain eval, parent selection
결과물 더 편한 에이전트 경험, 자동화, 메시지, 파일 작업 더 나은 agent variant, diff, output, 분석 결과
사용 맥락 개인 비서, CLI assistant, automation runtime 연구, 하네스 실험, 자기개선 구조 탐색
장애물 기능 폭이 넓어 복잡해질 수 있음 평가 환경 없으면 개선이 무의미해짐
바로 써먹기 높음 낮음
설계 영감 운영형 비서 플랫폼 메타 하네스 엔지니어링

이 표에서 제일 중요한 줄은 실행 단위다.

Hermes의 하루는 세션과 툴 호출과 스케줄로 흘러간다.

HyperAgents의 하루는 루프와 평가와 패치와 선택으로 흘러간다.

같은 agent라는 단어를 쓰지만, 손에 잡히는 리듬이 다르다.

Hermes는 어떻게 점점 더 나아지나

Hermes가 쓸수록 똑똑해진다는 말은 모델 파라미터가 자동으로 재학습된다는 뜻은 아니다.

공식 문서 기준으로 Hermes의 성장 축은 꽤 명확하다.

첫째, MEMORY.md와 USER.md라는 bounded memory가 있다.

2026년 4월 13일 기준 공식 memory 문서는 MEMORY.md를 에이전트 개인 메모, USER.md를 사용자 프로필로 설명한다.

둘은 세션 시작 시 시스템 프롬프트에 주입되고, agent가 memory tool로 add, replace, remove를 수행할 수 있다.

이게 중요한 이유는 항상 들어와 있어야 할 사실과 선호가 다음 세션에 바로 살아남기 때문이다.

둘째, 과거 세션 전체를 검색할 수 있다.

Hermes docs는 모든 CLI와 messaging 세션이 SQLite에 저장되고, session_search로 예전 대화를 찾을 수 있다고 설명한다.

즉 memory가 포켓 메모라면, session search는 창고에 가깝다.

셋째, 복잡한 작업 절차를 skill로 남길 수 있다.

공식 skills 문서는 이걸 agent의 procedural memory라고 부른다.

작업이 길었거나, 사용자 수정이 들어왔거나, 에러를 거쳐 결국 맞는 경로를 찾았을 때 그 절차를 SKILL로 저장해 다음에도 재사용할 수 있다는 뜻이다.

넷째, context files를 자동으로 읽는다.

Hermes docs의 기능 개요는 .hermes.md, AGENTS.md, CLAUDE.md, SOUL.md, .cursorrules 같은 문맥 파일을 자동 발견해서 에이전트 행동을 shaped한다고 설명한다.

즉 Hermes가 똑똑해지는 느낌은 아래 네 층이 합쳐져서 생긴다.

  1. 핵심 기억이 남는다.
  2. 예전 대화를 다시 찾을 수 있다.
  3. 반복 절차가 skill로 자산화된다.
  4. 프로젝트 규칙을 자동으로 먹는다.

그래서 Hermes의 성장 방식은 기억과 절차의 누적이라고 부르는 게 가장 정확하다.

HyperAgents는 어떻게 점점 더 나아지나

HyperAgents가 말하는 자기개선은 Hermes보다 훨씬 공격적이다.

arXiv 2603.19461 초록은 HyperAgents를 task agent와 meta agent를 하나의 editable program으로 통합한 self-referential agent framework라고 소개한다.

그리고 핵심 문장은 이거다.

meta-level modification procedure itself is editable

즉 task를 푸는 agent만 고치는 게 아니다.

앞으로 무엇을, 어떤 기준으로, 어떻게 고칠지 정하는 상위 절차 자체도 수정 대상으로 올린다.

이건 운영형 memory와는 결이 다르다.

Hermes가 다음엔 이 사용자 취향을 기억하자 쪽이라면,

HyperAgents는 다음엔 나를 고치는 방식 자체를 바꾸자 쪽이다.

GitHub 레포 구조도 그걸 그대로 드러낸다.

README 기준 2026년 4월 13일에 확인되는 핵심 파일은 이렇다.

  • generate_loop.py
  • run_meta_agent.py
  • meta_agent.py
  • task_agent.py
  • select_next_parent.py
  • domains/
  • analysis/
  • outputs/

즉 HyperAgents의 기본 리듬은 대화 세션이 아니라 생성 -> 평가 -> 선택 -> 반복 이다.

그래서 HyperAgents의 성장 방식은 코드와 메타 절차의 반복 개량 이라고 부르는 편이 맞다.

이 차이를 놓치면 둘 다 self-improving이라는 문장만 보고 같은 종류의 똑똑함으로 오해하게 된다.

Hermes의 실제 동작 루프는 어떤 느낌인가

Hermes의 공식 quickstart와 CLI 문서를 기준으로 보면 진입 흐름은 꽤 사용자 친화적이다.

설치는 one-line installer를 제공한다.

2026년 4월 13일 기준 quickstart는 Linux, macOS, WSL2에서 아래 설치 흐름을 제시한다.

curl -fsSL <https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh> | bash
source ~/.zshrc
hermes setup
hermes

그 다음부터의 흐름은 전형적인 운영형 agent runtime에 가깝다.

사용자 요청
-> 시스템 프롬프트 조립
-> memory/context 주입
-> 모델 호출
-> tool 필요 시 호출
-> 결과 반영
-> 응답
-> 세션 저장
-> 필요하면 memory/skill 갱신

여기서 중요한 건 이 루프가 매일 쓰는 경험과 바로 연결된다는 점이다.

예를 들어 Hermes docs는 아래 같은 사용 흐름을 공식 예시로 둔다.

  • 터미널 명령 대신 agent에게 요청하기
  • /tools, /model, /skills 같은 인터페이스로 기능 탐색하기
  • hermes --continue로 이전 세션 이어가기
  • hermes gateway setup으로 Telegram/Discord/Slack 연결하기
  • 자연어 또는 /cron add로 예약 업무 만들기

즉 Hermes는 처음부터 사용자를 중심으로 설계된 loop다.

대화가 출발점이고, 운영 기능이 그 대화를 장기화한다.

HyperAgents의 실제 동작 루프는 어떤 느낌인가

HyperAgents는 진입점부터 분위기가 다르다.

공식 GitHub README에 따르면 2026년 4월 13일 확인 기준 기본 실행 흐름은 아래처럼 잡혀 있다.

python3.12 -m venv venv_nat
source venv_nat/bin/activate
pip install -r requirements.txt
pip install -r requirements_dev.txt
bash ./setup_initial.sh
python generate_loop.py --domains <domain>

README는 기본 출력이 outputs/ 디렉터리에 저장된다고 설명하고, 핵심 실행 파일을 loop 구조 중심으로 소개한다.

이 사용 흐름이 말해주는 건 명확하다.

HyperAgents는 agent에게 말을 걸어 일 시키는 제품 이라기보다,

agent self-improvement 실험을 돌리는 시스템 에 가깝다.

실제 루프를 사람 언어로 번역하면 대략 이런 느낌이다.

초기 agent 준비
-> task 수행
-> meta agent가 task agent와 자기 자신을 수정
-> 수정본 평가
-> 더 나은 부모 선택
-> 다음 세대 생성
-> 결과 보관 및 분석

즉 HyperAgents에서 사용자 경험은 대화창보다 실험 루프 바깥에 있다.

사람은 operator에 가깝고, agent는 실험 대상이자 실험자다.

이게 Hermes와 가장 크게 갈라지는 지점이다.

언제는 굳이 안 써도 된다

둘 다 멋있어 보이지만, 항상 필요한 건 아니다.

네가 원하는 게 그냥 지금 있는 챗봇에 질문 몇 개 더 정확히 하는 정도라면 Hermes도 HyperAgents도 과할 수 있다.

Hermes는 memory, sessions, gateway, cron, toolsets를 만지는 순간 운영 판단이 따라온다.

즉 대답만 잘해주면 됨 상태라면 굳이 장기 실행형 runtime까지 들일 이유가 약하다.

HyperAgents는 더하다.

평가 환경도 없고, 도메인도 안 정했고, 수정본이 좋아졌는지 판별할 기준도 없는데 자기개선 loop부터 붙이면 멋있게 복잡해지기만 쉽다.

그래서 보통은 이렇게 생각하면 된다.

  • 그냥 답변 품질만 조금 올리고 싶다 -> 기존 도구 운영부터 다듬기
  • 오래 일하는 비서가 필요하다 -> Hermes류 고민 시작
  • 에이전트 구조 자체를 진화시키고 싶다 -> HyperAgents류 고민 시작

사용법만 놓고 보면 뭐가 더 어렵나

실사용 기준으로는 Hermes가 훨씬 쉽다.

이건 성능 비교가 아니라 도구 종류의 차이다.

Hermes는 설치 후 바로 hermes를 열고 대화부터 시작할 수 있다.

공식 quickstart도 60초 안에 시작 흐름을 전면에 둔다.

반면 HyperAgents는 환경 구성, 평가 도메인, 루프 실행, 출력 해석이 먼저다.

이건 IDE assistant를 켜는 경험이 아니라 실험 harness를 띄우는 경험에 더 가깝다.

실무에서 체감되는 차이는 아래처럼 정리된다.

질문 Hermes HyperAgents
설치 후 바로 대화 가능 가능 사실상 목적이 다름
메신저 연동 가능 공식 기능 없음에 가깝다
예약 업무 가능 공식 cron 기능 해당 방향 아님
내 프로젝트 규칙 자동 반영 context files 직접 하네스로 설계해야 함
반복 절차 재사용 skills 코드/절차 개량 차원
일반 사용자의 진입 난이도 낮은 편 높은 편

즉 네가 원하는 게 오늘부터 써볼 수 있는가 라면 Hermes다.

네가 원하는 게 하네스 구조를 얼마나 멀리 밀 수 있는가 라면 HyperAgents다.

기억 구조는 어디서 제일 크게 갈리나

이 부분이 사실 제일 중요하다.

왜냐하면 많은 사람이 기억한다 = 자기개선한다 로 뭉뚱그리기 때문이다.

Hermes의 memory는 bounded, curated, persistent memory다.

공식 문서 기준으로 MEMORY.md는 약 2200자, USER.md는 약 1375자 제한을 가진다.

세션 시작 시 시스템 프롬프트에 들어가고, 이후 session search로 과거 기록을 뒤진다.

즉 Hermes memory는 항상 들고 다닐 핵심만 압축하는 구조다.

이건 실무적으로 굉장히 현실적이다.

무한 기억 환상보다, 항상 필요한 것과 필요할 때 찾을 것을 분리하기 때문이다.

HyperAgents가 논문에서 말하는 memory는 그런 사용성 memory보다 메타 개선의 일부로 읽는 게 맞다.

네 HyperAgents 글에서도 정리했듯 persistent memory, performance tracking, evaluation 같은 요소는 실무 하네스 조각 으로 번역된다.

즉 HyperAgents의 memory는 비서형 기억이라기보다 자기개선 루프의 재료에 가깝다.

둘의 차이를 거칠게 말하면 이렇다.

  • Hermes memory는 나와 지금 잘 일하기 위한 기억
  • HyperAgents memory는 다음 세대를 더 잘 만들기 위한 메타 재료

이 차이를 이해하면 왜 Hermes는 눈치가 늘어나는 집사처럼 느껴지고, HyperAgents는 자기 훈련법을 손보는 연구체처럼 느껴지는지 설명된다.

스킬은 둘 다 쓰는가

겉으로 보면 둘 다 절차를 쌓는다 는 말이 가능하다.

그런데 실제 형태는 다르다.

Hermes의 skills는 공식 문서가 직접 procedural memory라고 부른다.

즉 사람이 반복해서 시키는 업무나, agent가 어렵게 찾아낸 정답 경로를 SKILL 문서로 저장해 다음에도 꺼내 쓰는 방식이다.

이건 SOP, 플레이북, 재사용 가능한 절차 카드에 가깝다.

반면 HyperAgents는 절차를 독립 skill 문서로 쌓는 제품이라기보다, 에이전트 프로그램과 메타 절차 자체를 수정 가능한 대상으로 본다.

즉 Hermes는 작업법을 남긴다 이고,

HyperAgents는 작업법을 짜는 구조 자체를 고친다 에 더 가깝다.

그래서 두 시스템의 학습 흔적도 다르게 남는다.

  • Hermes는 skill library가 늘어난다.
  • HyperAgents는 agent variant와 meta procedure가 달라진다.

사용자 입장에서 더 체감되는 쪽은 당연히 Hermes다.

왜냐하면 내가 다시 부를 때 바로 효용으로 돌아오기 때문이다.

HyperAgents는 그보다 한 단계 뒤에서 agent의 내부 진화 메커니즘을 바꾼다.

자동화와 채널은 누가 더 강한가

이건 거의 Hermes 압승이다.

Hermes 공식 docs와 홈페이지는 CLI, Telegram, Discord, Slack, WhatsApp, Signal, Email, Webhooks 같은 채널 이야기를 꽤 적극적으로 한다.

그리고 cron 기능도 단순 외부 스케줄러 래핑이 아니라 agent session을 fresh하게 다시 띄워 작업을 수행하게 하는 방향으로 설계돼 있다.

2026년 4월 13일 기준 cron 문서는 명시적으로 이렇게 말한다.

  • cron jobs run in a completely fresh agent session
  • cron-run sessions cannot recursively create more cron jobs
  • zero, one, or multiple skills를 붙일 수 있다

이건 상당히 실전적인 설계다.

자동화는 편하지만 자기복제형 스케줄 지옥은 막아야 하기 때문이다.

반면 HyperAgents는 자동화 채널 플랫폼이라기보다 연구 코드에 가깝다.

메신저에 붙고, 예약 업무를 돌리고, 일상적인 사용자 인터페이스를 넓히는 쪽은 핵심 축이 아니다.

그래서 채널과 자동화 관점에서 둘을 비교하면 사실 대결 자체가 잘 안 된다.

Hermes는 원래 그걸 하려고 나온 놈이고,

HyperAgents는 원래 그걸 하려고 나온 놈이 아니다.

안전성과 통제는 어떻게 다른가

이 축도 실무에선 꽤 중요하다.

Hermes는 운영형 runtime이기 때문에 기본적으로 도구 노출 범위, terminal backend, gateway 연결, memory injection, cron 실행 같은 현실 문제를 다뤄야 한다.

공식 quickstart조차 Docker isolation이나 SSH backend 설정을 안전 옵션으로 안내한다.

즉 Hermes의 안전성 질문은 이 agent가 어디까지 할 수 있나 와 연결된다.

도구가 많고 채널이 넓을수록 통제 기준이 중요해진다.

HyperAgents의 안전성 질문은 조금 다른 방향이다.

여기서는 이 자기개선 루프가 무엇을 최적화하며, 평가가 잘못되면 어디로 튈 수 있나 가 핵심에 가깝다.

실험 loop가 과적합되거나, 평가 함수가 빈약하거나, 도메인 정의가 부실하면 좋아진 척하는 수정본만 쌓일 수 있다.

즉 Hermes는 권한과 채널의 안전이 중요하고,

HyperAgents는 평가와 자기개선 신호의 안전이 중요하다.

둘 다 어렵지만 어려움의 위치가 다르다.

실사용 예시로 보면 더 분명해진다

예시 1. 아침마다 AI 뉴스 요약 받아보기

이건 Hermes 문제다.

Hermes라면 Telegram 연결 후 cron으로 매일 오전 9시에 요약을 보내게 만들 수 있다.

memory에 내가 좋아하는 소스나 말투를 남기고, skill로 요약 형식을 굳히면 점점 덜 설명해도 되는 비서가 된다.

HyperAgents로는 이걸 바로 해결하는 게 자연스럽지 않다.

물론 장기적으로 요약 agent를 더 좋게 만드는 실험은 가능하겠지만, 당장 아침 9시 요약을 보내는 제품 경험은 아니다.

예시 2. 에이전트가 실패한 뒤 다음 버전에선 덜 실패하게 만들기

이건 HyperAgents 질문에 훨씬 가깝다.

단순 memory 업데이트를 넘어 task agent와 meta agent를 어떻게 수정할지, 무엇을 평가하고 어떤 parent를 선택할지, 메타 절차를 어떻게 바꿀지가 중심이기 때문이다.

Hermes도 실패 경험을 skill이나 memory로 남겨 비슷한 실수를 덜 할 수는 있다.

하지만 그건 운영형 축적이지 자기개선 알고리즘 자체는 아니다.

예시 3. Obsidian, Codex, Telegram을 한 덩어리처럼 묶고 싶다

이건 네 시스템 맥락에선 Hermes 쪽 아이디어가 더 가깝다.

왜냐하면 네가 원하는 건 지금 당장 잘 부르고, 기억하고, 채널을 넘나들고, 반복 절차를 자산화하는 흐름이기 때문이다.

다만 HyperAgents는 여기서 전혀 쓸모없는 게 아니다.

오히려 하네스 개선 항목을 사람이 다 손으로 짜야 하나 라는 질문에는 HyperAgents가 강한 자극을 준다.

즉 실사용 레이어는 Hermes에 가깝고, 하네스 진화 아이디어는 HyperAgents에서 가져올 게 많다.

결국 누구에게 뭐가 맞나

Hermes가 더 맞는 사람

  • 에이전트를 실제로 매일 부르고 싶은 사람
  • CLI와 메신저를 넘나드는 비서형 경험이 필요한 사람
  • 기억, 세션, 스킬, 자동화를 한 제품 안에서 보고 싶은 사람
  • 내 프로젝트 규칙 파일을 자동으로 읽는 런타임이 필요한 사람
  • 당장 운영 가능한 도구를 찾는 사람

HyperAgents가 더 맞는 사람

  • 에이전트 자기개선 구조를 연구하는 사람
  • task agent와 meta agent의 상호작용을 실험하고 싶은 사람
  • generate-evaluate-select loop를 하네스 수준에서 다뤄보고 싶은 사람
  • 운영형 비서보다 자기개선 프레임워크에 더 흥미가 있는 사람
  • 평가 환경과 실험 인프라를 직접 다룰 수 있는 사람

둘 다 참고할 가치가 있는 사람

  • 내 agent stack을 직접 만들고 있는 사람
  • 하네스 엔지니어링에 진심인 사람
  • 운영형 비서와 자기개선 loop를 언젠가 연결해보고 싶은 사람
  • 단순 채팅 UX보다 장기 시스템 설계에 관심 있는 사람

자주 하는 착각 TOP 5

1. Hermes가 더 똑똑해진다 = 모델이 자동 재학습된다

아니다.

Hermes는 기본적으로 memory, session recall, skills, context files, 채널 확장 덕분에 실무 성능이 더 좋아지는 쪽이다.

즉 모델 IQ가 커진다기보다 내 맥락에 더 잘 맞는 운영형 agent 가 된다.

2. HyperAgents도 결국 memory 있는 agent니까 Hermes랑 비슷하다

비슷한 단어만 겹칠 뿐 중심 관심사가 다르다.

HyperAgents의 memory는 메타 개선 loop의 일부로 읽어야 한다.

Hermes의 memory는 사용자와 환경에 대한 지속 기억이다.

3. HyperAgents는 곧바로 개인 비서처럼 쓸 수 있다

그렇게 읽으면 실망하기 쉽다.

공식 레포 구조와 실행 흐름은 사용자-facing assistant라기보다 research harness에 훨씬 가깝다.

4. Hermes는 그냥 챗봇에 기능 몇 개 더 붙인 거다

그렇게 보기엔 세션 저장, memory, skills, gateway, cron, context files, toolsets, session resume까지 운영 기능 비중이 꽤 높다.

그래서 챗봇보다 운영형 agent runtime이라고 보는 편이 맞다.

5. 둘 중 하나만 고르면 된다

꼭 그렇진 않다.

실무에선 Hermes 같은 운영형 발상과 HyperAgents 같은 자기개선 발상을 다른 층에서 동시에 참고할 수 있다.

오히려 좋은 시스템은 운영과 진화를 섞어서 본다.

내 시스템 기준으로 번역하면

이 대목은 네가 제일 궁금한 부분일 가능성이 크다.

네 볼트 기준으로 보면 Hermes는 한 명의 장기 실행형 집사 에 가깝다.

기억을 남기고, 메신저와 스케줄에 붙고, 반복 절차를 skill로 굳히고, 세션을 이어 간다.

반면 HyperAgents는 그 집사가 자기 매뉴얼과 자기 훈련법을 계속 고치는 구조 에 가깝다.

Jarvis, Harness, LLM Wiki, Obsidian 시스템으로 번역하면 더 선명해진다.

  • Hermes는 운영형 frontdoor + 지속 기억 + 실행 채널 쪽 아이디어
  • HyperAgents는 메타 하네스 루프와 자기수정 쪽 아이디어

그래서 현실적인 조합은 대개 이렇다.

  1. 당장 굴릴 시스템은 Hermes류 감각으로 만든다.
  2. 하네스 개선 항목은 HyperAgents류 감각으로 재설계한다.
  3. 운영형 agent와 자기개선 loop를 같은 층에 섞지 않는다.

이게 중요한 이유는 두 아이디어를 한 군데에 우겨 넣으면 복잡도만 올라가고 설명은 흐려지기 때문이다.

그래서 어떤 글감이 더 센가

블로그 소재 관점에서도 둘은 다르게 먹힌다.

Hermes 글은 비서형 경험, 장기 기억, 텔레그램, 자동화, 실제로 써먹는 느낌 에서 클릭이 난다.

HyperAgents 글은 자기개선, meta agent, editable program, 하네스 진화, 미래형 설계 철학 에서 관심을 끈다.

즉 Hermes는 독자에게 바로 손이 가게 만들고,

HyperAgents는 독자 머릿속에 오래 남게 만든다.

둘을 비교하는 이 글은 그래서 꽤 괜찮은 다리다.

한쪽은 실사용, 한쪽은 구조적 자극이라 두 독자층이 자연스럽게 만난다.

내 결론

Hermes Agent와 HyperAgents는 같은 의미의 똑똑해짐을 말하지 않는다.

Hermes는 더 잘 기억하고, 더 잘 이어 받고, 더 잘 재사용하고, 더 잘 자동화되면서 점점 실무적으로 유능해지는 agent runtime이다.

HyperAgents는 task agent와 meta agent를 하나의 editable program으로 묶어 자기 자신과 자기개선 절차를 더 잘 고치도록 밀어붙이는 연구 프레임워크다.

그래서 네가 오늘부터 쓸 장기 실행형 비서 를 찾는다면 Hermes 쪽이 맞다.

네가 에이전트를 더 낫게 만드는 하네스까지 진화 대상으로 올리고 싶다 고 느낀다면 HyperAgents 쪽이 맞다.

실무적으로 가장 건강한 읽는 법은 이거다.

  • Hermes에서는 운영형 감각을 배운다.
  • HyperAgents에서는 메타 개선 감각을 배운다.
  • 둘을 같은 제품 카테고리로 억지로 싸움 붙이지 않는다.

이렇게 보면 이름은 비슷해도 실제로는 꽤 멀리 떨어져 있다.

하나는 집사에 가깝고, 하나는 집사를 스스로 다시 설계하는 연구체에 가깝다.

FAQ

Hermes는 진짜로 오래 쓸수록 더 좋아지나

공식 문서 기준으로는 그렇다.

다만 그 의미는 memory + session recall + skills + context files 가 쌓이면서 실무 적합도가 올라간다는 뜻에 가깝다.

모델 파라미터가 자동 학습되는 의미로 받아들이면 과장이다.

HyperAgents는 Hermes보다 더 똑똑한가

질문이 조금 잘못됐다.

HyperAgents는 개인 비서형 runtime과 1대1 비교되는 제품이 아니라, 자기개선 구조를 연구하는 프레임워크에 더 가깝다.

그래서 누가 더 똑똑하냐보다 누가 어떤 층의 문제를 푸냐가 먼저다.

HyperAgents도 나중엔 비서형 제품이 될 수 있지 않나

물론 가능성은 있다.

하지만 2026년 4월 13일 기준 공식 논문과 레포가 보여주는 초점은 사용자-facing 비서 제품보다 자기개선 실험 루프에 훨씬 가깝다.

Hermes를 쓰면 하네스를 안 짜도 되나

그건 아니다.

오히려 도구가 많아질수록 toolsets, 권한, terminal backend, memory 기준, cron 범위, gateway 채널 같은 운영 규칙을 더 신경 써야 한다.

좋은 runtime이 좋은 운영 판단까지 대신해주진 않는다.

내 시스템에 둘 중 하나만 가져와야 한다면

당장 실사용을 원하면 Hermes 쪽 아이디어가 먼저다.

하네스 고도화 방향을 잡고 싶다면 HyperAgents 쪽 아이디어를 나중에 넣는 편이 자연스럽다.

즉 보통은 운영을 먼저 붙이고, 진화를 나중에 붙인다.

관련 글

같이 보면 좋은 메모

  • [[03.Resources/📚기술_IT/260410_[정리] Hermes, 자비스, Harness, LLM Wiki 차이]]
  • [[03.Resources/📚기술_IT/260311_[통합요약] 에이전트 검색 운영 도구 비교]]

출처