SoC 업계에서 AI 이야기를 시작하면 자연스럽게 듣는 질문이 있었다.
“AI로 Verilog RTL이나 UVM Test부터 만들면 생산성 효과가 더 직접적이지 않을까요?”
충분히 합리적인 제안이었다.
AI Code Generation의 가치를 부정한 적도 없다.
그런데 내 머릿속에서는 바로 다음 질문이 따라왔다.
AI가 RTL을 만들었다면 그 RTL이 실제 Design Intent와 Spec에 맞는지는 누가 확인할까?
AI가 UVM Environment와 Test를 만들었다면 그 Test가 정말 확인해야 할 Behavior를 검증하고 있는지는 누가 판단할까?
Compile과 Simulation이 PASS해도 확인해야 할 Condition이 빠져 있을 수 있다.
실제 Project에 적용할지, Sign-off 가능한지는 결국 사람이 판단하고 Accountability를 져야 한다.
그래서 당시 내가 먼저 풀고 싶었던 문제는 “AI가 Code를 만들 수 있는가?”보다 조금 다른 곳에 있었다.
사람이 같은 업무를 반복해서 설명하고, Script를 다시 만들고, 사용 방법을 정리하고, Knowledge를 문서로 남기고, 다음 사람에게 또 설명하는 Human Work를 줄여보고 싶었다.
처음부터 조직의 Knowledge를 자산으로 남기는 방법이나 Harness, Context 관리 구조를 설계하려고 한 것은 아니다.
내가 기대한 구조는 훨씬 단순했다.
Human Know-how → AI Agent에게 업무 설명 → Script 생성 → Knowledge/Document 생성 → Project 적용 → 다음 업무에서 재사용
단순 Chat처럼 질문에 답하는 것보다, 설명한 업무를 바탕으로 여러 Step을 이어가며 파일과 Script를 만들고 수정하는 AI Agent 방식이 필요했다.
그리고 Creation 자체는 실제로 빨라졌다.
Script 초안을 빠르게 만들 수 있었고, 자연어로 수정할 수 있었고, 새로운 아이디어를 바로 시험할 수 있었고, 사용 방법과 관련 Knowledge를 정리한 Document도 만들기 쉬워졌다.
처음에는 “이제 사람에게만 있던 경험을 훨씬 쉽게 결과물로 남길 수 있겠다”고 생각했다.
그런데 시간이 지나 예전에 만든 Script와 Document를 다시 보면서 다른 문제가 보이기 시작했다.
무엇을 수행했는지, 어떤 Result가 나왔는지, 최종 상태가 무엇인지는 남아 있었다.
하지만 원래 Intent가 무엇이었는지, 처음 어떤 Assumption으로 시작했는지, 어떤 Alternative를 시도했다가 버렸는지, 왜 판단을 바꿨는지, 어떤 Context에서 그 결과가 유효한지는 충분히 남지 않은 경우가 있었다.
Script도 있고 Document도 있는데 다시 든 질문은 이것이었다.
“왜 이렇게 만들었지?”
문서가 남는 것 ≠ 맥락이 남는 것
3편에서 사람의 Project Artifact와 Knowledge Asset이 같은 것이 아니라고 느꼈던 문제가 AI Workflow에서도 반복된 셈이다.
AI가 Document를 만들어 준다고 경험과 판단의 Context까지 자동으로 보존되는 것은 아니었다.
Knowledge File을 제공하는 것도 충분하지 않았다.
Project에서는 Spec, Input, Result, Decision, Exception, Script와 Assumption이 계속 변한다.
AI가 Knowledge에 접근할 수 있다는 것과, 현재 업무 상태에 맞는 올바른 Knowledge와 Context를 지속적으로 가지고 일한다는 것은 달랐다.
여기서 내가 말하는 Intent는 단순한 한 줄 지시가 아니라 이 일을 왜 하는지와 어떤 제약을 지켜야 하는지까지 포함한 의도에 가깝다.
Context도 Chat History 자체보다 현재 Project State, 이전 Action과 Decision, Result를 이어서 이해하는 데 필요한 맥락을 뜻한다.
Context가 어긋나면 사람은 이전 상황을 다시 설명한다.
Agent가 다른 결과를 만들면 다시 Review한다.
Knowledge를 고친다.
Script를 고친다.
Document를 고친다.
다시 실행한다.
Human Work가 사라진 것이 아니라 “AI가 잃어버린 Context를 사람이 다시 공급하는 일”로 바뀌는 것 아닐까 하는 생각이 들었다.
Model 자체에 Domain Knowledge를 학습시키는 방법도 생각해 볼 수 있다.
충분한 Data, Compute, ML Engineering 역량과 지속적인 Evaluation 체계를 가진 조직이라면 Training이나 Fine-tuning을 중요한 선택지로 검토할 수 있다.
다만 Engineering Knowledge는 계속 바뀐다.
Spec Change, Failure, Rule, Exception, Decision, Learning이 생길 때마다 이를 Model에 지속적으로 반영하려면 Data를 정리하고, 다시 학습시키고, 평가하고, Regression을 확인하고, 배포하는 별도의 관리 과정이 필요하다.
모든 SoC 조직이 이것을 핵심 운영 역량으로 가져가야 하는지는 별개의 문제였다.
그래서 이때부터 이런 질문이 생기기 시작했다.
“조직의 Knowledge를 반드시 Model이 기억해야 할까?”
“Model 밖에서 변화하는 Knowledge와 Intent, Context를 관리하고 필요한 순간 AI가 정확한 것을 사용하게 할 수는 없을까?”
나중에 정리해 보니 “조직에 남겨야 할 Knowledge와 Model Weight는 같은 성격의 자산이 아니다”라는 판단으로 이어지는 질문이었지만, 당시에는 아직 답을 몰랐다.
Harness라는 개념도 지금처럼 이해하고 있지 않았다.
다만 한 가지는 분명해지고 있었다.
빠르게 만드는 것과 오래 재사용할 수 있게 만드는 것은 다른 문제였다.
그리고 처음 피해 갔던 질문도 여전히 남아 있었다.
AI가 무엇인가를 만들 수 있다는 것과, 그 결과를 Engineering Result로 믿을 수 있다는 것은 같은 일일까?
그 질문은 뒤에서 다시 돌아오게 된다.
다음 편 — AI로 Script와 Knowledge를 더 빨리 만들었는데, 왜 비슷한 문제는 계속 반복됐을까?