▲

우주선 설계의 법칙 (Akin's Laws of Spacecraft Design)

 (ece.uvic.ca)
17P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 우주선 설계 및 엔지니어링 프로젝트에 적용되는 40가지 실용적 원칙을 정리한 슬라이드
  • 수치 기반 분석, 반복적 설계, 결함 허용 설계를 핵심 원칙으로 강조
  • 일정은 한 방향으로만 움직이며, 초기 추정치는 항상 과소평가된다는 현실적 경고 포함
  • 우주공학을 넘어 소프트웨어·시스템·스타트업 설계 전반에 그대로 적용 가능
  • 공학적 판단에서 반복적으로 발생하는 오류를 예방하는 현실적 체크리스트

법칙 1 — 수치로 증명되는 공학

  • "Engineering is done with numbers. Analysis without numbers is only an opinion."
    • 공학은 수치로 수행됨, 수치 없는 분석은 의견에 불과
  • 공학도가 수학을 배우는 데 많은 시간을 투자하는 이유
  • 공학적 성공은 정량화 가능해야 함
    • "내 시스템이 더 빠르다" → 얼마나 더 빠른가?
    • "내 시스템이 더 저렴하다" → 비용이 얼마인가?
    • "내 시스템이 더 단순하다" → 단순함을 어떻게 측정하는가?

법칙 2 — 결함 허용 설계

  • "To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong."
    • 우주선을 제대로 설계하려면 무한한 노력이 필요하므로, 일부가 잘못되어도 작동하도록 설계해야 함
  • 100% 신뢰성을 요구하는 시스템 설계 금지
  • 실패 사례: Deep Water Horizon, 후쿠시마
  • 항공기 제어 시스템의 3중 논리 점검(3 way logic checking) 방식 예시

법칙 3 — 반복적 설계 과정

  • "Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time."
    • 설계는 반복적 과정이며, 필요한 반복 횟수는 현재까지 수행한 횟수보다 항상 하나 더 많음
  • 좋은 설계는 결코 완성되지 않음

법칙 4 — 실망에 대처하기

  • "Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment."
    • 최선의 설계 노력이 최종 설계에서 쓸모없게 될 수 있음, 실망에 대처하는 법을 배워야 함
  • Bhargava의 법칙: 연구 프로젝트 10개 중 1개만 산업 실무에 적용
  • 최고의 상업적 성공은 최고의 기술 설계가 아님
    • 예시: Nokia N95 vs 1세대 iPhone

법칙 5 (Miller의 법칙) — 세 점이 곡선을 결정

  • "Three points determine a curve."
    • 세 점이 곡선을 결정
  • 데이터 세트에서 항상 패턴을 찾게 됨
  • 그 패턴이 측정 노이즈가 아닌 실제 연구 대상 현상에 의한 것인지 확인 필요
  • 학계와 대학원생들이 특히 이 규칙을 무시하는 경향

법칙 6 (Mar의 법칙) — 데이터 과적합 경계

  • "Everything is linear if plotted log-log with a fat magic marker."
    • log-log 그래프에서 굵은 매직펜으로 그리면 모든 것이 선형으로 보임
  • Bigg의 법칙: "수학적 도구에 빠지지 말 것, 도구가 되돌려 사랑해주지 않음"
  • 데이터 과적합(over-fit) 금지

법칙 7 — 리더십과 팀 구성

  • "At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it."
    • 설계 프로젝트 시작 시 팀 리더가 되고 싶어하는 사람이 가장 능력이 부족할 가능성이 높음
  • Dilbert 만화는 실제 엔지니어링 회사 경험을 약간 과장한 것에 기반
  • 리더십의 일부는 타고나지만, 상당 부분은 학습해야 함
  • 관리자가 '기본을 존중(respect the basics)'하지 못하는 경우 존재
    • 산업공학자에게 MBA에 대해 물어볼 것

법칙 8 — 최적점은 중간에 존재

  • "In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point."
    • 자연에서 최적점은 거의 항상 중간 어딘가에 존재, 극단점이 최적이라는 주장은 의심해야 함
  • 표준 예시: 최적 전력 전송(Optimal power transfer)
  • 실습 예시: 최적 센서 저항(optimal sensor resistance)

법칙 9 — 정보 부족은 핑계가 아님

  • "Not having all the information you need is never a satisfactory excuse for not starting the analysis."
    • 필요한 모든 정보가 없다는 것은 분석을 시작하지 않는 만족스러운 변명이 될 수 없음
  • 더 완전한 분석을 위해 어떤 값이 필요한지 파악해야 함

법칙 10 — 추정과 추측

  • "When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along."
    • 의심스러우면 추정하고, 긴급 상황에서는 추측하되, 실제 수치가 나오면 반드시 돌아가서 정리해야 함
  • 엔지니어로 훈련받는 것이지, 점술사가 아님
  • 이 직업에서는 빠른 사고보다 양질의 사고가 더 중요

법칙 11 — 처음부터 다시 시작

  • "Sometimes, the fastest way to get to the end is to throw everything out and start over."
    • 때로는 끝에 도달하는 가장 빠른 방법은 모든 것을 버리고 처음부터 다시 시작하는 것
  • 언제 이렇게 해야 하는지 배우는 데 시간이 걸림
  • 많은 산업에서 이렇게 했어야 하지만 하지 않은 사례가 많음
    • 러시아 유인 정찰 우주정거장 Almaz: 뛰어난 기술 설계였으나, 발사 후 컴퓨터 제어 정찰 위성에 의해 구식이 됨
    • 초기 '자동차'들

법칙 12 — 단일 정답은 없음

  • "There is never a single right solution. There are always multiple wrong ones, though."
    • 단일 정답은 없으나, 여러 개의 오답은 항상 존재
  • 열린 마음 유지
  • 공학은 종교가 아님
    • 기술적 이단(Technical apostasy) 은 완전히 허용됨
  • 예시: 기계식 자동 계산
    • 2차 세계대전에서 주류 방식
    • 디지털 하드웨어가 이 분야를 장악하는 데 1960년대까지 걸림

법칙 13 — 요구사항 기반 설계

  • "Design is based on requirements. There's no justification for designing something one bit 'better' than the requirements dictate."
    • 설계는 요구사항에 기반, 요구사항이 지시하는 것보다 조금이라도 '더 좋게' 설계할 정당한 이유가 없음
  • 고객은 필요하지 않은 기능에 비용을 지불하는 것을 싫어함
  • 애플리케이션에 필요한 신뢰성을 찾고 해당 신뢰성 수준에 맞게 설계해야 함
    • 말은 쉽지만 실행은 어려움

법칙 14 (Edison의 법칙) — '더 좋음'은 '좋음'의 적

  • "'Better' is the enemy of 'good'."
    • '더 좋음'은 '좋음'의 적
  • 실제로는 Voltaire의 인용문
  • 시스템이 충분히 좋은(good enough) 상태에 도달했을 때 인식해야 함
    • 완벽함은 무한한 자원을 요구하므로 시스템은 항상 더 좋게 만들 수 있음
    • 법칙 13 참조

법칙 15 (Shea의 법칙) — 인터페이스가 핵심

  • "The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up."
    • 설계 개선 능력은 주로 인터페이스에서 발생, 이곳이 또한 망칠 수 있는 주요 위치
  • 하나의 시스템을 정말 잘 이해하는 엔지니어/기술자는 많음
  • 여러 다른 시스템을 정말 잘 이해하는 사람은 드묾
    • 예: 복잡한 하드웨어와 소프트웨어 상호작용이 있는 시스템은 대개 인터페이스에서 문제 발생

법칙 16 — 과거 분석에 대한 맹신 금지

  • "The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours."
    • 유사한 분석을 수행한 이전 사람들이 시대의 지혜에 직접 연결되어 있지 않았음, 따라서 그들의 분석을 자신의 것보다 믿을 이유가 없으며, 특히 그들의 분석을 자신의 것으로 제시할 이유는 없음

법칙 17 — 출판물의 정확성

  • "The fact that an analysis appears in print has no relationship to the likelihood of its being correct."
    • 분석이 인쇄물에 실렸다는 사실은 그것이 정확할 가능성과 무관
  • 1970년대의 유명한 의견:
    • "1200 baud가 아마도 전화 모뎀이 도달할 수 있는 최대 속도일 것"
    • "Coding is dead" 발언으로 알려짐
    • Trellis coded modulation이 1990년대까지 이 속도를 50kbps까지 끌어올림

법칙 18 — 과거 경험의 양면성

  • "Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though."
    • 과거 경험은 현실 점검을 제공하는 데 훌륭하나, 너무 많은 현실은 그렇지 않으면 가치 있는 설계를 망칠 수 있음

법칙 19 — 겸손의 중요성

  • "The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up."
    • 당신이 해당 분야의 다른 모든 사람보다 훨씬 똑똒할 확률은 매우 낮음, 분석 결과 종단 속도가 광속의 두 배라면 워프 드라이브를 발명했을 수도 있지만, 계산을 잘못했을 확률이 훨씬 높음

법칙 20 — 프레젠테이션의 중요성

  • "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
    • 나쁜 설계에 좋은 프레젠테이션은 결국 실패, 좋은 설계에 나쁜 프레젠테이션은 즉시 실패
  • 예시: Avro C102 — 세계에서 두 번째 상업용 제트 여객기 (13일 차이)
    • Avro Arrow 개발 지원을 위해 취소됨

법칙 21 — 교육의 본질

  • "Half of everything you hear in a classroom is crap. Education is figuring out which half is which."
    • 교실에서 듣는 것의 절반은 쓸모없음, 교육은 어느 절반이 어느 것인지 파악하는 것
  • 교수들이 의도적으로 50%의 시간을 낭비하려는 것이 아님
    • 빠르게 변화하고 진화하는 분야에서 어떤 기술이 필요할지 추측하는 것
  • 예시: 양자 컴퓨팅
    • 향후 20년간 엔지니어로 일하는 데 필수적인 지식이거나, 2030년대까지 학술적 관심에 불과할 수 있음

법칙 22 — 문서화의 중요성

  • "When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)"
    • 의심스러우면 문서화, 문서화 요구사항은 프로그램 종료 직후 최대치에 도달
  • 문제를 해결할 수 없다면 무지를 숨기지 말 것
    • 문제의 원인을 문서화
    • 다른 사람이 문제 해결 방법을 찾을 수 있을 수도 있음

법칙 23 — 일정의 허구성

  • "The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it."
    • 개발한 일정은 고객이 일정을 맞추지 못해 해고할 때까지 완전한 허구처럼 보일 것

법칙 24 — 작업 분류 체계

  • "It's called a 'Work Breakdown Structure' because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it."
    • 'Work Breakdown Structure(작업 분류 체계)'라고 부르는 이유는 구조를 강제하지 않으면 남은 작업이 붕괴(Breakdown)할 때까지 계속 늘어나기 때문

법칙 25 (Bowden의 법칙) — 테스트 실패 후 분석

  • "Following a testing failure, it's always possible to refine the analysis to show that you had negative margins all along."
    • 테스트 실패 후에는 항상 분석을 정제하여 처음부터 음의 마진이 있었음을 보여줄 수 있음
  • 예시: 캐나다 교통사고 조사 안전위원회 및 연방항공청(FAA) 사고 보고서
  • 일부 실패는 상상력 부족으로 인해 발생 (Frank Borman 의역)
  • 엔지니어는 실수를 저지르는 것은 용서받지만, 실수를 숨기는 것은 용서받지 못함

법칙 26 (Montemerlo의 법칙) — 멍청한 짓 금지

  • "Don't do nuthin' dumb."
    • 멍청한 짓을 하지 말 것
  • 공학 실무에서 놀라울 정도로 따르기 어려운 규칙
  • 기본을 잊지 말 것
  • 자신에게 우선순위를 명확히 할 것

법칙 27 (Varsi의 법칙) — 일정은 한 방향

  • "Schedules only move in one direction."
    • 일정은 한 방향으로만 움직임
  • 문제와 어려움에 대비한 여유를 남겨둘 것
    • 테스트 실패
    • 나중에는 가족 비상사태
  • 자신의 잘못이 아닌데 다른 사람이 필요한 제품을 늦게 전달할 수 있음
  • 항상 자신과 팀에게 일정상 여유를 남겨둘 것

법칙 28 (Ranger의 법칙) — 공짜 발사는 없음

  • "There ain't no such thing as a free launch."
    • 공짜 발사 같은 것은 없음

법칙 29 (von Tiesenhausen의 프로그램 관리 법칙) — 비용과 시간 추정

  • "To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right."
    • 최종 프로그램 요구사항의 정확한 추정을 얻으려면, 초기 시간 추정치에 π를 곱하고, 비용 추정치의 소수점을 오른쪽으로 한 자리 이동

법칙 30 (von Tiesenhausen의 엔지니어링 설계 법칙) — 아티스트 컨셉의 영향

  • "If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept."
    • 새로운 엔지니어링 시스템의 설계에 최대한 영향을 미치고 싶다면 그림 그리는 법을 배울 것, 엔지니어들은 항상 초기 아티스트 컨셉처럼 보이도록 차량을 설계하게 됨

법칙 31 (Mo의 진화적 개발 법칙) — 기술의 근본적 한계

  • "You can't get to the moon by climbing successively taller trees."
    • 점점 더 높은 나무를 올라간다고 달에 갈 수 없음
  • 기술/접근 방식의 근본적 한계를 이해하는 것이 유용

법칙 32 (Atkin의 데모 법칙) — 머피의 법칙

  • "When the hardware is working perfectly, the really important visitors don't show up."
    • 하드웨어가 완벽하게 작동할 때, 정말 중요한 방문객은 나타나지 않음

법칙 33 (Patton의 프로그램 계획 법칙) — 실행의 중요성

  • "A good plan violently executed now is better than a perfect plan next week."
    • 지금 격렬하게 실행되는 좋은 계획이 다음 주의 완벽한 계획보다 낫다
  • 산업에서의 오류: '완벽한' 기술을 기다리는 것
    • 기다리는 동안 경쟁자가 시장을 점령

법칙 34 (Roosevelt의 과제 계획 법칙) — 현실적 실행

  • "Do what you can, where you are, with what you have."
    • 있는 곳에서, 가진 것으로, 할 수 있는 것을 하라
  • SF 작가가 아닌 이상 존재하지 않는 기술을 위해 설계하는 것은 무의미

법칙 35 (de Saint-Exupéry의 설계 법칙) — 완벽한 설계

  • "A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
    • 설계자는 더 이상 추가할 것이 없을 때가 아니라, 더 이상 뺄 것이 없을 때 완벽에 도달했음을 안다

법칙 36 — 우아함, 효율성, 효과성

  • "Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective."
    • 평범한 엔지니어는 우아한 것을 설계할 수 있음, 좋은 엔지니어는 효율적인 시스템을 설계, 위대한 엔지니어는 효과적인 시스템을 설계
  • 우아한 설계(Elegant design): 표준 도시 상수도 시스템
  • 효율적 설계(Efficient design): 뉴욕 상수도 시스템
  • 효과적 설계(Effective design): 북미/남미 원주민 문명의 관개 시스템 (일부는 1000년 이상 작동 중)

법칙 37 (Henshaw의 법칙) — 책임의 명확한 선

  • "One key to success in a mission is establishing clear lines of blame."
    • 임무 성공의 핵심 중 하나는 명확한 책임 라인을 설정하는 것
  • 자신의 행동과 결정에 책임을 져야 함
  • 책임지기를 거부하는 엔지니어(또는 다른 누구든)를 신뢰하지 말 것

법칙 38 — 역량이 요구사항을 주도

  • "Capabilities drive requirements, regardless of what the systems engineering textbooks say."
    • 시스템 엔지니어링 교과서가 뭐라고 하든, 역량이 요구사항을 주도
  • 핵심은 어떤 새로운 역량이 개발되고 있는지 인식하는 것:
    • 1950년대: 트랜지스터
    • 1960년대: 집적 회로
    • 1970년대: 마이크로프로세서
    • 1980년대: 가정용 컴퓨터
    • 1990년대: 인터넷
    • 2000년대: 무선/모바일 컴퓨팅

법칙 39 — 새 발사체 개발 금지

  • 새로운 유인 우주 프로그램을 저렴하고 일정에 맞게 유지하는 세 가지 핵심:
    1. 새로운 발사체 없음
    2. 새로운 발사체 없음
    3. 무슨 일이 있어도 새로운 발사체를 개발하기로 결정하지 말 것
  • 완전히 새로운 제품이 항상 기존 제품의 진화보다 나을 것이라고 믿는 유혹을 피해야 함

법칙 40 — 우주는 용서하지 않음

  • "Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there's no partial credit because most of the analysis was right...)"
    • 우주는 완전히 용서 없는 환경, 엔지니어링을 망치면 누군가가 죽음 (대부분의 분석이 맞았다고 부분 점수는 없음)
  • 대형 엔지니어링 제어 재해:
    • 후쿠시마, 체르노빌
    • De Havilland Comet (상업용 여객기 창문에 둥근 모서리가 있는 이유)
    • Eastern Airline Flight 401 (자동 조종장치가 상업용 항공기를 에버글레이즈로 유도)
    • Therac-25 (캐나다 방사선 치료 기기)
  • Richard Feynman 의역: "자연은 속일 수 없다(Nature cannot be fooled)"
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 1990년대 Trellis coded modulation으로 50킬로보드까지 올렸다는 말은 약간 다름
    전화선의 대역폭과 SNR 특성으로 계산한 Shannon 용량은 약 30kb/s 수준이었고, V.34 모뎀은 이 한계에 근접해 33.6kb/s까지 도달했음
    하지만 80년대 이후 전화망은 ‘라스트 마일’을 제외하고는 이미 디지털화되어 있었음. ISP 측 모뎀이 디지털 오디오를 직접 출력하면 이론적으로 64kb/s까지 가능했지만, 실제로는 FCC의 전력 제한으로 약 53kb/s 정도였음
    당시 나는 모뎀 변조 연구팀에서 일했는데, 아날로그 사고방식에 익숙했던 엔지니어들이 디지털 채널의 가능성을 깨닫는 데 꽤 시간이 걸렸음
    이후 그들은 케이블 모뎀으로 넘어가 다시 아날로그 세계로 돌아갔음

    • “ISP 모뎀이 디지털 오디오를 직접 출력하면 용량이 높아진다”는 부분이 이해되지 않음
      여전히 집까지의 구간은 아날로그라면 Shannon-Nyquist 한계에 묶이지 않음?
      만약 ISP 모뎀과 홈 모뎀 사이가 필터 없는 구리선이라면, 그냥 UART로 수 Mbps 전송도 가능하지 않겠음?
      이 부분을 좀 더 명확히 설명해주길 바람
    • 1990년대 다이얼업 모뎀의 최고 속도는 실제로 56kbps였음
      Trellis 코딩을 포함한 다양한 인코딩·압축 기술 덕분이었고, 지금도 US Robotics의 56k 모뎀을 구매할 수 있음

  • Law 20은 요즘 스타트업의 현실을 정확히 표현함
    “좋은 디자인이 나쁜 프레젠테이션을 만나면 즉시 망한다”는 말처럼, 표현력의 중요성이 절대적임

    • 큰 자금을 다루는 책임자라면, 설계를 명확히 설명하지 못하는 팀에 돈을 맡기지 않을 것임
      설명을 잘한다는 건 이해하고 있다는 증거이기도 함
      “5살짜리에게 설명 못 하면 본인도 모르는 것”이라는 말이 떠오름
    • 요즘은 성공 시나리오가 회사를 키우는 것보다 기존 기업에 매각되는 것에 초점이 맞춰져 있음
    • 좋은 설계를 알아봤다면 직접 나서서 프레젠테이션을 개선해야 함. 그렇지 않으면 나쁜 설계가 채택됨
    • 세일즈맨이 세일즈맨에게 말하는 구조는 언제나 생산적인 일의 가장 불쾌한 부분임. 식당 창업도 마찬가지임

  • “가장 큰 상업적 성공이 최고의 기술 설계는 아니다”라는 말에 대해
    Nokia N95와 1세대 iPhone 비교는 적절하지 않음. 대신 나는 Canyon’s Law of Design Optimization을 제안함 — 고객이 원하는 지표와 개발자가 최적화하는 지표는 다르며, 고객이 틀렸다고 설득하려 하지 말라는 뜻임

    • 사실 N95는 초기 iPhone보다 더 많이 팔렸음
      iPhone 1세대는 형태와 인터페이스는 훌륭했지만 기능은 부족했음. 3G, GPS, 서드파티 앱, 카메라 모두 약했음
      iPhone 3G가 나오면서야 진정한 상업적 성공을 거둠
    • N95의 스펙을 보면 iPhone보다 나은 점이 많지만, 디자인과 사용성을 보면 왜 iPhone이 승리했는지 명확함
    • 오히려 이 예시는 훌륭함. 스펙이 더 좋아도 제품 경험이 우수하지 않으면 승리할 수 없음을 보여줌

  • 마지막 슬라이드가 빠져 있음
    “위의 모든 조언을 무시하고 옳은 일을 하라”는 문구가 핵심임
    서로 상충하는 조언 속에서 균형을 잡는 것이 진짜 엔지니어링이며, 기술적으로나 사회적으로 가장 어려운 목표임

    • 아마도 이것이 Law 16일 것임
      “이전 분석이 절대적 진리가 아니며, 스스로의 판단을 믿어야 함”이라는 내용임

  • 이 PDF는 새로 보이지만, Akin’s Laws of Spacecraft Design은 2003년부터 존재했음
    웹 아카이브 링크에서도 확인 가능함

  • 첫 번째 법칙만 봐도 왜 소프트웨어 “엔지니어링”이 진짜 엔지니어링이라 부르기 어려운지 알 수 있음

    • 대부분의 법칙이 소프트웨어 개발에도 그대로 적용됨. 오늘날의 ‘좋은 관행’이라 불리는 것들과 일맥상통함
    • 하지만 경영진이 모든 걸 수치화하려 들면 더 나빠짐. 직관과 감각이 필요한 영역도 있음
    • 결국 우리는 진짜 엔지니어링을 실천해 그 이름에 걸맞은 수준에 도달해야 함

  • 나는 오랫동안 von Tiesenhausen의 법칙을 인용해왔음
    “엔지니어는 결국 초기 아티스트의 콘셉트대로 설계하게 된다”는 말인데, 웹 프로젝트에서도 똑같이 느꼈음
    초기 문서를 만든 사람, 혹은 회의에서 메모를 남긴 사람이 제품의 방향을 결정짓는 경우가 많음.
    ‘애자일’이라 해도 실제로는 경로 의존적임

  • MIT에서 2003년 우주선 설계 캡스톤 수업을 들었는데, 이 리스트는 본 적이 없음
    당시 프로젝트는 위성 중심이었고, Akin의 철학이 암묵적으로 녹아 있었던 듯함
    우주공학은 보수적 설계 문화가 강해 발전 속도가 느렸고, Elon Musk 이전까지는 변화가 더뎠음
    특히 “우주는 용서 없는 환경이며, 엔지니어링 실패는 곧 생명 손실”이라는 문구가 인상 깊었음
    2003년 Columbia 참사 시기와도 맞물림

    • SpaceX가 이 법칙들, 특히 “발사체 설계를 피하라”는 Law 39에 어떻게 반응할지 궁금함
      아마도 Law 31(기존 기술의 한계를 이해하라)이 Law 11(다 버리고 다시 시작하라)을 촉발하고, Law 16(이전 분석을 맹신하지 말라)이 이를 뒷받침했을 것임

  • 나는 유지보수가 필요 없고 교체가 쉬운 시스템을 선호함
    소프트웨어 기술은 결국 사라지므로, 하드웨어처럼 언제든 교체 가능한 구조여야 함

    • 대기업에서는 기술적 이유보다 조직적 합의와 리스크 승인 문제로 인해, 부분 교체보다 전체 교체가 더 쉬웠음

  • “완전히 새로운 제품이 항상 기존 제품의 진화형보다 낫다고 믿는 유혹을 피하라”는 조언이 특히 와닿음

답변달기