카드뉴스
임베디드 포트폴리오, 설계 판단과 검증 기록을 남기는 법
보드 사진 옆에 “모터 제어 성공”이라고만 적으면 정작 궁금한 내용은 남습니다. 어떤 문제를 맡았고, 왜 그 부품과 구조를 골랐으며, 어디까지 직접 구현했는지 알기 어렵기 때문입니다. 임베디드 포트폴리오에는 결과물과 함께 목표 정의, 하드웨어 구성, 펌웨어 동작, 디버깅, 시험 결과가 한 흐름으로 이어져야 합니다. 다른 엔지니어가 기록을 읽고 개발 과정을 따라갈 수 있는지가 기준입니다.
요구사항을 적고 시스템 구조로 이어갑니다
첫 부분에는 해결하려던 문제와 기능·성능 목표, 입력과 출력, 제약 조건, 본인 담당 범위를 적습니다. 예를 들어 STM32 기반 모터 제어 시스템이라면 센서 입력을 받아 어떤 출력을 만들 것인지, 제어 대상과 시험 기준은 무엇인지부터 밝혀야 뒤의 설계가 이해됩니다.
구성도에는 전원부, MCU, 센서, 모터 드라이버, 모터, 통신 및 디버그 인터페이스를 놓고 신호가 흐르는 방향을 표시합니다. 부품명이나 회로 이미지만 붙이지 말고 MCU와 드라이버를 선택한 이유, 전원을 구성한 방식, 입출력 신호의 역할을 짧게 설명하세요. 대안을 비교했다면 성능, 비용, 구현 난이도 가운데 무엇을 기준으로 판단했는지도 남깁니다.
펌웨어는 파일 목록보다 동작 순서가 먼저입니다
코드 파일을 전부 보여줄 필요는 없습니다. 시스템 초기화, 센서 읽기, 제어 로직, PWM 출력, 통신 로그, 오류 처리처럼 실제 실행 순서를 먼저 그리면 구조가 빠르게 보입니다. 이어서 드라이버, 미들웨어, 응용 로직이 각각 맡는 책임과 데이터가 오가는 경계를 설명합니다. 핵심 코드는 이 흐름에서 본인이 구현한 기능을 보여주는 부분만 발췌하고, 입력값과 출력값까지 붙이는 편이 읽기 쉽습니다.
디버깅과 시험에는 판단 근거를 붙입니다
문제가 생긴 장면은 증상, 재현 조건, 확인한 지점, 원인, 수정 내용 순으로 정리합니다. 센서 입력과 전원, MCU 내부 상태, 통신 데이터, PWM 출력을 차례로 확인했다면 그 순서 자체가 문제 해결 능력을 보여줍니다. 디버거 화면, UART 로그, 오실로스코프 파형에는 무엇을 확인하려고 측정했는지 설명을 달아야 합니다.
시험 결과도 “정상 동작” 한 줄로 끝내지 않습니다. 시험 조건과 기대값, 실제 측정값, 허용 기준, 판정을 함께 기록하세요. 수정 전후를 비교할 때는 측정 위치와 축 단위를 맞추고, 어떤 변경이 차이를 만들었는지 해석합니다. 실패 항목이 있다면 감추기보다 확인된 영향과 다음 수정 계획을 구분해 적는 편이 기록의 신뢰도를 높입니다.
PDF·GitHub·시연 자료는 같은 흐름을 가리켜야 합니다
Notion이나 PDF의 한 페이지 요약에서 시스템 구성도, 핵심 코드, 디버깅 기록, 검증 결과로 넘어가고, GitHub와 시연 영상은 해당 근거를 바로 확인할 수 있게 연결합니다. 자료마다 다른 설명을 반복하기보다 각 매체의 역할을 나누는 방식입니다. 지금 진행 중인 프로젝트 하나를 골라 요구사항→설계 근거→구현 범위→시험 조건→측정 결과→개선 내용의 순서로 다시 배열해 보세요.
