에이전트가 보고서를 외부 시스템에 생성한 직후 죽었습니다. 완료 체크포인트는 저장되지 않았습니다. 런타임이 같은 입력으로 작업을 다시 시작하면 보고서는 하나일까요, 둘일까요?
Microsoft의 10월 28일 발표를 검토할 때 이 질문이 먼저 필요합니다. 관리형 Copilot harness의 public preview와 hosted agent의 장기 실행 복구는 함께 발표됐지만 적용 대상과 책임이 다릅니다. 이 글은 문서 검토와 로컬 가짜 서비스 실험이며 Foundry 배포 후기가 아닙니다.
관리형 하네스와 직접 가져오는 실행 루프
Copilot harness를 선택한 prompt agent에서는 Microsoft가 모델·도구를 잇는 실행 루프와 샌드박스를 운영합니다. 개발자는 지침·스킬·도구를 구성합니다. 반면 hosted agent는 자체 프레임워크와 실행 로직을 가져오는 경로입니다. 복구 관련 설명을 읽을 때 어느 쪽 이야기인지 확인해야 합니다. 공식 발표
다음은 이를 바탕으로 만든 도입 판단표입니다. 기능 지원표를 재인용한 것이 아니라 소유할 코드의 범위를 결정하는 기준입니다.
| 먼저 확인할 질문 | 판단 방향 |
|---|---|
| 지침과 지원 도구 호출만으로 충분한가 | 일반 prompt agent부터 검토 |
| 파일 작업·스킬·여러 단계 조정을 맡기고 싶은가 | 관리형 하네스의 지원 범위와 제약 확인 |
| 루프·미들웨어·의존성을 직접 바꿔야 하는가 | hosted agent에서 소유할 운영 코드 계산 |
| 외부 시스템을 변경하는가 | 어느 경로든 작업 ID·권한·중복 방지 계약을 먼저 정의 |
서브에이전트 수를 늘리는 선택보다 도구 하나가 실패했을 때 상태를 설명할 수 있는지가 도입의 앞선 조건입니다. 읽기 전용 자료 수집과 실제 보고서 게시를 다른 단계로 두면 복구와 승인을 분리하기도 쉽습니다.
10.8~22.1%p는 Foundry 배포의 예상 개선율이 아니다
Copilot Studio의 10월 28일 발표는 Standard 하네스 대비 같은 작업의 평가 통과율이 OpenAI 모델에서 10.8%p, Anthropic 모델에서 22.1%p 높았다고 보고합니다. 각주는 2026년 10월 내부 분석이며 성공적으로 수행된 평가 실행에 근거한다고 설명합니다. 정확한 모델 버전·표본 수·공개 데이터셋·기준 통과율은 제시하지 않아 독립 재현이나 상대 개선율 계산의 근거가 부족합니다.
이 수치는 Foundry 프리뷰에 애플리케이션을 옮긴 고객의 결과가 아닙니다. 도구 실패 뒤 계속 시도한 비율 역시 작업 완료율과 다릅니다. 팀의 도입 판단에서는 같은 입력·모델·권한으로 완료 기준과 재시도 비용을 함께 비교해야 합니다.
YAML은 실행 책임을 선택한다
현재 하네스 가이드의 azure.yaml 선택 필드는 다음과 같습니다. 미실행 예시이며 완전한 배포 파일이 아닙니다. review-agent는 설명용 이름입니다.
services:
review-agent:
host: azure.ai.agent
harness:
type: microsoft_copilot_preview
프로젝트·모델·인증·지원 지역과 나머지 생성 설정이 먼저 필요합니다. 초기 프리뷰에서는 생성 시 하네스를 선택하며 기존 agent의 하네스 전환을 지원하지 않는다고 가이드는 설명합니다. 모델명이나 배포 명령을 붙여 실행 가능한 샘플처럼 제시하지 않았습니다. 예상 확인 대상은 배포 후 저장된 정의의 하네스 값이지만, 이 글에서는 배포하지 않았습니다.
같은 가이드에서 특히 볼 부분은 도구 권한입니다. Shell을 켜 둔 채 파일·웹 전용 도구만 끄는 것으로 엄격한 파일·네트워크 경계를 만들 수는 없습니다. 하네스 도구와 고객 MCP 도구의 승인 설정도 구별해야 합니다. 도구 이름의 토글과 실제 환경 권한은 별개라는 점을 설정 검토에 반영하세요. 도구 설정 안내
완료된 외부 작업과 저장되지 않은 체크포인트 사이
복구 문서는 hosted handler가 처음부터 다시 진입하며, 로컬 변수나 호출 스택을 복원하지 않는다고 설명합니다. 스트림 재생도 업무 체크포인트와 다릅니다. 따라서 다음 구간이 남습니다.
보고서 생성 요청 → 외부 시스템에서 생성 완료 → 프로세스 중단
↓
로컬 완료 기록은 아직 없음
↓
handler 재진입 → 같은 생성 요청?
도식은 문서를 바탕으로 한 자체 실패 시나리오입니다. 완료 여부를 먼저 조회해도 조회와 생성 사이에 동시 요청이 들어오면 중복될 수 있습니다. 요청을 받는 쪽의 원자적인 중복 방지나 고유 제약이 있어야 그 경쟁을 닫을 수 있습니다.
아래는 Node.js 18 이상에서 restart.mjs에 저장해 실행할 수 있는 원본 예제입니다. 외부 시스템을 흉내 낸 배열과 영수증 Map만 사용합니다. 첫 생성 직후 체크포인트를 잃고 재진입한다는 입력 조건이며, 실제 프로세스 종료나 Azure 복구 시험은 아닙니다.
function simulate(deduplicate) {
const reports = [], receipts = new Map();
let checkpoint = null;
const key = 'tenant-demo:job-42:report:v1';
function createReport() {
if (deduplicate && receipts.has(key)) return receipts.get(key);
const id = `report-${reports.length + 1}`;
reports.push(id);
receipts.set(key, id);
return id;
}
createReport(); // Remote commit; crash before local checkpoint.
if (!checkpoint) checkpoint = createReport();
return { reports: reports.length, checkpoint };
}
console.log(JSON.stringify(simulate(false)));
console.log(JSON.stringify(simulate(true)));
로컬 실행 결과:
{"reports":2,"checkpoint":"report-2"}
{"reports":1,"checkpoint":"report-1"}
차이를 만든 것은 재시작 횟수가 아니라 같은 업무 키를 받는 외부 서비스의 동작입니다. 예제의 Map은 실제 분산 저장소가 아니며, 동시성·보존 기간·장애 내구성을 검증하지 않습니다. 운영에서는 대상 서비스의 멱등성 키 계약, 같은 키에 다른 본문을 보냈을 때의 거부, 원자적 생성과 영수증 저장을 확인해야 합니다. agent 호출 ID가 매번 바뀐다면 그것을 업무 키로 사용해서는 안 됩니다.
채택 전에 합의할 세 가지
첫째, tenant + job + operation + version처럼 재진입에도 유지되는 업무 식별자를 정하세요. 수정된 보고서는 새 버전으로 구별하되, 네트워크 재시도는 같은 키를 사용해야 합니다.
둘째, 결과를 모르는 타임아웃은 실패 확정으로 취급하지 마세요. 이미 생성됐는지 대상 시스템에서 확인하고, 확인할 수 없다면 자동 재생성 대신 검토 대기 상태를 두는 편이 낫습니다. 로컬 장부만으로 외부 변경을 정확히 한 번 실행했다고 보장할 수 없습니다.
셋째, 출시 상태를 계약과 맞추세요. 발표는 hosted resilience를 GA라고 쓰지만 10월 29일 열어 본 연결 문서는 여전히 preview 제목과 안내를 표시합니다. 이 불일치는 해소하지 못했습니다. 하네스 자체는 public preview이며, 실제 운영 채택 전 지역·SDK·SLA와 해당 기능 상태를 확인해야 합니다. 런타임 무료 기간도 모델 추론과 별도 도구의 무료 사용을 뜻하지 않습니다. 발표의 상태·과금 안내
관리형 하네스가 줄이는 것은 실행 기반을 소유하는 부담입니다. 성공한 외부 변경을 식별하고 복구하는 업무 계약은 여전히 애플리케이션의 몫입니다. 먼저 “보고서는 하나인가”에 답할 수 있는 작은 읽기·게시 흐름을 만들고, 그다음 긴 작업과 위임을 늘리세요.
관련해서 하네스 엔지니어링의 역할과 체크포인트·재개 설계를 함께 읽을 수 있습니다.
아래 공개 유료 강의는 도구 실행·검증·루프·그래프를 설계하는 학습과 연결됩니다. Azure 배포 전용 교육을 뜻하지 않으며, 강의 링크는 홍보 링크입니다.