일론의 5단계 법칙

⚙️ 효율적인 문제 해결 5단계 (일론 머스크)

graph LR
A[요구 사항 재검토] --> B{불필요 요소 제거};
B --> C{단순화/최적화};
C --> D{사이클 타임 가속화};
D --> E[자동화];

지식관리

1. 🤔 요구 사항 재검토 (Less Dumb)

• 요구 사항이 ==어리석을 수 있음==을 인지
• 누가 제시했든 비판적 사고 필요
• 특히 똑똑한 사람이 제시한 경우 맹신 금지
• ==요구 사항 제안자는 책임자를 명확히 해야 함 (부서 X, 개인 O)==
  • 과거에 임의로 생성된 요구 사항인지 확인

2. 🗑️ 불필요한 요소 제거 (Delete Part/Process)

• ==핵심==: 불필요한 부분/절차 적극 삭제
• 삭제 후 ==10% 정도는 다시 추가되는 것이 정상==
• 완전 재사용 로켓처럼 혁신적인 목표일수록 중요
• 불확실성에 대한 과도한 대비 지양
  • 예: 접이식 그리핀은 불필요한 메커니즘 추가

3. 🛠️ 단순화 및 최적화 (Simplify/Optimize)

• ==주의==: 반드시 3단계에 수행
• 흔한 오류: 불필요한 것을 최적화하는 함정
• 기존 교육 방식의 문제점: 질문에 대한 ==수렴적 답변 강요==
• 존재 가치가 없는 것에 대한 최적화 지양

4. 🚀 사이클 타임 가속화 (Accelerate Cycle Time)

• 속도 향상: 선행 단계 완료 후 진행
• ==중요==: 앞선 3단계를 먼저 수행해야 함

5. 🤖 자동화 (Automate)

• 자동화의 함정: 앞선 단계 무시하고 자동화부터 시도하는 경우
• ==실패 사례==: 모델3 배터리 팩 유리 매트
  • 문제: 생산 라인 병목 현상
  • 잘못된 접근: 자동화 개선 → 가속화 → 최적화
  • 해결책: 매트의 존재 이유에 대한 근본적 질문
    • 소음/진동 vs 화재 안전 목적 상충
  • 결과: 매트 제거 및 ==200만 달러 로봇 폐기==

원칙이 탄생한 이유: 비효율의 늪을 넘어서

기업이나 조직이 복잡한 프로젝트를 추진할 때, 흔히 빠지게 되는 함정이 있다. 바로 ‘관성’의 덫이다. 오랜 시간 동안 축적된 관행, 누구도 의문을 제기하지 않는 요구사항, 그리고 비효율적인 프로세스가 쌓여 거대하고 비대한 비즈니스 구조를 만든다. 이 거대한 구조는 작은 혁신조차도 어렵게 만든다. 마치 찰흙으로 덮인 복잡한 기계처럼, 어느 부분을 손대야 할지조차 알기 어려운 지경에 이르는 것이다.

이러한 문제의식에서 일론 머스크는 기존의 모든 것을 해체하고, 제로베이스에서 사고하는 ‘5단계 문제 해결 원칙’을 만들었다. 이 원칙은 단지 효율성을 높이는 방법론이 아니다. 그것은 모든 복잡성을 근본적으로 제거하고, 불가능하다고 여겨졌던 목표를 달성하기 위한 철학적 접근이다. 우주선 개발이나 전기차 생산 라인처럼 전례 없는 기술을 구현할 때, 이 원칙은 단순한 ‘개선’이 아니라 ‘혁명’의 도구가 된다.

5단계 문제 해결 원칙의 핵심 구조

일론 머스크의 원칙은 다음과 같은 5가지 단계로 이루어진다. 놀랍게도, 우리가 직관적으로 생각하는 순서와는 다르다. 보통은 최적화나 가속화를 먼저 떠올리지만, 이 원칙은 철저히 ‘제거’와 ‘단순화’를 우선시한다.

1. 요구사항을 덜 멍청하게 만들기 (Make your requirements less dumb)

2. 파트나 프로세스 삭제하기 (Delete the part or process)

3. 단순화 또는 최적화 (Simplify or optimize)

4. 사이클 시간 가속화 (Accelerate cycle time)

5. 자동화 (Automate)

이 5단계는 순서를 지키는 것이 매우 중요하다. 한 단계라도 건너뛰거나 순서를 바꾸면 원칙의 효과는 사라지고, 오히려 더 큰 혼란을 초래할 수 있다. 머스크는 이 순서를 지키지 않아 여러 번 실패를 경험했다고 직접 말하기도 했다. 다음은 각 단계에 대한 심층적인 분석이다.

1단계: 요구사항을 덜 멍청하게 만들기

원칙의 해설

모든 프로젝트의 시작은 요구사항에서 비롯된다. 하지만 머스크는 이 요구사항들이 “멍청하다”고 단정한다. 심지어 매우 똑똑한 사람이 제시한 요구사항일수록 더 위험할 수 있다. 왜냐하면 우리는 그들의 권위에 압도되어 질문을 멈추기 때문이다. 모든 인간은 언제나 실수를 한다. 그러므로 그 누구의 요구사항이든 맹목적으로 받아들이지 않고, 비판적인 시각으로 의문을 제기하는 것이 이 단계의 핵심이다.

실천적 적용

• 책임자 지정: 요구사항은 부서가 아닌 개인의 이름과 연결되어야 한다. “안전 부서의 요구사항”이 아니라 “김민지 팀장의 요구사항”이어야 하는 것이다. 이렇게 하면 요구사항의 근거에 대해 직접 책임을 물을 수 있고, 무의미한 요구사항이 거품처럼 늘어나는 것을 방지한다.

• 근본 질문: “왜 이 요구사항이 필요한가?” “이것이 최종 목표 달성에 정말로 필수적인가?”와 같은 질문을 반복적으로 던져라. 요구사항의 본질을 파고들다 보면, 생각보다 많은 것들이 모호하고 불필요한 근거 위에 세워져 있음을 깨닫게 된다.

예시: 모델 3 배터리 팩의 유리 매트

머스크는 모델 3 생산 라인의 병목 현상에 대해 설명하며 이 원칙의 중요성을 강조한다. 배터리 팩 위에 다섯 개의 유리 매트를 부착하는 공정이 전체 라인을 지연시키고 있었는데, 그 이유를 아무도 몰랐다. 안전팀에 물어보니 소음 및 진동 방지용이라 하고, 소음/진동팀에 물어보니 화재 방지용이라 답하는 딜버트 만화 같은 상황이었다. 결국, 매트를 제거한 채 테스트해보니 아무런 차이가 없었고, 수백만 달러를 들인 자동화 로봇 공정 전체가 불필요했다는 결론에 도달했다. 이 모든 비효율은 처음부터 “왜 이 매트가 필요한가?”라는 질문을 던지지 않았기 때문에 발생한 것이다.

2단계: 파트나 프로세스 삭제하기

원칙의 해설

가장 간단한 솔루션은 아무것도 없는 것이다. 존재하지 않는 부품은 고장 날 일도 없고, 존재하지 않는 공정은 비용이 들지 않는다. 이 단계는 모든 부품과 프로세스에 대해 존재의 당위성을 재검토하고, 불필요한 요소를 과감히 제거하는 것이다. 머스크는 이렇게 말한다. “만약 가끔씩 무언가를 다시 추가하지 않는다면, 당신은 충분히 삭제하고 있지 않는 것이다.” 이 말은 불필요한 것을 제거하는 데 있어 우리의 편견과 소심함을 경계하라는 의미다.

실천적 적용

• ‘만약에’라는 이유 경계: “만약에 A라는 문제가 발생하면…” 또는 “혹시 모를 B를 위해…”와 같은 가정은 대부분 무의미한 복잡성을 초래한다. 모든 파트와 프로세스는 명확하고 입증 가능한 이유가 있어야 한다.

• 과감한 제거: 불필요해 보이는 것을 발견하면, 일단 제거하고 문제가 발생하는지 지켜봐라. 많은 경우 아무런 문제도 발생하지 않는다.

예시: 스타십의 핀

스타십의 핀은 착륙 시 방향을 조절하는 중요한 부품이다. 처음에는 비행 중 공기역학적 효율을 위해 접을 수 있게 설계하는 아이디어가 나왔다. 그러나 머스크는 이 아이디어를 삭제했다. “접고 펴는 메커니즘”은 또 다른 고장 지점과 비용, 무게를 추가하기 때문이다. 결국, 스타십의 핀은 단순한 고정 형태로 만들어져 불필요한 복잡성을 제거했다. 이 결정은 스타십의 성공적인 재사용을 가능하게 하는 핵심적인 선택이었다.

3단계: 단순화 또는 최적화

원칙의 해설

머스크는 “똑똑한 엔지니어가 하는 가장 흔한 실수”가 바로 이 단계에 있다고 지적한다. 그들은 존재해서는 안 될 것을 최적화하는 데 엄청난 시간과 에너지를 쏟는다. 학창 시절부터 “주어진 질문에 대한 답을 찾아라”고 교육받은 탓에, 우리는 문제의 전제 자체에 의문을 제기하지 못하는 정신적 족쇄를 차고 있다. 이 족쇄는 우리를 무의미한 최적화의 함정으로 이끈다.

실천적 적용

• 순서 지키기: 이 단계는 반드시 1단계와 2단계를 거친 후에만 시작해야 한다. 비로소 핵심적인 부분만 남았을 때, 그제야 어떻게 이 부분을 더 단순하게 만들고, 더 효율적으로 최적화할지 고민하는 것이다.

• ‘삭제’가 ‘최적화’보다 우선: 최적화는 ‘더 좋게 만드는 것’이지만, 단순화와 삭제는 ‘불필요한 것을 없애는 것’이다. 없애는 것이 더 근본적인 개선이다.

4단계: 사이클 시간 가속화

원칙의 해설

프로젝트를 더 빠르게 진행하는 것은 항상 중요한 목표다. 그러나 속도는 앞선 세 단계의 기반 위에서만 의미가 있다. 멍청한 요구사항을 기반으로, 불필요한 부품을 포함한 복잡한 프로세스를 최적화한 뒤에 가속화하는 것은 재앙에 가깝다. 이는 마치 잘못된 방향으로 엄청난 속도로 달리는 것과 같다. 머스크는 “언제든 더 빠르게 갈 수는 있지만, 먼저 다른 세 가지를 해결해야 한다”고 강조한다.

5단계: 자동화

원칙의 해설

자동화는 이 모든 원칙의 마지막 단계다. 하지만 대부분의 사람들은 자동화를 가장 먼저 시도하는 실수를 범한다. 존재해서는 안 될 불필요한 공정을 자동화하는 것만큼 어리석은 일은 없다. 이 과정은 마치 비효율적인 수동 공정에 막대한 비용을 들여 로봇을 들여놓는 것과 같다. 이 단계는 단순화된 프로세스가 완성된 후에, 그 효율적인 과정을 기계가 대신하게 하는 것을 목표로 한다.

실천적 적용

• 자동화의 전제: 자동화는 오직 1-4단계를 모두 거쳐 완성된 ‘이상적인 수동 프로세스’를 기반으로 이루어져야 한다.

• ‘수동 모드’로 점검: 자동화 시스템을 구축하기 전, 사람이 직접 그 과정을 수십 번, 수백 번 반복하여 효율성을 검증하는 과정이 필수적이다.

단계	원칙	핵심 개념
1	요구사항을 덜 멍청하게 만들기	모든 요구사항에 의문을 제기하고, 책임자를 명확히 지정하기
2	파트나 프로세스 삭제하기	불필요한 요소를 과감히 제거하고, ‘만약에’라는 이유를 경계하기
3	단순화 또는 최적화	존재해서는 안 될 것을 최적화하는 함정에 빠지지 않기
4	사이클 시간 가속화	앞선 세 단계를 거친 뒤에 속도를 높이기
5	자동화	비효율적인 과정을 먼저 제거한 후, 마지막으로 자동화하기

이 핸드북을 통해 당신은 머스크의 문제 해결 철학을 이해하고, 당신의 프로젝트에 적용할 수 있는 실질적인 지침을 얻었을 것이다. 이 원칙들은 단순히 로켓이나 전기차에만 국한되지 않는다. 어떤 복잡한 문제든, 그것의 본질을 파고들고 불필요한 껍데기를 벗겨내는 데 이 원칙을 활용해 보기를 바란다. 혹시 당신의 프로젝트에도 ‘멍청한 요구사항’이나 ‘유리 매트’ 같은 불필요한 요소가 숨어있지는 않은지, 지금 바로 점검해 보는 건 어떨까?

대본

the sort of five-step process uh first make your requirements less dumb your requirements are definitely dumb uh it does not matter who gave them to you it's particularly dangerous if a smart person gave you the requirements cuz you might not question them enough everyone's wrong no matter who you are everyone's wrong some of the time um so make your requirements less d uh then uh try very hard to delete the part or process um this is actually very important if you're not uh occasionally adding things back in you are not deleting enough right the the bias tends to be very strongly towards let's add this part of process step in case we need it but you can you can basically make incase Arguments for so many things and for a rocket that is trying to be the first fully reusable rocket there's never been a fully reusable rocket people don't understand like this is like the Holy Grail of rocketry and so you got to delete the P process step super important um and and you can't like hedge your vets uh so uh that's why the gpin for example do not fold fold down because that's a whole extra me mechanism that we don't need and then also uh whatever if whatever requirement or constraint you have it must come with a name not a department because uh you can't ask the department you have to ask a person uh and that person who's putting forward the requirement or constraint must agree that they must take responsibility for that requirement otherwise you can have a requirement that basically an intn two years ago randomly came up with off the cuff uh and they don't even have the company anymore these things are often just way more silly than you'd think okay so step one uh make your requirements less D step two delete the pot or process step if you're not adding things back in 10% of the time you're clearly not deleting enough right um and and then uh only the the third step is simplify or optimize the third step not the first step um the reason it's the third step is cuz it's possibly the most common error of a smk engineer is to optimize a thing that should not exist everyone's been trained in in uh high school and college to that you got to answer the question convergent logic y so you can't tell the Professor your question is dumb you'll get a bad grade you have to answer the question y uh so everyone's basically without knowing it they got like mental straight jacket on they'll work on optimizing the thing that should simply not exist right and then finally you get to step four which is accelerate cycle time you're moving too slowly go faster but don't go faster until you have worked on the other three things first you can always make things go faster um and then the final step is automate now I have personally uh made the mistake of going backwards on all five steps multiple times literally I automated accelerated simplified and then deleted one example I've talked about before is like the there were these like five glass mats on top of the bottle 3 battery pack that were in between the FL Pan and the the battery um and it was one point choking the battery pack production line and I was like basically living on the battery pack production line like probably fix the line it was like choking the entire model 3 production program so the the first mistake was I I like try to fix the automation like make the robot better so automating was a mistake then accelerating was a mistake then optimizing was a mistake and finally I said what the hell are these mats for um and uh and I asked the the battery safety team what are these Ms for are they for fire protection or something they said no they're for noise and vibration then I asked an uh NBA noise vibration harness uh Team what's it for they said fire safety so literally it was like being in a Dilbert cartoon okay it's like actually I feel like I'm in a dber cartoon quite frequently so then finally okay great let's uh try a car with the the five of glass mats and without uh and they and put a microphone in both and and see if you can tell the difference you cannot in fact I was like which one is witch um so we just deleted them and just bypassed this $2 million robot robot sale it was just a complete pile Anis