우주에서의 Lisp: 자율 우주선 제어의 높고 낮음

우주 탐사의 역사는 종종 하드웨어—로켓, 착륙선, 로버—의 관점에서 이야기됩니다. 그러나 이 기계들을 제어하는 소프트웨어가 가장 치열한 기술적·정치적 전투가 벌어지는 곳입니다. 그 중 하나가 NASA 제트 추진 연구소(JPL)의 임무 핵심 시스템에 유연성과 고수준 추상화로 유명한 언어인 Lisp를 통합하려는 시도였습니다.

이 이야기는 로봇공학 및 AI 연구원인 Ron Garrett가 우주에서의 자율성을 한계까지 밀어붙이려 했던 과정과, 당시 제도적 문화와 근본적으로 맞지 않았던 프로그래밍 패러다임을 구현하려는 고군분투를 담고 있습니다.

The Quest for Autonomy on Mars

1988년, 화성 로버 운영의 가장 큰 제약은 40분이라는 왕복 광속 지연이었습니다. 이 지연 때문에 실시간 원격 조작은 불가능했으며, 운영자가 로버 앞에 바위가 있는 것을 보고 회피 명령을 보내는 사이에 로버는 이미 충돌했을 수도 있었습니다.

이를 해결하고자 Garrett와 그의 팀은 자율성 수준을 높이는 데 집중했습니다. 목표는 로버에게 목적지를 지정하면 스스로 경로를 찾아가게 하는 것이었습니다. 이 작업은 다음과 같은 일련의 프로토타입을 통해 진행되었습니다:

FANG (Futuristic Autonomous Navigation Gizmo): 실내·실외 테스트에 사용된 중형, 무거운 로봇.
Tooth: 신발 상자 크기의 로봇.
Robbie: 세계 최초로 스테레오 비전을 이용해 주행한 대형 SUV 크기의 6륜 로봇.
The Rocky Series: 결국 Sojourner 로버로 이어진 프로토타입 계통.

Lisp as a "Superpower"

NASA의 대부분 소프트웨어가 C, Pascal, Basic 등으로 작성된 반면, Garrett 팀은 Lisp를 활용했습니다. 1980년대 후반, Python이나 Java가 등장하기 전이라 Lisp는 연구자들이 빠르게 반복 작업을 할 수 있게 해주는 고수준 추상화를 제공했습니다.

Garrett는 모든 문제를 컴파일러 문제로 바꾸는 접근법을 설명합니다. 메모리가 제한된 소형 로봇의 경우, 팀은 로봇 전용 맞춤 언어를 Lisp로 설계한 뒤 이를 임베디드 코드로 컴파일했습니다. 대형 로봇의 경우 Lisp가 직접 하드웨어 위에서 실행되었습니다.

하지만 이 선택은 큰 저항에 부딪혔습니다. NASA 내부에서는 Lisp의 가비지 컬렉션이 예기치 않게 프로세스를 멈출 수 있다는 점과 높은 메모리 사용량 때문에 위험 요소로 인식되었습니다. 실시간 응답이 필수인 임베디드 환경에서는 이러한 특성이 치명적인 위험으로 여겨졌습니다.

The Political Divide: Autonomy vs. Control

기술적 의견 차이는 종종 더 깊은 정치적 갈등을 가립니다. JPL에서는 Garrett의 연구 중심 그룹과 전통적인 운영 그룹 사이에 영역 싸움이 벌어졌습니다.

전통적인 접근법은 "낮은 자율성"에 의존했으며, 운영자가 로버가 따라야 할 정확한 경로를 지정했습니다. 이는 로봇이 "제멋대로" 움직이는 위험을 줄였지만, 인력에게 막대한 운영 부담을 안겨 주었습니다. 반면 Garrett의 접근법은 인간을 완전히 배제하려는 것이었습니다.

Garrett가 지적하듯, 이는 단순한 기술 논쟁이 아니라 생계가 걸린 충돌이었습니다. 우주선 수동 운용에 의존하던 사람들의 역할이 자동화에 의해 사라질 위험에 직면했기 때문에, 이들은 새로운 기술을 자연스럽게 받아들이기 어려웠습니다.

Deep Space 1 and the Remote Agent

고자율 Lisp 접근법이 Sojourner 로버에 적용되지는 않았지만, NASA의 New Millennium Program을 통해 두 번째 기회를 얻었습니다. 이 프로그램은 규모의 경제를 통해 임무 비용을 절감할 수 있는 기술을 시연하는 것이 목표였습니다.

그 결과 Remote Agent가 탄생했으며, 이는 Deep Space 1 (DS1) 임무를 위한 자율 비행 제어 시스템이었습니다. 시스템은 여러 구성 요소로 이루어졌으며, 그 중 세 개가 Lisp로 작성되었습니다. Garrett가 담당한 구체적인 부분은 "executive"였으며, 이는 입력 데이터와 비상 상황에 따라 우주선의 순간순간 행동을 결정하는 소프트웨어였습니다.

신뢰성을 확보하기 위해 executive는 레이스 컨디션과 교착 상태와 같은 일반적인 멀티스레드 문제를 방지하도록 설계된 맞춤 언어로 프로그래밍되었습니다. 이 언어의 안전성은 형식적 정합성 증명과 비행 동일 하드웨어를 이용한 광범위한 지상 테스트로 뒷받침되었습니다.

The 150-Million-Mile Debugging Session

형식적 증명에도 불구하고 Remote Agent는 3일간의 비행 실험 중에 실패했습니다. 지구에서 1억 5천만 마일 떨어진 우주선이 결정을 멈춘 것입니다.

우주선에 Lisp REPL (Read‑Eval‑Print Loop)이 탑재돼 있었기 때문에 팀은 독특한 방법으로 문제를 해결할 수 있었습니다. Deep Space Network를 통해 S‑expression(리습 코드)을 직접 전송할 수 있었던 것입니다. 수많은 관리 승인과 70미터 안테나 전송 과정을 거친 뒤, 팀은 시스템 상태 덤프를 요청했습니다.

백트레이스 결과 레이스 컨디션이 발견되었습니다—즉, 언어가 방지하도록 설계된 바로 그 문제였습니다. 개발자가 안전한 언어 구조만으로는 특정 기능을 구현할 수 없다고 판단해, 낮은 수준의 Lisp 구문을 직접 호출하면서 안전 장치를 우회했기 때문에 교착 상태가 발생한 것이었습니다.

Lessons Learned

REPL을 이용해 팀은 시스템을 "풀어" 임무 목표를 달성하도록 수동으로 이벤트를 주입했습니다. 그러나 이 경험은 깊은 인상을 남겼습니다. 자율성 프로젝트는 곧 취소되었고, 고수준 Lisp 접근법은 주변화되었습니다.

Garrett는 도구인 Lisp의 가치는 절대적인 우수성에 있지 않고, 사용자의 사고방식과의 "임피던스 매치"에 있다고 회고합니다. 그에게 Lisp는 코드와 데이터를 동일하게 취급하고 강력한 추상화를 제공하는 완벽한 맞춤이었지만, NASA 조직 문화와는 맞지 않았던 것입니다.

궁극적으로, 우주에서의 Lisp 이야기는 형식적 증명이 가정만큼이나 강력하다는 점과, 가장 정교한 기술 솔루션도 인간 실수와 조직 정치의 결합에 의해 좌초될 수 있음을 일깨워 줍니다.