검증(DV)으로 입사하면 설계로 못 가나 — 직무 전환이 실제로 일어나는 조건

핵심 결론 DV로 입사했다고 설계로 못 가는 것은 아니다. 다만 자동으로 넘어가는 경우는 거의 없고, 전환은 '설계를 할 수 있다는 증거'를 DV 업무 안에서 미리 만든 사람에게만 일어난다. 전환 확률을 가르는 것은 연차가 아니라 세 가지다. 설계자와 같은 언어로 스펙을 논의한 기록, 작은 블록이라도 RTL을 직접 고쳐 본 경험, 그리고 이동하려는 팀의 인력 공백이다. AE에서 설계로 넘어가는 경로도 같은 원리다. 고객 설계를 대신 디버깅한 경험은 설계 역량으로 번역될 때만 이력서에서 힘을 갖는다.

DV와 설계, 경계는 생각보다 얇고 벽은 생각보다 높다

반도체 설계 조직에서 Design과 DV(Design Verification)는 같은 스펙 문서를 보고 일한다. 설계자는 스펙을 RTL로 구현하고, DV 엔지니어는 그 구현이 스펙과 일치하는지 검증한다. 매일 마주치는 산출물도 겹친다. 파형, 커버리지 리포트, assertion 실패 로그, 타이밍이 걸린 코너 케이스. 그래서 신입 시절에는 두 직무가 '비슷한 일을 하는 팀'처럼 보인다.

차이는 책임의 방향에 있다. 설계자의 책임은 '무엇을 만들 것인가'를 결정하는 쪽에 있고, DV의 책임은 '만든 것이 틀렸음을 증명하는' 쪽에 있다. 설계자는 microarchitecture 선택, pipeline 깊이, clock gating 전략, 면적과 전력 사이의 trade-off를 결정한다. DV는 그 결정을 의심하고, 경계 조건을 만들고, 설계자가 상상하지 못한 stimulus로 결정을 흔든다.

이 차이 때문에 전환의 벽이 생긴다. DV 경력 3년이면 검증 방법론에서는 중급 이상으로 평가받지만, 설계 팀장 입장에서는 '결정을 내려 본 적이 없는 사람'으로 보일 수 있다. 벽은 실력의 벽이 아니라 증거의 벽이다. 설계 결정을 내려 본 증거가 포트폴리오에 없으면, 면접관은 그 역량을 있다고 가정하지 않는다.

반대로 경계가 얇은 순간도 분명히 존재한다. 버그를 찾은 DV가 원인을 RTL 라인 단위까지 좁히고, 수정 방향까지 제시하고, 그 수정이 PPA에 미치는 영향까지 코멘트하는 순간, 그 사람은 사실상 설계 리뷰를 하고 있는 것이다. 전환에 성공한 사람들은 대부분 이 얇은 경계를 반복해서 넘나든 기록을 갖고 있었다.

왜 'DV는 설계로 못 간다'는 말이 도는가

첫째, 채용 공고가 분리되어 있기 때문이다. 대기업 공채든 경력 채용이든 Design과 DV는 별도 트랙으로 뽑고, 부서 배치 이후에는 팀 단위 평가와 인력 계획이 따로 돈다. 같은 사업부 안에서도 팀 이동은 내부 전배 절차를 거쳐야 하고, 보내주는 팀장이 동의하지 않으면 이동 자체가 시작되지 않는다.

둘째, DV 조직은 항상 인력이 부족하기 때문이다. Tape-out 일정이 가까워질수록 검증 workload는 늘어나고, 숙련된 DV 엔지니어를 다른 팀으로 보내주는 결정은 DV 팀장에게 손해로만 보인다. 즉 개인의 희망과 조직의 이해가 정면으로 충돌하는 구조다. 이 구조를 모르고 '열심히 하면 언젠가 옮겨주겠지'라고 기다리는 전략이 가장 흔한 실패다.

셋째, DV 경력이 길어질수록 연봉과 직급이 DV 전문성 기준으로 쌓이기 때문이다. 5년 차 DV가 설계로 옮기면, 설계 조직에서는 사실상 1~2년 차 수준의 일을 맡을 가능성이 높다. 회사도 본인도 그 간극을 감수해야 전환이 성립한다. 그래서 전환은 빠를수록, 직급이 낮을수록 쉽다. 이 현실을 인정하는 것부터가 전략의 시작이다.

전환이 실제로 일어나는 세 가지 경로

1. 같은 프로젝트 안에서 역할을 넓히는 경로

가장 현실적인 경로다. 공식적인 팀 이동 없이, 현재 프로젝트에서 설계에 가까운 일을 조금씩 맡는 방식이다. 예를 들어 검증 과정에서 발견한 버그의 fix를 직접 제안하고, 작은 sub-block의 RTL 수정을 설계자와 pair로 진행하고, ECO 단계에서 제한된 범위의 RTL 변경을 책임지는 식이다.

이 경로의 핵심은 '설계자가 귀찮아하는 일을 설계 수준으로 해내는 것'이다. 단순 반복 수정이 아니라, 수정 전후의 기능 동등성과 타이밍 영향을 스스로 확인해서 가져가면 신뢰가 쌓인다. 이 신뢰가 다음 프로젝트에서 '이 블록은 이 사람이 맡아도 되겠다'는 판단으로 바뀐다. 내부 이동 신청서에 쓸 한 줄도 여기서 나온다.

2. 신규 프로젝트나 신규 조직으로 이동하는 경로

새로운 칩 프로젝트가 시작되거나 신규 법인과 신규 팀이 만들어질 때 인력 수요가 한꺼번에 생긴다. 이때는 기존 설계 경력자만으로 팀을 채울 수 없어서, 인접 직무 경력자에게 문이 열린다. DV 출신이 설계 팀의 초기 멤버로 합류하는 사례는 대부분 이 타이밍에 발생한다.

이 경로를 노린다면 평소에 신규 프로젝트 정보를 빨리 접할 수 있는 위치에 있어야 한다. 설계 팀장들과 기술 리뷰 자리에서 얼굴을 익히고, 자신의 RTL 수정 경험을 짧게라도 공유해 둔 사람이 후보군에 오른다. 기회는 공고로만 오지 않는다.

3. 이직을 통한 전환 경로

내부 이동이 막혀 있으면 이직이 오히려 빠를 수 있다. 중소 팹리스나 스타트업은 Design과 DV의 경계가 대기업만큼 엄격하지 않다. 한 사람이 RTL 작성과 self-checking testbench를 함께 맡는 조직도 많고, 채용 시에도 'RTL을 읽고 고칠 수 있는 DV'와 '검증까지 이해하는 설계자'를 높게 평가한다.

단, 이직 면접에서는 DV 경력을 그대로 들고 가면 DV 포지션으로 다시 제안받기 쉽다. 이력서의 첫 화면부터 달라야 한다. 담당했던 블록의 microarchitecture를 설명하고, 직접 수행한 RTL 변경과 그 결과를 정량적으로 적어야 한다. 포지션 제안을 DV로 받았을 때 무조건 거절할 필요는 없지만, 입사 후 역할 확장 가능성을 면접 단계에서 구체적으로 확인해야 한다.

AE에서 설계로 넘어가는 경우도 원리는 같다

Application Engineer, 특히 EDA 툴 AE나 파운드리 연계 AE로 일하다가 설계로 이동하려는 경우도 구조는 동일하다. AE는 다양한 고객 설계를 접하면서 디버깅 속도와 툴 이해도가 빠르게 는다. 여러 회사의 설계 스타일을 비교해 본 경험은 한 회사에만 있던 설계자에게 없는 자산이다.

문제는 AE의 경험이 '남의 설계를 고친 경험'으로만 기록되면 설계 역량으로 인정받기 어렵다는 점이다. 인정받는 번역은 따로 있다. 고객 이슈를 재현하기 위해 직접 만든 test case와 constraint, 타이밍 위반을 해결하기 위해 제안한 RTL 구조 변경, signoff 기준을 만족시키기 위해 설계자와 합의한 trade-off. 이런 기록은 사실상 설계 판단의 기록이다.

AE 출신이 설계 면접에서 가장 강해지는 지점은 STA와 physical-aware 설계다. 타이밍이 왜 깨지는지, RTL 단계에서 어떤 선택이 backend를 어렵게 만드는지를 설명할 수 있는 지원자는 많지 않다. 반대로 약해지는 지점은 처음부터 끝까지 하나의 블록을 오너십 있게 끌고 가 본 경험이 있는가라는 질문이다. 이 질문에 답할 작은 오너십이라도 미리 만들어 두는 것이 AE 전환 준비의 핵심이다.

DV 역량을 설계 역량으로 번역하는 표

면접관과 팀장은 DV 경력을 자동으로 설계 경력으로 환산하지 않는다. 환산표는 본인이 만들어서 제시해야 한다.

이 표에서 오른쪽 열이 비어 있으면 아직 번역이 완성되지 않은 것이다. 전환 준비란 결국 오른쪽 열을 채우는 과정이다. 거창한 사이드 프로젝트보다 현재 업무에서 나오는 증거가 훨씬 설득력이 높다.

전환 타이밍과 회사 규모에 따른 차이

대기업에서는 내부 이동 제도가 formal하게 존재하는 대신 경쟁도 formal하다. 이동 신청 시즌, 팀장 동의, 받는 팀의 TO가 모두 맞아야 한다. 대신 이동 후에는 설계 프로세스와 교육 체계가 잘 갖춰져 있어, 부족한 부분을 체계적으로 메울 수 있다.

중소 팹리스에서는 제도보다 프로젝트 상황이 우선이다. 설계 인력이 부족한 프로젝트에서는 DV 출신이라도 RTL을 맡을 기회가 빨리 온다. 대신 체계적인 멘토링이 없을 수 있어, 스스로 학습 계획을 세우지 않으면 'RTL도 쓰고 검증도 하는 애매한 포지션'에 머물 위험이 있다.

스타트업에서는 직무 구분 자체가 흐릿한 경우가 많다. 전환이라는 개념 없이 처음부터 넓게 일하게 되지만, 그만큼 실적 압박도 직접적이다. 경력의 방향성을 본인이 관리하지 않으면 시장에서는 여전히 DV로 분류될 수 있다. 회사 안에서 맡은 일과, 시장에서 읽히는 이력서는 별개로 관리해야 한다.

타이밍으로 보면 입사 후 1~3년 구간이 전환 비용이 가장 낮다. 이 구간에서는 회사도 '육성 가능한 인력'으로 평가하고, 본인도 직급 하락 부담이 작다. 4년 차를 넘어가면 전환 자체가 불가능해지는 것은 아니지만, 증거의 수준이 달라진다. 작은 RTL 수정 경험으로는 부족하고, 블록 단위 오너십에 가까운 실적이 요구된다.

전환에 실패하는 전형적인 패턴

가장 흔한 패턴은 검증 전문성을 더 쌓으면 설계로 갈 수 있을 것이라고 믿는 경우다. UVM을 더 깊게 파고, formal verification을 익히고, 커버리지 방법론을 마스터하는 것은 DV로서의 가치를 높이지만 설계 전환과는 방향이 다르다. 오히려 전문성이 깊어질수록 DV 조직이 놓아주지 않게 되고, 본인의 시장 가치도 DV 쪽으로 굳어진다.

두 번째 패턴은 희망만 말하고 증거를 만들지 않는 경우다. '기회가 되면 설계를 하고 싶다'는 말은 팀장에게 인력 이탈 신호로만 들리고, 실제 기회가 왔을 때의 추천 사유가 되지는 못한다. 팀장이 위로 보고할 수 있는 문장은 희망이 아니라 실적이다.

세 번째 패턴은 전환 후의 간극을 인정하지 않는 경우다. 설계로 옮긴 뒤에도 기존 DV 연차에 맞는 평가를 기대하면 첫 평가 시즌에 크게 흔들린다. 전환은 단기적으로 손해 보고 장기적으로 방향을 바꾸는 결정이다. 이 손해를 감수할 수 있는 시점인지, 재정과 커리어 계획 측면에서 먼저 계산해야 한다.

FAQ

Q1. DV 경력 몇 년까지가 설계 전환의 현실적인 마지노선인가요? 정해진 마지노선은 없지만 비용 구조가 달라지는 구간은 분명히 있다. 1~3년 차까지는 육성 관점의 전환이 가능하고, 4년 차부터는 블록 단위 설계 기여 증거가 사실상 필수다. 연차가 쌓일수록 전환이 불가능해지는 것이 아니라 요구되는 증거의 수준이 높아진다고 이해하는 것이 정확하다.

Q2. DV를 하면서 RTL 공부는 무엇부터 해야 하나요? 문법 공부가 아니라 본인이 검증하는 블록의 RTL을 읽는 것부터 시작해야 한다. 담당 블록의 FSM, datapath, interface protocol을 그림으로 그릴 수 있을 때까지 읽고, 버그를 찾을 때마다 '내가 설계자라면 어떻게 짰을까'를 기록으로 남기는 습관이 가장 빠른 학습이다. 그다음 단계가 작은 블록을 직접 구현해 보는 것이다.

Q3. 내부 이동과 이직 중 무엇이 더 유리한가요? 현재 회사에 신규 프로젝트나 신규 조직 계획이 있다면 내부 이동이 빠르고 안전하다. 반대로 DV 조직의 인력 사정상 이동 동의가 구조적으로 어렵다면 이직이 현실적이다. 판단 기준은 본인의 희망이 아니라, 앞으로 6개월 안에 이동 가능한 TO가 실제로 존재하는지다.

Q4. AE에서 설계로 갈 때도 DV와 같은 준비가 필요한가요? 핵심은 같다. 남의 설계를 지원한 경험을 본인의 설계 판단 경험으로 번역해야 한다. AE라면 특히 타이밍과 physical-aware 관점의 강점을 전면에 내세우고, 블록 오너십 경험의 공백을 작은 설계 과제로라도 메워 두는 것이 중요하다.

Q5. 설계로 옮긴 뒤 다시 DV로 돌아갈 수 있나요? 가능하고, 실제로 설계 경험을 가진 DV는 시장에서 가치가 높다. 설계 가능한 검증 엔지니어는 coverage-driven 검증뿐 아니라 설계 초기 단계의 리뷰 품질 자체를 바꾼다. 전환을 일방통행으로 생각하고 조급해질 필요는 없다. 다만 이력서상의 직무 정체성이 흔들리지 않도록 각 단계에서 무엇을 얻었는지 명확히 정리해 두어야 한다.

행동 체크리스트

• ☐ 내가 검증하는 블록의 microarchitecture를 그림과 문장으로 설명할 수 있는지 점검했다
• ☐ 최근 6개월 안에 직접 제안하거나 작성한 RTL 변경 사례를 목록으로 정리했다
• ☐ DV 업무 기록을 설계 역량 표현으로 번역한 이력서 초안을 만들었다
• ☐ 이동하고 싶은 설계 팀의 프로젝트 일정과 인력 수요를 파악했다
• ☐ 현재 팀장에게 희망이 아닌 실적으로 말할 수 있는 전환 사유 한 문장을 준비했다
• ☐ 전환 후 1~2년간의 평가와 보상 간극을 감수할 수 있는지 계산했다
• ☐ 내부 이동이 막힐 경우를 대비해 외부 포지션의 요구 역량을 확인했다

함께 읽으면 좋은 글

• 삼성전자·SK하이닉스 회로설계·배치설계·회로검증 직무 차이 총정리 — 공고 해독하는 법
• 학사 회로설계 취업, RTL 코딩만 잘하면 될까 — 아키텍처 이해가 합격을 가른다

📩 VLSI Korea 뉴스레터 구독하기

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

무료로 구독하기