어제 제가 몇 달 동안 프로덕션 환경 전반에서 구축되는 것을 지켜봐 온 현상을 정의하는 글이 하나 올라왔습니다.

엔지니어링 팀들이 아직 추적하지 못하고 있는 프로덕션 장애(Production Incident) 카테고리가 있습니다. 왜냐하면 기존의 사후 분석(Postmortem) 템플릿에 부합하지 않기 때문입니다. 에이전트(Agent)가 행동을 시작했습니다. 그 행동은 에이전트의 컨텍스트(Context)를 고려했을 때 기술적으로는 정확했습니다. 하지만 컨텍스트가 불완전했습니다. 인프라(Infrastructure)가 연쇄적으로 무너졌습니다. 장애 검토(Incident Review)가 이루어질 때쯤에는 세 개의 팀이 이것이 에이전트의 실패인지, 아니면 인프라의 실패인지를 두고 논쟁하고 있었습니다. Kore.ai

이러한 논쟁이 발생하는 이유는 SRE(Site Reliability Engineering)와 자율 에이전트(Autonomous Agents)라는 두 분야가 의사결정 계층(Decision Layer)에서 공식적으로 연결된 적이 없기 때문입니다.

제가 명확히 하고 싶은 연결 고리는 다음과 같습니다.

카오스 엔지니어링(Chaos Engineering)이 제대로 하고 있는 것

성숙한 카오스 엔지니어링 프로그램은 제대로 작동할 때는 보이지 않기 때문에 간과하기 쉬운 특성을 가지고 있습니다. 인간 엔지니어가 어떤 실험(결함 주입(Fault Injection), 지연 시간 급증(Latency Spike), 의존성 차단(Dependency Kill))을 시작하기 전에, 그들은 판단을 내립니다. '지금 이 시스템이 섭동(Perturbation)을 흡수할 수 있는 용량이 있는가?'

그들은 에러 예산 소진율(Error Budget Burn Rate)을 확인합니다. 상위 의존성(Upstream Dependencies)이 안정적인지 살펴봅니다. 무언가 잘못되었을 때 온콜(On-call) 팀이 대응할 수 있는 대역폭(Bandwidth)이 있는지 평가합니다. 현재 진행 중인 배포(Deploy)가 있어 지금이 적절하지 않은 시점인지 확인합니다.

그 판단은 비공식적이고, 종종 직관적이며, 때로는 틀릴 수도 있습니다. 하지만 분명히 존재합니다. 시스템이 자율적인 행동을 안전하게 흡수할 수 있는 상태인지 결정하는 것은 바로 인간 개입(Human-in-the-loop)입니다.

에이전트는 그런 판단을 내리지 않습니다. 그들은 작업 컨텍스트를 평가하고, 계획을 세우고, 실행합니다. "시스템의 현재 신뢰성 상태를 고려할 때, 지금이 이 행동을 하기에 안전한 시점인가?"라는 질문은 그들의 의사결정 루프(Decision Loop)에 포함되어 있지 않습니다.

2026년에 프로덕션 가치를 전달하는 에이전트들은 한 가지 결정적인 특성을 공유합니다. 바로 제한된 범위(Bounded Scope)입니다. 에이전트는 정의된 도구 세트(Tool Set)를 가지고 하나의 도메인을 처리하며, 그 경계를 벗어나는 작업은 명시적으로 거부합니다.

경계(Boundary)는 자율 배포(Autonomous Deployment)를 안전하게 만드는 핵심 요소입니다. GlobeNewswire

작업 범위(Task Scope)에 대한 경계는 필수적입니다. 하지만 그것만으로는 충분하지 않습니다. 타이밍(Timing)에 대한 경계, 즉 시스템의 현재 신뢰성 상태(Reliability State)가 에이전트가 수행하려는 작업을 수용할 수 있는지 확인하는 게이트(Gate)가 필요합니다.

사전 행동 SRE 게이트 (The Pre-Action SRE Gate)

여기서 구체적인 패턴 하나를 소개하고자 합니다. 바로 '사전 행동 SRE 게이트(Pre-Action SRE Gate)'입니다. 이는 에이전트가 상태를 변경하는(State-changing) 어떠한 행동을 실행하기 전에, 기존의 SRE 신호(Signals)를 대상으로 수행하는 점검입니다.

이 게이트는 세 가지 점검 항목을 가지며, 모두 제가 이 시리즈 전반에 걸쳐 구축해 온 지표(Metrics)를 사용합니다.

점검 1 — 에러 예산 여유분 (Error Budget Headroom)
행동하기 전에, 에이전트는 자신의 영향 범위(Blast Radius) 내에 있는 서비스들에 대해 현재 남은 SLO 에러 예산(Error Budget)을 조회합니다. 만약 에러 예산이 임계값(Threshold) 미만이라면 — 즉, 시스템이 이미 허용 가능한 수준보다 빠르게 에러를 소모하고 있다면 — 에이전트는 자율적으로 행동하지 않습니다. 대신 상황을 에스컬레이션(Escalate)합니다. 이는 카오스 엔지니어링(Chaos Engineering)의 판단을 프로그래밍 가능한 점검으로 공식화한 것입니다.

점검 2 — AQDD 상태 (AQDD State)
승인 대기열 깊이 드리프트(Approval Queue Depth Drift, AQDD)는 인간 감독 계층(Human Oversight Layer)에 이미 병목이 발생했는지 알려줍니다. 만약 AQDD가 높아져 있다면 — 즉, 인간이 승인 요청을 충분히 빠르게 처리할 수 없는 상태라면 — 해당 기간 동안의 자율적 행동은 어떤 실수가 발생하더라도 제때 발견되지 않을 것임을 의미합니다. 에이전트는 대기합니다.

점검 3 — HER 추세 (HER Trend)
만약 에이전트 자신의 최근 인간 에스컬레이션 비율(Human Escalation Rate, HER)이 높아졌다면, 이는 에이전트가 신뢰할 수 있는 범위(Reliable Envelope) 밖에서 작동하고 있음을 나타냅니다. 그러한 상태에서 자율적 행동을 허용하는 것은 리스크를 가중시킵니다. 에이전트는 에스컬레이션합니다.

이 지표들은 새로운 것이 아닙니다. 이 시리즈의 포스트 4와 포스트 10에서 다루었던 내용입니다. 새로운 점은 이 지표들을 단순히 사후 관찰 신호(Observability Signals)로 사용하는 것이 아니라, 행동 전의 게이트(Gates)로 사용한다는 것입니다.

python

agentsre/pre_action_gate.py

from dataclasses import dataclass
from typing import Optional
from datetime import datetime, timezone
import json

@dataclass
class SREGateResult:
"""
Pre-Action SRE Gate 점검 결과.

만약 approved가 False라면, 에이전트는 자율 행동을 진행해서는 안 됩니다. 
ARO 기록에 따라 인간 소유자에게 에스컬레이션하십시오.

...

class PreActionSREGate:  
"""  
Pre-Action SRE Gate — 에이전트가 자율적인 쓰기(write), 복구(remediation), 스케일링(scale) 이벤트 또는 설정 변경(config change)을 실행하기 전에 SRE 신호 상태를 확인합니다.
"""

이것은 카오스 엔지니어링(Chaos Engineering)의 판단을 공식화한 것입니다.
인간 엔지니어는 실험을 실행하기 전에 이러한 사항들을 확인합니다.
여러분의 에이전트는 자율적으로 행동하기 전에 이를 확인해야 합니다.
...

전체 아크(Full Arc)와의 연결 방식
포스트 4에서는 관찰 가능한 SLI(Service Level Indicators)로서 DQR, TIE, HER, AQDD를 소개했습니다 — 즉, 여러분이 모니터링하는 대상들입니다.
포스트 10에서는 이러한 SLI가 위반되었을 때 에이전트의 소유권이 누구에게 있는지 나타내는 ARO를 소개했습니다.
포스트 11에서는 추론 관찰성 계층(reasoning observability layer)인 RTD를 소개했습니다.
포스트 12에서는 신뢰성 상한선으로서의 컨텍스트 예산(context budget)인 CUR을 소개했습니다.
이 포스트에서는 Pre-Action SRE Gate를 소개합니다 — 여기서 이 모든 신호들은 관찰 가능한 출력(observability outputs)이 아닌 의사결정 입력(decision inputs)이 됩니다. 에이전트는 행동한 후가 아니라, 행동하기 전에 여러분의 SRE 상태를 읽습니다.
회복탄력성(Resilience)을 위해서는 서킷 브레이커(circuit breakers), 우아한 성능 저하(graceful degradation), 그리고 시스템 무결성을 보존하는 명확한 실패 모드(failure modes)에 대한 명시적인 투자가 필요합니다. 에이전트를 구축하는 팀은 더 높은 중요도를 가진 워크로드로 확장하기 전에 회복탄력성 인프라에 투자해야 합니다. SourceForge
Pre-Action Gate가 바로 그 인프라입니다. 이것은 에이전트의 서킷 브레이커입니다 — 재시도 루프(retry loops)나 비용이 아니라, 시스템 수준의 신뢰성 상태를 기준으로 작동합니다.

사후 분석(Postmortem) 템플릿의 공백
현재 조직의 79%가 프로덕션 환경에서 AI 에이전트를 사용하고 있습니다. Gartner는 이러한 프로젝트의 40%가 부실한 리스크 통제로 인해 취소될 것이라고 경고합니다. 그 공백에서 발생하는 사고들은 기존의 사후 분석(postmortem) 템플릿에 부합하지 않는데, 현재의 템플릿은 다음과 같이 묻기 때문입니다: 무엇이 변했는가? 누가 배포했는가? 무엇이 실패했는가? Kore.ai

그들은 다음과 같이 묻지 않습니다: 에이전트가 행동했을 때 에러 예산(error budget) 상태는 어떠했는가? AQDD가 상승하여 승인 계층(approval layer)이 이미 과부하 상태였는가? 에이전트의 HER이 상승 추세여서 이미 신뢰할 수 없는 영역에 있었는가?

이러한 질문들이 여러분의 사후 분석(postmortem) 템플릿에 포함되어야 합니다.

다음 섹션을 추가하세요: 에이전트 실행 전 상태(Agent Pre-Action State) — 실행 시점의 에러 예산(error budget), AQDD 깊이, HER 추세. 만약 여러분의 사후 분석(postmortem)이 이 세 가지 질문에 답할 수 없다면, 동일한 사고가 재발하는 것을 방지할 데이터를 갖추지 못한 것입니다.

코드는 GitHub의 agentsre/pre_action_gate.py에 있습니다. MIT 라이선스이며, 외부 의존성이 전혀 없습니다.

Ajay Devineni | AWS Community Builder | Senior SRE/Platform Engineer
github.com/Ajay150313/agentsre