2026년 5월 Google I/O에서 Google Gemini Spark가 발표되었으며, 2026년 7월 29일에는 호주로 액세스 권한이 확장되었습니다. 개발자 관점에서의 이야기는 두 번째 출시가 아닙니다. 이는 초기 기기가 닫힌 상태에서도 계속 작동할 수 있는 런타임 (runtime)입니다.

실행 모델부터 시작하기

Spark는 Google의 24/7 상시 가동되는 개인용 AI 에이전트로 설명됩니다. 이는 전용 Google Cloud 가상 머신 (virtual machines)에서 지속적으로 실행되므로, 사용자가 세션을 떠나고 사용자의 기기를 열어두지 않아도 다단계 작업이 계속될 수 있습니다.

이는 제한된 대화 (bounded conversation)와는 다른 엔지니어링 경계입니다. 응답은 종료되지만, 런타임 (runtime)은 지속됩니다. 따라서 개발자는 에이전트가 무엇을 해야 하는지뿐만 아니라, 무엇이 활성 상태로 남아 있을 수 있는지, 어떤 도구 (tools)를 호출할 수 있는지, 그리고 아무도 세션을 지켜보지 않을 때 어떤 증거가 존재해야 하는지를 모델링해야 합니다.

정확한 구현 논의를 위해서는 호주 출시 시점이 중요합니다. Spark는 2026년 5월 Google I/O에서 처음 공개되었으며, 7월 29일 발표를 통해 초기 미국 출시 이후 액세스 권한이 확장되었습니다. 이는 호주 전용 제품이나 새로운 글로벌 데뷔가 아니었습니다.

도구를 보안 경계의 일부로 취급하기

Gmail, Chrome, 그리고 MCP는 도구들을 Spark의 실행 경로에 직접 배치합니다. 에이전트가 편지함, 브라우저 또는 MCP 연결 서비스를 사용할 수 있게 되면, 커넥터 (connector)는 더 이상 주변적인 요소가 아닙니다. 커넥터의 권한은 런타임 (runtime)이 무엇에 접근할 수 있고 무엇을 계속 사용할 수 있는지를 정의하는 데 도움을 줍니다.

유용한 설계 검토 (design review)는 액세스를 구체화해야 합니다. 작업에 필요한 메일함 범위, 브라우저 동작, MCP 기능, 운영 데이터 및 API 권한을 식별하십시오. 그런 다음 어떤 액세스가 항상 사용 가능한지, 어떤 것이 검토를 필요로 하는지, 그리고 어떤 것이 지속적인 실행 (persistent run)에 절대 허용되어서는 안 되는지를 결정하십시오.

프로덕션 신뢰 체크리스트 사용하기

Van Data Team에서는 오케스트레이션 레이어 (orchestration layer)를 선택하기 전에 운영 모델을 매핑합니다. Spark 파일럿을 위한 최소 검토 사항은 다음과 같습니다:

1. 작업 수용(task intake) 정의: 실행을 시작하는 요소, 요청된 결과, 제공된 컨텍스트를 기록합니다.
2. 결정 지점(decision points) 표시: 일상적인 실행과 사람의 개입이 필요한 선택을 구분합니다.
3. 권한 제한(Bound permissions): 각 Gmail, Chrome, MCP, API 또는 데이터 권한을 명시된 작업과 연결합니다.
4. 실패 처리(failure handling) 명시: 명시적인 중단 조건과 사람에게 에스컬레이션(escalation)을 트리거하는 상황을 작성합니다.
5. 증거 보존(Preserve evidence): 지속되는 실행을 위해 트레이스(traces), 토큰 및 비용 텔레메트리(telemetry), 데이터 출처(data provenance)를 캡처합니다.
6. 검토 게이트(review gates) 설정: 무인 실행(unattended execution)의 이점보다 계속되는 작업의 리스크가 더 큰 경우 승인을 요구합니다.

이것은 프롬프트 체크리스트가 아닙니다. 이는 런타임 제어(runtime control) 체크리스트입니다. 프롬프트는 의도를 표현할 수는 있지만, 권한 경계(permission boundaries), 텔레메트리(telemetry) 또는 중단 경로(stop path)를 대체할 수는 없습니다.

보고된 사실과 아키텍처 선택의 분리

확인된 제품의 모습은 명확합니다: 2026년 5월 I/O 공개, 7월 29일 호주 확장, 전용 Google Cloud 가상 머신에서의 지속적인 런타임, 그리고 Gmail, Chrome 및 MCP 실행 경로입니다.

해당 모습을 중심으로 구축된 모든 것은 설계 선택(design choice)으로 분류되어야 합니다. 중단 조건 스키마(stop-condition schema), 에스컬레이션 큐(escalation queue) 또는 검토 게이트(review gate)는 프로덕션 신뢰성을 위해 필요할 수 있지만, 이는 새롭게 보고된 Spark 기능이라기보다 구현 아키텍처(implementation architecture)의 일부입니다. 이러한 카테고리를 분리함으로써 제품 뉴스가 운영 보증(operational guarantee)으로 오인되는 것을 방지할 수 있습니다.

트레이드오프(tradeoffs)에 대해 솔직해지기

관리형 연속성(Managed continuity)이 유용한 이유는 바로 노트북을 계속 열어둘 필요가 없기 때문입니다. 동일한 특성이 권한과 실패가 중요하게 작용하는 기간을 연장합니다. 여기서 편의성과 제어는 서로 연결되어 있습니다. 한쪽을 설계하지 않고 다른 한쪽만 높이는 것은 불완전한 시스템을 남깁니다.

좁은 권한 (Narrow permissions)과 사람의 검토 (human review)는 실행 속도를 늦출 수 있습니다. 공격적인 중단 조건 (stop conditions)은 회복될 수도 있었던 작업을 종료시켜 버릴 수 있습니다. 토큰 및 비용 텔레메트리 (telemetry)는 운영자에게 런타임이 무엇을 소비했는지는 알려주지만, 해당 작업이 적절했는지 여부를 결정해주지는 않습니다. 추적 (Traces)과 출처 (provenance)는 재구성을 개선하지만, 팀에는 여전히 에스컬레이션 (escalation) 결정을 책임질 사람이 필요합니다.

목표는 최대의 자율성이 아닙니다. 검토 가능한 기록을 남기고 신뢰할 수 있는 중단 방법을 유지하면서, 정의된 작업을 완료할 수 있을 만큼의 충분한 자율성을 확보하는 것입니다.

데모가 아닌 경계(boundary)를 파일럿 테스트하세요

완료 조건이 명확하게 작성될 수 있는 하나의 다단계 작업 (multi-step task)으로 시작하세요. 해당 작업에 필요한 도구만을 부여하십시오. 증거가 누락되었을 때, 권한이 불충분할 때, 비용이나 토큰 사용에 대한 검토가 필요할 때, 또는 다음 동작이 실행 권한을 초과할 때 어떤 일이 발생할지 정의하십시오.

그런 다음 불편한 경로를 테스트하십시오: 사용자가 떠나고, 장치가 닫혔음에도 클라우드 런타임 (cloud runtime)은 계속 작동하는 상황입니다. 운영자가 추적 (traces)을 통해 결정을 재구성할 수 있습니까? 소스 데이터 (source data)를 식별할 수 있습니까? 사람의 에스컬레이션이 시급해지기 전에 중단 조건 (stop condition)이 작동합니까?

이것이 Google Gemini Spark의 실질적인 의미입니다. 지속적인 실행 (Persistent execution)은 가치 있을 수 있지만, 프로덕션 준비성 (production readiness)은 이를 둘러싼 제어 모델 (control model)에 달려 있습니다.

첫 번째 지속형 에이전트 (persistent-agent) 파일럿을 시작하기 전, 여러분은 어떤 제어를 요구하시겠습니까: 더 좁은 권한, 더 강력한 추적, 명시적인 중단 조건, 아니면 의무적인 사람의 검토입니까?

📖 가이드 전문 읽기 → Google Gemini Spark: The always-on agent runtime