학사 회로설계 취업, RTL 코딩만 잘하면 될까 — 아키텍처 이해가 합격을 가른다

핵심 결론 학사 회로설계 취업에서 RTL 코딩 실력은 필요조건이지 충분조건이 아니다. 코딩 테스트 수준의 Verilog는 지원자 대부분이 준비해 오기 때문에 변별력이 빠르게 사라진다. 합격자를 가르는 것은 architecture 이해다. 같은 기능을 왜 이 구조로 짜야 하는지, pipeline과 latency와 면적 중 무엇을 희생했는지를 설명할 수 있는 지원자가 뽑힌다. 포트폴리오는 코드 양으로 평가받지 않는다. 설계 결정을 기록한 문서, 검증까지 마친 완성도, 그리고 본인이 설명할 수 있는 범위인지를 본다.

학사 채용의 현실부터 정확히 보자

회로설계 직무는 전통적으로 석사 비중이 높은 분야다. 연구실 프로젝트를 거친 석사 졸업자는 특정 주제를 2년간 파고든 경험이 있고, 회사는 그 경험을 실무 투입 속도로 환산한다. 학사 졸업자가 같은 포지션에 지원하는 구조 자체가 불리하다는 점은 부정할 필요가 없다. 전략은 이 불리함을 인정한 위에서 세워야 한다.

그렇다고 학사에게 문이 닫혀 있는 것은 아니다. 회사 입장에서도 모든 설계 인력을 석사로 채울 수는 없고, 특히 디지털 설계와 검증이 맞물린 영역, FPGA 프로토타이핑, SoC integration처럼 넓게 보고 빠르게 실행하는 역할에서는 학사 채용이 꾸준히 일어난다. 중소 팹리스와 설계 서비스 회사까지 범위를 넓히면 학사 채용 비중은 더 커진다.

핵심은 학사와 석사를 같은 기준으로 비교하는 전형에서 정면 승부를 피하는 것이다. 학사 지원자가 이기는 방식은 '석사만큼 깊이 판 주제 하나'와 '신입답지 않은 완성도의 결과물' 조합이다. 둘 다 없으면 서류 단계에서 걸러지고, 하나라도 확실하면 면접까지는 간다. 면접에서 마지막으로 가르는 것이 바로 이 글의 주제인 architecture 이해다.

RTL 코딩만 잘하면 부족한 이유

Verilog 문법을 알고, 주어진 timing diagram대로 모듈을 구현하고, 간단한 testbench로 확인하는 능력은 출발점이다. 문제는 실무 설계가 '주어진 대로 구현하기'가 아니라는 데 있다. 실무에서는 스펙 자체가 불완전하고, 구현 방법은 여러 개이며, 그중 하나를 골라야 하는 이유가 면적, 전력, 타이밍, 검증 난이도, 일정에 흩어져 있다.

예를 들어 FIFO 하나를 설계한다고 하자. 코딩만 하는 지원자는 write와 read pointer를 만들고 full과 empty를 계산하면 끝낸다. Architecture를 이해하는 지원자는 다르다. 동기 FIFO인지 비동기 FIFO인지부터 묻고, 비동기라면 clock domain crossing을 어떻게 처리할지, Gray code pointer를 왜 쓰는지, fall-through 여부가 상위 블록 latency에 어떤 영향을 주는지를 설명한다. 면접관은 이 차이에서 '이 사람을 실무에 넣으면 어떤 질문을 들고 올 사람인가'를 판단한다.

또 하나의 차이는 디버깅에서 드러난다. 코딩 중심 지원자는 코드가 틀렸다고 생각하면 코드를 고친다. Architecture 중심 지원자는 먼저 스펙 해석이 틀렸는지, interface 가정이 틀렸는지, 타이밍 가정이 틀렸는지를 나눠서 본다. 실무 버그의 상당수는 코드 라인 자체가 아니라 가정에서 발생하기 때문에, 이 사고방식이 신입의 성장 속도를 결정한다.

결국 RTL 코딩은 글을 쓰는 능력에 가깝고, architecture 이해는 무엇을 쓸지를 정하는 능력에 가깝다. 회사는 문장력이 좋은 신입보다, 판단의 재료가 많은 신입을 오래 끌고 갈 수 있다고 본다.

면접관이 말하는 architecture 이해란 무엇인가

Architecture 이해는 거창한 논문 수준의 지식이 아니다. 채용 현장에서 확인하는 수준은 의외로 구체적이다.

첫째, block diagram을 그릴 수 있는가. 본인이 만든 설계를 박스와 화살표로 그리고, 각 블록의 역할과 데이터 흐름을 막힘없이 설명할 수 있어야 한다. 그림을 못 그리는 설계는 본인도 구조를 잡지 못한 설계일 가능성이 높다.

둘째, trade-off를 말할 수 있는가. Pipeline stage를 늘리면 frequency는 올라가지만 latency와 면적이 늘어난다. Memory를 register로 구현하면 빠르지만 면적이 커진다. 이런 기본 trade-off를 본인 프로젝트 숫자와 연결해서 말할 수 있어야 한다. 교과서 문장을 외운 것과 본인 설계에서 겪은 것은 면접에서 바로 구분된다.

셋째, interface를 먼저 생각하는가. 모듈 내부 구현보다 먼저 포트, protocol, handshake, backpressure를 어떻게 정의했는지를 묻는 질문에 답할 수 있어야 한다. SoC는 결국 블록 사이의 연결에서 무너지기 때문에, 신입에게도 interface 감각은 중요한 평가 항목이다.

넷째, 검증 관점이 있는가. 본인 설계를 어떻게 검증했는지, 어떤 corner case를 노렸는지, coverage를 어떻게 판단했는지를 설명할 수 있으면 architecture 이해의 신뢰도가 올라간다. 검증을 생각하지 않는 설계자는 실무에서 DV 조직이 가장 힘들어하는 유형이기 때문이다.

대학원 연구실 경험, 이른바 '결'이 왜 언급되는가

채용 과정에서 연구실 경험이 높게 평가되는 이유는 학위 자체보다 그 경험이 만드는 작업 습관 때문이다. 연구실 프로젝트를 거친 사람은 대체로 세 가지를 갖고 있다. 불완전한 스펙에서 문제를 정의해 본 경험, 수개월 단위로 하나의 주제를 끌고 간 경험, 그리고 결과를 문서와 발표로 정리한 경험이다.

학사 졸업자에게 필요한 것은 학위가 아니라 이 습관의 증거다. 학부 연구생, 장기 프로젝트, 인턴, 개인 프로젝트 중 무엇이든 좋다. 단기간에 끝낸 토이 프로젝트 여러 개보다, 하나의 주제를 몇 달간 붙잡고 구조를 바꿔 가며 완성한 프로젝트 하나가 연구실 경험에 가까운 신호를 준다.

반대로 주의할 점도 있다. 연구실 주제가 채용 포지션과 너무 동떨어져 있으면 깊이가 있어도 연결이 약하다. 메모리 컨트롤러를 판 경험은 대부분의 디지털 설계 포지션에 연결되지만, 매우 특수한 아날로그 IP나 특정 논문 재현에만 머문 경험은 범용 포지션에서 설득력이 떨어질 수 있다. 주제 선택 단계부터 채용 시장과의 연결을 의식해야 한다.

학부 연구생 기회가 없다면 공개 스펙을 활용한 장기 프로젝트로 대체할 수 있다. RISC-V 코어의 일부를 구현하거나, AXI interface를 갖춘 accelerator를 설계하고 FPGA에서 동작까지 확인하는 형태가 대표적이다. 중요한 것은 기간과 완성도, 그리고 결정 기록이다.

포트폴리오는 코드 저장소가 아니라 결정의 기록이다

많은 지원자가 포트폴리오를 GitHub 링크 하나로 끝낸다. 코드만 있는 저장소는 면접관에게 거의 정보를 주지 않는다. 면접관은 코드를 전부 읽지 않는다. 읽는 것은 README와 설계 문서다.

좋은 포트폴리오의 구조는 단순하다. 무엇을 만들었는지 한 문단, 전체 block diagram 한 장, 핵심 설계 결정 서너 개와 그 이유, 검증 방법과 결과, 그리고 한계와 다음 개선점. 이 구조가 있으면 면접은 자연스럽게 본인이 가장 잘 설명할 수 있는 주제로 흘러간다. 면접 질문을 본인에게 유리하게 설계하는 것이 포트폴리오의 진짜 기능이다.

포트폴리오에서 피해야 할 것도 분명하다. 본인이 설명할 수 없는 남의 코드를 가져다 쓴 프로젝트, AI 도구가 생성한 코드를 이해 없이 붙인 프로젝트, 동작 확인 없이 코드만 있는 프로젝트. 세 가지 모두 면접의 꼬리 질문 두세 개면 드러난다. 양을 줄이고 본인이 완전히 설명할 수 있는 것만 남기는 것이 원칙이다.

학사 지원자의 현실적인 준비 순서

준비 기간이 6개월이라면 순서가 중요하다. 첫 2개월은 디지털 논리와 컴퓨터 구조의 기초를 프로젝트와 연결하며 다지는 기간이다. 교과서를 다시 읽는 것이 아니라, FIFO와 arbiter와 간단한 FSM 기반 datapath를 직접 구현하면서 개념을 손에 붙이는 방식이 효율적이다.

다음 3개월은 대표 프로젝트 하나에 집중한다. 주제는 너무 크지 않게 잡아야 한다. 완성하지 못한 거대한 프로젝트보다, 검증까지 끝낸 중간 규모의 프로젝트가 훨씬 강하다. 이 기간에 설계 문서를 코드와 동시에 써야 한다. 나중에 몰아서 쓰는 문서는 결정의 이유가 사라진 뒤의 기록이라 설득력이 약하다.

마지막 1개월은 면접 대비다. 본인 프로젝트를 5분, 15분, 30분 길이로 설명하는 연습을 하고, 꼬리 질문을 예상해서 trade-off와 한계를 정리한다. 동시에 지원 회사의 제품과 interface 표준 정도는 파악해 두어야 한다. 회사가 쓰는 bus protocol과 제품군을 모르고 면접에 들어가면 준비 부족으로 읽힌다.

이 순서를 지키면 RTL 코딩 실력은 프로젝트 안에서 자연스럽게 는다. 반대로 코딩 문제 풀이에만 시간을 쓰면, 면접의 절반을 차지하는 프로젝트 심층 질문에서 무너진다.

FAQ

Q1. 학사인데 석사 진학과 취업 중 무엇을 먼저 고려해야 하나요? 설계 직무 중에서도 특정 분야를 깊게 파는 커리어를 원한다면 석사의 가치는 여전히 크다. 반면 빨리 실무에 들어가 넓게 배우는 쪽이 맞다면 취업 후 경력으로 승부할 수 있다. 결정 기준은 학위 선호가 아니라, 본인이 원하는 설계 분야가 학위를 사실상 요구하는 분야인지부터 확인하는 것이다.

Q2. Verilog와 SystemVerilog 중 무엇을 먼저 익혀야 하나요? 설계 지원자라면 Verilog로 합성 가능한 코딩 스타일을 먼저 몸에 붙이고, SystemVerilog의 interface, always_ff와 always_comb, package 같은 설계 친화 기능을 이어서 익히는 순서가 좋다. 검증용 문법을 설계 공부 초반에 깊게 파는 것은 우선순위가 낮다.

Q3. 포트폴리오 프로젝트 주제로 무엇이 좋나요? 채용 시장과 연결되는 표준 주제가 유리하다. AXI를 갖춘 작은 accelerator, DMA, 이미지 처리 pipeline, RISC-V 코어 일부 구현처럼 interface와 datapath와 제어가 모두 들어가는 주제가 architecture 이해를 보여 주기 좋다. 주제보다 완성도와 결정 기록이 더 중요하다.

Q4. 코딩 테스트는 어떻게 준비하나요? 기본 모듈 구현, FSM 설계, timing diagram 해석, 간단한 debugging 문제가 중심이다. 프로젝트 준비와 별개로 주 단위로 짧은 구현 연습을 유지하면 감각이 유지된다. 단 코딩 테스트 준비가 전체 준비 시간을 잠식하면 본말이 전도된다.

Q5. 학부 연구생 경험이 없으면 불리한가요? 출발점은 불리할 수 있지만 대체재는 있다. 몇 달 이상 이어 간 개인 프로젝트에 설계 문서와 검증 기록까지 갖추면 연구실 경험이 주는 신호 상당 부분을 재현할 수 있다. 중요한 것은 경험의 소속이 아니라 기간, 완성도, 기록이다.

행동 체크리스트

• ☐ 지원하려는 포지션이 학사 채용을 실제로 하는지 최근 공고로 확인했다
• ☐ 대표 프로젝트 하나를 정하고 검증까지 포함한 완성 일정을 세웠다
• ☐ 프로젝트의 block diagram과 핵심 설계 결정 이유를 문서로 작성했다
• ☐ FIFO, CDC, pipeline, handshake 같은 기본 주제를 본인 프로젝트와 연결해 설명할 수 있다
• ☐ 포트폴리오에서 설명할 수 없는 코드를 제거하거나 직접 다시 구현했다
• ☐ 프로젝트를 5분과 15분 길이로 설명하는 연습을 마쳤다
• ☐ 지원 회사의 제품군과 주요 interface 표준을 파악했다

함께 읽으면 좋은 글

• 삼성전자·SK하이닉스 회로설계·배치설계·회로검증 직무 차이 총정리 — 공고 해독하는 법

📩 VLSI Korea 뉴스레터 구독하기

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

무료로 구독하기