EDA 에이전트가 설계 반복을 맡는 방식

툴 호출을 이어 붙이는 것보다 한 단계 더

Synopsys의 AgentEngineer·Autopilot 발표는 여러 단계를 이어가는 에이전트와 개별 작업 에이전트를 함께 제시한다. 기반 플랫폼에는 재사용 스킬, 지속 메모리, 실행 관측 정보와 접근 통제가 들어간다. 이전 작업의 맥락을 다음 판단에 쓰겠다는 구성이다. 내부 메모리 방식은 공개문만으로 알 수 없으며, 제품 제공은 2026년 말로 예정돼 있다.

Cadence의 설명은 실행과 측정 뒤에 진단을 둔다. 실패 로그는 원인을 좁힐 단서이고, 에이전트는 그 근거로 다음 작업을 고른다. EDA 도구는 설계 결과를 검사하며, 실행 환경은 행동의 허용 여부를 통제한다. 후보를 고르는 내부 알고리즘까지 공개한 것은 아니다.

접근 정책의 증명과 RTL의 검증은 대상이 다르다

OpenShell 기술 문서에서 중요한 부분은 제어가 에이전트 프로세스 바깥에 있다는 점이다. 파일·네트워크 제한은 생성 코드와 하위 프로세스에도 적용된다. Policy Prover는 모델링된 접근 권한이 운영자가 정한 범위를 넘는지 확인한다. 검사 대상은 허용된 행동의 범위이며, RTL이 스펙대로 동작하는지는 아니다.

NVIDIA의 같은 날 발표도 OpenShell 소프트웨어와 BlueField-4 기반 Sentry 참조 시스템을 구분한다. 전자는 공개 제공 상태이고, 후자는 에이전트 실행 환경 밖에서 감시·통제하는 별도 구성을 제시한다. 소프트웨어를 받을 수 있다는 사실만으로 특정 EDA·하드웨어 조합의 실전 검증까지 끝났다고 볼 수는 없다.

에이전트가 RTL과 검증 환경을 모두 고칠 수 있다면 “수정 후 통과”의 의미부터 분리해야 한다. 회로가 나아졌는지, 검사 조건이 달라졌는지 기록이 필요하다. 승인된 속성과 가정은 별도로 버전 관리하고, 에이전트가 새 속성을 제안하면 그 변경도 검토하는 구성이 합리적이다. 실행 권한을 제한하는 것과 판정 기준의 의미를 지키는 것은 함께 필요한 작업이다.

30%와 24%를 같은 성능표에 놓을 수 없는 이유

발표에 실린 수치는 자동화가 노리는 작업을 보여준다. 다만 코드 생성 작업의 생산성과 회로 면적은 서로 다른 측정값이다. 무엇을 분모로 삼았는지부터 맞춰야 한다.

Cadence는 스펙에서 RTL을 만들거나 기존 RTL을 바꾸는 과정에 구현·검증 엔진을 결합한다고 설명한다. 따라서 이 PPA 수치는 EDA를 결합한 생성·수정 흐름과 모델 단독 생성의 차이다. 함께 제시한 “100% 기능 정확도”는 평가 회로와 오류 판정 범위가 공개되지 않은 초기 평가 주장이다. 해당 확장 기능의 조기 접근은 2026년 4분기 일부 고객 대상으로 예정돼 있다.

자기 팀에서는 같은 블록과 기능·타이밍 조건으로 비교해야 한다. 사람의 개입이 줄어도 EDA 실행량은 늘 수 있다. 작업 시간, 도구 사용량, 최종 PPA를 따로 기록해야 얻은 효과가 보인다. 현재 수치만으로 전체 일정 단축률이나 제품 순위를 계산할 수는 없다.