“임베디드 SW 개발자입니다”라고 자기소개를 하면, 듣는 사람이 떠올리는 그림은 사람마다 꽤 다릅니다. 누군가는 작은 칩 위에서 LED를 깜빡이는 코드를 떠올리고, 누군가는 차량 인포테인먼트 화면을 떠올리고, 또 누군가는 모터를 정밀하게 돌리는 제어 로직을 떠올립니다. 이상한 일이 아닙니다. 실제로 임베디드 SW 분야라는 타이틀 아래에서 사람들이 매일 다루는 일은 회사마다, 제품마다 꽤 다르기 때문입니다.
임베디드 SW 분야 5가지 한눈에 보기
- 펌웨어: MCU 레지스터, 인터럽트, 타이머, ADC, RTOS를 직접 다룹니다.
- 드라이버와 OS: 커널, BSP, 부트로더, 디바이스 트리처럼 하드웨어와 운영체제 사이를 연결합니다.
- 미들웨어와 통신: CAN, LIN, Ethernet, OTA, AUTOSAR 같은 제품 간 연결 구조를 다룹니다.
- 제어와 검증: 모터제어, 신호처리, HIL, 테스트 자동화처럼 동작 품질을 확인하는 영역입니다.
같은 회사 안에서도 팀이 달라지면 사용하는 도구, 코드 스타일, 검증 방식이 거의 다른 직군처럼 느껴질 때가 있습니다. 한쪽 팀은 어셈블리에 가까운 레지스터 매핑을 들여다보고, 다른 팀은 리눅스 커널 패치를 만지고, 또 다른 팀은 시뮬링크 모델로 제어기를 설계합니다. 모두 임베디드 SW 엔지니어라는 같은 호칭을 씁니다.
이 글에서는 자동차, 가전, 소형 IoT, 산업 자동화에서 자주 마주치는 임베디드 SW 분야를 다섯 가지로 나눠 봅니다. 산업 분류가 아니라 “엔지니어가 매일 어떤 문제를 푸는가”를 기준으로 본 분류입니다.
1. 펌웨어 (Bare-metal / Light-RTOS)
가장 전통적이고 익숙한 영역입니다. 마이크로컨트롤러(MCU) 위에서 직접 도는 코드를 다루는 일입니다. STM32, NXP, Renesas, Microchip 같은 MCU가 흔히 쓰이고, 칩의 데이터시트와 레퍼런스 매뉴얼을 옆에 두고 작업하게 됩니다.
이 영역에서 매일 만지는 것은 GPIO, 타이머, 인터럽트, ADC, DMA, 통신 페리페럴 같은 하드웨어 자원입니다. 코드 한 줄이 어떤 레지스터를 어떻게 건드리는지가 자연스럽게 머릿속에 그려지는 단계까지 가는 것이 중요합니다. 메모리도 항상 의식하게 됩니다. 플래시 몇 KB, 램 몇 KB 안에서 동작해야 하는 제품이 여전히 많기 때문입니다.
실시간 운영체제(RTOS)를 쓰느냐 안 쓰느냐는 제품의 복잡도에 따라 달라집니다. FreeRTOS, Zephyr, ThreadX 같은 가벼운 RTOS를 올려서 태스크 단위로 구조화하는 경우도 있고, 인터럽트와 메인 루프만으로도 충분한 경우도 있습니다. 어느 쪽이든 “정해진 시간 안에 정해진 일을 해야 한다”는 실시간성에 대한 감각이 핵심입니다.
활용 범위는 굉장히 넓습니다. 모터 컨트롤러, 센서 모듈, 가전 제품의 메인 컨트롤러, 차량의 작은 ECU(Electronic Control Unit), 무선 이어폰의 신호처리 칩까지, 우리 주변에서 전기로 움직이는 거의 모든 제품 안에 이 영역의 코드가 들어 있다고 봐도 큰 무리가 없습니다.
2. 임베디드 OS / 드라이버 (Linux 기반)
MCU보다 한 단계 위, 임베디드 리눅스가 도는 보드를 다루는 영역입니다. 보통 i.MX, Qualcomm, NXP Layerscape, Renesas R-Car 같은 애플리케이션 프로세서가 올라간 보드 위에서 일합니다.
여기서는 커널, 디바이스 드라이버, 부트로더(U-Boot), 그리고 빌드 시스템이 핵심 키워드입니다. Yocto, Buildroot 같은 빌드 시스템을 다루면서 자기 보드만의 BSP(Board Support Package)를 만들고, 필요한 디바이스 드라이버를 작성하거나 포팅합니다. 디바이스 트리(Device Tree)를 손보는 일도 자주 마주치게 됩니다.
이 영역의 어려움은 레이어가 많다는 점에서 옵니다. 하드웨어, 부트로더, 커널, 사용자 영역(User space), 그리고 그 위의 애플리케이션까지 어딘가 한 곳에 문제가 생기면 그 원인을 끝까지 따라가야 합니다. 부팅 로그 한 줄 한 줄을 읽는 능력, 커널 패닉 메시지를 해석하는 능력이 자연스럽게 길러지는 영역입니다.
대표적으로는 네트워크 카메라, 셋탑박스, 차량 인포테인먼트(IVI), 산업 게이트웨이, 의료기기, 로봇 제어 보드 등이 있습니다. 같은 임베디드 리눅스라도 어떤 제품에 들어가느냐에 따라 강조되는 부분이 달라집니다. 차량용은 부팅 시간과 안정성, 산업용은 보안과 장기 지원, 가전은 빠른 응답성이 중요해지는 식입니다.
3. 미들웨어 / 통신 스택
펌웨어와 OS 사이, 또는 그 위에 올라가는 통신·서비스 레이어입니다. 이 영역은 한 마디로 “여러 노드들이 서로 어떻게 이야기하게 만드는가”를 다룬다고 볼 수 있습니다.
자동차에서는 CAN, CAN FD, LIN, FlexRay, 그리고 점점 비중이 커지는 차량용 이더넷(Automotive Ethernet)이 대표적입니다. 그 위에서 진단(UDS), 네트워크 관리, 보안 통신 같은 프로토콜이 동작합니다. 가전과 IoT 쪽으로 가면 BLE(Bluetooth Low Energy), Wi-Fi, Thread, Matter, MQTT 같은 이름이 자주 등장합니다.
부트로더와 OTA(Over-the-Air) 업데이트도 이 영역에 가깝습니다. 제품이 출하된 뒤에도 펌웨어를 안전하게 갱신할 수 있어야 하고, 중간에 전원이 끊겨도 망가지지 않아야 하고, 잘못된 이미지가 올라가지 않도록 검증도 해야 합니다. 단순해 보여도 실패 시 시나리오가 많아서 까다로운 영역입니다.
자동차 쪽에서는 AUTOSAR 이야기를 빼놓기 어렵습니다. AUTOSAR Classic의 BSW(Basic Software)나 Adaptive AUTOSAR의 ARA(AUTOSAR Runtime for Adaptive Applications)도 이 미들웨어 영역에서 다뤄지는 경우가 많습니다. 다만 적용 여부와 범위는 OEM과 프로그램에 따라 차이가 큽니다. 어떤 곳은 표준을 그대로 쓰고, 어떤 곳은 일부만 가져와서 쓰고, 어떤 곳은 자체 미들웨어를 유지합니다.
4. 제어 / 신호처리
수학과 이론이 가장 짙게 묻어나는 영역입니다. 모터제어(BLDC/PMSM 구동, FOC 기반 전류·속도 제어), 배터리 관리(BMS), 센서 융합(Sensor Fusion), 전력 변환 제어 같은 일들이 여기에 들어갑니다. 다만 BLDC 6-step 구동과 PMSM FOC는 같은 모터 제어라는 이름으로 묶이지만 제어 방식은 다릅니다. 입문 단계에서는 이 둘의 차이를 분리해서 보는 편이 좋습니다.
이쪽 일을 하다 보면 도메인별 이론을 굉장히 깊이 들여다보게 됩니다. 모터 제어라면 좌표 변환과 PI 제어, 관측기 설계가 일상이 되고, 배터리라면 셀의 전기·화학적 거동을 모델링하는 일이 익숙해집니다. 자율주행 쪽 센서 융합이라면 칼만 필터 계열의 이야기가 빠지지 않습니다.
이 분야에서 자주 쓰이는 흐름이 모델 기반 개발(Model-Based Development, MBD)입니다. MATLAB과 Simulink로 제어기를 설계하고, 모델 단계에서 시뮬레이션으로 검증한 뒤, 프로젝트에 따라 자동 코드 생성까지 이어져 타깃 MCU에서 동작하는 코드를 만들기도 합니다. 모든 회사가 이렇게 하는 것은 아니고, 손으로 직접 C 코드를 작성하는 곳도 많지만, 자동차 파워트레인이나 일부 산업 제어 분야에서는 널리 쓰이는 접근 중 하나로 자리잡았습니다.
이 영역의 또 다른 특징은 실시간 제약입니다. 제어 주기가 수십 마이크로초 단위인 경우도 흔하고, 그 시간 안에 측정·연산·출력이 모두 끝나야 합니다. 알고리즘이 아무리 좋아도 정해진 시간 안에 못 돌면 의미가 없기 때문에, 이론과 구현의 거리감을 잘 다룰 수 있는 사람이 강점을 갖는 분야입니다.
5. 검증 / 인프라 (HIL, 자동화 테스트)
코드를 만드는 일만큼이나, 만든 코드가 잘 동작한다는 것을 증명하는 일도 큰 영역입니다. 검증과 인프라 쪽은 그래서 점점 더 비중이 커지고 있습니다.
대표적인 키워드가 HIL(Hardware-in-the-Loop)입니다.
실제 차량이나 제품을 매번 동원할 수 없으니, 제어기는 실물로 두고 나머지 환경을 시뮬레이터로 만들어 연결합니다. 이 위에서 다양한 시나리오를 자동으로 돌려가며 제어기가 어떻게 반응하는지를 검증합니다. 그 앞 단계로는 SIL(Software-in-the-Loop), MIL(Model-in-the-Loop)이 있고, 양산을 앞두고는 실제 환경에서의 검증 단계가 이어집니다.
여기서 다루는 일은 단순히 테스트를 돌리는 것에 그치지 않습니다. 테스트 인프라 자체를 설계하고 만드는 일이 많습니다. CI/CD 파이프라인, 자동 테스트 프레임워크, 캘리브레이션과 측정 도구, 로그 분석 시스템 같은 것들이 모두 이 영역에 속합니다. 일부 회사에서는 이런 인프라를 다루는 별도 조직이 있을 만큼 비중이 큽니다.
자동차 쪽은 특히 이 영역의 무게가 무겁습니다. 기능안전 관련 item이라면 item 정의와 HARA 결과에 따라 정해지는 ASIL 수준 및 ISO 26262 요구사항을 고려한 검증 인프라, 추적성(traceability) 관리, 문서화 체계까지 갖추어야 하기 때문입니다. 회사와 프로그램에 따라 정도 차이는 크지만, 양산 직전으로 갈수록 검증과 관련된 일감이 빠르게 늘어나는 흐름은 비슷합니다.
임베디드 SW 분야는 회사·직무에 따라 어떻게 갈리는가
같은 임베디드 SW라도 어디에서 일하느냐에 따라 다섯 분야의 비중은 꽤 달라집니다.
자동차 OEM에 들어가면 시스템 설계, 요구사항 관리, 검증, 문서화의 비중이 큽니다. 직접 코드를 한 줄씩 짜는 시간보다 사양을 정의하고, 협력사와 인터페이스를 맞추고, 검증 결과를 검토하는 시간이 더 많을 수 있습니다. 안전 요구사항이 강한 영역일수록 이 경향이 두드러집니다. 티어1 부품사로 가면 OEM이 정한 요구사항 안에서 실제 제어 로직과 펌웨어를 책임지고 만드는 일이 늘어납니다. 모델 기반 개발과 양산 펌웨어, 그리고 수많은 변종 관리가 일상이 됩니다.
가전이나 소형 IoT 회사로 가면 사이클이 빨라집니다. 한 제품의 개발 기간이 짧고, 한 사람이 펌웨어와 통신 스택, 간단한 검증 스크립트까지 폭넓게 다루는 경우가 흔합니다. 자동차처럼 무거운 프로세스 대신, 빠르게 시제품을 만들고 시장에서 피드백을 받는 흐름이 우선됩니다. 그만큼 한 사람이 여러 영역을 얕게 또는 깊게 다 다뤄야 하는 부담도 있습니다.
산업 자동화 쪽은 또 색깔이 다릅니다. 한번 설치한 장비가 10년, 20년 단위로 운영되는 경우가 많기 때문에 안정성과 장기 지원, 호환성 유지가 중요해집니다. 통신 프로토콜과 표준의 비중이 크고, 새 기능을 빨리 넣기보다 기존 동작을 깨지 않는 쪽에 더 무게가 실립니다.
스타트업이라면 또 사정이 다릅니다. 사람 수가 적은 만큼 한 명이 부트로더부터 클라우드 연동까지 책임져야 할 수도 있고, 반대로 특정 도메인에 집중해서 거기에서만 깊이 가는 경우도 있습니다.
이런 차이는 입사 전에 완전히 파악하기는 어렵지만, 적어도 “내가 어떤 일을 하고 싶은가”는 미리 그려두는 편이 좋습니다. 이론과 수학에 시간을 더 쓰고 싶은지, 큰 시스템을 설계하고 조율하는 역할을 하고 싶은지, 손으로 직접 코드를 짜는 시간이 많기를 바라는지에 따라 잘 맞는 자리가 달라집니다.
함께 읽으면 좋은 글
임베디드 개발자 로드맵을 먼저 보면 학습 순서를 잡기 쉽고, 2026 임베디드 개발자 전망을 함께 보면 각 임베디드 SW 분야가 시장 변화와 어떻게 연결되는지 이해하기 좋습니다.
공식 문서로 더 확인하기
차량 소프트웨어 플랫폼과 미들웨어 구조가 궁금하다면 AUTOSAR Classic Platform 문서를 참고하면 애플리케이션, RTE, Basic Software 계층이 어떻게 나뉘는지 확인할 수 있습니다.
마무리
다섯 가지로 나눠 봤지만, 현장에서는 이렇게 깔끔하게 갈라지지 않습니다. 펌웨어를 만드는 사람이 통신 스택을 함께 다루기도 하고, 제어 알고리즘을 만든 사람이 그 검증 인프라까지 같이 책임지기도 합니다. 작은 회사일수록 한 사람이 여러 영역을 오가게 됩니다.
직무 분류는 결국 출발점일 뿐입니다. 한 분야에서 깊이 들어가다 보면 그 옆에 있는 회로, 펌웨어, 제어, 검증이 모두 어딘가에서 맞닿아 있다는 것을 자연스럽게 알게 됩니다. 처음에는 어느 한 곳을 골라 시작하더라도, 시간이 지나면 결국 폭과 깊이를 함께 키워가게 되는 분야입니다.