Google I/O 2026 Gemini 발표 정리: Antigravity 2.0, 개발자는 갈아타야 할까

Google I/O 2026에서 중요한 변화는 Gemini가 단순한 챗봇에서 실행형 에이전트로 이동했다는 점입니다. 특히 Antigravity 2.0과 Gemini 3.5 Flash는 Claude Code나 Codex 중심으로 굳어진 개발 워크플로를 다시 점검하게 만드는 발표였습니다.

한 줄로 정리하면 이렇습니다. 지금 당장 전면 전환할 필요는 없지만, 반복 수정·테스트·문서화처럼 실패 비용이 낮고 실행 횟수가 많은 작업은 Antigravity 2.0과 Gemini 3.5 Flash로 비교 테스트해 볼 만합니다. 이번 발표의 핵심은 “모델이 더 똑똑해졌다”가 아니라 “AI가 답변을 넘어 일을 끝까지 수행하려 한다”입니다.

 

핵심 판단: 갈아탈지 말지를 먼저 정하지 말고, 반복 수정·테스트·문서화 같은 낮은 위험 작업에서 기존 도구와 결과물을 나란히 비교해 보세요.

 

코드 편집기와 테스트 결과를 놓고 여러 AI 코딩 에이전트 워크플로를 비교하는 개발자 작업 화면

 

이번 I/O의 키워드는 모델보다 에이전트다

Google은 I/O 2026 개발자 발표에서 Gemini 3.5 Flash, Antigravity 2.0, Gemini API의 Managed Agents, AI Studio의 Android 개발 흐름을 함께 묶어 소개했습니다. 따로 보면 제품 이름이 많아 보이지만, 한 방향으로 보면 메시지는 간단합니다. 프롬프트에 답하는 AI에서, 여러 단계를 계획하고 실행하는 AI로 무게중심이 이동하고 있습니다.

개발자에게 중요한 질문도 바뀝니다. “코드를 잘 짜나?”만으로는 부족합니다. 이제는 파일을 고치고, 도구를 호출하고, 테스트를 돌리고, 실패 원인을 설명하고, 다시 수정하는 전체 루프가 얼마나 덜 끊기는지를 봐야 합니다.

실제로 개발자가 체감하는 병목은 이런 곳에서 생깁니다.

• 에이전트가 변경한 파일을 사람이 다시 검증해야 한다.
• 긴 작업을 맡겼더니 컨텍스트가 흐려져 엉뚱한 방향으로 간다.
• 테스트를 돌렸는지, 실패를 어떻게 해석했는지 믿기 어렵다.
• 빠른 모델은 싸지만 깊은 설계가 약하고, 강한 모델은 비용이 부담된다.
• 로컬 도구와 클라우드 에이전트 사이에서 속도와 신뢰성의 균형이 흔들린다.

 

이 문제를 더 깊게 보려면 기존에 정리한 AI 코딩 에이전트와 Cloud Agent의 병목 흐름과 같이 읽으면 좋습니다. 이번 Google 발표도 결국 “모델이 코드를 쓰는가”보다 “그 작업을 끝까지 책임질 수 있는가”라는 질문으로 이어집니다.

 

 

AI 코딩 에이전트가 요청, 코드 변경, 테스트, 실패 복구, 사람 검토로 이어지는 과정을 보여 주는 다이어그램

 

Antigravity 2.0은 전환 대상이 아니라 실험 대상이다

Antigravity 2.0을 기존 AI 코딩 도구의 대체품으로만 보면 판단이 흐려집니다. Google이 노리는 것은 데스크톱 앱, CLI, SDK, Gemini API, AI Studio가 같은 에이전트 흐름을 공유하는 구조에 가깝습니다. 개발자가 터미널에서 시작한 일을 앱이나 API 흐름으로 확장하고, 제품 실험을 다시 코드 작업으로 끌고 오는 그림입니다.

잘 맞으면 장점은 큽니다. 작은 버그 수정, 반복적인 리팩터링, 테스트 보강, 문서 업데이트처럼 시간이 많이 들지만 판단 난도가 비교적 낮은 작업을 빠른 모델에 맡길 수 있습니다. 반대로 아키텍처 변경, 보안 설계, 장애 원인 분석처럼 실수 비용이 큰 작업은 더 강한 모델이나 사람의 검토를 끼워 넣어야 합니다.

그래서 Antigravity 2.0을 볼 때는 “Claude Code보다 낫나?”라고만 묻기보다 아래 기준으로 봐야 합니다.

 

판단 기준	확인해야 할 질문
반복 실행 비용	같은 수정/테스트 루프를 여러 번 돌려도 비용 부담이 낮은가
검증 흐름	변경 후 테스트, 린트, 타입 체크 결과를 스스로 설명하는가
컨텍스트 유지	긴 작업에서 원래 목표와 제약을 잃지 않는가
도구 연결	CLI, IDE, 브라우저, API 작업 사이 이동이 자연스러운가
실패 복구	엉뚱한 변경을 했을 때 되돌리기와 원인 파악이 쉬운가

 

이 표에서 세 항목 이상이 만족되지 않으면, 모델 성능이 좋아 보여도 실제 개발 워크플로에서는 금방 피로해집니다. AI 코딩 도구는 “처음 5분의 감탄”보다 “세 번째 실패를 어떻게 회복하는가”에서 실력이 드러납니다.

 

 

 

Gemini 3.5 Flash의 포인트는 싸게 많이 돌리는 능력이다

인터뷰에서 가장 눈에 띄는 대목은 Josh Woodward가 Gemini 3.5 Flash를 설명할 때 성능만이 아니라 비용을 강하게 언급했다는 점입니다. 에이전트 작업은 한 번의 완벽한 답변보다 여러 번의 계획, 실행, 실패, 수정, 재시도에 가깝습니다. 그래서 코딩 모델의 경제성은 생각보다 빨리 실제 생산성 문제로 바뀝니다.

빠르고 저렴한 모델이 충분히 좋아지면, 사람이 직접 하기 귀찮은 작은 루프를 모델에게 더 많이 맡길 수 있습니다.

• 테스트 실패 로그를 읽고 원인 후보를 정리한다.
• 같은 패턴의 타입 오류를 여러 파일에 걸쳐 수정한다.
• PR 설명, 변경 요약, 릴리스 노트를 초안으로 만든다.
• 코드베이스의 특정 규칙 위반을 찾아 후보 diff를 만든다.
• 간단한 마이그레이션을 여러 번 나눠 실행한다.

 

하지만 처음부터 Flash에 모든 설계 판단을 맡기는 것은 위험합니다. 인터뷰에서 언급된 것처럼 Google 내부에서도 빠른 모델과 강한 모델을 오가며 쓴다는 점이 더 현실적인 힌트입니다. 큰 방향과 위험 분석은 더 강한 모델이나 사람의 리뷰로 잡고, 반복 실행은 빠른 모델에 맡기는 방식이 안전합니다.

이전의 Gemini CLI 흐름을 써 본 사람이라면 Gemini CLI로 AI 코딩 자동화 시작하는 방법에서 다뤘던 터미널 기반 자동화 감각을 떠올리면 됩니다. 다만 Antigravity 2.0 이후의 관전 포인트는 “CLI가 된다”가 아니라 “CLI, 앱, API가 같은 에이전트 실행 구조로 얼마나 이어지는가”입니다.

 

 

데모가 잘 돌아가도 내 저장소에서는 다르게 실패한다

AI 코딩 도구를 바꿀 때 가장 흔한 실수는 데모 장면을 실제 업무 안정성으로 착각하는 것입니다. I/O 무대에서 멋지게 돌아간 워크플로가 내 저장소, 내 테스트 환경, 내 배포 규칙에서도 그대로 통한다는 보장은 없습니다.

특히 다음 작업은 새 도구에 바로 맡기기 어렵습니다.

• 결제, 인증, 권한, 개인정보가 엮인 코드
• 테스트가 부족한 오래된 레거시 코드
• 변경 범위가 넓고 롤백 비용이 큰 리팩터링
• 도메인 지식이 강하게 필요한 비즈니스 로직
• “대충 돌아가면 되는” 기준이 없는 데이터 처리 작업

 

이런 작업에서 에이전트가 틀리면 비용은 두 배가 됩니다. 코드도 고쳐야 하고, AI가 왜 틀렸는지도 추적해야 합니다. Antigravity 2.0을 처음 쓴다면 새 프로젝트나 작은 모듈, 테스트가 잘 갖춰진 저장소, 문서화가 쉬운 반복 작업부터 시작하는 편이 좋습니다.

 

 

Gemini Spark는 일반 사용자에게 더 큰 변화일 수 있다

개발자 발표 못지않게 중요한 것은 Gemini 앱의 변화입니다. Google은 Gemini 앱 발표에서 Gemini 앱 사용자가 지난 I/O 당시 4억 명 수준에서 현재 월 9억 명 이상으로 늘었다고 밝혔고, Gemini Spark를 개인 AI 에이전트 흐름으로 소개했습니다.

Spark의 핵심은 사용자가 일을 맡기고 나중에 돌아오는 방식입니다. 지금까지 챗봇은 대체로 사용자가 대화창 앞에 붙어 있어야 했습니다. 질문하고, 답을 받고, 다시 지시하고, 중간 결과를 확인해야 했습니다. Spark가 목표로 하는 방향은 다릅니다. 사용자가 작업을 던져 놓으면 백그라운드에서 진행하고, 사용자는 필요한 시점에 결과를 확인합니다.

이 변화는 작아 보이지만 실제로는 큽니다. AI가 “검색을 빨리 해 주는 도구”에서 “내 대신 디지털 일을 굴리는 도구”로 넘어가는 순간이기 때문입니다. 다만 개인 메일, 문서, 일정, 결제 정보와 연결될수록 권한 관리와 결과 확인 책임도 커집니다.

처음부터 민감한 일을 맡기기보다, 실패해도 손실이 작고 결과 확인이 쉬운 일부터 시작하는 편이 좋습니다.

• 여러 문서를 읽고 회의 준비 요약 만들기
• 반복 구독료나 비용 항목 후보 찾기
• 여행, 행사, 발표 자료의 체크리스트 만들기
• 긴 메일 스레드에서 결정 사항만 뽑기
• 블로그 글감 조사와 초안 구조 잡기

 

 

Google Labs 제품은 반복 생산을 겨냥한다

NotebookLM, Stitch, Flow, Pomelli 같은 Google Labs 제품은 따로 보면 실험적인 도구 모음처럼 보입니다. 하지만 묶어서 보면 방향이 보입니다. 사용자가 자료를 모으고, 인터페이스를 설계하고, 이미지·영상·음악을 만들고, 브랜드 자산을 반복 생산하는 과정을 AI가 더 많이 떠안는 흐름입니다.

특히 Pomelli는 웹사이트나 콘텐츠에서 폰트, 색, 스타일 같은 “비즈니스 DNA”를 뽑아 마케팅 자산으로 확장한다는 설명이 나왔습니다. 블로거나 1인 사업자에게는 꽤 현실적인 문제입니다. 글 하나를 쓰는 것보다 어려운 것은 일관된 썸네일, SNS 문구, 소개 페이지, 상품 설명, 이메일 문안을 계속 같은 톤으로 만드는 일이기 때문입니다.

다만 이 영역은 아직 실험 제품의 색이 강합니다. 당장 모든 마케팅을 자동화한다기보다, 반복 산출물의 초안을 빠르게 만들고 사람이 톤과 사실관계를 조정하는 보조 도구로 보는 편이 안전합니다.

 

 

Google의 강점은 풀스택이지만, 승자독식은 아직 이르다

Josh는 AI 시장이 승자독식으로 갈지에 대해 조심스럽게 답했습니다. 여러 대안이 공존할 가능성이 크다는 쪽에 가까웠습니다. 이 답은 현실적입니다. AI 도구는 검색, 코딩, 문서, 이미지, 영상, 교육, 업무 자동화처럼 사용 맥락이 너무 다릅니다. 한 제품이 모든 상황에서 항상 이기기는 어렵습니다.

Google의 강점은 풀스택입니다. TPU와 클라우드 인프라, 모델 연구, Gemini 앱, Search, Workspace, Android, AI Studio, Antigravity를 한 회사 안에서 연결할 수 있습니다. 이 구조는 잘 맞아떨어지면 강력합니다. 사용자의 작업 맥락을 여러 표면에서 이어 받을 수 있기 때문입니다.

하지만 풀스택이 곧 자동 승리를 뜻하지는 않습니다. 오히려 제품이 많을수록 사용자는 헷갈리기 쉽습니다. Gemini, AI Studio, Antigravity, NotebookLM, Flow, Stitch, Spark가 각각 어디에 쓰이는지 분명하지 않으면 장점이 복잡함으로 바뀝니다.

Google의 실제 승부처는 발표 수가 아니라 연결의 선명도입니다. 사용자가 “이 일은 Gemini 앱, 이 일은 NotebookLM, 이 일은 Antigravity”라고 자연스럽게 나눌 수 있어야 합니다.

 

 

오픈소스 모델과 Gemini는 같은 질문에 답하지 않는다

중국과 글로벌 오픈소스 모델의 성장도 무시할 수 없습니다. 인터뷰에서도 “Google과 OpenAI에 해자가 없다”는 과거 내부 메모가 언급됐습니다. 이 질문은 여전히 유효합니다. 오픈소스 모델이 빨리 좋아지면 폐쇄형 프런티어 모델의 차별점은 줄어듭니다.

다만 실전에서는 둘을 단순 승패로 보기 어렵습니다. 오픈소스 모델은 로컬 실행, 온디바이스 처리, 커스터마이징, 데이터 통제 측면에서 강점이 있습니다. 반면 Gemini 같은 대형 상용 모델은 최신 멀티모달 기능, 구글 제품과의 연결, 대규모 인프라, 에이전트 실행 환경에서 강점을 만들 수 있습니다.

선택 기준은 “무엇이 더 똑똑한가”보다 “내 작업의 제약이 무엇인가”입니다.

• 회사 내부 코드와 민감 데이터가 핵심이면 로컬/오픈 모델 실험 가치가 커집니다.
• Google Workspace, Search, Android, AI Studio와 연결된 업무라면 Gemini 쪽 마찰이 작을 수 있습니다.
• 비용 예측과 대량 반복이 중요하면 Flash 같은 빠른 모델의 경제성이 중요합니다.
• 최신 이미지·영상·음악 생성과 결합하려면 Google Labs 생태계가 더 유리할 수 있습니다.

 

 

지금 해볼 만한 테스트

이번 발표를 보고 가장 실용적인 행동은 하나입니다. 한 번에 도구를 바꾸지 말고, 작은 실험 세트를 만들어 비교하는 것입니다.

개발자라면 다음 5개 작업을 같은 저장소에서 Claude Code, Codex, Antigravity 2.0에 각각 맡겨 보세요.

1. 실패하는 테스트 하나를 고치기
2. 작은 리팩터링 후 타입 체크 통과시키기
3. README의 오래된 설치 방법 업데이트하기
4. 새 API 응답 필드에 맞춰 타입과 테스트 수정하기
5. PR 설명과 변경 위험 요약 만들기

 

비교할 때는 답변이 멋진지보다 결과물을 보세요. diff가 작고 읽기 쉬운가, 테스트를 직접 확인했는가, 모르는 부분을 추측하지 않았는가, 실패했을 때 다음 행동을 제안하는가가 더 중요합니다.

일반 사용자라면 Gemini Spark나 NotebookLM 계열 기능을 다음 작업부터 실험하는 것이 좋습니다.

1. 긴 문서 3개를 읽고 의사결정 요약 만들기
2. 메일이나 회의록에서 할 일만 뽑기
3. 블로그 글감 조사와 제목 후보 만들기
4. 여행/구매/학습 계획을 체크리스트로 바꾸기
5. 이미지나 영상 아이디어를 초안으로 만들기

 

AI 시대에 중요한 역량은 특정 도구 하나를 믿는 게 아닙니다. 여러 도구를 직접 써 보고, 내 업무에서 어디까지 맡길 수 있는지 경계를 그리는 능력입니다. 이번 Google I/O의 메시지도 결국 그쪽에 가깝습니다. AI는 점점 더 많은 일을 할 수 있게 되지만, 어떤 일을 맡길지 결정하는 기준은 여전히 사용자가 가져야 합니다.

 

 

FAQ

 

Antigravity 2.0으로 바로 갈아타야 할까요?

아직은 전면 전환보다 병행 테스트가 낫습니다. 테스트가 잘 갖춰진 작은 작업, 반복 수정, 문서 업데이트, PR 요약부터 맡겨 보고 기존 Claude Code나 Codex 결과와 비교하는 방식이 안전합니다.

 

개발자가 아니어도 Gemini Spark가 의미 있을까요?

의미가 있을 수 있습니다. Spark의 핵심은 코딩이 아니라 “맡겨 놓고 나중에 확인하는 작업”입니다. 문서 요약, 일정 준비, 반복 체크, 조사 초안처럼 결과를 사람이 쉽게 검토할 수 있는 일부터 시작하는 것이 좋습니다.