Microsoft Build 2026 AI 에이전트: Copilot, Foundry, Agent Framework와 Android 폰 에이전트 기준

Microsoft Build 2026이 AI 에이전트에 남긴 결론

Microsoft Build 2026 AI 에이전트를 지금 읽는 핵심은 행사 전 기대가 아니라 행사 뒤의 제품 구조입니다. Build 2026은 2026년 6월 2일부터 3일까지 열렸고, Microsoft는 에이전트를 단순한 챗봇이나 데모 기능이 아니라 만들고, 근거를 붙이고, 배포하고, 운영하고, 관찰하고, 통제해야 하는 프로덕션 시스템으로 제시했습니다. Microsoft Build 2026 공식 발표는 Microsoft Agent Platform과 Microsoft IQ를 중심으로 에이전트 개발, 컨텍스트, 모델 선택, 보안, 거버넌스, 운영을 함께 다뤘습니다.

Build 2026의 메시지는 “AI가 답한다”에서 “AI가 책임 있는 작업 흐름에 들어간다”로 이동했습니다. 업무 에이전트는 문서를 읽고, 도구를 호출하고, 승인 단계를 기다리고, 다른 에이전트나 시스템과 협력할 수 있습니다. 하지만 이런 흐름은 제품 이름만으로 완성되지 않습니다. 어떤 데이터가 근거로 쓰였는지, 어떤 도구가 호출됐는지, 작업이 어디까지 진행됐는지, 실패했을 때 어떻게 멈추고 복구하는지가 함께 설계되어야 합니다.

이 변화에서 독자가 먼저 잡아야 할 주제는 세 가지입니다. 첫째, Copilot 에이전트는 하나의 소비자 기능 이름이 아니라 Microsoft 365, Copilot Studio, Foundry, 개발자 도구, 조직 데이터와 맞물리는 흐름입니다. 둘째, Build 2026의 여러 발표는 정식 제공, 프로덕션 준비 미리 보기, 공개 미리 보기, 비공개 미리 보기, 향후 제공 상태가 섞여 있으므로 제품별 상태를 분리해야 합니다. 셋째, 에이전트가 실제 일을 하려면 작업의 주체, 도구, 권한, 기록, 실패 복구가 분명해야 합니다.

Android 폰 에이전트를 보는 독자에게도 이 기준은 중요합니다. Microsoft의 행사는 기업과 개발자 에이전트 중심이지만, 신원과 권한, 작업 상태, 관찰 가능성, 사용자 확인이라는 원칙은 개인 휴대폰 작업에도 그대로 적용됩니다. Microsoft Scout와 OpenClaw 같은 기업 에이전트 논의를 더 좁게 보고 싶다면 Microsoft Scout와 OpenClaw: 기업 에이전트와 Android 폰 에이전트의 차이가 별도 제품 맥락을 설명합니다. 이 글은 Build 2026의 플랫폼 구조를 먼저 정리한 뒤, Android 폰 에이전트가 무엇을 배워야 하는지로 이어갑니다.

Microsoft Agent Platform 구성 요소를 구분하기

Microsoft Build 2026 AI 에이전트 논의에서 가장 흔한 혼동은 Copilot, Copilot Studio, Foundry, Agent Framework, Microsoft IQ를 한 덩어리로 보는 것입니다. 실제로는 역할이 다릅니다. Microsoft IQ는 Microsoft 에이전트 제품 전반에서 조직과 사용자의 업무 맥락을 연결하는 컨텍스트 층으로 설명됩니다. 이는 에이전트가 단순한 질의응답을 넘어 문서, 일정, 회의, 조직 지식, 작업 흐름과 연결될 때 필요한 기반입니다.

Copilot Studio는 업무 에이전트를 만들고 조정하는 제작 환경에 가깝습니다. Copilot Studio 에이전트 개요는 조직이 채널, 데이터, 도구, 업무 프로세스에 연결되는 에이전트를 만들 수 있는 제품으로 설명합니다. Build 2026 이후 Copilot Studio 문서에서는 새 에이전트 제작 경험과 오케스트레이션 런타임, 컴퓨터 사용, 에이전트 인벤토리, 비동기 응답, 거버넌스 기능의 상태를 기능별로 따로 표시합니다. 이 구분은 실제 도입에서 중요합니다.

Microsoft Foundry는 프로덕션 AI 앱과 에이전트를 만들고 운영하는 개발자·플랫폼 영역에 가깝습니다. Microsoft Build 2026 공식 라이브 블로그는 Foundry 발표를 호스팅된 실행 환경, 에이전트 프레임워크, 근거 연결, 추적, 평가, 최적화, 게시 같은 항목으로 다뤘고, 각 항목의 정식 제공·미리 보기·향후 제공 상태를 구분했습니다. Foundry를 Copilot Studio와 같은 제품으로 합치면 이 운영 관점이 흐려집니다.

Microsoft Agent Framework는 개발자가 에이전트와 다중 에이전트 흐름을 만드는 SDK와 런타임입니다. Microsoft Agent Framework Build 발표는 1.0이 2026년 4월 2일 정식 제공됐고, .NET과 Python에서 컨텍스트, 도구, 승인, 상태, 오래 걸리는 작업을 다루는 패턴을 제공한다고 설명합니다. 넓은 Microsoft AI 앱 전략과 로컬 폰 에이전트의 차이는 Microsoft AI 슈퍼앱 vs 로컬 AI 에이전트: 휴대폰에는 무엇이 맞을까에서 별도 비교로 볼 수 있습니다.

Windows 365 for Agents, Agent 365, GitHub Copilot 관련 발표도 같은 지도 위에서 읽어야 합니다. 어떤 발표는 개발자가 코드를 만들고 테스트하는 흐름에 가깝고, 어떤 발표는 엔터프라이즈 실행 환경이나 가상화된 업무 세션에 가깝습니다. Build 2026 라이브 블로그는 이런 항목을 각각 다른 제품과 제공 상태로 표시했습니다. 따라서 “Microsoft가 에이전트를 발표했다”라는 한 문장만으로 내 조직이나 내 기기에서 무엇이 바로 가능한지 판단하면 위험합니다.

실무에서는 이 표가 도입 순서가 됩니다. 먼저 어떤 작업을 에이전트에게 맡길지 정하고, 그 작업이 Microsoft 365와 조직 데이터 중심인지, 개발자가 직접 만든 서비스와 도구 중심인지, 사용자 기기에서 실제 조작이 필요한지 나눕니다. 그런 다음 제작 도구, 실행 환경, 신원 관리, 평가 체계, 사용자 확인 지점을 따로 고릅니다. 이 분리가 되어야 Copilot Studio로 만들 작업과 Agent Framework로 코드화할 작업, Foundry에서 운영할 작업을 혼동하지 않습니다.

프로덕션 AI 에이전트의 실제 운영 흐름

Build 2026이 프로덕션 AI 에이전트에 남긴 가장 실용적인 메시지는 에이전트가 한 번의 답변으로 끝나지 않는다는 점입니다. 실제 운영에서는 컨텍스트를 가져오고, 어떤 도구를 쓸지 고르고, 중간 상태를 남기고, 사용자의 확인을 기다리고, 실행 결과를 추적하고, 실패하면 복구해야 합니다. 이 흐름이 없으면 에이전트는 멋진 데모에서 멈추기 쉽습니다.

첫 단계는 근거입니다. 에이전트가 조직 문서, 회의 내용, 코드 저장소, 고객 데이터, 사용자 입력 중 무엇을 참고했는지 알아야 합니다. Microsoft IQ와 Foundry의 근거 연결 흐름은 이 문제를 다룹니다. 근거가 약하면 도구 호출이 빨라도 결과를 믿기 어렵습니다. 반대로 근거가 명확하면 사용자는 에이전트가 왜 특정 파일을 열었고 왜 특정 작업을 제안했는지 추적할 수 있습니다.

두 번째 단계는 도구 선택입니다. 에이전트가 할 수 있는 일은 모델의 말솜씨가 아니라 연결된 도구와 정책으로 결정됩니다. 읽기 도구, 작성 도구, 외부 결과를 만드는 도구, 관리자 승인이 필요한 도구는 같은 위험도를 갖지 않습니다. 프로덕션 환경에서는 도구마다 입력 검증, 권한, 확인, 실패 처리, 로그가 필요합니다. “계약서 내용을 요약해 줘”와 “계약서를 외부 고객에게 보내 줘”는 같은 문서 작업처럼 보여도 운영상 완전히 다른 단계입니다.

세 번째 단계는 상태 관리입니다. 에이전트가 오래 걸리는 작업을 진행하거나 여러 하위 작업을 나눌 때, 현재 실행 중인 단계와 기다리는 단계를 구분해야 합니다. Agent Framework가 말하는 긴 작업과 상태 패턴은 이 지점에서 중요합니다. 사용자가 승인해야 하는 작업이 멈춰 있는지, 데이터 조회가 아직 진행 중인지, 실패 뒤 재시도가 필요한지 상태로 드러나야 운영할 수 있습니다.

Foundry 쪽 발표는 이 점을 개발자 언어로 분명하게 보여 줍니다. Microsoft Foundry 신뢰 스택 발표는 평가, 에이전트 제어, 관찰 가능성, 데이터 보호 같은 항목을 다루며 일부 기능의 공개 미리 보기 상태를 명시했습니다. 추적과 평가는 에이전트가 왜 그런 판단을 했는지, 어떤 도구를 호출했는지, 어디서 실패했는지 운영자가 다시 볼 수 있게 합니다.

네 번째 단계는 평가와 개선입니다. 프로덕션 에이전트는 한 번 배포하고 끝내는 기능이 아닙니다. 성공률, 잘못된 도구 호출, 권한 거부, 사용자 취소, 실패 뒤 복구율, 정책 위반 가능성을 계속 봐야 합니다. 미리 보기 기능을 실험할 때는 이 지표가 더 중요합니다. 정식 제공 기능이라도 테넌트 설정, 커넥터 권한, 사용자의 실제 업무 습관에 따라 결과가 달라질 수 있습니다.

프로덕션 AI 에이전트를 평가할 때는 다음 질문이 필요합니다. 에이전트가 어떤 근거를 사용했는가. 어떤 도구가 실제 변화를 만들었는가. 작업 상태가 남는가. 사용자의 승인 전후가 분리되는가. 실패가 기록되고 재시도 또는 중단 경로가 있는가. 에이전트 신원과 권한, 감사 기록을 더 깊게 다루는 기준은 AI 에이전트 신원과 권한: 도구별 승인 제어와 감사 로그 설계에서 이어서 볼 수 있습니다.

에이전트 신원, 권한, 관찰 가능성이 중요한 이유

AI 에이전트가 업무 데이터와 도구를 쓰기 시작하면 “누가 무엇을 했는가”가 제품의 핵심이 됩니다. Microsoft는 Copilot Studio의 새 에이전트에 Entra Agent ID를 부여하는 방향을 문서화했습니다. Microsoft Entra Agent ID 문서는 새 Copilot Studio 에이전트마다 Entra Agent ID가 만들어지고, 커넥터 권한, 수명 주기, 로깅, 거버넌스, 조건부 액세스와 연결될 수 있다고 설명합니다. 기존 에이전트는 전환 상태가 남아 있으므로 새 에이전트와 같은 상태로 단정하면 안 됩니다.

신원은 시작점일 뿐입니다. 에이전트가 어느 커넥터를 통해 어떤 데이터에 접근하는지, 그 커넥터의 런타임 권한이 무엇인지, 관리자가 어떤 정책을 적용했는지 함께 봐야 합니다. 에이전트가 데이터에 접근할 수 있다는 사실과 외부 결과를 만드는 작업을 실행할 수 있다는 사실은 다른 문제입니다. 이메일 전송, 레코드 수정, 파일 공유처럼 결과가 생기는 작업은 별도 정책과 확인이 필요합니다.

Copilot Studio 최신 변경 문서는 2026년 중 기능별 상태를 나눠 보여 줍니다. 예를 들어 새 에이전트 경험의 향상된 오케스트레이션 런타임은 프로덕션 준비 미리 보기로 설명되고, 컴퓨터 사용은 2026년 5월 정식 제공 항목으로 표시되며, 일부 거버넌스 기능은 미리 보기로 제공됩니다. 이처럼 같은 제품 안에서도 상태가 다르므로 도입 계획은 기능 단위로 세워야 합니다.

컴퓨터 사용 같은 기능은 특히 상태 표시가 중요합니다. 정식 제공이라고 해도 조직 정책, 보안 설정, 연결된 앱과 데이터, 사용자의 역할에 따라 실제 가능 범위가 달라집니다. 미리 보기 거버넌스 기능은 운영팀이 실험하고 기준을 만들 수 있게 해 주지만, 모든 시나리오에서 완성된 통제 체계로 취급할 수는 없습니다. Build 2026 이후 에이전트 도입은 제품명보다 테넌트 설정과 제공 상태, 커넥터 정책을 먼저 확인해야 합니다.

관찰 가능성도 신뢰의 일부입니다. 에이전트가 어떤 요청을 받았고 어떤 도구를 호출했고 어디서 멈췄는지 볼 수 있어야 운영자가 정책을 고치고 사용자가 결과를 신뢰할 수 있습니다. Android 폰 에이전트에서도 같은 원칙이 적용됩니다. 개인 기기에서는 조직 관리자 대신 사용자가 최종 확인자가 되는 경우가 많기 때문에, 권한 안내와 보이는 결과가 더 직접적인 신뢰 요소가 됩니다.

좋은 거버넌스는 에이전트를 느리게 만드는 장치가 아니라, 맡길 수 있는 작업을 늘리는 기반입니다. 신원이 분명하고 권한이 제한되어 있으며 로그가 남고 실패가 설명되면, 조직과 사용자는 더 중요한 작업을 단계적으로 맡길 수 있습니다. 반대로 신원과 권한이 흐리면 작은 자동화도 위험해 보입니다. Build 2026의 에이전트 플랫폼 논의가 보안과 운영을 함께 다룬 이유가 여기에 있습니다.

Android 폰 사용자에게 Build 2026이 주는 의미

Microsoft Build 2026은 Android 휴대폰의 모든 앱을 한꺼번에 조작하는 소비자 기능 발표가 아닙니다. 대신 Android 폰 사용자가 읽어야 할 변화는 더 구조적입니다. AI 에이전트가 실제 일을 하려면 누가 실행 주체인지, 어떤 도구를 쓰는지, 어떤 권한이 필요한지, 사용자가 어느 지점에서 확인하는지, 실패 뒤 어떤 복구 경로가 있는지 명확해야 합니다. 이 원칙은 기업용 Copilot 에이전트에도, 개인 Android 폰 에이전트에도 적용됩니다.

휴대폰에서는 작업 환경이 더 자주 바뀝니다. 앱이 로그인되어 있는지, 알림이 떠 있는지, 화면이 잠겼는지, 위치 권한이 허용됐는지, 기본 앱이 무엇인지에 따라 같은 요청도 다르게 처리됩니다. 기업 에이전트가 조직 데이터와 관리 정책을 중심으로 움직인다면, Android 폰 에이전트는 사용자의 실제 기기 상태와 앱 화면, 개인 권한 선택을 함께 다룹니다.

Build 2026의 원칙을 폰에 적용하면 질문이 선명해집니다. 이 에이전트는 사용자의 요청을 어떤 지원 작업으로 나누는가. 어느 작업이 읽기이고 어느 작업이 실제 변경인가. 결과가 보이는가. 거부된 권한이나 실패한 앱 상태를 설명하는가. 더 넓은 Android 실행 기준은 AI 에이전트 폰 제어란 무엇인가: 안드로이드 폰 에이전트가 실제로 해야 할 일에서 자세히 다룹니다.

Android 폰 에이전트의 평가 과정은 작은 실제 흐름으로 보는 편이 가장 정확합니다. 예를 들어 “다음 회의 장소까지 이동 시간을 확인하고, 늦을 것 같으면 상대에게 보낼 초안을 만들어 줘”라는 요청은 지도, 캘린더, 메시지 또는 메일, 사용자 확인이 섞입니다. 좋은 에이전트는 먼저 일정을 확인하고, 위치나 지도 접근이 필요한 이유를 설명하고, 이동 시간을 계산한 뒤, 초안을 만들고, 실제 전송 전에는 대상과 내용을 보여 줍니다. 이 과정에서 읽기, 판단, 작성, 전송은 각각 다른 상태입니다.

Microsoft의 Copilot OS 시제품이나 Windows 중심 에이전트 구조가 궁금한 독자는 Microsoft Aion이란? Copilot OS 시제품과 2026 에이전트 구조를 함께 보면 좋습니다. 여기서는 Build 2026의 생산 환경 원칙이 Android 폰 에이전트 평가에 어떤 기준을 주는지에 집중합니다.

현재 FoneClaw가 Android에서 적용하는 원칙

FoneClaw는 Android 폰에서 지원되는 작업을 관리되는 도구, 보이는 결과, 필요한 권한과 사용자 확인 안에서 진행하는 폰 에이전트 실행 환경입니다. 구성된 모델은 요청을 이해하고 계획하며, FoneClaw는 지원되는 Android 작업을 실제 기기 흐름으로 옮깁니다. Build 2026이 말한 프로덕션 에이전트 원칙을 휴대폰 쪽으로 가져오면, 가장 중요한 것은 작업 상태와 통제 지점이 사용자의 손 안에서 분명한가입니다.

현재 공개된 FoneClaw는 여러 대화 관리, 엄격한 작업 대기열, 독립적으로 보이는 실행 중·대기 중 상태, 세션에 묶인 승인, 작업 격리, 권한 복구, 음성 입력 개선, 실행 복구를 강화했습니다. 현재 버전은 FoneClaw 다운로드 페이지에서 확인할 수 있습니다. 이 변화는 Android에서 진행되는 작업이 어느 대화에 속하는지, 어떤 작업이 기다리는지, 어떤 확인이 필요한지 더 쉽게 이해하도록 돕습니다.

예를 들어 사용자가 “회의 전에 이동 시간을 확인하고, 늦을 것 같으면 답장 초안을 만들어 줘”라고 요청했다고 해 보겠습니다. FoneClaw는 일정과 지도 관련 지원 작업을 통해 시간을 확인하고, 필요한 경우 메일 또는 메시지 초안을 준비합니다. 실제 전송처럼 외부 결과가 생기는 단계에서는 수신자와 내용이 보이는 확인 흐름을 거칩니다. 위치 권한이 없거나 앱 상태가 맞지 않으면 권한 복구 또는 실행 복구로 다음 행동을 안내합니다.

이 흐름을 Build 2026의 운영 기준으로 다시 보면 네 단계가 보입니다. 첫째, 요청 해석과 근거 수집입니다. 일정, 위치, 현재 앱 상태처럼 필요한 정보가 무엇인지 정합니다. 둘째, 지원되는 도구 선택입니다. 캘린더 확인, 지도 열기, 초안 작성처럼 각 단계가 어떤 Android 작업으로 이어지는지 나눕니다. 셋째, 사용자 확인입니다. 읽기와 초안은 낮은 위험 작업일 수 있지만, 실제 전송이나 설정 변경은 결과가 생기므로 사용자가 내용을 봐야 합니다. 넷째, 결과와 복구입니다. 완료된 작업은 확인 가능해야 하고, 실패한 작업은 다음 조치가 보여야 합니다.

현재 FoneClaw가 다루는 Android 작업은 지원되는 앱 실행과 보이는 화면 확인, 선택된 화면 동작, 통신·캘린더·메일·지도·할 일·메모·기기 상태·설정 작업으로 묶어 볼 수 있습니다. 사용자 관점의 기능 범위는 FoneClaw 기능 소개에서 확인할 수 있습니다. 중요한 것은 기능 수를 세는 일이 아니라, 요청이 지원되는 작업으로 나뉘고 권한과 확인을 거쳐 결과로 남는 흐름입니다.

FoneClaw 공개 GitHub 저장소는 자연어 요청을 관리되는 휴대폰 작업으로 연결하는 구조, 도구 정책, 승인, 보이는 결과, Skills, Workflows, 플러그인 경계를 설명합니다. 우리는 지원되는 Android 워크플로에서 사용자가 이해할 수 있는 작업 상태, 필요한 권한 안내, 영향도에 맞는 승인, 확인 가능한 결과, 중단 뒤 복구를 제품 경험의 중심에 둡니다. 이 기준은 기업 플랫폼에서 말하는 운영 가능성과 개인 휴대폰에서 느끼는 신뢰를 연결합니다.

Build 2026 이후 에이전트 준비도를 보는 체크리스트

Microsoft Build 2026 이후 AI 에이전트를 평가할 때는 브랜드 이름보다 작업의 위치와 운영 조건을 먼저 봐야 합니다. 기업 업무 데이터와 Microsoft 365, Power Platform, 관리 정책이 중심이면 Copilot Studio, Foundry, Agent Framework, Entra Agent ID 같은 Microsoft 계층을 기능별 상태와 함께 확인합니다. 개인 Android 휴대폰에서 앱을 열고, 화면을 보고, 메일이나 일정 같은 지원 작업을 진행해야 한다면 폰 에이전트의 작업 상태와 사용자 확인 흐름을 살펴봅니다.

• 제품 층: 제작 도구인지, 실행 환경인지, 운영 플랫폼인지, 신원·권한 관리인지 구분합니다.
• 제공 상태: 정식 제공, 프로덕션 준비 미리 보기, 공개 미리 보기, 비공개 미리 보기, 향후 제공을 기능별로 확인합니다.
• 작업 주체: 에이전트가 어떤 신원으로 어떤 도구를 호출하는지 봅니다.
• 권한과 확인: 읽기 작업과 외부 결과가 생기는 작업이 다르게 취급되는지 확인합니다.
• 관찰 가능성: 요청, 도구 호출, 중간 상태, 실패 이유, 완료 결과를 나중에 볼 수 있는지 확인합니다.
• 복구: 권한 거부, 빈 결과, 앱 상태 변화, 중단된 작업 뒤에 사용자가 이어갈 수 있는가를 봅니다.

Microsoft 제품을 검토하는 팀은 Build 발표만으로 도입을 결정하지 말고 각 공식 문서의 현재 상태를 확인해야 합니다. Copilot Studio의 새 에이전트 경험, 컴퓨터 사용, 에이전트 인벤토리, 비동기 응답, 거버넌스 기능은 같은 제품 안에서도 상태가 다릅니다. Foundry의 관찰과 평가, 데이터 보호 기능도 정식 제공과 미리 보기 범위를 나눠야 합니다. Agent Framework 1.0은 정식 제공 상태지만, 그것만으로 호스팅·운영·보안 기능 전체가 자동으로 준비되는 것은 아닙니다.

테넌트와 순차 제공도 별도 확인 대상입니다. Microsoft 문서에서 기능이 정식 제공이라고 표시되어도 조직의 라이선스, 지역, 관리자 설정, 커넥터 정책, 데이터 거버넌스에 따라 사용 가능한 범위가 달라질 수 있습니다. 미리 보기 기능은 더 신중하게 봐야 합니다. 실험에는 가치가 있지만, 업무 핵심 프로세스에 넣기 전에는 로그, 실패 처리, 권한 검토, 사용자 교육, 중단 시 수동 처리 경로가 필요합니다.

Android 폰 에이전트를 평가하는 사용자는 더 작은 테스트가 좋습니다. 낮은 위험의 작업을 하나 고르고, 요청이 어떤 단계로 나뉘는지, 실행 중과 대기 중 상태가 보이는지, 권한 요청이 이유와 함께 나타나는지, 결과가 실제 앱에서 확인되는지, 실패 뒤 다음 행동이 분명한지 봅니다. FoneClaw는 이 경로에서 지원되는 Android 작업을 현재 기기에서 시험할 수 있는 실행 환경을 제공합니다.

실제 테스트는 이렇게 할 수 있습니다. 먼저 캘린더 확인이나 메모 작성처럼 되돌리기 쉬운 작업으로 시작합니다. 다음으로 메일 초안이나 지도 경로처럼 여러 정보를 모아야 하는 작업을 시도합니다. 마지막으로 전송, 설정 변경, 삭제처럼 결과가 생기는 작업은 대상과 내용을 눈으로 확인한 뒤 진행합니다. 이 순서를 거치면 사용자는 모델 답변의 품질뿐 아니라 에이전트가 휴대폰에서 상태와 권한, 결과를 어떻게 다루는지 볼 수 있습니다.

Microsoft의 기업 에이전트 흐름과 개인 기기 실행 흐름은 서로 다른 문제를 다루지만, 좋은 에이전트의 기준은 점점 비슷해지고 있습니다. 신원이 있어야 하고, 권한이 보여야 하며, 도구 호출과 결과가 추적되어야 하고, 사용자가 영향을 받는 순간에는 확인할 수 있어야 합니다. Build 2026은 이 기준을 기업 플랫폼 언어로 정리했고, FoneClaw는 같은 기준을 Android 폰 작업의 보이는 실행과 복구 흐름으로 가져갑니다.