자율 운영(Autonomous Operations)이 실패하는 이유는 분산 시스템(Distributed Systems)이 실패하는 이유와 같다

Cisco는 지난주 AgenticOps를 출시했습니다. Microsoft, AWS, Google도 그 뒤를 바짝 쫓고 있습니다.

현재 모든 기업 IT 포럼에서 오가는 대화는 다음과 같습니다: AI 에이전트(AI agents)가 실제로 이 일을 해낼 수 있을까? 충분히 잘 추론할 수 있을까? 정확하게 문제를 해결(troubleshoot)할 수 있을까? 무언가를 망가뜨리지는 않을까?

하지만 그것은 흥미로운 질문이 아닙니다.

진정으로 흥미로운 질문은, 에이전트가 작동하게 될 인프라(infrastructure)가 자율적인 동작(autonomous action)을 지원할 수 있을 만큼 충분히 양호한 상태인가 하는 점입니다.

아무도 논의하지 않는 전제 조건

계속해서 나타나는 패턴이 하나 있습니다. 자율 운영(autonomous operations) 배포를 평가하는 조직들은 평가 시간의 대부분을 에이전트 계층(agent layer) — 모델 품질(model quality), 추론 능력(reasoning capability), 인간 감독 워크플로우(human oversight workflows) — 에 소비합니다. 제가 **자율 운영 준비도 (Autonomous Operations Readiness)**라고 부르는 것, 즉 어떤 에이전트라도 안전하게 행동하기 전에 반드시 존재해야 하는 인프라 조건들에 투입되는 평가 시간은 거의 없습니다.

이러한 조건들은 새로운 것이 아닙니다. 숙련된 인간 운영자에게도 필요한 것과 동일합니다:

• 권위 있는 상태 (Authoritative state) — 가끔씩 일치하기도 하는 세 개의 소스가 아닌, 구성을 위한 단일 진실 공급원(one source of truth)
• 의존성 인식 (Dependency awareness) — X를 건드렸을 때 무엇이 망가지는지 알 수 있을 만큼 충분히 완전한 지도
• 복구 순서 (Recovery sequencing) —

실제 운영 환경에는 다른 것이 필요합니다. 즉, 불확실성이 정의된 임계값(threshold)을 초과할 때까지 실행되다가, 그 이후에는 에스컬레이션(escalation, 상위 단계 보고)을 수행하는 에이전트가 필요합니다. 에스컬레이션 경계(escalation boundary)는 실패 모드(failure mode)가 아닙니다. 그것은 제어 메커니즘(control mechanism)입니다. 그것은 '자율(autonomous)'이 끝나고 '감독(supervised)'이 시작되는 지점입니다.

정의된 에스컬레이션 경계가 없다면, 당신은 자율 운영 시스템을 가진 것이 아닙니다. 당신은 차단기(circuit breaker)가 없는 자동화된 시스템을 가진 것뿐입니다.

전제 조건이 누락되었을 때 실제로 발생하는 일

당신의 환경에서 변경 작업 시간(change window)에 대한 이견이 있었던 마지막 상황을 생각해 보십시오. CMDB는 한 가지를 말하고, 실제로 배포된 것은 다른 것을 말하며, 세 번째 엔지니어는 6개월 전에 수행된 작업에 대해 또 다른 기억을 가지고 있는 상황 말입니다. 그러한 상황에서 인간 운영자는 망설입니다. 그들은 질문을 던집니다. 상황이 더 명확해질 때까지 조치를 지연시킵니다. 그 망설임은 비용이 많이 듭니다. 하지만 그것은 또한 잘못 진단된 상태가 다중 시스템 장애(multi-system outage)로 이어지는 것을 방지하는 메커니즘이기도 합니다.

자율 시스템은 망설이지 않습니다. 그들은 자신들이 가진 상태(state)를 바탕으로 실행을 계속합니다.

그 상태가 불완전할 때 — 즉, 의존성 지도(dependency maps)에 공백이 있고, 권위 있는 상태 소스(authoritative state sources)에 이견이 있으며, 서로 다른 계층의 관측성(observability) 신호가 일치하지 않을 때 — 뒤따르는 실패는 단순히 틀린 것에 그치지 않습니다. 그것은 감독 계층(oversight layer)이 개입할 시간을 갖기도 전에, 기계의 속도로, 더 넓은 폭발 반경(blast radius)에 걸쳐 잘못된 결과를 초래합니다.

대부분의 평가 팀이 집중하는 위험: AI가 잘못된 결정을 내리면 어떻게 되는가?

더 많은 주의를 기울여야 할 위험: 인프라가 어떤 결정도 안전하게 내릴 수 있을 만큼 충분한 정보를 알지 못한다면 어떻게 되는가?

⚠ 확인해 볼 가치가 있는 사항: 지금 당신의 환경에서 — 모니터링은 정상(healthy)이라고 말하는데 애플리케이션 계층은 성능 저하(degraded)를 보고하고, 네트워크는 정상(normal)이라고 말하고 있지는 않습니까? 인간 운영자는 신호가 충돌한다는 것을 인식하고 에스컬레이션을 할 수 있습니다. 정의된 에스컬레이션 경계가 없는 자율 시스템은 자신의 정책이 권위 있다고 간주하는 신호에 따라 행동할 것입니다.

왜 모든 벤더가 결국 동일한 계층에 도달하는가

이 부분은 일단 이해하고 나면 납득이 갈 것입니다: Cisco, AWS, Google, Microsoft, ServiceNow — 이들은 모두 동일한 아키텍처 계층(Architectural Layer)을 향해 구축하고 있습니다. 관측성 (Observability), 정책 (Policy), ID (Identity), 자동화 인프라 (Automation Infrastructure) 말입니다. 이는 서로를 모방했기 때문이 아닙니다. 그 위에 어떤 에이전트 (Agent)가 실행되든 전제 조건이 동일하기 때문입니다.

"워크로드 성능 저하 (Workload degraded)" 신호를 받는 자율 복구 워크플로우 (Autonomous remediation workflow)는 다음 사항을 알아야 합니다: 이 워크로드를 누가 소유하고 있는가 (ID 상태, Identity state), 격리 조치를 규정하는 정책은 무엇인가 (정책 상태, Policy state), 이 워크로드에 의존하는 것은 무엇인가 (의존성 상태, Dependency state), 그리고 환경의 현재 운영 상태는 어떠한가 (운영 상태, Operational state). 이 네 가지가 동시에 충족되지 않는다면, 에이전트가 취하는 모든 조치는 추측에 불과합니다. 망설임 없이 실행되는, 신뢰도가 높은 추측일 뿐입니다.

이것이 바로 모든 벤더가 제어 평면 (Control plane) 계층으로 수렴하는 이유입니다. 자율 시스템은 런타임 (Runtime) 중에 운영 상태 (Operational state)를 처음부터 구축할 수 없습니다. 그것은 반드시 사전에 존재해야 합니다.

에이전트를 평가하기 전에, 환경을 평가하십시오

AI 에이전트가 인프라 운영 (Infrastructure operations)을 수행할 준비가 되었는지 묻기 전에, 귀하의 인프라가 자율 운영자 (Autonomous operators)를 받아들일 준비가 되었는지 먼저 물으십시오.

현재 귀하의 환경 중 다음 사항을 갖춘 비중은 어느 정도입니까:

• 충돌 시 우선권을 갖는 단일 권위 상태 소스 (Single authoritative state source)
• 프로그래밍 방식으로 쿼리할 수 있을 만큼 충분히 완비된 의존성 문서 (Dependency documentation)
• 암묵적 지식 (Tribal knowledge)이 필요하지 않은 정의된 복구 순서 (Recovery sequencing)
• 에이전트에게 모호함 없이 부여할 수 있는 명확한 권한 경계 (Authority boundaries)
• 공식적인 에스컬레이션 임계값 (Escalation threshold) — 시스템이 멈추고 도움을 요청하게 될 정확한 불확실성 수준

가장 솔직한 답변은 "부분적으로"와 "그렇지 않다" 사이 어딘가에 머물 것입니다.

이것은 자율 운영에 반대하는 논거가 아닙니다. 어디서부터 시작해야 하는지에 대한 논거입니다.

전체 아키텍처 분석 — 프레임워크 #118, 제어 평면 기질 (Control plane substrate) 논의, 교차 필라 거버넌스 (Cross-pillar governance) 연결 — 전체 버전은 rack2cloud.com에서 확인할 수 있습니다:

자율 운영(Autonomous Operations)을 위해서는 대부분의 기업이 갖추지 못한 인프라가 필요합니다

원문은 rack2cloud.com에서 처음 게시되었습니다.