개발자가 Google I/O 2026에서 봐야 할 핵심은 모델 이름이 하나 더 늘었다는 사실이 아닙니다. 더 중요한 변화는 개발 워크플로우의 기본 단위가 프롬프트에서 에이전트 실행 환경으로 이동하고 있다는 점입니다.
Google은 2026년 5월 19일 I/O 개발자 키노트에서 Gemini 3.5 Flash, Antigravity 2.0, Antigravity CLI, Gemini API Managed Agents, Google AI Studio의 Android·Workspace·Cloud Run 통합을 발표했습니다. 공식 발표에 따르면 Gemini 3.5 Flash는 Gemini 3.1 Pro를 대부분의 벤치마크에서 앞서고, 다른 frontier 모델보다 4배 빠르게 동작한다고 설명됐습니다. 이 수치는 Google 공개 자료 기준이며, 실제 제품 성능은 입력 길이, 도구 호출, 네트워크, 샌드박스 작업에 따라 달라집니다.
그래도 방향은 분명합니다. 앞으로 개발자는 모델에게 답을 묻는 사람이 아니라, 여러 에이전트가 파일을 만들고, 도구를 호출하고, 배포 전 검증까지 수행하는 흐름을 설계하는 사람이 됩니다. 따라서 이번 발표는 “어떤 모델이 더 똑똑한가”보다 “에이전트가 일하는 경계를 어떻게 정할 것인가”로 읽어야 합니다.
기존 AI 코딩 도구는 대부분 편집기 안에서 제안하는 방식이었습니다. 자동완성, 함수 생성, 테스트 초안 작성처럼 개발자가 즉시 확인하고 붙여 넣는 흐름이었습니다. 이때의 리스크는 비교적 작습니다. 개발자가 결과를 보고 수동으로 적용하기 때문입니다.
하지만 Antigravity 2.0과 Managed Agents가 겨냥하는 영역은 다릅니다. 공식 발표는 Antigravity가 여러 에이전트를 병렬로 실행하고, 동적 하위 에이전트를 만들고, 예약 작업과 백그라운드 자동화를 지원한다고 설명합니다. Gemini API Managed Agents는 단일 API 호출로 도구 사용과 코드 실행이 가능한 격리 Linux 환경을 provision한다고 소개됐습니다.
이 구조에서는 에이전트가 단순히 코드를 제안하지 않습니다. 저장소를 읽고, 파일을 만들고, 도구를 실행하고, 세션 상태를 유지합니다. 개발팀 입장에서는 IDE 보조 기능이 아니라 작은 CI/CD·작업자 시스템을 하나 더 운영하는 것과 비슷합니다.
따라서 도입 질문도 바뀌어야 합니다. “에이전트가 코드를 잘 짜는가?”보다 “에이전트가 어떤 파일에 접근하고, 어떤 명령을 실행하고, 실패하면 어디서 멈추는가?”를 먼저 물어야 합니다.
Google은 Antigravity 2.0을 agent-first development platform으로 설명합니다. 새 데스크톱 앱은 여러 에이전트를 병렬로 오케스트레이션하고, dynamic subagents로 복잡한 작업을 나누며, Google AI Studio, Android, Firebase와 연결됩니다. 터미널을 선호하는 개발자를 위해 Antigravity CLI도 함께 발표됐고, Gemini CLI 사용자는 Antigravity CLI로 이전하라는 안내도 포함됐습니다.
실무에서 이 변화는 세 가지 의미가 있습니다.
첫째, 작업 분해가 중요해집니다. “프로젝트 전체를 개선해줘” 같은 요청은 여전히 위험합니다. 대신 UI 회귀 확인, 테스트 보강, 문서 업데이트, 릴리즈 노트 초안처럼 입력과 출력이 좁은 작업으로 나누는 팀이 더 좋은 결과를 얻을 가능성이 큽니다.
둘째, 에이전트별 권한을 다르게 줘야 합니다. 테스트 에이전트는 명령 실행 권한이 필요할 수 있지만, 문서 정리 에이전트는 쓰기 범위가 제한되어야 합니다. Firebase 설정을 다루는 에이전트는 보안 규칙과 프로젝트 권한을 읽어야 하므로 별도 검토가 필요합니다.
셋째, 세션 로그와 산출물 비교가 필수입니다. 병렬 에이전트가 많아질수록 결과만 보고 판단하기 어렵습니다. 누가 어떤 파일을 바꿨는지, 어떤 도구 호출이 실패했는지, 어떤 가정을 했는지 남겨야 재현과 롤백이 가능합니다.
Gemini API Managed Agents는 개발자에게 매력적인 제안입니다. 공식 발표에 따르면 단일 API 호출로 reasoning, tool use, code execution을 수행하는 agent를 만들 수 있고, 격리된 Linux sandbox에서 파일과 상태를 관리할 수 있습니다. 후속 호출에서 같은 환경을 이어받아 멀티턴 작업을 계속할 수도 있습니다.
이 기능은 프로토타입 속도를 크게 높일 수 있습니다. 예를 들어 데이터 변환, 문서 생성, 테스트 케이스 생성, 간단한 리서치 자동화처럼 파일 상태가 필요한 작업을 직접 샌드박스 인프라 없이 구성할 수 있습니다.
하지만 추상화가 높아질수록 운영 질문은 더 명확해야 합니다.
Managed라는 말은 운영 책임이 사라진다는 뜻이 아닙니다. 샌드박스 생성, 코드 실행, 상태 유지가 쉬워졌다는 뜻입니다. 제품에 붙이려면 여전히 권한, 감사, 비용, 실패 처리를 설계해야 합니다.
이번 발표에서 Google AI Studio는 단순 모델 Playground에서 앱 제작 표면으로 더 이동했습니다. 공식 발표는 Android 앱을 Kotlin 기반으로 생성하는 흐름, Google Workspace API 연결, Cloud Run 원클릭 배포, Firebase 서비스 지원, Antigravity로 프로젝트 상태를 내보내는 기능을 설명합니다.
이 흐름은 비개발자에게도 매력적이지만, 실무 개발자에게는 다른 의미가 있습니다. 초기 프로토타입과 운영 코드의 경계가 더 흐려집니다. AI Studio에서 만든 앱이 Cloud Run으로 배포되고 Firebase를 연결하며 Antigravity로 이어진다면, 팀은 “초안 앱”을 어떻게 검토하고 제품 저장소로 편입할지 정해야 합니다.
특히 Workspace 데이터 연결은 민감합니다. Gmail, Docs, Sheets 같은 업무 데이터에 접근하는 앱은 편리하지만, OAuth scope, 데이터 저장 위치, 사용자 동의, 로그 보관 기준이 필요합니다. 빠른 프로토타입일수록 보안 검토를 건너뛰기 쉽습니다. 이 지점이 실제 사고로 이어질 수 있습니다.
이번 Google I/O 2026 발표를 바로 실무에 반영하려면 큰 플랫폼 전환보다 작은 운영 기준부터 잡는 편이 낫습니다. 추천 방식은 2주 파일럿입니다.
첫 번째 주에는 에이전트가 수행할 작업을 좁힙니다. 예를 들어 “프론트엔드 PR에서 접근성 체크리스트 생성”, “테스트 실패 로그 요약”, “릴리즈 노트 초안 작성”처럼 사람이 쉽게 검토할 수 있는 작업을 고릅니다.
두 번째 주에는 결과 지표를 봅니다. 작업 완료 시간, 사람이 수정한 비율, 실패 원인, 잘못된 파일 접근, 재실행 횟수를 기록합니다. 모델 점수보다 운영 지표가 중요합니다. 에이전트가 한 번 멋진 결과를 냈는지보다 반복 가능한지 봐야 합니다.
또한 모든 에이전트 작업에는 최소한 세 가지 제한이 필요합니다. 읽기 범위, 쓰기 범위, 실행 범위입니다. 이 세 가지가 문서화되지 않으면 에이전트는 팀이 통제할 수 없는 자동화가 됩니다.
Google I/O 2026의 에이전트 개발 흐름을 검토한다면 다음 순서로 시작하세요.
이번 발표의 핵심은 더 빠른 코딩이 아닙니다. 개발 워크플로우 자체가 agent-run, sandbox-run, tool-run 방식으로 재구성되고 있다는 점입니다. 우리 팀이 먼저 정해야 할 질문은 단순합니다. 에이전트에게 맡길 수 있는 가장 작은 반복 작업은 무엇이고, 어디서 반드시 사람이 멈춰 세워야 하나요?
출처: Google Developers Blog, “All the news from the Google I/O 2026 Developer keynote”, 2026-05-19. Google Blog, “Building the agentic future: Developer highlights from I/O 2026”, 2026-05-19.
