면접에서 전 직장 기술 어디까지 말할까: NDA를 지키면서 성과는 선명하게 만드는 6단계 프레임

핵심 결론 면접에서 말하면 안 되는 것은 회로도, 코드, 수치가 아니라 비밀 그 자체이며, 말해야 하는 것은 문제의 구조, 본인의 판단, 검증 방법이다. 성과 스토리는 "무엇을 만들었는가"가 아니라 "어떤 조건에서 어떤 트레이드오프를 어떻게 결정했는가"로 말할 때 NDA를 위반하지 않으면서도 실력이 드러난다. 아래 6단계 프레임으로 준비하면 민감한 프로젝트도 안전하게, 그러나 얇지 않게 설명할 수 있다.

면접관이 정말 듣고 싶은 것은 비밀 정보가 아니다

반도체, EDA, 설계 검증 면접에서 지원자가 가장 자주 하는 실수는 두 가지로 갈린다. 하나는 NDA가 걱정되어 모든 답을 "자세히 말씀드리기 어렵습니다"로 끝내는 경우다. 다른 하나는 반대로 공정 노드, 블록 이름, 내부 툴 플로우, 고객사 이름, 미공개 성능 수치를 그대로 말해 버리는 경우다. 두 경우 모두 탈락 사유가 된다. 전자는 실력을 증명하지 못했고, 후자는 이 회사에 와서도 같은 방식으로 말할 사람이라는 신호를 주기 때문이다.

면접관의 평가 포인트는 명확하다. 첫째, 이 사람이 실제로 어려운 문제를 끝까지 소유해 본 적이 있는가. 둘째, 문제를 구조화하고 가설을 세우고 검증하는 방식이 재현 가능한가. 셋째, 비밀 유지 의무를 이해하고 경계를 스스로 설정할 수 있는가. 이 세 가지는 비밀 수치를 말하지 않아도 충분히 증명할 수 있다. 오히려 수치를 말하지 않고도 설득하는 지원자가 더 신뢰를 얻는다.

특히 STA, Physical Design, DFT, 검증처럼 고객 프로젝트와 PDK, 라이브러리 정보가 얽힌 직무에서는 경계 설정 능력 자체가 직무 역량이다. 면접에서 경계를 설명하는 행위 자체가 실무 감각을 보여 준다.

말할 수 있는 것과 말하면 안 되는 것의 경계

경계는 "공개 여부"와 "식별 가능성" 두 축으로 나누면 단순해진다. 이미 논문, 특허, 학회 발표, 제품 페이지, 채용 공고 등으로 공개된 정보는 출처를 전제로 말할 수 있다. 반대로 미공개 프로젝트명, 고객사명, 내부 코드명, 정확한 일정과 수율, 회로 토폴로지의 세부 파라미터, 소스 코드와 스크립트 원문, PDK의 비공개 수치, 아직 출시되지 않은 제품의 스펙은 말하지 않는다.

애매한 영역이 가장 중요하다. 예를 들어 "7nm급 공정에서 대용량 SRAM이 포함된 SoC의 signoff를 담당했다" 수준의 일반화는 보통 허용 범위로 본다. 반면 노드, 업체, 제품군을 조합하면 특정 프로젝트가 식별되는 경우에는 한 단계 더 추상화해야 한다. "선단 공정", "모바일 AP급 복잡도", "수억 게이트 규모"처럼 규모감은 주되 식별자는 제거하는 방식이다. 수치도 마찬가지다. 절대값 대신 비율과 방향으로 말한다. "클록을 1.83GHz에서 2.1GHz로 올렸다"가 아니라 "목표 주파수 대비 부족했던 마진을 두 자릿수 퍼센트 수준으로 회복했다"처럼 표현하면 성과는 전달되고 비밀은 지켜진다.

면접관이 민감한 정보를 직접 캐묻는 경우도 있다. 이때는 거절로 끝내지 말고 대체 설명을 제공해야 한다. "그 수치는 말씀드릴 수 없지만, 당시 의사결정 기준은 이랬습니다"라고 전환하면 평가가 끊기지 않는다. 경계는 지키고 대화는 이어 가는 것이 핵심 기술이다.

성과 스토리를 만드는 6단계 프레임

아래 프레임은 어떤 프로젝트에도 적용할 수 있다. 각 단계를 한두 문장으로 준비해 두면 3분 버전과 10분 버전으로 길이를 조절할 수 있다.

1단계 — 맥락(Context): 어떤 종류의 제품, 어떤 단계였는지를 일반화해서 말한다. 예: "양산을 앞둔 단계에서 signoff 품질이 전체 일정에 영향을 주는 상황이었습니다." 고객명과 코드명은 넣지 않는다.

2단계 — 문제(Problem): 관찰된 현상을 측정 가능한 형태로 정의한다. "타이밍이 나빴다"가 아니라 "특정 corner에서 setup margin이 부족하고, 원인이 clock skew인지 cell delay인지 분리되지 않은 상태였다"처럼 말한다. 문제를 잘 정의한 경험은 그 자체로 실력이다.

3단계 — 가설과 분리(Hypothesis): 원인을 나누어 검증한 방식을 말한다. 어떤 리포트를 봤고, 어떤 변수를 고정했고, 어떤 비교 실험을 했는지를 설명한다. 이 단계에서 툴 이름 자체보다 분석 절차가 중요하다. 상용 툴의 일반 기능은 공개 정보이지만, 사내 전용 스크립트와 플로우의 세부 구현은 말하지 않는다.

4단계 — 본인의 결정(Decision): 대안 두세 개와 선택 이유를 말한다. 면접관은 정답보다 트레이드오프를 본다. 면적을 더 쓰는 대신 경로를 우회했는지, 전력을 감수하고 버퍼를 추가했는지, 일정상 ECO 범위를 제한했는지 같은 판단이 핵심이다. "팀이 결정했다"로 뭉개지 말고 본인이 주장한 부분과 그 근거를 분리한다.

5단계 — 검증(Validation): 결정이 맞았음을 어떻게 확인했는지를 말한다. 재현 조건, corner와 mode의 범위, 회귀 테스트, 리뷰 절차를 언급한다. 반도체 업무에서는 결과를 냈다는 말보다 검증 범위를 말하는 쪽이 훨씬 신뢰도가 높다.

6단계 — 결과와 회고(Result & Lesson): 결과는 비율과 정성적 변화로, 회고는 다음에 바꿀 점으로 마무리한다. "이후 같은 유형의 문제는 체크리스트로 만들어 초기에 잡도록 했다" 같은 문장이면 충분하다. 성과를 과장하지 않아도 학습이 남는 스토리가 된다.

직무별로 달라지는 민감도

같은 프레임이라도 직무마다 특히 조심할 지점이 다르다. RTL 설계자는 마이크로아키텍처의 독창적인 부분과 미공개 기능명을 피하고, 인터페이스와 검증 관점으로 스토리를 옮기는 것이 안전하다. Physical Design과 STA 담당자는 PDK, 라이브러리, 고객 플로우가 민감하므로 수치 대신 방법론을 말한다. DFT 담당자는 테스트 커버리지의 절대값보다 구조적 한계와 해결 방식을, 검증 담당자는 미공개 버그의 제품 영향도보다 버그를 찾기까지의 가설 수립 과정을 강조한다.

EDA 툴을 다루는 직무는 또 다르다. 툴의 공개된 명령어와 일반적인 사용법은 말할 수 있지만, 고객사에서 본 디자인 데이터, 내부 재현 케이스, 버그 리포트의 원문은 말할 수 없다. "특정 고객 디자인에서..."로 시작하는 문장은 거의 항상 위험하다. "대규모 계층 구조 디자인에서 메모리 사용량이 급증하는 패턴을..."처럼 패턴으로 추상화해야 한다.

이직 면접뿐 아니라 학회 발표 준비, 포트폴리오 작성, 이력서 bullet을 쓸 때도 같은 기준을 적용한다. 이력서에는 스토리의 1, 2, 6단계만 압축해서 넣고, 3~5단계는 면접에서 구두로 푼다는 원칙을 세우면 문서 유출 리스크도 함께 줄어든다.

자주 나오는 압박 질문에 답하는 법

"구체적인 수치를 말해 줄 수 없나요?"라는 질문에는 "정확한 수치는 말씀드릴 수 없지만, 개선 전후의 상대적인 변화와 그 변화를 만든 방법은 설명할 수 있습니다"로 답한다. "어떤 고객사 프로젝트였나요?"에는 "고객명은 말씀드릴 수 없고, 디자인 규모와 복잡도는 이 정도였습니다"로 대체 정보를 제공한다. "그 스크립트를 직접 보여 줄 수 있나요?"에는 단호하게 아니라고 하되, "대신 스크립트가 수행하던 검증 논리를 순서도로 설명할 수 있습니다"로 전환한다.

중요한 것은 태도다. 주저하거나 과도하게 사과하면 오히려 의심을 산다. 경계를 미리 정해 둔 사람은 짧고 calm하게 답한다. 면접 전에 본인 스토리의 금지 단어 목록을 만들어 두면 현장에서 실수할 확률이 크게 줄어든다. 프로젝트명, 고객명, 내부 툴의 사내 명칭, 정확한 노드와 일정이 그 목록의 기본 항목이다.

반대로 면접관에게 질문할 때도 같은 감각이 드러난다. 새 회사의 비밀 정보를 캐묻는 질문은 피하고, 직무의 문제 유형과 검증 문화, 툴 환경의 공개 가능한 범위를 묻는 것이 좋다. 경계를 지키는 사람은 질문에서도 드러난다.

FAQ

Q1. 이력서에 전 직장 프로젝트 이름을 그대로 써도 되나요? 공개된 제품명이나 논문·특허로 이미 알려진 범위라면 쓸 수 있지만, 코드명과 미공개 프로젝트명은 쓰지 않는 것이 원칙이다. 제품군과 역할 중심으로 쓰고, 식별 가능한 조합은 피한다.

Q2. 포트폴리오에 캡처나 코드 일부를 넣으면 설득력이 올라가지 않나요? 올라갈 수 있지만 리스크가 훨씬 크다. 사내 자료의 캡처와 코드는 소유권이 회사에 있는 경우가 대부분이다. 대신 본인이 새로 만든 예제 코드와 공개 데이터로 같은 역량을 보여 주는 대체 포트폴리오가 안전하다.

Q3. 면접관이 계속 구체적인 수치를 요구하면 어떻게 하나요? 경계를 한 번 명확히 말하고 대체 설명을 제공한다. 반복 요구에도 같은 톤을 유지한다. 이 상황 자체가 비밀 유지 역량을 평가하는 과정일 수 있다.

Q4. 이미 공개된 학회 논문에 참여한 내용은 말해도 되나요? 공개된 논문의 범위 안에서는 본인의 기여를 말할 수 있다. 단, 논문에 없는 후속 수치나 내부 버전의 개선 사항까지 확장해서 말하지 않는다.

Q5. 경력 초반이라 스토리가 작아 보이면 어떻게 하나요? 규모를 부풀리지 말고 문제 정의와 검증 범위를 구체화한다. 작은 블록이라도 가설 분리 과정이 선명하면 스토리는 충분히 강해진다.

행동 체크리스트

• ☐ 주요 성과 3개를 골라 6단계 프레임으로 각각 한 페이지씩 써 본다
• ☐ 스토리마다 금지 단어 목록(프로젝트명, 고객명, 코드명, 민감 수치)을 따로 적는다
• ☐ 모든 절대 수치를 비율, 범위, 방향 표현으로 바꿔 둔다
• ☐ 3분 버전과 10분 버전을 소리 내어 연습하고 시간을 잰다
• ☐ 압박 질문 3종에 대한 전환 문장을 미리 만들어 둔다
• ☐ 이력서에는 1·2·6단계만 넣고 세부 방법은 구두 설명으로 남긴다
• ☐ 면접 후 말한 내용을 복기해 경계를 넘은 표현이 없었는지 점검한다

📩 VLSI Korea 뉴스레터 구독하기

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

무료로 구독하기