Google 우주 데이터 센터, 궤도 진입 성공했지만 확장하려면 Starship 발사 1,800회 필요

Google의 우주 데이터 센터는 10월 1일, 회사가 AI 칩 4개를 궤도로 보냈을 때 연구 논문 단계를 넘어섰다. 그러나 이 실험은 훨씬 더 큰 충돌 지점도 드러냈다. Google의 경제성 모델은 SpaceX가 10년 안에 Starship을 약 1,800회 운항할 수 있다는 가정에 기반한다.

이는 모든 임무가 200톤의 화물을 실을 경우 연간 약 180회 발사에 해당한다. Starship은 Google 위성이 발사되기 며칠 전에야 처음으로 지구 궤도에 도달했다. 따라서 Google이 예상한 경제성이 성립하려면 SpaceX는 개발 중인 로켓을 산업 규모의 운송 네트워크로 전환해야 한다.

소형 위성은 이 문제에 대한 답을 내리지 못한다. 이 임무는 Google의 Tensor Processing Units, 즉 TPUs가 방사선, 발사 진동, 극심한 온도 변화에서 견딜 수 있는지를 시험한다. 또한 지상 데이터 센터 내부에서 사용할 수 있는 공기 기반 냉각 없이도 이 칩들이 작동할 수 있는지 살핀다.

Google은 이 광범위한 계획을 Project Suncatcher라고 부른다. 제안된 시스템은 태양광으로 구동되는 컴퓨팅 위성을 저지구 궤도에 배치하고 광 링크로 연결한다. 풍부한 태양 에너지가 매력적이지만, 실질적인 장벽으로는 발사 비용, 열 방출, 통신, 유지보수, 궤도 조정 등이 있다.

SpaceX는 이 계획에서 필수적인 공급업체인 동시에 가장 해결하기 어려운 의존 대상이다. Google은 칩, 소프트웨어, 위성 설계를 내부적으로 개선할 수 있다. 하지만 발사 제공업체가 전례 없는 규모의 재사용을 달성하지 않는 한, 저렴한 궤도 운송 수단을 만들 수는 없다.

Google 우주 데이터 센터의 출발점은 궤도 클라우드가 아닌 칩 4개

Google이 발사한 것은 지상 데이터 센터를 대체할 작동 중인 시설이 아니라 하드웨어 실험이다.

MVP로 불리는 첫 번째 Project Suncatcher 우주선은 SpaceX의 Transporter-18 라이드셰어 임무를 통해 캘리포니아에서 발사됐다. 궤도 임무 개요에 따르면 Falcon 9은 다른 129개 탑재체와 함께 이를 실어 날랐다.

이 위성은 지구 관측 기업 Planet과의 협력을 통해 제작됐다. Google은 TPUs 4개를 포함한 컴퓨팅 하드웨어를 제공했다. TPU는 머신러닝 학습과 추론을 위한 Google의 맞춤형 가속기다.

냉장고 크기의 이 우주선은 태양광 패널에서 약 1킬로와트를 공급받는다. 이는 상업용 AI 시설이 요구하는 전력과 비교하면 매우 작은 수준이다. 대규모 지상 시스템은 광범위한 네트워킹, 스토리지, 냉각, 전력 장비의 지원을 받는 수천 개의 가속기를 사용한다.

MVP는 하드웨어가 궤도에서 어떻게 작동하는지 시험하기 위해 Gemini 워크로드를 실행할 예정이다. 보도에 따르면 이 위성은 프로세서가 축적한 열을 방출하기 위해 멈추기 전 약 15분간 작동할 수 있다. 이런 운용 방식은 이를 지속적으로 사용할 수 있는 컴퓨팅 서비스가 아니라 과학 장비에 가깝게 만든다.

이 임무는 Google의 기존 일정을 앞당겼다. 회사는 이전에 2027년 초를 목표로 Planet과 함께 위성 2기를 활용한 학습 임무를 설명한 바 있다. 기존 Planet 우주선에 칩을 통합함으로써 Google은 더 이른 시점에 궤도 데이터를 수집할 수 있게 됐다.

Google은 위성이 발사 과정의 물리적 스트레스와 우주 환경의 열 및 방사선 조건을 평가할 것이라고 밝혔다. 이러한 측정은 지상 시뮬레이션만으로는 완전히 재현할 수 없는 증거를 엔지니어들에게 제공해야 한다.

이 구분은 중요하다. “우주 데이터 센터”라는 표현은 고객 워크로드를 운영하는 성숙한 시설을 연상시킬 수 있기 때문이다. MVP는 소형 실험실에 더 가깝다. Google이 더 큰 위성 아키텍처에 투자하기 전에 고장 양상을 파악하는 것이 이 위성의 역할이다.

그럼에도 이번 발사는 Project Suncatcher의 위상을 바꾼다. 이 프로젝트는 이제 시뮬레이션에만 의존하는 대신 실제 궤도 환경에 노출된 하드웨어를 보유하게 됐다. 이 증거는 가정을 확인하거나 예상치 못한 결함을 드러내거나, Google이 시스템을 재설계하도록 만들 수 있다.

이번 시험은 SpaceX에 중요한 시점에 이뤄지기도 했다. Starship은 9월 28일 처음으로 지구 궤도에 도달한 뒤 Starlink 위성 26기를 배치했다. 상단 단계는 엔진 하나를 잃고 계획보다 일찍 귀환했지만, 이 임무는 필수적인 역량을 입증했다.

Google의 위성은 Starship에 실려 발사되지 않았다. 임무는 Falcon 9이 수행했다. 하지만 Falcon 9에는 완전한 궤도 컴퓨팅 네트워크에 필요할 것으로 Google이 예상하는 탑재체 경제성과 부피가 부족하다.

그렇기에 이 소규모 실험은 즉시 훨씬 더 큰 인프라 문제를 가리킨다. 칩 4개는 라이드셰어 임무에 함께 실을 수 있다. 고밀도 컴퓨팅 시스템을 탑재한 수천 기의 위성에는 근본적으로 다른 발사 체계가 필요하다.

Project Suncatcher가 Starship 경제성을 필요로 하는 이유

Project Suncatcher는 반복 운항, 재사용, 그리고 막대한 누적 탑재체 물량을 통해 발사 가격이 하락하는 데 의존한다.

Google의 연구는 저지구 궤도 운송 비용이 2030년대 중반까지 킬로그램당 200달러 수준에 근접할 수 있다고 추정한다. 이 추정치는 SpaceX의 과거 발사 가격과 누적 탑재체 질량을 기반으로 한 학습 곡선에서 나온다.

학습 곡선은 제조 경험과 단위 비용 하락을 연결한다. Google 연구진은 SpaceX의 누적 발사 질량이 두 배가 될 때마다 킬로그램당 가격이 약 20% 감소했다고 추정한다.

이 패턴을 Starship까지 연장하면 프로젝트에서 가장 놀라운 수치가 나온다. SpaceX는 가정된 궤적을 유지하려면 약 37만 톤의 추가 화물을 궤도에 운반해야 한다.

임무당 200톤을 기준으로 하면 이는 약 1,800회의 Starship 발사에 해당한다. 10년에 걸쳐 평균을 내면 연간 약 180회 임무가 필요하다. 초기 몇 년은 이 평균에 못 미칠 가능성이 높으므로, 이후 운항은 더 빠른 속도로 진행돼야 한다.

이 수치는 Google의 궤도 컴퓨팅 논문에서 나왔다. 연구진은 자신들의 연구가 완전한 경제성 타당성 조사는 아니라고 강조한다. 대신 이 계산은 발사 가격이 사업성 판단을 지배하지 않게 되려면 무엇이 일어나야 하는지를 보여준다.

킬로그램당 200달러라는 기준은 Google이 궤도 운송 비용을 지상 데이터 센터의 반복적인 에너지 비용과 비교하기 때문에 중요하다. 이 발사 가격이라면 효율적인 위성의 수명 조정 운송 비용은 지상 전력 비용의 대략적인 범위에 들어갈 수 있다.

이 비교에는 한계가 있다. 실제 서비스의 경쟁력을 결정하는 여러 비용이 제외돼 있기 때문이다. 위성은 설계, 제조, 보험 가입, 운영, 연결, 중복성을 통한 수리, 그리고 최종 교체가 필요하다.

이 논문은 과거의 가격 개선이 발사체 설계의 큰 변화에도 이어질 수 있다고 가정한다. Falcon 9과 Starship은 동일한 생산 시스템, 운용 패턴, 위험 프로필을 공유하지 않는다. 이전 로켓에서 도출한 추세가 Starship의 미래 성능을 보장할 수는 없다.

Google의 분석도 이러한 불확실성을 인정한다. 추정치는 높은 재사용률, 누적 물량, 기술적 실행, 시장 경쟁, 규제 조건에 달려 있다고 설명한다. 따라서 가격 전망은 제시된 상업적 견적이 아니라 조건부 결과다.

회사는 더 낮은 물량의 경로도 검토한다. 탑재체 증가가 중심 추정치보다 약 70% 부족하더라도 발사 가격은 킬로그램당 약 300달러에 도달할 수 있다. 이 결과는 전체 1,800회 발사 시나리오를 충족하지 못하더라도 궤도 경제성을 개선할 수 있다.

하지만 발사 가격 하락만으로 수요가 생기지는 않는다. SpaceX는 반복되는 Starship 임무를 채울 만큼 충분한 탑재체를 보유한 고객이 필요하다. 궤도 컴퓨팅은 그러한 고객 중 하나가 될 수 있지만, 먼저 저렴한 발사가 컴퓨팅 시스템의 실현 가능성을 만들어야 한다.

이는 순환적 의존성을 만든다. 우주 데이터 센터는 확장하기 위해 저렴한 발사 능력이 필요하다. Starship은 예상된 비용 곡선을 따라 하락하기 위해 막대한 발사 수요가 필요하다.

Google은 단순히 더 저렴한 로켓을 기다리는 것이 아니다. Project Suncatcher 자체가 그 로켓을 더 저렴하게 만드는 데 필요한 질량의 일부를 제공할 수 있다. 이 가능성은 Google과 SpaceX를 일반적인 공급업체 계약이 아니라 상호 의존적인 관계에 놓는다.

따라서 발사 횟수는 단순히 눈길을 끄는 통계가 아니다. 칩 4개짜리 실험을 미래 궤도 네트워크의 경제성과 연결하는 메커니즘이다.

Google과 발사 빈도의 현실

핵심 상대는 다른 클라우드 제공업체가 아니다. SpaceX의 발사 야심과 연간 180회라는 실제 운용 빈도 사이의 격차다.

Starship의 첫 궤도 비행은 중요한 이정표였지만, 한 번 궤도에 도달하는 것과 연간 수백 회를 운용하는 것은 다르다. SpaceX는 발사를 안전하게 반복하고, 발사체의 두 단계를 모두 재사용하며, 정비 작업을 줄이고, 여러 발사장을 유지해야 한다.

9월 임무는 그 격차를 보여줬다. Starship은 탑재체 배치에는 성공했지만 상단 단계 엔진 하나가 작동을 멈췄다. SpaceX는 계획된 비행을 단축해 약 3시간 뒤 발사체를 귀환시켰다.

개발 비행은 문제를 드러내도록 설계된다. 엔진 문제 하나가 발사체나 Google의 연구를 무효화하는 것은 아니다. 다만 탑재 능력만으로 신뢰할 수 있는 운항 빈도를 추론할 수 없는 이유를 보여준다.

연간 180회 운항하는 시스템은 평균적으로 이틀에 한 번꼴로 발사해야 한다. 이 평균에는 점검, 탑재체 통합, 기상 지연, 규제 승인, 발사대 정비, 이상 상황 대응에 필요한 시간도 포함돼야 한다.

이 수치는 모든 비행이 200톤을 운반할 수 있다는 가정에도 기반한다. 실제 탑재량은 발사체 구성, 궤도, 회수 계획, 임무 요구 사항에 따라 달라진다. 평균 탑재량이 낮아지면 같은 누적 질량을 운반하기 위해 더 많은 발사가 필요하다.

SpaceX는 장기적으로 훨씬 높은 비행 횟수를 설명해 왔다. Elon Musk는 궁극적으로 Starship을 연간 수천 회 운항하는 방안을 언급한 바 있다. 이러한 발언은 회사의 야심을 보여주지만, 운용 체계가 이미 존재한다는 증거를 제공하지는 않는다.

최근의 진전은 Starship이 상업용 발사체가 될 수 있다는 근거를 강화한다. 궤도 임무는 Starlink V3 위성 26기를 배치했고, 부스터는 해안 인근에서 모의 착륙을 완료했다. SpaceX는 일회용 하드웨어가 아닌 빠른 재사용을 중심으로 발사체를 개발하고 있다.

Starlink는 SpaceX에 내부 수요원을 제공한다. 회사는 Starship 운항을 다듬는 동안 자체 통신 위성을 발사할 수 있다. 이러한 수직 통합은 Falcon 9이 비행 경험을 축적하는 데 도움이 됐으며, Starship의 초기 운항 빈도도 뒷받침할 수 있다.

궤도 데이터 센터는 다른 요구를 제기한다. 컴퓨팅 위성은 열 관리 하드웨어, 대형 태양광 배열, 광통신 장비, 고가의 프로세서를 탑재한다. 광대역 위성군에 단순히 합류하는 것이 아니라 정밀한 궤도 편대에 도달해야 한다.

Google은 SpaceX 투자자이기도 하며, 이는 일부 이해관계를 일치시킨다. 하지만 투자만으로 기술적 의존성이 사라지지는 않는다. Google의 일정은 설계하지도 통제하지도 않는 운송 시스템에 계속 묶여 있다.

다른 발사 제공업체가 장기적으로 이러한 노출을 줄일 수는 있다. Blue Origin, Rocket Lab, 그리고 미래의 대형 발사 경쟁업체는 가격을 낮출 수 있다. 그러나 현재 Starship이 목표로 하는 탑재량과 완전 재사용의 조합에 맞먹는 검증된 대체 수단은 없다.

Falcon 9은 시제품용으로는 여전히 신뢰할 만하지만, Google의 모델은 대규모 배치에 적합하지 않은 물량 한계를 지적한다. 이는 어색한 전환을 만든다. 기존 로켓은 이 아이디어를 시험할 수 있지만, 아직 완성되지 않은 로켓이 이를 경제적으로 성립시켜야 한다.

소스 헤드라인과 URL에서는 1,800회 발사 추정치가 처음에 1,600회로 잘못 표기됐다. 이후 공개된 정정은 논문에 근거한 수치가 1,800회임을 확인했다.

이 정정은 과제의 규모를 더욱 분명히 한다는 점에서 중요하다. 추가된 200회 발사는 요구되는 평균 발사 빈도로 계산하면 1년이 넘는 기간에 해당한다.

결정적인 증거는 전망이 아니라 운영에서 나올 것이다. SpaceX는 더 짧은 회전 시간, 반복적인 기체 재사용, 신뢰할 수 있는 페이로드 운송, 확장되는 발사장 수용 능력을 보여야 한다. 그때까지 Google의 비용 곡선은 기술적으로 근거 있는 시나리오에 머문다.

81기 AI 위성 클러스터는 하나의 컴퓨터처럼 작동해야 한다

저렴한 운송은 첫 번째 문제만 해결한다. 분산형 AI에는 정밀한 편대비행과 데이터센터급 통신도 필요하기 때문이다.

Google이 제안한 아키텍처는 81기 위성으로 구성된 그룹을 사용한다. 한 예시 클러스터는 평균 약 650킬로미터 고도에서 궤도를 돌며 반경 1킬로미터 안에 배치된다.

위성들은 인접한 파트너 위성과 약 100~200미터의 간격을 유지한다. 모든 우주선이 궤도 속도로 지구 주위를 비행하는 동안에도 이 배치는 안정적으로 유지돼야 한다.

머신러닝 워크로드는 가속기 간 빈번한 데이터 교환을 수반한다. 대규모 모델을 학습하려면 프로세서들이 낮은 지연 시간으로 데이터와 중간 결과를 동기화해야 한다. 느리거나 일관되지 않은 연결은 값비싼 칩이 정보를 기다리며 놀게 만들 수 있다.

지상 데이터센터는 광섬유와 특수 스위치로 이를 해결한다. Project Suncatcher는 고정된 연결 대신 정밀하게 조준한 레이저 빔으로 데이터를 전송하는 자유공간 광통신 링크를 사용한다.

Google은 짧은 실험실 경로에서 단방향 초당 800기가비트를 시연했다. 양방향 용량은 초당 1.6테라비트에 도달했다. 이 시험은 통신 개념의 기반을 뒷받침하지만, 움직이는 전체 궤도 편대를 재현한 것은 아니다.

실제 위성군은 위성들의 위치가 변하는 동안 여러 빔을 정확하게 조준해야 한다. 시스템은 진동, 온도 변화, 부품 열화, 우주 파편 회피, 클러스터 내부의 고장까지 처리해야 한다.

Google은 궤도 운동을 예측하고 편대를 제어하는 데 머신러닝 모델을 활용할 것을 제안한다. 이 접근법은 인접 위성들이 통신 범위 안에 머물도록 도울 수 있다. 동시에 이미 복잡한 물리 시스템에 소프트웨어 보증 요건을 추가한다.

지상 연결성도 또 다른 제약이다. 위성 간 대역폭이 있다고 해서 지구와 궤도 사이에서 입력과 출력을 옮길 필요가 사라지는 것은 아니다. 대기 난류, 구름, 빔 추적, 지상국 가용성은 광통신을 제한할 수 있다.

일부 워크로드는 다른 것보다 이 아키텍처에 더 잘 맞는다. 이미 궤도에서 수집된 데이터를 처리하면 지구로 전송해야 하는 데이터양을 줄일 수 있다. 원시 정보가 프로세서 가까이에서 생성되기 때문에 위성 영상 분석은 명백한 사례다.

대규모 지상 학습 작업은 더 어려운 경우를 만든다. 이들의 데이터셋은 지상 기반 스토리지 시스템에서 생성될 수 있다. 해당 자료를 업로드하고, 수천 개 프로세서를 조율하며, 출력을 회수하는 과정은 풍부한 태양 에너지의 일부 이점을 상쇄할 수 있다.

추론 워크로드는 더 관대할 수 있다. 추론은 학습된 모델을 실행해 답변, 분류 또는 예측을 생성하는 것을 뜻한다. 이런 작업은 장기간의 학습 실행보다 규모가 작고 동기화 집약도가 낮을 수 있다.

Google의 방사선 시험은 이 구분을 뒷받침한다. 연구진은 Trillium TPU가 영구 고장 없이 5년 임무에 해당하는 이온화 방사선량을 견뎠다고 말한다. 그러나 고에너지 입자는 여전히 일시적인 연산 오류를 일으킬 수 있다.

한 연구원은 TechCrunch에 일반적인 추론에서는 약 100만 회 연산당 한 번의 오류가 발생할 수 있다고 말했다. 같은 오류율도 수천 개 칩이 수개월간 지속되는 학습 작업을 조율할 때는 더 우려스럽다.

소프트웨어는 일부 잘못된 계산을 감지하고 반복할 수 있다. 이중화 프로세서는 고장 난 용량을 대체할 수도 있다. 두 대응 모두 에너지, 하드웨어 또는 시간을 소비해 경제성을 약화시킨다.

따라서 제안된 클러스터는 단순히 지구 상공에 설치된 서버 랙이 아니다. 네트워크, 전력 공급, 냉각 시스템, 물리적 배치가 계속 움직이는 분산형 슈퍼컴퓨터다.

이러한 시스템 수준에서 설명하면 Project Suncatcher는 기존 클라우드 리전을 이전하는 일과는 거리가 멀다. 궤도역학의 제약을 중심으로 새로운 컴퓨팅 플랫폼을 설계하는 일에 가깝다.

냉각과 정비가 사업성을 무너뜨릴 수 있다

우주는 햇빛을 제공하지만 공기, 물, 정비 인력을 제공하지 않기 때문에 가장 어려운 위험은 열 제거와 유지보수에 남아 있다.

태양 에너지는 Project Suncatcher의 가장 큰 매력이다. Google은 적절한 저지구궤도의 위성이 지구상 비슷한 위치의 패널보다 최대 8배 많은 태양 에너지를 받을 수 있다고 말한다.

햇빛에 접근하면 일부 지상 전력망 제약을 피할 수 있다. 새로운 지상 데이터센터는 송전망 업그레이드, 발전 계약, 허가, 지역 승인까지 수년간 기다릴 수 있다. 궤도 시스템은 프로세서 바로 옆에서 전기를 직접 생산하게 된다.

그러나 칩으로 들어간 전력은 결국 열이 된다. 지상 시설은 공기, 물, 냉매, 펌프, 냉각탑, 열교환기로 이 열을 이동시킨다. 진공에는 열을 운반해 줄 공기가 없다.

우주선은 대신 프로세서의 열을 방열판으로 전도해야 한다. 이 표면은 적외선 복사로 에너지를 방출한다. 필요한 면적은 발생하는 열의 양과 하드웨어가 견딜 수 있는 온도에 따라 커진다.

Google의 MVP는 이 한계를 부각한다. 4개의 칩은 시스템이 냉각을 위해 멈추기 전까지 짧은 시간만 작동할 수 있다. 15분 실험에서 연속적인 상업 운영으로 확장하려면 훨씬 더 크거나 효율적인 열 관리 하드웨어가 필요하다.

방열판은 질량과 표면적을 늘린다. 질량 증가는 발사 요구량을 높이고, 더 큰 구조물은 전개와 충돌 회피를 복잡하게 만든다. 엔지니어가 방사선 방어를 위해 차폐를 사용할 때도 같은 불이익이 발생한다.

독립적인 열 관리 평가는 여러 궤도 컴퓨팅 제안에서 이 절충을 지적한다. 기존 AI 가속기는 필요한 성능을 제공하지만, 방사선 내성을 갖춘 우주선 부품으로 설계된 것은 아니다.

칩을 차폐하면 무게가 늘어난다. 노출된 상태로 두면 오류와 고장 가능성이 커진다. 이중화 하드웨어는 신뢰성을 높이지만, 예비 프로세서를 궤도로 보내면 다시 질량, 전력, 냉각 요구량이 증가한다.

정비도 마찬가지로 가혹하다. 기술자들은 지상 시설에서 고장 난 드라이브, 네트워킹 장비, 전원 공급 장치, 가속기 보드를 일상적으로 교체한다. 궤도 클러스터는 일상적인 인력 정비 방문에 의존할 수 없다.

Google의 논문은 가장 단순한 대응으로 이중화 프로비저닝을 제안한다. 이는 시스템이 처음에 필요한 것보다 더 많은 용량을 발사한 뒤, 고장을 우회해 운영한다는 의미다.

이중화는 서비스를 계속 운영하게 하지만 활용률을 바꾼다. 예비 하드웨어에도 제조와 발사 비용이 든다. 일부 부품은 다른 부품이 고장 날 때까지 유휴 상태로 남을 수 있다.

위성 수명도 또 다른 제약을 만든다. Google은 5년 동안의 방사선 노출을 평가한다. 지상 시설은 프로세서를 단계적으로 교체할 수 있지만, 위성은 컴퓨팅, 전력, 냉각, 통신을 수명이 제한된 하나의 자산에 담을 수 있다.

빠른 AI 하드웨어 주기는 이 모델을 복잡하게 만든다. 현재 프로세서를 탑재해 발사한 위성은 방사선이 임무를 끝내기 훨씬 전에 더 새로운 지상 칩보다 효율이 떨어질 수 있다. 이를 교체하려면 서버 교체가 아니라 또 한 번의 발사가 필요하다.

노후 장비의 궤도 이탈도 시스템 설계의 일부여야 한다. 81기 위성 클러스터는 고장 난 장치가 안전하게 궤도를 떠날 수 있을 때에만 관리 가능하다. 대규모 배치는 충돌과 파편 우려를 증폭시킨다.

이 문제들이 궤도 컴퓨팅이 불가능하다는 것을 증명하는 것은 아니다. 다만 한 번의 성공적인 칩 시험으로 상업 서비스를 검증할 수 없는 이유를 보여준다. Google은 시간 경과에 따른 오류율, 지속 열 성능, 전력 가용성, 부품 열화를 측정해야 한다.

MVP 임무가 가치 있는 이유는 실패도 유용한 정보를 제공하기 때문이다. 지금 발견되는 온도 한계나 방사선 패턴은 전체 클러스터를 배치한 뒤 발견하는 것보다 비용이 적게 든다.

Google의 공개적 표현은 여전히 적절히 신중하다. Project Suncatcher 업데이트는 이 위성을 초기 시험으로 규정하고 냉각을 핵심 연구 과제로 꼽는다.

이러한 절제는 연구 프로그램을 단기 궤도 클라우드 용량에 관한 더 공격적인 주장과 구분한다. 시험은 증거를 제공하지만, 아직 연속 워크로드, 경쟁력 있는 비용, 배치 가능한 유지보수 전략을 입증하지는 못한다.

우주 컴퓨팅의 확장 가능성을 결정할 세 가지 신호

다음 증거는 성공적인 실험을 반복 가능한 컴퓨팅, 재사용 가능한 발사, 그리고 위성 한 기를 넘어설 신뢰할 수 있는 경로와 연결해야 한다.

첫 번째 신호는 MVP의 지속 운용 데이터다. Google은 TPU가 얼마나 자주 작동하는지, 열이 얼마나 빠르게 축적되는지, 방사선이 추론 정확도에 어떤 영향을 미치는지를 공개해야 한다.

성공적인 단기 세션은 기존 가속기가 궤도에서 작동할 수 있음을 확인해 줄 것이다. 예측 가능한 냉각을 동반한 더 긴 세션은 더 강력한 증거를 제공한다. 잦은 종료나 설명되지 않는 오류는 밀집된 궤도 클러스터의 근거를 약화시킬 것이다.

독자들은 Google이 하드웨어 상태 측정치만이 아니라 Gemini 추론 결과를 공개하는지도 지켜봐야 한다. 작동하는 칩은 필요하지만, 유용한 워크로드 성능이 더 의미 있는 이정표다.

두 번째 신호는 Google이 계획한 다중 위성 임무를 향한 진전이다. 두 기 이상의 우주선은 단일 위성이 재현할 수 없는 광통신 링크, 조율, 분산 워크로드를 시험할 수 있다.

Google은 앞서 Planet과 함께 2027년 초 두 기의 프로토타입 위성을 목표로 제시했다. 업데이트된 일정, 설계, 임무 목표는 MVP에서 얻은 교훈이 해당 계획에 어떤 영향을 주는지 보여줄 것이다.

다중 위성 시연은 연결 안정성, 빔 추적 정확도, 궤도 운동이 워크로드 조율에 미치는 영향을 드러내야 한다. 이러한 측정은 Project Suncatcher를 하나의 시스템으로 시험하기 시작할 것이다.

세 번째 신호는 Starship의 실제 발사 빈도와 재사용 기록이다. SpaceX가 회수한 하드웨어를 반복적으로 비행시키고, 회전 시간을 줄이며, 페이로드 운용을 확대할수록 Google의 경제성은 더 신뢰할 만해진다.

한 번의 궤도 임무로는 비용 곡선을 확립할 수 없다. 신뢰할 수 있는 상업 비행의 연속이 관련 증거를 제공할 것이다. 두 단계를 모두 재사용하는 일은 또 다른 단발성 비행 이정표에 도달하는 것보다 더 중요하다.

페이로드 용량 역시 설계 목표에서 운용 성능으로 옮겨가야 한다. Google의 1,800회 발사 계산은 비행당 200톤을 가정한다. 실제 입증된 용량이 더 낮다면 필요한 임무 수가 달라진다.

이 신호들은 함께 평가해야 한다. 더 나은 칩은 감당할 수 없는 운송 비용을 보완할 수 없다. 저렴한 운송은 프로세서의 열을 제거할 수 없다. 강력한 냉각은 분산 학습에 필요한 대역폭을 만들어낼 수 없다.

경쟁사들도 유용한 비교 기준을 제공할 것이다. SpaceX는 자체 궤도 컴퓨팅 네트워크를 제안했으며, Starcloud와 다른 스타트업들은 서로 다른 아키텍처를 시험하고 있다. 이들의 결과는 Google의 클러스터 설계가 유난히 보수적인지 혹은 낙관적인지를 보여줄 수 있다.

초기 상업적 활용은 Google의 가장 큰 비전과도 다를 수 있습니다. 전송 전에 센서 또는 이미지 데이터를 분석하는 것을 포함한 우주 기반 처리에는 지상 대역폭이 더 적게 필요합니다. 따라서 이는 더욱 현실적인 초기 시장이 될 수 있습니다.

지구 기반 사용자를 위한 범용 클라우드 컴퓨팅은 더 엄격한 요건에 직면합니다. 고객은 신뢰할 수 있는 접속, 예측 가능한 지연 시간, 안전한 데이터 처리, 신속한 하드웨어 교체, 명확한 서비스 수준 보장을 기대합니다. 궤도 인프라는 이동하면서 발생하는 오버헤드를 감당하는 동시에 이러한 기대를 충족해야 합니다.

가장 중요한 결론은 Google에 정확히 1,800회의 발사가 필요하다는 것이 아닙니다. 이 수치는 Starship, 위성 설계, 시장이 발전함에 따라 달라질 가정을 바탕으로 한 모델에서 나왔습니다.

중요한 점은 이 수치가 무엇을 드러내는지에 있습니다. Google의 우주 데이터 센터에는 로켓, 우주선 공장, 광학 네트워크, 열공학, 자율 운영, AI 하드웨어를 아우르는 산업 시스템이 필요합니다.

Project Suncatcher는 이제 그 사슬의 한 고리를 시험하기 시작했습니다. 이 위성은 Google에 자사의 칩이 실제 우주 환경을 견딜 수 있는지 알려줄 수 있습니다. 그러나 SpaceX가 매년 수백 회의 발사를 수행할 수 있을지는 판단할 수 없습니다.

이 실험이 주목할 만한 이유는 추측에 불과했던 아이디어를 측정 가능한 엔지니어링 프로그램으로 전환하기 때문입니다. 동시에 남은 거리를 외면하기도 더 어렵게 만듭니다.

Google이 MVP에서 무엇을 보고하는지, 다중 위성 임무가 일정대로 진행되는지, Starship이 재사용 가능한 상업 임무를 얼마나 자주 수행하는지를 지켜보십시오. 이 세 가지 신호는 궤도 AI가 인프라로 자리 잡고 있는지, 아니면 여전히 야심 찬 연구 프로젝트로 남아 있는지를 보여줄 것입니다.