🤖 AI 생성 콘텐츠 — 이 글은 AI가 자료를 수집하고 초안을 작성했으며, 발행 전 누슘 운영자가 검수했습니다.
마거릿 해밀턴은 MIT 계측연구소에서 아폴로 지휘선·달착륙선 탑재 소프트웨어 팀을 이끌었다. 아폴로 11 착륙 직전 컴퓨터 과부하 상황에서 우선순위 처리와 복구 설계가 중요한 작업을 계속하게 했다.
달 착륙선 이글이 표면으로 내려가던 순간, 컴퓨터는 경보를 쏟아냈습니다. 영화라면 빨간 불과 함께 “시스템 실패”가 뜰 장면입니다. 하지만 탑재 소프트웨어는 해야 할 일을 버리지 않았습니다. 덜 중요한 작업을 밀어내고 착륙에 필요한 계산을 계속했습니다. 이 이야기의 중심에 마거릿 해밀턴과 그녀가 이끈 팀이 있습니다.
목차
- 해밀턴은 어떤 일을 맡았나
- 착륙 직전 무엇이 벌어졌나
- 왜 이것이 소프트웨어 공학의 상징이 됐나
해밀턴은 어떤 일을 맡았나?
NASA와 컴퓨터역사박물관 기록에 따르면 해밀턴은 MIT 계측연구소의 Software Engineering Division을 이끌며 아폴로 지휘선과 달착륙선의 탑재 비행 소프트웨어 작업을 책임졌습니다. 지금은 “앱이 멈추면 다시 켜면 되지”라고 말할 수 있지만, 우주선 소프트웨어에는 두 번째 기회가 없었습니다.
그녀의 팀은 비동기 작업, 우선순위 스케줄링, 종단 간 시험, 사람이 판단에 참여하는 우선순위 표시 같은 개념을 실제 임무용 시스템에 적용했습니다. 소프트웨어를 하드웨어의 부속품이 아니라 엄격하게 설계해야 할 공학 분야로 보게 만드는 데에도 큰 역할을 했습니다.

착륙 직전 무엇이 벌어졌나?
NASA의 2003년 공식 자료는 아폴로 11이 달에 닿기 약 3분 전, 승무원에게 제공된 잘못된 운용 절차 때문에 레이더 관련 스위치가 켜진 상태에서 컴퓨터에 추가 작업이 걸렸다고 설명합니다. 이때 소프트웨어는 우선순위 처리를 통해 중요한 작업을 계속했고 임무가 이어질 수 있게 했습니다.
여기서 자주 생기는 오해가 있습니다. 해밀턴 혼자 현장에서 코드를 한 줄 바꿔 착륙선을 구한 영웅담이 아닙니다. 핵심은 그녀가 이끈 팀이 문제가 발생하기 전에 과부하를 감지하고 복구하도록 시스템을 설계했다는 점입니다. 영웅적인 순간보다 더 대단한 것은, 영웅이 필요 없게 만드는 사전 설계였습니다.
| 설계 생각 | 착륙 순간의 의미 |
|---|---|
| 작업 우선순위 | 착륙 계산을 덜 중요한 작업보다 먼저 처리 |
| 오류 감지 | 컴퓨터가 감당하지 못하는 상태를 알림 |
| 복구 가능성 | 중요한 작업을 이어가도록 정리 |
| 사람에게 표시 | 승무원과 관제팀이 상태를 판단할 정보 제공 |
왜 이것이 소프트웨어 공학의 상징이 됐나?
컴퓨터역사박물관의 해밀턴 구술 기록에는 “software engineering”이라는 표현을 꺼냈을 때 주변에서 농담처럼 받아들였다는 회고가 나옵니다. 당시에는 소프트웨어를 공학으로 부르는 일이 당연하지 않았습니다. 하지만 사람의 생명과 거대한 임무가 코드에 달리자, 직감과 땜질만으로는 부족했습니다.

해밀턴은 2003년 NASA Exceptional Space Act Award를 받았고, 2016년 미국 대통령 자유 메달을 받았습니다. 그러나 그녀의 가장 오래가는 유산은 상보다 질문입니다. “정상일 때 잘 돌아가는가?”가 아니라 “예상 밖의 일이 동시에 벌어져도 가장 중요한 일을 지킬 수 있는가?”
자주 묻는 질문 (FAQ)
Q. 마거릿 해밀턴이 아폴로 11 코드를 혼자 작성했나요? A. 아닙니다. 그녀는 MIT 계측연구소에서 아폴로 탑재 비행 소프트웨어 팀을 이끈 책임자였습니다. 성과는 팀의 설계와 구현 결과입니다.
Q. 아폴로 11 착륙 때 컴퓨터가 완전히 멈췄나요? A. NASA 기록은 과부하 상황에서 소프트웨어가 우선순위 처리를 통해 중요한 기능을 계속하도록 했다고 설명합니다. 완전 정지와는 다릅니다.
Q. 마거릿 해밀턴이 ‘소프트웨어 공학’이라는 말을 처음 만들었나요? A. 해밀턴은 자신이 조직 안에서 소프트웨어를 정당한 공학 분야로 부르기 위해 이 표현을 사용했다고 회고했습니다. 세계 최초 사용 여부는 단정하지 않고, 대중화와 정착에 기여했다고 표현하는 편이 정확합니다.
Q. 오늘날 개발자가 배울 점은 무엇인가요? A. 실패를 예외로 밀어두지 말고 우선순위, 복구, 사람에게 보일 경보를 설계의 중심에 두는 것입니다. 안정성은 사고 당일이 아니라 요구사항을 정할 때 만들어집니다.
마치며
아폴로의 교훈은 코드가 완벽해서가 아니라, 불완전한 현실을 견디도록 설계했다는 데 있습니다. 지금 만드는 서비스에서 모든 작업이 한꺼번에 몰리면 무엇을 먼저 살려야 할까요? 그 우선순위를 누슘 댓글에서 함께 이야기해봅시다.
참고자료
- NASA Science — Margaret Hamilton
- NASA — NASA Honors Apollo Engineer, 2003
- Computer History Museum — Margaret Hamilton
- Computer History Museum — Oral History of Margaret Hamilton
태그: #마거릿해밀턴 #Apollo11 #NASA #소프트웨어공학 #우선순위스케줄링 #MIT #우주개발

댓글을 남기려면 로그인이 필요합니다.
로그인하고 댓글 남기기