임베디드 개발자 로드맵을 찾는 분들은 “무엇부터 시작하지?”보다 “어디까지 알아야 하지?”에서 더 자주 막힙니다. STM32 보드에서 LED를 깜빡이고, 버튼 입력을 받고, PWM(Pulse Width Modulation) 듀티를 바꿔 모터를 돌려본 다음부터 길이 흐려지는 경우가 많습니다. 인터넷에는 자료가 많지만, 자료가 많다는 말이 곧 방향이 보인다는 뜻은 아닙니다.
임베디드 개발자 로드맵 체크리스트
- 전기전자 기초로 전압, 전류, 신호, 회로의 기본 감각을 잡습니다.
- STM32 같은 MCU로 GPIO, 타이머, UART, ADC, PWM을 직접 다뤄봅니다.
- 회로와 PCB를 읽으면서 펌웨어가 실제 하드웨어와 만나는 지점을 이해합니다.
- 모터제어와 전력전자 실습을 통해 제어 알고리즘과 계측 감각을 연결합니다.
- 작은 프로젝트를 완성하면서 요구사항, 디버깅, 검증, 문서화를 함께 경험합니다.
임베디드가 어려운 이유는 한 가지 기술만 잘해서는 문제가 풀리지 않기 때문입니다. 펌웨어를 잘 짜도 회로가 받쳐주지 않으면 동작이 이상해지고, 회로를 잘 그려도 제어 이론이 부족하면 모터가 원하는 방식으로 돌지 않습니다. 반대로 이론만 깊이 파면, 실제 보드에서 측정값이 왜 흔들리는지 설명하기 어렵습니다.
그래서 저는 임베디드 학습을 한 번에 깊게 파기보다, 필요한 축을 순서대로 훑고 작은 프로젝트에서 다시 묶어 보는 쪽을 권합니다. 아래 흐름은 절대적인 정답이라기보다, 자동차 전동화와 모터제어 쪽으로 가고 싶은 입문자에게 현실적으로 권하기 좋은 순서에 가깝습니다.
임베디드 개발자 로드맵을 한 줄로 보면
큰 흐름은 전기전자 기초 → MCU → 회로·PCB → 모터제어 → 프로젝트 통합 → 자동차 개발 프로세스입니다. 이 순서가 고정된 계단이라는 뜻은 아닙니다. 어떤 분은 회로부터 시작하고, 어떤 분은 소프트웨어를 하다가 MCU로 내려옵니다. 다만 오래 버티려면 결국 회로, 펌웨어, 제어, 검증을 모두 한 번씩은 지나가게 됩니다.
처음부터 모든 단계를 전문가 수준으로 만들 필요는 없습니다. 다음 단계로 넘어갈 수 있을 만큼 이해하고, 프로젝트에서 막히는 지점을 다시 돌아와 채우는 방식이 더 오래 갑니다.
0단계: 전기전자 기초
가장 먼저 다질 부분은 학교 1, 2학년 때 배우는 전기전자 기초입니다. 옴의 법칙, 키르히호프 전압·전류 법칙, RLC(Resistor-Inductor-Capacitor) 회로의 시정수, 다이오드와 트랜지스터의 동작, 연산증폭기의 기본 구성 정도는 꼭 한 번 정리해 두는 게 좋습니다.
이 단계의 목표는 회로 해석 문제를 빠르게 푸는 것이 아닙니다. 보드 위에서 일어나는 일을 머릿속에서 대략 그려볼 수 있게 만드는 것입니다. 캐패시터 양단 전압이 왜 갑자기 못 변하는지, 인덕터 전류가 왜 갑자기 끊기면 안 되는지 같은 감각은 나중에 모터 구동 회로를 볼 때 바로 도움이 됩니다.
깊이의 기준은 “처음부터 회로를 설계할 수 있는 수준”이 아니라 “다른 사람이 그린 회로도를 보고 전원, 신호, 접지 흐름을 따라갈 수 있는 수준”입니다. 이 단계는 빠르게 훑고, 나중에 필요할 때 다시 돌아오는 식으로 반복해도 충분합니다.
1단계: MCU 입문, STM32부터 시작해도 좋다
전기전자 기초가 어느 정도 잡히면 MCU(Microcontroller Unit)로 넘어옵니다. 입문 보드는 ST의 STM32 시리즈가 무난합니다. ST 공식 STM32 MCU 페이지를 보면 제품군, 개발 보드, 소프트웨어 도구가 한 생태계 안에 정리되어 있습니다. 자료가 많고, 저가형부터 고성능 라인업까지 이어지기 때문에 연습한 내용이 다른 보드로 넘어갈 때도 비교적 잘 이어집니다. STM32 입문 자료와 강의는 강의 보기 페이지에도 계속 정리해둘 예정입니다.
처음에 익혀야 할 주변장치는 GPIO(General Purpose Input/Output), 타이머, PWM, ADC(Analog-to-Digital Converter), UART(Universal Asynchronous Receiver/Transmitter), 인터럽트입니다. 기능 이름을 외우는 것보다 중요한 것은 데이터시트와 레퍼런스 매뉴얼을 직접 열어 보고, 레지스터 단위에서 무슨 일이 일어나는지 한 번씩 따라가 보는 것입니다.
입문할 때는 HAL(Hardware Abstraction Layer)로 빠르게 동작을 확인해도 됩니다. 다만 제 기준에서는 레지스터를 직접 접근해 보는 과정을 너무 늦추지 않는 편이 좋습니다. HAL만 쓰면 편하지만, 타이머·ADC·DMA가 왜 그 순서로 움직이는지 감이 늦게 옵니다. 레지스터를 한 번씩 만져 보면 다른 MCU로 넘어갈 때도 훨씬 덜 막힙니다.
이 단계의 끝은 “예제를 복사해서 돌아가게 만든 상태”가 아닙니다. 데이터시트를 보고 원하는 동작을 직접 설정할 수 있는 상태, 최소한 문제가 생겼을 때 어느 레지스터와 어느 주변장치를 확인해야 하는지 짐작할 수 있는 상태를 목표로 잡는 게 좋습니다. STM32 관련 글은 STM32 카테고리에 계속 모아둘 예정입니다.
2단계: 회로와 PCB를 읽는 힘
여기서부터 임베디드 개발자가 자주 빠지는 함정이 시작됩니다. 펌웨어만 보고, 회로는 “어차피 HW 엔지니어가 해주는 영역”으로 미루는 태도입니다. 짧게 보면 효율적인 분업처럼 보이지만, 길게 보면 본인이 만든 코드가 왜 동작하지 않는지 설명하지 못하는 상황을 자주 만듭니다.
모터제어 보드를 예로 들면 션트 저항의 위치, 게이트 드라이버의 데드타임, DC 링크 캐패시터 용량, 그라운드 분리, 측정 신호 라인의 노이즈가 모두 펌웨어 거동에 영향을 줍니다. 코드는 그대로인데 보드 리비전이 바뀌었다는 이유로 제어가 흔들리는 일도 충분히 생깁니다.
PCB 공부는 KiCad나 EasyEDA처럼 접근하기 쉬운 도구로 시작해도 됩니다. 처음부터 6층, 8층 보드를 그릴 필요는 없습니다. 2층짜리 작은 보드 하나를 직접 그리고, 발주하고, 납땜해서 동작시켜 보는 사이클을 한 번 끝내는 것이 어떤 책보다 강력합니다. 회로와 PCB 관련 글은 회로/PCB 카테고리에 정리해둘 예정입니다.
이 단계의 목표는 HW 엔지니어가 되는 것이 아닙니다. 회로도와 거버 파일을 보고 의도를 읽을 수 있고, 측정 결과가 이상할 때 SW 문제인지 HW 문제인지 가설을 세울 수 있으면 충분합니다.
3단계: 모터제어 이론은 실습과 같이 봐야 한다
회로와 펌웨어가 어느 정도 손에 익으면 모터제어 이론으로 들어갑니다. 임베디드의 여러 도메인 중에서도 모터제어는 SW, HW, 제어 이론이 강하게 얽혀 있는 영역입니다. 제가 전력전자와 모터제어 쪽에 가까운 일을 해왔기 때문에 이 방향을 특히 추천하는 면도 있습니다. 다른 분야에 더 관심이 있다면 센서, 통신, 임베디드 리눅스처럼 해당 도메인의 이론과 실습으로 바꿔 잡아도 됩니다.
먼저 모터의 종류를 구분해야 합니다. DC모터, BLDC(Brushless DC), PMSM(Permanent Magnet Synchronous Motor)은 외형만 보면 비슷해 보여도 제어 방식과 모델이 다릅니다. 일반적인 입문 단계에서는 BLDC를 사다리꼴 역기전력 기반의 6-step 구동으로, PMSM을 정현파 역기전력을 가정한 FOC(Field Oriented Control)로 나누어 보면 이해하기 쉽습니다. 실제 모터와 제어 방식에는 예외가 있으므로, 프로젝트에서는 모터 데이터시트와 구동 방식을 따로 확인해야 합니다.
FOC를 이해하려면 Clarke·Park 변환, dq축 전류, 전류 제어 루프, PWM과 ADC 샘플링 타이밍을 함께 봐야 합니다. 이 부분은 책으로만 읽으면 추상적으로 느껴지기 쉽습니다. MATLAB/Simulink 같은 도구로 인버터 모델, 모터 모델, PI 제어기를 먼저 돌려 보고 같은 구조를 펌웨어로 옮겨 보면 이해가 훨씬 빠릅니다.
독학으로 바로 PMSM FOC까지 가려 하면 꽤 어렵습니다. 처음 목표는 BLDC 모터를 실제로 한 번 구동해 보고, 그다음 PMSM과 FOC로 넘어가는 정도가 현실적입니다. 물론 이 순서가 정답은 아니고, 목표 도메인에 따라 센서·통신·리눅스 쪽으로 먼저 가도 됩니다. 모터제어 관련 글은 모터제어 카테고리에서 이어서 다루겠습니다.
4단계: 작은 프로젝트로 한 번 묶어보기
여기까지 왔다면 이제 통합이 필요합니다. 각 단계를 따로 공부했다면 머릿속에서는 연결되어 있어도, 손은 아직 한 번에 다루는 데 익숙하지 않을 가능성이 큽니다. 작은 프로젝트 하나를 처음부터 끝까지 자기 손으로 만들어 보는 경험이 그래서 중요합니다.
예를 들어 전동킥보드용 BLDC 컨트롤러 같은 주제는 출력 규모가 너무 크지 않으면서도 부품 선정, 기초적인 여유 설계 개념, 제어 성능 사이의 트레이드오프를 모두 겪게 만듭니다. MCU 선정, 게이트 드라이버 선정, 션트 저항의 위치와 값, DC 링크 캐패시터 용량, 보호 회로, 펌웨어 구조, 제어 알고리즘까지 한 흐름으로 이어집니다.
이 단계에서 중요한 습관은 결정의 근거를 글로 남기는 것입니다. “왜 이 게이트 저항을 골랐는지”, “왜 션트를 인버터 하단에 두었는지”, “왜 이 PWM 주파수를 골랐는지” 같은 항목을 짧게라도 적어 두면 나중에 본인이 그 보드를 다시 잡았을 때 시간을 크게 아낄 수 있습니다. 협업이나 이직 상황에서도 이런 기록은 생각보다 큰 자산이 됩니다.
5단계: 자동차 산업에서는 검증과 문서화가 붙는다
여기서부터는 분야에 따라 달라지는 영역이라 조심스럽게 적겠습니다. 자동차 OEM이나 Tier 1에서 일하게 되면 앞 단계에서 배운 기술 위에 양산 품질, 검증, 문서화라는 층이 올라갑니다. 같은 기능이라도 실험실에서 돌아가는 것과 양산 차량에 들어가는 것은 완전히 다른 문제로 다뤄집니다.
자주 등장하는 키워드로 Automotive SPICE와 ISO 26262(기능안전)가 있습니다. 다만 이 둘이 모든 프로젝트에 같은 강도로 적용되는 것은 아닙니다. OEM, 차종, 부품의 안전 관련성, ASIL 수준, 프로그램 범위에 따라 요구가 달라질 수 있습니다. 입문 단계에서는 용어와 큰 그림을 알아두되, 세부 적용은 실제 프로젝트의 고객 요구사항과 회사 프로세스를 기준으로 확인해야 합니다.
이 단계의 핵심은 “내 코드가 양산 차량에 들어간다”는 전제 위에서 다시 보는 시야입니다. 시뮬레이션에서 동작하는 것, 프로토 보드에서 동작하는 것, 실차 환경에서 오래 버티는 것은 서로 다른 문제입니다. 검증과 문서화가 처음에는 답답해 보일 수 있지만, 필드 이슈를 한 번 겪고 나면 왜 그런 절차가 필요한지 자연스럽게 이해됩니다.
자주 하는 오해 몇 가지
첫 번째는 “나는 SW 직무니까 회로는 몰라도 된다”, 또는 그 반대 방향입니다. 직무 분리는 조직 운영을 위한 구분이지 개인의 실력 한계가 아닙니다. 회로를 모르는 펌웨어 엔지니어는 디버깅 폭이 좁아지고, 펌웨어를 모르는 회로 엔지니어는 자신이 만든 보드의 한계를 잘 측정하지 못합니다.
두 번째는 “이론보다 일단 만들어 보는 것이 최고”라는 태도입니다. 절반은 맞습니다. 다만 모터제어처럼 측정과 해석이 동시에 필요한 영역에서는 이론 없이 만들기만 하면 같은 자리를 계속 맴돌기 쉽습니다. 만들고, 측정하고, 이론으로 해석하고, 다시 고치는 사이클을 한 번 돌아보는 것이 결국 가장 빠릅니다.
세 번째는 “도구가 부족해서 못 한다”는 생각입니다. 오실로스코프, 전원, 전자부하 같은 장비가 있으면 분명 유리합니다. 그래도 입문 단계에서는 저가 USB 오실로스코프, 멀티미터, 작은 전원만으로도 갈 수 있는 거리가 꽤 있습니다. 장비가 완벽해질 때까지 기다리는 것보다, 지금 할 수 있는 작은 측정부터 시작하는 편이 낫습니다.
함께 읽으면 좋은 글
임베디드 개발자 로드맵을 따라가면서 MCU 문서 읽기가 막힌다면 MCU 데이터시트 읽는 5가지 방법을 먼저 확인해도 좋습니다. 직무 방향이 고민된다면 임베디드 SW 분야 5가지와 2026 임베디드 개발자 전망을 함께 보면 큰 흐름을 잡기 쉽습니다.
자동차 임베디드 쪽으로 확장할 계획이라면 자동차 임베디드 SW 입문: MISRA C부터 AUTOSAR, MBD까지를 이어서 보고, 공부 방향이 막힐 때는 임베디드 개발자가 제대로 성장하려면 무엇을 봐야 할까에서 회로·디버깅·요구사항을 어떻게 연결할지 확인하면 좋습니다.
공식 문서로 더 확인하기
STM32 학습을 시작한다면 STMicroelectronics STM32 공식 페이지에서 데이터시트, 레퍼런스 매뉴얼, 애플리케이션 노트를 확인하는 습관을 들이는 것이 좋습니다.
- Arm Embedded and MCU Development: Cortex-M 계열 MCU와 Arm 개발 도구 흐름을 확인할 때 참고합니다. 입문자는 보드보다 코어, 툴체인, 디버깅 흐름을 함께 보는 것이 좋습니다.
- AUTOSAR Standards: 자동차 ECU 소프트웨어 쪽으로 확장할 때 Classic Platform, Adaptive Platform, Foundation의 큰 구분을 확인하는 공식 기준점입니다.
- ISO 26262 road vehicles functional safety: 기능안전은 모든 임베디드 SW에 같은 강도로 적용되는 것이 아니라 item 정의와 위험 분석 결과에 따라 범위가 달라지므로, 자동차 안전 관련 소프트웨어를 볼 때 공식 표준 구성을 확인합니다.
마무리
이 글의 임베디드 개발자 로드맵은 모든 사람에게 같은 순서로 적용되는 정답이 아닙니다. 어떤 분은 회로부터 시작해서 펌웨어로 올라오고, 어떤 분은 제어 이론에서 시작해 MCU로 내려옵니다. 순서는 달라도 결국 회로·펌웨어·제어·검증이라는 축을 모두 한 번씩 만나게 된다는 점은 비슷합니다.
처음부터 모든 단계를 깊게 파려고 하면 지치기 쉽습니다. 각 단계에서 다음 단계로 넘어갈 만큼만 이해하고, 작은 프로젝트로 통합하고, 부족한 부분을 다시 돌아와 채우는 사이클이 가장 무리가 없습니다. 그 과정에서 본인이 내린 결정과 측정한 데이터를 짧게라도 기록으로 남겨 두시기 바랍니다. 시간이 지나서 가장 큰 자산이 되는 부분은 그런 기록인 경우가 많습니다.
앞으로 이 블로그에서는 STM32 기반 모터제어를 중심으로, 회로·펌웨어·제어를 한 흐름으로 다루는 글을 차근차근 올려볼 예정입니다. 로드맵만 보고 끝내기보다, 각 단계에서 실제로 손에 남는 작은 결과물을 하나씩 만들어 가는 쪽으로 이어가 보겠습니다.