Published on

Google Gemini 3.5와 에이전트 검색: 모델 발표보다 중요한 것은 실행 레이어다

Authors

Google Gemini 3.5 · AI Search · Agentic Runtime

Google I/O 2026에서 가장 중요한 문장은 "Gemini 3.5가 더 똑똑해졌다"가 아니다. 더 정확히는 Google이 Gemini를 검색창, 브라우저, 개발자 도구, 클라우드 인프라를 관통하는 실행 레이어로 재배치하고 있다는 점이다.

Google Gemini 3.5 agentic era cover

이번 발표를 모델 성능표로만 보면 절반을 놓친다. Google은 Gemini 3.5를 "frontier intelligence with action"이라고 설명했고, Sundar Pichai의 I/O 키노트는 이를 "agentic Gemini era"라는 제품 전략으로 묶었다. 동시에 Search I/O 업데이트는 Search 안에 정보 에이전트와 예약 에이전트를 넣겠다고 밝혔다.

개발자와 빌더 입장에서 이 변화의 핵심은 명확하다. 앞으로 AI 제품의 경쟁력은 "좋은 모델을 호출한다"보다 모델이 사용자의 실제 업무 표면에서 얼마나 안전하게 행동하고, 오래 기다리고, 도구를 호출하고, 결과를 다시 사용자 경험으로 돌려보내는가로 옮겨간다.

기준 시점: 이 글은 2026-05-21에 확인한 Google 공식 발표와 블로그 내용을 바탕으로 썼다. 모델 이름, 제공 지역, 구독 조건, API 제공 방식은 빠르게 바뀔 수 있으니 실제 구현 전 공식 문서를 다시 확인하는 편이 좋다.

검색 의도부터 보자: 사람들이 궁금한 건 "Gemini 3.5 성능"이 아니라 "무엇을 만들 수 있나"다

이 주제로 검색하는 사람은 대체로 네 부류다.

  1. 개발자 — Gemini 3.5 Flash가 기존 모델 대비 어떤 워크플로에 맞는지 알고 싶다.
  2. 제품팀 — Search·Chrome·Workspace에 들어가는 에이전트 기능이 사용자 행동을 어떻게 바꿀지 궁금하다.
  3. AI 스타트업/빌더 — Google이 기본 제품 표면에 에이전트를 넣으면 독립 제품의 차별화 지점이 어디인지 고민한다.
  4. 기업 운영자 — "에이전트"가 실제 운영 자동화로 이어지려면 권한, 감시, 데이터 연결, 실패 대응을 어떻게 봐야 하는지 알고 싶다.

그래서 이 글은 Gemini 3.5의 점수 자랑보다 실행 구조와 실무적 의미에 초점을 둔다.

Gemini 3.5의 메시지: 지능보다 "행동 가능한 지능"이 전면에 왔다

Google의 Gemini 3.5 발표문은 Flash를 중심으로 "복잡한 agentic workflows를 실행하도록 설계됐다"고 설명한다. 여기서 중요한 단어는 frontier intelligence보다 action이다.

Gemini 3.5 model runtime

지금까지 많은 모델 발표는 이런 순서였다.

  • 더 높은 벤치마크 점수
  • 더 긴 컨텍스트
  • 더 나은 멀티모달 이해
  • 더 낮은 지연시간 또는 비용

Gemini 3.5의 포지셔닝은 여기에 한 층을 더 얹는다. 모델이 단순히 답을 잘하는 것이 아니라, 코딩·장기 작업·멀티스텝 업무·도구 호출 같은 실행형 작업에 맞춰져 있다는 메시지다. Google이 Flash를 강조하는 것도 이 맥락에서 읽어야 한다. 에이전트 제품에서 중요한 건 최고 점수 하나가 아니라, 반복 호출·대기·검증·툴 사용이 가능한 비용/속도/신뢰성 조합이기 때문이다.

실무에서는 이 차이가 꽤 크다. 챗봇은 한 번 대답하고 끝나도 된다. 하지만 에이전트는 다음을 버텨야 한다.

  • 사용자의 의도를 여러 단계 작업으로 분해한다.
  • 중간 결과를 확인하고 다음 행동을 고른다.
  • 외부 도구나 API를 호출한다.
  • 실패했을 때 재시도하거나 사용자에게 되묻는다.
  • 완료된 결과를 다시 제품 UX 안에서 설명한다.

즉 Gemini 3.5의 핵심 질문은 "얼마나 똑똑한가"보다 얼마나 오래, 빠르게, 안전하게 행동할 수 있는가에 가깝다.

Google이 무서운 이유: 모델 발표와 제품 배포 표면이 동시에 움직인다

Google의 강점은 모델만이 아니다. Search, Chrome, Android, Workspace, Cloud, YouTube, Maps 같은 기본 배포 표면이 있다. I/O 2026 키노트는 Gemini 3.5와 Antigravity, Search, Chrome, Science, TPU 8i 같은 요소를 하나의 큰 그림으로 묶었다.

이건 독립 AI 앱 입장에서는 불편한 신호다. 사용자가 별도 앱을 열지 않아도, 검색창·브라우저·업무 도구 안에서 에이전트가 자연스럽게 행동하기 시작하면, "AI 기능" 자체는 빠르게 기본값이 된다.

Google이 이번에 보여준 방향은 세 가지다.

  1. 모델 계층 — Gemini 3.5 Flash를 빠른 실행형 모델로 배치한다.
  2. 제품 계층 — Search와 Chrome 같은 대중 표면에 에이전트 UX를 넣는다.
  3. 인프라 계층 — TPU, Cloud, 개발자 도구, Antigravity 같은 실행 환경을 연결한다.

이 조합은 단순 모델 런치보다 훨씬 강하다. 모델 회사가 API만 제공하는 것과, Google이 검색·브라우저·모바일·클라우드 표면에서 에이전트 경험을 직접 배포하는 것은 완전히 다른 게임이다.

Search는 검색 엔진에서 "상시 대기 정보 에이전트"로 이동 중이다

Search I/O 업데이트에서 눈에 띄는 표현은 AI Mode의 성장과 정보 에이전트다. Google은 AI Mode가 출시 1년 만에 월간 사용자 10억 명을 넘었고, 쿼리가 분기마다 두 배 이상 늘었다고 밝혔다. 그리고 Search 안에 개인화된 정보 에이전트와 예약 에이전트를 넣겠다고 설명했다.

Google Search agents

이 변화는 SEO와 제품 전략 모두에 영향을 준다.

기존 검색은 사용자가 질문을 넣고 결과를 고르는 구조였다. AI Search는 답변을 요약한다. 하지만 정보 에이전트는 한 단계 더 간다. 사용자가 조건을 걸어두면, 에이전트가 백그라운드에서 계속 찾아보고, 새로운 이벤트가 생기면 알려준다. 예약 에이전트는 사용자가 조건을 말하면 가격·예약 가능성·공급자 링크를 모아준다.

이건 검색의 단위가 query에서 standing instruction으로 바뀐다는 뜻이다.

  • "지금 검색해줘"에서 "이 조건을 계속 감시해줘"로 이동한다.
  • "결과 목록을 줘"에서 "가능한 행동 경로를 정리해줘"로 이동한다.
  • "문서 링크를 클릭"에서 "예약·구매·신청 직전까지 진행"으로 이동한다.

SEO 관점에서도 중요하다. 앞으로 콘텐츠는 단순히 사람이 읽는 검색 결과가 아니라, 에이전트가 신뢰할 수 있는 구조화된 근거가 되어야 한다. 가격, 조건, 업데이트 일자, 위치, 정책, FAQ, 비교 기준이 흐릿한 페이지는 에이전트 검색에서 불리해질 가능성이 높다.

Chrome과 브라우저 에이전트는 "웹 자동화"의 기준선을 올린다

키노트에서 Google은 Spark가 Chrome 안에서 agentic browser로 작동하는 방향도 언급했다. 이름이나 제공 방식은 시간이 지나며 바뀔 수 있지만, 방향성은 분명하다. 브라우저는 더 이상 사람이 클릭하는 화면만이 아니라, 모델이 웹을 탐색하고 행동하는 실행 환경이 된다.

이건 이미 여러 스타트업과 오픈소스 에이전트가 해온 일이다. 차이는 배포다. Chrome은 웹의 기본 런타임에 가깝고, Google 계정·검색·결제·지도·문서·캘린더와 자연스럽게 연결될 수 있다.

빌더 입장에서 봐야 할 포인트는 두 가지다.

첫째, 범용 브라우저 조작은 점점 commodity가 된다. 단순히 "웹사이트를 열고 버튼을 누르는 에이전트"만으로는 차별화가 어렵다. 둘째, 진짜 차별화는 특정 도메인의 데이터, 워크플로, 권한 관리, 실패 복구, 감사 로그, 사용자 신뢰에서 나온다.

예를 들어 여행 예약 에이전트를 만든다면, 브라우저 클릭 자동화 자체보다 아래가 더 중요해진다.

  • 사용자의 선호 조건을 얼마나 정확히 유지하는가
  • 가격 변동과 취소 정책을 어떻게 검증하는가
  • 결제 직전 승인 플로우를 어떻게 설계하는가
  • 오류나 중복 예약을 어떻게 방지하는가
  • 나중에 왜 그 선택을 했는지 설명할 수 있는가

Google의 브라우저 에이전트 방향은 "에이전트가 가능하다"의 증명이 아니라, 기본 자동화 레이어가 플랫폼화될 때 앱이 어디에서 가치를 만들어야 하는지를 묻는 신호다.

개발자에게 더 중요한 질문: Gemini 3.5를 쓰느냐보다 에이전트 스택을 어떻게 짜느냐다

Gemini 3.5 발표를 보고 바로 모델 교체부터 생각하면 성급하다. 실무에서는 모델보다 스택 설계가 먼저다.

Agentic architecture stack

에이전트 제품은 대략 이런 층으로 나뉜다.

계층핵심 질문실무 체크포인트
제품 표면사용자가 어디서 지시하는가검색창, 채팅, IDE, 브라우저, 업무 도구
오케스트레이션작업을 어떻게 분해하고 이어가는가플래너, 상태 관리, 재시도, 큐, 스케줄러
도구/API어떤 행동을 실제로 수행하는가캘린더, 이메일, 결제, DB, 웹, 내부 시스템
권한/거버넌스어디까지 자동 실행할 수 있는가승인 단계, 감사 로그, 정책, 민감 데이터
모델 런타임어떤 모델을 언제 호출하는가속도, 비용, 컨텍스트, 멀티모달, 실패율
인프라장시간 작업을 어떻게 운영하는가관측성, 캐시, 백그라운드 작업, 비용 제어

Gemini 3.5 Flash는 이 중 모델 런타임 계층의 중요한 후보가 될 수 있다. 하지만 좋은 에이전트 제품은 모델 하나로 끝나지 않는다. 특히 업무 자동화에서는 "모델이 맞는 말을 했다"보다 "시스템이 잘못된 행동을 하지 않았다"가 더 중요하다.

따라서 지금 빌더가 해야 할 일은 단순 모델 비교가 아니라 다음 세 가지다.

  1. 행동 경계 정의 — 자동 실행 가능한 작업과 반드시 사람 승인이 필요한 작업을 나눈다.
  2. 상태와 근거 저장 — 에이전트가 어떤 근거로 어떤 결정을 했는지 남긴다.
  3. 플랫폼 의존성 관리 — Search/Chrome/Gemini가 기본 제공하는 영역과 내가 직접 가져갈 도메인 영역을 구분한다.

SEO와 콘텐츠 전략도 바뀐다: 에이전트가 읽기 좋은 페이지가 이긴다

Google Search가 정보 에이전트와 개인화된 모니터링으로 움직이면, 콘텐츠 운영자는 "검색어 순위"만 볼 수 없다. 에이전트가 페이지를 읽고 판단할 때 필요한 구조를 제공해야 한다.

앞으로 더 중요해질 가능성이 높은 요소는 다음이다.

  • 명확한 제목과 요약
  • 최신 업데이트 일자
  • 비교 기준과 표
  • 가격·조건·제약의 구조화
  • 출처와 원문 링크
  • FAQ와 예외 상황
  • 제품/서비스의 실제 사용 조건

특히 AI 관련 글이라면 "새 모델이 나왔다" 수준의 얕은 요약은 금방 묻힌다. 대신 누가 써야 하는지, 기존 워크플로와 무엇이 달라지는지, 어떤 리스크가 있는지, 지금 당장 무엇을 바꿔야 하는지를 구체적으로 써야 한다.

이 글이 Gemini 3.5를 모델 스펙보다 실행 레이어 관점에서 보는 이유도 여기에 있다. 검색 수요는 결국 "그래서 내 제품/팀/워크플로에 어떤 의미인가"로 수렴한다.

실무 해석: 한국 개발자와 빌더가 지금 봐야 할 5가지

1) 범용 AI 기능은 더 빨리 기본값이 된다

Search와 Chrome 안에 에이전트가 들어가면, 별도 앱의 "AI로 검색/예약/요약" 기능은 차별화가 약해진다. 제품은 더 좁고 깊은 도메인 문제로 이동해야 한다.

2) 모델 선택보다 승인 UX가 중요해진다

에이전트가 실제 행동을 하면 실패 비용이 생긴다. 이메일 발송, 예약, 결제, 코드 변경, 고객 데이터 조회 같은 작업에는 승인·취소·감사 로그가 필요하다.

3) SEO는 구조화된 근거 싸움이 된다

AI Search가 사용자 대신 정보를 비교하면, 페이지는 사람이 훑기 좋은 글이면서 동시에 에이전트가 추출하기 쉬운 근거여야 한다. 표, 업데이트 날짜, 조건, 제한사항을 숨기면 손해다.

4) 오픈 웹 자동화 스타트업은 더 구체적인 문제로 가야 한다

브라우저 조작 자체는 플랫폼 기능이 될 가능성이 높다. 차별화는 특정 산업의 데이터 모델, 업무 규칙, 예외 처리, 책임 소재에서 나온다.

5) Google 생태계 의존성을 의식해야 한다

Gemini 3.5와 Search/Chrome 에이전트는 강력하지만, 모든 제품이 Google 런타임에만 묶이는 것은 위험하다. 중요한 워크플로라면 모델/툴 추상화, 로그 보존, 대체 경로를 준비해야 한다.

결론: Gemini 3.5는 모델 업데이트가 아니라 Google식 에이전트 배포 전략이다

Gemini 3.5 발표의 핵심은 "더 좋은 Flash 모델" 하나가 아니다. Google은 Gemini를 Search, Chrome, 개발자 도구, Cloud, TPU 인프라와 연결해 사용자 표면에서 실제 행동하는 에이전트 런타임으로 만들고 있다.

그래서 이번 발표를 볼 때 질문은 하나다.

내 제품은 플랫폼이 기본 제공하는 에이전트 기능 위에서 어떤 도메인 신뢰, 데이터, 워크플로, 책임 구조를 만들 것인가?

단순 AI 기능은 빠르게 평준화된다. 앞으로 남는 것은 실행 품질, 권한 설계, 근거 관리, 도메인 깊이다. Gemini 3.5와 Google의 agentic era 선언은 그 전환을 꽤 노골적으로 보여준다.


참고한 공식/1차 출처