Google이 Cloud Next 2026에서 TPU 8i와 TPU 8t를 따로 소개한 건 단순한 칩 발표가 아닙니다. 메시지가 분명합니다. 이제 AI 인프라는 "모델 학습용 GPU/TPU" 하나로 퉁칠 수 없고, 에이전트 추론과 대규모 학습을 다른 기준으로 봐야 한다는 뜻입니다. 실무 개발자 입장에서는 이 변화가 꽤 중요합니다. 지금까지는 모델 크기와 시간당 비용만 비교했다면, 앞으로는 "무슨 워크로드를 돌리느냐"가 인프라 선택의 첫 질문이 됩니다.
Google 설명을 그대로 요약하면 TPU 8i는 에이전트처럼 빠른 반응성이 중요한 추론용에 맞춰졌고, TPU 8t는 학습 중심, 특히 큰 메모리 풀을 요구하는 복잡한 모델 훈련에 맞춰졌습니다. 이 차이가 중요한 이유는 에이전트 워크로드의 병목이 단순 FLOPS가 아니기 때문입니다. 에이전트는 추론 한 번으로 끝나지 않습니다. 계획하고, 툴을 호출하고, 중간 결과를 확인하고, 다시 다음 행동을 정하는 다단계 루프를 거칩니다. 여기서는 최고 성능 숫자보다 지연 시간과 응답 일관성이 더 직접적인 품질 지표가 됩니다.
반대로 학습은 긴 시간 동안 대량 데이터를 안정적으로 밀어 넣고, 큰 모델 상태를 유지하고, 병렬화 효율을 뽑아내는 쪽이 더 중요합니다. Google이 TPU 8t를 "single, massive pool of memory"라는 표현으로 설명한 것도 그래서입니다. 즉 둘은 이름만 다른 같은 제품이 아니라, 다른 종류의 병목을 겨냥한 인프라라고 봐야 합니다.
2024~2025년에는 많은 팀이 "모델을 서빙한다"는 개념으로 인프라를 봤습니다. 그런데 2026년의 에이전트 제품은 그보다 훨씬 복잡합니다. 한 번의 요청 안에서 검색, 도구 호출, 장문 문맥 유지, 멀티스텝 검증이 이어집니다. 사용자가 체감하는 성능은 모델 파라미터 수보다 "첫 토큰이 언제 나오느냐", "도구 호출이 이어져도 중간 지연이 버티느냐", "동시 요청이 많을 때 꼬이지 않느냐"에 더 가깝습니다.
이 때문에 추론 인프라를 학습 인프라와 같은 기준으로 최적화하면 어긋나는 경우가 많습니다. 예를 들어 배치 효율을 극단적으로 높이면 개별 요청 지연이 나빠질 수 있고, 메모리 최적화를 위해 컨텍스트를 공격적으로 잘라내면 에이전트 품질이 불안정해질 수 있습니다. TPU 8i 같은 분화된 추론 인프라가 등장했다는 건 대형 사업자들도 이 문제를 제품 차원에서 받아들였다는 신호입니다.
첫째, 학습과 추론 예산을 분리해서 봐야 합니다. 하나의 클러스터가 둘 다 처리하면 깔끔해 보이지만, 실제로는 비용 회계와 성능 최적화가 섞여 버립니다. 연구 조직이 자주 빠지는 함정이 "학습 장비가 남으니 서빙도 여기서 하자"인데, 이건 초기에는 편해도 운영 단계에서 불리한 경우가 많습니다. 에이전트 제품은 야간보다 업무시간 피크가 훨씬 중요하고, 학습은 반대로 장시간 점유가 핵심이어서 스케줄 특성이 다릅니다.
둘째, 응답성 지표를 더 구체적으로 쪼개야 합니다. 평균 지연 시간만 보면 안 됩니다. 첫 토큰 지연, 툴 호출 간 왕복 시간, 장문 컨텍스트 유지 시 p95 지연, 동시성 증가 시 실패율 같은 지표가 더 중요합니다. 에이전트는 한 번 느리면 전체 경험이 무너집니다. 사용자는 내부적으로 6단계 추론을 했는지 관심이 없고, 그냥 "왜 이렇게 버벅거리냐"만 느낍니다.
셋째, 메모리 구조와 컨텍스트 길이 정책을 같이 설계해야 합니다. 긴 문맥을 다룰 수 있다는 말과, 실제 서비스에서 그 문맥을 경제적으로 돌릴 수 있다는 말은 다릅니다. 학습용 대규모 메모리 풀이 필요할 때와, 추론에서 여러 세션을 동시에 붙들어야 할 때의 최적점은 다릅니다. 인프라 발표를 읽을 때 단순히 "더 세졌다"보다 "우리 워크로드의 병목이 메모리인지 지연인지 처리량인지"를 먼저 물어야 합니다.
현실적으로 대부분의 팀은 TPU 8i, 8t 같은 최신 인프라를 당장 직접 쓰지 못할 수도 있습니다. 그래도 발표에서 가져갈 실무 교훈은 분명합니다. 바로 "워크로드별 분리"입니다. 이를테면 다음처럼 생각하면 됩니다.
이렇게 나누면 클라우드 상품을 고를 때도 질문이 달라집니다. "이 인스턴스가 제일 빠르냐"가 아니라 "우리의 에이전트 루프에서 p95를 지킬 수 있나", "동시 세션 100개에서 메모리 스와핑 없이 버티나", "학습과 운영을 같은 풀에 넣었을 때 장애 전파가 생기지 않나"를 보게 됩니다.
또 하나 중요한 건 관측성입니다. 에이전트 인프라는 CPU/GPU 사용률만 보면 부족합니다. 툴 호출 지연, 라우팅 실패, 세션별 토큰 편차, 리트라이 횟수 같은 애플리케이션 레벨 지표가 인프라 병목을 더 잘 설명합니다. 하드웨어가 좋아도 오케스트레이션이 엉망이면 사용자는 그냥 느리다고 느낍니다.
작은 팀일수록 이번 발표를 "대기업 뉴스"로 넘기면 아깝습니다. 오히려 스타트업은 자원이 제한적이기 때문에 워크로드를 섞지 않는 설계가 더 중요합니다. 초기 MVP라도 학습, 추론, 오프라인 배치를 하나의 자원 풀에 모두 몰아넣으면 원인 분석이 어려워지고 비용도 흐려집니다. 제품이 잘 되기 시작했을 때 가장 먼저 무너지는 부분이 바로 여기입니다.
그리고 에이전트 제품은 모델 선택 못지않게 운영 환경 선택이 경쟁력입니다. 비슷한 모델을 써도 어떤 팀은 빠르고 안정적이고, 어떤 팀은 늘 버벅이는 이유가 여기에 있습니다. 결국 "좋은 모델"과 "맞는 인프라"는 별개의 문제입니다. TPU 8i와 TPU 8t가 던진 메시지는, 앞으로 이 둘을 함께 설계하는 팀이 유리하다는 겁니다.
앞으로 에이전트 시대의 인프라 의사결정은 더 세분화될 가능성이 큽니다. 학습용, 추론용, 멀티모달용, 초저지연용으로 계속 갈라질 수 있습니다. 이 흐름에서 중요한 건 특정 벤더를 따라가는 게 아니라, 내 서비스의 병목을 정확히 아는 겁니다. 그래야 새로운 칩 발표가 나올 때도 마케팅 문구가 아니라 운영 기준으로 읽을 수 있습니다.
실무 체크리스트로 마무리하겠습니다.
참고 소스: Google Keyword, Google introduces new TPUs at Cloud Next ‘26 (2026-04-22)
