Work IQ API 6월 16일 GA, M365 에이전트의 10개 도구

AI 요약

• 무슨 일: Microsoft가 Work IQ APIs를 2026년 6월 16일 GA로 전환합니다.
  • 이메일, 일정, 회의, 채팅, 파일, 사람, 협업 패턴을 에이전트용 Microsoft 365 문맥으로 제공합니다.
• 수치: Microsoft는 Fortune 500 평균 600TB 이상 data footprint와 80% token 절감을 제시했습니다.
• 구조: API domain은 Chat, Context, Tools, Workspaces 네 가지입니다.
  • Tool calling은 MCP progressive disclosure로 10개 generic tools까지 줄인다고 설명했습니다.
• 주의점: 비용은 Copilot Credits 기반이며, GitHub preview는 tenant admin consent와 API 변경 가능성을 명시합니다.

Microsoft 365 Blog는 2026년 6월 2일 Work IQ APIs가 2026년 6월 16일 일반 제공(GA)에 들어간다고 발표했습니다. Work IQ는 Microsoft 365 안의 이메일, 일정, 회의, 채팅, 파일, 사람, 협업 패턴, 업무 시스템을 처리해 에이전트가 쓸 수 있는 조직 문맥을 만드는 계층입니다. Microsoft는 이 API를 "Microsoft 365 data and apps"와 상호작용하는 에이전트의 기본 경로로 소개했습니다.

이번 발표는 Microsoft Build 2026의 여러 에이전트 발표 중 하나입니다. 같은 날 Official Microsoft Blog는 Microsoft IQ가 GitHub Copilot, Microsoft Foundry, Copilot Studio에서 사용할 수 있는 context layer라고 설명했습니다. 그 안에서 Work IQ는 workplace intelligence, Fabric IQ는 structured business data, Foundry IQ는 retrieval planning, Web IQ는 MCP-native web grounding을 맡습니다. devlery가 최근 다룬 Scout, Rayfin, MAI-Code-1, Aion, ASSERT/ACS가 실행 환경과 모델, 거버넌스 쪽이었다면 Work IQ APIs는 Microsoft 365 업무 데이터 자체를 에이전트 표면으로 바꾸는 발표입니다.

Work IQ가 다루는 데이터 범위는 단순한 Microsoft Graph wrapper보다 넓게 제시됩니다. Microsoft는 Work IQ가 email, calendar, meetings, chats, files, people, collaboration patterns, line of business systems를 계속 처리해 회사가 어떻게 일하는지 semantic understanding을 만든다고 설명했습니다. 발표문 안의 예시는 "raw data"가 아니라 business context를 agent에 넣는다는 쪽에 가깝습니다. 사내 회의록, Teams 대화, SharePoint 문서, 인물 관계, 조직 구조가 각각 분리된 API 목록으로만 남으면 에이전트는 어떤 정보가 업무상 관련 있는지 매번 추론해야 합니다.

Microsoft가 첫 번째로 내세운 수치는 규모입니다. 공식 이미지 설명에 따르면 Work IQ의 Fortune 500 조직 내 평균 data footprint는 2026년 5월 Microsoft 내부 데이터 기준 600TB를 넘습니다. 이 수치는 제품 성능 benchmark가 아니라 Microsoft 365가 이미 보유한 업무 데이터의 크기를 보여주는 지표입니다. 개발자에게는 다른 함의가 있습니다. 에이전트가 읽을 수 있는 context가 커질수록 검색, 권한, citation, 비용, stale data 처리가 API 설계의 중심으로 들어옵니다.

두 번째 수치는 tool surface입니다. Microsoft는 Work IQ APIs가 MCP의 progressive disclosure를 사용해 operations를 10개 generic tools로 줄인다고 밝혔습니다. 기존 방식에서는 agent가 메일, 일정, 파일, 사람, 메시지마다 세부 API와 schema를 배워야 합니다. Work IQ Tools는 resource path와 verb 조합으로 업무 범위를 지정하고, 새 데이터 유형이 늘어날 때마다 tool 목록을 끝없이 늘리지 않는 설계를 택합니다. 이 부분은 agent prompt와 tool schema token 비용을 직접 건드립니다.

공식 구조는 네 가지 domain으로 나뉩니다. Chat은 Microsoft 365 Copilot이 사용자에게 돌려줄 답변과 citation에 programmatic access를 제공합니다. Context는 Copilot이 답변에 사용할 source data를 agent-ready format으로 반환합니다. Tools는 이메일 전송, 회의 일정 생성, 문서 업로드 같은 Microsoft 365 entity와 action에 접근합니다. Workspaces는 장시간 에이전트가 reasoning 중간에 만든 state, file, memory, progress, intermediate output을 Microsoft 365 tenant boundary 안에 저장하는 영역입니다.

Workspaces가 별도 domain으로 들어간 점은 장시간 에이전트 운영에서 눈에 띕니다. Microsoft는 Copilot Cowork, Microsoft Scout 같은 long-running agents를 만들면서 이 영역이 critical enabler였다고 밝혔습니다. 개인 비서형 에이전트가 회의 준비, 일정 충돌 정리, 문서 초안 수정을 며칠에 걸쳐 수행한다면 중간 상태를 어디에 저장하는지가 제품 요구사항이 됩니다. 외부 vector store나 임시 worker storage에 업무 파일과 progress를 흩뿌리는 대신 Microsoft 365 tenant 안에 둔다는 설계입니다.

효율성 주장은 더 직접적입니다. Microsoft는 Work IQ APIs가 기존 API 대비 total token을 줄인다고 설명했습니다. 이유는 orchestration layer가 raw data를 받아 다시 읽고 붙이고 해석하는 대신, Work IQ runtime 안의 specialized LLMs와 agents가 agent가 소비하기 쉬운 구조로 context와 data를 포장하기 때문입니다. 발표문은 file record strings, message IDs, app IDs trimming도 token 절감 요소로 들었습니다.

Microsoft가 공개한 chart는 내부 coding harness 기준으로 Work IQ APIs가 traditional APIs보다 token을 80% 적게 쓴다는 주장입니다. 같은 발표에는 runtime 기준 2배 빠르다는 chart도 포함됐습니다. 둘 다 외부 재현 benchmark는 아닙니다. 업무 데이터, connector, tenant policy, 질문 유형에 따라 결과는 달라질 수 있습니다. 그래도 이 수치가 기사 가치가 있는 이유는 Microsoft가 에이전트 플랫폼 경쟁에서 모델 성능보다 API surface와 token bill을 제품 차별점으로 내세웠다는 점입니다.

비용 모델도 함께 공개됐습니다. Work IQ APIs는 Copilot Credits로 표시되는 consumption-based pricing을 사용합니다. Tools에는 fixed component가 있고, Chat과 Context에는 variable component가 있습니다. Microsoft 365 admin center에는 cost management dashboard가 추가됩니다. 관리자는 AI credit usage를 보고, prepaid 또는 pay-as-you-go billing을 구성하고, tenant, group, user 단위 spending limit을 걸고, user credit request를 모니터링할 수 있습니다. Work IQ APIs가 이 경험으로 관리되는 첫 제품이고, Microsoft는 Copilot Studio 같은 추가 제품도 이후 포함한다고 설명했습니다.

이 비용 화면은 에이전트 도입의 병목을 잘 보여줍니다. 사람이 Microsoft 365 앱을 열어 문서를 찾는 비용은 보통 좌석 라이선스 안에 묻힙니다. 에이전트는 다릅니다. 한 요청이 메일, 일정, 파일, Teams 메시지, 사람 정보, 외부 업무 시스템을 연속으로 조회할 수 있습니다. 여러 agent session이 병렬로 돌면 같은 사용자의 업무 context 접근이 수십 배 늘어납니다. 따라서 credit budget, group limit, audit, chargeback이 개발 단계부터 붙어야 합니다.

개발자 진입점은 microsoft/work-iq GitHub repository입니다. README는 "MCP Server and CLI for accessing Work IQ"라고 설명하고, 공식 Microsoft Work IQ plugin collection for GitHub Copilot이라고 소개합니다. Quick Start에는 GitHub Copilot CLI에서 /plugin marketplace add microsoft/work-iq를 실행하는 단계가 있습니다. 이후 workiq@work-iq, workiq-preview@work-iq, microsoft-365-agents-toolkit@work-iq, workiq-productivity@work-iq 같은 plugin을 설치합니다. standalone MCP server로는 npm install -g @microsoft/workiq, workiq mcp, npx -y @microsoft/workiq mcp를 제시합니다.

GitHub README의 경고도 기사에 포함해야 합니다. repository는 Public Preview라서 features와 APIs가 바뀔 수 있다고 명시합니다. Microsoft 365 tenant data에 접근하려면 WorkIQ CLI와 MCP Server가 tenant admin 권한이 필요한 permission consent를 받아야 합니다. 첫 접근 시 consent dialog가 뜨고, 사용자가 관리자가 아니면 tenant administrator가 접근을 승인해야 합니다. 개인 개발자가 빠르게 붙여 보는 API라기보다 회사 계정, Entra tenant, 관리자 승인 절차를 전제로 둔 preview입니다.

보안 측면에서 Work IQ의 약속은 Microsoft 365 tenant trust boundary입니다. Microsoft는 data, context, insights가 tenant boundary 안에 남고, agent action이 auditable and discoverable하다고 설명했습니다. 이 문장은 제품 홍보 문장으로 읽고 넘어갈 수 없습니다. 업무 에이전트가 사람 대신 메일을 보내고, 회의를 잡고, 파일을 업로드한다면 누가 어떤 권한으로 어떤 source를 읽었고 어떤 action을 수행했는지가 사후 조사 가능해야 합니다. Purview, Entra, Defender 계열의 정책과 연결되지 않은 에이전트는 enterprise deployment에서 곧바로 막힐 수 있습니다.

Work IQ APIs의 네 domain은 기존 Microsoft Graph 사용 방식과도 다르게 읽힙니다. Graph는 endpoint와 entity 중심 API입니다. Work IQ는 에이전트가 질문하고, source context를 받고, action tool을 호출하고, 중간 state를 저장하는 agent loop 중심 API입니다. 개발자는 "어떤 endpoint를 몇 번 호출할까"뿐 아니라 "Copilot이 합성한 답변을 받을지, 합성 전 context만 받을지, 어떤 action은 generic tool로 보낼지, 중간 산출물은 workspace에 남길지"를 정해야 합니다.

경쟁 구도에서는 Google, AWS, Salesforce, ServiceNow가 같은 문제를 다른 데이터 기반으로 풀고 있습니다. Google은 Gemini Enterprise Agent Platform과 Agentspace 계열로 Workspace, Drive, Search, enterprise connector를 묶습니다. AWS는 Bedrock Knowledge Bases와 AgentCore로 runtime, memory, tool execution을 연결합니다. Salesforce는 Agentforce를 CRM 데이터와 workflow에 붙입니다. Microsoft의 강점은 Outlook, Teams, SharePoint, OneDrive, Office 문서, 조직도처럼 지식 노동자의 하루가 이미 Microsoft 365에 쌓인다는 점입니다.

한국 기업의 검토 포인트는 네 가지입니다. 첫째, Microsoft 365를 업무 중심으로 쓰는 조직이라면 Work IQ가 기존 Graph integration을 대체할지 보완할지 결정해야 합니다. 둘째, admin consent와 tenant boundary가 개발 환경, staging tenant, production tenant에서 어떻게 분리되는지 확인해야 합니다. 셋째, Copilot Credits 비용을 부서별로 나눌 수 있는지, agent가 무한 반복하거나 대량 context를 요청할 때 spending limit이 실제로 막는지 테스트해야 합니다. 넷째, Workspaces에 저장되는 중간 산출물이 보존, 삭제, eDiscovery, 감사 정책에서 어떤 위치를 갖는지 법무·보안팀과 함께 봐야 합니다.

커뮤니티 반응은 아직 제품 규모에 비해 작습니다. Hacker News에서 Work IQ APIs 단독 토론은 확인하지 못했습니다. Reddit r/copilotstudio에는 Work IQ User MCP와 Work IQ Copilot MCP 차이를 묻는 글이 있었습니다. r/microsoft365에는 Work IQ CLI public preview를 Microsoft 365 Copilot data에 접근하는 CLI와 MCP server로 소개한 글이 있었습니다. 질문의 방향은 "이 API가 대단한가"보다 "어떤 identity로 접근하고, 어떤 tool이 read-only인지, preview와 GA 사이에 schema가 얼마나 바뀌는지"에 가깝습니다.

Work IQ APIs가 바로 모든 기업 에이전트의 표준이 된다고 보기는 어렵습니다. Microsoft 365 tenant 안에 업무 데이터가 충분히 있고, Copilot Credits 비용을 받아들일 수 있고, Entra/Purview 기반 정책을 이미 운영하는 조직에서 유리합니다. Slack, Google Workspace, Notion, Jira, Confluence, 자체 ERP가 더 큰 조직이라면 Work IQ만으로 업무 문맥을 닫을 수 없습니다. 그 경우 Work IQ는 전체 agent memory가 아니라 Microsoft 365 slice를 담당하는 connector로 들어갑니다.

이번 발표의 실무 결론은 Microsoft가 업무 앱을 "사람이 쓰는 UI"에서 "에이전트가 호출하는 조직 문맥 API"로 재포장한다는 점입니다. 6월 16일 GA 이후 개발자는 Work IQ를 단순 검색 API로 볼지, Copilot Chat의 답변을 가져오는 facade로 볼지, Microsoft 365 action tool surface로 볼지 선택해야 합니다. 같은 API라도 제품 설계는 달라집니다. 사내 지식 Q&A에는 Context와 citation이 먼저 필요하고, 회의 준비 에이전트에는 Chat, Tools, Workspaces가 함께 필요합니다. 비용과 권한은 나중에 붙이는 운영 문제가 아니라 첫 번째 prototype에서 확인해야 할 입력값입니다.