Hermes Agent를 설치하고 봇도 여러 개 만들었는데, 정작 결과물보다 중간 지시와 오류 확인에 시간을 더 쓰고 있다면 구성을 다시 볼 때다. 모델을 바꾸거나 컴퓨터를 새로 사기 전에 Hermes Agent 사용법에서 운영 기준부터 점검해 보자.
쫑대표의 딸깍일기는 자신의 경험과 구독자 사례를 바탕으로 피할 일을 일곱 가지로 정리했다. 영상의 운영 제안을 2026년 11월 10일 확인한 공식 문서·연구와 대조했다. 직접 비용 절감이나 성능 개선을 측정한 실험은 아니며, 연구에서 나온 비율도 모든 업무에 그대로 적용되는 수치는 아니다.
1. 에이전트를 늘리기 전에 하나로 작업을 끝내 본다
총괄·조사·디자인·작성 봇을 먼저 만들면 조직도는 그럴듯하다. 하지만 결과를 다음 담당자에게 누가 넘기는지, 중간에 막히면 누가 확인하는지 정하지 않았다면 사용자가 계속 전달자가 된다.
처음에는 에이전트 하나에 목표·입력 자료·완료 기준을 주고 실제 산출물까지 받아보자. 반복하는 절차는 스킬로 정리하고, 별도 역할이 필요한 부분이 확인되면 분리를 검토하는 순서다.
여러 에이전트가 늘 불리한 것은 아니다. Google Research의 연구 소개는 180개 구성을 비교했다. 병렬화하기 좋은 과업에서는 이점이 있었지만, 순차 계획 과업인 PlanCraft에서는 시험한 다중 에이전트 방식의 성능이 단일 방식보다 떨어졌다고 보고한다. 같은 결과를 모든 업무의 성능 하락으로 확대해서는 안 된다.
Anthropic의 다중 에이전트 연구 시스템도 독립적인 조사 방향을 병렬로 탐색하는 이점을 설명한다. 동시에 자사 데이터에서 일반 채팅 대비 에이전트는 약 4배, 다중 에이전트는 약 15배의 토큰을 사용했다고 적었다. 15배의 비교 기준은 단일 에이전트가 아니라 채팅이다. 현재 Hermes의 비용이 반드시 이 배수로 늘어난다는 뜻도 아니다.
스킬을 먼저 정리하자는 제안 역시 만능 공식은 아니다. 단일 에이전트와 스킬을 다룬 기술보고서는 일부 추론 벤치마크에서 효율 개선 가능성을 보였지만, 의미가 비슷한 스킬이 늘어나면 선택이 어려워질 수 있다는 한계도 다룬다. 스킬 수보다 역할과 적용 조건을 구분하는 일이 먼저다.
2. 봇끼리 대화시키기보다 작업 인계 방식을 정한다
봇들이 서로 말을 주고받는 모습과 일을 정확히 넘기는 것은 다르다. 보낸 메시지를 상대가 받았는지, 필요한 자료에 접근했는지, 결과물이 생성됐는지를 따로 확인해야 한다.
Hermes Kanban은 작업·담당·상태·인계 기록을 남기는 방식이다. 짧은 독립 과업의 위임과 달리 재시도나 검토 이력을 관리해야 하는 일에 활용할 수 있다. 카드가 완료로 바뀌었다는 사실만으로 결과물의 품질까지 보장되는 것은 아니다.
처음 맡길 때는 아래처럼 요청을 구체화해 보자. 영상의 문장을 그대로 복제한 것이 아니라 작업 계약을 명확하게 만든 예시다.
목표: 제공한 자료로 주간 운영 보고서 초안을 만든다.
담당: 이번 작업을 맡은 에이전트 한 명이 최종본을 정리한다.
입력: 최신 자료와 작성 기준을 먼저 확인한다.
산출물: 보고서 초안, 사용한 출처, 확인하지 못한 사항을 구분한다.
완료 기준: 요청 항목이 모두 있고 출처와 수치가 원자료에 연결된다.
예외: 자료가 없으면 추정하지 말고 막힌 항목과 필요한 입력을 보고한다.
승인: 외부 발송이나 공개 업로드는 하지 않고 검토를 기다린다.
봇 간 통신이 무조건 불가능한 것은 아니다
여기서는 기본 차단 원칙과 선택적 통신 기능을 구분해야 한다. Telegram의 일반 FAQ에는 봇 간 메시지를 막는 설명이 있다. 반면 현재의 봇 간 통신 전용 문서는 모드 설정과 메시지 유형에 따른 조건부 통신을 설명한다. 그룹의 멘션·답장 조건과 개인 대화의 조건도 같지 않다.
Hermes도 현재 Desktop Bot Mode에서 멘션 위임과 그룹 대화를 안내한다. 따라서 ‘봇 간 전달은 모두 요청 단계’라거나 ‘칸반만 가능하다’고 일반화하지 않는 편이 정확하다. 설치 버전·대화 방식·연결 플랫폼에 따라 확인할 조건이 다르다.
통신이 된다고 무한 대화를 허용할 이유도 없다. 반복 메시지 차단, 종료 조건, 최대 반복·대기 시간, 최종 보고 담당을 정해두자. 또한 칸반 화면을 만든 것과 외부에 공개해도 되는 고정 링크를 만든 것은 별개다. 공유 범위와 인증부터 확인해야 한다.
3. 맥락과 규칙을 지우기 전에 원인부터 진단한다
대화가 길어졌다고 모든 문제가 맥락 때문인 것은 아니다. 실제 사용 모델이 바뀌었거나 필요한 도구·스킬이 빠졌을 수도 있고, 압축 과정에서 중요한 조건이 요약됐을 수도 있다.
Chroma의 Context Rot 연구는 18개 모델을 대상으로 입력 길이에 따른 비균일한 성능 변화를 살폈다. 이는 긴 입력을 주면 항상 실패한다는 뜻이 아니다. Anthropic의 맥락 관리 안내 역시 짧게 쓰는 것 자체보다 필요한 정보를 충분히 담은 고신호 맥락을 구성하는 데 초점을 둔다.
Hermes 공식 품질 진단 가이드는 실제 모델·제공자, 맥락 사용량, 감지된 맥락 한도, 메모리 반영 시점, 스킬·도구와 압축 영향을 함께 확인하도록 안내한다.
따라서 ‘기억 파일을 싹 지워줘’보다는 먼저 진단을 요청하자.
현재 상태를 변경하지 말고 답변 품질이 달라진 원인을 진단해라.
실제 사용 모델·제공자, 맥락 사용량, 필요한 도구와 스킬의 존재를 확인해라.
오래된 기준, 중복 규칙, 서로 충돌하는 지시가 있는지 근거를 찾아라.
확인된 사실과 추정을 구분하고 비밀값은 보고서에 노출하지 마라.
각 문제의 영향과 최소 수정안을 제시해라.
삭제·압축·설정 변경은 먼저 실행하지 말고 내 검토를 기다려라.
이 요청 역시 블로그의 재구성 예시다. 자동으로 원인이 발견되거나 성능이 회복된다는 보장은 아니다. 특히 메모리 저장과 현재 세션의 반영 시점은 구분해야 한다. 공식 문서는 세션 시작 시 주입되는 메모리 스냅샷과 디스크에 저장된 최신 상태가 다를 수 있음을 설명한다.
4. 실행 장비는 맡길 작업과 모델 위치를 보고 고른다
외부 API로 모델을 호출하는 경우와 내 컴퓨터에서 모델을 직접 실행하는 경우는 자원 요구가 다르다. 브라우저를 여러 개 띄우거나 이미지·영상 처리를 하는 작업도 별도로 봐야 한다.
따라서 ‘Hermes에는 특정 용량의 RAM과 GPU가 필수’라는 식으로 구매 기준을 고정하기는 어렵다. 먼저 아래 항목을 적어보자.
- 모델 추론은 외부 서비스에서 하는가, 이 장비에서 하는가.
- 브라우저와 파일 처리 도구를 얼마나 함께 사용하는가.
- 작업이 계속 돌아가야 하는가, 필요할 때만 실행해도 되는가.
- 절전·재부팅·네트워크 단절이 발생하면 어떻게 확인할 것인가.
- 실제 작업 중 메모리·디스크·응답 속도에서 무엇이 부족한가.
원격으로 접속하는 기기마다 모델 실행용 장비를 마련할 필요도 없다. 실행 서버와 접속용 노트북·휴대전화의 역할을 구분할 수 있다. 다만 남는 컴퓨터라는 이유만으로 회사 자료나 개인 계정을 무제한으로 연결하는 것은 피하자. 권한과 저장 범위를 먼저 정해야 한다.
5. 실행 환경과 자료 보관·백업을 따로 설계한다
에이전트가 실행되는 장소, 작업 자료가 쌓이는 장소, 복구용 사본을 보관하는 장소는 같은 문제가 아니다. 한 컴퓨터에서 모든 것을 운영할 수는 있지만, 그 컴퓨터가 고장 났을 때 무엇을 복구해야 하는지는 정해두어야 한다.
백업 대상도 보고서 파일만으로 끝나지 않는다. 자신의 구성에 따라 기억·스킬·설정·작업 원본·상태 데이터가 포함될 수 있다. 자격증명처럼 민감한 정보는 보관 권한과 보호 방법을 따로 검토하자.
다음은 특정 업체를 추천하는 대신 적용해 볼 수 있는 백업 운영안이다.
- 복구해야 할 파일과 상태 데이터의 목록을 만든다.
- 동시 쓰기 중인 상태 데이터는 일관된 방식으로 사본을 확보한다.
- 원본 장비의 장애와 별개로 남는 사본을 둔다.
- 복구에 필요한 비밀정보의 접근 권한을 제한한다.
- 사본이 있다는 확인에 그치지 않고 복원 절차를 시험한다.
동기화도 백업과 구분해야 한다. 잘못 삭제하거나 덮어쓴 상태가 그대로 전파될 수 있기 때문이다. 영상의 특정 저장 장비나 클라우드 업체 선택을 모든 사람에게 가장 저렴하거나 안전한 구성으로 받아들일 필요는 없다.
6. 여러 기기를 연결하는 것과 상태를 동기화하는 것을 구분한다
영상에서는 실행 장비와 자료 저장소를 나누고 다른 기기에서 접속하는 개인 구성을 보여준다. 이때 Tailscale 같은 사설 네트워크 연결은 기기가 서로 접근할 경로를 만드는 역할이다. 그 자체가 모든 파일·기억·세션을 같은 상태로 맞추는 기능은 아니다.
다음 네 가지를 따로 적어두면 혼동이 줄어든다.
- 실행 주체: 실제 에이전트와 작업 프로세스가 돌아가는 곳
- 자료 원본: 최종 기준 파일을 보관하는 곳
- 접속 창구: 지시하고 결과를 확인하는 앱이나 메시징 채널
- 복구 사본: 장애 후 되돌릴 수 있는 백업
처음에는 실행 주체와 원본 위치를 명확하게 두고 다른 기기에서 접속하는 구성을 검토해 볼 수 있다. 그렇다고 여러 설치가 모두 잘못이라는 뜻은 아니다. 별도 사용자나 업무를 분리해야 한다면 목적에 맞는 구성이 필요하다.
Hermes 프로필 문서는 독립 에이전트의 상태를 프로필로 나누고, 같은 상태 폴더를 여러 에이전트의 동시 쓰기 대상으로 삼지 말라고 경고한다. 프로필을 나누는 것과 운영체제 파일 권한까지 격리하는 것도 별개다. 고객·팀 자료를 구분해야 한다면 보안 경계를 따로 설계해야 한다.
7. 새로 만드는 일과 반복 운영을 나누되 기능의 한계로 단정하지 않는다
진행자는 서비스를 만드는 일에는 Claude·Codex를, 만들어진 서비스를 매일 사용하는 일에는 Hermes를 쓰는 방식을 제안한다. 개발과 운영을 분리하는 실무 전략으로 볼 수 있다.
하지만 Hermes가 코딩을 못한다는 뜻은 아니다. 공식 소개도 코딩과 도구 실행, 위임, 스킬과 일정 기반 자동화를 포함한다. 맡길 일을 나누는 이유는 제품 이름보다 테스트·배포·권한·실행 환경과 결과 확인 방식에 있다.
새로운 기능을 만든다면 코드와 테스트, 설정 방법, 필요한 권한, 실패 시 복구 방법까지 정리하자. 이후 운영 담당에게는 안정된 실행 절차와 상태 확인 방법을 넘긴다. ‘만들었다’는 말만 듣고 반복 실행에 연결하지 않는 편이 좋다.
또한 스킬과 기억이 쌓인다는 설명을 모델 가중치가 자동으로 재훈련된다는 뜻으로 읽지는 말자. 재사용할 절차와 기준을 문서화하는 것, 모델 자체를 학습시키는 것은 서로 다른 과정이다.
처음에는 작은 작업 하나의 완료 기준부터 정한다
봇을 더 만들지, 더 큰 컴퓨터를 살지 고민하기 전에 지금 맡기는 작업 하나를 골라보자. 입력·산출물·확인 방법이 적혀 있고, 실패했을 때 어디서 멈췄는지 알 수 있는가.
그 흐름이 잡혀 있다면 반복 절차를 스킬로 정리하고 필요한 부분만 나누면 된다. 영상에서 가져갈 만한 운영 원칙도 이쪽에 가깝다. 에이전트의 수나 대화량을 늘리는 것보다, 일을 맡기고 결과를 확인할 수 있는 구조를 먼저 만드는 것이다.
함께 읽을 글
참고자료
- 쫑대표의 딸깍일기, Hermes 운영 시 피할 일곱 가지
- Hermes Agent 공식 문서
- Hermes, 품질 저하 진단 체크리스트
- Google Research, 에이전트 구성과 과업 특성 연구
- Anthropic, 다중 에이전트 연구 시스템
- 단일 에이전트와 스킬을 비교한 예비 기술보고서
- Chroma, Context Rot 연구
- Telegram, 조건부 봇 간 통신 안내
캡처는 원본 영상의 운영 제안을 설명·비평하기 위해 인용했다. 화면의 개념도는 실제 대시보드나 독립 실행 실험의 증거가 아니다. 구독자 대화 분석은 제작자의 자체 사례 검토이며 전체 사용자를 대표하는 통계로 보지 않았다. 모임·멤버십 안내, 특정 업체의 최저가 주장과 향후 모델 출시 전망은 검증된 운영 사실로 인용하지 않았다.
FAQ
처음부터 Hermes 봇을 여러 개 만들어야 하나요?
그럴 필요는 없다. 하나로 작업을 끝내 보고 반복 절차를 스킬로 정리한 뒤, 독립적인 조사·역할·자료 범위가 필요할 때 분리를 검토할 수 있다. 여러 에이전트가 유리한지는 과업의 병렬성, 인계 비용, 검증 방식에 따라 달라진다.
Telegram이나 Hermes의 봇끼리 대화하는 것은 불가능한가요?
무조건 불가능하지는 않다. Telegram은 선택적 통신 모드와 메시지 유형·대화 환경에 따라 조건을 달리한다. Hermes Desktop Bot Mode도 멘션과 그룹 대화를 제공한다. 다만 서로 메시지를 주고받는 것과 업무를 정확하게 인계·완료하는 것은 별개다.
Hermes를 쓰려면 고사양 컴퓨터를 사야 하나요?
모델을 어디서 실행하고 어떤 도구를 함께 쓰는지에 따라 다르다. 외부 모델 호출, 로컬 모델 실행, 브라우저·영상 처리는 요구 자원이 같지 않다. 실제 작업의 병목을 확인한 뒤 장비 변경을 검토하는 편이 낫다.
답변이 나빠지면 기억 파일과 규칙을 지워야 하나요?
삭제부터 하지 말자. 실제 모델·제공자, 맥락 상태, 필요한 스킬·도구, 압축 영향과 충돌 규칙을 먼저 확인한다. 근거와 최소 수정안을 검토한 뒤 변경하고, 필요한 경우 되돌릴 수 있는 사본을 남긴다.