AI 코딩 에이전트 이야기는 이제 “어느 모델이 코드를 더 잘 짜나”에서 조금 옮겨가고 있다. Google I/O 2026에서 나온 Gemini 3.5 Flash, Antigravity 2.0, Managed Agents, Android CLI 1.0을 한 묶음으로 보면 그 방향이 꽤 선명하다.
나는 처음엔 또 다른 모델 발표라고 생각했다. 숫자는 늘 그렇듯 멋있다. Terminal-Bench 2.1, MCP Atlas, 속도, 비용, 이런 것들. 그런데 이번 발표에서 더 눈에 들어온 건 모델 자체보다 모델이 놓이는 자리였다. 데스크톱 앱, CLI, SDK, 원격 Linux 환경, Android Studio 지식, Google AI Studio의 테스트 트랙 배포까지 한 줄로 이어지는 구조 말이다.
이전에 Google Antigravity 2가 데스크톱 에이전트 전략으로 보인 이유를 따로 썼는데, 하루 지나서 다시 보니 포인트가 조금 더 넓어졌다. Antigravity만의 문제가 아니다. Google은 “모델 하나 써보세요”가 아니라 “에이전트가 일하는 통로를 Google 생태계 안에 깔아두겠다”는 쪽으로 움직이고 있다.
AI 코딩 에이전트의 무게중심이 모델에서 실행면으로 옮겨갔다
빠른 모델보다 중요한 것은 어디서 실행되느냐다
Google의 공식 I/O 정리에서 Gemini 3.5 Flash는 “frontier intelligence with action” 쪽으로 설명된다. 말은 발표장스럽지만, 개발자 입장에서 번역하면 이렇다. 채팅창에서 답만 잘하는 모델이 아니라, 오래 걸리는 작업을 계획하고, 파일을 만들고, 도구를 호출하고, 상태를 이어받는 쪽에 맞춰졌다는 얘기다.
이 변화는 꽤 현실적이다. 요즘 AI 코딩 도구를 쓰다 보면 답변 품질만큼 답답한 게 실행 환경이다. 모델이 맞는 말을 해도 로컬 의존성을 못 읽으면 반쪽짜리다. 테스트를 돌릴 수 없으면 추측이다. 브라우저나 문서, 저장소, 배포 도구를 넘나들지 못하면 결국 사람이 중간 운반책이 된다.
그래서 이번 발표에서 내가 본 핵심은 Gemini 3.5 Flash 자체보다 주변 장치다. Antigravity 2.0은 데스크톱에서 여러 에이전트를 굴리는 표면을 맡고, Antigravity CLI는 터미널 사용자를 잡고, SDK는 제품 안에 에이전트를 심는 길을 연다. Managed Agents는 API 호출 한 번으로 격리된 Linux 환경을 열어준다. 이건 모델 발표라기보다 작업대 발표에 가깝다.
벤치마크는 출발점이지 운영 기준은 아니다
물론 숫자는 중요하다. Google은 Gemini 3.5 Flash가 Gemini 3.1 Pro보다 코딩과 에이전트 벤치마크에서 좋아졌고, 속도도 훨씬 빠르다고 말한다. 이런 개선은 실제로 체감될 수 있다. 에이전트 작업은 한 번 답하고 끝나는 게 아니라 수십 번의 파일 읽기, 수정, 테스트, 재시도를 반복하니까 지연 시간이 누적된다.
근데 운영에서 진짜로 중요한 건 다른 쪽이다. 에이전트가 실패했을 때 어디까지 되돌릴 수 있는가. 어떤 권한으로 실행되는가. 작업 로그와 diff를 어떻게 남기는가. 사람 리뷰를 어디서 끼워 넣는가. 모델이 네 번 빨라져도 이 부분이 흐리면 팀에서는 여전히 불안하다.
이번 I/O 발표가 흥미로운 건 Google이 이 질문을 피하지 않고 제품 표면으로 끌고 왔다는 점이다. 데스크톱, CLI, SDK, API, Android Studio, AI Studio를 연결하면 모델 성능 경쟁과 별개로 “에이전트 운영체제” 같은 그림이 생긴다. 아직 과장된 면도 있지만, 방향은 분명하다.
Managed Agents는 서버 없는 에이전트 실험실처럼 보인다
격리된 Linux 환경을 API로 여는 의미
Managed Agents는 이번 발표에서 가장 개발자 냄새가 나는 부분이었다. Gemini API에서 단일 호출로 에이전트를 띄우고, 그 에이전트가 격리된 Linux 환경에서 추론하고, 도구를 쓰고, 코드를 실행한다. 상태도 후속 호출에서 이어받을 수 있다고 한다.
이건 꽤 큰 차이다. 지금까지 많은 팀이 에이전트 기능을 만들 때 비슷한 문제를 반복해서 풀었다. 샌드박스는 어디에 둘지, 파일 시스템은 어떻게 격리할지, 장기 작업 상태는 어디에 저장할지, 브라우저나 패키지 설치 권한은 어떻게 막을지 같은 것들이다. 잘 만들면 강력하지만, 어설프게 만들면 보안 사고가 되기 쉽다.
Google이 이 레이어를 API 상품으로 밀면, 작은 팀은 훨씬 빨리 실험할 수 있다. 내부 도구에서 “이 이슈를 재현해봐”, “이 로그를 읽고 패치를 만들어봐”, “이 문서 기준으로 테스트 케이스를 추가해봐” 같은 흐름을 제품화하기 쉬워진다. 반대로 말하면, 에이전트 인프라를 직접 운영하던 회사들은 차별점을 더 분명히 보여줘야 한다.
그래도 신뢰 경계는 사라지지 않는다
여기서 조심할 부분도 있다. Managed라는 단어가 붙었다고 해서 신뢰 문제가 없어지는 건 아니다. 격리 환경이 있어도 입력 데이터, 비밀값, 외부 네트워크, 결과물 반영 권한은 여전히 설계해야 한다. 특히 에이전트가 코드를 실행하는 순간, 프롬프트 인젝션과 공급망 공격은 그냥 이론 문제가 아니다.
내가 팀에 적용한다면 처음부터 제품 코드 수정 권한을 주지는 않을 것 같다. 먼저 읽기 전용 분석, 테스트 생성, 문서 초안, 재현 스크립트 작성 같은 낮은 권한 작업부터 볼 것이다. 그다음 diff 생성, 그다음 제한된 브랜치에서 테스트 실행, 마지막으로 사람이 승인한 뒤 병합하는 식이 현실적이다.
이건 답답한 보수주의가 아니다. 에이전트가 빨라질수록 사고도 빨리 난다. 속도는 권한 설계와 같이 가야 한다.
Android CLI 1.0은 에이전트에게 Android Studio 지식을 내주는 장치다
“어떤 에이전트를 쓰든 Android 개발을 하게 하겠다”는 선언
Android CLI 1.0 안정화는 생각보다 상징적이다. Google은 이 도구가 Gemini in Android Studio, Antigravity, Claude Code, Codex 같은 여러 에이전트와 함께 쓰일 수 있다고 설명한다. 자기 모델만 쓰라는 얘기가 아니다. 어떤 에이전트를 쓰든 Android 개발에 필요한 지식과 작업 명령을 가져가게 하겠다는 쪽에 가깝다.
이건 꽤 영리하다. AI 코딩 에이전트 시장에서 모든 개발자를 한 IDE 안에 가두기는 어렵다. 이미 팀마다 Cursor, Claude Code, Codex, Copilot CLI, OpenCode, Windsurf 같은 취향이 갈라졌다. 그렇다면 플랫폼 사업자는 에이전트를 직접 통제하기보다, 에이전트가 플랫폼을 제대로 다루게 만드는 공식 통로를 제공하는 편이 낫다.
Android는 특히 이 통로가 중요하다. 앱 빌드, Gradle, 에뮬레이터, 권한, manifest, Compose, Play Console, 기기별 차이까지 문맥이 많다. 모델이 일반 웹앱처럼 대충 파일을 고쳐서 되는 영역이 아니다. Android CLI가 이 문맥을 줄여준다면, 에이전트가 “그럴듯한 코드”에서 “실제로 빌드되는 앱”으로 가는 거리가 짧아질 수 있다.
로컬 도구가 에이전트 친화적으로 바뀌는 흐름
이 흐름은 Android만의 얘기가 아닐 가능성이 크다. 앞으로 좋은 개발 도구는 사람만 쓰기 쉬운 도구가 아니라 에이전트도 쓰기 쉬운 도구가 될 것이다. 출력은 구조화되고, 에러는 기계가 해석하기 쉬워지고, dry-run과 rollback은 기본이 되고, 권한은 더 잘게 쪼개질 것이다.
예를 들면 이런 식이다.
android studio inspect --project . --format json
android studio run-journey --target emulator --report ./agent-report.json
android studio explain-failure --last-build --for-agent
위 명령이 실제 사용법이라는 뜻은 아니다. 내가 기대하는 방향이 그렇다는 얘기다. 사람에게 예쁜 로그보다 에이전트가 안정적으로 읽을 수 있는 로그가 더 중요해지는 순간이 온다. CLI는 단순히 터미널 사용자용 UI가 아니라, 에이전트와 플랫폼 사이의 계약서가 된다.
개발팀이 바로 확인할 지점
도구 선택보다 작업 경계를 먼저 정해야 한다
이번 발표를 보고 바로 “그럼 Antigravity로 갈아타야 하나”라고 묻는 건 조금 이르다. 도구는 계속 바뀐다. 오늘은 Gemini 3.5 Flash가 뜨겁고, 내일은 Copilot CLI의 원격 제어가 더 편해 보일 수 있고, 다음 주에는 Claude Code나 Codex 쪽에서 또 다른 흐름이 나올 수 있다.
내가 먼저 보려는 건 작업 경계다. 우리 팀에서 에이전트에게 맡겨도 되는 작업은 무엇인가. 테스트 실패 재현인가, 문서 업데이트인가, UI 스냅샷 확인인가, 의존성 업데이트인가, 아니면 작은 버그 수정까지인가. 이 경계를 정하지 않으면 새 도구를 도입해도 매번 같은 논쟁으로 돌아온다.
특히 장기 실행 작업은 따로 봐야 한다. GitHub Copilot CLI도 원격 제어를 강조하고 있고, Google은 Antigravity와 Managed Agents로 비슷한 방향을 잡았다. 개발자가 자리를 비운 동안 에이전트가 계속 일하는 구조는 매력적이다. 하지만 그만큼 체크포인트, 로그, 승인 지점, 중단 버튼이 중요해진다.
“생산성”보다 “검증 가능성”이 오래 간다
AI 코딩 도구 발표는 보통 생산성 문장으로 포장된다. 며칠 걸릴 일을 몇 시간에, 몇 시간 걸릴 일을 몇 분에. 맞는 말일 수 있다. 그런데 개발팀에서 오래 살아남는 도구는 결국 검증 가능한 도구다.
에이전트가 어떤 파일을 읽었는지, 왜 그 결정을 했는지, 어떤 테스트를 돌렸는지, 실패를 어떻게 처리했는지, 어느 권한으로 외부에 접근했는지 남겨야 한다. 이 기록이 없으면 속도는 잠깐의 기분으로 끝난다. 장애가 한 번 나면 조직은 바로 브레이크를 밟는다.
그래서 Gemini 3.5 Flash 이후의 경쟁은 모델 점수만으로 끝나지 않을 것 같다. 누가 더 좋은 실행 환경을 만들고, 누가 더 나은 권한 모델을 주고, 누가 리뷰와 배포 사이에 자연스럽게 들어오느냐가 더 중요해진다. 이번 Google 발표는 그 경쟁이 이미 시작됐다는 신호에 가깝다.
마치며
이번 Google I/O 2026에서 내가 제일 크게 느낀 건 “AI 코딩 에이전트가 제품 기능에서 개발 인프라로 내려오고 있다”는 점이다. 예전에는 에디터 옆 채팅창이 중심이었다. 이제는 CLI, SDK, API 샌드박스, Android Studio, AI Studio, Play Console까지 연결된다.
물론 아직은 발표 직후라 실제 손맛을 더 봐야 한다. Managed Agents가 얼마나 안정적인지, Antigravity CLI가 기존 도구보다 얼마나 덜 거슬리는지, Android CLI가 진짜로 에이전트 삽질을 줄이는지는 별도 검증이 필요하다. 이름만 멋지고 현장에서는 귀찮은 도구로 끝날 수도 있다.
그래도 방향은 무시하기 어렵다. 앞으로 팀에서 AI 코딩 에이전트를 고를 때는 “어느 모델이 더 똑똑한가”만 묻기 어렵다. “어디서 실행되는가”, “무슨 권한을 갖는가”, “어떻게 멈추는가”, “무엇을 증거로 남기는가”를 같이 봐야 한다. 이번 발표가 그 질문을 꽤 크게 밀어 올렸다.