검증 엔지니어에서 설계로 넘어가는 법

30초 요약

• DV(Design Verification)는 프론트엔드에서 채용이 가장 많은 직무다. 진입은 쉽지만, RTL 설계로 넘어가려면 의도적인 전환이 필요하다.
• 그대로 옮겨가는 것: testbench thinking, coverage methodology, AMBA/AXI 같은 protocol knowledge, debugging discipline.
• 새로 배워야 하는 것: microarchitecture design, timing-closure mindset, PPA tradeoff 감각, synthesis-friendly coding.
• 가장 설득력 있는 포트폴리오는 "내가 설계하고 내가 검증한" 작은 RISC-V peripheral 하나다. UVM testbench는 당신의 DV 경력이 증명한다.
• 인터뷰에서는 DV 경력을 우회가 아니라 설계의 자산으로 프레임하라. "남의 RTL 버그를 N년 찾아봤으니 버그 없는 RTL을 쓴다"는 말이 통한다.

인트로: 왜 DV에서 설계로 가는가

반도체 프론트엔드 채용 공고를 보면 한 가지 패턴이 반복된다. DV 인력이 제일 많이 뽑힌다. 이유도 명확하다. Wilson Research Group 조사에 따르면 logic verification effort는 큰 프로젝트에서 전체 프로젝트 시간의 최대 70%까지 차지한다. 칩이 커질수록 검증에 사람이 더 필요하고, 그래서 DV는 신입과 주니어에게 가장 넓게 열린 문이다.

그런데 그 문으로 들어간 사람들 중 적지 않은 수가 2~3년 뒤 같은 질문을 한다. "이제 설계를 해보고 싶은데, DV 경력이 도움이 될까, 아니면 처음부터 다시 시작해야 할까?"

답은 둘 다다. DV 경력의 절반은 설계로 그대로 옮겨가고, 나머지 절반은 의도적으로 새로 배워야 한다. 이 글은 그 경계선을 정확히 긋고, 6개월 안에 실행 가능한 플랜으로 바꿔준다.

시장 데이터부터 짚자. 인도 기준으로 RTL design engineer는 신입 연봉 6~8 LPA에서 시작해 5년 이상 경력이 되면 18~30 LPA 구간으로 간다. DV engineer의 pay는 RTL과 거의 같은 궤적을 그리며, 시니어 레벨에서는 오히려 앞서기도 한다. 검증 전문성이 칩 복잡도가 커질수록 가장 타이트한 병목 중 하나가 됐기 때문이다. 미국 쪽 2026년 3분기 실제 채용 공고를 보면, 대형 AI 칩 회사의 mid-level RTL design posting이 base 138k~197k USD에 15% 보너스를 제시했고, senior급은 163k~237k USD까지 열려 있다. 설계로 넘어가는 것이 보상 측면에서도 말이 되는 선택지라는 뜻이다. 단, 그 문은 실력으로 열린다.

한 가지 더. 검증이 프로젝트 노력의 50~70%를 먹는다는 것은 곧 헤드카운트도 그 비율로 돌아간다는 뜻이다. 프론트엔드 팀에서 DV가 가장 많은 인원을 차지하는 구조적 이유다. 그래서 DV는 진입 장벽이 낮은 대신, 내부에서 설계로 넘어가려는 경쟁도 치열하다. "언젠가 설계하고 싶다"는 막연한 희망이 아니라 6개월짜리 실행 계획이 필요한 이유다.

1. DV에서 설계로 그대로 옮겨가는 것들

1.1 Testbench thinking: 스펙을 읽는 눈

DV 엔지니어는 스펙을 "어떻게 깨뜨릴까"라는 관점으로 읽는다. 이건 설계자에게 가장 귀한 습관이다. RTL을 처음 쓸 때부터 corner case를 머릿속에 그리며 쓰는 사람과, 나중에 테스트벤치가 잡아주겠지 하고 쓰는 사람은 6개월 뒤 코드 품질이 완전히 다르다. DV 출신이 RTL을 잘 쓰는 이유 1순위가 이것이다.

1.2 Coverage methodology: "완료"의 정의

설계 초보가 가장 어려워하는 것 중 하나가 "이 정도면 됐나?"라는 판단이다. DV 엔지니어는 functional coverage와 code coverage로 "done"을 정의하는 훈련을 이미 받았다. 이 감각은 RTL 설계에서 microarchitecture를 블록으로 쪼개고, 각 블록의 완성 기준을 세우는 데 그대로 쓰인다.

1.3 Protocol knowledge: AMBA/AXI를 아는 손

SoC 설계의 절반은 인터페이스다. AXI4, AXI-Lite, APB의 handshake, ordering rule, outstanding transaction을 검증하면서 몸으로 익힌 사람은 peripheral을 설계할 때 인터페이스에서 헤매지 않는다. 채용 공고에서 RTL design role이 요구하는 스킬 리스트를 보면 bus protocol은 빠지지 않는다. DV에서 이미 갖춘 무기다.

1.4 Debugging discipline: 파형을 읽는 수사력

수백만 사이클 파형에서 버그를 찾아낸 경험은 RTL 설계 디버깅에 그대로 전이된다. 차이는 하나다. DV에서는 남의 버그를 찾았고, 설계에서는 내 버그를 찾는다는 것. 심리적 타격은 있지만 기술은 같다.

1.5 Scripting and automation: 리그레션 돌리던 손

DV 엔지니어는 리그레션을 돌리기 위해 Python, Tcl, Perl, Makefile을 매일 쓴다. 이 자동화 능력은 설계에서도 그대로 먹힌다. RTL lint + synthesis + 기본 시뮬레이션을 한 번에 돌리는 스크립트를 짜본 사람은 설계 생산성이 다르다. 채용 공고에서 Python/Tcl을 요구하는 이유가 여기에 있다. DV에서 이미 갖춘 무기다.

2. DV 경력으로 커버되지 않는 것들

솔직해지자. 아래 네 가지는 DV만 오래 했다고 생기지 않는다. 이게 전환의 진짜 커리큘럼이다.

2.1 Microarchitecture design: 구조를 짜는 사고

DV는 주어진 구조를 "검증"한다. 설계는 구조 자체를 "선택"한다. 같은 FIFO라도 depth를 얼마로 잡을지, cut-through으로 할지 store-and-forward로 할지, backpressure를 어디서 처리할지는 microarchitecture 결정이다. 이 결정들은 throughput, latency, area를 동시에 건드린다. DV에서는 이 결정을 평가했지만, 직접 내린 적은 없다. Pipeline 설계, arbiter 설계, FSM encoding 선택을 손으로 해보지 않으면 이 근육은 안 생긴다.

예를 들어보자. AXI slave 앞에 skid buffer를 둘지, full FIFO를 둘지 정하는 일이다. Skid buffer는 1~2 entry로 area가 작지만 backpressure 처리가 까다롭고, FIFO는 깊게 가져갈 수 있지만 area를 먹는다. Slave의 응답 latency가 10 사이클이고 master가 burst 16을 쏜다고 할 때, 어느 쪽이 deadlock 없이 버티는가? 이런 질문에 "FIFO 32 deep이면 됩니다"가 아니라 "outstanding 4, burst 16, slave latency 10 사이클이니 버퍼는 최소 64 entry, 그래서 area trade-off로 skid + credit 방식을 썼습니다"라고 답하는 것이 설계자의 언어다. 이 언어는 결정의 근거를 숫자로 말하는 훈련에서만 나온다.

2.2 Timing-closure mindset: 클럭을 만나는 RTL

Testbench에서는 1 GHz로 돌든 10 MHz로 돌든 기능만 맞으면 된다. 실제 칩에서는 당신의 RTL이 synthesis를 거쳐 gate가 되고, 그 gate들이 정해진 클럭 안에 setup/hold를 만족해야 한다. DV 출신이 처음 RTL을 쓸 때 가장 많이 하는 실수가 combinational logic을 깊게 쌓는 것이다. "기능은 맞는데 timing이 안 나온다"는 말을 설계 리뷰에서 듣는 순간이 전환의 첫 번째 관문이다. Critical path를 의식하고 pipeline stage를 나누는 습관은 의도적으로 훈련해야 생긴다.

구체적으로 감을 잡아보자. 5nm에서 1 GHz로 도는 블록을 설계한다고 치자. 클럭 주기는 1 ns다. 여기서 32-bit ripple-carry adder를 그냥 쓰면 carry chain이 32단 게이트를 타고 내려가면서 1 ns를 훌쩍 넘긴다. DV에서는 "덧셈 결과가 맞네"로 끝나는 코드가, 설계에서는 timing violation 리포트로 돌아온다. Carry-lookahead로 바꾸는지, pipeline stage를 하나 더 넣고 latency 1 사이클을 감수하는지가 설계자의 판단이다. 이런 판단을 수십 번 해보지 않으면 timing 감각은 안 생긴다. PrimeTime 같은 STA 툴 리포트를 읽을 줄 아는 것과, RTL을 쓸 때부터 timing을 의식하는 것은 완전히 다른 근육이다.

2.3 PPA tradeoff 감각: 코드 한 줄의 가격

Power, Performance, Area. 설계의 모든 결정은 이 세 축 위에서 값을 치른다. DV에서는 PPA가 남의 일이었다. 설계에서는 당신이 쓴 always 블록 하나가 area 리포트에 숫자로 찍힌다. 32-bit multiplier를 그냥 쓰는지, Booth encoding을 고민하는지, clock gating을 어디에 거는지가 실력의 차이로 드러난다.

2.4 Synthesis-friendly coding: 시뮬레이션과 합성의 간극

시뮬레이션에서 돌아가는 코드가 synthesis에서 의도대로 gate가 되지 않는 경우가 있다. Latch inference, incomplete case statement, simulation-synthesis mismatch는 DV만 하던 사람이 가장 무방비한 영역이다. Lint와 CDC check를 RTL 작성 직후 돌리는 습관부터 들여라. 실제 채용 공고의 required skills에 linting, CDC, RDC, LEC가 빠지지 않고 등장하는 이유다.

2.5 Spec writing: 읽는 것과 쓰는 것은 다르다

DV 엔지니어는 스펙을 읽는 데는 능숙하지만, microarchitecture spec을 써본 적은 거의 없다. 설계자는 블록을 만들기 전에 "무엇을, 어떻게 만들 것인가"를 문서로 정의한다. Register map, interface timing diagram, error handling 정책을 글로 쓰는 능력은 설계 리뷰의 출발점이다. Month 4 프로젝트에서 spec을 5페이지로 써보는 이유가 이것이다. 글로 못 쓰는 설계는 코드로도 못 쓴다.

3. 6개월 플랜: 달별 실행표

전제는 주 8~10시간의 사이드 스터디다. 현직 DV 엔지니어 기준이다.

Month 0 — 현재 위치 진단 (1주). 플랜에 들어가기 전에 솔직하게 체크하라. (1) Verilog로 200줄짜리 FSM을 lint-clean하게 쓸 수 있는가? (2) Yosys나 Design Compiler로 synthesis를 돌려본 적이 있는가? (3) Setup/hold violation 리포트를 읽고 원인을 짚을 수 있는가? 세 개 다 Yes면 Month 3부터 시작해도 된다. 하나라도 No면 Month 1부터 차례대로 가라. 괜히 건너뛰면 Month 5에서 막힌다.

Month 1 — RTL Coding Basics. Verilog를 "읽는 언어"가 아니라 "쓰는 언어"로 다시 배운다. Blocking vs non-blocking의 함정, FSM 3가지 스타일(Mealy/Moore, 1-process/2-process/3-process), parameterize된 모듈 작성을 손에 익힌다. 매일 30분씩 작은 모듈을 쓰고 lint를 돌리는 루틴을 만들어라. 목표: lint-clean한 500줄짜리 모듈을 스스로 쓰기.

Month 2 — Synthesis and PPA. Month 1에 쓴 RTL을 synthesis 돌려본다. 공개 툴(OpenLane, Yosys)로도 충분하다. Area 리포트와 timing 리포트를 읽는 법을 익히고, 같은 기능을 세 가지 방식으로 써서 PPA 차이를 비교한다. 예를 들어 같은 counter를 binary, one-hot, Gray code로 짜서 area와 max frequency를 비교해보는 식이다. 목표: "내 코드가 gate 몇 개인지" 말할 수 있기.

Month 3 — Microarchitecture. FIFO, arbiter(round-robin/fixed priority), crossbar, pipeline stage를 직접 설계한다. 각 블록의 throughput/latency/area를 계산하고 트레이드오프를 문서화한다. 특히 FIFO는 almost-full/almost-empty threshold를 어떻게 잡았는지 근거를 남겨라. 목표: 면접에서 "FIFO depth는 어떻게 정했나"에 숫자로 답하기.

Month 4 — Mini Project: UART. APB 인터페이스의 UART controller를 spec부터 쓴다. 작은 프로젝트지만 register map, interrupt, baud rate generator, TX/RX FIFO까지 포함한 "진짜" peripheral로 만든다. Spec 문서는 영어로 5페이지 이내로 쓰는 연습을 겸하라. 실제 현업의 microarchitecture spec이 그 정도 분량이다. 목표: GitHub에 spec + RTL + 문서가 있는 레포 하나.

Month 5 — RISC-V Peripheral. Month 4의 UART를 RISC-V 코어에 붙이고, 자신의 UVM testbench로 직접 검증한다. 이게 이 플랜의 핵심이다. DV 경력이 포트폴리오에서 증명되는 순간이다. Coverage 95% 이상, 발견한 자가 버그 리스트를 문서화한다. 여기서 찾은 버그 중 하나는 반드시 timing이나 synthesis 관련 이슈로 만들어라. 그래야 "설계자적 디버깅"을 했다는 증거가 된다.

Month 6 — Interview Prep. 설계 중심 면접 질문 100개를 뽑아 답을 쓴다. Microarchitecture decision 근거, PPA tradeoff 사례, timing closure 경험을 STAR 형식으로 정리한다. 지인 설계 엔지니어에게 모의 면접을 한 번은 받아라. DV 동료가 아니라 설계자에게 받아야 진짜 질문이 나온다. 목표: "DV 하던 사람이 왜 설계를?"라는 질문에 90초 스토리로 답하기.

4. 포트폴리오 프로젝트: 설계하고, 검증하고, 증명하라

채용 담당자가 DV 출신 지원자의 포트폴리오에서 보는 것은 하나다. "이 사람이 RTL을 쓸 수 있는가." 그리고 DV 출신에게는 두 번째 질문이 따라온다. "검증은 제대로 할 줄 아는가." 하나의 프로젝트로 두 질문에 답하는 구조가 최선이다.

권장 프로젝트: APB UART Peripheral + Self-built UVM Testbench

구성이 단순해 보이지만 평가 포인트가 정확히 들어맞는다.

• Design side: register map 설계, TX/RX FSM, baud rate generator, interrupt logic, APB slave interface. 면접관은 microarchitecture decision의 근거를 물어볼 것이다. 왜 FIFO depth를 16으로 했는지 숫자로 답할 준비를 하라.
• Verification side: 당신이 이미 잘하는 영역. UVM driver/monitor/scoreboard, functional coverage, assertion. Coverage 리포트를 첨부하라. 남의 RTL이 아니라 자기 RTL에서 찾은 버그 3개를 문서화하면 이 레포는 평범한 튜토리얼 결과물과 차원이 달라진다.
• PPA side: synthesis 돌린 area/timing 리포트 첨부. "내 설계의 가격"을 아는 지원자는 드물다.

레포 구조는 이렇게 가져가라: docs/ (spec, microarchitecture 결정 기록), rtl/, tb/ (UVM), synth/ (리포트). README 첫 줄에 이 프로젝트가 증명하는 것 3줄을 적어라. 채용 담당자는 30초 안에 판단한다.

전환 실패 패턴 3가지

이 플랜을 따라가다 망하는 경우도 정해져 있다. 미리 알아두라.

실패 1. Tutorial hell. 강의만 보고 코드를 안 쓰는 경우. DV 엔지니어는 학습 능력이 좋아서 강의를 빨리 소화하는데, 손으로 안 써보면 Month 6에 가서도 "아는 것"과 "할 수 있는 것"이 분리된다. 매주 커밋이 없으면 실패다.

실패 2. Synthesis를 안 돌리는 경우. 시뮬레이션에서만 돌려보고 "됐다"고 생각하는 경우. 설계와 DV의 차이는 바로 여기 있다. Synthesis를 안 돌린 RTL 포트폴리오는 면접관에게 "아직 DV 마인드"라고 읽힌다. Month 2를 건너뛰지 마라.

실패 3. 너무 일찍 지원하는 경우. Month 3 끝나고 조급해서 지원하는 경우. 설계 면접은 microarchitecture 질문에서 갈린다. 포트폴리오 없이 "열심히 공부 중입니다"로는 안 통한다. 최소 Month 5의 레포가 있어야 지원 자격이 된다.

면접관이 레포에서 확인하는 체크리스트:

1. Spec이 있는가? (README가 아니라 별도 문서로)
2. Microarchitecture 결정의 근거가 숫자로 적혀 있는가?
3. Testbench가 UVM인가, 대충 짠 directed test인가?
4. Coverage 숫자가 있는가?
5. Synthesis 리포트가 있는가?
6. Git 커밋 히스토리가 "한 번에 올림"이 아니라 점진적인가?

6번이 은근히 중요하다. 하룻밤에 완성된 레포와 5주에 걸쳐 커밋된 레포는 티가 난다. Month 4~5 동안 꾸준히 커밋하라.

5. 인터뷰 프레이밍: DV는 우회가 아니라 자산이다

면접관의 머릿속 질문은 정해져 있다. "DV 하던 사람이 설계를 할 수 있나?" 이 질문에 방어적으로 답하면 진다. 공격적으로 프레임하라.

솔직한 체크: 전환하지 말아야 할 경우

프레이밍 이야기로 넘어가기 전에 한 가지 짚자. 모두가 설계로 넘어가야 하는 것은 아니다. Methodology 자체가 재미있고, coverage closure의 추적 쾌감, UVM 아키텍처를 설계하는 일이 즐거운 사람이라면 DV에 남는 것이 맞다. 시니어 DV의 수급은 타이트하고 보상도 좋다. "설계가 더 멋있어 보여서" 넘어가는 것은 최악의 동기다. 진짜 동기는 하나다. "내가 구조를 직접 짜보고 싶다." 이 문장에 가슴이 뛰지 않으면, DV 리더나 architect 트랙이 더 행복한 길이다.

핵심 메시지: "저는 N년 동안 남의 RTL 버그를 찾아냈습니다. 그래서 버그가 안 나오는 RTL을 쓰는 법을 압니다."

이 한 문장이 통하는 이유는 구체적이기 때문이다. 이어서 증거를 붙여라.

• "제가 검증하면서 본 최악의 RTL 패턴 3가지가 있습니다. 첫째는..., 그래서 제 코드에서는..."
• "Coverage closure를 해봐서, 설계할 때부터 verification-friendly한 구조를 짭니다. 예를 들어..."
• "AXI ordering bug를 잡아본 경험이 있어서, 제가 master를 설계할 때는 outstanding transaction 관리를 이렇게 합니다."

절대 하지 말 것:

• DV를 깎아내리지 마라. "검증은 재미없어서요"는 최악의 답이다. 검증의 가치를 아는 설계자가 되겠다는 태도가 정답이다.
• "RTL도 쓸 줄 압니다" 수준의 주장만 하지 마라. 포트폴리오 레포 링크로 증명하라.
• Timing, PPA 질문을 회피하지 마라. 모르면 "아직 공부 중이며, 이렇게 접근하고 있습니다"라고 솔직히 말하라. 설계 면접관은 허세를 가장 빨리 간파한다.

자주 나오는 설계 면접 질문 (DV 출신이 특히 준비할 것):

1. Blocking vs non-blocking, 언제 무엇을 쓰는가 — 그리고 synthesis 결과 차이는?
2. FIFO depth 계산: write 100 MHz, read 50 MHz, burst 64일 때 minimum depth는?
3. CDC: 2-flop synchronizer의 MTBF 개념과 한계, 언제 handshake가 필요한가?
4. AXI4에서 out-of-order completion이 가능한 조건은?
5. 당신이 설계한 블록의 critical path는 어디였고 어떻게 고쳤는가?

2번은 DV 출신이 의외로 틀리는 문제다. 계산 자체는 간단하다. Write가 read보다 2배 빠르니 burst 64가 들어오는 동안 read는 32개만 빼낸다. 그래서 minimum depth는 64 - 32 = 32. 하지만 면접관이 듣고 싶은 것은 숫자 다음이다. "그래서 저는 margin을 두고 48이나 64로 잡았고, almost-full threshold는 이렇게 뒀습니다"가 나와야 설계자의 답이다.

3번도 마찬가지다. 2-flop synchronizer가 "대충 된다"는 것은 DV도 안다. 설계자는 MTBF가 clock frequency와 flop의 resolution time에 지수적으로 의존한다는 것, 그래서 고속 도메인에서는 handshake나 FIFO synchronizer로 넘어가야 한다는 것을 말한다. "언제 2-flop으로 충분하고 언제 아닌지"의 경계가 실력이다.

5번이 진짜 질문이다. 포트폴리오 프로젝트에서 timing 문제를 겪어보지 않았다면, 이 질문에 답할 수 없다. 그래서 Month 2의 synthesis 실습이 필수다.

연봉 협상 팁: DV 연차를 설계 연차로 1:1 인정받기는 어렵다. 현실적으로는 "관련 경력"으로 50~70% 정도 쳐주는 경우가 많다. 협상의 지렛대는 포트폴리오다. "3년 DV + 검증된 RTL 포트폴리오"는 "0년 설계 신입"과 다른 가격표를 받는다. 첫 설계 포지션에서 연봉이 DV 때보다 소폭 낮아지더라도, 2년 뒤 설계 시니어 트랙의 상승폭을 보고 판단하라. 위의 시장 데이터가 보여주듯 시니어 설계의 ceiling은 확실하다.

edu.vlsi.kr 연계 로드맵

이 글의 각 단계는 edu.vlsi.kr의 로드맵과 그대로 연결된다. 순서대로 밟으면 된다.

• RTL 설계 로드맵 — Month 1~3의 커리큘럼. Verilog 기초부터 microarchitecture까지 단계별 학습 경로.
• 검증 로드맵 — 당신이 이미 가진 무기. UVM, coverage, formal까지. 설계로 넘어가기 전 현재 위치를 점검하는 용도로.
• RTL2GDS 전체 흐름 로드맵 — RTL이 칩이 되기까지의 전체 그림. "전반적으로 다 해봐야 한다"는 철학의 지도.
• RTL 설계 연봉 데이터 — role별 보상 데이터. 전환의 경제적 근거를 숫자로 확인.

Chase's Take

솔직히 말하면, 나는 DV 출신이 아니다. SiFive Korea에서 RTL-to-GDS를 풀오너십으로 했고, Samsung 5~14nm에서 5번 이상 테이프아웃을 했다. 지금은 Synopsys에서 PrimeTime, PrimeShield, PrimePower 같은 STA/signoff 툴을 만드는 Staff Product Engineer다. 백엔드 툴을 만드는 사람이지만, 후배들에게는 항상 앞단계부터 배우라고 말한다. RTL 먼저, 그 다음 verification, 그 다음 synthesis/PD, 그 다음 STA/signoff. "전반적으로 다 해봐야 한다."

그래서 DV-first로 입문한 사람들을 보면 두 가지 부류가 보인다. 하나는 검증에만 머무르는 사람. 다른 하나는 검증을 발판으로 앞단계로 돌아가 RTL을 제대로 배우는 사람이다. 후자가 5년 뒤 훨씬 강한 엔지니어가 된다. 이유는 단순하다. 버그를 수백 개 잡아본 사람이 쓰는 RTL은 처음부터 다르다. 검증에서 본 나쁜 설계 패턴들이 몸에 배어 있어서, 자기도 모르게 피해간다.

단, 착각하지 마라. DV 경력이 자동으로 설계 실력이 되지는 않는다. 내가 STA 툴을 만든다고 STA를 잘하는 게 아니듯, 검증 오래 했다고 RTL을 잘 쓰는 게 아니다. Microarchitecture를 직접 짜보고, synthesis 돌려서 area 리포트에 데이고, timing violation을 밤새 잡아봐야 설계자가 된다. 이 글의 6개월 플랜이 바로 그 과정을 압축한 것이다.

마지막으로 한 마디. DV를 "설계 가기 전의 임시직" 취급하지 마라. 검증은 칩 프로젝트 시간의 절반 이상을 먹는 진짜 엔지니어링이다. 그 시간을 보낸 당신은 이미 설계자의 절반을 갖고 있다. 나머지 절반을 6개월 안에 채워라.

FAQ

Q1. DV 경력 3년인데, 설계 신입으로 지원해야 하나요?

A. "설계 신입"으로 지원하는 것은 손해다. DV 경력을 설계 지원 포지션으로 가져가라. 3년의 DV는 0년의 설계 경력보다 낫다. 포트폴리오로 RTL 역량을 증명하고, DV 경험은 검증 친화적 설계 능력으로 포장하라. 연봉 협상에서도 DV 연차를 완전히 버리지 마라.

Q2. UVM을 더 파는 게 낫지 않나요? DV 시니어가 연봉이 더 높다던데.

A. 맞는 말이다. 시니어 DV는 수급이 타이트해서 보상이 RTL을 앞서기도 한다. 그래서 이 글은 "DV를 떠나라"가 아니라 "선택지를 넓혀라"다. RTL을 쓸 줄 아는 DV 엔지니어는 검증 리더, design manager, architect로 가는 길도 열린다. 전환은 탈출이 아니라 확장이다.

Q3. FPGA로 포트폴리오를 만들어도 되나요?

A. 된다. 오히려 권장한다. RTL을 FPGA에 올려서 실제로 돌려본 경험은 시뮬레이션만 한 것보다 설득력이 세다. 단, FPGA에서 돌아간다고 ASIC timing이 해결되는 건 아니다. Synthesis 리포트와 함께 제출하라.

Q4. 6개월이 현실적인가요? 현업과 병행이 가능한가요?

A. DV 현직자 기준 주 8~10시간이면 가능하다. DV에서 이미 아는 것(프로토콜, 디버깅, 커버리지)을 빼면 새로 배울 것은 microarchitecture, synthesis/PPA, timing 감각 세 가지다. 가장 시간이 오래 걸리는 것은 Month 5의 자가 검증 프로젝트인데, 이건 당신의 본업 스킬이라 남들보다 빠르다.

이 글은 커리어 가이드이며 특정 회사나 채용 결과를 보장하지 않습니다. 연봉 수치는 공개 자료 기준이며 실제 보상과 다를 수 있습니다.

Sources: Wilson Research Group 2022 findings via SemiWiki; 2026 Siemens/Wilson study via SemiWiki; India salary data via Futurense 2026 salary guide and entri.app; US 2026-Q3 RTL postings via hardwareifai; JobzMall; entry-point data via techgig and Futurense 2026 guide.