NASA가 아르테미스 II 우주선에 넣은 '절대 죽지 않는 컴퓨터', 어떻게 만들었을까

사람을 태우는 우주선, 컴퓨터가 멈추면 끝이에요

NASA의 아르테미스 II는 2003년 컬럼비아 셔틀 사고 이후 처음으로 사람을 달 궤도까지 보내는 미션이에요. 무인 탐사선이라면 컴퓨터가 잠깐 멈춰도 재부팅하면 되지만, 우주비행사가 타고 있는 상황에서는 단 1초의 시스템 다운도 허용할 수 없거든요. 그래서 NASA는 아르테미스 II의 핵심 비행 컴퓨터를 "결함 내성(fault-tolerant)" 설계로 만들었는데, 이 과정이 우리가 일상적으로 다루는 소프트웨어 신뢰성 문제와도 깊이 연결되어 있어요.

결함 내성이 뭐냐면

결함 내성(Fault Tolerance)이란 시스템 일부가 고장 나더라도 전체가 멈추지 않고 계속 동작하는 능력을 말해요. 우리가 웹 서비스에서 "서버 한 대 죽어도 서비스는 살아있어야 한다"고 할 때 쓰는 개념과 같은 맥락이에요. 다만 우주선에서는 그 기준이 극단적으로 높아지는 거죠.

NASA가 아르테미스 II에 적용한 핵심 전략은 다중 중복(redundancy) 이에요. 쉽게 말해 같은 역할을 하는 컴퓨터를 여러 대 동시에 돌리는 건데, 단순히 백업용으로 대기시키는 게 아니라 실시간으로 같은 계산을 병렬 수행하면서 결과를 서로 비교하는 방식이에요. 만약 세 대의 컴퓨터 중 하나가 다른 답을 내놓으면, 다수결로 올바른 결과를 채택하고 이상이 있는 컴퓨터를 격리시키죠. 이걸 TMR(Triple Modular Redundancy, 삼중 모듈 중복) 이라고 불러요.

하드웨어부터 소프트웨어까지 전부 이중삼중

흥미로운 점은 중복이 하드웨어 레벨에서만 끝나지 않는다는 거예요. 소프트웨어 역시 동일한 요구사항을 서로 다른 팀이 독립적으로 구현하는 N-버전 프로그래밍 방식을 적용해요. 왜 이렇게까지 하냐면, 같은 코드를 복사해서 세 대에 넣으면 소프트웨어 버그가 세 대 모두에서 똑같이 발생하거든요. 하드웨어 결함은 중복으로 잡을 수 있지만, 소프트웨어 결함은 같은 코드인 이상 중복이 소용없는 거죠.

그래서 각 컴퓨터에 들어가는 비행 소프트웨어는 다른 언어, 다른 컴파일러, 심지어 다른 CPU 아키텍처에서 돌아가도록 설계하기도 해요. 이렇게 하면 특정 하드웨어 아키텍처나 컴파일러의 버그까지도 걸러낼 수 있으니까요.

네트워크 구조도 독특해요. 각 컴퓨터는 독립된 전원과 독립된 통신 버스를 사용해서, 하나의 전원 장치가 나가도 다른 컴퓨터에 영향을 주지 않도록 물리적으로 격리되어 있어요. 데이터센터에서 서버 랙마다 별도의 전원선과 네트워크 스위치를 두는 것과 비슷한 원리인데, 우주에서는 부품 하나 교체할 수 없으니 설계 단계에서 이 모든 시나리오를 잡아야 하는 거죠.

우리가 만드는 시스템과 뭐가 다를까

사실 이런 결함 내성 설계 원칙은 클라우드 인프라에서도 많이 사용돼요. AWS의 가용 영역(AZ) 분리, Kubernetes의 파드 자동 재시작, 데이터베이스의 복제(replication)가 전부 같은 철학에서 나온 거예요. 차이점이 있다면 허용 가능한 실패 시간이에요. 웹 서비스는 수초에서 수분 정도의 다운타임이 발생해도 대부분 감내할 수 있지만, 아르테미스의 비행 컴퓨터는 밀리초 단위 전환이 요구돼요. 로켓이 초속 수 km로 날아가는 상황에서 1초의 제어 공백은 치명적이니까요.

또 하나 큰 차이는 업데이트 불가라는 점이에요. 우리는 배포 후 버그를 발견하면 핫픽스를 내릴 수 있지만, 우주선이 달 궤도를 돌고 있을 때 소프트웨어를 패치하는 건 극도로 제한적이에요. 그래서 출발 전에 가능한 모든 시나리오를 시뮬레이션하고 형식 검증(formal verification)까지 거치는 거죠. 이건 "빠르게 배포하고 빠르게 고치자"는 현대 소프트웨어 문화와는 정반대되는 접근이에요.

한국 개발자에게 주는 시사점

국내에서도 자율주행, 의료 기기, 방위 산업 등 미션 크리티컬한 소프트웨어를 다루는 영역이 계속 커지고 있어요. 이런 분야에서는 "서버 죽으면 재시작하면 되지"라는 접근이 통하지 않아요. NASA의 설계 철학에서 배울 수 있는 건 단순히 중복을 늘리는 게 아니라, 어디서 어떻게 실패할 수 있는지를 체계적으로 분석하고, 각 실패 모드에 대한 대응을 설계 초기부터 심어놓는 것이에요.

실무에서 당장 적용해볼 수 있는 것들도 있어요. 예를 들어 결제 시스템처럼 실패가 돈과 직결되는 서비스에서 TMR까지는 아니더라도, 핵심 로직의 결과를 두 가지 경로로 계산해 교차 검증하는 패턴을 넣어볼 수 있겠죠. 또 장애 격리(failure isolation) 개념은 마이크로서비스 아키텍처에서 서킷 브레이커나 벌크헤드 패턴으로 이미 널리 쓰이고 있으니, NASA의 사례를 통해 그 원리를 더 깊이 이해하는 계기가 될 수 있어요.