9억 Gemini 사용자 앞의 24시간 에이전트 권한 문제

AI 요약

• 무슨 일: Google이 I/O 2026에서 Gemini Spark를 24시간 개인 AI 에이전트로 공개했습니다.
  • Spark는 Gemini 3.5와 Antigravity harness 위에서 Gmail, Docs, Slides 같은 Workspace 작업을 백그라운드로 처리합니다.
• 핵심 숫자: Gemini 앱은 월간 9억 사용자 표면을 갖고, Spark 베타는 우선 미국 Google AI Ultra 구독자에게 열립니다.
• 의미: MCP 연결, custom sub-agent, local browser 로드맵은 소비자 앱이 에이전트 런타임으로 바뀌는 신호입니다.
  • 문제는 생산성보다 권한입니다. Google은 고위험 행동 전 확인을 말하지만, 실제 승인 UX와 책임 경계는 아직 검증 전입니다.

Google이 I/O 2026에서 공개한 Gemini Spark는 또 하나의 챗봇 기능처럼 보이지만, 실제로는 훨씬 큰 제품 전환을 가리킵니다. 사용자가 앱을 열고 질문을 던질 때만 답하는 비서가 아니라, 사용자가 잠든 사이에도 클라우드에서 작업을 이어가는 24시간 개인 AI 에이전트를 Gemini 앱 안으로 들여오는 시도입니다. Google은 Spark를 "디지털 생활을 탐색하고, 사용자의 지시에 따라 행동하는 24/7 personal AI agent"라고 설명했습니다.

이 뉴스가 중요한 이유는 Spark가 고립된 실험실 데모가 아니기 때문입니다. Google은 같은 발표에서 Gemini 앱이 월간 9억 명 이상, 230개 국가와 70개 이상 언어에서 쓰인다고 밝혔습니다. 아직 Spark 자체는 trusted testers와 미국 Google AI Ultra 구독자 베타부터 시작하지만, 배포 표면은 이미 거대합니다. AI 에이전트가 대중 시장에 들어가는 방식이 독립 앱 설치가 아니라 Gmail, Docs, Slides, Calendar, Chrome, macOS 앱 같은 기존 생활/업무 표면 위에 얹히는 흐름이라면, Spark는 그 전환을 보여주는 가장 노골적인 사례입니다.

여기서 개발자 독자가 봐야 할 지점은 "Google도 개인 비서를 냈다"가 아닙니다. Spark는 Gemini 3.5와 Google Antigravity harness 위에서 동작하고, Google 앱뿐 아니라 MCP 연결을 통해 Canva, OpenTable, Instacart 같은 외부 서비스로 확장될 예정입니다. Google은 여름 로드맵으로 custom sub-agents, Spark에 문자나 이메일 보내기, local browser 조작까지 예고했습니다. 다시 말해 Spark는 단일 assistant 기능이 아니라, 모델, 에이전트 하네스, 앱 커넥터, 승인 UI, 브라우저 자동화가 묶이는 소비자용 런타임입니다.

Spark가 바꾼 질문: 답변이 아니라 권한

Google 공식 글에서 Spark의 예시는 꽤 일상적입니다. 월별 신용카드 명세서를 파싱해 새 구독료나 숨은 구독료를 찾고, 아이 학교에서 오는 이메일을 읽어 중요한 마감일을 추출한 뒤 가족에게 daily digest를 보내고, 이메일과 채팅에 흩어진 회의 메모를 종합해 Google Docs 문서를 만들고 동반 이메일 초안까지 작성합니다. 전형적인 "귀찮은 업무 자동화"입니다.

하지만 이 예시들을 한 단계만 들여다보면, Spark의 본질은 생산성보다 권한에 가깝습니다. 카드 명세서를 읽으려면 금융 메일이나 첨부 파일에 접근해야 합니다. 학교 공지를 정리하려면 가족 정보와 일정이 필요합니다. 회의 메모를 문서화하려면 메일, 채팅, Drive, Docs 사이를 오가야 합니다. 이메일 초안을 만들려면 발송 직전 승인 경계가 필요합니다. Google이 강조한 "under your direction"이라는 표현은 그래서 중요합니다. 에이전트가 유용해질수록 접근 권한과 실행 권한은 넓어지고, 넓어진 권한은 사용자와 제품팀이 감당해야 할 새 위험이 됩니다.

Google은 Spark가 사용자가 켤지 선택하고, 어떤 앱에 연결할지 선택하며, 돈을 쓰거나 이메일을 보내는 고위험 행동 전에는 먼저 묻도록 설계됐다고 설명했습니다. 이 방향은 맞습니다. 다만 뉴스의 핵심은 그런 안전 문구가 있다는 사실이 아니라, 그 문구가 실제 사용 경험에서 얼마나 촘촘하게 구현되는지입니다. 에이전트가 "이메일을 보내도 될까요?"라고 한 번 묻는 것과, 어떤 수신자에게 어떤 근거로 어떤 문장을 보내는지, 첨부 파일은 무엇인지, 외부 서비스 호출이 어떤 데이터를 넘기는지까지 사용자가 이해할 수 있게 보여주는 것은 다른 문제입니다.

Gemini 3.5와 Antigravity, 소비자 앱 뒤의 에이전트 스택

Spark는 Gemini 3.5와 Antigravity harness 위에 올라갑니다. Google의 I/O 종합 글은 Gemini 3.5 Flash가 Gemini 3.1 Pro보다 Terminal-Bench 2.1 76.2%, GDPval-AA 1656 Elo, MCP Atlas 83.6% 같은 코딩 및 에이전트형 벤치마크에서 앞선다고 설명했습니다. Google이 Spark를 소개하면서 3.5와 Antigravity를 같이 언급한 것은 우연이 아닙니다. 24시간 에이전트가 실제로 유용하려면 모델이 단발 답변보다 긴 작업 계획, 도구 호출, 실패 회복, 상태 관리에 강해야 하기 때문입니다.

Antigravity는 최근 devlery에서도 다룬 것처럼 Google의 에이전트형 개발 플랫폼 축입니다. Spark가 그 하네스를 소비자 Gemini 앱 쪽으로 가져온다면, 개발자용 에이전트 기술과 소비자용 생산성 앱 사이의 경계가 흐려집니다. 예전에는 "코딩 에이전트"와 "개인 assistant"가 다른 제품군처럼 보였습니다. 이제는 둘 다 같은 문제를 풉니다. 모델이 어떤 도구를 언제 호출할지, 장기 작업 상태를 어디에 둘지, 중간 산출물을 어떻게 검증할지, 사용자의 승인을 어느 단계에서 요구할지입니다.

이 변화는 AI 앱 개발자에게 실질적인 압박을 만듭니다. Spark가 MCP 연결을 소비자 표면에 들여오면, 외부 서비스는 사람이 쓰는 API와 에이전트가 쓰는 API를 동시에 생각해야 합니다. Canva, OpenTable, Instacart는 단순한 "Gemini 플러그인 파트너"가 아니라, 에이전트가 예약, 주문, 편집, 결제 전 단계까지 접근할 수 있는 권한 모델을 설계해야 하는 위치에 놓입니다. 앞으로 더 많은 서비스가 MCP 서버를 제공한다면, 제품팀은 "우리 API가 사람이 클릭하는 UI 뒤에 있을 때"와 "백그라운드 에이전트가 주기적으로 호출할 때"의 차이를 따로 다뤄야 합니다.

MCP가 소비자 앱으로 들어올 때 생기는 일

MCP는 지금까지 개발자 도구와 에이전트 프레임워크의 언어로 이야기되는 경우가 많았습니다. Claude Desktop, Claude Code, Cursor, OpenAI 계열 에이전트, 각종 로컬 서버와 연결되는 "도구 표준"이라는 맥락이 강했습니다. 그런데 Spark 발표에서 MCP는 소비자 앱의 확장 방식으로 등장합니다. Google은 Canva, OpenTable, Instacart MCP 연결을 출시하고, 앞으로 몇 주 안에 Spark가 이 연결을 사용해 작업을 수행할 수 있게 하겠다고 말했습니다.

이 지점이 흥미롭습니다. 소비자에게는 "Gemini가 식당을 예약하고 장을 봐준다"로 보이지만, 개발자에게는 "MCP 서버가 어떤 권한 요청, 데이터 스코프, 실행 confirmation, rollback 경로를 제공해야 하는가"라는 질문이 됩니다. 예를 들어 OpenTable 연결에서 에이전트가 후보 식당을 검색하는 것은 낮은 위험입니다. 특정 시간대 예약을 잡는 것은 중간 위험입니다. 노쇼 수수료가 있는 예약을 확정하거나 카드 정보를 쓰는 순간은 높은 위험입니다. Instacart에서도 장바구니 후보를 만드는 것과 실제 결제를 실행하는 것은 완전히 다른 단계입니다.

따라서 Spark는 MCP 생태계에 새로운 요구를 추가합니다. MCP 서버는 단순히 "이 도구는 이런 인자를 받습니다"라고 노출하는 것만으로 충분하지 않습니다. 어느 호출이 읽기 전용인지, 어느 호출이 외부 세계를 바꾸는지, 어느 호출이 결제를 유발하는지, 어느 호출이 사용자 데이터 일부를 제3자에게 넘기는지 기계가 이해할 수 있어야 합니다. 지금의 많은 agent tool schema는 이 경계를 자연어 설명에 기대는 경우가 많습니다. 9억 사용자 앱의 백그라운드 에이전트 표면에서는 그 정도로는 부족할 수 있습니다.

Google의 강점은 배포력, 약점도 배포력

Spark의 가장 큰 강점은 Google의 제품 배포력입니다. Gmail, Docs, Slides, Calendar, Drive, Android, Chrome, macOS용 Gemini 앱까지 이어지는 표면은 이미 사람들이 일하고 생활하는 곳입니다. 사용자는 별도 에이전트 앱을 설치하고 새 도구를 학습하는 대신, 이미 쓰는 앱에서 에이전트 기능을 켤 수 있습니다. OpenAI의 ChatGPT Agent나 Anthropic의 Claude Cowork도 강력하지만, Google은 사용자 데이터와 업무 도구의 접점에서 출발합니다.

그러나 바로 그 점이 약점이기도 합니다. 독립 에이전트 앱에서 실수하면 사용자는 "그 앱이 잘못했다"고 이해하기 쉽습니다. Gmail, Calendar, Docs에 깊게 통합된 에이전트가 실수하면, 사용자는 Google 계정 전체의 신뢰 문제로 받아들일 수 있습니다. 잘못된 이메일 발송, 민감 문서 참조, 잘못된 예약, 불필요한 결제, 개인 일정 노출은 모두 제품 차원의 책임 이슈가 됩니다. Google이 Spark를 trusted testers와 미국 Google AI Ultra 베타부터 시작하는 것은 기능 미완성뿐 아니라 신뢰 실험의 범위를 좁히려는 선택으로 볼 수 있습니다.

가격도 초기 확산을 제한합니다. Google은 Spark 베타를 다음 주 미국 Google AI Ultra 구독자에게 제공할 계획이라고 밝혔습니다. AI Ultra는 대중적 무료 기능이라기보다 고가의 파워 유저/전문가용 티어에 가깝습니다. 따라서 "9억 Gemini 사용자에게 바로 24시간 에이전트가 열린다"는 식으로 읽으면 과장입니다. 더 정확히는, Google이 9억 사용자 표면을 가진 앱 안에서 가장 민감한 에이전트 기능을 제한된 고가 베타로 시험하기 시작했다는 이야기입니다.

Daily Brief와 Spark의 차이

같은 발표에서 Daily Brief도 함께 나왔습니다. Daily Brief는 사용자의 목표를 바탕으로 하루를 정리하고 다음 단계를 제안하는 agent로 소개됐습니다. Gmail, Calendar, Tasks를 읽어 아침 브리핑을 만들고, 미국 Google AI 구독자부터 롤아웃됩니다. 이 기능은 Spark보다 이해하기 쉽습니다. 읽고, 요약하고, 우선순위를 매기고, 제안합니다. 사용자가 바로 실행 버튼을 누르기 전까지는 외부 세계를 크게 바꾸지 않습니다.

Spark는 다릅니다. Spark의 방향은 "정보를 정리해주는 에이전트"에서 "작업을 맡아 처리하는 에이전트"입니다. Google 공식 글도 Spark를 "information to action" 섹션에 배치했습니다. 이 구분은 제품 설계에서 중요합니다. 읽기 에이전트는 잘못 요약하면 사용자 판단으로 보정할 수 있습니다. 쓰기 에이전트는 잘못 실행하면 외부 세계에 흔적을 남깁니다. 이메일은 전송되고, 예약은 생성되고, 문서는 공유되고, 결제는 발생합니다. Spark가 정말 성공하려면 모델 성능보다 이 전환의 UX가 좋아야 합니다.

개발팀은 이 차이를 자신들의 제품에도 적용해 볼 수 있습니다. "AI가 알아서 처리합니다"라는 문구는 매력적이지만, 실제 권한 모델은 읽기, 초안 작성, 내부 상태 변경, 외부 상태 변경, 결제/발송/공유 같은 단계로 나뉘어야 합니다. 각 단계마다 로그, 설명, 취소, 승인, 재시도 정책이 달라야 합니다. Spark가 대중 제품에서 이 문제를 어떻게 푸는지는 앞으로 에이전트 UX의 사실상 기준점이 될 수 있습니다.

커뮤니티의 기대와 회의론

초기 커뮤니티 반응은 두 갈래입니다. 하나는 Google이 드디어 "agentic web"을 대중 제품에 올렸다는 기대입니다. Reddit과 기술 매체에서는 Spark가 챗봇을 넘어 Gmail, Workspace, 예약, 쇼핑, 브라우저까지 이어지는 계층이 될 수 있다는 반응이 나왔습니다. Google 제품군이 넓기 때문에, 사용자가 이미 연결해 둔 데이터와 서비스 위에서 에이전트가 작동할 수 있다는 점은 확실한 차별점입니다.

다른 한편에는 책임에 대한 우려가 있습니다. 한 Reddit 글은 Google I/O가 agentic web을 보여줬지만, 에이전트가 행동할 때 누가 책임지는지는 충분히 보여주지 않았다고 비판했습니다. 이 비판은 단순한 불안이 아닙니다. 에이전트가 Gmail을 읽고, Calendar를 조정하고, 외부 MCP 서비스를 호출하고, 향후 결제와 브라우저 조작까지 한다면 실패의 원인을 한 곳에 돌리기 어렵습니다. 모델 판단 오류인지, tool schema 설명 부족인지, MCP 서버의 권한 설계 문제인지, 사용자가 지나치게 넓은 권한을 부여한 것인지, 제품 UI가 위험을 충분히 설명하지 않은 것인지가 뒤섞입니다.

개발자에게 이 회의론은 좋은 체크리스트입니다. 에이전트 제품을 만들 때 "모델이 할 수 있다"는 데모만으로는 부족합니다. 실패했을 때 누가 무엇을 볼 수 있는지, 어떤 로그가 남는지, 사용자가 어떤 단위로 권한을 회수할 수 있는지, 작업이 장시간 백그라운드에서 진행되는 동안 어떤 알림을 받는지, 잘못된 결과를 어떻게 되돌릴 수 있는지까지 설계해야 합니다. Spark가 대중 시장에 들어가면 사용자는 이런 기준을 더 당연하게 요구하게 될 것입니다.

앞으로 볼 지점

첫째, Spark의 승인 UX입니다. Google은 고위험 행동 전 확인을 말했습니다. 하지만 실제 베타에서 확인해야 할 것은 "고위험"의 정의입니다. 이메일 전송, 문서 공유, 예약, 결제, 외부 앱 데이터 전달, 브라우저 조작은 모두 위험이 다릅니다. Spark가 각 행동을 어떻게 분류하고, 사용자에게 어떤 근거와 diff를 보여주는지가 핵심입니다.

둘째, MCP 권한 모델입니다. Canva, OpenTable, Instacart 연결은 시작일 뿐입니다. 더 많은 파트너가 붙을수록 MCP 서버는 읽기/쓰기 권한, 비용 발생, 개인정보 전달, 실행 취소 가능성을 구조화해 제공해야 합니다. 이 요구가 MCP 생태계의 표준 관행으로 자리 잡으면, 개발자용 에이전트 도구에도 영향을 줄 수 있습니다.

셋째, custom sub-agents입니다. Google은 Spark에서 사용자가 custom sub-agents를 만들 수 있게 하겠다고 예고했습니다. 이는 개인화된 자동화의 강력한 수단이지만, 동시에 권한 확산의 통로입니다. 사용자가 만든 하위 에이전트가 어떤 앱에 접근하는지, 부모 에이전트와 권한을 공유하는지, 각 sub-agent의 로그와 메모리가 분리되는지는 중요한 제품 질문입니다.

넷째, local browser와 macOS 통합입니다. Spark가 여름에 macOS 앱과 연결되고, 향후 local browser를 조작한다면 클라우드 에이전트와 로컬 컴퓨터 사용의 경계가 다시 열립니다. 브라우저는 사용자의 로그인 세션, 사내 앱, 관리자 콘솔, 결제 페이지가 모여 있는 곳입니다. 브라우저 자동화는 에이전트의 유용성을 크게 높이지만, 승인과 격리 없이는 가장 위험한 권한이 됩니다.

결론: Spark는 기능보다 운영 모델의 뉴스

Gemini Spark를 단순히 "Google의 새 AI 비서"로 읽으면 뉴스의 절반을 놓칩니다. 더 중요한 것은 Google이 9억 사용자 규모의 Gemini 앱을, 24시간 백그라운드 작업과 MCP 연결과 custom sub-agent와 브라우저 조작으로 이어지는 에이전트 런타임으로 바꾸려 한다는 점입니다. 지금은 제한된 베타이고, 실제 품질과 안전성은 검증 전입니다. 그럼에도 방향은 분명합니다. AI 제품의 경쟁은 더 이상 답변창 안에서만 벌어지지 않습니다. 사용자의 앱 권한, 연결 서비스, 승인 경계, 장기 실행 로그가 다음 전장이 되고 있습니다.

개발팀이 가져갈 실무 결론은 분명합니다. Spark를 지켜볼 때 모델 성능보다 권한 설계를 봐야 합니다. 어떤 데이터를 읽는지, 어떤 행동을 실행하는지, 어느 순간 사용자 승인을 요구하는지, 실패했을 때 무엇을 되돌릴 수 있는지 확인해야 합니다. MCP 서버나 에이전트 연결 기능을 만드는 팀이라면 tool schema에 자연어 설명만 붙이는 단계에서 벗어나, 위험도와 권한 범위를 기계가 읽을 수 있게 표현하는 방법을 고민해야 합니다. Spark가 성공하든 실패하든, 24시간 에이전트가 대중 앱 안으로 들어왔다는 사실은 앞으로의 AI 제품 설계 기준을 바꿀 가능성이 큽니다.