AI가 장애 대응까지 맡을 때, Google SRE가 세운 안전선

AI가 장애 대응까지 맡을 때, Google SRE가 세운 안전선

AI 뉴스 썸네일

AI가 코드를 더 빨리 만들면 운영팀의 일도 같이 바뀌어요. Google SRE는 이제 AI를 단순한 보조 도구가 아니라, 장애 감지와 조사, 일부 완화까지 맡는 운영 계층으로 보고 있어요.

핵심 요약

구분	핵심	왜 볼만한가요
운영 자동화	Google은 SRE 업무에 AI를 넣되, 자율성 레벨을 L0부터 L4까지 나눠요	장애 대응에서 “얼마나 맡길 수 있나”를 단계로 보는 기준이 생겨요
안전 설계	투명성, 실시간 리스크 평가, 점진적 권한 부여를 기본 축으로 둬요	프로덕션에서 AI가 실수할 때 피해가 커지는 문제를 정면으로 다뤄요
평가 방식	최근 인시던트와 사람의 대응 기록을 평가 데이터로 써요	데모가 아니라 실제 운영 품질을 매일 재검증하는 흐름을 보여줘요
개발 조직 변화	코드 리뷰는 줄 단위 검토보다 설계, 의도, 정책 검토 쪽으로 옮겨가요	AI 코딩 확산 뒤 운영과 리뷰 체계가 어떻게 바뀔지 가늠할 수 있어요

1. AI가 장애 대응까지 맡을 때, Google SRE가 세운 안전선

Google은 왜 SRE를 다시 설계하나요

Google SRE 글의 출발점은 꽤 현실적이에요. AI 코딩 도구가 코드 작성과 배포 속도를 끌어올리면, 사람이 모든 변경을 줄 단위로 따라가며 검토하는 방식은 금방 한계에 닿아요. 원문은 조직이 최대 4배 생산성 향상을 목표로 삼는 상황을 전제로 두고, SRE가 기존 운영 방식만 붙잡기 어렵다고 설명해요. 2

핵심은 “AI로 기존 업무를 더 빠르게 처리하자”가 아니에요. Google은 장애 감지, 알림 보강, 원인 추정, 완화 실행, 평가 데이터 생성까지 운영 흐름 전체에 AI를 넣는 쪽을 보고 있어요. 다만 프로덕션에서 잘못된 판단은 곧바로 장애로 이어질 수 있어서, AI가 할 수 있는 일과 하면 안 되는 일을 먼저 나누는 구조가 중요해져요. 1

자율성은 한 번에 열지 않고 단계로 나눠요

Google은 SRE AI의 자율성을 L0부터 L4까지 나눠요. L0는 사람이 모든 판단과 실행을 맡고, L1은 AI가 조사와 가설 제안을 도와요. L2는 실행 계획을 세울 수 있지만 사람의 승인이 필요하고, L3는 정해진 범위 안에서 직접 실행까지 할 수 있어요. L4는 진단, 완화, 복구 확인까지 여러 단계를 스스로 이어가는 상태예요. 2

이 구분이 중요한 이유는 “AI에게 맡긴다”는 말이 너무 넓기 때문이에요. 로그 요약을 맡기는 것과 트래픽을 실제로 빼는 것은 위험이 달라요. Google은 권한을 한 번에 열지 않고, 낮은 자율성에서 검증한 뒤 높은 단계로 올리는 방식을 택해요.

안전 삼각축은 운영 AI의 기본 조건이에요

원문에서 가장 눈에 띄는 부분은 Safety Trifecta예요. 첫 번째는 투명성이에요. AI가 어떤 신호를 봤고, 어떤 가설을 세웠고, 왜 특정 조치를 골랐는지 기록해야 해요. 두 번째는 실시간 리스크 평가예요. 같은 조치라도 배포가 진행 중인지, 에러 버짓이 어떤지, 활성 인시던트가 있는지에 따라 위험도가 달라져요. 세 번째는 점진적 권한 부여예요. 처음부터 전권을 주지 않고, 신뢰가 쌓인 범위에서만 권한을 넓혀요. 2

이 접근은 AI 운영 자동화에서 자주 빠지는 지점을 짚어요. 모델 성능보다 먼저 봐야 할 것은 실행 경로예요. AI가 좋은 답을 내도, 그 답이 실제 프로덕션 상태를 바꾸는 순간에는 최소 권한, 전용 레이트 리밋, 중단 장치, dry-run 같은 안전장치가 필요해요.

AI Operator와 Actus는 역할을 나눠요

Google은 AI Operator를 프로덕션 알림의 1차 대응 에이전트로 설명해요. 이 시스템은 알림을 받으면 여러 조사를 병렬로 수행하고, 과거 유사 사례와 운영 지식을 바탕으로 원인을 좁혀요. 막히면 사람에게 넘기고, 사람이 볼 수 있도록 조사 과정을 남겨요. 2

실행 쪽은 Actus 같은 제어 계층이 맡아요. AI가 직접 스크립트를 실행하는 방식이 아니라, 실행 계획을 안전 검사에 통과시킨 뒤 표준화된 경로로 조치해요. 위험이 커지면 L3에서 L2로 내려가 사람 승인을 요구하고, 비상 상황에서는 진행 중인 자동 조치를 멈출 수 있는 “레드 버튼”도 둬요. 이 분리는 운영 AI 설계에서 꽤 중요한 패턴이에요. 추론하는 시스템과 실제 상태를 바꾸는 시스템을 나눠야 통제가 쉬워져요.

평가 데이터는 사람의 운영 기억에서 나와요

Google은 AI가 높은 자율성을 얻으려면 평가 데이터가 먼저 필요하다고 봐요. 인시던트 채팅, 노트, CLI 기록처럼 흩어진 운영 흔적을 시간순 사건으로 재구성하고, 이를 Bronze, Silver, Gold 품질 계층으로 나눠요. 사람이 검증한 Gold 데이터는 AI가 실제로 올바른 완화 조치를 골랐는지 판단하는 기준으로 쓰여요. 2

흥미로운 점은 평가가 일회성 벤치마크에 머물지 않는다는 거예요. 최근 실제 인시던트로 매일 평가를 돌리고, 정성적인 추론은 LLM 평가자가 보되 최종 완화 결과는 결정론적으로 채점해요. 예를 들어 정확한 바이너리나 버전이 맞아야 정답으로 인정하는 식이에요. 운영 AI를 제품처럼 계속 배포하려면 이런 반복 평가가 필수에 가까워져요.

개발 속도가 빨라지면 리뷰 방식도 달라져요

원문은 SRE의 변화가 장애 대응에만 머물지 않는다고 봐요. AI가 코드를 계획하고, 작성하고, 리뷰하고, 제출하는 흐름이 커지면 변경량은 4배에서 10배까지 늘 수 있어요. 이때 사람이 모든 코드를 줄 단위로 검토하면 리뷰 피로가 커지고, 승인이 형식화될 위험도 생겨요. 2

그래서 Google은 사람의 감독이 더 앞단으로 옮겨가야 한다고 말해요. 코드를 한 줄씩 보는 대신 설계, 의도, 정책, 테스트 기준을 먼저 검토하는 쪽이에요. 코드를 만드는 AI와 테스트나 리뷰를 맡는 AI를 분리해 같은 편향이 반복되지 않게 하는 원칙도 제시해요. 단순 롤백이 어려워지는 문제도 다뤄요. 짧은 시간에 여러 변경이 들어오면 롤백 하나가 그사이 들어온 보안 패치까지 되돌릴 수 있어서, 동적 설정과 기능 플래그, 빠른 수정 배포가 더 중요해져요.

왜 중요한가요

이 글은 “AI가 SRE를 대체한다”는 식의 단순한 이야기가 아니에요. 오히려 사람의 역할이 어디로 옮겨가는지 보여줘요. 사람이 직접 모든 알림을 조사하고 모든 완화 명령을 치는 방식에서, AI가 안전하게 움직일 수 있는 경계와 평가 기준을 설계하는 쪽으로 이동해요. 1

서비스 운영팀이 바로 L3, L4 자동화를 도입하기는 어려워요. 그래도 L1 수준의 알림 보강, 원인 가설 제안, 인시던트 기록 정리부터는 현실적인 출발점이 될 수 있어요. 중요한 건 AI 기능 자체보다 운영 권한, 감사 기록, 평가 데이터, 중단 장치를 함께 설계하는 거예요.

참고 자료

1. SRE에서의 AI: Google은 어떻게 신뢰성 있는 운영의 미래를 설계하는가 — GeekNews
2. AI in SRE: How Google is Engineering the Future of Reliable Operations — Google SRE