엔지니어링 철학: 마거릿 해밀턴

핵심 요점

• 그녀는 이 분야가 정당성을 인정받도록 “소프트웨어 엔지니어링”이라는 용어를 만들었습니다. MIT 계측 연구소(MIT Instrumentation Laboratory)에서 아폴로 비행 소프트웨어 작업을 이끌던 시절, 마거릿 해밀턴은 이 일을 “소프트웨어 엔지니어링”이라고 부르기 시작했습니다. 소프트웨어가 부차적인 것으로 취급되던 시대에, 사람을 달까지 보내는 코드를 작성하는 일이 하드웨어 및 시스템 엔지니어링과 똑같은 엄격함과 존중을 받을 자격이 있다고 주장하기 위한 의도적인 선택이었습니다.¹²
• 유도 컴퓨터가 1202와 1201 경보를 띄웠을 때, 그녀의 소프트웨어가 아폴로 11호 착륙을 구했습니다. 최종 하강 중, 잘못 설정된 랑데부 레이더 스위치가 아폴로 유도 컴퓨터(Apollo Guidance Computer)에 결코 처리하지 말았어야 할 가짜 작업을 떠넘겼고, 익스큐티브는 이를 스케줄링할 메모리가 바닥났습니다. 바로 그 유명한 1202(“core set 없음”)와 1201(“VAC area 없음”) 경보입니다. 해밀턴의 팀이 소프트웨어를 우선순위 스케줄링과 재시작 보호 방식으로 구축해 두었기 때문에, 컴퓨터는 낮은 우선순위의 레이더 작업을 떨궈내고 착륙에 결정적인 유도 작업을 계속 돌렸으며, 착륙은 성공했습니다.³⁴⁵
• 그녀를 규정하는 신념은 방어적 설계입니다. 두 번째 기회가 없으므로 실패 상황을 염두에 두고 설계하라는 것입니다. “두 번째 기회는 없었습니다. 우리는 그것을 알고 있었습니다.”라고 그녀는 아폴로에 대해 말했습니다.² 오류 탐지, 복구, 비동기 우선순위 스케줄링, 그리고 사람이 개입하는 디스플레이는 정상 경로가 작동한 뒤에 덧붙인 기능이 아니었습니다. 그것들이 설계의 중심이었고, 소프트웨어가 충돌하는 대신 우아하게 성능을 낮추며 버틴 이유였습니다.⁶
• 그녀는 정확성을 처음부터 내장했습니다 – “사전 개발(Development Before the Fact)”. 아폴로 이후 그녀는 Higher Order Software(1976)와 Hamilton Technologies(1986)를 설립하여 Universal Systems Language(USL)와, 오류의 한 부류 전체를 테스트로 잡아내는 것이 아니라 애초에 구조적으로 불가능하게 만드는 시스템 설계 방법론을 개발했습니다. 그녀는 NASA Exceptional Space Act Award(2003)와 대통령 자유 훈장(Presidential Medal of Freedom, 2016)을 받았습니다.¹⁶

원칙

“두 번째 기회는 없었습니다. 우리는 그것을 알고 있었습니다. 우리는 일을 진지하게 받아들였고, 우리 중 많은 사람이 아직 20대일 때 이 여정을 시작했습니다.” – 마거릿 해밀턴, 아폴로 비행 소프트웨어에 대하여²

대부분의 엔지니어링은 모든 것이 잘 작동하는 경우에 맞춰 최적화됩니다. 정상 경로를 만들고, 상상할 수 있는 몇 가지 오류를 처리하고, 출시합니다. 그리고 프로덕션에서 무언가 망가지면, 패치하고 다시 배포합니다. 거의 모든 소프트웨어가 그 안에서 살아가는 안락함이 바로 그 순환입니다. 항상 다음 기회가 있기에 실패는 복구 가능합니다. 해밀턴의 작업은 그 반대 전제에서 출발했습니다. 그녀가 이끈 소프트웨어는 세 사람을 지구에서 40만 킬로미터 떨어진 곳까지 날려 보내고 그중 두 명을 달에 착륙시킬 예정이었으며, 패치도, 재배포도, 다음 기회도 없었습니다. 누구도 완전히 예행연습할 수 없는 조건에서, 멜로디를 연주하는 연하장보다 적은 메모리를 가진 컴퓨터 위에서, 단번에 작동해야 했습니다.² 잡아내지 못한 단 하나의 오류가 치르는 대가가 승무원의 목숨일 때, “실패 상황을 염두에 두고 설계하라”는 더 이상 좋은 조언이 아니라 일 전체가 됩니다.

여기서 따라 나오는 원칙은 방어적 설계를 뒷정리가 아니라 설계의 중심으로 삼는 것입니다. 소프트웨어가 예상치 못한 상황을 견뎌야 한다면, 오류를 탐지하고, 거기서 복구하고, 우아하게 성능을 낮추는 일은 작동하는 경로를 완성한 뒤에 추가하는 기능일 수 없습니다. 그것들은 작동하는 경로가 매달리는 골격이어야 합니다. 해밀턴의 팀은 아폴로 소프트웨어를, 컴퓨터가 처리 능력을 넘는 일을 요구받고 있음을 알아차리고, 중요하지 않은 작업을 내버리고, 알려진 정상 상태로 깨끗하게 재시작하고, 멈추면 승무원을 죽일 그 한 가지 일을 계속하도록 만들었습니다. 시스템은 모든 실패를 피하도록 만들어진 것이 아니었습니다. 그렇게 작은 기계로, 그렇게 가차 없는 임무에 맞서서는 그럴 수 없습니다. 실패가 닥쳤을 때 그 실패가 살아남을 수 있는 것이 되도록 만들어졌습니다.³⁶

이 원칙에는 후반부가 있으며, 그것이야말로 전반부를 현실로 만드는 부분입니다. 끝에서 버그를 테스트로 걸러내는 것이 아니라 처음부터 정확성을 내장하라는 것입니다. 런타임에 오류를 탐지하고 복구하는 것은 최후의 방어선입니다. 더 깊은 규율은, 오류의 한 부류 전체가 애초에 발생할 수 없도록 시스템을 설계하는 것입니다. 해밀턴은 경력의 후반부를 정확히 이것을 형식화하는 데 바쳤습니다. “사전 개발(Development Before the Fact)”이라 부른 방법론과, 인터페이스 오류를 구조적으로 불가능하게 만들기 위해 만든 언어가 그것입니다.⁶ 이 두 절반은 두 거리에서 본 하나의 발상입니다. 두 번째 기회가 없을 때, 당신은 런타임에서 방어하고 동시에 설계 시점에 그 실패를 표현 불가능하게 만듭니다. 완전히 신뢰할 수 있는 유일한 오류는 시스템이 애초에 만들 수 없었던 오류이기 때문입니다.

배경

마거릿 해밀턴은 1936년 8월 17일 인디애나주 파올리(Paoli)에서 마거릿 히필드(Margaret Heafield)라는 이름으로 태어났습니다.¹ 그녀는 Earlham College에서 수학을 공부해 1958년에 철학을 부전공으로 하여 학위를 받았습니다. 이 조합은 훗날 그녀가 시스템을 코드만큼이나 깊이 사고하는 방식에서 드러납니다.¹ 그녀는 컴퓨터 과학이라는 경로를 통해 아폴로에 이른 것이 아니었습니다. 1950년대 후반에는 그런 것이 존재하지 않았기 때문입니다. 그녀는 수학을 통해, 그리고 일 자체를 통해 그곳에 도달했습니다.

그녀의 첫 프로그래밍은 처음부터 현실 세계의 일이었고 위험 부담이 컸습니다. 1959년 그녀는 MIT 기상학과에서 카오스 이론의 창시자 에드워드 로렌즈(Edward Lorenz)와 함께 일하며 LGP-30과 PDP-1에서 기상 예측 소프트웨어를 작성하기 시작했습니다.¹ 대략 1961년부터 1963년까지 그녀는 MIT 링컨 연구소(MIT Lincoln Laboratory)의 SAGE 프로젝트에서 미 공군이 접근하는 항공기를 탐지하는 데 사용한 AN/FSQ-7 컴퓨터용 소프트웨어를 작성했습니다.¹ SAGE는 지금까지 만들어진 최초의 대규모 실시간, 고장에 민감한 소프트웨어 시스템 중 하나였으며, 그녀가 그곳에서 – 가장 어렵고 실패하기 쉬운 코드를 맡는 것으로 – 얻은 명성이 그녀를 아폴로로 데려왔습니다.

1965년 그녀는 MIT 계측 연구소(MIT Instrumentation Laboratory)(훗날 Draper Lab)에 합류했습니다. 이곳은 NASA 아폴로 프로그램의 탑재 비행 소프트웨어를 구축하는 계약을 맡고 있었습니다. 그녀는 소프트웨어 엔지니어링 부서(Software Engineering Division)를 이끄는 위치까지 올라, 사령선과 달 착륙선 양쪽의 아폴로 유도 컴퓨터에서 돌아가는 탑재 비행 소프트웨어를 책임지는 팀을 이끌었습니다.¹ 바로 이곳에서, 그 작업의 한복판에서 그녀는 “소프트웨어 엔지니어링”이라는 용어를 사용하기 시작했습니다. 유행어로서가 아니라 하나의 주장으로서였습니다. 그녀의 표현을 빌리면, 그녀는 이 용어를 “하드웨어 및 다른 종류의 엔지니어링과 구별하면서도, 각 유형의 엔지니어링을 전체 시스템 엔지니어링 과정의 일부로 다루기 위해” 사용했습니다.¹ 소프트웨어는 이름을, 그리고 그 이름에 따라오는 엄격함을 가질 자격이 있는 분야라고 그녀는 주장했습니다. 아폴로 이후 그녀는 1976년에 Higher Order Software를, 1986년에 Hamilton Technologies를 설립하여 Universal Systems Language와 “사전 개발(Development Before the Fact)” 방법론을 개발했습니다.¹⁶

작업

아폴로 11호 1202 경보: 우선순위 스케줄링과 재시작 보호

여기서 시작하겠습니다. 이것은 가능한 최악의 압박 아래에서 원칙이 메커니즘으로 구현된 사례이기 때문입니다. 아폴로 유도 컴퓨터는 작은 기계였습니다. 수십 킬로바이트의 메모리에, 현대적 의미의 운영 체제는 없었으며, 해밀턴의 팀이 설계한 실시간 익스큐티브를 돌렸습니다. 작업을 실행하려면 익스큐티브는 여유 메모리를 찾아야 했습니다. “core set”(작업 상태를 담는 작은 블록), 그리고 부동소수점 연산을 하는 작업의 경우 “VAC area”입니다.⁴ 작업이 스케줄링되었는데 여유 core set이 없으면, 익스큐티브는 경보 루틴으로 분기하여 경보 1202를 띄웠습니다. VAC area가 없으면 1201을 띄웠습니다.⁴ 이것들은 충돌 코드가 아니었습니다. 익스큐티브가 처리 능력 이상을 요구받았다고 알리고서, 그에 대해 무언가 조치를 취하는 것이었습니다.

아폴로 11호 하강의 마지막 몇 분 동안, 정확히 그 일이 벌어졌습니다. 우주비행사 체크리스트는 승무원이 랑데부 레이더 스위치를 잘못된 위치에 두게 했고, 이로 인해 레이더가 프로세서 사이클을 가로채면서 익스큐티브가 결코 돌아가지 말았어야 할 데이터 처리 작업을 반복적으로 스케줄링하게 만들었습니다.³⁴ 그 가짜 작업이 여유 메모리를 모두 소모했고, 1202 경보가 발생했습니다. 그러고는 다시 발생했고, 1201 경보도 함께, 착지 직전 몇 초 동안 네 번이나 울렸습니다. 모든 것을 하라고 요구받은 순진한 컴퓨터였다면 모든 것을 하려 들었을 테고, 정작 중요한 그 한 가지 작업에서 뒤처져 멈춰버렸을 것입니다. 해밀턴의 컴퓨터는 그러지 않았습니다.

두 가지 설계 결정이 착륙을 구했습니다. 첫 번째는 우선순위 스케줄링이었습니다. 익스큐티브는 작업을 우선순위에 따라 실행했고 가장 낮은 우선순위의 작업을 떨궈낼 수 있었기에, 착륙에 결정적인 유도와 승무원 디스플레이(DSKY)는 항상 돌아간 반면 쓸모없는 레이더 작업은 굶주리게 되었습니다.³⁵ 두 번째는 재시작 보호였습니다. 각 경보는 과부하된 작업 큐를 비우고 알려진 정상 상태로 재부팅하는 소프트웨어 재시작을 촉발하여, “하강 엔진 조종이나 DSKY 운영 같은 중요한 것들”은 재시작했지만 잘못 스케줄링된 레이더 작업은 재시작하지 않았습니다.⁴⁵ 컴퓨터는 사실상 잡음을 버리고, 우주선을 계속 조종했으며, 자신이 처리하고 있다고 승무원에게 알렸습니다. 그래서 관제 센터는, 더 못한 설계였다면 중단을 의미했을 경보에 대해 “go”를 외칠 수 있었던 것입니다.

이것이 엔지니어링으로서 중요한 이유: 경보는 실패가 아니었습니다. 설계된 대로 작동하는 실패 처리였습니다. 팀은 익스큐티브가 과부하를 예상하고, 그 아래에서 분류하고, 거기서 복구하도록 구축했으며, 그 복구를 너무나 철저히 테스트했기에 관제사들은 그 어떤 소프트웨어가 받아본 것보다 큰 압박 아래에서 그것을 신뢰했습니다. 그것이 한 순간에 담긴 교리 전체입니다. 실패는 전제되었고, 실패 상황이 설계의 중심이었으며, 시스템은 쓰러지는 대신 “승무원을 살리는 일만 하기”로 성능을 낮추었습니다. 같은 본능이 오늘날 부하를 떨궈내는 모든 우선순위 큐, 충돌한 워커를 깨끗한 상태로 재시작하는 모든 슈퍼바이저, 압도당하는 상황을 견디도록 만들어진 모든 시스템에 살아 있습니다.

“소프트웨어 엔지니어링”이라는 말을 만들고 정당성을 위해 싸우다

1202 이야기는 유명합니다. 하지만 이름 짓기가 어쩌면 더 큰 결과를 낳았습니다. 1960년대에 소프트웨어는 “진짜” 엔지니어링의 무르고 진지하지 못한 형제로 널리 취급되었습니다. 하드웨어가 설계된 후에 알아서 하는 것이지, 그 자체의 엄격함을 갖춘 분야가 아니었습니다. 해밀턴은 그 틀을 거부했습니다. 아폴로 안에서 그녀는 이 작업을 의도적으로 “소프트웨어 엔지니어링”이라고 부르기 시작했으며, 그 이유를 분명히 밝혔습니다. “하드웨어 및 다른 종류의 엔지니어링과 구별하면서도, 각 유형의 엔지니어링을 전체 시스템 엔지니어링 과정의 일부로 다루기” 위해서였습니다.¹ 요점은 어휘가 아니었습니다. 요점은 지위였습니다. 임무를 수행하게 한 코드가 엔지니어링이라면, 그것은 엔지니어링의 규율을 받을 자격이 있었습니다. 명세, 검토, 테스트, 추적 가능성, 그리고 단지 돌아가게 만들어지는 것이 아니라 정확하게 만들어져야 한다는 기대 말입니다.

그녀는 이 용어가 처음에는 웃음거리가 되었다고 말한 적이 있습니다. 소프트웨어가 “엔지니어링”일 수 있다는 발상이 사람들에게는 억지스럽게 느껴졌던 것입니다.¹ 그러나 그녀가 싸워 얻으려 한 정당성은 하중을 지탱하는 것이었습니다. 팀에게 실패 상황을 염두에 두고 설계하라고, 시스템의 뼈대에 오류 복구를 짜 넣으라고, 정확성을 타협 불가능한 것으로 다루라고 요구할 수는 없습니다 – 그 작업이 누군가 나중에 정리할 가벼운 스크립트 작성쯤으로 여겨진다면 말입니다. 분야에 이름을 붙이는 것은 그것을 어떤 기준에 붙들어 두기 위한 전제 조건이었습니다. 그 10년이 끝나갈 무렵 이 용어는 MIT를 벗어나 하나의 분야의 이름이 되었습니다. 오늘날 “소프트웨어 엔지니어링”은 너무나 평범해서 눈에 보이지 않을 정도이며, 이것이야말로 그 주장이 승리했다는 가장 확실한 징표입니다.¹²

방어적 설계: “로런 버그”와 인간에 맞서는 엔지니어링

해밀턴의 사고방식을 가장 선명하게 들여다보는 창은 “로런 버그(Lauren bug)”입니다. 그녀의 어린 딸 로런은 가끔 연구소에 와서 사령선 시뮬레이터에서 우주비행사 놀이를 하곤 했는데, 어느 날 시뮬레이터를 멈추게 했습니다. 시뮬레이션 우주선이 이미 달로 비행하는 도중에 발사 전 프로그램인 P01을 선택해서였습니다.⁷ 비행 도중에 발사 전 초기화를 불러오자 항법 데이터가 지워졌고 컴퓨터는 길을 잃었습니다. 해밀턴의 본능은 “어떤 우주비행사도 절대 그러지 않을 것”이 아니었습니다. 그것은 이러했습니다. 시뮬레이터가 아이에게 그것을 허용했다면, 소프트웨어가 그것을 허용한 것이고, 소프트웨어가 허용하는 것은 결국 언젠가 일어난다. 그녀는 비행 중 P01 선택을 막는 오류 탐지 코드를 추가하자고 제안했습니다.⁷

그녀의 제안은 기각되었습니다. 우주비행사는 그런 실수를 결코 하지 않을 훈련된 전문가라는 이유로 말입니다. 그녀에게는 문서에 주석을 다는 것만 허락되었습니다.⁷ 그런데 바로 다음 임무인 아폴로 8호에서, 짐 러벨(Jim Lovell)이 로런이 했던 바로 그 일을 했습니다. 인류 최초의 달 일주 비행 도중에 P01을 선택해 항법 데이터를 지운 것입니다.⁷ 그 후에 수정이 들어갔습니다. 해밀턴이 끌어내어 거듭 강조한 교훈은 방어적 설계의 핵심입니다. 어떤 실패가 “일어날 수 없다”고 결정하고서 일어나지 않을 것처럼 설계해서는 안 된다는 것입니다. 우주비행사, 레이더 스위치, 새벽 3시의 운영자 – 시스템은 인간이 완벽하리라 가정하고 책임에서 보호받을 것이 아니라, 개입하는 인간에 맞서 견고해야 합니다. 그녀의 우선순위 디스플레이는 반대 방향에서 같은 발상을 구현했습니다. 인간을 정보가 닿는 통제 위치에 두어, 컴퓨터가 과부하 아래에서 작업을 분류할 때 승무원이 그것이 무엇을 하는지 이해하고 결정할 수 있게 한 것입니다.⁶

Higher Order Software, USL, 그리고 “사전 개발”

아폴로는 해밀턴에게 오류가 어디서 오는지 가르쳐 주었고, 그녀는 남은 경력 전체를 그 오류를 근원에서 공격하는 데 바쳤습니다. 아폴로의 오류를 연구하면서, 그녀는 그 오류의 상당 부분이 개별 모듈 안이 아니라 모듈 사이의 인터페이스에서 산다는 것을 관찰했습니다. 한 소프트웨어 조각이 다른 조각에 데이터를 건넬 때 가정이 정확히 맞아떨어지지 않는 지점 말입니다. Higher Order Software(1976)에서, 그리고 이어서 Hamilton Technologies(1986)에서 그녀는 그 오류들을 테스트로 잡아내는 것이 아니라 구성을 통해 제거하는 작업 체계를 구축했습니다.¹⁶

이 방법론은 “사전 개발(Development Before the Fact)”이라 불립니다. 그 이름이 곧 주장입니다. 시스템을 만든 뒤에 사후적으로 결함을 사냥하는 대신, Universal Systems Language(USL)라는 형식 체계를 사용해 시스템을 너무나 엄격하게 정의함으로써, 오류의 한 부류 전체 – 특히 인터페이스 및 통합 오류 – 가 구조적으로 불가능해지도록 하는 것입니다. 이 모델은 입증 가능하게 일관되며, 거기서 정확한 코드를 생성할 수 있어서, 결함은 런타임에 발견되는 대신 설계 시점에 예방됩니다.⁶ 이것은 아폴로 익스큐티브와 똑같은 확신을 한 단계 더 깊이 밀어붙인 것입니다. 런타임 복구는 안전망이지만, 진짜 승리는 애초에 그 오류를 만들 수 없었던 시스템입니다. 업계 대부분은 여전히 반대의 순환을 돌립니다 – 출시하고, 버그를 찾고, 패치하기 – 그리고 그것이야말로 정확성이 진짜로 중요할 때는 거꾸로 된 것이라고 해밀턴이 30년간 주장한 바로 그 순환입니다.

방법론

아폴로 익스큐티브, “소프트웨어 엔지니어링”이라는 말의 창안, 로런 버그, 그리고 사전 개발을 가로질러 읽으면, 같은 신념들이 거듭 나타납니다. 해밀턴의 방법론은 구호라기보다는 일련의 변함없는 습관입니다.

실패 상황을 먼저 설계하라 – 두 번째 기회는 없다. 아폴로 익스큐티브는 과부하 처리를 덧붙인 스케줄러가 아니었습니다. 과부하를 견디는 것이 곧 설계였습니다. 달 위에서 멈춘 컴퓨터는 승무원을 죽이기 때문입니다.³⁴ 그 교훈은 우주 비행을 한참 넘어 옮겨집니다. 작동하는 경로를 쓰기 전에 시스템이 어떻게 실패하는지 열거하고, 이미 실패를 견디는 구조에서 작동하는 경로가 흘러나오게 하라는 것입니다. 이것은 신뢰성에 적용된 증거 관문입니다 – “시뮬레이터에서 작동한다”는 증거가 아닙니다. “레이더가 넘쳐날 때 부하를 떨궈내고 계속 비행한다”가 증거입니다 – 수십 년 뒤 베르너 포겔스(Werner Vogels)가 클라우드의 창립 전제로 삼은 우아한 성능 저하와 똑같은 기준입니다.

인간이 불가능한 일을 하리라 가정하라. 로런 버그는 그 규칙의 축소판입니다. 시스템이 위험한 행동을 허용하면, 누군가 – 아이, 우주비행사, 지친 운영자 – 결국 그것을 하게 되므로 “아무도 그러지 않을 것”은 방어가 아닙니다.⁷ 변함없는 습관은, 결코 도착할 수 없다고 보장받은 입력에 맞서 경계를 지키는 것입니다. 가장 크게 다치게 하는 실패는 일어날 수 없다고 미리 결정해 둔 실패이기 때문입니다. 이것은 라디아 펄먼(Radia Perlman)이 노드가 거짓말을 해도 정확함을 유지하는 라우팅에 심어 넣은, 적대자에 맞서는 견고함의 본능과 똑같습니다.

부하 아래에서 분류하라 – 중요하지 않은 것을 떨궈내고, 결정적인 것을 보호하라. 익스큐티브는 메모리가 바닥났을 때 모든 요청을 처리하려 하지 않았습니다. 가장 높은 우선순위의 작업을 돌리고 나머지를 굶긴 뒤, 깨끗하게 재시작했습니다.³⁵ 규율은, 결코 멈춰서는 안 되는 그 한 가지가 무엇인지 미리 정하고, 압박 아래에서 그 한 가지를 계속 돌리기 위해 다른 모든 것을 희생하도록 시스템을 구축하는 것입니다. 우선순위가 없는 시스템은 승무원 디스플레이와 쓸모없는 레이더 작업을 동등하게 대했기에 가장 나쁜 순간에 실패하는 시스템입니다.

정확성을 내장하라, 테스트로 집어넣지 마라. 사전 개발은 출시-후-디버그 순환에 대한 거부입니다. 시스템을 만든 뒤에 오류를 사냥하는 대신, 오류를 표현할 수 없도록 시스템을 정의하는 것입니다.⁶ 교훈은, 가장 값싸고 가장 신뢰할 수 있는 결함은 설계가 불가능하게 만든 결함이라는 것입니다 – 바버라 리스코프(Barbara Liskov)가 타입 규율과 추상화로 전환한, 그리고 레슬리 램포트(Leslie Lamport)가 코드를 작성하기 전에 정확성을 정밀하게 명세하는 것으로 전환한 똑같은 확신입니다. 이것은 워크플로로 만들어진 품질이 유일한 변수다입니다. 정확성은 끝에 오는 한 단계가 아니라, 처음부터 그 사물의 형태입니다.

기준에 붙들어 둘 수 있도록 분야에 이름을 붙여라. 이 작업을 “소프트웨어 엔지니어링”이라 부른 것은 나머지 모든 것 – 명세, 검토, 엄격함의 기대 – 을 가능케 한 행위였습니다.¹ 변함없는 습관은, 작업에 이름과 기준이 있다고 주장하는 것입니다. 조직이 일회용으로 여기는 것에는 장인 정신을 요구할 수 없기 때문입니다. 이것은 최소한의 가치 있는 제품(minimum worthy product)의 정신입니다. 그 사물은 제대로 할 가치가 있으므로 제대로 하고, 제대로 하는 것이 유일하게 받아들일 만한 방식이라고 소리 내어 논증하는 것입니다.

영향의 사슬

그녀를 빚어낸 것들

MIT의 수학과 실시간 전통. 해밀턴은 수학을 거쳐, 그리고 SAGE – 최초의 대규모 실시간, 실패에 민감한 소프트웨어 시스템 중 하나 – 를 거쳐, 그리고 카오스 이론의 창시자 에드워드 로렌즈와의 기상 모델링을 거쳐 성장했습니다.¹ 그 토대가 드러납니다. 그녀는 아폴로에 이르기 훨씬 전부터, 소프트웨어를 누구도 완전히 예측할 수 없는 조건에서 정확함을 유지해야 하는 시스템으로 사고했습니다. (형성적 영향)

우주 비행 그 자체의 가차 없는 규율. 아폴로 임무는 그 어떤 사람 못지않은 스승이었습니다. 단 하나의 오류가 승무원의 목숨을 앗아가는 영역, 패치도 두 번째 기회도 없는 영역은 하나의 일하는 방식을 강요합니다 – 실패 상황을 방어하고, 런타임에 복구하고, 설계 시점에 오류를 예방하라 – 평범한 소프트웨어는 결코 요구하지 않는 것입니다.² 제약이 철학을 빚었습니다. (직접적 영향)

아폴로 프로그램의 시스템 엔지니어링 문화. 그녀의 소프트웨어가 하드웨어, 관제 센터, 인간의 절차와 통합되어야 하는 프로그램 안에서 일한 경험은, 그녀가 소프트웨어를 여러 엔지니어링 분야 가운데 하나로 보도록 밀어붙였습니다 – 이것이 바로 “소프트웨어 엔지니어링”을 “전체 시스템 엔지니어링 과정”의 일부로 명명한 그녀의 발상 뒤에 있는 틀입니다.¹ (형성적 영향)

그녀가 빚어낸 것들

소프트웨어 엔지니어링이라는 분야 그 자체. 그 시대 가장 위험 부담이 큰 소프트웨어 프로젝트 안에서 이 분야에 이름을 붙이고 그 엄격함을 옹호함으로써, 해밀턴은 프로그래밍을 부차적인 것에서 명세, 검토, 정확성의 기대를 갖춘 엔지니어링 분야로 바꾸는 데 일조했습니다.¹²

모든 결함 허용 실시간 시스템. 우선순위 스케줄링, 부하 떨궈내기, 알려진 정상 상태로의 재시작, 그리고 사람이 개입하는 디스플레이 – 아폴로 익스큐티브가 1202 경보를 견디는 데 사용한 패턴들 – 은 이제 비행 제어부터 과부하 아래에서 웹 서비스를 살려두는 슈퍼바이저에 이르기까지, 회복력 있는 시스템의 표준 어휘입니다.³⁶

형식적, 구성에 의한 정확성 보장 방법. 사전 개발과 Universal Systems Language는, 정확성은 사후에 테스트로 집어넣는 것이 아니라 설계되고 입증되어야 한다고 주장하는 계보의 일부입니다 – 오늘날까지 형식 방법론과 모델 주도 개발을 관통하는 주장입니다.⁶

관통하는 줄기

해밀턴은 이 시리즈에서 신뢰성 계보의 기원점입니다 – “실패 상황을 염두에 두고 설계하라”가 선호가 아니라 타협 불가능한 것이 된 지점, 목숨이 거기 걸려 있었기에, 나머지 분야가 따라잡기 수십 년 전에 그렇게 된 곳입니다. 베르너 포겔스는 “모든 것은 항상 실패한다”를 토대로 클라우드를 구축하고 행성 규모에서 우아한 성능 저하를 설계했습니다. 해밀턴은 서류 가방 크기의 컴퓨터 위에서, 그 위에 탄 승무원과 함께, 우아한 성능 저하를 설계했고, 진정으로 두 번째 기회가 없을 때 그 교리가 작동함을 증명했습니다.³ 라디아 펄먼은 스스로 치유하고 노드가 거짓말을 해도 정확함을 유지하는 네트워크를 구축했습니다. 해밀턴의 익스큐티브는 달 위에서 실시간으로 스스로 치유했습니다. 깨끗하게 재시작하고, 망가진 레이더가 먹인 거짓말을 떨궈내면서 말입니다.⁴ 그리고 레슬리 램포트는 정확성을, 구축하기 전에 정밀하게 정의하고 입증하는 것으로 만들었습니다 – 이것이 바로 사전 개발이 한 세대 앞서, 같은 목표를 겨누며 도달하려 한 것입니다.⁶ 포겔스가 모든 것은 실패하니, 그것을 뚫고 가용성을 유지하라고 말하고 펄먼이 스스로 치유하도록 만들라고 말하는 곳에서, 해밀턴은 가장 먼저 그리고 가장 단호하게 말했습니다. 두 번째 기회는 없으니, 실패가 일어나기 전에 그것을 염두에 두고 설계하고, 일어나면 거기서 복구하고, 최악의 오류는 애초에 불가능하도록 시스템을 구축하라. (시리즈 가교)

내가 여기서 얻는 것

해밀턴에게서 내가 계속 간직하는 교훈은, 분명히 두 번째 기회가 있을 때조차 두 번째 기회가 없는 것처럼 구축하라는 것입니다. 내가 출시하는 거의 모든 것은 그녀가 갖지 못한 안락함 안에서 살아갑니다. 망가지면 수정을 밀어 넣으면 됩니다. 그 안전망은 실재하며, 조용히 기준을 낮춥니다. 정상 경로를 출시하고서 실패 상황은 나중에 처리하겠다고 스스로에게 말하게 만듭니다. 나중이 존재하기 때문입니다. 아폴로는 그 질책입니다. 진정으로 패치할 수 없을 때, “실패는 나중에 처리하라”가 애초에 엔지니어링이 전혀 아니었음을 깨닫게 됩니다. 실패 상황이 곧 엔지니어링이고, 작동하는 경로는 시스템이 이미 망가짐을 견디고 난 뒤에 남은 것에 불과합니다. 그래서 이제 무언가를 구축할 때 – 넘쳐날 수 있는 작업, 잘못 호출될 수 있는 API, 잘못된 시점에 진입될 수 있는 경로 – 나는 정상 경로가 작동하는지 묻기 전에 “여기서 잘못된 위치에 놓인 레이더 스위치는 무엇이며, 이것은 그것을 떨궈내고 계속 비행하는가?”를 물으려 합니다. 올바른 입력만 견디는 시스템은 내가 아직 끝내지 못한 시스템입니다.

두 번째 교훈은, 가장 신뢰할 수 있는 오류는 설계가 불가능하게 만든 오류라는 것입니다. 로런 버그가 내게 남아 있는 이유는, 해밀턴이 옳았는데도 “아무도 그러지 않을 것”이라는 이유로 기각되었기 때문입니다 – 그리고 우주는 곧바로, 바로 다음 임무에서 그것을 했습니다. 내 본능은 런타임에 오류를 잡는 것입니다. 위험한 호출을 가드로 감싸고 넘어가는 것이죠. 해밀턴의 더 깊은 수, 그녀가 30년을 바친 그것은, 위험한 호출 자체를 할 수 없도록 시스템을 설계하는 것입니다 – 나쁜 상태를 단지 탐지하는 것이 아니라 표현 불가능하게 만드는 것입니다. 런타임 복구는 그물입니다. 정확성을 내장하는 것은 그물이 필요 없도록 그 위에 서는 바닥입니다. 나는 늘 그 기준에 도달하지는 못하지만, 그것은 목표를 다시 짜놓았습니다. 질문은 “이것이 잘못될 때 내가 잡아낼 것인가?”만이 아니라 “애초에 잘못될 수 없도록 이것을 빚을 수 있는가?”입니다 – 그리고 두 번째 질문은, 내가 답할 수 있을 때, 언제나 더 나은 질문입니다.

자주 묻는 질문

마거릿 해밀턴이 “소프트웨어 엔지니어링”이라는 용어를 만들었나요?

마거릿 해밀턴은 “소프트웨어 엔지니어링”이라는 용어를 만든 – 적어도 대중화한 – 인물로 널리 인정받으며, 그녀는 1960년대에 MIT 계측 연구소에서 아폴로 비행 소프트웨어 작업을 이끌며 이 용어를 사용하기 시작했습니다.¹² 그녀는 소프트웨어 작성이 하드웨어 및 다른 엔지니어링 분야와 똑같은 정당성과 엄격함을 받을 자격이 있다고 주장하기 위해 이 용어를 의도적으로 사용했으며, “하드웨어 및 다른 종류의 엔지니어링과 구별하면서도, 각 유형의 엔지니어링을 전체 시스템 엔지니어링 과정의 일부로 다루고” 싶었다고 설명했습니다.¹ 당시에는 소프트웨어가 “엔지니어링”일 수 있다는 발상이 다소 웃음거리가 되었습니다. 오늘날 이 용어는 너무나 표준적이어서 눈에 보이지 않을 정도이며, 이것이 그 주장이 얼마나 철저히 승리했는지를 보여주는 척도입니다.¹

아폴로 11호의 1202와 1201 경보는 무엇이었나요?

그것들은 달 하강의 마지막 몇 분 동안 아폴로 유도 컴퓨터의 익스큐티브가 띄운 프로그램 경보였습니다. 잘못 설정된 랑데부 레이더 스위치가 레이더로 하여금 프로세서 사이클을 가로채게 했고, 익스큐티브가 돌아가지 말았어야 할 데이터 처리 작업을 반복적으로 스케줄링하게 만들어 여유 메모리를 모두 소모했습니다.³⁴ 메모리 “core set”이 없을 때 익스큐티브는 경보 1202를 띄웠고, “VAC area”가 없을 때는 1201을 띄웠습니다.⁴ 이 경보들은 충돌이 아니었습니다 – 익스큐티브가 처리 능력 이상을 요구받았다고 보고하고서 분류 작업을 하는 것이었습니다. 소프트웨어가 우선순위 스케줄링과 재시작 보호를 사용했기 때문에, 가짜 레이더 작업을 떨궈내고, 알려진 정상 상태로 재시작했으며, 착륙에 결정적인 유도와 승무원 디스플레이를 계속 돌렸고, 착륙은 성공했습니다.³⁵

마거릿 해밀턴은 아폴로 프로그램을 위해 무엇을 했나요?

해밀턴은 1965년에 MIT 계측 연구소에 합류하여, 사령선과 달 착륙선 양쪽의 아폴로 유도 컴퓨터에서 돌아가는 탑재 비행 소프트웨어를 책임지는 소프트웨어 엔지니어링 부서를 이끄는 위치까지 올랐습니다.¹ 그녀의 팀은 비동기 우선순위 스케줄링, 재시작 보호, 오류 탐지 및 복구, 그리고 우주비행사가 정보를 알고 통제할 수 있게 하는 우선순위 디스플레이를 갖춘 실시간 익스큐티브를 설계했습니다 – 아폴로 11호 컴퓨터가 1202 경보를 견디고 착륙을 완수할 수 있게 한 아키텍처입니다.³⁶ 그녀의 대통령 자유 훈장 표창은 “비동기 소프트웨어, 우선순위 스케줄링과 우선순위 디스플레이, 그리고 사람이 개입하는 의사결정 능력이라는 개념들에 기여하여, 현대적이고 초고신뢰 소프트웨어 설계 및 엔지니어링의 토대를 놓았다”고 그녀의 공로를 인정합니다.⁶

“사전 개발(Development Before the Fact)”이란 무엇인가요?

“사전 개발”은 해밀턴이 아폴로 이후 Higher Order Software와 Hamilton Technologies에서 개발한 시스템 방법론으로, 그녀의 Universal Systems Language(USL)를 중심으로 구축되었습니다.¹⁶ 그 주장은, 시스템을 만든 뒤에 테스트를 통해 “사후적으로” 결함을 사냥하는 대신, 시스템을 너무나 엄격하고 형식적으로 정의함으로써 오류의 한 부류 전체 – 특히 그녀가 아폴로 결함을 지배한다고 발견한 인터페이스 및 통합 오류 – 가 구성을 통해 구조적으로 불가능해지도록 한다는 것입니다.⁶ 이 모델은 입증 가능하게 일관되며 거기서 정확한 코드를 생성할 수 있어서, 결함은 런타임에 발견되는 대신 설계 시점에 예방됩니다. 이것은 그녀의 아폴로 확신을 형식 방법론으로 표현한 것입니다. 가장 신뢰할 수 있는 오류는 시스템이 애초에 만들 수 없었던 오류라는 것입니다.

출처