본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 05. 21. 20:49

당신이 잠든 사이 학습하는 AI: Hermes Agent의 자기 진화형 두뇌 내부 탐구

요약

Hermes Agent는 기존 에이전트의 상태 비저장(stateless) 문제를 해결하기 위해 스스로 학습하고 진화하는 오픈 소스 런타임입니다. OERC(Observe, Execute, Reflect, Crystallize) 사이클을 통해 작업 경험을 절차적 메모리로 변환하여 지능을 축적합니다.

핵심 포인트

  • 기존 에이전트의 기억 상실 문제를 해결하는 자기 진화형 구조
  • OERC 사이클을 통한 관찰, 실행, 성찰, 결정화 프로세스
  • 작업 경험을 바탕으로 새로운 절차적 메모리 파일 자동 생성
  • 유휴 시간에 스스로 성능을 개선하는 학습 대사(metabolism) 구현

다른 모든 에이전트는 잊어버립니다. 하지만 이 에이전트는 성장합니다. 새벽 3시입니다. 당신의 노트북은 유휴 상태(idle)입니다. 열려 있는 터미널도 없고, 기다리는 프롬프트(prompt)도 없습니다. 그리고 ~/.hermes/skills/ 내부 어딘가에서, 하나의 데몬(daemon)이 막 깨어났습니다. 이 데몬은 당신의 에이전트가 이번 주에 완료한 모든 작업 — 모든 도구 호출(tool call), 모든 실패, 모든 수정, 모든 우회책(workaround)을 읽고 있습니다. 그것은 이들을 채점합니다. 중복되는 것들을 통합합니다. 성능이 저조한 것들을 가지치기(pruning)합니다. 새로운 절차적 메모리(procedural memory) 파일들을 처음부터 새로 작성합니다. 당신은 요청하지 않았습니다. 당신은 스케줄을 잡지도 않았습니다. 그것은 마치 시계태엽처럼 — 7일마다 — 그냥 일어납니다. 아침이 되면, 당신의 에이전트는 어제보다 당신의 코드베이스(codebase)에 대해 측정 가능한 수준으로 더 나아져 있습니다. 그리고 당신은 그 시간 내내 잠들어 있었습니다. 이것이 Hermes Agent입니다. 그리고 이것은 제가 접한 첫 번째 오픈 소스 런타임(runtime)으로, 단순히 지능을 실행하는 것에 그치지 않고 — 지능을 축적합니다.

다른 모든 에이전트가 가진 문제
대부분의 에이전트 프레임워크(agentic frameworks)에는 추악한 비밀이 있습니다. 그것들은 설계 단계부터 기억 상실증에 걸려 있다는 것입니다. 당신은 에이전트에게 복잡한 작업을 부여합니다. 에이전트는 고군분투하고, 회복하며, 우회책을 찾아내고, 작업을 완료합니다. 당신은 기분이 좋습니다. 터미널을 닫습니다. 다음에 동일한 유형의 작업을 실행할 때? 에이전트는 제로(zero) 상태에서 다시 시작합니다. 우회책은 사라졌습니다. 어렵게 얻어낸 회복 패턴(recovery pattern)도 — 사라졌습니다. 에이전트는 지난 화요일에 헤쳐 나갔던 것과 정확히 동일한 실패 모드(failure mode)를 겪으며 고군분투할 것입니다. 왜냐하면 아키텍처(architecture) 내의 그 무엇도 그것이 배운 것을 포착하지 못했기 때문입니다. 이것은 대부분의 프레임워크에서 버그가 아닙니다. 그것은 철학적인 선택입니다. 에이전트를 상태 비저장(stateless)으로 유지하고, 예측 가능하게 유지하며, 단순하게 유지하는 것입니다. 문제는 그 "단순함"이 "영구적인 평범함"으로 누적된다는 점입니다. 당신은 점점 나아지는 에이전트를 실행하고 있는 것이 아닙니다. 당신은 매우 값비싼 for 루프(for loop)를 실행하고 있는 것입니다.

Hermes는 다른 선택을 했습니다. 전체 아키텍처가 단 하나의 질문을 중심으로 구축되었습니다: 만약 에이전트가 기억한다면 — 그리고 기억하는 행위 자체가 에이전트를 더 똑똑하게 만든다면 어떨까?

심박수(The Heartbeat): 관찰, 실행, 성찰, 결정화(Crystallize)
대부분의 에이전트 프레임워크는 루프(loop)를 가지고 있습니다. 입력(Input) → 계획(Plan) → 도구 호출(Tool Call) → 출력(Output). 반복. Hermes는 심박수(heartbeat)를 가지고 있습니다.

4단계의 OERC 사이클은 단순한 실행 패턴이 아니라, 하나의 학습 대사(learning metabolism)입니다. 각 단계는 뚜렷한 생물학적 유사성을 지니며, 이를 이해하는 것이 Hermes가 왜 지금과 같이 동작하는지를 이해하는 핵심입니다.

┌─────────────────────────────────────────────────────────┐
│ THE HERMES LEARNING HEARTBEAT (Hermes 학습 심박수) │
│ │ │ │ OBSERVE ──► EXECUTE ──► REFLECT ──► CRYSTALLIZE │ │ │ │ │ │ │ Scan skills Run GEPA Write SKILL.md │ │ FTS5 lookup self-analysis to ~/.hermes/ │ │ ~20 tokens/skill on trace skills/ │ │ │ │ │ │ │ "What do I "Why did "Next time, │ │ already know?" that work?" I'll know." │ └─────────────────────────────────────────────────────────┘

Observe (관찰) — 무엇인가를 실행하기 전에, 에이전트는 FTS5 전문 검색(full-text search)을 사용하여 로컬 SQLite 데이터베이스를 스캔하고 들어오는 작업과 일치하는 기술(skills)을 찾습니다. 결정적으로, 이 단계에서는 Level-0 요약(기술당 약 20개의 토큰)만을 로드하므로, 컨텍스트 창(context window)을 팽창시키지 않고도 수천 개의 절차를 조사할 수 있습니다. 에이전트는 자신이 무엇을 알고 있는지 이미 파악한 상태로 실행 단계에 진입합니다.

Execute (실행) — 에이전트는 도구 호출(tool-calling) 루프를 실행하며, 로컬화된 스레드 풀(thread pool)을 통해 최대 8개의 도구를 병렬로 배정합니다. 모든 터미널 명령, 모든 API 응답, 모든 수정 사항은 상세한 실행 추적(execution trace)에 기록됩니다. 에이전트는 단순히 작업을 수행하는 것이 아니라, 작업을 어떻게 수행했는지에 대한 완전한 기록(transcript)을 남기고 있는 것입니다.

Reflect (성찰) — 여기서부터 흥미로워집니다. 충분히 복잡한 작업(통상 5회 이상의 도구 호출)이 완료되면, DSPy와 함께 실행되는 유전적-파레토 프롬프트 진화(Genetic-Pareto Prompt Evolution, GEPA) 시스템이 실행 추적을 분석합니다. GEPA는 실패 지점을 식별합니다. 복구가 왜 성공했는지 모델링합니다. 최적화된 가이드라인을 생성하고, 흔한 함정(pitfalls)을 문서화하며, 검증 단계를 초안으로 작성합니다. 결정적으로, 이 성찰 과정은 백그라운드 스레드에서 실행되므로 사용자를 기다리게 하지 않습니다.

Crystallize (결정화) — 성찰 결과물은 구조화된 마크다운(Markdown) 기술 파일로 컴파일되어 ~/.hermes/skills/ 경로에 저장됩니다.

이것은 Level 1에서 인덱싱되어, 다음 세션의 관찰 (Observe) 단계에서 표면화될 준비를 마칩니다. 루프가 닫힙니다. 지식은 지속됩니다. 이것은 인간의 근육 기억 (Muscle memory)이 작동하는 방식과 같습니다. 당신은 새로운 운동 패턴을 의식적으로, 반복적으로 고군분투하며 익히고, 그 동작이 자동화되어 피질하 (Sub-cortical) 수준에 도달할 때까지 연습합니다. Hermes도 동일한 일을 수행합니다. 다만 만 번의 반복이 아닌, 단 한 번의 패스 (Pass)로 결정화 (Crystallize)한다는 점이 다를 뿐입니다.

3계층 두뇌 (The Three-Layer Brain)

OERC 사이클이 심장 박동이라면, 메모리 아키텍처 (Memory architecture)는 두뇌입니다. 그리고 이는 대부분의 프레임워크가 근처에도 가지 못할 정도의 정밀도로 구조화되어 있습니다.

메모리 계층 (Memory Layer)인간의 유사성 (Human Analog)위치 (Location)크기 제한 (Size Cap)동작 (Behavior)
L1: 세션 컨텍스트 (Session Context)작업 기억 (Working Memory)휘발성 RAM (Volatile RAM)모델 컨텍스트 윈도우 (Model context window)/reset 시 삭제
L2: 지속 저장소 (Persistent Store)일화 기억 (Episodic Memory)~/.hermes/memories/MEMORY.md약 2,200자 / 약 800 토큰 (tokens)세션 시작 시 시스템 프롬프트 접두사 (System prompt prefix)로 고정
L3: 사용자 모델 (User Model)자전적 자아 (Autobiographical Self)~/.hermes/memories/USER.md약 1

실행해야 할 벡터 임베딩 (Vector Embedding) 서버도 없고, 감수해야 할 의미론적 검색 (Semantic Search) 지연 시간도 없습니다. 그저 SQLite가 가장 잘하는 일을 수행하도록 매우 정교하게 설계된 SQLite 데이터베이스가 있을 뿐입니다.

면역 체계: 왜 서브에이전트 (Subagent) 제약 사항이 핵심 기능인가

Hermes가 서브에이전트에게 작업을 위임할 때, 해당 서브에이전트는 자신만의 대화 컨텍스트 (Conversational Context)를 가진 신선하고 격리된 작업 공간 (Isolated Workspace)에서 실행됩니다. 중요한 점은, 서브에이전트가 다음 네 가지 엄격한 제약 사항 (Hard Constraints) 하에 작동한다는 것입니다:

  • 서브에이전트 생성 금지 —

}

별도로 설정할 필요는 없습니다. 기본값입니다.

Hermes vs. OpenClaw: 철학적 비교
이것은 "어느 것이 더 나은가"에 대한 비교가 아닙니다. "어떤 철학을 선택할 것인가"에 대한 비교입니다.

차원OpenClawHermes Agent
중심축 (Center of Gravity)게이트웨이 우선 (Gateway-First): 세션이 상태가 없는 (stateless) 에이전트 루프로 라우팅됨에이전트 우선 (Agent-First): 인지 루프 (cognitive loop)가 핵심이며, 게이트웨이가 이를 감싸는 형태
기술 시스템 (Skill System)정적이며, 사람이 직접 작성하고 수동으로 편집하는 파일자기 생성형 (Self-generating): OERC 루프가 새로운 기술을 자동으로 작성함
메모리 (Memory)플랫 파일 (Flat files) + 표준 SQLite, 수동 설정FTS5를 포함한 3계층 지속성 스택, 플러그형 백엔드 (pluggable backends)
병렬 실행 (Parallel Execution)단일 스레드 내에서 순차적 실행격리된 병렬 서브에이전트 (subagents)를 생성하는 네이티브 delegate_task 방식
컨테이너 모델 (Container Model)작업당 새로운 컨테이너 생성 (높은 초기 오버헤드, stateless)단일 지속성 컨테이너 (낮은 오버헤드, stateful)
설정 시간 (Setup Time)30분 미만전체 설정을 위해 2~4시간 소요
연간 API 비용 (Annual API Cost)약 $600–$1,800약 $500–$1,600 (프롬프트 캐싱을 통해 최적화됨, α≈0.90)

트레이드오프 (tradeoff)는 솔직합니다. OpenClaw는 구조가 더 단순하기 때문에 설정이 더 빠르고 이해하기 쉽습니다. 반면 Hermes는 모델 라우팅, 메모리 설정, Docker 구성, 게이트웨이 페어링 등 실제적인 구성 투자가 필요합니다. 2~4시간의 설정 시간은 실제로 소요되는 시간입니다.

하지만 여기서 질문을 던져야 합니다. 당신은 한 번만 실행할 무언가를 만들고 있습니까, 아니면 매일 실행할 무언가를 만들고 있습니까? 만약 후자라면 — 즉, 이 에이전트가 정기적으로 당신의 코드베이스를 다루고, 당신의 패턴을 학습하며, 반복적인 작업을 자동화하게 될 것이라면 — 그 투자는 복리로 쌓입니다. 첫날 설정하는 데 4시간이 걸린 에이전트는, 30분이 걸린 에이전트보다 30일째 되는 날 측정 가능한 수준으로 더 똑똑해져 있을 것입니다. 그 시간 내내 지식을 결정화(crystallizing)해 왔기 때문입니다.

비용 구조: 왜 α≈0.90이 모든 것을 바꾸는가

Hermes를 단순히 "비싼 셀프 호스팅 AI"라고 치부하며 무시하기 전에, 그 경제적 모델을 이해할 가치가 있습니다. 단일 대화 턴(conversational turn)에 대한 비용 공식은 다음과 같습니다:

C_turn = T_dynamic · R_dynamic + T_cached · (1-α) · R_dynamic + T_cached · α · R_cached + T_out · R_out

여기서 α는 프롬프트 캐시 적중률(prompt cache hit ratio)입니다. Hermes는 정상 상태(steady-state) 운영 시 α≈0.90을 달성합니다. 즉, 입력 토큰의 90%가 캐시에 적중하여 할인된 캐시 요율(cached rate)로 청구된다는 의미입니다. 이것이 바로 동결된 메모리 레이어(frozen memory layers)가 가져다주는 구조적 보상입니다. MEMORY.md와 USER.md는 업데이트 사이에 정적(static) 상태를 유지하므로, Anthropic의 프롬프트 캐시(prompt cache)에 무기한 머물게 됩니다. 구축하는 데 1,300개의 토큰이 소요된 시스템 프롬프트는 단 한 번만 전체 가격으로 청구됩니다. 이후의 모든 세션에서는 아주 적은 비용으로 이를 로드합니다. Hermes가 설계된 목적 그대로인 장시간 지속되는 다시간 에이전트 작업(multi-hour agent operations)의 경우, 이 캐시 적중률은 세션 비용을 40달러에서 4달러로 만드는 결정적인 차이를 만듭니다.

큐레이터(The Curator): 인지적 가드닝 (Cognitive Gardening)

Hermes에 대해 철학적으로 가장 흥미롭다고 생각하는 세부 사항은 바로 큐레이터(Curator)입니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0