6편에서는 Model이나 Agent Runtime 같은 AI Environment는 바뀔 수 있어야 하고, 그 변화 때문에 Knowledge와 Engineering Rule, Harness Learning까지 다시 만들고 싶지는 않았다는 이야기를 했다.
그런데 AI Environment를 교체 가능한 Component로 본다고 해서 어떤 Model이나 Runtime이든 그대로 바꿔 넣을 수 있다는 뜻은 아니었다.
오히려 교체 가능한 Component라면 “이것이 실제 SoC 업무에 사용할 수 있는 수준인가?”를 판단할 기준이 필요했다.
Model 하나만 볼 수도 없었다.
실제 업무에서는 H/W, Inference Environment, Model, Agent Runtime이 함께 동작한다.
어느 한 부분에서 Tool Calling이 불안정하거나 Response가 지나치게 느리거나 Resource를 과도하게 사용하면 전체 Workflow는 사용할 수 없었다.
그래서 6편에서 AI Environment와 Engineering Asset을 분리한 뒤, 다음으로 필요했던 것은 AI Environment를 실제 업무 조건에서 Qualification하는 과정이었다.
“그렇다면 우리가 실제 SoC 업무에 사용할 AI Environment는 어느 정도면 충분할까?”
내 경우 Qualification의 첫 번째 전제 조건은 On-Premise였다.
내부 Spec, RTL과 Repository, Script, EDA Result, Log, Project-specific Knowledge와 고객 정보를 다루는 환경에서 모든 업무를 외부 Cloud AI에 의존하는 구조를 기본 전제로 삼기는 어려웠다.
Local AI가 Cloud보다 우월하다는 이야기가 아니다.
조직이 통제하는 내부 환경에서 Model과 Agentic Workflow를 운영할 수 있어야 한다는 실제 업무 조건이었다.
따라서 질문은 “어떤 AI가 가장 좋은가?”가 아니라 “우리가 통제하는 환경 안에서 실제 SoC 업무를 수행할 수 있는 AI Environment는 무엇인가?”에 가까웠다.
On-Premise라는 Constraint를 만족하려면 실제로 Model을 실행하고 계속 Qualification할 수 있는 H/W 기반이 필요했다.
2026년 3월경 실제 H/W 후보를 검토하면서 Apple Silicon 기반 Mac과 AMD Strix Halo 기반 제품도 함께 봤다.
최종적으로 DGX Spark를 선택했지만 이것은 H/W Benchmark 자체가 목적이 아니었다.
앞으로 Model과 Runtime을 바꿔가며 Qualification할 수 있는 운영 기반을 고르는 문제에 가까웠다.
내가 함께 본 것은 On-Premise로 운영 가능한지, 초기 비용, 필요한 Model을 실제로 돌릴 수 있는지, S/W 지원 환경, 문제 발생 시 대응 가능성, 장기 지원과 유지보수였다.
성능 차이만으로 선택이 명확하지 않다면 몇 년 동안 AI Server로 운영할 때 어느 Ecosystem이 더 편한지가 중요하다고 판단했다.
Model/Runtime 지원 범위, Driver·Container 호환성, 문제 발생 시 참고할 수 있는 자료와 장기 유지보수 같은 측면에서 당시 목적에는 NVIDIA/CUDA Ecosystem이 더 적합하다고 보았다.
이것은 AMD보다 NVIDIA가 절대적으로 우월하다는 주장이 아니다.
그 시점의 운영 목적과 조건에서 내린 Engineering Decision이다.
H/W를 고르는 동안 Model 설치와 Agent Workflow 개발도 함께 진행했다.
처음 Model을 평가하는 방법은 지금 생각하면 단순했다.
몇 가지 질문에 잘 답하는가?
간단한 Coding과 Reasoning이 가능한가?
몇 차례 결과가 괜찮으면 “이 정도면 쓸 수 있겠다”고 생각하기 쉬웠다.
나도 그렇게 시작했다.
질문에는 잘 답하던 Model이 실제 Workflow에서 멈추면서 기준이 완전히 바뀌었다.
단순 Chat이 아니라 Model이 필요한 기능을 선택해 Tool을 호출하고, 그 결과를 받아 다음 작업을 이어가는 Agentic Workflow를 보여주고 있었다.
그 과정에서 Tool Calling Timeout이 발생했다.
질문에는 잘 답하던 Model이 실제 여러 Step의 업무에서는 안정적으로 끝까지 동작하지 못했다.
이 경험 이후 내게 중요한 구분이 하나 생겼다.
좋은 답변 ≠ 실제 업무 투입 가능성
Chat은 Question → Answer로 끝날 수 있다.
하지만 Agentic Workflow는 Request → Reasoning → Tool 선택 → Tool Call → Result 수신 → Result 해석 → 다음 Action 으로 이어진다.
좋은 답변을 만드는 능력과 실제 Engineering Workflow를 끝까지 수행하는 능력은 달랐다.
Tool Calling, 응답속도, 동시 Request 처리, Resource 사용까지 포함해 실제 업무에 투입할 수 있는지가 더 중요했다.
그래서 Model 평가 기준을 다시 만들었다.
첫째, 실제 여러 Step의 Agentic Task를 수행할 수 있는가.
둘째, 필요한 Tool을 적절히 선택하고 호출한 뒤 Result를 다음 Action으로 이어갈 수 있는가.
셋째, 응답속도가 Engineer가 실제 업무 중 사용할 수 있는 수준인가.
여기서 TPS는 초당 생성되는 Token 수로, 숫자 자체보다 Engineer가 기다려야 하는 시간을 가늠하기 위한 지표로 봤다.
넷째, 여러 Request가 동시에 들어올 때 성능이 얼마나 떨어지는가.
다섯째, DGX Spark 한 대에서 Model과 Agent가 실제로 얼마나 많은 GPU Memory와 Computing Resource를 사용하는가.
여러 Request가 동시에 들어올 때의 성능도 직접 봤다.
Model 선택 과정에서는 4개의 Request를 동시에 처리했을 때 TPS와 Response Time이 얼마나 저하되는지 확인했다.
여기서는 실제로 확인한 범위와 향후 운영 Target으로 둔 범위를 분명히 구분할 필요가 있다.
약 10명 규모가 Local AI 환경을 함께 사용하는 것은 내가 생각한 운영 Design Target이다.
“DGX Spark 한 대에서 10명이 동시에 문제없이 Agentic 업무를 수행하는 것을 이미 검증했다”는 의미는 아니다.
4개의 Request를 동시에 처리한 조건은 실제로 민감도를 확인한 Benchmark 조건이고, 10명은 향후 조직 사용을 고려한 Target이다.
Benchmark보다 실제 업무 조건에서 Qualification하는 것이 더 중요해졌다
“어떤 Model이 최고인가?”보다 “우리가 실제 사용할 조건에서 이 Model이 업무에 투입 가능한가?”가 더 중요해졌다.
일반 Benchmark Score가 높은 것은 유용하다.
하지만 우리 Tool을 잘 부르는지, 필요한 속도가 나오는지, 동시 Request에서 견디는지, 제한된 Local H/W에서 운영 가능한지를 모두 대신 설명해 주지는 않는다.
그래서 최고 성능보다 실제 업무 조건을 먼저 정하고, 그 조건을 만족하는 충분한 기술을 찾는 것이 내 선택 방식이 됐다.
H/W에서도, Agent Runtime에서도, Model에서도 같은 원칙이 반복됐다.
제품 자체보다 무엇을 기준으로 선택했는지와 그 과정에서 얻은 Learning이 더 오래 남는 자산이어야 했다.
Tool Calling, 응답속도, 여러 Request가 동시에 들어올 때의 성능, 실제 Resource 사용량까지 확인하면서 6편에서 분리해 둔 AI Environment를 실제 업무 조건에서 Qualification하는 기준은 이전보다 더 분명해졌다.
다음 편 — Tool도 잘 부르고 Task도 끝냈다면, 이제 그 결과를 Engineering Result로 믿어도 될까?