Cohesity Agent Resilience, AI 에이전트가 만드는 복구 공백 겨냥

Cohesity는 9월 16일 Cohesity Agent Resilience를 공개하며 AI 에이전트와 이들이 변경할 수 있는 시스템까지 복구 보호 범위를 확장했다. 이 새로운 기능에는 더 강한 약속이 따른다. 사람의 승인을 없애지 않으면서 사이버 대응의 더 많은 부분을 자동화하겠다는 것이다.

이 구분이 중요한 이유는 엔터프라이즈 에이전트가 수동적인 보조 도구가 아니라 능동적인 운영 주체가 되고 있기 때문이다. 에이전트는 메모리를 유지하고, 애플리케이션을 호출하며, 데이터베이스를 업데이트하고, 워크플로를 실행한다. 탐지는 유해한 행동을 드러낼 수 있지만, 탐지만으로는 에이전트를 복원하거나 영향을 받은 모든 리소스를 되돌릴 수 없다.

Cohesity는 에이전트와 그 상태, 연결된 인프라를 하나의 복구 가능한 시스템으로 다루고 있다. Commvault, Druva, Rubrik도 유사한 접근법을 추진하며, AI 에이전트 복구를 데이터 보호 시장의 새로운 경쟁 영역으로 만들고 있다.

Cohesity Agent Resilience는 에이전트 이상을 보호한다

Cohesity Agent Resilience는 AI 에이전트의 메모리와 구성을 복구 가능한 운영 상태로 취급한다.

Cohesity는 9월 16일과 17일 여러 지역에서 열린 Catalyst 2026 가상 행사에서 이 기능을 발표했다. 회사는 앞서 Catalyst에서 멀티 에이전트 환경과 자율 복구 워크플로를 위한 새로운 제어 기능을 선보일 것이라고 밝힌 바 있다.

에이전트의 상태에는 행동에 영향을 주는 저장된 컨텍스트와 구성이 포함된다. 악의적인 지시, 구성 드리프트 또는 손상된 메모리가 이 상태를 바꾸면 데이터베이스를 복원하더라도 에이전트의 판단이 반드시 복원되는 것은 아니다.

Cohesity는 새 기능이 이러한 상태에 대한 시점 복구 옵션을 제공한다고 설명한다. 관리자는 영향을 받은 에이전트를 다시 구축하고 축적된 컨텍스트를 잃는 대신, 정상으로 알려진 버전으로 되돌릴 수 있다.

보호 범위는 에이전트 주변의 인프라까지 확장된다. 회사의 에이전트 복구 개요에 따르면, 이 범위에는 애플리케이션, 데이터베이스, 파일 시스템, 메모리 저장소, 그리고 에이전트가 사용하거나 관리하는 기타 서비스가 포함될 수 있다.

더 넓은 범위는 에이전틱 소프트웨어의 근본적인 문제를 다룬다. 에이전트는 메모리가 손상된 상태에서도 기능할 수 있으며, 복구된 뒤에도 연결된 시스템에 유해한 변경을 남길 수 있다.

이에 따라 Cohesity는 두 가지 복구 작업을 구분한다. 하나는 에이전트의 신뢰할 수 있는 상태를 복원하는 일이다. 다른 하나는 에이전트의 행동으로 영향을 받은 리소스를 식별하고 복구하는 일이다.

회사는 두 작업 모두에 기존 데이터 보호 메커니즘을 사용하고 있다. 여기에는 스냅샷, 불변 백업, 그리고 흔히 클린룸이라고 불리는 격리된 복구 환경이 포함된다.

클린룸은 시스템을 즉시 프로덕션 환경에 다시 연결하지 않고 검사하고 복원하기 위한 분리된 환경이다. 대응팀은 복구된 구성 요소가 여전히 침해 상태인지 점검할 여지를 얻는다.

회사는 또한 각 에이전트를 해당 메모리, 애플리케이션, 데이터베이스 및 지원 인프라와 연결하는 에이전트 토폴로지를 설명한다. 이 관계 맵은 보호 공백을 보여주고 신뢰할 수 있는 복구에 필요한 모든 요소를 식별하기 위한 것이다.

Cohesity Agent Resilience는 처음에는 Amazon Bedrock AgentCore와 Bedrock Agents를 지원한다. 일부 고객은 현재 사용할 수 있으며, 일반 제공은 2026년 말로 예정돼 있다. Microsoft Azure와 Google 플랫폼은 로드맵에 남아 있다.

이러한 제한은 범용 에이전트 복구 계층이 아니라 집중된 첫 출시라는 점을 보여준다. Cohesity는 서로 다른 클라우드, 에이전트 프레임워크, 메모리 시스템, 권한 구조 전반에서 이 모델이 작동한다는 점을 입증해야 한다.

그럼에도 이번 발표는 복구 경계를 바꾼다. 백업 플랫폼은 전통적으로 데이터와 애플리케이션을 보호했다. Cohesity는 에이전트의 운영 메모리가 프로덕션 활동을 직접 형성할 수 있으므로 이 경계 안에 포함돼야 한다고 주장한다.

보도된 출시 세부 사항과 로드맵은 원문 에이전트 복원력 보도에도 문서화돼 있다. 핵심 개념은 간단하다. 기업에는 에이전트가 건드린 자산뿐 아니라 행위자 자체도 복구할 방법이 필요하다.

AI 에이전트는 기존 복구 계획에 압박을 가한다

AI 에이전트는 하나의 침해된 결정이 여러 연결 시스템으로 전파될 수 있기 때문에 사고 표면을 넓힌다.

기존 복구 계획은 일반적으로 팀이 손상된 워크로드를 식별하고, 깨끗한 복사본을 복원하며, 그 결과 환경을 검증할 수 있다고 가정한다. AI 에이전트는 컨텍스트를 보유하고 애플리케이션 경계를 넘어 행동하기 때문에 이 순서를 복잡하게 만든다.

티켓, 고객 기록, 지식 저장소에 접근할 수 있는 내부 지원 에이전트를 생각해 보자. 손상된 지시는 이 에이전트가 정보를 공개하거나, 분류를 변경하거나, 여러 시스템에 잘못된 내용을 기록하게 할 수 있다.

티켓 데이터베이스를 복원하면 삭제된 기록은 되살릴 수 있다. 하지만 에이전트 메모리에서 침해된 지시를 제거하지는 못하며, 어떤 후속 행동을 되돌려야 하는지도 보여주지 않는다.

같은 문제는 소프트웨어 운영에서도 나타난다. 구성을 수정하고, 배포 요청을 생성하거나, 클라우드 리소스를 관리할 수 있는 에이전트는 유효하게 인증됐지만 유해한 변경의 연쇄를 만들어낼 수 있다.

이런 행동은 일반적인 침입처럼 보이지 않을 수 있다. 에이전트는 오염된 컨텍스트나 잘못된 구성에서 작동하면서도 합법적인 자격 증명과 승인된 인터페이스를 사용할 수 있다.

이 때문에 Cohesity는 AI 에이전트 복구를 모니터링 문제에만 국한하지 않고 복원력 문제로 규정한다. 모니터링은 행동을 기록한다. 복구는 신뢰할 수 있는 시점을 설정하고 그 시점 이후 손상된 시스템을 복원한다.

Cohesity의 최고제품책임자 Vasu Murthy는 이 공백을 직접 요약했다. 탐지는 에이전트가 경로를 이탈했다는 사실을 보여줄 수 있지만, 변경 사항을 되돌릴 수는 없다는 것이다. 이 주장은 회사가 상태와 종속성을 모두 보호하는 이유를 설명한다.

압박은 우선 보안 및 인프라 팀에 가해진다. 이들은 어떤 에이전트 메모리가 중요한지, 얼마나 자주 캡처할지, 연결된 리소스 전반에서 복구를 어떻게 조율할지 결정해야 한다.

AI 엔지니어링 팀도 관련 부담을 안게 된다. 보호 시스템이 에이전트 버전, 구성, 메모리 저장소, 권한 및 외부 종속성을 식별할 수 있도록 충분한 정보를 노출해야 한다.

애플리케이션 소유자 역시 복구 체인에 들어온다. 데이터베이스, ID 제어 또는 비즈니스 애플리케이션이 불일치 상태로 남아 있다면, 깨끗한 에이전트 복원은 가치가 제한적이다.

조직적 문제는 스토리지 문제보다 더 어려워질 수 있다. 서로 다른 팀이 에이전트, 모델 접근 권한, 기반 데이터, 연결된 각 애플리케이션을 각각 소유할 수 있기 때문이다.

Cohesity의 토폴로지 개념은 사고 전에 이러한 관계를 가시화하려는 시도다. 최신 종속성 맵은 대응팀에 조사해야 할 시스템과 일관성을 유지하는 복구 순서를 알려줄 수 있다.

이 매핑은 복구 시간 목표와 복구 시점 목표도 지원한다. RTO는 서비스가 얼마나 빠르게 복귀해야 하는지를 정의하고, RPO는 조직이 최근 상태를 어느 정도까지 잃을 수 있는지를 정의한다.

에이전트에서는 이러한 측정 기준이 더 불명확해진다. 어제의 메모리를 복원하면 유용한 컨텍스트가 사라질 수 있고, 오늘의 메모리를 복원하면 사고를 일으킨 손상이 보존될 수 있다.

따라서 팀에는 지속적인 지식과 일시적인 상태를 구분하는 정책이 필요하다. 또한 어떤 에이전트 행동을 자동으로 되돌릴 수 있고, 어떤 행동에 비즈니스 검토가 필요한지도 결정해야 한다.

Cohesity의 제안은 다른 백업 공급업체에도 압박을 만든다. 고객들은 복구 계획이 이처럼 넓어진 시스템 경계를 따라가기를 기대할 것이기 때문이다. 자율 소프트웨어가 둘 다 수정할 수 있게 되면 파일이나 워크로드만 보호하는 방식은 불완전해 보인다.

이 문제는 고도로 자율적인 에이전트를 도입하지 않은 기업에도 영향을 미친다. 제한적인 에이전트조차 요약을 작성하고, 기록을 분류하고, 도구를 호출하거나, 이후 의사결정에 영향을 주는 워크플로를 촉발할 수 있다.

따라서 에이전트 복원력은 완전 자율 시스템에만 필요한 것이 아니다. 핵심 기준은 소프트웨어가 모든 행동을 사람과 검토하지 않고도 상태를 보존하거나 중요한 변경을 할 수 있는지 여부다.

새로운 경쟁은 Cohesity AI 에이전트 복구와 분절된 제어 간의 대결이다

시장 경쟁은 단순히 Cohesity와 다른 공급업체 간의 대결이 아니라, 통합된 AI 에이전트 복구와 분리된 모니터링·백업·애플리케이션 제어 간의 대결이다.

기업은 이미 에이전트 위험의 일부를 다루는 도구를 보유하고 있다. 관측성 시스템은 추적 데이터를 수집하고, ID 플랫폼은 접근 권한을 관리하며, 애플리케이션 로그는 변경을 기록하고, 백업 제품은 데이터를 보존한다.

복구 문제는 이 계층들 사이에서 발생한다. 사고 대응팀은 의심스러운 에이전트 세션을 식별할 수는 있지만, 그 메모리와 영향을 받은 모든 종속성을 함께 복원할 조율된 방법은 여전히 부족할 수 있다.

Cohesity는 자사의 데이터 플랫폼을 그 조율 계층으로 만들고자 한다. 기존 스냅샷과 불변 복사본을 활용하면서 에이전트 토폴로지와 상태에 대한 지식을 추가할 수 있다.

이 접근법은 기존 백업 공급업체에 자연스러운 진입점을 제공한다. 이 회사는 이미 많은 고객의 복구 복사본과 격리 환경을 관리하고 있다.

그러나 기존 인프라가 에이전트의 의미론까지 자동으로 해결하는 것은 아니다. 플랫폼은 어떤 메모리 항목, 구성 파일, 프롬프트, 도구, 자격 증명 및 애플리케이션 변경이 특정 복구 시점에 속하는지 알아야 한다.

경쟁사들은 서로 다른 방향에서 같은 문제로 이동하고 있다. Rubrik의 AgentCloud는 에이전트 운영, 거버넌스, 관측성, 그리고 의도하지 않은 행동을 되감는 기능을 강조한다.

Rubrik은 또한 Model Context Protocol, 즉 MCP를 통해 고객 에이전트에 자사의 사이버 복원력 데이터를 개방하고 있다. MCP는 AI 시스템이 정의된 제어 아래 외부 도구와 데이터에 접근할 수 있도록 하는 표준 인터페이스다.

이 전략은 에이전트가 복구 정보를 바탕으로 추론하고 통제된 워크플로를 시작할 수 있게 한다. 최근 MCP 통합 세부 사항은 복구 플랫폼이 더 광범위한 AI 시스템 내에서 호출 가능한 구성 요소로 얼마나 빠르게 변하고 있는지를 보여준다.

Commvault는 연결된 환경 전반에서 에이전트를 발견하고 종속성을 목록화하도록 설계된 AI Protect를 발표했다. 계획된 기록 항목에는 모델, 구성, 데이터 소스, 애플리케이션 및 인프라가 포함된다.

Druva는 에이전트 보호, 에이전트를 통한 백업 정보 접근, 의심되는 AI 공격에 대한 자동화된 대응을 설명했다. 이는 에이전트 복구와 에이전트 지원 조사를 결합한다.

이러한 접근법은 겹치지만 각각 서로 다른 제어 지점을 강조한다. Cohesity는 복구 가능한 상태와 연결된 리소스에 초점을 둔다. Commvault는 반복적인 발견을 강조한다. Druva는 보호와 보안 조사를 결합하며, Rubrik은 거버넌스와 되돌릴 수 있는 운영을 연결한다.

고객은 각 플랫폼이 에이전트 종속성을 얼마나 깊이 이해하는지 살펴봐야 한다. 구성을 캡처하지만 후속 리소스를 매핑하지 않는 제품은 문제의 절반만 해결한다.

또한 프레임워크 적용 범위도 검토해야 한다. Cohesity의 AWS Bedrock 초기 지원은 명확한 통합 표면을 제공하지만, 많은 기업은 맞춤형 프레임워크와 혼합 클라우드 서비스를 사용해 에이전트를 구축한다.

복구 플랫폼은 모든 에이전트를 한 공급업체의 오케스트레이션 모델에 강제하지 않으면서 이러한 환경을 처리해야 한다. 개방형 인터페이스는 도움이 될 수 있지만, 관리자가 관리해야 하는 권한과 보안 관련 결정도 확대한다.

경쟁 압력은 세 가지 역량을 연결하는 공급업체에 유리하게 작용할 가능성이 높다. 이들은 에이전트 관계를 발견하고, 신뢰할 수 있는 버전을 보존하며, 종속 시스템 전반에서 일관된 복구를 조율해야 한다.

아직 어떤 공급업체도 이것이 엔터프라이즈 에이전트 스택 전반에서 보편적으로 작동할 수 있음을 입증하지 못했다. 제품 발표는 방향성을 제시하지만, 통합 복구가 분산된 통제 방식보다 우수한지는 실제 운영 환경의 증거가 결정할 것이다.

Cohesity의 강점은 기존 복구 기반에 있다. 과제는 안전한 복원을 지원할 만큼 정밀하게 지속적으로 변화하는 에이전트 상태를 그 기반이 표현할 수 있음을 입증하는 것이다.

자율형 사이버 회복탄력성도 여전히 인간의 판단에 의존한다

Cohesity의 자동화 계획은 반복 업무를 줄일 수 있지만, 안전한 복구에서 무엇을 보존해야 하는지 결정할 필요까지 없애지는 못한다.

Cohesity는 Cohesity Agent Resilience와 함께 Autonomous Cyber Resilience라는 더 폭넓은 비전도 제시했다. 이 비전은 에이전틱 워크플로를 활용해 5단계 회복탄력성 프레임워크의 일부를 자동화한다.

이 단계는 보호, 복구 가능성, 위협 제거, 복구 훈련, 데이터 및 AI 위험 태세의 지속적 개선을 다룬다. 제안된 시스템은 자산을 지속적으로 발견하고, 보호 수준을 평가하며, 복구 준비 상태를 검증하고, 계획을 업데이트한다.

Cohesity는 관리자가 Cohesity Copilot을 통해 비즈니스 목표를 설정하는 워크플로를 설명한다. 이후 플랫폼은 관련 워크로드를 평가하고 보호 정책, 위협 스캔, 복구 리허설을 권고한다.

실행에 앞서 사람은 이러한 권고를 승인하게 된다. 사고 발생 시 관리자는 영향을 평가하고, 공격자 활동의 지표를 찾고, 격리된 복구 환경을 준비하는 자동화 워크플로를 시작할 수 있다.

이 모델은 완전 자율형 위협 대응보다 더 신중하다. 발견, 분석, 준비, 오케스트레이션은 소프트웨어에 맡기되 승인은 인간 운영자가 유지한다.

이 경계는 복구 결정에 상충하는 목표가 수반되기 때문에 중요하다. 가장 빠르게 이용 가능한 복원 지점은 손상된 상태를 보존할 수 있다. 더 오래된 복원 지점은 위협을 제거할 수 있지만 최근 거래를 잃게 할 수 있다.

에이전틱 워크플로는 증거를 수집하고 선택지를 시험할 수 있지만, 조직에는 여전히 그러한 결과 사이에서 선택할 책임 있는 사람이 필요하다. 올바른 선택은 비즈니스 우선순위와 사고 맥락에 따라 달라진다.

Cohesity는 이 모델이 이미 사고 대응과 복구의 일부를 조율하는 RecoveryAgent를 기반으로 한다고 말한다. 또한 회복탄력성 기능을 외부 AI 도구에 연결하는 인터페이스 계층인 Cohesity Maestro를 확장할 계획이다.

회사는 Maestro가 Claude, ChatGPT, Gemini 및 Helios 관리 콘솔을 포함한 시스템과 연동될 것으로 예상한다. Cohesity는 이미 Claude workflows가 MCP와 에이전트 스킬을 통해 자사의 회복탄력성 인텔리전스에 접근할 수 있는 방식을 설명했다.

이러한 통합은 유용한 유연성을 제공한다. 보안 팀은 이미 사고를 조사하는 AI 환경에서 복구 정보에 접근할 수 있다.

동시에 또 다른 통제 표면도 만들어 낸다. 복구 데이터를 조회하거나 작업을 준비할 수 있는 모든 에이전트에는 엄격하게 범위가 제한된 권한, 신뢰할 수 있는 ID, 포괄적인 로깅, 검토 가능한 출력이 필요하다.

침해된 자동화 시스템이 프로덕션 자산과 그 복구 사본 모두에 무제한으로 접근해서는 안 된다. 에이전트가 프로세스를 조율하더라도 직무 분리는 여전히 중요하다.

자율형 사이버 회복탄력성이라는 표현은 서로 다른 자동화 수준을 감출 수도 있다. 자동 자산 발견은 프로덕션 애플리케이션의 자동 복원보다 운영상 위험이 낮다.

정책 권고는 그 중간 지점에 해당한다. 행정 업무를 줄일 수 있지만, 팀이 전제를 이해하지 못한 채 승인하면 부실한 권고는 중대한 결과를 초래한다.

Cohesity의 현재 automation tutorial은 기본 기능이 이미 데이터 발견과 지속적인 보호 결정을 연결하고 있음을 보여준다. 더 폭넓은 상용 자동화는 점진적으로 도입될 것이다.

이 단계적 접근은 각 수준에서 시스템에 증거가 필요하므로 타당하다. 발견 정확도, 정책 품질, 클린룸 준비, 복구 일관성은 각각 별도로 측정해야 한다.

가장 큰 불확실성은 에이전트가 복구 단계를 실행할 수 있는지 여부가 아니다. 자동화 소프트웨어는 수년간 인프라 작업을 조율해 왔다.

불확실성은 애플리케이션과 에이전트가 변화하는 동안 플랫폼이 비즈니스 종속성의 충분히 정확한 모델을 유지할 수 있는지에 있다. 오래된 토폴로지는 기술적으로는 성공했지만 운영상으로는 불완전한 복구를 초래할 수 있다.

사람의 승인이 이 위험을 없애지는 않는다. 검토자는 워크플로가 무엇을 발견했는지, 무엇을 제외했는지, 어떤 복구 지점을 선택했는지, 얼마나 확신하는지를 명확히 설명받아야 한다.

자율형 사이버 회복탄력성은 이러한 판단을 검사 가능하게 만들 때 신뢰를 얻을 수 있다. 사고 중에는 속도가 중요하지만, 설명되지 않는 속도는 피해를 키울 수 있다.

Cohesity Agent Resilience가 아직 입증하지 못한 것

이번 발표는 신뢰할 수 있는 복구 모델을 제시하지만, 실제 운영 환경에서의 적용 범위와 측정 가능한 복구 결과는 아직 검증되지 않았다.

첫 번째 한계는 가용성이다. 현재 일부 고객은 Cohesity Agent Resilience를 사용할 수 있지만, 광범위한 제공은 2026년 말로 목표가 설정되어 있다.

통제된 출시 방식은 Cohesity가 에이전트 발견 및 복구를 개선하는 데 도움이 될 수 있다. 하지만 대부분의 잠재 고객은 아직 이 제품을 전체 프로덕션 환경과 비교할 수 없다는 의미이기도 하다.

두 번째 한계는 플랫폼 범위다. 초기 지원은 Amazon Bedrock AgentCore와 Bedrock Agents에 집중되어 있으며, Azure 및 Google 환경은 아직 계획 단계에 있다.

엔터프라이즈 에이전트는 여러 서비스에 걸쳐 있는 경우가 많다. 에이전트는 한 클라우드에서 실행되고, 다른 플랫폼에서 문서를 검색하며, SaaS 애플리케이션을 호출하고, 외부 데이터베이스에 메모리를 저장할 수 있다.

지원되는 부분만 복구하면 상태 불일치가 발생할 수 있다. Cohesity는 이 체인의 일부가 직접 통제 범위 밖에 있을 때 토폴로지와 복원이 어떻게 작동하는지 보여줘야 한다.

세 번째 한계는 복구 세분성에 관한 것이다. 에이전트 상태에는 프롬프트, 단기 메모리, 장기 메모리, 도구 정의, 모델 설정, 액세스 정책, 외부 레코드가 포함될 수 있다.

모든 구성 요소가 같은 시점으로 돌아가야 하는 것은 아니다. 일부 레코드는 사고 시작 이후에도 유효할 수 있지만, 오염된 메모리 항목 하나가 실제 원인일 수 있다.

전체 상태 번들을 복원하면 정당한 작업이 제거될 수 있다. 지나치게 좁게 복원하면 침해 상태가 그대로 남을 수 있다.

Cohesity는 이러한 시나리오에 대한 상세한 성능 결과를 공개적으로 제공하지 않았다. 구매자는 발견 정확도, 복원 시간, 애플리케이션 일관성, 필요한 수동 조정 작업량에 관한 증거를 요구해야 한다.

공유 종속성을 시스템이 어떻게 처리하는지도 물어야 한다. 두 에이전트가 동일한 데이터베이스에 쓰거나 동일한 메모리 저장소를 사용할 수 있어 개별 복구가 어려워질 수 있다.

ID는 또 다른 미해결 문제를 제기한다. 에이전트를 깨끗한 구성으로 되돌린다고 해서 침해된 토큰이 반드시 폐기되거나 지나치게 넓은 권한이 수정되는 것은 아니다.

완전한 복구 프로세스는 ID 및 액세스 시스템과 조율되어야 한다. 그렇지 않으면 복원된 에이전트가 문제를 가능하게 했던 동일한 경로를 물려받을 수 있다.

네 번째 한계는 자동화된 권고에 관한 것이다. Cohesity는 플랫폼이 태세를 평가하고 정책, 스캔 전략, 복구 리허설 계획을 제안할 수 있다고 말한다.

이러한 출력은 고객이 실제 사고와 복잡한 애플리케이션 환경에서 검증하기 전까지는 회사의 주장일 뿐이다. 구매자는 자동화를 그 자체로 결과로 간주하기보다 권고의 품질을 평가해야 한다.

Cohesity 자체 연구는 시급성을 더하지만 제품을 검증하지는 않는다. 회사의 다섯 번째 연례 사이버 회복탄력성 보고서에 따르면, 설문 대상 조직의 78%는 비즈니스 운영 유지보다 시스템 복원에 복구 노력을 집중한다.

이 수치는 기술적 복원이 충분하지 않을 수 있다는 회사의 주장을 뒷받침한다. 그러나 Agent Resilience나 자율형 워크플로가 그 격차를 해소한다는 것을 보여주지는 않는다.

시스템 복구와 비즈니스 복구의 구분은 여전히 유용하다. 복원된 애플리케이션은 운영을 재개하기 전에 ID 서비스, 최신 데이터, 직원 액세스 및 다른 애플리케이션에 의존할 수 있다.

Cohesity는 Catalyst event에서 이 문제를 강조하며, 고립된 인프라가 아니라 최소 실행 가능한 비즈니스를 복원하는 관점에서 복구를 설명했다.

이 프레이밍은 적절한 기준을 제시한다. 고객은 스냅샷이 성공적으로 마운트되었는지가 아니라 신뢰할 수 있는 비즈니스 프로세스가 재개되는지를 기준으로 에이전트 복구를 판단해야 한다.

다섯 번째 한계는 책임성이다. 자동화 워크플로가 잘못된 복원 순서를 권고할 경우, 조직은 왜 그러한 선택을 했는지와 누가 승인했는지에 대한 기록을 보유해야 한다.

거버넌스는 사람의 승인 버튼에서 멈춰서는 안 된다. 특히 사고 압박이 신속한 행동을 부추길 때, 검토자는 승인이 의미 있으려면 충분한 맥락을 알아야 한다.

이러한 질문 중 어느 것도 Cohesity의 방향성을 무효화하지 않는다. 이는 그럴듯한 아키텍처에서 신뢰할 수 있는 운영 시스템으로 나아가기 위해 필요한 증거를 정의한다.

전략의 성과를 보여줄 세 가지 신호

Cohesity의 전략은 플랫폼 적용 범위, 검증된 복구 결과, 자동화에 설정된 경계를 통해 평가해야 한다.

첫 번째 신호는 2026년 말까지 일반 제공을 실현하는 것이다. 해당 출시에는 보호되는 상태, 종속성 발견, 복원 순서 지정, 지원되지 않는 구성에 대한 명확한 문서가 포함되어야 한다.

더 폭넓은 클라우드 지원은 일정만큼 중요하다. Microsoft 및 Google 통합의 진전은 Cohesity가 엄격히 통제된 AWS 구현을 넘어 확장할 수 있음을 보여줄 것이다.

출시가 지연되거나 프레임워크 적용 범위가 제한된다면, 플랫폼이 엔터프라이즈 에이전트를 위한 범용 복구 계층이 될 수 있다는 주장은 약화될 것이다.

두 번째 신호는 고객 증거다. Cohesity는 연결된 애플리케이션과 데이터가 일관성을 유지하는 상태에서 에이전트가 신뢰할 수 있는 상태로 돌아가는 사례를 제시해야 한다.

유용한 증거에는 복구 시간, 발견된 종속성 수, 실패하거나 불완전한 복원 사례, 이후 필요한 수동 작업이 포함될 것이다.

가장 강력한 증거는 준비된 데모가 아닌 현실적인 사고에서 나올 것이다. 구성 손상, 오염된 메모리, 과도한 권한, 의도하지 않은 다운스트림 쓰기는 서로 다른 복구 과제를 만들어야 한다.

고객은 반복적인 훈련도 살펴봐야 한다. 한 번 성공한 복구보다 에이전트와 애플리케이션이 변화하는 과정에서도 시스템이 최신 상태를 유지함을 보여주는 정기 테스트가 더 많은 것을 말해준다.

세 번째 신호는 Cohesity가 자율형 사이버 회복탄력성을 어떻게 확장하는지다. 회사는 이 모델이 상용 제공에 가까워짐에 따라 자동화를 추가할 것이라고 말한다.

핵심 질문은 어떤 결정이 권고로 남고 어떤 결정이 실행 가능한 조치가 되는지다. 자동 발견과 클린룸 준비는 프로덕션 복원 지점을 자동으로 선택하는 것과 다르다.

투명한 승인 통제는 Cohesity의 주장을 강화할 것이다. 이러한 통제는 제안된 조치, 이를 뒷받침하는 증거, 예상 영향, 제외된 자산, 롤백 경로를 보여줘야 한다.

자율성이 감사 가능성보다 빠르게 진전되면 전략은 약화될 것이다. 복구 자동화는 책임을 흐리지 않으면서 대응 시간을 줄여야 한다.

경쟁사의 움직임은 이 세 가지 신호 모두에 추가적인 맥락을 제공할 것이다. Commvault, Druva, Rubrik이 에이전트 보호를 협소한 기능 범주로 방치할 가능성은 낮다.

이들의 대응은 토폴로지 매핑, 에이전트 되감기, 불변 상태, 개방형 통합에 대한 공통 기대치를 형성할 수 있다. 또한 Cohesity의 적용 범위에서 빈틈을 드러낼 수도 있다.

기업 구매자에게 실질적인 다음 단계는 현재 에이전트가 무엇을 변경할 수 있는지 목록화하는 일이다. 팀은 각 핵심 에이전트에 연결된 메모리 저장소, 자격 증명, 애플리케이션, 데이터베이스 및 인프라를 파악해야 한다.

이 과정을 통해 기존 백업 계획이 전체 운영 체인을 포괄하는지 확인할 수 있다. 또한 AI 에이전트 복구 제품이 ID, 애플리케이션 및 보안 제어 체계와 통합되어야 하는 지점도 드러난다.

내부 지식 워크플로를 구축하는 조직도 정보 의존성에 동일한 원칙을 적용해야 한다. 잘 관리되는 AI knowledge base는 어떤 원천 자료가 사람과 자동화된 의사결정을 이끄는지 팀이 이해하는 데 도움이 될 수 있다.

Cohesity Agent Resilience는 필수적인 변화를 시사한다. 복구 계획은 기억하고 행동하는 소프트웨어 행위자까지 고려해야 한다. 이제 이 제품의 성공 여부는 일관성, 맥락 또는 통제력을 잃지 않고 그러한 행위자를 복원할 수 있는지에 달려 있다.

복구를 자동화에 맡기기 전에 한 가지 구체적인 질문을 던져야 한다. 시스템이 무엇을 복원하고, 무엇을 그대로 두며, 그 이유가 무엇인지 정확히 설명할 수 있는가? 답이 불완전하다면 인간 승인 절차를 확고히 유지해야 한다.