Google I/O 2026 개발자 키노트에서 눈에 띄는 방향은 모델 발표보다 개발 환경의 에이전트화입니다. Gemini 3.5 계열, Antigravity 2.0, Managed Agents, Android CLI, WebMCP, Chrome DevTools for agents가 한꺼번에 소개됐지만, 실무자가 봐야 할 질문은 하나입니다. 이제 AI 코딩 도구가 어디까지 직접 실행하고 검증할 수 있는가입니다.
구글은 ‘도와주는 AI’에서 ‘복잡한 업무를 독립적으로 탐색하는 에이전트’로 이동한다고 설명했습니다. 이 말은 마케팅 문구처럼 들릴 수 있지만, 발표된 구성 요소를 뜯어보면 실제 개발 프로세스 변화가 보입니다. 에이전트가 터미널에서 코드를 고치는 수준을 넘어 Android Studio 기능, Chrome DevTools, 브라우저 내부 도구, 원격 sandbox, 웹 표준 형태의 tool interface까지 연결되는 흐름입니다.
어제 다룬 Antigravity CLI 자체와 중복되지 않게 보면, 이번 포인트는 특정 IDE가 아니라 에이전트가 사용할 수 있는 표준화된 작업 표면입니다. 개발팀은 앞으로 ‘어떤 모델을 쓸까’와 함께 ‘우리 앱의 어떤 작업을 에이전트가 안전하게 실행하게 할까’를 설계해야 합니다.
첫째, Managed Agents in Gemini API입니다. 구글 설명에 따르면 단일 API 호출로 remote sandbox가 포함된 agent를 프로비저닝할 수 있습니다. 이건 개발팀에게 꽤 큰 변화입니다. 지금까지 에이전트를 운영하려면 실행 환경, 권한, 파일 시스템, credential 관리, 로그 수집을 직접 붙여야 했습니다. 관리형 agent가 안정화되면 PoC 단계에서 infrastructure glue code가 줄어듭니다.
둘째, Android CLI와 Android skills입니다. AI 에이전트가 Android SDK 다운로드, 디바이스 실행, 마이그레이션 같은 Android Studio의 heavy lifting을 터미널에서 호출할 수 있게 하는 방향입니다. React Native, 웹 프레임워크, iOS 코드에서 native Kotlin 앱으로 옮기는 Migration agent도 preview로 언급됐습니다. ‘몇 주 걸리던 마이그레이션을 몇 시간으로 줄인다’는 표현은 검증이 필요하지만, Android 팀이 에이전트 전용 CLI와 benchmark를 내놓았다는 점은 큽니다.
셋째, WebMCP입니다. Chrome 149 origin trial로 언급된 WebMCP는 브라우저 기반 AI 에이전트가 JavaScript 함수나 HTML form 같은 구조화된 도구를 실행할 수 있게 하려는 제안입니다. 이것이 중요한 이유는 웹앱이 AI 에이전트에게 버튼과 DOM만 던지는 것이 아니라, 의도와 제약이 있는 tool surface를 제공할 수 있기 때문입니다.
오늘날 브라우저 자동화 에이전트는 대개 화면을 읽고 클릭합니다. 이 방식은 데모에는 좋지만 운영에는 약합니다. 버튼 텍스트가 바뀌거나 레이아웃이 달라지면 실패하고, 어떤 action이 안전한지 모델이 추론해야 합니다. WebMCP 방향은 이 문제를 줄이려는 시도입니다.
웹앱이 ‘주문 취소’, ‘송장 생성’, ‘검색 실행’ 같은 기능을 구조화된 tool로 노출하면 에이전트는 DOM을 헤매지 않고 명시적 함수를 호출할 수 있습니다. 개발자 입장에서는 API와 UI 사이에 에이전트용 계약을 하나 더 두는 셈입니다.
다만 무조건 열면 위험합니다. WebMCP 류의 구조에서는 권한 모델이 핵심입니다. 읽기 전용 도구, 임시 실행 도구, 비용이 발생하는 도구, 데이터 삭제 도구를 나눠야 합니다. 사용자 확인이 필요한 작업은 tool schema에도 명시해야 합니다. 에이전트가 할 수 있는 일을 늘릴수록 audit log와 rollback 설계가 더 중요해집니다.
모바일 개발에서 에이전트가 어려운 이유는 코드 수정만으로 끝나지 않기 때문입니다. SDK 버전, Gradle 설정, emulator, device permission, 빌드 캐시, platform-specific API가 모두 얽힙니다. 그래서 AI가 Kotlin 파일 하나를 잘 고쳐도 빌드와 실행 검증에서 막히는 경우가 많습니다.
Android CLI는 이 지점을 겨냥합니다. 에이전트가 Android Studio의 기능을 CLI로 호출할 수 있으면, ‘코드 수정 → 빌드 → 디바이스 실행 → 로그 확인 → 재수정’ 루프가 더 자동화됩니다. 여기에 Android skills가 붙으면 Jetpack Compose migration, Navigation 3 migration 같은 복잡한 워크플로우를 모델에게 절차로 제공할 수 있습니다.
팀에서 바로 적용한다면 모든 앱을 에이전트에게 맡기기보다 반복적이고 실패 기준이 명확한 작업부터 잡는 게 좋습니다. 예를 들어 deprecated API 교체, compileSdk 업데이트, Compose preview 오류 수정, lint warning 정리, navigation graph migration처럼 테스트와 diff 검토가 가능한 작업입니다.
Chrome DevTools for agents는 웹 개발에서 더 직접적인 변화를 줍니다. 에이전트가 브라우저에서 실제 페이지를 열고, 성능과 접근성 문제를 확인하고, 네트워크 오류와 콘솔 로그를 보며 수정할 수 있다면 프론트엔드 작업의 검증 단계가 달라집니다.
기존 AI 코딩의 약점은 ‘코드는 그럴듯하지만 실제 UI가 깨지는’ 문제였습니다. DevTools 연결이 안정화되면 에이전트는 Lighthouse류의 지표, console error, hydration mismatch, network waterfall, viewport별 렌더링을 근거로 수정할 수 있습니다. 개발자는 결과 diff만 보는 것이 아니라, 에이전트가 어떤 화면에서 무엇을 확인했는지 artifact를 봐야 합니다.
구글이 언급한 Modern Web Guidance도 같은 맥락입니다. 100개 이상 use case와 Baseline target을 연결해 에이전트에게 성능, 접근성, 보안 가이드를 제공하는 방식입니다. 사람이 매번 ‘접근성도 봐줘’라고 말하는 대신, 프로젝트 기준을 skill이나 guidance로 설치해 두는 구조가 됩니다.
첫째, 에이전트 권한 범위입니다. 로컬 파일 수정, 테스트 실행, 브라우저 조작, 클라우드 리소스 접근, 배포까지 한 번에 열면 사고가 납니다. 초기에는 read-only 진단과 PR 생성까지만 허용하는 편이 안전합니다.
둘째, 검증 기준입니다. 에이전트가 성공했다고 말하는 것과 제품이 성공한 것은 다릅니다. Android라면 빌드, unit test, instrumentation test, emulator smoke test를 기준으로 잡아야 합니다. 웹이라면 typecheck, test, Lighthouse 핵심 항목, 주요 route 스크린샷이 필요합니다.
셋째, artifact 저장입니다. 구글이 Antigravity에서 screenshot과 recording artifact를 강조한 이유도 여기에 있습니다. 에이전트 작업은 결과 코드만 보면 의사결정 근거가 사라집니다. 어떤 로그를 봤고, 어떤 화면을 확인했고, 어떤 실패를 회피했는지 남아야 리뷰가 됩니다.
넷째, tool contract입니다. WebMCP든 MCP든 내부 도구든, 함수 이름과 인자만 던져서는 부족합니다. idempotency, side effect, required confirmation, rate limit, permission scope를 schema에 담아야 합니다.
Google I/O 2026 발표의 실전 메시지는 분명합니다. AI 개발 도구 경쟁은 모델 성능만으로 끝나지 않습니다. 에이전트가 안전하게 만질 수 있는 도구 표면, 검증 루프, 권한 설계가 개발 생산성의 차이를 만들기 시작했습니다.
