출처: 타직무(HW 생산기술/반도체 설계) 지원자의 「LIG 2차 면접 Q&A 전체정리」 PDF를
SW 공통 / 미사일시스템(판교) 신입 학사 관점으로 재구성한 문서.
- 빼낸 것: HW 생산기술 직무 고유 질문, 반도체 회로 기술 답변(SAR ADC·PLL·BGR/LDO·Cadence 등)
- 남긴 것: 자기소개·지원동기·인성·협업·보안·압박질문 등 직무 무관 공통 질문 + 제품 지식
- 포인트: 각 질문마다 “이런 축으로 말하라”는 방향성만. 실제 사례·수치는 본인 SW 프로젝트로 채울 것 →
[내 프로젝트] 표시
HW 지원자는 모든 답을 데이터→블록→시스템 / 원인 재현·기준화로 돌렸습니다.
SW 지원자인 나는 아래 5개 축으로 모든 답을 돌리면 됩니다.
| 답변 축 (SW) | 사용 질문 |
|---|
| 요구사항 → 설계 → 구현 → 검증(V&V) 으로 신뢰성 보장 | 자기소개, PR, 왜 SW, 직무 적합성 |
| 버그/이슈를 재현 가능하게 만들고 테스트로 고정(회귀방지) | 실패, 실수, 문제해결, 핵심역량 |
| 실시간·안전 제약(타이밍·메모리·고장 시 안전) 안에서 동작 보장 | 방산 SW가 왜 특별한가, 무기체계 |
| 감정보다 데이터·로그·이슈트래커 같은 공통 근거로 협업 | 갈등, 상사, 협업, 타직무와 마찰 |
| 동작뿐 아니라 왜 그렇게 동작하는지 설명·기록(추적성) | 좋은 개발자란, 10년 후, 가치관 |
가장 안전한 메인 문장 (외워둘 것):
“저는 코드가 ‘돌아간다’에서 멈추지 않고, 요구사항부터 검증까지 추적 가능하게 만들고
문제는 재현·테스트로 고정해 신뢰성을 남기는 개발자입니다.
이 방식이 한 번의 오류도 허용되지 않는 방산 무기체계 SW에서 가장 직접적으로 기여할 수 있다고 생각합니다.”
| Q 질문 | 방향성 포인트 (SW) |
|---|
| 자기소개 해주세요 | [내 전공/계기] → SW 핵심 경험 1개 → 신뢰성/검증 중시 개발자로 30초 흐름. 마지막 단어는 “방산 SW 신뢰성” |
| 영어로 자기소개 / 영어 가능? | 길게 말 필요 없음. 짧고 또박또박 + “꾸준히 학습 중”(toeic/opic 등 계획) 한 줄이면 충분 |
| 2분 정도 마음껏 PR | ① 평소 모습(책임감·꼼꼼) ② 일할 때 모습 ③ 성과(학점/수상/프로젝트) ④ 기대효과 — 4블록 |
| 자기소개 임팩트 있게 | ”동작만 시키는 게 아니라 왜 동작하는지·언제 깨지는지까지 보는 개발자” 한 문장 훅 |
| 본인을 한 문장으로 | ”문제를 감으로 넘기지 않고 재현·검증으로 끝까지 추적하는 SW 엔지니어” |
| 마지막으로 하고 싶은 말 | 면접관 감사 + “방산 SW는 신뢰성이 생명, 장기적으로 신뢰받는 개발자로 성장하고 싶다” |
| 왜 뽑아야 하나 | 거짓 못함/규칙엔 엄격 + 검증·문서화 습관 = 방산 SW 적합성으로 마무리 |
| Q 질문 | 방향성 포인트 (SW) |
|---|
| 지원동기 | ”LIG D&A = 유도무기·레이다·전자전 등 SW가 두뇌인 체계” → 실시간·신뢰성 SW에 끌림 → 직무 적합 |
| 왜 방산인가요? | 일반 IT는 빠른 출시·재배포가 핵심, 방산 SW는 한 번에 정확·안전이 핵심 → 그 책임감에 끌림 |
| 왜 LIG D&A인가요? | 유도무기 중심 → 레이다·전자전·무인체계로 확장 → 체계종합 SW 역량이 모두 성장 중 |
| 다른 방산사 말고 LIG인 이유? | 한화=추진/우주·엔진, 현대로템=지상/기동 / LIG=유도·레이다·전자전·무인 등 신호·체계 SW 중심 → 내 관심과 일치 |
| 왜 SW 직무인가요? | (왜 다른 직무 아님) “하드웨어가 아니라 무기체계의 판단·제어·유도 로직을 만드는 일에 흥미” |
| 미사일시스템(판교) 왜? | 유도무기 탑재 SW / 비행제어 / 유도·항법 알고리즘 / HILS·시뮬레이션에 직접 기여하고 싶다 |
| 회사 선택 기준은? | ”오래 성장 가능한 기술 방향성 + 내 강점(검증·문제분석)이 실제로 쓰이는 환경” |
| 최근 인상 깊은 LIG 뉴스? | AI 기반 무인기·유무인 복합체계 / 해외 MRO·수출 / 항공우주·위성 확장 중 하나 → “SW 비중이 커지는 흐름” 연결 |
| 방위산업의 역할은? | 국가 안보의 기술적 기반·전쟁 억제력 → 그 중심에 신뢰 가능한 SW 비중 증가 |
| 무기개발 윤리성에 대해 | 무기는 공격수단 아니라 방어력 → 개발자는 안전·정확·통제 가능성을 높이는 게 책임 (SW가 그 통제의 핵심) |
⚠️ 뉴스/제품 최신 동향은 면접 전 1회 업데이트 필요 (Shield AI 드론, MRO 거점, 항공우주·위성 등).
PDF의 3번은 HW 생산기술 전용이라 질문 틀만 빌리고 답은 SW로 새로 작성. 본인 직무공고(SW공통/미사일시스템) 키워드로 확정할 것.
| Q 질문 | 방향성 포인트 (SW) |
|---|
| (이 직무가) 하는 일을 설명해보세요 | 무기체계 탑재/제어/신호처리/지휘통제 SW를 요구사항부터 설계·구현·**검증(V&V)**까지. 실시간·임베디드 환경 |
| 직무 핵심 역량은? | ① 요구사항 추적성 ② 실시간/임베디드 제약 이해 ③ 테스트·검증 ④ 협업·형상관리 |
| 본인이 이 직무에서 잘할 수 있는 것은? | [내 SW 프로젝트]의 문제분석·디버깅·검증 경험 → 재현 가능한 개선으로 연결 |
| 방산 SW의 특징은? | 단기 기능보다 장기 신뢰성·안전성. 고장 시 안전(fail-safe), 형상관리, 인증/규격(MISRA 등) 중요 |
| 어떤 업무를 하고 싶나요? | (직무공고 기반) 탑재SW/비행제어/HILS·시뮬레이션/통합시험 중 본인 관심 1개 + 이유 |
| 입사 후 가장 먼저 배우고 싶은 것 | 실제 개발 프로세스(요구사항관리·형상관리·검증절차)와 도메인 지식 |
| 입사 후 근무/원라이프 계획 | 근미래: 기본기+도메인 학습 / 원미래: 시스템 신뢰성·검증 자동화 전문가 |
| 10년 뒤 모습은? | ”후배가 참고할 기준을 만드는 SW 엔지니어 — 검증·문서로 반복 가능하게” |
| 좋은 개발자란? | 결과만 내는 사람이 아니라 왜 그렇게 동작하는지 설명·기록할 수 있는 사람 |
| 야근/긴급 대응 괜찮나요? | 방산 SW는 책임감·즉시 대응 필요. 단, 무작정 버티기보다 원인·우선순위·회귀방지 남기는 대응 |
| 출장/지방 근무 괜찮나요? | 통합시험·현장(시험장)은 SW도 직접 확인 필요 → 적극적으로 수행 가능, 성장 기반 |
| 품질/다른 직무로 배치된다면? | 핵심은 제품 신뢰성 → 어디든 검증·테스트 역량 활용 가능, 조직 필요에 맞춰 수행 |
| 방산은 보수적인데 괜찮나요? | 보수성 = 신뢰성·안전을 위한 절차 → 정확한 검증·기준 중시 성향과 맞음 |
깊은 회로 지식 불필요. “이 무기체계에서 SW가 하는 역할”(유도·제어·신호처리·연동) 중심으로 가볍게.
| Q 질문 | 방향성 포인트 (SW) |
|---|
| 관심 있는 무기체계는? | 1개 골라(예: 천궁-II) “레이다·유도탄·교전통제가 결합된 복합 체계 → 그 안의 교전통제/유도 SW가 인상적” |
| 천궁-II 설명 | 중거리 지대공 요격체계. 레이다 탐지→교전통제(SW)→유도탄 발사·유도. LIG 체계종합 핵심 |
| 현궁 설명 | 휴대용 대전차 유도무기, Fire & Forget(발사 후 망각) — 발사 후 미사일이 표적을 스스로 추적하는 유도·영상추적 SW가 핵심 |
| Fire & Forget 방식 설명 | 발사 전 표적 지정 → 발사 후 미사일이 자체 탐색기·알고리즘으로 추적 → 사수 즉시 이탈/은폐 가능 (SW 자율추적) |
| 해궁 / 비궁 / KF-21 전자전 | 해궁=함정 근거리 함대공 / 비궁=2.75인치 유도로켓 / KF-21 전자전=탐지·분석·교란. 공통적으로 신호처리·통제 SW |
| 자신을 무기에 빗대어 | (인성 질문) 예: “현궁처럼 목표 지정되면 끝까지 추적·완수” → 나도 문제 원인 끝까지 추적 |
| 닮은 무기 / 동물? | 가벼운 비유 질문. 한 가지 정해두고 “상황 분석해 도구를 응용” 식으로 |
💡 외울 최소 세트: 천궁-II(지대공), 현궁(대전차·Fire&Forget), 해궁(함대공), 비궁(유도로켓), KF-21 전자전 + 각각 “SW가 하는 일” 한 줄.
| Q 질문 | 방향성 포인트 (SW) |
|---|
| 성격 한 단어로 | ”끈기/꼼꼼” → 원인 끝까지 추적 → [내 디버깅·검증 경험] 연결 |
| 장점 | 끝까지 확인하는 책임감 → 결과 나오면 원인까지 확인 → 신뢰성 SW에 적합 |
| 단점 | ”초반에 혼자 오래 고민” 류 → 정확성 장점이나 속도 보완 중(공유 기준 정해 개선) — 개선 노력까지 세트 |
| 강점 | 계획성·객관적 시각 → 가능한 원인 구조화 → 현실적 일정·목표 기준 접근 |
| MBTI와 특징 | MBTI 자체보다 업무 성향(분석적·계획적·신중)으로 연결, 단점은 보완 노력 |
| 가장 중요한 가치관 | ”맡은 문제는 끝까지 책임” → 신뢰성·검증 직무와 연결 |
| 일할 때 중요하게 보는 것 | ”재현 가능한 결과·신뢰성 — 한 번의 성공보다 반복 가능한 기준” |
| 스트레스 해소법 | 운동/혼자 정리 → 감정 분리 후 다시 차분히 문제 접근 |
| 주말/취미 | 운동·기술 공부 등 → 체력관리·자기정리 습관 강조 |
| 감정적 대응 경험? | 즉시 반응보다 원인·상황 정리 → 감정보다 근거 중심 |
| 하기 싫은 업무 맡으면? | 조직에 필요하면 목적 먼저 이해 → 배우며 책임 수행 → 개선 포인트 찾음 |
| 반복 업무 가능? | 가능 → 반복 속에서 자동화/개선 포인트 발견(테스트 자동화 등) |
| 실수했을 때 | 즉시 인정 → 영향 범위 확인 → 회귀방지 기준화(재발 방지 테스트) |
| 희생했던 경험 | 팀 목표 위해 개인 역할 밖 문제까지 분석 → 성과 연결 ([내 사례]) |
| 일 잘하지만 까칠 vs 못하지만 너글너글 | ”기준 명확하면서 존중하는 사람”이 이상 / 까칠함은 기준으로 조율 가능, 못하는 부분은 교육·분담 |
| Q 질문 | 방향성 포인트 (SW) |
|---|
| 팀원과 갈등 해결 경험 | ”누가 맞나”가 아니라 어디서 기준이 달라졌나로 전환 → 공통 지표(로그·이슈·테스트)로 정렬 ([내 사례]) |
| 협업에서 가장 중요한 점 | 소통 자체보다 소통이 가능해지는 환경(공통 기준·문서·역할 정리) |
| 팀원과 의견 충돌 시 | 감정보다 데이터·기준 → 각자 근거 정리 → 제3 공통 지표 활용 |
| 리더형 vs 팔로워형? | ”상황 따라 기준 정리하는 조율형” → 필요 시 방향 정리, 실행 단계선 책임 수행 |
| 대화 안 통하는 상사면? | 먼저 지시 의도·우선순위 확인 → 중간 결과 공유 → 필요 시 데이터 기반 대안 제시 |
| 상사와 의견 다르면? | 먼저 상사 방향 이해·실행 가능성 검토 → 리스크 있으면 데이터·근거로 조심스럽게 제안 |
| 같이 일하고 싶은/싫은 상사 | 싶은: 기준 명확·피드백 구체적 / 싫은: 무관심한 상사지만 “그래도 적응” 톤 |
| 타직무(HW/시험)와 마찰 시 | 현장·상대 경험 존중 → 내 분석 고집 아니라 실제 현상·데이터로 맞춤 → 공통 목적=품질·납기·신뢰성 |
| 헤드헌터/이직 제안 온다면 | 단기 조건보다 성장 방향·직무 적합성 우선 → LIG에서 신뢰 쌓는 게 먼저, 장기근속 지향 |
PDF 원문 답은 SAR ADC·PLL 등 반도체 내용이라 폐기. 아래 틀에 [내 SW 프로젝트]를 끼워 1~2개 미리 준비.
| Q 질문 | 방향성 포인트 (SW) |
|---|
| 실패 경험은? | 흐름: 초기 잘못된 원인 판단 → 개선 후에도 문제 지속 → 전체(시스템) 관점으로 전환 → 진짜 원인 발견 → 재발방지 |
| 가장 힘들었던 프로젝트는? | 어려움 + 어떻게 분석·검증해 돌파했는지. 결과 수치 1개 |
| 지원서 기반 질문 들어오면 흐름 | 역할 → 목표 → 문제 → 원인 분석 방법 → 사용 도구 → 개선 결과 → SW 직무 연결 6단계 고정 |
| 데이터 분석/AI 경험 있나요? | 있으면: 데이터→모델→검증, “노이즈가 아니라 실제 현상” 식 검증 태도 강조 ([내 사례]) |
| 본인 역할은? / 성과는? | 역할은 구체적 동사로(설계·디버깅·테스트 자동화), 성과는 정량 1개(통과율·시간단축·버그감소) |
| 노이즈/오류를 어떻게 찾았나? | 재현 → 로그/데이터 비교 → 가설·검증 → 라벨/기준 재정의 (HW의 ‘재현·기준화’를 SW 디버깅으로) |
| 사용할 줄 아는 툴은? | (HW의 Cadence/Spectre 대신) 본인 SW 스택: 언어(C/C++/Python 등), Git, 디버거/정적분석, 테스트 프레임워크, OS/RTOS |
| 가장 재밌던 과목은? | ”실제 환경·조건에 따라 동작이 달라지는 게 흥미” → 임베디드/OS/네트워크/제어 등 직무 연결 과목 |
| 학점 좋은데 대학원 안 간 이유 (받으면) | “이론 연구보다 실제 환경에서 동작·신뢰성 문제를 분석·개선하는 데 흥미” → SW 직무 선택 |
| Q 질문 | 방향성 포인트 (SW) |
|---|
| 보안규정 위반 상황 보면? | 방산에서 보안은 선택 아니라 기본 책임 → 즉시 중단/확인 → 규정 절차 보고 → 개인 판단으로 덮지 않음 |
| 방산 보안 엄격한데 괜찮나? | (SW는 소스코드·설계가 곧 기술) 기술 유출=국가 안보 직결 → 절차 준수·기록 관리가 개발자 기본 |
| 무기 개발 윤리적 부담 없나? | 방산 기술은 억제·방어 → 개발자는 안전·정확·통제 가능성을 높이는 책임, SW가 그 통제의 핵심 |
| 조직에서 필요한 사람인 이유? | 문제를 단순 현상으로 안 넘김 → 원인·조건·재발방지 기준까지 남김 |
| (방산 SW에서) 책임감이 중요한 이유? | 한 번의 작은 결함이 운용 실패로 → 검증·기록·재현성이 신뢰성의 핵심 |
| Q 질문 (SW 버전) | 방향성 포인트 |
|---|
| 성장 가능성만 말하는 것 아닌가요? | ”성장 가능성뿐 아니라 이미 실제 문제를 해결한 경험([내 프로젝트] 결과 1개) 있음” → 직무 적용 가능성 명확 |
| 신입이라 실무에 바로 도움 되나? | ”규모는 다르지만 접근 방식은 동일 — 원인 재현·기준 통일·검증·회귀방지는 실무 SW에도 핵심” |
| 학교 프로젝트 수준 아닌가요? | ”규모는 작아도 요구사항→구현→검증 흐름과 디버깅·테스트 경험은 그대로 이어짐” |
| 일반 IT 가는 게 낫지 않나? | ”빠른 재배포보다 한 번에 정확·안전이 핵심인 환경에 더 끌림 → 방산 SW와 성향 일치” |
| 본인이 말한 꼼꼼함이 속도를 늦추지 않나? | ”초반엔 그럴 수 있어 영향 범위·일정 기준으로 빨리 공유할 문제와 깊게 볼 문제를 구분 중” |
| 왜 LIG에서 오래 일할 수 있다고 보나? | 직무 방향성·개인 성향 일치 + “현장 기반 문제해결에 흥미, 신뢰성 기준을 장기적으로 쌓고 싶다” |