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

대부분의 AI Agent가 잊어버리는 가장 비용이 많이 드는 것은 사용자의 이름이 아닙니다. 바로 방금 수행한 작업입니다. 당신은 Agent가 당신의 환경을 학습하고, 저장소(Repository)를 조사하며, 문제를 디버깅하고, 프로젝트 컨벤션(Convention)을 파악하며, 유용한 엔지니어링 작업을 수행하고, 때로는 안정적으로 작동하는 워크플로우(Workflow)를 발견하기 위해 수천 개의 토큰을 소비하도록 허용합니다. 그러고 나서 세션을 종료하고 다음 날 돌아오면, 그 컨텍스트(Context)의 상당 부분이 사라져 있습니다. 저장소는 여전히 그 자리에 있지만, Agent는 그에 대해 무엇을 배웠는지, 문제를 어떻게 해결했는지, 그리고 어떤 워크플로우가 실제로 작업을 완수했는지를 잊어버립니다.

단기적인 작업의 경우, 이는 큰 문제가 아닙니다. 요약, SQL 쿼리, 또는 빠른 브라우저 자동화 작업만을 필요로 한다면 무상태(Stateless) 실행이 잘 작동합니다. 하지만 Agent가 반복적인 엔지니어링 작업, 자동화, 또는 운영 워크플로우를 다루기 시작하면, 동일한 솔루션을 반복해서 다시 발견하도록 강제하는 것은 비용이 많이 드는 설계 결함이 됩니다.

이것이 바로 Nous Research의 Hermes Agent를 흥미롭게 만드는 지점입니다. Hermes는 단순히 또 다른 코딩 코파일럿(Copilot)이나 도구 접근 권한이 덧붙여진 챗봇 래퍼(Wrapper)로 제안되는 것이 아닙니다. 더 야심 찬 아이디어는 성공적인 실행이 재사용 가능한 운영 지식(Operational Knowledge)을 생성해야 한다는 것입니다. 만약 Agent가 의미 있는 문제를 한 번 해결했다면, 다음번에 동일한 워크플로우를 처음부터 다시 학습할 필요가 없어야 합니다. 이것이 안정적으로 작동한다면, 오픈 소스(Open-source) Agent가 될 수 있는 모습이 바뀔 것입니다.

무상태 Agent 문제 (The Stateless Agent Problem)
대부분의 현재 Agent 프레임워크는 다음과 같이 효과적으로 작동합니다:
목표(Goal) → 계획(Plan) → 도구 호출(Tool Calls) → 실행(Execute) → 결과 반환(Return Result) → 망각(Forget)

이 라이프사이클(Lifecycle)은 작업이 반복되기 전까지는 놀라울 정도로 잘 작동합니다. Agent에게 저장소를 스캔하고, 누락된 라이선스 헤더를 식별하며, 패치(Patch)를 생성하고, 테스트를 실행한 뒤 검증된 변경 사항을 커밋(Commit)하도록 요청한다고 가정해 보십시오. 유능한 시스템은 작업을 정확히 완수하기 전에 파일 시스템을 조사하고, 프로젝트 컨벤션을 추론하며, 실패를 처리하고, 접근 방식을 개선하는 데 상당한 시간을 소비할 수 있습니다.

이제 정확히 동일한 작업을 일주일 후에 실행해 보십시오. 대부분의 에이전트(Agent)는 이전 실행이 전혀 일어나지 않았던 것처럼 처음부터 다시 시작할 것입니다. 반복되는 운영 문제에서도 동일한 현상이 발생합니다. 만약 에이전트가 불안정한 CI(Continuous Integration) 실패가 하나의 의존성 불일치와 잘못된 환경 변수 때문이라는 것을 발견하는 데 20분을 소비했다면, 당신은 그 발견이 재사용될 수 있기를 합리적으로 기대할 것입니다. 하지만 대부분의 시스템은 디버깅(Debugging) 프로세스 전체를 다시 재생합니다. 그것이 바로 비효율성입니다. 인간 엔지니어라면 그 패턴을 기억하거나 해결책을 문서화할 것입니다. 무상태(Stateless) 에이전트는 일반적으로 둘 다 하지 않습니다.

Hermes가 바꾸고자 하는 것
Hermes는 학습 루프(Learning loop)를 삽입함으로써 그 라이프사이클(Lifecycle)을 바꾸고자 시도합니다. 선형적인 시퀀스(Linear sequence)처럼 동작하는 대신, 의도된 모델은 다음과 같은 모습에 더 가깝습니다: 관찰(Observe) → 계획(Plan) → 실행(Execute) → 평가(Evaluate) → 기술 결정화(Crystallize Skill) → 재사용(Reuse). 중요한 차이점은 실행 후에 어떤 일이 일어나는가입니다. Hermes는 작업 완료를 상호작용의 끝으로 취급하는 대신, 방금 사용한 워크플로(Workflow)가 유지할 가치가 있는지를 평가합니다. 작업이 성공했는가? 어떤 동작이 실제로 중요했는가? 해결책이 일회성 임시방편(Workaround)이었는가, 아니면 재사용 가능한 운영 패턴을 나타내는가? 만약 대답이 '예'라면, Hermes는 모델이 나중에 동일한 프로세스를 다시 발견하도록 강요하는 대신, 해당 워크플로를 재사용 가능한 기술(Skill)로 보유할 수 있습니다. 이는 단순히 채팅 기록(Chat history)을 보존하는 것보다 훨씬 더 설득력 있는 아이디어입니다.

기술(Skill)의 실제 모습
'절차적 기억(Procedural memory)'은 실제로 무엇이 저장되는지를 생각하기 전까지는 추상적으로 들립니다. 절차적 워크플로에 대한 Hermes의 접근 방식은 불투명한 메모리 블롭(Memory blobs)보다는 검사 가능한 기술 아티팩트(Skill artifacts)에 훨씬 더 가깝습니다. 이는 메모리를 숨겨진 벤더 상태(Vendor state)로 취급하는 것보다 훨씬 더 건강한 모델입니다. 개념적으로, 결정화된 기술 아티팩트는 다음과 같은 모습입니다:

repo-license-remediation

version : 1.2
tags :

• python
• repository
• compliance
  inputs :
• repo_path
• license_header
  required_tools :
• filesystem
• regex_match
• file_write
• terminal
• git
  steps :

1. Python 파일 스캔

3. 누락된 헤더 감지

4. 패치 생성

5. 테스트 실행

6. 검증된 변경 사항 커밋

이것은 이전 프롬프트나 대화 조각을 기억하는 것과는 근본적으로 다릅니다. 이것은 운영 지식 (operational knowledge)입니다. 제가 간결한 응답을 선호한다는 것을 기억하는 것은 개인화 (personalization)입니다. 저장소 문제를 안전하게 복구하는 방법을 기억하는 것이 실제 능력 (capability)입니다. 그 차이가 중요합니다.

절차적 메모리 (Procedural Memory)는 채팅 메모리 (Chat Memory)보다 더 흥미롭습니다.
많은 AI 제품들이 메모리를 광고하지만, 대부분의 경우 그것은 대화의 연속성, 사용자 선호도, 또는 유지된 프롬프트 컨텍스트 (prompt context)를 의미합니다. 그것은 유용하지만, 반드시 시스템이 업무를 수행하는 능력을 더 좋게 만드는 것은 아닙니다. 더 의미 있는 구분은 사실을 기억하는 것과 절차를 기억하는 것 사이의 구분입니다. 인간은 반복 가능한 워크플로우 (workflows)를 내재화하기 때문에 유능한 엔지니어가 됩니다. 모든 정확한 명령어를 영원히 암기하는 것이 아니라, 반복되는 통합 문제에 어떻게 접근해야 하는지 또는 익숙한 실패 패턴을 어떻게 복구해야 하는지를 기억하는 것입니다.

Hermes는 그 모델에 훨씬 더 가깝게 다가가고 있습니다. 그 아키텍처 (architecture)는 세 가지 뚜렷한 계층으로 생각할 수 있습니다:

• 작업 메모리 (Working Memory): 현재 작업 컨텍스트, 임시 변수, 최근 도구 출력(tool outputs)을 포함하는 수명이 짧은 실행 상태. 이것은 표준적인 에이전트 (agent) 동작입니다.
• 일화적 메모리 (Episodic Memory): 연속성을 개선하기 위해 프로젝트 메타데이터, 사용자 선호도, 그리고 이전의 역사적 결정들을 매핑하는 더 긴 수명의 컨텍스트 회상 (contextual recall).
• 절차적 메모리 (Procedural Memory): 흥미로운 계층입니다. 디버깅 루틴, 배포 절차, 복구 파이프라인, 그리고 통합 플레이북 (integration playbooks)과 같은 재사용 가능한 워크플로우를 저장합니다. 이 계층이 잘 작동한다면, 시스템은 단순히 대화를 기억하는 대신 반복을 통해 개선됩니다.

확장성 문제 (The Scaling Problem)
지속적인 절차적 메모리는 다음과 같은 명백한 질문에 부딪히기 전까지는 매우 훌륭하게 들립니다: 에이전트가 수백 개의 워크플로우를 축적하게 되면 어떻게 될까요? 매번 그 모든 것을 컨텍스트 윈도우 (context window)에 쏟아붓는 것은 토큰 효율성 (token efficiency), 지연 시간 (latency), 그리고 추론 품질 (reasoning quality) 측면에서 끔찍할 것입니다.

단계별 검색 모델(staged retrieval model)이 훨씬 더 합리적입니다:

• Discovery Stub (~20 tokens): 최소한의 정보, 즉 관련성을 판단하기 위한 기술 이름과 짧은 설명으로 시작합니다. 예: Python repository license remediation workflow
• Signature Layer (~200 tokens): 워크플로우가 유용해 보인다면, 적용 가능성을 검증하기 위해 예상되는 입력값, 필요한 도구(tools), 그리고 설정 가정(configuration assumptions)을 검색합니다.
• Blueprint Layer (~1,000+ tokens): 워크플로우가 실제로 실행될 때만 전체 단계, 명령 시퀀스(command sequences), 그리고 도구 호출 로직(tool invocation logic)을 로드합니다.

이는 무차별적인 메모리 주입(brute-force memory stuffing)보다 훨씬 더 확장성이 뛰어납니다. 한 가지 주의할 점은, Hermes를 비판적으로 평가하고 있다면 이 중 어떤 부분이 현재 설명된 대로 정확히 구현되어 있는지, 그리고 어떤 부분이 더 넓은 아키텍처 방향성을 나타내는지 확인해 볼 가치가 있다는 것입니다. 하지만 개념적으로 이것이 올바른 솔루션의 형태입니다.

Hermes 직접 시도해보기
설정 자체는 간단해 보이지만, 더 흥미로운 질문은 Hermes가 실행될 수 있느냐가 아니라, 반복되는 작업이 실제로 더 똑똑해지느냐 하는 것입니다. 기본 설정은 빠른 터미널 시퀀스를 따릅니다:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
hermes setup
hermes

Hermes는 터미널을 넘어 메시징 인터페이스와 격리된 실행 백엔드(isolated execution backends) 전반에서 실행되는 것도 지원하며, 이는 아키텍처가 단순히 대화 중심이 아닌 운영 중심(operational)이라는 느낌을 줍니다. 가치 있는 테스트는 테스트 저장소를 스캔하고, 누락된 헤더를 식별하며, 로컬 패치(local patch)를 생성하는 것과 같이 실제로 다단계 추론(multi-step reasoning)이 필요한 작업을 주는 것입니다. 진짜 검증은 두 번째 실행이 눈에 띄게 더 깔끔하고, 빠르며, 낭비가 적게 느껴지는지 여부입니다.

다른 프레임워크와 비교한 Hermes의 위치
LangChain: 개발자에게 가공되지 않은 빌딩 블록(building blocks)과 엄청난 유연성을 제공합니다. 이는 완전한 아키텍처 제어를 원하는 경우라면 훌륭하지만, 모든 것을 직접 조립해야 함을 의미하기도 합니다. Hermes는 별도의 설정 없이도(out of the box) 좀 더 의견이 반영된(opinionated) 형태를 띱니다.

AutoGen: AutoGen은 멀티 에이전트 대화 워크플로우 (multi-agent conversational workflows)에서 빛을 발하지만, 대화 중심의 시스템은 빠르게 노이즈가 심해지고 비용이 많이 들 수 있습니다. Hermes는 에이전트 간의 대화보다는 원시 실행 워크플로우 (raw execution workflows)에 더 집중하는 느낌을 줍니다. OpenDevin: 소프트웨어 엔지니어링 자동화 및 워크스페이스 환경에 명확하게 정렬되어 있습니다. Hermes는 일반적인 운영 에이전트 동작 (general operational agent behavior)을 목표로 하여 조금 더 광범위한 느낌을 줍니다. OpenClaw: 직접적인 경쟁 관계라기보다는 인접한 관계입니다. OpenClaw는 오케스트레이션 (orchestration) 및 통신 라우팅 (communication routing) 측면에서 강력한 반면, Hermes는 절차적 학습 (procedural learning) 및 자기 개선 실행 (self-improving execution) 측면에서 더 흥미롭습니다.

인프라 설계의 중요성
실행 격리 (execution isolation)가 없는 강력한 에이전트는 오히려 부담이 됩니다. LLM에 제한 없는 셸 액세스 (shell access)를 부여하는 것은 진지한 프로덕션 전략이 아닙니다. Hermes는 제한된 로컬 실행 (restricted local execution), Docker 컨테이너, SSH 환경, Singularity, 그리고 Modal과 같은 원격 샌드박스 (remote sandbox) 환경을 포함한 다양한 실행 백엔드 (execution backends)를 지원합니다. 이것이 중요한 이유는 실질적인 자동화에는 격리가 필요하기 때문입니다. 현실적인 워크플로우는 Slack 알림이 격리된 환경을 트리거하고, Hermes가 배포 상태를 검증하며, 알려진 실패 패턴을 감지하고, 학습된 복구 워크플로우 (remediation workflow)를 적용한 뒤, 결과를 보고하는 과정을 포함할 수 있습니다. 이는 단순한 장난감 데모가 아니라 운영 팀이 실제로 사용할 수 있는 무언가처럼 보이기 시작합니다.

문제가 발생할 수 있는 지점
여기에는 실질적인 위험 요소가 있습니다:
기술 드리프트 (Skill Drift): 6주 전에는 작동했던 워크플로우가 의존성 변경, API 진화, 또는 CLI 플래그 오류로 인해 오늘날에는 잘못된 것이 될 수 있습니다. 재검증이 없다면 절차적 메모리 (procedural memory)는 오래된 자동화 부채 (automation debt)가 됩니다.
잘못된 일반화 (Faulty Generalization): 에이전트가 취약한 엣지 케이스 (edge-case) 수정 사항을 재사용 가능한 표준 워크플로우로 잘못 승격시킬 수 있습니다. 반복되는 잘못된 자동화는 매번 새로운 추론을 강제하는 것보다 종종 더 위험하기 때문에 이는 빠르게 위험한 상황이 됩니다.
보안 위험 (Security Risk): 지속적인 절차적 메모리는 안전하지 않은 명령, 환경 가정, 또는 자격 증명 유출 위험이 있는 패턴을 보존할 수 있습니다.

모든 자기 개선 실행 시스템(self-improving execution system)에는 엄격한 거버넌스(governance)가 필요합니다. 실질적인 안전장치(Practical Safeguards)로서, 만약 누군가 이러한 시스템을 프로덕션(production) 환경에서 사용할 계획이라면, 최소한 다음과 같은 체크리스트가 포함되어야 할 것입니다:

• 새로 생성된 기술(skills)이 활성 재사용 단계로 진입하기 전의 인간 승인(Human approval).
• 자율적 재사용을 허용하기 전, 여러 번의 성공적인 실행을 통한 검증.
• 자동화된 스모크 테스트(smoke testing), 버전 관리(version control), 그리고 엄격한 최소 권한 실행 경계(least-privilege execution boundaries).

이러한 통제 장치가 없다면, 절차적 메모리(procedural memory)는 유용한 자동화가 아닌 누적된 운영 리스크(operational risk)가 됩니다.

오픈 소스(Open Source) 관점에서 이것이 중요한 이유
여기서 더 큰 문제는 소유권(ownership)입니다. 많은 독점적(proprietary) AI 시스템은 지속적인 메모리가 벤더(vendor)의 인프라 내부에 속한다고 가정합니다. 이는 락인(lock-in), 불투명한 자동화 로직, 낮은 감사 가능성(auditability), 그리고 고통스러운 마이그레이션(migration) 사례를 만들어냅니다. 만약 오픈 에이전트(open agent)가 검사 가능하고 버전 관리가 되는 아티팩트(artifacts) 형태로 재사용 가능한 운영 지식을 보유할 수 있다면, 팀은 에이전트의 동작을 감사하고, 플레이북(playbooks)을 공유하며, 자유롭게 마이그레이션하고, 시스템이 학습한 워크플로우(workflows)를 실제로 소유할 수 있습니다. 에이전트가 유용한 무언가를 발견한다면, 그 지식은 호스팅된 메모리 계층(hosted memory layer) 속으로 사라지는 것이 아니라, 여러분이 제어할 수 있는 인프라 내에 존재해야 합니다. 이것이 어쩌면 더 중요한 변화일지도 모릅니다.

토론(Discussion)
오늘날 여러분은 비핵심적 자동화(non-critical automation)를 위해 자기 개선 에이전트(self-improving agent)를 신뢰하시겠습니까? 그 이유는 무엇입니까? 에이전트가 프로덕션 인프라(production infrastructure)를 다루도록 허용하기 전에 어떤 구체적인 안전장치를 요구하시겠습니까?