아무말이나해도 다 들어주는 AI쨩

이 글의 요지

이 글에서 잡고 싶은 건 하나다. AI가 "말을 들어준다"는 말이 답변에서 실행으로 넘어가고 있다는 것.

• 핵심 관점: 예전 AI는 내 말을 듣고 답했다. 이제 AI는 내 말을 듣고 실제 작업을 시작한다.

• Google의 방향: 사용자의 말을 Search, Web, Commerce, Code, Science로 보내 바깥세상에서 이뤄준다.

• Apple의 방향: 사용자의 말을 Siri, App Intents, Foundation Models, Core AI, PCC 같은 OS 경계 안에서 들어준다.

• 가장 큰 위험: AI가 말을 못 알아듣는 것이 아니라, 가짜 요청까지 너무 잘 들어줄 수 있다는 점이다.

• 개발자 질문: AI에게 무엇을 어디까지 들어주게 할 것인가.

처음에는 이 글의 제목을 조금 더 점잖게 잡으려고 했다.

"AI는 이제 버튼을 누른다."

나쁘지 않았다. Google I/O 2026과 WWDC26을 나란히 보면 실제로 그런 장면이 계속 보인다. AI가 검색하고, 웹사이트를 조작하고, 코드를 고치고, 앱 기능을 호출하고, 결제와 예약과 배포 같은 상태 변화를 수행한다. 답변하는 AI에서 행동하는 AI로 넘어가고 있다는 말도 맞다.

그런데 계속 걸리는 지점이 있었다. "버튼"이라는 말은 개발자에게는 정확하지만, 이 변화의 뉘앙스를 다 담지는 못한다. 내가 더 오래 붙잡고 싶었던 건 한국어의 "들어준다"라는 말이었다.

예전에는 AI가 내 말을 들어준다고 하면, 내 말을 알아듣고 답변해준다는 뜻에 가까웠다. 질문을 이해하고, 요약하고, 번역하고, 추천하고, 대화해주는 쪽이었다.

하지만 2026년의 Google I/O와 WWDC26을 이어서 보고 나면, 이 "들어준다"의 의미가 바뀌고 있다는 느낌이 강하다.

이제 AI가 말을 들어준다는 말은 단순히 듣고 답한다는 뜻이 아니다. 부탁을 실제로 이뤄준다는 뜻에 가까워지고 있다. 소원을 들어주듯 작업을 시작하고, 외부 서비스를 호출하고, 앱 기능을 실행하고, 상태를 바꾸는 쪽으로 간다.

그래서 이 글의 진짜 제목은 이렇게 잡는 게 더 정확하다.

아무말이나해도 다 들어주는 AI쨩.

물론 이 표현은 일부러 가볍다. 하지만 주제는 가볍지 않다. 중요한 건 "들어준다"라는 단어가 두 층으로 갈라졌다는 점이다.

듣고 답하는 AI.

듣고 실행하는 AI.

2026년의 플랫폼 경쟁은 이 둘 사이에서 벌어진다.

Google은 사용자의 말을 바깥세상에서 이뤄주는 실행 체인을 만들고 있다. Apple은 사용자의 말을 OS 안의 허락된 행동으로 위임하는 경계를 만들고 있다. 둘 다 "들어주는 AI"를 말하지만, 무엇을 어디서 어떻게 들어주는지는 다르다.

나는 이 차이를 조금 더 정확히 붙잡고 싶었다.

"들어준다"는 말이 바뀌었다

버튼보다 중요한 건 "들어준다"의 의미 변화다. 답변하던 AI가 실행하는 AI로 넘어가고 있다.

"AI가 내 말을 들어준다"는 말은 오랫동안 꽤 안전한 표현이었다.

내가 질문한다.

AI가 듣는다.

AI가 답한다.

답이 틀리면 다시 묻거나 무시하면 된다. 실패 비용은 대체로 낮았다. 틀린 요약, 어색한 번역, 부족한 추천은 불편하지만 시스템 상태를 직접 바꾸지는 않는다.

하지만 이제 "들어준다"는 말이 다른 쪽으로 이동한다.

내가 말한다.

AI가 듣는다.

AI가 실행한다.

검색한다. 예약한다. 수정한다. 결제한다. 배포한다. 삭제한다. 앱 기능을 호출한다. 장기 작업을 이어간다. 사용자가 앱을 열기 전에 작업 상태를 만든다.

이 순간부터 "말을 잘 듣는다"는 장점이 동시에 위험이 된다.

말을 잘 듣는 AI가 편리한 이유는, 내가 원하는 일을 빠르게 처리해주기 때문이다. 그러나 말 잘 듣는 AI가 위험한 이유도 같다. 그 AI가 정말 내 말을 듣는지, 아니면 외부 콘텐츠에 숨어 있던 가짜 지시를 듣는지, 혹은 시스템이 허락하지 않은 행동까지 이뤄주려 하는지 구분해야 하기 때문이다.

그래서 질문이 바뀐다.

AI가 얼마나 잘 알아듣는가?

에서

AI가 들어준 다음 어디까지 실제로 해도 되는가?

로.

나는 이 문장이 Google I/O 2026과 WWDC26을 읽는 핵심 프레임이라고 본다.

시간차가 만든 이상한 비교 감각

Google I/O를 먼저 보고 WWDC를 보면, 같은 AI 시즌 안에서도 두 회사가 서로 다른 문으로 들어간다는 감각이 더 선명해진다.

Google I/O 2026은 2026년 5월 19일에 열렸고, WWDC26은 2026년 6월 8일에 열렸다. 약 3주 차이다.

이 시간차는 단순한 일정 차이가 아니었다. 관찰자 입장에서는 Google의 발표를 먼저 보고, 그 여운이 남아 있는 상태에서 Apple의 발표를 보게 된다. 그래서 두 회사가 서로 비슷한 미래를 말하면서도 완전히 다른 방식으로 설명한다는 느낌이 더 선명해진다.

Google I/O를 먼저 보면 "AI가 밖으로 나가서 일을 끝내는구나"라는 인상이 강하다. Search Agents, Gemini Spark, Antigravity, WebMCP, Agent Executor, Universal Cart는 모두 사용자의 말을 작업으로 바꾸고, 외부 서비스를 호출하고, 상태를 유지하고, 필요하면 승인까지 받아내는 방향을 가리킨다.

그 뒤 WWDC26을 보면 Apple도 비슷한 말을 한다. Siri AI는 개인 맥락을 이해하고, 화면을 보고, 앱 액션을 호출한다. App Intents는 앱이 Siri와 Apple Intelligence에 기능을 노출하는 방식이 된다. Foundation Models와 Core AI는 앱 안에서 AI 기능을 만들 수 있는 개발자 경로를 제공한다. Xcode 27은 Agentic Coding을 전면에 놓는다.

하지만 Apple의 발표는 Google처럼 들리지 않는다.

Google은 사용자의 말을 바깥으로 보낸다. 검색, 웹, 장바구니, 클라우드, 코드, 과학 연구까지 외부 세계에서 그 말을 이뤄주려 한다.

Apple은 사용자의 말을 안으로 들인다. 개인 맥락, 기기, 앱, OS 권한, 프라이버시, 기업 관리 정책 안에서 그 말을 처리하게 만든다.

그래서 두 회사가 비슷한 단어를 쓰는데도 다르게 들린다.

한쪽은 "소원을 이뤄주러 밖으로 나가는 AI"에 가깝고, 다른 한쪽은 "허락된 방 안에서 부탁을 처리하는 AI"에 가깝다.

자막 데이터는 증거가 아니라 말버릇이다

단어 빈도 자체보다 원어 키워드의 조합이 중요하다. Google은 외부 실행 표면을, Apple은 OS 안 위임 경계를 반복한다.

두 행사의 자막을 단어 단위로 세어보면 이 차이는 어느 정도 숫자로도 보인다. 물론 단어 빈도가 전략을 증명하지는 않는다. 발표에서 많이 등장한 단어는 브랜드명, 제품명, 발표 구성에 영향을 받는다. 그래도 반복된 단어는 각 회사가 어느 표면을 강조했는지 보여주는 신호가 된다.

특히 이 부분은 한국어로 번역하면 차이가 잘 안 보인다. "검색", "앱", "보안"처럼 번역하면 둘 다 비슷한 말을 하는 것처럼 보인다. 그래서 원어 키워드 그대로 보는 편이 낫다. 말버릇이 다르기 때문이다.

Google 쪽에서 반복적으로 눈에 걸리는 말은 이런 쪽이다.

Gemini
Agent
Search Agents
Antigravity
WebMCP
Agent Executor
Universal Cart
Cloud
Science

이 조합은 AI가 바깥으로 나가는 그림을 만든다. 검색에서 시작해 웹을 호출하고, 코드를 고치고, 장바구니와 결제까지 건드리고, 장기 실행 Runtime과 연구 자동화로 이어진다.

Apple 쪽에서 반복적으로 눈에 걸리는 말은 다르다.

Siri AI
Apple Intelligence
App
Personal Context
App Intents
Spotlight
Foundation Models
Core AI
Private Cloud Compute
MDM

이 조합은 AI가 안쪽으로 들어오는 그림을 만든다. 개인 맥락을 읽고, OS가 앱 Action을 위임하고, 모델 실행 위치를 통제하고, 기업 정책으로 허용 범위를 관리한다.

표로 압축하면 이렇게 보인다.

이 표를 이렇게 읽으면 안 된다.

Google은 AI고 Apple은 Privacy다.

그건 너무 단순하다. Google도 Safety를 말하고, Apple도 Agentic Coding을 말한다. Google도 Personal Intelligence를 말하고, Apple도 Foundation Models를 말한다.

중요한 것은 단어 자체가 아니라 단어가 붙는 장소다.

Google의 AI 옆에는 Search, Chrome, Cloud, Antigravity, Commerce, Science가 붙는다. Apple의 AI 옆에는 Siri, App Intents, Spotlight, Photos, Safari, Foundation Models, Private Cloud Compute, Child Safety, MDM이 붙는다.

즉 Google은 "들어준 말"을 외부 실행 표면에 붙이고, Apple은 "들어준 말"을 내부 위임 경계에 붙인다.

답변에서 실행으로 넘어가는 순간

답변은 틀려도 다시 물으면 되지만, 실행은 되돌려야 한다. 이 차이가 권한, 승인, 기록, 복구를 제품 요구사항으로 만든다.

AI가 답변하는 동안에는 실패 비용이 비교적 낮다. 답변이 틀리면 사용자가 다시 묻거나 무시할 수 있다.

하지만 AI가 실제로 들어주기 시작하면 문제가 달라진다.

조회는 비교적 안전하다.

수정은 더 조심해야 한다.

예약은 시간과 외부 시스템이 얽힌다.

결제는 돈이 움직인다.

배포는 서비스 상태를 바꾼다.

삭제는 되돌리기 어려울 수 있다.

이 지점에서 예전 글의 "버튼" 은유가 다시 살아난다.

버튼은 UI의 작은 사각형이 아니다. 버튼은 행동의 다른 이름이다. 조회, 수정, 예약, 결제, 배포, 삭제처럼 시스템의 상태를 바꾸는 행위다.

그러니까 "AI에게 버튼을 맡긴다"는 말은, "AI에게 사용자의 말을 실제로 이뤄줄 권한을 준다"는 뜻이다.

여기서부터는 단순 UX 문제가 아니다. 제품 설계, 보안, 백엔드, 데이터, 법무, 운영, 고객지원이 함께 보는 문제가 된다. AI가 누른 버튼은 기록되어야 하고, 승인되어야 하고, 취소 가능해야 하고, 실패했을 때 누가 복구할지 정해져 있어야 한다.

Google I/O와 WWDC26을 이 관점에서 다시 보면 발표의 구조가 다르게 보인다. 모델 발표는 출발점일 뿐이고, 진짜 발표는 "들어준 말을 누가 어디에서 실행할 것인가"에 관한 것이다.

Google의 방향: 말을 바깥에서 이뤄주는 실행 체인

Google의 큰 흐름은 사용자의 말을 Search, Web, Agent Runtime으로 보내 실제 작업 상태로 바꾸는 것이다.

Google I/O에서 눈에 띄는 것은 기능의 수가 아니라 기능들이 같은 방향으로 이어진다는 점이다. Search Agents, WebMCP, Agent Executor는 따로 보면 각각 검색, 웹, 클라우드 기술처럼 보인다. 하지만 함께 보면 하나의 실행 체인이 된다.

사용자가 목표를 말한다.

Search가 그 목표를 작업 표면으로 바꾼다.

Agent가 외부 서비스와 웹 도구를 호출한다.

장기 실행 작업은 Agent Executor 같은 Runtime 위에서 시작, 대기, 승인, 재개, 분기된다.

이 구조에서 Google의 AI는 사용자의 말을 바깥 세계로 밀어낸다. 검색창은 더 이상 답을 보여주는 표면만이 아니다. 작업이 시작되는 표면이 된다.

Google의 AI Search 발표를 보면 Search는 링크 목록에서 벗어나려고 한다. Search Agents는 정보를 계속 감시하고, 필요할 때 업데이트를 제공하고, 사용자가 원하는 행동으로 이어지게 한다. Generative UI는 검색 결과 안에서 질문에 맞춘 시각화, 인터랙티브 위젯, 임시 작업 화면을 만들 수 있다.

이 변화가 꽤 무서운 이유는 제품의 시작점 자체를 흔들 수 있기 때문이다.

사용자가 우리 앱에 들어오기 전에 이미 Google Search 안에서 작업을 시작했다면, 우리 제품의 첫 화면은 무엇인가?

전통적인 SaaS의 첫 화면은 랜딩 페이지, 가입, 로그인, 온보딩이었다. 하지만 Search가 Mini App처럼 행동하기 시작하면 사용자는 앱에 들어오기 전에 이미 견적 비교, 예약 후보, 체크리스트, 일정 조정, 장바구니 상태를 갖고 있을 수 있다.

제품의 시작점이 앱 안이 아니라 앱 밖의 Task Surface가 되는 것이다.

이 관점에서 Search는 Acquisition Channel이 아니라 Pre-App Workspace가 된다. 조금 더 이 글의 언어로 말하면, Search는 사용자의 소원을 접수하고 작업 상태로 바꾸는 창구가 된다.

WebMCP와 Agentability: 웹은 AI가 부탁을 이뤄줄 수 있는 표면이 된다

웹은 이제 사람이 보는 화면을 넘어 AI Agent가 안전하게 호출할 수 있는 Tool Surface가 되어야 한다.

Search 안에서 작업이 시작되면 다음 문제는 웹사이트다. Agent가 외부 웹사이트를 다룰 수 있으려면 웹은 자신의 기능과 부작용을 명확하게 설명해야 한다.

Google Chrome 쪽의 WebMCP는 이 지점을 잘 보여준다. WebMCP는 웹사이트가 Browser-Based Agent에게 자기 기능을 구조화된 도구처럼 노출하도록 하는 방향이다. 단순히 버튼을 눈치껏 클릭하는 것이 아니라, Tool Name, Arguments, Side Effects 같은 정보를 통해 Agent가 기능을 이해하고 호출하도록 만드는 것이다.

이것을 발표에서는 Agentability라고 불렀다. 공식 용어라기보다 해석을 위한 렌즈다.

Accessibility는 사람이 웹을 더 잘 접근할 수 있게 만드는 문법이었다. Screen Reader, Keyboard Navigation, Semantic HTML은 사람이 보지 못하거나 손으로 누르지 못해도 웹을 사용할 수 있게 만든다.

Agentability는 AI 실행자가 웹을 오해하지 않고 사용할 수 있게 만드는 문법이다. Agent가 이 버튼이 단순 조회인지, 주문 확정인지, 결제인지, 삭제인지 구분할 수 있어야 한다. Action의 입력값과 부작용을 알아야 한다. 어느 지점에서 사용자 확인이 필요한지도 알아야 한다.

이건 프론트엔드만의 문제가 아니다. Agent에게 열리는 기능은 새로운 API 표면이고, 새로운 공격 표면이며, 새로운 감사 표면이다.

앞으로 좋은 웹은 빠른 웹, 검색 엔진이 잘 읽는 웹, 접근성 좋은 웹에 더해 AI가 실제로 부탁을 이뤄줄 수 있는 웹이 될 가능성이 있다.

Agent Executor: 들어준 일을 끝까지 처리하는 Runtime

Agent 작업은 Request-Response가 아니라 대기, 승인, 분기, 재개, Rollback을 포함하는 장기 실행 Workflow다.

웹이 도구 표면이 되면 남는 문제는 실행이다. Agent 작업은 일반적인 API 요청과 다르다. 사용자가 요청하면 바로 응답하고 끝나는 구조가 아니다. Agent는 도구를 호출하고, 외부 입력을 기다리고, 사용자 승인을 받고, 실패하면 분기하고, 중간 상태를 저장하고, 다시 이어가야 한다.

Google Cloud의 Agent Executor는 이 문제를 정면으로 다룬다. Event Log, Snapshot, Sandbox, Policy, Session, Trajectory Branching 같은 단어가 등장하는 이유는 Agent가 단순 함수 호출이 아니라 장기 실행 작업 단위이기 때문이다.

API 서버는 Request를 받고 Response를 준다.

Cron Job은 정해진 시간에 시작해서 끝난다.

Agent Workflow는 Start, Tool Call, Wait, Confirm, Branch, Resume을 오간다.

여기서부터는 개발자에게 꽤 익숙하면서도 불편한 문제가 된다. AI 제품을 만든다는 말은 모델 API를 호출한다는 뜻으로 끝나지 않는다. Agent가 작업 중간에 멈추고, 다시 시작하고, 사용자에게 승인받고, 실패했을 때 어떤 지점으로 돌아갈지 정하는 Runtime 문제가 된다.

결제, 배포, 삭제, 대량 수정 같은 고위험 행동에서는 Retry보다 Cancel, Rollback, Compensation이 더 중요하다. Agent가 잘못된 행동을 이뤄줬을 때 "다시 시도"가 아니라 "어디까지 되돌릴 수 있는가"가 제품의 신뢰를 결정한다.

그래서 Agent Executor가 말하는 것은 단지 Google Cloud의 새 기능이 아니다. 그것은 AI 시대의 백엔드가 Request-Response 중심에서 Task-Session 중심으로 이동한다는 신호다.

Antigravity와 Gemini 3.5: 코딩 보조에서 Agent 작업장으로

AI Coding의 변화는 자동완성보다 크다. IDE는 Agent가 코드를 바꾸고 검증하는 작업장으로 변하고 있다.

Google I/O에서 개발자에게 가장 직접적인 변화는 Antigravity였다. Antigravity는 단순한 AI 코딩 보조 도구가 아니라 Agent-First Development Platform으로 제시됐다. Gemini 3.5 Flash는 Agentic Coding, Long-Horizon Tasks, Real-World Workflows를 위해 강조됐다.

Google의 키노트 전사에서 Antigravity는 꽤 상징적인 데모를 보여준다. Agent들이 Subagent로 나뉘어 12시간 동안 운영체제의 핵심을 만들고, 수많은 Model Request와 Token을 처리하며, 테스트하고 수정하는 흐름이다. 이 장면은 "AI가 코드를 잘 쓴다"는 이야기보다 더 큰 의미가 있다.

IDE가 코드 편집기가 아니라 Agent 작업장이 되고 있다.

기존 IDE는 파일, 터미널, 디버거, 빌드 로그 중심이었다. AI-Assisted IDE는 채팅과 자동완성을 추가했다. 하지만 Agent-First IDE는 Conversation, Artifact, Task, Subagent, Test Result, Rollback 같은 단위가 중심이 된다.

개발자는 모든 줄을 직접 쓰는 사람이 아니라, Agent가 무엇을 했는지 검토하고, 어떤 권한을 줄지 결정하고, 어떤 실패를 되돌릴지 판단하는 사람에 가까워진다.

여기서도 "들어준다"의 의미 변화가 나온다. 예전 코딩 AI는 "이 코드 어떻게 고쳐?"라는 말을 듣고 답했다. 이제는 "이 버그 고쳐줘"라는 말을 듣고 실제로 코드를 바꾸고 테스트를 돌리는 방향으로 간다.

듣고 설명하는 AI에서, 듣고 커밋 직전까지 가는 AI로 이동하는 것이다.

Universal Cart와 Agent Commerce: 구매 요청은 정말 이뤄져도 되는가

구매는 "들어준다"의 가장 현실적인 위험이다. 결제까지 들어주는 AI에는 Guardrail, 감사로그, 책임 경계가 필요하다.

Google의 발표에서 덜 뻔하지만 중요한 축은 Commerce다. Universal Cart, UCP, AP2는 단순 쇼핑 기능이 아니다. AI가 사용자를 대신해 구매 조건을 감시하고, 가격을 비교하고, 장바구니를 관리하고, 결제까지 이어질 수 있는 기반이다.

Google 키노트의 쇼핑 파트는 Agent Commerce를 세 가지 Building Block으로 설명한다. UCP는 Agent Commerce를 위한 공통 언어, AP2는 Agent Payments의 Guardrail과 Accountability, Universal Cart는 여러 서비스와 Merchant에 걸친 지능형 장바구니다.

여기서 중요한 질문은 추천 품질이 아니다.

AI가 정말 구매 요청을 들어줘도 되는가.

사용자가 브랜드, 가격, 조건, 수량, 결제수단을 어떻게 제한할 수 있는가. Agent가 구매한 행위는 어떻게 기록되는가. 분쟁이 생기면 Merchant와 Payment Processor와 사용자가 같은 기록을 볼 수 있는가. 자동 구매는 어디까지 허용되고, 어느 순간에는 반드시 확인이 필요한가.

장바구니는 더 이상 장바구니가 아니다. 그것은 권한이 부여된 실행자다.

이 점에서 Commerce는 "다 들어주는 AI"의 신뢰 문제를 가장 현실적으로 보여준다. 문서 작성 Agent가 틀린 문장을 쓰는 것과 결제 Agent가 잘못 구매하는 것은 실패 비용이 다르다. 결제는 돈, 신원, 법적 책임, 고객지원, 환불, Fraud Detection이 모두 연결된다.

소원을 들어주는 AI에게 가장 무거운 소원 중 하나는 "사줘"다.

Google의 더 큰 끝: 과학 자동화

Google의 Agent 전략은 코딩과 쇼핑을 넘어 가설, 실험, 평가를 반복하는 연구 자동화까지 향한다.

Google I/O를 소비자 제품과 개발도구 중심으로만 보면 중요한 축 하나를 놓친다. Google Research 쪽에서는 Gemini For Science, ERA, Co-Scientist, WeatherNext, Health AI 같은 흐름이 있었다.

Google Research At I/O 2026 자료를 보면 Google의 Agent 전략은 코딩과 쇼핑에서 끝나지 않는다. 연구 문제를 정의하고, 가설을 만들고, 코드를 작성하고, 실험 결과를 평가하고, 다음 가설로 분기하는 연구 프로세스 자체가 Agentic Workflow가 된다.

개발자들은 AI가 코드를 짜는 데 먼저 놀란다. 하지만 Google이 더 멀리 보는 것은 과학 연구의 자동화에 가깝다.

Agentic Coding은 코드를 빠르게 쓰는 일이다.

Agentic Science는 가설과 실험과 평가의 루프를 빠르게 돌리는 일이다.

이 차이는 크다. 전자는 개발 생산성의 문제이고, 후자는 지식 생산의 속도 문제다. Google이 AI를 "세상의 복잡한 문제를 푸는 도구"로 말하는 이유가 여기에 있다.

여기서도 같은 말이 반복된다. Google은 사용자의 말을 답변으로 끝내지 않고, 작업 루프와 실험 루프로 밀어 넣는다. "이 문제를 풀어줘"라는 말이 정말로 연구 프로세스의 실행으로 이어지는 것이다.

Apple의 방향: 들어준 말을 OS 안에서 위임한다

Apple은 AI를 밖으로 뛰게 하기보다 Siri와 OS 경계 안에서 개인 맥락을 해석하고 앱 Action을 위임한다.

Google이 사용자의 말을 외부 실행으로 밀어낸다면, Apple은 사용자의 말을 OS 안으로 들여 위임한다.

WWDC26의 중심은 Siri AI였다. 그러나 Siri AI를 음성비서의 개선판으로 보면 부족하다. Siri AI는 Personal Context Understanding, On-Screen Awareness, Broad World Knowledge, App Actions, Visual Intelligence, Writing Tools를 묶은 System Interface에 가깝다.

Apple의 키노트 전사에서 Craig는 Apple Intelligence의 새 아키텍처를 설명하며 Personal Context Understanding, Spotlight Semantic Index, Broad World Knowledge, App Actions, On-Screen Awareness를 하나의 흐름으로 놓는다. Siri AI는 그 위에서 사용자의 사진, 메시지, 메일, 화면, 앱, 웹 정보를 조합해 행동을 돕는다.

하지만 이 행동은 Google식 Outside Execution과 다르다. Apple의 AI는 OS 표면에서 맥락을 모으고, System Orchestrator가 요청을 해석하며, 앱이 선언한 App Intents와 App Actions를 통해 제한된 행동을 수행한다.

즉 Apple의 AI는 자유롭게 외부 세계로 뛰어나가기보다, OS가 허락한 경로로 앱 기능을 위임받는다.

Apple에게 중요한 것은 AI가 무엇을 할 수 있는가만이 아니다. AI가 어느 경계 안에서 들어줘야 하는가다.

App Intents와 Spotlight: 앱은 AI가 부탁을 이뤄줄 수 있는 단위가 된다

Apple 생태계에서 앱은 사라지지 않는다. 대신 Siri와 Spotlight가 이해하고 호출할 수 있는 Entity/Action 단위가 된다.

Apple 생태계에서 앱은 사라지지 않는다. 오히려 더 중요해진다. 다만 앱의 의미가 바뀐다.

기존 앱은 사용자가 직접 열고 탐색하는 독립 경험이었다. WWDC26 이후의 앱은 Siri, Spotlight, Apple Intelligence가 이해하고 호출할 수 있는 Entity와 Action의 묶음이 된다.

App Intents는 이 구조의 핵심이다. 앱은 자신의 기능을 시스템이 이해할 수 있는 Action으로 선언한다. Spotlight는 앱 안의 콘텐츠를 Semantic Index로 노출한다. 사용자는 앱을 직접 열지 않고도 Siri에게 요청해 앱 안의 정보를 찾거나, 이벤트를 만들거나, 사진을 정리하거나, 메시지를 작성할 수 있다.

이 점에서 Apple은 AI가 앱을 대체한다고 말하지 않는다. 오히려 "rich, native experiences now enhanced with intelligence, not replaced by it"에 가까운 방향이다. 앱은 여전히 중심이다. 다만 앱의 기능은 시스템 AI가 위임받아 호출할 수 있는 방식으로 재구성된다.

Google이 웹과 앱을 Agent가 넘나드는 Tool Surface로 본다면, Apple은 앱을 OS Intelligence가 이해하는 Native Module로 본다.

둘 다 부탁을 들어주는 방식이다. 다만 Google은 밖으로 나가 도구를 찾고, Apple은 앱이 미리 선언한 행동 목록 안에서 부탁을 처리한다.

Apple Foundation Models와 Gemini: 엔진은 빌려도 무엇을 들어줄지는 플랫폼이 정한다

Apple이 Gemini 기술을 활용했다는 장면은 승패 구도가 아니라 모델 공급자와 권한 경계가 분리된다는 신호로 봐야 한다.

WWDC26에서 가장 상징적인 장면 중 하나는 Apple이 Google과의 협력을 언급한 대목이다. Apple 키노트 전사에서 Craig는 차세대 Apple Foundation Models를 만들면서 Google과 Deep Collaboration을 했고, Gemini Family Of Models 뒤의 기술을 활용했다고 설명한다. 이 모델들은 On-Device와 Private Cloud Compute 서버에서 실행되도록 조정됐다.

이 장면을 단순히 "Apple도 Google 기술을 썼다"로 소비하면 제일 재미있는 부분을 놓친다. 더 중요한 의미는 모델 공급자와 권한 경계가 분리된다는 점이다.

Apple은 Gemini 계열 기술을 활용할 수 있다. Xcode에서 Gemini를 포함한 여러 모델과 Agent를 선택할 수도 있다. 하지만 사용자의 개인 맥락, 앱 액션, OS 권한, Private Cloud Compute, On-Device Execution의 경계는 Apple이 관리한다.

즉 모델은 외부 기술을 쓸 수 있다. 하지만 권한 경계는 OS에 남는다.

이것은 AI 플랫폼 경쟁의 중요한 변화다. 앞으로 모델은 점점 더 공급망이 될 수 있다. 어떤 회사의 모델을 쓰는지는 중요하지만, 그보다 더 중요한 것은 그 모델이 어떤 Runtime, 어떤 Permission Boundary, 어떤 Audit System, 어떤 UX 안에 들어가는가다.

Apple의 전략은 "모델을 모두 직접 만든다"가 아니라 "어떤 모델이 들어와도 Apple의 사용자 맥락과 권한 경계 안에서 쓰이게 한다"에 가깝다.

이 글의 표현으로 바꾸면 이렇다.

엔진은 빌릴 수 있다. 하지만 무엇을 들어줄지, 어디까지 들어줄지는 플랫폼이 정한다.

Core AI와 Private Cloud Compute: 들어준 일을 어디서 처리할 것인가

모델 실행 위치는 성능표가 아니라 책임표다. 데이터 통제, 비용, 지연, 운영 책임이 함께 바뀐다.

Apple의 Foundation Models와 Core AI를 단순 개발자 API로 보면 반쪽만 본다. 더 중요한 것은 실행 위치의 정책이다.

AI를 어디서 돌릴 것인가.

기기 안에서 돌릴 것인가.

Apple의 Private Cloud Compute에서 돌릴 것인가.

외부 Provider에서 돌릴 것인가.

이 선택은 단순 배치도가 아니다. 데이터 통제, 최신 모델 접근성, 지연 시간, 비용, 운영 책임, 법적 계약이 모두 달라진다.

On-Device는 데이터 통제가 강하고 지연과 비용 예측이 쉬울 수 있지만, 모델 크기와 기기 성능에 제한이 있다. Private Cloud Compute는 클라우드 실행이지만 Apple이 검증 가능한 Privacy Boundary를 강조한다. External Provider는 최신 모델 접근이 빠를 수 있지만, 계약, 데이터 처리, 보안 정책, DPA, Logging에 대한 책임이 커진다.

그래서 Apple의 Core AI와 PCC는 성능표가 아니라 책임표로 봐야 한다.

Google은 Token Scale과 Cloud Runtime을 강하게 밀고, Apple은 Local Inference와 Privacy-Preserving Cloud Boundary를 강하게 민다. 앞으로 제품 아키텍처에서 "어떤 모델을 쓸까"만큼 중요한 질문은 "그 모델을 어디에서, 누구의 책임 아래 실행할까"가 될 것이다.

다시 말해, 이제 중요한 것은 "AI가 부탁을 이해했는가"가 아니다. "그 부탁을 어디서 처리해야 안전한가"다.

Xcode 27: Apple도 개발자의 부탁을 실제 작업으로 바꾼다

Apple도 Agentic Coding을 한다. 다만 새 작업장을 따로 세우기보다 Xcode 안으로 Agent를 흡수한다.

Apple도 Agentic Coding을 한다. 다만 표현 방식이 Google과 다르다.

Google은 Antigravity라는 Agent-First 개발 플랫폼을 전면에 내세운다. Apple은 Xcode 27 안에 Agentic Coding을 흡수한다. Xcode 27은 Coding Assistant, Device Hub, Simulator Interaction, Localization, Custom Skills, GitHub/Figma Integration, Gemini 포함 모델 선택 같은 흐름을 보여준다.

이 차이는 두 회사의 성격을 그대로 보여준다.

Google은 새 Agent 작업장을 만든다.

Apple은 기존 개발 환경의 관할권 안으로 Agent를 들인다.

Apple 개발자에게 중요한 변화는 코드를 누가 쓰느냐보다, Xcode가 Agent의 행동을 어떻게 보여주고 제어하는가다. Agent가 시뮬레이터를 조작하고, Localization을 만들고, UI Prototype을 만들고, GitHub와 Figma를 연결한다면 개발도구도 권한 관리와 실행 기록의 문제를 갖게 된다.

AI Coding의 핵심은 코드 생성량이 아니라 검증 루프의 자동화일 수 있다. 어떤 코드를 만들었는지, 어떤 테스트를 돌렸는지, 어떤 시뮬레이터 상태에서 확인했는지, 어떤 프롬프트와 모델로 생성됐는지 재현할 수 있어야 한다.

개발자의 말을 들어주는 AI는 더 이상 설명만 하지 않는다. 실제 작업 디렉터리에 들어와 코드를 바꾸고, 테스트를 돌리고, 시뮬레이터를 만진다.

그래서 개발 도구에서도 같은 질문이 생긴다.

이 요청을 어디까지 들어줘도 되는가.

Prompt Injection: 가짜 소원도 들어줄 수 있다는 문제

Prompt Injection은 AI가 말을 못 알아듣는 문제가 아니다. 가짜 부탁도 너무 잘 들어줄 수 있다는 문제다.

AI가 "들어주는" 존재가 될수록 보안의 질문이 달라진다.

기존 보안은 주로 Identity를 물었다. 이 사용자가 누구인가. 로그인했는가. 권한이 있는가. 토큰이 유효한가.

하지만 AI Agent 시대에는 Identity만으로 부족하다.

사용자가 진짜여도 사용자는 속을 수 있다. Agent가 정상 권한을 갖고 있어도 Agent가 읽은 외부 콘텐츠가 오염됐을 수 있다. 이메일, 캘린더, 웹페이지, 고객문의, 이슈 댓글, 슬랙 메시지 안에 Agent를 유도하는 악성 Instruction이 숨을 수 있다.

Apple의 Secure Your App: Mitigate Risks To Agentic Features 세션은 이 문제를 공식 보안 주제로 다룬다. 여기서 핵심은 Indirect Prompt Injection, Data Exfiltration, Unintended Actions다. Agent가 Private Data에 접근하고, Untrusted Content를 읽고, Side-Effect Action을 수행할 수 있을 때 위험이 커진다.

위험은 세 요소가 만나는 곳에서 생긴다.

Private Data.

Untrusted Content.

Side-Effect Action.

이 세 가지가 동시에 있으면 인증만으로는 부족하다. 로그인한 사용자를 대신해 AI가 행동한다면, 공격자는 사용자의 계정이 아니라 사용자의 의도를 조작하려 든다.

이 글의 언어로 바꾸면 이렇다.

Prompt Injection은 AI가 말을 못 알아듣는 문제가 아니다. 오히려 너무 잘 들어주는 문제에 가깝다. 문제는 그 말이 사용자의 부탁인지, 메일 본문에 숨어 있던 가짜 소원인지 구분해야 한다는 점이다.

SQL Injection이 데이터베이스 시대의 대표 취약점이었다면, Indirect Prompt Injection은 Agent 시대의 대표 취약점이 될 수 있다.

방어 표면도 넓어진다. Approval UX, Action Log, Rollback, Policy, MDM, Trust Insights, App Attestation, Data Boundary가 모두 필요해진다.

Trust Insights와 MDM: 말 잘 듣는 AI를 누가 통제할 것인가

AI는 개인 생산성 기능처럼 보이지만 조직 안에서는 정책 리소스가 된다. 누가 어떤 AI 기능을 허용할지 정해야 한다.

WWDC26에서 덜 화려하지만 중요한 축은 Trust와 Management다. Trust Insights는 Social Engineering과 Coercion 문제를 다룬다. 핵심 질문은 단순 인증이 아니다.

이 사용자는 진짜 사용자인가.

그리고 이 사용자는 지금 속거나 강요받고 있지 않은가.

이 질문은 AI 시대에 더 중요해진다. AI가 사용자를 대신해 Action을 수행하거나, 사용자의 개인 맥락을 해석하거나, 결제와 송금과 계정 변경을 돕게 되면 시스템은 사용자의 정체성뿐 아니라 의도와 상황을 고민해야 한다.

MDM도 마찬가지다. Apple의 Device Management 문서는 Apple Intelligence, External Intelligence Integration, Siri, Visual Intelligence, Writing Tools, Xcode의 AI 보조 기능 같은 것을 관리자가 제어할 수 있는 정책 객체로 다룬다.

예전 MDM은 카메라, AirDrop, 앱 설치, 네트워크 접근을 관리했다. 이제는 외부 AI Provider, Siri AI, Visual Intelligence, Writing Tools, Xcode AI Completion까지 통제한다.

기업 입장에서 AI는 생산성 기능이 아니라 정책 리소스다. 개발자 입장에서 AI는 코딩을 도와주는 도구이면서 동시에 회사 정책에 의해 제한될 수 있는 실행 환경이다.

이 점은 Google 쪽에도 연결된다. Gemini Spark, Managed Agents, MCP Integration, Universal Cart, Enterprise Agents가 현실이 되면 기업은 Agent의 Tool Access, Credential Scope, Audit Log, Data Boundary, Cost Limit을 관리해야 한다.

"다 들어주는 AI쨩"이 회사 안으로 들어오면, 회사는 결국 묻게 된다.

우리 조직에서는 무엇까지 들어줘도 되는가.

Apple의 Child Safety: AI가 개인 영역으로 들어올수록 룰이 필요하다

AI가 개인 영역과 앱 내부 경험으로 들어올수록 연령, 보호자, 콘텐츠 안전 같은 플랫폼 룰이 더 중요해진다.

WWDC26에서 Apple은 Siri AI와 개발자 도구만 말하지 않았다. Child Safety를 별도 축으로 길게 다뤘다. Screen Time, Ask To Browse, Time Allowances, Declared Age Range API, SensitiveContentAnalysis, PermissionKit 같은 요소가 포함됐다.

이 파트는 AI 발표와 별개처럼 보일 수 있다. 하지만 함께 보면 Apple의 플랫폼 전략이 더 잘 보인다. Apple은 AI가 앱 안으로 들어오고, 생성 콘텐츠가 늘고, 대화형 기능과 Immersive Gaming이 늘어나는 상황에서 Age-Appropriate Experience를 플랫폼의 신뢰 문제로 다룬다.

AI 기능이 강력해질수록 사용자의 개인 맥락, 아동 보호, 앱 내부 경험, 콘텐츠 노출, 커뮤니케이션 안전이 더 중요해진다. Apple은 이 문제를 개발자 API와 부모 통제 기능으로 함께 묶는다.

이것 역시 Inside Delegation의 일부다. AI가 개인 영역 안으로 들어오려면, 그 영역의 안전 규칙도 함께 강화되어야 한다.

소원을 들어주는 힘이 커질수록, 어떤 소원은 들어주면 안 된다는 룰도 같이 필요해진다.

콘텐츠는 사람이 보는 결과물이 아니라 AI가 다시 읽는 입력이 된다

콘텐츠는 최종 결과물이 아니라 AI가 다시 읽고 판단하고 실행하는 입력이 된다. Provenance는 Runtime Signal에 가까워진다.

두 행사 모두 이미지, 영상, 음악, 사진, 문서에 관한 발표가 많았다. Google은 Gemini Omni, Flow, YouTube, SynthID, Content Credentials를 강조했다. Apple은 Image Playground, Photos, Spatial Reframing, Safari, Visual Intelligence, Writing Tools를 강조했다.

이걸 단순 생성 기능 경쟁으로 보면 뻔하다. 더 중요한 변화는 콘텐츠의 지위가 바뀐다는 점이다.

과거 콘텐츠는 사람이 소비하는 최종 결과물이었다. 이제 콘텐츠는 AI가 다시 읽고, 요약하고, 편집하고, 변형하고, 판단하는 입력이 된다.

Google은 콘텐츠 출처와 생성 여부를 확인하기 위해 SynthID와 Content Credentials를 확장했다. Apple도 Apple Intelligence 기반 생성·편집 기능에서 Privacy와 워터마크, 서버 모델 사용 제한을 함께 다룬다.

출처 증명은 미디어 신뢰의 문제가 아니라 Agent 판단 품질의 문제가 된다. AI가 어떤 이미지나 문서를 보고 행동한다면, 그 입력이 생성됐는지, 편집됐는지, 신뢰 가능한지 알아야 한다.

앞으로 Provenance는 Metadata가 아니라 Runtime Signal이 될 가능성이 있다.

AI가 콘텐츠를 읽고 실제 행동까지 한다면, 콘텐츠는 더 이상 그냥 "볼거리"가 아니다. 그것은 AI가 들어줄지 말지를 판단하는 입력이다.

AI는 한 역할로 들어오지 않는다

AI는 User, Developer, Operator, Attack Surface, Auditor 역할로 동시에 들어온다. 그래서 권한 모델도 섞인다.

AI를 "Assistant"라고 부르면 너무 편하다. 하지만 실제로는 하나의 역할로 들어오지 않는다.

제품 안에서는 User처럼 행동한다. 폼을 채우고 버튼을 누르고 결제를 준비한다.

개발 도구 안에서는 Developer처럼 행동한다. 코드를 만들고 테스트를 돌리고 시뮬레이터를 조작한다.

운영 환경에서는 Operator처럼 행동한다. 로그를 읽고 장애 원인을 추정하고 복구 절차를 제안한다.

보안 관점에서는 Attack Surface가 된다. Prompt, Context, Tool Call, Action Boundary가 모두 공격 표면이 된다.

품질 관점에서는 Auditor가 된다. 결과를 평가하고, 행동을 비교하고, 다른 Agent의 산출물을 검토할 수 있다.

역할이 섞이면 권한 모델도 섞인다. 그래서 AI 기능은 특정 프론트엔드 기능 하나의 문제가 아니다. 제품, 보안, 운영, 데이터, 인프라, 법무, 고객지원이 모두 같은 질문을 공유하게 된다.

그 행동을 누가 승인했는가.

어떤 입력을 보고 실행했는가.

어떤 모델과 도구를 썼는가.

실패하면 어디까지 되돌릴 수 있는가.

사용자에게 어떻게 설명할 것인가.

"다 들어주는 AI"는 귀여운 표현이지만, 시스템 안에서는 다섯 역할을 동시에 가진다. User, Developer, Operator, Attack Surface, Auditor다.

Google과 Apple의 차이를 다시 정리하기

두 회사 모두 AI가 행동한다고 보지만, Google은 더 많이 이뤄주는 쪽을, Apple은 무엇을 믿고 들어줄지의 경계를 강조한다.

두 회사가 비슷한 점은 분명하다.

둘 다 AI가 답변을 넘어 행동한다고 본다.

둘 다 앱과 웹의 기능이 AI가 호출할 수 있는 Action으로 바뀐다고 본다.

둘 다 개발 도구 안에 Agent를 넣고 있다.

둘 다 모델을 제품 전반의 인프라로 본다.

둘 다 Safety, Evaluation, Permission, Privacy, Audit의 중요성을 알고 있다.

하지만 다르게 보는 지점이 더 중요하다.

Google은 사용자의 말을 붙잡은 뒤 외부 실행으로 확장한다. Search, Chrome, Antigravity, Google Cloud, Shopping, Gemini Spark는 모두 바깥 세계에서 일을 끝내는 표면이다.

Apple은 사용자의 맥락을 품은 뒤 OS 안에서 위임한다. Siri AI, Spotlight, App Intents, Foundation Models, Core AI, Private Cloud Compute, Trust Insights, MDM은 모두 행동 경계를 설계하는 표면이다.

Google의 중심 질문은 이것이다.

AI가 무엇을 더 이뤄줄 수 있는가.

Apple의 중심 질문은 이것이다.

AI가 무엇을 해도 된다고 믿을 수 있는가.

Google은 실행 능력의 최대치를 확장한다.

Apple은 실행 권한의 경계를 설계한다.

그래서 두 행사는 비슷하면서도 달랐다. 둘 다 AI에게 행동 능력을 준다. 하지만 Google은 AI를 외부 세계의 실행자로 만들고, Apple은 AI를 개인 세계의 위임자로 만든다.

발표를 보지 않은 독자를 위한 한 장 요약

Google은 외부 실행 체인, Apple은 내부 위임 경계다. 둘 다 "들어준다"를 답변에서 실행으로 바꾼다.

Google I/O 2026은 "AI가 더 많이 생각한다"보다 "AI가 더 많이 실행한다"에 가까웠다. Search는 작업 시작점이 되고, WebMCP는 웹을 Agent가 쓸 수 있는 도구 표면으로 만들고, Agent Executor는 장기 실행 Agent를 운영하는 Runtime 문제를 다룬다. Antigravity는 개발자를 위한 Agent 작업장이 되고, Universal Cart는 구매 요청의 위임 문제를 드러내고, Google Research는 Agentic Science라는 더 큰 끝을 보여준다.

WWDC26은 "AI가 더 많이 한다"보다 "AI가 어디까지 위임받을 수 있는가"에 가까웠다. Siri AI는 OS 차원의 개인 인터페이스가 되고, App Intents와 Spotlight는 앱 기능과 콘텐츠를 시스템 AI가 이해하는 경로가 된다. Foundation Models와 Core AI는 AI 모델을 앱 안에서 다루는 개발자 경로를 만들고, Private Cloud Compute는 클라우드 실행의 Privacy Boundary를 제공한다. Apple이 Gemini 계열 기술을 활용했다는 사실은 모델 공급자와 권한 경계가 분리되고 있다는 신호다. Trust Insights, Prompt Injection 보안, MDM은 AI 기능이 곧 정책과 신뢰의 대상이 된다는 점을 보여준다.

두 행사를 합쳐 보면 결론은 하나다.

AI가 "들어준다"는 말의 의미가 바뀌었다.

이제 들어준다는 말은 답변한다는 뜻을 넘어, 실행한다는 뜻에 가까워진다.

그리고 실행하는 순간, 우리는 모델 성능보다 권한 경계를 먼저 물어야 한다.

앞으로 봐야 할 질문

다음 관전 포인트는 Pre-App Workspace, Agentability, Agent Runtime, Prompt Injection, MDM, Local/Cloud 책임 경계다.

첫째, Search가 정말 Pre-App Workspace가 될 것인가. 사용자가 앱에 들어오기 전에 Google Search 안에서 이미 작업을 시작한다면, 제품의 Funnel과 Attribution은 바뀐다.

둘째, Agentability가 웹 품질의 새 기준이 될 것인가. 웹사이트가 AI Agent에게 Tool Name, Arguments, Side Effects를 설명해야 한다면, 프론트엔드와 백엔드의 경계도 바뀐다.

셋째, Agent Runtime이 실제 백엔드 아키텍처로 들어올 것인가. 장기 실행 Agent는 Queue나 Cron Job만으로 다루기 어렵다. State, Audit, Resume, Branch, Rollback이 필요하다.

넷째, Prompt Injection과 Coercion Detection이 보안 리뷰에 들어올 것인가. 들어오는 순간 Agentic Feature는 UX 실험이 아니라 보안 설계의 대상이 된다.

다섯째, 기업은 AI 기능을 어디까지 MDM과 Policy로 통제할 것인가. 외부 모델 호출, Source Code Access, Writing Tools, Xcode Completion, Visual Intelligence는 조직마다 다르게 제한될 수 있다.

여섯째, Local/Cloud 선택이 아키텍처의 핵심 결정이 될 것인가. Core AI, Private Cloud Compute, External Provider를 어떻게 나눌지는 제품 성능보다 데이터 관할권과 책임 경계에 더 큰 영향을 줄 수 있다.

일곱째, 모델 공급자와 플랫폼 권한 경계는 얼마나 분리될 것인가. Apple Foundation Models에 Gemini 계열 기술이 들어간 장면은 앞으로 더 흔한 구조의 예고일 수 있다.

여덟째, AI에게 어떤 요청은 절대 들어주지 않게 만들 것인가. 이 질문은 UX가 아니라 제품 책임의 문제다.

결론: 같은 미래를 말하지만, 다른 문으로 들어간다

결국 질문은 더 똑똑한 모델이 아니다. AI에게 무엇을 어디까지 들어주게 할 것인가다.

Google I/O를 보고 WWDC를 봤을 때 느꼈던 묘한 감각은 두 회사가 다른 이야기를 해서가 아니었다. 오히려 비슷한 이야기를 하고 있었기 때문에 더 헷갈렸다. 둘 다 AI가 행동한다고 말한다. 둘 다 앱과 웹과 개발 도구가 바뀐다고 말한다. 둘 다 모델과 Agent와 Safety를 말한다.

하지만 같은 미래로 들어가는 문이 다르다.

Google은 Intent의 문으로 들어간다. 사용자가 무엇을 원하는지 붙잡고, 그것을 외부 세계의 실행으로 밀어낸다.

Apple은 Context의 문으로 들어간다. 사용자가 어떤 맥락에 있는지 이해하고, 그것을 OS 안의 안전한 위임으로 묶는다.

내가 이 글의 표현으로 다시 줄이면 이렇다.

Google은 사용자의 말을 바깥에서 이뤄주려 한다.

Apple은 사용자의 말을 안쪽에서 허락된 방식으로 들어주려 한다.

그래서 2026년 플랫폼 경쟁의 핵심은 "누가 더 똑똑한 모델을 만들었나"가 아니다.

더 중요한 질문은 이것이다.

AI가 어디에서 실행하는가.

AI가 누구의 이름으로 실행하는가.

AI가 잘못 이뤄줬을 때 누가 책임지는가.

그리고 마지막으로, 우리는 AI에게 무엇을 어디까지 들어주게 할 것인가.

참고 링크

본문에서 언급한 Google과 Apple의 공식 자료를 모아둔 섹션이다.

Google

• Google I/O 2026: News And Announcements

• I/O 2026: Welcome To The Agentic Gemini ERA

• All The News From The Google I/O 2026 Developer Keynote

• A New ERA For AI Search

• Gemini 3.5: Frontier Intelligence With Action

• Chrome At I/O 2026

• Agent Executor, Google's Distributed Agent Runtime

• Google Research At I/O 2026

Apple

• WWDC26

• Platforms State Of The Union

• Apple Introduces Siri AI

• What's New In The Foundation Models Framework

• Meet Core AI

• What's New In Xcode 27

• App Intents And Siri

• Secure Your App: Mitigate Risks To Agentic Features

• Meet Trust Insights

• WWDC26 Device Management Updates