RTL, AI에 대체될까 — 숫자가 보여 주는 진짜 경계와 커리어 생존 전략

핵심 결론 단순 RTL 코딩은 빠르게 상품화되고 있다. 그러나 공개 벤치마크가 반복해서 보여 주는 것은, 기능 구현보다 PPA와 의사결정에서 AI의 성공률이 크게 떨어진다는 사실이다. VerilogEval에서는 최고 수준 모델도 spec-to-RTL pass@1이 63% 수준이었고, 현실에 가까운 CVDP에서는 34%에 그쳤다. 전체 설계 흐름을 평가한 Build-A-Chip-Bench에서는 기능 검증 통과가 약 40%, PPA 목표 달성은 약 10%였다. 대체되는 것은 RTL 엔지니어가 아니라 '결정 없이 코드만 쓰는 일'이다. 생존 전략은 코딩 속도가 아니라 스펙 결정, trade-off 판단, 검증과 물리 구현까지 책임지는 범위를 넓히는 쪽에 있다.

먼저 숫자부터 보자 — 세 개 벤치마크가 같은 이야기를 한다

AI가 RTL을 얼마나 잘 쓰는지는 감으로 논할 단계가 지났다. 공개 벤치마크가 이미 여러 세대에 걸쳐 쌓여 있고, 결과는 놀라울 정도로 일관된 패턴을 보여 준다.

첫 번째는 VerilogEval이다. 자연어로 주어진 스펙을 Verilog 코드로 바꾸는 능력을 재는 대표 벤치마크다. VerilogEval v2의 spec-to-RTL 과제에서 LLaMA 3.1 405B는 57%, GPT-4o는 pass@1 63%로 당시 최고 수준을 기록했다. 작은 모듈 단위 과제에서 최고 모델이 열 개 중 여섯 개 남짓을 한 번에 맞히는 수준이라는 뜻이다. 이후 특화 모델과 에이전트 기법이 높은 수치를 보고하고 있지만, 조건이 다른 결과를 같은 선에 놓고 비교해서는 안 된다.

두 번째는 CVDP(Comprehensive Verilog Design Problems)다. NVIDIA 연구진이 참여한 이 벤치마크는 숙련된 하드웨어 엔지니어가 출제한 783개 문제, 13개 카테고리로 구성되며 RTL 생성뿐 아니라 수정, 디버깅, 검증, 스펙 정합까지 평가한다. 여기서 최고 수준 모델의 코드 생성 aggregate pass@1은 34%(Claude 3.7 Sonnet)였고, GPT-4.1은 29%, LLaMA 3.1 405B는 23%였다. 과제가 현실 업무에 가까워질수록 성공률이 절반 가까이 떨어진다.

세 번째는 Build-A-Chip-Bench다. ChipAgents가 NVIDIA와 협력해 공개한 이 벤치마크는 RTL에서 끝나지 않고 architecture부터 verification, synthesis, floorplan, placement, CTS, routing, timing과 power signoff, physical verification까지 전체 흐름을 평가한다. 초기 평가에서 에이전트들의 기능 검증 통과율은 평균 약 40%, 물리적 PPA(Performance, Power, Area) 목표 달성률은 약 10%에 그쳤다.

세 숫자를 나란히 놓으면 경계가 보인다. AI는 '동작하는 코드'를 만드는 데서는 빠르게 사람 보조 수준을 넘어서고 있지만, '제약 안에서 최적에 가까운 결정을 내리는 일'에서는 아직 한참 멀다. 대체 논의는 이 간극을 기준으로 해야 정확해진다.

왜 기능 구현과 PPA 사이에 이렇게 큰 간극이 생기는가

기능 구현은 정답이 비교적 명확한 문제다. 스펙이 주어지면 동작은 맞거나 틀리고, testbench가 판정한다. 학습 데이터에 비슷한 패턴이 많고, 실패하면 다시 시도할 수도 있다. LLM이 강해지기 좋은 조건이다.

PPA는 성격이 다르다. 정답이 하나가 아니라 제약 조건 아래의 선택이다. 같은 기능을 구현해도 pipeline을 깊게 하면 frequency는 오르지만 전력과 면적이 늘고, 검증 부담도 커진다. 공정, 라이브러리, floorplan, 주변 블록의 상황이 모두 선택을 바꾼다. 게다가 결과는 synthesis와 backend를 돌려 보기 전까지 확정되지 않는다. 피드백 한 번이 비싸고 느리다는 뜻이다.

실무의 RTL도 마찬가지다. 코드 한 줄의 가치는 그 줄 자체가 아니라, 그 선택이 timing closure와 power budget와 일정에 미치는 영향으로 정해진다. AI가 코드를 더 많이, 더 빨리 쓰는 시대일수록 이 영향 판단의 가치는 오히려 올라간다. 생성된 코드가 많아질수록 검토하고, 버리고, 방향을 정하는 일이 병목이 되기 때문이다.

대체되는 일과 대체되지 않는 일을 나눠 보자

막연한 불안 대신 업무를 단위별로 나눠 보면 그림이 선명해진다.

빠르게 상품화되는 일은 패턴이 정해진 코드다. 표준 bus interface의 slave 모듈, register block, 단순 FSM, 기존 코드의 반복 변형, 주석과 문서 초안, testbench 골격. 이런 작업은 공개 코드와 오픈소스 IP가 풍부하고 스펙도 표준으로 고정되어 있어 AI가 학습하기 가장 좋은 영역이다. 여기서 사람과 속도 경쟁을 하는 전략은 이미 졌다고 봐야 한다.

오래 남는 일은 결정이 들어가는 작업이다. Microarchitecture를 정하는 일, 스펙의 모호한 부분을 제품 요구사항으로 해석하는 일, PPA trade-off에서 무엇을 버릴지 고르는 일, 일정과 리스크를 보고 설계 범위를 조정하는 일, tape-out 직전 ECO에서 고칠 것과 감수할 것을 나누는 일. 이런 결정은 코드가 아니라 맥락에서 나오고, 틀렸을 때의 책임도 사람이 진다.

중간 지대도 있다. 디버깅과 코드 리뷰다. AI는 파형 분석 보조와 코드 패턴 지적에서 이미 유용하지만, 버그의 root cause가 스펙 해석인지 RTL인지 testbench인지 가르는 최종 판단은 여전히 설계자의 몫이다. 이 중간 지대는 AI를 잘 쓰는 사람이 훨씬 강해지는 영역이기도 하다.

'RTL은 공짜가 된다'와는 다른 이야기 — 이번에는 개인의 생존법이다

표준 IP의 순수 코딩 가치가 떨어진다는 진단은 산업 구조의 이야기다. 이 글의 주제는 개인이다. 같은 진단 앞에서도 개인의 선택에 따라 결과는 완전히 달라진다. 표준 모듈 코딩만 맡던 사람은 수요 감소를 직접 맞지만, 그 모듈을 둘러싼 결정을 맡던 사람은 오히려 일이 늘어난다. AI가 초안을 쏟아낼수록 결정하고 검증할 사람이 더 필요해지기 때문이다.

그래서 생존 전략의 핵심은 'AI보다 코딩을 잘하기'가 아니다. 그 경쟁은 이길 수 없고, 이겨도 상이 작다. 핵심은 AI가 만든 결과를 평가할 수 있는 기준을 갖는 것과, AI가 대신할 수 없는 결정을 본인의 업무 범위에 포함시키는 것이다. 둘 다 하루아침에 생기지 않지만, 방향을 정하면 경력의 복리가 붙는 쪽이다.

커리어 생존 전략 네 가지

1. 스펙을 받는 사람에서 스펙을 정하는 사람으로 이동하라

스펙이 완성된 뒤에 호출되는 엔지니어는 AI와 가장 직접 경쟁한다. 반대로 스펙이 만들어지는 회의에 들어가는 엔지니어는 경쟁 위치가 다르다. 상위 시스템 요구를 microarchitecture로 바꾸는 단계, interface를 정의하는 단계, 성능 목표를 블록별로 배분하는 단계에 참여하는 것이 목표다. 신입이라면 스펙 리뷰에서 질문을 남기는 것부터 시작하면 된다. 질문의 질이 곧 참여의 자격이 된다.

2. 검증과 물리 구현 중 최소 하나를 내 땅으로 만들어라

RTL만 아는 사람의 대체 위험이 가장 높고, RTL과 DV를 함께 보는 사람, RTL과 STA와 backend 제약을 함께 보는 사람은 위험이 크게 낮아진다. 이유는 단순하다. AI의 약점이 정확히 그 경계 지점에 있기 때문이다. 기능은 맞지만 timing이 깨지는 코드, 검증 불가능한 구조로 짠 코드를 걸러내는 능력은 당분간 사람의 핵심 상품이다. 기존 커리어 조언에서 RTL이 DV와 PD와 DFT를 이해하는 기초 문해력이라고 말하는 이유도 같다. 문해력 위에 경계 지점의 판단력을 얹는 것이 순서다.

3. AI를 쓰는 속도가 아니라 AI 결과를 버리는 기준을 키워라

실무에서 AI를 잘 쓰는 사람은 프롬프트를 길게 쓰는 사람이 아니라, 나온 코드의 어디가 틀렸을지를 빨리 찾는 사람이다. 특히 clock domain, reset 전략, handshake의 corner case, 합성 불가능한 패턴처럼 AI가 자주 틀리는 지점을 본인만의 체크리스트로 갖고 있는 사람이 강하다. 이 기준은 결국 본인의 설계 경험에서만 나온다. AI 시대에도 경험을 쌓아야 하는 이유는 여기에 있다. 경험이 없으면 AI의 출력을 평가할 수 없고, 평가할 수 없으면 AI를 쓴 것이 아니라 AI에 맡긴 것이 된다.

4. 차별화 IP와 도메인 지식으로 이동하라

표준 IP 영역은 오픈소스와 AI가 가격을 계속 누른다. 반대로 회사의 제품 경쟁력과 직결되는 차별화 블록, 예를 들어 특정 workload에 최적화된 accelerator나 저전력 설계가 핵심인 블록은 스펙 자체가 회사 안에만 있고 학습 데이터에도 없다. AI의 성공률이 가장 떨어지는 영역이다. 커리어 후반으로 갈수록 이런 블록과 도메인, 예컨대 메모리 시스템이나 인터커넥트나 보안 같은 전문 영역의 비중을 높이는 것이 방어막이 된다.

신입과 주니어에게 이 변화가 의미하는 것

신입에게 불리한 변화부터 직시해야 한다. 과거에 주니어가 맡으며 배우던 단순 구현 업무가 AI로 먼저 흡수되고 있다. 그래서 입사 후 자연스럽게 성장하던 사다리의 아래 칸이 얇아지고 있다. 대응은 명확하다. 입사 전부터 단순 구현 이상의 결과물을 준비하고, 입사 후에는 단순 구현 업무를 빨리 통과해서 리뷰와 결정이 있는 자리로 이동하는 것이다.

그렇다고 기초 코딩을 건너뛰라는 뜻은 아니다. 순서가 반대다. RTL을 직접 써 본 경험이 없으면 AI 출력을 평가할 기준도 생기지 않는다. 기초를 건너뛴 사람은 AI를 도구로 쓰는 것이 아니라 AI에 의존하는 사람이 되고, 의존은 경력이 쌓여도 실력으로 전환되지 않는다. 답은 기초를 더 빨리, 더 의도적으로 통과하는 것이지 생략하는 것이 아니다.

FAQ

Q1. 벤치마크 성공률이 오르면 결국 설계자도 대체되는 것 아닌가요? 성공률 상승 자체는 사실로 받아들여야 한다. 다만 벤치마크가 보여 주는 구조적 패턴, 즉 기능 구현보다 현실 과제와 PPA에서 성공률이 크게 떨어지는 패턴이 언제 사라질지가 핵심 변수다. 커리어 전략은 '영원히 안전하다'는 가정이 아니라 이 간극이 유지되는 동안 결정과 판단 쪽으로 이동하는 데 베팅하는 것이다. 그 이동은 간극이 좁혀진 뒤에도 여전히 가치가 있다.

Q2. 지금 RTL 공부를 시작하는 것은 늦었나요? 늦지 않았다. 단, 공부 목표를 '코드를 빨리 쓰는 사람'이 아니라 '구조를 정하고 결과를 평가하는 사람'으로 잡아야 한다. RTL 문법과 함께 컴퓨터 구조, 검증 기초, 타이밍 개념을 세트로 배우는 커리큘럼이 AI 시대에 맞는 형태다.

Q3. 회사에서 AI 툴 사용이 제한적인데 불리한 것 아닌가요? 단기적으로는 개인 생산성 도구의 차이보다 본인의 판단력 축적이 더 중요하다. 공개 벤치마크와 오픈소스 프로젝트만으로도 AI 출력의 약점을 익히는 연습은 가능하다. 툴 접근성보다 평가 기준을 먼저 갖춘 사람이 툴이 풀리는 순간 가장 빨리 격차를 벌린다.

Q4. DV나 PD로 피하는 것이 안전하지 않나요? 직무 이동 자체가 답은 아니다. DV와 PD에도 AI 자동화가 빠르게 들어오고 있다. 안전한 것은 직무 이름이 아니라, 어떤 직무에서든 결정과 책임의 범위를 넓히는 방향이다. RTL을 기초로 DV나 STA를 겹치는 방식은 이동이 아니라 확장이라서 방어력이 생긴다.

Q5. AI가 짠 코드를 리뷰하는 능력은 어떻게 키우나요? 본인이 직접 짠 코드와 AI가 짠 코드를 같은 testbench로 검증하고 차이를 기록하는 연습이 가장 직접적이다. 특히 CDC, reset, backpressure, overflow 같은 corner case에서 AI가 어떤 패턴으로 틀리는지 모아 두면, 그 목록 자체가 실무에서 바로 쓰는 자산이 된다.

행동 체크리스트

• ☐ VerilogEval, CVDP, Build-A-Chip-Bench의 평가 방식과 결과 차이를 설명할 수 있다
• ☐ 내 업무를 '패턴 코드'와 '결정이 들어가는 일'로 나눠 목록화했다
• ☐ 스펙 리뷰나 architecture 논의에 참여할 기회를 한 가지라도 만들었다
• ☐ DV, STA, DFT 중 하나를 RTL과 겹쳐 배우는 계획을 세웠다
• ☐ AI가 자주 틀리는 패턴을 모은 나만의 리뷰 체크리스트를 시작했다
• ☐ 표준 IP가 아닌 차별화 도메인 하나를 정해 학습 주제로 잡았다
• ☐ 기초 RTL 구현 연습을 생략하지 않고 일정에 포함했다

함께 읽으면 좋은 글

• 학사 회로설계 취업, RTL 코딩만 잘하면 될까 — 아키텍처 이해가 합격을 가른다

📩 VLSI Korea 뉴스레터 구독하기

매일 발행되는 반도체 심층 분석을 이메일로 가장 먼저 받아보세요. 구독은 무료입니다.

무료로 구독하기