공유된 기록이 없으면 AI 장애 관리는 실패합니다
AI 에이전트가 장애 대응(incident response) 영역에 진입하고 있습니다.
LangChain, PagerDuty, New Relic과 같은 기업들은 SRE 에이전트를 구축하고 있습니다. 이러한 도구들은 트레이스를 읽고, 로그를 가져오며, 업데이트 초안을 작성할 수 있습니다. 속도가 빠르고 훌륭한 컨텍스트를 제공합니다.
하지만 함정이 있습니다.
많은 팀이 AI 컨텍스트를 개인적인 메모장처럼 취급합니다. 근본 원인(root cause)을 찾는 것과 같은 완화(mitigation) 작업에는 AI를 사용하지만, 협업(coordination) 작업은 잊어버립니다.
장애 관리는 단순히 원인을 찾는 것만이 아닙니다. 그것은 협업에 관한 것입니다. 즉, 다음 사항들에 대해 사람들이 합의하도록 만드는 과정입니다:
- 무엇이 일어났는가.
- 무엇이 변경되었는가.
- 무엇을 배제했는가.
- 다음 단계의 담당자는 누구인가.
- 비즈니스 측에서 알아야 할 사항은 무엇인가.
만약 이 정보가 개인적인 채팅이나 에이전트의 노트에만 머물러 있다면, 프로세스는 실패합니다.
유용한 AI 장애 기록은 단순한 채팅 로그가 아닙니다. 그것은 구조화된 운영 객체(operational object)여야 합니다. 여기에는 반드시 다음 내용이 포함되어야 합니다:
- 트리거 (알림, 서비스, 심각도).
- 증거 (트레이스, 로그, 메트릭, 최근 배포 내역).
- 가설 (무슨 일이 일어나고 있다고 생각하는지와 그 이유).
- 기각된 이론 (원인이 아님을 증명한 사항).
- 결정 및 승인 (롤백을 선택했거나 대기하기로 한 이유).
이러한 구조는 흔히 발생하는 AI의 실패를 방지합니다. 에이전트는 중력의 구덩이(gravity well)가 될 수 있습니다. 그럴듯한 원인을 하나 찾아내면 그것에만 매몰됩니다. 그러고 나서 모든 새로운 데이터를 그 하나의 이론을 뒷받침하는 방향으로만 해석하게 됩니다.
공유되고 구조화된 기록은 팀이 반증(disconfirming evidence)을 살펴보도록 강제합니다. 이는 에이전트의 편향을 제어합니다.
대응자들에게 필요한 것은 더 많은 소음이 아닙니다. 그들에게 필요한 것은 공유된 상태(shared state)입니다. 새로운 인원이 장애 대응에 참여했을 때, Slack을 뒤지며 5분을 허비해서는 안 됩니다. 현재의 가설, 증거, 그리고 대기 중인 조치 사항을 즉시 확인할 수 있어야 합니다.
목표는 화려한 데모를 보여주는 자율 대응자가 아닙니다. 목표는 조직의 지식(institutional knowledge)을 남길 수 있는 도구입니다.
가장 똑똑한 모델을 찾는 일을 멈추십시오. 구조화된 기록을 구축하기 시작하십시오.
- 장애를 위한 명확한 필드를 정의하십시오.
- 에이전트가 이 기록을 안전하게 읽고 쓸 수 있도록 하십시오.
- 기록이 단순한 데이터가 아닌 결정 사항을 담도록 하십시오.
- 기록을 활용하여 장애의 혼란을 재사용 가능한 지식으로 전환하십시오.
최고의 AI 도구는 인간 팀이 하나로 움직이게 만드는 도구입니다.
Optional learning community: https://t.me/GyaanSetuAi