AI가 하드웨어 코드를 “한 번에” 잘 생성하는지만 보는 시대는 지나가고 있습니다. 더 중요한 질문은 이것입니다. 틀린 설계를 발견했을 때 스스로 수정하고, 정해진 기준을 통과할 때까지 반복할 수 있는가?
NVIDIA Research의 HORIZON은 이 질문에 초점을 맞춘 hands-free 에이전트 프레임워크입니다. 핵심은 RTL 설계를 단발성 코드 생성 문제가 아니라, 저장소 수준의 코드 진화 문제로 다룬다는 점입니다.1 RTL은 레지스터 전송 수준의 하드웨어 설계 표현으로, 단순히 문법이 맞는 코드보다 의도한 동작을 정확히 구현하는지가 중요합니다.
HORIZON의 핵심: 프롬프트가 아니라 검증 가능한 작업 단위
HORIZON은 Markdown 하네스를 프로젝트 팩으로 컴파일합니다.1 이 프로젝트 팩에는 도메인 지식, 실행 가능한 평가기, 승인 조건, git·런타임 정책이 포함됩니다.1
이 구조가 중요한 이유는 명확합니다. 에이전트에게 “좋은 RTL을 만들어라”라고 지시하는 데서 끝나지 않고, 다음을 함께 제공합니다.
어떤 배경 지식이 필요한가
어떤 방식으로 설계를 평가할 것인가
어떤 조건을 만족해야 통과로 볼 것인가
변경과 실행을 어떤 정책 아래에서 관리할 것인가
즉 HORIZON의 강점은 더 멋진 프롬프트가 아니라, 에이전트가 반복적으로 시도하고 검증할 수 있는 작업 환경을 만든다는 데 있습니다.
Git worktree는 에이전트의 실험 공간이 된다
HORIZON의 에이전트 루프는 격리된 git worktree 안에서 후보 설계를 수정하고 평가합니다.1 평가 결과가 기준을 만족하면 해당 후보를 커밋하고, 만족하지 못하면 거부합니다.1
여기서 Git은 단순한 버전 관리 도구가 아닙니다. 에이전트가 어떤 변경을 했는지, 그 변경이 어떤 평가 결과를 냈는지 추적하는 실행 기록이 됩니다. 특히 git diff는 상태 변화를 드러내는 수단으로 쓰이고, commit은 통과한 설계 버전을 남기는 체크포인트가 됩니다.1
이 방식은 에이전트의 시행착오를 불투명한 대화 기록이 아니라, 재현 가능한 저장소 변화로 바꿉니다. 그래서 추적, 비교, 롤백, 검토가 쉬워집니다.
100% 완료율은 결과보다 구조를 봐야 한다
HORIZON은 벤치마크에서 100% 완료율을 기록한 것으로 보고됐습니다. 논문에서는 ChipBench, RTLLM, Verilog-Eval, CVDP 일부 범주에서 100% 완료율을 언급합니다.1
다만 이 숫자를 “하드웨어 설계 AI가 완성됐다”는 의미로 읽어서는 안 됩니다. 벤치마크는 실제 칩 설계 전체가 아니라 통제된 대리 문제입니다.1 따라서 더 중요한 해석은 완료율 자체보다, 그 결과를 가능하게 한 운영 방식입니다.
HORIZON이 보여주는 방향은 다음과 같습니다.
문제를 저장소 단위로 구성한다.
에이전트가 격리된 환경에서 후보 변경을 만든다.
실행 가능한 평가기로 결과를 검증한다.
승인 조건을 만족한 변경만 커밋한다.
diff와 commit으로 설계 진화를 추적한다.
이 흐름은 생성 모델의 첫 답변보다, 평가와 승인 조건이 붙은 반복 루프가 더 중요하다는 점을 보여줍니다.
실무자가 가져갈 교훈
HORIZON의 실질적 가치는 “AI가 RTL을 자동으로 완성한다”는 주장보다, 복잡한 기술 작업에 에이전트를 어떻게 적용해야 하는지 보여주는 데 있습니다.
AI 에이전트를 실무에 적용하려면 작업을 대화 단위가 아니라 저장소 단위로 설계해야 합니다. 그리고 실행 가능한 평가 기준, 승인 조건, 변경 이력을 함께 관리해야 합니다. 통과한 변경만 기록하고, 실패한 시도는 검증 과정에서 걸러내야 합니다.
이 원칙은 하드웨어 설계에만 머물지 않습니다. 복잡한 소프트웨어 개발, 테스트 수정, 리팩터링, 성능 개선처럼 반복 검증이 중요한 작업에도 그대로 적용할 수 있습니다. HORIZON이 던지는 메시지는 분명합니다. 에이전트의 신뢰성은 한 번의 생성 능력이 아니라, 검증 가능한 반복 구조에서 나온다는 것입니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.