이 글은 Hermes Agent Challenge를 위한 제출물입니다: Hermes Agent에 대해 작성하기

Hermes Agent는 매일 더 똑똑해집니다. 비용도 마찬가지입니다.

Hermes Agent에 관한 대부분의 글은 동일한 사실을 말해줍니다. 그것은 세션(session)을 거쳐 학습하고, 실행 시간이 길어질수록 더 나아지는 자기 개선형(self-improving), 셀프 호스팅(self-hosted) 에이전트라는 점입니다. 이는 정확한 사실입니다. 하지만 그것은 이야기의 쉬운 절반에 불과합니다.

거의 아무도 쓰지 않는 나머지 절반은 이것입니다: 역량(capability)이 복리로 쌓이는 시스템은 그 외의 모든 것—비용(cost), 드리프트(drift), 그리고 당신이 부여한 신뢰의 크기—도 함께 복리로 쌓는다는 점입니다. 자기 개선은 잠든 사이에 찾아오는 무료 업그레이드가 아닙니다. 그것은 대출입니다. 에이전트는 지금 역량을 끌어다 쓰고, 나중에 당신이 예측하지 못한 토큰(tokens), 검토하지 않은 기술, 그리고 당신이 작성하지 않은 코드가 당신의 서버에서 실행되는 방식으로 비용을 청구합니다.

저는 그 두 번째 절반에 대해, 제가 소유한 장비에 자율 에이전트(autonomous agent)를 배치하기 전에 알고 싶었던 것과 같은 정직한 엔지니어링적 접근을 제공하고자 합니다. 에이전트가 처음이라면, 처음 두 섹션이 쉬운 언어로 내용을 파악할 수 있게 도와줄 것입니다. 이미 몇 개를 배포해 보았다면, 흥미롭고도 충분히 논의되지 않은 문제들이 담긴 "부채 측면(The liability side)"으로 건너뛰십시오.

한 줄 요약: Hermes는 제가 본 복리적 자율성(compounding autonomy)의 가장 정직한 구현체입니다. 그리고 복리는 당신이 그저 즐기기만 해야 하는 것이 아니라, 반드시 관리해야 하는 속성입니다.

TL;DR

• Hermes의 초능력은 _복리 (compounding)_입니다. 스스로 재사용 가능한 기술 (skills) (일반 마크다운 형식)을 작성하고 이를 재사용하므로, 작업을 다시 해결하는 데 드는 비용이 0에 수렴하게 됩니다.
• 복리는 하나의 _속성 (property)_이지, 단순한 기능 (feature)이 아닙니다. 동일한 루프는 비용 드리프트 (cost drift), 기술 부패/드리프트 (skill rot/drift), 그리고 당신의 신뢰 표면 (trust surface) 또한 복리로 증가시킵니다. 이 세 가지는 모든 유명한 글들이 생략하는 부분입니다.
• 좋은 소식은 다음과 같습니다: 학습 내용이 _가독성 (legible)_을 갖추고 있기 때문에 (읽을 수 있는 파일, 쿼리가 가능한 메모리), 통제(governable)가 가능하다는 점입니다. 아래에는 실패 모드 분류 체계, 예시적 비용 모델, 그리고 이번 주에 바로 적용할 수 있는 6단계 프레임워크가 담겨 있습니다.

우선, 명확하게: 무엇이 실제로 Hermes를 다르게 만드는가

만약 당신이 챗봇만을 사용해 왔다면, 이것이 가장 중요한 핵심 아이디어입니다.

일반적인 LLM 호출은 상태 비저장 (stateless) 방식입니다. 당신이 질문하면 모델은 답변하고, 기록은 지워집니다. 내일이 되면 모델은 당신의 이름뿐만 아니라 한 시간 전에 당신을 위해 도출해낸 전체 해결책조차 잊어버립니다. 모든 세션은 이미 알고 있었던 것을 다시 발견하기 위해 매번 전체 비용을 지불합니다.

Hermes는 이와 정반대의 가정을 바탕으로 구축되었습니다. Hermes는 당신이 제어하는 인프라 위에서 실행되는 장기 실행 프로세스 (long-lived process) — 즉, VPS, Docker 컨테이너, SSH 호스트, 서버리스 백엔드 등 — 로 작동합니다. 요청 (request)이 아니라 프로세스이기 때문에, 세션 간에 정보를 유지할 수 있습니다. 구체적으로 다음 세 가지를 유지합니다:

1. 메모리 (Memory) — 과거 세션에 대한 검색 가능한 기록입니다 (Hermes는 메모리가 비대해지는 것을 방지하기 위해 SQLite 전문 검색 (full-text search)과 LLM 요약 (summarization)을 사용합니다). 이를 통해 지난 화요일에 무슨 일이 있었는지 기억해낼 수 있습니다.
2. 기술 (Skills) — 이 부분이 게임의 판도를 바꾸는 핵심입니다. Hermes가 무언가를 수행하는 _방법 (how)_을 찾아내면, 그 절차를 기술 디렉토리에 **일반 마크다운 파일 (plain markdown file)**로 작성할 수 있으며, 나중에 이를 불러와 재사용할 수 있습니다. 기술은 벡터 데이터베이스 (vector database)도 아니고 미세 조정 (fine-tuning)도 아닙니다. 그것은 읽을 수 있고 버전 관리가 가능한 파일, 즉 에이전트가 미래의 자신을 위해 작성한 지침입니다.
3. 루프 (A loop) — 에이전트는 오프라인 학습 실행 중이 아니라, 작업을 수행하는 동안 해당 메모리를 큐레이션하고 기술을 정교화하도록 유도됩니다.

이것이 신비주의를 걷어낸 마법의 전부입니다:

┌─────────────────────────────────────────────┐
│ │
▼ │
...

기술 파일(skill file) 자체는 의도적으로 화려하지 않게 설계되었습니다. 개념적으로는 다음과 같습니다:

---
name: weekly-revenue-brief
description: 팀을 위한 월요일 수익 요약본 작성
...

처음 한 번은, 에이전트가 처음부터 해당 절차를 찾아내기 위해 추론(reasoning)을 수행합니다. 이는 비용이 많이 들고, 느리며, 불확실합니다. 하지만 그 이후 매번, 에이전트는 단 네 줄의 마크다운(markdown)을 불러와 실행합니다. 이것이 바로 복리 효과를 내는 자산입니다. 재도출 비용(Re-derivation cost)이 0에 수렴합니다. 이 문장을 꼭 기억하세요. 이것이 다음에 이어질 모든 내용의 핵심입니다.

자산 측면: 복리가 진정으로 가치 있는 이유

이것이 왜 단순한 유용한 기능을 넘어선 것인지 구체적으로 짚어볼 가치가 있습니다. 왜냐하면 이 가치가 나중에 발생하는 비용을 감수할 정당성을 부여하기 때문입니다.

1. 재도출(Re-derivation)은 상태가 없는(stateless) 에이전트가 지불하는 보이지 않는 세금입니다. 상태가 없는 에이전트가 실제로 토큰(tokens)을 어디에 소비하는지 생각해 보십시오. 상당 부분은 문맥(context)을 다시 설정하고 이미 해결된 문제를 다시 푸는 데 사용됩니다. 기술(skill)은 단순한 데이터가 아니라, _추론(reasoning)_을 위한 캐시(cache)입니다. 일단 "월요일 요약본을 작성하는 방법"이 기술로 자리 잡으면, 모델은 새로운 계획을 만들어내는 대신 이미 알려진 계획을 실행하는 데 토큰을 사용합니다. 토큰 사용량이 줄어들고, 단계가 줄어들며, 경로를 이탈할 가능성도 줄어듭니다.

2. 결과물(artifacts)을 검사할 수 있습니다. 기술은 마크다운(markdown) 형태이고 메모리는 쿼리 가능한 저장소(queryable store)이기 때문에, 에이전트가 무엇을 배웠는지 실제로 읽을 수 있습니다. 이를 파인튜닝(fine-tuning)과 비교해 보십시오. 파인튜닝에서는 "모델이 무엇을 배웠는지"가 감사(audit)할 수 없는 수십억 개의 가중치(weights) 속에 분산되어 있습니다. Hermes의 학습은 판독 가능(legible)합니다. (이는 나중에 거버넌스(governance)를 논할 때 매우 중요해집니다. 읽을 수 없는 것은 관리할 수 없기 때문입니다.)

3. 병렬 처리를 수행합니다. Hermes는 고유한 실행 컨텍스트 (execution context)를 가진 격리된 하위 에이전트 (subagents)를 생성할 수 있습니다. 따라서 긴 작업이 팬아웃 (fan out, 예: 하나의 하위 에이전트가 초안을 작성하는 동안 메인 에이전트가 이를 취합)될 수 있으며, 결과는 다시 폴드백 (fold back, 다시 합쳐짐)됩니다. 이를 자연어 스케줄링 (natural-language scheduling) ("매일 아침 8시에 어제의 수치들을 요약해 줘")과 결합하면, 당신은 단순히 도구를 사용하는 것을 넘어 프로세스를 운영하기 시작하게 됩니다.

4. 모든 것을 당신이 소유합니다. MIT 라이선스이며, 당신의 하드웨어에서 작동하고, 모델 불가지론적 (model-agnostic, 특정 모델에 종속되지 않음)입니다 (특정 제공업체에 장애가 발생하거나 더 나은 가격이 나타나면 제공업체를 교체할 수 있습니다). 어떤 벤더 (vendor)도 당신의 에이전트를 강제로 중단시키거나 사용할 수 없게 만들 수 없습니다.

이 모든 것을 종합하면, 그 약속은 실재합니다. 즉, 처음 시작했을 때보다 작업당 비용은 더 저렴하고 주당 능력은 더 뛰어난 에이전트를 갖게 된다는 것입니다. 하지만 여기서 분석을 멈추는 것이 실수입니다. 이 모든 것을 가능하게 하는 동일한 메커니즘 (지속적이고, 스스로 작성하며, 복리로 쌓이는 산출물들)은 아무도 항목별로 상세히 기록하지 않는 청구서 뒤에 숨어 있는 메커니즘이기도 합니다.

부채 측면: 함께 복리로 쌓이는 세 가지 청구서

관점을 바꿔보겠습니다. 복리 (compounding)는 기능 (feature)이 아니라, **시스템의 속성 (property of the system)**입니다. 그리고 속성은 어느 한 편을 들지 않습니다. 능력을 복리로 쌓아 올리는 것과 동일한 루프가 세 가지 부채 (liabilities) 또한 복리로 쌓아 올리며, 이것이 바로 대중적인 글들이 생략하는 세 가지 요소입니다.

청구서 #1 — 비용 드리프트 (Cost drift)

낙관적인 이야기는 자기 개선 (self-improvement)이 에이전트를 더 저렴하게 만든다고 말합니다. 작업당 비용 측면에서는 종종 사실입니다. 하지만 두 가지 요소가 동시에 반대 방향으로 움직이며, 이들이 승리할 수도 있습니다.

• 기술은 축적되며, 축적에는 컨텍스트 비용 (context cost)이 따릅니다. 기술은 사용하기 위해 컨텍스트 (context)에 로드됩니다. 5개의 기술로 구성된 라이브러리는 비용이 들지 않지만, 가지치기(pruning)되지 않은 300개의 기술 라이브러리는 더 많은 탐색 오버헤드(discovery overhead), 어떤 기술을 적용할지 결정하는 데 더 많은 토큰 소모, 그리고 잘못된 기술이 실행될 수 있는 더 넓은 표면적을 의미합니다. 역량은 복리로 증가하며, 그만큼의 역량을 사용할 수 있게 함으로써 발생하는 호출당 오버헤드 (per-call overhead) 또한 복리로 증가합니다.
• 자율성 (Autonomy)은 자연적인 제동 장치를 제거합니다. 상태가 없는 (stateless) 챗봇은 사용자가 타이핑할 때만 비용이 발생합니다. 서브 에이전트 (subagents)에게 작업을 위임하는 예약된 상시 가동 에이전트는 당신이 잠든 동안에도 비용이 발생합니다. 이번 챌린지의 한 참가자는 밤새 실행된 작업으로 인해 47달러의 깜짝 청구서를 받고 깨어난 경험에 대해 썼습니다. 이는 특이한 실패 사례가 아니라, 감독되지 않는 루프 (unsupervised loop)가 재귀적 작업 (recursive task)을 만났을 때 나타나는 기본 동작입니다.

수치 계산하기 (벤치마크가 아닌 예시 모델). 숫자는 이를 구체화합니다. 하나의 반복되는 작업을 가져와서 입력 토큰 100만 개당 3달러, 출력 토큰 100만 개당 15달러라는 예시적인 혼합 요율로 가격을 책정해 보겠습니다. 핵심은 정확한 수치가 아니라, 곡선의 _형태 (shape)_입니다.

실행당 한계 비용 (Marginal cost per run) — 광고된 대로 작동하는 자산 측면:

모드	입력 토큰 (Input tok)	출력 토큰 (Output tok)	실행당 비용 (Cost / run)
상태 없는 재도출 (Stateless re-derivation, 매번 재계획)	9,000	2,500	$0.065
기술 캐싱 실행 (Skill-cached execution, 기술 로드 후 실행)	3,500	900	$0.024

기술이 존재하게 되면 실행당 비용이 약 63% 저렴해집니다. 이는 실제적이며 가질 만한 가치가 있습니다. 하지만 이제 시간이 흐르게 두고, 서로 상충하는 두 힘을 지켜보십시오:

복리로 증가하는 청구서 — 동일한 작업, 나중에:

단계	유효 입력/출력 토큰	일일 실행 횟수	일일 비용
기존 상태 비저장(stateless) 챗봇 (사용자가 입력할 때만 실행)	9,000 / 2,500	5	$0.33
...	...	...	...

두 가지 요소가 급증했습니다. 첫째, 스킬 라이브러리(skill-library)의 비대화로 인해 실행당 절감액의 일부가 상쇄되었습니다 ($0.024 → ~$0.039). 에이전트가 이제 200개의 스킬 중 _어느 것_이 적용되는지 결정하는 데 토큰을 소비하고, 때때로 잘못된 스킬을 실행하기 때문입니다. 둘째 — 그리고 이것이 지배적입니다 — 자율성(autonomy)이 실행 횟수를 배가시켰습니다. 실행당 비용이 가장 저렴한 설정이라 할지라도 월간 비용은 가장 높을 수 있으며, 단 한 번의 통제 불능인 재귀적 밤(subagents가 subagents를 생성하는 상황)이 하루 $3의 비용을 $47의 깜짝 청구서로 바꿔놓을 수 있습니다. 이러한 꼬리 위험(tail risk)은 청구서가 날아오기 전까지는 표에 나타나지 않습니다.

따라서 "자기 개선이 비용을 낮춘다"는 말은 절반만 맞습니다. 네, 개별 작업의 비용은 낮아집니다. 하지만 기준선(baseline)은 서서히 올라가고, 꼬리 위험(tail risk)은 커지며, 실제로 돈을 아낄 수 있느냐는 다음의 세 가지 번거로운 습관에 달려 있습니다: 오래된 스킬 정리(pruning), 지출 상한 설정(capping spend), 그리고 에이전트를 짧은 목줄로 제어하는 것(keeping the agent on a short leash). 이 중 어느 것도 저절로 일어나지 않습니다. 여러분이 직접 해야 합니다.

청구서 #2 — 스킬 드리프트(Skill drift)와 조용한 부패 (유지보수 격차)

이것은 거의 어디에서도 논의되지 않는 청구서이며, 1일 차가 아닌 90일 차에 당신을 물어뜯는 요소입니다.

스스로 작성된 스킬은 어떤 인간의 검토도 거치지 않았고, 테스트도 없으며, 소유자도 없고, 만료 기한도 없는 코드입니다. 이제 실행 시간을 앞당겨 보겠습니다:

• 해당 기술(skill)은 하나의 가정("orders API가 total_price를 반환한다")을 인코딩합니다. API가 변경되면 기술은 이를 알지 못합니다. 이제 기술은 확신에 찬 오답을 생성하며, 에이전트가 자신의 기술을 신뢰하기 때문에 이를 다시 도출하지 않고 단순히 오래된 절차를 실행할 뿐입니다. 이것이 바로 **기술 부패 (skill rot)**이며, 이는 소리 없이 실패합니다.
• 에이전트가 단 한 번의 노이즈가 섞인 성공을 바탕으로 사용 도중에 기술을 개선합니다. 이것이 **표류 (drift)**입니다. 즉, 우연을 포함하여 지난번에 운 좋게 작동했던 방식에 따라 절차가 서서히 변이하는 것입니다. 자기 개선 (self-improvement)과 과적합 (overfitting)은 희망적으로 좋은 방향을 향해 있는 동일한 그래디언트 (gradient)입니다.
• 두 기술이 중첩되어 조용히 서로 모순됩니다. 어떤 기술이 실행될지는 이제 의도가 아닌 검색 순서의 함수가 됩니다.

핵심적인 지점은 다음과 같습니다: 자기 개선 시스템은 "이것이 방금 작동했는가"를 최적화할 뿐, "이것이 여전히 올바른가"를 최적화하지 않습니다. 이 두 질문은 시간이 지남에 따라 서로 멀어지며, 루프 내의 그 어떤 것도 이를 스스로 알아차리지 못합니다. 레거시 코드 (legacy code)는 적어도 부패하는 동안에는 멈춰 있기라도 합니다. 자기 개선 에이전트의 기술 세트는 계속 움직이기 때문에, 에이전트가 무엇을 하는지에 대한 당신의 멘탈 모델 (mental model)은 기술 자체보다 훨씬 더 빠르게 노후화됩니다.

청구서 #3 — 신뢰 표면 (The trust surface)

프레임을 걷어내고 당신이 실제로 배포한 것을 살펴보십시오: 새로운 코드를 작성하고 당신이 소유한 서버에 이를 영구적으로 저장한 다음, 당신이 부여한 어떤 자격 증명(credentials)을 가지고 정해진 일정에 따라 그 코드를 실행하는 프로세스입니다.

이는 놀라운 수준의 역량이며, 대부분의 에이전트 관련 글들이 명시하지 않는 신뢰 표면 (trust surface)을 생성합니다:

• 지속성 (Persistence)은 기능인 동시에 공격자의 꿈입니다. 에이전트가 악성 기술 (malicious skill)을 작성하도록 유도하는 오염된 입력 (poisoned input)은 세션 종료 시 사라지지 않습니다. 이는 이제 관련 트리거 (trigger)가 나타날 때마다 로드되는 파일이 됩니다. 메모리 (Memory)와 기술 (skills)은 일회성 프롬프트 인젝션 (prompt injection)을 지속적인 거점 (durable foothold)으로 변모시킵니다.
• 폭발 반경 (blast radius)은 채팅창이 아니라 당신의 권한 범위 (scopes)입니다. 속성이 없는 (stateless) 챗봇이 속으면 바보 같은 말을 합니다. 하지만 속은 자율 에이전트 (autonomous agent)는 행동합니다 — 당신의 API 키, 파일 시스템, 메시징 통합 기능 (messaging integrations)을 가지고 말이죠.
• 샌드박싱 (Sandboxing)은 무시해도 되는 기본값이 아니라 선택 사항입니다. Hermes의 진정한 장점은 로컬 (local), Docker, SSH, Singularity, Modal, Daytona 등 다양한 실행 백엔드 (execution backends)를 제공한다는 점이며, 이는 정확히 에이전트가 접근할 수 있는 범위를 격리할 수 있도록 하기 위함입니다. 그것이 올바른 설계입니다. 하지만 안전한 설정은 바로 당신이 선택하는 것입니다. "당신의 서버에서 실행된다"는 말은 해방감을 주기도 하지만, 다섯 단어로 요약된 위협 모델 (threat model) 그 자체이기도 합니다.

이것이 "실행하지 마라"는 뜻은 아닙니다. 스스로 개선되는 에이전트를 대할 때 가져야 할 올바른 정서적 태도는, 운영 환경 (production) 접근 권한을 가진 날카롭고 빠르지만 잠이 부족한 주니어 엔지니어를 대하는 태도여야 한다는 뜻입니다: 엄청난 잠재력이 있지만, 코드 리뷰 (code review)를 건너뛰어서는 안 됩니다.

실패 모드 분류 체계 (A failure-mode taxonomy)

실패 모드 (failure modes)에 이름을 붙이는 것이 바로 그것에 대비한 설계를 하는 방법입니다. 여기 원인과 이를 해결하는 통제 수단 (control)에 매핑된, 실제로 발생하는 실패 모드 세트가 있습니다.