Google I/O 2026 개발자 관전 포인트: Gemini 3.5 Flash, Antigravity 2.0, HTML-in-Canvas

Google I/O 2026을 전부 따라가려 하면 "Gemini가 또 어디에 붙었나"만 남습니다. 개발자가 지금 봐야 할 것은 발표 이름이 아니라 우선순위입니다. 빠른 모델은 어디에 쓰고, 에이전트 IDE는 어디서 멈춰 세우며, 새 Chrome API는 언제 실험해야 할까요?

이번 발표의 큰 흐름은 Google이 검색, 메일, 안드로이드, 개발 도구를 따로 개선하는 데서 멈추지 않는다는 점입니다. Gemini가 사용자의 다음 작업을 이어받는 기본 인터페이스가 되고 있습니다. 그래서 이번 글은 발표 목록을 그대로 훑기보다, 실제 개발 흐름에서 바뀌는 지점만 골라 정리합니다.

 

빠른 AI 모델, 에이전트 작업 보드, HTML 컨트롤이 섞인 canvas 화면이 한 개발자 작업 공간에 연결된 모습

 

핵심은 "AI 기능 추가"가 아니라 작업 흐름의 이동이다

예전 Google의 상징은 검색 결과 링크였습니다. 이번 I/O에서 보인 방향은 사용자가 링크를 열고, 문서를 읽고, 코드를 고치는 단계를 AI가 한 흐름으로 묶는 쪽에 가깝습니다.

Google이 공개한 I/O 2026 개발자 하이라이트도 Gemini 3.5 Flash, Antigravity 2.0, Managed Agents, 개발 도구 통합을 같은 맥락에서 설명합니다. 개별 기능보다 "AI가 작업 단위를 맡는 방식"이 더 중요해진 셈입니다.

이 흐름을 너무 낙관적으로 보면 위험합니다. AI가 코드를 더 많이 써 주는 만큼 개발자가 할 일이 사라지는 것이 아니라, 사람이 봐야 할 지점이 바뀝니다. 이제 중요한 것은 타이핑 속도가 아니라 변경 범위, 권한, 비용, 실패 로그입니다.

 

 

Gemini 3.5 Flash는 싼 모델이 아니라 반복 실행용 모델로 봐야 한다

Gemini 3.5 Flash는 빠른 응답과 긴 컨텍스트를 앞세운 모델입니다. DeepMind의 Gemini 3.5 Flash model card를 보면 멀티모달 입력, 긴 컨텍스트, 큰 출력 한도 같은 에이전트형 작업에 유리한 특성이 강조됩니다.

실무에서는 "한 번에 깊게 생각하는 모델"보다 "여러 번 불러도 흐름이 끊기지 않는 모델"로 보는 편이 맞습니다. PR 요약, 테스트 실패 원인 후보 정리, 로그 분류, 코드베이스 검색 후 패치 초안 만들기처럼 반복 호출이 자연스러운 작업에 어울립니다.

여기서 자주 놓치는 부분이 비용입니다. Flash라는 이름 때문에 무조건 저렴한 보조 모델처럼 느껴질 수 있지만, 에이전트 워크플로는 한 번의 답변으로 끝나지 않습니다. 파일을 읽고, 도구를 호출하고, 실패하면 다시 시도하고, 마지막에 자기 검토까지 합니다. 모델 단가가 낮아도 반복 횟수가 늘면 비용은 다른 방식으로 튑니다.

적용 전에는 Gemini API 가격표를 보고 입력 토큰, 출력 토큰, 캐시 사용 가능성, 도구 호출 횟수를 함께 계산해야 합니다. "모델이 싸다"와 "전체 작업이 싸다"는 같은 말이 아닙니다.

 

작업	Gemini 3.5 Flash에 맡기기 좋은가	실패 포인트
긴 문서 요약과 분류	좋음	근거 문장 없이 요약만 남기면 검토가 어려움
PR 변경 요약	좋음	위험도 판단을 모델 말로 끝내면 안 됨
테스트 실패 원인 후보	좋음	수정 후 재실행이 없으면 추측에 머무름
아키텍처 결정	제한적	빠른 초안용이지 최종 판단용은 아님
보안/권한 변경	조심	자동 적용보다 diff와 권한 검토가 먼저

 

작게 시작하려면 "실패해도 되돌리기 쉬운 반복 작업"이 좋습니다. 예를 들어 CI 실패 로그를 분류하거나, PR 변경 파일을 읽고 리뷰 포인트를 뽑는 정도가 적당합니다.

 

 

Antigravity 2.0은 코딩 에디터보다 에이전트 관제 화면에 가깝다

Antigravity 2.0에서 중요한 변화는 코드 자동완성 자체가 아닙니다. 여러 에이전트를 동시에 굴리고, 작업 중 필요한 하위 에이전트를 만들고, 예약 작업까지 맡기는 방향입니다. 즉, 에디터라기보다 작은 개발팀을 지휘하는 화면에 가까워지고 있습니다.

이 변화는 Cursor나 Codex류 도구를 써 본 사람에게 익숙하면서도 불편합니다. 한 파일을 열고 직접 고치는 감각보다, 에이전트가 만든 결과를 받아 검수하는 감각이 커지기 때문입니다. AI 코딩 도구가 에디터 보조에서 작업 오케스트레이션으로 이동하는 흐름은 2026년 AI 코딩 도구 정리와도 맞닿아 있습니다.

데모는 당연히 화려합니다. 소스에서는 OS를 만들고, 빠진 드라이버를 생성해 Doom을 실행하는 장면이 강조됩니다. 이런 장면은 "AI가 코드를 얼마나 빨리 뱉는가"를 보여주기 좋습니다. 하지만 실무에서 더 중요한 질문은 따로 있습니다. 그 변경이 요청한 범위 안에 있는가? 테스트가 의미 있게 통과했는가? 사람이 리뷰할 수 있는 크기로 나뉘어 있는가?

Antigravity 같은 도구를 도입할 때는 다음 네 가지를 먼저 봐야 합니다.

• 변경 범위: 요청하지 않은 파일과 설정까지 건드리지 않는가
• 테스트 태도: 실패를 숨기거나 의미 없는 우회 코드로 통과시키지 않는가
• 권한 영역: auth, database rule, deployment setting을 자동으로 바꾸지 않는가
• 비용 루프: 빠른 재시도 때문에 토큰 비용과 CI 시간이 함께 늘지 않는가

 

결국 "AI가 코드를 쓴다"보다 "AI가 만든 변경을 어떤 단위로 멈춰 세울 것인가"가 더 중요합니다. PR 단위로 위험을 요약하고 사람이 확인하는 흐름은 AI 코드 리뷰와 PR 검증 흐름처럼 별도의 습관으로 가져가야 합니다.

 

하나의 요청이 여러 AI 에이전트 작업으로 나뉜 뒤 diff, 사람 검토, 테스트를 거쳐 병합되는 흐름

 

Managed Agents는 자동화가 쉬워지는 만큼 경계를 좁혀야 한다

Gemini API의 Managed Agents는 단일 API 호출 안에서 도구 실행과 코드 실행 환경을 붙이는 쪽으로 이해하면 됩니다. 별도의 실행 환경을 직접 만들고, 중간 상태를 관리하고, 도구 연결을 설계하는 부담을 줄여 줍니다.

이 기능은 내부 자동화에는 꽤 매력적입니다. 문서 묶음을 읽고 요약 파일을 만들거나, 로그를 분석해 이슈 후보를 뽑거나, 작은 코드 조각을 실행해 결과를 비교하는 작업에 붙이기 좋습니다.

하지만 에이전트가 코드를 실행할 수 있다는 것은 실패 형태가 단순한 오답이 아니라는 뜻입니다. 잘못된 파일을 읽을 수 있고, 필요 이상으로 넓은 데이터를 넘길 수 있고, 실행 결과를 과신할 수 있습니다. 그래서 Managed Agents를 시스템으로 붙일 때는 아래 기준이 먼저입니다.

• 접근 가능한 파일과 비밀값을 최소화한다.
• 실행 결과를 바로 반영하지 말고 diff나 report로 남긴다.
• 반복 횟수와 최대 비용을 사전에 제한한다.
• 실패 로그를 사람이 읽을 수 있는 형태로 저장한다.

 

작은 자동화일수록 이 원칙을 대충 넘기기 쉽습니다. 그런데 작은 자동화가 매일 돌기 시작하면, 나중에는 업무 흐름의 일부가 됩니다. 처음부터 권한과 로그를 좁게 잡는 편이 낫습니다.

 

 

HTML-in-Canvas는 AI 홍수 속에서 놓치기 쉬운 프론트엔드 뉴스다

이번 I/O에서 AI가 아닌 쪽으로 가장 눈에 띄는 발표는 Chrome의 HTML-in-Canvas API입니다. 이름 그대로 HTML 요소를 canvas 안에 그릴 수 있게 하는 실험입니다. Chrome Developers는 이를 HTML-in-Canvas origin trial로 소개했고, Chrome 148-150 범위의 origin trial과 Canary flag 사용을 안내합니다.

이 API가 의미 있는 이유는 canvas와 DOM을 억지로 맞추던 마찰을 줄일 수 있기 때문입니다. WebGL/WebGPU 화면은 픽셀 제어가 좋지만, 버튼, 입력창, 드롭다운, 폰트, 접근성 같은 기본 UI는 HTML이 훨씬 편합니다. 지금까지는 canvas 위에 HTML을 겹쳐 놓고 좌표, 스크롤, transform을 따로 맞추는 일이 많았습니다.

HTML-in-Canvas가 성숙하면 이런 화면에서 쓸모가 생깁니다.

• WebGPU 시각화 위에 실제 HTML 컨트롤을 함께 렌더링하는 대시보드
• 게임이나 시뮬레이션 화면 안의 설정 패널
• canvas 기반 편집기에서 일부 UI만 HTML로 유지하는 구조
• AI가 생성한 diagram, timeline, mini app을 canvas 화면에 섞는 실험

 

다만 지금 바로 프로덕션 표준처럼 쓰면 안 됩니다. origin trial 단계이고, 브라우저 지원도 Chrome 중심입니다. 또 canvas에 그린 HTML이 기존 DOM overlay와 완전히 같은 개발 경험을 준다고 가정하면 안 됩니다. 좌표 동기화, CSS transform, 이벤트 처리, 접근성, fallback을 따로 확인해야 합니다.

실험한다면 내부 도구나 데모부터 시작하는 편이 맞습니다. 질문은 "HTML을 canvas에 그릴 수 있나"가 아닙니다. "canvas와 DOM을 따로 맞추던 코드가 실제로 줄어드나"입니다.

 

 

실무 적용 우선순위

Google I/O 2026 발표를 전부 따라가려고 하면 금방 흐려집니다. 개발자 입장에서는 아래 순서로 보면 충분합니다.

 

우선순위	볼 것	지금 할 일
1	Gemini 3.5 Flash	반복형 자동화에 작은 PoC를 붙이고 비용을 측정
2	Antigravity 2.0	코드 생성보다 리뷰, 테스트, 권한 경계를 먼저 설계
3	Managed Agents	내부 자동화 후보를 찾되 데이터 접근 범위를 제한
4	HTML-in-Canvas	Chrome 실험 환경에서 UI 마찰이 줄어드는지 확인
5	Gemini가 붙은 소비자 제품	직접 개발 흐름에 영향이 있을 때만 추적

 

가장 위험한 접근은 "발표가 멋지니 바로 전면 도입"입니다. 특히 에이전트 도구는 작게 붙였을 때는 시간을 줄여 주지만, 검토 구조 없이 크게 붙이면 사람이 이해하지 못하는 변경이 빠르게 쌓입니다.

반대로 너무 보수적으로만 볼 필요도 없습니다. PR 요약, 테스트 로그 분류, 문서 초안, 데모 앱 생성처럼 실패해도 되돌리기 쉬운 영역에서는 이미 충분히 실험 가치가 있습니다. 중요한 것은 AI가 만든 결과를 신뢰하는 기준을 코드베이스 안에 남기는 것입니다.

 

 

FAQ

 

Gemini 3.5 Flash를 지금 바로 업무 자동화에 써도 될까요?

작은 반복 작업부터 붙이는 것은 괜찮습니다. 다만 비용 상한, 재시도 횟수, 사람이 확인할 report나 diff를 먼저 정해야 합니다. 처음부터 권한이 큰 배포, 인증, 데이터베이스 설정 변경에 연결하는 것은 피하는 편이 안전합니다.

 

HTML-in-Canvas는 지금 서비스에 써도 될까요?

아직은 실험 대상으로 보는 것이 맞습니다. origin trial과 Chrome 중심 지원을 전제로 내부 도구나 데모에서 먼저 확인하고, 실제 서비스에서는 fallback과 접근성 계획이 준비된 경우에만 검토하는 편이 좋습니다.

 

 

결론

Google I/O 2026의 핵심은 Gemini 이름이 몇 개 더 붙었는지가 아닙니다. 빠른 모델은 반복 실행을 맡고, IDE는 에이전트 관제로 바뀌고, 브라우저는 canvas와 HTML의 경계를 조금씩 허물고 있습니다.

지금 할 일은 세 가지면 충분합니다. Gemini 3.5 Flash로 작은 반복 작업 하나를 자동화해 비용을 재보고, Antigravity류 도구는 PR과 테스트 중심으로 멈춰 세우며, HTML-in-Canvas는 Chrome 실험 환경에서 UI 코드가 실제로 줄어드는지 확인하는 것입니다.

새 도구가 많아질수록 개발자의 역할은 사라지지 않습니다. 오히려 무엇을 자동화해도 되는지, 무엇은 반드시 멈춰 세워야 하는지 정하는 일이 더 중요해집니다.