아키텍처 자동화는 요구사항을 입력하면 새로운 칩을 얻는 과정으로 설명되곤 합니다. 이 표현에는 서로 다른 문제가 섞여 있습니다. 캐시 용량, 발행 폭, 큐 깊이, 가속기 배열 크기를 고르는 일은 탐색입니다. 합법적인 RTL을 만드는 일은 구현입니다. ISA와 시스템 동작을 유지하는 일은 검증입니다. 배치배선 이후에도 가치가 남는지를 확인하는 일은 근거를 만드는 과정입니다.
2025년 연구는 이 경계를 유지할 때 가장 설득력이 있습니다. QiMeng-CPU-v2는 상태 기반 자동 설계로 수퍼스칼라 RISC-V 프로세서를 만들고 실행합니다[1]. LEMOE는 BOOM 마이크로아키텍처 탐색의 다목적 베이지안 최적화에 LLM을 결합합니다[2]. ICCAD의 멀티모달 SoC 탐색은 매개변수 설명의 의미와 Chisel이 만든 RTL 그래프의 구조를 함께 사용합니다[3]. 세 연구는 서로 다른 층을 자동화하지만 공통된 역할이 있습니다. AI는 큰 설계 공간을 줄이고, 실행 가능한 설계가 결과의 중심에 남습니다.
아키텍처 선택이 만드는 연쇄 변화
초기 아키텍처 선택은 매개변수 하나를 바꾸는 것으로 보입니다. 그러나 발행 폭을 2에서 4로 늘리면 웨이크업과 선택 회로, 레지스터 파일 포트, 바이패스 경로, 큐 압력, 물리 배선이 함께 바뀝니다. 캐시를 키우면 미스율뿐 아니라 접근 지연, 뱅킹, 코히어런스 트래픽, 플로어플랜이 달라집니다. 화면에 보이는 숫자는 연쇄적인 설계 약속의 시작입니다.
기존 설계 공간 탐색은 매개변수화된 템플릿에서 후보를 평가하고 대리 모델을 만들어 다음 후보를 고릅니다. 필요한 아키텍처가 이미 템플릿 안에 있고 구성만 선택하면 될 때 효과적입니다. 토폴로지, 제어 의미, 워크로드 계약을 바꿔야 한다면 중요한 답이 탐색 공간 밖에 있을 수 있습니다. AI가 새로운 구조를 제안할수록 평가기는 더 깊어져야 합니다.
근거의 단계는 누적됩니다. PPA 예측은 약한 후보를 빠르게 걸러냅니다. RTL은 선택을 구조로 표현할 수 있음을 보여 줍니다. ISA 시험과 긴 프로그램 실행은 동작 오류를 찾습니다. FPGA나 실리콘은 타이밍, 전력, 통합 결과를 드러냅니다. 첫 단계만 통과한 후보는 탐색 결과이지 프로세서가 아닙니다.
실제 동작하는 CPU까지 연결한 QiMeng-CPU-v2
QiMeng-CPU-v2의 의미는 고립된 RTL 문제를 푼 것이 아니라는 데 있습니다. 프레임워크는 ALU 네 개를 가진 수퍼스칼라 RISC-V CPU를 구성하고, 실제 프로그램에서 1조 개가 넘는 명령어를 실행했으며 FPGA로도 검증했다고 보고합니다[1]. 상태 기반 설계 방식은 시뮬레이티드 어닐링을 사용하는 상태 선택기와 LLM을 이용해 설계를 확장하는 상태 추정기로 나뉩니다.
CPU는 시간에 따라 상태가 변하는 시스템입니다. 명령어가 큐에 들어오고, 피연산자를 기다리고, 자원을 경쟁하고, 순서대로 커밋하며, 예외 뒤에 복구합니다. 상태를 중심으로 생성을 구성하면 이런 전이를 명시적으로 다룰 수 있습니다. 프로세서를 한 번에 생성하라는 요청보다 실패 위치도 분명해집니다.
논문은 기존 자동 설계와 비교하고 결과의 역량을 Arm Cortex-A53급 참조와 나란히 설명합니다. 이를 공정과 제품 성능이 같다는 의미로 읽으면 안 됩니다. 주파수, 메모리 시스템, 컴파일러, 물리 구현, 워크로드 조건이 실제 성능을 정합니다. 더 강한 근거는 자동화된 흐름으로 실행 가능한 비순차 프로세서를 만들고 긴 동작 시험을 수행했다는 점입니다.
1조 명령어 실행도 올바른 범위에서 읽어야 합니다. 실제 프로그램과 드문 상호작용을 오래 견뎠다는 신뢰를 높이지만 모든 아키텍처 예외를 열거하거나 골든 모델과의 동등성을 증명하지는 않습니다. 인터럽트, 메모리 순서, 특권 동작, 디버그, 코히어런스, 저전력 상태는 일반 워크로드에서 거의 나타나지 않을 수 있습니다. 다음 단계는 생성된 상태 전이를 형식 ISA 속성과 커버리지 목표에 연결하는 것입니다.
정해진 CPU 계열 안의 선택을 자동화한 LEMOE
LEMOE는 더 좁지만 산업적으로 익숙한 문제를 다룹니다. 여러 목표를 만족하는 BOOM 구성을 효율적으로 찾습니다[2]. 베이지안 최적화는 비용이 큰 평가 결과로 대리 모델을 만들고 다음에 시험할 후보를 고릅니다. LLM은 매개변수 관계와 과거 관측을 해석해 가능성이 높은 영역으로 탐색을 유도할 수 있습니다.
BOOM이 일관된 비순차 RISC-V 구현을 이미 제공한다는 점이 강점입니다. 탐색 시스템은 커밋 의미나 코히어런스 프로토콜을 새로 만들 필요가 없습니다. IPC와 전력으로 평가할 수 있는 매개변수를 고릅니다. 아키텍처 자동화가 제약이 있는 최적화 서비스로 바뀝니다.
같은 이유로 한계도 분명합니다. 좋은 BOOM 구성은 새로운 프로세서 조직과 같지 않습니다. 예상하지 못한 매개변수 조합을 찾고 평가 횟수를 줄일 수 있지만 설계 계열, RTL 생성기, 측정 도구가 공간을 정합니다. 제품 차별화 요소가 새로운 데이터 흐름, 메모리 일관성 또는 가속기 결합 방식이라면 정답이 템플릿 안에 없을 수 있습니다.
도입 전에는 두 가지를 확인해야 합니다. 제품을 구분하는 선택이 템플릿 안에 있는지, 그리고 평가기가 그 선택의 가치를 만드는 워크로드와 물리 효과를 포함하는지입니다. 둘 중 하나가 빠지면 더 빠른 탐색은 잘못된 경계에서 정확히 수렴할 수 있습니다.
매개변수의 뜻과 구조를 함께 읽는 SoC 탐색
ICCAD의 멀티모달 방식은 빠져 있던 신호를 추가합니다. LLM으로 매개변수 설명의 의미를 인코딩하고, Chisel이 생성한 RTL 그래프에서 구조 정보를 추출한 뒤 두 특징을 합쳐 성능 예측과 베이지안 탐색에 사용합니다[3]. 평가는 Gemmini 기반 RISC-V SoC에서 이루어졌습니다.
텍스트와 구조는 서로 다른 질문에 답합니다. 매개변수 이름과 설명은 스크래치패드 뱅크, 큐, 배열 크기 중 무엇을 조절하는지 알려 줍니다. RTL 그래프는 그 선택이 연결과 로직을 어떻게 바꾸는지 보여 줍니다. 숫자만 사용하면 범위가 같은 서로 다른 매개변수를 비슷하게 취급할 수 있습니다. 구조만 사용하면 그 변화가 아키텍처에 왜 중요한지 놓칠 수 있습니다.
이 방식은 엔지니어가 생성기를 읽는 방법과 가깝습니다. 매개변수는 단순한 정수가 아니라 의도를 담고 있으며 구조적인 결과를 만듭니다. 목표는 자연어의 창의성이 아니라 새로운 구성에서 필요한 평가 횟수를 줄이는 것입니다. 합법적인 구현은 여전히 생성기가 만들고, 원하는 SoC 동작은 평가기가 정의합니다.
하나의 점수로 표현할 수 없는 아키텍처
IPC는 워크로드, 컴파일러, 메모리 모델, 클록 가정과 함께 봐야 합니다. 전력에는 활동량, 전압, 공정, 물리 구현이 필요합니다. 면적 예측은 배선과 버퍼 삽입 뒤에 순위가 바뀔 수 있습니다. 여러 값을 합친 보상은 탐색을 단순하게 만들지만 분모를 없애지 않고 가중치 뒤에 숨깁니다.
평가 결과는 벡터로 유지하는 편이 낫습니다. 처리량, 긴 꼬리 지연, 에너지, 면적, 메모리 트래픽, 구현 위험을 각각 보여 줘야 합니다. 제약 조건으로 사용할 수 없는 영역을 제외하고, 제품 우선순위로 가능한 후보를 정렬해야 합니다. 그러면 자동 설계가 시스템에서 쓸 수 없는 자원을 소비해 점수를 얻었는지 확인할 수 있습니다.
워크로드 구성도 중요합니다. 평균 점수는 넓은 실행 장치를 선호하지만 실제 서비스는 메모리 지연이나 동기화에 제한될 수 있습니다. 연산, 캐시 용량, 대역폭, 분기, 운영체제, 간섭 조건을 분리해 시험하고 어떤 상황에서 절충이 생겼는지 기록해야 합니다.
부족한 산업계 근거가 말해 주는 범위
2025년 공개 기록에는 학계의 CPU와 SoC 탐색, 산업계가 일부 도구에 참여한 연구가 있습니다. 그러나 산업체가 양산 마이크로아키텍처를 자동으로 바꾸고 그 결과를 사인오프나 실리콘까지 공개한 사례는 상대적으로 부족합니다. 업체 발표와 백서는 AI 보조 설계를 설명하지만 독립적인 기술 비교에 필요한 실험 조건을 제공하지 않는 경우가 많습니다.
이 빈칸을 마케팅 문구로 채우면 안 됩니다. 물리 설계는 타이밍, 혼잡, 배선 결과를 실제 레이아웃과 기존 도구에 대조할 수 있어 산업 근거가 더 분명합니다. 아키텍처 가치는 소프트웨어, 워크로드, 제품 결정 뒤에 나타나며 기업이 이를 공개하기도 어렵습니다. 공개 속도의 차이는 내부 사용이 없다는 뜻보다 근거를 만들기 어렵다는 뜻에 가깝습니다.
따라서 아키텍처 AI는 계약이 이미 존재하는 곳부터 도입하는 것이 합리적입니다. 매개변수화된 코어, 가속기 배열 크기, 캐시 계층, 인터커넥트 설정에는 측정 가능한 공간이 있습니다. 새로운 조직을 자유롭게 생성하려면 훨씬 강한 검증 체계와 시스템 계약을 책임질 사람이 필요합니다.
인과관계를 남기는 탐색 기록
탐색 이력에는 구성과 점수만 기록해서는 안 됩니다. 왜 매개변수를 바꿨는지, 어떤 워크로드가 변했는지, 어느 물리 제약이 활성화됐는지, 결과가 다른 시드와 구현에서도 유지됐는지를 남겨야 합니다. 그래야 샘플 모음이 아니라 다시 사용할 수 있는 아키텍처 지식이 됩니다.
반사실 시험도 유용합니다. 큰 재정렬 버퍼로 IPC가 올랐다면 메모리 수준 병렬성, 분기 복구, 워크로드 구간 중 무엇이 원인인지 확인해야 합니다. 메모리 지연을 고정하거나 워크로드를 바꾸는 단순한 시험만으로도 추천 이유를 검토할 수 있습니다. 다른 서브시스템이 바뀌었을 때 같은 이점이 남는지도 예측하기 쉬워집니다.
자동화는 답을 거부할 수도 있어야 합니다. 후보가 학습 범위 밖에 있거나 불확실성이 높거나 생성기가 요구한 변화를 표현하지 못하면 이를 알려야 합니다. 신뢰할 수 없는 대리 모델을 계속 최적화하는 것보다 추천을 중단하는 편이 낫습니다.
도입 판단과 역할 분담
현재의 AI 아키텍처 도구는 범위가 정해진 설계 공간을 줄이고 근거를 정리하는 데 사용할 수 있습니다. 후보를 제안하고, 매개변수 의미와 구조 특징을 읽고, 파레토 전선을 유지할 수 있습니다. QiMeng-CPU-v2는 상태와 검증을 명시하면 더 생성적인 과정도 실행 가능한 수퍼스칼라 프로세서에 도달할 수 있음을 보여 줍니다.
권한 경계는 분명해야 합니다. 엔지니어가 아키텍처 계약, 워크로드, 제약, 근거 단계를 정의합니다. 자동화는 그 안에서 후보를 찾고 관측한 절충을 설명합니다. 후보의 동작을 실행할 수 있고 구현 뒤의 시스템 결과가 유지될 때 아키텍처가 됩니다.
이 역할은 작지 않습니다. 설계팀은 전체 구현을 실행할 가치가 있는 실험을 고르는 데 많은 시간을 씁니다. 약한 영역을 일찍 제거하고, 한 구성에서 얻은 지식을 다른 구성에 적용하며, 원인이 보이는 근거를 제공하면 아키텍처 주기를 줄일 수 있습니다. 가치는 언어 모델 혼자 칩을 설계했다는 주장보다 비싼 결정을 내리기 전에 불확실성을 줄이는 데 있습니다.
출처와 저작권 안내
이 글은 인용한 세 논문과 공식 공개 기록을 바탕으로 Silicon & Systems가 독립적으로 작성한 편집 분석입니다. 기술 주장은 우리 표현으로 다시 설명했으며 원문의 문장, 표, 벤치마크 배치 또는 도판을 복제하지 않았습니다. 두 도판은 이 글을 위해 새로 만들었습니다. 인용 논문의 저작권은 각 출판사와 저자에게 있습니다.