Work IQ API 6월 16일 GA, M365 에이전트 비용표

Microsoft가 2026년 6월 2일 Microsoft 365 Blog에서 Work IQ APIs의 일반 제공 일정을 공개했습니다. GA 날짜는 2026년 6월 16일입니다. 발표문에서 Work IQ는 Microsoft 365 Copilot과 agents 뒤의 workplace intelligence layer로 설명됩니다. 대상 데이터는 이메일, 일정, 회의, 채팅, 파일, 사람, 협업 패턴, line-of-business systems입니다. 이 발표는 단순한 Graph API 확장이 아니라, agents가 Microsoft 365 업무 문맥을 읽고 행동하는 API 표면을 새로 묶는 사건입니다.

Build 2026의 공식 블로그는 같은 날 Microsoft IQ를 GitHub Copilot, Microsoft Foundry, Copilot Studio 전반의 context layer로 설명했습니다. 그 안에서 Work IQ는 workplace intelligence, Fabric IQ는 structured business data, Foundry IQ는 enterprise knowledge와 live web retrieval planning, Web IQ는 MCP-native web grounding을 맡습니다. Microsoft가 Work IQ APIs를 별도로 발표한 이유는 Microsoft 365 agent가 "데이터를 검색하는 앱"을 넘어 조직 안에서 어떤 일이 어떻게 진행되는지까지 사용해야 한다는 제품 판단 때문입니다.

Work IQ API architecture는 네 domain으로 나뉩니다. Chat은 Microsoft 365 Copilot이 사용자에게 줄 답변과 citation을 programmatic하게 반환합니다. Context는 Copilot이 답변에 쓸 context와 source data를 agent consumption format으로 돌려줍니다. Tools는 이메일 발송, 회의 예약, 문서 업로드 같은 Microsoft 365 entity와 action을 stable verbs와 resource paths로 다룹니다. Workspaces는 장기 실행 agent가 중간 상태, 파일, memory, progress, intermediate outputs를 Microsoft 365 tenant boundary 안에 저장하는 영역입니다.

Microsoft Learn의 Work IQ API overview는 protocol 선택 기준을 더 구체적으로 적습니다. 다른 agent가 Work IQ에 작업을 위임하고 structured result를 받아야 하면 A2A를 씁니다. 사용자가 GitHub Copilot 같은 LLM client에서 Work IQ를 도구로 호출해야 하면 MCP가 맞습니다. 앱이나 backend가 Work IQ를 직접 호출해 응답을 렌더링하는 구조라면 REST가 자연스럽지만, preview 문서에서는 REST API를 coming soon으로 표시합니다. 이 구분은 agent product의 UI 위치보다 실행 주체와 권한 경계를 먼저 보라는 뜻입니다.

Microsoft 365 Blog는 Work IQ APIs가 tool calling surface를 "10 generic tools"로 접고, MCP의 progressive disclosure를 통해 hundreds of data-specific tools를 agent에게 가르칠 필요를 줄인다고 설명했습니다. 이 문장은 개발자에게 실용적인 의미가 있습니다. 지금까지 enterprise agent를 만들 때 흔한 실패는 tool schema가 업무 시스템마다 늘어나고, 모델이 어떤 도구를 언제 써야 하는지 모르는 문제였습니다. Microsoft는 Work IQ runtime 쪽에 더 많은 판단과 context packaging을 넣어 agent orchestration layer의 부담을 줄이겠다고 말합니다.

발표문의 수치도 이 방향을 뒷받침합니다. Microsoft는 Work IQ가 Fortune 500 조직에서 평균 600TB가 넘는 data footprint를 다룬다고 적었습니다. 또한 Work IQ APIs가 traditional APIs보다 runtime 기준 2배 빠르고, coding harness 내부 테스트에서 80% fewer tokens를 쓴다는 이미지를 실었습니다. 이 숫자는 독립 benchmark가 아니라 Microsoft 내부 자료입니다. 그래도 기사에서 볼 부분은 절대 성능 순위가 아니라, Microsoft가 Work IQ의 가치를 "더 많은 데이터 접근"보다 latency와 token budget 절감으로 판매한다는 점입니다.

보안 모델은 Work IQ의 핵심 판매 포인트입니다. Microsoft 365 Blog는 data, context, insights가 Microsoft 365 tenant trust boundary 안에 머물고 agent actions가 auditable, discoverable하다고 설명했습니다. Microsoft Learn 문서는 요청이 signed-in user context에서 실행되고, Microsoft 365 permissions, sensitivity labels, compliance policies가 자동으로 적용된다고 적습니다. 인증은 Microsoft Entra ID delegated authentication이며 on-behalf-of flow를 지원합니다. 반대로 application-only authentication은 지원하지 않는다고 명시합니다.

이 제한은 기업 개발팀에 불편할 수 있지만, Work IQ의 성격을 보여줍니다. 일반적인 backend service라면 daemon이나 batch worker가 application permission으로 조직 데이터를 훑는 패턴이 익숙합니다. Work IQ는 agent가 사용자를 대신해 Microsoft 365 문맥을 다루는 쪽에 더 가깝습니다. 따라서 "내 서비스가 조직 전체를 읽는다"보다 "이 signed-in user가 볼 수 있는 정보를 agent가 읽고 행동한다"가 기본 권한 모델입니다. 내부 agent 플랫폼을 설계하는 팀은 service account 중심 구조를 그대로 옮길 수 있는지 먼저 확인해야 합니다.

Work IQ CLI와 MCP server는 개발자 도구 관점에서 별도 의미가 있습니다. GitHub의 microsoft/work-iq 저장소 설명은 Work IQ plugins, MCP servers, skills, tools가 AI assistants를 Microsoft 365 data에 연결한다고 소개합니다. 저장소 설명에는 Microsoft 365 tenant data 접근을 위해 WorkIQ CLI와 MCP Server가 tenant admin rights가 필요한 permissions에 consent되어야 한다는 문구도 있습니다. 개인 개발자가 npm package 하나 설치하듯 붙이는 도구가 아니라, tenant admin과 보안팀이 consent 범위를 검토해야 하는 connector입니다.

이 지점은 최근 AI coding assistant 생태계와 맞물립니다. Cursor, Claude Code, Codex, GitHub Copilot 같은 도구가 repository 안에서 작업을 대신할수록, 개발자는 코드뿐 아니라 회의록, issue 논의, 제품 문서, 고객 메일, 조직도까지 agent context로 넣고 싶어집니다. Work IQ MCP가 겨냥하는 사용 장면은 "지난주 Teams에서 논의한 출시 위험을 요약하고, 관련 OneDrive 문서를 찾아 PR 설명에 반영해 달라" 같은 요청입니다. 이 요청은 단일 검색 API보다 권한, citation, 최신성, 감사 로그가 더 중요합니다.

가격은 이번 발표에서 독립적인 뉴스입니다. Microsoft 365 Blog는 Work IQ APIs가 consumption-based pricing을 쓰며, Tools는 fixed component, Chat과 Context는 variable component라고 밝혔습니다. 과금 단위는 Copilot Credits입니다. Microsoft Licensing Resources의 Work IQ GA 페이지도 2026년 6월 16일부터 Work IQ API가 Copilot Credits 기반 consumption model로 청구된다고 설명합니다. June 1 이후 GitHub Copilot이 AI Credits로 이동한 흐름과 같이 보면, Microsoft의 agent product는 seat 가격에서 usage accounting을 더 많이 요구하는 방향으로 움직입니다.

Microsoft가 비용 관리 dashboard를 함께 발표한 것도 이 때문입니다. Microsoft 365 admin center에서 IT admin은 AI credit usage를 보고, prepaid와 pay-as-you-go billing을 설정하고, tenant, group, user 단위 spending limit를 둘 수 있습니다. 발표문은 Work IQ APIs가 이 경험으로 관리되는 첫 제품이며, 시간이 지나면 Copilot Studio 같은 추가 제품도 Copilot Credits 체계에 들어온다고 적었습니다. agent가 반복 실행되는 조직에서는 월말 invoice보다 실행 전 spending policy가 더 중요해집니다.

커뮤니티 반응은 아직 Work IQ API 자체보다 AI Credits 쪽에 더 몰려 있습니다. Hacker News와 GeekNews에서 Work IQ APIs 단독 토론은 크게 보이지 않았습니다. Reddit에서는 Work IQ CLI/MCP preview를 Microsoft 365 data access 도구로 소개한 글이 있었고, June 1 이후 GitHub Copilot usage-based billing에 대한 불만과 비용 계산 글이 더 많이 공유됐습니다. 이 반응은 Work IQ가 기능적으로는 enterprise context API이지만, 실제 도입 논의에서는 "agent가 얼마나 자주 context를 읽고 얼마를 태우는가"가 먼저 나올 수 있음을 보여줍니다.

개발팀이 검토할 첫 번째 항목은 API domain 선택입니다. 직원 질문에 Copilot식 답변을 그대로 보여주는 제품이면 Chat이 빠릅니다. 자체 agent가 근거 자료를 받아 별도 planning이나 workflow를 돌린다면 Context가 맞습니다. 실제 업무 action을 수행하려면 Tools가 필요합니다. 장기 실행 agent가 중간 파일과 상태를 남긴다면 Workspaces를 봐야 합니다. 네 domain을 모두 켜는 설계는 편하지만, 권한 검토와 비용 추적은 더 복잡해집니다.

두 번째 항목은 protocol boundary입니다. A2A는 agent-to-agent delegation에 어울리고, MCP는 IDE와 CLI에 들어간 AI assistant가 사용자 대신 context를 가져올 때 맞습니다. REST는 서비스가 자체 UI와 workflow를 갖고 Work IQ를 backend dependency로 쓰는 구조에 가깝습니다. Microsoft Learn이 같은 기능을 여러 protocol로 노출하는 이유는 agent가 어디서 실행되는지, 누가 user context를 갖는지, 결과를 누가 렌더링하는지가 조직마다 다르기 때문입니다.

세 번째 항목은 permission trimming입니다. Work IQ가 Microsoft 365 permission과 sensitivity label을 따른다는 점은 강점이지만, agent product의 UX에서는 예상치 못한 결과를 만들 수 있습니다. 같은 질문이라도 사용자 A와 사용자 B가 다른 답을 받습니다. 어떤 사용자는 관련 문서를 보지 못해 incomplete context를 받습니다. agent가 "자료가 없습니다"라고 말할 때 실제로 자료가 없는지, 사용자의 permission 때문에 빠졌는지 UI에서 설명해야 합니다. 그렇지 않으면 개발팀은 retrieval quality 문제와 권한 문제를 구분하기 어렵습니다.

네 번째 항목은 audit artifact입니다. 발표문은 Work IQ의 agent operations가 auditable and discoverable하다고 말합니다. enterprise agent에서 이 문장은 기능 설명보다 운영 요구사항입니다. 어떤 질문이 어떤 context를 읽었고, 어떤 tool action이 실행됐으며, 누가 승인했고, 어떤 workspace에 중간 산출물이 남았는지를 나중에 재구성해야 합니다. 특히 이메일 발송, 회의 예약, 문서 업로드처럼 실제 업무 action을 수행하는 Tools domain은 chat transcript만으로 감사가 끝나지 않습니다.

다섯 번째 항목은 비용 attribution입니다. Work IQ APIs는 Tools, Chat, Context가 서로 다른 가격 구조를 갖습니다. 한 agent run이 회의 3개, Teams thread 5개, OneDrive 문서 12개를 읽고 Copilot answer를 요청한 뒤 이메일 초안을 만든다면, 비용은 단일 "agent run"으로 보이지 않을 수 있습니다. Microsoft의 dashboard가 tenant, group, user spending limit를 다루는 이유도 여기에 있습니다. 제품팀은 기능 출시 전에 user, team, workflow, customer account 중 어느 단위로 Copilot Credits를 귀속할지 정해야 합니다.

Microsoft가 Work IQ를 공개한 타이밍은 Build 2026의 다른 agent governance 발표와도 연결됩니다. 같은 날 Microsoft Foundry Blog는 ASSERT와 Agent Control Specification을 공개하며, agent evaluation과 runtime control을 open-source와 standard 형태로 설명했습니다. Work IQ는 Microsoft 365 data and action plane이고, ASSERT/ACS는 agent policy와 control plane에 가깝습니다. 둘을 함께 보면 Microsoft의 enterprise agent 전략은 모델 제공보다 context, action, governance, billing을 묶는 쪽으로 무게가 이동합니다.

경쟁 구도에서는 Google Workspace, Salesforce Agentforce, ServiceNow AI agents가 떠오릅니다. 모두 조직 데이터를 agent context로 바꾸고, 기존 SaaS 권한 모델을 유지하며, 업무 action까지 이어가려 합니다. Work IQ의 차별점은 Microsoft 365 안의 협업 데이터 밀도와 Copilot 배포 기반입니다. 반대로 약점은 Microsoft 365 tenant에 묶이는 성격, delegated auth 중심의 제약, Copilot Credits 비용 예측입니다. 멀티 SaaS 조직은 Work IQ 하나로 모든 business context를 해결하기 어렵습니다.

이번 발표의 실무 결론은 명확합니다. Microsoft 365 안에서 agent를 만들려는 팀은 Graph API, vector database, custom sync job을 먼저 떠올리기 전에 Work IQ API를 검토해야 합니다. 그러나 검토 순서는 "얼마나 똑똑한가"가 아니라 "누가 어떤 권한으로 읽고, 어떤 protocol로 호출하고, 어떤 action을 남기며, 어떤 Copilot Credits 한도 안에서 반복 실행되는가"여야 합니다. Work IQ는 agent context 문제를 줄여주지만, 조직의 권한 설계와 비용 책임까지 대신 정해주지는 않습니다.

앞으로 확인할 지표는 세 가지입니다. 첫째, 6월 16일 GA 시점의 REST와 Remote MCP availability가 preview 문서와 얼마나 달라지는지입니다. 둘째, Microsoft가 내부 수치로 제시한 2배 속도와 80% token 절감이 고객 case study나 독립 측정으로 이어지는지입니다. 셋째, Copilot Credits dashboard가 실제 agent workflow의 per-run, per-user, per-team 비용을 충분히 설명하는지입니다. agent가 업무 시스템 안으로 들어갈수록, API surface보다 비용표와 감사 로그가 adoption 속도를 결정합니다.