
MIT가 컴퓨팅 선구자 마거릿 해밀턴(Margaret Hamilton)의 별세 소식을 전했어요. 이름은 낯설어도 사진 한 장은 아마 보셨을 거예요. 자기 키만큼 쌓인 종이 더미 옆에 서서 웃고 있는 여성 사진이요. 그 종이 더미는 아폴로 우주선에 들어간 소프트웨어 코드를 출력한 것이고, 사진 속 주인공이 바로 해밀턴이에요.
우리는 매일 ‘소프트웨어 엔지니어’라는 직함을 쓰는데요, 이 말이 자리 잡는 데 가장 앞장선 사람 중 하나가 그녀예요. 오늘은 부고 기사 대신, 개발자 눈으로 그녀가 남긴 것들을 하나씩 짚어볼게요.
코드가 ‘공학’ 대접을 못 받던 시절
1960년대에는 소프트웨어를 하드웨어에 딸린 부속품 정도로 여겼어요. 로켓이나 회로를 만드는 게 진짜 공학이고, 프로그래밍은 그걸 돌리는 잡일이라는 인식이었죠. 해밀턴은 MIT 계측연구소(지금의 드레이퍼 연구소)에서 아폴로 비행 소프트웨어 개발을 이끌면서 자기 팀의 일을 ‘소프트웨어 엔지니어링’이라고 부르기 시작했어요. 처음엔 다들 농담으로 받아들였대요. 하지만 그녀는 사람 목숨이 걸린 코드라면 설계와 검증, 테스트까지 다른 공학 분야만큼 엄격해야 한다고 생각했어요. 지금 우리가 당연하게 여기는 개발 문화가 이 생각에서 시작됐다고 봐도 돼요.
당시 환경을 알면 더 놀라워요. 아폴로 유도 컴퓨터(AGC)는 RAM이 약 4KB, 프로그램 저장 공간이 약 72KB밖에 안 됐어요. 프로그램은 ‘코어 로프 메모리’에 저장됐는데요, 이게 뭐냐면 전선을 작은 자석 고리 안으로 통과시키면 1, 바깥으로 지나가게 하면 0이 되도록 작업자가 손으로 일일이 엮어 만든 메모리예요. 말 그대로 코드를 뜨개질한 거죠. 한번 엮고 나면 고치기가 거의 불가능해서 버그 하나가 몇 주짜리 재작업으로 이어졌어요. “일단 배포하고 핫픽스하자”는 생각은 할 수도 없는 환경이었던 거예요.
1202 알람: 우선순위 설계가 착륙을 살린 순간
1969년 7월, 아폴로 11호 착륙선이 달 표면으로 내려가던 중에 컴퓨터에서 ‘1202’, ‘1201’ 알람이 연달아 울렸어요. 랑데부 레이더 쪽 설정 문제로 필요 없는 신호가 계속 들어오면서 컴퓨터가 처리할 일이 감당할 수 없을 만큼 쌓인 거예요. 요즘 말로 하면 CPU 과부하죠.
보통 컴퓨터였다면 여기서 멈춰버렸을 거예요. 해밀턴 팀이 만든 소프트웨어는 작업마다 우선순위를 매겨 뒀기 때문에, 과부하가 오자 덜 중요한 작업은 버리고 착륙에 꼭 필요한 작업만 다시 살려서 이어갔어요. 알람으로는 “문제가 생겼지만 핵심 기능은 돌아가고 있다”는 사실을 사람에게 알렸고요. 덕분에 관제센터는 착륙을 계속해도 된다고 판단할 수 있었어요.
이게 지금 우리가 우아한 성능 저하(graceful degradation)나 부하 차단(load shedding)이라고 부르는 개념이에요. 트래픽이 몰리면 추천 기능은 잠깐 끄고 결제만 살려두는 서비스, 쿠버네티스가 우선순위 낮은 파드부터 내보내는 동작이 다 같은 아이디어거든요. 50여 년 전에 4KB 메모리로 그걸 해낸 거예요.
“사람은 실수한다”를 전제로 한 설계
유명한 일화가 하나 더 있어요. 해밀턴의 어린 딸이 시뮬레이터를 가지고 놀다가 비행 도중에 발사 전 프로그램(P01)을 실행해서 시스템을 망가뜨렸대요. 해밀턴은 이런 실수를 막는 코드를 넣자고 했지만 “우주비행사는 그런 실수를 하지 않도록 훈련받는다”는 대답을 들었어요. 그런데 아폴로 8호 비행 중에 짐 러벨이 정말 그 실수를 했고, 항법 데이터가 날아가서 팀이 급하게 복구 방법을 찾아야 했어요. 이 일 이후로 이런 방어 로직은 있으면 좋은 게 아니라 반드시 있어야 하는 게 됐어요. “사용자 입력은 절대 믿지 마라”는 원칙을 이보다 극적으로 보여준 사례는 드물 거예요.
업계 맥락: 개척자들 사이에서 그녀의 자리
컴퓨팅 역사에는 컴파일러 개념을 밀어붙인 그레이스 호퍼, 궤도 계산으로 우주 프로그램을 받쳐준 캐서린 존슨 같은 이름이 있어요. 해밀턴이 남긴 건 조금 결이 달라요. 무엇을 계산하느냐보다 큰 소프트웨어가 어떻게 하면 실패하지 않느냐를 하나의 체계로 만든 사람이거든요. ‘소프트웨어 공학’이라는 말은 1968년 NATO 학회를 계기로 널리 퍼졌다는 설명도 많은데요, 해밀턴은 아폴로라는 실전에서 그 방법론이 통한다는 걸 증명했다는 점에서 의미가 커요.
아폴로 이후에는 Higher Order Software와 Hamilton Technologies를 세우고, 설계 단계에서부터 오류를 막자는 ‘Development Before the Fact’ 개념과 USL(Universal Systems Language)을 연구했어요. 2016년에는 미국 대통령 자유훈장도 받았고요.
한국 개발자에게 주는 시사점
먼저 GitHub에 공개된 아폴로 11호 소스 코드(chrislgarry/Apollo-11)를 한번 열어보시길 추천해요. 어셈블리라서 낯설겠지만 주석만 훑어봐도 재밌거든요. “BURN, BABY, BURN” 같은 장난스러운 주석 사이로, 극한의 제약 속에서 얼마나 치밀하게 고민했는지가 보여요.
실무에서는 이런 질문으로 이어볼 수 있어요. 장애가 나면 무엇부터 살릴지 미리 정해두었나요? 사용자가 엉뚱한 버튼을 눌러도 시스템이 버티나요? 에러 메시지가 운영자에게 판단할 근거를 주나요? 1202 알람은 단순한 에러 코드가 아니라 “지금 이런 상황인데 핵심은 괜찮다”는 신호였어요. 우리 서비스의 알림도 그만큼 친절한지 돌아볼 만해요.
마무리
한 줄 정리: 마거릿 해밀턴은 코드를 ‘공학’으로 만든 사람이고, 우리가 ‘소프트웨어 엔지니어’라는 이름으로 일할 수 있는 것도 그녀 덕분이 커요.
여러분이 겪은 장애 중에 우선순위 설계만 있었어도 버텼겠다 싶은 순간이 있었나요? “사용자는 절대 그렇게 안 쓸 거야”라고 했다가 크게 당한 경험도 좋아요. 댓글로 나눠주세요.
🔗 출처: Hacker News