AI의 칩 버그 수정, 전용 도구로 56분→21분…Booley 자체 실험

AI 코딩 에이전트가 칩 설계의 오류를 찾는 속도보다 수정 결과를 검증하는 환경이 작업 시간을 더 크게 좌우할 수 있다는 사례 분석이 나왔다. 오픈소스 RTL 개발 도구 Booley의 개발자는 10월 16일 공개한 자체 실험에서 전용 도구를 붙인 AI 에이전트의 평균 버그 수정 시간이 55.8분에서 21.3분으로 줄었다고 밝혔다. RTL은 반도체 회로의 동작을 기술하는 코드다.

실험 대상은 오픈소스 하드웨어 보안 모듈 Caliptra에 들어 있는 RISC-V 프로세서 VeeR EL2다. 작성자는 이미 수정된 과거 버그를 되살린 뒤, AI에 원인을 고치고 수정 전에는 실패하지만 수정 후에는 통과하는 재현 테스트를 작성하도록 했다. 새 취약점을 발견했다는 발표가 아니라, 알려진 오류를 이용해 디버깅 과정을 비교한 실험이다.

두 환경에는 같은 Claude Code 2.1.289와 Sonnet 5.5 모델, 같은 작업 지시와 컨테이너를 사용했다. 한쪽은 기존 셸과 Caliptra 빌드 스크립트만 제공했고, 다른 쪽은 Booley 0.3.0을 추가했다. 각 환경에서 90분 제한으로 10차례씩 수행했으며, 두 환경 모두 모든 시도에서 수정과 재현 테스트를 완료했다고 보고했다.

차이는 정답을 찾은 뒤에 벌어졌다. 원문에 따르면 에이전트는 대체로 5분 안에 문제가 있는 코드를 찾았다. 그러나 실제 시뮬레이션에서 오류를 드러내려면 메모리 설정과 명령 실행 간격을 조정해야 했다. 코드가 그럴듯하게 바뀌었다는 사실만으로는 수정이 입증되지 않는 셈이다.

Booley 환경은 시뮬레이션 파형을 검색하는 B-Wave, 작업 종료 시 결과를 반환하는 실행 도구, 빌드 설정을 파일에 담는 FuseSoC 구성을 제공했다. 파형은 칩 내부 신호가 시간에 따라 어떻게 바뀌는지 기록한 데이터다. 이를 직접 질의하면 내부 상태를 확인할 때마다 출력 코드를 추가하고 다시 빌드하는 과정을 줄일 수 있다.

대기 방식도 시간을 잡아먹었다. 일반 셸 환경의 한 시도에서는 작업이 이미 끝난 뒤에도 고정된 시간 동안 기다리는 데 30.7분을 썼다. 또 다른 시도에서는 셸 호출 사이에 환경변수가 유지되지 않아 펌웨어가 없는 시뮬레이션을 반복 실행했다. 전용 환경은 작업 완료를 기다렸다가 결과를 돌려주고, 선행 빌드가 실패하면 시뮬레이션을 시작하지 않도록 했다.

다만 시간 단축을 도구 자체의 일반적인 성능으로 받아들이기는 어렵다. 실험은 한 설계의 한 버그와 한 모델에 한정됐고, 비교 대상 도구를 만든 개발자가 직접 수행했다. Booley에 Caliptra를 연결하는 사전 설정 시간은 측정에서 제외됐으며, 세 가지 개선 요소의 효과를 따로 분리한 실험도 없었다.

작성자는 실험에 사용한 프로젝트 설정과 버전, 버그를 되살리는 패치, 에이전트 지시문을 공개했다. 이번 사례는 AI의 회로 추론 능력이 전반적으로 향상됐다는 증거라기보다, 내부 상태 관측과 작업 완료 통지, 재현 가능한 빌드가 검증 비용에 영향을 준다는 실무적 단서에 가깝다.

출처: Booley 개발자 사례 분석 「Why AI agents struggle with RTL debugging, and what helps」 (https://booley.dev/blog/harness-matters/); Booley 공식 저장소 (https://github.com/boldaxolotl/booley); 실험용 Caliptra 프로젝트 고정 버전 (https://github.com/boldaxolotl/booley-prj-caliptra/tree/an-001-trial); CHIPS Alliance VeeR EL2 1.4 릴리스 노트 (https://github.com/chipsalliance/Cores-VeeR-EL2/blob/fb3354352be70781450ea70963c44d4b8f88ae9b/release-notes.md).