꺼진 노트북 뒤의 Spark, 개인 에이전트의 권한 시험대
Gemini Spark는 Google 앱을 배경에서 움직이는 24시간 개인 에이전트로 만들며, 핵심 쟁점은 모델보다 권한과 승인입니다.
- 무슨 일: Google이
Gemini Spark를 24/7 개인 AI 에이전트로 공개했습니다.- Gemini 3.5와 Antigravity harness 기반으로, 노트북을 닫거나 휴대폰을 잠가도 cloud에서 작업을 이어갑니다.
- 핵심 변화: Gemini가 답변 앱에서 Gmail, Docs, Slides를 움직이는 실행 계층으로 이동합니다.
- 주의점: 이메일 발송, 결제, local browser 자동화는 모델 성능보다 권한·승인·감사가 성패를 가릅니다.
- Google은 high-stakes action 전 확인을 말하지만, 실제 UX와 정책 범위는 베타 운영에서 검증되어야 합니다.
Google I/O 2026에서 발표가 너무 많았습니다. Gemini 3.5 Flash, Gemini Omni, Google Pics, Antigravity 2.0, Search information agents, Android의 Gemini Intelligence까지 한꺼번에 나왔습니다. 그중 Gemini Spark는 겉으로 보면 소비자용 Gemini 앱의 새 기능처럼 보입니다. 하지만 AI 개발자와 제품팀 입장에서는 꽤 다른 질문을 던집니다. AI assistant가 사용자의 질문에 답하는 단계를 넘어, 사용자가 앱을 닫은 뒤에도 계속 작업하는 개인 에이전트가 되면 무엇을 허용해야 할까요.
Google은 공식 발표에서 Spark를 "24/7 personal AI agent"라고 설명했습니다. Gemini 3.5와 Antigravity harness를 기반으로 하고, Gmail, Docs, Slides 같은 Workspace 도구와 깊게 연결됩니다. 중요한 문장은 그다음입니다. Spark는 cloud-based agent이기 때문에 사용자가 노트북을 닫거나 휴대폰을 잠가도 background에서 계속 일할 수 있습니다. 이것은 단순한 모바일 알림 기능이 아닙니다. 개인 AI가 사용자의 기기 앞에 앉아 있는 시간이 아니라, 사용자가 위임한 목표와 권한을 기준으로 움직이는 구조입니다.
Google이 제시한 예시는 의도적으로 일상적입니다. 매달 신용카드 명세서를 읽고 새 구독료나 숨은 구독료를 찾습니다. 아이 학교에서 오는 이메일을 확인해 중요한 마감일을 뽑고, 사용자와 배우자에게 일일 digest를 보냅니다. 이메일과 채팅에 흩어진 회의 메모를 합쳐 Google Docs 문서로 정리하고, 프로젝트 시작용 이메일 초안까지 만듭니다. 하나하나는 이미 자동화 도구나 개인 비서 앱이 해온 일처럼 보일 수 있습니다. 차이는 이 작업들이 Gemini 앱, Workspace, Google Cloud, Antigravity harness, MCP connection이라는 한 덩어리 위에 놓인다는 점입니다.
답변 앱에서 실행 파트너로
지금까지 개인 AI assistant의 기본 장면은 대화창이었습니다. 사용자가 질문을 넣고, 모델이 답하고, 사용자가 그 답을 다른 앱으로 옮깁니다. Google은 Spark에서 이 방향을 뒤집으려 합니다. Gemini가 사용자의 Gmail과 Calendar와 Docs를 이해하고, 필요한 산출물을 직접 만들고, 다음 행동을 제안하거나 일부 행동을 실행하는 쪽입니다.
이 변화는 Gemini 3.5 Flash 발표와도 연결됩니다. Google은 Gemini 3.5 발표에서 3.5 Flash를 agentic workflow와 coding에 맞춘 모델로 설명했습니다. Terminal-Bench 2.1 76.2%, GDPval-AA 1656 Elo, MCP Atlas 83.6%, CharXiv Reasoning 84.2% 같은 숫자를 내세웠고, Antigravity harness와 결합하면 collaborative subagents가 장시간 문제를 나눠 풀 수 있다고 말했습니다. Spark는 이 기술 포지션을 소비자와 업무 앱 표면으로 끌고 온 제품입니다. 코딩 에이전트가 리포지토리를 읽고 테스트를 돌리는 것처럼, 개인 에이전트는 inbox와 document와 calendar를 읽고 다음 행동을 만듭니다.
여기서 개발자가 봐야 할 포인트는 "Gemini가 더 똑똑해졌다"가 아닙니다. Spark는 모델 상품이 아니라 권한 상품에 가깝습니다. 어떤 앱을 연결할 것인가. 어떤 데이터는 읽기만 허용하고, 어떤 데이터는 쓰기까지 허용할 것인가. 이메일 발송, 결제, 일정 추가, 브라우저 조작처럼 실수 비용이 큰 행동을 언제 멈춰 세울 것인가. 개인 에이전트의 품질은 모델의 reasoning 점수만으로 결정되지 않습니다. 중간 승인과 취소, 로그, 재시도, 실패 복구, 비용 한도, 데이터 보존이 모두 제품 품질입니다.
| 층 | Spark에서 보이는 변화 | 제품팀이 검증할 질문 |
|---|---|---|
| 모델 | Gemini 3.5 기반 장시간 agentic workflow | 오래 실행될 때 계획과 문맥이 유지되는가 |
| 하네스 | Antigravity harness와 subagent 문법 | 작업 분해, 상태 저장, 실패 복구가 설명 가능한가 |
| 연결 | Workspace, connected apps, MCP partner connections | 각 연결의 읽기·쓰기 권한이 분리되는가 |
| 승인 | high-stakes action 전 확인 설계 | 돈, 메일, 일정, 외부 공유를 언제 멈추는가 |
Google이 유리한 이유는 데이터가 아니라 표면입니다
Spark가 흥미로운 이유는 Google이 개인 데이터에 접근할 수 있어서만은 아닙니다. 더 정확히 말하면 Google은 이미 사용자의 작업 표면을 가지고 있습니다. Gmail은 외부 세계와의 약속, 영수증, 예약, 고객 문의, 학교 공지, 업무 스레드가 들어오는 곳입니다. Docs와 Slides는 산출물이 만들어지는 곳입니다. Calendar는 행동의 시간표입니다. Android와 Chrome은 사용자가 실제로 움직이는 화면입니다. 개인 에이전트가 유용해지려면 이 표면들 사이를 오가야 합니다.
기존 자동화 플랫폼도 이 문제를 풀어왔습니다. Zapier, Make, IFTTT, RPA 도구들은 앱을 연결하고 trigger와 action을 엮었습니다. 다만 대부분은 명시적 규칙과 connector 중심입니다. Spark가 다른 점은 자연어 목표, 개인 문맥, 앱 연결, cloud background execution을 같은 제품 언어로 묶는다는 데 있습니다. 사용자는 "학교 이메일을 매일 정리해줘"라고 말하고, 에이전트는 어떤 이메일을 보고 누구에게 보낼지, 어떤 deadline이 중요한지, 어떤 문장은 그대로 전달하면 안 되는지 판단해야 합니다. 이 지점에서 자동화는 workflow 설정 문제가 아니라 판단과 책임의 문제가 됩니다.
Google은 Workspace 발표에서도 Spark를 "질문에 답하는 assistant에서 사용자를 대신해 행동하는 agent"로 이동시키는 변화라고 설명했습니다. 이 문장은 마케팅 문구이지만 동시에 정확한 제품 정의입니다. 답변은 틀려도 사용자가 복사하기 전에 멈출 수 있습니다. 행동은 다릅니다. 잘못된 이메일을 보내거나, 잘못된 결제 승인을 내리거나, 민감한 문서를 잘못 공유하면 취소하기 어렵습니다. 그래서 개인 에이전트의 핵심 UX는 멋진 데모보다 "언제 멈추는가"에 있습니다.
MCP와 partner connection이 열어주는 것
Google은 Spark 로드맵에서 Canva, OpenTable, Instacart MCP connections를 언급했습니다. 지금은 연결 발표에 가깝고, 앞으로 Spark가 이 MCP connection을 사용해 일을 처리할 수 있게 하겠다는 방향입니다. 이 선택은 작지 않습니다. MCP는 원래 개발자와 에이전트 도구 생태계에서 빠르게 퍼진 연결 문법입니다. 파일, API, SaaS, 데이터베이스, 내부 시스템을 모델이 사용할 수 있는 도구로 노출하는 방식입니다. 이것이 개인 Gemini 앱의 소비자 기능 설명 안으로 들어왔다는 것은, agent tool layer가 개발자 도구 밖으로 나오고 있다는 뜻입니다.
OpenTable과 Instacart는 특히 민감합니다. 식당 예약은 일정과 선호, 위치 정보를 건드립니다. 장보기는 결제, 배송지, 가족 구성, 식습관, 예산과 연결됩니다. Canva는 콘텐츠 제작과 브랜드 자산, 공유 권한을 다룹니다. 이런 연결은 Spark를 유용하게 만들지만, 동시에 "개인 에이전트가 무엇까지 알고 무엇까지 할 수 있는가"라는 질문을 선명하게 만듭니다.
Google의 I/O 100가지 발표 정리는 더 나아갑니다. 향후 Spark에 직접 문자나 이메일을 보내고, custom sub-agents를 만들고, 예산과 merchant를 지정한 payment authorization을 할 수 있다고 적었습니다. 이것은 개인 AI의 product roadmap으로는 자연스럽지만, 보안과 신뢰 관점에서는 강한 신호입니다. 결제는 단순한 tool call이 아닙니다. 예산, 상점, 품목, 환불, 사기 탐지, 사용자 확인, 감사 기록이 필요합니다. 개인 에이전트가 "내 대신 장 봐줘"를 처리하려면, 모델이 좋은 후보를 고르는 것보다 구매 권한의 경계를 명확히 하는 일이 더 중요합니다.
24시간 실행은 편의가 아니라 운영 모델입니다
Spark가 cloud-based agent라는 점도 따로 봐야 합니다. 많은 개인 AI 도구는 사용자가 앱을 열어둔 동안만 실행됩니다. 브라우저 탭을 닫으면 멈추고, 노트북이 잠들면 멈춥니다. Spark는 반대로 사용자가 기기를 닫아도 cloud에서 계속 일하는 포지션입니다. 이것은 사용자 경험에는 편합니다. 하지만 제품 운영에는 더 높은 요구사항을 만듭니다.
첫째, 상태 관리가 필요합니다. 에이전트가 어떤 목표를 받았고, 어디까지 실행했고, 어떤 근거로 다음 행동을 기다리는지 보여줘야 합니다. 둘째, 중간 승인 큐가 필요합니다. 사용자가 잠든 동안 에이전트가 결제 전 단계까지 왔다면, 아침에 어떤 정보로 승인해야 하는지 이해할 수 있어야 합니다. 셋째, 실패 복구가 필요합니다. Gmail 검색이 실패하거나, 외부 MCP 연결이 rate limit에 걸리거나, Docs 작성 중 권한 문제가 생기면 에이전트는 조용히 실패하지 말고 재시도 가능한 상태로 남아야 합니다. 넷째, 비용과 사용량이 필요합니다. 개인 에이전트가 24시간 도는 순간, 사용자는 "몇 번 질문했는가"보다 "어떤 작업이 얼마나 오래 실행됐는가"를 봐야 합니다.
이 관점에서 Spark는 코딩 에이전트 시장과 닮았습니다. Codex, Claude Code, Cursor, GitHub Copilot coding agent는 모두 장시간 작업, diff, approval, background execution, remote control을 제품의 중심으로 가져왔습니다. Spark는 같은 문법을 개인 생활과 Workspace 업무로 옮깁니다. 차이는 코드 변경의 결과가 pull request에 남는 대신, 개인 에이전트의 결과는 이메일, 일정, 결제, 문서, 예약으로 퍼진다는 점입니다. 그래서 더 넓고 더 미묘합니다.
커뮤니티가 보는 핵심은 권한 모델입니다
확인 시점에 Hacker News나 GeekNews의 큰 독립 토론은 찾기 어려웠습니다. 반응은 Reddit과 기술 매체에 흩어져 있습니다. 긍정적인 쪽은 Google이 드디어 개인 AI를 실제 업무 표면에 붙였다고 봅니다. 특히 Gmail과 Workspace를 매일 쓰는 사용자에게는 "한 번 질문하고 답을 받는 AI"보다 "계속 들어오는 업무를 정리하는 AI"가 더 실용적일 수 있습니다.
반대로 회의적인 반응은 권한과 데이터에 집중합니다. Ars Technica는 유용성이 충분하다면 사용자의 감각이 바뀔 수 있지만, Google Cloud에서 실행되는 AI 모델에 많은 개인 데이터를 제공하는 데 불편함을 느끼는 사람이 많을 것이라고 해석했습니다. Reddit의 일부 반응도 비슷합니다. 24/7 background agent라면 UX와 permission model이 성패를 가를 것이라는 지적입니다. 이 반응은 단순한 프라이버시 우려가 아닙니다. 개인 에이전트가 정말 유용하려면 많은 권한이 필요하고, 많은 권한을 주면 실수의 비용이 커지는 구조적 긴장입니다.
Google은 이 긴장을 알고 있습니다. 공식 발표에는 사용자가 Spark를 켤지 선택하고, 어떤 앱을 연결할지 선택하며, 돈을 쓰거나 이메일을 보내는 high-stakes action 전에는 먼저 묻도록 설계됐다고 적혀 있습니다. 이 방향은 맞습니다. 다만 실제 제품에서는 "high-stakes"의 정의가 어렵습니다. 이메일 발송은 명백합니다. 하지만 민감한 초안을 만드는 것은 어떨까요. 캘린더에 tentative hold를 잡는 것은 어떨까요. 식당 후보를 공유하는 것은 어떨까요. 친구에게 보내는 메시지 초안을 쓰는 것은 high-stakes일까요. 개인 에이전트의 안전은 정책 문구보다 이런 경계 사례에서 결정됩니다.
개발자에게 남는 실무 질문
Spark는 아직 early product입니다. trusted testers에 먼저 제공되고, 미국 Google AI Ultra 구독자 대상 베타가 계획되어 있습니다. 따라서 지금 단계에서 "성공했다"거나 "위험하다"고 단정하기는 이릅니다. 대신 개발자와 AI 제품팀이 가져가야 할 질문은 분명합니다.
첫째, 에이전트가 앱을 연결할 때 권한을 얼마나 세분화할 수 있어야 할까요. 읽기, 초안 작성, 발송, 결제, 예약, 삭제, 외부 공유는 모두 다른 권한입니다. 둘째, 사용자가 승인하기 전에 충분한 근거를 볼 수 있어야 합니다. 어떤 이메일에서 어떤 정보를 뽑았고, 왜 이 결정을 제안했는지 보여주지 않으면 승인은 형식이 됩니다. 셋째, 에이전트가 실수했을 때 rollback 가능한 설계가 필요합니다. 문서 초안은 되돌릴 수 있지만, 보낸 이메일과 결제는 어렵습니다. 넷째, 장시간 실행 에이전트의 로그와 비용을 사용자 언어로 보여줘야 합니다. "작업이 완료됨"보다 "무엇을 읽고, 무엇을 만들고, 무엇을 멈춰 세웠는가"가 중요합니다.
Spark의 진짜 뉴스는 Google이 Gemini에 또 하나의 기능을 붙였다는 사실이 아닙니다. Google은 개인 AI assistant를 background worker로 바꾸고 있습니다. 이 worker는 Google 앱을 알고, 외부 MCP connection을 쓰고, 사용자가 잠든 동안에도 상태를 유지하며, 앞으로는 local browser와 결제 승인까지 다룰 수 있습니다. 이 방향이 성공하면 개인 AI는 대화창이 아니라 개인 운영 계층이 됩니다.
그만큼 다음 경쟁도 명확해집니다. 어느 회사가 가장 화려한 agent demo를 보여주는가가 아닙니다. 누가 사용자의 데이터와 권한을 가장 이해하기 쉬운 방식으로 나누고, 실수 비용이 큰 행동 앞에서 자연스럽게 멈추며, 장시간 작업의 상태를 믿을 수 있게 보여주는가입니다. 꺼진 노트북 뒤에서 계속 일하는 Spark가 시험대에 올린 것은 Gemini의 지능만이 아닙니다. 개인 AI에게 일을 맡기기 위해 필요한 권한의 문법입니다.