누구나 AI 에이전트를 만들 수 있다. 어려운 부분은 설정 이후에 시작된다

Microsoft Source는 기술의 역할이 질문에 답하는 수준에서 중요한 결과를 낳는 행동을 수행하는 방향으로 바뀌는 가운데, 간단한 AI 에이전트 가이드를 공개했다. 이 글은 목표, 지침, 지식, 도구, 테스트를 중심으로 에이전트를 만드는 과정을 누구나 접근할 수 있는 방식으로 제시한다. 이 같은 관점은 진입 장벽을 낮추지만, 동시에 새로운 문제를 만든다. 데모를 만드는 일은 점점 쉬워지고 있지만, 에이전트가 실제 권한을 받을 자격이 있음을 입증하는 일은 더 어렵다.

이 가이드는 Microsoft가 Microsoft 365 Copilot과 Copilot Studio 전반에서 에이전트 제작 기능을 확장하는 시점에 나왔다. 사용자는 자연어로 에이전트를 설명하고, 조직 정보를 연결하며, 작업을 추가하고, 결과를 테스트할 수 있다. Microsoft의 접근 방식은 이미 많은 기업이 사용하는 소프트웨어 안에 에이전트 개발을 배치한다.

진짜 경쟁은 Microsoft와 다른 모델 제공업체 사이의 대결이 아니다. 간편한 작성 기능과 운영 신뢰성의 경쟁이다. Microsoft Source는 거의 누구나 에이전트를 조립하는 방법을 보여줄 수 있지만, 프로덕션 환경에서 사용하려면 권한, 평가, 모니터링, 그리고 책임 있는 사람의 판단이 필요하다.

Microsoft Source는 에이전트 구축을 설정처럼 보이게 한다

가장 중요한 변화는 Microsoft가 이제 비개발자도 시작할 수 있는 설정 작업으로 에이전트 생성을 제시한다는 점이다.

AI 에이전트는 모델을 사용해 목표를 해석하고, 정보나 도구를 선택하며, 하나 이상의 작업을 완료하는 소프트웨어다. 기본 챗봇은 응답을 생성한다. 에이전트는 다음 단계가 무엇인지 결정하고 다른 시스템과 상호작용할 수 있다.

Microsoft Source 가이드는 일반 사용자를 위해 이 개념을 정리한다. 제목은 의도한 변화를 분명하게 보여준다. 에이전트 구축은 더 이상 연구자나 전문 엔지니어링 팀만의 영역처럼 보이지 않아야 한다.

이 메시지는 Microsoft의 현재 제품 방향과도 맞닿아 있다. Microsoft 365 Copilot에는 자연어 설명을 통해 가벼운 에이전트를 만드는 Agent Builder가 포함돼 있다. Copilot Studio는 워크플로, 통합, 배포, 분석, 거버넌스에 대한 더 많은 제어 기능을 제공한다.

Microsoft의 최신 Copilot Studio 환경은 지침과 연결된 구성 요소를 하나의 작성 화면에 배치한다. 제작자는 에이전트의 동작을 정의하고, 지식을 연결하며, 도구를 추가하고, 모델을 선택하고, 한계를 설정할 수 있다. 플랫폼의 Build 탭은 메모리와 연결된 에이전트도 지원한다.

이는 개발의 첫 단계를 바꾼다. 비즈니스 사용자는 더 이상 애플리케이션 아키텍처나 API 호출 모음으로 시작할 필요가 없다. 일상적인 언어로 원하는 결과를 설명하는 것부터 시작할 수 있다.

매주 프로젝트 업데이트가 필요한 직원을 생각해 보자. 에이전트는 승인된 문서를 검색하고, 최근 결정을 식별하며, 미해결 위험을 요약하고, 보고서 초안을 작성할 수 있다. 이 설계에는 여전히 여러 구성 요소가 필요하지만, 초기 사양은 명확한 서면 업무 지시처럼 보일 수 있다.

자연어 기반 작성은 반복 작업도 더 빠르게 만든다. 제작자는 전체 애플리케이션을 다시 구축하지 않고도 범위를 좁히고, 지침을 다시 작성하고, 지식 소스를 추가하거나, 작업을 제거할 수 있다. 템플릿은 익숙한 업무를 위한 또 다른 출발점을 제공한다.

그러나 설정이 곧 완성을 의미하지는 않는다. 첫 번째 버전은 제작자가 에이전트가 무엇을 하기를 원하는지만 표현한다. 에이전트가 요청을 얼마나 안정적으로 해석하고, 근거를 선택하며, 예외를 처리하고, 안전하게 멈출지를 보장하지는 않는다.

이 구분은 에이전트가 확률적으로 동작하는 모델과 결정론적인 비즈니스 시스템을 연결하기 때문에 중요하다. 모델은 유사한 입력에도 서로 다른 응답을 생성할 수 있다. 연결된 시스템은 수신한 모든 유효 요청을 정확히 그대로 실행할 수 있다.

초안의 잘못된 문단은 불편한 일이다. 하지만 워크플로, 고객 데이터베이스, 메시징 시스템으로 전송된 잘못된 지시는 전혀 다른 수준의 위험을 수반한다. 따라서 작성의 용이성은 신중한 경계 설정의 중요성을 높인다.

Microsoft는 아이디어와 작동하는 프로토타입 사이의 거리를 줄였다. 그러나 프로토타입에서 신뢰할 수 있는 배포 단계로 넘어가는 다음 거리는 여전히 훨씬 더 어렵다.

Microsoft가 지금 에이전트를 단순화하는 이유

Microsoft가 에이전트 생성을 단순화하는 이유는 기업 AI 전략이 생성된 텍스트를 요청하는 데 그치지 않고, 사람들이 워크플로를 위임하는 데 점점 더 의존하기 때문이다.

Microsoft는 지난 몇 년간 생산성, 개발, 보안, 비즈니스 애플리케이션 전반에 Copilot 인터페이스를 배치해 왔다. 에이전트는 이러한 인터페이스에 목표, 연결된 지식, 행동 권한을 부여함으로써 이 전략을 확장한다.

Microsoft의 2025 Work Trend Index는 인간과 에이전트가 함께 일하는 팀을 중심으로 구축된 미래를 설명했다. 이 연구는 31개 시장의 근로자 3만1,000명을 대상으로 한 설문 데이터와 Microsoft 365 및 LinkedIn 신호를 바탕으로 했다. 연례 보고서는 에이전트를 변화하는 업무 구조의 참여자로 규정했다.

이 비전에는 전문 개발자가 공급할 수 있는 수보다 더 많은 에이전트 제작자가 필요하다. 각 부서는 자체 승인 절차, 용어, 데이터 소스, 반복 업무를 이해하고 있다. 자연어 도구는 도메인 전문가가 이러한 요구사항을 직접 표현할 수 있게 한다.

영업 운영 전문가는 리드가 언제 단계 사이를 이동해야 하는지 안다. 지원 관리자는 어떤 사례에 에스컬레이션이 필요한지 이해한다. 제품 관리자는 결정 사항, 고객 근거, 납품 위험이 어디에 기록되는지 알고 있다.

이 사용자들에게도 기술 및 거버넌스 지원은 필요하다. 그러나 모든 세부 사항을 별도의 개발 팀을 통해 번역하지 않고도 첫 번째 유용한 사양을 만들 수 있다. Microsoft는 이 사양이 자사 소프트웨어 환경 안에 남을 때 이점을 얻는다.

이 전략은 범용 어시스턴트의 한계에도 대응한다. 광범위한 어시스턴트는 글을 잘 작성할 수 있지만, 기업의 내부 정의, 권한, 프로세스를 자동으로 이해하지는 못한다. 에이전트는 하나의 업무에 집중하고 선택된 조직 리소스를 사용할 수 있다.

Microsoft는 두 가지 주요 작성 경로를 구분한다. Agent Builder는 Microsoft 365 Copilot 내에서 집중된 에이전트가 필요한 개인과 소규모 그룹을 대상으로 한다. Copilot Studio는 더 폭넓은 사용자층, 맞춤형 통합, 다단계 워크플로, 더 엄격한 수명 주기 관리를 지원한다.

회사의 빌더 비교는 이 구분을 명확히 한다. Agent Builder는 빠르고 맥락적인 생성을 우선시하는 반면, Copilot Studio는 더 복잡하거나 광범위하게 배포되는 시스템을 겨냥한다.

이 계층적 접근 방식은 Microsoft에 폭넓은 도입 경로를 제공한다. 사용자는 좁은 범위의 지식 에이전트로 시작해 동료들이 이를 유용하게 여긴다는 점을 입증한 뒤, 나중에 Copilot Studio에서 이를 복제하거나 다시 구축할 수 있다.

이 시점은 더 광범위한 시장 변화도 반영한다. IBM, Google, Salesforce, OpenAI, Anthropic, 그리고 수많은 소규모 공급업체는 이제 모델을 에이전틱 시스템 내 구성 요소로 설명한다. 경쟁의 초점은 도구, 오케스트레이션, 메모리, 평가, 배포로 옮겨갔다.

Microsoft는 기업 맥락에서 우위를 가지고 이 경쟁에 뛰어든다. 많은 조직은 이미 SharePoint에 문서를, Teams에 대화를, Entra에 ID 정보를, Microsoft 365 전반에 업무 산출물을 보관하고 있다.

이 기반이 성공적인 에이전트를 보장하지는 않는다. 하지만 일부 기업이 조립해야 하는 분리된 시스템의 수를 줄여 준다. Microsoft는 에이전트 구축을 별도의 실험 환경이 아니라 기존 업무의 확장으로 제공할 수 있다.

부담은 플랫폼 관리자와 비즈니스 리더에게 돌아간다. 이들은 직원 실험을 지원하는 동시에 어떤 에이전트가 민감한 데이터에 접근하거나 작업을 수행할 수 있는지 결정해야 한다. 간단한 생성 기능은 이 거버넌스 문제를 즉각적인 과제로 만든다.

핵심 메커니즘은 단순하지만, 신뢰성은 그렇지 않다

에이전트에는 목표, 지침, 맥락, 도구가 필요하지만, 신뢰성은 이러한 요소들이 어떻게 상호작용하는지를 통제하는 데서 나온다.

목표는 결과를 정의한다. “영업을 지원하라”는 명확한 완료 조건이 없기 때문에 지나치게 광범위하다. “승인된 회의록을 바탕으로 후속 이메일 초안을 작성하라”는 에이전트에 구체적인 입력, 작업, 출력을 제공한다.

지침은 운영 규칙을 정의한다. 지침은 톤, 필수 근거, 금지된 작업, 에스컬레이션 조건, 예상 응답 형식을 정할 수 있다. 강력한 지침은 모호성을 줄이지만, 예기치 않은 모든 해석을 제거할 수는 없다.

맥락은 에이전트에 관련 정보를 제공한다. 여기에는 문서, 데이터베이스 기록, 이전 메시지, 검색된 문단이 포함될 수 있다. 일반적으로 RAG라고 불리는 검색 증강 생성은 모델이 응답하기 전에 선택된 외부 정보를 제공한다.

도구는 에이전트가 텍스트 생성 이상의 일을 할 수 있게 한다. 도구는 재고를 조회하고, 티켓을 만들며, 기록을 업데이트하고, 메시지를 보내거나, 다른 에이전트를 호출할 수 있다. 각각의 연결은 언어적 판단을 가능한 시스템 작업으로 바꾼다.

Microsoft의 작성 모델은 이러한 요소들을 함께 가져온다. 해당 문서는 제작자가 지식 소스를 연결하고, 도구를 추가하며, 제약 조건을 구성하고, 모델을 선택하고, 결과 구성 요소를 검토할 수 있다고 설명한다. 생성형 오케스트레이션은 이후 사용 가능한 구성 요소 중 어느 것이 요청을 처리해야 하는지 결정한다.

이 과정은 핵심적인 트레이드오프를 만든다. 명시적 워크플로는 제작자가 분기와 조건을 미리 매핑하도록 요구한다. 생성형 오케스트레이션은 더 다양한 요청을 처리할 수 있지만, 그 선택은 덜 예측 가능하다.

따라서 좁은 범위의 에이전트는 측정 가능한 하나의 작업으로 시작해야 한다. 제작자는 현실적인 사례를 수집하고, 허용 가능한 결과를 정의하며, 사람의 검토가 필요한 조건을 식별할 수 있다. 확장은 열의가 아니라 근거를 따라야 한다.

한 팀이 고객 갱신 브리프를 준비하는 에이전트를 만든다고 가정해 보자. 에이전트는 승인된 계정 기록을 검색하고, 최근 지원 사례를 요약하며, 계정 관리자에게 물을 질문의 초안을 작성할 수 있다. 사람이 검토하기 전까지 결과물은 권고안으로 남는다.

같은 에이전트에 계약 조건을 변경할 권한을 부여하면 전혀 다른 시스템이 된다. 목표, 권한, 평가 기준, 결과 모두 더 깊은 검토가 필요하다. 성공적인 브리핑 에이전트가 자동으로 협상 에이전트의 자격을 갖추는 것은 아니다.

지식 품질은 또 다른 제약을 만든다. 중복되거나 오래됐거나 서로 모순되는 문서에 기반한 에이전트는 취약한 맥락을 근거로 자신감 있는 답변을 제공할 수 있다. 더 많은 파일을 연결한다고 해서 반드시 결과가 개선되는 것은 아니다.

팀에는 의도적인 지식 계층이 필요하다. 권위 있는 소스를 식별하고, 버전을 관리하며, 유용한 메타데이터를 보존하고, 검색 범위를 관련 자료로 제한해야 한다. knowledge blending 워크플로는 반복적인 AI 작업에 의존하기 전에 사람들이 파편화된 업무 맥락을 정리하는 데 도움이 될 수 있다.

메모리에도 비슷한 절제가 필요하다. 지속 메모리는 에이전트를 개인화하거나 세션 간 진행 상황을 보존할 수 있다. 하지만 의도한 것보다 오래 관련 없거나 민감하거나 오해를 부르는 세부 정보를 유지할 수도 있다.

도구 설계는 더욱 중요해진다. 각 도구에는 정확한 설명, 제한된 권한, 검증된 입력, 이해할 수 있는 실패 동작이 있어야 한다. 에이전트는 도구가 적절한 때와 승인을 요청해야 하는 때를 알아야 한다.

제작자는 멱등성도 필요하다. 이는 요청이 반복돼도 의도하지 않은 중복 작업이 생성되지 않음을 의미한다. 네트워크 시간 초과로 성공적인 작업이 가려졌다면, 자동 재시도는 동일한 메시지를 다시 보내거나 같은 기록을 다시 생성해서는 안 된다.

단순한 아키텍처는 여전히 유용하다. 목표, 지침, 지식, 도구는 초보자에게 명확한 사고 모델을 제공한다. 그러나 운영 환경의 시스템에는 인증, 권한 부여, 로깅, 평가, 복구, 책임 소재도 필요하다.

Microsoft Source는 시작 지점을 단순화한다. 하지만 에이전트가 실제 프로세스를 건드리는 순간부터 시작되는 엔지니어링 및 관리 업무까지 없애주지는 않는다.

간단한 제작 방식이 전통적 자동화에 가하는 압력

자연어 에이전트는 경직된 워크플로 도구에 도전하지만, 결정론적 자동화를 시대에 뒤떨어지게 만들지는 않는다.

전통적 자동화는 입력값, 규칙, 결과를 알 수 있을 때 가장 잘 작동한다. 시스템은 승인된 필드를 복사하거나, 표준 알림을 생성하거나, 고정된 조건에 따라 요청을 라우팅할 수 있다.

에이전트는 덜 구조화된 업무를 다룬다. 이메일을 해석하고, 문서를 비교하고, 암묵적인 요청을 추출하며, 여러 도구 중 하나를 선택할 수 있다. 이러한 유연성 덕분에 이전에는 모든 단계에서 사람의 판단이 필요했던 워크플로에 매력적인 선택지가 된다.

가장 강력한 설계는 두 접근 방식을 결합하는 경우가 많다. 에이전트가 상황을 해석하고 다음 조치를 제안한다. 결정론적 워크플로는 요청을 검증하고, 권한을 확인하며, 승인된 작업을 실행한다.

이러한 분리는 제약 없는 모델 출력으로부터 핵심 시스템을 보호한다. 또한 읽기 쉬운 비즈니스 프로세스를 유지한다. 에이전트가 입력 분류를 도왔더라도 감사 담당자와 운영자는 어떤 조건이 작업을 허용하는지 확인할 수 있다.

Microsoft의 플랫폼 전략은 이러한 결합을 뒷받침한다. Copilot Studio는 에이전트를 워크플로, 지식, 커넥터, 맞춤형 도구와 연결할 수 있다. 제작자는 변동성이 중요한 곳에는 생성형 추론을, 일관성이 중요한 곳에는 명시적 규칙을 사용할 수 있다.

이는 전통적 자동화 벤더에 자연어 제작과 모델 기반 의사결정 기능을 추가하라는 압력을 가한다. 동시에 에이전트 벤더에는 기존 엔터프라이즈 플랫폼이 이미 제공하는 거버넌스 기능을 개발하라는 압력도 가한다.

구매자에게 핵심 질문은 에이전트가 워크플로를 대체하는지 여부가 아니다. 확률적 해석이 추가된 불확실성을 감수할 만큼 충분한 가치를 창출하는 지점이 어디인지가 중요하다.

문서 요약 단계는 표현상의 작은 차이를 허용할 수 있다. 그러나 결제 승인 단계는 만들어낸 계좌번호를 허용할 수 없다. 적절한 아키텍처는 오류의 결과에 따라 달라진다.

Agent Builder와 Copilot Studio도 서로 다른 위험 프로필에 대응한다. Microsoft 365 Agent Builder는 집중적인 지식 접근과 가벼운 팀 사용에 적합하다. Copilot Studio는 복잡한 배포에 필요한 더 폭넓은 통제 기능을 제공한다.

Microsoft는 Agent Builder 프로젝트를 Copilot Studio로 복사하는 경로를 문서화하고 있다. 복사된 버전은 별도의 에이전트가 되며, 원본도 계속 사용할 수 있다. 한쪽의 변경 사항이 다른 쪽에 자동으로 반영되지는 않는다.

이러한 분리는 유용한 통제력을 만들지만 버전 혼란을 초래할 수도 있다. 팀은 어떤 에이전트가 기준 버전인지, 누가 이를 유지 관리하는지, 사용자가 버전 간에 어떻게 이동할지를 정해야 한다.

경쟁사들도 프롬프팅에서 관리형 시스템으로 향하는 유사한 경로를 따르고 있다. IBM은 현대적 에이전트를 연결된 도구와 데이터로 작동하는 언어 모델로 설명한다. Google은 자사의 클라우드 플랫폼을 통한 에이전트 개발을 홍보하며, Salesforce는 에이전트를 고객 기록 및 비즈니스 작업과 연결한다.

오픈소스 프레임워크는 엔지니어링 팀에 더 많은 통제권을 제공한다. 맞춤형 모델, 특화된 평가, 인프라 선택을 지원할 수 있다. 그러나 일반적으로 ID, 모니터링, 배포, 거버넌스 스택의 더 많은 부분을 팀이 직접 조립해야 한다.

Microsoft는 많은 조직에서 최대 유연성보다 통합의 가치가 더 클 것이라고 보고 있다. 익숙한 ID 시스템과 기존 데이터 환경은 배포 작업을 단축할 수 있다. 중요한 프로세스가 Microsoft 제품 밖에 존재할 때는 이 장점이 약해진다.

따라서 시장은 업무와 통제 요구사항에 따라 나뉠 것이다. 소규모 팀은 자연어 빌더를 선호할 수 있다. 엔지니어링 그룹은 코드 우선 프레임워크를 선택할 수 있다. 규제를 받는 조직은 엄격히 통제되는 환경 안에서 두 방식을 결합할 수 있다.

누구나 에이전트를 만들 수 있다는 Microsoft Source의 메시지는 대체로 정확하다. 더 어려운 질문은 운영 지원 없이도 누구나 에이전트를 배포해야 하는가다.

보안과 평가는 빠진 난이도다

설득력 있는 언어, 신뢰할 수 없는 데이터, 광범위한 권한이 같은 워크플로 안에서 만날 때 에이전트는 위험해진다.

Microsoft는 도구가 이메일과 지원 티켓을 포함한 신뢰할 수 없는 출처에서 정보를 가져올 수 있다고 경고한다. 해당 콘텐츠에 숨겨진 악성 지침은 에이전트를 조작하거나 부적절한 작업을 유발하려 할 수 있다.

이 공격은 일반적으로 프롬프트 인젝션이라고 불린다. 공격자는 모델이 처리하는 데이터 안에 지침을 넣어, 그 지침이 제작자가 의도한 규칙을 무시하게 만들기를 기대한다.

Microsoft의 agent security guidance는 제작자에게 지식 및 맞춤형 도구용 보안 커넥터를 구성하라고 권고한다. 에이전트가 일반 콘텐츠를 증거이자 지시로 취급할 수 있기 때문에 이 경고는 중요하다.

고객 이메일에는 에이전트에게 정책을 무시하라고 지시하는 문구가 포함될 수 있다. 검색된 웹페이지는 모델에 내부 컨텍스트를 노출하라고 지시할 수 있다. 손상된 문서는 워크플로를 다른 곳으로 돌리려 할 수 있다.

지침만으로 완전한 보호를 제공할 수는 없다. 주변 시스템은 어떤 도구가 존재하는지, 어떤 기록에 접근할 수 있는지, 어떤 작업에 사람의 확인이 필요한지를 제한해야 한다.

최소 권한은 유용한 원칙이다. 에이전트에는 정의된 업무에 필요한 최소한의 접근 권한만 부여해야 한다. 초안 작성 에이전트에는 메시지 전송 권한이 필요하지 않다. 보고 에이전트에는 원본 기록을 수정할 권한이 필요하지 않다.

영향이 큰 작업에는 승인 게이트를 사용해야 한다. 데이터 삭제, 자금 이동, 권한 변경, 외부 커뮤니케이션 전송, 법적 조건 수정은 단일 모델의 결정에 의존해서는 안 된다.

평가는 다듬어진 답변 이상을 포괄해야 한다. 유용한 테스트 세트에는 일반적인 요청, 모호한 입력, 누락된 데이터, 상충하는 출처, 악성 콘텐츠, 도구 장애, 반복 작업이 포함된다.

각 사례에는 측정 가능한 결과가 필요하다. 에이전트는 올바른 출처를 식별하고, 적절한 도구를 선택하며, 필수 사실을 보존하고, 금지된 데이터를 피하거나, 실행 대신 에스컬레이션해야 할 수 있다.

Microsoft의 Copilot Agent Kit은 테스트 세트, 일괄 평가, 지연 시간 세부 정보, 통과 또는 실패 결과, 사용자 정의 루브릭을 지원한다. 이러한 기능은 대화형 테스트만으로는 운영 준비 상태를 확립할 수 없음을 인정한다.

제작자는 최종 응답뿐 아니라 전체 실행 추적을 검토해야 한다. 올바른 답변도 불필요한 도구 호출, 안전하지 않은 검색, 또는 모델이 공개하지 않은 실패한 작업을 숨길 수 있다.

반대의 경우도 발생한다. 표현이 완벽하지 않은 응답이라도 올바른 프로세스를 따르고 권위 있는 정보를 사용할 수 있다. 평가 기준은 표면적인 유창성만 보상하기보다 비즈니스 결과를 반영해야 한다.

독립적인 위험 지침도 이러한 더 폭넓은 관점을 뒷받침한다. NIST AI profile은 부정확한 출력, 개인정보 보호, 정보 보안, 인간 의존, 생성형 시스템의 측정과 관련된 위험을 다룬다.

조직은 에이전트를 변화하는 시스템으로 다뤄야 한다. 모델은 업데이트되고, 문서는 바뀌며, API는 진화하고, 권한은 이동하며, 사용자 행동은 초기 테스트에서 놓친 사례를 드러낸다.

모니터링은 업무 성공률, 에스컬레이션 비율, 도구 오류, 승인 거부, 지연 시간, 예기치 않은 접근 시도를 추적해야 한다. 또한 행동이 안전하지 않아질 때 에이전트를 비활성화할 명확한 프로세스가 필요하다.

책임 소재가 모호해서는 안 된다. 누군가는 변경을 승인하고, 사고를 검토하며, 테스트 사례를 유지 관리하고, 성과가 지속적인 배포를 정당화하는지 결정해야 한다.

Microsoft의 간단한 가이드는 구성 요소를 이해하기 쉽게 만든다는 점에서 가치가 있다. 그 단순성은 독자가 작동하는 프로토타입을 통제된 운영 서비스로 오인할 때만 위험해진다.

Microsoft Source 가이드 이후 주목할 점

다음 단계는 통제된 도입, 반복 가능한 평가, 그리고 지속적인 감독 없이도 에이전트가 유용한 업무를 완료한다는 증거로 측정될 것이다.

첫 번째 신호는 Microsoft의 새로운 Copilot Studio 제작 환경이 프리뷰에서 더 폭넓은 운영 사용으로 어떻게 전환되는지다. Microsoft는 현재 이 환경의 일부를 프리뷰 기능으로 표시하고 있으며, 일부 기능은 기존 제품과 다르다.

안정적인 정식 출시는 자연어 제작이 본격적인 배포를 지원할 수 있다는 Microsoft의 주장을 강화할 것이다. 지속적인 비호환성이나 마이그레이션 마찰은 간단한 생성을 신뢰할 수 있는 라이프사이클로 간주해야 한다는 논리를 약화할 것이다.

조직은 Microsoft가 기존 에이전트와 새 에이전트 간에 더 명확한 전환 경로를 제공하는지 지켜봐야 한다. 또한 연결된 에이전트, 메모리, 워크플로, Microsoft IQ가 운영 거버넌스 아래에서 어떻게 작동하는지도 추적해야 한다.

두 번째 신호는 평가 및 모니터링 데이터의 품질이다. 에이전트 제작자에게는 대화 기록이나 사용자 만족도 점수 이상이 필요하다. 도구 선택, 정책 준수, 오류 복구, 완료된 결과에 대한 증거가 필요하다.

Microsoft는 반복 가능한 테스트 세트와 실행 추적을 제작 워크플로의 중심에 두어 입지를 강화할 수 있다. 구매자는 중요한 변경이 있을 때마다 버전 관리된 평가를 기대해야 한다.

좋은 배포 프로세스는 직접적인 질문에 답할 수 있어야 한다. 어떤 테스트 사례가 변경되었는가? 도구 호출 정확도는 개선되었는가? 에이전트가 제한된 데이터를 노출했는가? 인간 검토자는 제안된 작업을 얼마나 자주 거부했는가?

세 번째 신호는 기업이 통제력을 잃지 않고 범위가 좁은 에이전트를 확장하는지 여부다. 초기 성공은 연구 요약, 문서 검색, 회의 준비, 티켓 분류 같은 집중된 업무에서 흔히 나온다.

확장은 모델을 시험할 것이다. 한 팀에서 성공한 에이전트가 문서, 용어, 권한, 기대치가 바뀌면 실패할 수 있다. 더 넓은 접근 권한은 더 많은 신뢰할 수 없는 콘텐츠와 더 중대한 도구를 도입할 수도 있다.

통제된 확장의 증거는 Microsoft의 핵심 제안을 뒷받침할 것이다. 그 증거에는 지정된 책임자, 제한된 권한, 민감한 작업에 대한 인간 승인, 측정 가능한 성공 기준, 신뢰할 수 있는 종료 경로가 포함돼야 한다.

많은 수작업 수정은 이 주장을 약화할 것이다. 초기 호기심을 끌지만 결과의 일관성이 낮아 사용자를 잃는 에이전트 패턴도 마찬가지다.

Microsoft Source 가이드는 실제 전환을 포착한다. 이제 사람은 모든 소프트웨어 계층을 처음부터 직접 구축하지 않고도 평이한 언어의 목표에서 작동하는 AI 에이전트로 나아갈 수 있다.

이 성과는 자동화 설계에 참여할 수 있는 사람의 범위를 바꾼다. 하지만 그 결과로 만들어지는 모든 시스템을 보호하고, 평가하고, 통제하는 데 필요한 지식까지 널리 보급하지는 않는다.

명확한 증거, 측정 가능한 결과, 인간 책임자가 있는 하나의 좁은 업무부터 시작하라. 테스트가 더 넓은 역할을 뒷받침하기 전까지는 되돌릴 수 없는 작업을 에이전트의 권한 밖에 두어야 한다. 그런 다음 누구나 에이전트를 만들 수 있는지보다 더 중요한 질문을 던져야 한다. 당신의 팀은 이 에이전트가 다음 조치를 맡아도 되는 이유를 설명할 수 있는가?