한국어로 된 런타임 표지
소개
이번에 저는 Hermes 기반 Telegram 반려봇을 여러 개 운영하는 구조를 만들어보려고 했습니다.
처음 목표는 단순했습니다. 먼저 청명을 Telegram에 안정적으로 붙이고, 그다음 유이설, bc, dg까지 확장해서 여러 개의 반려봇을 따로 운영하는 것이었습니다.
처음에는 SOUL.md + Telegram bot 연결 정도면 될 줄 알았습니다.
그런데 실제로 해보니 Hermes는 단순 챗봇 실행기가 아니라, provider, runtime, session, gateway, profile이 함께 돌아가는 구조였습니다.
그래서 이번 작업은 단순히 “텔레그램 봇 연결하기”가 아니라,
Hermes를 어떻게 확장해야 안전한지 직접 부딪혀 본 과정이 되었습니다.
진행 방법
처음에는 청명 봇을 Telegram에 연결하는 것부터 시작했습니다.
메시지를 보내면 typing 표시도 보였고, /restart 같은 명령도 반응했습니다.
여기까지는 “연결이 잘 되고 있구나”라고 생각했습니다.
'ups hermes 4'라는 단어가 표시된 검은 화면
한국 웹사이트의 홈페이지
그다음 목표는 봇을 여러 개로 늘리는 것이었습니다.
기존 환경을 그대로 복사하면 빠를 거라고 생각해서, 아래처럼 Hermes 디렉터리를 복제했습니다.
cp -r ~/.hermes ~/.hermes-bc
당시에는 이게 가장 쉬운 방법처럼 보였습니다.
기존 설정, 인증, 구조를 그대로 가져오면 새 봇도 빨리 붙을 거라고 판단했습니다.
그런데 여기서 문제가 시작됐습니다.
복제 후에는 겉으로 보면 살아 있는 것 같은데, 실제로는 이상한 증상이 나왔습니다.
Telegram 메시지는 들어왔습니다.
typing 표시도 있었습니다.
/restart도 됐습니다.terminal hook도 반응했습니다.
그런데 답변만 나오지 않았습니다.
즉 처음에는 “Telegram bot 연결이 실패했나?”라고 생각했지만,
증상을 하나씩 보면 Telegram 자체는 죽지 않았던 겁니다.
이후에는 문제를 Telegram이 아니라 Hermes 내부 구조로 좁혀서 보기 시작했습니다.
그 과정에서, 제가 한 cp -r 방식이 단순 폴더 복사가 아니라 사실상 운영 중인 runtime 상태까지 복제한 것과 비슷하다는 걸 알게 됐습니다.
문제가 될 수 있었던 항목은 이런 것들이었습니다.
- provider token
- Telegram session
- gateway state
- runtime db
- session registry
- auth rotation state
즉 저는 “봇 하나를 더 만든다”고 생각했는데, 실제로는 동작 중인 Hermes 런타임 일부를 통째로 복제한 셈이었습니다.
그 결과, bc와 dg가 꼬였을 뿐 아니라 청명까지 영향을 받으면서 멀티봇 확장이 runtime collision로 이어진 상황이 되었습니다.
이 과정을 구조로 정리하면 아래 그림이 가장 잘 보여줍니다.
다양한 언어가 표시된 화면
이후에는 복제 방식이 아니라 profile 기반으로 다시 만드는 방향이 맞다는 결론을 냈습니다.
hermes profile create <name> --clone --clone-from default
결과와 배운 점
이번 과정을 통해 가장 크게 배운 점은 두 가지입니다.
첫째, 이번 실패는 Telegram bot 실패가 아니었다는 점입니다.
실제 문제는 대부분 Hermes 내부 provider/runtime/session 충돌이었습니다.
증상을 다시 보면 이 해석이 맞습니다.
typing 표시가 있었다 → Telegram 연결은 정상
/restart가 동작했다 → gateway는 살아 있음terminal hook이 응답했다 → shell integration도 살아 있음
답변만 안 나왔다 → provider inference 쪽이 끊겼을 가능성이 큼
즉 한마디로 하면 이렇습니다.
입력은 살아 있었고, 응답을 만드는 내부 runtime이 꼬여 있었다.
둘째, Hermes는 디렉터리 복사로 확장하면 안 되는 시스템이라는 점입니다.
저는 처음에 빠르게 복제해서 여러 봇을 붙이려 했는데, 그 방식이 오히려 provider, session, gateway 상태를 같이 꼬이게 만들었습니다.
특히 “청명이 죽은 것 같다”는 느낌을 받았던 순간도, 실제로는 personality가 사라진 게 아니라 provider 연결이 실패해서 응답만 못하는 상태에 가까웠습니다.
이번 경험을 통해, 앞으로 멀티 봇을 운영하려면 아래 항목은 최소한 분리해야 한다는 기준도 잡았습니다.
Telegram token
memory
provider auth
gateway runtime
session
제 기준에서 이번 시행착오의 핵심 교훈은 이것입니다.
Hermes는 filesystem clone으로 늘리는 시스템이 아니라, profile 기반으로 분리 운영해야 하는 시스템이다.
앞으로는 청명과 유이설은 안정화하고,
bc와 dg는 기존 복제본을 억지로 살리기보다 profile 기반으로 다시 만드는 방향으로 정리할 계획입니다.
도움 받은 글
이번 글은 외부 자료를 많이 참고했다기보다,
직접 겪은 장애와 복구 과정 자체를 정리한 기록에 가깝습니다.
정리하면서 가장 도움이 된 것은:
실제 명령어 이력
Telegram에서 보인 증상
Hermes 구조를 다시 해석한 메모
복구 과정에서 확인한 provider/runtime/session 관계
