설계 자리가 안 열리면 검증·PD로 갈까? 순서가 답이다

30초 요약

• 검증 인력이 설계 인력을 추월했다. Wilson Research Group 2022년 조사 기준, 2007~2022년 프로젝트당 평균 투입 인력 증가율은 검증 6.2%, 설계 2.7%. 평균 인력비는 1:1, 프로세서 분야에서는 검증:설계가 5:1까지 벌어진다.
• 한국 채용시장도 뜨겁다. 잡코리아 집계 기준 2026년 3분기 반도체 대기업 채용 공고는 전년 대비 102% 증가. 다만 경력직이 157%, 신입은 55% — 신입에게 열리는 문은 생각보다 좁다.
• 우회는 영구화된다. RTL intent를 읽지 못하는 검증 엔지니어는 "설계할 수 없는 것을 검증"하고, RTL을 읽지 못하는 PD 엔지니어는 "읽을 수 없는 것을 구현"한다. 한 번 찍힌 타이틀은 다음 이직에서도 당신을 따라다닌다.
• 연봉 팩트(한국). 반도체 엔지니어 평균 base 약 8,296만원, 1~3년차 약 5,854만원, 8년차 이상 약 9,564만원(ERI SalaryExpert, 2026년). 대졸 엔지니어 초봉은 SK하이닉스 약 5,400만원, DB하이텍 4,800만~5,300만원 수준으로 알려져 있다.
• 답은 순서다. RTL 먼저, 그 다음 검증, synthesis, PD, STA/signoff 순으로 배워라. 검증·PD로 입사했어도 RTL부터 배워 앞으로 나아가라. 옆으로 가지 말고 앞으로 가라.

인트로: 가장 많이 받는 질문

독자 질문 중에서 이 질문이 가장 자주 온다.

"RTL 설계를 하고 싶은데 설계 TO가 안 나요. 검증이나 PD로 먼저 들어갔다가 나중에 설계로 옮기면 될까요?"

솔직히 말하겠다. 그 우회는 대부분 영구화된다. 검증으로 들어간 사람은 검증 엔지니어로 남고, PD로 들어간 사람은 PD 엔지니어로 남는다. 의지가 약해서가 아니다. 구조가 그렇게 만든다.

이 글은 그 구조를 데이터로 보여주고, 그럼에도 불구하고 이 길을 걷는 사람을 위한 답 — "순서" — 를 제시한다.

왜 이 질문이 계속 반복되는지도 짚어야 한다. "설계 자리가 안 보인다"는 느낌은 기분 탓이 아니라 구조의 결과다. RTL 설계는 본질적으로 소수 정예의 일이다. 한 명의 설계자가 짠 RTL을 여러 명의 검증 엔지니어가 검증하는 게 일반적인 프로젝트의 모습이고, Wilson 조사에서 본 1:1~5:1의 인력비가 바로 그 증거다. 국내의 한 진로 리서치(2026년 8월 작성, 실제 채용공고를 교차검증한 자료)에서도 회로설계 트랙 중 검증·DFT는 신입 채용이 "넓음"으로 분류되는 반면, AI 반도체 팹리스의 엔지니어 신입 채용은 드문 것으로 정리되어 있다. 즉, 신입이 체감하는 "설계 TO 실종"은 시장 구조 그 자체다.

본론

에피소드 1. 채용시장이 말하는 팩트: 검증 자리가 많은 건 사실이다

먼저 팩트부터. 검증 자리가 많다는 건 사실이다. 그것도 압도적으로.

Wilson Research Group의 Functional Verification Study(2022년판)에 따르면, 2007년부터 2022년까지 IC/ASIC 프로젝트당 평균 최대 투입 인력의 연평균 증가율(CAGR)은 설계 엔지니어 2.7%, 검증 엔지니어 6.2%였다. 검증 인력 증가 속도가 설계의 2.3배다. 오늘날 프로젝트당 평균 인력비는 검증:설계가 약 1:1이며, 프로세서 같은 분야에서는 5:1까지 벌어진다. (출처)

2020년판 조사에서는 더 직접적인 수치가 나온다. 설계 엔지니어가 업무 시간의 47%를 검증 관련 일에 쓴다. 설계를 해도 검증에서 벗어날 수 없다는 뜻이다. 역설적으로 들리겠지만, 이건 "검증으로 우회해도 된다"는 근거가 아니라 "설계자도 검증을 알아야 한다"는 근거다. (출처)

한국 시장도 뜨겁다. 잡코리아 집계에 따르면 2026년 3분기 반도체·디스플레이 대기업 채용 공고는 전년 동기 대비 102% 증가했다. 올해 3분기까지 누적 기준으로 반도체 엔지니어 공고는 55% 늘었다. (출처)

단, 한 줄을 더 읽어야 한다. 같은 조사에서 경력직 공고는 157% 늘어난 반면 신입 공고는 55% 증가에 그쳤다. AI 메모리 수요가 커지면서 기업들이 "바로 투입 가능한 인력"에 무게를 두고 있다는 해석이다. 즉, 공고 수는 늘었지만 신입에게 열리는 문의 폭은 생각보다 좁다. "검증 TO가 많으니 일단 들어가자"는 전략이 통하려면, 그 문이 신입에게도 열려 있어야 한다.

한 가지 수치를 더 보자. Wilson 2020년 조사에서 검증 엔지니어들이 가장 많은 시간을 쓰는 활동은 다름 아닌 디버깅이었다. 그런데 디버깅이란 결국 "RTL이 왜 이렇게 동작하는가"를 추적하는 일이다. RTL을 읽지 못하는 검증 엔지니어의 디버깅은 파형을 보고 testbench를 고치는 데서 끝나고, RTL을 읽는 엔지니어의 디버깅은 근본 원인까지 내려간다. 같은 "검증 3년차" 타이틀이라도 이 둘의 시장 가치는 다르다. 이 차이는 에피소드 3의 레버리지 이야기로 이어진다.

정직한 고지 하나. "RTL 설계 vs 검증 vs PD의 정확한 공고 수치"는 이 글에서 제시하지 않는다. 한국 채용 플랫폼(사람인·잡코리아 등)은 직무별 집계 수치를 공개하지 않아 텍스트로 검증할 방법이 없었기 때문이다. 위 수치는 프로젝트 인력 구조(Wilson)와 전체 채용 동향(잡코리아)이라는 검증 가능한 데이터에 기반한다. 직무별 공고 수 비교가 필요하면 플랫폼사에 직접 문의하거나 유료 리포트를 봐야 한다.

검증 offer를 받았다면, 수락 전에 이 세 가지를 확인해봐라. 첫째, 이 팀에 RTL design 리뷰 문화가 있는가. 검증 엔지니어가 설계 리뷰에 참여하는 팀에서는 RTL을 배울 수밖에 없다. 둘째, testbench 짜기 외에 assertion 기반 검증이나 formal을 쓰는가. 방법론이 다양한 팀일수록 배울 게 많다. 셋째, 사내 직무 전환 제도가 실제로 동작하는가. "나중에 설계로 옮기겠다"는 계획은, 그 문이 실제로 열리는 회사에서만 계획이 된다.

에피소드 2. 우회가 영구화되는 메커니즘

자리가 많다고 우회해도 된다는 뜻은 아니다. 우회가 영구화되는 데는 세 가지 메커니즘이 있다.

첫째, 검증은 RTL intent를 읽는 일이다.

UVM testbench를 짜는 기술 자체는 배울 수 있다. 문제는 그 다음이다. RTL intent — 설계자가 이 코드를 왜 이렇게 짰는가 — 를 읽지 못하면, 검증 엔지니어는 버그를 찾는 게 아니라 "돌아가는 것처럼 보이는 것"을 확인하는 데 그친다. Coverage 100%를 찍어도 spec을 오독한 데서 온 버그는 못 잡는다. Wilson 2020년 조사에서 ASIC/IC 프로젝트의 3분의 2가량이 한 번 이상의 respin을 경험했다는 수치가 괸히 나오는 게 아니다. 검증 인력은 늘었지만, 검증의 질은 인력 수로 해결되지 않는다.

둘째, PD는 "왜"를 모르면 툴 오퍼레이터로 남는다.

CTS를 돌리고, routing을 하고, timing ECO를 거는 일은 할 수 있다. 하지만 왜 이 pipeline stage가 여기에 있어야 하는지, 왜 이 구조가 timing에 유리한지를 모르면 PPA(power, performance, area) 트레이드오프에서 의사결정을 할 수 없다. 시키는 대로 돌리는 사람과 구조를 이해하고 돌리는 사람의 차이는 3년차부터 잔인하게 벌어진다.

구체적인 장면을 보자. Setup violation이 났다. RTL을 모르는 PD 엔지니어는 ECO를 열 번 돌려서 타이밍을 맞춘다. 끝. 구조를 아는 엔지니어는 timing report의 startpoint에서 RTL로 거슬러 올라가 본다. 어느 always 블록에서 왔는지, FSM의 어느 state인지. 그리고 "이건 backend에서 고칠 문제가 아니라, RTL 단계에서 pipeline을 하나 더 넣어야 할 문제"라고 설계팀에 되돌린다. 그 한 마디가 시니어와 주니어의 차이다. 검증도 마찬가지다. Spec에는 "두 클럭 도메인 간 신호 전달"이라고만 쓰여 있다. RTL을 읽지 못하는 검증 엔지니어는 기능 시뮬레이션에서 값이 전달되는 것만 보고 pass를 준다. Synchronizer가 빠진 걸 모른다. 실리콘에서 간헐적 fail이 터진다. RTL intent를 읽는 엔지니어는 코드를 보고 "여기 2-flop synchronizer가 있어야 하는데 없네"라고 잡아낸다.

정리하면 이렇다. RTL을 모르는 검증 엔지니어는 자신이 설계할 수 없는 것을 검증하고, RTL을 읽지 못하는 PD 엔지니어는 자신이 읽을 수 없는 것을 구현한다. 둘 다 "돌아가는 것"은 만들 수 있다. 하지만 "왜 돌아가는지"를 모른다. 그리고 "왜"를 모르는 엔지니어는 어려운 문제가 왔을 때 답을 낼 수 없다.

셋째, 타이틀의 관성.

채용시장은 당신의 "마지막 타이틀"로 당신을 부른다. 검증 3년차가 설계 포지션에 지원하면 면접관은 이렇게 묻는다. "왜 검증을 그만두려고 하시죠?" 그리고 당신은 RTL 설계 3년차들과 경쟁해야 한다. 그들보다 RTL을 못 읽으면서, 그들과 같은 테이블에 앉는 것이다. 1년차에는 가능했던 전환이 3년차부터는 급격히 어려워지는 이유다. 우회는 들어갈 때는 넓고, 나올 때는 좁다.

이력서의 첫 줄을 생각해봐라. "OOO, Design Verification Engineer (2023–2026)". 채용 담당자는 이력서를 6초 만에 스캔한다. 그 6초가 당신의 다음 3년을 결정한다. 타이틀은 그렇게 관성을 만든다.

솔직한 예외도 말하겠다. 우회가 통하는 경우가 있긴 하다. 검증·PD로 시작했다가 설계로 전환에 성공한 사람들의 공통점은 두 가지였다. 첫째, 입사 1~2년 안에 RTL을 독학해서 작은 IP를 직접 만들어봤다. "나중에"가 아니라 "지금" 했다. 둘째, 사내에 설계팀으로의 이동 경로가 실제로 열린 회사였다. 즉, 우회 자체가 문제가 아니라 "우회+방치"가 문제다. 들어간 자리에서 RTL을 배우지 않으면 우회는 영구화되고, 배우면 우회는 경유가 된다.

에피소드 3. 연봉 팩트: 타이틀이 아니라 레버리지가 돈을 번다

"그래서 검증이냐 PD냐, 어디가 돈을 더 주나요?" 이 질문에도 데이터로 답하겠다.

ERI SalaryExpert(2026년) 기준 한국 반도체 엔지니어의 평균 base salary는 약 8,296만원이다. 경력별로는 1~3년차 약 5,854만원, 8년차 이상 약 9,564만원. (출처) 대졸 신입 초봉은 SK하이닉스 약 5,400만원, DB하이텍 4,800만~5,300만원 수준으로 알려져 있다. (출처 1, 출처 2)

그리고 정직한 고지 둘. RTL 설계 vs 검증 vs PD로 나뉜 직무별 연봉 밴드 공개 데이터는 찾지 못했다. ERI 수치도 직무 blended 기준이다. 한국 대기업의 동일 직급 내에서는 설계·검증·PD 간 초봉 차이가 크지 않다. 같은 직급 체계, 같은 성과급 테이블을 쓰기 때문이다.

그렇다면 연봉을 가르는 건 뭔가. 타이틀이 아니라 레버리지다. RTL을 읽는 검증 엔지니어, 아키텍처를 이해하는 PD 엔지니어, 앞단의 intent를 읽고 signoff를 내리는 STA 엔지니어가 비싸다. STA/signoff 엔지니어의 몸값이 높은 이유도 같다. Signoff는 flow 전 단계의 intent를 전부 읽어야 하는 자리라서, 앞단을 모르면 할 수 없는 일이다. 5년 후의 연봉 차이는 "어느 타이틀이냐"가 아니라 "flow를 얼마나 넓게 읽느냐"에서 벌어진다.

글로벌 시장의 사례가 이를 증명한다. 2026년 3월 보도에 따르면, NVIDIA가 한국 HBM 개발 엔지니어 경력직 채용에 약 25만 8,750달러(약 3억 7,300만원) 수준의 연봉을 제시했고, MediaTek도 HBM 관련 엔지니어 채용에 약 26만 달러를 제시했다. (출처) HBM은 설계·공정·패키징 경험을 두루 갖춘 "실전형 인재"가 필요한 분야다. 돈이 몰리는 곳은 특정 타이틀이 아니라 "대체 불가능한 이해"다. HBM 경험이 비싼 이유는 HBM을 아는 사람이 적어서가 아니라, 그 정도 복잡도를 다룰 수 있는 엔지니어가 귀해서다. 검증이든 PD든, 그 수준의 이해에 도달한 엔지니어는 타이틀과 무관하게 비싸진다.

에피소드 4. 순서가 답이다: front-to-back 룰

여기까지가 진단이다. 이제 처방이다. 답은 단순하다. 순서대로 배워라. RTL 먼저.

칩이 만들어지는 순서대로 배우는 것 — front-to-back — 이 가장 빠른 길이다. 각 단계에서 손에 쥐어야 할 것은 다음과 같다.

1. RTL Design — Verilog/SystemVerilog, FSM, pipeline 구조, CDC 기초. "합성 가능한 RTL"을 직접 써보는 것. 이게 없으면 뒤의 모든 단계가 블랙박스가 된다.
2. Verification — UVM testbench 구조, SVA(assertion), functional coverage closure, formal의 개념. RTL을 쓰고 나면 "내가 짠 것을 어떻게 증명하는가"를 배운다.
3. Synthesis — constraint(SDC 기초), lint, netlist가 RTL과 어떻게 달라지는지.
4. Physical Design — floorplan, power plan, CTS, routing, physical verification(DRC/LVS)의 개념.
5. STA / Signoff — timing constraint 작성, timing exception, timing closure, signoff criteria.

이미 검증·PD로 입사한 사람을 위한 현실적인 플랜도 있다. 업무 외 하루 1시간, 6개월이면 된다. UART나 SPI 같은 작은 IP를 Verilog로 직접 쓰고, synthesis를 돌리고, STA까지 돌려보는 것이다. "읽기"가 아니라 "만들기"부터다. 직접 만들어본 사람만 intent를 읽을 수 있다.

업무 시간 안에서도 배울 수 있다. 검증 엔지니어라면, 버그가 났을 때 testbench부터 보지 말고 waveform과 RTL부터 봐라. "왜 이 신호가 이렇게 나오는가"를 RTL에서 추적하는 습관이 곧 RTL 리딩 훈련이다. PD 엔지니어라면, timing report의 startpoint/endpoint를 보고 netlist가 아니라 RTL로 거슬러 올라가라. 3개월만 해도 "타이밍이 왜 깨지는지"가 보이기 시작한다.

6개월 플랜을 구체적으로 짜면 이렇다. 1~2개월차: Verilog 기초와 작은 모듈(UART TX) 직접 작성. 3~4개월차: SPI slave 같은 slightly bigger IP와 testbench를 직접 작성해 기능 검증까지. 5~6개월차: synthesis를 돌리고 STA 리포트 읽기에 도전. 이 순서가 바로 위 그림의 1→2→3→5다. PD(4단계)는 개념 학습으로 병행하면 된다.

그리고 이 모든 과정을 GitHub에 올려라. RTL 코드, 직접 짠 testbench, synthesis 리포트, STA 리포트. "검증 2년차지만 RTL도 읽고 짭니다"를 증명하는 방법은 포트폴리오뿐이다. 면접관은 말을 믿지 않고 결과물을 본다. 이력서의 타이틀이 검증이어도, GitHub의 첫 페이지가 RTL이면 이야기가 달라진다.

핵심을 한 줄로 줄이면: 옆으로 가지 말고 앞으로 가라. 검증에서 PD로, PD에서 DFT로 옆으로 옮겨 다니는 건 이동이 아니라 표류다. RTL을 시작으로 flow를 따라 앞으로 나아가는 것만이 커리어가 된다.

edu.vlsi.kr 연계 로드맵

이 글의 "순서대로 배워라"는 주장은 VLSI Edu의 RTL2GDS 로드맵과 같은 방향을 본다. 해당 페이지는 "배운 기술이 닿을 다음 무대"라는 커리어 호라이즌 섹션에서 설계·검증·EDA·파운드리·장비 기업의 글로벌 커리어 지도를 보여준다(Samsung, SK hynix, NVIDIA, Qualcomm, AMD, Arm, Intel, Broadcom, Marvell, Micron, TSMC, Cadence, Synopsys, ASML). — 이 페이지는 직접 열어 확인했다.

정직한 고지 셋. 로드맵·튜토리얼 상세 페이지는 텍스트 fetch로 열리지 않아(JavaScript 렌더링 사이트) URL을 검증하지 못했다. 아래는 이 글의 순서와 직접 연결되는 주제들로, VLSI Edu에 이런 페이지가 있다면(또는 생긴다면) 그대로 따라가면 되는 것들이다.

1. RTL 설계 로드맵 — Verilog/SystemVerilog 기초 → 합성 가능한 RTL 코딩 → AMBA 프로토콜(AXI/AHB) → 작은 IP 직접 설계. 에피소드 4의 1단계.
2. 검증 로드맵 — UVM testbench 구조 → SVA → functional coverage closure → formal verification 개념. 에피소드 4의 2단계.
3. STA/Signoff 로드맵 — SDC 작성 → timing exception → timing closure → signoff criteria. 에피소드 4의 5단계이자 연봉 레버리지가 가장 큰 구간.
4. PD 로드맵 — floorplan → power plan → CTS → routing → physical verification. 에피소드 4의 4단계.

Chase's Take

나는 지금 Synopsys에서 PrimeTime/PrimeShield/PrimePower를 만드는 Staff Product Engineer다. STA와 signoff 툴이 본업이니, 따지고 보면 나는 "백엔드의 끝"에 서 있는 사람이다.

그런데 그 전에 나는 SiFive Korea에서 RTL-to-GDS 풀오너십으로 일했다. Samsung 5nm부터 14nm까지, 5번이 넘는 tapeout — Rebellions ATOM, FuriosaAI WARBOY, RHEA 같은 칩들의 physical implementation을 처음부터 끝까지 맡았다.

백엔드 툴을 만드는 내가 신입들에게 "앞단부터 배우라"고 말하는 이유가 있다. STA에서 timing violation을 마주하면, 결국 돌아가는 곳은 RTL intent다. SDC를 쓰는 것도, ECO를 판단하는 것도, 앞단을 모르면 "툴이 뱉은 숫자"와 싸우는 일이 된다. 숫자는 읽을 수 있지만, 숫자가 왜 나왔는지는 모르는 것이다. 내가 PrimeTime을 만들면서 가장 무서워하는 사용자가 바로 그 사용자다 — 툴을 믿고, RTL을 의심하지 않는 사용자.

SiFive에서 RTL-to-GDS를 할 때, tapeout 전날 밤에 내가 가장 오래 본 것은 PrimeTime 리포트 화면이 아니라 RTL 코드였다. Timing을 고치는 가장 빠른 방법은 대부분 RTL에 있었다. 이 경험이 지금 내가 STA 툴을 만들 때의 기준이 된다. "이 기능을 쓰는 엔지니어가 RTL을 모르면, 이 기능은 독이 된다." 툴은 앞단을 아는 엔지니어의 손에서만 제대로 된 무기가 된다.

그래서 나는 "전반적으로 다 해봐야 한다"고 말한다. Flow 전체를 손으로 만져본 엔지니어와 한 구간만 아는 엔지니어는 5년 후에 완전히 다른 사람이 된다. 검증·PD로 시작했다고 후회하지 마라. 다만 거기서 멈추지 마라. RTL부터 배워서 앞으로 나아가라. 순서가 답이다.

FAQ

Q1. 검증으로 시작하면 정말 설계로 못 돌아가나요?
못 돌아가는 게 아니라, 돌아가는 비용이 매년 커진다. 1년차에는 어렵지 않다. 하지만 3년차가 되면 RTL 설계 경력자들과 경쟁해야 하고, 면접에서는 "왜 검증을 떠나려 하느냐"는 질문을 받는다. 그래서 "나중에"가 아니라 "지금" RTL을 배워야 한다.

Q2. PD는 설계보다 연봉이 낮나요?
한국 대기업의 동일 직급 내에서는 설계·검증·PD 간 초봉 차이가 크지 않다. 직무별로 나뉜 공개 연봉 밴드 데이터도 없다(위 에피소드 3 참조). 차이는 5년 후에 벌어지는데, 그건 타이틀이 아니라 flow를 얼마나 넓게 읽느냐 — 레버리지의 차이에서 온다.

Q3. 검증 자리가 더 많다는데, 그냥 검증을 목표로 하면 안 되나요?
검증 자체는 훌륭한 커리어다. 문제는 "설계를 하고 싶은데" 검증으로 우회하는 것이다. 목표가 검증이라면 검증의 정점을 노려라 — formal verification, UVM 아키텍처, verification leadership. 우회는 목표가 아니라 타협일 때 위험해진다.

Q4. 지금 검증/PD로 일하고 있는데 RTL은 어떻게 시작하죠?
업무 외 하루 1시간이면 된다. UART나 SPI 같은 작은 IP를 Verilog로 직접 쓰고, synthesis를 돌리고, STA까지 돌려본다. 읽기만 하지 말고 만들어봐라. 직접 만들어본 사람만 intent를 읽을 수 있다. 위 edu.vlsi.kr 연계 섹션의 RTL 설계 로드맵 순서대로 가면 된다.

이 글은 커리어 관점의 일반 정보이며 투자·이민 조언이 아닙니다.