
Bare-metal과 RTOS 기반 펌웨어 개발의 차이를 비교한 이미지로, 단순한 MCU 제어와 멀티태스크·확장성을 갖춘 RTOS 구조를 대비해 보여준다.
개요
펌웨어는 마이크로프로세서 같은 작은 반도체 칩에서 동작하는 소프트웨어다. 일반적인 PC 프로그램이 운영체제 위에서 사용자 입력, 파일, 네트워크 같은 자원을 다룬다면, 펌웨어는 더 낮은 수준에서 하드웨어를 직접 제어한다.
펌웨어의 핵심 역할은 하드웨어 핀과 디지털 신호를 제어해 제품이 실제로 동작하도록 만드는 것이다. 즉, PCB 위의 회로, 프로세서의 핀 설정, 센서나 통신 모듈 같은 디지털 장치 제어가 펌웨어의 주요 관심사다.1
펌웨어 애플리케이션은 크게 두 가지 방식으로 나눌 수 있다. 하나는 별도 운영체제 없이 동작하는 Bare-metal 애플리케이션이고, 다른 하나는 RTOS, 즉 실시간 운영체제 기반 애플리케이션이다.
펌웨어 애플리케이션의 두 가지 방식
Bare-metal 방식은 운영체제 없이 작성된 코드가 하드웨어 위에서 직접 실행되는 구조다. 시스템이 단순하고 해야 할 일이 명확할 때 적합하다.
RTOS 기반 방식은 Real-Time Operating System 위에서 여러 작업을 나누어 실행하는 구조다. 여러 기능이 동시에 동작하거나, 기능별 우선순위와 자원 공유를 체계적으로 관리해야 할 때 유리하다.
두 방식은 "어느 쪽이 무조건 더 좋다"기보다 제품의 복잡도, 전력 조건, 메모리 여유, 실시간 요구사항에 따라 선택해야 한다.
Bare-metal 애플리케이션
Bare-metal 애플리케이션은 별도의 운영체제 없이 동작하는 펌웨어다. 전원이 공급되면 bootloader 실행, protocol stack 초기화, 주변 장치 설정 같은 기본 세팅을 먼저 수행한다. 이후에는 보통 for(;;){...} 형태의 단일 무한 루프를 반복 실행한다.
이 구조에서는 코드 흐름이 비교적 단순하다. 메인 루프 안에서 센서 값을 읽고, 조건을 확인하고, 통신을 처리하고, 출력을 제어하는 식으로 순차적으로 동작한다.
단일 루프 흐름을 벗어나는 대표적인 방식은 인터럽트 서비스 루틴, 즉 ISR이다. 예를 들어 특정 핀에 신호가 들어오거나 타이머 이벤트가 발생하면, 메인 루프와 별개로 ISR이 실행되어 긴급한 처리를 수행할 수 있다.
Bare-metal 방식의 예로는 nRF5 SDK 기반 Nordic BLE 칩 개발, nRF52832, nRF52840, Arduino 기반 IoT 기기 등이 있다.
Bare-metal의 장점은 가볍다는 점이다. 운영체제 계층이 없기 때문에 전력 소모와 메모리 사용량이 적은 편이고, 구조가 단순해 빠르게 동작할 수 있다. 작은 IoT 기기처럼 제한된 기능만 수행하는 장치에서는 이 단순함이 큰 장점이 된다.
반면 기능이 늘어나면 단점이 뚜렷해진다. 모든 로직을 하나의 메인 루프 안에서 관리해야 하므로, 센서 처리, 통신, 상태 관리, 예외 처리 등이 뒤섞이기 쉽다. 여기에 전역 변수를 많이 사용하거나 모듈화가 부족하면 코드 흐름을 추적하기 어려워지고 유지보수 비용이 커진다.
RTOS 기반 애플리케이션
RTOS 기반 애플리케이션은 Real-Time Operating System, 즉 실시간 운영체제를 기반으로 동작하는 펌웨어다. 이 방식에서는 여러 thread를 만들고, RTOS가 각 thread의 실행 순서, 자원 배분, 우선순위, 동작 규칙을 관리한다.
예를 들어 센서 측정 thread, BLE 통신 thread, 데이터 저장 thread, UI 처리 thread를 분리할 수 있다. 이렇게 기능별로 작업 단위를 나누면 코드 구조를 이해하기 쉬워지고, 각 기능을 독립적으로 개발하거나 수정하기도 편해진다.
RTOS에서는 Semaphore, Mutex, ISR 같은 메커니즘을 활용해 자원 접근과 실행 우선순위를 제어할 수 있다. 여러 thread가 같은 자원에 접근할 때 충돌을 막거나, 더 중요한 작업이 먼저 실행되도록 설계할 수 있다.
Nordic의 nRF Connect SDK, NCS는 Zephyr RTOS 기반이다. 이는 복잡한 IoT 애플리케이션을 RTOS 구조 위에서 개발할 수 있도록 하는 대표적인 예다.
RTOS의 장점은 복잡한 애플리케이션을 구조적으로 구성하기 좋다는 점이다. 기능별 thread 분리가 가능하고, 함수, 라이브러리, 드라이버, 프로토콜 스택 등 기존 자원을 활용하기 쉽다. 여러 기능이 동시에 동작해야 하는 제품에서는 Bare-metal보다 설계가 깔끔해질 수 있다.
하지만 RTOS를 사용한다고 자동으로 성능이 좋아지는 것은 아니다. thread를 어떻게 나눌지, 우선순위를 어떻게 둘지, 공유 자원을 어떻게 보호할지에 따라 성능과 안정성이 크게 달라진다. RTOS는 도구일 뿐이며, 최종 효율은 개발자의 설계 역량에 많이 의존한다.
Bare-metal vs RTOS 비교
| 비교 항목 | Bare-metal | RTOS 기반 |
|---|---|---|
| OS 유무 | 없음 | 있음 |
| 실행 방식 | 단일 메인 루프 중심 | 여러 thread를 RTOS가 관리 |
| 예외/동기화 | 주로 ISR 사용 | ISR, Semaphore, Mutex 등 사용 |
| 자원 사용 | 전력과 메모리 사용이 적은 편 | 관리 오버헤드는 있지만 구조화에 유리 |
| 개발 난이도 | 단순 시스템에는 쉽지만, 기능 증가 시 복잡도 증가 | 초기 학습 부담은 있으나 복잡한 시스템에 유리 |
| 적합한 경우 | 단순, 저전력, 제한된 기능의 기기 | 복수 기능, 실시간 작업, 확장성이 필요한 기기 |
Bare-metal은 단순한 흐름을 빠르고 가볍게 실행하는 데 강점이 있다. 반대로 RTOS는 여러 작업을 나누고 조율하는 데 강점이 있다. 따라서 작은 장치에서 하나의 목적만 수행한다면 Bare-metal이 적합할 수 있고, 통신, 센서, 저장, UI 같은 여러 기능이 함께 돌아가야 한다면 RTOS가 더 적합할 수 있다.
핵심 정리
펌웨어는 하드웨어 레벨의 디지털 신호를 제어하는 소프트웨어다. 제품이 실제로 동작하려면 프로세서의 핀, 회로, 주변 장치, 통신 모듈을 펌웨어가 적절히 제어해야 한다.
Bare-metal은 운영체제 없이 동작하기 때문에 가볍고 단순하다. 전력과 메모리가 제한된 시스템에서 유리하지만, 기능이 많아질수록 메인 루프가 복잡해지고 코드 관리가 어려워질 수 있다.
RTOS는 복잡한 시스템을 thread 단위로 나누어 관리하기 좋다. 여러 기능이 동시에 동작하는 제품에서 구조화와 확장성에 유리하다. 다만 RTOS를 도입했다고 자동으로 좋은 시스템이 되는 것은 아니며, thread 설계와 자원 공유 방식이 중요하다.
결국 선택 기준은 제품의 요구사항이다. 단순한 IoT 기기에는 Bare-metal이 충분할 수 있고, 여러 기능이 동시에 실행되어야 하는 제품에는 RTOS 기반 구조가 더 적합할 수 있다.
출처
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.
