Hermes cron의 HTTP 429 오류를 줄이기 위한 15분 주기 루프 중단 판단 기준 수립

과제

AI Agent를 정기 실행하면 수작업으로는 놓치기 쉬운 확인이나 개선을 자동으로 수행할 수 있습니다. ZennAI에서도 Hermes cron을 사용하여 일일 요약, Zenn 초안 작성, 운영 체크 등을 실행하고 있습니다.

반면, 짧은 간격의 잡(Job)을 너무 많이 늘리면 추론 프로바이더(Inference Provider)의 이용 한도에 걸리기 쉽습니다. 2026-05-17 운영에서는 15분 간격의 개선 루프가 여러 개 있어, HTTP 429 실패 통지나 불필요한 재실행이 눈에 띄었습니다.

이번 테마는 특정 내부 잡의 상세 내용이 아니라, Hermes cron으로 AI Agent를 안전하게 정기 운영하기 위한 중단 및 정리 규칙입니다.

하고 싶은 것

하고 싶었던 것은 다음 세 가지입니다.

• 429 오류가 발생하는 고빈도 잡을 중단하여 불필요한 실패를 줄임
• "중단하면 끝"이 아니라, 재개 조건을 명문화함
• cron의 표시상의 성공과 실제 처리의 성공을 분리하여 확인함

AI Agent는 움직이고 있는 것만으로도 일을 하고 있는 것처럼 보입니다. 이 점이 조금 위험합니다. ZennAI의 용도에서는 실제로 사업을 진전시켰는지, 실패를 늘리고 있지는 않은지까지 확인하며 운영할 필요가 있었습니다.

한 일

전날의 실무에서는 다음과 같이 정리했습니다.

• 15분 간격으로 실패를 반복하던 개선 루프를 중단 또는 일시 중지
• 재개 시에는 목적, 빈도, 알림 대상, 한도 대책의 재검토가 필요하다는 규칙을 기록
• last_status: ok를 "내부 태스크 성공"으로 간주하지 않는 운영 메모를 남김
• GitHub PR이나 일일 요약에는 공개 가능한 범위의 추상화된 배움만을 남김

포인트는 "AI를 멈추는 것"이 아니라, 실패를 반복하는 자동화를 멈추는 것입니다. 기세로 늘린 정기 잡은 나중에 정리하지 않으면 조용히 비용과 노이즈를 늘립니다. AI는 너무 편리해서 증식하기 쉽습니다. 귀엽지만, 너무 방목하면 밭을 먹어치웁니다.

절차 및 샘플

다음은 Hermes cron에서 고빈도 잡을 정리할 때의 최소 절차입니다. 실행 환경이나 Hermes의 버전에 따라 표시 항목은 달라질 수 있지만, 사고방식은 그대로 사용할 수 있습니다.

# 1. 모든 cron을 확인한다
hermes cron list --all
# 2. 관심 있는 잡의 상태를 확인한다
...

ZennAI에서는 다음과 같은 체크리스트를 만든 후 중단 및 재개를 판단하기로 했습니다.

# AI cron 정리 체크리스트
## 중단 후보
- [ ] 최근 HTTP 429 등의 한도 관련 에러를 반복하고 있다
...

나아가 일일 요약에는 다음과 같은 형식으로 남기면, 다음 날의 자신이나 다른 Agent가 혼란을 겪지 않게 됩니다.

## cron 운영 메모
- 고빈도 잡 A: paused. 이유는 한도 관련 에러의 연속.
- 고빈도 잡 B: deleted. 검증 목적이 종료되었으며 재사용 예정 없음.
...

사용해 본 소감

Hermes cron은 AI Agent를 "매일" "매시" 업무에 태우기 쉽다는 것이 강점입니다. ZennAI의 용도에서는 Zenn 초안 생성, 일일 컨텍스트 압축, GitHub PR 확인과 같이 반복성이 높은 작업과 궁합이 좋습니다.

다만, 편리하다고 해서 너무 짧은 주기로 돌리면 AI 측의 한도, GitHub 측의 상태, 작업 디렉토리의 오염, 알림 노이즈가 한꺼번에 얽히게 됩니다.

특히 배운 점은 cron이 완료된 것과 업무가 성공한 것은 다르다는 점입니다. cron 화면상으로는 성공으로 보여도, 내부적으로는 Git push에 실패했거나 참조 대상 스크립트가 존재하지 않을 수 있습니다. 이 부분을 분리해서 보는 것만으로 운영의 가시성이 상당히 좋아졌습니다.

효과

이번 정리를 통해 얻은 효과는 주로 세 가지입니다.

• 실패를 반복하는 고빈도 잡을 중단하여 한도 소비와 알림 노이즈를 줄임
• 재개 조건을 명문화함으로써 "어쩌다 보니 재개"하는 것을 방지할 수 있게 됨
• 일일 요약에 운영 판단을 남겨 다음 날의 복구 태스크로 연결하기 쉬워짐

AI Agent 운영은 구현 능력뿐만 아니라 운영 설계가 매우 중요합니다. 오히려 사업에서 사용한다면 "무엇을 돌릴 것인가"보다 "무엇을 멈출 것인가"가 더 효과적인 날도 있습니다.

어려웠던 점

어려웠던 점은 잡의 겉보기 상태와 실제 처리 결과가 어긋나는 점입니다.

예를 들어, cron으로서는 완료되었더라도 내부의 Git 조작이 실패하는 경우가 있습니다. 또한 존재하지 않는 스크립트를 참조하고 있는 잡이라도, 알림 문구를 제대로 읽지 않으면 "어떻게든 돌아가고 있다"고 오해하기 쉽습니다.

따라서 ZennAI에서는 다음과 같은 방식으로 확인하기로 했습니다.

• cron 목록: 실행 여부를 확인
• 실행 로그 (Execution Log): 내부 명령어가 성공했는지 확인
• 결과물 (Artifacts): 파일, PR (Pull Request), Issue 댓글 등이 실제로 남았는지 확인
• 다음 액션 (Next Action): 사람 또는 Agent (에이전트)가 무엇을 수정해야 하는지 확인

향후 계획

앞으로는 고빈도 잡 (High-frequency job)을 늘리기 전에, 먼저 저빈도로 가치를 확인하겠습니다.

권장하는 순서는 다음과 같습니다.

• 수동 실행으로 결과물을 확인한다
• 하루 1회 cron으로 설정한다
• 필요하다면 하루에 몇 회로 늘린다
• 15분 간격 등의 고빈도화는 명확한 가치와 상한선 대책이 있는 경우에만 실시한다

AI Agent (AI 에이전트)를 회사의 실무에 도입할 때는, "많이 움직이게 하는 것"보다 "중단 기준까지 설계하는 것"이 더 재현성이 높습니다. ZennAI에서도 이러한 운영 방식을 일간 로그, Zenn 초안, GitHub PR 운영으로 조금씩 확대해 나갈 것입니다.