칩이 아직 존재하지 않는데도 실패를 찾아낼 수 있을까. 설계검증 엔지니어는 실제 실리콘이 만들어지기 전, 회로가 약속한 동작을 지키는지 수많은 조건으로 질문한다. 정상적으로 작동하는 장면보다 리셋이 갑자기 걸리는 순간, 저장공간이 가득 찬 순간, 읽기와 쓰기가 동시에 일어나는 순간이 더 중요한 시험대가 된다. 반도체 분야 진로를 고민한다면 장비나 언어의 이름보다 먼저 이 직업의 질문하는 방식을 이해할 필요가 있다.

명세서의 문장을 검증 가능한 조건으로 바꾸는 법부터 RTL 시뮬레이션의 시간 개념, 테스트벤치의 입력과 관찰, 독립적인 기대값을 계산하는 스코어보드까지 차례로 연결한다. 무작위 입력을 많이 만들어도 검증이 끝났다고 말할 수 없는 이유를 살피고, SystemVerilog와 UVM, 속성 검증과 형식 검증이 각각 어느 문제를 다루는지 구별한다. 파형과 로그가 실패의 원인을 가리키도록 만드는 과정이 구체적으로 펼쳐진다.

커버리지 98%라는 숫자 뒤에 무엇이 남았을까. 코드 커버리지와 기능 커버리지의 분모가 다르다는 사실, 회귀 시험과 버전 기록이 결과의 의미를 바꾼다는 사실을 알아야 통과 보고서를 제대로 읽을 수 있다. FPGA 검증의 가능성과 ASIC을 대신할 수 없는 한계, OpenTitan과 CV32E40P처럼 공개적으로 추적 가능한 프로젝트 자료의 읽는 법도 다룬다. 툴을 사용했다는 주장과 실제로 무엇을 검증했는지 증명하는 일의 차이를 선명하게 보여 준다.

전자공학과 컴퓨터공학 전공자, 반도체 설계검증으로 진입하려는 취업준비생, 작은 검증 과제를 포트폴리오로 만들고 싶은 독자를 위한 직무 안내서다. UART와 FIFO 예제로 요구사항, 실패 재현, 커밋과 로그, 잔여 위험을 묶어 내는 학습 경로를 따라가 보자. 찾은 오류의 개수보다 확인의 근거를 설명하는 능력이 왜 이 직업을 만드는지 이해하게 된다.