인프런 커뮤니티 질문&답변

안녕하세요, 답변 남겨드립니다.

결론부터 말씀드리면, 디코더나 카운터를 CMOS 트랜지스터 레벨로 “외워서” 즉시 그릴 정도까지는 대부분의 디지털 RTL 직무 면접에서 요구하지 않습니다. 대신 면접에서 자주 보는 포인트는 논리게이트 수준에서의 기능 이해, 불리언 대수로의 단순화, 타이밍 관점에서의 위험(글리치, 해저드), 그리고 그 회로를 Verilog로 안전하게 표현하는 능력입니다. NAND와 NOT을 “모든 논리의 기초”로 언급하는 것도, 실제로는 NAND로 모든 조합논리를 구성할 수 있다는 사실을 이용해 논리적 사고가 되는지를 보려는 성격이 강합니다.

디코더나 카운터 같은 블록에 대해 어느 수준까지 해야 하느냐를 직무 관점으로 나누면 명확해집니다. RTL 설계/검증(Verilog/SystemVerilog) 중심이라면 디코더는 “n비트 입력이 들어오면 2^n개의 one-hot 출력이 나온다”, “enable이 있으면 출력이 모두 0이 될 수 있다”, “case 문으로 one-hot을 만들되 default를 명확히 한다” 같은 동작적 이해가 핵심이고, 카운터는 “동기식/비동기식 reset 차이”, “enable gating”, “rollover 조건”, “비트폭과 overflow”, “업/다운”, “Gray counter 같은 파생형” 정도를 정확히 말하고 코딩할 수 있으면 됩니다. 게이트 레벨로는 2:4 decoder 정도는 진리표를 바로 쓰고 논리식을 만들 수 있으면 좋고, 4비트 카운터는 “플립플롭 4개와 다음상태 논리”라는 구조를 설명할 수 있으면 충분한 경우가 많습니다. 반면 트랜지스터(CMOS) 레벨로 인버터, NAND, NOR 정도는 기본 소양으로 물을 수 있지만, “카운터 전체를 CMOS로 그려라” 같은 질문은 보통 아날로그/풀커스텀/표준셀 라이브러리 설계 쪽에서나 의미가 있고, RTL 채용에서 나오면 오히려 비정상적인 편입니다.

다만 “논리기호로 바로 표현”은 케이스가 있습니다. 예를 들어 2:1 MUX, half adder/full adder, 2:4 decoder, priority encoder 같은 소규모 조합회로는 면접에서 구두로 설명하다가 손으로 블록 다이어그램 또는 간단한 게이트 조합을 그리게 하는 일이 있습니다. 여기서 기대치도 “정확히 최적 게이트 수로”가 아니라, 기능이 맞고 입력 조합에 대해 일관되게 동작하는 구조를 제시하는 수준인 경우가 많습니다. 정량적으로 말하면, 신입 기준으로 2~3분 안에 진리표를 쓰고, 5분 안에 간단한 논리식이나 게이트 구조를 제시할 수 있으면 충분히 경쟁력이 있습니다.

두 번째 질문인 “취업을 위해 Verilog 구현 능력이 어느 정도여야 하냐”는 회사/포지션에 따라 차이가 있지만, 소프트웨어처럼 대규모 코딩테스트를 보는 형태는 상대적으로 덜 흔하고, 대신 짧은 RTL 문제를 화이트보드나 코딩 플랫폼에서 15~45분 정도 푸는 방식이 꽤 있습니다. 즉 “종이 한 장 주고 4비트 FA 코드를 적어봐라”는 형태가 실제로 나올 수 있습니다. 다만 여기서 말하는 코드는 대개 문법을 완벽히 외워서 한 번에 컴파일되게 쓰는 수준이라기보다는, 조합논리와 순차논리를 구분해서 always_comb/always_ff(또는 always @*)/(posedge clk)로 의도를 정확히 표현하고, latch가 생기지 않게 default를 주고, blocking/non-blocking을 올바르게 쓰는지 같은 “RTL 사고력”을 봅니다.

면접에서 자주 나오는 “백지 코딩”의 난이도를 정량적으로 예시로 들면, 신입/주니어 RTL 기준으로 아래 정도는 외우다시피 즉시 작성하는 편이 안전합니다. 2:1 mux, 4:1 mux, decoder(2:4 또는 3:8), priority encoder(4:2), 1비트/4비트 adder(연쇄), DFF with reset/enable, up counter with enable and synchronous reset, simple FSM(traffic light 수준), 간단한 ready/valid 핸드셰이크 레지스터 슬라이스 정도입니다. 반대로 AXI 전체 채널을 백지에서 정확한 타이밍까지 다 적으라는 식의 문제는 신입 면접에서 비현실적이고, 오히려 개념 질문으로 “AW/W/B 채널이 독립인 이유”, “burst length/size 의미”, “backpressure 처리” 같은 걸 묻는 쪽이 일반적입니다.

AI나 검색을 활용하는 방식에 대해서는, 현업에서는 당연히 활용합니다. 다만 면접은 “검색 없이도 최소한의 정확한 골격을 만들 수 있는지”를 보려고 하기 때문에, 뼈대(skeleton)조차 못 세우면 불리해집니다. 현실적인 목표는 “빈 종이에서도 70~80%는 맞는 RTL을 작성하고, 문법 자잘한 부분(예: sensitivity list 디테일, 타입 선언, 일부 키워드)은 약간 틀릴 수 있지만 의도는 명확히 설명 가능” 정도입니다. 특히 조합회로는 always @* 또는 always_comb에서 모든 출력에 default를 주는 습관, 순차회로는 non-blocking(<=)을 쓰는 습관, 그리고 bit-width를 명시적으로 관리하는 습관은 면접에서 바로 티가 납니다.

현업적인 예시를 하나 들면, 4비트 FA를 “구현”하라고 했을 때 단순히 assign으로 “sum = a + b + cin”을 쓰는 것도 기능은 맞지만, 면접관이 보고 싶은 포인트가 “carry chain을 이해하는가”라면 generate로 1비트 FA를 4개 연결하거나, 최소한 {cout,sum} = a + b + cin 형태로 캐리와 합이 어떻게 나뉘는지 보여주는 답을 선호할 수 있습니다. 반대로 검증 관점이면 “랜덤 벡터 1000개를 넣어 reference 모델(a+b+cin)과 비교하는 self-checking TB를 10분 내로 짜라” 같은 식으로 형태가 바뀝니다. 결국 요구 역량은 “코드량”보다 “의도 표현과 검증 가능성”에 더 가깝습니다.

마지막으로 준비 전략을 정량적으로 추천드리면, 매일 30분씩 2주만 투자해도 체감이 크게 올라갑니다. 하루에 미니 문제 1개를 정하고, 10분 안에 진리표/상태도, 10분 안에 RTL, 10분 안에 간단한 테스트(예: for 루프로 2^n 전수 또는 랜덤 200~1000패턴)를 만드는 훈련을 하시면, “백지 공포”가 상당히 줄어듭니다. 면접에서 요구되는 건 대개 이 정도 속도감과 정확도입니다.