Copilot harness 공개 미리보기: Foundry 도입 전 권한·리전·비용 확인

Microsoft가 2026년 10월 28일 Copilot harness를 Foundry Agent Service의 공개 미리보기로 발표했습니다. 업무용 AI 에이전트를 검토하는 팀이라면 모델 이름뿐 아니라 실행을 누가 관리하고, 어떤 권한과 비용이 따라오는지 살펴볼 만한 변화입니다. 다만 정식 서비스와 같은 조건으로 바로 운영에 넣을 수 있다는 뜻은 아닙니다. 이 글은 10월 31일 공식 발표와 문서를 확인한 해설이며, Azure에 에이전트를 배포하거나 성능·요금을 직접 시험한 결과가 아닙니다.

Copilot harness는 무엇을 맡아 주나요?

하네스는 모델이 일을 끝내도록 주변에서 실행을 이어 주는 체계라고 이해하시면 편합니다. 모델에 지시와 문맥을 전달하고, 필요한 도구를 부르고, 여러 단계를 연결하는 역할을 합니다. Microsoft의 공식 발표는 여러 제품에서 사용하는 이 실행 기반을 Foundry에서도 제공한다고 설명합니다. 여러 모델을 지원한다는 발표와 내 프로젝트에서 특정 모델을 쓸 수 있다는 사실은 구분해서 확인해야 합니다.

Foundry의 세부 발표는 재사용할 작업 절차인 스킬, 연결 도구, 파일과 코드 실행, 제한된 하위 작업 위임 등을 소개합니다. Microsoft가 실행 반복 과정과 샌드박스를 운영하고, 사용자는 업무 지식과 절차, 도구를 정의하는 구성입니다. 여기서 관리형이라는 말은 업무의 정답과 최종 책임까지 서비스가 대신 정한다는 뜻으로 넓혀 읽지 않는 편이 좋겠습니다.

모델을 고르는 것만으로 충분하지 않은 이유는 뭘까요?

다음은 실제 고객의 사용 사례가 아니라, 도입 범위를 정할 때 생각해 볼 가상의 업무입니다. 공개 자료를 모아 보고서 초안을 만드는 에이전트라면 자료를 읽는 단계와 문서를 만드는 단계가 필요합니다. 여기에 사내 시스템에 보고서를 등록하거나 고객에게 보내는 일을 더하면, 읽기와 생성만 하던 때보다 확인할 범위가 넓어집니다. 초안의 문장이 그럴듯한지와 외부에 무엇이 실제로 저장됐는지는 서로 다른 질문입니다.

그래서 도입 검토에서는 모델의 답변 품질과 함께 실행 기록, 승인 지점, 결과 보관, 실패 시 중복 작업을 살펴보는 방법을 권합니다. 이 항목은 특정 제품이 모두 자동 해결한다는 기능 목록이 아니라, 팀이 맡길 업무를 정리하기 위한 확인표입니다. 대화가 자연스럽게 이어졌다는 인상만으로 실제 업무가 끝났다고 판단하지 말고, 어떤 결과물을 어디에서 확인하면 완료인지 먼저 정해 두세요.

관리형 하네스와 직접 운영하는 방식은 어떻게 다른가요?

Microsoft의 세부 발표는 단순한 지시·지원 도구로 충분한 프롬프트 에이전트, 하네스를 사용하는 프롬프트 에이전트, 자체 프레임워크와 실행 방식을 가져오는 호스팅 에이전트를 구분합니다. 선택의 기준은 더 많은 기능이 있는 쪽으로 무조건 이동하는 것이 아니라, 팀이 직접 소유하고 바꿔야 할 부분이 어디인지입니다.

팀에서 필요한 것	비교해 볼 방향
지시와 지원 도구 중심의 작업	기본 프롬프트 에이전트로 충분한지 검토
파일·스킬·복합 도구 실행을 관리형으로 이용	Copilot harness의 지원 범위 확인
실행 반복 과정·의존성·프레임워크를 직접 제어	호스팅 에이전트 방식과 운영 부담 비교

예를 들어 팀에 꼭 필요한 자체 실행 방식이 있다면, 관리형 기능을 쓰기 위해 그 요구를 포기해야 하는지 살펴보세요. 반대로 특별히 다를 필요가 없는 실행 기반을 직접 유지하느라 시간이 드는 상황이라면, 관리형으로 줄일 수 있는 일을 목록으로 적어 볼 수 있습니다. 이 비교는 실제 인건비 절감액을 측정한 결론이 아닙니다. 제품 비용과 함께 운영에 남는 일을 확인하자는 제안입니다.

미리보기에서 먼저 확인할 조건은 무엇인가요?

하네스 사용 문서는 미리보기 항목에 서비스 수준 계약이 제공되지 않으며 운영용 작업에는 권장하지 않는다고 안내합니다. 초기 미리보기에서는 새 에이전트를 만들 때 하네스를 선택하고, 기존 에이전트의 하네스를 나중에 바꾸는 것은 지원하지 않는다고 설명합니다. 기존 에이전트가 자동으로 전환됐다고 가정하면 안 됩니다.

또한 제한·리전 안내는 하네스의 지원 리전이 일반 프롬프트 에이전트보다 좁을 수 있다고 구분합니다. 작성 때 확인한 하네스 전용 목록에는 Korea Central이 없었습니다. 일반 Agent Service 표에 해당 리전이 있다는 사실을 하네스 지원으로 옮겨 읽지 마세요. 필요한 모델, 도구, 네트워크 조건도 실제 프로젝트에 맞춰 다시 확인할 부분입니다.

이 조건을 검토할 때는 먼저 “우리 팀은 어느 지역에서 어떤 데이터를 다루어야 하는가”를 적는 편이 좋습니다. 그다음 필요한 모델과 연결 도구를 대조해 보세요. 기능 시연이 매력적이더라도 필수 조건 하나가 맞지 않으면 현재 도입 범위는 달라질 수 있습니다. 이 글은 특정 회사의 보안·규제 적합성을 판정하거나, 다른 리전으로 옮기라고 권하는 안내가 아닙니다.

무료 미리보기라면 전체 비용도 없나요?

세부 발표는 하네스 런타임 사용 요금이 2026년 12월 1일 전에 무료이며 그날부터 사용량 기반 과금을 시작한다고 안내합니다. 동시에 모델 추론, 별도로 청구되는 도구와 연결 서비스에는 해당 요금이 적용된다고 구분합니다. 이 발표의 무료 범위를 전체 업무 비용으로 확대하면 안 됩니다. 향후 과금 시점은 공급자가 발표한 계획이며, 이 글이 다음 날의 계약 조건이나 청구액을 확정하는 것은 아닙니다.

비용 비교표에는 에이전트 실행 기반, 모델 사용, 연결 도구, 결과 보관, 사람이 확인하는 일을 나누어 적어 보세요. 작업 한 건이 처음부터 끝까지 성공한 경우뿐 아니라, 중간 결과를 고치거나 다시 수행한 경우도 비교할 필요가 있습니다. 모델 호출이 늘어나는 업무와 외부 도구를 자주 쓰는 업무는 같은 실행 횟수만으로 비교하기 어렵기 때문입니다. 실제 금액은 계정의 리전·계약과 선택한 서비스 요금표로 확인해야 합니다.

또 다른 혼동은 SDK와 Foundry 경로의 비용을 한데 묶는 것입니다. 공식 Copilot SDK 저장소는 구독과 사용량, 자체 키를 가져오는 BYOK 경로를 따로 설명합니다. 이를 Foundry의 미리보기 과금 안내와 같은 이용 조건으로 취급하지 마세요. 이름이 비슷해도 어떤 제품 경로로 실행하는지부터 맞춰야 합니다. 이 글은 SDK를 설치하거나 구독 자격을 확인하지 않았습니다.

우리 팀의 검토표는 어떻게 만들면 좋을까요?

아래 순서는 직접 배포한 결과가 아니라 작은 검증을 설계하기 위한 제안입니다. 첫째, 외부 시스템을 바꾸지 않고 읽기와 초안 생성으로 끝나는 업무를 하나 정합니다. 입력 자료와 완료 기준을 고정하면, 결과가 바뀌었을 때 어느 조건이 영향을 줬는지 비교하기 쉽습니다. 두 번째 업무까지 한꺼번에 묶기보다 결과를 읽고 판정할 수 있는 단위를 고르는 편이 좋겠습니다.

둘째, 성공한 예제만 준비하지 말고 필요한 자료가 없는 경우, 근거가 서로 다른 경우, 입력이 불완전한 경우를 함께 적습니다. 이때 정답 문장 하나만 만드는 것보다, 답을 보류해야 하는 상황과 사람에게 넘길 조건을 정하는 것이 도움이 됩니다. 예를 들어 출처를 찾지 못한 숫자를 그럴듯하게 채우는 대신 빈 항목과 확인할 질문으로 남겨야 하는 업무인지 미리 결정해 보세요.

셋째, 결과 품질과 실행 사실을 별도로 확인합니다. 보고서가 읽기 좋다는 평가와 파일이 올바른 위치에 저장됐다는 평가는 각각 기록하세요. 외부 저장을 나중에 허용한다면 같은 요청이 반복됐을 때 새 항목을 또 만드는지, 이미 만든 결과를 찾는지 확인할 기준도 필요합니다. 여기서 제안한 중복 점검은 서비스의 특정 동작을 시험해 확인했다는 뜻이 아닙니다.

넷째, 잘 안된 결과는 수정 사유와 함께 남깁니다. 내용을 이해하지 못한 문제인지, 자료 접근 조건인지, 도구 실행 결과를 확인하지 않은 문제인지 나누어 보세요. 결과가 맞지 않을 때 모델 성능만 살펴보면 바꿔야 할 지점을 놓칠 수 있습니다. 담당자가 수정한 사례를 다음 검토에 다시 쓰되, 이전 결과를 그대로 정답으로 확정하지 말고 업무 규칙이 바뀌었는지도 함께 살펴보세요.

마지막으로 관리형 서비스를 선택해도 팀에 남는 일을 확인합니다. 자료의 책임자, 도구 사용 권한을 승인할 사람, 결과를 최종 검토할 사람, 비용을 확인할 담당자를 정해 두는 방식입니다. 한 사람이 여러 역할을 맡더라도 확인 항목은 분리해 두면 좋습니다. 서비스가 운영하는 실행 기반과 팀이 판단하는 업무 책임을 구분하면, 도입 이후 무엇을 계속 관리해야 하는지 설명하기 쉬워집니다.

긴 작업을 맡길 계획이라면 중단 기준도 평가에 넣어 보세요. 사용자가 취소를 요청했을 때 새 도구 호출을 멈추는지, 이미 시작한 외부 작업은 어디에서 확인하는지, 남은 결과를 어떤 상태로 표시할지 질문으로 정리할 수 있습니다. 이는 현재 서비스의 취소 동작을 확인한 설명이 아니라, 팀이 도입 검증에서 확인할 항목입니다. 시작과 성공만 평가하지 않고 중단 뒤의 정리까지 포함하면 담당자가 운영 범위를 판단하는 데 도움이 됩니다.

파일과 실행 상태는 어디까지 믿어도 될까요?

하네스 사용 문서는 대화별 작업 공간과 샌드박스를 설명하면서 중요한 결과물을 별도의 지속 보관 서비스에 저장하라고 안내합니다. 대화 기록이 있다는 이유만으로 모든 결과 파일의 장기 보존까지 보장되는 것은 아닙니다. 입력 파일이 실제로 처리됐는지 확인하라는 안내도 있습니다. 첨부했다는 사실과 내용이 반영됐다는 사실은 다르게 확인해야 합니다.

팀의 검토표에는 결과 파일을 누가 언제 다시 열어 볼 것인지도 넣어 보세요. 파일 이름만 남겨 두면 어느 입력과 어떤 지시로 만든 결과인지 알기 어려울 수 있습니다. 입력의 기준일, 결과의 버전, 검토한 사람과 미확인 항목을 함께 적어 두면 인수인계에도 도움이 됩니다. 이 항목은 독자에게 제안하는 운영 기록이며 특정 저장 시스템의 보존 기간을 대신 설명하는 것은 아닙니다.

자주 묻는 질문과 확인 범위

여러 모델을 지원하면 원하는 모델을 모두 쓸 수 있나요? 제품 발표의 넓은 설명과 프로젝트의 지원 모델·리전·도구 조건을 나누어 보세요. 제한 문서는 현재 하네스에서 자체 모델을 가져오는 BYOM을 지원하지 않는다고 명시합니다. SDK의 자체 키 사용인 BYOK와 같은 뜻으로 추정하지 않는 것이 좋습니다.

기존 에이전트도 자동으로 새 하네스를 쓰나요? 초기 미리보기 문서는 새 에이전트 생성 때 선택하며 기존 하네스 전환은 지원하지 않는다고 안내합니다. 새 발표만으로 기존 환경이 바뀌었다고 판단하지 마세요.

이 글에서 실제로 검증한 것은 무엇인가요? 2026년 10월 31일 공식 발표와 공개 문서에 나온 기능·제한·과금 범위를 읽어 확인했습니다. 실제 배포, 외부 도구 연결, 속도·정확도·요금·장기 복구는 시험하지 않았습니다. 기능과 조건은 바뀔 수 있으므로 도입 전 현재 문서와 프로젝트에서 필요한 범위를 다시 확인해 주세요.

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.