Hermes Auth Readiness: 예약된 자동화가 끝까지 실행되게 만드는 법

Lede

자동화가 실패할 때 가장 위험한 장면은 큰 오류 메시지가 뜨는 순간이 아니다. 더 위험한 것은 아무 일도 일어나지 않는 것처럼 보이는데, 실제로는 필요한 외부 인증이 끊겨 작업이 끝까지 가지 못하는 상태다. 예약된 작업은 남아 있고, 스케줄도 정상이며, 프롬프트도 맞는데 provider나 GitHub, 메시징 플랫폼, 이미지 생성 계정 같은 외부 의존성이 만료되어 있으면 자동화는 마지막 단계에서 조용히 멈춘다.

Hermes Agent의 auth와 credential pool은 이 문제를 운영 표면으로 끌어올리는 기능이다. hermes login은 OAuth 기반 provider 인증을 연결하고, hermes auth add, hermes auth list, hermes auth status, hermes auth reset은 여러 credential의 상태와 소진 여부를 다룬다. 즉 auth는 “처음 한 번 로그인하는 절차”가 아니라, 자동화가 지금도 완료 가능한지 확인하는 readiness 계층이다.

개념

Hermes는 provider-agnostic agent다. OpenRouter, Anthropic, Nous, OpenAI Codex, local model, 기타 custom endpoint처럼 다양한 모델 공급자를 사용할 수 있고, 일부 provider는 OAuth 로그인을 제공한다. 또한 credential pool을 쓰면 한 provider에 여러 credential을 등록하고, 실패나 rate limit 상황에서 다른 credential로 전환하는 운영 패턴을 만들 수 있다. 이 구조는 편리하지만 동시에 점검해야 할 상태도 늘어난다.

Readiness 관점에서 중요한 구분은 “설정이 존재한다”와 “지금 성공할 수 있다”다. cron job이 등록되어 있어도 필요한 provider credential이 만료되면 실행은 실패한다. profile이 분리되어 있으면 한 프로필의 인증은 살아 있지만 다른 프로필의 인증은 비어 있을 수 있다. fallback provider가 있어도 실제로 호출 가능한 credential이 없다면 fallback은 문서상 계획에 그친다. Auth readiness는 이 차이를 사전에 드러내는 점검이다.

사용법

기본 점검은 공개 가능한 명령 표면에서 시작한다. hermes login --provider openai-codex처럼 OAuth provider를 연결하고, credential pool은 hermes auth add로 추가한다. 현재 상태는 hermes auth list 또는 hermes auth status로 확인한다. credential이 일시적으로 exhaustion 상태가 되었거나 rate limit 때문에 제외되었다면 hermes auth reset PROVIDER로 상태를 초기화할 수 있다. 로그아웃이나 재인증이 필요할 때는 hermes auth logout과 provider별 login 절차를 분리해서 다룬다.

자동화에는 이 점검을 실행 전 checklist로 붙이는 편이 좋다. 예약 작업을 만들 때는 프롬프트와 스케줄만 보지 말고, 필요한 provider, tool, repo, 메시징 delivery가 각각 인증을 요구하는지 확인한다. 특히 장기 실행 cron, 게시 워크플로, 이미지 생성, Git push처럼 외부 시스템을 통과하는 작업은 “마지막 성공 로그”보다 “지금 dry-run 또는 status check가 통과하는가”가 더 중요하다.

짧은 사이드바

한 운영 사례에서는 블로그 발행 자동화가 예약되어 있었지만 OAuth 상태가 깨지면서 실제 발행이 조용히 멈췄다. 문제는 스케줄러가 사라진 것이 아니라, 발행에 필요한 외부 credential이 더 이상 유효하지 않았다는 점이었다. 이후 기준은 단순해졌다. “job exists”는 readiness가 아니다. readiness는 “job can complete its external dependencies”다.

Pitfalls

첫 번째 함정은 인증을 설치 단계로만 보는 것이다. OAuth token은 만료될 수 있고, provider credential은 rate limit이나 exhaustion 상태가 될 수 있다. 두 번째 함정은 profile별 상태 차이를 무시하는 것이다. 사용자 터미널에서는 인증되어 있어도 agent profile에서는 다른 HOME, 다른 credential store, 다른 config를 볼 수 있다. 세 번째 함정은 실패 알림 없이 조용히 끝나는 자동화다. scheduled job에는 실행 여부뿐 아니라 외부 의존성 실패를 드러내는 로그와 알림이 필요하다.

클로징

Hermes의 auth 기능은 모델을 부르기 위한 문지기이면서, 자동화의 건강 상태를 알려주는 센서다. 잘 설계된 자동화는 스케줄만 저장하지 않는다. 필요한 credential이 살아 있는지, pool이 소진되지 않았는지, fallback이 실제로 가능한지, profile마다 같은 전제가 성립하는지를 확인한다. 조용히 멈추는 자동화를 막으려면 로그인보다 readiness를 먼저 설계해야 한다.