[리벨리온] Physical Design Engineer - Frontend 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• physical design(RTL to GDS)을 구현해 최적의 PPA를 달성합니다.

  이렇게 볼 수 있어요

  Frontend 공고인데도 첫 업무의 목표는 RTL에서 GDS까지 흐름 전체에서 최적의 PPA를 내는 것입니다. 합성 단계에서 내린 결정이 배치·배선 뒤 성능, 전력, 면적 결과로 어떻게 이어졌는지를 블록 단위 수치로 보여 주는 것이 좋습니다.

• physical-awareness를 적용하거나 적용하지 않은 logic synthesis, clock-gating 삽입, 새 아키텍처에 대한 feasibility check를 수행합니다.

  이렇게 볼 수 있어요

  배치 정보를 반영하지 않는 합성과 반영하는 합성이 둘 다 적혀 있습니다. 어떤 블록에서 왜 그 방식을 골랐는지, 설계 초기에 합성 결과로 새 구조의 타이밍과 면적을 미리 따져 본 일이 있었는지를 경력기술서에 구체적으로 풀어 씁니다.

• logic equivalence를 확인하고 FECO(function ECO)를 수행합니다.

  이렇게 볼 수 있어요

  netlist가 바뀔 때마다 원래 RTL과 기능이 같은지 확인하는 일과 기능 수정을 netlist에 직접 반영하는 일이 한 항목에 묶여 있습니다. 테이프아웃을 앞두고 처리한 FECO의 횟수와 규모를 밝히면 이 업무를 해 본 정도가 바로 드러납니다.

• STA와 simulation으로 로직과 전체 설계를 최적화합니다.

  이렇게 볼 수 있어요

  타이밍 분석이 확인 수단이 아니라 최적화 수단으로 적혀 있습니다. STA 결과를 보고 로직 구조를 바꿔 critical path를 줄인 사례가 이 업무와 가까운 경험입니다.

• logic DR(design rule) 수정을 포함해 setup/hold timing sign-off를 관리합니다.

  이렇게 볼 수 있어요

  이 자리가 timing sign-off까지 책임집니다. sign-off를 맡았던 칩이나 블록이 있다면 공정과 목표 주파수를 함께 밝혀야 맡은 범위가 분명해집니다.

• 전력 소모를 추정하고 PVT 조정을 포함해 PPA 최적화를 합니다.

  이렇게 볼 수 있어요

  전력이 추정 단계부터 업무로 따로 적혀 있습니다. 합성 단계의 전력 추정값과 sign-off 값의 차이를 줄이려고 조건을 바꿔 본 경험이 있다면 숫자로 보여 줄 수 있습니다.

• 논리적 관점에서 design QoR(quality of result)을 높일 아키텍처 변경을 제안합니다.

  이렇게 볼 수 있어요

  같은 제안을 Backend 공고는 물리적 관점에서, 이 공고는 논리적 관점에서 한다고 적었습니다. 합성 결과를 근거로 RTL 설계자에게 구조 변경을 제안해 설계가 바뀐 일이 있다면 제안부터 반영까지의 과정을 순서대로 쓰면 됩니다.

• DSP와 contractor가 TAT를 맞추면서 높은 품질의 결과를 내도록 지원합니다.

  이렇게 볼 수 있어요

  구현의 일부를 외부 파트너가 맡고 이 직무가 그 결과물의 일정과 품질을 함께 챙깁니다. 외부 인력과 일정을 맞추고 산출물을 검토해 본 경험은 협력사 수와 기간을 붙여 적으면 규모가 드러납니다.

2자격 요건

• Electrical Engineering 학사 이상 또는 그에 준하는 실무 경험이 필요합니다.

  이렇게 볼 수 있어요

  학위 요건 옆에 실무 경험이 대안으로 함께 적혀 있습니다. 전공이 다르다면 물리 설계 프로젝트를 맡은 기간과 내용으로 그 실무 경험을 설명합니다.

• 반도체 업계에서 EDA tool workflow를 다룬 경력이 최소 8년 필요합니다.

  이렇게 볼 수 있어요

  주요 업무의 합성, STA, ECO, 전력 추정은 모두 EDA 도구로 하는 일입니다. 다뤄 온 공정과 도구, 구현한 칩의 수를 적으면 8년 동안 무엇을 했는지 구체적으로 보여 줄 수 있습니다.

• 워크플로 자동화와 데이터 시각화를 위한 scripting language(Tcl, Perl, Python 등)에 능숙해야 합니다.

  이렇게 볼 수 있어요

  스크립트의 용도가 자동화와 시각화 두 가지로 적혀 있습니다. 합성이나 STA 결과를 실행마다 모아 비교하는 스크립트를 만든 적이 있다면 두 용도에 모두 맞는 경험입니다.

• RTL to GDS 흐름을 자동화하는 physical design 프로세스와 도구 경험이 풍부해야 합니다.

  이렇게 볼 수 있어요

  Frontend 공고에서도 RTL to GDS 흐름 전체의 자동화를 요구합니다. 합성 단계만이 아니라 뒤 단계로 넘기는 흐름까지 스크립트로 묶어 본 경험이 있다면 그 범위를 밝히는 게 좋습니다.

• ECO 과정의 In-Place-Optimization을 깊이 이해해야 합니다.

  이렇게 볼 수 있어요

  In-Place-Optimization은 배치를 다시 하지 않고 셀 크기나 버퍼를 바꿔 타이밍을 맞추는 방식입니다. 업무의 FECO와 timing sign-off 막바지에 남은 위반을 이 방식으로 정리한 경험을 이 요건의 사례로 들 수 있습니다.

• physical implementation에서 한 가지 이상의 영역을 리드한 경험이 필요합니다.

  이렇게 볼 수 있어요

  전체를 이끈 경험이 아니라 한 영역이라도 이끈 경험을 묻습니다. 합성 방법론이나 STA sign-off 기준처럼 직접 정해 팀이 따른 것이 있다면 리드 경험으로 내세울 수 있습니다.

• design parameter를 추출하고 QoR(Quality of Results)를 요약하며 추이를 분석해 QoR를 개선한 경험이 필요합니다.

  이렇게 볼 수 있어요

  결과를 데이터로 모으고 흐름을 본 뒤 개선 방향을 정하는 일입니다. 실행마다 타이밍, 면적, 전력 지표를 어떤 형태로 모아 비교했고 그 비교로 무엇을 바꿨는지를 예로 들 수 있습니다.

4기타 사항

• 게시일 : 2026년 1월 28일
• 고용형태 : 해당 내용은 원본 공고에서 확인되지 않습니다.
• 근무지 : 경기도 성남시 분당구 정자일로156번길 6
• 경력 조건 : 경력 8년 이상
• 학력 조건 : Bachelor's or higher degree in Electrical Engineering or equivalent practical experience

쓰는 기술

공고 본문에 적힌 기술만 모은 목록입니다.

• Tcl
• Perl
• Python
• STA
• FECO
• PVT

전형과 지원

분석 시점 공고 42건 가운데 27건이 같은 여섯 단계를 적었습니다. Software와 System Software 공고는 전부 과제나 코딩테스트를 더했고, System Software 공고 9건 가운데 8건은 평판 조회도 거칩니다. 지원할 공고의 전형절차를 본문에서 따로 확인하는 편이 안전합니다.

지원 전 준비할 것

1. 1

   합성 결과를 블록별로 정리하기

   최근 맡은 블록 두세 개의 공정, 목표 주파수, 합성 뒤 면적과 전력, sign-off까지의 timing 결과를 표로 만들어 두면 'best PPA'와 QoR 추이를 묻는 질문에 같은 자료로 답할 수 있습니다.

2. 2

   FECO 사례 하나 고르기

   logic equivalence check와 FECO가 업무에, In-Place-Optimization이 자격 요건에 있습니다. 테이프아웃을 앞두고 처리한 ECO 하나를 골라 바뀐 기능, 확인 방법, 정리한 위반을 순서대로 설명할 수 있게 준비합니다.

3. 3

   자동화·시각화 스크립트 고르기

   Tcl, Perl, Python 가운데 주로 쓴 언어로 만든 스크립트 하나를 골라 무엇을 자동화했고 어떤 지표를 한 화면에 모았는지, 그 덕에 줄어든 반복 시간이 얼마인지 정리합니다.