AI 에이전트 ‘정상 작동’이 부르는 인프라 장애…모니터링 기준 바뀐다

새벽 2시 17분, 데이터베이스 지연 경고가 뜨자 여러 AI 에이전트가 동시에 대응에 나서는 상황은 더 이상 가상 시나리오가 아니라는 지적이 나왔다. 각 에이전트는 저마다 올바른 판단을 내리지만, 그 결정이 겹치는 순간 인프라 전체가 무너질 수 있다는 것이다.

시스코 시스템즈의 조 바카로(Joe Vaccaro) 플랫폼·어슈어런스 부문 부사장은 실리콘앵글 기고문에서 차세대 인프라 장애는 ‘무언가가 고장 나서’가 아니라 ‘모든 것이 설계대로 작동해서’ 발생하는 형태가 될 수 있다고 설명했다. 성능 관리 에이전트가 데이터베이스 용량을 늘리고, 비용 관리 에이전트가 과잉 할당으로 판단해 인스턴스를 줄이며, 트래픽 라우팅 에이전트가 우회 경로를 설정하는 식이다. 개별 판단은 모두 합리적이지만, 결과적으로 2분 만에 데이터베이스 계층이 다운될 수 있다는 의미다.

이미 대형 클라우드 장애에서 비슷한 패턴이 나타났다

이런 위험은 AI 에이전트가 본격 확산하기 전에도 실제 장애 사례에서 드러났다. 아마존웹서비스(AWS)의 다이너모DB DNS 사고는 서로 다른 두 시스템이 각자 정상적으로 구성을 적용하는 과정에서 발생했다. 한쪽은 오래된 설정을 늦게 반영했고, 다른 한쪽은 최신 설정을 기준으로 정리 작업을 진행했다. 그 순간 지연됐던 시스템이 새 설정을 덮어쓰면서 문제가 터졌다. 핵심은 어느 한 시스템의 오류가 아니라 ‘타이밍’이었다.

마이크로소프트 애저 프런트도어 장애도 비슷했다. 제어 플레인이 잘못된 메타데이터를 만들었고, 자동화 시스템은 이를 정상적으로 차단했다. 이후 정리 프로세스도 의도대로 작동했지만, 제3의 구성요소에 숨어 있던 버그를 건드리며 장애로 번졌다. 클라우드플레어 봇 관리 사고 역시 권한 변경으로 중복 질의 결과가 생성됐고, 설정 시스템은 이를 정상 처리해 지나치게 큰 파일을 만들었다. 프록시는 정해진 크기 제한에 따라 이 파일을 거부했다. 각 시스템은 모두 규칙대로 움직였지만, 조합된 결과는 실패였다.

이 사례들은 단일 시스템 내부 로그만 봐서는 이상 징후를 찾기 어려웠다는 공통점이 있다. 여기에 수십 개 에이전트가 기계 속도로 동시 의사결정을 내리기 시작하면, 같은 유형의 장애는 더 자주, 더 복잡하게 나타날 수 있다는 분석이다.

기존 자동화와 ‘에이전트 기반 인프라’는 다르다

서버 용량을 자동 조정하는 오토스케일링, 쿠버네티스의 워크로드 이동, 장애 서비스를 재시작하는 AIOps 같은 자동화는 이미 널리 쓰이고 있다. 다만 이런 시스템은 대체로 사전에 정의된 좁은 규칙 안에서 움직인다.

반면 에이전트 기반 인프라는 상황을 관찰하고, 비용과 성능 같은 상충 요소를 저울질한 뒤, 기계 속도로 판단을 내린다. 문제는 기업들이 한두 개가 아니라 수십 개의 에이전트를 동시에 같은 인프라 위에서 운용하려 한다는 점이다. 이 경우 장애 양상은 세 방향으로 증폭될 수 있다.

첫째, 여러 에이전트가 같은 문제를 해결하려다 되레 악화시킬 수 있다. 예를 들어 한 에이전트가 큐 A 과부하를 보고 작업을 큐 B로 넘기면, 다른 에이전트는 큐 B 과부하를 감지해 다시 큐 A로 돌려보낼 수 있다. 둘 다 맞는 대응이지만, 함께 보면 끝없는 루프가 된다.

둘째, 에이전트는 다른 에이전트의 행동이 ‘판단’인지 ‘실수’인지 구별하기 어렵다. 한쪽이 용량을 늘리면 다른 쪽은 비용 절감을 위해 줄이고, 다시 첫 번째가 이를 문제로 보고 재확장하는 식의 충돌이 생긴다. 외부에서 보면 인프라 장애처럼 보이지만, 실제로는 조정 실패에 가깝다.

셋째, 국지적 결정이 시스템 전체 문제로 번질 수 있다. 서비스 A를 관리하는 에이전트의 조치가 서비스 B에 영향을 주고, B의 에이전트가 다시 C에 영향을 미치는 식이다. 운영팀이 조사에 착수할 때쯤이면 최초 조건은 이미 사라져 원인 규명이 더 어려워진다.

모니터링 방식도 바뀌어야 한다

기존 모니터링은 CPU 사용률, 메모리, 요청 지연, 오류율처럼 개별 시스템의 상태를 파악하는 데 최적화돼 있다. 하지만 에이전트 시대에는 모든 시스템이 ‘정상’인데도 상호작용 때문에 장애가 날 수 있다. 따라서 이제 중요한 질문은 서비스 A가 건강한지가 아니라, A의 변화가 B·C·D의 어떤 행동을 유발했는지다.

또 단순히 에이전트가 무엇을 했는지보다, 그 에이전트가 어떤 데이터를 보고 왜 그런 결정을 내렸는지를 함께 봐야 한다. 이를 위해서는 네트워크, 컴퓨트, 애플리케이션, 데이터 전반을 아우르는 통합 가시성이 필요하다. 개별 구성요소 지표만으로는 부족하고, 의존관계와 타이밍, 각 결정이 실시간으로 어떻게 연결되는지 추적할 수 있어야 한다는 뜻이다.

숙련된 사이트 신뢰성 엔지니어(SRE)는 이미 변경 동결, 단계적 배포, 장애 확산 범위 제한 같은 방식으로 일부 위험을 관리해 왔다. 다만 에이전트 속도에서는 사람이 개입할 수 있는 시간이 크게 줄어든다. 결국 보이지 않는 것은 조정할 수도 없다는 점이 핵심으로 꼽힌다.

에이전트 도입 전부터 ‘상호작용 가시성’을 설계해야 한다

조 바카로 부사장은 에이전트 기반 인프라 자체를 피해야 할 위험으로 보지는 않았다. 대응 속도 향상, 최적화 효율, 운영 부담 축소 같은 장점은 분명하기 때문이다. 다만 앞으로의 장애는 에이전트가 실패해서가 아니라, ‘의도대로 너무 잘 작동해서’ 생길 수 있다고 강조했다.

이 때문에 기업은 배포 이후 모니터링으로 문제를 때우는 접근보다, 에이전트가 실제 가동되기 전부터 상호작용 구조를 설계 제약으로 반영해야 한다. 그렇지 않으면 새벽 2시 17분, 로그에는 아무 이상이 없는데 시스템만 멈춘 상황을 맞게 될 수 있다.