ML 인프라를 구축하며 살아갑니다 — 헤르메스 에이전트가 플랫폼 엔지니어의 판도를 바꾸는 이유
Source: Dev.to
Hermes Agent 챌린지 제출: Hermes Agent 챌린지 페이지에 대해 쓰기
지난 1년 동안 나는 NeuroScale이라는 오픈소스 AI 추론 플랫폼을 Kubernetes 위에 구축했다. 108개의 커밋, 6개의 마일스톤에 걸친 21개의 자동화된 스모크 체크. 개발자가 Backstage 폼을 채우면 드리프트 제어, 정책 가드레일, 비용 할당이 포함된 프로덕션 급 추론 엔드포인트를 바로 얻을 수 있는 플랫폼—kubectl은 전혀 필요하지 않다.
이 말을 하는 이유는 내가 어디에서 출발했는지를 이해시키기 위해서다. 나는 이렇게 말한다: Hermes Agent는 단순한 AI 코딩 어시스턴트가 아니다. 플랫폼 엔지니어처럼 실제로 사고하는 최초의 에이전트 프레임워크다.
가볍게 말하는 것이 아니다.
ML 인프라를 구축하면 한 가지를 빨리 깨닫게 된다: 모든 것이 **상태(state)**다.
ArgoCD 동기화 상태는 상태다. Kyverno 정책 위반도 상태다. Git에 있는 내용과 클러스터에 실제로 실행 중인 내용 사이의 드리프트도 상태다. 누군가가 새벽 2시에 직접 kubectl apply를 실행해 GitOps 계약을 깨뜨렸다는 사실도 역시 상태다.
내가 이전에 사용했던 모든 AI 에이전트는 Hermes 이전에 각 대화를 백지 상태로 취급했다. 아키텍처를 설명하고, 문제를 기술하고, 그럴듯한 답을 얻는다. 그리고 탭을 닫고 다음 날 다시 시작한다.
인프라 디버깅의 그라운드호그 데이다.
Hermes Agent는 구조적으로 다르며, 그 차이는 플랫폼 엔지니어가 하는 일에 직접적인 영향을 미친다.
대부분의 Hermes 관련 글은 메모리 시스템을 편의 기능으로만 강조한다. “당신의 선호도를 기억한다.” “당신의 이름을 안다.”
그것이 흥미로운 점이 아니다.
Hermes는 3계층 메모리 아키텍처를 실행한다:
- 단기 — 현재 대화 컨텍스트 (다른 모든 에이전트와 동일)
- 중기 — 대화 사이에 지속되는 세션 요약, 주기적인 “메모리 넛지”를 통해 구축
- 장기 — 특정 유형의 문제를 해결한 방식을 캡처한 Skill Document(재사용 가능한 절차)
플랫폼 엔지니어에게 이것은 이미 익숙한 런북과 직접 연결된다.
ArgoCD 동기화 실패를 트러블슈팅할 때 나는 원리부터 시작하지 않는다. 런북을 확인한다. 토큰 만료? 웹훅 설정 오류? 동기화 파동 순서? 런북은 이전 사고 해결 절차를 코드화한 것이다.
Hermes는 이를 자동으로 수행한다. 약 15개의 작업을 수행하면, ICLR 2026 Oral 발표된 GEPA 루프(Goal → Execute → self‑Prompted introspection → Adapt)가 작동한다: 자체 성능을 검토하고, 패턴을 식별하며, 새로운 Skill Document를 작성한다. 20개 이상의 자체 생성 스킬을 보유한 에이전트는 동일한 미래 작업을 새 인스턴스보다 40% 빠르게 완료한다.
그것은 “당신의 이름을 기억한다”는 수준이 아니다. 에이전트가 자체 런북 라이브러리를 구축하는 것이다. 이는 모든 실패 모드를 이미 경험한 시니어 엔지니어와 초보 온콜 엔지니어의 차이와 같다.
추상적인 가능성은 저렴하다. 이제 NeuroScale 같은 스택에서 이 차이가 실제로 어디에 적용되는지 구체적으로 살펴보자.
NeuroScale은 selfHeal: true 옵션이 켜진 ArgoCD를 사용한다—드리프트가 자동 교정된다. 하지만 ArgoCD가 잡아내기 전에 드리프트를 감지하고, 왜 발생했는지를 이해하는 것은 별개의 문제다.
다음은 Hermes가 스케줄링한 감사 작업이 실제로 어떻게 실행되는지 예시이다:
hermes task add --cron "0 */6 * * *" \
"Check the diff between Git-declared state in infrastructure/apps/ \
and live cluster state. If they diverge, summarize what changed, \
correlate with recent kubectl audit logs, and flag whether the \
change was human-initiated or a controller reconciliation. \
Send results to Telegram."대부분의 에이전트는 diff를 수행할 수 있다. Hermes가 중요한 부분을 담당한다: 시간이 흐름에 따라 패턴 라이브러리를 구축한다. 한 달간 감사를 수행한 뒤, Hermes는 serving-stack 네임스페이스의 드리프트는 거의 항상 Knative 자동 스케일러 업데이트(무해)이며, kyverno/policies/의 드리프트는 거의 항상 입장 제어를 우회한 사람에 의한 것(중요)임을 알고 있다.
그 컨텍스트는 Skill Document에 축적된다. 나는 이런 기능을 기본 제공하는 다른 에이전트 프레임워크를 본 적이 없다.
다음은 몇 주간 누적된 컨텍스트를 바탕으로 Hermes가 만든 드리프트 보고서 예시이다:
📋 Drift Audit — 2026-05-23 12:00 UTC
Cluster: neuroscale-prod
Namespaces scanned: 4
✅ serving-stack: 2 diffs detected
→ Both are Knative autoscaler reconciliations (harmless)
→ Matches pattern from Skill: "knative-autoscaler-drift"
→ No action required.
⚠️ kyverno/policies: 1 diff detected
→ ClusterPolicy "require-resource-limits" modified in-cluster
→ Not present in Git (infrastructure/policies/)
→ kubectl audit: manual apply by user "ops-admin" at 03:12 UTC
→ FLAGGED: Possible admission control bypass.
→ Recommend: Revert in-cluster change or commit to Git.
📎 Context: This is the 3rd manual policy edit in 14 days.
Previous incidents resolved by reverting. See Skill:
"kyverno-drift-response" for standard procedure.마지막 세 줄을 보라. 이것은 일반적인 diff가 아니다. 오늘의 이상 현상을 이전 감사에서 학습한 패턴과 연계해 자체 운영 이력을 참조하고 있다. 새 인스턴스는 이를 할 수 없지만, 한 달치 Skill Document를 보유한 인스턴스는 가능하다.
NeuroScale은 5개의 Kyverno ClusterPolicy를 강제한다—리소스 제한, 표준 라벨, 비루트 컨테이너, :latest 태그 금지 등. 하지만 입장 단계에서 위반을 잡으면 배포 자체가 이미 실패한 것이다. 일찍 잡을수록 수정 비용이 저렴해진다.
이때 Skill Document가 진정으로 강력해진다. 다음과 같이 특정 정책을 코드화한 스킬을 작성한다:
# Skill: NeuroScale Policy Pre-Check
## When to Use
When reviewing PRs that modify files under `apps/` or `infrastructure/`.
## Procedure
1. Check for `owner` and `cost-center` labels on all InferenceService manifests
2. Verify `resources.requests` and `resources.limits` are set
3. Flag any image tag that is `latest` or missing
4. Verify `securityContext.runAsNonRoot: true`
## Known False Positives
- ClusterServingRuntime objects are exempt from label requirements프롬프트가 아니다. 필요 시 로드되는 절차형 메모리 문서이며, 토큰을 소모하지 않는다. 새로운 위반을 발견하면 스스로 개선한다.
실제 사례: NeuroScale 개발 중 Backstage가 CrashLoop에 빠졌다. 근본 원인은 Kubernetes 서비스 어카운트 토큰 갱신 문제였다. 나는 이를 INCIDENT_BACKSTAGE_CRASHLOOP_RCA.md에 기록했다.
Hermes를 지속적으로 실행하면(5 USD VPS 혹은 유휴 시 절전되는 서버리스 백엔드에서도 가능) 다음을 수행한다:
- 스케줄된 헬스 체크로 CrashLoop 감지
- 최근 변경 사항(인증서 교체? 비밀 업데이트?)과 연계
- 기존 Skill Document에서 Backstage 사고 기록 조회
- 직접 해결하거나 구조화된 진단과 함께 에스컬레이션
다음에 유사한 문제가 발생하면, 이미 존재하는 #1 사고 스킬 덕분에 더 빠르게 해결한다. 이는 경험 많은 SRE가 시간이 지날수록 더 가치 있게 되는 복합 효과를 에이전트 메모리에 인코딩한 것이다.
다른 프레임워크(LangChain, CrewAI, AutoGen)를 살펴보면, 인프라에 특화된 Hermes의 구조적 강점은 다음과 같다:
- 로컬 우선 데이터 거주: 모든 데이터가 로컬 SQLite에 저장된다. 클러스터 자격 증명과 배포 설정을 다루는 플랫폼 엔지니어에게 이는 선택이 아니라 전제조건이다. 타인의 API로 정책 위반