오늘날 신뢰성 있는 소프트웨어를 위한 마가렛 해밀턴의 아폴로 교훈

왜 마가렛 해밀턴이 여전히 신뢰성에서 중요한가\n\n마가렛 해밀턴은 MIT 기기 연구소(나중의 드레이퍼 연구소)에서 NASA의 아폴로 임무를 위한 온보드 비행 소프트웨어를 이끈 인물입니다. 그녀가 ‘혼자서’ 현대 소프트웨어 엔지니어링을 발명한 것은 아니지만, 그녀의 작업과 리더십은 복잡한 시스템을 압박 속에서도 신뢰할 수 있게 유지하는 규율적 관행의 가장 분명한 사례 중 하나로 남아 있습니다.\n\n## 신뢰성, 쉽게 말하면\n\n소프트웨어 신뢰성은 제품이 기대한 대로 동작하고, 상황이 엉망일 때도 계속 동작한다는 뜻입니다: 과도한 트래픽, 잘못된 입력, 부분적 장애, 인간의 실수, 놀라운 엣지 케이스 등. 단순히 ‘버그가 적다’가 아닙니다. 시스템이 예측 가능하게 동작하고, 안전하게 실패하며, 빠르게 복구할 것이라는 확신입니다.\n\n## 왜 아폴로가 유용한 사례 연구인가\n\n아폴로는 명확성을 강제하는 제약들이 있었습니다: 제한된 컴퓨팅 성능, 비행 중에 ‘핫픽스’를 할 수 없음, 실패의 결과가 즉각적이고 치명적이라는 점. 이런 제약은 팀을 정확한 요구사항, 엄격한 변경 통제, 계층화된 테스트, 무엇이 잘못될 수 있는지에 대한 집착으로 밀어넣었습니다.\n\n이 교훈은 로켓을 만들지 않는 팀에도 적용됩니다. 현대 팀은 매일 사람들이 의존하는 시스템을 배포합니다—결제, 의료 포털, 물류, 고객 지원 도구, 또는 마케팅 스파이크 중의 회원가입 흐름 등. 위험의 크기는 다를 수 있지만 패턴은 동일합니다: 신뢰성은 마지막 순간의 테스트가 아니라 좋은 결과를 반복 가능하게 만드는 공학 방식입니다.\n\n## 아폴로의 제약과 그것이 규율을 강제한 이유\n\n아폴로 소프트웨어는 가장 문자 그대로 안전-중요(safety-critical)했습니다: 단순히 비즈니스 프로세스를 지원하는 수준이 아니라 우주선을 항해, 착륙, 도킹하는 동안 우주비행사의 생명을 지키는 데 관여했습니다. 잘못된 값, 놓친 타이밍, 혼란스러운 표시 하나가 사소한 버그가 아니라 임무 결과를 바꿀 수 있었습니다.\n\n### ‘나중에 고치자’ 여유가 없게 만든 제약들\n\n아폴로의 컴퓨터는 극히 제한된 계산 능력과 메모리를 가졌습니다. 모든 기능은 희소한 자원을 두고 경쟁했고, 추가 명령 하나에도 실질적 비용이 있었습니다. 팀은 더 큰 서버나 더 많은 메모리로 비효율을 ‘가릴’ 수 없었습니다.\n\n중요한 점은, 비행 중에 패치하는 것이 정상적인 옵션이 아니었다는 것입니다. 우주선이 발사된 후 업데이트는 절차, 통신 한계, 임무 일정으로 인해 위험하고 제약이 많았습니다. 신뢰성은 설계 단계에서 내장되고 발사 전에 입증되어야 했습니다.\n\n### 실패의 비용이 프로세스를 형성했다\n\n실패 비용이 인명, 임무 상실, 국가적 신뢰도 등으로 측정될 때, 규율은 선택사항이 아닙니다. 명확한 요구사항, 신중한 변경 통제, 엄격한 테스트는 관료적 습관이 아니라 불확실성을 줄이는 실용적 도구였습니다.\n\n아폴로 팀은 스트레스받는 사람이 시스템과 예기치 않은 방식으로 상호작용할 것임을 가정해야 했습니다. 이는 소프트웨어를 더 명확한 동작과 안전한 기본값으로 몰아갔습니다.\n\n### 오늘날 우리가 복사할 수 있는 것과 없는 것\n\n대부분의 현대 제품은 그 정도로 안전-중요하지 않고, 우리는 자주 업데이트를 배포할 수 있습니다. 그것은 실제로 이점입니다.\n\n하지만 복사해야 할 교훈은 ‘모든 앱을 아폴로처럼 취급하라’가 아니라 운영 환경을 중요하게 여기고 위험에 맞게 규율을 맞추라는 것입니다. 결제, 의료, 운송, 인프라와 같은 분야에는 아폴로급 엄격함이 여전히 적용됩니다. 위험이 낮은 기능에는 더 빠르게 움직이되 같은 사고방식—실패를 정의하고, 변경을 통제하며, 배포 전에 준비성을 증명하는 것—을 유지할 수 있습니다.\n\n## 프로덕션 준비성: 테스트 뒤의 진짜 목표\n\n테스트는 필요하지만 결승선이 아닙니다. 아폴로의 작업은 진짜 목표가 프로덕션 준비성임을 일깨웁니다: 소프트웨어가 실제 조건(엉망인 입력, 부분적 장애, 사람의 실수)에서도 안전하게 동작할 수 있는 순간입니다.\n\n### “프로덕션 준비”가 의미하는 것(‘테스트 통과’ 이상의 것)\n\n시스템이 프로덕션 준비되었다는 것은 다음을 평이한 언어로 설명할 수 있을 때입니다:\n\n- 무엇을 반드시 해야 하고 무엇을 절대 해서는 안 되는지. 이 요구사항은 기능뿐 아니라 성공과 실패 조건을 정의합니다.\n- 이미 알고 있는 위험들. 모든 위험을 제거할 수는 없지만, 준비성은 위험이 이름 붙여지고 한계가 정해지며 의도적으로 수용되었음을 의미합니다.\n- 문제를 감지하고 복구하는 방법. 새벽 2시에 무언가가 터졌을 때 계획이 운에 의지하거나 집단 기억에만 기대서는 안 됩니다.\n\n### ‘놀람 없음’ 릴리스\n\n아폴로 시대의 규율은 예측 가능성을 목표로 했습니다: 변경은 최악의 시점에 알 수 없는 동작을 도입하면 안 됩니다. ‘놀람 없음’ 릴리스는 팀이 답할 수 있는 릴리스입니다: 무엇이 바뀌었나? 무엇에 영향을 줄 수 있나? 문제가 생기면 어떻게 빨리 알 수 있나? 이 답들이 애매하면 릴리스는 준비되지 않은 것입니다.\n\n### 주의할 일반적인 준비성 간극\n\n강력한 테스트 스위트도 실무적 간극을 가릴 수 있습니다:\n\n- 모니터링이 없다거나 노이즈가 많음(사용자가 고통받는지 알 수 없음)\n- 소유권 불명확(알림이 울릴 때 책임질 사람이 없음)\n- 롤백 또는 안전한 대체 경로 없음(실패가 되돌릴 수 없게 됨)\n- 존재하지 않거나 현실과 맞지 않는 런북\n\n프로덕션 준비성은 테스트 더하기 명확성: 명확한 요구사항, 가시적 위험, 그리고 안전으로 돌아가는 리허설된 방법입니다.\n\n## 명확한 요구사항과 실패 조건에서 시작하기\n\n“요구사항”은 기술적으로 들릴 수 있지만 아이디어는 단순합니다: 소프트웨어가 ‘정확하다’고 간주되기 위해 무엇이 참이어야 하는가.\n\n좋은 요구사항은 어떻게 만들지(방법)를 설명하지 않습니다. 관찰 가능한 결과를 명시합니다—사람이 검증할 수 있는 것. 아폴로의 제약은 이 사고방식을 강제했습니다. 우주선에선 논쟁의 여지가 없습니다: 시스템이 정의된 조건 내에서 동작하거나 그렇지 않거나입니다.\n\n### 모호함은 숨은 실패 모드를 만든다\n\n모호한 요구사항은 눈에 보이는 위험을 숨깁니다. 요구사항이 “앱은 빠르게 로드되어야 한다”라고만 하면 ‘빠르게’가 무엇인지—1초인지, 5초인지, 느린 Wi‑Fi나 오래된 기기에서인지—명확하지 않습니다. 팀은 서로 다른 해석을 배포하고 그 차이가 실패로 이어집니다:\n\n- 사용자가 플로우를 이탈한다.\n- 지원 티켓이 급증한다.\n- ‘드문’ 엣지 케이스가 반복적인 사고로 변한다.\n\n모호함은 테스트도 망칩니다. 아무도 무엇이 반드시 일어나야 하는지 말할 수 없다면 테스트는 의견 모음이 됩니다.\n\n### 효과가 있는 경량 관행\n\n정확하기 위해 방대한 문서가 필요하지 않습니다. 작은 습관으로 충분합니다:\n\n- 수용 기준(acceptance criteria): 짧은 합격/불합격 명세\n- 구체적 예시: “Given X, when Y, then Z.” 형식\n- 엣지 케이스: 빈 입력, 타임아웃, 더블 클릭, 낮은 배터리, 이벤트 순서가 뒤바뀐 경우 등 실제로 일어나는 이상 상황\n\n### 재사용 가능한 간단한 템플릿\n\n다음 템플릿을 사용해 변경 또는 개발 전에 명확성을 강제하세요:\n\n```text

User need: Success condition (what must be true): Failure condition (what must never happen, or what we do instead): Notes / examples / edge cases: