HPE Zerto Agentic Troubleshooting, 온프레미스 복구에 클라우드 AI 도입

HPE Zerto는 세 가지 에이전트 역할로 구성된 agentic troubleshooting 시스템을 출시했지만, 가장 중요한 특징은 이들 에이전트가 작동하는 위치다. HPE Zerto agentic troubleshooting 런타임은 각 고객 환경 내부에 위치한다. 실시간 재해 복구 신호를 로컬에서 분석하는 한편, 선택된 추론 및 지식 질의는 Amazon Web Services로 전송한다.

이러한 분리는 유용한 엔터프라이즈 에이전트가 운영 데이터를 중앙화된 클라우드 애플리케이션으로 옮겨야 한다는 통념에 도전한다. HPE Zerto는 조사 대상 인프라 곁에 오케스트레이션을 배치했다. Amazon Bedrock은 전체 문제 해결 워크플로의 중심이 되지 않으면서도 모델 액세스, 지식 검색, 가드레일 및 지원 제어 기능을 제공한다.

이 시스템은 2026년 2분기에 프로덕션 환경에 도입됐다. HPE와 AWS는 이후 Zerto 고객의 20% 이상이 이를 채택했다고 밝혔다. 또한 시스템이 다루는 워크플로 전반에서 지원 사례가 10% 감소했다고 보고했다. 이 수치는 기업들이 제공한 것이며 독립적인 검증은 이뤄지지 않았다.

이 아키텍처의 결과는 하나의 복구 제품을 넘어 의미가 있다. 재해 복구 환경에는 민감한 로그, 변화하는 구성, 엄격한 액세스 제어, 극심한 시간 압박이 함께 존재한다. 현재 상태를 볼 수 없는 어시스턴트는 일반적인 조언만 제공한다. 제한 없이 액세스할 수 있는 에이전트는 또 다른 운영 리스크를 만든다.

HPE Zerto는 이 두 결과 사이의 좁은 영역을 겨냥한다. 이 시스템의 에이전트는 로컬 정보에 구조화된 방식으로 액세스하고, 기술 영역별로 조사를 분담하며, 하나의 제어 오케스트레이터를 통해 압축된 답변을 반환한다. 핵심 질문은 실제 환경이 더 복잡해질수록 이 아키텍처가 컨텍스트, 안전성, 예측 가능한 동작을 유지할 수 있는지다.

HPE Zerto Agentic Troubleshooting은 고객 환경 내부에서 시작된다

결정적인 변화는 채팅 인터페이스가 아니다. 에이전트 런타임을 조사해야 하는 시스템과 증거 바로 곁에 배치했다는 점이다.

HPE Zerto Software는 하이브리드 및 멀티클라우드 인프라 전반에서 재해 복구, 지속적 데이터 보호, 사이버 복원력을 지원한다. 운영자는 이 제품을 사용해 보호된 워크로드, 복구 준비 상태, 복제 상태, 서비스 수준 계약 노출을 모니터링한다.

이 환경의 문제 해결에는 전통적으로 여러 위치의 정보가 필요하다. 관리자는 경고를 확인하고, 구성 요소 로그를 검토하며, 구성 데이터를 살펴보고, 제품 문서를 검색한 뒤, 결과를 런북과 비교할 수 있다. 장애 상황에서는 이러한 소스 간 이동 하나하나가 지연을 더하고 관련 증거를 놓칠 가능성을 만든다.

새 시스템은 기존 Zerto 관리 인터페이스에 채팅 경험을 배치한다. 운영자는 보호 그룹 상태, 최근 경고, 구성 방식, 복제 지연, 업그레이드 실패 또는 진행 중인 시스템 문제를 질문할 수 있다. 어시스턴트는 상태 문제를 표시하고 완화 조치를 안내할 수도 있다.

공동 아키텍처 설명에 따르면, HPE는 agentic 계층을 고객의 온프레미스 환경 내부에 있는 pod로 배포한다. pod는 하나의 애플리케이션 단위로 실행되는 배포 가능한 컨테이너 그룹이다. 이 설계에서는 로컬 에이전트 런타임을 담는다.

런타임은 AWS가 모델 기반 에이전트 구축을 위해 개발한 오픈소스 프레임워크인 Strands Agents를 사용한다. 세션 기록은 로컬에 저장되며, 에이전트는 로컬 Model Context Protocol 서버를 통해 실시간 Zerto 정보에 접근한다.

Model Context Protocol, 즉 MCP는 AI 애플리케이션이 도구를 호출하고 컨텍스트 데이터를 가져오는 표준 방식을 정의한다. HPE는 기존 Zerto Manager API를 MCP 서버로 감싸 에이전트가 최신 환경 정보에 구조화된 방식으로 접근하도록 했다.

이는 모든 로그와 구성 레코드를 원격 챗봇에 복사하는 방식과 실질적으로 다르다. Zerto 에이전트는 런타임이 어플라이언스 내부에 머무르는 동안 조사에 필요한 로컬 사실을 요청할 수 있다. HPE는 모델 추론 요청과 Amazon Bedrock Knowledge Bases 질의만 HTTPS를 통해 로컬 네트워크 밖으로 나간다고 설명한다.

이 차이는 신중하게 표현할 필요가 있다. 이 시스템은 클라우드와 완전히 분리돼 있지 않으며, 오프라인 모델 배포도 아니다. Amazon Bedrock은 계속 모델 요청을 처리하고, 관리형 지식 서비스는 관련 제품 정보를 검색한다. 로컬 설계는 외부 처리를 없애는 것이 아니라 오케스트레이션과 운영 액세스를 제어한다.

이 경계는 이 글의 핵심 긴장을 만든다. 로컬에서 운영되는 에이전트는 민감한 증거 가까이에 머물 수 있지만, 그 추론은 여전히 원격 모델 서비스와 신중하게 설계된 아웃바운드 요청에 의존한다. 따라서 시스템의 유용성은 어떤 컨텍스트가 이 경계를 넘는지, 어떻게 필터링되는지, 그리고 반환된 지침이 근거에 기반하는지에 달려 있다.

이번 출시로 AI 지원은 복구 워크플로 안으로 더 깊이 들어왔다. 더 이상 문서를 설명하는 데 그치지 않는다. 시스템은 현재 상태를 검사하고 문제별 조사를 구성할 수 있으며, 이는 운영 가치를 높이는 동시에 잘못된 결론이 초래할 비용도 키운다.

허브 앤 스포크 설계로 하나의 에이전트가 통제권을 유지한다

HPE Zerto는 문제 해결을 전문 에이전트로 나누면서도, 위임과 최종 응답의 제어 지점으로 단일 오케스트레이터를 유지했다.

이 아키텍처는 오케스트레이터 에이전트와 최소 두 개의 전문 서브 에이전트를 사용한다. 오케스트레이터는 일상적인 질문을 직접 처리하고, 문제가 전문 분석을 요구할 때 심층 조사를 위임한다.

한 서브 에이전트는 ZVM으로도 불리는 Zerto Manager에 초점을 맞춘다. 서비스 충돌, 네트워킹 문제, 업그레이드 실패와 같은 영역을 조사한다. 이 도구는 관련 환경 데이터에 접근할 수 있게 하며, 도메인 스킬은 기술 지식과 식별 가능한 로그 패턴을 판별한다.

다른 서브 에이전트는 Zerto Replication Engine, 즉 VRA에 초점을 맞춘다. 복제 문제, 사이트 간 네트워킹, 설치 실패, 지연을 처리한다. 이 에이전트는 자체 도구, 지침, 도메인 지식, 작업 컨텍스트를 제공받는다.

이 분리는 중요한 엔지니어링 선택을 반영한다. 하나의 범용 에이전트에 모든 로그, 도구, 지침, 대화 세부 정보를 제공하면 상충하는 신호가 포함된 과도한 컨텍스트가 생성될 수 있다. 또한 동일한 구성 요소가 라우팅, 분석, 응답 생성을 모두 수행하므로 실패를 분리하기 어려워진다.

대신 HPE는 허브 앤 스포크 구조를 사용한다. 오케스트레이터는 허브에 위치하고 전문 에이전트는 스포크로 작동한다. 서브 에이전트는 서로 직접 호출하지 않고 상위 에이전트에 보고한다.

AWS는 이 멀티 에이전트 패턴을 조정 에이전트가 경계가 설정된 인터페이스를 통해 전문가를 호출하는 agents-as-tools로 설명한다. 각 전문 에이전트는 별도의 프롬프트, 컨텍스트, 모델, 도구 세트를 사용할 수 있다.

Zerto에서 이러한 분리는 세 가지 실질적인 이점을 제공한다. 첫째, 로그가 많은 조사가 원시 진단 자료로 오케스트레이터의 컨텍스트를 채우지 않는다. 전문 에이전트는 전체 작업 과정이 아니라 조사 결과를 담은 더 짧은 보고서를 반환한다.

둘째, 각 에이전트를 독립적으로 테스트할 수 있다. 엔지니어는 모든 테스트가 관련 없는 ZVM 동작을 통과하도록 요구하지 않고도 VRA 전문 에이전트가 올바른 도구를 선택하는지 평가할 수 있다. 이러한 분리는 회귀 문제의 위치를 더 쉽게 찾게 할 수 있다.

셋째, 오케스트레이터는 최종 답변의 책임을 유지한다. HPE는 사용자에게 결과를 제시하기 전에 비밀 정보와 원시 로그를 제거한다고 밝혔다. 단일 출력 경로는 제품이 응답 규칙을 적용할 하나의 지점도 제공한다.

허브 앤 스포크 구조는 수평적 자율성을 제한한다. 전문 에이전트가 다른 구성 요소가 문제를 담당한다는 사실을 발견하면, 그 관찰 결과를 오케스트레이터에 반환한다. 동료 에이전트를 독립적으로 호출하지는 않는다.

이 제약은 의사결정에 이르지 못한 채 토큰을 소모하는 재귀적 에이전트 대화의 가능성을 줄인다. 또한 관측 가능성을 위한 추적 가능한 순서를 만든다. 모든 위임은 동일한 제어 지점에서 시작되고 끝난다.

상충하는 대가는 잠재적인 라우팅 마찰이다. 오케스트레이터는 질문에 전문화가 필요한 시점을 올바르게 인식하고 적절한 에이전트를 선택해야 한다. 전문 에이전트 역시 최종 진단에 필수적인 증거를 제거하지 않고 조사 결과를 압축해야 한다.

HPE는 이러한 책임에 서로 다른 모델 프로필을 사용한다. 일상적인 작업은 오케스트레이터에서 처리할 수 있고, 추론 비중이 큰 조사는 더 강력한 모델을 사용할 수 있다. 회사는 처음에 실행 가능성을 확인하기 위해 더 큰 모델을 평가한 뒤, 응답 품질, 지연 시간, 비용 측면에서 대안을 비교했다고 설명한다.

이 멀티 모델 접근 방식은 모든 요청을 동일하게 어려운 작업으로 취급하지 않는다. 보호 그룹의 상태를 확인하는 일은 로그와 네트워크 상태 전반에 걸친 장기 장애 시퀀스를 해석하는 것과 같은 수준의 추론 예산을 필요로 하지 않는다.

또한 모델 선택을 일회성 조달 결정에서 지속적인 엔지니어링 프로세스로 전환한다. 파운데이션 모델이 변화함에 따라 HPE는 전체 제품을 특정 공급자 워크플로 하나에 맞춰 재구축하지 않고도 각 에이전트에 적합한 모델을 재평가할 수 있다.

실시간 복구 데이터는 장점이자 위험이다

시스템은 현재 인프라를 질의할 수 있을 때 유용해지지만, 바로 그 액세스 때문에 근거성, 권한, 도구 선택이 매우 중요해진다.

문제 해결 에이전트에는 제품 매뉴얼 이상이 필요하다. 문서는 경고의 의미를 설명할 수 있지만, 특정 복제 엔진이 지연되는지, 어떤 네트워크 경로가 실패하는지, 최근 구성 변경이 복구 준비 상태에 영향을 주었는지는 알려줄 수 없다.

HPE는 로컬 MCP 서버를 통해 에이전트를 실시간 운영 데이터에 연결한다. 이 서버는 선택된 Zerto Manager API를 구조화된 도구로 노출한다. 언어 모델에 원시 데이터 덤프를 해석하도록 요청하는 대신, 에이전트는 정의된 작업을 호출하고 유형이 지정된 결과를 받을 수 있다.

공개 MCP 사양은 합의된 클라이언트-서버 인터페이스를 통해 도구, 리소스, 프롬프트를 분리한다. 엔터프라이즈 소프트웨어에서 이 구조는 기반 운영 서비스를 재작성하지 않고도 기존 제품 API를 에이전트가 접근 가능한 계층으로 전환할 수 있다.

유형이 지정된 액세스는 도움이 되지만, 정확한 진단을 보장하지는 않는다. 에이전트는 여전히 적절한 도구를 선택하고, 유효한 파라미터를 제공하며, 반환된 정보를 해석하고, 이를 관련 문서와 연결해야 한다.

HPE는 로컬 도구와 Amazon Bedrock Knowledge Bases를 결합한다. 검색 증강 생성, 즉 RAG는 모델이 답변을 생성하기 전에 관련 소스 자료를 검색한다. 목표는 모델의 기억에만 의존하는 대신, 승인된 제품 문서와 런북에 근거해 지침을 제공하는 것이다.

Amazon의 지식 베이스 서비스는 문서 검색을 관리하고 질의와 관련된 소스 자료를 반환할 수 있다. Zerto의 설계에서 이 외부 지식은 MCP를 통해 얻은 로컬 환경 상태를 보완한다.

이러한 소스 간 차이는 중요하다. 제품 문서는 예상되는 동작을 설명한다. 로컬 API는 고객의 현재 상태를 설명한다. 신뢰할 수 있는 문제 해결을 위해서는 에이전트가 일반적인 절차와 진행 중인 인시던트에 관한 증거를 혼동하지 않고 두 정보를 비교해야 한다.

복제 지연 문제를 생각해 보자. 문서에는 대역폭 제약, 네트워크 중단, 워크로드 변동 또는 어플라이언스 상태가 가능한 원인으로 나열될 수 있다. 로컬 도구는 고객 환경에 어떤 조건이 실제로 존재하는지 확인해야 한다. 유용한 응답은 전체 목록을 되풀이하는 대신 가능성을 좁혀야 한다.

HPE는 전문 에이전트가 알려진 로그 패턴을 포함한 도메인 스킬도 활용한다고 설명한다. 이러한 스킬은 특정 구성 요소 및 장애와 연관된 신호를 인식하도록 모델에 구조화된 지침을 제공한다.

그다음 시스템은 내부적으로 출처 정보를 보존해야 한다. 엔지니어는 실시간 데이터로 뒷받침되는 조사 결과와 모델이 추론한 가설을 구분할 수 있어야 한다. 공개된 AWS 계정은 텔레메트리, 평가 및 구조화된 출력을 설명하지만, 관리자에게 표시되는 전체 인용 동작은 공개하지 않는다.

액세스 제어도 또 다른 압박 지점이다. 광범위한 MCP 도구는 질문에 필요한 것보다 더 많은 운영 정보를 노출할 수 있다. 범위가 좁은 도구는 노출을 줄이지만 진단에 필요한 맥락을 누락할 수 있다. 따라서 도구 경계를 설계하는 일은 단순한 통합 작업이 아니라 보안 및 제품 결정이 된다.

테넌트별 요청 태깅은 또 다른 통제 수단을 제공한다. 이 아키텍처는 각 테넌트와 연결된 AWS Identity and Access Management 역할 태그를 사용한다. CloudWatch, DynamoDB 및 Lambda는 사용량 모니터링과 테넌트 제한 적용을 지원한다.

Amazon Bedrock Guardrails는 모델 추론 전후의 프롬프트와 출력을 검사한다. AWS 문서에 따르면 가드레일 제어 기능은 선택된 콘텐츠를 필터링하고, 프롬프트 공격을 탐지하며, 금지된 주제를 제한하고, 민감한 정보를 마스킹할 수 있다.

이러한 필터는 특정 위험을 줄이지만 모든 운영 결론을 검증할 수는 없다. 응답은 승인된 주제 범위에 머물면서도 잘못된 조치를 권고할 수 있다. 가드레일은 콘텐츠 경계를 관리하며, 기술적 정확성은 평가와 제품 로직이 다뤄야 한다.

이 때문에 HPE의 로컬 아키텍처를 단순한 개인정보 보호 주장으로 해석해서는 안 된다. 로컬 오케스트레이션은 중앙 집중식 수집을 줄이고 도구 실행을 환경 가까이에 유지한다. 그렇다고 아웃바운드 데이터 통제, 권한 설계, 모델 위험 테스트 또는 고영향 사고 발생 시의 인간 판단이 불필요해지는 것은 아니다.

HPE Zerto가 테스트한 응답, 도구 경로, 지연 시간 및 토큰

HPE는 평가를 출시 전 수행하는 단일 정확도 테스트가 아니라 운영 시스템으로 다뤘다.

에이전트 평가는 최종 응답이 관찰 가능한 결과 중 하나일 뿐이기 때문에 어렵다. 에이전트는 잘못된 도구를 선택하거나, 관련 없는 증거를 사용하거나, 지나치게 비용이 큰 경로를 택한 뒤에도 그럴듯한 답변을 만들 수 있다. 이러한 동작은 조건이 조금만 달라져도 실패할 수 있다.

HPE는 PyTest와 Strands Agents 평가 소프트웨어 개발 키트를 사용해 테스트를 구축했다. 에이전트, 모델 및 프롬프트가 바뀔 때 더 광범위한 테스트 스위트를 반복 실행하는 작업을 만들었다.

첫 번째 테스트 범주는 기본 질의를 다룬다. 각 테스트는 단일 요청을 제공하고 응답을 평가한다. 이 접근 방식은 명확한 예상 결과나 정의된 채점 기준이 있는 안정적인 질문에 적합하다.

두 번째 범주는 멀티턴 대화를 평가한다. 초기 질의 이후 사용자 시뮬레이터 모델이 에이전트와 상호작용하고, 전체 대화가 평가 대상이 된다. 이 형식은 시스템이 누락된 정보를 요청하고 여러 차례의 대화에 걸쳐 맥락을 유지하는지 시험한다.

세 번째 범주는 동적 테스트를 생성한다. Strands 실험 생성기는 선택한 기준을 바탕으로 사례를 만들어, HPE가 고정된 테스트 세트에 포함되지 않은 시나리오를 탐색할 수 있게 한다. 동적 생성은 범위를 넓히지만, 생성된 테스트에도 여전히 의미 있는 기준과 검토가 필요하다.

각 테스트에는 네 가지 평가기를 적용할 수 있다. 응답 평가는 사전 정의된 요구 사항에 따라 답변을 채점한다. 경로 평가는 에이전트가 적절한 도구를 선택하고 허용 가능한 경로를 따랐는지 살핀다.

지연 시간 평가는 완료 시간이 임계값 이내인지 확인한다. 토큰 평가는 사용량이 정의된 범위 내에 머무르는지 확인한다. 이 지표들은 함께 진단 품질, 응답 시간 및 추론 소비 간의 프로덕션 트레이드오프를 반영한다.

운영 에이전트에서 경로 평가는 특히 중요하다. 시스템이 안전하지 않거나 신뢰할 수 없는 순서로 결론에 도달했더라도 최종 문구는 정확해 보일 수 있다. 경로를 테스트하면 에이전트가 실시간 검증을 건너뛰었는지, 관련 없는 API를 호출했는지, 현재 데이터를 사용할 수 있는데도 문서에 의존했는지를 드러낼 수 있다.

평가 스위트는 멀티모델 설계도 지원한다. HPE는 동일한 응답, 경로, 지연 시간 및 토큰 기준으로 소형 모델과 대형 모델을 비교할 수 있다. 이로써 모델 교체는 대형 모델이 항상 더 뛰어나다는 일반적 가정이 아니라 실증적 결정이 된다.

시스템은 Server-Sent Events를 사용해 조사 진행 상황을 인터페이스로 스트리밍한다. SSE는 서버가 하나의 연결을 통해 브라우저에 업데이트를 지속적으로 전송할 수 있게 하는 웹 메커니즘이다. 사용자는 전문 에이전트가 문제를 조사하는 동안 진행 상황을 확인할 수 있다.

HPE는 스트리밍이 운영자가 피드백 없이 기다리지 않게 해 사용자 경험을 개선했다고 설명한다. 재해 복구 상황에서는 표시되는 진행 상황이 계속 진행 중인 조사와 멈춘 인터페이스를 구분하는 데도 도움이 된다.

하지만 증거적 가치를 설명하지 않은 채 단계를 표시한다면 스트리밍 활동은 잘못된 신뢰를 만들 수 있다. 도구 호출 목록은 검증된 진단과 같지 않다. 인터페이스는 내부 추론을 보여주기식으로 만들지 않으면서도 신뢰를 형성할 만큼의 진행 정보를 제시해야 한다.

같은 주의는 HPE의 도입 주장에도 적용된다. 회사는 고객의 20% 이상이 시스템을 적극적으로 사용하고 있으며, 해당 지원 사례가 10% 감소했다고 보고한다. 이러한 결과는 실제 제품 사용을 시사하지만, 공개 게시물은 활성 사용의 정의, 측정 기간 또는 대상 워크플로 인구를 명시하지 않는다.

지원 사례 감소에도 여러 가능한 설명이 있다. 에이전트가 문제를 성공적으로 해결했을 수도 있고, 사용자를 기존 문서로 안내했을 수도 있으며, 사례 분류 방식을 바꿨거나 일부 에스컬레이션을 억제했을 수도 있다. 독립적인 해결률 및 결과 데이터가 더 명확한 관점을 제공할 것이다.

유사한 설계를 고려하는 엔지니어링 팀에 주는 교훈은 네 가지 평가기가 신뢰성을 확정한다는 것이 아니다. 교훈은 프로덕션 에이전트가 여러 계층에서 측정 가능한 동작을 필요로 한다는 점이다. 답변 품질, 도구 선택, 응답성 및 리소스 사용은 각각 독립적으로 실패할 수 있다.

검색 가능한 엔지니어링 지식 베이스도 관련된 원칙을 따른다. 문서가 체계적으로 정리되고 최신 상태로 유지되며 엔지니어가 수행하는 업무와 연결될 때 검색은 더 유용해진다.

클라우드 복구 플랫폼이 이제 마주한 인터페이스 질문

경쟁 압력은 복제 기능만의 경쟁에서 사고 발생 시 복구 상태를 해석하고 운영자를 안내할 수 있는 주체를 둘러싼 경쟁으로 이동하고 있다.

HPE Zerto는 이미 클라우드 네이티브 복구 서비스를 포함하는 시장에서 경쟁하고 있다. Amazon Elastic Disaster Recovery는 지원되는 온프레미스 및 클라우드 워크로드를 AWS 계정 내 스테이징 영역으로 복제한다. 운영자는 훈련 또는 실제 사고를 위해 복구 인스턴스를 시작할 수 있다.

AWS 복구 서비스는 지속적 복제, 시점 복구, 비중단 테스트 및 페일백을 강조한다. 이 서비스는 AWS 인프라와 긴밀히 통합되어 있으며 Amazon EC2로의 복구를 대상으로 한다.

Microsoft Azure Site Recovery는 지원되는 가상 머신 및 물리적 서버의 복제, 페일오버 및 페일백을 관리한다. 복구 플랫폼은 Azure 간 복제와 Azure를 복구 대상으로 하는 여러 온프레미스 시나리오를 포괄한다.

이러한 서비스는 모든 Zerto 배포와 직접적으로 일대일 대응하지는 않는다. HPE Zerto는 더 폭넓은 하이브리드 운영 패턴을 지원하고 자체 제품 아키텍처를 유지한다. 여기서 중요한 비교는 복제 기능의 체크리스트가 아니다.

새로운 압력은 이러한 기능 위에 놓인 운영 인터페이스에 관한 것이다. 복구 시스템은 경고, 구성 상태, 복제 지표 및 훈련 결과를 생성한다. 에이전트는 모든 관리자가 각 신호의 위치를 알 필요 없이 이 정보를 안내형 조사로 변환할 수 있다.

HPE의 초기 움직임은 독점적인 운영 맥락을 중심으로 에이전트 동작을 정립할 기회를 제공한다. 전문 에이전트는 구성 요소별 로그 패턴을 인코딩하고 Zerto Manager 및 복제 엔진과 이미 연결된 API를 사용할 수 있다.

클라우드 제공업체는 다른 이점을 보유한다. 각자의 클라우드 내 인프라, 텔레메트리, ID 서비스, 복구 API 및 관리형 AI 플랫폼을 통제한다. 잠재적으로 더 폭넓은 네이티브 신호 집합에 직접 접근하는 에이전트를 구축할 수 있다.

이것이 HPE Zerto 접근 방식의 핵심 경쟁 구도를 만든다. 즉, 로컬에서 통제되는 문제 해결과 클라우드 중심의 운영 인텔리전스 간의 대결이다. AWS가 Zerto 시스템의 기반 모델을 제공하기 때문에 이는 단순히 HPE 대 AWS 또는 Microsoft의 경쟁이 아니다. 이는 통제와 맥락을 위한 아키텍처적 위치 간의 경쟁이다.

로컬 통제는 오케스트레이션을 보호된 인프라 가까이에 두고 엄격한 데이터 레지던시 정책이 적용되는 환경을 지원할 수 있다. 클라우드 중심 시스템은 각 고객의 어플라이언스 안에서 에이전트 런타임을 유지하지 않고도 통합 텔레메트리와 관리형 서비스에서 정보를 가져올 수 있다.

HPE의 아키텍처는 두 경로를 결합한다. 에이전트와 운영 도구는 로컬에 유지되는 반면, 모델 추론과 문서 검색에는 AWS를 사용한다. 이 하이브리드 구성은 관리형 파운데이션 모델을 포기하지 않으면서 가장 민감한 실행 경계를 온프레미스에 두려는 시도다.

이 접근 방식은 완전 관리형 클라우드 서비스가 피할 수 있는 배포 책임도 HPE에 부여한다. 로컬 Pod는 제품 릴리스, 고객 네트워크 정책, 인증 시스템 및 제한된 아웃바운드 연결과 호환성을 유지해야 한다. 문제 해결 에이전트를 문제 해결하는 일 자체가 운영 부담의 일부가 된다.

에어갭 환경은 가장 뚜렷한 제약을 제시한다. HPE는 재해 복구 인프라가 흔히 에어갭 상태이거나 지연 시간에 민감하거나 데이터 레지던시 요구 사항의 적용을 받는다고 설명한다. 하지만 설명된 시스템은 여전히 모델 추론과 지식 질의를 위해 HTTPS 접근이 필요하다.

따라서 엄격히 분리된 설치 환경은 설명된 그대로의 아키텍처를 사용할 수 없다. 다른 고객은 엄격히 통제된 아웃바운드 트래픽을 허용할 수 있지만, 보안 팀은 여전히 목적지, 요청 내용, ID 통제, 보존 동작 및 장애 모드를 검토해야 한다.

지연 시간도 두 위치에 걸쳐 발생한다. Zerto에 대한 도구 호출은 로컬에 남아 있는 반면, 추론 요청은 AWS로 이동한다. 복잡한 조사는 모델 결정과 로컬 도구 결과 사이에 여러 차례의 순환을 요구할 수 있다. 스트리밍은 이 대기 시간을 가시화할 수는 있지만 네트워크 의존성을 제거할 수는 없다.

이 아키텍처의 전략적 가치는 이 하이브리드 절충안이 대안보다 더 나은 성능을 제공하는지에 달려 있다. 원시 운영 데이터를 중앙화하지 않으면서도 신뢰할 수 있고 증거 기반의 지침을 제공한다면, 엔터프라이즈 소프트웨어 공급업체에 재사용 가능한 패턴을 제공한다. 네트워크 제약이나 근거화 오류가 지배적이라면 구매자는 더 단순한 지원 방식이나 완전 관리형 클라우드 운영을 선호할 수 있다.

다음 시험대는 안내형 진단이 신뢰받는 운영으로 자리 잡는지 여부다

HPE Zerto의 에이전트 기반 문제 해결이 매력적인 지원 인터페이스가 아니라 신뢰할 수 있는 인프라가 되고 있는지를 보여줄 세 가지 신호가 있다.

첫 번째 신호는 해결 품질에 관한 증거다. 도입 규모와 지원 사례 건수는 유용한 출발점이지만, 사용자가 안전한 해결책을 선택했는지 또는 사고를 더 빠르게 해결했는지는 보여주지 않는다.

HPE는 궁극적으로 지원 워크플로우의 결과 지표를 공개해야 한다. 유용한 신호로는 성공적인 셀프서비스 해결, 에이전트 상호작용 이후의 에스컬레이션, 반복 사고, 관리자 승인, 검토 과정에서 발견된 오류 등이 있다. 비교 가능한 측정 기간을 적용하면 이러한 결과는 더욱 의미를 갖게 된다.

독립적인 검토를 거친 결과가 다양한 고객 환경에서 정확한 진단을 보여준다면, 로컬 에이전트 기반 운영의 근거는 더 강해진다. 신뢰할 수 있는 해결 데이터 없이 지원 감소만 나타난다면, 공개된 성과 이야기는 여전히 불완전하다.

두 번째 신호는 자문 업무를 넘어선 확장이다. HPE는 사용자를 대신해 작업을 수행하는 것을 시스템의 목표 중 하나로 제시한다. 공개된 아키텍처는 주로 지원, 조사, 상태 경고, 완화 지침을 설명한다.

권고에서 실행으로 넘어가면 위험 모델이 달라진다. 잘못된 설명은 시간을 소모시키지만, 잘못된 구성 변경은 보호나 복구 준비 상태에 영향을 줄 수 있다. 작업을 수행하는 에이전트에는 제한된 권한, 승인 절차, 완전한 감사 추적, 멱등성 작업, 신뢰할 수 있는 롤백 경로가 필요하다.

따라서 시스템이 구성을 수정할 수 있게 하는 모든 릴리스는 면밀한 주의를 받아야 한다. 명시적인 확인 절차를 갖춘 제한적이고 되돌릴 수 있는 작업은 HPE의 아키텍처를 강화할 것이다. 공개된 제어 세부 사항 없이 광범위한 자율 복구를 허용하면 불확실성이 커질 것이다.

세 번째 신호는 연결 상태가 저하되거나 중대한 사고가 발생했을 때 에이전트가 어떻게 작동하는지다. 일상적인 지원 문의는 안정적인 네트워크 접속과 보통 수준의 긴급성을 전제로 한다. 하지만 랜섬웨어 사건이나 인프라 장애는 에이전트가 사용하는 동일한 ID, 네트워크 또는 클라우드 경로를 중단시킬 수 있다.

Amazon Bedrock을 사용할 수 없게 되거나, 지식 쿼리가 시간 초과되거나, 로컬 도구가 오래된 데이터를 반환하거나, 오케스트레이터가 조사를 완료하지 못할 때 HPE의 동작은 명확해야 한다. 안전한 성능 저하는 누락된 증거와 정상적인 인프라를 구분하고, 운영자를 확립된 복구 절차로 안내해야 한다.

회사의 내부 사용도 또 하나의 시험 환경을 제공한다. HPE는 엔지니어들이 일반적인 문제를 조사하는 데 이 시스템을 사용하며, 품질 보증 팀은 이를 테스트 워크플로우에 통합한다고 말한다. 이 사용자들은 고객이 위기 상황에서 동일한 동작에 의존하기 전에 실패 패턴을 드러낼 수 있다.

이 아키텍처에는 이미 몇 가지 합리적인 제약이 포함되어 있다. 전문 에이전트에는 제한된 책임이 부여된다. P2P 재귀는 금지된다. 오케스트레이터가 최종 출력을 제어한다. 로컬 API는 최신 데이터를 제공하며, 반복 평가가 응답과 도구 실행 경로를 검토한다.

이러한 제어 장치 중 어느 것도 언어 모델의 추론을 결정론적으로 만들지는 않는다. 시스템은 여전히 변화하는 소프트웨어 버전, 고객 토폴로지, 로그 형식, 모델 릴리스, 문서 전반에서 작동한다. 따라서 지속적인 평가는 배포 이후에도 제품을 따라가야 한다.

엔터프라이즈 구매자에게 올바른 질문은 에이전트가 경고를 요약할 수 있는가가 아니다. 시스템이 답변의 출처를 보여주는지, 운영 권한을 준수하는지, 누락된 증거를 인식하는지, 불확실성이 실행으로 이어지기 전에 에스컬레이션하는지가 중요하다.

개발자는 도구 경계를 주시해야 한다. 잘 설계된 MCP 서버는 기존 API를 에이전트가 사용할 수 있게 만들 수 있지만, 노출되는 모든 작업은 시스템의 권한을 확장한다. 제품 팀은 공개 API와 관리자 역할에 적용하는 것과 같은 수준의 주의로 도구 설계를 다뤄야 한다.

지식 근로자는 이 배포에서 더 넓은 교훈을 얻을 수 있다. AI는 신뢰할 수 있는 참고 자료를 현재 업무 맥락과 연결할 수 있을 때 더 유용해진다. 그 이점은 소스 품질, 접근 경계, 검색된 사실과 생성된 판단 사이의 명확한 구분에 달려 있다.

HPE Zerto는 이 아이디어를 엔터프라이즈 컴퓨팅에서 가장 관용적이지 않은 환경 중 하나로 옮겼다. 이 시스템은 하나의 운영 경로 안에서 로컬 오케스트레이션, 실시간 재해 복구 데이터, 전문 에이전트, 관리형 클라우드 추론을 결합한다.

이제 증거는 도입 규모를 넘어야 한다. HPE가 해결 결과를 공개하는지, 통제된 작업을 도입하는지, 성능 저하 모드의 동작을 문서화하는지 지켜봐야 한다. 이러한 신호가 HPE Zerto의 에이전트 기반 문제 해결 모델이 다른 인프라 공급업체가 따라야 할 패턴이 될지를 결정할 것이다.