나는 SoC 개발 관련 업무를 오래 하고 싶었다.
오랫동안 해 온 일이었고, 여전히 내가 가장 잘 알고 좋아하는 분야였다.
그런데 어느 순간부터 “나는 이 일을 언제까지 지금과 같은 방식으로 할 수 있을까?”라는 생각을 자주 하게 됐다.
힘든 이유가 단순히 일이 많아서만은 아니었다.
경력이 쌓일수록 더 많은 Failure와 Corner Case가 보였다.
하나를 결정해도 “이 조건은 괜찮을까?”, “Side-effect 문제가 없을까?”, “예전 Project에서는 어땠지?”가 계속 떠올랐다.
중요한 Review나 Sign-off를 지나고 나서도 놓친 것이 없는지 다시 생각하곤 했다.
돌이켜보면 내가 더 조심스러워진 것만이 이유는 아니었다.
내가 IP나 ASIC의 일부 영역을 중심으로 개발하던 시기에는 한 Engineer가 직접 이해하고 확인해야 하는 범위와 관계가 지금보다 상대적으로 좁았고, 경험이 쌓이면 상당 부분을 개인의 기억과 판단 안에서 감당할 수 있었다.
물론 당시의 개발이 단순했다는 뜻은 아니다.
SoC 수준으로 범위가 넓어지면서 Block과 Interface, HW/SW Interaction, 여러 Constraint와 후속 단계에 미치는 영향까지 함께 봐야 하는 관계가 많아졌다.
개인이 더 많이 기억하고 더 꼼꼼하게 확인하는 방식만으로 이 복잡도를 계속 감당하는 데에는 한계가 있다는 생각이 들기 시작했다.
문제는 신중함이 아니었다 조직에서 중요한 Decision이 위로 올라갈수록 비슷한 일이 반복됐다.
“다른 조건도 확인해 봤나요?” “이전 결과와 비교해 주세요.” “문제가 생기면 이 판단을 왜 했는지 설명할 수 있나요?”
이 질문들은 대부분 합리적이다.
나 역시 같은 위치라면 비슷한 질문을 했을 것이다.
문제는 누가 신중하냐 아니냐가 아니었다.
무엇을 어디까지 확인해야 하는지가 충분히 정리되어 있지 않았다 내가 경험한 많은 경우에는, 판단을 위해 어떤 자료가 필요한지는 대략 알고 있어도 무엇을 반드시 봐야 하는지, 어느 Source를 기준으로 해야 하는지, 어떤 조건을 비교해야 하는지, 어느 정도의 차이를 중요하게 볼지, 어디까지 확인하면 Review를 끝낼 수 있는지가 충분히 구조화되어 있지 않았다.
Checklist가 있어도 그 항목을 어떤 기준과 Source로 채워야 하는지까지 명확하지 않은 경우가 있었다.
그래서 Engineer는 요청의 의도를 해석해 자료를 만든다.
결과를 본 Decision Maker는 그제야 자신이 확인하고 싶었던 기준을 더 구체화한다.
다시 분석하고, 다시 정리하고, 다시 설명한다.
판단 자료를 만드는 일이 다시 판단을 늦췄다 Decision 필요 → 판단 자료 준비 → Review → 판단 기준 구체화 → 추가 분석 → 재정리 → 재검토 → Decision
특정 판단을 위해 그때그때 준비하는 비교표, 분석 결과, Log 정리, Review용 PPT·Excel·Report 같은 자료(이후 Decision Material로 표현)는 판단이 필요할 때마다 다시 만들어지는 경우가 많았다.
어느 Source를 기준으로 볼지, 어떤 Condition을 비교할지, 어느 정도의 차이를 중요하게 볼지, 반드시 확인해야 할 Check는 무엇인지 같은 판단 기준(이후 Decision Criteria 또는 Review Criteria로 표현)도 충분히 구조화되어 있지 않은 경우가 있었다.
가장 경험 많은 사람의 시간이 Round-trip에 들어갔다 중요한 것은 이름이 아니다.
판단 기준이 경험과 직관에 머물면 자료를 찾고, 비교하고, 분석하고, 정리하고, 설명하고, 다시 만드는 일이 반복된다.
그때마다 가장 경험이 많은 사람의 시간이 Review와 재작업의 Round-trip에 계속 들어간다.
그런데 더 큰 문제는 Human Cost 자체보다 Decision이 늦어진다는 것이었다.
Engineering은 대개 Decision 이후에 Execution과 Verification이 시작된다.
판단이 틀려도 충분히 일찍 실행하고 검증하면 문제를 발견하고 수정할 기회가 있다.
반대로 Decision이 너무 늦어지면 검증의 시작도 늦어지고, 문제를 발견했을 때는 이미 되돌릴 시간이 부족할 수 있다.
현장에서 가장 답답했던 순간 중 하나는 문제가 보이는데도 일정 때문에 “이제는 그냥 가야 한다”는 선택을 해야 할 때였다.
빨리 결정하자는 것이 아니라, 고칠 시간을 남기자는 것이다 그래서 내가 중요하게 생각하게 된 것은 “빨리 결정하자”가 아니다.
근거를 줄이는 것도 아니다.
필요한 판단 기준과 자료를 더 일찍 명확하게 만들고, 사람이 Decision-ready 상태에 더 빨리 도달하게 하는 것이다.
그래야 틀렸을 때 고칠 시간도 남는다.
오래 하고 싶었지만, 같은 방식으로 계속할 수 있을까?
이런 구조를 되돌아보면서 내 개인적인 부담도 조금 다르게 보이기 시작했다.
나는 중요한 판단을 하고 나서도 반복해서 확인했고, 걱정이 수면에 영향을 주었던 때도 많았다.
함께 일했던 일부 Senior Engineer와 Engineer 출신 Director에게서 비슷한 모습을 본 적도 있다.
이것을 업계 전체의 문제라고 일반화하고 싶지는 않다.
다만 내게는 분명한 경험이었다.
개인이 더 버티는 것이 답은 아니라고 생각하기 시작했다 이런 경험이 반복되면서 처음에는 내가 조금 더 익숙해지고 더 잘 버티면 되는 문제라고 생각하기도 했다.
하지만 경력이 쌓일수록 책임과 판단의 범위도 함께 넓어졌고, 같은 방식으로 계속 일하는 것은 어렵겠다는 생각이 들기 시작했다.
SoC 개발이 싫어진 것은 아니었다.
오히려 오래 하고 싶었던 일이었다.
그래서 실무를 그만두고 다른 일을 해야겠다고 생각하면서도, 내가 가장 오래 해 왔고 가장 많은 경험을 쌓은 분야를 완전히 떠나는 것은 아쉬웠다.
처음에는 “SoC 일을 그만두면 나는 무엇을 하지?”라고 생각했다.
그런데 원인을 되짚어 보면서 질문이 조금 바뀌었다.
“내가 힘들었던 이 구조를 조금이라도 바꿀 수 있는 일을 해보면 어떨까?”
더 오래 일하기 위해 더 강하게 버티는 방법보다, 오래 일할 수 있도록 불필요한 부담을 줄이는 방법을 고민해 보고 싶었다.
다음 편 — EDA Tool과 H/W는 빨라졌는데, 왜 Project 전체는 그만큼 빨라지지 않았을까?