- Published on
Google의 "에이전트 런타임" 전략: TPU, Chrome AI Mode, Skills가 하나의 작업면이 되는 이유
- Authors
- Name
- Kyunghyun Park
- @devkhpark
Google · TPU 8i/8t · Chrome AI Mode · Skills in Chrome
Google의 최근 발표를 하나씩 따로 보면 그저 제품 뉴스 몇 개처럼 보일 수 있다. 하지만 4월 중순부터 말까지 나온 공식 글을 묶어 읽으면 이야기가 달라진다. TPU 8i·8t 발표, Chrome의 AI Mode 발표, Skills in Chrome 발표는 모두 같은 방향을 가리킨다. Google은 AI를 더 똑똑한 답변 엔진으로만 밀고 있는 게 아니라, 에이전트가 오래 실행되고, 브라우저 안에서 문맥을 붙잡고, 반복 가능한 작업을 즉시 재사용하는 런타임 스택으로 만들고 있다.
이 글의 핵심 논지는 단순하다. Google의 최근 AI 전략은 모델 경쟁보다 런타임 경쟁에 더 가깝다. TPU는 에이전트의 속도와 처리량을 받치고, Chrome AI Mode는 사용자가 실제 웹 작업을 이어가는 표면을 만들고, Skills는 좋은 프롬프트를 재사용 가능한 작업 단위로 바꾼다. 셋을 합치면 Google은 브라우저와 인프라를 동시에 쥔 회사답게, AI를 하나의 연속된 작업 환경으로 만들려는 쪽에 가깝다.
한 줄 논지: Google은 Gemini를 잘 만드는 것에서 멈추지 않고, 에이전트가 돌아가는 칩·브라우저·워크플로 레이어를 한꺼번에 제품화하고 있다.
TPU 8i와 8t는 "더 빠른 칩"이 아니라 에이전트 시대의 역할 분리다
Google이 4월 22일 공개한 "We're launching two specialized TPUs for the agentic era"는 문장 자체가 꽤 노골적이다. 발표의 초점은 단순 성능 자랑이 아니라 AI 에이전트가 더 demanding한 workload를 처리한다는 전제다. Google은 이 글에서 TPU 8i를 빠른 사용자 경험을 위한 에이전트용 추론 칩으로 설명하고, TPU 8t를 거대한 메모리 풀 위에서 복잡한 모델을 훈련시키는 쪽으로 포지셔닝한다.
이 표현이 중요한 이유는 두 가지다.
첫째, Google이 이제 AI workload를 하나의 평균값으로 보지 않는다는 점이다. 에이전트는 단일 프롬프트 응답보다 훨씬 복잡하다. 계획을 세우고, 여러 단계를 실행하고, 도구를 부르고, 필요하면 다시 수정한다. 이런 워크로드에서는 단순 토큰 처리량이 아니라 짧은 응답 지연, 지속 세션, 다단계 루프가 중요해진다. TPU 8i와 8t를 나눠 설명했다는 건 Google이 그 차이를 인프라 단계에서부터 제품화하고 있다는 뜻이다.
둘째, 이 발표는 칩이 더 이상 숨은 백엔드가 아니라는 신호다. 예전엔 인프라가 서비스 내부 사정처럼 취급됐다면, 지금은 다르다. Google은 agentic era라는 표현을 공개 블로그 제목에 올리면서, 추론 하드웨어 자체를 에이전트 제품 전략의 일부로 전면화했다. 이건 AWS가 inference recommendation을 전면에 내세우고, OpenAI가 Responses API WebSockets처럼 런타임 병목을 공개적으로 다루는 흐름과도 닿아 있다. 이제 성능 경쟁은 모델 한 줄 벤치마크보다 어떤 칩과 어떤 serving path가 에이전트 루프를 버티게 하느냐로 옮겨간다.
정리하면 TPU 8i/8t는 “칩 두 개 추가”가 아니다.
- TPU 8i는 빠른 agent response와 좋은 UX를 위한 추론용 축
- TPU 8t는 복잡한 frontier 모델 학습과 대형 메모리 수요를 위한 훈련용 축
- 둘을 같이 내세운 것은 Google이 에이전트 시대를 inference + training의 연속된 시스템으로 본다는 신호
Chrome AI Mode는 브라우저를 검색창이 아니라 에이전트 작업면으로 바꾼다
4월 16일 공개된 "A new way to explore the web with AI Mode in Chrome"는 브라우저 UX 차원에서 더 중요하다. 이 글에서 Google은 AI Mode가 Chrome 데스크톱에서 링크를 열 때 웹페이지와 AI Mode를 나란히 보여 준다고 설명한다. 핵심은 “탭을 덜 왔다 갔다 하게 해 준다” 정도가 아니다. 더 본질적인 변화는 웹 탐색의 문맥이 끊기지 않는 상태에서 AI가 옆에서 계속 따라붙는 구조가 생긴다는 점이다.
이건 생각보다 큰 차이다. 기존 웹 검색은 검색 결과를 열고, 탭을 바꾸고, 비교하고, 다시 질문하는 흐름이었지만, AI Mode는 탐색과 질문을 한쪽 표면 안에 묶는다. Google이 예시로 든 쇼핑이나 정보 탐색 시나리오는 사실 더 넓은 의미를 가진다.
- 사용자는 웹페이지를 읽는 중에도 문맥을 유지한 채 질문할 수 있다.
- AI는 현재 페이지와 웹 전반의 정보, 그리고 최근 탭 문맥을 함께 활용할 수 있다.
- 사용자는 검색창으로 되돌아가지 않고도 follow-up loop를 이어갈 수 있다.
즉 Chrome은 더 이상 AI 기능이 붙은 브라우저가 아니라, 브라우징 자체가 AI loop의 일부가 되는 표면으로 바뀌고 있다. 이 점이 중요하다. 검색이든 쇼핑이든 리서치든, 실제 지식 노동은 대부분 브라우저에서 일어난다. Google은 이 현실을 가장 잘 아는 회사다. 그래서 AI를 별도 앱으로만 두지 않고, Chrome이라는 거대한 분배 채널 안으로 밀어 넣는 쪽이 훨씬 강력하다.
실무적으로 보면 이 변화는 단순 convenience가 아니다. 브라우저 안에서 문맥이 유지되면, 앞으로는 다음 같은 워크플로가 자연스러워진다.
- 여러 페이지를 동시에 비교하면서 요약받기
- 특정 페이지 내용을 기준으로 follow-up 질문 반복하기
- 최근 탭과 현재 문서를 묶어 비교·검증하기
- 웹 탐색 결과를 바로 다음 액션으로 연결하기
이건 전형적인 agent workbench의 특징이다. 질문 하나에 답하는 AI가 아니라, 계속 이어지는 탐색형 작업을 옆에서 조율하는 AI에 가깝다.
Skills in Chrome은 좋은 프롬프트를 일회성 입력에서 반복 가능한 작업으로 바꾼다
4월 14일 공개된 "Turn your best AI prompts into one-click tools in Chrome"는 얼핏 사소해 보인다. 프롬프트를 저장하고 다시 쓰게 해 준다는 얘기니까. 하지만 제품 전략 관점에서 보면 이 기능은 꽤 중요하다. Google은 여기서 Skills를 통해 사용자가 가장 유용한 프롬프트를 저장하고, / 또는 + 버튼으로 현재 페이지나 여러 탭에 즉시 실행할 수 있게 한다고 설명한다. 나아가 ready-to-use Skills 라이브러리도 제공한다.
왜 이게 중요할까? AI 제품에서 실제 생산성은 "좋은 답변"보다 좋은 작업 패턴을 얼마나 재사용 가능하게 만드느냐에서 갈리는 경우가 많다. 예를 들어 긴 문서를 훑어 핵심만 찾기, 여러 상품 스펙을 비교하기, 레시피를 특정 제약에 맞게 바꾸기 같은 일은 한 번 잘 되면 계속 반복하고 싶어진다. Skills는 바로 이 반복을 제품 안에 박아 넣는다.
이 흐름은 OpenAI가 Codex skills와 automations를 교육 콘텐츠로 밀고 있는 것과도 닮아 있다. 차이는 Google이 그걸 브라우저 안에서 한다는 점이다. 즉 Google은 좋은 프롬프트를 별도 노트에 저장하는 문화가 아니라, 브라우저 작업 자체에 부착되는 one-click workflow로 만들고 있다.
여기서 중요한 포인트는 세 가지다.
- 좋은 프롬프트를 저장 가능한 작업 자산으로 만든다.
- 현재 페이지와 선택한 탭 문맥 위에서 바로 실행할 수 있다.
- 라이브러리와 편집 기능을 통해 개인화 + 재사용을 동시에 지원한다.
이건 AI 제품이 점점 skill pack, recipe, automation 중심으로 바뀌고 있다는 신호다. 결국 강한 AI는 질문을 잘 받는 도구가 아니라, 반복 업무를 구조화해서 다시 돌릴 수 있는 도구가 된다.
셋을 같이 보면 Google의 전략은 모델 출시보다 "작업 환경 장악"에 가깝다
TPU 발표만 보면 인프라 뉴스다. Chrome AI Mode만 보면 브라우저 기능 추가다. Skills만 보면 편의 기능 같다. 그런데 셋을 같이 놓으면 완전히 다르게 보인다. Google은 각 레이어를 따로 놀게 두지 않는다.
- TPU 레이어: 에이전트 workload를 감당할 수 있는 specialized compute
- 브라우저 레이어: 사용자가 실제로 일하는 표면에서 문맥을 유지하는 AI 경험
- 워크플로 레이어: 반복 가능한 프롬프트/스킬을 저장하고 다시 실행하는 메커니즘
즉 Google은 모델 하나를 더 똑똑하게 만들었다고 말하는 대신, 에이전트가 돌아가는 전체 환경을 칩에서 브라우저까지 연속된 제품으로 설계하고 있다. 이게 Google다운 강점이다. 다른 회사가 강한 모델을 내놓는 동안, Google은 브라우저·검색·클라우드 인프라·배포 채널을 동시에 갖고 있다. 그래서 AI를 앱으로만 파는 게 아니라, 사용자의 기존 작업면 위에 겹쳐 씌울 수 있다.
실무적으로 무엇을 읽어야 하나
이 흐름은 한국의 개발자, SaaS 운영자, 내부 도구 빌더에게도 꽤 직접적인 시사점을 준다.
1) 에이전트 경쟁은 벤치마크보다 런타임 설계로 이동한다
이제 중요한 질문은 “모델 IQ가 얼마나 높은가”만이 아니다. 실제 서비스에서는 얼마나 빨리 반응하는지, 긴 루프를 버티는지, 도구 호출을 얼마나 자연스럽게 엮는지가 더 중요하다. TPU 8i/8t 발표는 이 현실을 칩 단계에서 인정한 사례다.
2) 브라우저는 여전히 가장 중요한 AI 작업면이다
많은 업무가 결국 브라우저에서 이뤄진다. 문서 검토, 경쟁사 조사, 쇼핑, 광고 운영, 제품 리서치, 고객지원까지 거의 다 그렇다. AI Mode와 Skills가 브라우저 안으로 들어오면, 별도 SaaS가 제공하던 얇은 요약·비교·정리 기능은 빠르게 흡수될 가능성이 있다.
3) 반복 가능한 workflow를 먼저 정의해야 한다
좋은 에이전트는 신기한 데모보다 반복 작업에서 나온다. Skills in Chrome이 보여주듯 사용자가 계속 쓰는 프롬프트는 곧 workflow다. 팀 내부에서도 같은 기준으로 업무를 쪼개야 한다. 무엇을 매주 반복하는지, 어떤 입력과 출력이 고정돼 있는지, 어디에 승인 지점이 필요한지부터 봐야 한다.
4) 차별화는 고유 데이터와 실행 책임에서 남는다
Google처럼 브라우저와 인프라를 동시에 가진 플랫폼이 강해질수록, 독립 제품은 단순한 AI 껍데기만으로는 버티기 어렵다. 대신 도메인별 데이터 구조, 승인 체계, 감사 로그, 실패 비용이 큰 업무 같은 곳에서 더 깊은 가치가 남는다.
결론
Google의 최근 발표를 "TPU 뉴스", "Chrome 기능 추가", "프롬프트 저장 기능" 정도로 따로 보면 큰 그림을 놓치기 쉽다. 셋을 함께 보면 훨씬 선명하다. Google은 AI를 더 똑똑한 챗봇으로만 밀고 있는 게 아니라, 에이전트가 실제로 돌아가는 런타임 스택을 칩-브라우저-워크플로 레이어 전체에서 구축하고 있다.
이 전략의 무서운 점은 단일 기능의 우수성이 아니다. Google은 이미 사용자가 가장 오래 머무는 브라우저와 검색 표면을 갖고 있고, 동시에 클라우드 인프라도 갖고 있다. 그래서 AI를 새로운 앱으로 도입하는 대신, 기존 작업 환경 전체를 AI화할 수 있다.
앞으로 경쟁은 더 분명해질 가능성이 높다.
- 누가 더 강한 모델을 내놓는가
- 누가 더 빠르고 지속적인 agent loop를 제공하는가
- 누가 더 자연스럽게 브라우저 문맥과 연결되는가
- 누가 더 쉽게 반복 workflow를 재사용하게 만드는가
이 기준으로 보면, Google의 최근 신호는 단순한 기능 출시가 아니다. 에이전트 시대의 기본 작업 환경을 누가 장악할 것인가에 대한 선언에 더 가깝다.