Microsoft Copilot Harness, Foundry를 통해 공개… 구축·구매 결정의 지형 바꾼다

Microsoft는 10월 28일 Foundry를 통해 Microsoft Copilot harness를 공개하며, 운영 주도권은 유지한 채 내부 실행 기반을 개발자에게 확장했다. harness는 AI 모델을 둘러싸고 지침, 컨텍스트, 도구, 실행을 구성하는 소프트웨어다. 이번 발표는 기업이 직접 구축하는 대신 구매할 수 있는 범위를 넓히지만, 그 결과물에 대한 책임까지 없애지는 않는다.

핵심 선택지는 이 실행 체계를 내부에서 유지할지, 아니면 Microsoft의 관리형 접근 방식을 도입할지다. 모델과 도구를 활용해 작업을 수행하는 소프트웨어인 에이전트는 성능 좋은 모델에 접근하는 것만으로는 충분하지 않다. 누군가는 에이전트가 어떻게 작업을 이어가고, 실패를 어떻게 처리하며, 비즈니스 경계 안에 머물도록 할지를 결정해야 한다.

Anthropic도 이미 경쟁하는 관리형 접근 방식을 제공하고 있어, 구매자에게 Microsoft 제품군 밖의 유용한 기준점을 제시한다. Microsoft의 차별화된 제안은 공유 인프라를 통해 서로 다른 모델 계열에 접근할 수 있다는 점에 초점을 둔다. 개발팀에는 실무적인 질문이 제기된다. 어떤 책임은 위임하기 쉬워지고, 어떤 책임은 여전히 애플리케이션별 판단을 요구할까?

Microsoft Copilot Harness, Foundry 공개 미리 보기로 진입

Microsoft는 공통 제품 기반을 고객 애플리케이션을 위한 관리형 구성 요소로 전환하고 있다.

Microsoft의 멀티모델 harness 발표에 따르면, GitHub의 엔지니어링 팀은 Microsoft가 이를 Copilot 경험 전반에 도입하기 전에 harness를 개발했다. Microsoft는 Copilot Code, Copilot Studio, GitHub Copilot app, 명령줄 인터페이스, VS Code를 사용 사례로 꼽았다.

에이전트를 구축하고 운영하는 Microsoft의 플랫폼인 Foundry Agent Service는 이제 공개 미리 보기로 harness를 제공한다. 이 상태는 기존의 내부 기술과 새롭게 제공되는 관리형 서비스를 결합한다는 점에서 중요하다. Microsoft 제품 안에서 축적된 경험이 모든 외부 고객 워크로드에 대한 준비 상태를 자동으로 입증하는 것은 아니다.

Microsoft는 실행 체계는 자사가 운영하고, 고객은 애플리케이션별 지침과 연결을 제공하는 책임 분담 방식을 설명한다. 이 구조는 출시의 의미를 코딩 어시스턴트 너머로 확장한다. 리서치 어시스턴트나 운영 에이전트를 개발하는 기업은 이전까지 내부 엔지니어링 업무로 여겨졌던 인프라를 구매하는 방안을 검토할 수 있다.

이번 발표는 애플리케이션에 기술을 통합하기 위해 개발자가 사용하는 패키지인 다운로드 가능한 소프트웨어 개발 키트도 설명한다. 이 경로를 관리형 Foundry 경험과 혼동해서는 안 된다. 배포 방식을 선택하는 일과 서비스를 누가 운영할지 선택하는 일은 관련돼 있지만, 서로 다른 질문에 답한다.

기업 구매자에게 즉각적인 변화는 구현 선택지가 하나 더 생겼다는 점이다. 에이전트를 평가하는 팀은 더 이상 여러 모델을 지원하려면 자체 실행 시스템을 반드시 유지해야 한다고 가정할 필요가 없다. Microsoft는 고객을 대신해 이 공통 기반을 유지하겠다고 제안하고 있다.

이 제안은 정확하게 읽을 필요가 있다. 관리형 harness를 구매한다고 해서 특정 워크플로가 정확한 답변이나 적절한 조치를 만들어낸다는 사실이 입증되는 것은 아니다. 이는 체계의 일부를 누가 제공하는지를 바꾼다. 구매자는 완성된 애플리케이션이 자체 요구 사항을 충족한다는 증거를 여전히 확보해야 한다.

공급업체 발표를 비교하고 내부 브리핑을 준비하는 가상의 리서치 애플리케이션을 생각해 보자. 유용한 결과물에는 정확한 출처, 명확한 날짜, 상충하는 정보에 대한 명시적 처리가 포함된다. 제대로 작동하는 실행 시스템은 이 작업을 지원하지만, 조직을 대신해 그러한 편집 요구 사항을 정의할 수는 없다.

따라서 이번 출시는 아키텍처 논의의 출발점을 바꾼다. 팀은 단순히 어떤 모델이 요청에 답해야 하는지만 묻는 대신, 에이전트 실행의 어느 부분이 맞춤형 엔지니어링에 적합한지 물을 수 있다. 이는 선택 메뉴에 다른 모델이 나타나는지보다 훨씬 더 중요한 질문이다.

자체 실행 체계를 유지하는 팀에 압박이 가해진다

Microsoft의 제안은 내부 인프라 프로젝트를 면밀히 검토하게 만든다. 특히 비즈니스 이점 없이 기능을 재현하는 프로젝트가 그렇다.

가장 큰 압박은 이미 에이전트용 주변 체계를 유지하고 있는 애플리케이션 팀에 가해진다. 이들의 관리자는 이제 검토할 외부 대안을 갖게 됐다. 맞춤형 구현을 계속하는 일은 에이전트를 출시하기 위한 당연한 전제 조건이 아니라, 정당화가 필요한 결정이 된다.

그 정당화는 여전히 설득력 있을 수 있다. 기업은 특이한 실행 동작, 전문화된 통합, 또는 작업 진행 방식에 대한 직접적 통제를 필요로 할 수 있다. 중요한 구분은 그러한 요구 사항이 애플리케이션에 실질적인 영향을 주는지다. 조직이 그 통제로 무엇을 달성하는지 명확히 설명할 수 있다면 맞춤형 소유가 더 타당하다.

인프라를 구매하면 다른 의무가 생긴다. 바로 제공업체의 경계를 이해하는 일이다. 개발팀은 데모에서 보이는 기능만으로 관리형 서비스를 평가할 수 없다. 플랫폼이 끝나는 지점과 자사 소프트웨어, 절차, 감독이 시작되는 지점을 파악해야 한다.

Microsoft의 관리형 에이전트 실행 발표는 skills, 연결된 도구, 파일 및 코드 실행, 제한된 위임을 설명한다. skills는 지침과 보조 리소스로 구성된 재사용 가능한 절차다. 도구는 에이전트에게 외부 정보나 작업에 대한 접근 권한을 제공한다. 이러한 기능은 텍스트 생성만을 넘어선 더 폭넓은 애플리케이션 기반을 보여준다.

같은 발표에는 초기 고객의 관점도 담겼다. Confluence Technologies의 최고기술책임자 Chris Evans는 회사가 일주일도 안 돼 솔루션을 가동했다고 말한다. 이는 유용한 구현 사례이지만, 일반적인 배포 일정이나 장기 운영 성과를 입증하지는 않는다.

구매자에게 중요한 구분은 초기 작동 상태에 도달하는 것과 신뢰할 수 있는 서비스를 유지하는 것 사이에 있다. 내부 프로토타입은 운영 애플리케이션이 감당할 수 없는 가정을 허용할 수 있다. 관리형 기반은 일부 엔지니어링 작업을 단축할 수 있지만, 통합 검토, 수용 기준, 소유권 결정은 여전히 해결되지 않은 채 남는다.

따라서 유용한 재무 비교는 단일 모델 응답이 아니라 전체 워크플로를 살펴봐야 한다. 관련 고려 사항에는 엔지니어링 유지보수, 실패 조사, 사람의 검토, 연결된 시스템의 변경이 포함된다. 이러한 책임은 조직마다 다르므로, 이번 출시만으로 보편적인 계산식이 도출되지는 않는다.

압박은 모델 주변 제품을 제공하는 인프라 벤더에도 미친다. Microsoft의 배포 방식은 고객이 어떤 별도 구성 요소를 실제로 필요로 하는지 다시 묻게 하는 또 하나의 이유가 된다. 그렇다고 독립 제품이 불필요해진다는 뜻은 아니다. 이들이 제공하는 추가적인 통제, 가시성, 전문성을 설명하는 기준이 높아진다는 의미다.

지식 근로자에게는 다른 형태로 영향이 나타난다. 이들은 에이전트가 사용할 수 있는 결과물을 완성하는지, 적절한 근거를 보존하는지, 불확실성을 적절히 상향 처리하는지를 경험한다. 아키텍처 변화는 미완성 작업을 줄이거나 실수를 더 쉽게 식별하고 수정하게 할 때 이들에게 의미가 있다.

이 때문에 구축·구매 논의에는 엔지니어뿐 아니라 제품 책임자도 참여해야 한다. 조직은 어떤 인프라 구성이 이를 제공할지 결정하기 전에 만족스러운 결과를 정의해야 한다. 그렇지 않으면 기술적으로 성공한 배포가 실제 비즈니스 문제를 상당 부분 그대로 남길 수 있다.

모델 선택과 런타임 제어는 별개의 결정이다

서로 다른 모델에 접근할 수 있다고 해서 고객이 관리형 서비스의 작업 실행 방식을 무제한으로 통제할 수 있는 것은 아니다.

Microsoft의 harness 제공 FAQ는 미리 보기의 경계를 명확히 한다. 자체 모델 가져오기 지원은 제공되지 않는다. 고객은 새 prompt agent를 만들 때 harness를 선택하며 이후 이를 전환할 수 없다. 제공 가능 여부는 지역, 클라이언트, 도구, 네트워킹, 할당량에 따라 달라질 수도 있다.

이러한 제한은 멀티모델 지원의 의미를 분명히 한다. 고객은 서비스 경계 안에서 지원되는 선택지를 평가할 수 있다. 이는 더 넓은 전략이 선택권을 강조한다는 이유만으로 어떤 모델, 연결 또는 배포 구성도 작동할 것이라고 가정하는 것과는 다르다.

이 구분은 조달 과정에서 중요하다. 벤더 포트폴리오의 다른 위치에 모델이 존재한다고 해서 특정 관리형 경험에서 지원된다는 답이 되지는 않는다. 구매자는 관련 배포 위치와 연결된 시스템을 포함해 실제로 사용할 조합을 평가해야 한다.

모델을 바꾸는 일과 애플리케이션 동작을 유지하는 일 사이에도 구분이 있다. 인터페이스가 일관되게 유지되더라도 다른 모델은 다른 판단이나 결과를 낼 수 있다. 애플리케이션 소유자는 모델 변경을 관리상 단순 교체가 아니라 비즈니스 요구 사항에 따라 평가해야 할 사안으로 다뤄야 한다.

공급업체 제안을 검토하는 가상의 조달 어시스턴트를 생각해 보자. 한 작업은 납기일을 추출하는 일이다. 다른 작업은 모호한 계약 해지 조항을 해석하는 일이다. 조직은 이 활동들에 서로 다른 모델 특성을 선호할 수 있지만, 허용 가능한 근거와 상향 처리에 대한 일관된 정의는 여전히 필요하다.

공유 실행 기반은 이러한 비교를 더 쉽게 구성하게 할 수 있다. 그렇다고 동일한 지침이 지원되는 모든 모델에서 똑같이 잘 작동한다는 사실이 입증되는 것은 아니다. 유용한 결과는 무엇이, 왜 바뀌었는지에 대한 명확한 기록과 함께 결과를 비교할 수 있는 통제된 기회다.

Anthropic의 관리형 에이전트 아키텍처는 적절한 경쟁 비교를 제공한다. 2026년 4월의 엔지니어링 설명은 모델과 harness를 실행 환경 및 영속 세션 기록에서 분리하는 방식을 다룬다. 제시된 목표는 안정적인 인터페이스 뒤에서 구현이 발전할 수 있도록 하는 것이다.

이 비교는 업계 경쟁이 모델 선택을 넘어서는 이유를 보여준다. 제공업체들은 고객이 신뢰할 수 있는 인터페이스를 보존하면서도 어떤 실행 책임을 흡수할 수 있는지를 두고 경쟁하고 있다. 여러 모델 계열을 강조하는 Microsoft의 접근은 이 더 넓은 구매 결정의 한 차원을 다룬다.

어느 아키텍처 설명도 보편적인 승자를 입증하지는 않는다. 관리형 접근 방식 중 하나를 선택하는 기업은 실제 워크플로, 필요한 통합, 운영 제약을 비교해야 한다. 한 애플리케이션에 잘 맞는 서비스가 다른 애플리케이션에는 부적절한 가정을 강요할 수 있다.

더 깊은 상충 관계는 유연성이 어디에 위치하는지에 관한 것이다. 팀은 제공업체의 실행 설계를 수용하면서 지원되는 모델 간 선택권을 유지할 수 있다. 또는 더 많은 실행 통제를 보존하고 그 유지 책임을 맡을 수 있다. 이는 서로 다른 엔지니어링 결과를 수반하는 별개의 유연성 형태다.

Microsoft Copilot harness에 대한 가장 현실적인 해석은 따라서 제한된 선택지라는 것이다. 고객은 에이전트 개발을 위한 추가적인 관리형 경로를 얻는다. 이들은 더 폭넓은 브랜딩을 범용 호환성의 약속으로 받아들이기보다, 문서화된 기능을 기준으로 해당 경로를 평가해야 한다.

Microsoft의 평가 개선은 신중한 해석이 필요하다

Microsoft의 내부 결과는 추가 평가를 뒷받침하지만, 모든 Foundry 애플리케이션에서 동등한 개선을 입증하지는 않는다.

Microsoft는 에이전트 평가 결과에서 Copilot Studio의 Copilot harness를 Standard harness와 비교한다. OpenAI 모델에서는 통과율이 10.8%포인트, Anthropic 모델에서는 22.1%포인트 향상됐다고 보고했다.

Microsoft는 또한 평가된 사례 중 84~91%에서 도구 호출 실패 이후에도 시도가 이어졌다고 보고했으며, Standard harness를 사용했을 때는 그 비율이 7% 미만이었다. 함께 제공된 설명은 지속적인 도구 사용 및 성공적인 재시도와 전체 작업의 성공적인 완료를 명시적으로 구분한다. 이는 여기서 독립적인 검증이 확립되지 않은 회사 자체 보고 결과다.

이러한 단서는 발표를 해석하는 데 핵심적이다. 지속성은 문제가 발생한 뒤의 행동을 설명한다. 완료는 요청된 결과에 도달했는지를 설명한다. 시스템은 계속 작업할 수 있지만 여전히 작업을 잘못 이해하거나, 부적절한 근거를 사용하거나, 받아들일 수 없는 결과를 낼 수 있다.

가상의 고객 서비스 워크플로를 생각하면 이 차이는 구체적이다. 에이전트는 사례 기록에 대한 접근을 성공적으로 재시도할 수 있지만, 여전히 잘못된 해결책을 권고할 수 있다. 실패한 연결로부터의 복구를 측정하면 실행 동작을 설명하는 데 도움이 된다. 그러나 고객이 정확한 답변을 받았는지를 판정하지는 못한다.

마찬가지로 더 높은 평가 통과율은 평가가 무엇을 묻는지에 따라 달라진다. 구매자는 결과를 자신의 환경에 적용하기 전에 관련 작업, 수용 기준, 구성 방식을 이해해야 한다. 퍼센트포인트 개선은 그것이 측정한 테스트와의 관계 속에서만 유의미한 정보가 된다.

이는 주변 실행 시스템의 중요성을 낮추는 것이 아니다. Microsoft가 보고한 비교는 모델 역량만으로 에이전트의 결과가 결정되지는 않는다는 주장과 일치한다. 이는 고객이 귀속 관계와 한계를 명확히 유지하면서 모델 선택과 함께 실행 선택지를 시험할 이유를 제공한다.

Microsoft는 또한 2026년 8월에 완전 자율 해결률이 35%를 넘은 내부 지원 애플리케이션을 설명한다. 회사는 이 지표를 사람의 개입 없이 사례를 해결하는 비율로 정의한다. 이는 구체적으로 보고된 배포 사례이지만, 비교 기준으로서의 적합성은 사례와 운영 조건에 따라 달라진다.

유사한 애플리케이션을 평가하는 기업이라면 자율성을 정확성과 결과의 영향과 함께 고려해야 한다. 개입 없이 해결된 사례는 해결이 정확하고 적절하다면 유용한 근거가 될 수 있다. 개입이 없었다는 사실만으로 결과가 조직의 기준을 충족했다고 입증할 수는 없다.

평가는 검토자에게 이전되는 업무도 고려해야 한다. 에이전트가 더 많은 자료를 만들어 내지만 상당한 수정이 필요하다면, 산출물 규모는 실제 기여도를 왜곡할 수 있다. 비즈니스 관점의 질문은 완료되고 수용 가능한 업무와, 이를 얻는 데 필요한 노력에 관한 것이다.

나중에야 드러나는 실패에도 같은 논리가 적용된다. 근거 없는 주장이 담긴 세련된 브리핑은 전달 시점에는 성공한 것처럼 보일 수 있다. 근거와 출처 표기를 점검하는 평가는 다른 결과를 드러낼 것이다. 수용 기준은 결과가 실제로 사용될 방식을 반영해야 한다.

현재 Microsoft의 수치는 자체 테스트 환경에 관한 유용한 근거다. 이는 고객별 테스트를 대체하지 않으면서 조사를 정당화한다. 구매자는 공급업체의 비교 결과를 보고된 평가에 포함되지 않은 워크로드의 전망으로 바꾸어 해석하지 않아야 한다.

관리형 실행 환경에서도 비즈니스 책임은 고객에게 남는다

인프라를 위임한다고 해서 에이전트가 수행하도록 허용할 업무를 결정하는 책임까지 이전되는 것은 아니다.

가장 분명한 경계는 중대한 결과를 수반하는 행동에 있다. 권고안을 준비하는 에이전트와 조직이 그 권고안을 실행하도록 확정하는 에이전트에는 서로 다른 통제가 필요하다. 관리형 실행 서비스는 두 설계를 모두 지원할 수 있지만, 권한이 어디서 시작하고 끝나는지는 조직이 결정해야 한다.

Fashable은 Microsoft의 출시 자료에서 고객 관점을 제시한다. 최고경영자 Orlando Ribas Fernandes는 상업적으로 구속력 있는 결정은 사람의 통제 아래 두면서 소싱 워크플로와 관련된 기회를 설명한다. 이는 제안된 모든 기능이 이미 측정 가능한 결과를 냈다는 증거가 아니라, 의도된 운영 경계다.

이 사례는 자동화만으로 책임성을 추론할 수 없는 이유를 보여 준다. 소싱 지원 도우미는 사양을 비교하고, 누락된 정보를 식별하거나, 협상 자료를 준비할 수 있다. 구매를 승인하는 일은 다른 책임을 수반한다. 이러한 구분은 활동들이 하나의 대화 안에 나타나더라도 분명히 유지되어야 한다.

장기 실행 업무는 또 다른 경계를 만든다. 즉, 무슨 일이 있었는지를 기억하는 것과 무엇이 여전히 유효한지를 아는 것의 차이다. 에이전트는 상황이 달라졌다는 사실을 모른 채 이전 결과를 보존할 수 있다. 애플리케이션 소유자는 이전 정보에 언제 재검토가 필요한지와 어떤 결정이 최신 근거에 의존하는지를 정해야 한다.

Anthropic의 장기 실행 에이전트 연구는 세션 전반에서 발생하는 미완료 작업과 성급한 완료 선언 관련 실패를 설명한다. 이들이 제안하는 접근 방식은 명시적인 진행 기록과 점진적 작업을 사용한다. 더 넓은 교훈은 지속적인 실행에 미완료 의무를 신뢰성 있게 파악하는 체계가 필요하다는 점이다.

기업에는 이 교훈이 완료를 비즈니스 조건으로 다루어야 한다는 뜻을 시사한다. 작업은 필요한 검토나 확인을 포함한 수용 기준이 충족될 때 끝난다. 자신감 있는 최종 메시지는 그러한 조건이 충족됐다는 근거를 대신할 수 없다.

중단된 작업을 다시 시작할 때도 관련된 우려가 생긴다. 보고서를 준비해 다른 시스템에 제출하는 가상의 에이전트를 상상해 보자. 제출은 성공했지만 확인 정보가 사라진 경우, 같은 작업을 반복하면 중복 기록이 만들어질 수 있다. 애플리케이션에는 미완료 작업과 확인되지 않은 작업을 구분할 방법이 필요하다.

Microsoft는 고객이 자체 실행 로직을 가져오는 호스팅 에이전트를 위한 장기 실행 복원력의 정식 출시도 별도로 발표했다. 해당 문서는 저장된 진행 상황과 중복 방지의 책임을 애플리케이션 코드에 둔다. 이 별도 기능을 새 harness 미리 보기의 포괄적 보장으로 간주해서는 안 된다.

정보 품질은 또 다른 책임을 만든다. 오래된 지침에 연결된 에이전트는 지시를 일관되게 실행하더라도 부적절한 작업을 만들 수 있다. 검색 가능한 지식 기반을 고려하는 팀은 소스 구성과 유지 관리를 애플리케이션의 일부로 다뤄야 한다.

이 관계는 특정 통합을 암시하지 않으면서도 지식 관리를 이번 출시와 관련 있게 만든다. 인프라는 작업이 진행되는 방식을 결정하고, 이용 가능한 근거는 에이전트가 합리적으로 내릴 수 있는 결론을 제한한다. 한쪽을 개선한다고 해서 다른 쪽의 약점이 사라지지는 않는다.

따라서 조직은 전체 워크플로 전반에 걸쳐 소유권을 할당해야 한다. 누군가는 소스 자료, 권한, 수용 기준, 그리고 결과가 실패했을 때의 수정에 책임을 져야 한다. 관리형 실행은 엔지니어링 부담을 바꿀 수는 있지만, 이러한 조직적 결정을 없애지는 않는다.

가장 신뢰할 만한 도입 사례는 제공업체가 흡수하는 업무와 고객이 유지하는 의무를 모두 식별한다. 이러한 명확성은 서비스가 전체적으로 복잡성을 줄이는지 판단하기 쉽게 만든다. 또한 성공적인 프로토타입이 아무도 완전히 소유하지 않는 애플리케이션으로 바뀌는 일을 막는다.

관리형 접근 방식의 성과를 보여 줄 세 가지 신호

다음으로 유용한 근거는 추가적인 출시 주장이 아니라 서비스 성숙도, 비교 결과, 고객 운영에 관한 것이다.

첫 번째 신호는 Microsoft가 향후 몇 달 동안 Foundry 미리 보기를 어떻게 발전시키는가다. 구매자는 더 명확한 제공 범위, 지원 구성, 마이그레이션 옵션, 운영 환경 지침을 살펴봐야 한다. 더 폭넓게 문서화된 지원은 더 많은 애플리케이션에 공통 관리형 기반을 도입해야 한다는 근거를 강화할 것이다.

가장 의미 있는 확장은 현재 실제 배포를 막고 있는 요구 사항을 해결하는 것이다. 또 다른 지원 구성은 조직이 기술적·비즈니스적 제약 안에서 운영할 수 있게 해 줄 때 중요하다. 기능 목록이 길어진다는 사실만으로 특정 애플리케이션이 실현 가능해졌는지는 알기 어렵다.

미리 보기 제한이 고객의 의도된 환경에서 여전히 상당하다면, 그 고객에게 즉시 도입해야 할 근거는 약해진다. 이는 워크로드별 판단이다. 한계는 연구 프로토타입에는 중요하지 않을 수 있지만, 민감한 운영 시스템에 연결된 애플리케이션에는 결정적일 수 있다.

두 번째 신호는 모델 변경과 실행 변경을 구분하는 비교 근거다. 평가는 어떤 구성 요소가 바뀌었는지와 성공을 어떻게 측정했는지를 명확히 해야 한다. 그러면 구매자는 보고된 이점이 harness, 모델, 또는 둘 사이의 상호작용에서 비롯된 것인지 판단할 수 있다.

특히 실패 범주와 검토 요건을 공개한다면 독립적 평가는 신뢰를 더할 것이다. 완료된 업무에 초점을 둔 비교는 활동에만 초점을 둔 비교보다 Microsoft의 주장을 더 직접적으로 뒷받침할 것이다. 구성 의존성이 크다는 결과는 이 주장을 얼마나 넓게 적용할 수 있는지를 제한할 것이다.

경쟁 환경의 변화도 같은 비교 안에서 중요하다. Anthropic의 관리형 서비스나 다른 제공업체의 실행 방식 변화는 이용 가능한 대안을 바꿀 수 있다. 구매자는 변화하는 시장이 평가를 끝없는 기능 추격으로 바꾸지 않도록, 안정적인 애플리케이션 요구 사항을 기준으로 서비스를 비교해야 한다.

세 번째 신호는 초기 배포 속도를 넘어선 고객 보고다. 유용한 사례는 지속적인 운영, 수용 가능한 결과, 수정 노력, 그리고 고객에게 남은 책임을 설명할 것이다. 신뢰할 수 있는 결과와 함께 유지 관리 부담이 낮아졌다는 근거는 공용 실행 계층을 구매해야 한다는 주장을 강화할 것이다.

광범위한 맞춤 작업에 관한 사례는 더 신중한 해석이 필요하다. 맞춤화는 가치 있는 비즈니스 특수화를 반영할 수도 있고, 관리형 서비스의 공백을 반영할 수도 있다. 고객이 작성한 코드의 양을 단순히 세는 것보다 어느 설명이 적용되는지 이해하는 일이 더 중요하다.

이러한 신호는 이전 결정을 다시 검토하는 실용적인 방법도 제공한다. 팀은 오늘 자체 실행 시스템을 구축하고 나중에 관리형 서비스를 도입하는 것이 합리적일 수 있다. 또 다른 팀은 관리형 인프라로 시작해, 그 방식이 계속해서 요구 사항을 충족하는 동안에만 이를 유지할 수 있다.

Microsoft Copilot 하니스를 조직이 잘 이해하는 워크플로에 적용해 평가하세요. 허용 가능한 결과를 정의하고, 승인이 필요한 작업을 식별하며, 사람의 수정이 여전히 필요한 지점을 기록하세요. 동일한 근거와 완료 기준을 사용해 관리형 옵션을 기존 접근 방식과 비교하세요. 출처의 품질, 복구 동작, 실수 조사에 필요한 노력도 포함하세요. 의사 결정은 팀이 실제로 위임할 수 있는 책임에 기반하도록 하고, 문서화된 지원 범위와 고객 사례가 축적됨에 따라 다시 검토하세요. Microsoft의 출시는 전체 실행 기반을 내부적으로 유지하는 방식에 대한 구체적인 대안을 제시합니다. 다음으로 유용한 단계는 그 대안이 자체 워크플로의 어떤 부분을 개선하는지, 그리고 어떤 근거가 의사 결정을 바꿀 수 있는지를 명확히 하는 것입니다.