일론 머스크식 문제 해결 5단계 프로세스 정리

핵심 요약

어떤 시스템이든 개선할 때는 무조건 "빼는 것"부터 시작해야 하며, 자동화·최적화는 제일 마지막 단계에 와야 한다는 내용이다. 요구사항을 의심하고, 불필요한 것을 지우고, 남은 것만 단순하게 빠르게 자동화하라는 사고법이다.

문제 해결 5단계 전체 그림

이 내용의 핵심은 "무언가를 만들거나 개선할 때 어떤 순서로 생각해야 하는가"에 대한 체계적인 방법이다.

순서는 다음과 같다.

1. 요구사항을 의심하고 덜 멍청하게 만들기

2. 부품·단계·프로세스를 과감히 삭제하기

3. 정말 필요한 것만 단순화·최적화하기

4. 그 다음에야 속도를 높이기

5. 마지막으로 자동화하기

많은 사람이 3→4→5부터 시작하려다, 존재할 필요가 없는 것을 미친 듯이 잘 만들고 잘 돌리다가 뒤늦게 없애버리는 실수를 반복한다.

1단계: 요구사항은 항상 틀렸다고 가정하기

첫 단계는 "지금 주어진 요구사항이 멍청하다"라고 가정하고 출발하는 것이다.

이때 중요한 포인트는, 누가 만들었는지는 상관없다는 점이다.

아주 똑똑한 사람이 만든 요구사항일수록 오히려 더 위험하다.

"저 사람이 했으니 맞겠지"라는 믿음 때문에 의심과 질문이 사라지기 때문이다.

그래서 "이 요구사항은 왜 존재하는가?", "지금도 여전히 필요한가?", "전제는 여전히 유효한가?"를 집요하게 따져봐야 한다.

학교나 시험에선 주어진 질문을 그대로 풀어야 점수를 받지만, 실제 현장에선 "질문 자체가 잘못된 것 아닌가?"를 묻는 용기가 훨씬 더 중요하다.

2단계: 부품·프로세스는 일단 빼고 볼 것

두 번째 단계는 가능한 한 많은 부품, 단계, 절차를 삭제하는 것이다.

사람들의 기본 습관은 "혹시 필요할지 모르니까"를 이유로 자꾸 뭔가를 추가하는 쪽으로 기울어져 있다.

하지만 "혹시"를 붙이면 끝없이 추가할 수 있다.

그래서 좋은 기준은 이런 것이다.

• 뭔가를 많이 삭제했는데, 나중에 10% 정도는 다시 되돌려 넣는 일이 생긴다면, 그건 잘한 것이다.

• 반대로 삭제한 것을 거의 다시 추가하지 않는다면, 애초에 충분히 빼보지 않은 것이다.

무언가를 설계할 때 "이걸 어떻게 더 넣지?"가 아니라 "이걸 안 하면 안 되나?"를 먼저 물어야 한다.

3단계: 존재할 필요가 있는 것만 단순화·최적화하기

세 번째가 비로소 우리가 익숙한 "개선·최적화" 단계다.

하지만 이건 반드시 1·2단계 이후에 와야 한다.

가장 흔한 실수는, 애초에 존재할 필요가 없는 것, 혹은 미련 없이 삭제할 수 있는 것을 엄청 정교하게 다듬고 최적화하는 것이다.

학교 교육은 대개 "주어진 문제를 잘 푸는 법"을 가르친다.

그래서 사람들은 "문제 자체가 틀렸다"라고 느껴도, 묻지 않고 주어진 조건을 전제로 최적화 작업에 들어간다.

좋은 실무자는 항상 되묻는다.

"이걸 최적화하기 전에, 이게 정말 있어야 하는가?", "이 기능/부품 자체를 없애면 어떤가?"

단순화와 최적화는 "필터를 통과한 것들"만 대상으로 해야 효과가 크고 유지 관리도 쉽다.

4단계: 그 다음에야 속도를 높인다

네 번째 단계는 "더 빠르게 돌리기"다.

여기서의 속도는 개발 주기, 생산 속도, 실험·피드백 주기 등 모든 사이클 타임을 의미한다.

하지만 많은 조직이 이 단계부터 시작해 버린다.

• 복잡하고 불필요한 프로세스를 그대로 둔 채,

• 그걸 더 빨리, 더 많이 하려고 한다.

이렇게 되면 엉망인 시스템을 더 빨리, 더 크게 확대하는 꼴이 된다.

1~3단계로 "정말 필요한 것만 남기고, 간단하게 정리한 다음"에야 속도를 올리는 것이 맞다.

정리 안 된 방을 치우지 않고, 정리 속도만 올리면 결국 더 큰 혼란만 생기는 것과 같다.

5단계: 마지막에 자동화하기

마지막 단계가 자동화다.

로봇, 소프트웨어, 시스템을 도입해 사람 손을 줄이고 효율을 끌어올리는 단계다.

하지만 이 순서를 거꾸로 적용하면, 아주 비싼 쓰레기 자동화 라인이 만들어질 수 있다.

좋은 자동화는 다음 조건을 만족해야 한다.

• 이미 불필요한 것들은 충분히 제거되었고

• 남은 프로세스는 단순하며

• 빠르게 돌아가도 문제가 없고

• 반복이 많아 자동화할 가치가 있는 경우

이때 자동화는 폭발적인 효율 향상을 가져오지만, 그렇지 않다면 "쓰레기를 더 빠르고 멋지게 만드는 시스템"이 될 뿐이다.

실제 사례: 모델 3 배터리 팩의 유리 매트

이론이 실제로 어떻게 적용되는지를 보여주는 대표 사례가 모델 3 배터리 팩 이야기다.

배터리 팩 위에는 바닥과 배터리 사이에 깔리는 유리 섬유 매트가 여러 장 있었다.

이 부품을 다루는 로봇 공정이 전체 생산 라인의 목을 조르고 있었다.

처음에는 "로봇 성능을 개선해야 한다"고 생각해 자동화를 더 잘 돌리려고 했다.

그다음에는 속도를 높이려고 노력했고, 이어서 공정을 최적화하려 했다.

하지만 이 모든 시도가 사실은 순서가 완전히 거꾸로였다.

결국 "이 매트를 왜 넣고 있지?"라는 근본적인 질문을 던지고, 안전팀과 소음·진동팀에 각각 물어본 결과 서로가 서로의 이유를 오해하고 있다는 사실이 드러났다.

정작 누구도 이 매트가 정말 필요한지 검증한 사람이 없었던 것이다.

실험을 해 보니, 매트가 있을 때와 없을 때 소음 차이가 사실상 느껴지지 않았다.

결론은 간단했다.

• 매트를 아예 삭제했다.

• 그와 관련된 공정과 20억 원짜리 로봇 공정이 통째로 사라졌다.

이건 "1~2단계(요구사항 의심, 삭제)를 건너뛰고 3~5단계(최적화·가속·자동화)만 열심히 한 실패 사례"이자, 이 5단계의 필요성을 잘 보여주는 예시다.

책임 있는 요구사항: "부서"가 아니라 "사람"에게 묻기

요구사항을 다룰 때 또 하나 중요한 원칙은, "부서 이름이 아니라 사람 이름이 있어야 한다"는 점이다.

"안전팀에서 그랬다", "품질팀에서 요구했다"라는 식이면 아무도 책임을 지지 않는다.

이러면 예전에 잠깐 일하던 누군가가 가볍게 만든 규칙이 수년 동안 "성역"처럼 남아 버릴 수 있다.

그래서 다음 기준이 필요하다.

• 이 요구사항·제약조건의 '이름과 얼굴이 있는' 담당자가 누구인가?

• 그 사람이 지금도 이 요구를 책임지고 인정하는가?

책임 주체가 분명해야만 요구사항을 제대로 검토하고, 필요하면 과감히 수정하거나 없앨 수 있다.

인사이트

이 5단계는 로켓, 전기차뿐 아니라 거의 모든 일에 적용할 수 있는 사고법이다.

• 새 기능을 만들기 전에, "이 요구가 정말 맞는가?"부터 의심하고

• 프로세스를 개선하기 전에, "뭘 없앨 수 있지?"를 먼저 생각하고

• 남은 것만 단순하게 정리한 다음

• 그걸 빨리 돌리고

• 마지막에 자동화한다.

작게 적용해 보고 싶다면, 자신의 업무 중 반복적인 프로세스를 하나 골라 다음 질문들을 순서대로 던져보면 좋다.

1. 이 일을 왜 해야 하지? 전제·요구사항이 여전히 유효한가?

2. 빼도 티 안 나는 단계는 무엇인가? 일단 과감히 삭제해 보자.

3. 남은 과정은 더 간단하게 묶거나 줄일 수 없나?

4. 이제 이 과정을 더 빠르게 돌릴 수 있는 방법은?

5. 진짜 자주 반복되고 가치가 큰 부분을 자동화할 수 있을까?

핵심은 "먼저 없애고, 그 다음에 다듬고, 제일 마지막에 멋지게 만든다"는 순서를 절대 거꾸로 타지 않는 것이다.

출처 및 참고: