Microsoft는 2026년 10월 28일 공식 블로그에서 Microsoft Foundry를 통해 Copilot harness를 개방한다고 발표했습니다. 이는 Copilot Code, Copilot Studio, GitHub Copilot 앱, 명령줄 도구, VS Code 등 제품을 구동하는 것과 동일한 멀티모델 에이전트 오케스트레이션 계층입니다. Microsoft의 판단은 직접적입니다. 서로 다른 모델을 잘 쓰려면 먼저 충분히 좋은 harness가 필요하고, 이를 직접 만들고 유지하는 비용은 너무 크다는 것입니다.
harness는 모델 바깥의 모든 일을 맡는다
Microsoft의 정의에 따르면 모델은 지능을 제공하고, harness는 모델 주변의 모든 것을 책임집니다. 에이전트에 지침을 주고, 맥락을 준비하고, 실행 환경과 통제 수단을 제공해 진짜 의미 있는 작업을 완수하게 합니다. 이 harness는 MCP, 에이전트 스킬, 에이전트 플러그인 같은 개방형 표준을 지원하므로, 개발자는 harness나 기술 스택을 바꾸지 않고도 작업마다 다른 모델을 선택할 수 있습니다.
개방 이후 개발자에게는 두 가지 길이 있습니다. SDK를 내려받아 직접 실행하거나, Foundry에서 완전 관리형 클라우드 실행 방식을 쓰는 것입니다. harness는 이미 20개가 넘는 프런티어 모델에 연결되며 자체 키 사용도 지원합니다. Microsoft는 작업에 따라 적절한 모델로 작업을 지능적으로 라우팅하므로 개발자가 새 모델을 일일이 따라가며 평가할 필요가 없습니다. GitHub 팀은 최근 harness 런타임을 Rust로 이식했고, Microsoft는 이를 통해 업계 최고 수준의 성능을 얻고 세션 오버헤드와 첫 토큰까지의 대기 시간을 줄였다고 밝혔습니다. 동일한 harness가 이미 Microsoft 내부에서 수백만 사용자에게 서비스되고 있어 실제 규모에서 검증됐다고 강조합니다.
아끼는 것은 오케스트레이션 비용이지 제품 판단이 아니다
Microsoft는 에이전트 루프와 샌드박스, 거버넌스와 최적화를 처음부터 내장해 맡습니다. 개발자는 지침과 스킬, 도구, 모델 선택만 가져오면 됩니다. 플랫폼은 계속 개방되어 있어 개발자는 다른 harness와 프레임워크도 계속 쓸 수 있습니다. 다만 이번 블로그에는 Foundry에서 harness를 사용할 때의 구체적인 요금 세부 정보가 없어 실제 비용은 이후 제품 페이지를 봐야 합니다. 팀에게 진짜 선택지는 오케스트레이션 계층을 Microsoft에 맡겨 부담을 덜지, 직접 개발을 유지해 완전한 통제권을 지킬지입니다. harness 개방은 전자의 선택을 쉽게 만들 뿐, 팀을 대신해 결정하지는 않습니다.
