Google은 5월 28일, 모든 SRE(Site Reliability Engineer)가 읽어야 할 백서(white paper)를 발표했습니다.

이 백서는 세 가지 핵심 구성 요소인 AI Operator(자율 완화 에이전트), Actus(엄격한 실행 가드레일), 그리고 IRM Analyzer(인간의 운영 메모리에 기반한 지속적 평가 파이프라인)를 통해 신뢰성을 위한 새로운 기반을 어떻게 설계하고 있는지 상세히 설명합니다. 목표는 Google의 규모에서 고속 에이전트 소프트웨어 개발(agentic software development)을 안전하게 관리하는 것입니다. Rootly

저는 Google 내부에서가 아니라, Google과 같은 인프라나 자본을 갖추지 못한 팀들을 위해 동일한 문제를 해결하려는 독립적인 실무자로서 지난 몇 달 동안 밑바닥부터 동일한 아키텍처를 구축해 왔습니다.

백서를 읽어보니 Google이 명명한 모든 구성 요소가 agentsre 라이브러리 또는 이 시리즈에 이미 있는 무언가와 직접적으로 매핑된다는 것을 발견했습니다. 이 포스트는 이들을 나란히 매핑해 봅니다.

Google의 Actus → Pre-Action SRE Gate

Actus는 안전한 자율 완화(autonomous mitigation)를 위한 Google의 물리적 실행 제어 평면(execution control plane)입니다. 이는 어떤 동작이 실행되기 전에 엄격한 정책 집행을 통해 에이전트가 운영 환경(production)에서 할 수 있는 일을 제한합니다. Rootly

이것은 Pre-Action SRE Gate가 수행하는 역할과 정확히 일치합니다. 자율적인 동작을 수행하기 전 세 가지 확인 절차를 거칩니다: 에러 예산 잔여량(error budget remaining, 시스템에 여유 공간이 있는가?), AQDD 상태(이 작업이 잘못될 경우 인간이 경로를 수정할 수 있는가?), 그리고 HER 트렌드(이 에이전트가 이미 신뢰할 수 있는 범위를 벗어났는가?)입니다. 만약 어떤 확인 절차라도 실패하면 에이전트는 동작하지 않고 에스컬레이션(escalate)합니다.

Google은 내부 시스템을 위해 인프라 수준에서 Actus를 구축했습니다. Pre-Action Gate는 동일한 패턴을 AWS 팀이 이번 주에 바로 배포할 수 있는 Lambda + CloudWatch + DynamoDB 패턴으로 구현한 것입니다.

Google의 IRM Analyzer → DQR + RTD

IRM Analyzer는 인간의 운영 메모리(human operational memory)를 캡처하고, 배포 전 및 운영 중에 에이전트의 준비 상태를 증명하기 위해 매일 밤 평가를 실행하는 Google의 지속적 평가 파이프라인(continuous evaluation pipeline)입니다. Rootly

이 시리즈의 두 가지 지표가 동일한 작업을 수행합니다:

DQR (Decision Quality Rate, 의사결정 품질률) — 에이전트의 출력이 정확한가?

배포 시점에만 측정하는 것이 아니라 지속적으로 측정됩니다.

RTD (Reasoning Trace Depth, 추론 추적 깊이) — 에이전트의 추론이 안정적인가? 작업당 재계획(Re-planning) 주기. DQR이 하락하기 전에 상승합니다.

Google은 인간이 검증한 인시던트(Incident) 코퍼스를 대상으로 매일 밤 평가(Evals)를 실행합니다. 해당 코퍼스가 없는 팀의 경우, 30일간의 섀도 모드(Shadow mode)에서 측정된 DQR과 RTD가 Google의 내부 인시던트 데이터베이스 없이 달성 가능한 근사치입니다.

Google의 AI Operator → ARO가 필요한 에이전트

Google SRE는 인시던트 발생 중 사용 패턴을 기반으로 플레이북(Playbook)과 운영 문서(Production documentation)를 지속적으로 모니터링하고 개선하는 AI 에이전트를 보유하고 있습니다. AI 에이전트는 인시던트로부터 새로운 플레이북을 생성할 수도 있습니다. Nova AI Ops

이것이 실제로 작동하는 AI Operator의 모습입니다. 그리고 이는 운영 문서에 쓰기 작업을 시작하기 전에 — 지정된 소유자, 정의된 영향 범위(Blast radius), 그리고 에스컬레이션 경로(Escalation path) — 에이전트 신뢰성 소유권 (Agent Reliability Ownership, ARO) 등록이 반드시 필요한 에이전트 범주에 정확히 해당합니다.

런북(Runbook)을 수정할 수 있는 에이전트는 인시던트 동안 모든 인간 SRE가 의존하는 가이드를 오염시킬 수 있는 에이전트입니다. 해당 범주의 에이전트에게 영향 범위(Blast radius) 정의는 선택 사항이 아닙니다. 그것은 여러분이 가진 가장 중요한 거버넌스 산출물(Governance artifact)입니다.

Google이 다루지 않는 간극 — 플릿 거버넌스 (Fleet governance)

Google의 백서(Whitepaper)는 개별 에이전트 거버넌스는 잘 다루고 있습니다. 하지만 Google이 다루지 않는 부분은 — Google의 규모에서는 이것이 별개의 문제이기 때문에 — 엔지니어가 플랫폼에 배포된 에이전트와 함께 자신만의 에이전트 워크플로우를 배포하는 팀을 위한 플릿 수준(Fleet-level)의 거버넌스입니다.

이것이 바로 포스트 6(Post 6)에서 언급한 에이전트 확산(Agent Sprawl) 문제입니다. 포스트 12(Post 12)의 확산 레지스트리(Sprawl Registry)와 사후 분석 준비율(Postmortem Readiness Rate, PRR)은 Google의 아키텍처가 가정하며 생략해 버린 플릿 수준의 거버넌스 간극을 해결합니다.

여러분의 팀에 의미하는 바

AI SRE 기술은 이를 안전하게 배포하는 데 필요한 신뢰 프레임워크(Trust frameworks)보다 더 빠르게 도착하고 있습니다. Sherlocks AI

Google은 방금 자신들의 환경을 위한 신뢰 프레임워크를 발표했습니다. agentsre 라이브러리는 다른 모든 사람을 위해 동일한 프레임워크를 오픈 소스로 구현한 것입니다.

가장 먼저 구현해야 할 중요한 세 가지 구성 요소는 순서대로 다음과 같습니다:

1. Pre-Action Gate (Actus의 대응 요소)부터 시작하십시오 — 게이트(gate)가 없는 에이전트는 자산이 되기 전에 부채가 되기 때문입니다.
2. DQR + RTD 모니터링 (IRM Analyzer의 대응 요소)을 추가하십시오 — 측정할 수 없는 것은 평가할 수 없기 때문입니다.
3. 모든 에이전트를 ARO + Sprawl Registry (AI Operator 거버넌스)에 등록하십시오 — 이름을 붙이지 않은 것은 소유할 수 없기 때문입니다.

백서(whitepaper)는 sre.google에서 확인할 수 있습니다. 라이브러리는 github.com/Ajay150313/agentsre에 있습니다.

현재 여러분의 팀에 가장 부족한 구성 요소는 무엇인가요?

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