OccupySaaS 오픈소스 대체재, Auth0와 Salesforce 겨냥
OccupySaaS는 AI를 활용해 Auth0와 Salesforce의 대안을 구축하며, 두 개의 공개 프로젝트로 구독형 소프트웨어에 도전하고 있다. OccupySaaS의 오픈소스 대체재는 기존 통합을 유지하면서 고객이 기반 서비스를 직접 운영할 수 있도록 하는 것을 목표로 한다. 이들의 야심은 익숙한 인터페이스를 넘어선다. 이미 자리 잡은 공급업체를 떠나는 비용과 기술적 부담을 줄이려는 것이다.
프로젝트는 아이덴티티 서버인 ZeroAuthy와 고객 기록 및 영업 활동을 관리하는 고객 관계 관리 시스템 SalesCompel이다. 어느 쪽도 기업이 내일 당장 현재 공급업체를 떠날 수 있음을 입증하지는 않는다. 당면한 긴장은 소프트웨어 독립성이라는 매력적인 약속과 비즈니스 인프라 운영의 책임 사이에 있다.
이 구분이 이 이야기의 방향을 결정한다. AI 지원 구현은 개발 작업을 단축할 잠재적 수단을 제공하고, 호환성 약속은 마이그레이션 작업을 줄이려 한다. 기존 공급업체들은 그 이후의 영역, 즉 안정성, 보안, 지원, 그리고 고객이 의존해 온 축적된 동작을 놓고 여전히 경쟁한다.
OccupySaaS 오픈소스 대체재, 선언문을 넘어 움직이다
Tom’s Hardware는 11월 4일 AI 소프트웨어 복제를 다룬 보도에서 이 이니셔티브를 조명했다. 해당 보도는 독점 서버 코드에 접근하는 대신 공개 문서와 관찰 가능한 동작을 기반으로 한 독립적 구현이라고 설명한다.
이 시점이 중요한 이유는 이 이니셔티브가 이제 단순한 의향 표명보다 더 구체적인 결과물을 갖췄기 때문이다. 프로젝트의 현재 릴리스 정보에 따르면 ZeroAuthy는 11월 4일 첫 릴리스 후보 버전에 도달했다. 릴리스 후보 버전은 최종 릴리스 전에 평가를 위해 제공되는 버전이지, 운영 준비 완료를 보장하는 것은 아니다.
SalesCompel은 아직 개발 초기 단계에 머물러 있다. 두 프로젝트를 동일한 수준으로 성숙했다고 판단하면 그 유용성을 평가하는 사람에게 중요한 차이를 가리게 된다. 하나의 운동은 공동의 사명을 선언할 수 있지만, 개별 프로젝트는 매우 다른 속도로 발전할 수 있다.
변화는 평가할 수 있는 소프트웨어를 이용할 수 있게 됐다는 점이지, 기존 서비스가 이미 대체됐다는 증거가 아니다.
이는 의미 있는 기준점이다. 공개 소프트웨어는 외부 개발자에게 주장을 조사하고, 실패를 재현하며, 누락된 동작을 식별할 기회를 제공한다. 선언문은 독자에게 주장에 동의해 달라고 요청하지만, 구현체는 독자가 직접 검증하고 이의를 제기할 대상을 제공한다.
“드롭인 대체재”라는 표현은 기준을 한층 더 높인다. 이는 주변 수정 없이 다른 시스템을 대체할 수 있도록 설계된 소프트웨어를 뜻한다. 비즈니스 구매자에게는 낯선 제품을 중심으로 모든 통합을 다시 구축하는 것보다, 불만에서 행동으로 이어지는 경로가 더 짧다는 의미가 될 수 있다.
하지만 이 주장은 범위를 명확히 해야 한다. 호환성은 특정 작업, 특정 클라이언트 라이브러리 또는 정의된 워크플로에 적용될 수 있다. 원래 공급업체의 이름을 단 모든 기능으로 자동 확장되는 것은 아니다.
따라서 이 발표를 읽는 유용한 방식은 구체적이어야 한다. OccupySaaS는 선택된 의존성을 이식 가능하게 만들 수 있는지 시험할 기회를 만들었다. Auth0나 Salesforce를 둘러싼 완전한 운영 환경이 서로 대체 가능하다는 점을 입증한 것은 아니다.
이 구분은 항의의 언어가 기술적 증거의 역할을 대신하지 못하게 한다. 독자는 구현에 대해 엄격한 질문을 던지면서도 더 큰 소프트웨어 소유권이라는 목표를 지지할 수 있다. 조직이 실제로 유지할 수 있는 대안을 목표로 할 때, 이 두 입장은 서로를 강화한다.
압박은 떠나는 비용에 가해진다
구독 서비스에 대한 불만은 고객에게 신뢰할 만한 대안이 있을 때에만 경쟁 압력으로 이어진다. 구매자는 갱신 조건이 마음에 들지 않아도, 이전이 애플리케이션을 중단시키거나 직원을 혼란스럽게 하거나 엔지니어링 시간을 소모할 수 있기 때문에 남을 수 있다.
OccupySaaS는 이 간극을 겨냥한다. 이들의 전략적 전제는 조직이 기존 소프트웨어 연결을 보존할 수 있을 때 대안이 더 매력적으로 변한다는 것이다. 기존 사업자에 대한 도전은 완전히 다른 워크플로를 발명하겠다는 약속보다 떠나는 비용에 초점을 맞춘다.
애플리케이션 프로그래밍 인터페이스, 즉 API는 소프트웨어가 다른 시스템과 통신하는 데 사용하는 요청의 집합이다. 대안이 예상된 요청을 받아들이고 사용할 수 있는 응답을 반환하면, 주변 코드의 더 많은 부분을 그대로 유지할 수 있다. 이는 이전을 평가하는 데 필요한 작업을 잠재적으로 줄인다.
외부 아이덴티티 공급자에 고객 로그인을 위임하는 예시 애플리케이션을 생각해 보자. 이 의존성을 관련 없는 시스템으로 교체하려면 개발자가 애플리케이션의 통합을 다시 작성해야 할 수 있다. 반면 호환 가능한 대안은 목적지만 바꾸면서 해당 통합을 유지하는 것을 목표로 한다.
고객 기록을 생성하는 영업 통합에도 같은 논리가 적용된다. 예상된 작업이 계속 제공된다면, 팀은 전체 연결을 먼저 교체하지 않고도 대안을 조사할 수 있다. 그 결과 워크플로가 실제로 작동하는지는 여전히 테스트가 필요하다.
경쟁 위협은 탈출이 단지 상상 가능한 일이 아니라 실행 가능한 일이 될 때 커진다.
이 때문에 광범위한 도입이 입증되기 전에도 이 프로젝트들은 주목할 가치가 있다. 신뢰할 만한 탈출 경로는 구매자의 협상 위치를 바꿀 수 있다. 그러나 현재 이용 가능한 증거는 OccupySaaS가 이미 광범위한 마이그레이션을 이끌었거나 상업적 양보를 강제했다는 점을 보여주지 않는다.
압박도 균일하지 않다. 의존성이 제한적인 회사는 수년간의 맞춤화가 축적된 조직과 다른 평가 문제를 안고 있다. 비슷한 제품 명칭은 매우 다른 전환 요건을 숨길 수 있다.
기존 사업자에게 암시되는 대응은 지속적인 서비스를 선택할 만한 가치가 있도록 만드는 것이다. 여기에는 까다로운 작업 처리, 통합 유지, 장애 해결이 포함된다. 대안이 선택된 소프트웨어 동작을 재현할 수 있더라도 이러한 장점은 여전히 중요하다.
구매자에게 비교는 구독 서비스와 무료 코드의 단순한 대립보다 더 까다로워진다. 이들이 받는 서비스와 책임 있게 운영할 수 있는 대체재를 비교해야 한다. 공급업체 관계를 제거하는 일은 남은 의무가 조직에 맞을 때에만 가치를 만든다.
따라서 OccupySaaS의 오픈소스 대체재는 감정적인 논쟁에 실질적인 질문을 던진다. 어떤 의존성이 진정으로 이식 가능한가? 답은 기업, 애플리케이션, 그리고 같은 기업 내 부서마다 달라질 것이다.
이 때문에 포괄적인 예측은 시기상조다. 이 이니셔티브의 초기 상업적 의미는 정의된 워크로드에 대해 입증된 탈출 경로가 될 것이다. 그러한 종류의 증거는 모든 곳에서 구독형 소프트웨어를 대체할 수 있다는 광범위한 주장보다 더 큰 무게를 가질 것이다.
AI는 구현을 가속할 수 있지만, 호환성이 작업을 규정한다
이 프로젝트는 허용된 공개 정보를 바탕으로 독립적인 구현을 개발하는 클린룸 프로세스를 설명한다. 명세 작성자와 구현 담당자를 분리하고, AI가 구현을 지원하며, 사람이 변경 사항을 검토한다고 밝힌다. 이는 모든 기여에 대한 독립적 감사를 거친 설명이 아니라, 프로젝트가 제시한 개발 안전장치다.
기술적 개념은 이를 자동적인 일로 취급하지 않고도 충분히 간단히 설명할 수 있다. 명세는 예상되는 동작을 설명한다. 구현 담당자는 그 명세를 충족하도록 소프트웨어를 만들고, 테스트는 결과물이 요구 사항에 맞게 동작하는지 조사한다.
AI는 목표가 제한돼 있기 때문에 이 구조 안에서 유용하다. 개발자는 코딩 시스템에 전체 비즈니스 제품을 발명하라고 요청하는 대신, 정의된 작업에 집중하도록 지시할 수 있다. 요구 사항이 좁을수록 결과물이 이를 충족하는지 점검하기 쉬워진다.
그렇다고 OccupySaaS의 측정 가능한 생산성 향상이 입증되는 것은 아니다. 검토된 출처는 개발 시간, 엔지니어링 노력 또는 총 제공 비용에 대한 독립 검증 비교를 제공하지 않는다. 가속에 관한 주장은 프로젝트와 그 지지자들에게 귀속된 상태로 남아야 한다.
더 빠른 구현은 기회를 만들고, 신뢰할 수 있는 호환성 정의는 그 기회가 유용해질지를 결정한다.
대체재는 애플리케이션이 의존하는 동작을 충족해야 하며, 여기에는 까다로운 사례도 포함된다. Tom’s Hardware는 호스팅 서비스에서 문서화되지 않은 동작을 재현하는 어려움을 강조한다. 문서화된 자료는 의도된 계약을 설명할 수 있지만, 실제 통합이 축적해 온 모든 가정을 포착하지는 못할 수 있다.
예를 들어 클라이언트가 특정 오류 응답을 기대한다고 하자. 대체재는 성공적인 요청을 올바르게 처리하면서도 그 오류가 발생하면 실패할 수 있다. 눈에 보이는 기능은 존재하는 것처럼 보이지만, 주변 애플리케이션은 여전히 다르게 동작한다.
다른 예로 재시도 후 성공하는 작업이 있다. 대체재가 반복 요청을 다르게 처리하면 통합이 일관되지 않은 결과를 만들 수 있다. 이는 두 OccupySaaS 프로젝트에서 보고된 결함이 아니라 평가 시나리오다.
이런 사례는 더 많은 코드를 생성하는 것이 불완전한 진척도 측정 기준인 이유를 설명한다. 더 큰 구현체도 핵심 가정을 해결하지 못할 수 있다. 반대로 동작이 명확히 문서화된 비교적 작은 구현체는 의도적으로 좁게 설정된 워크로드에 유용할 수 있다.
테스트 역시 해석이 필요하다. 통과 결과는 테스트가 실행된 조건에 적용된다. 구매자는 결과를 자신의 애플리케이션과 관련된 것으로 판단하기 전에 어떤 버전, 구성 및 작업이 다뤄졌는지 알아야 한다.
이는 프로그래밍 문제인 동시에 지식 문제다. 공개 참조 자료, 마이그레이션 가정, 테스트 결과, 예외 사항은 구현체가 바뀌어도 이해 가능한 상태로 유지돼야 한다. 대안을 평가하는 팀은 그러한 기술적 결정을 접근 가능하게 유지하는 검색 가능한 지식 베이스의 도움을 받을 수 있다.
더 넓은 함의는 AI가 엔지니어링 노력이 향하는 곳을 바꿀 수 있다는 점이다. 구현 초안 작성에 쓰는 시간이 줄어들면, 명세화, 검토, 운영 검증이 남은 작업에서 더 큰 비중을 차지하게 된다. 이 재배분이 신뢰할 수 있는 서비스를 만들어 내는지는 이제 이 프로젝트들이 외부인에게 검토하도록 요청하는 질문이다.
ZeroAuthy와 SalesCompel은 서로 다른 호환성 격차에 직면한다
ZeroAuthy에는 구체적인 외부 검증 항목이 있다. OpenID Foundation의 인증 공급자 레지스트리는 Basic OP, Config OP, Form Post OP 프로필에서 커밋 38b4229의 zeroauthy를 목록에 올리고 있다. OpenID Connect는 애플리케이션이 아이덴티티 공급자를 통해 신원을 확인할 수 있게 하는 표준이다.
이 목록은 범위를 유지한 채 인정할 만하다. 이는 지정된 프로토콜 프로필과 특정 코드 수정본에 관한 것이다. Auth0 기능 전체의 지원 범위, 성공적인 고객 마이그레이션, 또는 전체 시스템에 대한 독립 감사까지 입증하는 것은 아니다.
재단은 자체 테스트를 활용한 구현자의 자체 인증을 포함하는 적합성 인증 절차를 설명합니다. 적합성이란 표준에서 정의한 요구사항을 충족한다는 뜻입니다. 이는 상호운용성에 관한 유용한 근거이지만, 구매자는 여전히 운영 요구사항에 대한 별도의 근거가 필요합니다.
현재 프로젝트 사이트는 패스키와 엔터프라이즈 디렉터리 지원을 포함해 ZeroAuthy의 릴리스 후보에서 제외된 항목도 명시하고 있습니다. 또한 해당 소프트웨어가 아직 프로덕션 환경에 적합하지 않다고 분명히 밝힙니다. 개별 기능이 유망해 보이더라도 이 단서는 릴리스에 관한 논의에 계속 따라붙어야 합니다.
SalesCompel은 더 제한적인 출발점을 제시합니다. 공개 설명에는 영구적인 Account 및 Contact 작업, 제한된 쿼리, 관련 호환성 작업이 나열되어 있습니다. 레코드 생성, 읽기, 업데이트, 삭제는 맞춤화된 영업 조직 전체의 동작이 아니라 기반을 구축합니다.
이 프로젝트들은 “Auth0를 대체한다”와 “Salesforce를 대체한다”는 표현이 현재 근거가 뒷받침하는 범위보다 더 넓은 야망을 나타내므로 워크로드별 평가가 필요합니다.
유용한 비교 기준은 지원되는 작업과 실제 의존성 간의 차이입니다. ID 관리의 경우, 평가자는 조직의 조건에서 필요한 로그인 및 관리 동작이 작동하는지 물어야 합니다. 고객 레코드의 경우에는 데이터와 종속 워크플로가 이전 과정에서 어떻게 유지되는지도 포함됩니다.
가상의 영업 마이그레이션은 이것이 왜 중요한지 보여줍니다. 대체 시스템이 연락처를 성공적으로 저장할 수는 있지만, 조직의 승인 프로세스가 기대하는 동작은 제공하지 못할 수 있습니다. 레코드 작업은 작동하더라도 비즈니스 프로세스는 여전히 불완전합니다.
이는 그러한 공백이 영구적이라는 증거는 아닙니다. 다만 작게 구현된 기능 범위만으로 전체 플랫폼과의 동등성을 입증할 수 없는 이유를 설명합니다. 진전은 전혀 평가절하하거나 근거 없는 주장으로 확대하기보다, 입증된 수준에서 인정해야 합니다.
이 구분은 기여자들에게도 더 명확한 목표를 제시합니다. 정의된 워크플로에서 재현 가능한 실패는 실행 가능한 작업으로 이어질 수 있습니다. 성숙한 플랫폼을 따라잡으라는 광범위한 요구는 무엇이 “완료”를 뜻하는지에 대한 불확실성을 너무 많이 남깁니다.
ZeroAuthy와 Auth0를 비교하는 구매자에게 프로토콜 근거는 조사 출발점입니다. SalesCompel과 Salesforce를 검토하는 이들에게는 지원되는 레코드와 작업이 초기 테스트 경계를 정의합니다. 어느 비교도 즉각적인 전사적 마이그레이션을 권고할 근거는 제공하지 않습니다.
이 이니셔티브의 신뢰도는 이러한 차이를 보존할수록 높아질 것입니다. 명확한 한계는 평가자가 적절한 실험을 선택하고 유용한 결과를 보고할 수 있게 합니다. 모든 릴리스를 포괄적인 동등성으로 취급하면 소프트웨어는 평가하기 더 어려워지고, 주장은 기각하기 더 쉬워집니다.
구독을 없애면 운영 책임이 이전된다
가장 강력한 회의적 주장은 호스팅 서비스 뒤에 계속 필요한 작업에 관한 것입니다. 대안을 배포하면 조직은 더 많은 통제권을 얻지만, 유지보수, 복구, 접근 권한, 지원에 관한 결정도 맡게 됩니다.
Cybernews는 오픈소스 SaaS 대안 보도에서 양측의 관점을 제시합니다. Burrus Research의 Daniel Burrus는 AI가 소규모 팀의 대안 구축을 도울 수 있다고 주장합니다. Guardian Digital의 Dave Wreski는 유지보수, 보안, 신뢰성, 호환성의 지속적인 중요성을 강조합니다.
이러한 관점은 공존할 수 있습니다. 구현물은 만들기 쉬워질 수 있지만, 책임 있게 운영하는 데는 여전히 많은 비용이 들 수 있습니다. 소프트웨어 제작에 필요한 노력이 줄어든다고 해서 그것에 의존하는 데 필요한 노력도 같은 수준으로 줄어든다는 뜻은 아닙니다.
관련된 경제적 비교에는 구독이 사라진 뒤 실패의 책임을 누가 지는지가 포함됩니다.
바쁜 업무일 중 발생한 가상의 로그인 장애를 상상해 보십시오. 자체 ID 서비스를 운영하는 기업은 누가 조사하고, 누가 접근 권한을 복구하며, 누가 영향을 전달할지 결정해야 합니다. 소프트웨어에 라이선스 비용이 있든 없든 이러한 책임은 존재합니다.
고객 레코드 시스템에 업그레이드가 필요할 때도 비슷한 문제가 발생합니다. 누군가는 변경이 통합에 영향을 미치는지, 복구가 가능한지, 조직이 다운타임을 감당할 수 있는지 판단해야 합니다. AI가 생성한 패치만으로는 이러한 운영상의 질문에 답할 수 없습니다.
그렇다고 자체 호스팅이 비합리적인 선택이라는 뜻은 아닙니다. 통제의 가치는 조직이 이를 실행할 수 있는 역량에 달려 있다는 의미입니다. 적절한 운영 경험을 갖춘 팀은 인프라 책임을 피하려는 팀과 다른 절충안을 마주합니다.
소프트웨어 독립성과 모든 운영을 내부에서 수행하는 것은 서로 다릅니다. Tom’s Hardware는 Apache-2.0 라이선스 모델이 프로젝트 주변의 서비스 제공업체가 활동할 여지를 남긴다고 지적합니다. 호스팅 서비스는 아웃소싱 관계를 유지하면서도 선택 가능한 공급업체의 폭을 바꿀 수 있습니다.
이 가능성은 이 이니셔티브의 주장에 중요한 결과를 드러냅니다. 가장 지속적인 도전은 유료 소프트웨어 서비스의 소멸이 아니라, 더 큰 이식성과 공급업체 경쟁일 수 있습니다. 조직은 시스템 운영을 누군가에게 맡기는 비용을 계속 지불하면서도 탈출 선택지를 가치 있게 여길 수 있습니다.
개발 과정에도 또 다른 검증 공백이 있습니다. 공개된 클린룸 정책은 작업을 평가할 기준을 제공합니다. 하지만 그 자체만으로 모든 기여의 출처를 독립적으로 입증하거나 도입에 관한 모든 의문을 해결하지는 못합니다.
운동의 정체성에도 같은 절제가 적용됩니다. 해고된 엔지니어들에 대한 설명은 제시된 동기를 설명하지만, 활성 기여자 커뮤니티의 규모를 입증하지는 않습니다. 열의, 리포지터리 관심도, 지속적인 유지보수 역량은 서로 다른 척도입니다.
이러한 한계가 실험을 무의미하게 만드는 것은 아닙니다. 논의를 진전시키는 데 필요한 근거를 식별할 뿐입니다. 운영 경험, 투명한 유지보수, 재현 가능한 호환성 결과는 목표 목록을 또 한 번 확장하는 것보다 이 이니셔티브의 논거를 더 강하게 만들 것입니다.
독립 테스트, 마이그레이션 근거, 유지보수를 주시하라
향후 몇 달은 독립적인 호환성 결과, 문서화된 마이그레이션 경험, 지속적인 유지보수라는 세 가지 신호로 평가해야 합니다. 이 순서는 소프트웨어 동작에서 비즈니스 유용성으로, 그리고 지속적인 신뢰성으로 이어지는 경로를 따릅니다.
첫째, 독립적인 호환성 결과는 외부인이 중요한 주장을 재현할 수 있는지 보여줄 것입니다. 강력한 보고서는 테스트한 릴리스를 명시하고, 환경을 설명하며, 성공한 작업과 지원되지 않는 작업을 모두 식별합니다. 실패 역시 조사할 만큼 구체적이라면 유용합니다.
이는 평가를 프로젝트 설명에 덜 의존하게 함으로써 OccupySaaS 오픈소스 대체품에 대한 논거를 강화할 것입니다. 재현할 수 없는 주장이나 불명확한 테스트 경계는 이를 약화시킬 것입니다. 그에 상응하는 검증 없이 기능 목록만 늘어난다면 핵심 질문은 해결되지 않은 채 남습니다.
ZeroAuthy와 Auth0의 경우, 유용한 근거는 성공적인 로그인 시연을 넘어설 것입니다. 평가자는 어떤 필수 동작을 수행했고 비교가 어디에서 멈췄는지 설명해야 합니다. 프로토콜 적합성은 이를 대체하지 않으면서도 그 작업에 정보를 제공할 수 있습니다.
둘째, 문서화된 마이그레이션 경험은 호환되는 요청이 실현 가능한 이전으로 이어지는지 입증할 것입니다. 가장 강력한 사례는 출발 의존성, 지원되는 대상 환경, 그 사이에 필요한 작업을 설명할 것입니다. 또한 원래 제공업체에 무엇이 남았는지도 설명해야 합니다.
SalesCompel과 Salesforce의 경우 이 구분은 특히 중요합니다. 제한적인 통합이 성공적으로 이전됐다면 제한적인 결론을 뒷받침합니다. 그렇다고 영업 조직 전체의 프로세스, 권한, 과거 맞춤화가 이식 가능해졌다는 사실까지 입증하지는 않습니다.
프로덕션 도입 전에 문서화된 리허설을 수행하는 것 역시 가치가 있습니다. 이는 누락된 동작을 드러내고 남은 노력의 규모를 명확히 할 수 있습니다. 시연을 넘어서는 데 실패한다면 즉시 실용적인 탈출 경로라는 주장은 약화될 것입니다.
셋째, 지속적인 유지보수는 프로젝트가 자체 진전으로 발생하는 요구를 흡수할 수 있는지 보여줄 것입니다. 유용한 신호에는 이해하기 쉬운 릴리스, 재현 가능한 문제에 대한 신속한 대응, 구현 변경을 따라가는 문서가 포함됩니다. 핵심 질문은 기능과 함께 신뢰성이 발전하는지입니다.
결정적인 근거는 평가에서 운영으로 이어지는 반복 가능한 경로와, 이후 소프트웨어가 계속 유지보수될 수 있음을 보여주는 증거입니다.
이러한 신호는 기존 업체의 대응을 해석하는 데도 도움이 됩니다. 상업 조건의 변경은 그 대안과 연결하는 근거가 있을 때만 의미가 있습니다. 공급업체가 OccupySaaS를 공개적으로 인정했는지와 관계없이 지원이나 신뢰성에 대한 지속적 투자는 여전히 중요합니다.
이 운동은 핵심 명제에 대한 구체적인 시험을 열었습니다. 호환 가능한 소프트웨어는 고객에게 필수 의존성에 대한 더 많은 통제권을 제공할 수 있다는 것입니다. 현재 릴리스는 조사를 정당화하지만, 명시된 한계는 결과가 이미 확정된 것처럼 취급하는 일을 배제합니다.
OccupySaaS 오픈소스 대체품을 평가하고 있다면, 팀이 정확히 설명할 수 있는 의존성부터 시작하십시오. 실제 요구사항을 문서화된 릴리스와 비교한 뒤, 각 호환성 주장 뒤에 있는 근거를 살펴보십시오. 평가 전반에 걸쳐 마이그레이션 가정, 지원되지 않는 동작, 운영 책임을 계속 드러내 두십시오. 성공적인 시연은 복구, 업그레이드, 소유권에 관한 더 까다로운 질문으로 이어져야 합니다. 또한 무엇이 아직 테스트되지 않았는지에 대한 명확한 설명을 만들어야 합니다. 이 이야기를 따라가는 독자도 향후 발표에 같은 원칙을 적용해야 합니다. 독립적인 결과, 신뢰할 수 있는 마이그레이션 사례, 초기 관심 이후에도 지속되는 유지보수를 찾으십시오. 어떤 구체적인 워크로드가 귀사의 조직에 구독 제공업체를 떠나는 일이 실용적인 선택이 되었다고 확신시킬 수 있겠습니까?
