“AI로 RTL을 짜도 되나요?”, “LLM이 만든 테스트벤치를 믿어도 될까요?” 요즘 주변의 설계·검증 엔지니어와 취업 준비생에게 자주 듣는 질문입니다. 특정 개인이나 프로젝트를 인용하지 않고, 익명으로 반복된 고민만 일반화해 현직자 관점에서 답합니다.
한 줄 답: AI로 RTL 초안을 만드는 것은 가능합니다. 다만 명세 → lint → simulation·coverage → formal·CDC → synthesis·STA·PPA의 다섯 검증 게이트를 사람이 승인해야 합니다.
AI가 Verilog 몇 줄을 보조하는 단계는 이미 지났습니다. Cadence는 ChipStack AI Super Agent가 RTL 생성, 테스트벤치 생성, regression orchestration, debug를 전문 에이전트로 연결한다고 설명합니다. 2026년 4월에는 초기 고객 작업에서 최대 10배의 생산성 향상을 확인했다고 발표했습니다. 이 수치는 독립 벤치마크가 아니라 공급사 발표이므로 그대로 일반화해서는 안 됩니다. 하지만 EDA 인터페이스가 GUI와 Tcl 중심에서 “목표를 주고 도구 결과를 되먹이는 에이전트”로 이동하는 방향은 분명합니다.
AI EDA가 산업의 어느 단계부터 바꿀지에 대한 큰 흐름은 AI EDA 생산성 스택: RTL보다 검증과 클로저가 먼저 바뀐다에서 다뤘습니다. 이번 글은 실제 프로젝트와 포트폴리오에서 적용할 수 있는 승인 게이트에 집중합니다.
문제는 소프트웨어의 바이브 코딩처럼 “컴파일되고 데모가 돌면 됐다”는 기준을 RTL에 적용할 때 생깁니다. RTL은 기능만 맞으면 끝나는 코드가 아닙니다. clock, reset, protocol, CDC, power intent, 합성 가능성, PPA, signoff constraint를 함께 만족해야 하는 구현 명세입니다.
게이트 1: 자연어를 실행 가능한 명세로 바꿨는가
“AXI slave를 만들어줘”는 명세가 아닙니다. 최소한 다음이 결정되어야 합니다.
- 지원 protocol과 subset
- data/address width
- outstanding transaction 수
- latency와 throughput 목표
- reset 종류와 polarity
- invalid access 처리
- backpressure 조건
- clock domain과 power domain
AI가 빈칸을 임의로 채우게 하지 마세요. 미정 항목은 질문으로 반환하게 해야 합니다. 최근 LLM RTL 연구에서도 오류의 상당 부분은 모델의 추론 능력만이 아니라, 모호한 설명과 회로 개념의 오해에서 발생했습니다.
통과 조건: 요구사항 목록, I/O 표, 상태 전이, timing example, error behavior가 문서화되고 각각 추적 ID를 가진다.
게이트 2: 문법이 아니라 RTL 품질을 검사했는가
컴파일 성공은 가장 낮은 문턱입니다. latch inference, width truncation, signedness, incomplete assignment, combinational loop, reset 누락, simulation-synthesis mismatch 가능성을 정적 검사해야 합니다.
AI 에이전트가 lint 결과를 읽고 자동 수정하더라도 경고를 무작정 suppress하지 못하게 해야 합니다. waiver에는 이유, 책임자, 적용 범위, 만료 조건이 필요합니다.
통과 조건: compile/elaboration 성공, lint severity 기준 충족, 모든 waiver에 근거가 기록된다.
게이트 3: self-checking simulation과 coverage가 있는가
AI가 RTL과 테스트벤치를 함께 만들면 같은 오해를 두 파일에 복제할 수 있습니다. reference model, assertion, testbench는 가능한 한 독립된 표현으로 만들어야 합니다.
최소 테스트 세트는 다음을 포함해야 합니다.
- reset과 reset release
- 정상 single transaction과 연속 transaction
- backpressure와 최대 지연
- 경계값과 illegal input
- protocol ordering의 가능한 조합
- long random regression
VerilogEval 계열 연구가 LLM RTL을 testbench로 평가하고, 최근 연구들이 simulation-error localization-correction loop를 넣어 성능을 높인 이유도 같습니다. one-shot 생성보다 도구 기반 피드백 루프가 중요합니다.
통과 조건: 모든 요구사항 ID에 test 또는 assertion이 연결되고 regression이 재현 가능하며, functional coverage의 미도달 항목이 설명된다.
게이트 4: 독립적인 formal·CDC·equivalence를 통과했는가
시뮬레이션은 실행한 경로만 봅니다. control logic, arbitration, protocol safety property처럼 상태 공간이 중요한 블록은 formal property가 강합니다. 여러 clock이나 asynchronous reset이 있으면 CDC/RDC 분석이 별도 게이트가 되어야 합니다.
AI가 기존 RTL을 최적화하거나 ECO를 만들었다면 equivalence가 특히 중요합니다. Cadence는 Conformal 계열 equivalence 도구를 구현 도구가 만든 결과가 논리적으로 동일한지 확인하는 독립 auditor로 설명합니다. 여기서 중요한 단어는 AI가 아니라 독립입니다. 생성기와 판정기를 같은 추론에 묶지 않아야 합니다.
통과 조건: assertion proof 또는 명시적 bound, CDC/RDC violation disposition, 변경 전후 equivalence 결과가 남는다.
게이트 5: 합성·STA·PPA·물리 조건을 만족하는가
기능적으로 맞는 RTL도 합성 후 실패할 수 있습니다. 긴 combinational path, 과도한 priority chain, 잘못된 clock gating, 큰 fanout, memory inference 실패가 대표적입니다.
AI에게 PPA 목표를 하나의 숫자로 주지 마세요. area만 줄이다 timing이나 testability를 망칠 수 있습니다. constraint, library, corner, tool version을 고정한 뒤 다음을 함께 비교해야 합니다.
- worst/total negative slack
- area와 cell count
- dynamic/leakage power estimate
- congestion과 physical feasibility
- DFT와 low-power rule 영향
통과 조건: 기준 RTL과 기능 equivalence를 유지하면서 합의된 timing·area·power·physical feasibility 범위를 만족한다.
AI에게 맡겨도 되는 일과 사람이 승인할 일
| AI에 맡기기 좋은 작업 | 사람 승인이 필요한 작업 |
|---|---|
| boilerplate RTL·testbench 초안 | architecture와 state behavior |
| lint·compile 오류 수정 후보 | warning waiver와 reset policy |
| test scenario와 assertion 후보 생성 | 검증 계획의 완전성과 oracle 독립성 |
| regression 실패 분류와 로그 요약 | root cause와 release 판단 |
| PPA 탐색 후보 제안 | constraint, signoff, tape-out 승인 |
AI 시대에 더 비싸지는 엔지니어 역량
코드 타이핑 비중은 줄어들 수 있습니다. 대신 네 가지 역량의 가치는 올라갑니다.
- 모호한 요구를 실행 가능한 계약으로 바꾸는 능력
- 도구 로그와 waveform에서 진짜 원인을 찾는 능력
- 생성기와 검증기의 독립성을 설계하는 능력
- 기능·성능·전력·물리 구현의 trade-off를 설명하는 능력
자주 묻는 질문
Q. ChatGPT나 Claude로 만든 RTL을 포트폴리오에 써도 되나요?
가능합니다. 다만 프롬프트보다 검증 증거를 보여주세요. 명세, test plan, assertion, coverage, 합성 결과, AI가 만든 오류를 발견하고 고친 기록이 있어야 합니다.
Q. AI가 testbench까지 만들면 검증이 끝난 것 아닌가요?
아닙니다. RTL과 testbench가 같은 잘못된 해석을 공유할 수 있습니다. 독립 reference model, protocol assertion, formal, 상용 VIP 등 다른 oracle이 필요합니다.
Q. 그럼 RTL 엔지니어 일자리가 줄어드나요?
반복 코딩과 로그 분류 비중은 줄 수 있습니다. 반면 spec, architecture, verification closure, physical trade-off를 책임지는 사람의 중요성은 커집니다. 역할이 사라지기보다 책임의 중심이 이동할 가능성이 큽니다.
Q. 회사 코드를 외부 AI에 넣어도 되나요?
회사 정책과 보안 승인이 없으면 넣지 마세요. RTL, constraint, log, waveform에는 제품 구조와 취약점이 포함될 수 있습니다. 승인된 enterprise 환경과 데이터 경계가 먼저입니다.
마무리
“AI가 만든 RTL을 믿을 수 있는가”는 정확한 질문이 아닙니다. 더 좋은 질문은 이것입니다.
누가 만들었든 같은 다섯 개 검증 게이트를 통과하게 만들었는가.
바이브 코딩은 초안을 빠르게 만듭니다. 실리콘을 만드는 것은 여전히 검증 가능한 증거입니다.
공개 출처
- Cadence ChipStack AI Super Agent
- Cadence–NVIDIA agentic AI 발표
- Cadence Conformal AI Studio
- OpenLLM-RTL paper
- Understanding and Mitigating Errors of LLM-Generated RTL Code
- NVIDIA VerilogEval repository
편집 원칙: 이 글은 주변에서 반복해서 들은 익명 고민을 일반화해 작성했습니다. 개별 인물·프로젝트를 특정할 수 있는 비공개 정보는 사용하지 않았으며, 공급사 성능 수치는 공급사 주장으로 구분했습니다.
