Microsoft Sovereign Cloud 확장, 워크로드 제어를 핵심에 두다

Microsoft는 2026년 10월 20일 sovereign cloud 제품군을 확장하며 퍼블릭 클라우드 감독 기능과 로컬에서 운영되는 애플리케이션을 하나의 전략으로 묶었다. 이번 Microsoft Sovereign Cloud 확장은 민감한 애플리케이션이 외부 의존성을 어느 정도까지 감수할 수 있는지라는 까다로운 엔터프라이즈 선택지를 다룬다. 그 의미는 구매자가 선택할 수 있는 다양한 운영 모델과 함께, 검토해야 하는 서로 다른 출시 단계에 있다.

핵심 경쟁 구도는 클라우드의 편의성과 운영 권한 사이에 있다. 공급업체는 고도화된 서비스를 제공할 수 있지만, 고객은 접근, 복구, 연속성에 관한 중요한 책임을 계속 보유한다. 애플리케이션을 고객이 통제하는 환경으로 옮기면 이러한 관계가 달라지지만, 유지보수 책임의 주체도 달라진다.

AWS와 Google은 각각 유럽 전용 인프라와 분리형 컴퓨팅을 비롯한 접근 방식을 통해 유용한 비교 기준을 제시한다. Microsoft의 발표 역시 이보다 넓은 경쟁 구도에 속한다. 엔터프라이즈 구매자에게 중요한 비교 대상은 나열된 주권 기능의 수가 아니라 현실적인 조건에서 운영되는 완전한 애플리케이션이다.

Microsoft Sovereign Cloud 확장, 서로 다른 출시 단계로 제공

이번 발표는 하나의 완성된 패키지가 아니라, 사용 가능한 기능, 프리뷰, 단계적 배포, 향후 출시 계획을 결합한다.

Microsoft의 sovereign cloud expansion은 퍼블릭 클라우드, 고객 운영 인프라, 파트너 전반의 변화를 설명한다. Azure Managed HSM을 이용한 외부 키 관리는 정식 출시됐다. Sovereign Control Panel은 Microsoft Ignite에서 퍼블릭 프리뷰에 들어갈 예정이다.

회사는 Data Guardian과 Production Touch Ledger를 유럽에서 단계적으로 배포하는 계획도 설명했다. 프리뷰에서는 연결 상태와 분리 상태의 운영 간 전환을 시험한다. 기타 로컬 개발 및 AI 기능은 Ignite와 연계된 제공 시점을 갖는다.

이러한 구분은 발표가 당장 제공하는 가치를 좌우한다. 정식 출시된 구성 요소는 문서화된 조건에 따라 프로덕션 평가에 들어갈 수 있다. 프리뷰는 고객에게 동작을 시험할 기회를 제공하지만, 프로덕션 사용 적합성과 향후 변경에 관한 의문은 남긴다.

발표된 출시 계획은 방향을 제시하지만, 구매자에게는 실제 소프트웨어, 문서, 지원 조건이 여전히 필요하다. 이 범주들을 하나의 제공 가능성 주장으로 묶으면 조달팀에 필요한 정보를 가리게 된다.

민감한 기록 애플리케이션을 평가하는 가상의 공공기관을 생각해 보자. 현재 사용 가능한 암호화 제어 기능은 오늘날 해당 기관의 키 보관 요건을 충족할 수 있다. 하지만 설계의 다른 부분에 포함된 프리뷰 기능은 전체 애플리케이션이 이에 의존하기 전에 별도의 승인을 받아야 한다.

이 때문에 제품 준비도는 애플리케이션 수준에서 평가해야 한다. 워크로드는 특정 작업을 수행하는 애플리케이션과 지원 서비스다. 그 준비도는 해당 작업에 필요한 구성 요소 중 가장 성숙도가 낮은 요소에 따라 결정된다.

이번 소식은 Microsoft 포트폴리오에 주권 개념을 새로 도입하기보다 기존 전략을 확장한다. 2025년 6월의 sovereign deployment models는 이미 제품군을 퍼블릭, 프라이빗, 국가 파트너 환경으로 구분했다. 당시 발표에는 Microsoft 365 Local과 고객 통제형 암호화 계획도 포함됐다.

이 구분은 진전을 평가할 때 중요하다. 유용한 질문은 이전 약속 가운데 무엇이 이제 배포 가능한 구현, 확대된 범위 또는 더 명확한 운영 체계를 갖췄는지다. 이미 발표된 범주를 다시 계산하면 이번 주에 바뀐 내용을 과장하게 된다.

Microsoft의 방향은 평가할 만큼 분명하다. 회사는 고객이 개별 애플리케이션별로 제어 기능을 선택하기를 원한다. 이 접근 방식이 엔터프라이즈 운영을 단순화할지는 구현의 문제로 남는다. 일관된 전략이라도 서로 다른 사전 요건과 지원 경계를 지닌 구성 요소를 포함할 수 있다.

구매자에게 첫 번째 영향은 더욱 세부적인 평가 절차다. “Sovereign cloud”는 완전한 구매 사양이 될 수 없다. 팀은 각 요건에 연결된 정확한 서비스, 배포 모델, 위치, 제공 상태, 책임을 식별해야 한다.

부담은 구매자와 그들의 운영 모델로 옮겨간다

배포 선택지가 늘어날수록 구매자가 정의하는 제어의 의미는 더욱 중요해진다.

Microsoft Sovereign Cloud 확장은 엔터프라이즈 기술 리더에게 까다로운 위치를 요구한다. 이들은 광범위한 조직 선호도를 엔지니어가 구현하고 검토자가 점검할 수 있는 요건으로 옮겨야 한다. 민감한 정보를 로컬에 유지해 달라는 요청은 시작에 불과하다.

데이터 레지던시는 정보가 저장되거나 처리되는 위치를 의미한다. 운영 권한은 누가 시스템을 관리하고 민감한 작업을 승인할 수 있는지와 관련된다. 연속성은 의존성이 실패했을 때 어떤 서비스를 계속 사용할 수 있는지를 뜻한다.

이 요건들은 서로 겹치지만, 하나를 충족한다고 해서 다른 요건도 자동으로 충족되는 것은 아니다. 로컬 데이터베이스도 외부 인증 서비스에 의존할 수 있다. 고객 통제형 서버도 복구를 위해 원격 지원 절차를 요구할 수 있다.

이러한 구분은 주권을 일반적인 보증으로 구매하는 조직에 부담을 준다. 의사결정은 자신들이 견디려는 구체적인 사건을 식별해야 한다. 그렇지 않으면 서로 다른 부서가 양립할 수 없는 결과를 기대하면서도 같은 구매를 승인할 수 있다.

보안팀은 관리자가 민감한 시스템을 변경할 수 있게 하는 권한인 특권 접근의 제한을 우선시할 수 있다. 운영팀은 네트워크 중단 중에도 필수 서비스를 계속 가동하는 일을 우선시할 수 있다. 조달팀은 계약 조직의 정체성과 의무에 초점을 맞출 수 있다.

이러한 우려 중 어느 것도 하나의 공통된 명칭 속에서 사라져서는 안 된다. 운영 모델은 이들이 어떻게 함께 작동하는지 설명해야 한다. 또한 요건이 충돌할 때 누가 결정하는지도 밝혀야 한다.

이는 인프라팀에 실질적인 부담을 만든다. 추가되는 모든 배포 환경에는 유지보수, 모니터링, 복구를 책임질 담당자가 필요하다. 익숙한 소프트웨어 플랫폼이 이러한 의무를 없애지는 않는다.

같은 부담은 애플리케이션 개발자에게도 미친다. 지속적으로 사용 가능한 원격 의존성을 중심으로 설계된 서비스는 분리 운영을 지원하기 전에 신중한 검토가 필요하다. 데이터베이스를 가까이에 둔다고 해서 모든 지원 기능이 로컬화되는 것은 아니다.

지식 근로자에게 그 영향은 일상적 행동에서 나타난다. 장애 상황에서도 승인된 문서를 검색하고, 최신 버전을 확인하며, 올바른 권한으로 접근할 수 있는가? 이러한 질문은 인프라 결정과 조직이 실제로 보존해야 하는 업무를 연결한다.

개인 지식과 팀 지식의 구분은 정보 소유권을 정의하는 데 유용한 기준을 제공한다. 엔터프라이즈 주권은 관리와 연속성에 관한 추가 질문을 제기한다. 조직이 의미 있는 제어 기능을 할당하려면 명확한 소유권이 여전히 필요하다.

파트너도 압박을 받는다. 구매자가 이해하고 검증할 수 있는 운영 체계를 만들 때 현지 전문성의 가치가 커진다. 파트너의 역할은 권한, 책임, 에스컬레이션 절차를 명확히 해야 한다.

이는 광범위한 보증보다 구체적인 제안을 선호하게 만든다. 조직은 문서화된 복구 책임이나 관리자 승인 절차를 비교할 수 있다. 각 약속이 무엇을 포괄하는지 모른 채 더 큰 통제력을 약속하는 주장은 쉽게 비교할 수 없다.

따라서 즉각적인 효과는 자동적인 마이그레이션 물결이 아니라 평가 업무의 변화다. 구매자는 검토할 아키텍처 선택지를 더 많이 갖게 된다. 동시에 자체 요건을 정의하지 않은 채 넘어갈 이유는 줄어든다.

퍼블릭 클라우드 제어와 로컬 운영은 서로 다른 문제를 해결한다

접근, 키, 처리, 복구에 대한 제어는 각각 별도로 평가해야 한다.

Microsoft의 public cloud controls는 여러 메커니즘을 구분한다. Data Guardian은 공급업체 운영에 대한 감독을 다룬다. External Key Management를 사용하면 고객은 Microsoft 클라우드 경계 밖에서 암호화 키를 관리할 수 있다.

기밀 컴퓨팅은 하드웨어 기반의 격리 실행을 통해 지원되는 데이터를 처리 중에 보호한다. Sovereign Control Panel은 주권 관련 정보를 중앙화된 Azure 포털 환경으로 가져온다. 이 메커니즘들은 애플리케이션 노출의 서로 다른 부분을 다룬다.

구매자에게 이러한 분리는 주장을 더 정밀하게 만든다는 점에서 유용하다. 키 보관은 누가 암호화 자료를 통제하는지에 답한다. 접근 감독은 지정된 관리 활동이 어떻게 감독을 받고 증거를 남기는지에 답한다.

어느 답도 다른 답을 대체해서는 안 된다. 조직은 둘 다 요구할 수 있지만, 각 메커니즘이 무엇에 기여하는지 이해해야 한다. 평가에서는 예외와 적용되는 서비스도 식별해야 한다.

유용한 가상 사례로 규제 대상 분석 애플리케이션을 들 수 있다. 검토자는 민감한 관리 접근이 적절한 승인을 받았다는 증거를 요구할 수 있다. 이와 별도로 암호화 키가 지정된 조직의 통제 아래 유지될 것을 요구할 수 있다.

그러면 애플리케이션 팀은 이러한 제어 기능을 실제 운영과 연결해야 한다. 긴급 접근 요청은 누가 처리하는가? 키 서비스가 사용할 수 없게 되면 어떻게 되는가? 조직은 승인한 제어 기능을 유지하면서 어떻게 복구하는가?

이는 기능을 배제해야 할 이유가 아니라 아키텍처에 관한 질문이다. 제어 기능은 정상 동작과 장애 시 동작이 이해될 때 유용해진다. 이러한 이해는 추가 보호 조치가 필요한지 판단하는 데도 도움이 된다.

로컬 운영은 관계의 다른 부분을 바꾼다. 더 많은 환경을 고객의 운영 경계 안에 배치한다. 그에 따른 권한은 조직이 이를 행사할 사람과 절차도 갖췄을 때 가치가 있다.

분리된 환경은 외부 서비스나 네트워크에 능동적으로 연결되지 않은 상태에서 운영된다. 이 기능은 까다로운 애플리케이션 요건을 만든다. 필수 기능은 허용된 경계 안에서 계속 사용할 수 있어야 한다.

예를 들어, 가상의 긴급 대응 조정 시스템에는 접근 가능한 기록만으로는 충분하지 않다. 직원들은 작동하는 계정, 권한, 검색 기능, 새 결정을 기록할 방법도 필요하다. 필요한 기능은 조직의 임무에 따라 달라진다.

이 지점에서 Microsoft Sovereign Cloud 확장은 애플리케이션 아키텍처의 이야기가 된다. 그 가치는 정의된 작업을 중심으로 각 구성 요소가 어떻게 맞물리는지에 달려 있다. 배포 다이어그램은 정상 운영과 제약된 운영을 모두 설명해야 한다.

운영을 유지하는 것과 모든 기능을 그대로 유지하는 것 사이에도 차이가 있다. 서비스는 선택 기능을 제한하면서 필수 워크플로를 보존할 수 있다. 구매자는 장애가 발생하기 전에 어떤 동작을 허용 가능한 것으로 볼지 정의해야 한다.

완전히 연결된 환경과 구체적으로 명시되지 않은 로컬 대안을 비교하는 것은 도움이 되지 않습니다. 의미 있는 비교는 동일한 필수 작업과 명확히 제시된 운영 조건을 기준으로 이뤄집니다. 그래야만 구매자는 수반되는 추가 권한과 책임을 평가할 수 있습니다.

AWS와 Google은 구매자에게 서로 다른 기준점을 제시합니다

경쟁 비교의 핵심은 보편적인 주권성 순위가 아니라 운영 경계와 애플리케이션 적용 범위입니다.

AWS는 European Sovereign Cloud를 유럽연합 내에 위치한 물리적·논리적으로 분리된 인프라라고 설명합니다. 첫 번째 리전은 독일 브란덴부르크에 있습니다. AWS는 이 환경에 전용 ID 및 청구 시스템이 포함된다고 밝힙니다.

또한 AWS는 EU 외부의 인력이나 인프라에 대한 핵심 의존성을 피하도록 설계된 유럽 내 운영 체계와 통제를 설명합니다. 이는 설계에 관한 AWS의 공개 주장입니다. 모든 워크로드에 대한 독립적인 판정이 아니라, 고객이 평가할 수 있는 구체적인 기준을 제공합니다.

구매자 입장에서 분리된 인프라는 특정한 질문을 낳습니다. 필요한 서비스는 그곳에 어떤 것이 있습니까? 계정, 애플리케이션, 지원 체계는 분리된 환경에 어떻게 맞춰집니까? 기존 배포를 이전하면 무엇이 달라집니까?

Microsoft의 퍼블릭, 고객 운영형, 파트너 모델 범위는 또 다른 평가 기준을 만듭니다. 구매자는 각 옵션에 수반되는 책임을 비교해야 합니다. 환경 간 경계가 이해 가능하다면 폭넓은 환경 선택지는 유용합니다.

Google은 Google Distributed Cloud를 통해 또 다른 기준점을 제시합니다. 10월 20일 발표에서는 외부 네트워크와 격리된 시스템을 의미하는 에어갭 환경을 위한 기능 추가를 설명합니다. 여기에는 로컬 AI, 엔터프라이즈 검색, 인프라 및 파트너 애플리케이션이 포함됩니다.

Google은 Gemini 기반 엔터프라이즈 검색이 프리뷰로 제공된다고 말합니다. 또한 격리된 환경에서 Gemini와 오픈 모델을 지원한다고 설명합니다. 이는 우월성에 대한 비교 증거가 아니라 제품 주장과 출시 관련 발표입니다.

경쟁 측면에서 중요한 점은 구매자가 경계 내부의 애플리케이션 적용 범위를 물을 수 있다는 것입니다. 필요한 소프트웨어가 인프라 플랫폼과 함께 실행될 수 있을 때 그 플랫폼은 더 유용해집니다. 누락된 종속성은 실질적인 결과를 좌우할 수 있습니다.

가령 가상의 연구 기관이 AI로 민감한 내부 자료를 검색하려 한다고 가정해 보겠습니다. 이 기관은 모델이 로컬에서 실행되는지 여부 이상을 평가해야 합니다. 문서 수집, 권한 적용, 인덱싱, 그리고 활용 가능한 답변도 필요합니다.

모델 출력을 생성하는 과정인 추론은 그 시스템의 일부에 불과합니다. 답변은 불완전하거나 잘못된 권한이 적용된 인덱스를 참조하면서도 로컬 환경 안에 머물 수 있습니다. 애플리케이션의 유용성과 거버넌스는 전체 흐름에 달려 있습니다.

이는 Microsoft, AWS, Google을 비교하는 공정한 기준입니다. 각 기업은 동일한 정보 경계와 필수 워크플로를 기준으로 평가되어야 합니다. 공급업체별 기능 총량으로는 이 비교를 대체할 수 없습니다.

구매자는 모든 주권형 옵션이 같은 고객을 위한 것이라고 가정해서도 안 됩니다. 일부 조직은 호스팅 서비스에 대해 지리적·관리적 보장을 필요로 합니다. 다른 조직은 외부 연결 없이도 계속 사용할 수 있는 애플리케이션을 필요로 합니다.

이러한 요구사항은 어느 구매자도 일관성을 잃지 않은 채 서로 다른 배포 선택으로 이어질 수 있습니다. 필수 운영 조건이 명확할 때 경쟁 시장은 더 이해하기 쉬워집니다.

Microsoft의 기회는 기존 엔터프라이즈 고객이 자사 옵션 범위를 이해할 수 있게 만드는 데 있습니다. 과제는 그 범위가 명시된 요구사항을 충족하는 애플리케이션으로 어떻게 이어지는지 보여주는 것입니다. 경쟁업체들도 각자의 설계 안에서 동일한 증거 요구에 직면합니다.

더 많은 통제권에도 전체 애플리케이션에 관한 증거가 필요합니다

주권성 기능은 정의된 통제에 관한 증거일 뿐, 모든 종속성이 구매자의 요구사항을 충족한다는 증명은 아닙니다.

가장 강력한 회의적 질문은 범위에 관한 것입니다. 통제는 정확히 무엇을 포괄하며, 무엇이 그 밖에 남습니까? 이는 공급자의 공개 역량이 실패했다는 주장이 아니라 평가 질문입니다.

대시보드는 유용한 정보를 보여줄 수 있지만, 중요한 애플리케이션 결정을 고객에게 남길 수 있습니다. 액세스 기록은 명시된 활동을 문서화할 수 있지만, 가능한 모든 종속성을 설명하지는 않습니다. 암호화 기능은 키 관리 책임을 다룰 수 있지만, 애플리케이션 가용성을 결정하지는 않습니다.

이러한 구분은 주권성 결정이 조직 경계를 가로지르기 때문에 중요합니다. 인프라 담당자는 조달 부서가 결코 보지 못하는 기술적 제약을 이해할 수 있습니다. 애플리케이션 소유자는 호스팅 환경이 승인을 받았다는 이유로 서비스도 적용 대상이라고 가정할 수 있습니다.

해결책은 실제 애플리케이션에 대한 공동의 이해입니다. 여기에는 필요한 구성 요소, 각 운영 주체, 그리고 기능하는 조건이 식별되어야 합니다. 또한 이미 확립된 동작과 아직 평가 중인 역량을 구분해야 합니다.

프리뷰 상태에는 특히 주의할 필요가 있습니다. 이것이 역량의 관련성을 없애는 것은 아니지만, 구매자가 프로덕션 계획에 둘 수 있는 신뢰 수준은 달라집니다. 평가 결과는 향후 출시 예상과 분리되어야 합니다.

단계적 배포는 또 다른 질문을 제기합니다. 즉, 필요한 역량이 해당 환경에서 활성화되어 있는지 여부입니다. 일반적인 제품 가용성과 개별 배포 적용 범위는 서로 다른 사실입니다. 구매자는 자신이 운영할 수준에서 확인이 필요합니다.

운영 테스트는 보호하려는 작업을 반영해야 합니다. 의도한 테스트가 완전한 비즈니스 워크플로에 관한 것이라면 네트워크 연결을 끊는 것만으로는 충분하지 않습니다. 직원은 조직이 보존하려는 행동을 실제로 시도해야 합니다.

가상의 공공 유틸리티 기업은 통신 장애 중에도 엔지니어가 유지보수 절차를 조회하고 시정 작업을 기록해야 할 수 있습니다. 유용한 실습은 계정 액세스부터 최종 기록 저장까지 그 워크플로를 검토할 것입니다. 그 결과 서버 인벤토리만으로는 놓칠 수 있는 종속성이 드러날 것입니다.

같은 원칙은 복구에도 적용됩니다. 시스템은 중단을 견딜 수 있지만, 이후 복잡한 조정이 필요할 수 있습니다. 구매자는 제한된 운영 중에 발생한 변경 사항이 어떻게 처리되는지 이해해야 합니다.

증거에는 책임자도 필요합니다. 누군가는 테스트 조건을 설명하고, 실패를 해석하며, 시정 작업을 승인해야 합니다. 환경의 일부를 외부에 위탁한다고 해서 내부 책임성의 필요가 사라지는 것은 아닙니다.

이것이 발표 이면의 실질적인 트레이드오프입니다. 추가 권한은 특정 외부 종속성을 줄이는 대신 내부 운영 의무를 늘릴 수 있습니다. 구매자는 자신의 역량과 미션을 기준으로 그 교환을 판단해야 합니다.

따라서 Microsoft의 새 옵션은 일괄적인 승인도, 일괄적인 기각도 받아서는 안 됩니다. 적절한 대응은 더 정밀한 평가입니다. 각 주장된 이점에는 정의된 범위, 책임 있는 운영 주체, 그리고 의도한 워크로드와 관련된 증거가 필요합니다.

출시 이행, 연속성 테스트 및 파트너 책임성을 주시하세요

다음으로 유용한 신호는 완료된 출시, 현실적인 운영 증거, 명확한 책임 분담입니다.

첫째, 발표와 관련된 Ignite 마일스톤을 지켜보세요. 핵심 질문은 명시된 출시가 사용 가능한 문서와 명확한 자격 요건을 갖춰 이뤄지는지입니다. 가용성은 서비스 및 배포 수준에서 더 쉽게 판단할 수 있어야 합니다.

이는 발표된 방향을 고객이 직접 평가할 수 있는 것으로 바꿔 Microsoft의 주장을 강화할 것입니다. 불명확한 전제 조건이나 더 좁은 적용 범위는 확장의 즉각적인 유용성을 제한할 것입니다. 출시 세부 사항이 나오기 전에는 어느 결과도 추정해서는 안 됩니다.

중요한 증거는 제품 데모를 넘어섭니다. 구매자는 구성 요구사항, 지원되는 조합, 유지보수 책임을 이해해야 합니다. 이러한 세부 사항은 역량이 기존 애플리케이션에 맞는지, 아니면 더 광범위한 변경이 필요한지를 결정합니다.

둘째, 완전한 애플리케이션 전반의 연속성에 대한 고객 평가를 지켜보세요. 유용한 설명은 운영 조건, 필수 기능, 관찰된 제약을 식별할 것입니다. 무엇이 계속 작동했고 무엇에 개입이 필요했는지 설명해야 합니다.

그런 증거는 배포 유연성이 실질적인 운영 권한으로 이어진다는 주장을 강화할 것입니다. 검증되지 않은 외부 서비스에 반복적으로 의존한다면 해당 워크로드에서는 그 주장이 약화될 것입니다. 결과는 테스트의 실제 범위 안에서 평가되어야 합니다.

로컬 AI에도 동일한 기준이 적용됩니다. 데모는 사용자가 적절한 정보에 접근하고 의도한 작업을 완료할 수 있는지를 입증해야 합니다. 모델 실행만으로는 주변 애플리케이션이 요구사항대로 작동한다는 사실이 입증되지 않습니다.

셋째, 파트너가 자신의 책임을 어떻게 설명하는지 지켜보세요. 가장 강력한 제안은 누가 각 구성 요소를 운영하고, 민감한 조치를 승인하며, 복구를 처리하는지 식별할 것입니다. 또한 사고 발생 시 책임이 어떻게 바뀌는지도 설명할 것입니다.

명확한 책임성은 구체적인 로컬 요구사항을 가진 구매자에게 파트너 접근 방식을 더 유용하게 만들 것입니다. 기반 기술이 적합하더라도 모호한 에스컬레이션 절차는 평가를 어렵게 만들 것입니다. 파트너 참여는 운영상 필요를 해결할 때 의미를 갖습니다.

이러한 신호는 논의를 관찰 가능한 이행에 기반하게 합니다. 또한 제품 포트폴리오가 발전함에 따라 구매자가 이전 가정을 재검토할 방법을 제공합니다. 오늘의 요구사항을 위해 선택한 아키텍처는 재평가 가능성을 열어 두어야 합니다.

Microsoft Sovereign Cloud 확장을 고려하는 조직이라면, 중단이나 노출의 영향이 가장 큰 애플리케이션부터 시작하세요. 반드시 보존해야 하는 기능, 반드시 준수해야 하는 정보 경계, 그리고 팀이 유지해야 하는 권한을 식별하세요. 그런 다음 공급업체에 실제로 마주할 것으로 예상하는 조건에서 해당 애플리케이션을 입증해 달라고 요청하세요. 어떤 역량을 사용할 수 있는지, 어떤 역량에 평가가 필요한지, 어떤 항목이 향후 약속으로 남아 있는지 기록하세요. 구매를 승인하는 사람과 함께 시스템을 운영하고 복구할 사람도 포함하세요. 그 결과로 얻은 증거를 활용해 배포 모델을 비교하세요. 조직에 필요한 통제권을 제공하면서 현실적으로 감당할 수 있는 책임을 수반하는 옵션은 무엇입니까?