AI 에이전트에게 운영 권한을 맡기기 전에 알아야 할 3단계 통제 구조 (구글 SRE 최신 백서 정리)

요즘 온콜 대응이나 배포, 롤백 같은 운영 작업 일부를 AI 에이전트에게 맡기는 팀이 늘고 있습니다. 문제는 대부분 "에이전트한테 어디까지 권한을 줄 것인가"를 명확히 정하지 않은 채로 시작한다는 점이에요. 처음엔 조회·분석만 시키다가, 편해지니까 조금씩 실행 권한을 넓히고, 그러다 사고가 나면 그제서야 통제 장치를 급하게 만듭니다.

구글 SRE 팀이 최근 공개한 백서 "AI Engineering for Reliable Operations"는 이 문제를 처음부터 구조적으로 설계한 사례라 참고할 부분이 많습니다. 핵심은 크게 세 가지 축입니다.

1. 조사를 맡는 에이전트와 실행을 통과시키는 게이트를 분리한다

백서에서 "AI Operator"라고 부르는 조사 에이전트는 알림이 오면 과거 유사 사건의 사람 대응 사례를 근거로 가설을 세우고 원인을 조사합니다. 하지만 이 에이전트가 결론을 내렸다고 해서 바로 인프라를 건드리지 않습니다. 모든 실행 요청은 "Actus"라는 별도의 실행 제어 계층을 통과해야 합니다.

여기서 중요한 포인트는, Actus가 에이전트에게 붙은 "권한 설정값"이 아니라 아예 별도로 분리된 시스템이라는 점이에요. 에이전트의 추론이 아무리 그럴듯해도 Actus가 허용하지 않은 행동은 실행되지 않습니다. Actus는 세 가지 일을 합니다.

에이전트의 의도를 사전에 등록된 완화 조치 목록 안에서만 실행 계획으로 변환한다
실행 전에 의무적으로 드라이런(모의 실행)을 거쳐 결과를 예측해보게 한다
위험도가 올라가면 자동으로 "사람 승인 필요" 단계로 강등시키고, 언제든 실행을 즉시 멈출 수 있는 긴급 정지 기능을 둔다

일반 회사가 이걸 그대로 구현할 필요는 없지만, 원리는 그대로 가져올 수 있습니다. 에이전트가 셸 스크립트나 API를 직접 두드리게 두지 말고, 정해진 액션 목록(허용 목록)과 드라이런을 강제하는 얇은 게이트 하나만 앞에 세워도 실질적인 위험은 크게 줄어듭니다. OPA(Open Policy Agent)나 그냥 코드로 짠 allowlist 정도로도 시작할 수 있는 수준입니다.

2. 사람의 사고 대응 기억을 구조화된 데이터로 남긴다

백서에서 "IRM Analyzer(IRMA)"라고 부르는 부분은, 사고 대응 중 슬랙 메시지·티켓·명령어 로그처럼 흩어져 있는 기록을 자동으로 파싱해서 "누가 무엇을 언제 시도했고, 어떤 가설을 세웠다가 버렸는지"를 시간순으로 재구성합니다. 이게 왜 중요하냐면, 이 데이터가 나중에 에이전트를 평가하고 개선하는 데 쓰는 "정답 데이터"의 원천이 되기 때문입니다.

실무적으로 옮기면 이런 얘기예요. 사고가 끝난 뒤 사람이 무엇을 확인했고 무엇을 배제했는지가 어딘가에 구조적으로 남아있지 않으면, 다음번에 비슷한 사고가 났을 때 그 판단 과정을 다시 처음부터 반복하게 됩니다. AI 에이전트를 붙이든 안 붙이든, "이번에 뭘 의심했다가 아니라고 확인했나"를 기록해두는 습관 자체가 팀의 대응 속도를 올리는 투자입니다.

3. 평가 데이터를 신뢰도별로 계층화한다

백서는 에이전트 품질 평가용 데이터를 세 등급으로 나눕니다. 자동 라벨러가 만든 Bronze(신뢰도 낮음), 프로그램으로 생성하되 사람 검증 데이터로 보정한 Silver(중간), 사람 전문가가 직접 검증한 Gold(가장 신뢰도 높음)입니다. 매일 밤 최근 실제 사고 데이터로 에이전트를 자동 테스트하고, 그중 일부를 사람이 검증해 Gold로 승격시켜 Silver 기준선을 계속 보정하는 방식입니다.

이 구조의 요점은 "사람 검증을 전부 없애려는 게 아니라, 사람 검증이 필요한 범위를 계속 줄여나가는 것"입니다. 처음부터 완벽한 자동 평가를 만들려고 하면 끝이 안 나지만, Bronze로 빠르게 시작하고 표본을 뽑아 Gold로 보정하는 루프를 돌리면 점진적으로 정확도를 끌어올릴 수 있습니다.

자율성은 단계적으로 올린다

백서는 에이전트에게 넘기는 자율성을 L0(전부 사람)부터 L4(완전 자동)까지 다섯 단계로 나누고, 각 단계로 올라갈 때마다 "통계적으로 유의미한 성공률"을 먼저 입증하도록 요구합니다. 예를 들어 "용량이 10% 미만으로 남은 셀에서만 자동으로 트래픽을 빼는 것"처럼 조건을 좁게 정의한 상태에서 자율 실행을 허용하고, 전역 네트워크 설정 변경 같은 건 애초에 자율 실행 대상에서 제외하는 식입니다.

정리

AI 에이전트에게 운영 업무를 맡기는 순서를 고민하고 있다면, "이 에이전트가 뭘 더 할 수 있게 할까"보다 먼저 물어볼 질문은 이거예요. 에이전트의 판단과 실제 실행 사이에 사람이 아닌 시스템이 개입하는 지점이 하나라도 있는가, 그리고 그 시스템의 판단 기준을 누가 어떻게 검증하고 있는가. 통제 구조를 먼저 만들고 그 안에서 자율성을 넓혀가는 순서가, 반대 순서보다 사고 처리 비용이 훨씬 적게 듭니다.

원문 백서: https://sre.google/resources/practices-and-processes/ai-engineering-reliable-operations/