$3억 7천만 달러짜리 로켓을 파괴한 16비트 정수

증거가 입증하는 것:

• 주 사고 원인은 SRI 관성 기준 소프트웨어의 수평 바이어스 계산에서 발생한 64비트-16비트 부동소수점 대 정수 변환 오버플로.
• 주 컴퓨터와 백업 컴퓨터 모두 동일한 결함을 가진 소프트웨어를 실행했기 때문에 밀리초 단위로 동시 정지됨.

증거가 입증하지 않는 것 (What the evidence does NOT establish):

• 하드웨어 결함 또는 로켓 엔진 고장; 모든 추진체 및 기계 구조는 극단적 노즐 편향 명령이 내려질 때까지 정상 작동함.
• 발사 도중 인간 운영자의 조작 실수; 비행 시퀀스는 100% 자동 제어됨.

유럽우주국(ESA)은 아리안 5호를 설계하는 데 10년이라는 시간과 70억 달러 이상을 투자했습니다. 이 발사체는 매우 신뢰할 수 있었던 이전 모델인 아리안 4호보다 훨씬 더 무겁고, 더 빠르며, 더 많은 탑재량을 처리할 수 있도록 설계되었습니다.

1996년 6월 4일, 첫 번째 비행(Flight 501)이 프랑스령 기아나의 쿠루에서 발사되었습니다. 그러나 39초 후, 보험에 가입되지 않은 4개의 과학 위성을 싣고 있던 3억 7천만 달러짜리 로켓은 하늘에서 격렬하게 공중 분해되었습니다.

근본 원인은 구조적 결함이나 잘못된 연료 밸브, 혹은 오작동하는 추진기가 아니었습니다. Flight 501의 파괴는 아주 큰 숫자를 너무 작은 상자에 억지로 집어넣으려고 시도한 단 한 줄의 코드 때문이었습니다.

불일치 분석 (Forensic Discrepancy Matrix)

1막: 불필요한 정렬 프로세스

이 시스템 붕괴를 이해하기 위해서는 로켓의 위치, 속도, 자세를 계산하는 관성 기준 시스템(SRI, Système de Référence Inertielle)을 살펴봐야 합니다. 아리안 5호에는 하나는 활성 상태이고 다른 하나는 백업 상태인, 완벽하게 동일한 두 개의 SRI가 장착되어 있었습니다.

SRI 소프트웨어 내부에는 발사 전 로켓이 자신의 정확한 위치를 파악하도록 하는 “정렬(alignment)” 기능이 있었습니다. 구형 아리안 4호의 경우, 이 정렬 기능이 발사 후 40초 동안 계속 실행되도록 설계되었습니다. 엔진이 점화된 직후 발사대에서 짧은 대기 시간이 발생할 경우, 45분이 걸리는 재보정 작업 없이 로켓을 빠르게 초기화하기 위함이었습니다.

이 발사 후 40초의 작동 창은 아리안 4호만을 위한 매우 구체적이고 특이한 요구사항이었습니다. 반면 아리안 5호는 완전히 다른 발사 시퀀스를 가지고 있었습니다. 아리안 5호에서는 발사대에서의 빠른 재초기화가 기계적으로 아예 불가능했습니다.

그럼에도 불구하고 소프트웨어가 새 로켓으로 그대로 복사되었을 때, 이 40초 동안 실행되는 정렬 기능은 삭제되지 않고 고스란히 남겨졌습니다. (분석적 재구성)

[레거시 아리안 4 요구사항] ──▶ [DOCUMENTED] ──▶ [발사 후 40초 동안 정렬 기능 실행됨]
                                                        │
[아리안 5 비행 프로필]     ──▶ [DOCUMENTED] ──▶ [물리적으로 전혀 쓸모없음에도 기능이 실행됨]

2막: 16비트의 함정

아리안 5호는 아리안 4호보다 훨씬 빨랐습니다. 초기 비행 궤적은 훨씬 더 높은 수평 가속도를 포함했습니다.

Flight 501이 상승함에 따라 백그라운드에서 무의미하게 실행되고 있던 정렬 기능은 로켓의 수평 속도를 나타내는 “수평 편향(horizontal bias, BH)” 변수를 계속해서 추적했습니다.

BH는 원래 64비트 부동소수점 숫자로 측정되었습니다. 그러나 소프트웨어는 처리를 위해 이 값을 16비트 부호 있는 정수로 변환했습니다.

16비트 부호 있는 정수가 가질 수 있는 최댓값은 32,767입니다.

아리안 4호의 비행에서는 물리적 수평 속도가 발사 후 처음 40초 동안 32,767을 초과할 만큼 높아진 적이 없었습니다. 그러나 아리안 5호는 그 한계를 쉽게 넘어섰습니다.

설상가상으로, 프로그래머들은 소프트웨어의 다른 변수들에 대해서는 보호 장치(예외 처리)를 구현했지만, BH 변수는 의도적으로 보호하지 않은 상태로 남겨 두었습니다. 공식 조사 위원회 보고서에 따르면, 이는 해당 값이 결코 오버플로를 일으킬 수 없다는 사전 분석에 기반한 의식적인 결정이었습니다. 그러나 그 분석은 아리안 5호가 아닌 아리안 4호의 비행 프로필에 전적으로 기반하고 있었습니다.

3막: 39초 만의 붕괴

원격 측정(Telemetry) 로그는 전적으로 소프트웨어 아키텍처 제약에 의해 주도된 잔혹하고 결정론적인 사건의 연쇄를 보여줍니다.

• H0 + 36초: 발사체는 완벽하게 정상적인 동작을 보여줍니다. 궤적, 추력, 공기역학 모두 흠잡을 데 없습니다.
• H0 + 36.7초: 로켓의 물리적 수평 속도가 급증하여 BH 변수가 32,767을 초과합니다.
• H0 + 37초: 소프트웨어가 데이터 변환을 시도합니다. 이는 즉각적으로 하드웨어 수준의 “피연산자 오류(operand error)” 즉, 정수 오버플로를 촉발합니다. 예외 처리가 전혀 되어 있지 않았기 때문에 활성 SRI 프로세서는 의도적으로 자체 시스템을 종료하고, 진단 실패 코드를 메인 탑재 컴퓨터(OBC)로 전송합니다.
• 백업 시스템의 붕괴: 완전히 동일한 비행 경로에서 동일한 소프트웨어를 실행 중이던 백업 SRI 역시 불과 72밀리초 전에 똑같은 정수 오버플로에 부딪혀 자체 종료되었습니다.
• H0 + 38초: 메인 OBC는 죽어버린 SRI들로부터 진단 오류 코드를 수신합니다. 그러나 OBC는 이 비트 패턴을 오류 메시지로 인식하도록 프로그래밍되어 있지 않았습니다. OBC는 진단 비트를 유효한 비행 데이터로 맹목적으로 구문 분석하여, 로켓의 자세에 거대하고 급격한 편차가 발생한 것으로 착각합니다.
• H0 + 39초: 로켓이 궤도를 크게 이탈했다고 판단한 OBC는 이를 보정하기 위해 벌컨(Vulcain) 엔진과 고체 부스터를 극단적인 한계치까지 회전시키도록 명령합니다. 이 즉각적이고 폭력적인 기동은 막대한 공기역학적 응력을 발생시켜 부스터를 코어 스테이지에서 뜯어냅니다.
• 최후: 부스터의 물리적 분리는 자동 자폭 메커니즘을 즉각 촉발시킵니다. Flight 501은 산산조각 났습니다.

시스템 예방 플레이북

아리안 5호 참사는 검증되지 않은 레거시 코드와 누락된 아키텍처 연동 장치(interlock)의 위험성을 보여주는 완벽한 교보재입니다. 현대 엔지니어링 팀은 다음과 같은 방어 계층을 반드시 구현해야 합니다.

1. 마찰 방어 (Friction Defenses)

• 명시적 계약 검증 (Explicit Contract Validation): 레거시 코드를 새로운 시스템으로 이식할 때, 최대 물리적 속도와 같은 모든 환경적 가정은 명시적인 어설션(assertion)으로 문서화되어야 하며, 새 시스템의 사양에 대해 다시 엄격하게 검증되어야 합니다.

2. 경계 제약 조건 (Boundary Constraints)

• 글로벌 예외 처리 (Global Exception Handling): 현재 하드웨어 환경에 대해 수학적으로 증명되지 않는 한, “가정된” 물리적 한계를 근거로 예외 처리를 선택적으로 제거해서는 절대 안 됩니다. 중요한 임베디드 시스템에서 처리되지 않은 예외는 반드시 정의된 안전 상태로의 단계적 저하(safe-state degradation) 경로를 가져야 합니다.
• 타입 안전 경계 (Type-Safe Boundaries): 컴파일러와 정적 분석 도구는 64비트 부동소수점에서 16비트 정수로의 변환과 같이 보호되지 않은 축소 변환(narrowing conversions)을 플래그로 지정하고 경고하도록 엄격하게 구성되어야 합니다.

3. 비상 브레이크 (Emergency Brakes)

• 데이터 유효성 마스크 (Data Validity Masks): 주 제어 컴퓨터는 진단용 실패 코드와 유효한 작동 원격 측정 데이터를 명확하게 구분할 수 있는 아키텍처 능력을 반드시 갖추고 있어야 합니다. 유효성 비트 확인(validity bit check) 없이 들어오는 데이터 페이로드를 맹목적으로 신뢰하는 것은 치명적인 아키텍처 결함입니다.

아키비스트의 판결

아키비스트의 분석:

아리안 5호 Flight 501의 상실은 단순한 로켓 공학의 실패가 아니었습니다. 그것은 시스템 엔지니어링과 인식론적 가설의 참담한 실패였습니다. 엔지니어링 팀은 한 기계에서 흠잡을 데 없이 작동했던 소프트웨어라면 더 강하고 빠른 기계에서도 똑같이 완벽하게 작동할 것이라는 환상에 빠져 있었습니다.

그들은 소프트웨어가 진공 상태에 존재하는 것이 아님을 간과했습니다. 소프트웨어는 그것이 작동하는 하드웨어의 물리적 현실과 깊게 결합되어 있습니다. 아리안 4호의 코드를 가져오면서 그 변수들을 지배하는 물리적 경계 조건에 의문을 제기하지 않은 대가는 치명적인 취약성의 수입으로 돌아왔습니다.

이 비극은 백업 시스템의 아키텍처에 의해 더욱 악화되었습니다. 동일한 코드를 실행하는 이중화 시스템은 결정론적인 소프트웨어 결함에 대해 “제로(0)“의 보호를 제공합니다. 활성 시스템이 정수 오버플로라는 물리적 경계에 부딪혔을 때, 백업 시스템 역시 정확히 같은 밀리초에 똑같은 벽에 부딪혀 산산조각 났습니다.

결국 3억 7천만 달러짜리 경이로운 항공우주 공학의 결정체는 파괴되었습니다. 완벽하게 논리적이고 수학적으로 정밀하지만, 하늘이라는 물리적 현실과는 근본적으로 단절되어 있던 일련의 명령어를 시스템이 맹목적이고 성실하게 실행한 대가였습니다.

공식 1차 출처

• Ariane 501 Inquiry Board Report (Prof. J. L. Lions)
• European Space Agency Post-Flight Telemetry Press Releases

자주 묻는 질문 (FAQ)

아리안 5호 Flight 501 폭발의 근본 원인은 무엇인가요?

관성 기준 시스템(SRI) 소프트웨어에서 64비트 부동소수점 수평 바이어스(BH) 값을 16비트 부호 있는 정수로 변환하던 중 32,767 한도를 초과하여 정수 오버플로(Integer Overflow)가 발생했습니다. 이로 인해 주 컴퓨터(OBC)가 진단 오류 덤프 데이터를 유효한 비행 자세 명령어로 잘못 해석하여 노즐을 극단적으로 꺾으면서 로켓이 공중 분해되었습니다.

이번 실패는 하드웨어 결함이나 엔진 고장 때문이었나요?

아닙니다. 모든 엔진, 추진체, 물리적 구조체 및 하드웨어는 완벽하게 작동했습니다. 유일한 원인은 이전 아리안 4호에서 검증 없이 재사용된 소프트웨어 루틴이 아리안 5호의 훨씬 빠른 가속도와 물리적 궤적을 감당하지 못해 발생한 순수한 소프트웨어 설계 및 시스템 엔지니어링 실패였습니다.

주 컴퓨터와 백업 컴퓨터가 왜 정확히 같은 순간에 실패했나요?

주 SRI와 백업 SRI 모두 완벽하게 동일한 소프트웨어를 실행하고 있었습니다. 하드웨어 이중화는 부품 고장을 방지하지만, 동일한 결함을 공유하는 소프트웨어 버그에 대해서는 아무런 보호를 제공하지 못합니다. 동일한 물리적 가속 입력이 주어지자 두 컴퓨터 모두 같은 밀리초에 동일한 오버플로 예외를 발생시키고 셧다운되었습니다.

왜 이륙 후 필요하지도 않은 정렬 소프트웨어가 계속 실행되고 있었나요?

발사 직전 카운트다운이 잠시 중단되었을 때 시스템을 신속하게 재시작할 수 있도록 돕기 위해 이륙 후 약 40초 동안 정렬 루틴을 계속 실행하도록 설계되었습니다. 아리안 4호에서는 유효했던 이 편의 기능이 아리안 5호에서는 치명적인 시한폭탄이 되었습니다.

아리안 5호 501편 참사로 인한 피해액은 얼마인가요?

로켓 자체 비용과 보험에 가입되지 않은 4개의 클러스터(Cluster) 과학 위성을 포함하여 약 3억 7천만 달러(당시 기준)의 직접적 손실이 발생했으며, 유럽우주국(ESA)은 수년간의 대체 위성 제작 및 지연 비용을 감당해야 했습니다.

사고 이후 항공우주 소프트웨어 엔지니어링에는 어떤 변화가 있었나요?

ESA는 보호되지 않는 모든 데이터 타입 변환을 전수 조사하고, 이륙 후 불필요한 기능의 완전한 비활성화, 원격 측정 데이터와 진단 덤프의 엄격한 분리, 그리고 신규 발사체의 전체 물리 비행 역학을 적용한 폐쇄 루프 하드웨어-소프트웨어(HITL) 통합 시뮬레이션을 의무화했습니다.