직원 모두가 에이전트 메이커가 되려면: Microsoft Customer Zero의 도구 선택·거버넌스 가이드
“누구나 에이전트를 만들게 하자”는 목표는 도구 사용 권한을 켜는 것만으로 달성되지 않습니다. 프로젝트 문서를 찾아주는 개인 도우미와, 외부 업무 시스템의 데이터를 바꾸는 자율 에이전트에는 다른 기술과 다른 통제가 필요합니다.
Microsoft의 사내 IT 조직인 Microsoft Digital은 자사 제품의 첫 사용자, Customer Zero로서 이 문제를 다뤄 왔습니다. 이번 Inside Track 가이드는 Microsoft 365 Copilot의 Agent Builder, Microsoft Copilot Studio, Microsoft Foundry와 pro-code 도구를 어떤 기준으로 구분하고, 직원의 학습과 거버넌스를 어떻게 함께 설계했는지 설명합니다.
이 글의 중심 원칙은 업무 문제에서 출발하고, 요구사항을 충족하는 가장 단순한 도구를 선택하며, 위험에 비례해 검토 수준을 높이는 것입니다. 아래 수치와 운영 정책은 Microsoft 내부 사례이며 다른 조직에 자동으로 보장되는 성과나 제품 기본 설정은 아닙니다.
도구를 고르기 전에 답해야 하는 질문
Microsoft가 관찰한 흔한 문제는 직원들이 가장 강력하고 유연한 도구부터 선택하는 일이었습니다. 작은 아이디어에도 복잡한 보안·개인정보·컴플라이언스 검토가 붙고, 필요하지 않은 기술과 더 비싼 모델을 배우느라 구현이 지연될 수 있습니다.
출발점은 다음 질문입니다.
- 어떤 업무 결과를 달성하려고 하나요?
- 필요한 데이터는 무엇이며 개인·팀·전사 중 어느 범위인가요?
- 에이전트가 정보를 조회하나요, 작업을 실행하나요, 자율적으로 움직이나요?
- 누구에게 얼마나 넓게 공유할 계획인가요?
전통적인 workflow, 기존 애플리케이션, 다른 팀이 이미 만든 에이전트가 더 적합할 수도 있습니다. 에이전트를 만드는 것 자체가 목표가 아니라 업무 개선이 목표입니다.
세 가지 개발 경로: 지식에서 실행, 맞춤 엔지니어링까지
| 경로 | 주요 대상과 용도 | 확장 시 고려할 책임 |
|---|---|---|
| Agent Builder in Microsoft 365 Copilot | 다양한 직무의 직원이 자연어로 만드는 지식 조회·요약·질의응답·기준에 따른 피드백 | 기존 Microsoft 365 권한·데이터 품질·소유자·수명주기 |
| Copilot Studio | 시민 개발자·업무팀·Power Platform 사용자가 만드는 시스템 연계, 작업 수행, workflow·트리거·자율 동작 | 승인된 커넥터, 환경별 DLP, 공유 범위, 실행 결과 평가 |
| Microsoft Foundry·Microsoft 365 Agents Toolkit 등 pro-code | 개발자·아키텍트가 만드는 맞춤 모델·오케스트레이션·복잡한 기업 솔루션 | 아키텍처, 보안·개인정보·컴플라이언스 검토, 모니터링, 수명주기 |
첫 번째 경로 역시 지식 소스·지침·권한·수명주기 관리가 필요합니다. 단순하다는 이유로 관리가 없어도 된다는 뜻은 아닙니다. 또한 이 구분은 엄격한 제품 기능 경계표가 아니라 Microsoft 내부의 선택 가이드입니다. Copilot Studio로도 상당수 기업 업무를 처리할 수 있으므로 전사 용도라는 이유만으로 Foundry를 선택하지 않습니다.
거버넌스: 누가 위험을 통제하는지부터 명확히
원문은 세 경로를 다음과 같이 설명합니다.
| 경로 | 가이드가 제시하는 거버넌스 관점 |
|---|---|
| Agent Builder | 플랫폼의 내재적 통제와 기존 Microsoft 365 경계 중심 |
| Copilot Studio | 관리자가 환경·커넥터·데이터 이동을 구성하는 통제 중심 |
| Foundry | 조직이 맞춤 아키텍처와 운영 전반을 명시적으로 책임지는 통제 중심 |
이는 책임과 설계 관점을 설명하는 틀입니다. Agent Builder를 사용한다고 조직의 데이터 권한 관리 책임이 사라지는 것은 아닙니다. Microsoft는 민감도 레이블, 기존 소프트웨어 개발 수명주기, 위험 기반 앱·에이전트 관리 정책을 함께 활용합니다.
데이터 위치, 접근 방식, 사용자 범위, 실행할 액션이 플랫폼 선택의 토대입니다. 원문이 제시하는 AI-ready 데이터의 다섯 축도 모델 관리에 의한 가치 실현, 데이터 민주화, 전문가 간 연결, 품질·거버넌스, 사일로를 줄이는 인프라 통합입니다. 강력한 모델보다 먼저 믿을 수 있는 데이터와 접근 경계를 준비해야 한다는 의미입니다.
검토는 위험에 비례해야 합니다
개인 생산성용 조회 에이전트와 여러 기업 시스템에서 자율적으로 작업하는 에이전트에 같은 검토 절차를 적용하지 않습니다. 대신 접근 범위·실행 능력·업무 영향에 비례해 검토 강도를 높입니다.
Microsoft는 과도한 제한도 위험이라고 설명합니다. 공식 경로가 너무 어렵다면 직원들이 shadow AI로 옮겨가 생산성과 컴플라이언스 가시성을 함께 잃을 수 있기 때문입니다. IT, 보안, 개인정보, 법무, 컴플라이언스, 데이터 담당자가 함께 제한의 근거와 적용 범위, 마찰을 줄일 방법을 검토해야 합니다.
경로 1: Agent Builder로 모든 직원의 첫 성공을 돕기
Agent Builder는 SharePoint 사이트, 웹사이트, Microsoft Graph connectors 등 승인된 지식 소스에 기반해 정보를 찾고 이해하는 경험의 시작점입니다. 팀 지식 허브, 프로젝트 안내, 회의 준비, 제품·정책 안내가 대표적인 예입니다.
Microsoft는 문서와 영상만 제공하는 대신 실제 업무를 이용한 워크숍, guided exercises, office hours, 동료 간 공유, Agent Launchpad의 실습·게임형 활동에 투자했습니다. 에이전트의 목적·설명·지침·지식 소스를 잘 정의할수록 이후 문제 해결 부담이 줄었다는 경험도 공유합니다.
데이터와 수명주기를 함께 관리합니다
Agent Builder가 보여주는 정보는 사용자가 이미 접근할 수 있는 정보입니다. 따라서 정리되지 않은 콘텐츠나 잘못된 권한은 에이전트 품질과 관리에 그대로 영향을 줍니다.
또한 에이전트 확산을 관리하려면 존재 여부, 소유자, 현재 유효성을 파악해야 합니다. Microsoft는 60일 비활성 기준으로 알림과 자동 정리를 작동시키는 내부 정책을 소개합니다. 이는 제품의 보편적인 자동 삭제 기본값이 아니라 사내 운영 사례입니다. Agent 365는 관찰·관리·추적·보안을 위한 제어 평면으로 언급됩니다.
사례: Campaign Prediction Agent
Microsoft Digital의 콘텐츠팀은 내부 캠페인의 도달 범위, 효과, 측정 신뢰도를 예측하는 에이전트를 Agent Builder로 만들었습니다. 프로젝트별 보고서, 여러 해·여러 채널의 분석, 벤치마크 데이터를 SharePoint 폴더에 모아 grounding 기반을 구성했습니다.
사용자는 캠페인 성과 예측을 요청하고 채널별 보고서를 받아 어느 채널에서 효과를 낼지 판단합니다. 예측 보고서라는 점을 기억해야 하며, 확정 성과나 인과 효과 측정으로 읽어서는 안 됩니다.
경로 2: Copilot Studio로 조회에서 실행으로
Microsoft 365 밖의 데이터, 외부 업무 애플리케이션, 액션, 트리거, workflow, 더 넓은 게시 범위나 고급 telemetry·평가가 필요하면 Copilot Studio를 검토합니다. 목적은 모든 메이커에게 대규모 맞춤 개발을 요구하지 않으면서 업무 시스템과 연결할 수 있게 하는 것입니다.
Microsoft 내부에서는 직원 대부분에게 Microsoft Digital과 CISO 조직이 관리하는 승인된 커넥터의 일부 집합을 제공합니다. 가장 고급 기능은 자격을 갖춘 엔지니어에게 제한합니다. “모두가 만들 수 있다”와 “모두에게 모든 커넥터를 허용한다”는 다른 정책입니다.
환경·공유·위험 분류를 함께 설계합니다
개인 self-service 에이전트는 Copilot Studio 환경 수준의 정책과 DLP로 허용 범위를 정의합니다. 더 넓게 공유하는 업무 부문·전사 솔루션은 보안·개인정보 등 전문 검토를 거칩니다.
원문은 내부 운영에 쓰는 세 에이전트도 소개합니다.
- Risk-O-Meter: 제출의 위험을 green·yellow·red로 분류하고 자동 승인·거절 또는 관련 검토자에게 전달합니다.
- Action-O-Meter: 새 커넥터와 MCP servers에 같은 분류 논리를 적용합니다.
- Friction Meter: 메이커가 겪는 어려움을 공식 지표로 드러냅니다.
이들은 Microsoft 내부 구현 사례이지 모든 고객 테넌트에 기본 제공되는 기능 이름이 아닙니다. 조직은 허용 데이터, 환경, 공유 범위, 측정 가능한 통제를 구체화해 단계적으로 승인을 넓혀야 합니다.
평가·telemetry와 개발 중 안내
Microsoft는 게시 직전에만 문제를 지적하기보다 개발 중 자동 안내, AI 기반 컴플라이언스 지원, 커넥터·환경·DLP 교육, self-service에서 IT 지원 개발로 넘어갈 기준을 제공합니다. Telemetry와 평가 결과는 품질 차이, 사용 방식, 실제 업무 가치를 파악하는 데 사용합니다.
사례: DigitalMe
Copilot Studio로 만든 DigitalMe는 변화 관리 리더의 지식을 Teams와 Outlook에서 활용하는 디지털 트윈입니다. 승인된 지식과 이전 안내를 기반으로 세션 참가자와 동료의 질문에 답하며, 담당자가 회의·출장·부재 중일 때도 정보를 제공합니다.
원문이 공유한 결과는 60분 세션에서 158개 질문 처리, 현재 약 90% 응답 정확도입니다. 이는 해당 내부 사례의 보고 수치이며 모든 DigitalMe 활용이나 Copilot Studio 에이전트의 정확도 보장이 아닙니다.
경로 3: Foundry와 pro-code가 필요한 때
다음 요구사항이 있으면 전문 개발 경로를 고려합니다.
- 도메인 데이터로 foundation model을 미세 조정하거나 여러 모델 계열을 비교·평가
- 맞춤 multi-agent orchestration과 고급 관찰·평가 파이프라인
- 여러 기업 서비스에 걸친 자율 시스템
- 자체 API·서비스·독자 아키텍처와 깊게 통합
- 광범위한 엔지니어링 제어와 사용자 정의
Microsoft 365 Agents Toolkit은 Visual Studio Code에서 여러 데이터 소스, API, Adaptive Cards, 지침·플러그인·manifest를 활용해 역할·작업별 에이전트를 개발하는 경로로 소개됩니다.
전제조건은 명확한 업무 결과, 도메인 전문가의 참여, 배포 전 평가 체계, 개발 workflow에 내장된 거버넌스·컴플라이언스, 자율 판단을 도입할 때의 human-in-the-loop입니다.
모델만큼 검색 파이프라인이 중요합니다
Microsoft는 Foundry 기반 프로젝트에서 데이터 분할과 인덱싱, embeddings 갱신, 정확한 retrieval 전략, 원천 시스템 변경이 AI 경험에 반영되는 방식을 함께 검토합니다. 잘못 설계한 검색은 정교한 모델 아키텍처도 무력화할 수 있습니다.
모델, 프롬프트, workflow, 오케스트레이션을 바꿀 때는 지속적인 테스트·벤치마크·검증이 필요합니다. Foundry의 평가 기능과 Agent 365를 통한 중앙 관리가 이런 운영의 도구로 언급됩니다.
사례: MarThrive
Foundry로 만든 MarThrive는 내부 마케팅 지식과 프로세스를 연결하는 12개 에이전트의 경험입니다. 블로그 탐색, 소셜 문안 생성, AI 보조 글쓰기 조정, 출력 품질 확인, BOM 생성, 캠페인 출시 준비 등을 지원합니다.
이 사례의 의미는 전문 개발 플랫폼을 사용했다는 사실보다, 여러 저장소와 도구에 흩어진 마케팅 자료를 업무 목적에 맞게 연결했다는 데 있습니다.
Microsoft 내부의 도입 지원과 측정 결과
Microsoft는 내부 SharePoint 허브 Builders Central에서 도구 선택, 전제조건, 환경, 만들 수 있는 에이전트 유형을 안내합니다. 그 콘텐츠에 기반한 AskMica는 도구·환경 선택과 보안·개인정보·민감 데이터 접근 예외 절차를 설명합니다.
AI Skills Navigator는 팀의 학습 경로를 목표별로 구조화하는 프로그램으로 소개되며, Microsoft Digital은 IT 직원의 역할에 맞게 학습 내용을 조정했습니다. IT가 다른 직원의 도입을 지원하려면 IT 자체의 역량도 키워야 하기 때문입니다.
원문이 제시한 내부 결과는 다음과 같습니다.
| 지표 | Microsoft 내부 보고 |
|---|---|
| 월간 활성 메이커 | 약 2,000명에서 20,000명으로, 대략 10배 증가 |
| 거버넌스 아래 관리하는 개인 개발 환경 | 약 150,000개 |
| 측정한 메이커 마찰 지표 | 약 50%에서 5%로 감소 |
원문은 이 지표의 세부 산식이나 고객 조직에서 재현될 효과를 보장하지 않습니다. 한국 조직에서는 활성 메이커, 프로덕션 전환 시간, 마찰 지표를 보안·컴플라이언스 지표와 함께 측정한다는 측정 방향을 참고하는 편이 적절합니다.
우리 조직의 시작 순서
다음은 원문의 원칙을 적용한 실무 진행안입니다.
- 대표 업무를 조회형·실행형·맞춤 엔지니어링형으로 나누고 성공 기준을 정합니다.
- 필요한 데이터, 민감도, 권한, 공유 범위와 액션을 문서화합니다.
- 가장 단순한 적합 도구를 선택하고 실습·동료 지원을 제공합니다.
- 승인된 커넥터, 환경별 DLP, 공유 통제와 고위험 검토 경로를 정합니다.
- 소유자·비활성·폐기 정책, telemetry와 평가 체계를 설정합니다.
- 업무 성과와 도입 마찰을 같이 측정하고 확대 여부를 판단합니다.
이 가이드는 사내 운영 경험이며, 기능별 GA·프리뷰 상태나 라이선스·가격을 일괄 명시하지 않습니다. 원문 사례를 고객 테넌트의 기본 제공 기능으로 해석하지 말고, 실제 계약·제품 문서·지역·환경의 지원 조건을 확인해야 합니다.
마무리: 하나의 도구가 아니라 여러 출발점을 제공하세요
직원 모두에게 같은 개발 모델을 강요할 필요는 없습니다. 어떤 직원은 조회 에이전트로 충분하고, 어떤 팀은 Copilot Studio의 액션이 필요하며, 전문 개발팀은 Foundry 기반의 맞춤 시스템을 만들어야 합니다.
Microsoft가 제시하는 흐름은 실험 → 거버넌스 → 확장 → 최적화입니다. 도구 접근, 학습, 신뢰할 수 있는 데이터, 위험에 비례하는 통제를 함께 설계해야 직원의 아이디어가 실제 업무 가치로 이어집니다.
출처: Microsoft Inside Track Blog, Our Customer Zero guide: Enabling agent creation across Microsoft 365 Copilot, Copilot Studio, and Foundry.
자세한 내용은 원문 참조.