이 글은 Hermes Agent Challenge를 위한 제출물입니다.

대부분의 AI 에이전트는 스스로 인정하지 않는 메모리 문제를 가지고 있습니다. 모든 세션이 종료되면 컨텍스트(Context)가 초기화되며, 내일 당신은 당신의 코드베이스, 선호도, 제약 사항을 처음부터 다시 설명해야 합니다. Nous Research의 Hermes Agent는 이를 구조적으로 해결하는 최초의 오픈 소스 (Open-source) 에이전트입니다. 이는 단순히 설정 가능한 메모리 기능을 통해서가 아니라, 에이전트 런타임 (Runtime) 자체에 내장된 폐쇄형 학습 루프 (Closed learning loop)를 통해 이루어집니다.

왜 다른 모든 에이전트는 잊어버리는가
표준적인 에이전트 루프 (Agentic loop)는 세 단계로 이루어집니다: 작업 수신, 계획 및 실행, 결과 반환. 상태가 초기화됩니다. 다음 작업은 백지 상태에서 시작됩니다. 대부분의 프레임워크는 과거 대화의 임베딩 (Embeddings)을 저장하는 벡터 데이터베이스 (Vector database)와 같이, 사후에 장기 메모리 (Long-term memory)를 덧붙이는 방식으로 이를 해결하려 시도했습니다.

문제는 벡터 검색 (Vector retrieval)이 "이것과 유사한 내용으로 우리가 무엇을 이야기했는가?"라는 질문에는 답할 수 있지만, "지난번에 이 종류의 문제를 실제로 어떻게 해결했는가, 그리고 정확한 단계는 무엇이었는가?"라는 질문에는 답하지 못한다는 점입니다. 이 둘은 서로 다른 질문이며, 이 둘을 혼동하기 때문에 대부분의 "메모리 기능이 활성화된" 에이전트들이 실제로는 여전히 상태가 없는 (Stateless) 것처럼 느껴지는 것입니다.

Hermes Agent는 응답이 반환된 후 두 단계를 추가합니다.
4단계: 에이전트는 해당 세션을 유지할 가치가 있는지 평가하도록 내부적인 자극 (Internal nudge)을 받습니다.
5단계: 만약 작업에 5개 이상의 도구 호출 (Tool calls)이 포함되었다면, 에이전트는 그것이 어떻게 해결되었는지를 정확하게 기술하는 기술 문서 (Skill document)를 자율적으로 작성한 다음, 이를 향후 모든 세션을 위해 메모리에 인덱싱 (Indexing)합니다.

이것이 바로 루프입니다. 그리고 이것이 이 프로젝트가 2026년 2월 25일 출시된 후 7주 만에 GitHub 스타 100,000개를 돌파한 이유입니다.

실제 적용되는 5단계
루프를 이해한다는 것은 "당신이 메시지를 보낸" 시점과 "에이전트가 응답하는" 시점 사이에 실제로 어떤 일이 일어나는지를 이해하는 것을 의미합니다.
메시지가 도착합니다 - CLI, Telegram, Discord, Slack, WhatsApp, Signal, 또는 예약된 cron job으로부터 말이죠. 이 모든 것들은 동일한 실행 엔진 (Execution engine)으로 들어옵니다.

모델이 사용자의 쿼리(query)를 확인하기 전에, 에이전트는 검색 (retrieval)을 수행합니다. 에이전트는 FTS5 전문 검색 (full-text search) 기능을 갖춘 로컬 SQLite 데이터베이스에 쿼리를 날려, 10,000개 이상의 인덱싱된 문서들 사이에서 약 10ms의 지연 시간 (latency) 내에 관련 있는 과거 기술 (skills)과 노트 (notes)를 가져옵니다. 그 후 모델은 계획을 세우고, 도구 (tools)를 호출하며, 실행하고, 출력을 스트리밍합니다. 이것이 여러분이 알고 있는 일반적인 에이전트 루프 (agent loop)입니다. 응답이 완료된 후, 루프는 갈라집니다. 에이전트는 자신의 세션 (session)을 점검합니다. 이번 과정에 의미 있는 도구 시퀀스 (tool sequences)가 포함되었는가? 여기에 일반화 가능한 절차 (generalizable procedure)가 있는가? 만약 그렇다면, agentskills.io 오픈 표준 (open standard)을 따르는 일반 Markdown 형식으로 skill 문서가 ~/.hermes/skills/ 경로에 작성됩니다. 이 파일은 즉시 모든 향후 세션에서 검색 가능해집니다. 다음에 유사한 문제가 발생하면, Hermes는 해당 절차를 새로 발견하는 대신 검색하여 가져옵니다. 실질적인 결과로, 독립적인 벤치마크 (benchmarks)에 따르면 20개 이상의 자체 생성 기술을 보유한 에이전트가 동일한 작업에서 새로운 에이전트 인스턴스보다 유사한 미래 연구 작업을 약 40% 더 빠르게 완료하는 것으로 나타났습니다. 솔직한 주의 사항은 도메인 특이성 (domain specificity)입니다. GitHub PR을 요약하며 학습한 기술은 데이터베이스 마이그레이션 (database migrations) 계획으로 전이되지 않습니다. 도메인 간 일반화 (Cross-domain generalization)는 여전히 해결되지 않은 과제입니다. 하지만 좁고 반복적인 도메인 내에서는 복리 효과 (compounding effect)가 실질적이며 측정 가능합니다.

네 가지 메모리 계층 (Memory Layers), 각각의 서로 다른 문제 해결
학습 루프 (learning loop)가 프로세스라면, 메모리 시스템 (memory system)은 그 루프가 기록하는 대상이며, 네 가지 별도의 계층으로 나뉩니다. 세션 메모리 (Session memory)는 일반적인 컨텍스트 관리 (context management)로, 현재의 대화 창을 의미합니다. 새로운 것은 아니지만, Hermes는 /compress, /usage, /insights 슬래시 명령어 (slash commands)를 노출하여 사용자가 조용히 오버플로 (overflow)가 발생하기를 기다리는 대신 이를 명시적으로 모니터링하고 제어할 수 있게 합니다. 지속성 메모리 (Persistent memory)는 완료된 작업 결과와 에이전트가 큐레이션한 노트가 저장되는 SQLite FTS5 저장소입니다. 모든 것은 사용자의 로컬 머신 내 ~/.hermes/에 위치합니다. 클라우드 왕복 (cloud round-trips)도, 텔레메트리 (telemetry)도, 제3자 메모리 제공업체도 없습니다.

이 아키텍처는 Qdrant나 Chroma와 같은 전용 벡터 스토어 (vector store)로 교체하기 전까지 약 10만 개의 문서까지는 무리 없이 확장 가능합니다. 스킬 문서 저장소 (skill document store)는 학습 루프 (learning loop)의 결과물입니다. 스킬은 일반적인 마크다운 (Markdown) 파일로 구성되어 있어, 이식성이 높고 사람이 읽기 쉬우며 버전 관리 시스템 (version control)에서 차이점 (diff)을 확인할 수 있습니다. 결정적으로, 기본적으로는 스킬 이름과 짧은 설명만이 시스템 프롬프트 (system prompt)에 로드됩니다. 전체 스킬 본문은 필요할 때만 (on demand) 로드됩니다. 이러한 설계 덕분에 200개의 스킬 라이브러리가 있더라도 컨텍스트 예산 (context budget)을 초과하지 않습니다. v0.10.0 기준으로, Hermes는 MLOps, GitHub 워크플로 (workflows), 연구 파이프라인 (research pipelines), 스크래핑 (scraping), 코드 실행 (code execution) 등을 포함한 26개 이상의 카테고리에 걸쳐 96개의 번들 스킬 (bundled skills)과 22개의 선택적 스킬을 제공합니다. Honcho는 선택적인 네 번째 레이어 (layer)로, Plastic Labs의 '변증법적 아키텍처 (dialectic architecture)'와의 통합을 통해 구축된 사용자 모델링 시스템입니다. Honcho는 세션 전반에 걸쳐 사용자의 선호도, 커뮤니케이션 스타일, 기술 스택 (tech stack), 도메인 어휘 (domain vocabulary)를 수동적으로 축적합니다. 이는 수백 번의 상호작용 후에

4월 중순 기준으로 커뮤니티 허브(community hub)에는 643개의 검토된 기술(skills)이 등록되어 있었습니다. 이는 OpenClaw의 13,000개 이상의 마켓플레이스보다는 규모가 작지만, 방대한 오픈 마켓플레이스가 일반적으로 갖지 못하는 방식으로 큐레이션(curation)되어 있습니다. 한 가지 실질적인 주의 사항(gotcha)은, 중간 정도의 작업(5~10회의 도구 호출 (tool calls))에서 자동 생성된 기술은 정교하고 재사용 가능한 경향이 있다는 점입니다. 반면 매우 복잡한 다단계 작업(50회 이상의 도구 호출)에서 생성된 기술은 때때로 과도하게 일반화되거나 세션 특화적인 컨텍스트 (session-specific context)를 너무 많이 포함하기도 합니다. 사용 첫 달 동안 자동 생성된 기술을 수동으로 검토하는 과정은 시간을 들일 가치가 충분합니다.

이 아키텍처 (architecture)가 실제로 중요한 이유
2025년과 2026년 초의 에이전트 (agent) 분야는 특정 유형의 데모들이 지배했습니다. 인상적인 원샷 (one-shot) 작업 실행, 우아한 도구 오케스트레이션 (tool orchestration), 깔끔한 아키텍처 다이어그램 등이 그것입니다. 하지만 거의 아무도 출시하지 못한 것은, 실행 시간이 길어질수록 사용자의 특정 워크플로 (workflow)에 대해 측정 가능한 수준으로 개선되는 에이전트였습니다. Hermes Agent의 학습 루프 (learning loop)는 에이전트가 범용 작업 실행기 (general-purpose task executors)로서가 아니라, 축적되는 전문가 (accumulating specialists)로서 가장 가치 있다는 구조적 베팅 (structural bet)입니다. 만약 귀하의 워크플로가 반복적이고 구조화되어 있다면 — 즉, 수개월 동안 동일한 코드베이스에 대해 동일한 범주의 작업을 실행한다면 — Hermes는 프롬프트 엔지니어링 (prompt-engineered)된 에이전트가 도저히 따라올 수 없는 방식으로 복리 효과를 창출합니다. 반대로 워크플로가 광범위하고 끊임없이 변한다면, 루프가 활용할 수 있는 데이터가 없으므로 기술 라이브러리 (skill library)는 빈약한 상태로 남게 됩니다. 이 시스템을 기반으로 아키텍처를 설계하기 전에 귀하가 어느 카테고리에 속하는지 파악하십시오. 스스로 개선되는 에이전트는 매력적인 추상화 (abstraction)이지만, 그 가치는 반복을 통해 증명됩니다. 좁은 도메인 내에서 한 달 동안 매일 사용하는 것이 그 어떤 벤치마크 (benchmark)보다 이 아키텍처가 귀하의 업무에 적합한지 더 잘 알려줄 것입니다.

또한 충분히 다뤄지지 않는 연구적 관점도 있습니다. Nous Research는 Atropos RL 환경 통합 및 궤적 내보내기 (trajectory export) 기능을 Hermes에 직접 구축했습니다. 모든 실행, 모든 성공적인 도구 시퀀스, 모든 생성된 기술은 더 작고 목적에 맞게 제작된 모델들을 미세 조정 (fine-tuning)하기 위한 후보 궤적 (candidate trajectory)이 됩니다.

Hermes는 단순한 애플리케이션이 아닙니다. 이는 모델을 직접 학습시키는 연구소(lab)에서 구축한, 차세대 도구 호출 (tool-calling) 모델들을 위한 데이터 파이프라인입니다. 이러한 이중 용도 (dual-use) 아키텍처는 보기 드문 사례이며, 단순히 "에이전트를 구축한다"는 즉각적인 사용 사례를 넘어 이 분야를 고민하고 있다면 이를 이해할 가치가 있습니다.

시작하기

Linux / macOS / WSL2에 설치

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

모델 제공자 설정

hermes model

첫 세션 시작

hermes

전체 문서는 hermes-agent.nousresearch.com/docs 에서 확인할 수 있습니다. 퀵스타트 (quickstart)를 이용하면 5분 이내에 실행 중인 에이전트를 가질 수 있습니다.

더 큰 질문
오픈 소스 에이전트 분야는 여전히 주로 "에이전트가 이 작업을 수행할 수 있는가?"를 묻고 있습니다. Hermes Agent는 다른 질문을 던집니다. "에이전트가 시간이 지남에 따라 이 작업에 대해 더 나아지는가?" 이 두 질문은 같지 않으며, 두 번째 질문이 훨씬 더 어렵습니다. 학습 루프 (learning loop)가 단순히 더 나은 사용자 경험 (UX)을 제공하는 것을 넘어, 아키텍처 수준에서 복리적인 개선 (compounding improvement)을 전달할 수 있는지 여부는 연구 커뮤니티가 여전히 풀어가고 있는 과제입니다.

동반 프로젝트인 hermes-agent-self-evolution은 DSPy와 GEPA를 적용하여 벤치마크에 맞춰 기술과 프롬프트 (prompts)를 최적화합니다. 만약 이 피드백 루프 (feedback loop)가 공개 평가 (public evals)에서 측정 가능한 개선을 만들어낸다면, "자기 개선 (self-improving)"이라는 프레임워크는 유효합니다. 만약 몇 번의 반복 후에 이득이 정체된다면, 해당 학습 루프는 더 나은 알고리즘이 아니라 더 나은 개발자 경험 (developer experience)인 것입니다. 어느 쪽이든, 이는 누군가가 오픈 소스로 출시한 문제에 대한 가장 정직한 시도입니다. 다른 모든 에이전트는 망각합니다. 그것이 여전히 기준점 (baseline)입니다. Hermes는 그 기준점을 구식으로 만들고자 합니다.

MCP, 에이전트형 AI (agentic AI), 그리고 AI 인프라에 대한 더 많은 소식을 위해 팔로우하세요.