임베디드 개발자 이력서 예시

차량 제어기 소프트웨어 분야에서 통신과 진단 스택을 다뤄온 오현준입니다. 하늘전장에서 3년간 도어·조명 제어기의 CAN 송수신 모듈을 C 언어로 개발하였고, 현재는 다온모빌리티에서 AUTOSAR Classic 기반 제어기 3종의 COM·PduR·CanIf 설정과 UDS 진단 서비스를 담당하고 있습니다. 단순히 통신 사양을 설정하는 작업에 머물지 않고, 실차 버스 로그와 시험 결과를 대조하면서 사양 변경의 근거와 결함 원인을 꾸준히 확인해 왔습니다. 통신 모듈 개발부터 양산 검증, 필드 문의 분석까지 두루 경험한 임베디드 소프트웨어 개발자입니다. 수신 처리를 메인 루프에서 수행하던 기존 구조는 부하가 집중될 때 메시지를 누락시키는 문제가 있었습니다. 인터럽트 수신 후 큐로 처리하는 방식과 폴링 주기를 줄이는 방식을 비교하였고, CPU 여유 자원이 부족하다는 점을 고려하여 큐 처리 방식을 채택했습니다. 큐 메모리 2KB를 확보하기 위해 로그 버퍼를 줄이는 결정을 설계 문서에 명시하기도 했습니다. 그 결과 수신 지연을 최대 6ms에서 2ms로 단축했습니다. 현재도 대안을 비교한 뒤 버스 부하와 수신 지연에 미치는 영향을 기준으로 설정안을 선택하고, 시험 결과로 판단의 타당성을 확인하는 과정을 반복하고 있습니다. [핵심 역량] - AUTOSAR Classic 통신 모듈 설정 및 제어기 3종 연동 - CAN·CAN FD 통신 모듈 개발과 버스 부하 검증 - UDS 진단 서비스 21종 및 DTC 186개 구현 - HIL 통신 회귀 시험 85항목 자동화 - ASPICE 레벨 2 산출물 및 MISRA C 위반 관리

한빛모빌리티의 차세대 통합 제어기 플랫폼 통신 스택 내재화 공고를 접하고 지원했습니다. 다온모빌리티에서 제어기 3종의 COM·PduR·CanIf 설정을 담당하며 신호 1,400여 개와 연 140여 건의 통신 사양 변경을 관리했습니다. 공통 템플릿을 구축하여 신규 차종 적용 기간을 10주에서 6주로 단축했습니다. 플랫폼 단위의 재사용성과 개별 차종의 통신 요구를 조율해 온 경험은 지원 직무와 맞닿아 있습니다. CAN FD 전환 차종에서는 메시지 재배치 방안을 검토하며 주기 변경안과 신호 통합안을 비교했습니다. 주기 변경보다 수신 지연 영향이 적은 신호 통합안을 선택했고, 버스 부하를 검증하여 최대 부하율을 62% 이하로 유지했습니다. 진단 업무에서는 사양서와 구현 결과를 자동 대조하는 스크립트를 작성해 누락 항목을 확인했습니다. 진단 서비스 21종과 DTC 186개의 구현 및 시험을 진행하며 양산 검증 단계의 지적 사항을 0건으로 마무리했습니다. 사양과 코드, 시험 결과를 서로 맞춰 확인하는 것이 제가 일하는 기준이 되었습니다. 한빛모빌리티의 통합 제어기 플랫폼에서도 공통 설정의 적용 범위와 차종별 예외를 구분하고, 변경 사항이 통신 동작과 진단에 미치는 영향을 시험으로 확인하려 합니다. ASPICE 레벨 2 대응 산출물 작성과 HIL 회귀 시험 자동화 경험도 갖추고 있습니다. 플랫폼 통신 스택을 내재화하는 과정에서 설정 재사용성과 양산 검증의 추적성을 확보하는 것을 목표로 합니다.

2025년 3월부터 9월까지 STM32 개발 보드와 미세먼지·이산화탄소 센서를 활용해 실내 공기 측정기를 직접 제작했습니다. 단일 루프 방식에서는 화면 갱신 중 측정이 지연되는 문제가 발생해, 측정·표시·저장 기능을 FreeRTOS 태스크 3개로 분리하여 효율을 높였습니다. 실내 환경에 맞춰 센서 범위를 최적화했고, 데이터가 튀는 현상은 이동 평균과 이상치 제거 알고리즘으로 보정했습니다. 보정된 결과값은 시판 측정기와 1주일간 나란히 배치해 정밀도를 비교했습니다. 그 결과 평균 오차는 18%에서 6%로 크게 줄었고, 저전력 모드를 적용한 뒤 배터리 사용 시간은 9일에 달했습니다. 회로도와 펌웨어, 측정 기록은 공개 저장소에 정리해 두었습니다. 제한된 메모리와 전력 조건에서 하드웨어 구조와 센서 선택을 종합적으로 검토한 이 경험은, 앞으로의 개발 과정에서 효율적인 시스템을 설계하는 기준이 될 것입니다.