일류와 이류의 차이 (반도체 전설 짐켈러)

🍞 레시피 vs 이해: 깊이 있는 지식의 중요성

1원칙 사고법

1. 📚 레시피의 한계와 이해의 깊이

1. 레시피

• 밀가루, 물, 이스트를 섞어 빵을 만드는 ==단순한 방법==을 제시

2. 이해

• ==생물학, 공급망, 물리학 등 다양한 분야에 대한 깊이 있는 지식 포함==
  • 곡물, 효모, 열역학 등에 대한 이해

3. 문제점

• 레시피는 ==제한된 범위==만을 다룸
  • 빵 레시피는 오믈렛 만드는 법을 알려주지 않음

2. 🍳 요리 전문가의 차이

1. 전문가

• 요리에 대한 ==깊은 이해==를 추구
  • 빵, 오믈렛, 샌드위치 등 다양한 요리에 적용 가능

2. 효율성

• 레시피대로 실행하는 것은 ==매우 효율적==이지만, ==제한적==임

3. 💻 컴퓨터 개발에서의 깊이 있는 이해

1. 🛠️ 점진적 개선의 함정

• 컴퓨터를 10% 빠르게 만들기 위해 ==버퍼를 늘리거나 명령어 추가==
• 각 요소가 점진적으로 복잡해짐
• 어느 순간 ==개선이 멈추는 한계==에 도달

2. 🔄 근본적인 재검토의 필요성

• 문제 해결 방식과 기능 간 상호 작용 방식의 ==재검토 및 재작성 필요==
• 재작성은 성능 향상뿐 아니라 ==복잡성 감소 효과도 가져옴==

4. 🗑️ 전체 재작업의 필요성

1. 📅 주기

• 컴퓨터 아키텍처에서 큰 발전을 이루려면 ==3~5년마다 전체를 재작업==해야 함

2. 😨 두려움

• 레시피 반복의 효율성 vs. ==새로운 시도의 두려움==
  • 단기적 손실 vs. 장기적 성공

5. 📈 장기적 성공을 위한 리더십

1. 📉 단기적 손실 감수

• 장기적 목표를 위해 ==단기적 제약==을 극복해야 함

2. 🤝 리더의 역할

• ==재작업의 필요성==을 인지하고 주도해야 함
• 기존 프로젝트 최적화와 신규 프로젝트 개발을 ==병행==해야 함

6. 🎯 마케팅과 아키텍처의 균형

1. ⚖️ 평균 vs. 예외

• 새로운 컴퓨터는 ==평균적으로 빠르지만, 특정 작업에서는 느릴 수 있음==
• 마케팅 부서는 모든 면에서 빠른 컴퓨터를 요구
• 아키텍처 담당자는 결과 분포와 예외 상황을 고려해야 함

2. 📢 고객의 요구

• 특정 고객이 중요하게 생각하는 ==예외적인 성능==을 간과해서는 안 됨

• 레시피는 빠르고 효율적이지만, 특정 범위에 한정된 해결책입니다.

• 깊은 이해는 근본 원리를 파악하여 새로운 문제에 적용할 수 있는 유연성과 혁신을 가져옵니다.

• 진정한 전문가와 리더는 단기적 효율성을 넘어, 주기적인 근본적 재정립을 통해 장기적 성공을 추구합니다.

1. 만들어진 이유 - 레시피와 이해의 근본적 차이

당신이 빵을 만들려 한다고 상상해 보십시오. 첫 번째 접근 방식은 ‘레시피’를 따르는 것입니다. 밀가루, 물, 이스트를 정해진 비율로 섞고, 반죽하고, 발효시키고, 오븐에 굽는 일련의 과정을 충실히 이행합니다. 이 방법은 빠르고, 예측 가능하며, 누구나 쉽게 좋은 빵을 만들 수 있게 합니다. 이것이 바로 우리가 일상에서 접하는 대부분의 문제 해결 방식입니다. 정해진 매뉴얼, 표준 작업 절차, 검증된 라이브러리 등은 모두 이런 ‘레시피’에 속합니다.

그러나 ‘이해’는 완전히 다른 차원의 접근법입니다. 빵을 근본적으로 이해한다는 것은 단순히 레시피를 외우는 것을 넘어섭니다. 이스트의 생물학적 작용 원리, 밀가루를 구성하는 단백질과 전분의 화학적 성질, 반죽 과정에서 발생하는 글루텐 형성의 물리학, 오븐 속에서의 열역학적 변화 등을 깊이 파고드는 것입니다. 이러한 깊은 이해를 갖추면, 단순히 빵을 만드는 것을 넘어 반죽의 상태를 보고 온도나 습도를 조절하며, 오븐의 종류에 따라 굽는 시간을 유연하게 바꾸는 등 레시피를 초월한 창조적 행위를 할 수 있게 됩니다.

이러한 비유는 엔지니어링, 비즈니스, 심지어 일상생활의 모든 영역에 적용됩니다. ‘레시피’는 효율적인 실행을 위한 도구이며, ‘깊은 이해’는 혁신과 창조를 위한 기반입니다. 대부분의 사람들은 주어진 레시피를 효율적으로 실행하는 데 능숙하지만, 진정한 전문가와 리더는 레시피가 통하지 않는 새로운 문제에 봉착했을 때 깊은 이해의 힘을 발휘합니다.

2. 구조 - 레시피의 힘과 한계

2.1 레시피의 힘: 효율성과 속도

레시피는 놀라운 효율성을 제공합니다. 복잡한 문제를 단순한 단계로 분해하여, 전문 지식이 없는 사람도 성공적으로 결과물을 만들어낼 수 있게 합니다.

• 진입 장벽 감소: 복잡한 시스템의 구성 요소나 특정 기술을 깊이 이해하지 못해도, 정해진 API를 호출하거나 프레임워크의 규칙을 따르면 기능을 구현할 수 있습니다.

• 예측 가능성: 동일한 레시피를 따르면 항상 유사한 결과를 얻을 수 있어, 프로젝트의 일정이나 예산을 예측하기가 용이합니다.

• 협업 용이성: 팀원들이 모두 같은 레시피를 공유하고 있다면, 각자 맡은 부분을 효율적으로 진행하여 전체 프로젝트를 완성할 수 있습니다.

이러한 이유로 대부분의 기업은 레시피 기반의 프로세스를 구축하여 단기적인 생산성을 극대화합니다. 그러나 이 과정은 서서히 눈에 보이지 않는 한계를 만들어냅니다.

2.2 레시피의 함정: 기술 부채와 정체

레시피는 그 태생적 한계 때문에 ‘레시피북’에 없는 문제는 해결하지 못합니다. 빵 레시피로는 오믈렛을 만들 수 없는 것처럼 말입니다.

• 범위의 한정: 레시피는 특정 문제의 스코프(Scope) 안에서만 유효합니다. 이 범위를 벗어나는 새로운 요구사항이나 예상치 못한 문제가 발생하면, 기존의 레시피는 무용지물이 됩니다.

• 점진적 복잡성: 기존 시스템에 새로운 레시피를 계속해서 덧붙여 나가는 방식은 시간이 지날수록 시스템을 비대하고 복잡하게 만듭니다. 이는 흔히 ‘기술 부채(Technical Debt)‘라고 불리는 현상으로, 마치 레시피가 덕지덕지 붙은 낡은 요리책처럼 시스템을 이해하고 관리하기 어렵게 만듭니다.

• 혁신 저해: 레시피만 고집하는 문화에서는 근본적인 혁신이 일어나기 어렵습니다. 모두가 ‘왜’라는 질문 대신 ‘어떻게’에만 집중하기 때문입니다. 이러한 접근은 기존 제품을 조금 더 빠르게, 조금 더 효율적으로 만드는 점진적 개선(Incremental Improvement)만 가능하게 할 뿐, 시장의 판도를 뒤집을 만한 파괴적 혁신(Disruptive Innovation)으로 이어지지 않습니다.

3. 사용법 - 깊은 이해를 추구하는 방법

깊은 이해는 단순히 지식을 축적하는 행위를 넘어섭니다. 이는 문제를 해결하는 사고방식 그 자체를 전환하는 것입니다.

3.1 근본 원리 사고(First-Principles Thinking)

근본 원리 사고는 복잡한 문제를 가장 기본적인 진리, 즉 더 이상 쪼갤 수 없는 ‘근본 원리’로 분해하는 사고방식입니다. 그리고 이 원리로부터 문제를 처음부터 다시 재구성하는 것입니다.

• ‘왜’라는 질문: 레시피가 ‘어떻게’에 대한 답이라면, 깊은 이해는 ‘왜’에 대한 답을 찾는 과정입니다. “이 컴퓨터는 왜 이런 구조를 가졌는가?”, “이 코드는 왜 이렇게 작성되었는가?”와 같은 질문을 끊임없이 던져야 합니다.

• 문제의 재정의: 사용자 예시에서처럼, 컴퓨터 아키텍처의 성능이 한계에 다다르면 “버퍼를 더 키워야 하나?” 같은 레시피 기반의 질문을 멈추고, “이 문제를 근본적으로 나누는 방식 자체가 잘못된 것은 아닌가?”라고 재정의해야 합니다.

• 제로 베이스(Zero-Base) 접근: 근본 원리 사고는 기존의 모든 가설과 전제를 버리고, 백지 상태에서 다시 시작할 용기를 요구합니다. 이는 새로운 아이디어가 탄생하는 진정한 원천이 됩니다.

3.2 재구성(Refactoring)의 필요성

깊은 이해는 점진적 개선의 한계를 인식하고, 때로는 모든 것을 버리고 ‘재구성’해야 할 필요성을 깨닫게 합니다.

• 점진적 개선의 끝: 버퍼를 키우고, 명령어를 추가하는 등의 점진적 개선은 결국 ‘수확 체감의 법칙(Diminishing Returns)‘에 부딪힙니다. 특정 지점을 넘어서면, 노력 대비 성능 향상이 거의 없어지게 됩니다.

• 새로운 시작의 가치: 사용자의 경험처럼, 컴퓨터 아키텍처를 3~5년마다 완전히 재구성하는 것은 혁신의 새로운 시작점을 만듭니다. 처음에는 기존 최적화된 시스템보다 성능이 떨어질 수 있지만, 근본적으로 더 단순하고 효율적인 구조를 기반으로 하기 때문에 더 높은 성능 상한선에 도달할 수 있습니다.

• 더 단순하게: 깊은 이해는 종종 더 간단하고 우아한 해결책으로 이어집니다. 복잡한 기능들을 덕지덕지 붙이는 대신, 근본 원리를 기반으로 설계된 새로운 시스템은 더 빠를 뿐만 아니라 관리하기도 훨씬 수월해집니다.

4. 심화 내용 - 조직과 리더십의 역할

개인의 깊은 이해는 조직의 시스템과 맞물릴 때 비로소 진정한 힘을 발휘합니다.

4.1 단기적 목표와 장기적 성공의 딜레마

이러한 근본적 재구성의 시도는 필연적으로 두려움과 저항에 부딪힙니다.

• 단기적 재앙의 두려움: 분기별 실적과 주가에 민감한 기업의 리더들은 레시피 기반의 점진적 개선을 선호합니다. 이는 단기적으로는 안정적이고 예측 가능한 성장을 보장하기 때문입니다. 모든 것을 재구성하는 ‘빅뱅’ 방식은 단기적인 실패 가능성을 내포하고 있습니다.

• 장기적 재앙의 인식: 반면, 장기적인 비전과 목표를 가진 리더들은 레시피의 한계가 결국 기업의 미래를 막는 ‘장기적 재앙’이 될 것임을 알고 있습니다. 이들은 단기적인 불편함과 위험을 감수하고서라도 근본적인 변화를 추구합니다.

이러한 두려움을 극복하고 장기적 성공을 이루기 위해서는 전략적인 접근이 필요합니다.

4.2 병렬 프로젝트의 중요성

스티브 잡스의 명언처럼, 한 단계 더 높은 곳으로 도약하기 위해서는 새로운 프로젝트를 시작해야 합니다.

• 투 트랙 전략: 가장 효과적인 방법은 ‘병렬 프로젝트’를 운영하는 것입니다. 기존 시스템을 계속해서 최적화하고 개선하는 팀과 동시에, 완전히 새로운 구조를 처음부터 설계하는 팀을 별도로 운영하는 것입니다. 이는 단기적인 매출과 성과를 유지하면서, 장기적인 혁신을 위한 기반을 마련하는 현명한 방법입니다.

• 데이터 기반의 의사결정: 새로운 재구성 프로젝트가 진행될 때, ‘새로운 컴퓨터는 모든 면에서 더 빨라야 한다’는 마케팅 부서의 압박에 직면할 수 있습니다. 이때 중요한 것은 ‘평균적인 성능 향상’과 ‘몇몇 분야의 성능 저하’를 솔직하게 인정하고 소통하는 것입니다. 깊은 이해를 통해 도출된 데이터는 이러한 논쟁에서 강력한 무기가 됩니다.

4.3 전문가의 역할과 리더의 용기

진정한 전문가는 단순히 레시피를 많이 아는 사람이 아닙니다. 그들은 레시피의 한계를 인식하고, 근본적인 이해를 통해 새로운 레시피를 만들어낼 수 있는 사람입니다.

이러한 전문가들이 목소리를 내고, 조직의 리더가 그들의 통찰을 믿고 단기적인 압박을 이겨내는 ‘용기’를 가질 때, 비로소 조직은 정체를 벗어나 지속적인 성장과 혁신을 이룰 수 있습니다. 레시피는 효율적인 도구이지만, 깊은 이해는 진정한 탁월함을 창조하는 핵심입니다.

이 핸드북이 레시피를 넘어 깊은 이해의 세계로 나아가는 데 도움이 되기를 바랍니다. 만약 이 개념을 특정 분야(예: 소프트웨어 개발, 데이터 분석, 마케팅 전략 등)에 적용하는 방법에 대해 더 깊이 논의하고 싶다면 언제든지 말씀해 주세요.

대본

well most people don't think simple enough all right so you know the difference between a recipe and the understanding so imagine you're going to make a loaf of bread yep the recipe says get some flour add some water add some yeast mix it up Let It Rise put it in a pan put it in the oven it's a recipe right understanding bread you can understand biology Supply chains you know grain grind ERS yeast physics you know thermodynamics like there's so many levels of understanding there and then when people build and design things they frequently are executing some stack of recipes right and the problem with that is the recipes all have limited scope like if you have a really good recipe book for making bread it won't tell you anything about how to make an omelet right right but if you have a deep understanding of cooking right then bread omelets you know sandwich you know there's there's a different you know way of viewing everything and most people when you get to be an expert at something you know you're you're hoping to achieve deeper understanding not just a large set of recipes to go execute and it's interesting to walk groups of people because executing recipes is unbelievably efficient if it's what you want want to do if it's not what you want to do you're really stuck does it every stage of development deep understanding on the team needed oh this goes back to the art versus Science question sure if you constantly unpacked everything for deeper understanding you never get anything done right and if you don't unpack understanding when you need to you'll do the wrong thing but uh with deep understanding do you mean also so sort of fundamental questions of uh things like what is a computer like or why like like the why question is why are we even building this like of purpose or do you mean more like going towards the fundamental limits of physics sort of really getting into the core of the science well in terms of building a computer think simp think a little simpler so practice is you build a computer and then when somebody says I want to make it 10% faster you'll go in and say all right I need to make this buffer bigger and maybe I'll add an ad unit or you know I have this thing that's three instructions wide I'm going to make it four instructions wide and what you see is each piece gets incrementally more complicated right and then at some point you hit this limit like adding another feature or buffer doesn't seem to make it any faster and then people will say well that's because it's a fundamental limit and then somebody else will look at it and say well actually the way you divided the problem up and the way the different features are interacting is limiting you and it has to be rethought Rewritten right so then you refactor it and rewrite it and what people commonly find is the rewrite is not only faster but half is complicated from scratch yes so how often in your career but just have you seen as needed maybe more generally to just throw the whole out the whole thing this is where I'm on one end of it every 3 to 5 years so if you want to really make a lot of progress on computer architecture every five years you should do one from scratch well and here's isn't it scary yeah of course well scary to who to uh everybody involved because like you said rep repeating the recipe is efficient companies want to make money well no individual Jers want to succeed so you want to incrementally improve increase the buffer from 3 to four will inre this where you get into diminishing return curves I think Steve Jobs said this right so every you have a project and you start here and it goes up and they have demission return Y and to get to the next level you have to do a new one and the initial starting point will be lower than the the old optimization point but it'll get higher so now you have two kinds of fear short-term disaster and long-term disaster disaster and you're you're grownups right like you know people with a quarter by quarter business objective are terrified about changing everything yeah and people who are trying to run a business or build a computer for a long-term objective know that the short-term limitations block them from the long-term success so if you look at leaders of companies that had really good long-term success every time they saw the they had to redo something they did and so somebody has to speak up or you do multiple projects in parallel like you optimize the old one while you build a new one and but the marketing guys are always like make promise me that the new computer is faster on every single thing and the computer architect says well the new computer will be faster on the average but there's a distribution of results and performance and you'll have some outliers that are slower and that's very hard because they have one customer who cares about that one