2026년 6월 16일은 개발자들이 반드시 기억해야 할 날짜입니다. Copilot Cowork가 이미 전 세계적으로 일반 가용성 (General Availability) 단계에 도달했기 때문입니다. 2026년 7월 22일의 Microsoft 세션은 Microsoft 365 Copilot과 Copilot Cowork를 전 세계 인력에 도입하기 위한 가이드라인이었으며, 출시 이벤트가 아니었습니다.

이러한 차이점은 힘든 작업의 초점을 출시 추적에서 워크플로 엔지니어링 (Workflow Engineering)으로 옮겨줍니다. 팀이 에이전트의 작업, 권한, 사용 경계 (Usage Boundary), 그리고 핸드오프 지점 (Handoff Points)을 장기 실행 전에 검사할 수 있을 때, Microsoft Copilot Cowork 도입은 구체화됩니다.

만약 비결정론적 (Non-deterministic) 에이전트 루프를 디버깅하며 재시도해야 할지, 중단해야 할지, 아니면 승인을 기다려야 할지 고민해 본 적이 있다면, 이 운영 문제는 익숙하게 느껴질 것입니다. 과제는 에이전트 실행을 팀이 검사하고 제어할 수 있는 무언가로 바꾸는 것입니다.

에이전트를 경계가 있는 작업자 (Bounded Worker)로 취급하십시오

'운영 지원'은 프로덕션 범위 (Production Scope)가 아닙니다. 경계가 있는 워크플로 (Bounded Workflow)는 에이전트가 수행할 수 있는 작업, 접촉할 수 있는 데이터, 사용할 수 있는 도구, 결과의 소유자, 그리고 검토를 위해 실행이 일시 중지되어야 하는 지점을 명시합니다.

Van Data Team에서는 런타임 (Runtime)을 선택하기 전에 워크플로, 데이터 의존성, 도구, 소유자, 검토 게이트 (Review Gates), 그리고 복구 경로 (Recovery Path)를 매핑합니다. 이 순서가 중요한 이유는 관리되는 런타임이 정의되지 않은 프로세스를 구제할 수 없기 때문입니다. 이 매핑은 구현 범위, 텔레메트리 (Telemetry), 그리고 통제된 롤아웃 (Rollout)의 기초가 됩니다.

프롬프트 작성 전에 제어 계약 (Control Contract)을 작성하십시오

장기 실행되는 에이전트에는 좋은 초기 지침 이상의 것이 필요합니다. 명시적인 성공 기준, 중단 조건, 재시도 제어, 승인 게이트, 그리고 복구 절차가 필요합니다. 이러한 결정 사항들을 개발자, 운영자, 그리고 검토자가 검사할 수 있는 제어 계약 (Control Contract)에 담으십시오:

• 범위 (Scope): 허용된 작업, 데이터 소스, 도구 및 환경.
• 완료 (Completion): 결과를 수용 가능하게 만드는 증거.
• 제한 (Limits): 사용 경계, 재시도 횟수 및 실행을 중단하는 조건.
• 개입 (Intervention): 인간의 승인이 필요한 작업 및 책임 있는 소유자.
• 복구 (Recovery): 보존해야 할 부분적 출력물 및 알려진 상태로 돌아가는 경로.

이 계약은 '에이전트가 완료된 것 같다'라는 모호한 상태를 테스트 가능한 결정으로 바꿔줍니다. 또한 실패의 모호함을 줄여줍니다. 중단된 실행, 거부된 결과, 그리고 복구 가능한 부분적 실행은 비록 그 중 어느 것도 수용된 결과물을 생성하지 못하더라도 서로 다른 운영 상태 (operational states)입니다.

Copilot 크레딧을 작업에 귀속시키기

단일 소비 총량은 무언가가 실행되었다는 사실만 알려줄 뿐, 유용한 작업이 발생했는지 여부는 알려주지 않습니다. Copilot 크레딧을 팀, 워크플로 (workflow), 환경, 실행 및 수용된 결과에 귀속시키십시오.

귀속된 메타데이터 헤더는 다음과 같이 매우 작을 수 있습니다:

copilot_credit_attribution:
  team: <team>
  workflow: <workflow>
...

이러한 체인을 통해 운영자는 단순 활동과 검토 게이트 (review gate)를 통과한 작업을 구분할 수 있습니다. 수용된 결과 (accepted outcome)가 중요한 종착점입니다. 완료된 실행이라 할지라도 여전히 거부나 복구가 필요할 수 있으므로, 가공되지 않은 실행 횟수가 비즈니스 결과를 대신해서는 안 됩니다. 원장 (ledger)은 소비, 실행 컨텍스트 (execution context), 그리고 작업을 수용하기로 한 결정 사이의 연결 고리를 보존해야 합니다.

플랫폼 경계를 정직하게 유지하기

Microsoft Foundry는 관리형 플랫폼 레이어 (managed platform layer)를 제공하지만, 귀하의 팀이 책임져야 할 영역을 대신 맡아주지는 않습니다. 귀하의 기업은 여전히 신뢰성, 권한, 사고 대응 (incident response) 및 비즈니스 결과에 대한 소유권을 가집니다. 이것이 바로 실행이 실패하기 전에 기록해 둘 가치가 있는 부분입니다.

실무에서는 플랫폼이 실행을 호스팅하게 하되, 귀하의 워크플로에서 누가 액세스를 제어하고, 에스컬레이션 (escalation)을 처리하며, 작업을 승인하고, 복구를 책임지는지를 명시하십시오. 실패가 사고 대응 단계에 도달했을 때, 경로와 책임자는 이미 명확해야 합니다.

데이터 거버넌스를 작업(actions)으로 확장하기

파이프라인 제어 (Pipeline controls)는 필요하지만 불충분합니다. 데이터 품질 (Data quality), 최신성 (freshness), 계보 (lineage), 액세스 거버넌스 (access governance), 그리고 감사 증거 (audit evidence)는 에이전트가 수신하는 데이터부터 수행하는 작업 (actions)에 이르기까지 지속적으로 따라다녀야 합니다.

이는 증거 추적 (evidence trail)이 다음과 같은 실질적인 질문에 답할 수 있어야 함을 의미합니다: 입력 데이터가 최신이었는가? 데이터가 어디에서 왔는가? 어떤 액세스 규칙이 사용을 허용했는가? 에이전트가 그것으로 무엇을 했는가? 누가 결과를 승인했는가? 이러한 질문들은 거버넌스를 데이터 수집 (ingestion) 단계에서 끝내는 대신, 실행 (run) 단계와 연결합니다.

운영상의 트레이드오프 (operational tradeoffs)를 수용하기

제어에는 비용이 따릅니다. 승인 게이트 (Approval gates)는 대기 지점을 만듭니다. 엄격한 중단 조건 (stop conditions)은 사람이 살릴 수도 있었던 실행을 종료시킬 수 있습니다. 재시도 (Retries)는 추가적인 사용량을 소비합니다. 더 많은 속성 필드 (attribution fields)는 더 많은 텔레메트리 (telemetry)와 더 명확한 소유권을 요구합니다.

그러한 제어 장치를 제거한다고 해서 근본적인 결정이 사라지는 것은 아닙니다. 단지 결정이 암묵적으로 변하여 감사 (audit)하기 더 어려워질 뿐입니다. 유용한 균형은 비례적이어야 합니다. 민감한 데이터, 중대한 결과가 따르는 작업, 그리고 비용이 많이 드는 복구 경로에는 가장 강력한 게이트를 배치하는 한편, 위험도가 낮은 작업은 명시적인 한도 내에서 진행될 수 있도록 허용해야 합니다.

7월의 AMA는 실질적인 도입 질문에 답할 수 있겠지만, 해당 목록이 Copilot Credits나 Microsoft Foundry에 대한 내용을 보장하지는 않았습니다. 소스 측의 주장을 여러분의 운영 설계 (operating design)와 분리한 다음, 누락된 제어 장치들을 의도적으로 구축하십시오.

여러분이 처음으로 프로덕션에 투입할 워크플로우(workflow)의 경우, 어떤 조건이 실행을 자동으로 중단해야 하며, 어떤 작업이 항상 사람의 확인을 기다려야 합니까?

📖 가이드 전문 읽기 → Microsoft Copilot Cowork Adoption: Operations Guide