AI 에이전트가 기업이 아직 파악하지 못한 혼돈 엔지니어링 실패를 조용히 일으키고 있다

Source: VentureBeat

엔지니어링 팀이 아직 추적하고 있지 않은 생산 사고 카테고리가 있습니다—기존 사후 분석 템플릿에 맞지 않기 때문이죠.
에이전트가 행동을 시작했습니다. 그 행동은 에이전트의 컨텍스트에서는 기술적으로 올바른 것이었습니다. 하지만 컨텍스트가 불완전했습니다. 인프라가 연쇄적으로 영향을 받았습니다. 그리고 사고 검토가 이루어졌을 때, 세 팀이 그 사고가 에이전트 실패인지 인프라 실패인지 논쟁하고 있었습니다. 왜냐하면 이 두 가지를 생각하는 프레임워크가 전혀 연결돼 있지 않았기 때문이죠.

이 노출 규모는 이제 이론적인 것이 아닙니다. 79%의 조직이 현재 프로덕션에 AI 에이전트를 운영하고 있으며, 96%가 확장을 계획하고 있습니다. Gartner는 2028년까지 기업 소프트웨어의 33%가 에이전시 AI를 포함할 것이라고 예측하지만, 동시에 위험 관리가 미흡해 40%의 프로젝트가 취소될 것이라고 경고합니다.

두 통계가 포착하지 못하는 실패 모드는 바로 그 사이에 존재합니다: 실행 중이며 취소되지 않은 에이전트가 위험으로 분류되지 않은 인프라 이벤트를 조용히 생성하고 있는 상황입니다.

저는 Cisco에서 20개 이상의 글로벌 기업 고객에게 AI 기반 라이프사이클 플랫폼을 제공하고, Splunk에서는 수천 개 기업 환경에 AI 지원 근본 원인 분석 및 가시성 워크플로를 설계하면서 기업 규모의 인프라 자동화 시스템을 6년간 구축해 왔습니다.

그 기간 동안 의도 기반 혼돈 엔지니어링 방법론에 대한 특허도 출원했습니다. 그리고 그 과정에서 조직들이 같은 구조적 실수를 반복하는 것을 보았습니다: 자율 에이전트와 혼돈 엔지니어링을 별개의 분야로 취급하는 것. 사실 이 둘은 같은 분야이며, 그 사이의 격차가 다음 대규모 프로덕션 사고를 조용히 만들고 있습니다.

에이전트가 건너뛰는 판단

왜 이것이 중요한지 이해하려면, 에이전트를 도입하기 전에 현재 기업이 혼돈을 어떻게 관리하고 있는지, 즉 무엇이 실제로 부서졌는지를 알아야 합니다.

대부분의 성숙한 엔지니어링 조직은 혼돈 엔지니어링 프로그램에 투자했습니다. 게임 데이, 블라스트 반경 제어, SLO 기반 실험 등 말이죠. 사람이 혼돈 실험을 시작하면, 그 흐름에는 중요한 속성이 있습니다: 사람이 현재 시스템이 교란을 흡수할 수 있는지를 판단하는 것입니다. 대시보드를 확인하고, 오류 예산 소모율을 살피며, 의존성이 안정적인지 평가합니다. 이는 완벽하지 않고 직관에 의존하기도 하지만, 무언가 실행되기 전에 올바른 질문을 하는 사람이 루프에 존재한다는 점이 핵심입니다.

자율 복구 에이전트를 도입하면—서비스를 재시작하거나 트래픽을 재라우팅하고, 리소스를 스케일링하거나 구성 변경을 수행하는 에이전트—그 질문이 사라집니다. 에이전트는 이상을 감지하고 행동을 취합니다. 그 행동 자체가 혼돈 이벤트가 되는 것이죠. SLO 소모율 체크도, 블라스트 반경 계산도, “지금이 추가 스트레스를 가하기에 적절한 순간인가?”라는 인간 판단도 없습니다.

제가 목격한 구체적인 실패 모양은 다음과 같습니다. 복구 에이전트가 마이크로서비스의 지연이 상승했음을 감지하고 서비스 클러스터를 재시작합니다. 이는 학습 데이터와 사고에 대한 좁은 시야에서는 합리적인 행동입니다. 하지만 에이전트는 모릅니다: 다른 세 서비스가 현재 피크 트래픽을 처리 중이며, 공유 연결 풀은 이미 87% 사용 중이고, 의존 데이터베이스는 백그라운드 인덱스 재구성을 진행 중이라는 사실을. 재시작은 복구 중인 서비스에 ‘천둥소리 무리’를 일으킵니다.

에이전트가 해결하도록 설계된 지연 스파이크는, 에이전트가 전혀 모델링하지 못한 연쇄 반응으로 변합니다. 에이전트 행동의 블라스트 반경은 서비스 재시작 자체가 아니라, 재시작 이후 하위 시스템 전체이며, 에이전트는 그 전체 상태를 파악하지 못했습니다.

아무 조직도 그 특정 조합을 테스트하지 않았습니다. 아무 블라스트 반경 계산에도 에이전트를 행위자로 포함하지 않았습니다. 왜냐하면 우리는 에이전트를 혼돈 주입자로 생각하지 않기 때문이죠. 그래야 합니다.

AI Incident Database에 따르면, AI 관련 사고 보고 건수는 2024년에서 2025년 사이에 21% 증가했습니다. 하지만 이 수치는 실제 노출을 크게 과소평가하고 있습니다. 대부분의 조직은 자율 에이전트 행동을 연쇄의 최초 원인으로 포착할 분류 체계가 없기 때문입니다. 사고는 서비스 재시작, 연결 풀 포화, 지연 이벤트 등으로 기록되고, 에이전트는 사후 분석에서 보이지 않습니다.

흡수 용량은 자원이며, 대부분의 시스템은 이를 그렇게 다루지 않는다

근본적인 문제는 기업 시스템에 ‘흡수 용량’—시스템이 SLO 약속을 위반하기 전까지 추가로 견딜 수 있는 스트레스 양에 대한 실시간 추정치—에 대한 공유 언어가 없다는 점입니다. 혼돈 엔지니어링 프로그램은 인간 판단과 정적 임계값을 통해 암묵적으로 관리하지만, 이미 한계가 넘어간 뒤에야 작동합니다. 에이전트는 전혀 관리하지 못합니다.

Intuit와 GPTZero 등 여러 조직의 SRE·플랫폼 엔지니어와의 구조화된 1차 연구를 통해, 저는 ‘탄력성 예산(Resilience Budget)’ 모델을 개발하고 있습니다. 핵심 아이디어는 흡수 용량을 정적 임계값이 아니라 지속적으로 재계산되는 소비 가능한 자원으로 보는 것입니다.

탄력성 예산은 네 가지 실시간 신호 클래스를 활용합니다.

• SLO 소모율: 현재 시스템 행동과 실제로 중요한 약속 사이의 거리를 직접 인코딩하므로 가장 중요한 입력입니다. 월간 오류 예산을 기대치의 5배 속도로 소모하고 있다면, CPU 사용률이 어떻든 탄력성 예산은 거의 0에 가깝습니다.
• P99 지연 추세: 절대 지연보다 중요합니다. 40분 동안 지연이 상승하고 있다면, 같은 절대값을 유지하고 있는 서비스와는 다른 의미를 가집니다.
• 의존성 포화 상태: 가장 흔히 놓치는 신호입니다. 공유 연결 풀이 87%에 머물러 있음에도 자유롭게 사용할 수 있다고 가정하는 혼돈 실험이나 에이전트 행동은 설계되지 않은 실패 모드를 초래합니다.
• 애플리케이션 행동 신호: 세션 완료율, API 호출 패턴 변화, 전환율 저하 등은 인프라 메트릭보다 먼저 시스템 스트레스를 드러냅니다. 사용자는 인프라가 Prometheus에 보고하기 전에 이미 체감하고 있기 때문입니다.

예산이 임계값이 아니라 ‘소비 가능한’ 것이 되는 이유는 바로 이 때문입니다. 모든 혼돈 실험은 사용 가능한 용량에서 차감되고, 모든 에이전트 행동도 마찬가지입니다. 여러 팀이 동시에 여러 실험과 에이전트를 운영하는 경우, 예산은 공유됩니다.

소비 내역을 공유하는 장부가 없으면, 겹치는 의존성을 대상으로 실험을 진행하는 두 팀은 각각 계획하지 않은 결합된 블라스트 반경을 만들게 됩니다. 자동 에이전트가 장부 밖에서 행동하면 회계는 붕괴합니다.

언어 모델이 도움이 되는 곳, 그리고 정확히 실패하는 곳

몇몇 엔지니어링 조직은 대형 언어 모델(LLM)을 활용해 의존성 그래프와 사고 사후 분석 코퍼스를 기반으로 혼돈 가설을 생성하고 있습니다. 결과는 방향성 있게 유용합니다. 언어 모델은 경험 많은 SRE가 테스트 가치가 있다고 판단하는 plausible한 실패 모드를 제시하고, 특히 풍부한 사후 분석 기록이 있을 때 수동 프로세스보다 빠르게 가설을 만들어냅니다.

하지만 한계는 의존성 그래프의 최신성입니다. 그래프가 지난달 서비스 추출이나 두 스프린트 전 추가된 공유 라이브