Veeam DataAI, 에이전트 신뢰를 복구 계층으로 옮겼다

AI 요약

• 무슨 일: Veeam이 DataAI Command Platform을 공개하며 데이터, ID, AI 에이전트, 백업을 하나의 신뢰 계층으로 묶겠다고 발표했습니다.
  • Securiti AI 인수 자산과 Veeam의 복구 역량을 결합한 플랫폼으로, VeeamON NYC에서 2026년 5월 12일 발표됐습니다.
• 의미: 에이전트 거버넌스가 런타임 통제와 로그 수집을 넘어 data source와 backup graph로 내려가고 있습니다.
• 실무 영향: 에이전트가 민감 데이터를 잘못 읽거나 변경했을 때, 기업은 차단뿐 아니라 영향 범위 파악과 정밀 복구까지 설계해야 합니다.
• 주의점: Veeam의 82:1 에이전트/직원 비율, 97% 과도 권한 같은 수치는 벤더 발표 맥락이므로 적용 범위와 산식을 확인해야 합니다.

Veeam이 AI 에이전트 시장에 들어오는 방식은 조금 다릅니다. 최근 에이전트 발표 대부분은 더 나은 모델, 더 긴 작업 시간, 더 많은 도구 호출, 더 편한 IDE 통합을 말합니다. Honeycomb은 에이전트가 프로덕션에서 무엇을 했는지 보는 타임라인을 강조했고, Endor Labs는 코딩 에이전트의 명령 실행과 패키지 설치를 보안 통제 대상으로 삼았습니다. UiPath는 코딩 에이전트가 만든 자동화를 엔터프라이즈 배포와 거버넌스 안으로 끌어들이려 했습니다.

Veeam의 DataAI Command Platform 발표는 같은 문제를 보지만, 시선이 데이터와 복구 계층에 있습니다. 핵심 질문은 "에이전트가 무엇을 했는가"만이 아닙니다. 에이전트가 어떤 데이터에 접근할 수 있었는지, 그 데이터가 민감했는지, 누가 같은 데이터에 접근할 수 있는지, 어떤 변경이 실제 위험을 만들었는지, 문제가 생기면 전체 시스템을 되감지 않고 어디까지 복구할 수 있는지입니다.

이 차이는 중요합니다. 에이전트 보안은 지금까지 주로 런타임 경계에서 이야기됐습니다. 어떤 tool을 허용할 것인가, shell 실행을 막을 것인가, 네트워크 접근을 제한할 것인가, 승인 없이는 어떤 명령을 실행하지 못하게 할 것인가 같은 질문입니다. 당연히 필요합니다. 하지만 에이전트가 실제 기업 데이터 위에서 움직이기 시작하면 런타임 경계만으로는 충분하지 않습니다. 민감 데이터는 SaaS, 파일 저장소, 데이터베이스, 백업, 메일함, 협업 문서, 로그 아카이브에 흩어져 있습니다. 에이전트는 이 경계를 가로지릅니다.

Veeam은 신뢰 지점을 데이터 원천으로 옮깁니다

Veeam은 이번 발표에서 DataAI Command Platform을 "Data, Access, Identities, AI"가 만나는 단일 trust layer라고 설명합니다. 제품의 기반은 DataAI Command Graph입니다. 공식 발표는 이 그래프가 클라우드, SaaS, 온프레미스 전반의 300개 이상 커넥터를 통해 어떤 데이터가 어디에 있고, 누가 접근하며, 어떤 변경이 위험 조건을 만들었는지 granular하게 이해한다고 말합니다.

기존 데이터 보호 제품에서 그래프라는 말은 흔합니다. 그러나 Veeam이 이 발표에서 강조하는 지점은 운영 데이터와 백업 데이터를 동시에 본다는 부분입니다. 보안 도구는 종종 현재 시스템의 권한과 노출을 봅니다. 백업 도구는 복구 가능한 사본을 봅니다. 에이전트 시대에는 두 시야가 분리되면 문제가 생깁니다. 에이전트가 실수로 데이터를 바꾸거나, 민감 데이터를 잘못 공유하거나, 자동화가 대량 변경을 일으켰을 때 현재 상태만 보면 복구 경로가 늦고, 백업만 보면 왜 그 변경이 위험한지 맥락이 부족합니다.

그래서 Veeam의 주장은 "agent governance를 agent에만 걸지 말자"에 가깝습니다. DataAI Governance는 정책 집행을 데이터 소스에서 수행한다고 설명됩니다. 승인된 에이전트든, 알 수 없는 에이전트든, rogue agent든 민감 데이터 접근 정책은 원천에서 강제되어야 한다는 뜻입니다. 이 접근은 프록시나 런타임 래퍼만으로 모든 에이전트를 포착하기 어렵다는 현실을 인정합니다. 기업 안에는 공식 Copilot, 커스텀 agent, SaaS 내장 agent, 자동화 스크립트, 실험용 워크플로가 동시에 존재합니다. 모든 실행 지점을 하나의 에이전트 런타임으로 통일하기는 어렵습니다.

여섯 개 기능은 하나의 운영 모델을 가리킵니다

Veeam 발표에는 기능 이름이 많습니다. DataAI Security, DataAI Governance, DataAI Compliance, DataAI Privacy, DataAI Precision Resilience, 그리고 이를 떠받치는 DataAI Command Graph입니다. 마케팅 이름을 걷어내면 구조는 비교적 명확합니다.

보안팀 관점에서 가장 흥미로운 부분은 DataAI Compliance입니다. Veeam은 EU AI Act, DORA, GDPR, HIPAA, NIST, AI RMF 등 100개 이상 프레임워크에 매핑된 auditable evidence를 만든다고 설명합니다. AI 거버넌스 논의는 종종 모델 카드, 정책 문서, 사용자 교육에서 멈춥니다. 하지만 규제와 감사는 결국 증거를 요구합니다. 어떤 데이터가 민감 데이터였는지, 누가 접근했는지, 어떤 정책이 적용됐는지, 예외가 있었는지, 문제가 생긴 뒤 어떤 복구가 수행됐는지 남아야 합니다.

AI 에이전트가 실제 업무를 처리할수록 이 증거는 더 중요해집니다. 사람이 실수하면 권한과 변경 이력, 승인 기록을 추적합니다. 에이전트도 마찬가지입니다. 차이는 속도와 규모입니다. 에이전트는 짧은 시간에 수많은 파일, API, SaaS 객체, 데이터베이스 행을 건드릴 수 있습니다. 실수의 단위가 작아 보이더라도 연쇄 효과는 큽니다. 그렇다면 거버넌스는 "실행 전에 막기"와 "실행 후 설명하기"를 넘어 "실행 후 정확히 되돌리기"까지 포함해야 합니다.

Intelligent ResOps는 복구를 AI 운영의 일부로 만듭니다

같은 날 Veeam은 Veeam Intelligent ResOps도 발표했습니다. 이 제품은 DataAI Command Platform 위에 올라가는 첫 resilience offering입니다. 발표문은 Microsoft 365를 첫 지원 워크로드로 두고, 이후 다른 워크로드를 추가한다고 설명합니다.

Microsoft 365가 첫 대상인 것은 자연스럽습니다. 기업의 민감한 문서, 메일, 회의 자료, 재무 파일, 고객 정보, 계약서, 운영 문서가 이 계층에 모입니다. 동시에 Copilot류 AI, 문서 요약, 메일 작성, 일정 조율, 에이전트 기반 업무 자동화가 가장 빠르게 침투하는 표면이기도 합니다. 여기서 사고가 나면 단순히 서버를 복원하는 문제가 아닙니다. 어떤 SharePoint 문서가 바뀌었는지, 어떤 메일함의 데이터가 잘못 삭제됐는지, 어떤 Teams 파일이 외부 공유됐는지, 어느 시점으로 되돌리는 것이 업무 피해를 최소화하는지 판단해야 합니다.

Veeam은 Intelligent ResOps가 데이터 context와 recovery를 통합한다고 말합니다. 중요한 표현은 "restore only what's impacted"입니다. 전통적인 복구는 넓은 단위로 되감는 경우가 많았습니다. 그러나 에이전트가 만든 문제는 넓은 롤백이 더 큰 사고를 만들 수 있습니다. 예를 들어 에이전트가 고객 계약서 30개에 잘못된 조항을 삽입했다면, 전체 문서 라이브러리를 되돌리는 것은 다른 정상 변경까지 날릴 수 있습니다. 필요한 것은 어떤 파일과 버전이 영향을 받았는지 찾아 해당 부분만 되돌리는 능력입니다.

이 지점에서 백업은 보험이 아니라 런타임 운영 계층이 됩니다. 에이전트가 더 많은 일을 할수록 복구 전략도 더 촘촘해져야 합니다. 단순히 "백업이 있다"가 아니라 "에이전트가 만든 변경을 원인, 영향 범위, 민감도와 함께 찾아 되돌릴 수 있다"가 되어야 합니다. Veeam은 바로 이 문장을 제품 카테고리로 만들려는 중입니다.

강한 수치는 조심해서 읽어야 합니다

Veeam 발표에서 가장 눈에 띄는 문장은 autonomous AI agents가 human employees를 82:1로 앞서고, 그중 97%가 과도한 권한을 가진다는 주장입니다. 또 agentic AI가 number one cyber threat라고 표현합니다. 뉴스 큐레이션 입장에서 이 수치는 그대로 받아쓰기보다 맥락을 붙여 읽어야 합니다.

첫째, 에이전트의 정의가 중요합니다. 기업 안에서 "agent"는 Copilot 같은 대화형 도구일 수도 있고, SaaS 내 자동화 bot일 수도 있고, RPA workflow일 수도 있고, API token으로 움직이는 서비스 계정일 수도 있습니다. 정의를 넓게 잡으면 사람보다 훨씬 많은 자동화 주체가 존재한다는 말은 이상하지 않습니다. 그러나 독자가 상상하는 "자율 AI 에이전트"와 벤더가 계수한 "non-human identity 또는 자동화 주체"가 같다고 보면 오해가 생깁니다.

둘째, 과도 권한도 산식이 필요합니다. 사람 계정에서도 least privilege는 오래된 숙제입니다. 서비스 계정, API key, CI token은 더 자주 과권한을 가집니다. AI 에이전트가 이 기존 문제를 악화시키는 것은 맞지만, 97%라는 숫자가 어떤 표본과 기준에서 나온 것인지는 확인해야 합니다. Veeam은 제품 문제를 선명하게 만들기 위해 강한 수치를 앞세웁니다. 그 수치를 방향성의 신호로 읽되, 그대로 모든 조직에 적용되는 평균처럼 받아들이면 안 됩니다.

성숙도 모델은 구매 설문보다 운영 체크리스트에 가깝습니다

Veeam의 Data and AI Trust Maturity Model도 같은 날 흐름 안에 있습니다. 이 페이지는 300명 이상 보안 리더 대상 조사에서 80%가 안전하게 AI를 확장할 자신이 있다고 답했지만, 52%는 문제 때문에 AI 이니셔티브를 축소했고, 68%는 AI audit에 완전히 준비되지 않았으며, 43%는 예산보다 talent를 주요 장벽으로 꼽았다고 설명합니다.

이 숫자는 제품 홍보 페이지의 일부이지만, 질문 자체는 실무적입니다. AI readiness는 모델 API를 붙였는지로 결정되지 않습니다. 민감 데이터 분류가 되어 있는지, 권한이 적절한지, 에이전트가 접근한 데이터와 산출물을 추적할 수 있는지, 문제가 생기면 복구할 수 있는지, 규제 감사에 낼 증거가 있는지가 더 중요합니다. 개발자와 플랫폼 팀에게도 이 관점은 필요합니다. 에이전트 앱을 만들 때 "정답률"이나 "응답 속도"만 보는 팀은 운영 단계에서 곧 막힙니다.

특히 RAG와 에이전트 제품은 데이터 신뢰 문제가 곧 제품 품질 문제입니다. 검색된 문서가 오래됐는지, 사용자가 볼 수 없는 문서를 retrieval했는지, 삭제 요청된 개인정보가 embedding과 백업 안에 남았는지, 에이전트가 임시 파일로 민감 정보를 남겼는지 같은 질문은 모델 벤치마크로 해결되지 않습니다. Veeam이 말하는 trust layer는 이런 데이터 운영 문제를 AI 시대 언어로 다시 포장한 것이기도 합니다.

Veeam의 차별점은 "되돌릴 수 있는 AI"입니다

에이전트 운영 시장은 빠르게 붐비고 있습니다. Microsoft Agent 365는 조직 안의 agent inventory와 정책을 말합니다. Endor AURI는 코딩 에이전트의 프롬프트, 명령, 파일 접근, 패키지 설치를 보안 대상으로 봅니다. Honeycomb은 에이전트 행동을 프로덕션 telemetry와 연결해 사건을 재구성하려 합니다. UiPath는 코딩 에이전트가 만든 자동화를 enterprise orchestration 안으로 넣으려 합니다.

Veeam의 차별점은 복구입니다. 물론 Veeam도 security, governance, privacy, compliance를 모두 말합니다. 하지만 이 회사가 가장 설득력 있게 말할 수 있는 부분은 "문제가 생긴 뒤 어디까지 되돌릴 수 있는가"입니다. AI 에이전트가 실제 시스템에 쓰기 권한을 갖는 순간, 기업은 실패를 전제로 설계해야 합니다. 좋은 prompt와 policy만으로는 부족합니다. 로그를 남겨도 되돌릴 수 없으면 사고 대응은 반쪽입니다. 반대로 영향 범위를 알고 정밀 복구할 수 있다면, 에이전트 도입의 위험 계산이 달라집니다.

개발팀 입장에서는 이 발표를 Veeam 제품 구매 뉴스로만 볼 필요가 없습니다. 더 중요한 것은 설계 원칙입니다. 에이전트가 데이터에 접근하는 제품을 만든다면, 최소한 다음 질문을 해야 합니다. 에이전트가 읽은 데이터와 근거를 추적할 수 있는가. 민감 데이터 접근 정책은 retrieval, tool call, downstream API에서 일관되게 적용되는가. 에이전트가 외부 시스템을 변경하면 변경 단위와 승인 경로가 남는가. 잘못된 변경을 사용자의 다른 정상 작업과 분리해 되돌릴 수 있는가. 감사 요청이 오면 사람이 읽을 수 있는 증거를 만들 수 있는가.

Veeam DataAI Command Platform은 아직 발표 직후의 제품입니다. 실제 품질은 커넥터 범위, Microsoft 365 외 워크로드 확장, 데이터 분류 정확도, 백업과 운영 데이터 그래프의 일관성, 정책 충돌 처리, 복구 시나리오에서 검증될 것입니다. 또 Veeam의 강한 시장 수치와 "industry first" 표현은 벤더 발표답게 신중히 읽어야 합니다.

그럼에도 이 뉴스의 방향은 분명합니다. AI 에이전트 신뢰는 채팅창이나 IDE 플러그인 안에서만 해결되지 않습니다. 에이전트가 기업 데이터를 읽고 쓰는 순간, 신뢰의 단위는 데이터 원천, ID, 접근 정책, 감사 증거, 백업, 복구로 내려갑니다. Veeam이 이번 발표로 말하는 것은 단순한 백업 제품 확장이 아닙니다. 에이전트 시대에는 "막을 수 있는가"만큼 "설명하고 되돌릴 수 있는가"가 중요해진다는 신호입니다.

출처

• Veeam Launches DataAI Command Platform
• Veeam DataAI Command Platform product page
• Veeam Intelligent ResOps announcement
• Veeam Data and AI Trust Maturity Model