Microsoft Copilot Cowork 개발: 엔지니어 9명, 풀 리퀘스트 1,211건, 그리고 검증 병목

Microsoft는 10월 21일 Copilot Cowork 개발 과정에서 엔지니어 9명이 풀 리퀘스트 1,211건을 병합했으며, 코드 대부분은 에이전트가 작성했다고 밝혔다. 풀 리퀘스트는 통합 전에 검토를 위해 변경 사항을 제안하는 절차다. 이 구분은 중요하다. 헤드라인은 병합된 변경 건수를 측정하지만, 생산성은 그 변경의 유용성, 신뢰성, 유지보수 부담에도 좌우된다.

11월 2일 공개된 엔지니어링 사례는 팀이 소프트웨어를 명세하고, 검토하고, 운영하는 방식을 어떻게 바꾸고 있는지 설명한다. 핵심 긴장은 확대되는 구현 역량과 제한된 검증 역량 사이에 있다. 조직이 어떤 변경이 사용자에게 도달할 가치가 있는지 판단할 수 있을 때에만, 더 많은 변경을 생성하는 일이 가치를 만든다.

Anthropic의 에이전트 연구와 Google의 소프트웨어 딜리버리 연구는 Microsoft의 결과를 독립적으로 검증하지는 않지만 유용한 참고점이 된다. 두 연구 모두 AI 도구를 둘러싼 시스템에 주목하게 한다. 코드 생산을 쉽게 확장할 수 있게 되면서 엔지니어링 리더에게는 리뷰 관행, 아키텍처, 책임성에 대한 부담이 커지고 있다.

Copilot Cowork 개발 이정표가 실제로 측정하는 것

Microsoft의 Copilot Cowork engineering 사례에 따르면, 백엔드 팀은 1월에 작업을 시작한 뒤 이 일일 총량에 도달했다. 엔지니어는 요구사항과 더 높은 위험을 수반하는 의사결정에 대한 책임을 유지했다. 자동화된 검사와 에이전트 리뷰어가 변경 사항을 살폈다. Microsoft는 또한 인간 리뷰어가 에이전트 리뷰어가 놓친 차단 수준의 문제 네 건을 발견한 민감한 변경 사례도 설명한다.

병합된 풀 리퀘스트는 승인된 활동을 기록할 뿐이며, 그 비즈니스 가치를 입증하려면 별도의 근거가 여전히 필요하다.

조직은 하나의 기능을 여러 변경으로 나눌 수도 있고, 관련 작업을 더 큰 제출 단위로 묶을 수도 있다. 두 방식 모두 건수에 영향을 준다. 어느 쪽도 그 작업이 얼마나 많은 고객 가치를 제공했는지는 입증하지 않는다. 따라서 총량만으로 팀을 비교하면 엔지니어링 성과의 차이보다 패키징 방식의 차이에 보상할 위험이 있다.

더 작은 변경은 각 제안이 더 좁은 질문을 다루기 때문에 리뷰를 쉽게 만들 수 있다. 하지만 개별적으로 이해 가능한 변경들이 모여도 예상치 못한 복합 효과를 낳을 수 있다. 평가의 관련 단위는 때로 릴리스, 고객 워크플로, 또는 시간에 따른 서비스 자체가 된다.

가령 요청을 읽고, 가능 여부를 확인하고, 회의 초대장을 준비하는 가상의 일정 관리 어시스턴트를 생각해 보자. 각 구성 요소는 자체 테스트를 통과할 수 있지만, 전체 워크플로는 취소를 잘못 처리할 수 있다. 성공한 구성 요소 변경만 세면 고객이 실제로 겪는 문제를 놓치게 된다.

이 사례는 이 이정표가 보편적 목표가 되지 않으면서도 주목할 가치가 있는 이유를 보여준다. 이 수치는 유난히 바쁜 통합 프로세스를 시사한다. 그러나 기능 복잡성, 고객 편익, 또는 결과 시스템을 유지하는 데 필요한 노력에 관한 표준화된 측정치는 공개하지 않는다.

시점도 중요하다. 이 사례는 생성된 코드의 짧은 시연이 아니라, 지속적인 개발을 통해 형성된 운영 모델을 설명한다. 독자는 이 주장을 기업의 프로덕션 사례 연구로서, 그러한 형식이 수반하는 모든 맥락과 선택의 한계까지 고려해 평가해야 한다.

따라서 Copilot Cowork engineering은 코딩 속도를 넘어선 관리 질문을 제기한다. 어떤 근거가 변경 수용을 정당화해야 하는가? 답에 따라 필요한 인력 구성도 달라진다. 로컬 테스트 결과를 중시하는 팀은 보안 리뷰, 운영 근거, 고객 결과 확인을 요구하는 팀과 다르게 조직될 것이다.

일일 총량은 다른 조직을 위해 그 질문에 답해주지 못한다. 하지만 그 질문을 미루기는 더 어렵게 만든다. 구현 역량이 확대되면, 약한 수용 기준은 가끔의 불편이 아니라 운영상의 제약이 된다.

구매자에게도 이 구분은 똑같이 실용적이다. 공급업체의 개발 속도는 제품을 바꾸는 능력을 설명한다. 그러나 구매자는 그 변경이 직원들이 의존하는 워크플로를 개선한다는 근거를 여전히 필요로 한다.

엔지니어링 리더가 마주한 검증 역량 문제

구현 역량이 확대되면, 부족해지는 자원은 출시되는 결과물에 대한 정당한 신뢰다.

신뢰는 여러 원천에서 비롯된다. 정확한 요구사항, 의미 있는 테스트, 정보에 기반한 리뷰, 그리고 실제 실행 중인 서비스에서 얻는 근거다. 이 원천들은 서로 다른 질문에 답한다. 테스트는 선택된 입력값에 대해 예상한 동작을 입증할 수 있지만, 요구사항 자체가 고객에게 도움이 되는지는 입증하지 못한다.

Google의 AI-assisted software development 연구는 더 폭넓은 비교 관점을 제공한다. 2025년 DORA 조사 결과는 AI 도입을 높은 딜리버리 처리량과 연관 짓는 한편, 이를 둘러싼 조직을 강조한다. 연구는 AI가 기존의 강점과 약점을 증폭한다고 설명한다.

이 관점은 Microsoft의 이정표를 신중하게 해석하도록 뒷받침한다. 명확한 책임 체계와 신뢰할 수 있는 릴리스 통제를 갖춘 팀은 추가 구현 역량을 투입할 곳이 있다. 반면 책임이 정리되지 않은 팀은 누구도 자신 있게 승인할 수 없는 제안을 더 많이 쌓아 올릴 수 있다.

따라서 부담은 우선 엔지니어링 관리자와 플랫폼 팀에 돌아간다. 이들은 누가 수용 기준을 소유하는지, 어떤 변경에 전문가의 주의가 필요한지, 릴리스를 어떻게 되돌릴 수 있는지를 결정한다. 제안이 더 빠르게 도착할수록 이러한 결정은 더 중요해진다.

보안 전문가도 관련된 자원 배분 문제에 직면한다. 모든 변경을 같은 강도로 검토하면 위험과 무관하게 주의력을 소모한다. 명백한 보안 관련 파일만 검토하면 다른 곳에서 도입된 동작을 놓친다. 어려운 과제는 변경 사항을 그 변경이 영향을 미치는 권한, 데이터, 고객 행동과 연결하는 일이다.

제품 관리자 역시 더 큰 책임을 맡게 된다. 이견이 드러나기 전에 소프트웨어를 만들 수 있게 되면 모호한 요청의 비용은 커진다. 세련된 구현은 오해된 요구사항을 중심으로 추진력을 만들 수 있으며, 코드 변경 자체는 기술적으로 간단하더라도 수정은 정치적으로 더 어려워진다.

여기서 조직은 대기와 필요한 숙고를 구분해야 한다. 어떤 지연은 정보 부족이나 과부하 상태의 리뷰어를 반영한다. 다른 지연은 되돌릴 수 없는 결정을 보호한다. 둘 다 낭비로 취급하면 팀은 단지 대시보드 속도를 늦춘다는 이유로 안전장치를 제거하게 된다.

유용한 관리 대응은 프로세스에서 불확실성이 어디로 들어오는지 살피는 것이다. 리뷰어가 기능이 무엇을 해야 하는지 반복해서 묻는다면 요구사항을 다듬어야 한다. 배포 효과를 반복해서 의심한다면 릴리스 프로세스의 가시성을 개선해야 한다.

이는 무제한적인 프로세스를 주장하는 조직 진단이 아니다. 모든 추가 통제에는 비용이 든다. 기준은 다른 통제가 해결하지 못한 중요한 질문에 답하는지 여부여야 한다.

Copilot Cowork 개발 사례는 이 절충을 유난히 뚜렷하게 보여준다. 이제 엔지니어링 리더는 구현 역량과 함께 검증 역량을 어떻게 확대할지 설명해야 한다. 코딩 에이전트에 대한 접근권을 구매한다고 해서 이 운영상의 결정이 해결되는 것은 아니다.

엔터프라이즈 구매자에게 이에 대응하는 질문은 변경 품질에 관한 것이다. 더 빠른 릴리스는 직원이 더 적은 중단, 더 명확한 권한, 더 신뢰할 수 있는 작업 완료를 경험할 때 유용해진다. 릴리스 빈도만으로는 이러한 결과가 확정되지 않는다.

Copilot Cowork Rust migration은 언어와 아키텍처를 구분한다

Microsoft는 Copilot Cowork Rust migration이 비교 기간 동안 첫 번째 턴의 중앙 응답 시간을 7.9초에서 2.7초로 줄였다고 보고했다. 또한 개선의 일부를 에이전트 루프 이전에 기인한다고 설명하며, 턴당 비용에 대해서는 어떠한 주장도 하지 않는다.

마이그레이션은 프로그래밍 언어가 모든 개선을 일으켰다는 사실을 입증하지 않고도 서비스를 개선할 수 있다.

런타임은 애플리케이션의 작업을 실행하는 소프트웨어 장치다. 이 장치를 언어 간에 옮기면 메모리 관리, 스케줄링, 배포, 시작 동작이 달라질 수 있다. 여러 요소가 함께 바뀌면, 결과 측정치는 이들의 결합 효과를 포착한다.

이 구분은 프로그래밍 언어 논쟁이 아키텍처 프로젝트를 단순한 경쟁으로 축소하는 경우가 많기 때문에 중요하다. 이런 프레이밍은 간결한 헤드라인을 만들지만, 다른 팀의 투자 결정에는 빈약한 근거가 된다. 관련 질문은 어떤 메커니즘이 해당 팀의 병목을 해결하는지에 관한 것이다.

Rust의 concurrency guarantees는 구체적인 기술적 참고점이 된다. 동시성이란 프로그램의 서로 다른 부분이 독립적으로 진행할 수 있음을 뜻한다. Rust는 소유권 규칙과 타입 검사를 사용해 실행 전에 많은 메모리 및 동시성 오류를 포착한다.

이러한 보장에는 한계가 있다. 응답에 올바른 비즈니스 정보가 포함되는지, 작업에 권한이 있는지, 또는 사용자가 예상한 순서대로 이벤트를 수신하는지는 보장하지 않는다. 언어 안전성과 애플리케이션 정확성은 일부만 겹친다.

일정 관리 서비스는 그 차이를 잘 보여준다. 코드는 메모리를 안전하게 처리하면서도 잘못된 캘린더를 선택할 수 있다. 작업은 데이터 레이스 없이 실행되면서도 승인 전에 초대장을 발송할 수 있다. 언어 수준의 보장은 빠진 제품 규칙을 제공할 수 없다.

따라서 마이그레이션 근거에는 여러 층위가 필요하다. 한 층위는 자원 사용량과 응답 시간에 관한 것이다. 다른 층위는 현실적인 트래픽에서의 동작에 관한 것이다. 또 다른 층위는 대체 시스템이 이전에는 암묵적이었던 의무를 보존하는지에 관한 것이다.

통제된 비교라면 이상적으로는 평가 대상 변경 사항을 문서화하면서 워크로드와 인프라 조건을 일정하게 유지해야 한다. 프로덕션 마이그레이션은 완벽한 실험적 분리를 제공하는 경우가 드물다. 이러한 한계는 유용한 운영 측정치를 무시하기보다 원인 귀속 방식을 형성해야 한다.

Copilot Cowork Rust migration 사례를 읽는 개발자에게 실질적인 시사점은 분석적이다. 결과를 일반화하기 전에 관련 문제에 실행 스케줄링, 시작 오버헤드, 메모리 동작, 애플리케이션 설계 중 무엇이 관여하는지 판단해야 한다.

구매자에게는 언어 자체보다 서비스 결과가 대개 더 중요하다. 더 빠른 초기 응답은 가치가 있지만, 전체 작업의 더 빠른 완료를 입증하지는 않는다. 시스템은 응답을 더 일찍 시작하면서도 올바른 결과물을 만드는 데는 더 오래 걸릴 수 있다.

같은 구분은 경제성에도 적용된다. 지연 시간 개선이 자동으로 더 낮은 운영 비용을 뜻하지는 않는다. 인프라 사용량, 모델 호출, 재시도, 지원 업무 모두 계산에 영향을 미친다.

이 때문에 이 마이그레이션은 원인 귀속에 관한 유용한 사례 연구가 된다. 엔지니어링 결과가 공개 성능 주장으로 전환될 때 아키텍처적 맥락을 유지해야 하는 이유를 보여준다.

에이전트 리뷰에는 신뢰를 위한 독립적인 근거가 필요하다

리뷰어를 추가하는 일은 그 검사가 유용하고 충분히 독립적인 근거를 제공할 때에만 신뢰를 높인다.

AI 에이전트는 목표를 향해 행동을 선택하고 도구를 사용하는 모델 기반 시스템이다. 에이전트 리뷰어는 제안된 변경 사항을 검토하고, 우려 사항을 식별하며, 수정을 요청할 수 있다. 특히 작성 에이전트가 주변 설명의 상당 부분을 제공했을 때도 그 판단은 평가해야 할 출력으로 남는다.

Anthropic의 에이전트 워크플로 패턴은 생성과 평가를 분리하는 시스템을 설명한다. 이 회사는 단순한 설계, 명확한 평가 기준, 그리고 결과를 개선할 때에만 추가하는 복잡성을 권장한다. 이는 자동화된 리뷰의 역할이 커지는 상황과 비교할 수 있는 유용한 기준을 제공한다.

성공 여부를 직접 관찰할 수 있을 때 평가자의 업무는 더 수월해진다. 수치 계산은 독립적인 계산 결과와 대조해 확인할 수 있다. 권한에 민감한 워크플로에는 정답이 신원, 정책, 맥락에 따라 달라지므로 다른 유형의 증거가 필요하다.

핵심적인 위험은 공통된 오해다. 작성자와 리뷰어는 모호한 요구사항을 같은 방식으로 해석했기 때문에 동의할 수 있다. 그들의 합의가 모호성을 해소하는 것은 아니다. 별도의 모델이나 프롬프트도 관련 증거나 추론상의 차이를 가져올 때에만 도움이 된다.

테스트에도 비슷한 한계가 있다. 구현과 함께 작성된 테스트는 구현의 가정을 그대로 재현할 수 있다. 테스트 통과는 두 산출물 간의 일관성을 입증한다. 그러나 의도된 동작과의 일관성을 반드시 입증하는 것은 아니다.

독립적인 증거는 기존 계약, 관찰된 동작, 승인된 요구사항, 또는 신중하게 선택한 실패 사례에서 얻을 수 있다. 적절한 출처는 변경 사항에 따라 달라진다. 중요한 구분은 해당 증거가 구현과 모순될 수 있는지 여부다.

관련 입력을 전혀 받지 않았는데도 성공을 보고하는 자동 검사 기능을 생각해 보자. 그 결과는 성공적인 검토처럼 보이지만, 제안된 변경 사항에 관한 정보는 전혀 담고 있지 않다. 사용자가 검사가 실제로 무엇을 살폈는지 알 수 없을 때 눈에 보이는 통과 표시는 오해를 부른다.

이 때문에 리뷰 품질은 배정된 에이전트 수로 환원할 수 없다. 목적이 서로 다른 소수의 검사는 반복적인 광범위 리뷰보다 더 큰 신뢰를 제공할 수 있다. 목표는 읽기 어려운 논평의 흐름을 만들지 않으면서 중요한 실패 모드를 포괄하는 것이다.

사람의 참여에도 구체적인 역할이 필요하다. 시간이나 맥락 없이 누군가에게 변경 사항 승인을 요청하면 명목상의 감독만 생긴다. 효과적인 리뷰에는 명확한 결정, 관련 증거, 그리고 제안을 거부할 권한이 필요하다.

Copilot Cowork 개발의 경우, 더 넓은 교훈은 자동화와 책임성의 관계에 있다. 더 빠른 자동화 피드백은 사람의 판단을 뒷받침할 수 있지만, 조직에는 여전히 위험을 수용할 명시적인 근거가 필요하다.

그 근거는 원래 작성자들이 대화에서 떠난 뒤에도 이해할 수 있어야 한다. 요구사항과 결정에 대한 검색 가능한 기록은 향후 리뷰어가 의도를 재구성하는 데 도움이 된다. 이러한 맥락을 관리하는 팀은 저장된 문서를 소프트웨어가 올바르게 동작한다는 증거로 취급하지 않으면서 검색 가능한 지식 기반을 살펴볼 수 있다.

생산성 연구가 풀 리퀘스트 헤드라인을 복잡하게 만든다

Microsoft의 사례 연구와 독립적인 생산성 연구는 서로 다른 것을 측정하므로, 한쪽의 결과를 다른 쪽 대신 사용할 수 없다.

METR의 개발자 생산성 실험은 유용한 반대 관점을 제공한다. 2025년 초 연구에서 경력이 풍부한 오픈소스 개발자 16명은 246개의 작업을 완료했다. 참가자들은 도구가 도움이 된다고 믿었지만, AI 사용을 허용하자 해당 환경에서 완료 시간이 19% 늘어났다.

이 결과는 특정 개발자, 저장소, 작업, 도구에 관한 것이다. AI가 모든 엔지니어링 팀의 속도를 늦춘다는 사실을 입증하지는 않는다. 또한 여러 동시 에이전트를 중심으로 구성된 이후의 워크플로를 직접 평가할 수도 없다.

METR은 이후 이 상황을 더 제한적으로 해석했다. 2026년 2월의 생산성 실험 업데이트에서는 개발자들이 에이전트를 동시에 사용할 때 발생하는 표본 선택 문제와 시간 측정의 어려움을 설명했다. 연구진은 최신 결과가 현재 효과를 정밀하게 추정하기에는 신뢰할 수 없다고 판단했다.

이 출처들을 함께 보면 보편적인 결론이 아니라 측정 문제를 확인할 수 있다. 작업 완료 시간, 병합된 변경 사항, 자기 보고식 유용성은 서로 다르게 움직일 수 있다. 타당한 평가는 결과를 해석하기 전에 어떤 결과가 중요한지 명시한다.

개별 개발자에게 도구는 경과 시간을 줄이지 않더라도 불쾌한 업무를 줄일 수 있다. 조직에게 도구는 유지보수 노력을 낮추지 않더라도 실행 가능한 프로젝트의 범위를 넓힐 수 있다. 이런 이점은 고려할 가치가 있지만, 정확한 명칭이 필요하다.

팀은 더 작은 작업을 선택하기 때문에 더 많은 일을 완료할 수도 있다. 이는 대기와 불확실성을 줄여 납품을 개선할 수 있다. 그러나 주요 고객 문제는 해결되지 않은 채 활동 지표만 부풀릴 수도 있다. 단순한 건수만으로는 이 두 설명을 구분할 수 없다.

반사실적 비교 역시 중요하다. 생산성을 평가하려면 도구나 프로세스가 없었다면 어떤 일이 일어났을지에 대한 설명이 필요하다. 성공적인 릴리스는 팀이 무언가를 출시했다는 사실을 보여 준다. AI에 기인하는 가속의 정도를 독립적으로 입증하지는 않는다.

Microsoft의 공개 설명은 무작위 비교가 아니라 운영상의 사례를 제공한다. 이런 형식은 유용한 작동 방식과 실패 모드를 드러낼 수 있다. 개발자 전문성, 인프라, 조직 지원, 모델 성능이 기여한 모든 부분을 분리해 낼 수는 없다.

경쟁사에도 같은 주의가 적용된다. Anthropic의 아키텍처 가이드는 설계 접근법을 설명하는 반면, Google의 연구는 더 광범위한 패턴을 설명한다. 어느 쪽도 특정 엔터프라이즈 워크로드에서 어떤 공급업체가 최선의 결과를 제공하는지 입증하지는 않는다.

엔지니어링 리더가 얻을 시사점은 기억에 남는 숫자를 인력 산정 공식으로 바꾸지 않는 것이다. 인력 규모 결정에는 지속적인 납품, 품질, 지원 부담, 그리고 측정된 프로세스 밖에 남아 있는 업무에 관한 증거가 필요하다.

이 이야기는 경제성에 관한 질문도 열어 둔다. 수용된 작업의 총비용에는 생성, 평가, 인프라, 사람의 주의, 출시 후 수정이 포함된다. 구현 활동이 늘어나면서 경제성이 더 좋아질 수도, 더 나빠질 수도 있다.

그러므로 Copilot Cowork 엔지니어링은 재구성된 업무의 구체적 사례로 평가해야 한다. 가장 큰 기여는 엔지니어와 에이전트 사이의 보편적 환산율을 제공하는 데 있지 않고, 증거에 관해 더 나은 질문을 제기하게 만드는 데 있다.

세 가지 신호가 개발 모델을 더 쉽게 판단하게 할 것이다

다음으로 유용한 증거는 지속적인 결과, 재현 가능한 검증, 그리고 수용된 작업의 전체 비용에 관한 것이다.

첫 번째 신호는 개발 활동을 프로덕션 신뢰성과 연결하는 후속 자료다. 향후 몇 달 동안 릴리스 실패, 되돌리기, 반복되는 고객 문제를 공개한다면 독자는 병합된 변경 사항의 규모를 해석하는 데 도움을 받을 수 있다.

지속적인 납품과 함께 신뢰성이 개선된다면 운영 모델의 근거가 강화될 것이다. 수정 작업이 늘어난다면 상황은 더 복잡해진다. 어느 결과든 또 하나의 고립된 활동 기록보다 더 큰 의사결정 가치를 제공한다.

비교에는 일관된 정의를 사용해야 한다. 보고 방식의 변화는 서비스의 동작을 바꾸지 않고도 더 건강해 보이게 할 수 있다. 독자는 안정적인 측정 기간과 실패로 간주되는 항목에 대한 명확한 설명을 찾아야 한다.

두 번째 신호는 검증 관행이 원래 팀을 넘어 이전된다는 증거다. 문서화된 평가, 재현 가능한 테스트 환경, 또는 비교 가능한 프로덕션 사례는 폭넓게 유용한 접근법과 특수한 조건에 의존하는 결과를 구분하는 데 도움이 된다.

재현은 다른 팀이 일일 총량을 똑같이 맞출 것을 요구하지 않는다. 추가 구현 역량이 리뷰와 운영을 압도하지 않으면서 수용 가능한 결과를 낸다는 점을 보여 주어야 한다. 워크로드가 다르면 활동 수준도 합리적으로 달라져야 한다.

다른 팀들이 서로 다른 제약 아래에서 이점을 재현한다면 사례는 더 일반화된다. 성공이 특수한 인프라나 집중된 전문성에 크게 의존한다면 적용 범위는 더 좁아진다. 그 역시 구매자와 엔지니어링 리더에게 유용한 정보가 될 것이다.

세 번째 신호는 신뢰할 수 있는 경제성 설명이다. 성공적으로 완료된 고객 작업당 비용은 엔지니어링 변경 사항을 제품의 운영 현실과 연결할 수 있다. 또한 재시도와 수정 작업이 겉보기 효율성 향상을 흡수하는지도 드러낼 것이다.

유용한 공개는 어떤 비용이 계산에 포함되는지 설명해야 한다. 리뷰나 인프라를 제외하면 더 좁은 질문에 답하게 된다. 이를 포함하면 조직이 이 접근법을 기존 프로세스와 비교하는 데 도움이 된다.

이는 발표된 보고 약속이 아니라 관찰의 우선순위다. Microsoft는 여기서 논의한 모든 측정치를 약속하지 않았다. 이러한 정보가 없다고 해서 자동으로 실패가 입증되는 것은 아니며, 사례의 일부가 해결되지 않은 채 남는다는 뜻이다.

엔터프라이즈 구매자에게 당장의 조치는 실제 워크플로와 연결된 증거를 공급업체에 요청하는 것이다. 직원이 수행하는 작업을 선택하고, 수용 가능한 결과를 정의하며, 시스템이 예외를 어떻게 처리하는지 살펴보라. 개발 활동은 고객 성공과 분리해 두어야 한다.

Copilot Cowork 개발을 평가하는 엔지니어링 리더라면, 이 이정표를 활용해 자체 도입 결정의 근간이 되는 질문을 더 정교하게 다듬어라. 팀이 검증하기 어려워하는 것이 무엇인지, 어디에서 의도가 사라지는지, 어떤 결과가 추가 자동화를 정당화하는지 파악하라. 이를 수정하는 데 필요한 노력까지 포함해 의미 있는 기간에 걸쳐 수용된 작업을 비교하라. 기반이 되는 엔지니어링 설명과 생산성 연구는 서로 다른 질문에 답하므로 함께 읽어야 한다. 그런 다음 조직이 왜 어떤 변경 사항이 출시될 만한지 설명할 수 있는지 살펴보라. 구현을 더 쉽게 확장할 수 있게 될수록, 그 설명은 엔지니어링의 핵심 책임이 된다. 더 많이 생성된 코드가 더 신뢰할 수 있는 소프트웨어가 되었다는 점을 어떤 증거가 팀에 확신시킬 수 있을까?