Work IQ API와 MCP로 Microsoft 365 Copilot은 어떻게 확장되는가

Microsoft 365 Copilot 주변의 확장 포인트로서 Work IQ API / MCP / REST / A2A라는 용어들이 나열되기 시작했습니다.

이 기사에서는 2026년 6월 7일 시점에서 확인할 수 있는 Microsoft 공식 정보를 바탕으로, 개발자 및 정보 시스템(情シス) 담당자를 위해 다음 관점들을 정리합니다.

• Work IQ API는 Microsoft 365 Copilot을 어떻게 확장하는가
• A2A / MCP / REST는 어떻게 구분하여 사용하는가
• 권한 상속 · 감사 · 테넌트 경계(Tenant Boundary)를 어떻게 고려해야 하는가

참고로, Work IQ API 관련 정보에는 프리뷰(Preview) 단계의 내용이 포함되어 있습니다. Microsoft 블로그에서는 Work IQ APIs의 일반 제공(GA, General Availability)이 2026년 6월 16일로 예정되어 있다고 설명하고 있습니다. 반면, Microsoft Learn의 개별 문서에서는 2026년 6월 7일 시점에서 preview라고 명시되어 있는 페이지가 있습니다. 이 기사에서는 "블로그에서는 GA 예정이 공지되었으나, 개별 기능의 구현 문서에는 현재 시점에서 preview 표기가 남아 있다"는 전제하에 정리합니다.

특히 프로토콜별 제공 상황(후술)과 과금 조건(후술)은 블로그, Developer Blog, 각 개요(Overview) 페이지마다 표기 전제가 다릅니다. 읽는 시기나 참조하는 페이지에 따라 상황이 변할 수 있으므로 단정적인 기술은 피하고 있습니다. 구현할 경우, 특히 2026년 6월 16일 이후에 읽는다면 반드시 최신 공식 문서를 확인하시기 바랍니다.

Work IQ는 Microsoft 365 Copilot과 에이전트(Agent)의 배후에 있는 "업무 컨텍스트 이해 레이어(Work Context Understanding Layer)"라고 파악하면 이해하기 쉽습니다.

기존의 API 이용 방식에서는 이메일, 일정, Teams 메시지, SharePoint 파일, OneDrive, 외부 업무 데이터 등을 개별적으로 가져와서 앱 측에서 검색 · 요약 · 권한 제어 · 프롬프트 구성(Prompt Engineering)을 직접 구현해야 했습니다.

Work IQ는 그 일부를 Microsoft 365 측의 런타임(Runtime)으로 옮깁니다. 공식 문서에서는 Microsoft 365 데이터, 조직 시스템, 외부 소스를 가로질러 시맨틱(Semantic)한 이해를 지속적으로 구축하고, 기존의 권한이나 정책을 존중하면서 에이전트가 이용할 수 있도록 하는 것으로 설명되어 있습니다.

요컨대, Work IQ API는 "Microsoft 365의 데이터를 단순히 가져오는 API"라기보다, Copilot을 뒷받침하는 문맥 이해 · 검색 · 추론 · 도구 호출(Tool Calling)과 같은 메커니즘의 일부를 외부 앱이나 에이전트에서도 사용할 수 있게 하는 입구라고 정리하면 이해하기 쉽습니다.

대략적으로 정리하면, Microsoft 365 Copilot의 확장은 다음과 같이 나뉩니다.

핵심은 외부 앱이나 에이전트가 직접 모든 데이터 소스를 떠안는 것이 아니라, Work IQ를 통해 Microsoft 365의 컨텍스트(Context)를 이용하는 구조가 된다는 점입니다.

Microsoft는 Work IQ API의 프로토콜로 A2A, MCP, REST를 제시하고 있습니다. 즉, "하나의 API 형식으로 통일"한다기보다, 에이전트나 앱의 형태에 따라 입구를 선택하는 설계입니다.

또한, Work IQ API는 Chat, Context, Tools, Workspaces라는 도메인(Domain)으로도 설명됩니다. Chat / Context는 Copilot 방식의 대화나 그라운딩(Grounding)과 관련이 있고, Tools는 Microsoft 365 엔티티(Entity)나 액션(Action)에 대한 액세스, Workspaces는 에이전트가 처리 중인 상태나 중간 결과물을 Microsoft 365 테넌트 경계 내에서 다루기 위한 영역입니다. 프로토콜 축과 도메인 축을 나누어 보면 설계 판단을 내리기 쉬워집니다.

현시점에서의 이해로는, 3가지 입구를 다음과 같이 구분하여 사용하는 것으로 정리하면 쉽습니다.

방식	적합한 용도	살펴봐야 할 논점
A2A	에이전트 간의 연동, Copilot 측 에이전트와의 대화	어떤 에이전트를 호출할 것인가, 헤드리스(Headless) 실행 시 유효한 응답을 얻을 수 있는가
...

A2A는 Agent-to-Agent의 약자로, 에이전트 간의 대화나 태스크 위임(Task Delegation)을 다루는 입구입니다.

예를 들어, 사내 포털의 에이전트가 Microsoft 365 측의 에이전트에게 "이 사용자의 이번 주 회의 문맥을 고려하여 답변해 주길 바랍니다"라고 요청하는 구성도 가능합니다.

다만, 공식 퀵스타트(Quick Start)에서는 Word / Excel / PowerPoint 등 일부 Microsoft 365 에이전트는 Office 제품의 문맥(Context) 내에서 동작하도록 설계되어 있어, 헤드리스(Headless) 방식으로 A2A로 호출할 경우 유용한 응답을 반환하지 않을 수도 있다고 설명하고 있습니다. 즉, A2A는 만능 원격 실행 API가 아니라, '에이전트의 설계 의도'와 함께 고려해야 합니다.

MCP는 Model Context Protocol의 약자로, AI 에이전트가 외부 도구(Tool)나 데이터 소스(Data Source)를 다루기 위한 프로토콜입니다.

Work IQ MCP는 Microsoft 365 intelligence를 MCP 서버로서 공개하는 것입니다. 공식 문서에서는 읽기, 생성, 업데이트, 삭제, 액션 실행, Copilot 호출, 스키마 발견(Schema Discovery) 등을 10개의 범용 도구로 처리하도록 설계되어 있다고 설명합니다.

여기서 중요한 것은 '도구의 수를 늘리는 것'이 아니라 '경로(Path)와 스키마(Schema)를 실행 시점에 발견하는' 방식입니다. 예를 들어, 메일을 읽거나, 일정을 만들거나, Teams 메시지를 가져오는 등의 조작을 개별적인 대량의 도구로 보유하는 것이 아니라, fetch나 create_entity와 같은 범용 도구와 리소스 경로(Resource Path)의 조합으로 처리합니다.

개발자 입장에서는 IDE나 CLI의 AI 어시스턴트가 SharePoint의 사양서, Teams 회의록, 과거 메일 등을 참조하면서 코드 생성이나 조사를 진행하는 용도를 그려볼 수 있습니다.

참고로, MCP에는 Local MCP와 Remote MCP 형태가 있습니다. Local MCP는 Work IQ CLI를 로컬 MCP 서버로 구동하여 IDE나 CLI의 AI 어시스턴트에서 사용하는 방식입니다. Remote MCP는 원격의 Work IQ MCP 엔드포인트(Endpoint)를 사용하는 방식입니다.

제공 상황에 대해서는 참조하는 시기와 페이지에 따라 표기가 달라지므로, 단정적인 표현은 피하는 것이 안전합니다. 정리하면 다음과 같습니다.

• 2026년 6월 7일에 확인한 시점의 API overview (preview)에서는 프로토콜 선택 표에서 'coming soon'이 붙어 있는 것은 REST뿐이며, A2A · Local MCP · Remote MCP는 preview 상태로 참조할 수 있는 것으로 정리되어 있습니다.
• Microsoft 365 Developer Blog에서는 6월 16일 GA(General Availability)에서 A2A · 새로워진 Remote MCP 서버 · REST가 제공된다고 설명하고 있습니다.
• 4~5월의 공개 프리뷰(Public Preview) 공지 시점에서는 REST와 Remote MCP가 'coming soon' 취급이었습니다.

즉, '언제, 어떤 페이지를 보았느냐'에 따라 상황이 다릅니다. 구현 전에는 반드시 최신 공식 문서에서 제공 상황을 확인하시기 바랍니다.

정보 시스템(情シス) 담당자에게는 MCP 서버를 어느 테넌트(Tenant)에서 허용할지, 어떤 사용자나 그룹이 사용하게 할지, 관리자 동의(Admin Consent)를 어떻게 처리할지가 논점이 됩니다.

보충: REST API는 위에서 언급한 바와 같이 API overview의 현재 페이지(2026년 6월 7일 확인 시점)에서는 'coming soon'으로 표기되어 있습니다. 다음은 공개된 REST overview (preview)의 내용에 기반한 정리이며, 실제 이용 가능 여부는 시기에 따라 달라질 수 있습니다.

Work IQ REST API는 독자적인 앱에서 Microsoft 365 Copilot과 멀티 턴(Multi-turn) 대화를 프로그래밍 방식으로 수행하는 입구입니다.

공식 문서에서는 엔터프라이즈 검색 그라운딩(Enterprise Search Grounding)과 웹 검색 그라운딩(Web Search Grounding)을 사용하여 Microsoft 365의 신뢰 경계(Trust Boundary) 내에서 답변을 반환한다고 설명합니다. 이를 통해 독자적으로 벡터 DB, 검색 기반, 오케스트레이션(Orchestration) 계층을 구축해야 하는 부담을 줄일 수 있을 가능성이 있습니다.

반면, REST API에는 제약 사항도 있습니다. 공개된 정보에 따르면 파일 생성, 메일 전송, 회의 생성과 같은 액션이나 콘텐츠 생성 스킬은 지원되지 않으며, 텍스트 응답만 가능하고, 장시간 작업은 타임아웃(Timeout)되기 쉽다는 제한이 명시되어 있습니다.

따라서 REST는 우선 '업무용 앱에 Copilot 스타일의 답변을 통합하는' 용도에 적합합니다. 실행 계열의 조작까지 맡기고 싶다면 MCP나 Copilot Studio의 액션, Power Platform 커넥터(Connector) 등을 포함하여 설계해야 합니다.

Work IQ API의 실무적인 최대 논점은 기능 그 자체보다 "누구의 권한으로 무엇이 보이는가"입니다.

공식 문서에 따르면, Work IQ는 Microsoft Entra ID의 위임된 인증 (delegated authentication)을 사용하며, 요청은 로그인한 사용자의 컨텍스트 (context)에서 실행된다고 설명되어 있습니다. On-behalf-of (OBO) 플로우는 지원되지만, 애플리케이션 전용 인증 (application-only authentication)은 지원되지 않는 것으로 명시되어 있습니다.

이는 상당히 중요한 지점입니다.

애플리케이션 권한으로 "백엔드가 무엇이든 읽을 수 있는" 방식이 아니라, 기본적으로 사용자가 Microsoft 365 상에서 접근할 수 있는 범위에 따라 Work IQ가 응답한다는 개념입니다. Microsoft 365의 권한, 민감도 레이블 (sensitivity label), 컴플라이언스 정책 (compliance policy)도 자동으로 적용된다고 합니다.

개발자 관점에서는 다음과 같은 설계 판단이 필요합니다.

• 자체 앱 측에서 ACL (Access Control List)을 이중으로 재구현하지 않는다
• 단, 앱 고유의 인가 (authorization)는 별도로 설계한다
• OBO 플로우를 사용할 경우, 사용자 컨텍스트가 어디에서 유실되는지 확인한다
• 로그에 프롬프트나 답변의 민감한 정보를 함부로 남기지 않는다

정보 시스템(情シス) 관점에서는 다음과 같은 확인이 필요합니다.

• 관리자 동의가 필요한 앱 및 MCP 서버를 파악한다
• 이용 가능한 사용자 및 그룹을 제어한다
• 감사 로그 (audit log) 및 이용 상황을 확인할 수 있는 운영 체계를 구축한다
• SharePoint / OneDrive / Teams의 기존 권한이 과도하지 않은지 점검한다
• 민감도 레이블 및 DLP (Data Loss Prevention) 정책이 실제 업무 데이터에 적용되어 있는지 확인한다

여기서 흔히 발생하는 오해는 "Copilot이나 Work IQ를 도입하면 새로운 정보 유출 경로가 갑자기 생긴다"는 것이 아니라, "기존 권한 설계의 허점이 AI에 의해 더 잘 보이게 된다"는 점입니다.

AI 에이전트는 인간보다 빠르고, 횡단적으로, 자연어로 정보를 탐색할 수 있습니다. 그렇기 때문에 기존의 액세스 권한이 너무 넓을 경우, 그 영향이 체감하기 쉬워집니다.

외부 데이터를 Microsoft 365 Copilot에 넣는 방법으로는 Copilot 커넥터 (Copilot connectors)도 중요합니다.

공식 문서에서는 Copilot 커넥터를 크게 동기화된 커넥터 (synced connectors)와 페더레이션 커넥터 (federated connectors)로 분류합니다.

동기화된 커넥터 (synced connectors)는 외부 데이터를 Microsoft Graph에 인덱싱하여 Copilot이나 Microsoft Search에서 검색할 수 있게 합니다. 각 아이템에 ACL을 부여하여 사용자가 소스 시스템에서 접근할 수 있는 것만 표시하는 구조입니다.

페더레이션 커넥터 (federated connectors)는 MCP를 사용하여 실시간으로 외부 데이터를 가져옵니다. 인덱싱하지 않고 데이터를 소스 측에 남겨둔 채 다룰 수 있기 때문에, 실시간성이 높은 데이터나 Microsoft 365 측으로 가져오고 싶지 않은 데이터에 적합합니다. 다만, 공개된 정보에 따르면 페더레이션 커넥터는 읽기 전용 (read-only)으로 설명되어 있습니다.

정리하자면, 외부 데이터 활용은 다음과 같이 생각할 수 있습니다.

하고 싶은 것	후보
외부 지식을 Copilot Search / Copilot Chat의 검색 대상으로 만들고 싶다	synced connector
...

개발자가 가장 먼저 생각해야 할 것은 "자신의 앱이 AI의 두뇌를 만드는 것인가, 아니면 Microsoft 365 Copilot의 문맥 이해를 빌려 쓰는 것인가"입니다.

독자적인 RAG (Retrieval-Augmented Generation)를 구축할 경우, 데이터 수집, 차분 동기화, ACL, 검색, 재순위화 (re-ranking), 프롬프트 구축, 감사, 삭제 반영 등을 직접 처리해야 합니다. 이는 자유도가 높은 반면, Microsoft 365 데이터를 안전하게 다루기 위해서는 구현 및 운영 비용이 커집니다.

Work IQ API를 사용할 경우, Microsoft 365 측의 시맨틱 인덱스 (semantic index), Copilot의 그라운딩 (grounding), 기존 권한, 테넌트 경계 (tenant boundary)를 활용할 수 있습니다. 대신 제공되는 API의 제약, 프리뷰 단계의 변경, 라이선스 및 과금 등의 상업적 조건을 수용해야 합니다.

과금에 대해서는 참조하는 문서에 따라 전제가 다르므로, 혼동하지 않도록 주의가 필요합니다.

• Microsoft 365 블로그나 Developer Blog에서는 Work IQ API 전체를 Copilot Credits 기반의 종량제 과금 (GA 이후의 모습)으로 설명하고 있습니다. Tools는 고정 요소, Chat / Context는 변동 요소를 갖는 것으로 간주되며, Microsoft 365 관리 센터에는 Copilot Credits 사용 현황, 과금 방식 (선불 / 종량제), 지출 제한, 사용자 및 그룹 단위 관리에 관한 대시보드가 추가될 예정입니다. - 반면, REST API overview (preview)의 Licensing 항목에는, Microsoft 365 Copilot 애드온 라이선스를 보유한 사용자는 REST API를 추가 비용 없이 이용할 수 있으며, 라이선스를 보유하지 않은 사용자를 위한 제공은 현 시점에서 미지원이라고 명시되어 있습니다.

이 두 가지는 "전체 종량제 모델 (GA 가정)"과 "현재 REST 프리뷰 시점에서의 라이선스 조건"이라는 서로 다른 레이어의 이야기이며, 전제가 다릅니다. 어느 한쪽만 보고 "추가 비용 없음" 또는 "모두 종량제 과금"이라고 단정하면 오해하기 쉬운 부분입니다.

비용 산출을 할 때는 대상 프로토콜 (REST / MCP / A2A), preview 여부 또는 GA 여부, 대상 사용자의 Copilot 라이선스 보유 여부를 구분한 뒤, 최신 문서로 확인하는 것이 안전합니다. IT 운영(情シス) 측면에서는 기술 검증과 동시에 이용량 관리 설계도 함께 살펴볼 필요가 있습니다.

현실적으로는 다음과 같은 단계적 도입이 좋아 보입니다.

• REST API (제공 상황을 확인한 후)를 통해 사내 앱에 "Microsoft 365 문맥이 포함된 답변"을 통합
• IDE / CLI용 Work IQ MCP를 시도하여 개발자 경험 (Developer Experience)을 검증
• 업무 에이전트에서 필요한 조작을 MCP / Copilot Studio actions / Power Platform connector로 분해
• 외부 데이터는 synced connector와 federated connector를 구분하여 사용
• 권한, 감사, DLP, 민감도 레이블 (Sensitivity Label) 정리를 병행

IT 운영 측면에서는 기술 검증만큼이나 거버넌스 설계가 중요합니다.

• Microsoft 365 Copilot 라이선스 보유 여부
• Work IQ API / MCP 이용에 필요한 관리자 동의
• 이용 대상 사용자 및 그룹
• Copilot Credits, 지출 제한, 이용량 관리 방침
• SharePoint / OneDrive / Teams의 액세스 권한 정리
• 민감도 레이블, DLP, 보존 정책 (Retention Policy) 적용 현황
• 로그, 감사, 인시던트 대응 흐름
• 외부 MCP 서버 및 커스텀 커넥터의 심사 기준

특히 MCP는 편리한 한편, AI 에이전트에게 "사용 가능한 도구"를 전달하는 메커니즘입니다. 인간용 SaaS 연동과 같은 감각으로 허용하면, 권한, 조작, 감사의 정리가 따라가지 못할 가능성이 있습니다.

"어떤 에이전트에게, 어떤 도구를, 누구의 권한으로, 어떤 데이터 범위에 대해 사용하게 할 것인가"를 명문화하는 것이 도입 전 실무 포인트가 됩니다.

Work IQ API는 Microsoft 365 Copilot의 문맥 이해를 외부 앱이나 에이전트에서 사용하기 쉽게 만들기 위한 API 군입니다.

A2A는 에이전트 간의 연동, MCP는 에이전트나 IDE / CLI에 도구와 문맥을 전달하는 입구, REST는 독자적인 앱으로부터 Copilot 스타일의 답변을 얻는 입구라고 정리하면 전망이 명확해집니다. 다만 각 프로토콜의 제공 상황은 preview와 GA의 경계에서 변동되므로, 단정 짓지 말고 최신 문서로 확인하는 것을 전제로 합니다.

그리고 실무에서 가장 중요한 것은 프로토콜 선택만이 아닙니다. Work IQ는 위임된 인증 (Delegated Authentication)을 전제로, 기존의 Microsoft 365 권한 및 컴플라이언스 정책을 존중하도록 설계되었습니다. 즉, 도입의 성패는 API 구현뿐만 아니라 기존의 정보 설계, 액세스 권한, 감사, DLP의 성숙도에도 좌우됩니다.

우선 작은 유스케이스(Use Case)로 REST나 MCP를 시도하면서, 병행하여 Microsoft 365 측의 권한 정리를 진행하는 것이 개발자와 IT 운영자 모두에게 현실적인 첫걸음이라고 생각합니다.

• Microsoft Work IQ API 개요
• Work IQ 개요
• 새로운 Work IQ API 발표 (Microsoft 365 Blog)
• Work IQ: 모든 에이전트를 위한 프로덕션 준비 완료된 지능 (Microsoft 365 Developer Blog)
• Work IQ REST API 개요
• Work IQ MCP 개요
• Work IQ A2A 퀵스타트 (Quickstart)
• Microsoft Work IQ CLI
• Copilot 커넥터 (Connectors) 개요
• 연합 커넥터 (Federated connectors) 개요
• Copilot Studio에서 Model Context Protocol (MCP)을 사용하여 에이전트 확장하기