이번 AX에 대한 고민과 실제 수행은 AI에서 시작한 것이 아니었다.
“나는 이 SoC 일을 언제까지 지금과 같은 방식으로 할 수 있을까?”
라는 개인적인 질문에서 시작했다.
나는 이 일을 싫어해서 떠나고 싶었던 것이 아니다.
가능하면 오래 하고 싶었다.
하지만 경력이 쌓일수록 더 많은 Failure와 Corner Case가 보였고, Decision, Review, Sign-off와 설명의 책임도 커졌다.
그래서 “어떻게 더 강하게 버틸까?”보다 “이 일을 오래 할 수 있도록 불필요한 부담 자체를 줄일 방법은 없을까?”를 고민하게 됐다.
10편을 지나오면서 내가 줄이고 싶었던 ‘무게’가 무엇인지 조금 더 명확해졌다.
책임 자체가 아니었다.
SoC Engineering에는 여전히 책임 있는 판단과 Verification이 필요하다.
내가 줄이고 싶었던 것은 이런 일들이었다.
과거에 이미 했던 판단을 처음부터 다시 복원하는 것.
이미 겪은 Failure를 같은 방식으로 다시 겪는 것.
Rule이 왜 생겼는지 알기 위해 사람을 찾아다니는 것.
Review 직전에 근거를 다시 모으는 것.
암묵적인 Criteria를 뒤늦게 맞추느라 같은 분석을 반복하는 것.
Responsibility remains.
Reconstruction should not.
이 문장은 표준 Engineering 용어가 아니라 이번 AX 관련 고민과 수행을 거치며 남은 생각을 압축한 표현이다.
책임을 없애고 싶은 것이 아니다.
다만 이전 사람이 이미 겪고 배운 것을 다음 사람이 다시 처음부터 복원해야 하는 부담은 줄이고 싶었다.
Project에는 자연스럽게 “이 문제는 그 사람에게 물어봐야 한다”는 Knowledge Holder가 생긴다.
경험 있는 사람이 있다는 것은 큰 자산이다.
하지만 조직의 Knowledge가 충분히 남지 않으면 Senior Engineer가 새로운 판단을 하는 사람인 동시에 과거 Project History를 보관하는 Project Memory 역할까지 맡게 될 수 있다.
나는 Senior의 가장 가치 있는 시간이 과거 자료를 다시 찾아주고 같은 설명을 반복하는 데 사용되기보다, 새로운 Risk와 Exception을 판단하고, 후배와 이야기하고, 더 어려운 문제를 푸는 데 사용되는 편이 낫다고 생각한다.
Human Time → Judgment
AI와 AX의 목적을 사람이 필요 없어지는 것으로 보고 싶지 않은 이유다.
사람의 시간을 없애는 것이 아니라 사용처를 바꾸는 것이다.
돌이켜보면 내가 해결하고 싶었던 것은 Engineer 개인의 역량을 더 끌어올리는 문제가 아니었다.
내가 IP나 ASIC의 일부 영역을 중심으로 일하던 때보다 SoC 수준에서 한 사람이 동시에 이해하고 확인해야 할 관계와 판단 범위가 훨씬 넓어졌고, 이제는 개인의 경험과 기억만으로 감당하기 어려운 복잡도를 조직의 System이 함께 받아줘야 한다고 느꼈다.
Search, Collect, Reconstruct, Summarize, Explain에 반복해서 쓰던 시간을 Engineering Judgment에 더 쓰게 하는 것.
경험을 남긴다는 의미도 처음 생각했던 것보다 넓어졌다.
Final Result만 보관하는 것이 아니었다.
무엇을 하려 했는지와 어떤 기준으로 판단했는지, 어떤 Rule과 Contract가 생겼고 왜 필요한지, 무엇을 실행하고 확인했으며 어떤 Failure에서 무엇을 배웠는지, 그리고 그 판단과 다음 Action의 History까지 함께 남아야 했다.
필요하면 이런 내용을 Intent, Decision Context, Skill·Policy·Contract, Engineering Evidence 같은 구조로 정리할 수 있다.
하지만 중요한 것은 용어가 아니라 다음 사람이 그 이유를 다시 확인하고 사용할 수 있느냐였다.
무엇을 했는가뿐 아니라 왜 그렇게 판단했고, 무엇을 확인했고, 무엇이 실패했고, 그 결과 무엇을 배웠는지가 다음 업무에서 다시 사용할 수 있는 형태로 남아야 했다.
Schema Drift, Path Hallucination, Stuck Loop, Session Context Loss, Silent PASS 같은 실패도 실패 자체가 중요한 것은 아니다.
왜 Schema Validation이 생겼는지, 왜 Path를 추측하지 않고 Repository에 실제로 무엇이 있는지 먼저 확인하게 됐는지, 왜 Stop Condition을 넣었는지, 왜 Context Recovery와 Explicit Validation을 요구하게 됐는지.
Failure → Learning → Engineering Rule → Harness.
그리고 여러 Harness에서 반복되는 Learning과 Control Pattern은 다시 그 바깥의 공통 구조로 축적될 수 있었다.
이 연결이 남아야 다음 사람이 같은 Failure를 다시 겪지 않고도 그 Learning에서 출발할 수 있다.
Experience ≠ Answer
과거 경험을 System에 남긴다고 예전 Senior의 답을 현재 Project에 그대로 적용하자는 뜻도 아니다.
Technology, Customer, Constraint, Risk는 바뀐다.
경험은 정답보다 출발점이어야 한다.
“이전에는 이런 조건에서 이렇게 판단했고, 근거와 결과는 이랬다. 이제 현재 조건에서 다시 판단하라.”
내가 생각하는 좋은 Knowledge Asset은 이런 형태에 가깝다.
그리고 이것은 Junior만을 위한 문제도 아니다.
충분한 경력을 가진 Senior도 새로운 Project, Block, 조직, Customer, Role에 들어가면 그 Project의 Decision History와 Failure History를 모른다.
목표는 누군가를 Senior처럼 흉내 내게 만드는 것이 아니라, 새롭게 업무에 들어온 사람이 조직이 이미 배운 것을 다시 처음부터 배우지 않도록 하는 것이다.
최근 SoC AI의 흐름을 보면서 한 가지는 다시 확인할 수 있었다 내가 처음 AI를 SoC 업무에 적용해 보기 시작했을 때는 자연스럽게 Code Generation이나 반복 업무 자동화처럼 눈에 보이는 기능부터 생각했다.
하지만 실제로 적용해 보면서 내 관심은 점점 다른 곳으로 이동했다.
하나의 RTL이나 Script를 잘 만드는 것보다, 여러 Step이 어떤 Context와 State를 공유해야 하는지, 어떤 Tool과 Source를 기준으로 움직여야 하는지, 잘못된 실행을 어디에서 멈춰야 하는지, 결과를 무엇으로 확인할 수 있어야 하는지가 더 중요하게 보이기 시작했다.
최근 SoC 관련 AI 업체들의 공개 방향을 보면 비슷한 변화도 보인다.
초기에는 RTL Generation이나 특정 Verification Task처럼 비교적 명확한 개별 업무가 많이 강조됐지만, 최근에는 Design, Verification, Debug를 연결하고 여러 Agent와 EDA Tool이 함께 움직이는 Agentic Workflow까지 범위를 넓히는 흐름이 보인다.
물론 이들이 내가 생각한 Harness나 Knowledge Asset과 같은 방법을 사용한다는 뜻은 아니다.
다만 AI가 무엇을 생성할 수 있는가에서, 실제 Engineering Workflow 안에서 어떻게 일을 수행하게 할 것인가로 질문의 범위가 넓어지고 있다는 점은 내가 시행착오를 겪으며 질문을 바꿔 온 과정과 비슷하게 느껴졌다.
그래서 지금 내 관심도 “어떤 AI 기능을 더 만들 수 있는가?”
보다 “SoC Engineering에서 실제로 반복되는 어떤 문제를 끝까지 줄일 수 있는가?”
에 더 가깝다.
그리고 이 질문은 결국 나 자신에게도 돌아왔다 나는 AI를 전공한 사람이 아니다.
박사나 석사도 아니다.
NPU를 설계하는 전문가도 아니고 Foundation Model을 Training하는 연구자도 아니다.
그렇다면 내가 지금까지 해온 경험을 바탕으로 앞으로 계속할 수 있는 일은 무엇일까?
처음에는 이 질문이 꽤 부담스러웠다.
하지만 지금은 내가 모든 AI 기술을 직접 만들어야 한다고 생각하지 않는다.
내가 오래 경험한 것은 SoC Engineering에서 실제로 일이 어디에서 막히는지, 어떤 판단이 늦어지는지, 어떤 Context가 사라지는지, 어떤 Failure가 반복되는지에 대한 문제다.
AI에 대해 모르는 부분은 배우거나 필요한 전문가와 협업하면 된다.
대신 내가 알고 있는 Engineering Problem을 더 정확히 정의하고, AI를 어디에 어떻게 적용해야 실제 도움이 되는지를 연결하는 일은 내가 계속할 수 있다고 생각하게 됐다.
Trust me → Verify with me.
내가 모든 것을 안다고 말하기보다, 무엇을 알고 무엇을 모르는지 범위를 분명히 하고 내가 실제로 무엇을 확인했는지를 보여주는 방식으로 일하고 싶다.
실제 SoC Domain Experience를 보여주고, 개인의 감각을 반복 가능한 업무 Know-how와 Rule, Contract, Harness처럼 다시 사용할 수 있는 구조로 바꾸고, 여러 Harness에서 반복되는 Control과 Learning 역시 조직의 Asset으로 남기고, 새로운 Model과 Tool을 실제 업무 조건에서 Qualification하고, “됩니다”라고 말하는 대신 무엇을 실행했고 무엇을 확인했으며 무엇을 확인하지 못했는지를 Engineering Evidence로 보여주는 것.
이것이 내가 앞으로 일하고 싶은 신뢰의 방식에 더 가깝다.
내가 책임지고 싶은 영역은 실제 SoC Engineering Work에서 어떤 문제에 AI를 적용할지, 어떤 Knowledge와 Contract를 남길지, 어떤 Model과 Runtime이 충분한지 어떻게 Qualification할지, 어떤 Harness로 통제할지, 무엇을 Evidence로 남길지, 어디까지 위임하고 어디서 Human Decision을 요구할지를 함께 설계(AX Architect)하는 일이다.
이번 AX 관련 고민과 수행을 관통하는 문장인 “개인의 경험에서, 조직의 통찰로, 시스템의 자산으로” 도 결국 이 과정을 말한다.
개인의 경험을 그대로 저장하는 것이 아니라 Experience → Learning → Engineering Rule → 다시 사용할 수 있는 System Asset 으로 바꾸는 것.
AI는 그 경험을 대신 소유하는 주체가 아니라, 조직이 구조화한 Knowledge와 Rule, Criteria, Contract, Evidence Requirement를 필요한 순간 Workflow에서 사용할 수 있게 돕는 중요한 수단이다.
내가 남기고 싶은 것은 AI가 아니다 내가 이미 겪은 시행착오와 그때의 판단 근거가 다음 사람에게 다시 같은 답을 강요하는 규칙이 아니라, 조금 더 나은 판단을 시작할 수 있는 출발점으로 남는 것이다.
다음 Engineer가 같은 Responsibility를 가지더라도, 조직이 이미 배운 것 위에서 시작할 수 있기를 바란다.
과거 판단을 처음부터 복원하는 일을 조금 덜 하고, 같은 Failure를 조금 덜 반복하고, 조금 덜 불필요하게 걱정하고, 조금 더 중요한 판단에 시간을 쓰면서, 조금 더 오래 이 일을 이어갈 수 있기를 바란다.
이 고민은 지금 내가 SoC 업계에서 배운 것을 다른 방식으로 현장에 보태고 싶어하는 배경이기도 하다.
개인의 경험이 다음 사람의 출발점이 되고, 반복된 Learning이 조직 안에 남을 수 있게 하는 것.
지금 내가 앞으로도 계속 풀어가고 싶은 문제는 그것이다.
이 과정이 정답이라고 생각하지는 않는다 내가 겪은 Project와 조직의 방식 안에서 문제를 하나씩 따라가며 지금까지 도달한 생각에 가깝다.
그래서 오히려 비슷한 고민을 하고 있는 사람들의 경험이 궁금하다.
SoC 개발에서 이미 했던 판단을 다시 복원하는 데 시간이 많이 들었던 경험, 특정 사람에게 Knowledge가 집중되어 어려움을 겪었던 경험, AI를 실제 업무에 적용하면서 기대와 다른 문제를 만났던 경험, Agent를 어디까지 믿고 어디에서 사람이 확인해야 하는지 고민했던 경험이 있다면 이야기를 들어보고 싶다.
같은 문제를 보더라도 조직과 Role, 업무에 따라 전혀 다른 답이 있을 수 있다고 생각한다.
그리고 내가 여기에서 다루지 못한 SoC 개발의 다른 문제를 AI나 AX로 풀어가고 있는 경험도 궁금하다.
어떤 문제를 선택했고, 실제로 적용해 보니 무엇이 달라졌으며, 예상하지 못했던 어려움은 무엇이었는지도 배우고 싶다.
내가 미처 보지 못한 문제나, 같은 문제를 다른 방식으로 풀어본 경험, 또는 전혀 다른 Engineering Problem을 AX로 풀어가고 있는 경험이 있다면 그 이야기도 듣고 배우고 싶다..