AI 에이전트가 장애를 찾아냈습니다. 하지만 저는 여전히 에이전트에게 kubectl 권한을 주지는 않을 것입니다.

잘못된 결제 서비스 배포가 체크아웃 기능을 망가뜨리고 있었습니다. 장애 대응 에이전트(incident agent)는 실패한 요청들을 찾아내고, 이를 배포와 연결했으며, 올바른 해결책을 제안했습니다: payment-service를 롤백(roll back)하는 것이었습니다.

그럼에도 저는 여전히 에이전트에게 Kubernetes 자격 증명(credential)을 주고 싶지 않았습니다.

이러한 긴장감이 바로 SigNoz 에이전트 해커톤(Agents of SigNoz hackathon)을 위해 제가 만든 프로젝트인 MANDATE가 되었습니다. 이는 AI 에이전트와 실제 시스템을 변경할 수 있는 도구들 사이의 권한 계층(authority layer)입니다. SigNoz는 단순히 사후에 트레이스(traces)를 보내는 곳이 아닙니다. SigNoz는 장애를 감지하고, 의사결정을 위한 제한된 증거(bounded evidence)를 제공하며, 승인 및 실행 경로를 기록하고, 시스템이 실제로 복구되었는지 확인합니다.

에이전트 관측성(observability)에서 누락된 부분

일반적인 에이전트 트레이싱(tracing)은 다음과 같은 유용한 질문에 답할 수 있습니다: 어떤 모델이 실행되었는가? 어떤 도구를 호출했는가? 얼마나 걸렸는가? 토큰을 얼마나 사용했는가?

하지만 행동을 취하는 에이전트(action-taking agent)를 위해서는 또 다른 답변 세트가 필요했습니다:

• 누가 이 에이전트에게 권한을 부여했는가?
• 어떤 도구와 리소스가 범위(scope) 내에 있었는가?
• 어떤 실시간 증거가 해당 행동을 정당화했는가?
• 정책이 이를 허용했는가, 거부했는가, 아니면 승인을 위해 일시 중지했는가?
• 운영자가 승인한 정확한 인자(arguments)는 무엇인가?
• 해당 행동이 실제 시스템에서 작동했는가?

MANDATE는 이러한 결정들을 모델 외부에서 유지합니다. 에이전트는 유용한 다음 단계를 제안할 수 있지만, 결정론적 게이트웨이(deterministic gateway)가 서명된 위임장(mandate)과 운영자 소유의 설정으로부터 신원, 리소스 범위, 리스크, 예산, 증거 요구 사항 및 승인 정책을 도출합니다.

참조 스택은 Python/FastAPI 게이트웨이, Next.js 운영 콘솔, Slack 승인, Kind Kubernetes 워크로드, OpenTelemetry, 그리고 Foundry를 통해 프로비저닝된 자체 호스팅 SigNoz 배포를 사용합니다. 에이전트는 MCP 또는 REST를 통해 연결되는 반면, Kubernetes 자격 증명(credentials)과 SigNoz 서비스 계정(service-account) 키는 게이트웨이 측에 유지됩니다.

테스트를 위해 사용한 장애 상황

데모는 의도적으로 작게 구성되었습니다: checkout-service가 payment-service를 호출합니다. 통제된 릴리스(release)를 통해 결제(payment) 배포를 성능이 저하된(regressed) 이미지로 변경하여 결제 실패를 발생시킵니다.

하나의 네이티브 SigNoz 메트릭(metric) 경보는 5분간의 결제 실패율을 감시합니다:

name: checkout SLO breach
condition: >
  100 * sum(rate({"checkout_requests_failed_total"}[5m]))
...

두 번째 트레이스(trace) 기반 규칙은 mandate.release.regressed = true인 mandate.release.deploy라는 이름의 스팬(span)을 감지합니다. 이를 통해 에이전트에게 빨간색 그래프를 보고 추측하라고 요청하는 대신, 고객 영향도와 릴리스 마커(release marker)를 모두 제공할 수 있습니다.

MANDATE Incident Command 대시보드는 결제 오류율, 결제 지연 시간(latency), 실패한 요청 트레이스, 릴리스 마커, Kubernetes 상태, 그리고 복구 증거를 결합하여 보여줍니다.

서비스 또는 릴리스 경보가 발생하면, SigNoz는 MANDATE로 웹훅(webhook)을 보냅니다. 장애 코디네이터(incident coordinator)는 수명이 짧은 루트 권한(root mandate)을 받은 다음, 읽기 전용 조사 권한을 SigNoz 조사관(investigator)에게 위임합니다. 이 자식 에이전트는 결제 배포를 점검하고 제한된 SigNoz 증거 번들(evidence bundle)을 쿼리할 수 있지만, 새로운 도구, 더 큰 예산(budget), 또는 더 넓은 리소스 범위를 상속받을 수는 없습니다.

제안된 롤백 (rollback)은 독립적으로 제어됩니다:

k8s.rollback_deployment:
  enabled: true
  source: kubernetes
...

게이트웨이 (gateway)는 대상 (target), 표준 인자 (canonical arguments), 증거 다이제스트 (evidence digest), 정책 버전 (policy version), 영향 범위 (blast radius), 그리고 만료 시간 (expiry)을 포함하는 불변의 실행 계획 (immutable action plan)을 기록합니다. 운영자는 Slack이나 MANDATE 콘솔에서 모호한 “에이전트 승인” 버튼이 아니라, 바로 그 정확한 계획을 확인하게 됩니다.

승인은 단지 해당 작업을 다음 체크포인트 (checkpoint)로 진행시킬 뿐입니다. 실행 직전에 게이트웨이는 위임 사항 (mandate), 인자 다이제스트 (argument digest), 만료 시간 (expiry), 예산 (budget), 감사 체인 (audit chain), 의존성 상태 (dependency health), 그리고 실시간 증거 (live evidence)를 재검증합니다. 오직 그 후에야 게이트웨이는 롤백을 수행합니다. 이후에는 사후 상태 (post-state)를 쿼리하고 검증 (verification)을 별도의 단계로 기록합니다.

SigNoz 활용 방법

결과적으로 저는 서로 연관된 두 개의 텔레메트리 (telemetry) 경로를 갖게 되었습니다:

1. 에이전트 런타임 (Agent-runtime) 텔레메트리는 모델 호출 (model calls), 하위 에이전트 (subagents), 도구 호출 (tool calls), 지연 시간 (latency), 토큰 사용량 (token use), 평가 점수 (evaluation score), 그리고 예상 비용 (estimated cost)을 설명합니다.
2. mandate.* 텔레메트리는 권한 검증 (capability validation), 위임 (delegation), 정책 (policy), 계획 (planning), 승인 (approval), 실행 (execution), 검증 (verification), 취소 (revocation), 그리고 감사 상태 (audit health)를 설명합니다.

두 경로 모두 mandate.id, mandate.parent.id, mandate.root.id, mandate.action.id와 같은 낮은 카디널리티 (low-cardinality) 식별자를 사용합니다. 전체 프롬프트 (prompts), 권한 (capabilities), 인증 헤더 (authorization headers), 그리고 API 키는 의도적으로 제외되었습니다.

이 저장소 (repository)는 3개의 대시보드 (dashboards), 7개의 저장된 조사 뷰 (investigation views), 그리고 메트릭 (metric), 로그 (log), 트레이스 (trace) 기반의 18개 알림 (alerts)을 통합합니다:

• 권한 개요 (Authority Overview): 정책 (policy), 승인 (approval), 위임 (delegation), 실행 (execution), 검증 (verification), 예산 (budgets) 및 감사 무결성 (audit integrity) 관리.
• 장애 대응 (Incident Command): 서비스 영향 (service impact), 릴리스 상관관계 (release correlation), 인프라 (infrastructure) 및 복구 (recovery) 관리.
• 에이전트 및 LLM 비용 (Agent & LLM Cost): 모델 지연 시간 (latency), 오류 (errors), 토큰 (tokens), 비용 (cost), 도구 호출 (tool calls) 및 평가 (evaluations) 관리.

SigNoz Query Builder가 여기서 중요한 이유는 증거 수집기 (evidence collector)가 메트릭 (metrics)과 트레이스 (traces) 전반에 걸쳐 구조화되고 재현 가능한 쿼리 (queries)를 필요로 하기 때문입니다. SigNoz MCP 서버는 이러한 관측 가능성 (observability) 기능을 게이트웨이 (gateway)에 노출하지만, MANDATE는 현재 에이전트에게 부여된 읽기 전용 (read-only) 하위 집합만을 프록시 (proxy) 합니다. 에이전트는 근본적인 SigNoz 키 (key)를 절대 받지 못합니다.

설계를 변경하게 만든 버그들

가장 유용한 교훈은 성공적인 데모가 아니라 실패로부터 얻었습니다.

한 시점에, 하위 복구 위임 (child remediation mandate)이 실수로 부모의 범위를 벗어난 리소스를 포함한 적이 있었습니다. 게이트웨이는 위임 (delegation)을 올바르게 거부했지만, 웹훅 핸들러 (webhook handler)가 HTTP 502를 반환했습니다. SigNoz는 알림 (alert)을 재시도했고, 모든 재시도는 또 다른 장애 코디네이터 (incident coordinator)를 생성했습니다. 저는 문제의 양쪽 측면을 모두 수정했습니다: 하위 권한 (child authority)은 부모를 넘어 확장될 수 없으며, 실패한 장애 워크플로 (incident workflow)는 재시도 폭풍 (retry storm)을 유발하는 대신 멱등적 (idempotently)으로 기록되고 확인됩니다.

또한 저는 정상적인 배포 (deployment)를 수동으로 복구한 후 롤백 (rollback)을 승인했습니다.
해당 작업은 executing 상태로 전환되었다가 evidence_unavailable과 함께 중단되었습니다.
처음에는 롤백이 실패한 것처럼 보였습니다. 하지만 이는 사실 안전 모델 (safety model)이 작동한 것이었습니다. 즉, 계획을 정당화했던 릴리스 마커 (release marker)와 장애 증거 (failure evidence)가 더 이상 유효하지 않게 된 것입니다. 승인 (approval)은 현재의 단일 계획에 대한 동의이지, 나중에 다른 조건 하에서 해당 계획을 실행할 수 있는 권한이 아닙니다.

마지막으로, 지나치게 광범위한 인프라 쿼리 (infrastructure query)가 ClickHouse의 memory OvercommitTracker에 부하를 주었습니다. 이로 인해 저는 짧은 증거 윈도우 (evidence windows), 제한된 집계 (bounded aggregates), 그리고 낮은 카디널리티 (low-cardinality) 메트릭 레이블 (metric labels)을 사용하도록 유도되었습니다. 관측성 (observability) 쿼리 또한 운영 경로 (operational path)의 일부이므로, 이들에게도 예산 (budgets)이 필요합니다.

흐름 재현하기

해당 저장소에는 SigNoz 배포를 Foundry로 재현할 수 있도록 casting.yaml과 casting.yaml.lock이 포함되어 있습니다. 저의 로컬 설정은 다음과 같습니다:

uv run mandate setup
uv run mandate start --profile lab --signoz
make kind-up kind-build kind-deploy
...

마지막 명령은 관측 가능한 신호 (observable signals)를 준비하고, SigNoz 에셋 (assets)을 검증하며, 제어된 결제 회귀 (payment regression)를 배포하고, 체크아웃 실패 (checkout failures)를 생성합니다.
그다음부터 저는 Incident Command를 지켜보고, 증거에 기반한 롤백을 검사하며, Slack에서 정확한 계획을 승인합니다. 승인이 대기 중인 동안에는 워크로드 (workload)를 수동으로 재설정하지 않는데, 의도적으로 그렇게 하면 증거가 오래되어 (stale) 무효화되기 때문입니다.

데모는 실시간 LLM 호출이 없어도 결정론적 (deterministic)으로 유지됩니다. 실험을 위해 제한된 실시간 모델 경로가 존재하지만, 모델의 출력 (output)이 중요한 정책 분기 (policy branch)를 제어하지는 않습니다.

유지하고 싶은 것

주요 교훈은 간단합니다. 에이전트의 추론 (reasoning)을 보는 것이 에이전트의 권한 (authority)을 제어하는 것과 같지는 않다는 점입니다.

SigNoz는 MANDATE에 장애 (incident), 에이전트, 정책 결정 (policy decision), 인간 체크포인트 (human checkpoint), 실제 실행 (real execution), 그리고 복구 증거 (recovery proof)를 위한 공유 증거 평면 (shared evidence plane)을 제공했습니다. 덕분에 흥미로운 질문을 엔드 투 엔드 (end-to-end)로 가시화할 수 있었습니다.

단순히 "에이전트가 무엇을 했는가?"가 아니라, "왜 그것을 할 수 있도록 허용되었는가, 그리고 그것이 제대로 작동했다는 것을 어떻게 알 수 있는가?"

소스 코드, 재현 가능한 설정, 대시보드, 알림(alerts), 그리고 런북(runbooks)은 MANDATE repository에서 확인할 수 있습니다.

추가 읽을거리:

• SigNoz MCP Server
• SigNoz Query Builder v5
• OpenTelemetry signals
• Agents of SigNoz