AI Agent를 업무에 연결하면 문서나 대화 기록만 보관해서는 충분하지 않을 수 있습니다. Agent가 어떤 권한으로 움직였는지, 어떤 설정을 사용했는지, 이전 작업의 맥락을 무엇으로 기억하고 있었는지가 함께 있어야 장애 뒤에도 같은 방식으로 다시 운영할 수 있기 때문입니다.
Cohesity는 9월 16일 이런 문제를 겨냥한 Agent Resilience를 발표했습니다. 이름 그대로 기업이 운영하는 AI Agent의 복원력을 높이는 제품입니다. 단순히 Agent가 다루던 데이터를 백업하는 수준이 아니라, Agent를 정상 상태로 되돌리는 데 필요한 요소를 함께 파악하고 보호한다는 점이 특징입니다.
AI Agent는 데이터만 복구해서는 원래대로 돌아오지 않습니다
일반적인 시스템 백업은 파일, 데이터베이스, 서버 설정처럼 비교적 명확한 대상을 중심으로 합니다. 그러나 AI Agent는 실행 환경이 조금 다릅니다. 같은 모델을 다시 연결해도 이전과 같은 결과가 나오지 않을 수 있습니다.
Agent Resilience는 Agent의 Memory, Configuration, Credentials, Operational Context, 연결 데이터 등을 보호 대상으로 봅니다. Memory는 Agent가 이전 업무에서 참고한 기억이나 작업 맥락에 가깝고, Configuration은 동작 규칙과 설정입니다. Credentials는 외부 서비스와 사내 시스템에 접근할 때 쓰는 인증 정보입니다.
여기서 특히 중요한 것은 Operational Context입니다. Agent가 어떤 도구와 데이터에 연결돼 있었고, 어떤 조건에서 업무를 수행했는지에 관한 운영 맥락을 의미합니다. 파일만 되살린 뒤 담당자가 연결과 권한을 다시 하나씩 맞춰야 한다면, 실제 복구 시간은 길어질 수밖에 없습니다.
장애 복구보다 ‘같은 Agent’를 되살리는 접근입니다
문제가 생겼을 때 정상 상태의 Agent로 복구한다는 설명은 단순해 보이지만 기업 입장에서는 차이가 큽니다. 예를 들어 고객 문의를 분류하고 내부 지식 문서를 찾아 답변 초안을 만드는 Agent가 있다고 가정해보겠습니다. 데이터만 남아 있어도 권한, 연결 대상, 운영 규칙이 빠지면 실무자는 다시 검증 작업을 해야 합니다.
AI Agent가 늘어날수록 이 부담은 커집니다. 누가 어떤 Agent를 만들었는지, 어디까지 접근하도록 허용했는지, 변경 전 상태로 되돌릴 수 있는지를 관리하지 못하면 AI 도입의 편리함보다 운영 위험이 먼저 커질 수 있습니다.
AWS Bedrock부터 지원, 플랫폼 확대도 예고했습니다
현재 Agent Resilience는 Amazon Web Services Bedrock을 지원합니다. AWS 환경에서 Bedrock 기반 Agent를 운영하거나 도입을 검토하는 기업이라면 직접적인 대상입니다. Cohesity는 Microsoft와 Google 플랫폼 지원도 예정하고 있다고 밝혔습니다.
다만 지원 예정이라는 말만으로 기존 Agent 운영 환경 전체가 바로 보호되는 것은 아닙니다. 실제 도입 전에는 사용 중인 Agent 프레임워크와 연결 서비스가 어디까지 대상인지, 인증 정보와 민감 데이터의 보관 방식은 어떻게 되는지 확인할 필요가 있습니다. 백업 제품이라고 해서 권한 관리 문제까지 자동으로 해결해주는 것은 아닙니다.
AI Agent 도입 기업이 확인할 질문
AI Agent를 아직 실험 단계로 쓰고 있다면 별도 복구 체계가 과할 수도 있습니다. 하지만 고객 정보, 사내 문서, 업무 시스템을 연결해 실제 업무를 맡기기 시작했다면 이야기가 달라집니다. 이때는 “대화 기록이 남는가”보다 “장애 뒤에 검증된 상태로 되돌릴 수 있는가”를 봐야 합니다.
Agent가 업무 인프라로 자리 잡을수록 백업의 대상도 넓어집니다. Cohesity의 이번 발표는 AI Agent를 하나의 기능이 아니라 운영하고 보호해야 할 기업 시스템으로 보기 시작했다는 점에서 의미가 있습니다.
