74일에서 물리적 한계까지: Jensen Huang의 "빛의 속도" 사고방식이 공학에서 바꾸는 것
서론: 일정을 이해하기 전에 왜 개선하려 하는가?
한 팀이 어떤 과정에 74일이 걸린다고 말합니다. 이를 72일로 줄이겠다고 제안합니다. 진전처럼 들립니다. 하지만 다른 방식으로 구성하면 실제 작업을 6일 만에 완료할 수 있다면 어떨까요?
이 숫자는 방법을 설명하는 예시이지 특정 프로젝트에 대한 약속이 아닙니다. Jensen Huang은 기존 과정을 출발점으로 받아들이기 전에 근본적인 한계를 찾는 것을 "빛의 속도" 사고방식으로 설명합니다.
중요한 질문은 같은 사람들에게 더 큰 노력을 요구하는 방법이 아닙니다. 필요한 작업과 물려받은 지연을 구분하는 방법입니다.
1. 기존 과정은 증거이지 자연법칙이 아닙니다
확립된 일정에는 실제 작업, 대기, 승인, 인계, 일괄 처리 [Batching], 더는 유효하지 않은 이유로 이뤄진 타협 등 여러 요소가 들어갈 수 있습니다.
지속적 개선 [Continuous Improvement]은 그 기존 방식에서 출발합니다. 과정을 어떻게 조금 더 낫게 할 수 있는지 묻습니다.
제1원리 사고 [First-principles Reasoning]는 그보다 앞선 질문을 합니다. 실제로 무엇이 일어나야 하며, 다르게 일어나는 것을 무엇이 막고 있습니까?
경험이 무가치하다는 뜻은 아닙니다. 경험 많은 사람은 어려운 단계가 왜 존재하는지 정확히 아는 경우가 많습니다. 핵심은 일정 자체를 설명으로 취급하지 않고 그 이유를 다시 찾아내는 것입니다.
2. 중요한 각 차원의 한계를 찾으십시오
"빛의 속도"는 관련 제약 아래에서 가능한 것의 한계를 줄여 표현한 말입니다. 모든 사업 활동이 문자 그대로 빛의 이동 속도에 제한된다는 뜻은 아닙니다.
컴퓨팅에서 그 차원에는 메모리 데이터 이동 [Memory Movement], 에너지, 응답 지연 [Latency], 처리량 [Throughput], 비용, 제조 시간이 포함될 수 있습니다. 한 설계가 한 차원에서는 한계에 가까우면서 다른 차원에는 상당한 여유를 남길 수 있습니다.
이 차원들을 분리하는 것은 유용합니다. 답 하나를 빨리 제공하는 시스템은 많은 요청을 효율적으로 처리하도록 설계한 시스템과 다를 수 있습니다. 하나를 최적화 [Optimising]한다고 다른 하나가 자동으로 최적화되지는 않습니다.
모든 것을 최종 설계로 결합하기 전에 팀은 각 목표가 무엇을 요구하는지 이해해야 합니다.
3. 이상적인 기준선을 정한 뒤 격차를 설명하십시오
6일이라는 예시는 나머지 68일을 살펴볼 때 비로소 가치가 생깁니다.
그 격차의 일부는 정당할 수 있습니다. 더 느린 과정이 비용이 적거나, 희소한 장비를 더 공정하게 사용하거나, 필요한 검사를 제공할 수 있습니다. 다른 지연은 중복 결정이나 최근 아무도 의문을 제기하지 않은 순서에서 생길 수 있습니다.
이 작업은 그런 선택을 드러냅니다. 이틀을 줄일 수 있는지 논쟁하는 대신 팀은 근본적 기준선에서 훨씬 큰 격차를 왜 받아들이는지 논의할 수 있습니다.
따라서 물리적 최소치는 판단을 위한 참고점입니다. 자동으로 올바른 상업적 마감일이 되는 것은 아닙니다.
4. 단순함은 불필요한 복잡성을 없애는 것입니다
정교한 컴퓨팅 시스템에는 상호작용하는 부분이 많으면서도 단순한 목적이 있을 수 있습니다. 복잡성이 그 목적에 기여하지 않고 존재할 때 문제가 됩니다.
Huang의 접근법은 구성요소, 단계, 종속 관계 [Dependency]가 필요한지 묻는 것입니다. 필요하다면 이해하십시오. 필요하지 않다면 왜 남아 있는지 물으십시오.
이것은 제 기능을 못 할 때까지 시스템을 덜어내는 것과 다릅니다. 전력 공급, 냉각, 시험, 신뢰성은 도표를 복잡하게 만든다는 이유로 선택 사항이 되지 않습니다.
유용한 목표는 요구사항을 충족할 만큼의 복잡성은 갖되 습관만 보존하는 추가 복잡성은 없는 설계입니다.
5. 리더는 실행 현장을 이해해야 합니다
프로젝트 보고서는 원인을 가린 채 지연을 설명할 수 있습니다. 작업이 일어나는 곳에서는 설명이 훨씬 명확할 수 있습니다.
케이블은 어떻게 설치합니까? 구성요소는 왜 기다립니까? 어떤 결정이 다음 작업을 막습니까? 이 질문들은 광범위한 시스템을 그것을 만들어내는 작은 행동과 연결합니다.
긴급함은 실제 장애물을 없앨 때 유용해집니다. 작업을 이해하지 않은 채 더 공격적인 마감일을 반복한다고 공학적 진전이 생기지는 않습니다.
리더십은 제약을 드러내고 적절한 전문성을 모으며 어떤 절충을 받아들일 수 있는지 결정하도록 도와야 합니다.
결론: 개선을 축하하기 전에 기준선에 의문을 제기하십시오
"빛의 속도" 사고방식의 강점은 왜인지 묻는 규율입니다. 왜 이 순서입니까? 왜 이 대기 시간입니까? 왜 이 설계입니까? 어떤 한계가 물리학에서 오고 어떤 한계가 선택에서 옵니까?
답이 명확해지면 지속적 개선 [Continuous Improvement]의 토대도 더 나아집니다. 팀은 물려받은 과정을 다듬는 대신 자신이 이해하는 과정을 개선할 수 있습니다.
이 방법은 모든 74일짜리 프로젝트가 6일 만에 끝난다고 약속하지 않습니다. 왜 그렇게 되지 않는지 알라고 요구합니다. 그 지식이 뒤따르는 모든 결정의 질을 바꿉니다.
Powered By K7