이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학부 RTL 설계 팀 프로젝트에서 스펙 리뷰를 처음 체계적으로 진행했습니다. 리뷰 전에 스펙의 어느 부분이 모호한지를 체크리스트로 먼저 정리했습니다. 인터페이스 정의에서 핸드셰이크 조건이 불명확하거나, 예외 상황에서 어떻게 동작해야 하는지 빠진 경우가 많았습니다.
스펙에서 빈틈을 찾는 것이 RTL을 짜기 전에 해야 하는 작업이라는 걸 그때 배웠습니다. 코드 리뷰에서는 타이밍 제약과 스펙을 동시에 보면서 구현이 의도대로 됐는지를 확인했습니다. 리뷰어가 다른 시각으로 보기 때문에 혼자 검토할 때 안 보이던 것이 드러나는 경우가 많다는 걸 경험했습니다. 이후 저는 구현 전에 스펙 빈틈 목록을 만드는 습관이 생겼습니다. 스펙이 구체적일수록 구현 오류가 줄어든다는 걸 그때 배웠습니다.
코드 리뷰에서 지적된 결함 유형을 해결하고 끝내는 것이 아니라 같은 유형의 결함을 잡는 테스트 커버리지 목표로 전환하는 것이 리뷰의 장기 가치를 높이는 방법입니다. 학부 RTL 프로젝트에서 리뷰 중 CDC 동기화 누락이 발견됐을 때, 해당 신호만 수정하고 끝냈는데 다른 신호에서 같은 유형의 문제가 다시 나온 경험이 있었습니다.
CDC 관련 UVM 커버포인트 추가로 한 번 발견된 결함 유형을 테스트벤치 검증 항목으로 남기면 이후 모든 코드 변경에서 동일 유형을 자동으로 검사하는 구조가 됩니다. 리뷰 지적은 해당 코드의 수정으로 끝나는 것이 아니라 검증 범위를 넓히는 계기입니다.
이 이해에서 리뷰에서 결함이 발견될 때 같은 유형을 다른 곳에서도 검사하는 커버리지 항목을 추가하는 것을 세트로 처리하는 방식이 생겼습니다. 코드 리뷰의 완성은 수정이 아니라 검증 범위 확장입니다.
스펙·코드 리뷰에서 FSM(유한 상태 머신) 설계의 완전성을 검증하는 원칙을 리뷰 체크리스트에 넣어두는 것이 반복적인 누락을 막는 방법입니다. 학부 프로젝트에서 FSM의 도달 불가 상태(Unreachable State)를 처리하지 않아 특정 시퀀스에서 설계가 예상 외 상태에 갇히는 문제가 발생했습니다.
FSM 상태 전이 완전성 체크(모든 입력 조합에 전이 정의 여부) 항목을 리뷰 체크리스트에 넣으면 시뮬레이션에서 나타나지 않는 엣지 케이스를 리뷰 단계에서 잡을 수 있습니다. RTL 리뷰에서 기능 동작만 확인하고 상태 완전성을 확인하지 않으면 코너 케이스에서 예측 불가 동작이 남습니다. 이 경험에서 RTL 리뷰 체크리스트를 만들 때 FSM 완전성 항목을 표준 항목으로 포함시키는 방식이 생겼습니다. 리뷰 원칙은 과거 결함 데이터에서 역추적해 만들 때 빠진 자리가 줄어듭니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 반도체 회로설계 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.