FreeRTOS 커널이 9KB인 이유 — 에지 디바이스를 위한 경량 OS의 설계 원칙
FreeRTOS 태스크·동기화·메모리 관리부터 Zephyr·RIOT 비교, 엣지 컨테이너와 KubeEdge까지 경량 실시간 OS를 실무 관점에서 정리한다
2026-08-12 · 최초 발행 2026-01-19
클라우드로 데이터를 보내고 처리 결과를 다시 받아오는 왕복 구조는 밀리초 단위 응답이 필요한 상황에서 근본적인 한계에 부딪힌다. 에지 컴퓨팅은 데이터가 생성되는 지점 가까이에서 연산과 저장을 수행해 이 왕복을 줄이는 접근이고, IoT 센서·자율주행차처럼 실시간성이 요구되는 영역에서 특히 중요해진다.
클라우드 중심 구조가 부딪히는 벽
데이터를 클라우드로 보내지 않고 로컬에서 처리하면 밀리초 수준의 응답시간을 확보할 수 있고, 원시 데이터를 전부 전송하는 대신 필터링·집계한 결과만 올리면 네트워크 부하가 줄어든다. 민감한 데이터를 로컬에서 처리해 외부 노출을 최소화할 수 있고, 네트워크 연결이 끊겨도 독립적으로 동작할 수 있으며, 중앙 서버에 몰리던 부하가 여러 에지 노드로 분산돼 시스템 전체의 확장성도 올라간다.
디바이스 레이어가 센서 데이터를 수집하고 기본 전처리를 하면, 에지 레이어가 실시간 분석과 로컬 의사결정을 담당한다. 여러 에지 노드를 조율하고 중급 데이터 처리를 하는 게 포그 레이어이고, 대규모 데이터 분석과 AI 모델 학습, 장기 저장은 여전히 클라우드 레이어의 몫이다. 즉 에지 컴퓨팅은 클라우드를 대체하는 게 아니라 역할을 나누는 구조다.
에지용 OS에게 요구되는 것
에지 환경에 최적화된 OS는 데스크톱·서버용 OS와 요구사항 자체가 다르다. 메모리 사용량이 수 KB에서 수십 MB 수준으로 작아야 하고(작은 풋프린트), 응답시간이 예측 가능해야 하며 우선순위 기반 스케줄링이 필요하고(실시간 성능), 저전력 모드와 동적 전원 관리를 지원해야 하고(전력 효율), 하드웨어 기반 보안과 안전한 부팅이 필요하며, OTA(Over-The-Air) 업데이트로 원격 관리가 가능해야 한다.
이 요구사항을 채우는 대표적인 OS로는 마이크로컨트롤러용 실시간 OS이자 AWS IoT와 통합되는 FreeRTOS, Linux Foundation이 관리하는 다양한 하드웨어 지원 RTOS인 Zephyr, IoT 특화 모듈식 설계의 RIOT, 저전력 무선 네트워크에 최적화된 Contiki-NG, Microsoft의 보안 강화 IoT OS인 Azure Sphere OS, 그리고 여러 OS를 아우르는 프레임워크인 EdgeX Foundry가 있다.
FreeRTOS 안을 들여다보면
FreeRTOS는 커널 바이너리 크기가 약 9KB에 불과하면서도 ARM Cortex-M, RISC-V, x86을 포함해 40개 이상의 아키텍처를 지원한다. MIT 라이선스라 상업적 사용에 제약이 없고, AWS IoT Core와 긴밀히 통합돼 있으며 활발한 오픈소스 커뮤니티와 상업 지원을 함께 갖췄다.
FreeRTOS의 핵심은 태스크(Task) 관리다.
void vTaskFunction(void *pvParameters) {
for (;;) {
// 태스크 로직
vTaskDelay(pdMS_TO_TICKS(1000));
}
}
xTaskCreate(
vTaskFunction, // 태스크 함수
"TaskName", // 태스크 이름
128, // 스택 크기
NULL, // 파라미터
1, // 우선순위
&xTaskHandle // 태스크 핸들
);스케줄링은 우선순위가 높은 태스크가 먼저 실행되는 것이 기본이고, 동일 우선순위 태스크끼리는 시간을 나눠 쓰는 Round-Robin으로 처리된다. configUSE_PREEMPTION 설정으로 협력적 스케줄링과 선점형 스케줄링 중 선택할 수 있고, 실행할 태스크가 없을 때는 최하위 우선순위의 아이들 태스크가 돈다.
태스크 간 통신·동기화는 다섯 가지 메커니즘으로 나뉜다. 큐(Queue)는 FIFO 방식으로 메시지를 전달하고 크기 제한을 설정할 수 있으며, 세마포어(Semaphore)는 바이너리·카운팅 방식으로 자원 접근을 제어한다. 뮤텍스(Mutex)는 우선순위 상속을 지원해 데드락을 방지하고, 이벤트 그룹(Event Group)은 여러 이벤트를 비트 플래그로 관리하며, 스트림 버퍼(Stream Buffer)는 바이트 스트림을 전송하고 인터럽트에서도 사용 가능하다.
메모리 할당 전략도 제한된 자원에 맞춰 다섯 단계로 나뉜다. heap_1은 할당만 가능하고 해제는 불가능한 가장 단순한 방식이고, heap_2는 할당·해제는 되지만 메모리 병합이 없다. heap_3는 표준 malloc/free를 그대로 감싼 것이고, heap_4는 할당·해제에 인접 블록 병합까지 지원하며, heap_5는 heap_4에 비연속 메모리 영역 지원을 더한 것이다. 어떤 heap을 쓸지는 결국 파편화를 얼마나 신경 써야 하는 환경인지에 달려 있다.
FreeRTOS만이 답은 아니다
| 특성 | FreeRTOS | Zephyr |
|---|---|---|
| 커널 크기 | 약 9KB | 약 8KB |
| 라이선스 | MIT | Apache 2.0 |
| 하드웨어 지원 | 40+ 아키텍처 | 300+ 보드 |
| 네트워크 스택 | lwIP, FreeRTOS+TCP | 자체 네트워크 스택 |
| 개발 도구 | 다양한 IDE 지원 | West 빌드 시스템 |
| 생태계 | AWS 통합 | Linux Foundation |
Zephyr는 커널 크기 자체는 FreeRTOS와 비슷하지만 지원 보드 수가 훨씬 많고 Linux Foundation 산하 프로젝트라는 점에서 생태계 성격이 다르다. RIOT는 POSIX 호환 API로 표준 C/C++를 그대로 쓸 수 있고, 6LoWPAN·CoAP·MQTT 같은 IoT 프로토콜을 커널에 내장했으며, 필요한 기능만 골라 빌드하는 모듈식 설계에 마이크로초 수준의 인터럽트 지연시간을 낸다.
엣지에도 컨테이너를 올리는 이유
RTOS가 마이크로컨트롤러급 디바이스를 위한 것이라면, 그보다 여유 있는 에지 노드에서는 컨테이너 기술도 쓰인다. 여러 워크로드를 같은 하드웨어에서 안전하게 격리하고, 동일한 이미지를 다양한 디바이스에 이식하고, 컨테이너 단위로 롤링 업데이트하고, CPU·메모리 제한으로 자원을 관리할 수 있다는 게 이유다. 표준 Docker와 그 코어인 containerd, 데몬 없이 rootless로 도는 Podman, 100MB 미만의 경량 Kubernetes인 K3s, Canonical의 MicroK8s가 에지 환경에 맞춰진 런타임들이다.
Kubernetes를 에지까지 확장하는 KubeEdge는 클라우드 측 CloudCore와 에지 측 EdgeCore로 나뉜다.
CloudCore는 에지 노드와 통신하는 클라우드 측 관리 컴포넌트이고, EdgeCore는 에지 노드에서 실행되는 경량화된 kubelet인 Edged를 품고 있다. EdgeHub가 클라우드와 에지 사이의 신뢰성 있는 통신을 담당하는 동안, MetaManager는 로컬 메타데이터를 캐싱해 네트워크가 끊겨도 에지 노드가 독립적으로 동작할 수 있게 한다. 이미지 크기를 줄이는 데는 멀티 스테이지 빌드, Alpine 같은 수 MB짜리 베이스 이미지, 변경 없는 레이어의 캐싱, squash·gzip 압축, 그리고 에지 게이트웨이에 둔 로컬 레지스트리가 함께 쓰인다.
물리적으로 노출된 디바이스의 보안 문제
에지 디바이스는 보호되지 않은 물리적 환경에 놓이는 경우가 많고, 복잡한 암호화·인증 알고리즘을 돌리기엔 자원이 제한적이며, 이기종 하드웨어마다 일관된 보안 정책을 적용하기 어렵고, 업데이트 주기가 길어 취약점이 노출되는 시간도 길어진다. 대응책은 신뢰할 수 있는 펌웨어만 실행하는 시큐어 부트, TPM·Secure Element로 키를 저장하는 하드웨어 보안 모듈(HSM), 에지-클라우드 간 통신을 암호화하는 TLS, Trivy·Clair 같은 도구로 하는 컨테이너 스캐닝, 네트워크 세그먼트화, 그리고 애플리케이션에 필요한 최소한의 권한만 주는 최소 권한 원칙이다.
에지에서 도는 AI
AI 모델을 에지 디바이스에서 실행하려면 먼저 모델 자체를 가볍게 만들어야 한다. Quantization과 Pruning으로 모델 크기와 연산량을 줄이고, TensorFlow Lite나 ONNX Runtime 같은 경량 추론 프레임워크를 쓰며, Google의 Edge TPU나 Intel의 OpenVINO 같은 전용 가속기·툴킷을 활용한다. 학습까지 에지에서 하려는 경우에는 데이터를 중앙으로 모으지 않고 분산 학습하는 Federated Learning, 사전 학습 모델을 로컬 데이터로 파인튜닝하는 Transfer Learning, 실시간 데이터로 모델을 점진적으로 업데이트하는 Online Learning이 쓰인다.