2026.10.15 · 네이버 프리미엄 콘텐츠 · 올바른 미국주식 by SAPIENS

구글 AI 인프라 총괄 인터뷰 : $200B를 쏟아붓는 구글, Goodput과 OCS가 중요한 이유

네이버 프리미엄 콘텐츠 원문 보기 별의순간 텔레 요약 바로가기 분석 기준 보기

유형

네이버 프리미엄 콘텐츠

날짜

2026.10.15

강연자/작성자

올바른 미국주식 by SAPIENS

분석 주제

미지정

자료 길이

본문 50,297자

문서 전체 조망

핵심 구조

AI 인프라의 성과 기준이 칩 스펙에서 시스템의 유효 작업으로 옮겨간다

이 인터뷰는 구글이 대규모 AI 인프라를 가속기만이 아니라 건물·전력·냉각·네트워크·소프트웨어까지 함께 설계하는 이유를 다룬다.

수십만 개의 가속기를 실제로 돌릴 때는 이론 성능보다 장애와 대기를 뺀 Goodput이 중요해지고, 그 설계 선택이 데이터센터 확장의 병목과 연결된다.

AI 데이터센터는 범용 건물이 아니라 특정 가속기 시스템의 일부다

기존 데이터센터는 여러 세대 장비를 담기 위해 범용적으로 설계했지만, AI 데이터센터는 TPU·GPU 랙의 전력 밀도·발열·통신량에 맞춰 건물·전력·냉각·네트워크를 함께 맞춘다.
일반 스토리지 랙은 10~40kW인 반면 TPU·GPU 랙은 수백 kW이며 앞으로 MW급 가능성까지 제시돼, 용도를 먼저 정하는 설계가 중요해진다.

Goodput은 시스템이 실제 결과를 만든 비율을 본다

FLOPS와 Throughput은 최대 처리량을 보여주지만, 대규모 학습·추론에서는 장애·복구·중복 연산·대기 때문에 스펙상 연산이 모두 결과로 이어지지 않는다.
Program·Runtime·Scheduling Goodput을 곱한 유효 연산 효율은 같은 수의 칩을 갖춰도 실제 학습 능력이 달라질 수 있음을 보여준다.

OCS는 고장 회피와 통신 최적화를 함께 맡는다

광회로스위치(OCS)는 소프트웨어로 물리적 광 연결을 바꿔 정상 Cube를 다시 묶고, 작업의 통신 패턴에 맞는 토폴로지를 만들 수 있다.
TPU v4의 자원 재구성과 v8t의 링크 장애 우회, v8i의 Boardfly 연결은 개별 칩 성능을 바꾸지 않고도 복구 시간과 통신 대기를 줄여 Goodput을 높이려는 사례로 제시된다.

ASIC의 경제성은 특화 성능과 수요 지속성의 균형에 달렸다

TPU는 음성인식의 급증하는 계산 수요에서 출발했지만, 트랜스포머·추천·생성형 AI로 용도가 넓어지며 더 범용적인 AI 컴퓨팅 시스템이 됐다.
특정 작업에 특화할수록 유연성이 줄어들기 때문에, 원문은 향후 3~4년의 워크로드 규모·성장·지속 기간과 훈련·추론 간 자원 전환 가능성을 함께 판단해야 한다고 설명한다.

공동 설계는 여러 층의 개선을 누적하지만 tape-out을 늦출 수도 있다

DeepMind와 인프라 팀의 공동 설계는 모델 구조·컴파일러·칩·네트워크를 함께 맞춰 한 층의 개선이 모든 워크로드에 곱셈으로 퍼지게 한다.
반대로 더 나은 선택이 보일 때 tape-out을 미루는 일도 생기며, 원문은 수년 간 5~6개 세대를 병렬로 검토하고 시뮬레이션으로 균형점을 찾는 과정 자체를 경쟁력으로 본다.

확장의 가장 근본적인 제약은 전력이며, 해법은 아직 조건부다

에이전트는 사람이 입력하는 속도를 넘어 계속 작업하므로 CPU·스토리지·네트워크의 오케스트레이션 수요도 키운다.
전력망 협력, 직접 발전, 지역별 추론센터, 우주 태양광은 모두 검토 대상이지만 냉각·수리·네트워킹·비용이라는 제약이 남아 있어, 우주 데이터센터는 실제 투자 중인 문샷이면서도 해결 과제가 많은 방향으로 제시된다.

사실·구조, 해석·전망, 시점 관찰, 판단 방법

지식·관점

사건 밖에서도 다시 참고하거나 다른 자료와 비교할 가치가 있는 내용을 대상과 반복 가능한 논점으로 묶습니다.

사실·구조AI 데이터센터 설계주 대상 · 산업·업종 · AI 데이터센터

AI 데이터센터는 왜 가속기와 건물·전력·냉각·네트워크를 함께 설계하는가?

이 자료가 더한 내용

AI 가속기 랙의 전력 밀도와 네트워크 요구가 스토리지 랙과 다르므로, 특정 하드웨어 용도에 맞춰 건물·전력 공급·냉각·네트워크를 함께 최적화해야 한다고 설명했다.

근거 보기 2

원문 구간 1
소냐 황 : 본격적으로 들어가기 전에 청취자들을 위해 기초적인 질문부터 드리겠습니다. AI 데이터센터는 무엇이고, 기존의 비AI 데이터센터와는 어떻게 다른가요? 아민 바흐다트 : 좋은 질문입니다. 사실 AI 데이터센터와 기존 데이터센터는 공통점이 많습니다. 둘 다 콘크리트로 지은 건물 안에 전력 설비와 냉각 시스템을 갖춰야 합니다. 대규모 연산 장치를 서로 연결하는 네트워크 인프라도 필요하고, 상당한 규모의 스토리지도 들어갑니다. 가장 큰 차이는 얼마나 특정 목적에 맞춰 설계하느냐에 있습니다. 과거에는 데이터센터 건물을 지을 때 20~30년을 내다보고 설계했습니다. 그동안 어떤 서버와 네트워크 장비, 스토리지, 가속기가 들어올지 알 수 없었기 때문에 최대한 범용적으로 만들어야 했습니다. 하드웨어의 수명은 보통 6년 정도이니 하나의 건물에서 여러 세대의 장비를 수용할 수 있어야 했던 것이죠. 그런데 AI 데이터센터는 접근 방식이 다릅니다. 처음부터 특정 용도에 맞춰 건물과 하드웨어를 함께 설계하는 경우가 많습니다. 예를 들어 어떤 데이터센터에는 스토리지를 거의 넣지 않기로 결정할 수도 있습니다. 일반적인 스토리지 랙은 전력 사용량이 10~40kW 정도이지만, 오늘날의 TPU나 GPU 랙은 수백 kW에 달합니다. 앞으로는 랙당 전력 사용량이 MW급까지 올라갈 수도 있습니다. 이렇게 되면 스토리지 랙 30개를 배치하는 공간과 AI 가속기 랙 한두 개를 배치하는 공간은 설계부터 완전히 달라집니다. 필요한 공간의 크기뿐만 아니라 전력 공급 방식과 네트워크 요구사항도 크게 다릅니다. 특히 HDD 중심의 스토리지 랙은 AI 가속기 랙에 비해 네트워크 대역폭 요구량이 훨씬 적습니다.
원문 구간 2
그런데 모든 종류의 장비를 수용할 수 있도록 데이터센터를 설계한다면 어떻게 될까요? 건물을 필요 이상으로 크게 지어야 하거나 전력과 냉각 설비를 과도하게 구축해야 할 수도 있습니다. 그렇다고 이런 범용성을 앞으로 30년 동안 유지하는 것도 현실적으로 어렵습니다. 그래서 AI 데이터센터는 처음부터 목적을 명확하게 정하고 설계하는 것이 중요합니다. 어떤 하드웨어가 들어갈지에 맞춰 건물을 설계하고, 전력 공급부터 냉각 시스템까지 함께 최적화해야 한다는 것입니다. *코멘트 → AI 데이터센터는 단순히 GPU나 TPU를 많이 설치하는 건물이 아닙니다. 처음부터 가속기의 전력 소비량과 발열량, 네트워크 구조를 고려해 건물과 전력/냉각 인프라를 함께 설계해야 합니다. 이를 System-level Co-design이라고 합니다. 특히 엔비디아 GB200 NVL72는 랙당 약 120kW의 전력을 소비하며, 차세대 AI 랙은 수백 kW에서 최대 1MW까지 높아질 가능성이 있습니다. 이 정도 전력 밀도에서는 기존의 전력 공급과 공랭식 냉각만으로 대응하기 어렵습니다. 액체냉각과 새로운 전력 공급 방식이 중요해지는 이유입니다. 네트워크도 마찬가지입니다. AI 가속기끼리 막대한 데이터를 주고받기 때문에 일반적인 스토리지 네트워크와 분리하고, 가속기 간 통신에 최적화된 네트워크를 구축해야 합니다. 소냐 황 : 제 포트폴리오 기업인 Ineffable Intelligence에 대규모 베어메탈 클러스터를 공급하셨을 때 출하 당시 사진을 봤습니다. 정말 멋지더군요. *코멘트 → 소냐 황이 언급한 것은 구글이 데이비드 실버(David Silver)의 AI 스타트업 Ineffable Intelligence에 공급한 엔비디아 Vera Rubin 기반 AI 슈퍼컴퓨터입니다.

사실·구조ML 생산성주 대상 · 산업·업종 · AI 인프라

대규모 AI 시스템의 실제 성과는 어떻게 측정하는가?

이 자료가 더한 내용

이론 FLOPS나 Throughput만이 아니라 장애·복구·중복 연산·대기를 반영한 Goodput을 보며, Program·Runtime·Scheduling Goodput의 곱으로 유효 연산 효율을 설명했다.

근거 보기 4

원문 구간 1
소냐 황 : 그 사진을 보고 정말 소름이 돋았습니다. 그런데 이렇게 거대한 규모의 인프라를 구축할 때는 어떤 기준으로 성과를 측정하고 그 결과에 대한 책임을 지시나요? 인터뷰를 시작하기 전에 FLOPS만으로는 실제 성과를 제대로 측정하기 어렵고, 다른 지표를 더 중요하게 보신다고 말씀하셨는데요. 그 부분을 좀 더 자세히 설명해 주시겠습니까? 아민 바흐다트 : FLOPS를 비롯해 칩의 성능을 나타내는 지표들은 대부분 이론적인 수치입니다. 특정 조건에서 그 칩이 낼 수 있는 최대 연산 성능을 보여주는 것이죠. 하지만 저희가 정말 중요하게 생각하는 것은 실제 워크로드를 실행했을 때 얼마나 높은 성능이 나오는가입니다. 실제 성능은 칩 하나만으로 결정되지 않습니다. FLOPS도 중요하고 HBM이나 SRAM의 용량도 중요합니다. 하지만 더 중요한 것은 이런 칩들을 2개, 4개, 8개, 16개씩 연결하고, 나아가 수천 개에서 수만 개까지 확장했을 때 시스템 전체가 얼마나 효율적으로 작동하느냐입니다. TPU나 GPU 같은 가속기뿐만 아니라 여기에 데이터를 공급하는 CPU와 가속기들을 연결하는 네트워크까지 모두 성능에 영향을 미칩니다. 그래서 저희는 어떤 워크로드를 실행하고 있는지, 그리고 그 워크로드에서 실제로 얼마나 높은 성능을 달성하는지를 중요하게 봅니다. 이때 유용하게 사용할 수 있는 지표 중 하나가 FLOPS 활용률입니다. 예를 들어 어떤 시스템이 이론적으로 수백 테라플롭스나 수 페타플롭스의 연산 성능을 낼 수 있다고 해보겠습니다. 중요한 것은 실제 워크로드를 실행했을 때 그 이론적인 성능의 몇 퍼센트를 활용할 수 있느냐는 것입니다. 이것이 저희가 말하는 Goodput, 즉 실제로 유효한 작업을 얼마나 처리할 수 있는지를 이해하는 출발점입니다.
원문 구간 2
소냐 황 : Goodput이 정확히 무엇인가요? 아민 바흐다트 : 먼저 일반적으로 사용하는 Throughput이라는 개념부터 생각해 보겠습니다. Throughput은 시스템이 얼마나 많은 작업을 처리할 수 있는지를 보여주는 지표입니다. 그런데 실제 워크로드에는 여러 가지 비효율이 존재합니다. 특히 중요한 것이 시스템의 신뢰성입니다. AI 학습이나 추론 서빙, 에이전트 워크로드에서는 수많은 구성 요소가 서로 긴밀하게 동기화되어 작동해야 하는 경우가 많습니다. 수천 개에서 수만 개, 심지어 10만 개에 달하는 구성 요소가 마이크로초 또는 밀리초 단위로 서로 협력해야 한다고 생각해 보세요. 그런데 그중 하나라도 고장 나면 어떻게 될까요? 전체 시스템이 멈출 수도 있습니다. 그러면 어디에서 문제가 발생했는지 찾아내야 하고, 마지막 체크포인트가 어디인지 확인한 다음 시스템을 복구해서 다시 실행해야 합니다. 최악의 경우에는 처음부터 작업을 다시 시작해야 할 수도 있습니다. 실제로 추론 과정에서도 이런 일이 발생할 수 있습니다. 이 과정에서 이미 수행했던 연산을 다시 실행하거나 오류의 원인을 찾아내느라 시간을 허비하게 됩니다. 분명 시스템은 계속 일을 하고 있지만, 정작 최종 결과를 만들어내는 데는 아무런 도움이 되지 않는 작업들입니다. 종이에 수학 문제를 푼다고 생각해 보겠습니다. 1단계부터 4단계까지 열심히 풀었는데 중간에 실수를 발견해서 다시 1단계로 돌아가야 한다면 어떨까요? 분명 그동안 계속 문제를 풀고 있었던 것은 맞습니다. 하지만 정답에 도달하는 데 실제로 기여한 작업은 얼마나 될까요? 저희가 중요하게 생각하는 것이 바로 이 차이입니다.
원문 구간 3
시스템 장애와 복구, 중복 연산, 대기 시간까지 모두 고려했을 때 실제로 얼마나 많은 유용한 결과를 만들어냈는지를 봐야 합니다. 단순히 이론적인 벤치마크에서 얼마나 높은 Throughput을 기록했느냐가 아니라, 실제 워크로드에서 얼마나 높은 Goodput을 달성했느냐로 저희의 성과를 평가해야 한다는 것입니다. 그런데 안타깝게도 가속기가 10만 개에 달하는 규모가 되면… 소냐 황 : 마침 그걸 여쭤보려고 했습니다. 그 정도 규모라면 시스템 어딘가에서는 항상 장애가 발생하고 있을 것 같은데요. 아민 바흐다트 : 항상 그렇습니다. 사실 칩 하나하나가 정말 놀라운 기술의 결정체입니다. 인류가 만들어낼 수 있는 가장 최첨단의 반도체 기술이 집약되어 있죠. 게다가 겉으로는 하나의 칩처럼 보이지만, 실제로는 그 패키지 안에 2개, 4개, 8개 또는 그 이상의 칩렛이 들어갈 수도 있습니다. 주변에는 HBM이 있고 네트워크 연결도 필요합니다. 경우에 따라서는 CPO(Co-Packaged Optics) 같은 기술까지 적용됩니다. 그만큼 고장이 발생할 수 있는 지점이 굉장히 많다는 뜻입니다. 이런 가속기가 10만 개씩 모여 있는 시스템이라면 어딘가에서 문제가 발생하는 것은 사실상 피할 수 없습니다. 따라서 장애가 발생했을 때 거의 실시간으로 탐지하고 복구할 수 있는 체계를 갖춰야 합니다. 그런데 이게 정말 어려운 텔레메트리 문제입니다. 수많은 장비에서 발생하는 데이터를 분석해 정확히 어디에서 문제가 생겼는지 찾아내야 하니까요. 말 그대로 건초더미에서 바늘을 찾는 것과 같습니다. 어떤 문제는 몇 초나 몇 분 안에 해결해야 하고, 워크로드에 따라서는 몇 시간, 며칠, 심지어 몇 주에 걸쳐 이런 작업을 계속 수행해야 할 수도 있습니다.
원문 구간 4
그래서 예를 들어 가상의 클러스터에서 Program Goodput이 60%, Runtime Goodput이 80%, Scheduling Goodput이 90%라면 전체 유효 연산 효율은 약 43.2%입니다. 같은 TPU 10만 개를 보유하더라도 Goodput이 다른 두 기업의 실제 학습 능력은 상당히 달라질 수 있습니다. 그런 의미에서 '같은 칩을 사도 같은 성능이 나오지 않는 시대'란 것입니다. 여기서 OCS는 주로 Scheduling Goodput과 Runtime Goodput을 개선합니다. 네트워크 토폴로지까지 최적화하는 경우에는 Program Goodput도 높일 수 있습니다. 그럼 모든 면에서 성능을 끌어올릴 수 있는 게 아닌가 싶으실텐데, 맞습니다. 그래서 OCS가 굉장히 중요하고 단순한 Components가 아니라 Systems임을 강조드리는 것입니다. 2. OCS는 고장난 칩을 어떻게 우회하는가? OCS의 본질은 소프트웨어로 물리적인 연결을 변경할 수 있다는 점입니다. OCS의 반대를 표현하자면 EPS입니다. 각각 Optical Circuit Switching과 Electrical Packet Switch입니다. EPS는 광 → 전기 → 광 변환을 통해서 패킷별로 목적지를 판단해주는 것이고, OCS는 광학적으로 포트와 포트 사이의 경로를 연결해주는 것입니다. 구글의 MEMS 방식 OCS는 미세한 거울을 움직여 광섬유의 연결 상대를 바꿉니다. 한 번 회로가 설정되면 별도의 광-전기-광 변환 없이 데이터가 그 광 경로를 통과합니다. 특히 중요한 것은 OCS가 네트워크 연결을 물리적 배선을 다시 설치하지 않고도 재구성할 수 있는 자원으로 바꿔놓는다는 점입니다.

사실·구조광회로스위치 OCS주 대상 · 기술·제품 · 광회로스위치관련 대상 · 산업·업종 · AI 인프라

OCS는 대규모 TPU 시스템의 Goodput에 어떻게 작용하는가?

이 자료가 더한 내용

OCS는 고장 난 Cube를 피해 정상 자원을 다시 연결하고, 분산학습 통신 패턴에 맞춰 네트워크 토폴로지를 바꿔 Scheduling·Runtime Goodput과 경우에 따라 Program Goodput을 높이는 방식으로 설명됐다.

근거 보기 4

원문 구간 1
실질적인 예시는 TPU v4 논문에서 나온 바 있습니다. 논문의 이름부터가 <TPU v4: An Optically Reconfigurable Supercomputer for Machine Learning with Hardware Support for Embeddings>입니다. 이 방식을 TPU v7, v8도 모두 사용하고 있기 때문에 기본적으로 스케일만 더 커졌을 뿐 핵심 역할과 구조는 같습니다. 그래서 한 번 자세히 살펴볼만 합니다. 구글은 TPU v4에서 4,096개의 칩을 64개씩 묶은 Cube 64개로 구성했습니다. Cube 내부 연결은 고정된 전기 배선으로 유지하면서 Cube와 Cube 사이의 광 연결을 OCS로 재구성합니다. 예를 들어 256개 TPU가 필요한 작업이 있다고 하겠습니다 고정형 네트워크에서는 물리적으로 필요한 형태로 연결된 연속된 TPU 자원을 확보해야 합니다. OCS 기반 네트워크에서는 서로 떨어져 있는 정상 Cube 네 개를 선택해 하나의 256개 TPU Slice를 만들 수 있습니다. 고장난 Cube가 있더라도 다른 정상 Cube를 선택해 필요한 토폴로지를 구성할 수 있습니다. 그러면 결과적으로 구글은 실제 TPU v4 시스템에서 OCS를 적용하면 CPU 호스트에 요구되는 가용성 수준을 99.9%에서 99%까지 낮추면서도 대규모 작업에 필요한 자원을 확보할 수 있다고 설명했습니다. 이는 개별 하드웨어의 신뢰성이 완벽하지 않더라도 전체 시스템의 가용성을 높일 수 있다는 뜻입니다. 3. OCS는 장애 복구뿐 아니라 실제 학습 속도도 높입니다 앞서 OCS를 이용하면 고장난 장비를 우회하고 정상적인 TPU들을 다시 연결해 자원 활용률을 높일 수 있다고 설명했습니다.
원문 구간 2
그런데 OCS의 역할은 여기서 끝나지 않습니다. 학습 모델의 통신 패턴에 맞춰 TPU 사이의 네트워크 연결 구조 자체를 최적화할 수 있다는 점도 중요합니다. 대규모 분산학습에서는 수많은 TPU가 나눠 계산한 중간 결과와 그래디언트를 서로 주고받아야 합니다. 이 과정에서 All-reduce, All-gather, All-to-all 같은 Collective Communication이 반복적으로 발생합니다. 문제는 TPU의 연산 성능이 아무리 높더라도 네트워크가 데이터를 제때 전달하지 못하면 다른 TPU들이 기다려야 한다는 점입니다. 특히 수천 개의 TPU가 동기화되어 작동하는 환경에서는 일부 장비나 통신 경로의 지연이 전체 학습 속도를 떨어뜨릴 수 있습니다. 이를 하나의 학습 단계에 걸리는 시간으로 단순화하면 다음과 같습니다. → Step = Compute Time + Exposed Communication + Straggler입니다. Compute Time : TPU가 실제 연산을 수행하는 시간 Exposed Communication : 연산과 동시에 처리하지 못해 추가로 소요되는 통신 시간 Straggler Delay : 다른 TPU보다 느린 장비나 통신 경로를 기다리면서 발생하는 추가 지연시간 여기서 OCS는 TPU 사이의 연결 구조를 변경해 통신 패턴에 적합한 네트워크를 구성할 수 있습니다. 이를 통해 통신 병목과 대기 시간을 줄이면 칩의 FLOPS를 높이지 않고도 동일한 학습 단계를 더 빠르게 완료할 수 있습니다. 결국 OCS는 장애로 인한 연산 손실을 줄이는 것뿐 아니라, 정상적으로 작동하는 상황에서도 네트워크 효율을 높여 실제 학습 처리량을 개선할 수 있는 기술입니다.
원문 구간 3
이는 앞서 설명한 Program Goodput 개선으로 이어집니다. 4. TPU v8에서 Goodput과 OCS의 역할은 어떻게 진화했는가? 구글이 TPU v8을 훈련용 v8t와 추론용 v8i로 나누고 서로 다른 네트워크 토폴로지를 채택한 이유는 두 워크로드의 병목이 다르기 때문입니다. 이를 Goodput 관점에서 살펴보면 구글의 설계 방향을 더 명확하게 이해할 수 있습니다. ① TPU v8t : 대규모 학습에서 장애로 인한 중단 시간을 최소화 구글은 TPU v8t를 설계하면서 97% 이상의 Goodput을 목표로 제시했습니다. 여기서 97%는 이론적 FLOPS 활용률이 아니라 실제로 유용한 학습에 시간을 얼마나 사용할 수 있는지를 의미합니다. 이를 위해 실시간 텔레메트리로 장애를 탐지하고, 문제가 발생한 ICI 링크를 자동으로 우회하거나 OCS를 통해 네트워크 연결을 재구성하는 기술을 도입했습니다. 기존 TPU v4에서는 장애가 발생하면 작업을 중단하고 정상 장비에 다시 배치한 다음 마지막 체크포인트부터 학습을 재개하는 방식에 의존했습니다. 반면 TPU v8t는 일부 링크 장애가 발생하더라도 학습을 중단하지 않고 통신 경로를 변경할 수 있도록 설계했습니다. 체크포인트에서 학습을 재개하려면 복구 시간뿐 아니라 마지막 저장 이후 수행했던 연산을 다시 처리하는 비용도 발생합니다. 처음부터 학습을 중단하지 않고 장애를 우회할 수 있다면 그만큼 Runtime Goodput을 높일 수 있습니다. ② TPU v8i : MoE 추론에서 통신 지연시간을 최소화 추론용 TPU v8i는 해결해야 할 문제가 다릅니다. 특히 MoE 모델은 토큰마다 서로 다른 전문가(Expert)를 호출하기 때문에 여러 칩 사이에서 All-to-all 통신이 빈번하게 발생합니다.
원문 구간 4
특정 장비나 경로에 문제가 생기더라도 그 영향이 전체 클러스터로 확산되는 것을 최소화하려는 것입니다. 구글은 개별 TPU의 연산 성능을 높이는 것을 넘어, 수십만 개의 TPU를 연결한 환경에서도 실제 학습 처리량과 Goodput을 최대한 유지할 수 있도록 OCS를 활용해서 네트워크 전체를 설계하고 있습니다. 5. 수십만 개의 가속기를 연결할수록 Goodput을 유지하기 어려워지는 이유 가속기 수가 늘어날수록 장애가 발생할 가능성도 높아집니다. 예를 들어 TPU 134,000개가 각각 99.9%의 가용성을 가진다고 가정하면, 특정 시점에 평균적으로 약 134개의 칩을 사용할 수 없다는 계산이 나옵니다. 개별 칩의 신뢰성이 아무리 높더라도 수십만 개를 연결한 시스템에서는 어딘가에서 장애가 발생하는 것이 사실상 불가피합니다. 문제는 대규모 AI 학습에서는 일부 가속기의 장애만으로도 전체 학습이 중단될 수 있다는 점입니다. 이 때문에 구글은 일정 간격으로 학습 상태를 저장하는 Checkpointing을 사용합니다. 다만 장애가 발생하면 마지막 체크포인트 이후 수행했던 연산을 다시 실행해야 하므로 그만큼 시간과 컴퓨팅 자원이 낭비됩니다. 체크포인트를 자주 저장하면 손실은 줄어들지만 저장 자체에도 시간이 필요합니다. 바로 여기서 OCS의 역할이 중요해집니다. 장애가 발생한 장비를 제외하고 정상적인 TPU들로 네트워크를 재구성할 수 있기 때문입니다. 일부 링크 장애는 학습을 중단하지 않고 우회할 수도 있습니다. 장비를 교체해야 하는 경우에도 스케줄러와 체크포인트 복구 시스템을 통해 작업을 빠르게 재개할 수 있습니다. 결국 Goodput을 높인다는 것은 장애를 완전히 없애는 것이 아니라, 장애가 발생하더라도 실제 연산에 미치는 영향을 최소화하는 것입니다.

사실·구조AI ASIC 설계주 대상 · 기술·제품 · TPU

AI ASIC의 경제성에서 특화와 유연성은 어떻게 균형을 이루는가?

이 자료가 더한 내용

특정 워크로드에 맞춘 하드웨어는 성능을 높일 수 있지만 유연성을 낮추므로, 워크로드의 규모·3~4년 성장·수요 지속성과 훈련·추론 간 여유 용량 활용을 함께 봐야 한다고 설명했다.

근거 보기 5

원문 구간 1
그런데 점차 AI 학습과 트랜스포머, 추천 시스템까지 영역이 넓어졌습니다. 그리고 생성형 AI 시대가 도래하면서 TPU는 훨씬 더 다양한 워크로드를 처리하고 대규모로 확장할 수 있는 범용적인 AI 컴퓨팅 시스템으로 발전하게 됐습니다. *코멘트 → Bitter Lesson은 AI 연구자 리치 서튼(Rich Sutton)이 2019년에 발표한 글에서 제시한 개념입니다. 핵심 주장은 다음과 같습니다. 인간이 특정 문제에 대한 지식을 직접 설계에 반영한 방법보다, 더 많은 컴퓨팅 자원을 활용해 스스로 학습하고 탐색하는 범용적인 방법이 장기적으로 더 뛰어난 성과를 거뒀다는 것입니다. 대표적으로 체스와 바둑이 있습니다. 과거 연구자들은 인간 전문가의 전략과 지식을 프로그램에 직접 구현하려 했습니다. 그러나 결국 엄청난 연산량을 활용하는 탐색과 머신러닝이 훨씬 좋은 성과를 거뒀습니다. 리치 서튼은 이러한 패턴이 컴퓨터 비전 등 여러 AI 분야에서도 반복됐다고 설명했습니다. 여기서 중요한 것은 범용 하드웨어 자체가 아니라 컴퓨팅 자원이 증가할수록 더 강력해질 수 있는 알고리즘의 확장성입니다. 그런데 소냐 황은 왜 TPU 이야기에 Bitter Lesson을 가져왔을까? 2013년 반도체 업계에는 비슷한 통념이 있었습니다. 범용 CPU는 무어의 법칙과 거대한 소프트웨어 생태계의 지원을 받으며 계속 발전하고 있었습니다. 따라서 특정 작업에 최적화한 전용 칩을 개발해봤자 범용 프로세서의 발전 속도를 따라잡기 어렵다는 생각이었습니다. 하지만 구글은 AI 연산 수요가 범용 CPU의 성능 개선 속도보다 훨씬 빠르게 증가할 가능성에 주목했습니다.
원문 구간 2
당시 구글은 사용자들이 하루에 단 3분씩 음성 검색을 사용하더라도 이를 처리하려면 데이터센터의 컴퓨터 수를 거의 두 배로 늘려야 한다고 추산했습니다. 그래서 기존 CPU를 더 구매하는 대신 AI 연산에 특화된 TPU를 개발하기 시작했습니다. TPU가 성공한 이유는 특정 모델이 아닌 공통적인 연산에 특화했기 때문입니다 구글이 직접 설명한 내용과도 일치합니다. 2024년 TPU 개발 회고에서 구글의 수석 아키텍트인 놈 주피(Norm Jouppi)는 "미래의 모델이 어떻게 바뀔지는 알 수 없었지만 텐서 연산을 사용할 것이라는 점은 알고 있었다"고 설명했습니다. 그래서 특정 모델에 지나치게 최적화하기보다 마지막 10~20%의 최적화 성능을 포기하더라도 미래 모델에 대응할 수 있는 유연성을 확보하는 편이 낫다고 판단했습니다. 이것이 TPU 성공의 중요한 이유라고 생각합니다. 처음에는 번역과 음성 인식이 주요 워크로드였지만 이후 Transformer와 추천 시스템, 생성형 AI까지 확대됐습니다. 모델은 계속 바뀌었지만 행렬 연산을 효율적으로 처리한다는 핵심 하드웨어 구조는 오랫동안 유효했습니다. 2026년 구글 연구진의 논문에서도 TPU v2부터 Ironwood까지 기본 아키텍처의 안정성을 유지하면서 Transformer 등 변화하는 워크로드에 대응했다고 평가합니다. 소냐 황 : 방금 트랜스포머의 등장에 대해 말씀하셨는데요. 흥미로운 점은 TPU가 특정 연산에 특화된 칩이면서도 트랜스포머만을 위해 설계된 것은 아니라는 겁니다. 그렇다면 칩을 특정 워크로드에 얼마나 특화할 것인지, 또 어느 정도의 범용성을 유지할 것인지는 어떻게 결정하시나요?
원문 구간 3
그 사이에서 적절한 균형을 찾는 것이 쉽지 않을 것 같습니다. 아민 바흐다트 : 핵심은 그 칩을 얼마나 다양한 워크로드에 활용할 수 있느냐입니다. 앞으로 어떤 워크로드에서 얼마나 널리 사용될 수 있을지를 판단하는 것이죠. 저희는 TPU를 설계할 때마다 이 질문을 던집니다. 이번 세대에서는 특정 워크로드에 더 특화하는 것이 좋을까? 아니면 범용성을 유지하는 것이 좋을까? 실제로 약 2년 전에도 중요한 결정을 내려야 했습니다. 2026년을 위한 TPU를 하나만 개발할 것인지, 아니면 두 종류로 나눠서 개발할 것인지를 결정해야 했죠. 학습과 추론을 모두 잘 처리할 수 있는 범용 칩 하나를 만들 수도 있고, 추론에 특화된 칩과 학습에 특화된 칩을 각각 개발할 수도 있었습니다. 여러 분석을 거친 끝에 저희는 올해 추론에 최적화된 TPU 8i와 학습에 최적화된 TPU 8t를 각각 출시하기로 결정했습니다. 이렇게 결정한 이유는 2026년에는 AI 추론과 서빙 수요가 폭발적으로 증가할 것으로 예상했기 때문입니다. 불과 몇 년 전만 해도 상황이 달랐습니다. 예를 들어 어떤 칩의 전체 사용 기간 동안 추론 서빙이 전체 워크로드의 30%, 40%, 50%, 심지어 60%까지 차지할 것으로 예상된다고 해보겠습니다. 그렇다면 추론에 특화된 칩을 별도로 개발해서 훨씬 높은 성능을 얻는 것이 충분히 합리적인 선택입니다. 반대로 추론이 전체 워크로드의 2~5%밖에 차지하지 않는다면 어떨까요? 추론 전용 칩을 개발해서 성능을 두 배로 높일 수 있다고 해도 경제성이 맞지 않을 수 있습니다. 이런 경우에는 일부 효율을 포기하더라도 학습과 추론을 모두 처리할 수 있는 범용 칩 하나를 만드는 편이 낫습니다.
원문 구간 4
결국 저희가 판단해야 하는 것은 해당 워크로드의 규모가 얼마나 큰지, 앞으로 3~4년 동안 얼마나 성장할 것인지, 그리고 그 수요가 얼마나 오래 지속될 것인지입니다. 하드웨어는 특정 작업에 특화할수록 유연성이 줄어듭니다. 대신 그 작업에서 훨씬 높은 성능과 전력 효율을 얻을 수 있는 기회가 생깁니다. 그래서 어떤 워크로드에 맞춰 칩을 설계할지 결정하는 일은 과학이면서 동시에 예술이기도 합니다. 미래의 수요를 정확하게 예측해야 하기 때문입니다. 예를 들어 어떤 워크로드가 지금은 굉장히 큰 비중을 차지하더라도 한두 달이나 석 달 뒤에 사라질 것이라면 전용 하드웨어를 개발할 이유가 없습니다. 칩을 개발해서 실제로 배포하기까지 걸리는 시간을 생각하면 대응할 수도 없겠죠. 따라서 해당 워크로드가 충분히 오랫동안 유지될 것이라는 확신이 필요합니다. 동시에 전용 칩을 개발했을 때 기존 범용 칩보다 정확히 얼마나 큰 성능과 효율상의 이점을 얻을 수 있을지도 예측할 수 있어야 합니다. 소냐 황 : 결국 경제성의 문제이기도 하겠네요. 새로운 칩을 별도로 개발하려면 상당한 고정비가 들어가니까요. 그만큼 충분한 수요가 있어야 추가적인 칩 개발 비용을 정당화할 수 있다는 말씀이군요. 아민 바흐다트 : 정확합니다. 다행히 이번에 개발한 8i와 8t는 각각 특화된 워크로드뿐만 아니라 다른 워크로드도 처리할 수 있습니다. 이것도 저희가 설계할 때 중요하게 고려한 부분입니다. 예를 들어 8i는 추론만 할 수 있고 학습은 전혀 할 수 없다고 가정해 보겠습니다. 반대로 8t는 학습에는 뛰어나지만 추론은 전혀 처리하지 못한다면 어떨까요? 그렇게 되면 하드웨어의 수명이 약 6년이라는 점을 고려했을 때, 앞으로 6년 동안 학습과 추론에 각각 얼마나 많은 컴퓨팅 용량이 필요할지 미리 정확하게 예측해야 합니다.
원문 구간 5
그런데 그건 굉장히 어려운 일입니다. 그래서 이번에는 각 칩이 자신에게 특화된 워크로드에서 더 높은 성능을 내면서도 필요에 따라 다른 워크로드를 처리할 수 있도록 설계했습니다. 예를 들어 추론용 칩에 여유 용량이 생기면 그 자원을 학습에 활용할 수도 있고, 반대의 경우도 가능합니다. 특정 워크로드에 지나치게 특화하면 이런 유연성을 잃게 됩니다. 상황에 따라 컴퓨팅 자원을 다른 용도로 전환할 수 있다는 것도 굉장히 중요한 설계 요소입니다. 소냐 황 : 특정 워크로드의 규모가 클수록 전용 칩을 개발할 경제성이 높아진다는 말씀이군요. 그렇다면 오늘날 AI 워크로드의 상당 부분이 트랜스포머 기반이라는 점도 생각해 볼 수 있을 것 같습니다. 조금 도발적인 질문을 드려보겠습니다. 아예 트랜스포머 아키텍처 자체를 하드웨어에 구현해서 트랜스포머 전용 칩을 만들면 안 되는 건가요? 아민 바흐다트 : 맞습니다. 오늘날 대부분의 AI 모델이 트랜스포머 기반인 것은 사실입니다. 그런데 트랜스포머가 실제로 어떤 연산을 수행하는지 자세히 들여다보면 대부분 행렬/벡터 곱셈 같은 선형대수 연산과 Softmax 같은 연산으로 이루어져 있습니다. 저희뿐만 아니라 다른 반도체 기업들도 이미 이런 기본적인 연산을 하드웨어 수준에서 지원하고 있습니다. 그렇다면 그다음 단계는 얼마나 더 구체적인 모델 구조에 맞춰 하드웨어를 특화할 것인가의 문제입니다. 같은 트랜스포머 기반 모델이라고 해도 내부 구조는 상당히 다를 수 있습니다. 레이어가 몇 개나 있는지, 각 레이어를 어떤 순서와 방식으로 통과하는지, 레이어 사이에서 데이터가 어떻게 이동하는지에 따라 필요한 연산이 달라집니다.

해석·전망구글 AI 인프라주 대상 · 기업·종목 · Google

구글은 공동 설계를 어떤 경쟁력으로 보는가?

이 자료가 더한 내용

DeepMind와 인프라 조직이 모델·소프트웨어·하드웨어·네트워크를 함께 설계하고, 수년간 여러 제품 세대를 병렬 검토해 개선 효과를 누적하는 방식을 경쟁력으로 설명했다. 성능 개선 여지가 있으면 tape-out을 늦출 수 있다는 점도 함께 제시했다.

근거 보기 7

원문 구간 1
각 단계에서 수행하는 행렬과 벡터 연산의 크기와 형태도 다를 수 있고요. 따라서 단순히 트랜스포머 연산에 최적화된 칩을 만드는 것에서 한 단계 더 나아가 특정 모델의 구조와 데이터 흐름에 맞춰 하드웨어를 훨씬 더 깊이 특화할 수도 있다는 것입니다. 이미 여러 기업이 이런 방향을 고민하고 있을 것이라고 생각합니다. 저 역시 굉장히 흥미로운 접근 방식이라고 봅니다. 소냐 황 : 현재 고객들은 TPU와 GPU를 사실상 서로 대체할 수 있는 가속기로 보고 있나요? 아니면 각각의 장점이 달라서 더 적합한 워크로드가 따로 있는 건가요? 아민 바흐다트 : 분명히 각각의 가속기에 더 적합한 워크로드가 있습니다. GPU가 TPU보다 범용성이 높다는 것은 사실입니다. 구글 클라우드에서도 다양한 GPU 제품을 제공하고 있고, 구글 내부적으로도 GPU를 사용하고 있습니다. 결국 어떤 가속기를 선택할지는 고객이 해결하려는 문제와 워크로드의 특성에 달려 있습니다. TPU와 GPU 모두에서 효율적으로 실행할 수 있는 워크로드도 있지만, 특정 가속기에서 더 높은 성능을 내는 워크로드도 있습니다. 그래서 고객들은 자신들이 실행하려는 워크로드를 기준으로 TPU와 GPU의 성능과 효율을 비교한 뒤 적합한 제품을 선택합니다. 저희의 목표는 고객들이 자신의 워크로드에 가장 적합한 솔루션을 선택할 수 있도록 다양한 옵션을 제공하는 것입니다. '공동 설계' 구글의 경쟁력 여러 계층에 걸친 최적화 누적, 성능 개선을 위해 tape-out을 연기하다 소냐 황 : 이번에는 공동 설계에 대해 좀 더 여쭤보겠습니다. 반도체부터 네트워크와 소프트웨어까지 전체 시스템을 하나로 묶어서 설계하면 어떤 장점이 있나요?
원문 구간 2
반대로 이런 접근 방식의 단점이나 한계는 무엇인가요? 아민 바흐다트 : 공동 설계(Co-design)의 가장 큰 장점은 시스템 전체를 최적화할 수 있는 기회가 엄청나게 많다는 것입니다. 다만 모든 구성 요소를 자유롭게 선택하고 조합하고 싶다면 이야기가 달라집니다. 예를 들어 여러 클라우드를 사용하면서 다양한 하드웨어와 소프트웨어를 조합한다고 생각해 보겠습니다. 어떤 하드웨어나 소프트웨어에서도 작동하고, 어떤 네트워크 토폴로지에서도 실행할 수 있도록 추상화 계층을 만들 수 있습니다. 이렇게 하면 시스템의 이식성과 유연성이 굉장히 높아집니다. 새로운 컴퓨팅 자원이 등장하더라도 거의 즉시 활용할 수 있죠. 특정 기업의 하드웨어나 인프라에 맞춰 시스템을 설계하지 않았기 때문입니다. 그런데 이런 범용성을 확보하려면 상당한 성능을 포기해야 합니다. 하드웨어부터 소프트웨어, 네트워크, 스토리지, 컴퓨팅까지 모든 구성 요소를 자유롭게 교체할 수 있도록 만들면 각 계층 사이에서 상당한 비효율이 발생합니다. 반대로 각 계층을 함께 설계하고 최적화하면 10%, 20%, 경우에 따라서는 두 배에 달하는 성능 차이를 만들어낼 수도 있습니다. 여기서 중요한 것은 이런 최적화 효과가 여러 계층에 걸쳐 누적된다는 점입니다. 한 계층에서 20%의 성능을 개선하고 다른 계층에서도 20%를 개선한다면 그 효과가 서로 곱해지는 것이죠. 이런 개선이 여러 계층에서 반복되면 최종적으로 시스템 전체의 성능이나 와트당 지능, 와트당 Throughput에서 엄청난 격차가 벌어질 수 있습니다. 전력 배분부터 소프트웨어 최적화까지 모든 영역에서 이런 기회를 찾을 수 있습니다.
원문 구간 3
여기에 나중에 이야기할 소비자 서비스와 클라우드까지 포함하면 또 다른 협력 관계가 있지만, 우선 딥마인드와의 공동 설계는 정말 긴밀하게 이루어지고 있습니다. 실제로 어떤 식으로 협력하는지 사례를 들어보겠습니다. 딥마인드 연구원들이 트랜스포머에서 사용하는 특정 연산이나 모델 최적화에 관한 새로운 아이디어를 제안했다고 해보겠습니다. 마침 저희가 개발하고 있는 TPU가 아직 설계가 끝나지 않은 단계라면 딥마인드에서 이런 요청을 할 수 있습니다. "하드웨어에서 이 연산을 직접 지원할 수 있다면 모델의 학습이나 추론 서빙 성능을 훨씬 더 높일 수 있을 것 같습니다." 그러면 저희 하드웨어 엔지니어들과 딥마인드 연구원들이 한자리에 모입니다. 며칠 동안 논의할 수도 있고 일주일, 때로는 2주 동안 집중적으로 검토하기도 합니다. 그 과정에서 저희가 "요청하신 기능을 그대로 구현하기는 어렵지만 이런 방식이라면 가능합니다"라고 이야기할 수 있습니다. 그러면 딥마인드 연구원들이 다시 제안합니다. "그렇다면 모델 구조를 조금 변경해서 원래 기대했던 성능 향상의 90% 정도를 얻을 수 있지 않을까요?" 이렇게 서로 아이디어를 주고받으면서 하드웨어와 모델을 함께 조정하는 겁니다. 만약 그 과정에서 얻을 수 있는 이점이 충분히 크다면 칩의 테이프아웃(Tape-out)을 일주일이나 2주 정도 늦추기로 결정할 수도 있습니다. 사실 저희는 항상 여러 세대의 TPU를 동시에 개발하고 있습니다. 이미 데이터센터에 대규모로 배포되어 운영 중인 칩이 있습니다. 제조를 마치고 테스트와 디버깅을 진행하는 칩도 있고, 설계를 거의 마무리해서 tape-out을 앞둔 칩도 있습니다.
원문 구간 4
한창 설계를 진행하고 있는 차세대 칩도 있고, 아직 어떤 아키텍처를 사용할지 구상하는 초기 단계의 칩도 있습니다. 이렇게 실제 운영 중인 제품부터 미래 세대의 초기 설계까지 대략 5~6개의 개발 단계가 수년에 걸쳐 동시에 진행되고 있습니다. 그리고 저희는 이 모든 단계에서 딥마인드와 협력합니다. 우선 이미 운영 중인 칩에서도 공동 최적화가 이루어집니다. 저희는 하드웨어 내부에서 실제로 어떤 일이 일어나는지 알고 있고, 딥마인드 연구원들은 모델 내부에서 어떤 연산이 수행되는지 정확하게 이해하고 있습니다. 그 사이에 있는 소프트웨어가 어떻게 동작하는지도 함께 분석할 수 있습니다. 따라서 전체 시스템을 살펴보면서 와트당 지능이나 Goodput을 극대화할 수 있는 최적화 기회를 찾아낼 수 있습니다. tape-out을 앞둔 칩에서도 이런 협력이 이루어집니다. 아직은 하드웨어 아키텍처를 일부 변경할 수 있는 시점이기 때문입니다. 그런데 이런 협력은 서로 다른 회사에서 일한다면 훨씬 어려울 겁니다. 칩 개발이 거의 끝나서 몇 주 또는 몇 달 뒤면 테이프아웃을 해야 하는 상황에서 모델 개발팀과 하드웨어 개발팀이 갑자기 모여 "지금 설계를 변경하는 것이 좋을까요?"라고 논의하고 실제로 결정을 내리는 것은 쉬운 일이 아니니까요. 반면 개발 초기 단계에서는 훨씬 더 다양한 가능성을 검토할 수 있습니다. 저희는 딥마인드 연구원들에게 이런 질문을 합니다. "앞으로 2~3년 뒤에는 AI 모델 아키텍처가 어떤 방향으로 발전할 것 같습니까?" 그런 다음 하드웨어 아키텍처 측면에서 가능한 선택지와 모델 아키텍처 측면에서 가능한 선택지를 함께 검토합니다.
원문 구간 5
서로 어떤 조합이 가장 높은 성능과 효율을 낼 수 있을지 최적의 균형점을 찾는 것이죠. 이를 위해 저희는 다양한 하드웨어에서 특정 워크로드가 어떻게 실행될지를 미리 예측할 수 있는 고도화된 시뮬레이션 인프라도 갖추고 있습니다. 이 모든 과정은 굉장히 빠르고 반복적으로 이루어집니다. 하드웨어 팀과 모델 개발팀이 각자 따로 작업하다가 가끔 만나서 의견을 교환하는 방식이 아닙니다. 실제로 같은 건물이나 같은 공간에서 함께 일하는 경우도 많고, 일상적으로 굉장히 깊이 있는 논의를 나눕니다. 저 역시 코레이나 데미스와 일주일에도 몇 번씩 이야기를 나눕니다. 이런 방식으로 함께 일할 수 있다는 것이 제가 구글에서 가장 즐겁게 생각하는 부분 중 하나입니다. 소냐 황 : 정말 멋집니다. 결국 딥마인드의 모델이 칩을 설계하는 데도 활용되겠군요. 아민 바흐다트 : 저희는 차세대 Gemini를 구동할 하드웨어를 설계하는 과정에서도 Gemini 자체를 활용하고 있습니다. 소냐 황 : 정말 놀랍네요. 그 이야기는 잠시 후에 다시 해보겠습니다. 그런데 이렇게 긴밀하게 협력하는 과정에서도 어려움이 있을 것 같습니다. 하드웨어는 개발에 몇 년씩 걸리지만, 딥마인드가 개발하는 AI 모델과 소프트웨어는 훨씬 빠르게 발전하잖아요. 하드웨어는 몇 년 뒤를 내다보고 설계해야 하는데, 그사이에 모델 아키텍처가 계속 바뀔 수도 있습니다. 이렇게 개발 속도가 서로 다르다는 점에서 어려움은 없나요? 아민 바흐다트 : 물론입니다. 소냐 황 : 실제로는 어느 정도까지 함께 조정할 수 있나요? 아민 바흐다트 : 저희는 하드웨어를 개발할 때 2년, 3년, 4년, 심지어 5년 뒤까지 내다보고 계획합니다.
원문 구간 6
최근 발표한 TPU v8i와 v8t뿐만 아니라 그다음 세대인 9세대와 10세대 TPU, 그리고 다른 여러 제품도 이미 개발하고 있습니다. 물론 제품마다 개발 단계는 다릅니다. 아직 초기 아이디어를 검토하는 제품도 있고 실제 구현을 진행하고 있는 제품도 있습니다. 최종적으로 출시되기까지 몇 년이 걸릴 수도 있죠. 반면 AI 모델을 개발할 때는 일반적으로 몇 년 뒤에 출시할 모델만을 목표로 연구하지는 않습니다. 개발 주기 자체가 훨씬 짧으니까요. 그런데도 저희가 긴밀하게 협력할 수 있는 것은 구글이 지금까지 발전해 온 과정과 조직 문화 덕분이라고 생각합니다. 구글 리서치와 딥마인드는 오랫동안 긴밀하게 협력해 왔고, 트랜스포머 아키텍처도 이런 연구 환경에서 탄생했습니다. 덕분에 연구원들 사이에는 자신들의 모델 연구가 하드웨어 로드맵에도 영향을 미칠 수 있다는 인식이 자연스럽게 자리 잡았습니다. 동시에 하드웨어 개발에는 몇 년이라는 긴 시간이 필요하다는 사실도 잘 이해하고 있습니다. 예를 들어 테이프아웃을 앞둔 칩에서 성능을 0.5~1% 정도 개선할 수 있는 아이디어가 나왔다고 해보겠습니다. 그 정도의 개선을 위해 굳이 하드웨어 설계를 변경하자고 요청하지는 않을 겁니다. 소프트웨어는 코드를 변경하고 2주 만에 새로운 버전을 배포할 수도 있습니다. 하지만 하드웨어는 다릅니다. 테이프아웃을 중단하고 설계를 변경한다는 것은 훨씬 더 큰 결정이기 때문입니다. 딥마인드 연구원들도 이런 차이를 잘 이해하고 있습니다. 반대로 성능 개선 효과가 정말 크다면 어떻게든 함께 방법을 찾아서 하드웨어 설계에 반영할 수 있다는 것도 알고 있습니다.
원문 구간 7
그리고 이런 협업의 효과는 앞서 말씀드린 것처럼 곱셈으로 누적됩니다. 하드웨어에서 한 번 성능을 개선하면 그 하드웨어에서 실행되는 모든 워크로드가 혜택을 받을 수 있습니다. 딥마인드 연구원들도 이런 장기적인 파급효과를 잘 알고 있기 때문에 하드웨어 로드맵에 영향을 줄 수 있는 아이디어를 계속 고민합니다. 개인적으로 정말 보람을 느끼는 순간도 바로 이런 때입니다. 2년 전에 딥마인드 연구원들과 함께 고민했던 아이디어가 이제 실제 데이터센터에 적용되어 구글의 모든 워크로드를 더 빠르고 효율적으로 처리하도록 돕는 모습을 보는 것이죠. 소냐 황 : 맞습니다. 그런데 5년 뒤에 어떤 AI 워크로드가 주류가 될지, 그사이에 어떤 새로운 알고리즘이 등장할지 예측하는 건 사실상 불가능에 가까워 보이는데요. 그렇게 먼 미래를 내다보고 하드웨어를 설계하는 것이 굉장히 어려운 일이지 않나요? 아민 바흐다트 : 그렇게 생각하실 수 있습니다. 그런데 흥미로운 사실이 하나 있습니다. 저희가 지금까지의 TPU 개발 역사를 자세히 정리하고 있는데, 놀랍게도 아키텍처를 조금 더 추상적인 수준에서 살펴보면 TPU는 v1 이후 핵심 구조가 크게 달라지지 않았습니다. CPU의 명령어 집합을 생각해 보세요. 메모리에서 데이터를 읽고 쓰는 Load/Store 명령어가 있고, 덧셈과 뺄셈 같은 산술 연산이나 조건에 따라 실행 흐름을 바꾸는 분기 명령어도 있습니다. 이런 기본적인 명령어를 바탕으로 지난 수십 년 동안 수없이 다양한 소프트웨어가 개발되고 실행되어 왔습니다. TPU도 비슷합니다. 물론 세대가 바뀔 때마다 새로운 명령어와 기능을 계속 추가해 왔습니다.

사실·구조에이전트형 AI와 데이터센터주 대상 · 산업·업종 · AI 데이터센터

에이전트형 AI는 데이터센터 자원과 전력 수요를 어떻게 바꾸는가?

이 자료가 더한 내용

에이전트가 사람의 상호작용 속도보다 오래·빠르게 작업하면서 CPU가 스토리지·네트워크·다양한 자원을 조율하는 오케스트레이션 수요가 커지고, 전력이 가장 근본적인 확장 제약으로 남는다고 설명했다.

근거 보기 5

원문 구간 1
이러한 변화가 데이터센터의 설계와 운영에는 어떤 영향을 미치고 있나요? 아민 바흐다트 : 크게 두 가지 변화가 있습니다. 첫 번째는 더 이상 사람이 AI와 상호작용하는 속도가 시스템 전체의 속도를 제한하지 않는다는 점입니다. 과거에는 사람이 브라우저나 스마트폰에 프롬프트를 입력하고, 모델이 생성한 답변을 받은 다음 그 내용을 읽고 생각해서 다시 질문하는 방식이었습니다. 중간에 사람이 개입하기 때문에 한 번의 상호작용이 끝나고 다음 요청이 들어오기까지 몇 초, 길게는 몇십 초의 간격이 자연스럽게 발생했습니다. 그런데 장기 호라이즌 에이전트는 다릅니다. 이제 사람이 중간에서 속도를 제한하지 않습니다. 에이전트는 모델의 응답을 받자마자 그 내용을 파싱하고 분석해서 다음에 어떤 작업을 수행할지 판단한 뒤 곧바로 새로운 요청을 보낼 수 있습니다. 기존에는 몇 초씩 걸리던 상호작용 간격이 밀리초 단위로 줄어들 수 있다는 것이죠. 두 번째 변화는 이런 에이전트의 작업을 처리하는 데 CPU가 굉장히 중요한 역할을 하게 된다는 점입니다. 모델의 응답을 파싱하고 다음 작업을 결정하고, 여러 작업을 조율하는 오케스트레이션 과정의 상당 부분이 CPU에서 이루어지기 때문입니다. 예를 들어 에이전트가 다음 프롬프트를 모델에 보내기 전에 어떤 정보를 추가로 수집해야 할지 판단해야 한다고 해보겠습니다. 이전 응답에서 얻은 정보를 바탕으로 다음 작업을 진행하려면 필요한 컨텍스트를 가져와야 합니다. 그 컨텍스트는 로컬 DRAM에 있을 수도 있고, 다른 CPU에 연결된 DRAM에 있을 수도 있습니다. SSD나 HDD에 저장되어 있을 수도 있죠.
원문 구간 2
결국 에이전트가 계속 작업을 수행하려면 CPU가 이런 다양한 자원에 접근해서 필요한 데이터를 가져오고, 다음 작업을 조율해야 합니다. 이제 데이터센터에서는 과거와 비교할 수 없을 정도로 많은 오케스트레이션 작업이 필요해지고 있습니다. 그 결과 TPU나 GPU 같은 가속기의 연산 수요가 증가하는 것은 물론이고, CPU와 네트워크, 스토리지처럼 기존 데이터센터를 구성하던 인프라에 대한 수요도 폭발적으로 증가하고 있습니다. 소냐 황 : 그렇다면 GPU 랙 바로 옆에 더 많은 CPU를 배치해야 한다는 뜻인가요? 아민 바흐다트 : GPU든 TPU든 마찬가지입니다. 그런데 이 문제는 앞서 이야기했던 데이터센터를 특정 용도에 얼마나 특화해서 설계할 것인가라는 질문으로 다시 이어집니다. 예를 들어 가속기 랙 바로 옆에 CPU 랙을 많이 배치한다고 해보겠습니다. 그렇게 되면 데이터센터 건물 전체를 TPU나 GPU에 맞춰 최적화하기가 어려워집니다. TPU나 GPU 랙은 일반적인 CPU 랙보다 전력 밀도가 훨씬 높고, 네트워크 대역폭에 대한 요구사항도 훨씬 클 수 있기 때문입니다. 서로 특성이 다른 장비들을 한 건물에 배치하면 전력과 네트워크 인프라를 어느 한쪽에 맞춰 설계하기 어려워지는 것이죠. 그렇다면 건물별로 용도를 구분하는 방법도 있습니다. 예를 들어 한 건물에는 TPU와 GPU를 집중적으로 배치하고, 바로 옆 건물에는 CPU를 배치하는 겁니다. HDD는 또 다른 건물에 모아둘 수도 있겠죠. 그런데 이렇게 하면 또 다른 문제가 생깁니다. 건물과 건물 사이에 훨씬 더 많은 네트워크 연결이 필요해진다는 것입니다.
원문 구간 3
아민 바흐다트 : 저희가 가장 자주 받는 질문 중 하나가 현재 AI 인프라를 확장하는 데 가장 큰 제약조건이 무엇이냐는 것입니다. 그런데 사실 하나만 꼽기는 어렵습니다. 거의 모든 요소가 제약조건이 될 수 있고, 어느 것 하나 해결하기 쉬운 문제가 아닙니다. 게다가 병목이 발생하는 지점도 계속 바뀌고 있습니다. 그럼에도 가장 근본적인 제약조건을 하나만 꼽으라면 저는 전력이라고 답하겠습니다. 다른 문제들은 대체로 어떻게 해결해야 할지 알고 있습니다. 지금 당장은 어렵더라도 시간이 지나면 해결할 수 있을 것으로 보입니다. 하지만 전력은 다릅니다. 장기적으로도 AI 인프라 확장을 계속 제한하는 요인이 될 가능성이 높습니다. 물론 원자력 같은 해결책이 있습니다. 원자력이 충분히 풍부한 청정에너지를 공급할 수 있게 된다면 지금의 전력 문제를 상당 부분 해결할 수도 있을 겁니다. 다만 그런 기술과 전력 공급 능력을 언제쯤 대규모로 확보할 수 있을지는 여전히 불확실합니다. 소냐 황 : 그렇다면 실제로 데이터센터에 필요한 전력은 어떻게 확보하시나요? 예를 들어 새로운 데이터센터를 구축하는 데 1GW의 전력이 필요하다고 해보겠습니다. 그렇다고 전력회사인 PG&E에 전화해서 "1GW만 공급해 주세요"라고 요청한다고 해결되는 문제는 아닐 것 같은데요. 그렇다면 발전용 터빈까지 직접 설치해서 전력 생산 자체를 수직계열화해야 하는 건가요? 구글은 이런 대규모 전력 확보 문제를 실제로 어떻게 해결하고 있나요? 아민 바흐다트 : 정말 중요하면서도 큰 질문입니다. 구글이 가장 선호하는 방식은 전력회사와 협력해서 데이터센터를 기존 전력망에 연결하는 것입니다.
원문 구간 4
기본적으로는 전력회사에 필요한 전력을 공급해 달라고 요청하는 방식이죠. 소냐 황 : 그렇다고 PG&E에 전화 한 통 하면 바로 해결되는 건 아니겠죠? 아민 바흐다트 : 당연히 그렇습니다. 데이터센터가 위치한 지역의 전력회사와 아주 정중하게, 그리고 수년 전부터 협의를 시작해야 합니다. 1GW의 전력이 필요하다고 해서 전력회사에 전화해서 "내일부터 1GW를 사용할 테니 요금은 언제부터 내면 되나요?"라고 말할 수는 없으니까요. 전력회사와 오랜 기간에 걸쳐 함께 계획해야 하는 일입니다. 여기서 저희가 중요하게 생각하는 것 중 하나는 전력망을 확충하는 데 필요한 비용을 구글이 부담해야 한다는 점입니다. 구글의 데이터센터에 전력을 공급하기 위해 전력망 용량을 늘리는 것인데, 그 비용이 지역 주민이나 다른 고객들의 전기요금 인상으로 이어져서는 안 된다고 생각합니다. 그래서 새로운 송전선을 건설하거나 기존 송전선을 업그레이드하고, 추가 변전소를 건설하는 데 필요한 비용을 저희가 부담하는 방안을 전력회사와 협의합니다. 예를 들어 2028년에 1GW의 전력이 필요하다고 해보겠습니다. 그런데 전력회사에서 "2029년에는 1GW를 공급할 수 있지만 2028년에는 700MW까지만 가능합니다"라고 답할 수도 있습니다. 그러면 저희는 부족한 300MW를 어떻게 확보할지 고민해야 합니다. 가장 간단한 방법은 필요한 전력이 공급될 때까지 기다리는 것입니다. 하지만 다른 방법도 있습니다. 부족한 전력의 일부를 저희가 직접 생산하는 것이죠. 예를 들어 태양광 발전이나 배터리, 다른 발전원을 조합해서 필요한 전력을 확보할 수 있습니다.
원문 구간 5
그런데 이 경우에도 전력회사와 긴밀하게 협력해야 합니다. 기존 전력망에서 공급받는 전력과 저희가 직접 생산하는 전력을 어떻게 결합할지 결정해야 하기 때문입니다. 여기서 한 단계 더 나아갈 수도 있습니다. 나중에 전력회사가 1GW 전체를 공급할 수 있게 되면 저희가 직접 생산한 전력의 일부를 다시 지역 전력망에 공급하는 겁니다. 예를 들어 한여름에 가장 더운 2주 동안 지역 주택들의 전력 수요가 급격하게 증가한다고 해보겠습니다. 그럴 때 저희가 생산한 전력의 일부를 지역 전력망으로 보내서 전력 수요를 충당하는 데 도움을 줄 수도 있습니다. 이런 방식으로 데이터센터에 필요한 전력을 확보하면서 지역 전력망에도 기여할 수 있습니다. 그래서 전력회사와 수년에 걸쳐 긴밀하게 협력하는 과정이 반드시 필요한 것입니다. 소냐 황 : 그렇다면 구글이 직접 발전 설비를 구축해서 전력 생산까지 수직계열화하기보다는 기존 전력회사와 협력하는 방식을 선호하는 이유는 무엇인가요? 아민 바흐다트 : 가장 큰 이유는 양쪽 모두에게 더 많은 유연성과 경제적인 이점이 있기 때문입니다. 이건 통계적 다중화(Statistical Multiplexing) 또는 대수의 법칙이라는 관점에서 이해할 수 있습니다. 예를 들어 저희가 1GW의 전력이 필요하고, 그 전력을 99.99% 또는 그 이상의 신뢰성으로 공급받아야 한다고 가정해 보겠습니다. 만약 필요한 전력을 전부 직접 생산한다면 1GW가 아니라 2GW 규모의 발전 설비를 구축해야 할 수도 있습니다. 99.99%나 99.999% 수준의 신뢰성을 확보하려면 한쪽에 문제가 생겼을 때 다른 쪽이 전력을 공급할 수 있도록 1+1 이중화 구성을 갖춰야 하기 때문입니다.

사실·구조TPU 생태계주 대상 · 기술·제품 · TPU

TPU에서 개방형 표준과 상호운용성은 왜 중요한가?

이 자료가 더한 내용

구글은 JAX를 사용하지만 PyTorch 모델을 수정하지 않고 TPU에서 실행할 수 있도록 TorchTPU를 제공하려 하며, 시스템이 만나는 지점의 개방형 표준이 고객 선택권과 확산에 중요하다고 설명했다.

근거 보기 2

원문 구간 1
하지만 그렇다고 고객들이 특정 시스템에 종속되거나 폐쇄적인 환경만 사용하도록 만들고 싶지는 않습니다. 예를 들어 구글에는 JAX라는 머신러닝 프레임워크가 있습니다. 저희는 JAX를 굉장히 좋아하고 구글 내부에서도 광범위하게 사용하고 있습니다. 하지만 많은 고객은 PyTorch를 선호합니다. 물론 저희가 "TPU를 사용하려면 JAX를 사용하셔야 합니다. 저희는 그게 가장 좋은 방법이라고 생각합니다"라고 이야기할 수도 있겠죠. 실제로 저희는 JAX가 굉장히 훌륭한 프레임워크라고 생각하니까요. 하지만 다른 접근 방식도 있습니다. "JAX가 좋으시면 JAX를 사용하시면 됩니다. 하지만 PyTorch를 사용하고 싶으시다면 기존 모델을 수정하지 않고도 TPU에서 실행할 수 있도록 TorchTPU를 제공하겠습니다." 저희는 이런 방향이 중요하다고 생각합니다. 왜 그런지는 인터넷의 역사를 살펴보면 이해할 수 있습니다. 저는 종종 인터넷 프로토콜인 IP를 예로 드는데요. 1970년대와 1980년대 초반에는 IP와 경쟁하는 네트워크 프로토콜이 굉장히 많았습니다. 그런데 결국 IP가 승리했습니다. 왜 그랬을까요? IP가 개방형 표준이었기 때문입니다. IP는 일종의 모래시계에서 가장 잘록한 허리 부분과 같은 역할을 했습니다. 그 위에서는 어떤 소프트웨어든 실행할 수 있고, 그 아래에는 어떤 하드웨어든 연결할 수 있었습니다. 서로 다른 기업이 만든 시스템이라도 IP라는 공통 표준을 사용하면 문제없이 통신할 수 있었던 것이죠. 누구든 IP를 지원하는 장비를 만들기만 하면 기존 라우터에 연결해서 인터넷의 일부가 될 수 있었습니다.
원문 구간 2
덕분에 인터넷이 전 세계로 빠르게 확산될 수 있었던 겁니다. 저희도 같은 철학을 가지고 있습니다. 서로 다른 시스템이 연결되는 지점에서는 개방형 표준을 사용하는 것이 중요하다고 생각합니다. 물론 특정 고객이 더 높은 성능을 위해 자신의 워크로드에 특화된 방식을 원한다면 그것도 지원할 수 있습니다. 하지만 기본적으로 저희는 개방형 표준을 적극적으로 지원하려고 합니다. 가능하다면 오픈소스 생태계를 기반으로 한 표준을 사용하는 것이 가장 좋다고 생각합니다. 소냐 황 : 지금 구축하는 AI 인프라는 한 공급업체의 폐쇄적이고 독점적인 표준에 맡기기에는 너무 크고 중요하다는 말씀이군요. 아민 바흐다트 : 저희는 정말 그렇게 믿고 있습니다. 고객에게 선택권을 제공하는 것도 굉장히 중요하다고 생각합니다. 구글 클라우드에서 TPU뿐만 아니라 GPU와 다양한 가속기를 폭넓게 지원하고 제공하는 것도 바로 그런 이유 때문입니다. 소냐 황 : AI를 실제 업무에 도입한 이후 아민의 팀이 일하는 방식은 어떻게 달라졌나요? 특히 어떤 업무에서 가장 큰 변화가 나타나고 있나요? 아민 바흐다트 : 가장 먼저 떠올릴 수 있는 분야는 소프트웨어 엔지니어링입니다. 이미 외부에도 많이 알려져 있죠. 구글과 저희 팀은 소프트웨어 개발에 AI를 굉장히 효과적으로 활용하고 있습니다. 코드 작성뿐만 아니라 테스트와 배포, 시스템 설계까지 다양한 업무에서 AI의 도움을 받고 있습니다. 그런데 외부에는 상대적으로 덜 알려져 있지만 하드웨어 엔지니어링에서도 상당한 변화가 일어나고 있습니다.

해석·전망우주 데이터센터주 대상 · 기술·제품 · 우주 데이터센터

우주 데이터센터의 에너지 이점과 운영 제약은 무엇인가?

이 자료가 더한 내용

우주는 지상보다 약 40% 많은 태양광 발전과 태양 동기 궤도 98~100%의 일조 가능성을 제시하지만, 냉각·고장 수리·클러스터 네트워킹이 큰 과제로 남는다고 설명했다.

근거 보기 3

원문 구간 1
지구 밖에서 해법을 찾다 태양광 이용시간 98~100%, 우주 데이터센터의 가능성과 한계 소냐 황 : 이제 조금 엉뚱하지만 흥미로운 질문 두 가지로 인터뷰를 마무리해 보겠습니다. 먼저 우주 궤도에 데이터센터를 구축하는 것에 관한 질문입니다. 구글에서도 이 가능성을 꽤 진지하게 검토하고 있는 것으로 알고 있습니다. 물론 구체적인 내부 계획까지 공개하실 필요는 없습니다. 다만 사람들이 우주 궤도에 데이터센터를 구축하는 것이 경제적으로 타당한지 진지하게 계산하기 시작했다는 사실 자체가 흥미롭습니다. 그만큼 지구에서는 해결하기 어려운 심각한 제약조건이 생겼다는 의미일까요? 아민께서는 우주 궤도 데이터센터의 가능성을 어떻게 보고 계신가요? 아민 바흐다트 : 굉장히 흥미로운 방향이라고 생각합니다. 사실 저희는 이미 이 프로젝트를 추진하고 있습니다. 단순한 공상이나 재미있는 아이디어 정도로 생각하는 것이 아니라, 구글의 중요한 문샷(Moonshot) 프로젝트 중 하나로 보고 실제로 투자하고 있습니다. 인터뷰 초반에 말씀드렸듯이 AI 인프라를 확장하는 데 가장 근본적인 제약조건은 에너지입니다. 특히 충분한 전력을 생산하고 확보하는 것이 가장 큰 문제입니다. 그런데 우주에는 이 문제를 해결하는 데 굉장히 유리한 조건이 있습니다. 먼저 우주에서는 지구 대기로 인한 태양광의 감쇠가 발생하지 않습니다. 따라서 동일한 태양광 설비를 사용하더라도 지상보다 약 40% 더 많은 전력을 생산할 수 있습니다. 이것만으로도 약 1.4배의 이점이 있는 것이죠.
원문 구간 2
게다가 태양 동기 궤도에서는 태양광 패널이 전체 시간의 98~100% 동안 햇빛을 받을 수도 있습니다. 반면 지상에서는 그 비율이 보통 28~30% 수준이고, 아무리 높아도 35% 정도입니다. 그러니까 햇빛을 받을 수 있는 시간만 비교해도 우주가 지상보다 3~4배 정도 유리한 겁니다. 여기에 대기가 없어서 얻는 1.4배의 이점까지 더해집니다. 우주에는 태양이라는 엄청난 에너지원이 존재하는 셈입니다. 이렇게 거의 지속적으로 태양광 발전을 할 수 있다면 에너지를 저장하기 위한 배터리의 필요성도 크게 줄어듭니다. 그만큼 새로운 가능성이 열리는 것이죠. 발전 과정에서 탄소를 배출하지 않는다는 장점도 있습니다. 물론 해결해야 할 과제는 굉장히 많습니다. 정말 많습니다. 가장 먼저 냉각 문제를 생각해 볼 수 있습니다. 얼핏 생각하면 우주는 굉장히 추운 환경이니까 데이터센터를 냉각하기도 쉬울 것 같잖아요? 그런데 실제로는 정반대입니다. 우주에서는 장비에서 발생하는 열을 제거하는 것이 훨씬 더 어렵습니다. 신뢰성도 중요한 문제입니다. 앞서 대규모 AI 클러스터에서는 가속기와 시스템에 끊임없이 장애가 발생한다고 말씀드렸죠. 그런데 그런 장비들을 우주에 배치한다면 어떻게 될까요? 우주에서는 고장 난 장비를 수리하는 것 자체가 훨씬 더 어렵습니다. 물론 불가능한 것은 아니지만 지상 데이터센터에서 수리하는 것과는 비교할 수 없을 정도로 까다로운 작업이 될 겁니다. 여기에 네트워킹도 해결해야 할 굉장히 큰 과제입니다.
원문 구간 3
소냐 황 : 여러 컴퓨팅 클러스터를 서로 연결하는 문제군요. 아민 바흐다트 : 맞습니다. 어쩌면 우주에서는 예비 시스템을 충분히 확보해 두고, 장애가 발생했을 때 다른 시스템으로 전환하는 방식이 도움이 될 수 있을 겁니다. 그리고 앞서 자유공간 광통신에 관해 질문하셨잖아요? 사실 그 기술이 정말 필요한 곳이 바로 우주입니다. 우주에 떠 있는 시스템들을 광섬유 케이블로 일일이 연결할 수는 없으니까요. 대신 레이저를 이용해 서로 통신하는 방식을 사용하게 될 겁니다. 한쪽에서 발사한 레이저가 상대방의 수신기에 정확하게 도달하도록 조준하고, 위성들이 움직이는 동안에도 실시간으로 방향을 보정해야 합니다. 물론 굉장히 어려운 기술적인 과제입니다. 하지만 해결할 수 없는 문제라고 생각하지는 않습니다. 적어도 현재로서는 우주에 데이터센터를 구축하는 것을 근본적으로 불가능하게 만드는 절대적인 한계가 존재한다고 보지 않습니다. 소냐 황 : 이제 마지막 질문입니다. 아민께서 구축하신 거대한 슈퍼컴퓨터의 모습이 계속 머릿속에 남아 있는데요. 그렇다면 지금으로부터 10년 뒤인 2036년에는 세계에서 가장 앞선 슈퍼컴퓨터가 어떤 모습일 거라고 예상하시나요? 아민 바흐다트 : 와, 정말 어려운 질문이네요. 사실 10년이라는 기간이 참 애매합니다. 지금도 2036년의 컴퓨터가 어떤 모습일지 진지하게 고민하고 설계하는 사람들이 분명 있을 겁니다. 하지만 아직은 불확실성이 굉장히 큽니다. 그래도 지금의 기술 발전 방향을 보면 한 가지는 비교적 분명해 보입니다.

시간흐름대로 모든 내용을 살려 정리

자료의 출처와 문제 제기

[원문 유형] 네이버 프리미엄 콘텐츠
[채널] 올바른 미국주식 by SAPIENS
[게시일] 2026.10.15
[원문 URL] https://contents.premium.naver.com/sapiens/sapiensasset/contents/261015164325078dz
[제목] 구글 AI 인프라 총괄 인터뷰 : $200B를 쏟아붓는 구글, Goodput과 OCS가 중요한 이유
[수집 기준] 구매회원 본인이 QR 로그인으로 승인한 구독 열람권을 사용해 개인 문서 보관용으로 확보했다. 목록 메타데이터가 아니라 아래 실제 본문만 분석 근거로 사용한다.
[구독 원문 본문]

안녕하세요 올바른입니다.

구글의 데이터센터에서 TPU를 제외하고 가장 중요한 것을 하나 꼽으라면 OCS를 빼놓을 수 없습니다. 구글 AI 인프라 책임자로부터 OCS에 대해 들어보고 개인적인 생각을 덧대봤습니다.

추론과 RL을 위해 쓰이는 컴퓨팅 규모가 가파르게 증가하면서 이제는 Throughput 개념이 아니라 Goodput 개념이 중요한 시대가 됐습니다. ML 생산성의 3요소를 정리했습니다.

에이전트로 인해서 달라진 것들, TPU에서 JAX를 넘어 PyTorch까지 네이티브로 지원하려는 방향, tape-out 연기가 생각보다 잦은 이유, 우주 데이터센터에 대한 생각이 담긴 자료입니다.

큰 흐름 읽기 (Bird's-eye view)

2026-09-16

1873년, 미국의 미래를 맞힌 투자자들은 왜 파산했을까 (바로가기)

2026-06-12

AI 사이클의 모든 것, 게빈 베이커 인터뷰 : 버블의 역사는 반복되지 않지만, 운율은 반복된다 (바로가기)

2026-03-27

관련 읽을거리와 면책

앤스로픽 CEO 다리오 아모데이 인터뷰 : "Extremely fast, but not infinitely fast" (바로가기)

2025-10-08

오픈AI 퇴사자의 글 #1 : 2027년 AGI가 온다 (바로가기)

AI 심화편 of 심화편

2026-07-09

구글 TPU v8 네트워킹의 모든 것 : 같은 칩을 사도 같은 성능이 나오지 않는 시대 (바로가기)

2026-06-19

추론의 시대, 핵심이 된 메모리 #2 : Agentic AI의 시대, NAND가 중요한 이유 'DualPath' (바로가기)

2026-06-05

AI 가속기 심화편 : GPU vs TPU, 무엇이 칩을 다르게 만드나 (feat. CPU, ASIC, FPGA) (바로가기)

2026-05-27

LLM 추론 토큰 가격의 비밀 : MoE의 시대, 엔비디아 NVL72가 중요한 이유 (바로가기)

유니티 (U)

2026-08-11

유니티 2Q26 실적발표 : 앱러빈이 이미 걸어간 길, 유니티는 이제 그 초입에 서 있다 (바로가기)

포티넷 (FTNT)

2026-09-03

포티넷 기업분석 : Agentic AI가 폭발시킨 트래픽, 방화벽의 두 번째 전성기 (바로가기)

광학 (Optics)

2026-09-09

'빛💡'의 시대 #2 : 구리도 광모듈도 CPO도 다 커진다, AI 인터커넥트의 폭발 (바로가기)

2026-08-26

셈텍 2Q26 실적발표 : 생각보다 더 빨리 온 1.6T 변곡점, 한 분기 사이 생산능력 완판 (바로가기)

2026-08-12

루멘텀 2Q26 실적발표 : ALL BEAT, 더욱 강해진 루멘텀의 모멘텀 (바로가기)

목차와 인터뷰의 출발

2026-08-06

비아비 솔루션스 2Q26 실적발표 : CPO 정상 진행 중, 광학은 Lab → Production으로 (바로가기)

2026-07-03

셈텍(SMTC) 기업분석 : 미디어텍 TPU와 함께 성장할 기업, 'DSP를 지우는 자' (바로가기)

2026-04-17

'빛💡'의 시대 : 광학 밸류체인 한 눈에 보기 (바로가기)

메모리 (Memory)

2026-10-01

마이크론 3Q26 실적발표 : 메모리 Phase 2, 시장은 마진의 높이가 아니라 길이를 묻는다 (바로가기)

2026-06-19

추론의 시대, 핵심이 된 메모리 #2 : Agentic AI의 시대, NAND가 중요한 이유 'DualPath' (바로가기)

2026-01-21

추론의 시대, 핵심이 된 메모리 : 메모리 쇼티지를 떠받치고 있는 힘 (바로가기)

2026-01-07

엔비디아 CES 2026 : Vera Rubin의 시대, ICMS가 불러올 메모리 지각변동 (바로가기)
투자자문 서비스에 따른 투자 시 원금 손실이 발생할 수 있으며, 투자 손익에 대한 책임은 전적으로 고객에게 귀속됩니다. 또한 과거의 투자수익이 미래의 수익률을 보장하지 않습니다.

신규 구독 전에, 아래 투자자문계약 권유문서의 계약 관련 제반 사항을 반드시 읽으시고 충분히 검토하시기 바랍니다.

*투자자문계약 권유문서 : https://naver.me/5ZST47Qf
목차
$200B를 쏟아붓는 AI 인프라 전쟁 : 가속기에 맞춰 건물, 전력, 냉각, 네트워크까지 함께 설계한다
OCS가 Goodput을 높이는 방법들 : 스펙상 Throughput과 다른 실질적인 'Goodput'

AI 인프라 전쟁의 질문

TPU 개발 과정에 대한 얘기들 : AI ASIC의 경제성, DeepMind와의 co-design
'공동 설계' 구글의 경쟁력 : 여러 계층에 걸친 최적화 누적, 성능 개선을 위해 tape-out을 연기하다
데이터센터 확장의 병목 '전력' : 에이전트로 인해 CPU, 스토리지, 네트워크 수요가 증가한다
지구 밖에서 해법을 찾다 : 태양광 이용시간 98~100%, 우주 데이터센터의 가능성과 한계
아민 바흐다트 Amin Vahdat
2026년 10월 6일, 구글 클라우드 시스템/TPU 인프라 책임자
$200B를 쏟아붓는 AI 인프라 전쟁
가속기에 맞춰 건물, 전력, 냉각, 네트워크까지 함께 설계한다

소냐 황 Sonya Huang : 아민 바흐다트님을 모시게 되어 정말 기쁩니다. 인터뷰에 함께해 주셔서 감사합니다.

아민 바흐다트 Amin Vahdat : 초대해 주셔서 감사합니다. 저도 오늘 대화가 정말 기대됩니다.

소냐 황 : 오늘 인터뷰는 특히 기대가 큽니다. 지금은 인류 역사상 유례없는 규모로 CapEx가 확대되고 있는 시기이고, 아민께서는 바로 그 중심에 계시니까요. 구글만 해도 올해 $200B 이상을 CapEx에 사용할 것으로 예상되는데, 그중 대부분이 데이터센터 구축에 투입됩니다.

아민께서는 지난해 말 구글의 AI 인프라 책임자로 임명되셨죠. 말 그대로 역사상 가장 많은 자본이 투입되는 인프라 구축 프로젝트 중 하나를 이끌고 계신 겁니다. 오늘은 이 이야기를 좀 더 깊이 나눠보고 싶습니다.

아민 바흐다트 : 구글뿐만 아니라 업계 전체에 정말 엄청난 한 해입니다. 솔직히 저도 이런 상황은 처음 겪어봅니다. 말씀하신 것처럼 인류 역사 전체를 돌아봐도 지금처럼 거대한 규모의 인프라가 이렇게 빠른 속도로 구축되는 것은 정말 믿기 어려운 일입니다.

AI 데이터센터와 범용 설계의 차이

소냐 황 : 본격적으로 들어가기 전에 청취자들을 위해 기초적인 질문부터 드리겠습니다. AI 데이터센터는 무엇이고, 기존의 비AI 데이터센터와는 어떻게 다른가요?

아민 바흐다트 : 좋은 질문입니다. 사실 AI 데이터센터와 기존 데이터센터는 공통점이 많습니다. 둘 다 콘크리트로 지은 건물 안에 전력 설비와 냉각 시스템을 갖춰야 합니다. 대규모 연산 장치를 서로 연결하는 네트워크 인프라도 필요하고, 상당한 규모의 스토리지도 들어갑니다.

가장 큰 차이는 얼마나 특정 목적에 맞춰 설계하느냐에 있습니다. 과거에는 데이터센터 건물을 지을 때 20~30년을 내다보고 설계했습니다. 그동안 어떤 서버와 네트워크 장비, 스토리지, 가속기가 들어올지 알 수 없었기 때문에 최대한 범용적으로 만들어야 했습니다. 하드웨어의 수명은 보통 6년 정도이니 하나의 건물에서 여러 세대의 장비를 수용할 수 있어야 했던 것이죠.

그런데 AI 데이터센터는 접근 방식이 다릅니다. 처음부터 특정 용도에 맞춰 건물과 하드웨어를 함께 설계하는 경우가 많습니다. 예를 들어 어떤 데이터센터에는 스토리지를 거의 넣지 않기로 결정할 수도 있습니다. 일반적인 스토리지 랙은 전력 사용량이 10~40kW 정도이지만, 오늘날의 TPU나 GPU 랙은 수백 kW에 달합니다. 앞으로는 랙당 전력 사용량이 MW급까지 올라갈 수도 있습니다.

이렇게 되면 스토리지 랙 30개를 배치하는 공간과 AI 가속기 랙 한두 개를 배치하는 공간은 설계부터 완전히 달라집니다. 필요한 공간의 크기뿐만 아니라 전력 공급 방식과 네트워크 요구사항도 크게 다릅니다. 특히 HDD 중심의 스토리지 랙은 AI 가속기 랙에 비해 네트워크 대역폭 요구량이 훨씬 적습니다.

가속기에 맞춘 건물·전력·냉각

그런데 모든 종류의 장비를 수용할 수 있도록 데이터센터를 설계한다면 어떻게 될까요? 건물을 필요 이상으로 크게 지어야 하거나 전력과 냉각 설비를 과도하게 구축해야 할 수도 있습니다. 그렇다고 이런 범용성을 앞으로 30년 동안 유지하는 것도 현실적으로 어렵습니다.

그래서 AI 데이터센터는 처음부터 목적을 명확하게 정하고 설계하는 것이 중요합니다. 어떤 하드웨어가 들어갈지에 맞춰 건물을 설계하고, 전력 공급부터 냉각 시스템까지 함께 최적화해야 한다는 것입니다.

*코멘트 → AI 데이터센터는 단순히 GPU나 TPU를 많이 설치하는 건물이 아닙니다. 처음부터 가속기의 전력 소비량과 발열량, 네트워크 구조를 고려해 건물과 전력/냉각 인프라를 함께 설계해야 합니다. 이를 System-level Co-design이라고 합니다.

특히 엔비디아 GB200 NVL72는 랙당 약 120kW의 전력을 소비하며, 차세대 AI 랙은 수백 kW에서 최대 1MW까지 높아질 가능성이 있습니다. 이 정도 전력 밀도에서는 기존의 전력 공급과 공랭식 냉각만으로 대응하기 어렵습니다. 액체냉각과 새로운 전력 공급 방식이 중요해지는 이유입니다. 네트워크도 마찬가지입니다. AI 가속기끼리 막대한 데이터를 주고받기 때문에 일반적인 스토리지 네트워크와 분리하고, 가속기 간 통신에 최적화된 네트워크를 구축해야 합니다.

소냐 황 : 제 포트폴리오 기업인 Ineffable Intelligence에 대규모 베어메탈 클러스터를 공급하셨을 때 출하 당시 사진을 봤습니다. 정말 멋지더군요.

*코멘트 → 소냐 황이 언급한 것은 구글이 데이비드 실버(David Silver)의 AI 스타트업 Ineffable Intelligence에 공급한 엔비디아 Vera Rubin 기반 AI 슈퍼컴퓨터입니다

Ineffable 클러스터와 광섬유

. 사진은 이것입니다. 데이비드 실버는 구글 딥마인드에서 AlphaGo 개발을 이끌었던 세계적인 강화학습 연구자입니다. 그는 기존 LLM처럼 인터넷의 인간 생성 데이터를 학습하는 접근보다, AI가 환경에서 직접 경험하고 시행착오를 통해 지능을 발전시키는 접근에 집중하고 있습니다. 소냐 황은 세쿼이아캐피털의 파트너로서 이 회사에 직접 투자했습니다. 따라서 인터뷰에서 '제 포트폴리오 기업'이라고 표현한 것입니다.

아민 바흐다트 : 맞습니다.

소냐 황 : 저는 이런 데이터센터를 볼 때마다 인류 역사상 가장 거대한 건설 프로젝트 중 하나를 보고 있다는 생각이 듭니다. 인류가 이 정도 규모의 인프라를 실제로 구축할 수 있다는 것 자체가 정말 놀랍습니다. 역사에 남을 만한 성취라고 생각합니다.

아민 바흐다트 : 사진이 정말 멋지게 나오긴 했습니다. 그런데 사실 그 사진에 나온 건 전체 클러스터 중 랙 몇 개에 불과합니다. 특히 광섬유 케이블이 연결된 모습을 보면 정말 아름답습니다. 물론 아름다움의 기준은 사람마다 다르겠지만, 적어도 저나 이 방송을 듣는 분들 눈에는 굉장히 멋진 광경일 겁니다.

그 사진을 소셜미디어에 올렸을 때 Ineffable에 대한 관심이 정말 뜨거웠습니다. 저도 Ineffable이 하는 일을 좋아하고, 팀도 굉장히 훌륭하다고 생각합니다. 그런데 흥미로운 건 사람들이 특히 좋아했던 부분이 서버 랙 자체가 아니라 광섬유 케이블이 만들어내는 프랙탈 같은 패턴이었다는 겁니다. 실제로 저희가 올린 게시물 중에서도 반응이 가장 좋았던 글 중 하나였습니다. 저희도 앞으로가 무척 기대됩니다.
OCS가 Goodput을 높이는 방법들
스펙상 Throughput과 다른 실질적인 'Goodput'

FLOPS에서 실제 워크로드 성과로

소냐 황 : 그 사진을 보고 정말 소름이 돋았습니다. 그런데 이렇게 거대한 규모의 인프라를 구축할 때는 어떤 기준으로 성과를 측정하고 그 결과에 대한 책임을 지시나요? 인터뷰를 시작하기 전에 FLOPS만으로는 실제 성과를 제대로 측정하기 어렵고, 다른 지표를 더 중요하게 보신다고 말씀하셨는데요. 그 부분을 좀 더 자세히 설명해 주시겠습니까?

아민 바흐다트 : FLOPS를 비롯해 칩의 성능을 나타내는 지표들은 대부분 이론적인 수치입니다. 특정 조건에서 그 칩이 낼 수 있는 최대 연산 성능을 보여주는 것이죠. 하지만 저희가 정말 중요하게 생각하는 것은 실제 워크로드를 실행했을 때 얼마나 높은 성능이 나오는가입니다.

실제 성능은 칩 하나만으로 결정되지 않습니다. FLOPS도 중요하고 HBM이나 SRAM의 용량도 중요합니다. 하지만 더 중요한 것은 이런 칩들을 2개, 4개, 8개, 16개씩 연결하고, 나아가 수천 개에서 수만 개까지 확장했을 때 시스템 전체가 얼마나 효율적으로 작동하느냐입니다.

TPU나 GPU 같은 가속기뿐만 아니라 여기에 데이터를 공급하는 CPU와 가속기들을 연결하는 네트워크까지 모두 성능에 영향을 미칩니다. 그래서 저희는 어떤 워크로드를 실행하고 있는지, 그리고 그 워크로드에서 실제로 얼마나 높은 성능을 달성하는지를 중요하게 봅니다.

이때 유용하게 사용할 수 있는 지표 중 하나가 FLOPS 활용률입니다. 예를 들어 어떤 시스템이 이론적으로 수백 테라플롭스나 수 페타플롭스의 연산 성능을 낼 수 있다고 해보겠습니다. 중요한 것은 실제 워크로드를 실행했을 때 그 이론적인 성능의 몇 퍼센트를 활용할 수 있느냐는 것입니다.

이것이 저희가 말하는 Goodput, 즉 실제로 유효한 작업을 얼마나 처리할 수 있는지를 이해하는 출발점입니다.

Throughput과 Goodput의 구분

소냐 황 : Goodput이 정확히 무엇인가요?

아민 바흐다트 : 먼저 일반적으로 사용하는 Throughput이라는 개념부터 생각해 보겠습니다. Throughput은 시스템이 얼마나 많은 작업을 처리할 수 있는지를 보여주는 지표입니다. 그런데 실제 워크로드에는 여러 가지 비효율이 존재합니다. 특히 중요한 것이 시스템의 신뢰성입니다.

AI 학습이나 추론 서빙, 에이전트 워크로드에서는 수많은 구성 요소가 서로 긴밀하게 동기화되어 작동해야 하는 경우가 많습니다. 수천 개에서 수만 개, 심지어 10만 개에 달하는 구성 요소가 마이크로초 또는 밀리초 단위로 서로 협력해야 한다고 생각해 보세요.

그런데 그중 하나라도 고장 나면 어떻게 될까요? 전체 시스템이 멈출 수도 있습니다. 그러면 어디에서 문제가 발생했는지 찾아내야 하고, 마지막 체크포인트가 어디인지 확인한 다음 시스템을 복구해서 다시 실행해야 합니다. 최악의 경우에는 처음부터 작업을 다시 시작해야 할 수도 있습니다. 실제로 추론 과정에서도 이런 일이 발생할 수 있습니다.

이 과정에서 이미 수행했던 연산을 다시 실행하거나 오류의 원인을 찾아내느라 시간을 허비하게 됩니다. 분명 시스템은 계속 일을 하고 있지만, 정작 최종 결과를 만들어내는 데는 아무런 도움이 되지 않는 작업들입니다.

종이에 수학 문제를 푼다고 생각해 보겠습니다. 1단계부터 4단계까지 열심히 풀었는데 중간에 실수를 발견해서 다시 1단계로 돌아가야 한다면 어떨까요? 분명 그동안 계속 문제를 풀고 있었던 것은 맞습니다. 하지만 정답에 도달하는 데 실제로 기여한 작업은 얼마나 될까요?

저희가 중요하게 생각하는 것이 바로 이 차이입니다.

장애·복구까지 포함한 유효 작업

시스템 장애와 복구, 중복 연산, 대기 시간까지 모두 고려했을 때 실제로 얼마나 많은 유용한 결과를 만들어냈는지를 봐야 합니다. 단순히 이론적인 벤치마크에서 얼마나 높은 Throughput을 기록했느냐가 아니라, 실제 워크로드에서 얼마나 높은 Goodput을 달성했느냐로 저희의 성과를 평가해야 한다는 것입니다.

그런데 안타깝게도 가속기가 10만 개에 달하는 규모가 되면…

소냐 황 : 마침 그걸 여쭤보려고 했습니다. 그 정도 규모라면 시스템 어딘가에서는 항상 장애가 발생하고 있을 것 같은데요.

아민 바흐다트 : 항상 그렇습니다. 사실 칩 하나하나가 정말 놀라운 기술의 결정체입니다. 인류가 만들어낼 수 있는 가장 최첨단의 반도체 기술이 집약되어 있죠. 게다가 겉으로는 하나의 칩처럼 보이지만, 실제로는 그 패키지 안에 2개, 4개, 8개 또는 그 이상의 칩렛이 들어갈 수도 있습니다. 주변에는 HBM이 있고 네트워크 연결도 필요합니다. 경우에 따라서는 CPO(Co-Packaged Optics) 같은 기술까지 적용됩니다.

그만큼 고장이 발생할 수 있는 지점이 굉장히 많다는 뜻입니다.

이런 가속기가 10만 개씩 모여 있는 시스템이라면 어딘가에서 문제가 발생하는 것은 사실상 피할 수 없습니다. 따라서 장애가 발생했을 때 거의 실시간으로 탐지하고 복구할 수 있는 체계를 갖춰야 합니다.

그런데 이게 정말 어려운 텔레메트리 문제입니다. 수많은 장비에서 발생하는 데이터를 분석해 정확히 어디에서 문제가 생겼는지 찾아내야 하니까요. 말 그대로 건초더미에서 바늘을 찾는 것과 같습니다. 어떤 문제는 몇 초나 몇 분 안에 해결해야 하고, 워크로드에 따라서는 몇 시간, 며칠, 심지어 몇 주에 걸쳐 이런 작업을 계속 수행해야 할 수도 있습니다.

대규모 시스템에서 반복되는 장애

그래서 저희는 데이터센터가 얼마나 많은 연산을 수행했느냐보다 실제로 중요한 워크로드에서 얼마나 높은 Goodput을 제공했느냐를 기준으로 성과를 평가합니다.

소냐 황 : 'Goodput'은 구글 내부 용어인가요, 아니면 업계 전반에서 쓰는 표현인가요?

아민 바흐다트 : 원래는 구글 내부에서 사용하던 용어인데, 최근에는 업계 전반에서도 점점 더 많이 사용하기 시작한 것 같습니다.

소냐 황 : 대략 어느 정도인지 감을 잡고 싶은데요. 가속기가 10만 개 정도 있다면 장애가 얼마나 자주 발생하나요? 1분에 한 번꼴인가요, 아니면 하루에 한 번 정도인가요?

아민 바흐다트 : 가속기가 10만 개 정도라면 적어도 하루에 여러 번은 장애가 발생할 겁니다. 시스템을 어떻게 구성했느냐에 따라서는 한 시간에도 여러 차례 문제가 생길 수 있습니다.

소냐 황 : 가장 흔한 고장 원인은 무엇인가요?

아민 바흐다트 : 바로 그게 어려운 부분입니다. 만약 반복적으로 발생하는 공통적인 장애 원인이 있다면 저희가 이미 찾아내서 해결했을 겁니다. 그런데 실제로는 예상하지 못했던 새로운 문제들이 끊임없이 나타납니다. 롱테일(Long Tail) 문제에 가깝습니다. 새로운 제품을 도입할 때마다 미처 예상하지 못했던 문제가 발견되곤 합니다.

초고속 네트워크나 장비 간 연결 방식에서 문제가 발생할 수도 있고, 하드웨어 자체에 결함이 있을 수도 있습니다. 이런 문제들은 발견할 때마다 하나씩 해결해 나갑니다.

그런데 소프트웨어도 상당한 장애 원인이 될 수 있습니다. 예를 들어 칩 자체는 이론적으로 높은 FLOPS 성능을 낼 수 있다고 해보겠습니다

롱테일 장애와 소프트웨어 문제

. 그런데 컴파일러나 런타임에 버그가 있거나, 모델 또는 운영체제에서 문제가 발생하면 실제 성능은 크게 떨어질 수 있습니다. 하드웨어가 아무리 완벽하고 안정적으로 작동하더라도 소프트웨어에 문제가 생기면 시스템 전체의 성능과 안정성이 영향을 받을 수 있다는 것입니다.

*코멘트 → <구글 TPU v8 네트워킹의 모든 것 : 같은 칩을 사도 같은 성능이 나오지 않는 시대> 자료에서 OCS에 대해서 말씀드리긴 했는데 이게 OCS에 대해서 더 깊게 들어가도 상당히 재밌습니다. Goodput을 얘기할 때 OCS를 얘기하지 않을 수가 없고, 데이터센터 단위 최적화 설계에 있어서도 OCS를 뺴놓고 설명할 수 없습니다.

이건 따로 좀 더 깊게 쭉 설명해보겠습니다:

1. Goodput은 구체적으로 무엇으로 측정하는가?
구글은 ML Productivity Goodput을 세 가지로 구분합니다.

Program Goodput : 실제 학습 코드가 칩의 이론적 FLOPS를 얼마나 유효하게 활용하는가 → 커널 최적화, MFU 개선, 통신 병목 제거 등등을 통해서 높일 수 있습니다.
Runtime Goodput : 실행 중인 시간 중 실제 학습이 진전된 비율 → 체크포인트, 장애 탐지 및 복구가 중요합니다.
Scheduling Goodput : 학습에 필요한 모든 가속기를 얼마나 안정적으로 확보하는가 → 스케줄러, 예비 서버, OCS를 통한 동적 재구성 등이 중요합니다.

세 지표가 실제 연산량에 미치는 영향을 단순화하면

→ 전체 유효 연산 효율 = Scheduling Goodput x Runtime Goodput x Program Goodput입니다.

ML Productivity Goodput의 세 요소

그래서 예를 들어 가상의 클러스터에서 Program Goodput이 60%, Runtime Goodput이 80%, Scheduling Goodput이 90%라면 전체 유효 연산 효율은 약 43.2%입니다. 같은 TPU 10만 개를 보유하더라도 Goodput이 다른 두 기업의 실제 학습 능력은 상당히 달라질 수 있습니다. 그런 의미에서 '같은 칩을 사도 같은 성능이 나오지 않는 시대'란 것입니다.

여기서 OCS는 주로 Scheduling Goodput과 Runtime Goodput을 개선합니다. 네트워크 토폴로지까지 최적화하는 경우에는 Program Goodput도 높일 수 있습니다. 그럼 모든 면에서 성능을 끌어올릴 수 있는 게 아닌가 싶으실텐데, 맞습니다. 그래서 OCS가 굉장히 중요하고 단순한 Components가 아니라 Systems임을 강조드리는 것입니다.

2. OCS는 고장난 칩을 어떻게 우회하는가?
OCS의 본질은 소프트웨어로 물리적인 연결을 변경할 수 있다는 점입니다. OCS의 반대를 표현하자면 EPS입니다. 각각 Optical Circuit Switching과 Electrical Packet Switch입니다. EPS는 광 → 전기 → 광 변환을 통해서 패킷별로 목적지를 판단해주는 것이고, OCS는 광학적으로 포트와 포트 사이의 경로를 연결해주는 것입니다.

구글의 MEMS 방식 OCS는 미세한 거울을 움직여 광섬유의 연결 상대를 바꿉니다. 한 번 회로가 설정되면 별도의 광-전기-광 변환 없이 데이터가 그 광 경로를 통과합니다. 특히 중요한 것은 OCS가 네트워크 연결을 물리적 배선을 다시 설치하지 않고도 재구성할 수 있는 자원으로 바꿔놓는다는 점입니다.

OCS로 자원을 다시 연결하는 방식

실질적인 예시는 TPU v4 논문에서 나온 바 있습니다. 논문의 이름부터가 <TPU v4: An Optically Reconfigurable Supercomputer for Machine Learning with Hardware Support for Embeddings>입니다. 이 방식을 TPU v7, v8도 모두 사용하고 있기 때문에 기본적으로 스케일만 더 커졌을 뿐 핵심 역할과 구조는 같습니다. 그래서 한 번 자세히 살펴볼만 합니다.

구글은 TPU v4에서 4,096개의 칩을 64개씩 묶은 Cube 64개로 구성했습니다. Cube 내부 연결은 고정된 전기 배선으로 유지하면서 Cube와 Cube 사이의 광 연결을 OCS로 재구성합니다.

예를 들어 256개 TPU가 필요한 작업이 있다고 하겠습니다
고정형 네트워크에서는 물리적으로 필요한 형태로 연결된 연속된 TPU 자원을 확보해야 합니다.
OCS 기반 네트워크에서는 서로 떨어져 있는 정상 Cube 네 개를 선택해 하나의 256개 TPU Slice를 만들 수 있습니다.

고장난 Cube가 있더라도 다른 정상 Cube를 선택해 필요한 토폴로지를 구성할 수 있습니다. 그러면 결과적으로 구글은 실제 TPU v4 시스템에서 OCS를 적용하면 CPU 호스트에 요구되는 가용성 수준을 99.9%에서 99%까지 낮추면서도 대규모 작업에 필요한 자원을 확보할 수 있다고 설명했습니다. 이는 개별 하드웨어의 신뢰성이 완벽하지 않더라도 전체 시스템의 가용성을 높일 수 있다는 뜻입니다.

3. OCS는 장애 복구뿐 아니라 실제 학습 속도도 높입니다
앞서 OCS를 이용하면 고장난 장비를 우회하고 정상적인 TPU들을 다시 연결해 자원 활용률을 높일 수 있다고 설명했습니다

OCS와 분산학습 통신 병목

. 그런데 OCS의 역할은 여기서 끝나지 않습니다. 학습 모델의 통신 패턴에 맞춰 TPU 사이의 네트워크 연결 구조 자체를 최적화할 수 있다는 점도 중요합니다.

대규모 분산학습에서는 수많은 TPU가 나눠 계산한 중간 결과와 그래디언트를 서로 주고받아야 합니다. 이 과정에서 All-reduce, All-gather, All-to-all 같은 Collective Communication이 반복적으로 발생합니다. 문제는 TPU의 연산 성능이 아무리 높더라도 네트워크가 데이터를 제때 전달하지 못하면 다른 TPU들이 기다려야 한다는 점입니다. 특히 수천 개의 TPU가 동기화되어 작동하는 환경에서는 일부 장비나 통신 경로의 지연이 전체 학습 속도를 떨어뜨릴 수 있습니다.

이를 하나의 학습 단계에 걸리는 시간으로 단순화하면 다음과 같습니다.
→ Step = Compute Time + Exposed Communication + Straggler입니다.

Compute Time : TPU가 실제 연산을 수행하는 시간
Exposed Communication : 연산과 동시에 처리하지 못해 추가로 소요되는 통신 시간
Straggler Delay : 다른 TPU보다 느린 장비나 통신 경로를 기다리면서 발생하는 추가 지연시간

여기서 OCS는 TPU 사이의 연결 구조를 변경해 통신 패턴에 적합한 네트워크를 구성할 수 있습니다. 이를 통해 통신 병목과 대기 시간을 줄이면 칩의 FLOPS를 높이지 않고도 동일한 학습 단계를 더 빠르게 완료할 수 있습니다. 결국 OCS는 장애로 인한 연산 손실을 줄이는 것뿐 아니라, 정상적으로 작동하는 상황에서도 네트워크 효율을 높여 실제 학습 처리량을 개선할 수 있는 기술입니다

TPU v8t·v8i의 서로 다른 설계

. 이는 앞서 설명한 Program Goodput 개선으로 이어집니다.

4. TPU v8에서 Goodput과 OCS의 역할은 어떻게 진화했는가?
구글이 TPU v8을 훈련용 v8t와 추론용 v8i로 나누고 서로 다른 네트워크 토폴로지를 채택한 이유는 두 워크로드의 병목이 다르기 때문입니다. 이를 Goodput 관점에서 살펴보면 구글의 설계 방향을 더 명확하게 이해할 수 있습니다.

① TPU v8t : 대규모 학습에서 장애로 인한 중단 시간을 최소화

구글은 TPU v8t를 설계하면서 97% 이상의 Goodput을 목표로 제시했습니다. 여기서 97%는 이론적 FLOPS 활용률이 아니라 실제로 유용한 학습에 시간을 얼마나 사용할 수 있는지를 의미합니다. 이를 위해 실시간 텔레메트리로 장애를 탐지하고, 문제가 발생한 ICI 링크를 자동으로 우회하거나 OCS를 통해 네트워크 연결을 재구성하는 기술을 도입했습니다.

기존 TPU v4에서는 장애가 발생하면 작업을 중단하고 정상 장비에 다시 배치한 다음 마지막 체크포인트부터 학습을 재개하는 방식에 의존했습니다. 반면 TPU v8t는 일부 링크 장애가 발생하더라도 학습을 중단하지 않고 통신 경로를 변경할 수 있도록 설계했습니다. 체크포인트에서 학습을 재개하려면 복구 시간뿐 아니라 마지막 저장 이후 수행했던 연산을 다시 처리하는 비용도 발생합니다. 처음부터 학습을 중단하지 않고 장애를 우회할 수 있다면 그만큼 Runtime Goodput을 높일 수 있습니다.

② TPU v8i : MoE 추론에서 통신 지연시간을 최소화

추론용 TPU v8i는 해결해야 할 문제가 다릅니다. 특히 MoE 모델은 토큰마다 서로 다른 전문가(Expert)를 호출하기 때문에 여러 칩 사이에서 All-to-all 통신이 빈번하게 발생합니다

Boardfly와 추론 통신 지연

. 기존 3D Torus 구조에서는 멀리 떨어진 칩과 통신할 때 여러 홉을 거쳐야 하므로 지연시간이 늘어날 수 있습니다.

구글은 이를 해결하기 위해 Boardfly 토폴로지를 도입했습니다. Boardfly는 칩 사이의 통신 경로를 단축해 통신 집약적인 워크로드에서 최대 50%의 지연시간 개선을 목표로 합니다. 여기에 CAE(Collectives Acceleration Engine)를 탑재해 칩 내부 Collective 연산의 지연시간도 최대 5배 줄였다고 설명했습니다.

여기서도 OCS가 중요한 역할을 합니다. Boardfly를 구성하는 36개 그룹 사이의 광 연결을 담당하며, 워크로드에 적합한 물리적 네트워크를 구성할 수 있도록 지원합니다. 다만 토큰이 생성될 때마다 OCS의 거울을 움직이는 것은 아닙니다. 미리 설정된 광 경로를 통해 실제 데이터가 전달되는 구조입니다.

훈련용 TPU v8t는 장애로 낭비되는 시간을 줄이는 데,
추론용 TPU v8i는 토큰 생성 과정에서 발생하는 통신 지연을 줄이는 데 초점을 맞춘 것입니다.

③ Virgo Network : 단일 Pod를 넘어 데이터센터 캠퍼스 전체로 확장

구글의 Virgo Network는 여러 TPU v8t Pod를 연결하는 Scale-out 네트워크입니다. 단일 패브릭에서 최대 134,000개 이상의 TPU를 연결할 수 있도록 설계됐습니다. 이 정도 규모에서는 네트워크 대역폭을 늘리는 것만으로 충분하지 않습니다. 수많은 TPU가 동시에 학습하는 과정에서 일부 장비나 통신 경로의 장애와 지연이 전체 작업의 성능을 떨어뜨릴 수 있기 때문입니다.

따라서 Virgo는 다중 스위칭 플레인을 통한 장애 격리와 텔레메트리, Straggler 탐지 및 완화 같은 기술을 함께 활용합니다

Virgo 네트워크의 규모 확장

. 특정 장비나 경로에 문제가 생기더라도 그 영향이 전체 클러스터로 확산되는 것을 최소화하려는 것입니다. 구글은 개별 TPU의 연산 성능을 높이는 것을 넘어, 수십만 개의 TPU를 연결한 환경에서도 실제 학습 처리량과 Goodput을 최대한 유지할 수 있도록 OCS를 활용해서 네트워크 전체를 설계하고 있습니다.

5. 수십만 개의 가속기를 연결할수록 Goodput을 유지하기 어려워지는 이유
가속기 수가 늘어날수록 장애가 발생할 가능성도 높아집니다. 예를 들어 TPU 134,000개가 각각 99.9%의 가용성을 가진다고 가정하면, 특정 시점에 평균적으로 약 134개의 칩을 사용할 수 없다는 계산이 나옵니다. 개별 칩의 신뢰성이 아무리 높더라도 수십만 개를 연결한 시스템에서는 어딘가에서 장애가 발생하는 것이 사실상 불가피합니다.

문제는 대규모 AI 학습에서는 일부 가속기의 장애만으로도 전체 학습이 중단될 수 있다는 점입니다. 이 때문에 구글은 일정 간격으로 학습 상태를 저장하는 Checkpointing을 사용합니다. 다만 장애가 발생하면 마지막 체크포인트 이후 수행했던 연산을 다시 실행해야 하므로 그만큼 시간과 컴퓨팅 자원이 낭비됩니다. 체크포인트를 자주 저장하면 손실은 줄어들지만 저장 자체에도 시간이 필요합니다.

바로 여기서 OCS의 역할이 중요해집니다. 장애가 발생한 장비를 제외하고 정상적인 TPU들로 네트워크를 재구성할 수 있기 때문입니다. 일부 링크 장애는 학습을 중단하지 않고 우회할 수도 있습니다. 장비를 교체해야 하는 경우에도 스케줄러와 체크포인트 복구 시스템을 통해 작업을 빠르게 재개할 수 있습니다.

결국 Goodput을 높인다는 것은 장애를 완전히 없애는 것이 아니라, 장애가 발생하더라도 실제 연산에 미치는 영향을 최소화하는 것입니다

레퍼런스 스택과 맞춤 최적화

. 구글이 OCS뿐 아니라 텔레메트리, 장애 복구 소프트웨어, 스토리지까지 함께 최적화하는 이유입니다.

소냐 황 : 엔비디아나 구글 TPU 팀처럼 AI 가속기를 개발하는 곳에서는 표준 레퍼런스 아키텍처를 제공하나요?
예를 들어 '우리 가속기를 가장 효율적으로 사용하려면 시스템을 이렇게 구성해야 한다'는 식으로 권장하는 설계가 있는 건가요? 아니면 반도체 제조사가 제공하는 기본 설계와는 별개로, 실제 데이터센터를 구축하고 운영하는 기업이 상당 부분을 직접 설계하고 최적화해야 하는 건가요?

아민 바흐다트 : 네, 레퍼런스 스택은 존재합니다. 엔비디아는 시스템 통합 역량이 굉장히 뛰어난 기업입니다. 반도체 기업이지만 단순히 칩만 만드는 회사는 아닙니다. 하드웨어부터 소프트웨어까지 잘 통합된 레퍼런스 스택을 제공하고 있습니다. 다만 대부분의 고객은 이 레퍼런스 스택을 그대로 사용하기보다는 자신들의 워크로드에 맞춰 일부를 최적화합니다. 특정 작업에서 더 높은 성능을 얻을 수 있도록 시스템 구성을 조정하는 것이죠.

TPU도 마찬가지입니다. 저희 역시 표준 레퍼런스 스택을 제공하고 있고 대부분의 고객이 이를 사용합니다. 하지만 많은 고객이 자신들의 환경과 워크로드에 맞춰 추가적인 최적화를 진행합니다.

소냐 황 : 이번에는 전체 인프라 용량에 관해 여쭤보겠습니다. 구글 내부적으로 AI 추론 서빙 용량을 6개월마다 거의 두 배씩 늘려야 한다고 말씀하셨다는데, 사실인가요?

*코멘트 → 2025년 11월 21일, 구글 AI 인프라 책임자인 아민 바흐다트가 전직원 회의에서 "수요를 충족하기 위해 6개월마다 AI 서비스 용량을 2배로 늘려야 한다"고 말했던 것을 언급한 것입니다.

추론 서빙 용량의 의미

아민 바흐다트 : 먼저 여기서 말하는 용량이 무엇인지 명확히 하고 싶습니다. 제가 말하는 것은 실제로 얼마나 많은 토큰을 생성할 수 있느냐, 즉 AI 추론 서빙 능력입니다. 하드웨어와 소프트웨어의 성능이 모두 반영된 결과라고 보시면 됩니다.

6개월마다 하드웨어의 FLOPS를 무조건 두 배로 늘려야 한다는 뜻은 아닙니다. 물론 그것도 하나의 방법이 될 수 있습니다. 하지만 제가 말하는 것은 6개월마다 실제 토큰 생성 능력을 두 배로 높여야 한다는 것입니다.

그리고 이러한 성능 향상의 상당 부분은 하드웨어뿐만 아니라 소프트웨어에서도 나올 것입니다. 모델 자체를 최적화할 수도 있고, 런타임을 개선할 수도 있습니다. 수십 가지, 수백 가지의 작은 최적화가 계속 쌓이면서 전체 시스템의 토큰 생성 능력을 높이는 것이죠. 어떤 방식으로 달성하든 저희에게 요구되는 용량 증가 속도는 정말 놀라울 정도입니다.

소냐 황 : 지난 몇 년 동안 데이터센터와 반도체 기술이 계속 발전했고, 모델과 소프트웨어도 크게 개선됐잖아요.
그렇다면 '와트당 지능(같은 전력으로 얼마나 높은 AI 성능을 낼 수 있는지)'을 기준으로 봤을 때, 실제 성능 향상분 중 어느 정도가 반도체 자체의 발전에서 나온 건가요? 또 모델이나 소프트웨어 같은 다른 요소들이 기여한 비중은 얼마나 되나요?

아민 바흐다트 : 각각의 요소가 얼마나 기여했는지 정확하게 나눠서 계산한 수치는 없습니다. 다만 제 경험으로는 와트당 지능이 향상되는 데 가장 크게 기여하는 것은 모델 자체의 발전이라고 생각합니다.

사실 '와트당 지능'은 굉장히 좋은 지표입니다. 저희도 와트당 Goodput을 중요하게 생각합니다

전력당 지능과 용량 확장

. 왜 하필 전력을 기준으로 측정해야 하는지는 나중에 좀 더 이야기할 수 있을 것 같습니다. 여기서 Goodput은 특정 워크로드에서 실제로 얼마나 많은 지능이나 유효한 작업량을 제공했는지를 나타내는 지표라고 보시면 됩니다.

가장 큰 개선은 모델에서 나오지만, 소프트웨어 시스템의 기여도 상당합니다. 아무리 좋은 하드웨어를 확보하더라도 소프트웨어가 뒷받침되지 않으면 그 성능을 제대로 활용할 수 없기 때문입니다. 물론 하드웨어의 발전 속도도 정말 놀랍습니다. 지금은 하드웨어 자체의 발전만으로도 전년 대비 두 배 이상의 성능 향상을 기대할 수 있는 시대입니다.

물론 이런 성능 향상이 공짜로 얻어지는 것은 아닙니다. 하지만 중요한 것은 하드웨어의 발전이 일종의 승수 효과를 만들어낸다는 점입니다. 하드웨어의 성능이 높아진 상태에서 모델과 소프트웨어까지 계속 개선되면 그 효과가 서로 곱해지면서 훨씬 더 큰 성능 향상을 만들어낼 수 있습니다.
TPU 개발 과정에 대한 얘기들
AI ASIC의 경제성, DeepMind와의 co-design
소냐 황 : 이번에는 TPU 개발과 공동 설계(Co-design)에 관해 좀 더 이야기해 보고 싶습니다. 구글은 이미 10년도 더 전에 자체 AI 칩을 개발하기 시작했잖아요. 당시만 해도 상당히 이례적인 결정이었는데, 그 이후 TPU 프로그램이 어떻게 발전해 왔는지 설명해 주시겠습니까?

아민 바흐다트 : 2013년에 TPU 프로그램을 시작했을 당시에는 정말 업계의 일반적인 생각과 정반대되는 결정이었습니다. 당시에는 아무리 뛰어난 엔지니어에게 물어봐도 특정 워크로드만을 위한 전용 가속기를 개발하는 것은 좋은 선택이 아니라고 했을 겁니다

TPU가 시작된 문제와 범용화

. 그럴 만한 이유가 있었습니다. 당시에는 무어의 법칙에 따라 범용 프로세서의 성능이 18~24개월마다 두 배씩 향상되고 있었으니까요. 게다가 C++, Java, Python처럼 개발자들에게 이미 익숙한 프로그래밍 언어와 개발 환경도 잘 갖춰져 있었습니다.

소냐 황 : 당시 반도체 업계에서는 특정 작업에 특화된 칩을 개발하는 것보다 계속 발전하는 범용 CPU를 활용하는 편이 장기적으로 유리하다고 생각했던 거군요. AI 분야에서 말하는 'Bitter Lesson'과 비슷한 이야기네요.

아민 바흐다트 : 맞습니다. 당시 반도체 업계의 씁쓸한 교훈은 결국 특정 용도에 특화된 하드웨어는 성공하기 어렵다는 것이었습니다. 그런데 구글이 운영하던 일부 애플리케이션은 전용 하드웨어를 사용했을 때 얻을 수 있는 이점이 엄청나게 컸습니다. 같은 작업을 범용 CPU로 처리하려면 상상하기 어려울 정도로 많은 CPU가 필요했기 때문입니다.

그래서 2013년 TPU 프로그램을 시작할 당시에는 구글 내부에서도 성공을 확신하지 못했습니다. 일종의 도박이었던 셈이죠. 그런데 결과적으로는 엄청난 성공을 거뒀습니다. 첫 번째 TPU는 추론만을 위한 가속기였습니다. 이후 두 번째 TPU를 개발하면서 같은 접근 방식을 AI 학습에도 적용해 보자는 생각을 하게 됐습니다.

그 무렵 트랜스포머(Transformer) 아키텍처가 등장했는데, 이것이 TPU 프로그램의 발전 방향을 완전히 바꿔놓은 중요한 사건이었습니다. 이후에는 추천 시스템도 TPU에서 굉장히 효율적으로 실행할 수 있다는 사실을 발견했고, 활용 범위가 계속 확대됐습니다.

처음에는 언어 번역이나 음성 인식처럼 영향력이 큰 소수의 추론 애플리케이션을 위해 시작했습니다

TPU의 초기 음성인식 용도

. 그런데 점차 AI 학습과 트랜스포머, 추천 시스템까지 영역이 넓어졌습니다. 그리고 생성형 AI 시대가 도래하면서 TPU는 훨씬 더 다양한 워크로드를 처리하고 대규모로 확장할 수 있는 범용적인 AI 컴퓨팅 시스템으로 발전하게 됐습니다.

*코멘트 → Bitter Lesson은 AI 연구자 리치 서튼(Rich Sutton)이 2019년에 발표한 글에서 제시한 개념입니다.

핵심 주장은 다음과 같습니다. 인간이 특정 문제에 대한 지식을 직접 설계에 반영한 방법보다, 더 많은 컴퓨팅 자원을 활용해 스스로 학습하고 탐색하는 범용적인 방법이 장기적으로 더 뛰어난 성과를 거뒀다는 것입니다. 대표적으로 체스와 바둑이 있습니다. 과거 연구자들은 인간 전문가의 전략과 지식을 프로그램에 직접 구현하려 했습니다. 그러나 결국 엄청난 연산량을 활용하는 탐색과 머신러닝이 훨씬 좋은 성과를 거뒀습니다.

리치 서튼은 이러한 패턴이 컴퓨터 비전 등 여러 AI 분야에서도 반복됐다고 설명했습니다. 여기서 중요한 것은 범용 하드웨어 자체가 아니라 컴퓨팅 자원이 증가할수록 더 강력해질 수 있는 알고리즘의 확장성입니다.

그런데 소냐 황은 왜 TPU 이야기에 Bitter Lesson을 가져왔을까?
2013년 반도체 업계에는 비슷한 통념이 있었습니다. 범용 CPU는 무어의 법칙과 거대한 소프트웨어 생태계의 지원을 받으며 계속 발전하고 있었습니다. 따라서 특정 작업에 최적화한 전용 칩을 개발해봤자 범용 프로세서의 발전 속도를 따라잡기 어렵다는 생각이었습니다.

하지만 구글은 AI 연산 수요가 범용 CPU의 성능 개선 속도보다 훨씬 빠르게 증가할 가능성에 주목했습니다

AI 전용 칩을 택한 배경

. 당시 구글은 사용자들이 하루에 단 3분씩 음성 검색을 사용하더라도 이를 처리하려면 데이터센터의 컴퓨터 수를 거의 두 배로 늘려야 한다고 추산했습니다. 그래서 기존 CPU를 더 구매하는 대신 AI 연산에 특화된 TPU를 개발하기 시작했습니다.

TPU가 성공한 이유는 특정 모델이 아닌 공통적인 연산에 특화했기 때문입니다
구글이 직접 설명한 내용과도 일치합니다.

2024년 TPU 개발 회고에서 구글의 수석 아키텍트인 놈 주피(Norm Jouppi)는 "미래의 모델이 어떻게 바뀔지는 알 수 없었지만 텐서 연산을 사용할 것이라는 점은 알고 있었다"고 설명했습니다. 그래서 특정 모델에 지나치게 최적화하기보다 마지막 10~20%의 최적화 성능을 포기하더라도 미래 모델에 대응할 수 있는 유연성을 확보하는 편이 낫다고 판단했습니다.

이것이 TPU 성공의 중요한 이유라고 생각합니다. 처음에는 번역과 음성 인식이 주요 워크로드였지만 이후 Transformer와 추천 시스템, 생성형 AI까지 확대됐습니다. 모델은 계속 바뀌었지만 행렬 연산을 효율적으로 처리한다는 핵심 하드웨어 구조는 오랫동안 유효했습니다. 2026년 구글 연구진의 논문에서도 TPU v2부터 Ironwood까지 기본 아키텍처의 안정성을 유지하면서 Transformer 등 변화하는 워크로드에 대응했다고 평가합니다.

소냐 황 : 방금 트랜스포머의 등장에 대해 말씀하셨는데요. 흥미로운 점은 TPU가 특정 연산에 특화된 칩이면서도 트랜스포머만을 위해 설계된 것은 아니라는 겁니다. 그렇다면 칩을 특정 워크로드에 얼마나 특화할 것인지, 또 어느 정도의 범용성을 유지할 것인지는 어떻게 결정하시나요

특화와 유연성의 균형

? 그 사이에서 적절한 균형을 찾는 것이 쉽지 않을 것 같습니다.

아민 바흐다트 : 핵심은 그 칩을 얼마나 다양한 워크로드에 활용할 수 있느냐입니다. 앞으로 어떤 워크로드에서 얼마나 널리 사용될 수 있을지를 판단하는 것이죠. 저희는 TPU를 설계할 때마다 이 질문을 던집니다. 이번 세대에서는 특정 워크로드에 더 특화하는 것이 좋을까? 아니면 범용성을 유지하는 것이 좋을까?

실제로 약 2년 전에도 중요한 결정을 내려야 했습니다. 2026년을 위한 TPU를 하나만 개발할 것인지, 아니면 두 종류로 나눠서 개발할 것인지를 결정해야 했죠. 학습과 추론을 모두 잘 처리할 수 있는 범용 칩 하나를 만들 수도 있고, 추론에 특화된 칩과 학습에 특화된 칩을 각각 개발할 수도 있었습니다. 여러 분석을 거친 끝에 저희는 올해 추론에 최적화된 TPU 8i와 학습에 최적화된 TPU 8t를 각각 출시하기로 결정했습니다.

이렇게 결정한 이유는 2026년에는 AI 추론과 서빙 수요가 폭발적으로 증가할 것으로 예상했기 때문입니다. 불과 몇 년 전만 해도 상황이 달랐습니다. 예를 들어 어떤 칩의 전체 사용 기간 동안 추론 서빙이 전체 워크로드의 30%, 40%, 50%, 심지어 60%까지 차지할 것으로 예상된다고 해보겠습니다. 그렇다면 추론에 특화된 칩을 별도로 개발해서 훨씬 높은 성능을 얻는 것이 충분히 합리적인 선택입니다.

반대로 추론이 전체 워크로드의 2~5%밖에 차지하지 않는다면 어떨까요? 추론 전용 칩을 개발해서 성능을 두 배로 높일 수 있다고 해도 경제성이 맞지 않을 수 있습니다. 이런 경우에는 일부 효율을 포기하더라도 학습과 추론을 모두 처리할 수 있는 범용 칩 하나를 만드는 편이 낫습니다.

3~4년 수요를 보는 ASIC 설계

결국 저희가 판단해야 하는 것은 해당 워크로드의 규모가 얼마나 큰지, 앞으로 3~4년 동안 얼마나 성장할 것인지, 그리고 그 수요가 얼마나 오래 지속될 것인지입니다. 하드웨어는 특정 작업에 특화할수록 유연성이 줄어듭니다. 대신 그 작업에서 훨씬 높은 성능과 전력 효율을 얻을 수 있는 기회가 생깁니다. 그래서 어떤 워크로드에 맞춰 칩을 설계할지 결정하는 일은 과학이면서 동시에 예술이기도 합니다. 미래의 수요를 정확하게 예측해야 하기 때문입니다.

예를 들어 어떤 워크로드가 지금은 굉장히 큰 비중을 차지하더라도 한두 달이나 석 달 뒤에 사라질 것이라면 전용 하드웨어를 개발할 이유가 없습니다. 칩을 개발해서 실제로 배포하기까지 걸리는 시간을 생각하면 대응할 수도 없겠죠. 따라서 해당 워크로드가 충분히 오랫동안 유지될 것이라는 확신이 필요합니다. 동시에 전용 칩을 개발했을 때 기존 범용 칩보다 정확히 얼마나 큰 성능과 효율상의 이점을 얻을 수 있을지도 예측할 수 있어야 합니다.

소냐 황 : 결국 경제성의 문제이기도 하겠네요. 새로운 칩을 별도로 개발하려면 상당한 고정비가 들어가니까요. 그만큼 충분한 수요가 있어야 추가적인 칩 개발 비용을 정당화할 수 있다는 말씀이군요.

아민 바흐다트 : 정확합니다. 다행히 이번에 개발한 8i와 8t는 각각 특화된 워크로드뿐만 아니라 다른 워크로드도 처리할 수 있습니다. 이것도 저희가 설계할 때 중요하게 고려한 부분입니다. 예를 들어 8i는 추론만 할 수 있고 학습은 전혀 할 수 없다고 가정해 보겠습니다. 반대로 8t는 학습에는 뛰어나지만 추론은 전혀 처리하지 못한다면 어떨까요? 그렇게 되면 하드웨어의 수명이 약 6년이라는 점을 고려했을 때, 앞으로 6년 동안 학습과 추론에 각각 얼마나 많은 컴퓨팅 용량이 필요할지 미리 정확하게 예측해야 합니다

훈련·추론 칩의 여유 용량

. 그런데 그건 굉장히 어려운 일입니다.

그래서 이번에는 각 칩이 자신에게 특화된 워크로드에서 더 높은 성능을 내면서도 필요에 따라 다른 워크로드를 처리할 수 있도록 설계했습니다. 예를 들어 추론용 칩에 여유 용량이 생기면 그 자원을 학습에 활용할 수도 있고, 반대의 경우도 가능합니다. 특정 워크로드에 지나치게 특화하면 이런 유연성을 잃게 됩니다. 상황에 따라 컴퓨팅 자원을 다른 용도로 전환할 수 있다는 것도 굉장히 중요한 설계 요소입니다.

소냐 황 : 특정 워크로드의 규모가 클수록 전용 칩을 개발할 경제성이 높아진다는 말씀이군요. 그렇다면 오늘날 AI 워크로드의 상당 부분이 트랜스포머 기반이라는 점도 생각해 볼 수 있을 것 같습니다. 조금 도발적인 질문을 드려보겠습니다. 아예 트랜스포머 아키텍처 자체를 하드웨어에 구현해서 트랜스포머 전용 칩을 만들면 안 되는 건가요?

아민 바흐다트 : 맞습니다. 오늘날 대부분의 AI 모델이 트랜스포머 기반인 것은 사실입니다. 그런데 트랜스포머가 실제로 어떤 연산을 수행하는지 자세히 들여다보면 대부분 행렬/벡터 곱셈 같은 선형대수 연산과 Softmax 같은 연산으로 이루어져 있습니다. 저희뿐만 아니라 다른 반도체 기업들도 이미 이런 기본적인 연산을 하드웨어 수준에서 지원하고 있습니다.

그렇다면 그다음 단계는 얼마나 더 구체적인 모델 구조에 맞춰 하드웨어를 특화할 것인가의 문제입니다. 같은 트랜스포머 기반 모델이라고 해도 내부 구조는 상당히 다를 수 있습니다. 레이어가 몇 개나 있는지, 각 레이어를 어떤 순서와 방식으로 통과하는지, 레이어 사이에서 데이터가 어떻게 이동하는지에 따라 필요한 연산이 달라집니다

모델과 하드웨어의 공동 설계

. 각 단계에서 수행하는 행렬과 벡터 연산의 크기와 형태도 다를 수 있고요.

따라서 단순히 트랜스포머 연산에 최적화된 칩을 만드는 것에서 한 단계 더 나아가 특정 모델의 구조와 데이터 흐름에 맞춰 하드웨어를 훨씬 더 깊이 특화할 수도 있다는 것입니다. 이미 여러 기업이 이런 방향을 고민하고 있을 것이라고 생각합니다. 저 역시 굉장히 흥미로운 접근 방식이라고 봅니다.

소냐 황 : 현재 고객들은 TPU와 GPU를 사실상 서로 대체할 수 있는 가속기로 보고 있나요? 아니면 각각의 장점이 달라서 더 적합한 워크로드가 따로 있는 건가요?

아민 바흐다트 : 분명히 각각의 가속기에 더 적합한 워크로드가 있습니다. GPU가 TPU보다 범용성이 높다는 것은 사실입니다. 구글 클라우드에서도 다양한 GPU 제품을 제공하고 있고, 구글 내부적으로도 GPU를 사용하고 있습니다. 결국 어떤 가속기를 선택할지는 고객이 해결하려는 문제와 워크로드의 특성에 달려 있습니다.

TPU와 GPU 모두에서 효율적으로 실행할 수 있는 워크로드도 있지만, 특정 가속기에서 더 높은 성능을 내는 워크로드도 있습니다. 그래서 고객들은 자신들이 실행하려는 워크로드를 기준으로 TPU와 GPU의 성능과 효율을 비교한 뒤 적합한 제품을 선택합니다. 저희의 목표는 고객들이 자신의 워크로드에 가장 적합한 솔루션을 선택할 수 있도록 다양한 옵션을 제공하는 것입니다.
'공동 설계' 구글의 경쟁력
여러 계층에 걸친 최적화 누적, 성능 개선을 위해 tape-out을 연기하다

소냐 황 : 이번에는 공동 설계에 대해 좀 더 여쭤보겠습니다. 반도체부터 네트워크와 소프트웨어까지 전체 시스템을 하나로 묶어서 설계하면 어떤 장점이 있나요

공동 설계의 이점과 복잡성

? 반대로 이런 접근 방식의 단점이나 한계는 무엇인가요?

아민 바흐다트 : 공동 설계(Co-design)의 가장 큰 장점은 시스템 전체를 최적화할 수 있는 기회가 엄청나게 많다는 것입니다. 다만 모든 구성 요소를 자유롭게 선택하고 조합하고 싶다면 이야기가 달라집니다. 예를 들어 여러 클라우드를 사용하면서 다양한 하드웨어와 소프트웨어를 조합한다고 생각해 보겠습니다. 어떤 하드웨어나 소프트웨어에서도 작동하고, 어떤 네트워크 토폴로지에서도 실행할 수 있도록 추상화 계층을 만들 수 있습니다.

이렇게 하면 시스템의 이식성과 유연성이 굉장히 높아집니다. 새로운 컴퓨팅 자원이 등장하더라도 거의 즉시 활용할 수 있죠. 특정 기업의 하드웨어나 인프라에 맞춰 시스템을 설계하지 않았기 때문입니다. 그런데 이런 범용성을 확보하려면 상당한 성능을 포기해야 합니다. 하드웨어부터 소프트웨어, 네트워크, 스토리지, 컴퓨팅까지 모든 구성 요소를 자유롭게 교체할 수 있도록 만들면 각 계층 사이에서 상당한 비효율이 발생합니다.

반대로 각 계층을 함께 설계하고 최적화하면 10%, 20%, 경우에 따라서는 두 배에 달하는 성능 차이를 만들어낼 수도 있습니다. 여기서 중요한 것은 이런 최적화 효과가 여러 계층에 걸쳐 누적된다는 점입니다. 한 계층에서 20%의 성능을 개선하고 다른 계층에서도 20%를 개선한다면 그 효과가 서로 곱해지는 것이죠. 이런 개선이 여러 계층에서 반복되면 최종적으로 시스템 전체의 성능이나 와트당 지능, 와트당 Throughput에서 엄청난 격차가 벌어질 수 있습니다. 전력 배분부터 소프트웨어 최적화까지 모든 영역에서 이런 기회를 찾을 수 있습니다.

범용 시스템과 공동 설계의 교환

결국 범용적인 시스템의 가장 큰 장점은 언제 어디서나 실행할 수 있고 특정 공급업체에 종속되지 않는다는 것입니다. 하지만 그 대가로 상당한 성능과 효율을 포기해야 할 수도 있습니다. 공동 설계는 그 반대입니다. 일부 범용성과 유연성을 포기하는 대신 시스템 전체를 함께 최적화해서 훨씬 더 높은 성능과 효율을 얻는 접근 방식입니다.

소냐 황 : 제가 이해하기로 오픈AI는 상대적으로 하나의 컴퓨팅 스택에 집중해 온 반면, 앤스로픽은 여러 종류의 하드웨어를 활용하는 이기종 컴퓨팅 환경을 구축해 왔습니다. 그렇다면 이런 인프라 설계 방식의 차이가 두 회사의 AI 모델 아키텍처가 서로 다른 방향으로 발전하게 된 이유 중 하나일 수도 있을까요?

아민 바흐다트 : 그 부분은 추측하기 어렵습니다. 오픈AI와 앤스로픽이 내부적으로 어떤 판단을 내리고 있는지 제가 단정해서 말씀드리고 싶지는 않습니다. 물론 컴퓨팅 인프라의 차이가 모델 아키텍처에 영향을 미치는 요인 중 하나일 수는 있습니다. 하지만 두 회사가 서로 다른 모델 아키텍처를 선택한 데에는 굉장히 다양한 이유가 있을 겁니다. 각 회사의 내부적인 의사결정 과정을 알지 못하는 상황에서 그 원인을 판단하기는 어렵습니다.

소냐 황 : 그렇다면 구글 내부에서는 어떻게 하고 있나요? 아민의 팀과 구글 딥마인드가 어떤 방식으로 협력하는지 궁금합니다. 실제로 AI 모델을 개발하는 과정에서 각 단계마다 어떤 팀들이 참여하고, 하드웨어와 모델을 함께 최적화하기 위한 공동 설계 관련 의사결정은 어떻게 이루어지나요?

아민 바흐다트 : 제가 구글에서 일하면서 가장 즐겁고 보람을 느끼는 부분 중 하나가 바로 구글 딥마인드와 긴밀하게 협력하면서 하드웨어와 AI 모델을 함께 설계할 수 있다는 점입니다

DeepMind와의 긴밀한 협업

. 여기에 나중에 이야기할 소비자 서비스와 클라우드까지 포함하면 또 다른 협력 관계가 있지만, 우선 딥마인드와의 공동 설계는 정말 긴밀하게 이루어지고 있습니다. 실제로 어떤 식으로 협력하는지 사례를 들어보겠습니다.

딥마인드 연구원들이 트랜스포머에서 사용하는 특정 연산이나 모델 최적화에 관한 새로운 아이디어를 제안했다고 해보겠습니다. 마침 저희가 개발하고 있는 TPU가 아직 설계가 끝나지 않은 단계라면 딥마인드에서 이런 요청을 할 수 있습니다. "하드웨어에서 이 연산을 직접 지원할 수 있다면 모델의 학습이나 추론 서빙 성능을 훨씬 더 높일 수 있을 것 같습니다."

그러면 저희 하드웨어 엔지니어들과 딥마인드 연구원들이 한자리에 모입니다. 며칠 동안 논의할 수도 있고 일주일, 때로는 2주 동안 집중적으로 검토하기도 합니다. 그 과정에서 저희가 "요청하신 기능을 그대로 구현하기는 어렵지만 이런 방식이라면 가능합니다"라고 이야기할 수 있습니다.

그러면 딥마인드 연구원들이 다시 제안합니다. "그렇다면 모델 구조를 조금 변경해서 원래 기대했던 성능 향상의 90% 정도를 얻을 수 있지 않을까요?" 이렇게 서로 아이디어를 주고받으면서 하드웨어와 모델을 함께 조정하는 겁니다. 만약 그 과정에서 얻을 수 있는 이점이 충분히 크다면 칩의 테이프아웃(Tape-out)을 일주일이나 2주 정도 늦추기로 결정할 수도 있습니다.

사실 저희는 항상 여러 세대의 TPU를 동시에 개발하고 있습니다. 이미 데이터센터에 대규모로 배포되어 운영 중인 칩이 있습니다. 제조를 마치고 테스트와 디버깅을 진행하는 칩도 있고, 설계를 거의 마무리해서 tape-out을 앞둔 칩도 있습니다

동시에 진행되는 여러 세대 개발

. 한창 설계를 진행하고 있는 차세대 칩도 있고, 아직 어떤 아키텍처를 사용할지 구상하는 초기 단계의 칩도 있습니다. 이렇게 실제 운영 중인 제품부터 미래 세대의 초기 설계까지 대략 5~6개의 개발 단계가 수년에 걸쳐 동시에 진행되고 있습니다.

그리고 저희는 이 모든 단계에서 딥마인드와 협력합니다. 우선 이미 운영 중인 칩에서도 공동 최적화가 이루어집니다. 저희는 하드웨어 내부에서 실제로 어떤 일이 일어나는지 알고 있고, 딥마인드 연구원들은 모델 내부에서 어떤 연산이 수행되는지 정확하게 이해하고 있습니다. 그 사이에 있는 소프트웨어가 어떻게 동작하는지도 함께 분석할 수 있습니다.

따라서 전체 시스템을 살펴보면서 와트당 지능이나 Goodput을 극대화할 수 있는 최적화 기회를 찾아낼 수 있습니다. tape-out을 앞둔 칩에서도 이런 협력이 이루어집니다. 아직은 하드웨어 아키텍처를 일부 변경할 수 있는 시점이기 때문입니다.

그런데 이런 협력은 서로 다른 회사에서 일한다면 훨씬 어려울 겁니다. 칩 개발이 거의 끝나서 몇 주 또는 몇 달 뒤면 테이프아웃을 해야 하는 상황에서 모델 개발팀과 하드웨어 개발팀이 갑자기 모여 "지금 설계를 변경하는 것이 좋을까요?"라고 논의하고 실제로 결정을 내리는 것은 쉬운 일이 아니니까요.

반면 개발 초기 단계에서는 훨씬 더 다양한 가능성을 검토할 수 있습니다. 저희는 딥마인드 연구원들에게 이런 질문을 합니다. "앞으로 2~3년 뒤에는 AI 모델 아키텍처가 어떤 방향으로 발전할 것 같습니까?" 그런 다음 하드웨어 아키텍처 측면에서 가능한 선택지와 모델 아키텍처 측면에서 가능한 선택지를 함께 검토합니다

시뮬레이션으로 찾는 균형점

. 서로 어떤 조합이 가장 높은 성능과 효율을 낼 수 있을지 최적의 균형점을 찾는 것이죠.

이를 위해 저희는 다양한 하드웨어에서 특정 워크로드가 어떻게 실행될지를 미리 예측할 수 있는 고도화된 시뮬레이션 인프라도 갖추고 있습니다. 이 모든 과정은 굉장히 빠르고 반복적으로 이루어집니다. 하드웨어 팀과 모델 개발팀이 각자 따로 작업하다가 가끔 만나서 의견을 교환하는 방식이 아닙니다.

실제로 같은 건물이나 같은 공간에서 함께 일하는 경우도 많고, 일상적으로 굉장히 깊이 있는 논의를 나눕니다. 저 역시 코레이나 데미스와 일주일에도 몇 번씩 이야기를 나눕니다. 이런 방식으로 함께 일할 수 있다는 것이 제가 구글에서 가장 즐겁게 생각하는 부분 중 하나입니다.

소냐 황 : 정말 멋집니다. 결국 딥마인드의 모델이 칩을 설계하는 데도 활용되겠군요.

아민 바흐다트 : 저희는 차세대 Gemini를 구동할 하드웨어를 설계하는 과정에서도 Gemini 자체를 활용하고 있습니다.

소냐 황 : 정말 놀랍네요. 그 이야기는 잠시 후에 다시 해보겠습니다. 그런데 이렇게 긴밀하게 협력하는 과정에서도 어려움이 있을 것 같습니다. 하드웨어는 개발에 몇 년씩 걸리지만, 딥마인드가 개발하는 AI 모델과 소프트웨어는 훨씬 빠르게 발전하잖아요. 하드웨어는 몇 년 뒤를 내다보고 설계해야 하는데, 그사이에 모델 아키텍처가 계속 바뀔 수도 있습니다. 이렇게 개발 속도가 서로 다르다는 점에서 어려움은 없나요?

아민 바흐다트 : 물론입니다.

소냐 황 : 실제로는 어느 정도까지 함께 조정할 수 있나요?

아민 바흐다트 : 저희는 하드웨어를 개발할 때 2년, 3년, 4년, 심지어 5년 뒤까지 내다보고 계획합니다

차세대 TPU와 tape-out 지연

. 최근 발표한 TPU v8i와 v8t뿐만 아니라 그다음 세대인 9세대와 10세대 TPU, 그리고 다른 여러 제품도 이미 개발하고 있습니다. 물론 제품마다 개발 단계는 다릅니다. 아직 초기 아이디어를 검토하는 제품도 있고 실제 구현을 진행하고 있는 제품도 있습니다. 최종적으로 출시되기까지 몇 년이 걸릴 수도 있죠.

반면 AI 모델을 개발할 때는 일반적으로 몇 년 뒤에 출시할 모델만을 목표로 연구하지는 않습니다. 개발 주기 자체가 훨씬 짧으니까요. 그런데도 저희가 긴밀하게 협력할 수 있는 것은 구글이 지금까지 발전해 온 과정과 조직 문화 덕분이라고 생각합니다. 구글 리서치와 딥마인드는 오랫동안 긴밀하게 협력해 왔고, 트랜스포머 아키텍처도 이런 연구 환경에서 탄생했습니다.

덕분에 연구원들 사이에는 자신들의 모델 연구가 하드웨어 로드맵에도 영향을 미칠 수 있다는 인식이 자연스럽게 자리 잡았습니다. 동시에 하드웨어 개발에는 몇 년이라는 긴 시간이 필요하다는 사실도 잘 이해하고 있습니다.
예를 들어 테이프아웃을 앞둔 칩에서 성능을 0.5~1% 정도 개선할 수 있는 아이디어가 나왔다고 해보겠습니다. 그 정도의 개선을 위해 굳이 하드웨어 설계를 변경하자고 요청하지는 않을 겁니다.

소프트웨어는 코드를 변경하고 2주 만에 새로운 버전을 배포할 수도 있습니다. 하지만 하드웨어는 다릅니다. 테이프아웃을 중단하고 설계를 변경한다는 것은 훨씬 더 큰 결정이기 때문입니다. 딥마인드 연구원들도 이런 차이를 잘 이해하고 있습니다. 반대로 성능 개선 효과가 정말 크다면 어떻게든 함께 방법을 찾아서 하드웨어 설계에 반영할 수 있다는 것도 알고 있습니다.

곱셈으로 누적되는 최적화

그리고 이런 협업의 효과는 앞서 말씀드린 것처럼 곱셈으로 누적됩니다. 하드웨어에서 한 번 성능을 개선하면 그 하드웨어에서 실행되는 모든 워크로드가 혜택을 받을 수 있습니다. 딥마인드 연구원들도 이런 장기적인 파급효과를 잘 알고 있기 때문에 하드웨어 로드맵에 영향을 줄 수 있는 아이디어를 계속 고민합니다.

개인적으로 정말 보람을 느끼는 순간도 바로 이런 때입니다. 2년 전에 딥마인드 연구원들과 함께 고민했던 아이디어가 이제 실제 데이터센터에 적용되어 구글의 모든 워크로드를 더 빠르고 효율적으로 처리하도록 돕는 모습을 보는 것이죠.

소냐 황 : 맞습니다. 그런데 5년 뒤에 어떤 AI 워크로드가 주류가 될지, 그사이에 어떤 새로운 알고리즘이 등장할지 예측하는 건 사실상 불가능에 가까워 보이는데요. 그렇게 먼 미래를 내다보고 하드웨어를 설계하는 것이 굉장히 어려운 일이지 않나요?

아민 바흐다트 : 그렇게 생각하실 수 있습니다. 그런데 흥미로운 사실이 하나 있습니다. 저희가 지금까지의 TPU 개발 역사를 자세히 정리하고 있는데, 놀랍게도 아키텍처를 조금 더 추상적인 수준에서 살펴보면 TPU는 v1 이후 핵심 구조가 크게 달라지지 않았습니다.

CPU의 명령어 집합을 생각해 보세요. 메모리에서 데이터를 읽고 쓰는 Load/Store 명령어가 있고, 덧셈과 뺄셈 같은 산술 연산이나 조건에 따라 실행 흐름을 바꾸는 분기 명령어도 있습니다. 이런 기본적인 명령어를 바탕으로 지난 수십 년 동안 수없이 다양한 소프트웨어가 개발되고 실행되어 왔습니다.

TPU도 비슷합니다. 물론 세대가 바뀔 때마다 새로운 명령어와 기능을 계속 추가해 왔습니다

칩 안팎의 핵심 기능

. 하지만 기본적으로는 대규모 행렬 곱셈에 특화된 연산, 벡터 연산, 스파스 코어(SparseCore)를 활용한 Scatter-Gather 연산, 원격 메모리에 접근하는 Load/Store 등 5~6가지 핵심 기능을 중심으로 발전해 왔습니다. 예를 들어 ICI 네트워크를 활용하면 다른 칩의 메모리에 접근해서 데이터를 읽거나 쓸 수 있습니다.

이런 기본적인 기능들은 오래전부터 존재했습니다. 저희는 이 핵심 구조를 유지하면서 필요한 기능을 계속 확장했고, 그 결과 여러 세대의 AI 모델과 다양한 딥러닝 아키텍처를 지원할 수 있었던 것입니다.

*코멘트 → 모델 아키텍처와 하드웨어의 기본 연산 기능(Primitive)을 구분해볼 수 있습니다. 그동안 AI 모델은 CNN, Transformer, MoE로 발전했지만 행렬곱(MXU), 벡터 연산(VPU), 메모리 접근과 데이터 이동 같은 기본적인 연산은 계속 필요했습니다. 이러한 핵심 연산을 효율적으로 처리하는 하드웨어를 유지하면서 XLA 같은 컴파일러를 통해 새로운 모델의 연산을 기존 하드웨어에 매핑해 왔습니다. 필요할 때는 SparseCore처럼 새로운 기능도 추가했습니다.
데이터센터 확장의 병목 '전력'
에이전트로 인해 CPU, 스토리지, 네트워크 수요가 증가한다

소냐 황 : 이번에는 AI 워크로드가 어떻게 변화하고 있는지 이야기해 보겠습니다. 지난 1년 동안, 특히 올해 초부터 나타난 가장 큰 변화 중 하나가 장시간에 걸쳐 복잡한 작업을 수행하는 장기 호라이즌(Long-Horizon) 에이전트의 등장인 것 같습니다. 이런 에이전트는 사용자와 짧게 질문과 답변을 주고받는 기존 LLM 챗봇과는 워크로드 특성이 상당히 다를 텐데요

에이전트가 바꾸는 데이터센터

. 이러한 변화가 데이터센터의 설계와 운영에는 어떤 영향을 미치고 있나요?

아민 바흐다트 : 크게 두 가지 변화가 있습니다.

첫 번째는 더 이상 사람이 AI와 상호작용하는 속도가 시스템 전체의 속도를 제한하지 않는다는 점입니다. 과거에는 사람이 브라우저나 스마트폰에 프롬프트를 입력하고, 모델이 생성한 답변을 받은 다음 그 내용을 읽고 생각해서 다시 질문하는 방식이었습니다. 중간에 사람이 개입하기 때문에 한 번의 상호작용이 끝나고 다음 요청이 들어오기까지 몇 초, 길게는 몇십 초의 간격이 자연스럽게 발생했습니다.

그런데 장기 호라이즌 에이전트는 다릅니다. 이제 사람이 중간에서 속도를 제한하지 않습니다. 에이전트는 모델의 응답을 받자마자 그 내용을 파싱하고 분석해서 다음에 어떤 작업을 수행할지 판단한 뒤 곧바로 새로운 요청을 보낼 수 있습니다. 기존에는 몇 초씩 걸리던 상호작용 간격이 밀리초 단위로 줄어들 수 있다는 것이죠.

두 번째 변화는 이런 에이전트의 작업을 처리하는 데 CPU가 굉장히 중요한 역할을 하게 된다는 점입니다. 모델의 응답을 파싱하고 다음 작업을 결정하고, 여러 작업을 조율하는 오케스트레이션 과정의 상당 부분이 CPU에서 이루어지기 때문입니다.

예를 들어 에이전트가 다음 프롬프트를 모델에 보내기 전에 어떤 정보를 추가로 수집해야 할지 판단해야 한다고 해보겠습니다. 이전 응답에서 얻은 정보를 바탕으로 다음 작업을 진행하려면 필요한 컨텍스트를 가져와야 합니다. 그 컨텍스트는 로컬 DRAM에 있을 수도 있고, 다른 CPU에 연결된 DRAM에 있을 수도 있습니다. SSD나 HDD에 저장되어 있을 수도 있죠

CPU·스토리지·네트워크 수요

. 결국 에이전트가 계속 작업을 수행하려면 CPU가 이런 다양한 자원에 접근해서 필요한 데이터를 가져오고, 다음 작업을 조율해야 합니다.

이제 데이터센터에서는 과거와 비교할 수 없을 정도로 많은 오케스트레이션 작업이 필요해지고 있습니다. 그 결과 TPU나 GPU 같은 가속기의 연산 수요가 증가하는 것은 물론이고, CPU와 네트워크, 스토리지처럼 기존 데이터센터를 구성하던 인프라에 대한 수요도 폭발적으로 증가하고 있습니다.

소냐 황 : 그렇다면 GPU 랙 바로 옆에 더 많은 CPU를 배치해야 한다는 뜻인가요?

아민 바흐다트 : GPU든 TPU든 마찬가지입니다. 그런데 이 문제는 앞서 이야기했던 데이터센터를 특정 용도에 얼마나 특화해서 설계할 것인가라는 질문으로 다시 이어집니다. 예를 들어 가속기 랙 바로 옆에 CPU 랙을 많이 배치한다고 해보겠습니다. 그렇게 되면 데이터센터 건물 전체를 TPU나 GPU에 맞춰 최적화하기가 어려워집니다. TPU나 GPU 랙은 일반적인 CPU 랙보다 전력 밀도가 훨씬 높고, 네트워크 대역폭에 대한 요구사항도 훨씬 클 수 있기 때문입니다. 서로 특성이 다른 장비들을 한 건물에 배치하면 전력과 네트워크 인프라를 어느 한쪽에 맞춰 설계하기 어려워지는 것이죠.

그렇다면 건물별로 용도를 구분하는 방법도 있습니다. 예를 들어 한 건물에는 TPU와 GPU를 집중적으로 배치하고, 바로 옆 건물에는 CPU를 배치하는 겁니다. HDD는 또 다른 건물에 모아둘 수도 있겠죠.

그런데 이렇게 하면 또 다른 문제가 생깁니다. 건물과 건물 사이에 훨씬 더 많은 네트워크 연결이 필요해진다는 것입니다

건물 밖 통신과 지연의 비용

. 네트워크 연결이 건물 외부로 나가는 순간 비용이 증가하고 신뢰성을 확보하기도 어려워집니다. 지연시간도 늘어납니다. 네트워크에서 발생하는 대기열 같은 요소까지 고려하면 서로 다른 구성 요소 사이의 통신 지연시간이 수백 마이크로초, 경우에 따라서는 그 이상 증가할 수도 있습니다.

물론 워크로드에 따라서는 그 정도 지연시간을 충분히 감수할 수도 있습니다. 하지만 중요한 것은 AI 워크로드가 변화하면서 데이터센터를 어떻게 설계하고 각 구성 요소를 어디에 배치할 것인지에 대한 선택과 고려사항이 크게 달라지고 있다는 점입니다.

소냐 황 : 이야기를 듣기만 해도 어려운 일이네요.

아민 바흐다트 : 하지만 재미있습니다.

소냐 황 : 그렇다면 네트워킹 분야에서는 어떤 변화가 일어나고 있나요? 구글은 오랫동안 광통신을 비롯한 첨단 네트워킹 기술을 선도해 온 것으로 알고 있는데요. 현재 광 네트워킹 기술은 어느 수준까지 발전해 있나요?

아민 바흐다트 : 구글은 약 15~16년 전에 데이터센터에 파장 분할 다중화(WDM) 기술을 도입한 최초의 기업 중 하나입니다. 하나의 광섬유에 서로 다른 파장의 빛을 동시에 실어서 여러 신호를 전송하는 기술이죠. 저희는 지금도 데이터센터에서 랙과 랙 사이를 연결할 때 이 기술을 사용하고 있습니다.

비슷한 시기에 OCS(Optical Circuit Switching) 기술도 도입했습니다. 기존의 전기적 패킷 스위칭과 달리 빛을 전기 신호로 변환하지 않고 광학적인 방식으로 통신 경로를 변경하는 기술입니다.

일반적인 네트워크 패킷 스위치를 생각해 보겠습니다. 패킷이 스위치에 들어오면 먼저 패킷 헤더를 확인합니다

패킷 스위칭과 전력 문제

. 여기에는 IP 주소처럼 데이터가 어디로 가야 하는지 알려주는 정보가 들어 있습니다. 스위치는 이 정보를 테이블에서 조회한 다음 어느 출력 포트로 데이터를 보내야 할지 결정합니다. 이런 작업을 초당 수십억, 수백억 번, 경우에 따라서는 수조 번씩 수행하는 것이죠.

그런데 OCS는 접근 방식이 완전히 다릅니다. 데이터에 들어 있는 비트 하나하나를 전기적으로 해석할 필요가 없습니다. 단지 특정 입력 포트로 들어온 빛을 어느 출력 포트로 보낼지만 결정하면 됩니다.

이를 구현하는 방법은 여러 가지가 있는데, 저희가 처음 사용했던 것은 MEMS 기반 광 스위치였습니다. MEMS는 아주 작은 전기기계식 거울을 사용하는 기술입니다. 이 거울을 3차원 공간에서 움직여 빛이 진행하는 방향을 바꾸는 것이죠. 예를 들어 입력과 출력에 각각 128개 또는 256개의 포트가 있는 광 스위치를 생각해 보겠습니다. 소프트웨어를 통해 어떤 입력 광섬유를 어떤 출력 광섬유에 연결할지 지정할 수 있습니다.

그러면 스위치 내부의 작은 거울들이 각도를 조절해서 입력 포트로 들어온 빛을 원하는 출력 포트로 반사시킵니다. 실제 광섬유 케이블을 옮기지 않고도 연결 경로를 바꿀 수 있는 겁니다.

저희가 이 기술을 도입했던 이유는 크게 두 가지입니다.

첫 번째는 서로 통신을 많이 하는 랙들을 더 효율적으로 연결하기 위해서입니다. 예를 들어 구글 검색 서비스를 처리하는 컴퓨팅 클러스터와 여기에 필요한 데이터를 제공하는 스토리지 클러스터가 있다고 해보겠습니다. 두 클러스터 사이에는 굉장히 많은 데이터가 오갈 겁니다. 이때 OCS의 거울을 적절하게 조정하면 두 클러스터 사이에 직접 연결되는 광학적인 지름길을 만들어줄 수 있습니다

OCS의 재구성과 확장성

. 데이터를 훨씬 더 효율적으로 전달할 수 있는 것이죠.

두 번째는 사람이 광섬유 케이블을 직접 옮기지 않고도 네트워크를 확장하거나 축소할 수 있다는 점입니다. 이 부분을 자세히 설명하려면 화이트보드가 필요할 것 같습니다. 하지만 간단히 말씀드리면 OCS를 이용하면 네트워크 컨트롤러가 스파인(Spine) 네트워크의 연결 구조를 소프트웨어로 재구성할 수 있습니다. 기존에는 네트워크 구성을 변경하기 위해 사람이 직접 케이블을 뽑아서 다른 포트에 연결해야 했다면, 이제는 그런 작업을 소프트웨어로 수행할 수 있다는 뜻입니다.

그런데 이 기술은 TPU에서도 굉장히 중요합니다. TPU들은 서로 Torus 형태의 네트워크 토폴로지로 연결되어 있습니다. 앞서 제가 Throughput과 Goodput의 차이를 설명했었죠. OCS는 바로 이 Goodput을 높이는 데도 굉장히 유용합니다. 예를 들어 TPU 랙 하나에서 장애가 발생했다고 해보겠습니다. 기존 방식이라면 고장 난 랙을 복구하거나 네트워크 연결을 물리적으로 변경해야 할 수도 있습니다.

그런데 OCS를 사용하면 훨씬 간단해집니다. 미리 예비 TPU 랙을 준비해 두고, 장애가 발생하면 원래 고장난 랙으로 향하던 빛을 예비 랙으로 보내도록 광 스위치의 연결을 변경하는 겁니다. 이 과정에서 광섬유 케이블을 직접 옮길 필요가 없습니다. 소프트웨어가 광 스위치의 연결을 재구성하면 되고, 이런 작업을 밀리초 단위로 수행할 수 있습니다. 결국 장애가 발생하더라도 시스템을 훨씬 빠르게 복구할 수 있고, 그만큼 실제 워크로드에서 얻을 수 있는 Goodput을 높일 수 있는 것이죠.

OCS 추가 설명과 광학 구조

*코멘트 → 위에 OCS에 대해서 말씀드렸던 것에서 좀 더 이어져서 정리하자면

최근의 논문은 2026년 6월에 발표했던 <Google's Training Supercomputers from TPU v2 to Ironwood>이 있습니다. OCS가 단순한 장애 우회를 넘어 자원 스케줄링, 불량 칩 격리, 슈퍼컴퓨터의 가동 효율까지 어떻게 개선하는지 설명한 논문입니다.

TPU v7 9,216개 SuperPod 구성 = 8,192 + 1,024
TPU v7과 v8의 발전을 살펴보면 구글이 OCS를 어떤 방향으로 확장하고 있는지 이해할 수 있습니다. 2026년 IEEE Micro에 발표된 Ironwood 논문에서 가장 흥미로운 부분은 OCS가 단순한 네트워크 연결 장치를 넘어 슈퍼컴퓨터의 자원 할당과 신뢰성을 관리하는 핵심 기술로 활용된다는 점입니다.

Ironwood는 9,216개의 TPU를 144개 Cube로 구성합니다. 여기서 OCS를 통해 물리적으로 떨어진 정상 Cube들을 하나의 학습 Slice로 구성할 수 있기 때문에 일부 장비에 장애가 발생하더라도 대규모 학습 작업을 위한 자원 확보가 가능합니다. 이는 Scheduling Goodput을 높이는 중요한 방법입니다. 그리고 TPU v7에서 도입된 Hardware Replay 기능은 정상적으로 작동하는 것처럼 보이면서 잘못된 연산 결과를 만드는 불량 칩까지 찾아내 OCS를 통해 격리한다는 점입니다.

소냐 황 : 그렇다면 꼭 광섬유를 사용해야 하나요? 광섬유를 통하지 않고 자유공간에서 빛을 직접 전달하는 방식은 안 되는 건가요?

자유공간 광통신의 조건

아민 바흐다트 : 광섬유 없이 자유공간에서 빛을 직접 전송하는 방식을 말씀하시는 거군요. 그런 방식도 가능하지만 몇 가지 어려움이 있습니다. 우선 빛이 전파되는 과정에서 감쇠가 발생하기 때문에 사용할 수 있는 대역폭이 크게 줄어들 수 있습니다. 무엇보다 데이터센터처럼 거대한 건물 안에서 수많은 장비를 3차원으로 연결하려면 빛을 원하는 지점에 정확하게 조준해야 하는데, 이게 굉장히 어렵습니다.

광섬유를 사용하면 이런 문제를 해결할 수 있습니다. 저희도 자유공간 광통신을 검토해 봤고, 내부적으로 흥미로운 논의도 많이 했습니다. 하지만 실제 데이터센터에서 대부분의 연결은 여전히 광섬유를 통해 이루어집니다.

다만 OCS 내부에서는 조금 다릅니다. 광섬유를 통해 전달된 빛이 스위치 안으로 들어오면 광섬유 밖으로 나와 작은 칩 위를 직접 통과하는 구조를 사용할 수 있습니다. 이 외에도 정말 많은 변화가 일어나고 있습니다. 특히 AI 데이터센터에서 네트워크에 요구되는 성능이 폭발적으로 높아지고 있고, 네트워킹 자체의 중요성도 그 어느 때보다 커지고 있다고 생각합니다.

소냐 황 : 앞서 이야기했던 Ineffable Intelligence의 클러스터 사진을 다시 떠올려 보면, 정말 엄청난 양의 케이블이 연결되어 있다는 점이 눈에 띄었습니다.

아민 바흐다트 : 맞습니다. 그 케이블 중 일부는 결국 저희 데이터센터에 설치된 OCS로 연결됩니다.

소냐 황 : 알겠습니다. 이번에는 전력에 관해 이야기해 보겠습니다. 앞서 '와트당 Goodput'이나 '와트당 지능'이라는 표현을 여러 번 사용하셨는데요. 전력을 기준으로 성능을 측정한다는 것은 결국 전력이 데이터센터에서 가장 중요한 제약조건이거나, 확보하기 어렵고 비용도 많이 드는 자원이라는 뜻으로 들립니다.

AI 인프라의 제약조건: 전력

아민 바흐다트 : 저희가 가장 자주 받는 질문 중 하나가 현재 AI 인프라를 확장하는 데 가장 큰 제약조건이 무엇이냐는 것입니다. 그런데 사실 하나만 꼽기는 어렵습니다. 거의 모든 요소가 제약조건이 될 수 있고, 어느 것 하나 해결하기 쉬운 문제가 아닙니다. 게다가 병목이 발생하는 지점도 계속 바뀌고 있습니다.

그럼에도 가장 근본적인 제약조건을 하나만 꼽으라면 저는 전력이라고 답하겠습니다. 다른 문제들은 대체로 어떻게 해결해야 할지 알고 있습니다. 지금 당장은 어렵더라도 시간이 지나면 해결할 수 있을 것으로 보입니다. 하지만 전력은 다릅니다. 장기적으로도 AI 인프라 확장을 계속 제한하는 요인이 될 가능성이 높습니다.

물론 원자력 같은 해결책이 있습니다. 원자력이 충분히 풍부한 청정에너지를 공급할 수 있게 된다면 지금의 전력 문제를 상당 부분 해결할 수도 있을 겁니다. 다만 그런 기술과 전력 공급 능력을 언제쯤 대규모로 확보할 수 있을지는 여전히 불확실합니다.

소냐 황 : 그렇다면 실제로 데이터센터에 필요한 전력은 어떻게 확보하시나요? 예를 들어 새로운 데이터센터를 구축하는 데 1GW의 전력이 필요하다고 해보겠습니다. 그렇다고 전력회사인 PG&E에 전화해서 "1GW만 공급해 주세요"라고 요청한다고 해결되는 문제는 아닐 것 같은데요. 그렇다면 발전용 터빈까지 직접 설치해서 전력 생산 자체를 수직계열화해야 하는 건가요? 구글은 이런 대규모 전력 확보 문제를 실제로 어떻게 해결하고 있나요?

아민 바흐다트 : 정말 중요하면서도 큰 질문입니다. 구글이 가장 선호하는 방식은 전력회사와 협력해서 데이터센터를 기존 전력망에 연결하는 것입니다

전력회사와의 협력

. 기본적으로는 전력회사에 필요한 전력을 공급해 달라고 요청하는 방식이죠.

소냐 황 : 그렇다고 PG&E에 전화 한 통 하면 바로 해결되는 건 아니겠죠?

아민 바흐다트 : 당연히 그렇습니다. 데이터센터가 위치한 지역의 전력회사와 아주 정중하게, 그리고 수년 전부터 협의를 시작해야 합니다. 1GW의 전력이 필요하다고 해서 전력회사에 전화해서 "내일부터 1GW를 사용할 테니 요금은 언제부터 내면 되나요?"라고 말할 수는 없으니까요. 전력회사와 오랜 기간에 걸쳐 함께 계획해야 하는 일입니다.

여기서 저희가 중요하게 생각하는 것 중 하나는 전력망을 확충하는 데 필요한 비용을 구글이 부담해야 한다는 점입니다. 구글의 데이터센터에 전력을 공급하기 위해 전력망 용량을 늘리는 것인데, 그 비용이 지역 주민이나 다른 고객들의 전기요금 인상으로 이어져서는 안 된다고 생각합니다. 그래서 새로운 송전선을 건설하거나 기존 송전선을 업그레이드하고, 추가 변전소를 건설하는 데 필요한 비용을 저희가 부담하는 방안을 전력회사와 협의합니다.

예를 들어 2028년에 1GW의 전력이 필요하다고 해보겠습니다. 그런데 전력회사에서 "2029년에는 1GW를 공급할 수 있지만 2028년에는 700MW까지만 가능합니다"라고 답할 수도 있습니다. 그러면 저희는 부족한 300MW를 어떻게 확보할지 고민해야 합니다. 가장 간단한 방법은 필요한 전력이 공급될 때까지 기다리는 것입니다.

하지만 다른 방법도 있습니다. 부족한 전력의 일부를 저희가 직접 생산하는 것이죠. 예를 들어 태양광 발전이나 배터리, 다른 발전원을 조합해서 필요한 전력을 확보할 수 있습니다

직접 발전과 전력망의 결합

. 그런데 이 경우에도 전력회사와 긴밀하게 협력해야 합니다. 기존 전력망에서 공급받는 전력과 저희가 직접 생산하는 전력을 어떻게 결합할지 결정해야 하기 때문입니다.

여기서 한 단계 더 나아갈 수도 있습니다. 나중에 전력회사가 1GW 전체를 공급할 수 있게 되면 저희가 직접 생산한 전력의 일부를 다시 지역 전력망에 공급하는 겁니다. 예를 들어 한여름에 가장 더운 2주 동안 지역 주택들의 전력 수요가 급격하게 증가한다고 해보겠습니다. 그럴 때 저희가 생산한 전력의 일부를 지역 전력망으로 보내서 전력 수요를 충당하는 데 도움을 줄 수도 있습니다.

이런 방식으로 데이터센터에 필요한 전력을 확보하면서 지역 전력망에도 기여할 수 있습니다. 그래서 전력회사와 수년에 걸쳐 긴밀하게 협력하는 과정이 반드시 필요한 것입니다.

소냐 황 : 그렇다면 구글이 직접 발전 설비를 구축해서 전력 생산까지 수직계열화하기보다는 기존 전력회사와 협력하는 방식을 선호하는 이유는 무엇인가요?

아민 바흐다트 : 가장 큰 이유는 양쪽 모두에게 더 많은 유연성과 경제적인 이점이 있기 때문입니다. 이건 통계적 다중화(Statistical Multiplexing) 또는 대수의 법칙이라는 관점에서 이해할 수 있습니다.

예를 들어 저희가 1GW의 전력이 필요하고, 그 전력을 99.99% 또는 그 이상의 신뢰성으로 공급받아야 한다고 가정해 보겠습니다. 만약 필요한 전력을 전부 직접 생산한다면 1GW가 아니라 2GW 규모의 발전 설비를 구축해야 할 수도 있습니다. 99.99%나 99.999% 수준의 신뢰성을 확보하려면 한쪽에 문제가 생겼을 때 다른 쪽이 전력을 공급할 수 있도록 1+1 이중화 구성을 갖춰야 하기 때문입니다.

청정에너지 조달의 비용·유연성

당연히 비용이 엄청나게 많이 들겠죠. 게다가 데이터센터 바로 옆에서 그만한 규모의 청정에너지를 확보하는 것도 쉽지 않습니다. 반면 기존 전력망에 연결되어 있다면 훨씬 유연하게 운영할 수 있습니다. 저희가 전력을 적게 사용하는 시간에는 여유 전력을 전력망에 공급하고, 반대로 더 많은 전력이 필요할 때는 전력망에서 가져올 수 있습니다.

이렇게 하면 구글이 자체적으로 필요한 모든 예비 발전 용량을 확보할 필요가 없습니다. 전력망 전체에서 여러 수요처와 발전원의 전력 수급을 통합해서 운영하기 때문에 서로의 여유 용량을 훨씬 효율적으로 활용할 수 있는 것이죠. 결과적으로 구글에도 이익이고 전력회사에도 이익입니다. 지역의 일반 가정에도 도움이 될 수 있습니다.

물론 예외적인 경우도 있습니다. 전력망에서 공급받는 대신 데이터센터 부지 내에 발전 설비를 설치하는 Behind-the-Meter 방식을 선택할 수도 있습니다. 하지만 그런 경우에도 보통은 1년 정도 뒤에 기존 전력망과 연결한다는 계획을 가지고 추진합니다. 저희가 궁극적으로 원하는 것은 전력망에 연결되는 것입니다. 전력망과 연결되어 있을 때 구글에도 더 유리하고, 전력망 전체에도 더 많은 이점을 제공할 수 있기 때문입니다.

소냐 황 : 일리가 있네요. 그렇다면 데이터센터의 규모는 어떻게 결정하나요?

아민 바흐다트 : 이건 정말 많은 논의가 필요한 문제이고, 어떻게 보면 일종의 예술에 가깝습니다.

사실 10~15년 전에도 구글 내부에서 이 문제를 두고 굉장히 많은 논쟁이 있었습니다. 모든 컴퓨팅 자원을 하나의 거대한 데이터센터에 집중시키는 것이 좋을까

대형 데이터센터의 단일장애 위험

? 당시에도 1GW급 데이터센터를 구축하는 방안을 상상하곤 했습니다. 물론 지금과는 상황이 많이 달랐습니다. 당시 가장 큰 우려는 단일 장애 지점(Single Point of Failure)이었습니다.

앞으로 30년 동안 운영해야 하는 시설 하나에 모든 인프라를 집중한다는 것은 상당한 위험을 감수해야 한다는 뜻이니까요. 그 시설에 문제가 생기면 전체 시스템이 영향을 받을 수 있습니다.

반면 오늘날의 AI 학습 워크로드만 놓고 보면 클러스터는 클수록 좋습니다. 가능한 한 많은 가속기를 한곳에 모아서 서로 긴밀하게 연결하는 것이 유리하기 때문입니다. 장비 간 네트워크 지연시간을 최소화하려면 물리적으로도 최대한 가까이 배치하는 것이 좋습니다.

하지만 단일 장애 지점이라는 위험은 여전히 존재합니다. 여기에 이제는 전력 확보라는 문제까지 더해졌습니다. 10~15년 전에는 1GW급 데이터센터가 엄청난 규모이긴 했지만 충분히 상상할 수 있는 수준이었습니다. 그런데 지금 구글이 필요로 하는 모든 컴퓨팅 용량을 하나의 데이터센터에 수용한다는 것은 전 세계 어느 지역에서도 현실적으로 불가능합니다.

그래서 저희는 데이터센터의 적정 규모를 결정하기 위해 다양한 모델과 시뮬레이터를 활용합니다. 다만 모든 데이터센터에 적용할 수 있는 하나의 정답이 있는 것은 아닙니다. 어떤 용도로 사용하는지에 따라 적절한 규모가 달라지기 때문입니다. 예를 들어 네트워크 엣지에 배치하는 데이터센터라면 수십 MW 규모로 충분할 수 있습니다.

반면 초대규모 AI 학습 클러스터를 구축한다면 1GW에 가까운 전력이 필요할 수도 있습니다

워크로드별 적정 규모

. 또 다른 데이터센터는 수백 MW 수준으로 설계하는 것이 적절할 수도 있고요. 결국 데이터센터의 규모는 어떤 워크로드를 처리할 것인지, 그리고 그 워크로드에 어떤 인프라 구성이 가장 적합한지에 따라 결정해야 합니다.

소냐 황 : 흥미롭네요. 그렇다면 구글은 여러 데이터센터와 클러스터의 수명주기를 어떻게 관리하나요? 제 생각에는 가장 크고 최신 하드웨어로 구성된 클러스터를 프론티어 모델 학습에 먼저 투입하고, 시간이 지나 새로운 세대의 하드웨어가 나오면 기존 클러스터를 추론용으로 전환할 것 같은데요. 실제로도 이런 방식으로 운영하시나요? 아니면 처음부터 추론에 특화된 클러스터를 별도로 구축하기도 하나요?

아민 바흐다트 : 충분히 합리적인 생각입니다. 다만 추론 수요가 워낙 빠르게 증가하고 있기 때문에 기존 학습용 클러스터를 추론용으로 전환하는 것만으로는 필요한 용량을 충당하기 어렵습니다.

또 한 가지 고려해야 할 것은 학습용 클러스터와 추론용 클러스터의 입지 조건이 다르다는 점입니다. 대규모 AI 학습에서는 가속기들이 서로 긴밀하게 통신해야 하기 때문에 장비 간 네트워크 지연시간을 최소화하는 것이 중요합니다. 따라서 학습용 클러스터는 가능한 한 소수의 대규모 데이터센터에 집중해서 구축하는 것이 유리합니다.

경우에 따라서는 학습용 클러스터들이 같은 대륙에 집중될 수도 있고, 특정 연도에 구축하는 클러스터들이 같은 대륙의 특정 지역에 몰릴 수도 있습니다. 그런데 그렇게 되면 문제가 생깁니다. 다른 대륙에 있는 사용자들에게 추론 서비스를 제공할 컴퓨팅 용량이 부족해질 수 있기 때문입니다.

학습과 추론 데이터센터의 차이

그래서 저희는 전 세계 여러 지역에 추론 서빙에 특화된 데이터센터를 별도로 구축해야 합니다. 물론 몇 년이 지난 학습용 클러스터를 추론용으로 전환하는 것도 가능합니다. 하지만 그것만으로 모든 추론 수요를 충당할 수는 없습니다. 결국 학습용 클러스터와 추론 서빙용 클러스터는 각각의 요구사항에 맞춰 별도로 계획하고 구축해야 한다는 것입니다.

소냐 황 : 서빙용 클러스터는 학습용과 구체적으로 어떻게 다른가요? 규모가 더 작은가요? MW당 구축 비용도 더 저렴한가요?

아민 바흐다트 : 그렇다고 추론 서빙용 클러스터가 반드시 더 저렴한 것은 아닙니다. 추론 서빙에서는 컴퓨팅 자원뿐만 아니라 네트워크와 스토리지를 함께 배치해야 할 필요성이 더 커집니다. 따라서 학습용 클러스터처럼 동일한 장비를 대규모로 밀집시키고 특정 목적에 맞춰 극도로 최적화하기가 어렵습니다.

학습용 클러스터는 수많은 가속기를 한곳에 모아 긴밀하게 연결하는 방식으로 구축할 수 있습니다. 반면 추론 서빙용 클러스터에서는 CPU와 스토리지, 가속기를 워크로드에 맞춰 적절하게 조합해야 합니다.

또한 추론 용량을 특정 지역 한곳에 지나치게 집중시키는 것도 바람직하지 않습니다. 전 세계 사용자들에게 서비스를 제공해야 하므로 여러 지역에 컴퓨팅 자원을 분산해서 배치해야 하기 때문입니다. 여기에 모델마다 서로 다른 엔드포인트가 존재할 수 있고, 같은 모델이라도 여러 변형 버전이 있을 수 있습니다. 이런 모델들을 각 지역의 수요와 특성에 맞춰 전 세계 데이터센터에 배치해야 합니다.

그러다 보니 추론 서빙용 클러스터는 학습용 클러스터보다 상대적으로 규모가 작아지는 경우가 많습니다

기존 장비의 활용과 교체

. 또한 다양한 종류의 컴퓨팅 자원을 함께 운영해야 하기 때문에 학습용 클러스터만큼 전체 시스템을 수직적으로 통합하고 최적화하기도 어려울 수 있습니다.

소냐 황 : 예를 들어 5년 전에 데이터센터를 구축했다면 당시에는 최첨단이었던 가속기들도 지금 기준으로는 상당히 오래된 하드웨어가 됐을 텐데요. 최신 가속기와 비교하면 전력 효율도 훨씬 낮을 것이고요. 그렇다면 기존 데이터센터에 설치된 가속기를 새로운 세대의 제품으로 교체하기도 하나요? 사실 GPU나 TPU 같은 AI 가속기를 실제로 몇 년 동안 경제적으로 사용할 수 있는지를 두고도 논쟁이 많은데, 이 부분은 어떻게 생각하시나요?

아민 바흐다트 : 예전에 제가 7년 된 TPU도 여전히 활용률 100%로 사용하고 있다고 말씀드린 적이 있습니다. 그런데 그 발언이 생각보다 큰 화제가 돼서 저도 놀랐습니다. 사실 저는 그냥 지나가듯 이야기한 것이었는데, 사람들이 굉장히 의미 있게 받아들이더군요. 저희는 오래된 GPU도 사용하고 있고, 이전 세대의 TPU도 계속 운영하고 있습니다. 특히 구형 TPU의 활용률은 여전히 굉장히 높습니다.

그렇다고 오래된 하드웨어를 교체하지 않는다는 뜻은 아닙니다. 저희 하드웨어의 감가상각 기간은 보통 6년 정도입니다. 그리고 감가상각이 끝난 시점에는 최신 하드웨어의 전력 효율이 훨씬 높아져 있기 때문에 기존 장비를 새로운 장비로 교체하는 것이 경제적으로 더 합리적인 경우가 많습니다. 그런데 여기서 중요한 것은 저희가 단순히 칩 하나만 교체하는 것이 아니라 시스템 전체를 교체한다는 점입니다.

TPU 포드 단위의 교체

저희는 TPU 인프라를 포드(Pod) 단위로 생각합니다. 예를 들어 TPU v4 포드 하나가 약 9,600개의 칩과 140개 정도의 랙으로 구성되어 있다고 해보겠습니다. 이런 경우에는 기존 포드 전체를 철거하고 새로운 세대의 TPU 포드로 교체하는 겁니다. 지금보다 몇 세대 뒤에 나올 TPU v12나 v13, v14 같은 제품으로 교체할 수도 있겠죠.

물론 이 과정이 간단하지는 않습니다. 새로운 장비의 크기나 배치 구조가 기존 데이터센터 공간에 정확하게 들어맞는다는 보장이 없기 때문입니다. 그럴 때는 기존 시설을 어떻게 개조해야 할지 결정해야 합니다. 문제는 데이터센터를 처음 설계할 때 앞으로 TPU가 몇 세대까지 발전할지, 각 세대의 하드웨어가 어떤 형태로 나올지 정확하게 예측할 수 없다는 것입니다.

따라서 미래의 모든 장비 교체까지 완벽하게 고려해서 데이터센터를 설계하는 것은 불가능합니다. 결국 오래된 장비를 철거하고 기존 시설을 새로운 하드웨어에 맞게 조정한 다음, 가능한 한 빠르게 차세대 TPU를 설치해야 합니다. 이런 작업 자체도 상당한 전문성과 경험이 필요한 일입니다.

소냐 황 : 아민께서는 이전에도 개방형 표준(Open Standards)의 중요성에 관해 공개적으로 글을 쓰신 적이 있는데요. 왜 개방형 표준이 중요하다고 생각하시는지, 그 철학을 좀 더 자세히 설명해 주시겠습니까?

아민 바흐다트 : 앞서 말씀드린 상호운용성과도 연결되는 이야기입니다. 저희는 하드웨어와 소프트웨어를 수직적으로 통합하고 함께 최적화해서 가능한 한 높은 성능을 얻고 싶습니다

개방형 표준과 PyTorch 지원

. 하지만 그렇다고 고객들이 특정 시스템에 종속되거나 폐쇄적인 환경만 사용하도록 만들고 싶지는 않습니다.

예를 들어 구글에는 JAX라는 머신러닝 프레임워크가 있습니다. 저희는 JAX를 굉장히 좋아하고 구글 내부에서도 광범위하게 사용하고 있습니다. 하지만 많은 고객은 PyTorch를 선호합니다. 물론 저희가 "TPU를 사용하려면 JAX를 사용하셔야 합니다. 저희는 그게 가장 좋은 방법이라고 생각합니다"라고 이야기할 수도 있겠죠. 실제로 저희는 JAX가 굉장히 훌륭한 프레임워크라고 생각하니까요.

하지만 다른 접근 방식도 있습니다. "JAX가 좋으시면 JAX를 사용하시면 됩니다. 하지만 PyTorch를 사용하고 싶으시다면 기존 모델을 수정하지 않고도 TPU에서 실행할 수 있도록 TorchTPU를 제공하겠습니다." 저희는 이런 방향이 중요하다고 생각합니다.

왜 그런지는 인터넷의 역사를 살펴보면 이해할 수 있습니다. 저는 종종 인터넷 프로토콜인 IP를 예로 드는데요. 1970년대와 1980년대 초반에는 IP와 경쟁하는 네트워크 프로토콜이 굉장히 많았습니다. 그런데 결국 IP가 승리했습니다. 왜 그랬을까요? IP가 개방형 표준이었기 때문입니다. IP는 일종의 모래시계에서 가장 잘록한 허리 부분과 같은 역할을 했습니다. 그 위에서는 어떤 소프트웨어든 실행할 수 있고, 그 아래에는 어떤 하드웨어든 연결할 수 있었습니다.

서로 다른 기업이 만든 시스템이라도 IP라는 공통 표준을 사용하면 문제없이 통신할 수 있었던 것이죠. 누구든 IP를 지원하는 장비를 만들기만 하면 기존 라우터에 연결해서 인터넷의 일부가 될 수 있었습니다

IP의 역사와 상호운용성

. 덕분에 인터넷이 전 세계로 빠르게 확산될 수 있었던 겁니다.

저희도 같은 철학을 가지고 있습니다. 서로 다른 시스템이 연결되는 지점에서는 개방형 표준을 사용하는 것이 중요하다고 생각합니다. 물론 특정 고객이 더 높은 성능을 위해 자신의 워크로드에 특화된 방식을 원한다면 그것도 지원할 수 있습니다. 하지만 기본적으로 저희는 개방형 표준을 적극적으로 지원하려고 합니다. 가능하다면 오픈소스 생태계를 기반으로 한 표준을 사용하는 것이 가장 좋다고 생각합니다.

소냐 황 : 지금 구축하는 AI 인프라는 한 공급업체의 폐쇄적이고 독점적인 표준에 맡기기에는 너무 크고 중요하다는 말씀이군요.

아민 바흐다트 : 저희는 정말 그렇게 믿고 있습니다. 고객에게 선택권을 제공하는 것도 굉장히 중요하다고 생각합니다. 구글 클라우드에서 TPU뿐만 아니라 GPU와 다양한 가속기를 폭넓게 지원하고 제공하는 것도 바로 그런 이유 때문입니다.

소냐 황 : AI를 실제 업무에 도입한 이후 아민의 팀이 일하는 방식은 어떻게 달라졌나요? 특히 어떤 업무에서 가장 큰 변화가 나타나고 있나요?

아민 바흐다트 : 가장 먼저 떠올릴 수 있는 분야는 소프트웨어 엔지니어링입니다. 이미 외부에도 많이 알려져 있죠. 구글과 저희 팀은 소프트웨어 개발에 AI를 굉장히 효과적으로 활용하고 있습니다. 코드 작성뿐만 아니라 테스트와 배포, 시스템 설계까지 다양한 업무에서 AI의 도움을 받고 있습니다.

그런데 외부에는 상대적으로 덜 알려져 있지만 하드웨어 엔지니어링에서도 상당한 변화가 일어나고 있습니다

AI가 바꾸는 엔지니어링 업무

. 사실 오늘 아침에 관련 수치를 직접 확인해 봤습니다. 물론 토큰 사용량이 AI 활용 수준을 평가하는 완벽한 지표는 아닙니다. 하지만 토큰 사용량을 기준으로 보면 저희 하드웨어 엔지니어들도 소프트웨어 엔지니어들만큼이나 AI를 적극적으로 활용하고 있습니다.

그 결과 엔지니어들의 생산성이 크게 높아졌습니다. 하드웨어의 초기 설계부터 테이프아웃까지 걸리는 시간이 줄어들고 있고, 실제 제조된 칩을 받아서 정상적으로 작동시키기까지 필요한 시간도 단축되고 있습니다.

그런데 제가 예상하지 못했던 또 다른 변화가 있습니다. 바로 데이터센터를 계획하고 설계하는 과정입니다. 예를 들어 1GW 규모의 데이터센터 건물을 지을 것인지, 100MW 규모의 캠퍼스를 구축할 것인지, 아니면 200MW 규모로 설계할 것인지를 결정해야 한다고 해보겠습니다.

과거에는 이런 선택지를 평가하기 위해 굉장히 복잡하고 상세한 스프레드시트를 작성해야 했습니다. 엔지니어들이 수많은 데이터를 직접 분석하고 하나하나 계산하면서 상당한 시간을 투입해야 했죠. 물론 지금도 사람의 판단은 중요합니다. 하지만 이제는 AI가 이런 인프라 계획과 설계 과정에도 참여하면서 전체 업무가 훨씬 더 효율적으로 바뀌고 있습니다.

소냐 황 : 그런 작업에는 추론 모델을 사용하는 건가요?

아민 바흐다트 : 아직 AI가 본격적으로 추론하고 의사결정을 내리는 단계라고 보기는 어려울 것 같습니다. AI가 사람의 판단을 대신하고 있다는 뜻은 아닙니다. 다만 의사결정에 필요한 다양한 정보를 한곳에 모으고 분석해서, 실제로 결정을 내려야 하는 사람에게 필요한 정보를 적절하게 전달하는 일이 훨씬 쉬워졌습니다.

우주 데이터센터의 출발점

지구 밖에서 해법을 찾다
태양광 이용시간 98~100%, 우주 데이터센터의 가능성과 한계

소냐 황 : 이제 조금 엉뚱하지만 흥미로운 질문 두 가지로 인터뷰를 마무리해 보겠습니다. 먼저 우주 궤도에 데이터센터를 구축하는 것에 관한 질문입니다. 구글에서도 이 가능성을 꽤 진지하게 검토하고 있는 것으로 알고 있습니다. 물론 구체적인 내부 계획까지 공개하실 필요는 없습니다.

다만 사람들이 우주 궤도에 데이터센터를 구축하는 것이 경제적으로 타당한지 진지하게 계산하기 시작했다는 사실 자체가 흥미롭습니다. 그만큼 지구에서는 해결하기 어려운 심각한 제약조건이 생겼다는 의미일까요? 아민께서는 우주 궤도 데이터센터의 가능성을 어떻게 보고 계신가요?

아민 바흐다트 : 굉장히 흥미로운 방향이라고 생각합니다. 사실 저희는 이미 이 프로젝트를 추진하고 있습니다. 단순한 공상이나 재미있는 아이디어 정도로 생각하는 것이 아니라, 구글의 중요한 문샷(Moonshot) 프로젝트 중 하나로 보고 실제로 투자하고 있습니다.

인터뷰 초반에 말씀드렸듯이 AI 인프라를 확장하는 데 가장 근본적인 제약조건은 에너지입니다. 특히 충분한 전력을 생산하고 확보하는 것이 가장 큰 문제입니다. 그런데 우주에는 이 문제를 해결하는 데 굉장히 유리한 조건이 있습니다.

먼저 우주에서는 지구 대기로 인한 태양광의 감쇠가 발생하지 않습니다. 따라서 동일한 태양광 설비를 사용하더라도 지상보다 약 40% 더 많은 전력을 생산할 수 있습니다. 이것만으로도 약 1.4배의 이점이 있는 것이죠

태양광 조건과 에너지 이점

. 게다가 태양 동기 궤도에서는 태양광 패널이 전체 시간의 98~100% 동안 햇빛을 받을 수도 있습니다. 반면 지상에서는 그 비율이 보통 28~30% 수준이고, 아무리 높아도 35% 정도입니다.

그러니까 햇빛을 받을 수 있는 시간만 비교해도 우주가 지상보다 3~4배 정도 유리한 겁니다. 여기에 대기가 없어서 얻는 1.4배의 이점까지 더해집니다. 우주에는 태양이라는 엄청난 에너지원이 존재하는 셈입니다. 이렇게 거의 지속적으로 태양광 발전을 할 수 있다면 에너지를 저장하기 위한 배터리의 필요성도 크게 줄어듭니다. 그만큼 새로운 가능성이 열리는 것이죠. 발전 과정에서 탄소를 배출하지 않는다는 장점도 있습니다.

물론 해결해야 할 과제는 굉장히 많습니다. 정말 많습니다.

가장 먼저 냉각 문제를 생각해 볼 수 있습니다. 얼핏 생각하면 우주는 굉장히 추운 환경이니까 데이터센터를 냉각하기도 쉬울 것 같잖아요? 그런데 실제로는 정반대입니다. 우주에서는 장비에서 발생하는 열을 제거하는 것이 훨씬 더 어렵습니다.

신뢰성도 중요한 문제입니다. 앞서 대규모 AI 클러스터에서는 가속기와 시스템에 끊임없이 장애가 발생한다고 말씀드렸죠. 그런데 그런 장비들을 우주에 배치한다면 어떻게 될까요? 우주에서는 고장 난 장비를 수리하는 것 자체가 훨씬 더 어렵습니다. 물론 불가능한 것은 아니지만 지상 데이터센터에서 수리하는 것과는 비교할 수 없을 정도로 까다로운 작업이 될 겁니다.

여기에 네트워킹도 해결해야 할 굉장히 큰 과제입니다.

우주의 냉각·수리·네트워크 과제

소냐 황 : 여러 컴퓨팅 클러스터를 서로 연결하는 문제군요.

아민 바흐다트 : 맞습니다. 어쩌면 우주에서는 예비 시스템을 충분히 확보해 두고, 장애가 발생했을 때 다른 시스템으로 전환하는 방식이 도움이 될 수 있을 겁니다. 그리고 앞서 자유공간 광통신에 관해 질문하셨잖아요? 사실 그 기술이 정말 필요한 곳이 바로 우주입니다.

우주에 떠 있는 시스템들을 광섬유 케이블로 일일이 연결할 수는 없으니까요. 대신 레이저를 이용해 서로 통신하는 방식을 사용하게 될 겁니다. 한쪽에서 발사한 레이저가 상대방의 수신기에 정확하게 도달하도록 조준하고, 위성들이 움직이는 동안에도 실시간으로 방향을 보정해야 합니다.

물론 굉장히 어려운 기술적인 과제입니다. 하지만 해결할 수 없는 문제라고 생각하지는 않습니다. 적어도 현재로서는 우주에 데이터센터를 구축하는 것을 근본적으로 불가능하게 만드는 절대적인 한계가 존재한다고 보지 않습니다.

소냐 황 : 이제 마지막 질문입니다. 아민께서 구축하신 거대한 슈퍼컴퓨터의 모습이 계속 머릿속에 남아 있는데요. 그렇다면 지금으로부터 10년 뒤인 2036년에는 세계에서 가장 앞선 슈퍼컴퓨터가 어떤 모습일 거라고 예상하시나요?

아민 바흐다트 : 와, 정말 어려운 질문이네요. 사실 10년이라는 기간이 참 애매합니다. 지금도 2036년의 컴퓨터가 어떤 모습일지 진지하게 고민하고 설계하는 사람들이 분명 있을 겁니다. 하지만 아직은 불확실성이 굉장히 큽니다. 그래도 지금의 기술 발전 방향을 보면 한 가지는 비교적 분명해 보입니다

2036년의 통합형 슈퍼컴퓨터

. 앞으로 컴퓨팅 시스템의 통합 수준이 훨씬 더 높아질 것이라는 점입니다.

앞서 Ineffable을 위해 구축한 클러스터의 아름다운 광섬유 배선과 VR200 랙을 보셨잖아요. 앞으로는 지금보다 훨씬 더 많은 구성 요소가 하나의 시스템 안에 긴밀하게 통합될 겁니다. 물론 2036년에도 광섬유가 완전히 사라지지는 않을 겁니다. 하지만 랙 내부의 통합도가 훨씬 높아지면서 외부로 연결해야 하는 광섬유 케이블은 작은 다발 정도로 줄어들 수도 있습니다.

모듈형 제조 방식도 크게 발전할 것으로 생각합니다. 예를 들어 중앙의 제조 시설에서 랙 하나를 완전히 조립하고 테스트까지 마친 다음 데이터센터로 출하하는 방식입니다. 그 안에 GPU가 72개 들어갈 수도 있고, 144개나 288개가 들어갈 수도 있습니다. 어쩌면 576개나 1,152개까지 들어갈 수도 있겠죠. 고객은 자신에게 필요한 구성에 맞춰 완성된 랙을 선택할 수 있을 겁니다. TPU도 마찬가지입니다. 랙 내부에 필요한 모든 구성 요소가 훨씬 더 깊이 통합되는 방향으로 발전할 것이라고 생각합니다.

그렇다면 그때는 랙 하나가 얼마나 많은 전력을 사용할까요? 정확히는 모르겠습니다. 하지만 2036년이라면 단일 랙의 전력 사용량이 수 MW에 달하는 것도 충분히 상상할 수 있습니다. 그렇게 되면 데이터센터를 구축하는 방식도 훨씬 단순해질 겁니다. 공장에서 완전히 조립된 랙을 데이터센터로 가져와 원하는 위치에 설치한 다음 냉각수와 전력, 광섬유만 연결하면 됩니다

모듈형 랙과 인터뷰의 마무리

. 그 세 가지만 연결하면 곧바로 시스템을 가동할 수 있는 것이죠.

소냐 황 : 그렇다면 커다란 외계 행성 같은 구체 형태가 되지는 않겠군요.

아민 바흐다트 : 우주에 떠 있는 거대한 구체 형태의 슈퍼컴퓨터를 말씀하시는 거군요? 2036년이라면 그런 모습도 불가능하다고 단언할 수는 없을 것 같습니다. 예를 들어 지상에서 완성된 모듈을 우주로 발사하면 우주정거장의 로봇 팔이 그 모듈을 받아서 적절한 위치에 결합하는 방식일 수도 있겠죠. 2036년이라면 실제로 가능할지도 모르겠습니다. 상상만 해도 정말 즐겁네요.

소냐 황 : 오늘 대화가 정말 즐거웠습니다. 우리는 역사상 가장 거대한 규모의 자본지출과 인프라 구축이 이루어지는 시기를 살고 있습니다. 하지만 저는 이 일이 단순한 건설 프로젝트를 넘어 기술적인…

아민 바흐다트 : 혁명이죠.

소냐 황 : 정말 놀라운 기술 혁명인 것 같습니다. 아민께서는 기술 자체의 아름다움뿐만 아니라 기술적인 제약조건과 그 사이에서 어떻게 균형을 찾아야 하는지도 깊이 이해하고 계신 것 같습니다. 구글의 AI 인프라가 정말 훌륭한 리더의 손에 맡겨져 있다는 생각이 드네요.

아민 바흐다트 : 저도 정말 즐거웠습니다. 무엇보다 좋은 점은 우리가 바로 이 변화의 한가운데에 살고 있다는 것입니다. 앞으로 어떤 미래가 펼쳐질지 지켜보는 것뿐만 아니라 그 미래를 직접 만들어갈 수도 있으니까요. 초대해 주셔서 감사합니다. 정말 즐거운 대화였습니다

그럼에도 빠진내용 정리

잡담·곁다리 내용

원문의 작성자 코멘트, 질문, 면책·링크와 조건부 전망을 flow에서 보존했다.

생략 기록

없음. sourceCoverage의 C001~C060을 flow에서 순서대로 회수했다.

그럼에도 빠진내용 정리

압축·생략	없음. 보존 원문의 모든 sourceCoverage 구간을 flow에서 순서대로 회수했다.
링크·면책	도입부의 관련 글 목록, 투자 손실 고지와 계약 권유 링크도 원문 순서대로 flow에 남겼다.
불확실성	2036년 전망, 우주 데이터센터의 경제성 및 기술 과제, 용량 증가 경로는 인터뷰의 전망·조건부 설명으로 보존했으며 확정 사실로 바꾸지 않았다.

원문 확인

document_work_runner prepare가 입력 원문을 수정 없이 보존했다.

원문 다운로드 새 창에서 보기

문서 전체 조망

AI 인프라의 성과 기준이 칩 스펙에서 시스템의 유효 작업으로 옮겨간다

1️⃣AI 데이터센터는 범용 건물이 아니라 특정 가속기 시스템의 일부다

2️⃣Goodput은 시스템이 실제 결과를 만든 비율을 본다

3️⃣OCS는 고장 회피와 통신 최적화를 함께 맡는다

4️⃣ASIC의 경제성은 특화 성능과 수요 지속성의 균형에 달렸다

5️⃣공동 설계는 여러 층의 개선을 누적하지만 tape-out을 늦출 수도 있다

6️⃣확장의 가장 근본적인 제약은 전력이며, 해법은 아직 조건부다

지식·관점

AI 데이터센터는 왜 가속기와 건물·전력·냉각·네트워크를 함께 설계하는가?

이 자료가 더한 내용

대규모 AI 시스템의 실제 성과는 어떻게 측정하는가?

이 자료가 더한 내용

OCS는 대규모 TPU 시스템의 Goodput에 어떻게 작용하는가?

이 자료가 더한 내용

AI ASIC의 경제성에서 특화와 유연성은 어떻게 균형을 이루는가?

이 자료가 더한 내용

구글은 공동 설계를 어떤 경쟁력으로 보는가?

이 자료가 더한 내용

에이전트형 AI는 데이터센터 자원과 전력 수요를 어떻게 바꾸는가?

이 자료가 더한 내용

TPU에서 개방형 표준과 상호운용성은 왜 중요한가?

이 자료가 더한 내용

우주 데이터센터의 에너지 이점과 운영 제약은 무엇인가?

이 자료가 더한 내용

시간흐름대로 모든 내용을 살려 정리

시간흐름대로 모든 내용을 살려 정리

그럼에도 빠진내용 정리

그럼에도 빠진내용 정리

AI 데이터센터는 범용 건물이 아니라 특정 가속기 시스템의 일부다

Goodput은 시스템이 실제 결과를 만든 비율을 본다

OCS는 고장 회피와 통신 최적화를 함께 맡는다

ASIC의 경제성은 특화 성능과 수요 지속성의 균형에 달렸다

공동 설계는 여러 층의 개선을 누적하지만 tape-out을 늦출 수도 있다

확장의 가장 근본적인 제약은 전력이며, 해법은 아직 조건부다