Broadcom VCF 확장, AI·보안·복구를 하나의 플랫폼으로 통합

Broadcom은 11월 4일 프라이빗 AI 인프라, 보안, 복구 관련 변경 사항과 소규모 가상화 제품을 결합한 최신 포트폴리오 확장을 발표했다. Broadcom VCF 확장은 프라이빗 클라우드 소프트웨어 플랫폼인 VMware Cloud Foundation 내부로 더 많은 엔터프라이즈 책임을 가져온다. 그러나 이번 발표는 기존 기능, 향후 출시 항목, 별도의 고급 서비스를 아우른다. 고객이 무엇을 배포할 수 있고 무엇을 추가로 구매해야 하는지 판단할 때 이러한 구분은 중요하다.

핵심적인 트레이드오프는 운영 통합에 있다. 인프라를 공유하면 중복 관리 업무를 줄일 수 있지만, 접근 권한, 유지보수, 복구에 관한 의사결정도 한곳에 집중된다. 엔터프라이즈 구매자는 더 광범위한 플랫폼이 실제 운영 환경을 단순화하는지 평가해야 한다. 더 긴 기능 목록만으로는 이 질문에 답할 수 없다.

Nutanix는 인프라와 엔터프라이즈 AI 관리를 함께 제공한다는 점에서 유용한 경쟁 기준을 제시한다. 따라서 Broadcom의 발표는 기업이 기존 애플리케이션과 함께 AI를 운영하는 방식을 둘러싼 더 큰 경쟁의 일부다. 인프라 리더에게 당면한 결정은 공유 플랫폼 안에서 어느 정도까지 책임을 통합할 것인가에 관한 것이다.

Broadcom VCF 확장이 실제로 바꾸는 것

이번 발표는 제품 제공, 향후 개발, 포트폴리오 패키징을 결합하며, 각각 다른 배포 결정을 요구한다.

Broadcom의 프라이빗 클라우드 업데이트는 이미 제공된 기능과 2027 회계연도 1분기에 추가될 예정인 항목을 구분한다. 멀티테넌트 모델 공유는 VCF 9.1.1에 도입됐으며, 기밀 컴퓨팅은 VCF 9.1에 포함됐다. 기밀 컴퓨팅은 지원되는 하드웨어를 통해 처리 중인 데이터를 보호한다.

예정된 추가 기능에는 AI Infrastructure Quickstart, 네이티브 S3 호환 객체 스토리지, 인프라 컴플라이언스 관리, 정책 기반 연결성, 네이티브 재해 복구가 포함된다. Quickstart는 초기 AI 인프라 설정을 자동화하기 위한 기능이다. S3 호환성은 파일과 모델 아티팩트 같은 객체를 저장하고 검색하기 위한 인터페이스를 뜻한다.

Broadcom은 고급 서비스 포트폴리오 내에 HyperArmor, Live Recovery, 워크로드 컴플라이언스 관리도 포함한다고 밝혔다. 이러한 제품은 네이티브 인프라 기능과 목적이 다르다. 구매자는 계약에 실제로 어떤 기능이 포함되는지 확인해야 하므로, 이들의 배치 방식은 중요하다.

실질적인 결과는 헤드라인이 암시하는 것보다 더 복잡한 출시 평가가 필요하다는 점이다. 인프라 관리자는 발표된 모든 기능을 즉시 사용할 수 있다고 간주할 수 없다. 보안 팀 역시 고급 서비스가 자동으로 배포 환경의 일부가 된다고 가정해서는 안 된다.

유용한 평가는 제공 상태와 아키텍처적 관련성을 분리한다. 어떤 기능은 기업의 요구에 관련성이 있을 수 있지만 현재 배포 일정에는 적합하지 않을 수 있다. 반대로 이미 사용할 수 있는 기능도 하드웨어 변경, 인력 준비 또는 추가 검증이 필요할 수 있다.

이 구분은 팀이 조달 마감일을 중심으로 프로젝트를 구성할 때 특히 중요해진다. 발표는 공급업체의 방향성을 제시한다. 릴리스 문서는 관리자가 무엇을 설치할 수 있는지 규정하고, 계약 문구는 조직이 무엇을 사용할 수 있는지 정한다.

Broadcom VCF 확장은 인프라 자동화와 해당 인프라를 관리하기 위한 통제를 함께 결합한다. 이들은 서로 관련된 투자이지만 해결하는 문제는 다르다. 더 빠른 배포는 팀이 환경을 구축하는 데 도움이 되지만, 거버넌스는 환경이 마련된 후 무엇을 안전하게 할 수 있는지를 결정한다.

예를 들어 클러스터 설정을 자동화한다고 해서 어떤 부서가 기밀 문서에 접근할 수 있는지 결정되는 것은 아니다. 스토리지를 제공한다고 해서 보존 정책이 수립되는 것도 아니다. 복구 오케스트레이션을 추가한다고 해서 사고 이후 어떤 애플리케이션을 먼저 복구해야 하는지가 결정되는 것도 아니다.

이는 발표가 확인한 단점이 아니라 분석적 구분이다. Broadcom의 추가 기능은 고객을 대신해 결정하지 않으면서도 이러한 결정을 지원할 수 있다. 기업은 여전히 기술 기능을 비즈니스 요구사항과 연결하는 운영 모델이 필요하다.

이 운영 모델은 이번 업데이트를 평가하는 적절한 틀을 제공한다. 핵심 질문은 추가 기능이 특정 업무를 제거하는지, 시행 가능한 통제를 개선하는지, 또는 문서화된 복구 공백을 해소하는지다. 이러한 연결이 없다면 포트폴리오 확장을 운영 가치로 전환하기는 여전히 어렵다.

공유 AI 인프라는 플랫폼 팀에 부담을 준다

AI 모델을 중앙화하면 접근 권한, 용량, 서비스 연속성을 관리하는 팀으로 책임이 이동한다.

Broadcom은 공유 모델 인프라가 분리된 보안 경계와 프라이빗 컨텍스트를 유지하면서 여러 내부 조직에 서비스를 제공할 수 있다고 말한다. 제시된 이점은 부서 간 중복을 줄이는 것이다. 이는 특정 고객 환경에서의 절감 효과에 대한 독립적 증거가 아니라 아키텍처의 장점에 관한 공급업체의 주장이다.

기본 메커니즘은 이해할 수 있다. 서로 다른 부서는 각기 다른 정보를 다루면서도 유사한 모델 기능에 접근하기를 원할 수 있다. 중앙 서비스는 모든 부서의 데이터를 의도적으로 공유하지 않으면서 모델 배포를 공유할 방법을 제공한다.

그러나 공유 환경에서는 플랫폼 팀이 가용성 이상을 책임져야 한다. 누가 접근 권한을 받는지, 경쟁하는 요청에 리소스를 어떻게 배분할지, 어떤 변경에 승인이 필요한지를 정의해야 한다. 프로비저닝이 쉬워져도 이러한 책임은 지속된다.

법무, 엔지니어링, 고객 지원용 어시스턴트를 둔 가상의 조직을 생각해 보자. 각 어시스턴트는 공유 모델 서비스를 사용하지만 서로 다른 리포지토리에서 정보를 검색한다. 인프라는 공통으로 사용할 수 있지만, 허용되는 문서, 사용자, 작업은 서로 다르게 유지된다.

이러한 구성은 구체적인 거버넌스 과제를 만든다. 직원에게 모델 사용 권한이 있다고 해서 연결된 모든 문서를 검색할 권한까지 있다는 뜻은 아니다. 마찬가지로 문서를 읽을 권한이 있다고 해서 다른 비즈니스 시스템을 수정할 권한이 부여되는 것은 아니다.

바로 이 지점에서 VMware 프라이빗 AI는 조직적 의사결정이 된다. 인프라 관리자, 애플리케이션 소유자, 보안 팀은 호환되는 접근 권한 정의를 마련해야 한다. 그렇지 않으면 각 그룹이 다른 그룹이 통제를 담당한다고 믿는 사이 아무도 구현하지 않은 통제가 생길 수 있다.

용량 관리도 또 다른 부담을 만든다. 공유 서비스는 하나의 워크로드가 사용 가능한 모든 리소스를 소비하지 않도록 하면서 서로 다른 비즈니스 우선순위를 수용해야 한다. 적절한 정책은 플랫폼의 기본 설정이 아니라 비즈니스 요구에 따라 달라진다.

개발 실험과 고객 대면 애플리케이션은 지연에 대한 허용 수준이 크게 다를 수 있다. 기반 인프라를 공유한다고 해서 이 차이가 사라지는 것은 아니다. 플랫폼 소유자는 자원 경합과 유지보수 중에도 이러한 우선순위를 유지할 방법이 필요하다.

동일한 문제는 변경 사항에도 적용된다. 중앙에 배포된 모델을 업데이트하면 이에 의존하는 여러 애플리케이션에 영향을 줄 수 있다. 따라서 애플리케이션 팀은 공유 업데이트가 프로덕션에 도달하기 전에 변경된 동작을 평가하는 프로세스가 필요하다.

이 분석이 Broadcom의 모델 공유가 용납할 수 없는 위험을 만든다고 단정하는 것은 아니다. 이는 통합에 수반되는 책임을 식별한다. 관련 비교 대상은 부서별로 중복되는 노력과 공통 서비스를 운영하는 데 필요한 규율 사이의 균형이다.

엔터프라이즈 지식에도 관련된 구분이 적용된다. 인프라 통제는 어시스턴트가 실행되는 환경을 구축하는 반면, 정보 통제는 어시스턴트가 무엇을 검색할 수 있는지를 결정한다. 지식 베이스의 구분은 배포 위치만으로 접근 정책을 결정할 수 없는 이유를 설명하는 데 도움이 된다.

부담은 또 다른 고립된 운영 환경을 만들지 않으면서 AI를 지원해야 하는 인프라 리더에게 가장 직접적으로 돌아간다. 이들은 중앙화가 서비스 제공을 개선한다는 점을 보여줘야 한다. 이를 위해서는 워크로드 동작, 관리 노력, 권한 집행에 관한 증거가 필요하다.

개발자에게 이점은 공유 플랫폼이 무엇을 예측 가능하게 만드는지에 달려 있다. 일관된 요청 프로세스, 문서화된 제한 사항, 명확한 소유권은 초기 배포 속도만큼 중요할 수 있다. 이러한 조건이 가용한 인프라를 사용할 수 있는 내부 서비스로 전환한다.

통합은 운영 선택권과 경쟁한다

Broadcom의 통합 전략은 엔터프라이즈 AI 인프라를 구성하고 관리하는 대안적 방식과 경쟁한다.

Nutanix의 엔터프라이즈 AI 통제는 관련성 있는 비교 대상이다. Enterprise AI 2.8 릴리스는 세분화된 권한, 통제된 모델 공유, 연결이 끊긴 환경을 위한 배포 옵션을 설명한다. 또한 이 릴리스는 정식 제공 기능과 프리뷰를 구분하며, 구매자는 공급업체를 비교할 때 이 구분을 유지해야 한다.

이 비교는 전반적인 승자가 아니라 중첩되는 우선순위를 보여준다. 두 접근 방식 모두 엔터프라이즈 인프라 내 AI 리소스에 대한 접근을 다룬다. 어느 공급업체의 기능 목록도 그 자체만으로 특정 조직에 어떤 플랫폼이 적합한지를 증명하지는 않는다.

Broadcom 고객은 관리자가 이미 이해하고 있는 환경을 확장하는 가치를 높이 평가할 수 있다. 새로운 기능이 기존 책임 체계에 부합한다면 익숙한 절차는 일부 전환 작업을 줄일 수 있다. 이 장점은 고객의 출발점에 달려 있으며 보편적으로 가정해서는 안 된다.

다른 조직은 인프라, 모델 서비스, 보안 도구를 각각 독립적으로 교체할 수 있는 상태를 우선시할 수 있다. 이 접근 방식은 선택권을 유지할 수 있지만, 팀이 구성 요소 간 연결을 유지해야 한다. 유연성에는 그 자체의 운영상 의무가 따른다.

따라서 핵심 긴장은 통합 운영과 독립적 통제 사이에 있다. 통합 플랫폼은 일부 워크플로를 더 쉽게 조정할 수 있게 해준다. 조립형 환경은 구성 요소를 변경할 자유를 더 많이 제공할 수 있지만, 더 많은 통합 작업을 요구한다.

이는 아키텍처적 트레이드오프이지 어느 한 경로가 본질적으로 우월하다고 가정할 이유는 아니다. 적절한 선택은 인력 역량, 애플리케이션 종속성, 하드웨어 요구사항, 조직의 변화 수용도에 달려 있다. 구매자는 이러한 조건을 직접 테스트해야 한다.

공정한 비교는 후보 환경 전반에 동일한 대표 워크로드를 사용해야 한다. 배포, 접근 제한, 유지보수, 복구를 검토해야 한다. 초기 설정만 비교하면 시작 시연을 가장 쉽게 만드는 제품에 유리하게 작용한다.

워크로드는 종속성을 드러낼 수 있을 만큼 프로덕션 환경과 충분히 유사해야 한다. 승인된 내부 문서에 연결된 어시스턴트는 고립된 챗봇 시연보다 더 많은 정보를 제공한다. 그 동작은 권한, 검색, 모델 가용성, 애플리케이션 구성에 함께 의존한다.

문서화 역시 이러한 평가에서 주목할 필요가 있습니다. 팀은 정책이 어디에 있는지, 관리자가 이를 어떻게 검토할 수 있는지 이해해야 합니다. 기술적으로 존재하는 제어 기능이라도 그 동작 방식이 불분명하면 운영이 까다로울 수 있습니다.

문제 해결은 또 다른 유용한 비교 기준을 제공합니다. 애플리케이션에 장애가 발생하면 관리자는 문제가 인프라, ID, 스토리지 또는 애플리케이션 동작 중 어디에 관련되는지 파악해야 합니다. 통합은 이러한 불확실성을 더 적은 조정으로 해소하는 데 도움이 될 때 가치를 발휘합니다.

Broadcom의 서비스 생태계도 구현의 중요성을 반영합니다. Kyndryl의 private cloud alliance는 VCF를 중심으로 한 컨설팅, 현대화, 역량 투자에 대해 설명합니다. 상업적 파트너인 Kyndryl은 결과에 대한 독립적 평가보다는 우호적인 관점을 제시합니다.

그럼에도 Kyndryl의 참여는 실무적인 요점을 부각합니다. 소프트웨어 기능에는 아키텍처와 운영 준비가 필요합니다. 고객은 여전히 벤더 포트폴리오를 실제로 작동하는 정책, 책임, 절차로 전환해야 합니다. 이러한 작업은 배포 노력과 함께 평가에 포함되어야 합니다.

Broadcom의 VCF 확장은 VMware 인프라 내에서 더 많은 책임을 통합해야 한다는 주장을 강화합니다. 고객이 그 주장을 받아들일지는 운영 마찰이 실제로 줄어든다는 입증에 달려 있습니다. 구매자는 동일한 비즈니스 요구사항을 충족하는 여러 방식을 비교할 수 있으므로 경쟁 제품도 여전히 중요합니다.

하이퍼바이저 보호가 애플리케이션 보안을 해결하지는 않는다

가상화 계층 보호는 중요한 위험을 다루지만, 애플리케이션 및 정보 제어는 별도의 책임으로 남습니다.

Broadcom의 hypervisor protection 발표는 가상 머신을 실행하는 소프트웨어 계층인 ESX를 위한 예방적 방어 기능으로 HyperArmor를 설명합니다. 회사는 이것이 호스트 수준의 가상 패치, 허용된 동작 제어, 관리 로그인 경로의 추가 인증을 결합한다고 말합니다.

가상 패치는 취약한 소프트웨어를 먼저 교체하지 않고도 악용을 차단하려는 방식입니다. Broadcom은 이 접근법을 노출 기간 동안의 보호 수단으로 제시합니다. 고객은 이 주장을 모든 취약점이나 공격 경로를 막는다는 보장과 구분해야 합니다.

이 발표에는 하이퍼바이저 계층의 예방적 제어에 관한 IDC 애널리스트 Stephen Elliot의 우호적 평가가 포함되어 있습니다. 그의 관점은 해당 계층의 아키텍처상 중요성을 뒷받침합니다. 그러나 이는 모든 HyperArmor 기능에 대한 독립적 검증을 확립하지는 않습니다.

구매자에게 회의적으로 검토해야 할 질문은 범위입니다. 인프라 방어는 호스트를 겨냥한 공격을 다룰 수 있지만, AI 애플리케이션이 기밀 정보를 적절하게 처리하는지까지 판단하지는 못합니다. 이러한 제어는 시스템의 서로 다른 계층에서 작동합니다.

권한이 있는 직원이 수신해서는 안 되는 문서를 요약해 달라고 내부 어시스턴트에게 요청하는 상황을 상상해 보십시오. 이 상호작용 내내 호스트는 침해되지 않은 상태로 남을 수 있습니다. 실패는 가상화 소프트웨어에 대한 성공적인 공격이 아니라 정보 접근 또는 애플리케이션 동작과 관련됩니다.

마찬가지로 비즈니스 도구에 연결된 모델에는 허용되는 작업을 규정하는 규칙이 필요합니다. 승인되지 않은 호스트 명령을 방지한다고 해서 어시스턴트가 메시지를 보내거나 레코드를 변경할 수 있는지가 자동으로 결정되지는 않습니다. 애플리케이션 소유자는 이러한 경계를 설정해야 합니다.

이 구분은 보안 관련 표현이 조달 논의를 거치며 종종 더 광범위해지기 때문에 중요합니다. 한 계층을 위해 설계된 제품이 전체 환경을 보호한다는 약칭이 될 수 있습니다. 구매자는 기술적 주장을 승인 문서로 옮길 때 원래의 범위를 유지해야 합니다.

기밀 컴퓨팅도 비슷한 주의가 필요합니다. 처리 중인 데이터를 보호하는 것은 특정 유형의 노출을 다룹니다. 그렇다고 모든 사용자 요청이 적절하다거나, 검색된 모든 문서가 승인되었다거나, 생성된 모든 답변이 정확하다는 의미는 아닙니다.

적절한 결론은 계층화된 책임입니다. 인프라 제어, ID 정책, 애플리케이션 제한, 정보 거버넌스는 서로를 뒷받침해야 합니다. 한 계층을 강화했다고 해서 문서화된 이유 없이 다른 곳의 제어를 제거하는 것이 정당화되지는 않습니다.

관리 절차도 평가가 필요합니다. 팀은 승인된 긴급 접근이 어떻게 작동하는지, ID 종속성에 장애가 발생했을 때 복구가 어떻게 진행되는지 이해해야 합니다. 추가 인증은 관리자가 예상되는 조건에서 이를 안정적으로 운영할 수 있을 때에만 도움이 됩니다.

이러한 질문 중 어느 것도 Broadcom의 보안 방향을 일축할 필요는 없습니다. 호스트 침해를 방지하고 권한 있는 접근의 오용을 제한하는 것은 의미 있는 목표입니다. 주의해야 할 점은 이러한 목표를 가용한 증거가 뒷받침하지 않는 주장으로 확장하는 것입니다.

따라서 프로덕션 평가는 광범위한 보안 라벨이 아니라 구체적인 동작을 시험해야 합니다. 의도된 관리자가 승인된 작업을 수행할 수 있는가? 시스템은 금지된 작업을 차단하는가, 그리고 팀은 그 결과를 설명할 수 있는가?

AI 관련 위협 주장에도 동일한 원칙이 적용되어야 합니다. 구매자가 제어 기능을 평가하기 위해 공격자에 관한 포괄적 서사를 받아들일 필요는 없습니다. 해결하려는 위협, 제공되는 보호, 남아 있는 노출을 식별해야 합니다.

복구는 신뢰할 수 있는 서비스를 복원해야 한다

VMware 복구 기능은 인프라가 성공적으로 재시작되었는지를 넘어 애플리케이션 수준에서 평가할 가치가 있습니다.

portfolio availability details는 기본 재해 복구와 더 광범위한 고급 서비스 포트폴리오를 구분합니다. Network World는 vSphere Express가 최대 128코어의 소규모 환경에서 즉시 이용 가능하다고 보도합니다. 복구 및 연결 기능을 포함한 여러 VCF 추가 기능은 Broadcom의 2027 회계연도 1분기에 제공될 예정입니다.

이 구분은 재해 복구와 사이버 복구가 서로 다른 질문에 답하기 때문에 중요합니다. 재해 복구는 중단 이후 운영을 복원하는 문제입니다. 사이버 복구는 공격 후 복원된 환경이 다시 연결하기에 적합하다는 확신도 요구합니다.

AI 애플리케이션에서 컴퓨팅을 복원하는 것은 작업의 일부일 뿐입니다. 서비스는 모델 파일, 문서, 권한, 애플리케이션 설정, 다른 시스템과의 연결에 의존할 수 있습니다. 복구 계획은 이러한 종속성을 함께 고려해야 합니다.

보안 사고 이후 복원된 가상의 내부 엔지니어링 어시스턴트를 생각해 보십시오. 가상 머신은 성공적으로 시작되고 인터페이스는 요청을 받습니다. 그러나 문서 인덱스에는 오래된 권한이 반영되어 있고, 애플리케이션 구성은 변경된 모델을 가리킵니다.

인프라 복원은 성공할 수 있지만, 서비스는 여전히 정상 사용에 부적합할 수 있습니다. 이 사례는 복구 검증에 애플리케이션 소유권이 필요한 이유를 보여줍니다. 관리자는 인프라가 실행되는지 확인할 수 있지만, 비즈니스 소유자는 서비스가 허용 가능한 방식으로 동작하는지 판단하는 데 참여해야 합니다.

따라서 VMware 복구 기능은 정의된 복구 목표에 따라 평가되어야 합니다. 이 목표는 최신 접근 규칙과 검증된 소스 자료를 갖춘 승인된 애플리케이션을 복원하는 것일 수 있습니다. 조직은 오케스트레이션 기능을 평가하기 전에 이 결과를 명시해야 합니다.

복구된 시스템을 검사하기 위한 격리 환경인 클린룸은 이 과정을 지원할 수 있습니다. 격리는 팀이 프로덕션 종속성을 다시 연결하기 전에 조사할 공간을 제공합니다. 그렇다고 복원된 모든 아티팩트나 구성이 자동으로 신뢰할 수 있게 되는 것은 아닙니다.

복구 결정이 어떻게 승인을 받는지도 평가해야 합니다. 보안 담당자, 인프라 관리자, 애플리케이션 소유자는 서로 다른 증거 요건을 가질 수 있습니다. 문서화된 절차는 사고 중에 이러한 차이를 발견하는 일을 피하는 데 도움이 됩니다.

복원 순서는 또 다른 실무적 종속성을 만듭니다. 애플리케이션은 사용 가능해지기 전에 ID 서비스, 스토리지 또는 네트워크 연결이 필요할 수 있습니다. 오케스트레이션은 이러한 순서를 반영하고 팀이 각 종속성을 검증하도록 도울 때 중요합니다.

이는 특히 공유 AI 인프라와 관련이 있습니다. 중앙화는 공통 서비스를 여러 부서에 가치 있게 만들 수 있으며, 이는 장기 중단의 영향을 키웁니다. 복구 계획은 이러한 종속 애플리케이션의 중요성을 반영해야 합니다.

구매자는 기능 시연과 복구 훈련도 구분해야 합니다. 시연은 선택된 조건에서 워크플로가 작동할 수 있음을 보여줍니다. 훈련은 고객의 인력, 종속성, 절차가 요구되는 결과를 달성할 수 있는지 검토합니다.

가장 강력한 증거는 복구 자동화를 문서화된 애플리케이션 검증과 연결할 것입니다. 팀은 무엇이 복귀했는지, 어떤 검사를 통과했는지, 누가 재연결을 승인했는지 알아야 합니다. 이는 인프라 상태 지표만으로 얻는 것보다 더 명확한 신뢰 근거를 제공합니다.

VMware private AI 배포에서 운영상의 질문은 간단합니다. 조직이 신뢰할 의사가 있는 서비스를 복원할 수 있는가? 답은 소프트웨어 기능과 이를 둘러싼 준비에 달려 있습니다.

다음 릴리스까지 구매자가 주시해야 할 사항

다음 증거는 제공 여부, 실질적인 통합 이점, 대표 조건에서의 복구 동작을 확립해야 합니다.

첫 번째 신호는 발표된 범위에 맞춘 릴리스 제공입니다. 고객은 계획된 인프라, 스토리지, 연결성, 컴플라이언스, 복구 추가 기능을 다루는 최종 문서를 주시해야 합니다. Broadcom의 회계 분기 표현은 추정된 달력상 마감일과 구분되어야 합니다.

관련 증거에는 지원되는 구성, 알려진 제한 사항, 기본 기능과 고급 서비스 간의 관계가 포함됩니다. 이러한 세부 사항은 발표된 기능이 기존 환경에 적합한지 결정합니다. 또한 고객이 도입 전에 어떤 준비를 해야 하는지도 보여 줍니다.

문서화된 고객 요구사항에 부합하는 제공은 Broadcom의 통합 주장을 강화할 것입니다. 기능 누락, 제한된 지원 또는 변경된 제공 가능성은 영향을 받는 배포에서 그 주장을 약화할 것입니다. 평가는 발표의 전반적 폭이 아니라 실제 요구사항을 따라야 합니다.

두 번째 신호는 대표적인 공유 모델 배포에서 나온 증거입니다. 구매자는 워크로드 특성, 접근 경계, 서비스 동작, 관리 노력을 설명하는 결과를 찾아야 합니다. 리소스 효율성에 관한 제목 수준의 주장은 이러한 조건 없이는 평가하기 어렵습니다.

유용한 증거는 부서들이 정보와 워크로드에 대한 적절한 제어를 유지하면서 인프라를 공유할 수 있는지 보여줄 것입니다. 또한 업데이트, 경합, 문제 해결 중 플랫폼 담당자가 무엇을 해야 하는지도 설명할 것입니다. 이는 통합이 작업을 없애는지, 아니면 재분배하는지를 드러냅니다.

벤더 시연은 자연스럽게 유리한 조건을 선택하므로 독립적인 고객 사례는 특히 가치가 있습니다. 상세한 사례는 제한 사항을 솔직하게 설명한다면 여전히 유용할 수 있습니다. 구매자는 설명되지 않은 개선 주장보다 설명 가능한 결과를 선호해야 합니다.

세 번째 신호는 완전한 애플리케이션을 포함한 복구 검증입니다. 고객은 복원된 인프라를 권한, 소스 정보, 애플리케이션 동작과 연결하는 훈련을 주시해야 합니다. 이러한 증거는 운영 복원력에 관한 주장을 더 구체적으로 만들 것입니다.

성공적인 훈련은 필요한 검증을 유지하면서 조정 업무를 줄일 수 있다면 통합 복구의 타당성을 강화할 것입니다. 해결되지 않은 종속성을 드러내는 훈련은 여전히 필요한 작업을 식별할 것입니다. 어느 결과든 통합이 준비 상태를 보장한다고 가정하는 것보다 더 많은 정보를 제공합니다.

이러한 신호를 종합하면 Broadcom VCF 확장을 평가하는 데 집중된 방법을 제공합니다. 제공 범위는 무엇이 존재하는지를 보여줍니다. 배포 증거는 그것이 어떻게 운영되는지를 보여주며, 복구 검증은 중단 상황에서 조직이 이를 신뢰할 수 있는지를 판단하게 합니다.

다가오는 아키텍처 검토를 위해 대표적인 애플리케이션을 선택하고, 그 액세스 요구 사항, 종속성, 유지보수 프로세스, 복구 기준을 문서화하세요. 플랫폼 팀에 각 요구 사항을 사용 가능한 기능, 계획된 추가 사항 또는 운영 절차에 매핑하도록 요청하세요. 이 평가에서는 기본 제공 기능과 고급 서비스를 구분해 유지하세요. 동일한 애플리케이션을 동등한 조건과 승인 기준을 사용해 신뢰할 수 있는 대안과 비교하세요. Broadcom VCF 확장의 경우 관리 업무 감소, 강제 가능한 정보 경계, 그리고 만족스럽게 복구되는 서비스를 보여주는 증거를 우선시하세요. 프로덕션 워크로드를 확정하기 전에 애플리케이션 소유자가 평가할 수 있는 배포 및 복구 훈련을 요청하세요. 귀사 팀은 어떤 책임을 통합할 것이며, 그 결과 서비스가 요구 사항을 충족한다는 점을 어떤 증거로 입증할 것인가요?