브라우저를 열고 Gemini한테 말을 건네는 데 걸리는 시간은 1~2초 남짓이다. 근데 그 1~2초 사이에 무슨 일이 일어나는지 생각해본 적 있는가. 수천억 개의 파라미터를 가진 모델이 사용자 입력을 이해하고, 문맥을 파악하고, 자연스러운 답변을 생성해서 돌려보내는 과정이 그 짧은 시간 안에 전부 완료된다. 이게 가능한 이유는 Gemini 뒤에서 조용히 돌아가는 인프라 때문이다.
GPU 기반 서버를 쌓아놓는 것만으로 이 속도가 나오진 않는다. Google은 10년 넘게 자체 AI 칩을 직접 설계했고, 그 위에서만 Gemini가 제대로 돌아간다. 요즘 AI 개발자들 사이에서 “TPU가 뭔데 그렇게 특별하냐”는 질문이 많이 나온다. 이 글은 그 질문에 제대로 답하는 글이다. TPU의 구조가 왜 GPU와 다른지, Vertex AI가 어떤 역할을 하는지, 그리고 Chrome 안에서 Gemini Nano가 내 노트북에서 직접 실행될 때 어떤 일이 벌어지는지까지, Gemini 인프라의 실제 구조를 뜯어본다.
GPU로는 안 되는 이유 — TPU가 탄생한 배경
사람들이 흔히 “AI 서버 = GPU 서버”라고 생각한다. NVIDIA 주가가 그 인식의 산물이기도 하다. 그런데 Gemini를 실제로 돌리는 건 GPU가 아니다. Google이 자체 설계한 전용 칩, TPU다. 이 차이가 왜 생겼는지를 알면 Gemini 인프라 전체가 훨씬 선명하게 보인다.
AI가 부상하기 전에도 Google 데이터센터에는 GPU가 없었던 건 아니다. 하지만 2013년쯤, Google 내부에서 심각한 문제가 제기됐다. 당시 딥러닝 모델들이 빠르게 커지면서 추론에 필요한 연산량이 폭발적으로 늘어났는데, 이 속도에 GPU 인프라가 전혀 따라가지 못했다. 단순 계산으로, 전 세계 사용자가 하루에 수십억 건의 Google 검색을 하고 각 검색마다 딥러닝 모델 추론이 들어간다면, 기존 GPU 클러스터 규모로는 전기도 공간도 감당이 안 됐다.
그래서 Google이 택한 답이 전용 칩을 직접 만드는 것이었다. TPU, Tensor Processing Unit의 탄생이다. GPU는 원래 그래픽 렌더링을 위해 설계된 칩이다. 병렬 연산에 강하고 범용성이 높다는 장점이 있지만, AI 추론에 필요한 특정 연산 패턴, 특히 행렬 곱셈에는 불필요한 오버헤드가 많다. TPU는 처음부터 이 행렬 연산만을 위해 설계됐다. 범용성은 포기하고, AI 워크로드 하나에 모든 설계를 집중시킨 전용 가속기다.
내부 구조를 보면 TPU는 Systolic Array라는 구조를 사용한다. 데이터가 칩 안에서 물처럼 흘러다니며 연산이 연쇄적으로 이루어지는 구조인데, 메모리와 연산 유닛 사이를 반복해서 오가는 GPU 방식보다 훨씬 에너지 효율적이다. 그리고 AI 학습과 추론에 쓰이는 bfloat16이라는 데이터 형식을 TPU는 하드웨어 수준에서 네이티브로 지원한다. GPU가 소프트웨어 레이어에서 처리해야 하는 것을 TPU는 칩 레벨에서 바로 처리한다.
TPU 세대별 진화 — Gemini 3를 돌리는 칩은 어디까지 왔나
TPU는 현재 7세대까지 나왔다. 세대별로 구조와 목적이 상당히 달라서 한 번 짚고 넘어가면 이해가 훨씬 쉬워진다.
TPU v4까지는 학습과 추론 모두를 하나의 아키텍처로 커버하는 범용 설계였다. v5 세대부터 Google은 전략을 바꿨다. TPU v5p는 대규모 학습에 특화된 고성능 버전이고, TPU v5e는 추론에 최적화된 비용 효율 버전으로 나뉘었다. 목적에 따라 칩 자체를 두 가지로 분리한 것이다. v5e 하나의 칩이 초당 393조 회의 INT8 연산을 처리할 수 있고, v5e 하나의 Pod 전체로 보면 초당 100 페타(Peta) 연산이 가능하다.
Gemini 2.0을 학습시키는 데 사용된 건 6세대 Trillium이다. Trillium은 v5e 대비 학습 성능이 4배 이상 개선됐고, 추론 처리량은 3배, 에너지 효율은 67% 향상됐다. 칩 하나당 최대 100,000개의 Trillium 칩이 Jupiter 네트워크 패브릭으로 연결되어 단일 분산 학습 작업을 수십만 개의 가속기에 걸쳐 확장할 수 있다.
그리고 2026년에 본격 출시 예정인 7세대 Ironwood가 현재 가장 주목받고 있다. Ironwood는 Google이 “추론의 시대(Age of Inference)”를 위해 설계했다고 공식 발표한 칩으로, 기존 세대와 다르게 처음부터 추론 워크로드에 최적화된 설계다. 칩 하나가 4.6 페타플롭스의 FP8 연산을 처리하고, 메모리는 192GB HBM3e에 대역폭 7.4TB/s다. 9,216개의 칩을 하나의 포드로 묶으면 42.5 엑사플롭스의 연산이 가능한데, 이건 이전까지 지구상에서 가장 강력하다는 슈퍼컴퓨터를 훨씬 넘어서는 수준이다. Gemini 2.5 같은 최신 추론 모델들이 이미 Ironwood 기반으로 실행되고 있다.
Vertex AI — 기업이 Gemini를 쓸 수 있는 통로
TPU가 물리적인 엔진이라면, Vertex AI는 그 엔진을 기업이 사용할 수 있게 연결해주는 플랫폼이다. Google Cloud에서 제공하는 Vertex AI는 크게 세 가지 역할을 한다.
첫째는 모델 서빙이다. 기업이 Gemini API를 호출할 때, 그 요청이 실제로 처리되는 곳이 Vertex AI의 TPU 클러스터다. 개발자는 API 하나만 연결하면 되고, 그 뒤에서 어떤 TPU 세대가 몇 개의 칩에서 추론을 처리하는지는 Google이 알아서 관리한다. 트래픽이 갑자기 몰려도 자동으로 스케일아웃된다.
둘째는 파인튜닝이다. Google의 기반 모델을 기업 데이터로 특화시키는 작업도 Vertex AI에서 이루어진다. TPU v5e 기준으로 v4 대비 LLM 파인튜닝 성능이 달러당 1.9배 개선됐다. 같은 예산으로 더 많은 파인튜닝 작업을 할 수 있다는 뜻이다.
셋째는 JetStream이다. JetStream은 Google이 오픈소스로 공개한 추론 엔진으로, Gemini 모델 서비스에 실제로 사용하는 것과 동일한 추론 스택을 기반으로 한다. Trillium TPU에서 JetStream을 사용하면 Llama 2 70B 기준으로 v5e 대비 처리량이 2.9배 향상된다. 기업이 오픈소스 모델을 TPU 위에서 효율적으로 서비스할 수 있는 도구를 Google이 직접 제공하는 셈이다.
Azure나 AWS도 GPU 클러스터를 빌려주는 방식으로 AI 추론 서비스를 제공하지만, Vertex AI는 Google의 TPU와 긴밀하게 통합된다는 점에서 구조적으로 다르다. 타사 클라우드는 NVIDIA 칩을 빌려서 서비스하는 반면, Vertex AI는 Google이 직접 설계한 칩 위에서 직접 만든 소프트웨어 스택으로 서비스한다. 이 수직 통합이 가격과 성능 양쪽에서 차이를 만든다.
Google Workspace 기업 고객이 Gemini in Chrome을 사용할 때 “엔터프라이즈 등급 데이터 보호”가 적용된다고 하는데, 그 구체적인 의미가 바로 이 Vertex AI 인프라 위에서 격리된 환경으로 처리된다는 것이다. 사용자의 브라우징 컨텍스트가 Gemini로 전달될 때, 그 데이터는 Google의 공유 소비자 인프라가 아닌 기업 전용 Vertex AI 환경에서 처리된다.
온디바이스 추론 — Gemini Nano가 내 노트북에서 실행되는 방식
클라우드 추론이 Gemini의 주축이라면, 온디바이스 추론은 완전히 다른 패러다임이다. Chrome에 내장된 Gemini Nano는 Google 서버에 요청을 보내지 않고, 사용자 기기 안에서 직접 모델을 실행한다.
Gemini Nano의 용량은 1.5GB에서 2.4GB 사이로, 4~6B 파라미터 규모의 모델로 추정된다. 처음 Chrome에서 AI 기능을 활성화하면 이 모델이 자동으로 다운로드된다. 한 번 다운로드되면 같은 기기에서 Chrome을 사용하는 모든 웹사이트와 익스텐션이 공유해서 사용할 수 있다. 따로 다시 다운로드할 필요가 없다.
실행 방식도 흥미롭다. 초기에는 GPU가 있는 기기에서만 동작했는데, 2025년 10월 Chrome 140 버전부터는 CPU에서도 실행되도록 확장됐다. Linux, macOS, Windows 모두 지원한다. GPU에서 실행하는 것보다 속도는 느리지만, 고성능 GPU가 없는 대부분의 일반 사용자 기기에서도 온디바이스 AI를 쓸 수 있게 된 것이다.
기술적으로는 LiteRT-LM이라는 프레임워크가 Gemini Nano의 실행을 담당한다. Google이 내부적으로 Chromebook Plus, Pixel Watch, Chrome 브라우저에 걸쳐 수억 개의 기기에 Gemini Nano를 배포할 때 실제로 사용하는 엔진이다. 세션 복제, KV 캐시 관리, 프롬프트 캐싱 같은 추론 최적화 기법이 모두 이 엔진 안에 포함되어 있다.
개발자 입장에서는 Prompt API를 통해 JavaScript에서 직접 Gemini Nano를 호출할 수 있다. 별도 API 키도 필요 없고, 요청당 비용도 없다. 서버를 거치지 않으니 당연히 레이턴시도 거의 없다. 특히 요약, 분류, 텍스트 재작성 같은 작업에서 온디바이스 추론이 유리하다. 민감한 데이터를 서버로 보내지 않아도 된다는 프라이버시 측면도 있다.
다만 한계도 있다. Gemini Nano는 대규모 추론이나 복잡한 멀티스텝 작업에는 적합하지 않다. 정확한 사실 기반 답변보다는 언어적 처리 작업에 최적화된 모델이다. Chrome에서 “웹페이지 요약해줘”, “이 문단 다시 써줘” 같은 가벼운 요청은 Nano가 로컬에서 처리하고, 복잡한 멀티탭 분석이나 에이전트 작업은 클라우드의 Gemini 3로 넘어가는 방식이다.
하이브리드 추론 구조 — 클라우드와 엣지의 조합
개발자나 클라우드 엔지니어 입장에서 “온디바이스면 서버 비용이 없으니까 좋은 거 아닌가”라고 단순하게 생각하기 쉽다. 나도 처음엔 그렇게 봤다. 근데 실제로 AI 추론 시스템을 설계해보면 그게 전혀 단순한 문제가 아니라는 걸 금방 알게 된다.
Chrome + Gemini의 실제 추론 구조는 단순히 “클라우드냐 온디바이스냐”의 이분법이 아니다. 작업의 복잡도와 프라이버시 요건에 따라 두 가지를 조합하는 하이브리드 구조다.
단순한 텍스트 처리 → Gemini Nano, 로컬 실행 멀티탭 컨텍스트 분석, 복잡한 질의 → Gemini 3, Vertex AI TPU 클러스터 기업 사용자의 Workspace 통합 작업 → 엔터프라이즈 Vertex AI 환경
이 구조가 중요한 이유는 비용과 속도와 프라이버시를 동시에 잡을 수 있기 때문이다. 온디바이스에서 처리 가능한 작업은 서버 비용이 들지 않고 응답도 빠르다. 무거운 작업은 TPU 클러스터에서 처리해 품질을 유지한다. Pathways라는 Google의 분산 ML 런타임이 이 워크로드 분배를 담당한다. 수천 개의 TPU 칩에 작업을 나눠 처리하면서도 단일 모델처럼 동작하게 만드는 오케스트레이션 레이어다.
Azure나 AWS가 GPU 기반 인프라를 대여해주는 방식과 Google이 다른 점이 바로 이 수직 통합이다. Google은 칩 설계(TPU), 칩 위에서 돌아가는 ML 프레임워크(JAX, XLA), 분산 런타임(Pathways), 서비스 플랫폼(Vertex AI), 그리고 최종 모델(Gemini)까지 전체 스택을 직접 만든다. 중간에 서드파티 의존성이 없다는 것은 최적화의 여지가 극도로 크다는 뜻이다.
TPU vs GPU — 어떤 상황에서 무엇을 쓸까
이 질문은 개발자들이 실제로 많이 하는 질문이다. 결론부터 말하면, 대규모 LLM 추론에서는 TPU가 경제적으로 압도적으로 유리하지만 생태계 종속성을 감수해야 한다.
실제 사례를 보면 이해가 빠르다. Midjourney는 이미지 생성 추론 인프라를 NVIDIA GPU에서 TPU v6e로 전환했고, 월 추론 비용을 210만 달러에서 70만 달러로 줄였다. 같은 워크로드에서 65% 절감이다. 한 컴퓨터 비전 스타트업은 H100 GPU 128장에서 TPU v6e로 이전하면서 월 비용이 34만 달러에서 8만9천 달러로 내려갔다.
TPU가 저렴한 건 여러 이유가 복합적이다. 가장 큰 건 전력 효율이다. 동일한 워크로드에서 GPU 대비 60~65% 전력 소모가 적다. 데이터센터 냉각 비용까지 포함하면 운영비 차이가 더 벌어진다. Google이 칩 설계부터 데이터센터까지 수직 통합하면서 NVIDIA처럼 외부 마진이 얹히지 않는다는 점도 가격 경쟁력의 원천이다.
하지만 단점도 명확하다. TPU는 Google Cloud에서만 사용할 수 있다. 멀티클라우드나 온프레미스 전략을 가진 조직은 TPU를 선택할 수 없다. 그리고 생태계가 JAX와 TensorFlow 중심이라, PyTorch 코드베이스가 많은 팀은 전환 비용이 크다. vLLM도 최근 TPU 백엔드를 지원하기 시작했지만 GPU 대비 성숙도는 아직 차이가 있다.
현실적인 기준을 하나 제시하면, 월 추론 비용이 5만 달러를 넘는 시점부터 TPU 전환이 경제적으로 의미있는 수준이 된다. 그 아래 규모에서는 생태계 전환 비용이 절감액을 상쇄할 가능성이 높다. 반대로 대규모 안정적 LLM 추론 워크로드라면, 규모가 커질수록 TPU의 비용 절감 효과도 복리처럼 쌓인다.
Anthropic이 2025년 11월 Google 역사상 최대 규모의 TPU 계약을 체결하면서 2026년에 수십만 개의 Trillium 칩을, 2027년까지 100만 개까지 확장하는 계획을 발표한 것은, TPU의 경제성에 대한 업계의 판단을 상징적으로 보여주는 사례다.
마무리 : Gemini 인프라가 Chrome과 만났을 때 벌어지는 일
여기까지 읽었다면 Gemini in Chrome이 단순히 브라우저에 챗봇 하나 붙인 수준이 아니라는 게 느껴질 것이다.
Chrome 안에서 사용자가 “이 논문 요약해줘”라고 말하는 순간, 경량 요청은 내 노트북에서 Gemini Nano가 LiteRT-LM으로 처리하고, 무거운 멀티탭 분석 요청은 Google의 Vertex AI TPU 클러스터, 구체적으로는 Trillium 혹은 Ironwood 위의 Gemini 3으로 넘어간다. 그 사이 Pathways가 수천 개의 칩에 작업을 분산하고 JetStream이 추론을 최적화해서 응답을 돌려보낸다.
이 인프라를 경쟁자가 단기간에 따라잡는 건 매우 어렵다. TPU 설계에만 10년 넘는 노하우가 쌓여 있고, 그 위에서 JAX, XLA, Pathways, Vertex AI가 긴밀하게 맞물려 있다. OpenAI는 NVIDIA GPU와 Microsoft Azure에 의존하는 구조고, Anthropic은 아이러니하게도 Google의 TPU를 빌려 쓰는 구조다. Google만이 자신의 AI 인프라 전체를 직접 소유하고 운영한다.
브라우저가 AI 플랫폼이 되는 데는 사용자 인터페이스의 변화만으로는 부족하다. 그 아래에서 초당 수십억 건의 추론을 감당할 수 있는 인프라가 받쳐줘야 한다. Gemini in Chrome이 진짜 강력한 이유의 절반은 화면에 보이는 사이드바가 아니라, 그 아래 보이지 않는 TPU 클러스터에 있다.
AI 시대에 누가 인프라를 가지고 있는가의 문제는, 단순한 기술 선택의 문제가 아니다. 누가 AI 플랫폼의 주도권을 쥐는가의 문제다. Google이 Chrome에 Gemini를 넣은 것은 그 인프라 위에 사용자와의 접점을 직접 만들어버리는 전략이다. 그리고 그 접점의 품질은 결국 TPU, Vertex AI, LiteRT-LM으로 이어지는 인프라 스택이 결정한다. 기술이 보이지 않을수록, 그 기술이 더 깊숙이 박혀 있다는 증거다.
전반적인 Chrome + Gemini 관련 글을 찾는다면, “브라우저가 AI 플랫폼이 되는 순간, 인터넷 패러다임이 바뀐다” 이 글을 읽어보길 바란다.