단위 하나가 탐사선을 잃게 했을까: 화성 기후 궤도선 사고의 진짜 교훈

화성에 닿기 직전, 숫자는 멀쩡해 보였다

화성 기후 궤도선은 화성의 대기와 기후를 관측하고, 뒤따를 화성 극지 착륙선의 통신 중계 역할을 맡을 예정이었다. 1998년 12월 11일 발사된 탐사선은 약 9개월을 비행한 뒤 1999년 9월 23일 화성 궤도 진입 기동을 시작했다. 신호는 화성 뒤로 들어가며 끊겼고, 예상했던 시간이 지나도 돌아오지 않았다.

사고 뒤 NASA 조사위원회가 찾아낸 핵심은 복잡한 우주 공식의 오류가 아니었다. 지상 소프트웨어가 만든 ‘작은 힘’ 파일의 수치가 명세와 다른 단위로 전달됐다. 인터페이스 명세는 충격량을 뉴턴초(N·s)로 요구했지만 실제 파일에는 파운드힘초(lbf·s)의 수치가 들어갔다. 뒤의 항법 소프트웨어는 문서대로 N·s라고 믿고 계산했다.

여기서 흔히 “미터법과 야드파운드법을 헷갈려 탐사선이 추락했다”는 한 문장만 남는다. 방향은 맞지만 중요한 부분이 빠진다. 탐사선 내부 계산은 미터법으로 올바르게 작동했고, 불일치는 지상 소프트웨어가 만든 파일과 그것을 읽는 항법 모델 사이에서 생겼다. 조사 보고서는 오류가 궤도에 미친 효과를 4.45배 과소평가했다고 적었다. 사후에 값을 바로잡아 다시 계산한 궤도 진입 뒤 첫 근화점, 곧 화성에 가장 가까워질 지점의 고도는 57km로 추정됐으며 생존하기에 너무 낮다고 판단됐다. 정확히 불타 없어졌는지, 대기를 스쳐 태양 주회 궤도로 나갔는지는 직접 확인되지 않았다. NASA 조사 보고서의 Phase I 부록 (새 창)

12.0은 단위를 잃는 순간 다른 값이 된다

단위 불일치가 계산에서 어떤 모양인지 보기 위해 설명용 가상 자료를 만들자. 실제 화성 기후 궤도선의 질량, 분사 시간, 충격량을 뜻하지 않는다. 어떤 시험 장치에 가한 충격량을 생산자가 12.0 lbf·s로 계산했는데, 파일에는 숫자 12.0만 적었고 소비자는 이를 12.0 N·s로 읽었다고 하자.

NIST 환산표에서 1 lbf는 4.448222 N이다. 초(s)는 양쪽에 그대로 있으므로 다음처럼 바꿀 수 있다.

• 올바른 값: 12.0 lbf·s × 4.448222 = 53.378664 N·s
• 소비자가 사용한 값: 12.0 N·s
• 빠진 충격량: 53.378664 - 12.0 = 41.378664 N·s
• 과소평가 비율: 53.378664 / 12.0 = 4.448222배

가상의 장치 질량을 600kg으로 두고, 충격량을 질량으로 나눈 속도 변화 Δv = J / m를 계산하면 차이가 더 선명하다.

같은 방향의 가상 사건이 열 번 반복된다고 단순화하면 속도 변화의 차이는 약 0.689644m/s가 된다. 실제 우주선의 궤도는 방향, 시점, 다른 힘을 함께 계산하므로 이 곱셈으로 재현할 수 없다. 이 예시가 보여주는 것은 하나뿐이다. 숫자의 자릿수와 형식이 모두 정상이어도 단위를 잃으면 서로 다른 물리량으로 계산될 수 있다.

사고는 단위 하나로 끝나지 않았다

NASA 보고서는 근본 원인을 단위 불일치로 정리했지만, 거기서 조사를 멈추지 않았다. 별도로 여덟 가지 기여 원인을 적었다. 속도 변화 모델의 이상을 놓친 일, 탐사선에 익숙하지 않은 항법팀, 다섯 번째 궤도 수정 기동을 하지 않은 결정, 개발에서 운영으로 넘어가는 과정의 시스템 공학 부족, 팀 사이 소통 문제, 부족한 항법 인력과 교육, 지상 소프트웨어를 충분히 다루지 못한 검증 절차가 함께 등장한다.

오류가 숨어 있을 기회만 있었던 것도 아니다. 비대칭 태양전지판 때문에 각운동량을 덜어내는 분사 사건이 운영 항법팀의 예상보다 10~14배 자주 일어났다. 초기 네 달에는 파일 형식과 자세 정보 문제로 해당 파일을 항법 계산에 쓰지 못했다. 1999년 4월에는 파일을 쓰기 시작한 지 일주일 안에 작은 힘이 과소평가되는 이상이 드러났지만, 단위 원인은 탐사선을 잃은 뒤인 9월 29일에야 확인됐다.

따라서 이 사건의 교훈을 “개발자가 변환식 한 줄을 빼먹었다”로 줄이면 같은 문제를 막기 어렵다. 조사위원회도 사람의 실수는 생길 수 있다고 전제했다. 문제는 명세, 검토, 이상 보고, 종단 간 시험이라는 여러 방어선이 그 실수를 임무 실패 전에 붙잡지 못했다는 데 있다. 단위 변환을 추가하는 일과 단위가 틀린 값을 통과시키지 않는 체계를 만드는 일은 다르다.

인터페이스 계약은 값보다 넓다

서로 다른 프로그램이나 팀이 숫자를 주고받을 때 12.0만으로는 계약이 완성되지 않는다. 최소한 다음 항목이 같은 문서와 같은 시험에 들어 있어야 한다.

파일명이나 회의록에만 단위를 적는 것으로는 부족하다. 스키마의 필드 이름을 impulse_N_s처럼 만들거나 값과 단위를 한 구조로 묶으면, 사람이 문서를 다시 찾지 않아도 의미를 볼 수 있다. 더 중요한 것은 생산자와 소비자가 같은 예제 파일을 가지고 서로의 결과를 비교하는 일이다. 경도 측정에서 기준 시각을 함께 맞춘 이유처럼, 기준은 계산 바깥의 설명이 아니라 계산에 들어가는 입력이다.

변환보다 먼저 실패하게 만드는 검사

운영 중인 시스템이라면 완벽한 사람을 기다리는 대신 잘못된 값이 빨리 실패하도록 만들 수 있다.

1. 단위가 드러나는 이름을 쓴다. impulse보다 impulse_N_s가 낫다. 단위를 바꾸면 필드 버전도 바꾼다.
2. 1이나 0이 아닌 기준 예제를 고정한다. 12.0 lbf·s → 53.378664 N·s처럼 변환 오류가 감춰지지 않는 값으로 생산자와 소비자의 시험을 함께 실행한다.
3. 차원과 범위를 검사한다. 충격량 자리에 힘이나 속도가 들어오면 거부하고, 정상 운용 범위를 크게 벗어난 값은 경고가 아니라 처리 중단 후보로 올린다.
4. 독립 계산을 둔다. 같은 함수의 결과를 복사해 비교하지 말고, 단순한 별도 계산이나 검증 도구로 핵심 값을 다시 구한다.
5. 이상을 닫을 때까지 추적한다. 관측과 모델의 차이가 계속되면 담당자·기한·확인 결과를 남긴다. “이미 알고 있는 차이”라는 말은 해결 상태가 아니다.
6. 종단 간 시험을 한다. 입력 생성부터 파일 전송, 파싱, 단위 변환, 최종 의사결정 화면까지 실제 경로를 통과시킨다.

이 검사는 우주 탐사에만 필요한 것이 아니다. 온도 °C와 °F, 압력 Pa와 psi, 길이 mm와 inch, 시간 초와 밀리초를 섞을 수 있는 주문·센서·설비 시스템에도 그대로 적용된다. 모형의 적용 범위를 확인하는 일은 입력값의 의미를 고정하는 데서 시작한다.

보고서에 남길 다섯 줄

새 연동을 검토할 때는 다음 다섯 줄을 실제 값으로 채워 보자.

• 전달하는 물리량과 단위: 충격량, N·s
• 생산자 → 소비자: 제어 프로그램 → 항법 모델
• 좌표계·방향·시간 기준: 기체 축 +X, 사건 종료 시각 UTC
• 기준 예제와 기대값: 12.0 lbf·s 입력은 변환 뒤 53.378664 N·s
• 범위 이탈 시 행동: 계산 중단, 담당자 알림, 원본 값과 단위 보존

이 문장은 특정 도구를 강요하지 않는다. 대신 값이 어디서 생겨 어떤 의미로 소비되는지, 틀렸을 때 어디에서 멈추는지를 한 화면에 남긴다. NASA 조사 보고서가 권고한 것도 단순히 모든 숫자를 미터법으로 바꾸라는 말에 그치지 않았다. 설계와 운영 전반의 단위 일관성을 확인하고, 팀 사이에 전송되는 데이터가 인터페이스 명세를 지키는지 소프트웨어 감사를 하라고 했다.

화성 기후 궤도선의 숫자는 무작위 문자나 깨진 파일이 아니었다. 형식이 정상인 값이 잘못된 의미로 연결됐다. 그래서 좋은 검증은 “숫자를 읽을 수 있는가” 다음에 “같은 양·단위·방향·시각으로 읽고 있는가”를 묻는다. 같은 결과를 다시 얻는 조건을 기록하는 일과 마찬가지로, 단위는 결과 옆의 작은 표기가 아니라 결과를 다시 만들 수 있게 하는 조건이다.