통신과 신뢰성 — 레이저 링크, 방사선, 우주잔해 — 우주 데이터센터 AI워크로드 경제성 6/9

시리즈: 우주 데이터센터 AI워크로드 경제성 (총 9편) | 6회

통신과 신뢰성 — 레이저 링크, 방사선, 우주잔해

우주에 데이터센터를 올리면 계산은 우주에서 하더라도 결과는 지구로 보내야 하잖아. 통신이 느리면 의미 없고, 장비가 방사선에 고장 나면 돈만 날려. 이 편에서는 통신·방사선·우주잔해라는 세 가지 신뢰성 이슈를 파헤쳐 볼게.

Summary

• 우주 데이터센터의 통신 전략은 “데이터를 줄여서 보내기” 또는 “결과물만 내려보내기” 두 갈래야
• 레이저 통신은 수백 Mbps~수십 Gbps까지 가능하지만, 지상국·중계위성·기상까지 포함한 ‘망’ 구축이 필수
• 상용 GPU/메모리는 우주 방사선 전제로 설계되지 않아서 SEU·TID 대응이 가동률과 교체주기를 결정해
• LEO 우주잔해 회피 기동·보험·관제 인력이 운용비(OPEX)에 지속적으로 쌓여

이 글의 대상

• 우주 데이터센터가 데이터를 어떻게 주고받는지 궁금한 사람
• 방사선 환경에서 상용 하드웨어를 쓸 수 있는지 알고 싶은 엔지니어
• 우주잔해가 위성 운용에 미치는 실질적 비용을 이해하고 싶은 독자

목차

1. 우주 데이터센터의 통신 시나리오
2. 레이저 통신의 현재 수준
3. 통신 ‘망’을 구축한다는 것
4. 방사선 — 상용 칩의 적
5. 방사선 대응: 시스템 설계로 버티기
6. 우주잔해 — 끊이지 않는 OPEX

1. 우주 데이터센터의 통신 시나리오

우주에 계산 자원을 올려놓을 때, 데이터 흐름은 크게 두 가지 시나리오로 나뉘어:

시나리오 A: 우주에서 생성한 데이터를 우주에서 처리
위성이나 센서가 만들어내는 데이터를 그 자리에서 처리하고, 핵심 결과만 지상으로 내려보내는 거야. 원시 데이터 전체를 전송하지 않으니 통신 부담이 확 줄어들지.

시나리오 B: 대규모 학습을 우주로 옮기기
AI 학습 같은 대규모 연산을 우주에서 돌리고, 학습된 모델(가중치)만 지상으로 전송해. 학습 데이터 수십~수백 TB를 올리는 건 초기 한 번이고, 결과물은 수 GB 수준이니까 비대칭 통신이 되는 셈이야.

어떤 시나리오든 “통신 대역폭이 충분한가”가 사업 모델의 전제 조건이 돼. 레이저 통신이 빠르다는 뉴스만 보면 다 해결될 것 같지만, 현실은 더 복잡하거든.

2. 레이저 통신의 현재 수준

기존 RF(전파) 통신보다 레이저(광학) 통신이 주목받는 이유는 대역폭이야. 빛의 파장이 훨씬 짧으니 같은 출력에서 더 많은 데이터를 실어 보낼 수 있지.

현재 실증된 성과를 보면:

프로젝트	거리	달성 속도	특징
NASA DSOC	수억 km (심우주)	267 Mbps	목성 궤도 근처에서 시연
NASA LLCD	달-지구 (~38만 km)	622 Mbps	달 궤도 위성에서 지상국으로
NASA LCRD	지구 정지궤도	~1.2 Gbps	GEO-지상 중계
Starlink ISL	위성 간 (~수천 km)	25 Gbps	위성 간 레이저 링크

심우주에서도 수백 Mbps, 위성 간에서는 수십 Gbps가 이미 시연됐어. 속도 자체는 꽤 인상적이지.

하지만 “267 Mbps로 연결됐다”와 “상업 서비스로 24시간 안정 운용된다”는 완전히 다른 이야기야.

3. 통신 ‘망’을 구축한다는 것

레이저 통신의 가장 큰 약점 중 하나는 기상 영향이야. 구름이 끼면 레이저 빔이 차단되거든. 지상국 하나만으로는 가용률이 떨어지니까, 전 세계 여러 곳에 지상국을 분산 배치해야 해.

그 외에도 망 구축에 필요한 것들:

• 지상국 네트워크: 다수의 지상국을 지리적으로 분산 배치해서 기상 리스크를 분산
• 중계 위성: 직접 지상국이 보이지 않는 위치에서도 데이터를 전달할 수 있는 중계 인프라
• 운용 인력: 링크 상태 모니터링, 장애 대응, 스케줄링을 위한 관제 팀
• SLA와 단가 체계: 상업망으로 쓰려면 가용률, 지연 시간, 요금 구조가 정립돼야 해

이 전체가 하나의 통신 인프라 사업이야. 데이터센터 운영자 입장에서는 자체 구축 vs 통신 사업자 서비스 이용 중에서 선택해야 하고, 어느 쪽이든 비용이 만만치 않지.

“레이저 통신이 빠르다”는 기술 시연 수준에서, “상업 SLA를 보장하는 통신 서비스”로 가는 과정은 별개의 산업 과제야.

4. 방사선 — 상용 칩의 적

우주 방사선은 데이터센터 하드웨어에 두 가지 방식으로 피해를 줘:

SEU (Single Event Upset, 단일사건오류)

고에너지 입자가 칩을 관통하면서 메모리 비트를 뒤집거나 회로를 일시적으로 오동작시켜. 한 번의 입자 충돌로 소프트웨어 크래시가 날 수 있지. 치명적일 수도, 자동 복구될 수도 있어.

TID (Total Ionizing Dose, 총이온화선량)

시간이 지나면서 방사선이 누적되면 칩의 트랜지스터 특성 자체가 변해. 문턱 전압이 바뀌고, 누설 전류가 늘고, 결국 칩이 제 기능을 못 하게 돼. 이건 돌이킬 수 없는 열화야.

상용 GPU, SSD, HBM은 우주 방사선 환경을 전제로 만들어진 게 아니야. 지구 표면에서는 대기가 방사선 대부분을 막아주니까 신경 안 써도 됐거든.

실제 측정 데이터를 보면:

환경	방사선 수준	출처
달 표면	흡수선량 13.2 ± 1 μGy/h	Chang’E-4 LND
화성 표면	유효선량 0.6~0.7 mSv/day	Curiosity RAD
LEO (ISS 고도)	ISS 내부 기준 약 0.5~1 mSv/day	다수 측정

이 수치가 상용 전자부품에 어떤 영향을 미치는지는 칩 공정과 설계에 따라 다르지만, 확실한 건 가동률과 교체주기에 직결된다는 거야.

5. 방사선 대응: 시스템 설계로 버티기

방사선 내성(rad-hard) 전용 칩을 쓰면 좋겠지만, 성능이 상용 대비 수 세대 뒤처져. H100 수준의 AI 가속기를 rad-hard로 만드는 건 현실적이지 않아. 그래서 상용 칩을 쓰되 시스템 설계로 버티는 전략이 나와:

ECC 강화 + 메모리 스크럽

SEU로 비트 오류가 나면 ECC(Error Correcting Code)가 자동 수정해. 주기적으로 메모리 전체를 스캔해서 축적된 오류를 잡아내는 스크럽도 함께 돌려.

모듈 이중화/삼중화

같은 계산을 여러 모듈에서 동시에 수행하고 결과를 비교해. 다수결로 정상 결과를 선택하는 TMR(Triple Modular Redundancy) 방식이 대표적이지.

체크포인트 기반 자동 재시작

AI 학습이나 대규모 연산은 주기적으로 중간 상태를 저장(체크포인트)해두고, 오류 발생 시 마지막 체크포인트부터 재시작해.

컨테이너 단위 장애 격리

한 노드가 방사선 피해로 고장 나도 전체 시스템이 멈추지 않게, 컨테이너/팟 단위로 장애를 격리하고 자동으로 다른 노드에 재배치해.

여기서 문제가 뭐냐면, 이 모든 대응책이 성능·전력·질량 오버헤드를 만든다는 거야. TMR을 쓰면 같은 계산에 3배 자원이 필요하고, 체크포인트는 스토리지 I/O를 먹고, ECC 스크럽은 메모리 대역폭을 잡아먹지.

4편에서 “전력비가 싸다”를 핵심 가치로 내세웠잖아? 방사선 대응 오버헤드는 그 “싸다”와 정면 충돌해. 이 트레이드오프를 어떻게 최적화하느냐가 우주 데이터센터 설계의 핵심 챌린지 중 하나야.

6. 우주잔해 — 끊이지 않는 OPEX

LEO에는 수만 개의 추적 가능한 우주잔해가 돌고 있어. 크기 1cm 이상이면 위성을 파괴할 수 있고, 추적 불가능한 작은 파편까지 합치면 수억 개에 달해.

데이터센터 위성이 LEO에 있다면 이런 운용 비용이 지속적으로 발생해:

충돌 회피 기동

우주잔해가 접근하면 궤도를 살짝 바꿔서 피해야 해. ISS도 연간 수 차례 회피 기동을 하거든. 기동할 때마다 추진제를 쓰고, 그동안 데이터센터 운용이 중단되거나 불안정해져.

SSA(우주상황인식) 서비스

어떤 잔해가 어디로 오는지 추적하는 서비스야. 미국 우주군이 기본 데이터를 제공하지만, 상업용 정밀 추적 서비스는 별도 비용이 들어.

보험

위성 충돌이나 잔해 피해에 대비한 보험료도 OPEX야. 위성 가치가 높을수록(GPU 수천 대 탑재), 보험료도 올라가지.

관제 인력

24시간 충돌 경보를 모니터링하고 회피 기동 여부를 결정하는 관제 팀이 필요해. 위성 수가 늘면 관제 부담도 비례해서 커져.

이런 비용은 한 번 내고 끝이 아니라, 위성이 운용되는 동안 계속 쌓이는 OPEX야. 지상 데이터센터에서는 “건물 관리비” 정도에 해당하는 건데, 우주에서는 “생존을 위한 비용”이니까 규모가 다르지.

핵심 정리

1. 우주 데이터센터 통신은 "데이터 축소 후 전송" 또는 "결과물만 전송"이 핵심 전략
2. 레이저 통신 기술은 수백 Mbps~수십 Gbps까지 왔지만, 상업 SLA 망 구축은 별개 과제
3. 상용 칩은 방사선에 취약해서 ECC·이중화·체크포인트 등 대응이 필요한데, 이게 성능·전력 오버헤드
4. LEO 우주잔해 대응(회피 기동, SSA, 보험, 관제)은 운용 기간 내내 쌓이는 OPEX

FAQ

Q. 레이저 통신이면 지구-우주 간 실시간 통신이 되는 거야?

A. LEO라면 빛의 왕복 지연이 수 ms 수준이라 거의 실시간이야. 하지만 달(약 1.3초 왕복)이나 화성(4~24분 왕복)은 물리적으로 실시간이 불가능해. 레이저가 아무리 빨라도 빛의 속도를 넘을 순 없거든.

Q. 방사선 때문에 상용 GPU를 못 쓰면, 전용 칩을 새로 만들어야 해?

A. 꼭 그렇진 않아. 상용 칩을 시스템 수준에서 보호하는 게 현실적인 접근이야. 차폐재로 일부 방사선을 막고, 소프트웨어 수준의 오류 복구를 적용하는 방식이지. 다만 차폐재도 질량이니까 발사비에 반영돼.

Q. 우주잔해 충돌 확률이 실제로 높아?

A. 개별 위성 기준으로 보면 연간 충돌 확률은 낮아. 하지만 데이터센터 규모로 위성 수가 늘면 확률이 곱해지고, 한 번이라도 충돌하면 피해가 엄청나지. 저확률·고영향(low probability, high consequence) 리스크인 거야.

Q. Starlink도 레이저 링크를 쓰잖아. 이미 해결된 거 아니야?

A. Starlink의 위성 간 레이저 링크(ISL)는 통신 중계용이야. 데이터센터가 필요로 하는 대역폭과는 규모가 다르고, 상향 링크(지구→우주) 대역폭도 별개 문제야. 기술의 존재와 사업적 충분함은 다른 얘기지.

Q. 방사선 차폐를 두껍게 하면 되지 않아?

A. 차폐재(납, 폴리에틸렌 등)를 쌓으면 방사선은 줄지만 질량이 폭증해. 이미 라디에이터, 전력 시스템으로 무거운데 차폐까지 추가하면 발사비가 감당이 안 돼. 최소한의 차폐 + 시스템 수준 대응이 균형점이야.

Q. SEU로 AI 학습 중간에 결과가 틀어지면 어떻게 돼?

A. 체크포인트 없이 돌리면 처음부터 다시 해야 할 수도 있어. 그래서 주기적 체크포인트가 필수야. 문제는 체크포인트 빈도가 높을수록 I/O 오버헤드가 커져서 전체 학습 시간이 늘어난다는 점이지.

Q. 달이나 화성 표면은 우주잔해 걱정이 없잖아?

A. 맞아, 대기가 없어서 운석은 있지만 인공 우주잔해 문제는 없어. 대신 달·화성 표면 데이터센터는 발사·착륙 비용이 훨씬 비싸고, 방사선 문제는 여전하며, 통신 지연이 길어지는 다른 단점이 있어.

참고 자료 (References)

데이터 출처

출처	설명	링크
JPL DSOC	심우주 광학 통신 시연 결과	JPL
Sci Adv 2020	Chang’E-4 달 표면 방사선 측정	PMC
NASA Mars RAD	Curiosity 화성 표면 방사선 데이터	NASA
SSA 운용	우주상황인식 서비스 및 운용 참조	ASC Program
NVIDIA H100	GPU 제품 스펙 및 전력 정보	NVIDIA

핵심 인용

“DSOC has demonstrated that optical communications can work across interplanetary distances, opening the door to higher data rates for future deep space missions.”
— NASA JPL, Deep Space Optical Communications

다음 편 예고

[7편] TCO 분석 — 발사비와 질량예산이 만드는 손익분기점

• 발사비가 전체 비용에서 차지하는 비중
• 질량예산이란 무엇이고 왜 중요한지
• 지상 데이터센터 대비 우주 데이터센터의 손익분기점 계산