GitHub Universe 2026, Copilot에 코드 이상의 업무를 맡기다

GitHub는 GitHub Universe 2026에서 Copilot의 역할을 코드 생성 너머로 확장하며, 에이전트 조율과 완성된 소프트웨어 작업을 발표의 중심에 놓았다. 10월 28일 공개된 업데이트는 앱 워크스페이스, 모델 오케스트레이션, 연결된 클라우드 세션을 결합한다. 이들이 공유하는 제안은 명확하다. 개발자는 모든 중간 인계를 직접 관리하지 않고도 작업을 지휘할 수 있어야 한다는 것이다.

이 제안은 경쟁 구도를 바꾼다. GitHub Copilot과 Claude Code 같은 대안을 고르는 일은 이제 모델 품질뿐 아니라 워크플로 소유권까지 포함한다. 핵심 긴장은 조율된 실행과 책임 있는 배포 사이에 있다. 에이전트는 그럴듯한 변경 사항을 만들 수 있지만, 그 변경이 프로덕션에 반영될 만한지 판단하는 책임은 여전히 검토자에게 남을 수 있다.

이 발표들이 주목할 만한 이유는 코딩 단계 사이의 업무, 즉 맥락과 승인, 미결정 사안이 쌓이는 영역을 다루기 때문이다. 동시에 신중한 구분도 필요하다. 제품별 제공 가능 시점은 서로 다르고, 벤더의 벤치마크 주장은 출처를 명시해야 하며, 소프트웨어 배포에는 자동화 이후에도 남는 책임이 포함된다. GitHub는 연결된 시스템을 제시하고 있지만, 구매자는 그 시스템이 만들어내는 결과에 대한 근거를 여전히 확인해야 한다.

GitHub Universe 2026, 소프트웨어 배포의 요소들을 연결하다

GitHub의 핵심 발표는 더 넓어진 작업 단위다. 여러 도구와 의사결정을 거쳐 승인된 소프트웨어가 되는 하나의 목표를 뜻한다.

GitHub는 소프트웨어 배포 비전에서 에이전트가 변경 사항을 구현하고 검증하는 동안 개발자가 작업을 지휘하는 방식을 설명한다. 회사는 Copilot 프로젝트, 세션 연속성, 자동화, 심화된 코드 리뷰를 이 접근법의 연결된 요소로 제시했다. 회사가 강조하는 바는 완결된 작업이다.

이러한 구도는 패치를 생성하는 일과 과제를 완료하는 일이 서로 다른 성취임을 보여주므로 중요하다. 패치는 파일을 바꾼다. 과제를 완료하려면 의도한 동작, 수용 가능한 위험 수준, 변경이 최초의 문제를 해결하는지에 관한 합의가 필요하다.

도구를 사용해 과제를 수행하는 소프트웨어인 AI 에이전트는 이러한 단계에 참여할 수 있다. 그러나 참여 자체가 최종 결정을 내리는 사람이 누구인지 자동으로 정하지는 않는다. GitHub의 발표는 제안된 시스템이 더 많은 실행 업무를 맡는 상황에서도 개발자의 책임을 유지한다.

GitHub Copilot 앱 역시 시점에 대한 설명이 필요하다. Universe는 이 앱이 이 행사에서 처음 등장했다는 뜻이 아니라, 기존 제품에 중요한 업데이트를 추가한다. GitHub의 이전 릴리스 노트에서도 이미 이 앱의 기능이 언급됐다.

구체적인 Copilot 앱 업데이트는 프로젝트를 공개 미리 보기로 제공한다. GitHub는 프로젝트가 여러 리포지토리나 더 광범위한 출시 활동에 걸친 업무와 관련된 맥락, 에이전트, 결과를 한데 모은다고 설명한다. 리포지토리는 소프트웨어 프로젝트를 구성하는 파일과 이력의 버전 관리 컬렉션이다.

프로젝트와 세션의 차이는 중요하다. 세션은 보통 하나의 상호작용이나 실행 스레드를 의미한다. 프로젝트는 관련 작업에 더 큰 컨테이너를 제공하며, 서로 다른 변경 사항이 같은 목표를 충족해야 할 때 유용해진다.

서비스와 그 문서에 걸친 가상의 기능을 생각해 볼 수 있다. 각 변경은 개별적으로는 타당해 보여도, 전체 기능은 여전히 미완성일 수 있다. 여기서 조직화의 과제는 공통 요구 사항을 보존하고 결합된 결과가 이를 충족하는 시점을 파악하는 일이다.

이는 GitHub 발표에 대한 가장 강력한 해석이다. 회사는 과제들 사이의 관계를 조직하려 한다. 그 가치는 작업이 분기되고, 가정이 바뀌거나, 누군가 제안된 결과를 거부할 때에도 이러한 관계가 계속 보이는지에 달려 있다.

혼잡한 워크스페이스만으로는 큰 성과를 내기 어렵다. 유용한 배포 시스템은 시작된 작업, 결정을 기다리는 작업, 실제로 승인 기준을 충족한 작업을 구분해야 한다. 이러한 상태는 배포를 책임지는 사람에게 서로 다른 결과를 초래한다.

엔지니어링 리더가 마주할 새로운 병목

에이전트가 제안된 변경의 공급을 늘리면, 엔지니어링 리더는 그 변경에 관한 결정을 내릴 역량에 더 주의를 기울여야 한다.

이는 GitHub 발표에서 측정된 결과라기보다 그 방향성이 시사하는 분석적 함의다. 실행을 시작하기 쉬워질수록 검토와 조율은 더 면밀히 살펴봐야 한다. 조직이 그 결과를 감당할 수 있을 때에만 더 많은 활동이 가치를 만든다.

개발자는 이러한 압박을 즉시 마주한다. 과제를 위임하면 주의력을 쓰는 방식이 달라진다. 개발자는 목표를 설명하고, 관련 맥락을 제공하며, 결과를 검토하고, 작업에 수정이 필요한지 결정해야 한다.

일부 과제는 이 교환에서 이점을 얻는다. 반면 일부 과제에는 구현 과정에서만 드러나는 불확실성이 있다. 모호하게 정의된 요청을 수행하는 에이전트는 잘못된 모호성을 해결하는 데 노력을 쏟을 수 있고, 검토자는 원래 의도를 다시 구성해야 할 수 있다.

엔지니어링 매니저는 관련된 측정 문제에 직면한다. 생성된 변경 사항을 세는 방식은 누군가 유용성을 평가하기 전부터 산출물을 진전으로 간주할 위험이 있다. 승인된 변경을 세는 편이 낫지만, 재작업, 유지보수, 이후 발견되는 결함에 대한 질문은 여전히 남는다.

따라서 의미 있는 평가는 과제가 처음으로 완료된 듯 보이는 시점 이후까지 추적해야 한다. 검토자는 상당 부분을 다시 작성해야 했는가? 변경으로 인해 지원 업무가 발생했는가? 최초 요청자는 필요한 동작을 받았는가?

이러한 질문은 병렬 작업이 종속성을 공유할 때 특히 중요하다. 여러 에이전트는 각자 국지적 진전을 이룰 수 있지만, 집합적으로는 호환되지 않는 가정을 만들 수 있다. 조율 부담은 이후 통합 단계에서 드러나며, 하나의 결정을 바꾸려면 다른 결정을 다시 검토해야 한다.

엔터프라이즈 구매자에게 권한은 제품 평가의 일부가 된다. 데모를 편리하게 만드는 접근 권한이 일상적 사용에는 부적절할 수 있다. 배포 시스템에는 중요한 작업을 승인할 수 있는 사람이 누구인지 등을 포함해 조직의 책임에 맞는 경계가 필요하다.

지식의 품질도 또 다른 압박 지점이다. 설계 논의에는 승인된 요구 사항과 함께 잠정적인 제안이 포함될 수 있다. 둘 모두가 구분 없이 에이전트의 맥락에 들어가면, 결과물은 내부적으로 일관되면서도 조직적으로는 잘못된 구현이 될 수 있다.

이 지점에서 검색 가능한 지식 기반이 워크플로와 관련성을 갖는다. 엔지니어에게는 기술적 결정과 이를 뒷받침하는 문서를 신뢰성 있게 찾아낼 방법이 필요하다. 검색은 맥락 제공에 도움을 주지만, 어떤 결정이 여전히 권위를 갖는지는 팀이 판단해야 한다.

따라서 GitHub Universe 2026은 엔지니어링 리더 앞에 실질적인 질문을 제시한다. 오늘날 미완성 작업은 어디에 쌓이는가? 구현에 어려움을 겪는 팀의 필요는 모호한 사양이나 과중한 검토자 때문에 어려움을 겪는 팀의 필요와 다르다.

이 차이는 구매 결정을 이끌어야 한다. 실행을 가속하는 시스템은 하나의 제약을 해결한다. 그 조직적 가치는 실행이 유용한 소프트웨어의 사용자 도달을 막고 있던 제약이었는지에 달려 있다.

Copilot Fusion 해설: 모델 선택은 시스템의 결정이 된다

Copilot Fusion은 반복적으로 발생하는 개발자 선택, 즉 어떤 모델이 과제를 처리하고 그 작업이 어떻게 상호작용해야 하는지를 실행 시스템으로 옮긴다.

GitHub의 멀티 모델 오케스트레이션 발표에 따르면 Fusion은 정식 출시됐다. 오케스트레이션은 모델과 그 실행 단계를 조율하는 것을 뜻한다. 개발자는 노력 수준을 선택하고, 시스템은 적합한 모델을 어떻게 사용할지 결정한다.

GitHub는 직접 실행, 품질 검사 후 상향 처리, 초안 작성 뒤 비평 및 수정 방식을 설명한다. 이러한 접근법은 서로 다른 실패 패턴을 다룬다. 단순한 요청이 반드시 까다로운 디버깅 과제와 같은 처리를 필요로 하지는 않는다.

Copilot Fusion을 이런 방식으로 설명하면 전략적 의미가 더 분명해진다. GitHub는 개별 모델 위에 놓이는 의사결정 계층을 판매하고 있다. 이 계층은 답변 품질, 리소스 소비, 결과를 얻는 데 필요한 작업 간의 관계를 관리하려 한다.

회사는 Fusion Max가 Artificial Analysis Coding Agent Index에서 60점을 기록했다고 밝혔다. GitHub는 이것이 Opus 5.5 Max를 사용하는 Claude Code와 2점 이내의 차이였다고 말한다. 또한 평균 API 비용은 약 절반, 과제당 시간은 약 40% 적었다고 보고했다.

이는 특정 엔지니어링 조직에서 독립적으로 검증된 절감 효과가 아니라 GitHub가 보고한 벤치마크 비교다. 이는 정의된 평가 환경을 비교한다. 임의의 고객 기능을 완성하고 유지하는 데 필요한 총 노력을 입증하지는 않는다.

이번 릴리스에는 고객 관점도 포함됐다. AT&T 수석 소프트웨어 엔지니어 Hari Pokhrel은 자동 선택이 더 까다로운 모델의 불필요한 사용을 줄인다고 말한다. 그의 설명은 운영상 이점을 보여주지만, GitHub 발표에서 제시된 고객 증언이라는 점은 변하지 않는다.

보편적 이득을 전제하지 않아도 근본 메커니즘은 타당하다. 반복적으로 모델을 선택하는 개발자는 과제의 난이도를 예측해야 한다. 자동 선택기는 그 대신 자체 의사결정 과정에서 이용 가능한 정보를 바탕으로 그 예측을 수행한다.

이러한 구조는 불확실성을 없애기보다 책임을 이전한다. 라우팅 시스템은 과제를 과소평가하거나, 불필요하게 상향 처리하거나, 추가 검토 업무를 만들어내는 방식을 선택할 수 있다. 구매자는 관찰된 결과를 통해 그 결정을 평가해야 한다.

비평은 미묘한 한계도 갖는다. 두 모델이 동일한 잘못된 요구 사항에 의존한다면, 모델 간의 합의가 정확성을 입증하지는 않는다. 검토는 검토 과정이 관련 오류 유형을 감지할 수 있을 때에만 도움이 된다.

조달 팀에게 벤치마크 성능과 워크플로 적합성은 별개의 질문에 답한다. 벤치마크는 명시된 조건에서의 역량 비교에 도움을 준다. 워크플로 근거는 선택한 시스템이 조직의 리포지토리, 제약 조건, 기대를 효과적으로 처리하는지 보여준다.

따라서 Claude Code에 대한 경쟁 압박은 리더보드 순위 이상의 문제다. GitHub의 제안은 구매자에게 개발 환경 전반의 조율을 중시하라고 요구한다. 경쟁 시스템은 각자의 실행 품질, 통합 선택, 개발자 경험을 통해 응답할 수 있다.

어느 경로도 자동으로 승리하지는 않는다. 관련 있는 비교 대상은 요청부터 승인된 결과에 이르는 전체 과정이며, 여기에는 각 접근법이 요구하는 사람의 노력도 포함된다.

앱과 클라우드 세션, 워크플로 소유권을 놓고 경쟁하다

GitHub Copilot 앱이 중요한 이유는 개발자가 에이전트를 조율하는 장소가 개발 의사결정이 축적되는 장소가 될 수 있기 때문이다.

지속적인 워크스페이스는 고립된 상호작용보다 장점이 있다. 사람들은 전체 이력을 처음부터 다시 구성하지 않고도 목표로 돌아갈 수 있다. 실질적인 질문은 그 복귀를 지원할 만큼 의미 있는 맥락을 충분히 보존하는지 여부다.

GitHub의 connected cloud sessions 발표는 지원되는 인터페이스 전반에서 동일한 작업을 계속 이어갈 수 있다고 설명한다. 여기에는 웹, 모바일, 에디터, 앱, 명령줄이 포함된다. 회사는 클라우드 세션이 격리된 실행 환경을 사용하며, 스냅샷을 통해 나중에 작업을 재개할 수 있다고 밝혔다.

이 기능은 익숙한 중단 비용을 해결한다. 개발자는 책상을 떠났다는 이유만으로 조사 내용을 다시 설명할 필요가 없어야 한다. 세션을 보존하면 진행 중인 실행과 유사한 지시로 새롭게 시작한 시도를 구분하는 데도 도움이 될 수 있다.

하지만 세션 연속성과 조직 연속성은 여전히 별개의 문제다. 대화를 온전히 유지한다고 해서 그 요구사항이 최신 상태라는 뜻은 아니다. 다른 곳에서 결정이 바뀐 상황에서도 작업은 성공적으로 재개될 수 있다.

따라서 인터페이스는 단순한 기억 이상의 기능을 지원해야 한다. 사람들은 에이전트가 무엇을 이해했는지, 무엇을 변경했는지, 어떤 미해결 가정이 남아 있는지 살펴볼 수 있어야 한다. 기술적으로 완전한 기록이라도 검토하기 어려울 수 있다.

이는 GitHub에 전략적 기회를 만든다. 개발자가 공통 환경에서 일상적으로 작업을 시작하고, 실행을 감독하며, 결과를 검토한다면 그 환경은 그들의 습관에 영향을 미치게 된다. 워크플로우 소유권은 반복되는 유용성을 통해 커진다.

동시에 경쟁의 틈도 생긴다. 다른 에이전트의 상호작용 모델이 까다로운 작업을 더 쉽게 이해하도록 돕는다면 개발자는 그 에이전트를 선호할 수 있다. 결과적으로 중요한 결정을 내리는 데 필요한 추론이 작업 공간에서 가려진다면 통합 범위의 가치는 떨어진다.

Anthropic의 코딩 에이전트 연구는 경쟁이 코드 생성에만 국한되지 않는 이유를 보여준다. 이 회사는 실제 Claude Code 세션을 상호작용형 작업으로 연구한다. 그 분석은 벤더 연구이지만, 그 초점 자체가 사람들이 에이전트를 사용하는 방식에 대한 관심을 드러낸다.

GitHub의 대응은 조정을 플랫폼 기능으로 만드는 것이다. 사용자에게 중요한 질문은 그 조정이 자신의 정신적 관리 부담을 줄여 주는지다. 공통 세션 목록은 그 내용이 무엇에 주의가 필요한지를 보여줄 때에만 도움이 된다.

프로덕션 오류에서 시작해 제안된 패치로 끝나는 가상의 조사를 생각해 보자. 유용한 기록에는 관찰된 실패, 작업 가설, 확인한 증거, 남아 있는 불확실성이 포함된다.

이 요소들이 연결된 상태로 유지된다면 다른 엔지니어는 재구성에 드는 노력 없이 제안된 결과를 평가할 수 있다. 반대로 긴 대화 기록 속으로 사라진다면 조직은 데이터를 보존했을 뿐 실질적인 이해는 보존하지 못한 것이다.

이것이 제품 발표의 이면에 있는 워크플로우 경쟁이다. 개발자에게는 작업을 지시하고 평가하는 데 도움이 되는 환경이 필요하다. 실행이 더욱 분산될수록 가장 강력한 인터페이스는 책임을 더 쉽게 수행하게 해 줄 것이다.

테스트 통과만으로는 유지보수자의 결정을 대신할 수 없다

GitHub가 제시하는 완료된 작업의 기준은 증거의 기준을 높인다. 수용 가능한 패치는 자동화된 검사가 항상 포착하지 못하는 기대까지 충족해야 한다.

검토를 위해 제출된 제안 코드 변경인 풀 리퀘스트는 테스트를 통과하고도 수정이 필요할 수 있다. 테스트는 선택된 기대를 나타낸다. 유지보수자는 호환성, 유지보수성, 프로젝트 관례, 그리고 제안된 해결책이 실제 필요를 충족하는지도 평가한다.

독립 연구는 이러한 구분에 실체를 부여한다. 2026년 3월 유지보수자 검토 연구에서 METR은 이전 세대 코딩 에이전트가 만든 패치를 조사했다. 연구진은 검토 노이즈를 보정한 뒤, 테스트를 통과한 패치 중 약 절반은 유지보수자에게 받아들여지지 않았을 것이라고 밝혔다.

이 연구 노트는 이전 세대 에이전트와 특정 벤치마크 환경을 다뤘다. Universe 출시나 Copilot Fusion은 평가하지 않았다. METR은 또한 에이전트가 검토자 피드백을 통해 제출물을 개선할 일반적인 기회를 갖지 못했다고 주의를 당부한다.

이러한 한계는 중요하다. 이 결과가 에이전트 유용성의 영구적인 상한을 확립하는 것은 아니다. 다만 벤치마크의 자동화 검사를 통과한 것을 살아 있는 소프트웨어 프로젝트 내 수용과 동등하게 취급할 수 없는 이유를 보여준다.

이는 더 광범위한 배포 서사에 대한 독립적이고 회의적인 관점을 제공한다. GitHub는 완료된 작업을 강조하는 반면, 유지보수자 연구는 완료 여부가 선택된 평가자에 따라 달라진다는 점을 보여준다. 서로 다른 평가자는 실질적으로 다른 결론에 도달할 수 있다.

운영상의 시사점은 측정하기 전에 완료를 정의하는 것이다. 팀은 테스트가 통과했을 때, 검토자가 승인했을 때, 또는 사용자가 의도한 동작을 받았을 때 작업이 끝났다고 볼 수 있다. 각 정의는 서로 다른 경계를 설명한다.

위험이 낮은 내부 변경이라면 자동화 검사와 짧은 검토로 충분한 확신을 얻을 수 있다. 권한 부여나 영구 데이터를 포함하는 변경은 다른 의무를 만든다. 필요한 검토 노력은 위임의 편의성이 아니라 결과의 영향에 따라 결정된다.

피드백 문제도 있다. 자동화가 결과로부터 학습한다면 결과 신호는 조직이 중요하게 여기는 것을 나타내야 한다. 이후 결함이 발생하기 전에 기록된 승인은 결함 있는 접근법을 성공적으로 보이게 만들 수 있다.

이 관찰은 GitHub의 구현에 관한 발견이 아니라 적응형 워크플로우에 관한 추론이다. 이는 구매자가 물어야 할 질문을 제기한다. 어떤 결과가 향후 행동에 영향을 미치며, 이후 수정은 어떻게 반영되는가?

사람의 관여가 모든 문제를 자동으로 해결하지는 않는다. 검토자는 결함을 놓치거나 그럴듯한 설명을 너무 빨리 받아들일 수 있다. 승인을 중심으로 구축된 시스템도 의미 있는 검토가 가능하도록 근거 자료를 충분히 접근 가능하게 만들어야 한다.

생산적인 대응은 일괄적인 불신도 자동적인 수용도 아니다. 팀에는 작업에 맞는 검토 경계가 필요하다. 또한 요청, 에이전트의 행동, 수행된 검사, 수용 결정이 연결된 기록도 필요하다.

GitHub의 배포 비전은 그 연결 고리를 강화할 때 가치가 생긴다. 실행 속도만 빨라져서는 조직이 올바른 종점에 도달했다는 사실을 입증할 수 없다.

수용된 작업, 라우팅 결과, 운영 신뢰성을 살펴봐야 한다

다음 증거는 연결된 에이전트가 수용 가능한 소프트웨어를 제공하는 데 드는 총 노력을 줄이는지 보여줘야 한다.

가장 먼저 살펴볼 신호는 프로젝트 프리뷰에서 나온 수용된 작업이다. 유용한 보고서는 수정 요청과 수용 전 포기된 작업을 포함해 작업이 검토를 통과하는 과정을 추적해야 한다. 출시 시연은 의도된 동작을 보여주지만, 반복적인 사용은 되풀이되는 마찰을 드러낸다.

더 강력한 결과는 재작업 증가 없이 인수인계가 줄어드는 경우일 것이다. 이는 조정이 독자적인 제품 계층으로서 가치가 있다는 GitHub의 주장을 뒷받침한다. 감독 부담이 늘어나거나 맥락이 분절된다는 보고는 해당 워크플로우에서 이 주장을 약화할 것이다.

비교에는 의미 있는 출발점이 필요하다. 이미 엄격한 명세와 자동화 검사를 사용하는 팀은 Copilot과 함께 그러한 방식을 도입하는 팀과 다르다. 주변 프로세스도 함께 바뀌면 개선 효과를 전적으로 에이전트에 귀속할 수 없다.

두 번째 신호는 대표 벤치마크 밖에서의 라우팅 동작이다. Fusion의 가치는 모델 선택이 완전한 작업에 어떤 영향을 주는지에 달려 있다. 평가에는 실패한 시도, 반복 실행, 그리고 사람들이 결과를 검토하는 데 쓰는 시간이 포함되어야 한다.

더 적은 총 노력으로 일관된 품질을 보여주는 증거는 자동화된 오케스트레이션의 근거를 강화할 것이다. 더 나은 수용 결과를 낸다면 비용이 더 높은 에스컬레이션이 본질적으로 실패는 아니다. 저렴한 실행도 반복적으로 작업을 사람에게 되돌린다면 매력이 떨어진다.

고객은 변동성도 이해해야 한다. 일상적인 변경, 익숙하지 않은 시스템, 모호한 요청은 에이전트에 서로 다른 요구를 제시한다. 평균 결과는 한 범주에서는 잘 작동하지만 다른 범주에서는 부진한 워크플로우를 감출 수 있다.

세 번째 신호는 이어지는 세션 전반의 운영 신뢰성이다. 개발자에게는 작업이 이해 가능한 상태와 적절한 권한으로 재개된다는 증거가 필요하다. 연결된 경험은 실행이 멈추거나 실패하거나 인터페이스 사이를 이동할 때에도 이해 가능해야 한다.

신뢰성에는 이미 무슨 일이 일어났는지를 아는 것도 포함된다. 부분 변경 후 세션이 재개된다면 개발자는 중복되거나 충돌하는 행동을 피할 수 있을 만큼 충분한 정보가 필요하다. 소프트웨어 작업은 좀처럼 중단 없이 진행되지 않기 때문에 복구 동작이 중요하다.

이 관찰들은 함께 고려해야 한다. 감독 부담이 큰 높은 작업 수용률은 명확한 결정과 제한된 재작업을 동반한 높은 수용률과는 다른 이야기를 전한다. 시스템의 가치는 그 조합에서 드러난다.

GitHub Universe 2026을 평가하는 독자라면, 팀이 이미 완료 기준을 이해하고 있는 범위가 제한된 워크플로우부터 시작하라. 원래 요청, 검토 노력, 수용 전에 필요했던 수정을 기록하라. 코딩 벤치마크에는 거의 나타나지 않는 조정 작업을 포함해, 이 관찰을 기존 프로세스와 비교하라.

평가의 초점은 활동이 아니라 유용한 결과에 맞춰야 한다. 더 짧은 대화, 더 빠른 응답, 더 많은 제안 변경은 더 나은 배포를 입증하지 못해도 고무적일 수 있다. 책임 엔지니어가 결과를 이해하는지, 요청자의 필요가 충족됐는지, 이후 작업이 숨은 비용을 드러내는지 물어보라. 그 증거를 바탕으로 다음에 어떤 책임을 위임할지 결정하라. 현재 워크플로우 중 더 나은 조정으로 가장 큰 혜택을 받을 부분은 어디이며, 어떤 관찰 가능한 결과가 그것이 개선됐다고 확신하게 만들겠는가?