요약
아폴로 계획의 비행 소프트웨어를 이끈 마거릿 해밀턴이 90세로 세상을 떠났습니다.
MIT가 10월 7일 낸 부고에 따르면 해밀턴은 9월 30일 숨졌습니다. 그는 MIT 계측연구소에서 NASA 아폴로 계획의 소프트웨어 개발을 이끌었고, 소프트웨어 공학을 하나의 분야로 세우는 데 앞장섰습니다.
왜 중요한가
- 소프트웨어가 하드웨어보다 가볍게 여겨지던 때, "소프트웨어 공학"이라는 말을 내세워 정식 공학 분야로 인정받게 했습니다.
- 오류를 미리 막는 그의 설계는 방어적 프로그래밍(사람의 실수까지 예상해 막아 두는 작성법)의 초기 사례로 꼽힙니다.
- 아폴로 코드 출력물 옆에 선 사진과 레고 피규어로 과학기술계 여성의 상징이 됐습니다.
핵심 내용
- 1965년 MIT 아폴로 프로젝트의 첫 프로그래머로 합류해 유인 비행 소프트웨어 팀을 이끌었고, 400명 넘는 인원을 총괄했습니다.
- 아폴로 11호 착륙 중 "1202" 과부하 경보가 울렸지만, 우선순위 설계 덕분에 컴퓨터가 급하지 않은 작업을 버려 착륙을 계속할 수 있었습니다.
- 네 살 딸이 시뮬레이터에서 낸 오류를 막자는 제안은 거절됐다가, 아폴로 8호에서 같은 오류가 실제로 나자 받아들여졌습니다.
- 1959년에는 기상학자 에드워드 로렌즈의 날씨 예측 프로그램을 짰고, 이 작업은 훗날 그의 카오스 이론 연구에 쓰였습니다.
- 1976년 하이어 오더 소프트웨어를 세웠고, 2016년 버락 오바마 대통령에게서 대통령 자유훈장을 받았습니다.
HN 반응
- 여러 이용자가 HN 상단에 추모의 검은 띠를 달자고 했고, "소프트웨어 공학"이란 말을 그가 처음 썼다는 인터뷰와 출처도 이어졌습니다.
- 스티븐 레비의 『해커스』 속 일화에서 해커들이 망친 날씨 프로그램이 그의 것이라는 지적에, 당시 해커 문화를 두고 의견이 갈렸습니다.
저는 그분과 MIT 계측연구소/드레이퍼 연구소에서 일하던 다른 분들을 직접 만나 뵐 기회가 있었습니다. 제가 몸담았던 스타트업이 아폴로 시대 드레이퍼 연구소 출신들이 세운 벤처캐피털에서 투자를 받았거든요. 그분들과 이야기를 나누려니 제가 감히 낄 자리가 아니라는 생각뿐이었습니다. 30년 전 일인데, 형식화된 제어 시스템에 대해 말씀하시던 게 기억납니다. 흥미롭긴 했지만 제 머리로는 도무지 따라갈 수 없었습니다. 제 스타트업은 꽤 시시한 멀티미디어 CD-ROM 회사였고, 저는 그 자리에 앉아 있는 것만으로도 좋았습니다.
이 슬픈 소식에 달린 어떤 댓글보다 이 이야기를 진솔하게 나눠 주신 게 정말 좋았습니다. 생각보다 훨씬 즐겁게 읽었습니다. 감사합니다.
관련 글:
Margaret Hamilton Led the NASA Software Team That Landed Astronauts on the Moon - https://news.ycombinator.com/item?id=36720448 - 2023년 7월 (댓글 32개)
Margaret Hamilton oral history (2017) - https://news.ycombinator.com/item?id=30668338 - 2022년 3월 (댓글 7개)
An interview with Margaret Hamilton - https://news.ycombinator.com/item?id=20453737 - 2019년 7월 (댓글 12개)
Grace Hopper and Margaret Hamilton Awarded Presidential Medal of Freedom - https://news.ycombinator.com/item?id=12991524 - 2016년 11월 (댓글 70개)
Profile of Margaret Hamilton, programmer of the Apollo software - https://news.ycombinator.com/item?id=10379904 - 2015년 10월 (댓글 58개)
Margaret Hamilton, lead software engineer, Project Apollo - https://news.ycombinator.com/item?id=8735912 - 2014년 12월 (댓글 94개)
아폴로 같은 프로젝트가 중요한 건 비범한 사람들이 자기 역량을 마음껏 쓸 수 있게 해 주기 때문이라고 생각합니다.
제 경험으로나 주변 사람들 얘기로나, 기업 세계는 인재를 다루는 데 번번이 애를 먹습니다. 괴짜 천재가 난해한 일을 하는 얘기가 아닙니다. 아주 평범하지만 유능한 사람이 탄탄한 근거로 사업에 실제로 도움이 되는 포괄적인 일을 하려는 경우를 말하는 겁니다. 그런데도 일을 아주 단순하게 눈높이를 낮춰서 해야 합니다. 조직이 현재 수준에서 조금씩만 바뀌는 것을 받아들이도록 짜여 있기 때문입니다.
문제는 '이런 조직이 뛰어난 결과물을 낼 수 있느냐'만이 아니라 '품질 좋은 결과물을 낼 수 있느냐'이기도 합니다. 평범한 일을 제대로 해내고 사람들에게 좋은 경험을 주는 데도 큰 자부심을 가질 수 있다고 생각합니다.
이번 주말에 대형 체인 호텔에 묵었는데 숙박 자체는 좋았고 직원들도 훌륭했습니다. 그런데 사소한 기술 문제가 한두 가지가 아니었습니다. USB 충전기는 접촉이 불량해서 밤새 휴대폰을 꽂아 뒀는데도 충전이 안 됐고, 다음 날 아침에야 커넥터를 비틀어야 작동한다는 걸 알았습니다. 그다음에 Steam Deck [1]으로 와이파이에 접속하려니 호텔 리워드 프로그램에 가입하라며 개인 정보를 요구하더군요. 그런데 주(州)를 고르는 자바스크립트 기반의 복잡한 드롭다운 메뉴가 거의 먹통이었습니다. 1분쯤 씨름한 끝에 엉뚱한 주는 고를 수 있었지만 제가 사는 주는 고를 수 없어서, 그 주의 우편번호를 찾아 입력했습니다.
집에 돌아오니 "[email protected]"에서 메일이 와 있었습니다. 고객님이 완벽한 경험을 하기를 바란다, 의견을 간절히 듣고 싶다며 호들갑을 떨더군요. 그래요, 800번 번호로 전화해서 제대로 한마디 해 달라는 거겠죠.
이게 거슬리는 이유는 제가 하루 종일 자바스크립트 앱 문제를 고치는 사람이라 그런 과하게 복잡한 드롭다운을 훤히 알기 때문입니다. 직원이 실수하면 책임을 묻겠지만, 기술 문제는 날씨처럼 어쩔 수 없는 것으로 취급하는 느낌입니다.
[1] 흔치 않은 기기이긴 합니다. 하지만 저는 이제 노트북을 들고 다니지 않고, 5G가 되는 곳에서는 휴대폰을 와이파이에 연결할 필요도 없고, 아이폰은 연결할 수도 있고 안 할 수도 있습니다. HTML 기본 <select>를 썼으면 그냥 '잘 됐을' 텐데요. 요즘은 CSS로 그걸 꾸밀 방법도 아주 많습니다.
맞아요, 아폴로 같은 프로젝트는 목적지와 비전이 워낙 가슴 뛰고 깊이가 있어서, 제멋대로인 사람들을 한 방향으로 몰아가는 강제 장치 역할을 합니다.
수십 년 커리어에서 제가 가장 크게 배운 건, 가장 어려운 일이 사람들이 자발적으로 같은 방향으로 나아가게 만드는 거라는 점입니다. 사람마다 동기는 늘 다르거든요. 한 방향을 억지로 밀어붙이는 리더십은 충분한 관점을 고려하지 못해 거의 항상 실패합니다. 그렇다고 대안인 의도된 리좀형 혼돈이나 살벌한 경쟁은 사기를 완전히 꺾어 놓을 수 있고요.
아폴로 프로그램 코드 책자 옆에 서 있는 그분의 모습은 평생 제 머릿속에 남을 겁니다.
https://news.mit.edu/2016/scene-at-mit-margaret-hamilton-apollo-code-0817
그 사진들이 돌아다니는 걸 볼 때마다 저는 꼭 시간을 들여 한참 들여다봅니다.
그토록 뛰어난 사람, 그토록 놀라운 업적을 남긴 분이 재미있고 엉뚱한 사진 촬영에도 기꺼이 응했다니요. 인간미가 느껴지는 멋진 순간이고, 컴퓨터 과학의 역사가 근본적으로 사람의 이야기라는 걸 다시 떠올리게 합니다.
공유해 주셔서 감사합니다. 이 사진들에서 그분의 정말 아름다운 면모가 배어 나오네요.
아이콘이죠.
제 기억이 맞다면 "소프트웨어 엔지니어"라는 말을 처음 만든 사람이 마거릿 해밀턴입니다. 편히 쉬시길.
맞아요! 몇 년 전에 그 출처를 직접 추적해 봤는데, 무명에 가까운 교재를 위해 진행한 인터뷰였어요. 더 알고 싶은 분이 계실까 해서 제 블로그에 다시 올려 뒀습니다. https://catskull.net/interview-with-margaret-h-hamilton.html
궁금한데, 그 교재는 어떻게 구하셨어요?
대단하네요. 저희가 볼 수 있게 공개해 주셔서 정말 감사합니다.
이 용어가 나중에 웹사이트 버튼 색깔이나 바꾸는 사람들한테 갖다 쓰일 줄은 꿈에도 몰랐겠죠.
그만큼 많은 사람이 문턱을 높이기도 하고요. 그분이 어느 쪽을 더 못마땅해했을지 궁금하네요. 제가 알기로 그분은 소프트웨어를 만드는 사람들의 위상을 높이고 싶었던 거지, 선을 긋고 싶었던 게 아닙니다.
저라면 '엔지니어'라는 호칭은 문턱이 있었으면 좋겠습니다.
용어가 흔히 간과되는 분야의 위상을 높이는 데 도움이 될 수는 있지만, 프로그래머를 모두 '소프트웨어 엔지니어'라고 부르면 특별한 일을 구분할 방법이 없어지니까요.
일부 나라에서는 보호되는 호칭이지만 영국은 아닙니다(미국도 아닌 것 같고요?).
유럽 일부 국가에서는 전문가 단체 회원이 아니면 어떤 종류의 '엔지니어'도 자칭할 수 없다고 알고 있습니다.
그렇게 됐다면 아이러니하게도 Margaret Hamilton은 그 용어를 만들 수 없었겠네요.
미국, 중국, 인도에서는 보호되는 호칭이 아닙니다. 그런데 이 세 나라가 전 세계가 쓰는 소프트웨어를 가장 많이 만드는 나라라고 할 수 있죠. 어느 정도 연관이 있다고 봅니다.
문턱을 두는 게 특히 가치 있는 쪽은 스스로를 차별화할 수단이 있는 사람들이라는 건 쉽게 알 수 있습니다. 하지만 제품을 만들거나 쓰려는 나머지 사람들에게는, 분야의 문이 열려 있는 쪽과 닫혀 있는 쪽 중 어느 쪽이 더 이로울까요?
그 호칭이 전문 기준에 뒷받침되고, 그 기준에 따라 호칭을 잃을 수도 있고 법적 책임도 질 수 있다면, 문턱이 가치 있다고 볼 수 있습니다. 누가 소프트웨어를 쓸 수 있는지를 제한하는 데 쓰인다면 해롭다고 보고요.
그게 문제를 풀어 보는 가장 좋은 방식 같네요. 앞서 제 주장에 반박하자면, 자격을 얻는 길이 누구에게나 열려 있기만 하다면 기준을 집행하는 장치가 꼭 배타적일 필요는 없습니다. 이제는 누구나 코드를 이해하지 못한 채 만들어 낼 수 있으니, 어느 때보다 더 중요할 겁니다.
소프트웨어와 무관한 일부 업계에서도 직함에 '엔지니어'를 쓰는 일이 흔합니다. 제가 일했던 시추 회사의 기계 감독관은 (시추용) 머드 '엔지니어'를 늘 머드 영업사원이라고 불렀습니다. 제품을 더 팔려고만 들었거든요.
미국에서 보호되는 건 'Engineer'가 아니라 P.E.입니다.
P.E. 면허는 특정한 일을 할 때만 필요합니다. 예를 들어 일부 관할 구역에서는 일정 높이나 연면적을 넘는 건물의 설계도에 면허를 가진 P.E.의 서명이 있어야 합니다.
모든 공학 분야가 P.E. 시험으로 다뤄지는 것도 아니고요.
유럽에 있었다면 아예 아폴로 프로젝트에 참여하지 못했을 겁니다. 소프트웨어 공학 같은 새로운 분야를 만들어 내야 할 만큼 최첨단이었던 프로젝트였고, 그래서 그 용어가 처음 나올 수 있었던 거죠.
프랑스에서는 전문가 단체 회원이어야 하는 게 아니라, 엔지니어 학위가 있어야 엔지니어라고 불릴 수 있습니다.
석사 학위이긴 한데 모든 석사가 엔지니어 학위는 아닙니다. 그랑제콜 과정입니다.
그리고 맞습니다, 프랑스 소프트웨어 엔지니어 대부분은 엔지니어 학위가 있습니다.
AI 시대가 된 지금은 이런 논쟁이 이미 탁상공론 같네요.
정말요?
엔지니어가 전혀 관여하지 않고 AI로 만든 비행기를 타는 건 어떨 것 같으세요?
지금은 별로죠. 내일은 사람이 만든 것보다 나을 거고요.
그 내일이 언제인데요?
그럼 소프트웨어에서 쓰는 이 용어에 진짜 엔지니어들이 불만을 가져도 괜찮다는 건가요? 문턱을 두자는 입장이시니까요. '엔지니어'는 소프트웨어가 생기기 훨씬 전부터 쓰던 말입니다. 문턱을 지지한다면 엔지니어링은 '코드'가 아닌 '실제 작업'을 가리키게 두고, '원래 의미'를 집어삼키지 않는 새 용어를 찾아야죠.
아니면 사회와 기술이 변하듯 용어도 변한다는 걸 그냥 받아들이든가요.
말이 너무 뒤죽박죽이네요. 소프트웨어 이전에는 모든 일이 물리적인 작업이었다는 뜻인가요? 아니죠, 엔지니어들은 예전에도 지금도 제도판 앞에서 많은 시간을 보냅니다. 다만 개 그림에 공구함 스티커가 붙은 플라스틱 테이블에 앉아 있지 않을 뿐이죠.
항공이나 원자로 소프트웨어처럼 자신과 고용주 바깥에서 정해진 규칙과 관행을 따르지 않는다면, 그건 엔지니어링일 가능성이 아예 없습니다. '소프트웨어 엔지니어링'이라고는 할 수 있겠죠. '소프트웨어 아키텍트'가 '아키텍트'가 아닌 것과 똑같이요.
https://ncees.org/wp-content/uploads/Software-Engineering-exam-news-release.pdf
같은 엄격함을 원하지 않는다면, 같은 엄격함을 감당하지 못한다면, 같은 존중을 받을 수 없습니다. 그럴 자격이 없으니까요.