AI 에이전트 확산…‘정상 작동’이 인프라 장애로 번질 수 있다

새벽 2시 17분, 데이터베이스 지연 경고가 뜨자 여러 AI 에이전트가 동시에 움직인다. 성능을 담당하는 에이전트는 용량을 늘리고, 비용 최적화 에이전트는 과잉 자원으로 판단해 인스턴스를 줄이며, 트래픽 관리 에이전트는 우회 경로를 재설정한다. 각각의 판단은 모두 ‘정상’이지만, 결과는 2분 만의 서비스 중단일 수 있다는 경고가 나왔다.

시스코 시스템즈의 플랫폼·어슈어런스 부문 부사장 조 바카로(Joe Vaccaro)는 실리콘앵글 기고문에서 앞으로의 인프라 장애는 ‘무언가가 고장 나서’가 아니라 ‘모든 것이 설계대로 작동해서’ 발생할 수 있다고 짚었다. 개별 로그만 보면 오류가 없지만, 여러 에이전트의 결정이 짧은 시간 안에 충돌하면서 전체 시스템이 무너질 수 있다는 설명이다.

이미 나타난 징후…AWS·애저·클라우드플레어 사례

이런 유형의 장애는 AI 에이전트가 본격 확산하기 전에도 이미 나타났다는 게 바카로의 진단이다. 그는 지난해 발생한 AWS, 마이크로소프트 애저, 클라우드플레어 사례를 대표적 예로 들었다.

AWS 다이너모DB DNS 장애는 서로 독립적인 두 시스템이 각자 올바르게 동작한 가운데 발생했다. 한쪽은 이전 설정을 적용하는 과정에서 지연을 겪었고, 다른 쪽은 최신 설정을 반영한 뒤 정리 작업을 진행했다. 문제는 지연된 시스템이 정리 시점에 맞물려 최신 설정을 덮어쓰면서 생겼다. 단일 시스템의 오류가 아니라 ‘타이밍 충돌’이 원인이었다.

애저 프런트 도어 장애도 비슷한 흐름이었다. 제어 영역이 잘못된 메타데이터를 만들었고, 자동화 시스템은 이를 정상적으로 차단했다. 이후 정리 작업 역시 설계대로 수행됐지만, 이 과정에서 또 다른 구성요소에 숨어 있던 버그가 깨어났다. 각 단계는 맞았지만, 연결된 순서가 문제를 키웠다.

클라우드플레어 봇 관리 장애는 권한 변경으로 중복 쿼리 결과가 만들어지면서 시작됐다. 설정 시스템은 이를 정상 처리해 유효하지만 지나치게 큰 파일을 생성했고, 프록시는 역시 정상적으로 용량 제한을 적용해 해당 파일을 거부했다. 한 시스템의 ‘정상 출력’이 다른 시스템의 ‘정상 제한’과 충돌한 셈이다.

자동화와 다른 ‘에이전트 정의 인프라’

기존 자동화 시스템 자체는 새로운 개념이 아니다. 오토스케일링은 서버 용량을 조절하고, 쿠버네티스는 워크로드를 재배치하며, AIOps 플랫폼은 장애 서비스를 재시작한다. 다만 이런 자동화는 대체로 미리 정해진 규칙과 제한된 범위 안에서 움직인다.

반면 ‘에이전트 정의 인프라’는 상황을 관찰하고, 비용과 성능 같은 상충 요소를 저울질한 뒤, 기계 속도로 판단을 내린다. 문제는 기업들이 한두 개가 아니라 수십 개의 에이전트를 동시에 운영하려 한다는 점이다. 모두가 같은 인프라를 공유한 채 몇 초 안에 결정을 내리면, 기존 장애 패턴은 사라지지 않고 더 복잡하게 증폭될 수 있다.

바카로는 이런 위험이 세 가지 방식으로 커진다고 설명했다. 먼저 여러 에이전트가 같은 문제를 동시에 풀려다 오히려 악화시킬 수 있다. 예를 들어 한 에이전트가 대기열 A의 과부하를 보고 작업을 B로 넘기면, 다른 에이전트는 B의 과부하를 보고 다시 A로 돌려보낼 수 있다. 각각은 관측값에 충실하지만, 함께 보면 끝없는 루프다.

또 에이전트는 다른 에이전트의 행동이 ‘의도된 결정’인지 ‘수정해야 할 오류’인지 구분하기 어렵다. 한쪽이 자원을 늘리면 다른 쪽은 낭비로 보고 줄이고, 다시 첫 번째가 성능 저하로 해석해 자원을 늘리는 식이다. 외부에서는 인프라 문제처럼 보여도 실제로는 조정 실패, 즉 ‘협업 부재’가 본질일 수 있다.

마지막으로 국지적 결정이 연쇄 반응을 일으켜 시스템 전반의 문제로 번질 수 있다. 서비스 A를 관리하는 에이전트의 행동이 서비스 B에 영향을 주고, B의 변화는 다시 C를 흔드는 구조다. 운영팀이 조사에 착수할 무렵이면 각 에이전트가 판단했던 당시 조건은 이미 사라졌을 가능성이 크다. 사후 분석이 어려운 이유다.

기존 모니터링만으로는 부족

이 같은 ‘에이전트 장애’는 CPU 사용률, 메모리 점유율, 요청 지연, 에러율 같은 전통적 지표만으로는 포착하기 어렵다. 이런 도구는 기본적으로 단일 시스템 내부에서 무엇이 망가졌는지 보여주도록 설계됐다. 하지만 새로운 문제는 여러 시스템이 모두 정상인데도 상호작용 결과로 실패가 발생하는 데 있다.

따라서 관건은 서비스 A가 건강한지를 보는 데서 끝나지 않는다. A의 변화가 B, C, D의 행동을 어떻게 촉발하는지, 그리고 에이전트가 그 순간 어떤 데이터를 보고 판단했는지까지 한 화면에서 파악해야 한다. 네트워크, 컴퓨트, 애플리케이션, 데이터 계층을 통합해서 봐야 실시간 연쇄 효과를 읽을 수 있다는 의미다.

현장의 사이트 신뢰성 엔지니어(SRE)들은 이미 변경 동결, 단계적 배포, 영향 범위 제한 같은 방식으로 이런 위험을 어느 정도 관리해왔다. 다만 에이전트가 움직이는 속도에서는 사람이 개입할 수 있는 시간이 크게 줄어든다. 결국 보이지 않으면 조정도 불가능하다는 지적이다.

배포 후 대응 아닌, 배포 전 설계가 핵심

바카로는 에이전트 정의 인프라 자체를 피해야 할 위험으로 보지는 않았다. 응답 속도 향상, 운영 부담 경감, 자원 최적화 같은 장점은 분명하기 때문이다. 다만 앞으로의 핵심은 개별 에이전트의 성능보다, 서로 독립적으로 옳은 결정이 실제 운영 환경에서 어떤 조합으로 충돌할지를 미리 설계 단계에서 검증하는 데 있다는 주장이다.

결국 다음 세대 인프라 장애는 ‘오작동’보다 ‘과도하게 잘 작동한 자동화’에서 나올 가능성이 크다. 기업이 이를 배포 이후 모니터링 문제로만 보면, 장애 원인을 새벽 2시 17분의 로그 속에서 뒤늦게 추적하게 될 수 있다. AI 에이전트 확산이 빨라질수록, 인프라 운영의 승부처는 개별 기능이 아니라 ‘상호작용 가시성’이 될 전망이다.