임베디드 개발자 면접 준비 예시

다온모빌리티에서 제어기 3종의 COM·PduR·CanIf 설정과 신호 1,400여 개를 관리하면서, 차종마다 반복 설정을 다시 검토해 적용에 10주가 걸리는 문제가 있었습니다. 저는 세 제어기의 신호 경로와 통신 주기, 타임아웃, 라우팅 규칙을 비교해 공통 설정과 차종별 차이를 구분했습니다. 반복 검증된 항목은 템플릿에 넣고, 핀 구성이나 신호 사용 조건처럼 차종마다 달라지는 항목은 별도 설정표와 변경 이력으로 관리했습니다. 같은 검토 단계와 산정 기준으로 적용 기간을 비교해 6주로 줄였습니다. 공통화는 예외를 없애는 일이 아니라 예외를 추적 가능하게 만드는 일이라고 배웠습니다.

CAN FD 전환 차종에서 메시지 재배치안을 검토할 때, 주기를 바꾸면 수신 시점이 늦어질 수 있고 신호를 통합하면 프레임 구성과 부하가 달라지는 점을 비교했습니다. 저는 기존 주기와 수신 타임아웃을 기준으로 두 안의 수신 시점 변화를 계산하고, CANoe 버스 로그에서 주기별 프레임과 부하를 확인했습니다. 재생 시험에서도 변경 전후 신호 갱신 시점을 대조해 지연 영향이 작은 신호 통합안을 선택했습니다. 대표 주행 시나리오와 고부하 조건을 포함해 검증한 결과 최대 버스 부하율을 62% 이하로 유지했습니다. 선택 기준을 로그와 시험 결과로 함께 확인하는 습관을 얻었습니다.

진단 사양과 구현 결과를 수작업으로 대조하던 중 서비스별 식별자와 응답 조건이 빠질 가능성을 발견했습니다. 저는 사양 자료의 서비스 번호, 서브기능, 긍정·부정 응답 조건, DTC 상태 정보를 구현 목록과 비교하는 스크립트를 작성했습니다. 차이가 난 항목은 사양 기준으로 다시 확인해 구현과 시험 항목에 반영하고, 수정 뒤에는 대상 서비스와 DTC의 응답 결과를 진단 시험으로 대조했습니다. 이 과정에서 서비스 21종과 DTC 186개를 점검했고, 양산 검증에서 진단 관련 지적 사항 없이 마무리했습니다. 자동 비교는 검증 누락을 줄이고 사람이 의미를 판단할 시간을 확보하는 데 효과적이었습니다.

기존 통신 회귀 시험은 동일한 송수신 조건을 사람이 반복 수행해 결과 정리까지 3일이 걸렸습니다. 저는 사양 변경 때마다 반복되는 주기 송신, 타임아웃, 신호값 경계 조건을 우선 자동화 대상으로 골랐고, HIL에서 85개 항목을 실행하도록 구성했습니다. 각 항목에 기대 신호값과 허용 시간 범위를 두고, 결과 로그의 실제값과 대조해 불일치가 나면 실패로 판정하게 했습니다. 정상 조건과 오류 조건을 함께 실행해 수작업 결과와 비교한 뒤 반복 적용했습니다. 전체 수행 시간은 같은 시험 범위 기준 1일로 줄었습니다. 자동화는 실행뿐 아니라 판정 기준의 일관성이 중요하다는 점을 배웠습니다.

저는 먼저 변경된 통신 사양에서 신호, 주기, 타임아웃, 송수신 노드를 확인하고 기존 설정과 차이를 정리합니다. 신호 변경이면 COM의 신호와 I-PDU 매핑을 확인하고, PDU 경로 변경이면 PduR 라우팅과 CanIf의 CAN ID, 컨트롤러, 프레임 구성을 이어서 점검합니다. 이어 관련 DBC와 설정 산출물의 일치 여부를 확인하고 변경 이력에 영향받는 시험 항목을 연결합니다. 실제 변경 뒤에는 CANoe 로그에서 주기와 신호값을 확인하고 HIL 회귀 결과와 대조했습니다. 제어기 3종의 설정을 맡으며 이 순서를 적용해 사양, 설정, 시험 결과가 서로 이어지도록 관리했습니다.

저는 변경 건수를 기준으로 일괄 처리하기보다 영향 범위와 실패 시 영향을 먼저 봅니다. 안전이나 주요 기능에 연결된 신호, 여러 제어기의 PDU 경로를 바꾸는 건, 타임아웃과 진단 동작까지 영향을 줄 수 있는 건을 우선 분석합니다. 이어 변경된 계층과 연동 노드를 기준으로 회귀 시험을 묶고, 영향이 국소적인 표시용 신호 변경은 핵심 통신 경로 확인 뒤 배치합니다. 다온모빌리티에서 연 140여 건의 사양 변경을 처리할 때도 변경 이력에 영향 항목과 필요한 시험을 함께 기록했습니다. 제한된 시간에는 위험이 큰 경로부터 검증하고, 남은 범위는 우선순위와 근거를 공유하는 것이 품질을 지키는 방법이라고 생각합니다.

MISRA C 위반 312건을 검토하면서 저는 먼저 필수 규칙 위반을 분류하고, 통신 송수신과 진단 경로에 있는 항목을 우선 확인했습니다. 값의 범위나 형 변환처럼 데이터 손상으로 이어질 수 있는 코드는 수정 필요성을 높게 두고, 실제 영향이 제한적인 항목은 근거와 함께 개별 검토 대상으로 관리했습니다. 일괄 예외는 감사에서 판단 근거가 불분명해질 수 있어 적용하지 않았습니다. 수정 후에는 정적 분석을 다시 실행하고 코드 리뷰에서 규칙과 조치 근거를 확인했습니다. 신규 위반은 리뷰 단계에서 바로 확인하도록 점검 기준을 두었습니다. 이 경험을 통해 위반 수보다 위험과 추적 가능한 판단 근거를 먼저 관리해야 한다고 배웠습니다.

저는 먼저 CANoe 로그에서 해당 메시지의 실제 수신 간격과 신호값을 확인하고, 같은 시점에 버스 오프나 전체 통신 정지가 있었는지 살핍니다. 하늘전장 실차 시험에서도 버스 오프 여부와 신호 타임아웃을 먼저 나눠 확인한 뒤 재현 시험을 정했습니다. 버스 오프가 없으면 송신 주기 변동, 프레임 누락, 신호 갱신 조건을 시간 순서로 대조하고, Trace32로 수신 인터럽트와 큐 처리 시점을 확인합니다. 이후 같은 부하와 조건을 HIL에서 재현해 로그를 비교하고, 확인된 사실과 가설을 분리해 원인을 좁힙니다. 실차 결함 연 60여 건을 분석하며 추정만으로 원인을 단정하지 않는 태도를 익혔습니다.

ISO 26262 안전 요구사항이나 안전 분석 산출물을 직접 작성한 경험은 없습니다. 다온모빌리티에서는 ASPICE 레벨 2 대응으로 요구사항, 설계, 시험 산출물을 작성하고 변경 항목을 시험 결과까지 연결해 관리했습니다. 예를 들어 통신 사양 변경 때 영향받는 설정과 회귀 시험 항목을 추적하고, 결과를 산출물에 반영했습니다. 이 경험은 추적성과 검증 측면에서 가깝지만 기능안전 분석을 대신한다고 말할 수는 없습니다. 입사 후 3개월 안에 회사의 안전 개발 절차와 산출물 기준을 익히고, 선임 검토를 받으며 안전 요구사항과 분석 결과가 시험까지 연결되는 작성 방식을 실무에서 학습하겠습니다.

AUTOSAR Adaptive 플랫폼을 개발한 경험은 없습니다. 제 경험은 다온모빌리티의 AUTOSAR Classic 기반 제어기 3종에서 COM·PduR·CanIf 설정을 관리하고 통신 변경과 시험을 수행한 범위입니다. 공통 설정과 차종별 예외를 구분하고, 변경 영향이 시험에 반영되도록 추적한 경험은 있습니다. 다만 이를 Adaptive 개발 경험이라고 포장하지 않겠습니다. 입사 후 첫 3개월 동안 회사 플랫폼의 구조와 Classic·Adaptive 간 통신 경로 및 설정 방식의 차이를 문서와 코드 기준으로 익히고, 이후 공통 템플릿 적용 업무에 참여해 6개월 안에 담당 범위의 검증 결과를 독립적으로 정리할 수 있도록 역량을 넓히겠습니다.

하늘전장에서 메인 루프 수신 구조의 누락을 줄이기 위해 저는 인터럽트 수신 후 큐 처리와 폴링 주기 단축을 비교했습니다. CPU 여유가 부족한 조건에서는 폴링을 더 촘촘하게 하는 부담이 커질 수 있다고 판단해 큐 방식을 택했고, 필요한 큐 메모리 2KB를 확보하려고 로그 버퍼를 줄였습니다. 로그 보존량이 감소하는 영향과 수신 지연 개선의 기준을 함께 정리해 설계 문서에 기록했습니다. 변경 후 시험에서 최대 수신 지연은 6ms에서 2ms로 줄었습니다. 성능 개선은 자원 비용과 운영상 영향을 함께 드러내고 근거를 남겨야 재검토할 수 있다는 점을 배웠습니다.

하늘전장에서 실차 결함을 분석할 때 저는 버스 오프와 신호 타임아웃 여부를 먼저 확인하고, 로그만으로 판단하기 어려운 건은 재현 조건을 정리해 시험에 반영했습니다. 연 60여 건의 결함은 안전 관련성과 재발 여부를 기준으로 나눠 주간 회의에서 증상, 로그 근거, 재현 결과, 조치 우선순위를 공유했습니다. 시험 일정이 촉박해도 안전 관련 건은 원인 확인과 조치 검증을 우선으로 두고, 일정에 맞춰 진행할 항목은 남은 위험과 상태를 기록해 추적했습니다. 대응 결함의 92%를 다음 시험 차수 전에 해결했습니다. 공통 근거로 우선순위를 설명하면 일정과 품질을 함께 관리할 수 있음을 배웠습니다.