지난 글에서는 Decision이 늦어질수록 Execution과 Verification의 시작도 늦어지고, 결국 수정할 수 있는 시간까지 줄어들 수 있다는 이야기를 했다.
그 다음에 자연스럽게 이런 질문이 생겼다.
“회사는 더 빠른 S/W와 H/W에 계속 투자해 왔는데, 왜 Project 전체는 그만큼 빨라지지 않았을까?”
먼저 분명히 하고 싶은 것이 있다.
Server, CPU/Memory, Compute Farm, EDA S/W, License, Parallel Run, Automation, Methodology에 대한 투자는 실제로 큰 효과를 만들었다.
Run은 빨라졌고 더 많은 작업을 동시에 처리할 수 있게 됐다.
나는 그 가치를 부정하려는 것이 아니다.
오히려 Machine이 빨라진 뒤 어디에 새로운 Bottleneck이 생겼는지를 보고 싶었다.
Run Complete ≠ Decision-ready
Tool Runtime은 Command를 실행한 뒤 Result가 나올 때까지의 시간이다.
하지만 Project에서 중요한 것은 Result가 나온 시점이 아니라 “이제 다음 행동이나 Decision을 할 수 있다”고 판단할 수 있는 시점이다.
실제 업무는 종종 이렇게 이어졌다.
Input 준비 → Run → Result 확인 → 이상 여부 판단 → 추가 분석 → 다른 Condition 비교 → Decision Material 준비 → Review → 추가 질문 → Re-run → 재해석 → Decision
Run이 끝났다는 것과 판단할 준비가 됐다는 것은 다른 문제였다.
Machine Capacity가 커지면서 또 다른 역설도 생겼다.
더 많은 Corner와 Scenario를 더 짧은 시간에 돌릴 수 있게 되면 Result도 더 많이 생긴다.
그런데 더 많은 Result가 자동으로 더 빠른 Decision을 의미하지는 않았다.
어떤 Result가 중요한지, 어떤 차이가 이상한지, 무엇을 추가 확인해야 하는지, 지금 다음 단계로 가도 되는지는 여전히 사람이 해석해야 했다.
Machine에서 Run과 Result를 만드는 속도는 빨라졌지만, 그 결과를 해석하고 Review해야 하는 사람의 일도 함께 늘어날 수 있었다.
SoC로 개발 범위가 넓어지면서 사람이 동시에 판단해야 할 것도 함께 늘어났다 내가 IP나 ASIC의 일부 영역을 중심으로 개발하던 시기와 지금의 SoC 개발을 비교하면 또 하나의 차이가 느껴진다.
당시에도 어려운 Engineering Decision과 Verification은 많았다.
다만 한 Engineer가 직접 이해하고 확인해야 하는 Design 범위와 Interface, Condition의 연결은 상대적으로 좁았고, 경험이 쌓이면 상당 부분을 개인의 기억과 판단으로 감당할 수 있었다.
SoC에서는 여러 IP와 Subsystem, HW/SW Interaction, Power·Performance·Clock·Reset·Security·DFT·Physical Constraint가 서로 영향을 준다.
하나의 변경이 다른 Block이나 Verification Condition, 후속 Flow에 어떤 영향을 줄지 함께 봐야 하는 경우도 많아졌다.
중요한 것은 예전보다 Engineer의 역량이 낮아졌다는 이야기가 아니다.
한 사람이 머릿속에 유지하면서 확인하고 판단해야 하는 범위가 개인의 경험과 기억만으로 감당하기 어려울 정도로 커졌다는 쪽에 가깝다.
그래서 숙련자의 경험은 더 중요해졌지만, 동시에 그 경험을 개인에게만 기대는 방식은 더 잘 확장되지 않았다.
그리고 중요한 판단은 결국 경험 있는 사람에게 집중되기 쉬웠다.
Routine Run은 자동화하거나 분산할 수 있어도 “이 정도 차이는 허용 가능한가?”, “추가 검증이 필요한가?”, “이 변경이 이후 단계에 어떤 Risk를 만들 수 있는가?”
같은 질문은 Project Context를 충분히 아는 사람에게 모였다.
여기서 나는 Headcount와 실제 Decision Capacity가 같지 않다는 점을 많이 느꼈다.
Experienced Headcount ≠ Effective Decision Capacity
조직도에는 충분한 경력자가 있어도, 지금 이 Project가 그 경험을 바로 사용할 수 있는 것은 아니다.
필요한 사람이 다른 Project를 지원하고 있을 수 있다.
Role이 바뀌어 Management 비중이 커졌을 수 있다.
새로운 Block이나 Project로 이동해 Context를 다시 익히는 중일 수 있다.
여러 Project의 Review를 동시에 맡고 있을 수도 있다.
이직이나 퇴사도 그중 하나의 경우다.
결국 Project 관점에서 중요한 것은 “경력자가 몇 명인가”보다 “필요한 경험과 Context를 가진 사람이 필요한 시점에 실제로 판단에 기여할 수 있는가”였다.
필요한 경험과 Project Context를 가진 사람이 필요한 시점에 실제 Review와 판단에 참여할 수 있는 정도(이후 Effective Decision Capacity로 표현)는 단순한 경력자 수와 달랐다.
또 하나는 새로 업무에 들어온 사람이 해당 Project의 Context를 익혀 실제 판단에 기여하기까지 시간이 필요하다는 점이었다.
충분히 숙련된 Engineer라도 새로운 Project에 들어가면 바로 같은 판단을 할 수 있는 것은 아니다.
Architecture, Spec History, 과거 Failure, 이전 Decision의 이유와 Review Criteria를 익혀 실제 판단에 참여하기까지 시간이 필요하다.
Machine Resource는 증설하면 비교적 빠르게 Capacity가 늘어난다.
하지만 숙련된 사람의 판단 Capacity는 Availability, Domain Fit, Project Context, Decision Experience, 실제 투입 가능한 시간에 따라 달라진다.
필요한 시점에 장비를 증설하듯 바로 늘리기 어렵다.
그래서 내가 본 구조는 대략 이랬다.
Execution Capacity는 크게 증가한다.
Result Volume도 증가한다.
Review와 Interpretation Load도 증가한다.
그런데 Effective Decision Capacity는 같은 속도로 증가하지 않는다.
이 Gap이 Project TAT의 새로운 Bottleneck이 될 수 있었다.
여기서 “사람이 가장 비싼 Resource”라는 말은 단순히 연봉이 높다는 뜻이 아니다.
Project Context를 충분히 이해하고 중요한 판단을 할 수 있는 사람의 시간은 필요할 때 즉시 추가하기 어렵고, 다른 Resource처럼 쉽게 복제할 수도 없다는 의미에 가깝다.
다음 편 — 경험 있는 사람이 필요한 순간 바로 판단하기 어려운 이유는, Project의 무엇이 사람에게만 남아 있기 때문일까?