모델을 바꿀 때마다 오케스트레이션을 처음부터 다시 짜야 한다면, 에이전트 출시 일정은 금세 흔들립니다. Microsoft Foundry의 Microsoft Copilot harness는 이 문제를 겨냥한 관리형 실행 계층입니다. Copilot Code, Copilot Studio, GitHub Copilot 앱, CLI, Visual Studio Code를 뒷받침해 온 동일한 실행 계층을 Foundry에서 공개 프리뷰로 제공하며, 2026년 12월 1일까지 런타임을 무료로 사용할 수 있습니다(blogs.microsoft.com). 지금은 실험을 시작하기 좋은 시점이지만, 아래에 정리한 프리뷰 제한사항이 해소되기 전까지는 운영 환경을 기존 스택에 두는 편이 안전합니다.
Microsoft Copilot harness가 실제로 하는 일
Microsoft Copilot harness는 모델의 추론을 실제 작업 완료로 연결하는 관리형 오케스트레이션 계층입니다. Microsoft가 에이전트 루프, 샌드박스, 거버넌스와 최적화를 맡고, 개발자는 지침과 스킬, 도구, 모델을 정의합니다.
Microsoft의 설명은 간단합니다. “모델이 지능을 제공한다면, harness는 모델을 둘러싼 나머지 전부”라는 것입니다(blogs.microsoft.com). 실제로는 작업 진행에 따라 컨텍스트를 관리하고, 모델 호출과 도구 호출을 조율하며, 샌드박스 안에서 파일과 코드를 실행합니다. 기본 제공 서브에이전트에 범위가 제한된 하위 작업을 맡기고, 설정된 한도와 정책 경계도 적용합니다(devblogs.microsoft.com).
| 담당 영역 | Microsoft Foundry가 관리 | 개발자가 제공 |
|---|---|---|
| 에이전트 루프와 샌드박스 실행 | 예 | 아니요 |
| 거버넌스, 승인, 최적화 | 예 | 구성 |
| 지침과 스킬 | 아니요 | 예 |
| 도구, MCP 서버, 지식 | 아니요 | 예, 인증은 직접 구성 |
| 모델 선택 | 지원 목록 제공 | 배포할 모델 선택 |
20개 이상의 최신 모델과 BYOK를 활용한 멀티 모델 라우팅
Microsoft Copilot harness는 여러 모델 계열에 걸친 20개 이상의 최신 모델을 지원하며, BYOK(Bring Your Own Key) 구성도 사용할 수 있습니다. 작업에 따라 적합한 모델 하나 또는 여러 모델로 요청을 라우팅하는 방식입니다(blogs.microsoft.com). 다만 Microsoft는 발표문에서 20개 모델의 전체 목록을 공개하지 않았습니다. 멀티 모델 설계를 계획한다면 먼저 사용 중인 Foundry 리전에서 실제로 어떤 모델을 쓸 수 있는지 확인해야 합니다. 핵심은 고객이 별도의 커스텀 라우터를 관리하지 않아도 된다는 데 있습니다. “지침과 스킬, 도구, 모델 선택은 여러분이 가져오면 됩니다”라는 설명입니다.
초기 사용자 한 명은 모델이 바뀔 때마다 오케스트레이션 계층을 다시 작성하지 않아도 되는 점이 가장 큰 장점이라고 요약했습니다 — @ai_fengshou.
Rust 런타임과 이미 적용된 제품들
Microsoft Copilot harness 런타임은 최근 Rust로 포팅됐습니다. Microsoft는 이를 통해 세션 오버헤드와 첫 토큰까지 걸리는 시간이 줄었다고 설명합니다(blogs.microsoft.com). 다만 개선 폭을 보여주는 백분율이나 지연 시간 표는 공개되지 않았으므로, 현재는 방향성을 보여주는 주장으로 받아들이는 편이 좋습니다.
Microsoft에 따르면 동일한 harness가 이미 Copilot Code, Copilot Studio, GitHub Copilot 앱, GitHub Copilot CLI, Visual Studio Code를 비롯한 여러 Microsoft 및 GitHub Copilot 제품에서 사용되고 있습니다(blogs.microsoft.com). 또한 이 공통 기반은 수백만 명의 사용자와 수백 가지 실제 사용 사례를 대상으로 검증됐다고 Microsoft는 설명합니다(blogs.microsoft.com).
Model Context Protocol(MCP), 에이전트 스킬, 에이전트 플러그인을 통해 확장할 수 있다는 점도 특징입니다(blogs.microsoft.com).
2026년 10월 28일에 달라진 것
Microsoft는 2026년 10월 28일 두 가지 변화를 함께 발표했습니다. Microsoft Copilot harness가 Foundry Agent Service에서 공개 프리뷰에 들어갔고, 호스팅 에이전트의 장시간 실행 복원 기능은 정식 출시됐습니다(devblogs.microsoft.com).
제품 용어도 바뀌는 중입니다. Copilot Studio 문서 일부에서는 여전히 GitHub Copilot harness라고 부르지만, 제품 전반의 명칭은 Microsoft Copilot harness로 전환되고 있습니다. 문서마다 적용 시점은 다를 수 있습니다(microsoft.com).
현재 Foundry Agent Service는 세 가지 추상화 수준을 제공합니다. harness가 없는 프롬프트 에이전트, 프리뷰 상태인 Microsoft Copilot harness 기반 프롬프트 에이전트, 그리고 개발자가 프레임워크를 직접 제어하는 호스팅 에이전트입니다(devblogs.microsoft.com). 장시간 실행 복원은 이미 GA 단계에 들어간 기능으로, 몇 시간 또는 며칠간 이어지는 워크플로에서 중단이 발생해도 호스팅 에이전트가 작업을 복구할 수 있게 해줍니다.
Foundry에서 harness 에이전트 만들기
Foundry harness 에이전트는 선언적으로 정의하며, 애플리케이션 코드와 함께 저장할 수 있습니다(devblogs.microsoft.com). 개발자는 Foundry에서 에이전트를 만들고 테스트한 뒤 정의 파일을 소스 관리에 넣고, Azure Developer CLI(azd) 또는 Foundry 포털로 배포합니다(devblogs.microsoft.com).
재사용 가능한 스킬로 작업 방식을 패키징
재사용 가능한 스킬에는 에이전트가 여러 작업에 반복 적용할 수 있는 지침, 스크립트, 보조 리소스, 절차가 들어갑니다. 문서의 예제는 skills/research-brief/SKILL.md에 research-brief 스킬을 두고, 에이전트가 질문과 대상 독자, 범위, 기간을 확인하도록 합니다. 승인된 도구로 근거를 수집하고, 출처와 날짜를 인용하며, 사실과 해석을 구분하고, 서로 충돌하는 근거도 표시하도록 구성한 사례입니다.
연결된 도구도 승인 절차 안에서 관리
연결된 도구를 사용하면 에이전트가 Microsoft Foundry 도구와 MCP 도구를 활용할 수 있습니다. 단, 인증과 승인 방식을 명시적으로 설정해야 합니다. 이 승인 절차는 거버넌스 장치인 동시에, 아래 Reddit 사례처럼 최종 사용자에게 동의 창이 반복해서 표시될 때 운영상의 마찰이 발생하는 지점이기도 합니다.
실행, 파일 처리, 하위 작업 위임
에이전트는 파일을 다루고 코드를 실행하며, 범위가 제한된 작업을 기본 제공 서브에이전트에 위임할 수 있습니다. 메인 에이전트는 각 결과를 조율합니다. Copilot Studio의 harness 비교 문서에 따르면 GitHub 계열 harness는 Word, Excel, PowerPoint, PDF 파일을 기본적으로 만들고 편집할 수 있으며, 스킬과 메모리도 지원합니다(learn.microsoft.com).
소스 관리 가능한 정의와 한 줄짜리 harness 설정
에이전트 정의는 코드와 함께 관리합니다. Foundry 샘플에서는 azure.yaml에 harness를 선언합니다(devblogs.microsoft.com).
harness:
type: microsoft_copilot_preview
이 샘플은 research-brief 프롬프트 에이전트에 research-brief-skill 스킬을 연결합니다. 웹 검색(public-research)과 Code Interpreter(research-analysis)를 사용하며, 환경 입력값으로 FOUNDRY_PROJECT_ENDPOINT와 MODEL_DEPLOYMENT_NAME을 지정합니다(devblogs.microsoft.com). 배포와 호출은 프리뷰 CLI로 진행합니다.
azd deploy --all
azd ai agent invoke research-brief \
"Compare publicly announced approaches to agent interoperability. Produce a concise brief with sources, tradeoffs, and open questions."
그 밖에도 Foundry 포털, Visual Studio Code용 Foundry Toolkit, GitHub Copilot 앱용 Foundry 플러그인을 사용할 수 있습니다(devblogs.microsoft.com).
작업에 맞는 Foundry 에이전트 경로 고르기
모든 상황에 맞는 단 하나의 추상화 수준은 없습니다. Microsoft도 애플리케이션 요구사항을 충족하는 범위에서 인프라 소유권이 가장 적은 방식을 고르라고 안내합니다(devblogs.microsoft.com). 프리뷰 기간에는 에이전트를 만들 때 경로가 결정되므로, 생성 버튼을 누르기 전에 선택해야 합니다.
| 방식 | 적합한 경우 | 얻는 것 | 포기하는 것 |
|---|---|---|---|
| harness 없는 프롬프트 에이전트 | 지침과 지원 도구만으로 충분할 때 | 가장 단순하며 관리 부담이 적음 | 스킬, 관리형 파일 처리, 서브에이전트, 고급 오케스트레이션을 사용할 수 없음 |
| Microsoft Copilot harness 기반 프롬프트 에이전트(프리뷰) | 스킬, 관리형 실행, 파일, 서브에이전트, 복잡한 도구 조율이 필요할 때 | 관리형 루프와 샌드박스, 재사용 가능한 스킬, 풍부한 실행 기능 | 프리뷰 제한사항 적용; 런타임에 대한 Microsoft의 통제 범위가 더 큼; 지원 모델·도구·리전 제한 적용 |
| 호스팅 에이전트 | 프레임워크, 루프, 미들웨어 또는 종속성을 직접 가져오거나 수정해야 할 때 | Foundry가 호스팅을 관리하면서도 가장 높은 제어권 확보 | 체크포인트, 재개 로직, 중복 작업 방지를 직접 책임져야 함 |
Microsoft가 소개한 초기 고객 사례로는 인프라보다 설계에 집중해 일주일도 안 돼 솔루션을 출시한 Confluence Technologies, 그리고 상업적으로 구속력 있는 판단은 사람의 통제 아래 두면서 관리형 소싱 워크플로에 harness를 활용한 Fashable이 있습니다(devblogs.microsoft.com).
2026년 12월 1일 이후 요금
Microsoft Copilot harness 런타임 요금은 2026년 12월 1일부터 사용량 기반으로 부과됩니다. 그 전까지 런타임 사용료는 무료지만, 모델 추론 비용과 별도 과금되는 도구 및 연결 서비스 비용은 기간과 관계없이 따로 청구됩니다.
| 샌드박스 리소스 | 2026년 12월 1일부터의 가격 |
|---|---|
| 샌드박스 컴퓨팅 | vCPU-시간당 $0.0994 |
| 샌드박스 메모리 | GiB-시간당 $0.0118 |
가격은 리전과 고객 계약에 따라 달라질 수 있습니다(devblogs.microsoft.com). 프리뷰 기간에는 Foundry가 실행 환경의 CPU, 메모리, 유휴 설정을 관리하며(devblogs.microsoft.com), 지원 리전과 모델, 도구, 프리뷰 제한사항은 별도 문서에서 확인하도록 안내합니다.
Copilot Studio에서 GitHub 계열 harness를 사용하는 에이전트는 사용량 기반 Copilot Credits로 과금됩니다. 이는 Foundry의 샌드박스 측정과는 별도의 과금 체계입니다(learn.microsoft.com). 파일럿 비용을 추정할 때는 실제 샌드박스 vCPU-시간과 GiB-시간에 위 요율을 곱한 뒤, 모델 토큰 비용과 도구 비용을 더하면 됩니다.
구축 전에 확인할 프리뷰 제한사항
프리뷰가 운영 환경에서도 버틸 수 있는지는 세부 조건에서 갈립니다. 아래 제약은 별도 표시가 없는 한 Microsoft의 Foundry 게시물을 바탕으로 정리했습니다.
- 현재 harness 선택은 되돌릴 수 없습니다. 에이전트를 만들 때 harness를 선택해야 합니다. 기존 에이전트는 그대로 유지되며, 생성 후 harness를 바꾸는 기능은 아직 지원되지 않습니다. 한 초기 사용자는 이 점을 정확히 지적했습니다. “에이전트를 만들 때 Copilot harness를 선택해야 합니다. 기존 에이전트는 그대로 유지되고, 생성 후 harness를 바꾸는 기능은 아직 지원되지 않습니다” — @navaneethan_es.
- 리전과 모델에 제한이 있습니다. Foundry는 지원 리전·모델·도구와 프리뷰 제한사항의 전체 목록을 별도 문서로 안내합니다. 한 사용자는 약 9개 리전이 지원되며 중동 지역은 포함되지 않고, 완전한 BYOM도 아직 지원되지 않는다고 요약했습니다 — @HeshamSaadZaki. 이는 공식 리전 표가 아니라 사용자가 문서를 읽고 정리한 내용이므로 실제 적용 여부를 문서에서 확인해야 합니다.
- 장시간 실행 복구는 애플리케이션의 몫입니다. Foundry는 중단된 호스팅 작업을 재시작하고 원래 입력을 다시 제공합니다. 하지만 진행 상황 저장, 체크포인트부터 재개, 같은 외부 보고서를 두 번 만드는 것과 같은 중복 작업 방지는 애플리케이션이 구현해야 합니다. 대화 기록만으로는 진행 중인 작업을 복원할 수 없습니다.
- 출시와 함께 벤치마크나 SLA 수치가 제공되지는 않습니다. 지연 시간, 처리량, 정확도 표 없이 “업계 최고 수준의 성능” 같은 정성적 표현만 제시될 가능성을 염두에 둬야 합니다.
초기 Copilot harness 사용자가 운영 환경에서 겪은 문제
GitHub 계열 harness를 사용하는 Copilot Studio 사용자들은 프리뷰와 운영 환경 사이의 차이에 대해 반복적으로 우려를 제기하고 있습니다. 아래 사례는 Foundry 프리뷰 이전 Copilot Studio의 GitHub harness 경험을 다룬 내용입니다. Microsoft가 설명하는 공통 계보를 바탕으로 한 참고용 추론일 뿐(blogs.microsoft.com), Foundry의 측정 결과는 아닙니다.
운영 환경에서 커넥터가 하루도 연결 상태를 유지하지 못합니다. — r/copilotstudio의 u/roberts2727
어떤 때는 플로우가 작동하고, 어떤 때는 에이전트가 플로우에 아무것도 전달하지 않습니다. — r/copilotstudio의 u/donstazz
일반 비즈니스 사용자는 이런 앱 등록 등을 할 수 없습니다. IT 관리자가 각각의 에이전트마다 따로 처리해야 합니다. — r/copilotstudio의 u/Teemu_St
해당 스레드에서 보고된 문제는 다음과 같습니다.
- SharePoint 기반 에이전트의 응답이 느리다는 보고. r/copilotstudio에서는 다른 대안보다 상당히 느리다고 설명했습니다.
- Studio 테스트 창에서는 작동하지만 Teams 또는 M365 Copilot에 배포하면 일반적인 오류가 발생하는 에이전트. r/copilotstudio에서 보고됐습니다.
- 커넥터와 플로우의 불안정성, 반복되는 인증 및 MCP 동의 절차. r/copilotstudio에서 제기됐습니다.
- M365 Copilot 라이선스에 harness 런타임이 포함되는지, Copilot Credits가 별도로 적용되는지를 둘러싼 과금 혼란. r/microsoft_365_copilot에서 보고됐습니다.
이런 사례가 Foundry 프리뷰의 가치를 부정하는 것은 아닙니다. 다만 파일럿을 진행할 때는 실제 지식 소스, 실제 채널, 실제 최종 사용자 동의 절차를 모두 사용해 테스트한 뒤 일정을 약속해야 한다는 점을 보여줍니다.
FAQ
Microsoft Copilot harness는 GitHub Copilot harness와 같은 것인가요?
예. GitHub에서 구축한 동일한 계보의 기술이며, 새로운 Microsoft 명칭으로 전환 중입니다. 일부 Copilot Studio 문서는 아직 이전 이름을 사용합니다.
Foundry harness가 지원하는 모델은 무엇인가요?
작업 기반 라우팅을 제공하는 20개 이상의 최신 모델과 BYOK를 지원합니다. Microsoft가 전체 목록을 공개하지 않았으므로 사용 중인 리전의 Foundry 문서를 확인해야 합니다(위 멀티 모델 섹션 참고).
기존 Foundry 에이전트를 harness로 마이그레이션할 수 있나요?
프리뷰 기간에는 기존 에이전트에서 바로 전환할 수 없습니다. 프롬프트, 도구, 인증, 상태 요구사항을 먼저 정리한 뒤, 프리뷰 프로젝트에서 microsoft_copilot_preview를 사용해 에이전트를 별도로 재현하세요. 이후 동일한 작업을 기준으로 품질, 지연 시간, 샌드박스 사용량, 복구 동작을 비교한 다음 전환하는 방식이 좋습니다.
M365 Copilot 라이선스에 harness 사용량이 포함되나요?
자동으로 포함되지는 않습니다. Foundry는 모델 추론과 별도로 샌드박스 컴퓨팅과 메모리를 측정하고, Copilot Studio는 이 harness 계열을 Copilot Credits로 과금합니다. 실제 사용하는 제품과 표면에서 어떤 미터가 적용되는지 확인해야 합니다.
harness와 호스팅 에이전트 중 무엇을 사용해야 하나요?
오케스트레이션을 직접 관리하지 않으면서 관리형 루프, 샌드박스, 스킬, 서브에이전트가 필요하다면 harness를 선택하세요. 반대로 프레임워크나 런타임을 직접 제어해야 하고 체크포인트와 멱등성을 직접 책임질 수 있다면 호스팅 에이전트가 적합합니다.
프리뷰에서는 research-brief 스킬 패턴부터 시작해 보세요. 같은 작업을 harness 없는 프롬프트 에이전트로도 실행해 샌드박스 비용과 토큰 비용을 비교하고, 마이그레이션 방식과 지원 리전, 동의 절차가 테넌트 기준으로 문서화되기 전까지는 운영 환경을 검증된 경로에 유지하는 것이 좋습니다.