Google Project Suncatcher 발사, 우주 데이터 센터 시험을 앞당기다

Google은 2027년 두 위성을 중심으로 계획했던 임무의 일부를 앞당겨, 첫 Project Suncatcher 궤도 시험을 10월 1일로 옮겼다. Google Project Suncatcher 발사는 SpaceX 로켓을 통해 네 개의 AI 가속기를 저지구 궤도로 보낼 예정이다.

이는 우주 데이터 센터의 시작처럼 들릴 수 있다. 그러나 엄격한 제약 아래 이뤄지는 하드웨어 생존 실험으로 이해하는 편이 더 정확하다. 위성의 태양광 전력은 약 1킬로와트이며, 프로세서는 냉각이 필요해지기 전까지 약 15분간 작동할 수 있다.

Google은 전체 배치 일정을 앞당기는 것이 아니라 하나의 시험을 가속하고 있다. 회사는 여전히 2027년에 더 야심 찬 두 위성 임무를 계획하고 있다. 이 우주선들은 밀집한 위성군 전체에 AI 워크로드를 분산하기 위한 광학 연결을 시험하게 된다.

초기 발사가 중요한 이유는 실험실 가정을 실제 운용 증거로 대체하기 때문이다. 이는 일반 Google Tensor Processing Unit, 즉 TPU를 발사 진동, 방사선, 온도 변화, 진공 냉각 환경에 노출한다.

SpaceX, Starcloud, Aetherflux 등 다른 기업들도 궤도 컴퓨팅을 탐색하고 있다. 그러나 Google은 TPU, Gemini 모델, 네트워킹 연구, 데이터 센터 경험을 포함한 자사 인프라 스택을 기반으로 이 문제에 접근하고 있다.

따라서 경쟁의 핵심은 누가 먼저 컴퓨터를 궤도에 올리느냐가 아니다. 궤도 컴퓨팅이 짧은 시연을 넘어 신뢰할 수 있는 네트워크형 인프라로 발전할 수 있느냐에 있다.

Google Project Suncatcher 발사는 초기 하드웨어 시험이다

Google은 상용 데이터 센터가 아니라 작은 궤도 실험실을 발사한다.

MVP라고 불리는 실험 위성은 대략 냉장고 크기다. 여기에는 지상 클라우드 인프라의 AI 워크로드에 사용되는 동일한 프로세서 계열인 Google의 Trillium TPU 네 개가 탑재된다.

MVP는 여러 탑재체를 함께 실어 나르는 Falcon 9 공동 탑승 비행인 SpaceX의 Transporter-18 임무에 실린다. Google은 새로운 우주선 설계를 요구하는 대신 기존 위성 플랫폼을 제공한 Planet과 함께 이 실험을 개발했다.

이 결정은 Google이 일정을 앞당길 수 있었던 이유를 설명한다. 원래 계획은 2027년 초까지 맞춤 제작한 시제품 위성 두 기를 준비하는 것이었다. 기존 Planet 우주선에 TPU 하드웨어를 추가하면서 더 이른 시점에 비행 데이터를 수집할 기회가 생겼다.

Google의 9월 24일 임무 업데이트는 이번 발사를 Project Suncatcher의 첫 궤도 시험으로 설명한다. 이 임무는 프로세서가 실험실에서는 완전히 경험할 수 없는 기계적·환경적 조건을 견디는지 살펴볼 예정이다.

시험과 배치의 구분은 중요하다. MVP에는 TPU 네 개가 탑재되지만, 지상 데이터 센터에는 수천 개의 가속기가 들어갈 수 있다. 태양광 어레이는 약 1킬로와트를 생산하는데, 이는 소규모 서버 시설 내부에서 이용 가능한 전력보다도 훨씬 적다.

냉각은 실험의 제약을 더한다. TPU는 약 15분 동안 Gemini 워크로드를 실행한다. 이후 위성의 라디에이터가 축적된 열을 방출하는 동안 작동을 멈춰야 한다.

이러한 운용 패턴은 연속적인 AI 서비스를 지원하지 않는다. 대신 엔지니어들은 통제된 시간대에 프로세서 동작, 메모리 오류, 전력 사용량, 열 성능, 워크로드 무결성을 측정할 수 있다.

이 임무에는 Google의 궁극적 아키텍처에서 핵심이 되는 레이저 링크도 없다. 단일 위성으로는 위성군 전반의 분산 컴퓨팅을 시연하거나 여러 궤도 프로세서가 하나의 클러스터처럼 동작할 수 있음을 입증할 수 없다.

Project Suncatcher를 한 문장으로 설명하자면, 이번 발사는 Google의 기존 AI 하드웨어가 궤도에 도달한 뒤에도 안정적으로 작동할 수 있는지를 묻는 좁은 범위의 시험이다.

성공적인 답은 다음 실험의 타당성을 뒷받침할 것이다. 하지만 Google 우주 데이터 센터가 상업적으로 실현 가능하다는 사실을 입증하지는 못한다.

따라서 10월 1일은 증거 수집을 가속하는 시점을 의미한다. Google은 더 큰 2027년 이정표를 취소하지 않고도 비행 하드웨어를 더 빨리 시험할 방법을 찾았다.

이는 발표나 시뮬레이션보다 더 큰 의미를 지닌다. 우주 비행은 지상 시험이 근사할 수는 있어도 완전히 재현할 수 없는 진동, 방사선, 진공, 열 순환의 조합을 만들어 낸다.

이번 발사는 프로젝트 규모가 작을 때 불편한 실패를 발견할 기회도 Google에 제공한다. 메모리 결함, 냉각 부족, 전력 관리 문제는 수십 기의 위성에 걸쳐 조사하는 것보다 MVP에서 연구하는 편이 비용이 적게 든다.

가장 가치 있는 결과는 중단 없는 작동이 아닐 수도 있다. 고장 모드에 대한 상세 정보는 Google이 후속 프로세서, 차폐 장치, 라디에이터, 워크로드 일정을 재설계하는 데 도움이 될 것이다.

Google이 일정 일부를 앞당긴 이유

수정된 일정은 더 빠른 시험 기회를 반영한 것이지, 궤도 AI가 더 쉬워졌다는 증거는 아니다.

Google은 2025년 11월 장기 연구 프로그램으로 Project Suncatcher를 발표했다. 공개 로드맵은 Planet과 함께 제작한 두 위성을 2027년 초까지 발사하는 계획이었다.

Google이 개발 중이던 Planet 위성에 자사 하드웨어를 탑재하기로 결정한 뒤 10월 임무가 등장했다. 발사 보도에 따르면, 이 방식으로 팀은 맞춤형 시제품 두 기를 모두 기다리지 않아도 됐다.

위성은 저지구 궤도로 향하는 동안 약 10분간 강한 진동과 가속을 겪게 된다. Google은 우주선이 지구 중력의 약 10배에 이르는 지속 하중을 받을 수 있다고 설명한다.

개별 부품은 중력의 50~100배에 이르는 힘을 받을 수 있다. 엔지니어들은 발사 전 관련 진동 주파수를 재현하기 위해 조립된 시스템을 세 축 방향으로 흔들었다.

Google에 따르면 이 시험은 하드웨어가 온전한 상태를 유지했음을 보여줬다. 그러나 지상 시험만으로는 연결부, 메모리, 냉각 소재, 프로세서가 궤도 임무 전반에서 어떻게 작동할지 확인할 수 없다.

방사선은 또 다른 불확실성 범주를 만든다. 고에너지 입자는 반도체 소재를 손상하거나 저장된 비트를 바꿔 일시적 오류를 일으킬 수 있다.

Google은 AI 워크로드를 처리하는 Trillium TPU에 67메가전자볼트 양성자 빔을 노출했다. 회사는 누적 선량 2킬로라드 이후 고대역폭 메모리에서 불규칙성이 나타났다고 밝혔다.

Google은 이 수준이 5년 임무 동안 예상되는 차폐 방사선 선량의 거의 세 배라고 추정한다. 또한 최고 시험 선량에서도 총 이온화 방사선에 기인한 영구적 고장은 없었다고 보고했다.

이는 고무적인 실험실 결과이지만, 여전히 회사 측 결과다. 궤도 환경에는 변화하는 방사선 조건, 온도 주기, 워크로드 동작, 여러 우주선 시스템 간 상호작용이 더해진다.

MVP는 지상의 엔지니어에게 원격 측정 데이터를 제공하면서 이러한 상호작용을 시험할 수 있다. 팀은 오류를 방사선 사건, 워크로드 강도, 프로세서 온도, 이용 가능한 전력 변화와 비교할 수 있다.

이번 실험을 앞당기면 2027년 임무의 추측성도 줄어든다. MVP가 취약한 부품이나 부정확한 가정을 드러낼 경우 Google은 발사 전에 후속 위성을 수정할 수 있다.

더 이른 일정이 Google이 내년에 완전한 위성군을 발사한다는 의미는 아니다. 2027년 시제품 두 기는 여전히 다른 목적, 즉 이동하는 위성 간 고대역폭 레이저 통신 시험을 수행한다.

Google이 이러한 링크를 필요로 하는 이유는 현대 AI 시스템이 여러 가속기가 데이터를 빠르게 교환하는 방식에 의존하기 때문이다. 고립된 프로세서로는 데이터 센터 클러스터의 동작을 재현할 수 없다.

이처럼 이정표를 분리하면 로드맵을 더 쉽게 해석할 수 있다. 10월 임무는 생존성과 현지 작동을 시험한다. 2027년 임무는 분산 작동과 광학 연결을 시험할 것으로 예상된다.

단계적 접근은 Google이 모든 문제를 하나의 거대한 엔지니어링 프로젝트로 다루지 않도록 한다. 하드웨어, 열 제어, 편대 비행, 네트워킹, 경제성은 각각 독립적으로 실패할 수 있다.

Google Project Suncatcher 발사는 이 순서의 첫 단계를 앞당긴다. 더 어려운 시스템 수준의 질문은 후속 임무에 남겨 둔다.

Google 우주 데이터 센터 계획의 작동 원리

Project Suncatcher는 풍부한 궤도 태양 에너지와 유난히 조밀한 컴퓨팅 위성 네트워크의 결합에 의존한다.

매력은 햇빛에서 시작된다. 적절한 태양동기궤도에 있는 위성은 지구 주행 대부분의 시간 동안 햇빛을 받을 수 있다.

Google은 궤도 태양광 패널이 지상의 동등한 패널보다 최대 8배 많은 에너지를 생산할 수 있다고 추정한다. 밤, 구름, 대기가 일으키는 상당 부분의 필터링을 피할 수 있기 때문이다.

이 에너지는 시설을 지역 전력망에 연결하지 않고도 AI 연산을 지원할 수 있다. 궤도 시스템은 지상 캠퍼스와 관련된 지역 물, 토지, 건설 요구 사항도 피할 수 있다.

그러나 이용 가능한 태양광 전력이 자동으로 쓸 수 있는 데이터 센터를 만드는 것은 아니다. 프로세서는 데이터를 교환하고, 열을 방출하고, 지구와 통신하며, 방사선을 견디고, 저지연 광학 링크를 위해 충분히 가까운 거리를 유지해야 한다.

Google의 시스템 설계는 TPU를 탑재하고 자유공간 광학 링크로 통신하는 모듈형 위성을 구상한다. 이 링크는 물리적 케이블이 아닌 레이저를 이용해 정보를 전송한다.

대규모 AI 워크로드에서는 가속기가 매우 높은 속도로 데이터를 교환해야 한다. Google의 분석에 따르면 궤도 연결은 궁극적으로 초당 수십 테라비트로 측정되는 용량이 필요하다.

회사는 하나의 실험실 트랜시버 쌍을 사용해 각 방향에서 초당 800기가비트를 시연했다. 이는 양방향 합산 용량으로 초당 1.6테라비트에 해당한다.

이 결과는 광학 개념을 뒷받침하지만, 실험대 위에서 나온 것이다. 비행 하드웨어는 양쪽 끝점이 궤도 속도로 이동하는 동안에도 비슷한 연결을 유지해야 한다.

Google이 제시한 대응책은 조밀한 위성 편대다. 공개된 모델은 고도 약 650킬로미터에서 운용되는 위성 81기를 고려한다.

시뮬레이션된 클러스터의 반경은 1킬로미터다. 인접한 우주선은 계획된 편대를 유지하면서 서로 약 100~200미터 거리까지 접근할 수 있다.

짧은 거리는 고용량 링크를 유지하는 데 필요한 광학 전력을 줄인다. 동시에 항법, 조준, 충돌 회피, 궤도 유지에 요구되는 정밀도는 높아진다.

각 우주선은 자신의 위치와 인근 위성의 위치를 알아야 한다. 레이저는 편대 전체가 지구 주위를 이동하는 동안 작은 움직이는 목표물을 계속 겨냥해야 한다.

이 때문에 Google 우주 데이터 센터 개념은 일반 통신 위성에 서버를 발사하는 것과 다르다. 이는 하나의 분산 컴퓨팅 시스템으로 협력하는 다수의 우주선에 의존한다.

첫 임무는 이 메커니즘을 시험하지 않는다. MVP에는 제안된 단거리·고대역폭 연결을 구축할 수 있는 짝 위성이 없다.

대신 MVP는 미래 각 노드 내부에 탑재될 컴퓨팅 모듈에 관한 증거를 제공한다. Google은 대규모 궤도 네트워크를 설계하기 전에 표준 TPU 아키텍처가 여전히 실현 가능한지 연구할 수 있다.

Project Suncatcher를 에너지 프로젝트로만 설명하면 이야기의 절반을 놓치게 된다. 태양광의 가용성은 기회를 만들지만, 분산된 프로세서들이 유용한 공동 작업을 수행할 수 있는지는 네트워킹에 달려 있다.

궁극적으로 어떤 워크로드를 처리할지도 중요하다. 궤도 환경은 간헐적 작동과 지구와의 제한적인 통신을 견딜 수 있는 작업에 유리하다.

훈련 작업, 과학 처리, 일부 형태의 배치 추론은 대화형 애플리케이션보다 이 조건에 더 잘 맞을 수 있다. 사용자 대상 서비스에는 예측 가능한 지연 시간, 지속적인 가용성, 안정적인 지상 연결이 필요하다.

Google은 상용 서비스, 고객 워크로드, 배치 일정에 관해 발표한 바 없다. Project Suncatcher는 미래 시스템에 필요한 구성 요소를 연구하는 단계에 머물러 있다.

이러한 신중한 설명은 MVP를 궤도 데이터센터라고 부르는 것보다 덜 극적이다. 하지만 더 정확하다.

SpaceX와 스타트업, 시험을 경쟁 신호로 전환하다

Google의 초기 비행은 발사 접근성, 열 설계, 운용 데이터가 좌우하는 경쟁에 맞춤형 AI 하드웨어를 투입한다.

여러 기업은 이미 발표용 슬라이드 단계를 넘어섰다. Associated Press가 요약한 보도에 따르면 Starcloud는 2025년 11월 Nvidia AI 프로세서를 탑재한 위성을 발사했다.

Aetherflux 역시 컴퓨팅 하드웨어를 궤도로 보내려는 계획을 설명했다. 많은 잠재 경쟁사가 필요로 하는 로켓을 통제하는 SpaceX는 궤도 AI 인프라를 홍보해 왔다.

이는 Google에 이례적인 경쟁 구도를 만든다. SpaceX는 프로젝트를 가능하게 하는 공급업체인 동시에 잠재적 인프라 경쟁자이기도 하다.

10월 임무는 이 관계를 보여준다. Google은 SpaceX 자체의 궤도 컴퓨팅 사업 구상과 결국 경쟁할 수 있는 아키텍처를 시험하기 위해 Falcon 9 라이드셰어를 활용한다.

발사 통제는 단순한 운송 이상의 의미를 지닌다. 잦은 발사는 운영자가 새로운 하드웨어를 시험하고, 고장 난 위성을 교체하며, 설계를 더 빠르게 수정할 수 있게 한다.

궤도 데이터센터는 기술자가 손상된 프로세서를 교체할 수 없다. 고장 난 구성 요소는 사용하지 않은 채 남거나, 중복 하드웨어로 대체되거나, 다음 발사를 기다려야 한다.

따라서 궤도 경쟁은 컴퓨팅 전문성과 우주선 제조 역량, 저렴한 궤도 접근성을 결합하는 기업에 유리하다.

Google도 자체적으로 중요한 자산을 보유하고 있다. TPU를 설계하고, 대규모 AI 클러스터를 운영하며, Gemini 모델을 구축하고, 분산 컴퓨팅을 연구한다.

Planet은 비행 검증을 거친 위성 엔지니어링과 사용 가능한 우주선 플랫폼을 제공한다. SpaceX는 발사체와 라이드셰어 임무를 공급한다.

이러한 협력 구조는 Google이 임무의 모든 부분을 수직 통합하지 않고도 빠르게 학습할 수 있게 한다. 동시에 초기 궤도 컴퓨팅이 파트너십에 얼마나 의존하는지도 드러낸다.

경쟁의 핵심은 단순히 TPU가 우주에서 Nvidia GPU보다 성능이 뛰어난지 여부가 아니다. 아직 공개된 어떤 궤도 시험도 지상 AI 캠퍼스의 규모, 냉각 부하, 네트워크 수요를 대표하지 못한다.

각 실험은 서로 다른 계층을 강조한다. 일부는 프로세서의 생존성을 시험하고, 다른 일부는 엣지 추론, 지구 관측 처리, 통신 또는 발전에 초점을 맞춘다.

Google의 차별화된 베팅은 조밀하게 연결된 TPU 별자리다. 성공한다면 이 시스템은 다수의 태양광 구동 노드에 걸쳐 머신러닝 작업을 분산하게 된다.

SpaceX는 발사 주기와 우주선 생산에서 우위를 갖는다. Nvidia 기반 스타트업은 널리 쓰이는 소프트웨어 생태계를 활용할 수 있다. Google은 시험하려는 프로세서와 모델 스택을 통제한다.

이러한 강점이 경제성을 결정하지는 않는다. 기업은 프로세서와 함께 태양광 패널, 라디에이터, 통신 하드웨어, 차폐재, 구조물, 교체 용량까지 발사해야 한다.

10월 시험은 이처럼 완전한 시스템들을 비교하지 않는다. 대신 기존 우주선과 공동 발사를 활용해 Google이 학습 주기를 단축할 수 있는지를 보여줄 것이다.

그 속도는 중요하다. 궤도 인프라는 반복적인 물리적 임무를 통해 발전하기 때문이다. 소프트웨어는 배치 후 빠르게 바뀔 수 있지만, 라디에이터, 차폐재, 태양광 어레이는 그렇지 않다.

MVP 비행이 성공하면 Google은 궤도에서의 TPU 동작에 관한 독점 정보를 얻게 된다. 경쟁사들은 공개 결과는 알 수 있지만, 완전한 원격측정 데이터나 엔지니어링 분석까지 확보할 수는 없다.

실패 역시 유익한 정보가 될 수 있다. 지상용 가속기가 실험실 방사선 결과가 시사한 것보다 더 많은 개조를 필요로 한다는 점을 드러낼 수 있다.

따라서 Google Project Suncatcher 발사는 기존 항공우주 기업과 궤도 컴퓨팅 스타트업 모두에 압박을 가한다. 이는 Google이 선호하는 아키텍처가 완성되기 전에도 하드웨어를 비행시킬 의지가 있음을 보여준다.

그럼에도 이 임무가 승자를 결정하지는 않는다. 이 경쟁은 유용한 궤도 컴퓨팅을 각기 다르게 정의하며 진행되는 소규모 실험들의 집합으로 남아 있다.

냉각과 신뢰성은 여전히 가장 어려운 시험이다

핵심적인 모순은 간단하다. 궤도는 풍부한 햇빛을 제공하지만, 컴퓨팅에 사용된 모든 와트는 결국 폐열이 된다.

우주는 매우 차가울 수 있지만, 진공 상태에서는 일반적인 대류로 열을 이동시킬 수 없다. 우주선은 프로세서의 열을 라디에이터로 전달해야 하며, 라디에이터는 적외선 복사로 에너지를 방출한다.

MVP는 열 인터페이스 소재, 금속 히트파이프, 라디에이터를 사용한다. 인터페이스는 TPU에서 파이프 쪽으로 열을 전달하고, 파이프는 이를 노출된 복사 표면으로 옮긴다.

Google은 이 시스템이 한 번에 약 15분간 Gemini 처리를 지원할 것으로 예상한다. 이후 프로세서는 라디에이터가 열을 따라잡는 동안 멈춰야 한다.

이러한 듀티 사이클은 실험에는 적합하다. 실제 서비스라면 훨씬 더 일관된 처리량이나 반복되는 열 휴지 시간을 중심으로 설계된 스케줄링 시스템이 필요하다.

미국 회계감사원은 전력과 냉각을 궤도 데이터센터의 주요 장벽으로 지목한다. 기술 평가에 따르면 대규모 배치에는 2026년 4월까지 우주에서 조립된 어떤 시스템보다 큰 태양광 어레이가 필요할 것이다.

이 기관의 예시 설계는 10,000제곱피트 태양광 어레이와 최대 5,000제곱피트의 라디에이터를 결합한다. 그 정도 시스템도 수백 킬로와트만 공급할 수 있다.

대규모 지상 데이터센터는 약 100메가와트를 소비할 수 있다. 이 용량을 재현하려면 다수의 궤도 유닛, 광범위한 발사 활동, 그리고 이를 조율할 수 있는 네트워크가 필요하다.

냉각만이 신뢰성 문제는 아니다. 방사선은 계산을 손상시키거나 시간이 지나면서 구성 요소를 열화시킬 수 있다.

Google의 양성자 빔 시험은 유용한 증거를 제공하지만, 고대역폭 메모리는 TPU 패키지에서 가장 민감한 부분이었다. AI 모델은 저장장치와 프로세서 사이에서 대량의 데이터를 지속적으로 이동시키므로 메모리는 필수적이다.

시스템은 영구적인 칩 고장 없이도 살아남을 수 있지만, 여전히 허용하기 어려운 오류율을 낼 수 있다. Google은 방사선이 조용한 오류, 중단된 워크로드 또는 증가하는 오류 수정 오버헤드를 유발하는지 판단해야 한다.

발사 진동은 또 다른 고장 지점을 만든다. 전기 연결부, 히트파이프, 광학 구성 요소, 메모리 패키지는 모두 강한 힘을 겪은 뒤에도 정렬 상태를 유지해야 한다.

그다음은 궤도 유지보수다. 지상 운영자는 고장 난 서버를 교체하고, 펌프를 수리하며, 장비를 청소하고, 새 가속기를 추가할 수 있다.

궤도 클러스터는 중복성, 로봇 정비 또는 예정된 교체 발사에 의존해야 한다. 각 선택지는 질량과 운용 복잡성을 더한다.

우주 파편은 더 광범위한 공공 위험을 만든다. Google의 미래 아키텍처는 다른 우주선들이 저지구 궤도를 지나는 동안 다수의 위성을 촘촘한 편대에 배치한다.

편대 비행 위험에 대한 분석은 대형 어레이와 밀집 클러스터가 충돌 관리를 복잡하게 만들 수 있다고 지적한다. 손상된 위성은 관련 없는 다른 우주선을 위협하는 파편을 만들 수도 있다.

대규모 컴퓨팅 별자리가 빛을 반사하거나 관측을 방해한다면 천문학자들은 별도의 이의를 제기할 수 있다. 규제기관은 궤도 위치, 기동성, 폐기 계획, 무선 주파수 사용에 관한 정보를 필요로 할 것이다.

10월 임무는 이 질문들에 답하기에는 너무 작다. 소형 위성 한 기로는 81개 노드 클러스터의 파편 영향이나 조율 수요를 재현할 수 없다.

또한 Google의 가장 낙관적인 경제성 가정도 검증할 수 없다. 이 프로젝트는 더 낮은 발사 비용, 허용 가능한 하드웨어 수명, 별자리 전반의 높은 활용도에 의존한다.

활용도가 낮은 프로세서도 계속 질량을 차지하고, 에너지를 소비하며, 냉각을 필요로 한다. 성공적인 아키텍처에는 값비싼 궤도 하드웨어의 생산성을 유지할 수 있을 만큼 적합한 워크로드가 충분해야 한다.

이것이 본질적인 상충 관계다. 우주는 여러 지상 제약을 제거하는 대신 열 관리, 유지보수, 네트워킹, 발사라는 제약으로 대체한다.

Google Project Suncatcher 발사는 이 상충 관계의 한 부분을 측정 가능하게 해야 한다. 하지만 그 상충 관계 자체를 없애지는 못한다.

Suncatcher의 확장 가능성을 보여줄 세 가지 신호

다음 이정표는 단순히 또 한 번의 성공적인 발사가 아니라, 지속 운용, 분산 컴퓨팅, 신뢰할 만한 확장 경로를 입증해야 한다.

첫 번째 신호는 10월 1일 이후 MVP의 운용 기록이다. Google은 네 개 TPU가 모두 정상적으로 시작되는지, 얼마나 자주 실행되는지, 그리고 그 결과가 동등한 지상 워크로드와 일치하는지를 공개해야 한다.

열 데이터는 프로세서 생존성만큼 중요하다. 더 길거나 더 빈번한 세션은 히트파이프와 라디에이터 설계가 예상에 가깝게 작동한다는 점을 시사할 것이다.

예상치 못한 종료가 프로젝트를 끝내지는 않겠지만, 진행을 제한하는 구성 요소를 밝혀낼 것이다. 방사선 오류, 불안정한 전력, 과도한 열, 손상된 연결부는 서로 다른 해결책을 필요로 한다.

독자들은 Google이 얼마나 많은 정보를 공개하는지도 지켜봐야 한다. 위성이 정상이라는 발표는 워크로드 결과, 온도, 오류율, 비행 전 모델과의 비교보다 증거 가치가 낮다.

두 번째 신호는 2027년에 계획된 2위성 임무다. 이 실험은 독립적으로 움직이는 우주선 간 광학 링크를 입증해야 한다.

대역폭만으로는 충분하지 않다. Google은 시스템이 링크를 획득하고, 정밀한 지향을 유지하며, 중단에서 복구하고, 유용한 분산 작업을 조율할 수 있음을 보여야 한다.

회사의 실험실 트랜시버는 양방향 각각 초당 800기가비트에 도달했다. 위성 간 높은 처리량을 재현한다면 Suncatcher의 핵심 네트워킹 메커니즘을 뒷받침하게 된다.

안정적인 링크를 유지하지 못한다면 조밀한 별자리 설계는 약화될 것이다. Google은 서로 다른 간격, 더 큰 광학 시스템, 더 많은 온보드 버퍼링 또는 통신 집약도가 낮은 워크로드를 필요로 할 수 있다.

세 번째 신호는 프로토타입을 넘어설 경로에 관한 증거다. 여기에는 정의된 워크로드, 신뢰할 만한 열 아키텍처, 교체 전략, 규제 계획이 포함된다.

Google 우주 데이터센터가 즉시 지상 캠퍼스와 같아질 필요는 없다. 다만 추가된 복잡성을 정당화할 만큼 궤도에서 더 잘 수행되는 작업을 제공해야 한다.

배치 AI 작업은 일정 지연을 견딜 수 있으므로 초기 후보가 될 수 있다. 이미 우주에서 생성된 데이터를 처리하면 원시 정보를 지구로 전송해야 하는 필요성을 줄일 수 있다.

대화형 소비자 애플리케이션은 더 어려운 목표다. 이들은 안정적인 용량, 낮은 지연 시간, 궤도 하드웨어와 지상 네트워크 간의 신뢰할 수 있는 링크를 요구한다.

Google은 고장 난 우주선을 어떻게 퇴역시키고 충돌 위험을 통제할지도 설명해야 한다. 폐기 계획 없이 확장한다면 데이터센터 인프라의 압박을 이미 혼잡한 궤도 환경으로 옮기게 된다.

향후 1년간 가장 신뢰할 만한 결과는 상업용 별자리가 아니다. 미지수 목록을 좁히는 일련의 공개 측정 결과다.

그런 관점에서 이 임무를 지켜봐야 한다. TPU가 정확한 결과를 내는지, 냉각 시스템이 실질적인 운용 주기를 지원하는지, 2027년 위성들이 실제 워크로드를 주고받는지를 물어야 한다.

Google이 이러한 답을 제시한다면 Project Suncatcher는 야심 찬 연구 제안에서 엔지니어링 프로그램으로 나아가게 될 것이다. 반대로 발사 이미지와 포괄적인 주장만 내놓는다면, 핵심 근거는 여전히 입증되지 않은 채로 남을 것이다.

10월 1일 비행은 Google이 전망을 증거로 바꿀 수 있는 더 이른 기회다. 이것이 Google Project Suncatcher 발사의 진정한 의미이며, 그 진전을 평가해야 할 기준이다.