# NASA가 Artemis II의 내결함성 컴퓨터를 구축한 방법 > Clean Markdown view of GeekNews topic #28389. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28389](https://news.hada.io/topic?id=28389) - GeekNews Markdown: [https://news.hada.io/topic/28389.md](https://news.hada.io/topic/28389.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-10T20:32:55+09:00 - Updated: 2026-04-10T20:32:55+09:00 - Original source: [cacm.acm.org](https://cacm.acm.org/news/how-nasa-built-artemis-iis-fault-tolerant-computer/) - Points: 7 - Comments: 1 ## Topic Body - 달 유인 비행선 **Orion**의 비행 컴퓨터는 **Apollo 시대 시스템보다 복원력과 자동 제어 능력이 크게 향상된 구조**로, 생명 유지·전력·통신 등 핵심 기능을 모두 관리함 - 달 궤도 25만 마일 거리에서도 중단 없이 작동하도록, **물리적·논리적 중복 구조와 다중 비행 컴퓨터**를 통해 하드웨어 오류와 방사선 영향을 견디도록 설계됨 - 각 **Flight Control Module(FCM)** 은 자체 검증 프로세서 쌍으로 구성되어 총 8개의 CPU가 병렬 실행되며, **fail-silent 설계와 우선순위 기반 출력 선택 알고리듬**으로 오류를 격리함 - 시스템은 **시간 트리거형 이더넷과 결정론적 아키텍처**를 통해 완전 동기화 상태를 유지하고, 삼중화된 네트워크와 메모리로 단일 비트 오류까지 자동 수정함 - 주 시스템이 모두 실패할 경우를 대비해 **독립 하드웨어와 운영체제 기반의 Backup Flight Software**가 제어권을 인계받으며, 이 구조는 향후 **자율 시스템의 항상 가동 복원력 모델**로 평가됨 --- ### NASA의 Artemis II 내결함성 컴퓨터 설계 - **Artemis II**의 비행 컴퓨터는 **Apollo 시대 항법 컴퓨터**보다 복원력과 자동 제어 능력이 크게 향상된 구조 - Apollo 컴퓨터는 1MHz 프로세서와 약 4KB 메모리를 사용했으며, 주요 제어는 수동 스위치나 릴레이 기반 - Artemis II의 **Orion 캡슐**은 생명 유지, 전력, 통신 등 모든 핵심 기능을 컴퓨터가 직접 관리 - 달 궤도 25만 마일 거리에서의 임무 실패는 복구 불가능하므로, 시스템은 **우주 방사선, 비트 플립, 하드웨어 결함**에도 중단 없이 작동해야 함 - NASA는 물리적 중복 배선, 논리적으로 중복된 네트워크 평면, 다중 비행 컴퓨터를 통해 하드웨어 오류를 대비 - ## The Power of Eight - Orion은 기존 **삼중 중복(triple redundancy)** 을 넘어서는 구조를 채택 - 두 개의 Vehicle Management Computer(VMC) 각각에 두 개의 Flight Control Module(FCM)을 탑재해 총 4개의 FCM 구성 - 각 FCM은 **자체 검증(self-checking)** 프로세서 쌍으로 이루어져 총 8개의 CPU가 병렬로 비행 소프트웨어를 실행 - 시스템은 **fail-silent 설계**를 기반으로 하며, 오류가 발생한 CPU는 잘못된 출력을 내보내지 않고 즉시 침묵 상태로 전환 - 다수결 투표 대신 **우선순위 기반 소스 선택 알고리듬**을 사용해 정상 채널의 출력을 선택 - NASA는 Van Allen 복사대 통과 중 일시적 오류를 예상하며, 최대 22초 동안 3개의 FCM을 잃어도 마지막 FCM으로 임무를 지속 가능 - 침묵 상태의 FCM은 재설정 후 다른 모듈과 동기화되어 비행 중 재참여 가능 - ## 결정론적 동작 유지 - 여러 독립 컴퓨터를 완전 동기화(lockstep) 상태로 유지하기 위해 **결정론적 아키텍처(deterministic architecture)** 를 적용 - Orion은 **시간 트리거형 이더넷(time-triggered Ethernet)** 네트워크를 사용해 시스템 전체에 시간을 분배 - 비행 소프트웨어는 ARINC653 스케줄러가 관리하는 **주 프레임(major frame)** 과 **부 프레임(minor frame)** 내에서 실행 - 시간·공간 분할을 통해 입력과 출력이 네트워크 일정과 완벽히 정렬되도록 보장 - 각 FCM은 동일한 입력을 받아 동일한 코드를 실행하고 동일한 출력을 생성 - 각 초마다 FCM의 클록 드리프트를 측정해 네트워크 기준 시간으로 재보정 - 마감 시간(deadline)을 지키지 못한 애플리케이션은 자동으로 침묵 상태로 전환 후 재동기화 - 하드웨어는 **삼중 모듈 중복 메모리(TMR)** 를 사용해 단일 비트 오류를 자동 수정하며, 네트워크 인터페이스 카드도 **이중 트래픽 경로**를 비교해 오류 발생 시 fail-silent 처리 - 네트워크는 세 개의 독립 평면으로 삼중화되어 있으며, 모든 스위치는 자체 검증 기능을 가짐 - ## 최종 백업 시스템 - NASA는 모든 주요 채널에 동시에 영향을 줄 수 있는 **공통 모드 실패(common mode failure)** 에 대비 - 이를 위해 **Backup Flight Software(BFS)** 시스템을 별도로 탑재 - BFS는 다른 하드웨어, 다른 운영체제, 독립적으로 개발된 단순화된 비행 소프트웨어로 구성 - 주 시스템이 실패하면 자동으로 BFS가 제어권을 인계받아 임무의 동적 구간을 완료 가능 - 이후 승무원이 주 FCM 복구를 시도할 수 있음 - **fail-silent 논리**는 필수이지만, 오류가 감지되지 않은 채 남지 않도록 **감시 타이머 및 다층 모니터링**이 병행되어야 함 - 전원 완전 상실(“dead bus”) 시에도 생존 가능하도록 설계 - 전원 복구 시 자동으로 **안전 모드(safe mode)** 진입 - 태양 전지판을 태양 방향으로 조정해 전력 회복 후, 열 안정화를 위해 기체를 태양에 꼬리를 향하게 함 - 이후 지구와의 통신 재수립 시도, 필요 시 승무원이 수동으로 생명 유지 장치 조정 가능 - ## 신뢰성의 미래 - Apollo에서 Artemis로의 변화는 **소프트웨어 복잡성의 비약적 증가**를 의미 - Apollo는 기계적 백업이 존재했지만, Artemis에서는 소프트웨어가 모든 제어를 담당 - NASA는 **전 환경 시뮬레이션, 몬테카를로 스트레스 테스트, 대규모 결함 주입(fault injection)** 을 포함한 현대적 검증 워크플로를 사용 - 슈퍼컴퓨터를 활용해 전체 비행 타임라인을 모의하고, 하드웨어 결함 상황에서도 소프트웨어가 fail-silent로 복구 가능한지 검증 - Orion의 **제로 톨러런스 아키텍처**는 향후 **자율주행차, 산업 제어망** 등에서도 적용 가능한 **항상 가동(always-on) 복원력**의 모델로 평가됨 ## Comments ### Comment 55042 - Author: neo - Created: 2026-04-10T20:32:55+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47704804) - 1989년부터 95년까지 Stratus에서 **VOS와 데이터베이스 성능** 관련 일을 했음 Stratus는 하드웨어 기반의 **결함 허용(fault-tolerant)** 시스템 회사였고, 경쟁사 Tandem은 소프트웨어 기반 접근을 했음 Stratus의 구조는 “pair and spare”로, 모든 보드가 이중화되어 있었고 각 핀 출력을 매 틱마다 비교했음 Motorola 68K에서 Intel로 전환할 때, 일부 명령어의 미사용 핀이 떠버리는 문제로 하드웨어 팀이 큰 어려움을 겪었음 - CMU 연구자가 말한 “Agile과 DevOps가 아키텍처적 규율을 약화시켰다”는 표현이 인상적이었음 요즘은 **결정론적 시스템**을 만드는 법을 잊은 것 같음 **Time-triggered Ethernet**의 엄격한 프레임 스케줄링은 지금의 소프트웨어 개발 방식과는 완전히 다른 세계처럼 느껴짐 - 아직도 **실시간 보장**이 필요한 임베디드 시스템을 다루는 사람들이 있음 최신 개발 관행 중 일부(단위 테스트, CI 등)는 이런 환경에서도 긍정적인 영향을 줌 - 아폴로 시절에는 국방부 중심의 연구 자금 덕분에 **WCET(최악 실행 시간)** 기반의 결정론적 컴퓨팅이 주류였음 지금은 상업 시장 중심으로 바뀌며 투자가 줄었지만, 여전히 흥미로운 알고리즘이 많음 Frank Mueller나 Johann Blieberger의 연구를 참고할 만함 - Time-triggered Ethernet은 항공기 인증용 데이터 버스의 일부로, **INRIA와 Airbus**가 관련 연구를 했음 항공기처럼 입력·출력이 한정된 환경에서는 결정론적 설계가 완벽히 들어맞음 실제로는 이더넷이라기보다 **전용 하드웨어 버스**에 가까움 - **Tesla Cybertruck**도 이 방식을 이더넷에 사용한다고 들었음 - 아마도 그가 말한 것은 [SpaceWire](https://en.wikipedia.org/wiki/SpaceWire)일 것 같음 - [Code Golf의 ‘radiation hardening’ 챌린지](https://codegolf.stackexchange.com/questions/57257/radiation...)를 보며 이런 접근이 실제로 쓸모가 있을까 궁금했음 현실적으로는 너무 많은 층위의 문제가 얽혀 있어서 어렵겠지만, 그래도 흥미로운 아이디어라고 생각함 - 기사에서 설명된 **“fail-silent” 설계**는 흥미로웠음 하지만 두 CPU가 동시에 잘못된 계산을 하고 그 결과가 일치하면 어떻게 감지할지 궁금했음 - 방사선으로 인한 동일 비트 오류가 동시에 두 CPU에서 발생할 확률은 **극도로 낮음** - 이런 CPU들은 **lockstep 구조**로 같은 연산을 동시에 수행하며 결과를 비교함 두 CPU가 동시에 같은 오류를 내는 확률은 단일 CPU의 FIT보다 훨씬 낮음 - 두 CPU가 동시에 같은 비트를 뒤집을 확률은 차라리 **소행성 충돌**이 일어날 확률보다 낮음 그래도 우주에서는 Murphy의 법칙이 통하니 장담은 못 함 - 사실 3중 다수결 구조에서도 두 CPU가 같은 오류를 내면 같은 문제가 생김 - 시스템 1과 2가 동시에 잘못되고 나머지 6개가 정상이라면, “25% 다수결”로 잘못된 결과가 선택될 수도 있음 - 이 시스템의 **CPU, RAM, OS, 언어** 등에 대한 구체적인 정보가 궁금함 얼마나 자주 FCM이 “fail-silent” 되었는지도 알고 싶음 - **NASA cFS**는 C로 작성되었고, [GitHub](https://github.com/nasa/cFS)에 공개되어 있음 보통 FreeRTOS나 RTEMS 위에서 동작함 개인적으로는 프로젝트 구조가 너무 복잡해서 다루기 힘들었음 - BFS는 cFS를 사용하며, [YouTube 영상](https://youtu.be/4doI2iQe4Jk?si=ucMoIdw7x_QgZR32)에서도 볼 수 있음 NASA의 핵심 코드는 대부분 비공개지만, cFS는 **고전적인 비행 소프트웨어 설계**를 배울 수 있는 좋은 자료임 - 기사에서는 실제 **RTOS와 아키텍처**에 대한 세부 내용이 빠져 있음 Orion의 주 비행 제어는 **Green Hills INTEGRITY RTOS**와 **BAE RAD750** 프로세서 기반의 4중 중복 구조임 BFS는 완전히 다른 **LEON3 + VxWorks** 하드웨어에서 동작하며, NASA의 **cFS 프레임워크**를 사용함 이는 James Webb 망원경과 Mars Rover에도 쓰인 **모듈형 재사용 아키텍처**임 이런 구조는 단순한 “주 시스템 + 백업”이 아니라, **이기종 중복(dissimilar redundancy)** 개념임 자세한 내용은 [NASA 기술 문서 1](https://ntrs.nasa.gov/api/citations/20190000011/downloads/20190000011.pdf), [문서 2](https://ntrs.nasa.gov/api/citations/20230002185/downloads/FS-2023-02185.pdf)에서 볼 수 있음 - 하지만 완전히 다른 팀이라 해도, 같은 **교재나 알고리즘 출처**를 쓰면 동일한 오류가 생길 수 있음 - 실제 제작은 **Lockheed Martin과 하청업체들**이 담당했음 언론이 NASA가 직접 만든 것처럼 표현하는 건 오해를 부름 - Lockheed가 NASA 요청 없이 이런 고가의 **4중 중복 PowerPC 시스템**을 만들었을 리는 없다고 생각함 - BFS는 NASA 내부에서 주로 개발되었음 (직접 참여한 친구의 증언) - 실제로는 NASA와 Lockheed 간에 **긴밀한 협업**이 있었을 것임 - “메가코프를 생각해보라”는 농담도 나왔음 - 25년 전 웹 개발자로 일할 때, NASA 출신 친구에게 “버그는 어떻게 처리했냐”고 물었더니 그가 웃으며 “**버그가 없었음**”이라고 답했음 오늘날의 개발자들은 실패해도 사람 목숨이 걸리지 않는 환경에 익숙해져 있음 - 산업마다 “충분히 괜찮음”의 기준이 다름 웹 서비스는 매출 손실 정도지만, 우주선은 **인명**이 걸려 있음 - 예전에 **방사선 내성 컴퓨터**를 개발한 적이 있는데, 단순한 중복 외에도 **비중복적 오류 검출 기법**을 썼음 이번 시스템은 그런 접근이 보이지 않아 아쉬움 - 셔틀 시절에는 5대의 컴퓨터를 서로 다른 위치와 방향에 설치해서 **방사선 충돌 단면을 분산**시키는 물리적 하드닝도 했었음 - 여러 중복 구조가 훌륭하긴 하지만, **수동 조종(Manual Override)** 기능이 여전히 가능한지 궁금함 아폴로 11과 13처럼 필요할 때 직접 제어할 수 있는지 알고 싶음 여전히 **테스트 파일럿 출신 우주비행사**들이 조종하니 가능할 것 같음