Work IQ API 6월 16일 GA, Microsoft 365 에이전트 과금선

AI 요약

• 무슨 일: Microsoft가 2026년 6월 16일 Work IQ APIs를 일반 제공한다고 발표했습니다.
  • API는 Chat, Context, Tools, Workspaces 네 도메인으로 Microsoft 365의 이메일·회의·파일·사람 관계를 에이전트가 쓰는 형태로 제공합니다.
• 개발자 포인트: Work IQ Tools는 MCP progressive disclosure로 도구 표면을 10개 generic tools까지 줄인다고 설명됩니다.
  • Context API는 Copilot 답변이 아니라 에이전트가 소비할 수 있는 source context를 돌려주는 쪽에 가깝습니다.
• 비용과 통제: 과금은 Copilot Credits consumption model이며, ASSERT와 ACS는 평가·제어를 agent loop 안으로 끌어옵니다.

Microsoft가 Build 2026 첫날인 2026년 6월 2일 Work IQ APIs 일반 제공 일정을 공개했습니다. 날짜는 2026년 6월 16일입니다. Microsoft 365 Copilot 화면 안에서 보이던 Work IQ가 이제 개발자 API, Copilot Credits 과금, admin center 비용 관리, MCP/A2A/REST 접근 표면으로 내려옵니다. 5월 28일의 Copilot 재설계가 사용자가 보는 입력창과 앱 안 실행면을 바꾼 소식이었다면, 이번 발표는 외부 개발자와 기업 IT가 에이전트에 Microsoft 365 업무 컨텍스트를 붙이는 방식에 가깝습니다.

Microsoft의 설명에 따르면 Work IQ는 이메일, 일정, 회의, 채팅, 파일, 사람, 협업 패턴, line-of-business 시스템을 계속 처리해 조직이 일하는 방식을 semantic model로 만듭니다. 이 문장은 추상적으로 들리지만 API 표면은 네 가지로 나뉩니다. Chat은 Microsoft 365 Copilot의 답변과 Copilot 안 에이전트 접근을 제공합니다. Context는 Copilot이 답변에 쓸 자료를 합성 답변이 아니라 에이전트 소비용 구조로 돌려줍니다. Tools는 이메일 발송, 회의 예약, 문서 업로드 같은 Microsoft 365 action을 단순한 verb와 resource path로 노출합니다. Workspaces는 장시간 실행되는 에이전트의 중간 상태, 파일, 기억, 진행 상황을 Microsoft 365 tenant boundary 안에 저장합니다.

개발자에게 가장 직접적인 변화는 Context와 Tools입니다. 지금까지 많은 업무 에이전트는 Microsoft Graph, SharePoint, Teams, Outlook, CRM connector, 자체 retrieval pipeline을 따로 묶어 컨텍스트를 만들었습니다. 이 방식은 권한 trimming, 출처 citation, 파일 schema, meeting signal, 사람 관계, 감사 로그를 각각 처리해야 합니다. Work IQ API의 주장은 이 조립 비용 일부를 Microsoft 365 런타임으로 가져가겠다는 것입니다. Context API가 raw data 대신 agent-ready context를 돌려준다는 설명은 단순 검색 API와 구분되는 지점입니다.

Tools 도메인도 같은 문제를 겨냥합니다. Microsoft는 Work IQ APIs가 MCP progressive disclosure를 사용해 수백 개의 데이터별 도구를 가르치는 대신 10개 generic tools로 tool calling 표면을 줄인다고 말합니다. 이 수치가 모든 업무 시나리오의 복잡도를 사라지게 만들지는 않습니다. 그래도 에이전트 개발자가 매번 sendMail, createEvent, uploadDocument, searchDriveItem 같은 세부 API를 모델 프롬프트에 직접 설명하는 구조와는 다릅니다. 모델은 좁은 도구 이름을 외우기보다 verb와 resource path를 통해 작업 범위를 지정하고, Work IQ runtime이 Microsoft 365 내부 지식과 권한을 적용하는 방식입니다.

Microsoft가 제시한 성능·효율 수치는 공격적입니다. 발표문에는 Fortune 500 조직에서 Work IQ의 평균 데이터 footprint가 600TB 이상이라는 이미지 설명이 들어갑니다. 또 Work IQ APIs가 기존 API 대비 runtime 기준 2배 빠르고, coding harness에서 80% 적은 토큰을 쓴다는 이미지 설명도 포함됐습니다. 이 숫자는 Microsoft 내부 데이터와 테스트라는 점을 분리해서 읽어야 합니다. 독립 벤치마크가 아니라 제품 발표 수치이기 때문입니다. 다만 수치의 방향은 명확합니다. Microsoft는 업무 에이전트의 병목을 모델 성능만이 아니라 컨텍스트 조립, 도구 surface area, round trip, token budget으로 보고 있습니다.

과금 방식은 이 발표를 더 현실적인 뉴스로 만듭니다. Work IQ APIs는 Copilot Credits 단위의 consumption-based pricing을 사용합니다. Tools에는 fixed component가 있고, Chat과 Context에는 variable component가 붙습니다. Microsoft 365 admin center에는 새 cost management dashboard가 들어갑니다. IT 관리자는 AI credit 사용량을 보고, prepaid 또는 pay-as-you-go billing을 설정하고, tenant·group·user 단위 spending limit와 credit request를 모니터링할 수 있습니다. Work IQ APIs는 이 관리 경험에 들어가는 첫 제품이며, Microsoft는 Copilot Studio 같은 다른 Copilot Credits 제품도 뒤따를 것이라고 밝혔습니다.

이 대목은 기업 AI 팀의 도입 판단을 바꿉니다. Work IQ는 "Microsoft 365 데이터를 에이전트가 잘 찾게 한다"는 기능만 팔지 않습니다. 실제 구매 질문은 "Context 호출 하나가 얼마인가", "Tools 호출과 Chat 호출의 비용 모델이 어떻게 다른가", "사용자별 spending limit가 어느 수준까지 강제되는가", "Copilot 라이선스가 없는 내부 앱에서도 consumption model로 쓸 수 있는가"로 내려갑니다. Microsoft 365 Developer Blog는 Work IQ API access가 Microsoft 365 Copilot licensing과 독립적인 consumption model로 제공된다고 설명합니다. 이 조건은 Copilot 사용자 UI와 별개로 백오피스 자동화나 사내 에이전트에 Work IQ를 붙이려는 팀에게 중요합니다.

같은 Build 2026 발표에서 Microsoft는 Work IQ를 더 큰 Microsoft IQ 체계 안에 넣었습니다. 공식 Build 글은 Microsoft IQ, Work IQ, Fabric IQ, Foundry IQ, Web IQ를 함께 설명합니다. Work IQ는 Microsoft 365 업무 신호를 다룹니다. Fabric IQ는 구조화된 business data의 semantic foundation을 맡고, Foundry IQ는 enterprise knowledge와 live web retrieval planning을 연결합니다. Web IQ는 MCP-native web grounding을 맡는 식입니다. 이 포장은 Microsoft가 모델 제공자보다 enterprise context provider로 포지셔닝하려는 시도입니다.

새로 발표된 Microsoft Scout도 이 그림에 붙습니다. Build 글은 Scout를 Frontier 고객에게 private preview로 제공되는 always-on personal agent라고 설명합니다. Scout는 OpenClaw와 Work IQ 위에서 Teams와 Outlook 같은 도구를 사용해 meeting prep, scheduling conflict, routine task를 처리합니다. Scout 자체가 모든 개발팀에 당장 열리는 제품은 아니지만, Work IQ APIs가 어떤 사용 사례를 염두에 두는지 보여줍니다. 사람이 매번 프롬프트를 입력하는 챗봇보다, 장시간 상태를 들고 다니며 조직 데이터와 도구를 호출하는 업무 에이전트가 목표입니다.

하지만 업무 데이터에 가까워질수록 컨트롤 질문도 커집니다. 에이전트가 회의록과 이메일과 파일을 읽고, 회의를 잡고, 문서를 업로드할 수 있으면 "무엇을 할 수 있는가"보다 "어디서 멈추는가"가 먼저 검증돼야 합니다. Microsoft는 이 부분을 Agent 365, ASSERT, Agent Control Specification, MDASH와 함께 묶었습니다. Agent 365는 로컬 에이전트까지 Entra, Defender, Purview로 관찰·거버넌스·보안을 연결하는 control plane으로 설명됩니다. ASSERT와 ACS는 이 control plane의 개발자 쪽 언어에 가깝습니다.

Microsoft Foundry Blog는 ASSERT를 policy-driven agent evaluation을 위한 오픈소스 framework로 소개합니다. 정책에서 adversarial test를 만들고, 에이전트가 어디서 실패하는지 드러내는 도구입니다. Agent Control Specification은 input, model, state, tool execution, output 같은 agent loop 지점에서 control을 어디에 어떻게 적용할지 표준화하려는 시도입니다. TechCrunch도 ACS를 에이전트가 여러 환경에 배포될 때 허용 행동을 더 일관되고 세밀하게 제어하려는 오픈소스 표준으로 보도했습니다.

이 조합은 Microsoft의 메시지를 더 분명하게 만듭니다. Work IQ는 컨텍스트와 도구를 엽니다. Copilot Credits는 사용량과 비용을 계량합니다. Agent 365는 inventory와 governance를 봅니다. ASSERT는 배포 전후 평가를 자동화합니다. ACS는 runtime control 지점을 이름 붙입니다. MDASH는 보안 쪽에서 100개 이상 에이전트가 취약점을 찾고 검증하는 시스템으로 소개됐습니다. 각각의 제품과 프로젝트는 다른 팀에서 나온 것처럼 보이지만, Build 2026에서는 기업 에이전트 운영의 한 묶음으로 배열됐습니다.

개발팀이 당장 가져갈 실무 질문은 세 가지입니다. 첫째, Microsoft 365 데이터를 읽는 에이전트가 이미 있다면 자체 retrieval pipeline과 Work IQ Context API의 경계를 비교해야 합니다. 자체 pipeline은 벤더 독립성과 세밀한 제어가 장점이지만, Microsoft 365 내부 권한·관계·meeting signal을 재구성하는 비용이 큽니다. Work IQ는 그 비용을 줄일 수 있지만 Copilot Credits, tenant boundary, Microsoft API availability에 의존합니다.

둘째, tool calling 설계를 다시 봐야 합니다. 에이전트에게 수십 개 Graph API wrapper를 노출하는 방식은 처음에는 빠르지만, 모델이 도구를 선택하는 비용과 prompt surface가 커집니다. Work IQ가 말하는 10개 generic tools 접근은 반대로 작은 표면 위에 resource path와 progressive disclosure를 얹습니다. 자체 에이전트 framework를 쓰는 팀도 이 방향을 참고할 수 있습니다. 도구를 많이 주는 것이 아니라, 작업 범위와 승인 조건을 더 명확히 주는 쪽입니다.

셋째, 비용과 평가를 같은 설계 문서에 넣어야 합니다. Context 호출이 늘어나면 답변 품질은 좋아질 수 있지만 variable credit 비용이 커집니다. Tools 호출은 fixed component라도 action의 위험도가 다릅니다. 이메일 읽기와 외부 발송, 회의 조회와 회의 생성, 파일 검색과 파일 업로드는 같은 도구 호출로 취급할 수 없습니다. ASSERT나 ACS 같은 접근이 필요한 이유도 여기에 있습니다. 평가는 응답 문장만 보지 않고, 어떤 state를 읽고 어떤 tool execution을 허용했는지까지 봐야 합니다.

커뮤니티 반응은 아직 제한적입니다. Hacker News에서 Work IQ APIs GA 자체를 중심으로 큰 토론은 확인하지 못했습니다. Reddit에는 Work IQ MCP public preview나 Work IQ User MCP와 Copilot MCP 차이를 묻는 실무형 글이 있었지만, 6월 2일 Build 발표 이후의 운영 경험은 아직 쌓이지 않았습니다. Build 관련 Reddit 반응 중에는 에이전트 데모와 실제 2시 장애 대응 사이의 간극을 지적하는 의견도 있었습니다. 이 비판은 Work IQ에도 적용됩니다. 컨텍스트 API가 있다고 해서 권한 설계, 승인 단계, 비용 예측, 장애 복구가 자동으로 해결되지는 않습니다.

Microsoft의 강점은 데이터 위치입니다. Microsoft 365는 많은 기업의 이메일, 일정, 문서, 회의, 채팅이 이미 있는 곳입니다. Google Workspace Gemini, OpenAI workspace agents, Glean, Notion AI, Salesforce Agentforce도 업무 컨텍스트를 다룹니다. Microsoft는 Graph, Entra, Purview, Teams, SharePoint, Outlook, Copilot Studio, Agent 365를 한 판매 단위로 묶을 수 있습니다. 반대로 그 강점은 lock-in 질문을 낳습니다. Work IQ가 조직의 업무 지식을 가장 잘 읽는 API가 될수록, 에이전트 아키텍처는 Microsoft tenant와 Copilot Credits 정책에 더 강하게 묶입니다.

이번 발표를 단순한 API 출시로만 보면 작게 보입니다. 그러나 6월 16일 GA되는 것은 Microsoft 365 데이터에 붙는 새 endpoint 몇 개가 아닙니다. 업무 에이전트가 조직 컨텍스트를 읽고, 도구를 호출하고, 상태를 저장하고, 그 사용량을 credit로 계산하며, 평가와 제어 표준 안에서 운영되는 제품 경계입니다. 개발자에게는 편한 컨텍스트 API가 생기는 동시에, 비용·권한·감사·평가를 설계 초반부터 문서화해야 하는 압력이 커집니다.

Work IQ APIs의 다음 확인 지점은 실제 tenant rollout입니다. 공개 문서의 preview 단계에서는 A2A와 local MCP가 제공되고 REST와 remote MCP가 뒤따르는 것으로 설명됐습니다. GA 이후에는 remote MCP, REST endpoint, Copilot Credits 대시보드, tenant별 제한, admin approval flow, audit evidence가 실제로 어느 수준까지 동작하는지 봐야 합니다. Microsoft가 말한 2배 속도와 80% 토큰 절감도 외부 개발팀의 workload에서 재검증될 필요가 있습니다. 숫자보다 더 중요한 검증은 에이전트가 조직 데이터를 쓸 때 사람이 비용과 권한과 행동 기록을 이해할 수 있는가입니다.