- 우주선 설계 및 엔지니어링 프로젝트에 적용되는 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 — 새 발사체 개발 금지
-
새로운 유인 우주 프로그램을 저렴하고 일정에 맞게 유지하는 세 가지 핵심:
- 새로운 발사체 없음
- 새로운 발사체 없음
- 무슨 일이 있어도 새로운 발사체를 개발하기로 결정하지 말 것
- 완전히 새로운 제품이 항상 기존 제품의 진화보다 나을 것이라고 믿는 유혹을 피해야 함
법칙 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)"