에이전트형 AI는 실제 하드웨어 엔지니어링을 수행할 준비가 되었는가? Phoenix-bench를 통한 심층 분석

우리는 소프트웨어 엔지니어링 (Software Engineering)을 위해 구축된 에이전트형 AI (Agentic AI) 시스템이 현실적인 하드웨어 엔지니어링 (Hardware Engineering)으로 전이될 수 있는지 질문합니다. 기존의 하드웨어 LLM 벤치마크들은 하위 작업들을 분리하여 다루지만, 저장소 탐색 (Repository Navigation), 계층 구조 인식 로컬라이제이션 (Hierarchy-aware Localization), 전자 설계 자동화 (EDA) 실행 가능성 검증, 그리고 유지보수 스타일의 패칭 (Patching)을 통합적으로 요구하는 벤치마크는 존재하지 않습니다. 우리는 114개의 GitHub 저장소에서 추출한 511개의 검증된 Verilator 인스턴스로 구성된 동기화된 코퍼스인 \textbf{Phoenix-bench}를 소개합니다. 각 인스턴스는 개발자 패치, 설계 흐름 (Design-flow) 레이블, 실패-통과 (Fail-to-pass) 및 통과-통과 (Pass-to-pass) 테스트벤치 (Testbench), 그리고 해결률 (Resolved-rate)의 차이가 툴체인 가용성이 아닌 에이전트의 행동을 반영할 수 있도록 고정된 Docker 기반의 EDA 환경을 포함합니다. Phoenix-bench를 사용하여 우리는 4개의 상용 에이전트와 8개의 오픈 소스 에이전트 구조를 4개의 LLM 백본 (Backbone)에 걸쳐 균일하게 평가하였으며, 두 가지 진단적 개입 (파일 수준의 오라클 로컬라이제이션 및 1회의 테스트벤치 로그 피드백)을 수행했습니다. 세 가지 주요 발견 사항이 도출되었습니다. (i) 소프트웨어와 하드웨어는 근본적으로 다른 엔지니어링 작업입니다: 동일한 에이전트가 SWE-bench Verified에서 Phoenix-bench로 넘어갈 때 37%에서 58%의 성능 저하를 보입니다. 이는 하드웨어 버그가 소프트웨어 스타일의 호출 그래프 (Call Graph)를 따라 흐르는 것이 아니라, 신호 흐름 (Signal Flow)을 통해 병렬로 인스턴스화된 모듈 전체로 전파되기 때문이며, 소프트웨어에 최적화된 에이전트들은 인스턴스화 체인 (Instantiation Chain)을 역추적하는 대신 증상이 나타난 파일에서 멈추기 때문입니다. (ii) 실패는 설계 제어 흐름 (Design Control-flow) / 유한 상태 머신 (FSM) 버그, 검증 테스트벤치 버그, 그리고 계층 구조를 넘나드는 신호 흐름 추적과 조정된 다중 파일 편집을 요구하는 난도 높은 사례에 집중됩니다. (iii) 로컬라이제이션 (Localization)의 정밀도는 로컬라이제이션 자체보다 훨씬 더 중요합니다: 완벽한 파일 수준의 오라클 (Oracle)을 제공하더라도 해결률은 단 1.4%만 상승하는데, 이는 에이전트가 편집할 필요가 없는 파일까지 망가뜨리기 때문입니다. 반면, 단 한 번의 테스트 케이스 피드백은 해결률을 42%에서 45%까지 끌어올리는데, 이는 테스트 케이스가 버그가 '어디에' 있는지와 수정 사항이 '어떠해야' 하는지를 알려주기 때문입니다.