Hermes Agent의 칸반(Kanban) 시스템: 오픈 소스 AI 에이전트에서 가장 과소평가된 기능

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

사람들이 Hermes Agent에 대해 이야기할 때, 보통 스킬 시스템(Skills System)과 지속성 메모리(persistent memory)를 언급합니다. 그것들은 진정으로 인상적입니다. 하지만 v0.12 "Tenacity Release"에 포함된 기능 중 제가 더 많은 관심을 받아야 한다고 생각하는 기능이 있습니다. 바로 **칸반 멀티 에이전트 시스템 (Kanban multi-agent system)**입니다.

이 포스트는 이 기능이 실제로 무엇을 하는지, 왜 중요한지, 그리고 왜 대부분의 에이전트 프레임워크가 이 기능이 해결하려는 문제를 해결하지 못했는지에 대해 다룹니다.

문제점: 작업을 완료하지 못하는 에이전트들

긴 작업을 수행하는 AI 에이전트를 사용해 본 사람이라면 누구나 공감할 만한 패턴이 있습니다:

에이전트에게 복잡하고 다단계인 작업을 부여합니다. 시작은 좋습니다. 하지만 중간 어디쯤에서 — 도구 호출(tool call)이 실패하거나, 하위 프로세스(subprocess)가 멈추거나, 컨텍스트 윈도우(context window)가 가득 차거나, 모델이 상태(state)에 대해 혼란을 느끼면서 — 에이전트가 루프를 돌거나, 쓰레기 값을 생성하거나, 그냥 멈춰버립니다. 한 시간 뒤에 돌아와 보면 에이전트가 갇혀 있거나 완전히 잘못된 결과물을 내놓은 채 작업을 끝낸 것을 발견하게 됩니다.

이것은 모델의 지능 문제가 아닙니다. 이것은 상태 관리(state management) 및 결함 허용(fault tolerance)의 문제입니다. 에이전트는 자신이 무엇을 했는지, 무엇이 대기 중인지, 무엇이 실패했는지에 대한 영구적인 기록을 가지고 있지 않습니다. 무언가 잘못되었을 때, 복구 경로가 없습니다.

Hermes의 칸반 시스템은 이에 대한 직접적인 해답입니다.

칸반 시스템이란 무엇인가

칸반은 영구적인 멀티 에이전트 작업 보드(durable multi-agent task board)로 제공됩니다. 이는 명시적인 상태 전환(state transitions), 내장된 결함 허용(fault tolerance), 그리고 자동 복구 기능을 갖춘 구조화된 작업 큐(queue)입니다.

보드 위의 작업들은 todo, in_progress, blocked, done, failed 상태를 가집니다. 보드는 재시작 후에도 유지됩니다. 작업을 수행하는 에이전트들은 하트비트(heartbeats)를 방출합니다. 만약 하트비트가 중단되면, 해당 작업은 자동으로 회수되어 재시도되거나 에스컬레이션(escalated)됩니다.

핵심 구성 요소:

하트비트 모니터링 (Heartbeat monitoring) — 모든 활성 작업에는 하트비트 타이머가 있습니다. 작업을 수행하던 에이전트가 하트비트 윈도우를 놓치면 (충돌이 발생했거나, 멈췄거나, 프로세스가 종료된 경우), 시스템이 이를 자동으로 감지합니다.

좀비 탐지 (Zombie detection) — "좀비"란 응답을 중단했지만 깔끔하게 종료되지 않은 에이전트를 의미합니다. 시스템은 좀비 에이전트를 감지하여, 해당 작업이 영원히 in_progress (진행 중) 상태로 멈춰 있지 않도록 작업을 회수합니다.

불완전한 종료 시 자동 차단 (Auto-block on incomplete exit) — 작업에 할당된 에이전트가 작업을 완료(done) 또는 실패(failed)로 표시하지 않고 종료할 경우, 보드는 자동으로 해당 작업을 blocked (차단됨) 상태로 이동시킵니다. 아무것도 조용히 누락되지 않습니다.

작업별 재시도 (Per-task retries) — 실패한 작업은 에스컬레이션(escalation)되기 전까지 최대 N번까지 자동으로 재시도하도록 설정할 수 있습니다. 재시도 정책(retry policy)은 작업별 또는 보드별로 설정할 수 있습니다.

환각 복구 (Hallucination recovery) — 이 기능은 미묘합니다. 에이전트가 자신의 작업 로그와 모순되는 출력(실행하지 않은 단계를 완료했다고 주장하는 경우 등)을 생성하면, 보드는 이러한 불일치를 감지하고 작업을 조용히 완료로 표시하는 대신 검토를 위해 플래그(flag)를 지정합니다.

/goal 명령어: 목표 유지하기

칸반(Kanban)과 더불어, v0.12 릴리스에는 문서에서 "Ralph 루프"라고 부르는 /goal 명령어가 추가되었습니다.

/goal 세션 종료 전까지 테스트와 PR을 포함한 인증 모듈을 배포할 것

이 명령어는 에이전트가 여러 턴(turn)에 걸쳐 목표에 집중할 수 있게 합니다. 각 메시지가 독립적으로 해석되는 대신, 모든 후속 작업은 선언된 목표에 따라 평가됩니다. 에이전트는 경로를 이탈하지 않습니다. 만약 하위 작업(sub-task)이 목표에서 벗어나게 만든다면, 에이전트는 이를 인지하고 다시 궤도로 돌아옵니다.

칸반과 결합하면 다음과 같은 과정이 이루어집니다:

1. 사용자가 목표를 선언합니다.
2. Hermes가 이를 작업 단위의 칸반 보드로 분해합니다.
3. 하위 에이전트(Subagents)들이 작업을 가져가 병렬로 수행합니다.
4. 실패한 작업은 재시도되고, 좀비 에이전트의 작업은 회수되며, 차단된 작업은 에스컬레이션됩니다.
5. 에이전트는 원래 목표 대비 진행 상황을 추적하며, 실제로 완료된 시점을 파악합니다.

이것이 바로 "에이전트가 시작한 일을 끝마친다"는 것이 실제로 구현된 모습입니다.

하위 에이전트 위임: 병렬성 계층

칸반 시스템은 delegate_task 도구를 통한 Hermes의 하위 에이전트 위임(subagent delegation)과 결합될 때 가장 강력한 힘을 발휘합니다.

복잡한 작업을 수행하는 부모 에이전트(parent agent)는 기본적으로(설정 가능) 최대 3개의 자식 에이전트(child agents)를 생성할 수 있으며, 각 자식 에이전트는 다음과 같은 특징을 가집니다:

• 격리된 컨텍스트 (Isolated context) (하위 에이전트는 자신에게 필요한 정보만 알고 있음)
• 제한된 도구 세트 (Restricted toolsets) (자신의 작업과 관련된 도구만 사용할 수 있음)
• 자체 터미널 세션 (Its own terminal session) (에이전트 간의 파일 상태 충돌 없음)

부모 에이전트는 직접 작업을 수행하는 것이 아니라 조정(coordinate) 역할을 합니다. 부모 에이전트는 작업을 위임하고, 칸반(Kanban) 보드를 통해 진행 상황을 모니터링하며, 에스컬레이션(escalations)을 처리하고, 결과를 합성(synthesize)합니다.

실제 사례는 다음과 같습니다:

부모(Parent): "인증, 테스트 및 문서화가 포함된 REST API를 구축하라"

→ 하위 에이전트 1(Subagent 1): 핵심 API 엔드포인트 구현
...

지속 가능한 상태 관리(durable state management)가 없다면 병렬 하위 에이전트들은 취약합니다. 하나가 실패하면 어떤 것인지 알 수 없고 복구는 수동으로 이루어져야 합니다. 칸반 보드는 작업 상태를 명시적이고 복구 가능하게 만듦으로써 병렬 실행을 안전하게 만듭니다.

Checkpoints v2: 안전망 (The Safety Net)

실제 작업을 수행하는 병렬 에이전트들을 실행한다는 것은 실제적인 위험을 의미합니다. 파일을 변경하는 하위 에이전트가 잘못된 동작을 할 수 있기 때문입니다.

Hermes의 Checkpoints v2 (Tenacity Release의 일부이기도 함)가 이를 처리합니다. 어떠한 파일 변이(file mutation)가 일어나기 전에, 시스템은 작업 디렉토리를 자동으로 스냅샷(snapshot)합니다. checkpoint_manager는 실제 가지치기(pruning) 기능을 통해 이러한 스냅샷을 추적합니다. 즉, 오래된 체크포인트는 무한히 축적되지 않고 정리됩니다.

문제가 발생하면:

/rollback

이것이 전부입니다. 마지막 파일 변이 작업 이전 상태로 돌아갑니다. 칸반 보드의 작업 상태와 결합되어, 이는 멀티 에이전트 실행이 실패하더라도 알 수 없는 상태로 부분적으로 변이된 코드베이스를 남기지 않음을 의미합니다.

Gateway Auto-Resume: 재시작으로부터의 생존

신뢰성 측면의 또 다른 요소는 게이트웨이 자동 재개(gateway auto-resume)입니다.

이전 버전에서는 Hermes 게이트웨이 프로세스가 재시작되면(서버 재부팅, OOM kill, 네트워크 끊김 등), 진행 중이던 모든 에이전트 세션이 손실되었습니다. 사용자는 작업을 수동으로 다시 시작해야만 했습니다.

Tenacity Release를 통해, 게이트웨이는 재시작 후 중단된 세션을 자동으로 재개합니다. 칸반(Kanban) 보드 상태가 유지(persisted)되며, 진행 중이던 작업들이 회수(reclaimed)되어 에이전트가 중단되었던 지점 근처에서 작업을 다시 시작합니다.

이는 VPS나 컨테이너에서 Hermes를 실행하는 사용자에게 생각보다 훨씬 중요한 문제입니다. 프로세스 충돌(Process crashes)은 언제든 발생할 수 있습니다. 이러한 충돌로부터 우아하게 살아남는 에이전트 시스템은, 지속적인 관리(babysitting)가 필요한 시스템과는 차원이 다른 도구입니다.

이 아키텍처가 희귀한 이유

대부분의 에이전트 프레임워크(agent frameworks)는 내구성이 있는 멀티 에이전트 작업 관리(durable multi-agent task management)에 대한 대등한 해답을 가지고 있지 않습니다. 그 이유는 다음과 같습니다.

연구 커뮤니티는 단일 에이전트 성능에 최적화되어 있습니다. 벤치마크(Benchmarks)는 거의 모두 단일 에이전트 중심입니다. 즉, 에이전트가 이 코딩 문제를 해결할 수 있는지, 이 질문에 답할 수 있는지, 이 작업을 완료할 수 있는지에 집중합니다. 결함 허용(fault tolerance)을 갖춘 멀티 에이전트 협업은 벤치마크의 문제가 아니라 엔지니어링의 문제입니다.

내구성 있는 상태(Durable state)를 유지하는 것은 어렵습니다. 대부분의 프레임워크는 작업 상태를 메모리나 단순한 파일에 저장합니다. 진정한 의미의 내구성—하트비트 모니터링(heartbeat monitoring), 좀비 프로세스 탐지(zombie detection), 재시작 복구(restart recovery)—를 구현하려면 대부분의 오픈 소스 프로젝트가 감당하기 어려운 수준의 인프라 투자가 필요합니다.

실패 모드(failure modes)가 미묘합니다. 명확하게 실패하는 에이전트는 수정하기 쉽습니다. 하지만 잘못된 방식으로 성공하는 에이전트—예를 들어 마지막 단계를 환각(hallucination)하여 작업을 완료된 것으로 표시하는 경우—는 명시적인 검증 없이는 탐지하기 어렵습니다. 대부분의 프레임워크는 작업 관리 계층(task management layer)에 환각 복구(hallucination recovery) 기능을 갖추고 있지 않습니다.

제가 알기로 Hermes는 이 모든 기능을 단일 설치 패키지에 담아 제공하는 유일한 오픈 소스 에이전트 프레임워크입니다.

칸반 시스템을 사용해야 하는 경우

칸반(Kanban)과 서브 에이전트 위임(subagent delegation) 방식은 단순한 작업에는 과할 수 있습니다. 다음과 같은 경우에 사용하십시오:

• 작업을 완료하는 데 20~30분 이상 소요되는 경우
• 병렬로 실행 가능한 여러 개의 독립적인 하위 작업(subtasks)이 있는 경우
• 무인 상태로 실행하는 경우 (예: 예약된 cron, 야간 배치 작업)
• 부분적인 완료나 알 수 없는 상태로 인한 비용이 높은 경우 (예: 프로덕션 배포, 대규모 코드베이스)
• 발생한 일에 대한 명확한 감사 추적(audit trail)이 필요한 경우

대화형 작업, 빠른 조회 또는 일회성 자동화의 경우에는 일반적인 Hermes 채팅을 사용하면 됩니다. 칸반(Kanban)은 본격적인 워크로드(workloads)를 위한 것입니다.

종합하기

# 멀티 에이전트 프로젝트 시작
/goal 완전한 사용자 인증 모듈 구축: JWT, 리프레시 토큰(refresh tokens), 테스트, 문서

...

v0.12 "Tenacity Release"는 864개의 커밋(commits), 588개의 병합된 PR(merged PRs)을 배포했으며, 282개의 이슈(issues)를 종료했습니다 (P0 13개 및 P1 36개 포함).
칸반(Kanban) 시스템이 핵심이지만, 보안 파도(WhatsApp의 기본 외부인 거부, Discord 역할 허용 목록(role-allowlists), 기본 활성화된 레드액션(redaction))와 20번째 플랫폼으로서의 Google Chat 또한 주목할 만합니다.

"Tenacity"라는 이름은 정확합니다. 이번 릴리스는 에이전트가 시작한 일을 끝마치고, 예방할 수 없는 상황에서도 살아남으며, 무엇이 잘못되었는지에 대해 정직해지는 것에 관한 것입니다.

이는 단순한 원시 능력(raw capability)보다 더 어려운 문제이며, 실제 프로덕션(production) 사용에서 정말로 중요한 문제입니다.

시작하기:

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

Docs: Subagent Delegation · GitHub Release Notes