AWS는 최근 엔드 투 엔드(end-to-end) Agentic SRE를 구축하는 것에 관한 포스트를 게시했으며, 저는 동시에 두 가지 반응을 보였습니다. 첫 번째 반응은 '네, 당연하죠'였습니다. 장애 대응(Incident response)은 에이전트(Agent)가 도움을 주어야 할 반복적인 조사 작업으로 가득 차 있습니다. 두 번째 반응은 '오 안 돼, 우리는 이것 때문에 분명히 스스로를 다치게 할 거야'였습니다. SRE 에이전트가 나쁜 아이디어이기 때문이 아닙니다. 사실 저는 이것이 가장 유용한 AI 방향 중 하나라고 생각합니다. 하지만 Pager(온콜 호출)는 조용한 화요일 오후의 코딩 작업과는 매우 다른 환경입니다. 운영 환경의 장애(Production incidents)는 모호한 자동화, 불완전한 컨텍스트(Context), 잘못된 권한, 그리고 자신만만한 요약이 짜증스러운 수준을 넘어 막대한 비용을 초래하는 곳입니다.

장애 대응은 대부분 컨텍스트 수집(Context gathering)입니다. 많은 장애 관련 작업은 영웅적인 디버깅(Debugging)이 아닙니다. 그것은 압박감 속에서의 컨텍스트 수집입니다. 대시보드(Dashboards)를 확인합니다. 배포 타임스탬프(Deploy timestamps)를 비교합니다. 로그(Logs)를 살펴봅니다. 에러율(Error rates)을 조사합니다. 한 지역이 다른 지역보다 상태가 더 나쁜지 묻습니다. 종속성(Dependency)이 저하되었는지 확인합니다. Slack에서 이 항목을 마지막으로 건드린 사람이 누구인지 검색합니다. 아마도 70%는 정확하고 30%는 고고학적 발굴에 가까운 런북(Runbook)을 읽습니다.

그것이 바로 에이전트가 도움을 줄 수 있는 지저분하고 도구 집약적인 워크플로우(Workflow)의 전형입니다. CloudWatch 메트릭(Metrics)을 가져오고, 트레이스(Traces)를 쿼리하며, 로그를 요약하고, 최근 배포를 조사하며, 타임라인을 준비할 수 있는 에이전트는 실제 몇 분의 시간을 아껴줄 수 있습니다. 그리고 고객 서비스가 중단되고 모든 사람이 장애 채널에서 침착한 척하고 있을 때는 그 몇 분이 매우 중요합니다.

Stack Overflow 또한 AI 세상에서의 관측 가능성(Observability)과 인간의 직관에 관한 좋은 글을 올렸으며, 저는 그 프레임워크가 중요하다고 생각합니다. 목표는 직관을 대체하는 것이 아닙니다. 목표는 인간에게 판단을 위한 더 나은 시작점을 제공하는 것입니다. 훌륭한 장애 에이전트는 인간을 더 수동적으로 만드는 것이 아니라, 더 예리하게 만들어야 합니다.

위험한 부분은 바로 동사(verb)입니다. 문제는 에이전트가 "조사(look)"에서 "실행(do)"으로 넘어갈 때 시작됩니다. 다음과 같은 작업들 사이에는 엄청난 차이가 있습니다:

"지난 30분간의 5xx 에러 급증을 요약해줘"
"관련성이 높은 배포(deploy)를 찾아줘"
"이 서비스를 지난주 베이스라인(baseline)과 비교해줘"
"배포를 롤백(rollback)해줘"
"서비스를 스케일 아웃(scale)해줘"
"재시도 정책(retry policy)을 변경해줘"
"이 피처 플래그(feature flag)를 비활성화해줘"
"클러스터(cluster)를 재시작해줘"

첫 번째 그룹은 조사(investigation)입니다. 두 번째 그룹은 운영(operation)입니다. 둘 다 유용합니다. 하지만 그중 오직 하나만이 3초 만에 장애(incident) 상황을 악화시킬 수 있습니다. 이것이 많은 AI 데모가 오해를 불러일으키는 지점입니다. 데모에서는 에이전트가 문제를 진단하고, 해결책을 제안하고, 동작을 실행하면 그래프가 초록색으로 변합니다. 멋지죠. 하지만 운영(production) 환경에서 에이전트는 증상을 근본 원인(root cause)으로 진단하거나, 신호(signal)를 숨겨버리는 해결책을 적용하거나, 한 고객 경로에는 작동하지만 다른 경로를 망가뜨리는 동작을 수행할 수도 있습니다. 물론 인간도 이런 실수를 합니다. 차이점은 인간은 더 느리고, 사회적 책임을 지며, 중단시키기가 더 쉽다는 것입니다. 광범위한 권한을 가진 에이전트는 매우 효율적으로 틀릴 수 있습니다. 장애 상황에서 효율성이 항상 당신의 편인 것은 아닙니다.

관측 가능성(observability)은 안전 시스템입니다. 만약 당신이 에이전트 기반의 SRE(Agentic SRE)를 원한다면, 관측 가능성(observability)은 단순히 있으면 좋은 추가 기능이 아닙니다. 그것은 안전 시스템입니다. 에이전트에게는 신뢰할 수 있는 텔레메트리(telemetry)가 필요하지만, 인간에게도 에이전트에 대한 텔레메트리가 필요합니다. 에이전트가 어떤 데이터를 검사했는가? 어떤 쿼리(query)를 실행했는가? 어떤 가정을 했는가? 어떤 동작을 제안했는가? 어떤 동작을 실행했는가? 누가 그것들을 승인했는가? 동작 이후에 무엇이 변했는가? 만약 에이전트가 "데이터베이스가 병목(bottleneck)입니다"라고 말한다면, 저는 에이전트가 포화도(saturation), 락 대기(lock waits), 커넥션 풀 고갈(connection pool exhaustion), 디스크 지연 시간(disk latency), 다운스트림 타임아웃(downstream timeouts)을 살펴본 것인지, 아니면 그저 상태가 안 좋아 보이는 CPU 그래프 하나만 본 것인지 알고 싶습니다. 이것이 제가 아름다운 자연어 요약만을 생성하는 장애 에이전트(incident agent)에 회의적인 이유입니다. 요약은 유용하지만, 불확실성(uncertainty)을 압축하여 없애버릴 수도 있습니다. 장애 상황에서 불확실성은 노이즈(noise)가 아닙니다. 그것은 신호(signal)의 일부입니다.

훌륭한 SRE 에이전트는 사후 분석 (postmortem)을 진행하는 긴장한 스태프 엔지니어처럼 자신의 작업 과정을 보여주어야 합니다. 권한 (permissions)은 장애 (incident)의 단계와 일치해야 합니다. 가장 쉬운 잘못된 설계는 에이전트에게 하나의 거대한 프로덕션 역할을 부여하고 주의를 기울일 것이라 믿는 것입니다. 제발 그렇게 하지 마십시오. 장애 대응 (incident response)에는 단계가 있으며, 권한은 그 단계에 맞아야 합니다. 정상 운영 (normal operation) 시 에이전트는 대부분 읽기 전용 (read-only)이어야 합니다. 메트릭 (metrics), 로그 (logs), 트레이스 (traces), 배포 메타데이터 (deploy metadata), 피처 플래그 (feature flag) 상태, 설정 이력 (config history), 런북 (runbooks), 그리고 최근 알람 (alerts)을 조사할 수 있게 하십시오. 이것만으로도 이미 가치가 있습니다. 완화 (mitigation)를 위해서는 되돌릴 수 있는(reversible) 소수의 작업 세트만을 허용하십시오: 장애 타임라인 생성, 롤백 (rollback) 명령 초안 작성, 피처 플래그 변경 제안, PR (Pull Request) 오픈, 담당 팀 호출 (page), 또는 런북 단계 준비 등이 있습니다. 어떤 팀들은 저위험 자동화 작업을 허용할 수도 있지만, 이는 명시적이고 지루할 정도로 단순해야 합니다. 영향력이 큰 작업 (high-impact operations)의 경우, 인간의 승인을 요구해야 합니다. 롤백, 트래픽 전환 (traffic shifting), 데이터베이스 페일오버 (database failovers), 권한 변경, 그리고 인프라 변형 (infrastructure mutation)은 "AI가 최선이라고 생각했다"라는 말 뒤에 숨겨져서는 안 됩니다. 이것은 자동화에 반대하는 것이 아닙니다. 이것이 성숙한 자동화가 작동하는 방식입니다. 폭발 반경 (blast radius)이 승인 모델을 결정합니다.

런북은 실행 가능한 계약 (executable contracts)이 됩니다. 제가 에이전트 기반 SRE (agentic SRE) 방향에서 좋아하는 점 중 하나는, 이것이 마침내 팀들이 런북을 정리하도록 강제할 수 있다는 것입니다. 인간만을 위해 작성된 런북은 모호할 수 있습니다: "대시보드를 확인하고 서비스가 멈춘 것처럼 보이면 재시작하십시오." 에이전트가 사용하는 런북은 더 나은 구조가 필요합니다: 어떤 대시보드인가? 어떤 메트릭이 "멈춤"을 정의하는가? 어떤 임계값 (threshold)이 중요한가? 어떤 명령어가 서비스를 재시작하는가? 배포 중에도 재시작이 안전한가? 누가 이를 승인하는가? 복구를 어떻게 검증하는가? 무엇을 자동으로 재시작해서는 안 되는가? 이것은 건강한 압박입니다. CI/CD에서도 동일한 일이 일어났습니다. 배포가 자동화되자, 팀들은 릴리스 프로세스를 명시적으로 만들어야만 했습니다. 에이전트 기반 SRE도 운영 (operations)에 대해 똑같은 일을 할 수 있습니다. 에이전트가 마법 같아서가 아니라, 자동화는 모호함을 처벌하기 때문입니다.

만약 당신의 런북 (runbook)이 새벽 3시에 주의 깊은 주니어 엔지니어가 따라 할 수 없는 것이라면, 아마 에이전트 (agent) 역시 안전하게 수행할 수 없을 것입니다. 페이저 (pager)는 벤치마크가 아닙니다. 제가 가장 피하고 싶은 것은 장애 (incident)를 AI 리더보드로 만드는 것입니다. "에이전트가 장애의 42%를 자동으로 해결했습니다"라는 말은 어떤 장애였는지, 어떤 조치를 취했는지, 오탐 (false positive)은 몇 건이었는지, 숨겨진 회귀 (regression)는 몇 건이었는지, 그리고 사후에 얼마나 많은 사람이 조용히 뒷수습을 했는지 묻기 전까지는 인상적으로 들릴 뿐입니다. 더 나은 지표는 훨씬 더 지루할 것입니다: 유용한 첫 요약까지 걸린 시간 (time to useful first summary), 완전한 타임라인을 가진 장애의 비율, 반복적인 수동 진단 단계의 감소율, 에이전트가 제안한 조치에 대한 승인율, 에이전트의 완화 (mitigation) 지원 이후의 롤백 (rollback) 또는 되돌리기 (revert) 비율, 누락된 컨텍스트로 인해 발생한 사후 분석 (postmortem) 결과, 추측하는 대신 올바르게 에스컬레이션 (escalation)한 횟수 등 말입니다. 저는 가끔 영웅적인 자율 수정을 수행하고 가끔 모두를 식은땀 흘리게 만드는 에이전트보다, 조사 시간을 확실하게 10분 줄여주는 에이전트에 훨씬 더 관심이 많습니다. 영웅적인 자동화는 데모에서 즐겁습니다. 지루한 지원이야말로 프로덕션 (production)에서 살아남는 것입니다.

제가 가장 먼저 구축할 것

만약 제가 오늘 팀에 에이전트 기반 SRE (agentic SRE)를 추가한다면, 가장 덜 화려한 버전부터 시작할 것입니다. 읽기 전용 장애 어시스턴트 (Read-only incident assistant) 말입니다. 변경 (mutation)은 없습니다. 비밀스러운 권한도 없습니다. 에이전트는 장애 채널에 참여하여, 텔레메트리 (telemetry)를 수집하고, 타임라인을 구축하며, 최근 배포 (deploy)를 연결하고, 증상을 요약하며, 유력한 담당자를 식별하고, "알려진 사실 vs 추측" 목록을 계속 유지할 것입니다. 그다음에는 실행되는 조치가 아닌, 제안되는 조치를 추가할 것입니다. 에이전트는 롤백 (rollback) 명령어를 초안할 수 있지만, 실행은 사람이 합니다. 에이전트는 피처 플래그 (feature flag)를 제안할 수 있지만, 전환은 사람이 합니다. 에이전트는 스케일링 (scaling)을 제안할 수 있지만, 반드시 근거를 제시해야 합니다. 그렇게 한동안 작동하고 난 후에야 제한적인 자동 완화 (automated mitigation)를 고려할 것입니다. 그리고 그때조차도, 되돌릴 수 있고, 로그가 남으며, 팀에서 이미 안전하다고 승인된 좁은 범위의 조치부터 시작할 것입니다.

지루한 성숙도 모델(maturity model)은 다음과 같은 단계로 진행됩니다: 읽기 전용 요약기(read-only summarizer) → 타임라인 및 증거 생성기(timeline and evidence builder) → 런북 탐색기(runbook navigator) → 조치 권장기(action recommender) → 인간 승인 운영자(human-approved operator) → 좁은 범위의 자율 완화 도구(narrow autonomous mitigator). 1단계에서 6단계로 건너뛰는 것은 사후 분석(postmortem) 보고서에 "예상치 못한 에이전트 동작"이라는 문구가 포함되게 만드는 지름길입니다.

진정한 변화
더 큰 이야기는 AWS나 그 어떤 벤더가 SRE 챗봇을 만들 수 있다는 것이 아닙니다. 더 큰 이야기는 운영(operations)이 에이전트가 워크플로(workflow)에 참여하는 또 다른 영역이 되고 있다는 점입니다. 마법 같은 동료로서가 아니라, 권한(access), 메모리(memory), 로그(logs), 권한(permissions), 그리고 실패 모드(failure modes)를 가진 도구 사용 프로세스(tool-using processes)로서 말입니다. 이는 플랫폼 팀이 에이전트를 고려하여 설계해야 함을 의미합니다. 다음과 같은 동일한 질문들이 계속해서 돌아옵니다: 에이전트가 무엇을 볼 수 있는가, 무엇을 변경할 수 있는가, 어떻게 검토하는가, 어떻게 관찰(observe)하는가, 어떻게 롤백(roll back)하는가, 그리고 에이전트가 잘못되었을 때 그 난장판에 대한 책임은 누구에게 있는가?

Agentic SRE가 흥미로운 이유는 실제적인 노고(toil)를 해결하기 때문입니다. 동시에 같은 이유로 위험하기도 합니다. 작업은 실제이고, 시스템은 실제이며, 페이저(pager)는 데모가 멋져 보였다는 사실 따위에는 신경 쓰지 않기 때문입니다. 그러니 네, 사고 대응(incident response)에 에이전트를 도입하십시오. 다만, 다른 모든 운영 도구가 그러하듯 에이전트도 신뢰를 얻도록 만드십시오: 처음에는 읽기 전용으로, 항상 관찰 가능하게(observable), 가능한 경우 되돌릴 수 있게(reversible), 그리고 작은 불을 더 큰 불로 키울 수 있는 모든 것에 대해서는 매우 신중하게 말입니다.