인시던트 대응(Incident Response)은 에이전트 검토 워크플로우(Agent Review Workflow)로 변하고 있다

인시던트(Incident) 발생 시 가장 쓸모없는 문장은 "AI가 문제를 찾았다고 합니다"입니다.

참 좋네요.

AI가 무엇을 살펴봤나요?

어떤 로그(Logs)를 봤나요?

어떤 메트릭(Metrics)을 봤나요?

어떤 권한(Permissions)을 사용했나요?

무엇을 제외(Rule out)했나요?

어떤 조치를 권장하고 있으며, 모두가 지나치게 자신만만하면서도 동시에 너무나 피곤한 새벽 2시에 그 조치에 대한 책임은 누가 지는 것입니까?

이것이 바로 제가 최근 AWS가 공개한 AWS DevOps Agent의 Amazon EKS 컨트롤 플레인(Control-plane) 성능 문제 진단 가이드가 일반적인 "운영을 위한 AI" 이야기보다 더 흥미롭다고 느낀 이유입니다. 이 사례는 매우 구체적입니다: API 서버 스로틀링(Throttling), API 우선순위 및 공정성(API Priority and Fairness) 시트 고갈, 감사 로그(Audit logs), CloudWatch 메트릭(Metrics), 그리고 복구를 위한 권장 경로(Recommendation path)를 다룹니다.

그러한 구체성이 중요합니다.

이 이야기는 "AI가 Kubernetes를 고친다"가 아닙니다.

이 이야기는 인시던트 대응(Incident response)이 검토 워크플로우(Review workflow)로 변하고 있다는 것입니다.

Kubernetes 인시던트는 대부분 증거(Evidence)의 문제이다

Kubernetes는 하나의 문제를 다섯 개의 증상으로 바꾸는 데 매우 능숙합니다.

배포(Deployment)가 느려집니다. API 서버가 스로틀링(Throttling)을 시작합니다. 컨트롤러(Controllers)가 뒤처집니다. 웹훅(Webhooks)이 지연 시간(Latency)을 추가합니다. 소란스러운 클라이언트(Noisy client)가 클러스터(Cluster)를 몰아칩니다. 누군가는 포드(Pods)가 빠르게 스케줄링되지 않는 것을 알아차립니다. 다른 누군가는 대시보드가 빨간색이지만 별로 도움이 되지 않는 것을 봅니다. 실제 원인은 애플리케이션 동작, 클러스터 구성, 클라우드 제한, 그리고 압박 속에서 설계된 대로 정확히 작동하고 있는 컨트롤 플레인(Control plane) 사이 어딘가에 있습니다.

이것은 "인시던트를 요약해줘"라는 말만으로는 충분하지 않은 영역입니다.

어려운 부분은 적절한 순서로 적절한 증거를 수집하는 것입니다.

엔지니어가 EKS 컨트롤 플레인 문제를 조사할 때, 그들은 보통 여러 소스를 하나로 엮습니다:

API 서버 요청량, 지연 시간(Latency), 스로틀링(Throttling)을 위한 CloudWatch 메트릭(Metrics)
어떤 클라이언트가 어떤 호출을 하고 있는지 보여주는 감사 로그(Audit logs)
Kubernetes 이벤트(Events) 및 컨트롤러(Controller) 동작
API 우선순위 및 공정성(API Priority and Fairness) 신호
최근 배포(Deploys), 자동화 작업(Automation jobs), 그리고 스크립트(Scripts)
동일한 시스템에 거의 저장되지 않는 인간의 맥락(Human context)

에이전트의 가치는 마법 같은 직관을 가지고 있다는 점에 있지 않습니다.

그 가치는 지루한 상관관계 분석 작업(correlation work)을 빠르고 일관되게 수행하며, 다른 사람이 검토할 수 있을 만큼 충분한 구조를 갖추어 수행할 수 있다는 점에 있습니다.

그 마지막 부분이 바로 '도움'과 '리스크'를 가르는 차이점입니다.

에이전트는 논거(argument)를 생성해야 합니다

저는 운영 에이전트(operations agent)가 단순히 '느낌(vibe)'을 내놓는 것을 원하지 않습니다.

저는 에이전트가 논거(argument)를 생성하기를 원합니다.

예를 들면 다음과 같습니다:

"이 시점에 API 서버 요청이 급격히 증가했습니다. 이 증가는 주로 이 ID(identity)로부터 발생했습니다. 요청은 이 동사(verb)와 리소스(resource)에 집중되었습니다. APF 메트릭(metrics)은 이 우선순위 레벨(priority level)이 시트(seats)를 소진하고 있음을 보여줍니다. 감사 로그(Audit logs)는 이 워크로드(workload)로부터의 반복적인 호출을 확인합니다. 일치하는 컨트롤 플레인(control-plane) 상태 이벤트가 없으므로 지역 서비스 문제는 아닌 것으로 보입니다. 유력한 원인은 이 클라이언트 동작입니다. 권장 조치는 다음과 같으며, 각각의 트레이드오프(tradeoffs)는 이렇습니다."

이것은 검토가 가능합니다.

틀릴 수도 있지만, 인간이 이의를 제기할 수 있는 방식으로 틀립니다.

이것이 제가 AWS 예시에서 좋아하는 형태입니다. DevOps 에이전트는 단순히 대시보드 옆에 앉아 있는 챗봇이 아닙니다. 에이전트는 메트릭(metrics), 로그(logs), 감사 추적(audit trails), 클러스터 특화 컨텍스트(cluster-specific context)와 같은 클라우드 네이티브 증거(cloud-native evidence)를 사용합니다. 에이전트는 자신이 본 것을 직접 지목할 수 있습니다.

이것은 인간의 역할을 변화시킵니다.

엔지니어는 더 이상 6개월 전에 어떤 쿼리(query)가 동일한 유형의 문제를 잡아냈는지 기억해내려 애쓰며 백지 상태에서 시작하지 않습니다. 엔지니어는 제안된 인시던트 내러티브(incident narrative)를 검토합니다.

증거가 완전한가?

에이전트가 첫 번째 의심스러운 메트릭에 과적합(overfit)되지는 않았는가?

5분 전에 발생한 배포(deploy)를 놓치지는 않았는가?

업무 시간 중에 복구(remediation)를 수행하는 것이 안전한가?

클라이언트 압박을 줄여야 하는가, APF를 조정해야 하는가, 자동화(automation)를 롤백해야 하는가, 아니면 클러스터 전체 정책을 변경하기 전에 단 하나의 악성 행위자(bad actor)를 차단해야 하는가?

이것은 인간이 루프(loop)에서 사라질 수 있는 것처럼 가장하는 것보다 훨씬 더 나은 AI의 활용법입니다.

액세스(access)는 진단의 일부입니다

데모가 운영(operational) 측면처럼 보이기 때문에 놓치기 쉬운 보안 관점이 여기에 있습니다.

프로덕션 인프라를 진단하는 에이전트에게는 액세스(access) 권한이 필요합니다.

아마 쓰기 권한(write access)까지는 필요 없을 것입니다. 기본적으로 광범위한 쓰기 권한을 가질 필요도 없을 것입니다. 하지만 로그(logs), 메트릭(metrics), 이벤트(events), ID(identities), 설정(configurations), 그리고 때로는 민감한 운영 세부 정보(operational details)를 조사할 수 있는 충분한 읽기 권한(read access)은 필요합니다. Kubernetes에서는 읽기 전용(read-only) 권한만으로도 시스템에 대해 많은 것을 드러낼 수 있습니다.

따라서 에이전트의 ID(identity)가 중요합니다.

에이전트가 어떤 IAM 역할(role)이나 액세스 엔트리(access entry)를 사용했나요? 어떤 클러스터(clusters)를 조사할 수 있나요? 어떤 네임스페이스(namespaces)를요? 어떤 CloudWatch 로그 그룹(log groups)을요? 감사 로그(audit logs)를 볼 수 있나요? 계정 간(across accounts) 쿼리가 가능한가요? 누군가가 "디버깅(debugging)"을 모든 권한을 부여할 명분으로 삼는 바람에 실수로 비밀(secrets)을 읽을 수도 있지는 않나요?

이 지점에서 에이전트 기반 운영(agentic ops)은 다시 평범한 플랫폼 엔지니어링(platform engineering)으로 돌아갑니다.

에이전트에게는 최소 권한(least privilege)이 필요합니다. 감사 추적(audit trails)이 필요합니다. "관찰(observe)", "권고(recommend)", "실행(act)" 사이의 명확한 경계가 필요합니다. 개발(development), 스테이징(staging), 프로덕션(production) 환경에 대해 서로 다른 권한이 필요합니다. 또한 에이전트가 어떤 증거에 접근할 수 없었는지 설명할 수 있는 방법이 필요합니다. 왜냐하면 증거의 누락 자체가 인시던트(incident) 상황에서는 중요하기 때문입니다.

만약 에이전트가 "악성 클라이언트(bad client)를 찾지 못했습니다"라고 말했는데, 정작 그 악성 클라이언트가 보일 수 있는 감사 로그 그룹(audit log group)을 읽을 수 없었다면, 그 결론은 유용하지 않습니다.

액세스 투명성(access transparency)이 없는 신뢰는 보여주기식(theater)에 불과합니다.

권고(recommendations)는 소유권(ownership)이 아니다

시스템이 진단에서 실행으로 너무 빠르게 넘어가는 위험한 형태의 운영 AI(operations AI)가 존재합니다.

에이전트가 스로틀링(throttling)을 감지합니다. 에이전트는 API 우선순위 및 공정성(API Priority and Fairness) 설정을 변경할 것을 권고합니다. 누군가는 권고 내용이 그럴듯해 보이고 대시보드가 빨간색으로 표시되어 있기 때문에 승인(approve)을 클릭합니다. 인시던트 상황은 10분 동안 개선되지만, 변경 사항이 압력을 다른 곳으로 옮겨버렸기 때문에 더 중요한 워크로드(workload)가 자원 부족(starved) 상태에 빠지게 됩니다.

Kubernetes에는 국지적으로는 합리적이지만 전역적으로는 놀라운 결과를 초래하는 수많은 조절 노브(knobs)가 있습니다.

이것이 바로 제가 권고(recommendation)와 소유권(ownership) 사이의 구분에 관심을 두는 이유입니다.

에이전트는 해결책(remediation)을 권고할 수 있습니다. 예상되는 효과를 설명할 수 있습니다. 영향 범위(blast radius)를 보여줄 수 있습니다. 개선되어야 할 지표(metrics)를 연결할 수 있습니다. 변경 사항(change)의 초안을 작성할 수 있습니다. 심지어 롤백 계획(rollback plan)을 준비할 수도 있습니다.

하지만 조직은 여전히 해당 조치의 소유권(ownership)을 누가 가질지 결정해야 합니다.

인시던트(incident)가 발생하는 동안, 그 소유권은 지루할 정도로 명확해야 합니다:

에이전트가 이를 진단함
이 사람이 진단을 수락함
이 변경 사항이 승인됨
이 시스템이 이를 적용함
이후 이 지표들을 모니터링함
이 롤백 경로가 사용 가능했음

사후 분석(postmortem)을 작성해야 할 때가 오기 전까지는 이것이 관료주의적으로 들릴 수 있습니다.

하지만 그때가 되면 이것은 친절함으로 느껴집니다.

사후 분석(postmortem)은 인시던트 도중에 시작된다

인시던트 에이전트가 할 수 있는 가장 좋은 일은 문제를 해결하는 것이 아닐 수도 있습니다.

조사 과정(investigation)을 보존하는 것일 수 있습니다.

대부분의 인시던트 타임라인은 사건이 종료된 후 Slack 메시지, 대시보드(dashboards), 터미널 기록(terminal history), 배포 로그(deploy logs), 기억, 그리고 나중에 모두가 논쟁하게 될 몇몇 타임스탬프(timestamps)를 통해 재구성됩니다. 인시던트는 이미 주의력을 소진시킨 상태입니다. 이제 팀은 고고학 작업을 수행해야 합니다.

에이전트는 타임라인을 처음부터 워크플로우(workflow)의 일부로 만듦으로써 도움을 줄 수 있습니다.

어떤 증거가 확인되었는지, 어떤 가설(hypotheses)이 고려되었고 어떤 것이 기각되었는지, 어떤 쿼리(query)가 전환점을 보여주었는지, 어떤 해결책(remediation)이 선택되었는지, 그리고 그 이후에 어떤 일이 일어났는지를 기록할 수 있습니다. 세련된 경영진 요약 보고서(executive summary) 형식이 아니라, 스트레스 상황에서도 살아남을 수 있는 운영 노트(operational notes)로서 말입니다.

이것이 중요한 이유는 인시던트 대응(incident response)이 맥락을 벗어나면 이상해 보이는 합리적인 결정들로 가득 차 있기 때문입니다.

팀은 왜 그 컨트롤러(controller)를 재시작했는가?

왜 그 자동화(automation)를 일시 중지했는가?

왜 인시던트 중에 APF를 변경하지 않기로 결정했는가?

왜 소음이 심한 클라이언트(noisy client)가 단순한 증상이 아니라 원인이라고 판단했는가?

만약 에이전트가 증거의 흔적(evidence trail)을 유지한다면, 사후 분석(postmortem)은 기억에 의존하는 것이 아니라 학습에 더 가까워질 것입니다.

그것이 매우 실용적인 형태의 AI 지원입니다.

이것이 바로 운영 에이전트(ops agents)가 지루해져야 하는 지점이다

자율성(autonomy)으로 너무 빠르게 도약하려는 그 어떤 운영 AI(operations AI) 이야기에도 저는 회의적입니다.

자율적 복구(Autonomous remediation)는 좁은 영역에서 발생할 것입니다. 이미 일부는 그렇게 하고 있습니다. 알려진 잘못된 작업을 재시작하거나, 명백한 큐 워커(queue worker)를 확장하거나, 방금 상태 체크(health checks)에 실패한 카나리(canary)를 되돌리거나, 명백히 남용하는 클라이언트를 차단하는 것 말입니다. 좋습니다.

하지만 대부분의 운영 인시던트(production incidents)는 "모델이 처리하게 하라"는 커다란 빨간 버튼을 누를 만큼 깔끔하지 않습니다.

더 나은 단기적 제품은 오히려 더 지루한 형태입니다:

증거를 더 빠르게 수집
시스템 간의 상관관계(correlate) 분석
추론 과정(chain of reasoning) 보존
권한(permissions)을 가시화
제한된 범위의 조치(bounded actions) 제안
위험한 변경 사항에 대해 인간의 승인 요구
전체 과정을 더 나은 사후 분석(postmortem) 결과물로 전환

이것은 여전히 매우 중요한 일입니다.

이는 온콜(on-call) 엔지니어가 증거가 어디에 있는지 기억하는 데 쓰는 시간을 줄이고, 그 증거가 무엇을 의미하는지 결정하는 데 더 많은 시간을 쓸 수 있음을 의미합니다. 새로운 팀원들이 단순히 최종 요약본이 아니라 실제 인시던트 추론 과정을 통해 배울 수 있음을 의미합니다. 플랫폼 팀이 모든 인시던트가 동일한 것처럼 가장하지 않고도 일반적인 진단 경로를 인코딩할 수 있음을 의미합니다.

가장 중요한 것은, 검토자(reviewers)에게 구체적인 무언가를 제공한다는 점입니다.

"에이전트가 도움이 되었습니다"가 아니라,

"에이전트가 수행한 조사 내용은 이것이고, 결론은 이것이며, 누가 이를 승인했고, 무엇이 변경되었는지 여기 있습니다"라고 말하는 것입니다.

이것이 바로 문장 생성 시스템(sentence production systems)이 수용할 수 있는 수준의 결과물입니다.

핵심(the punchline)

AWS DevOps Agent가 EKS 컨트롤 플레인(control-plane) 성능 문제를 진단하는 것은 운영 AI가 아마도 어디로 향할지를 보여주는 유용한 신호입니다.

곧바로 마법 같은 복구로 가는 것이 아닙니다.

구조화되고 검토 가능한 워크플로우(workflow)로서의 인시던트 대응(incident response)을 향해 가는 것입니다.

Kubernetes 인시던트에는 증거가 필요합니다. 클라우드 제공업체는 이미 로그(logs), 메트릭(metrics), 감사 추적(audit trails), ID(identities), 그리고 구성 API(configuration APIs)에 그 증거의 상당 부분을 보유하고 있습니다. 에이전트는 콘솔 사이를 오가는 지친 인간보다 더 빠르게 이러한 조각들을 모을 수 있습니다. 하지만 유용한 출력물은 확신에 찬 답변이 아닙니다. 그것은 검사(inspected)할 수 있는 진단입니다.

에이전트가 무엇을 보았는가?

에이전트가 무엇에 접근할 수 있었는가?

에이전트가 무엇을 놓쳤는가?

그것은 어떤 조치를 권장했는가?

누가 실행하기로 결정했는가?

이러한 질문들에 답할 수 있다면, 에이전트는 인시던트(incident) 프로세스에서 소유자(owner)도, 영웅(hero)도, 호출(pager)을 담당하는 사람도 아닌, 두 번째 검토자(second reviewer)가 됩니다.

검토자 말입니다.

이것이 자율 운영(autonomous operations)보다는 덜 흥미롭게 들릴 수도 있습니다.

좋습니다.

운영 환경(Production)에는 흥미진진한 놀라움이 적을수록 좋습니다.

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.

Insights