실시간 운영체제(RTOS, Real-Time Operating System)

1. 개요

가. 정의

실시간 운영체제(RTOS) 는 정해진 시간(마감시간, deadline) 안에 반드시 응답한다는 시간 제약(timing constraint)을 지키도록 설계된 운영체제다. 핵심 가치는 '얼마나 빠른가(throughput)'가 아니라 '언제 끝날지 예측 가능한가(determinism)'에 있다.

RTOS가 등장한 배경은 임베디드 제어의 본질에 있다. 에어백 전개, 모터 제어, 항공기 비행 제어, 산업 PLC처럼 물리 세계와 맞물려 동작하는 시스템에서는 '평균적으로 빠른 응답'이 아니라 '최악의 경우에도 정해진 시한 안에 끝나는 응답'이 안전과 직결된다. 에어백이 충돌 후 평균 10ms에 터지더라도 어쩌다 한 번 50ms가 걸리면 탑승자는 사망할 수 있다. 범용 운영체제(GPOS, General-Purpose OS)는 전체 처리량과 공평성을 높이기 위해 설계되어 응답 시간의 상한을 보장하지 못하므로, 이러한 요구를 충족하기 위해 결정성을 1차 목표로 삼는 RTOS가 필요해졌다.

따라서 RTOS를 이해하는 출발점은 '빠름'과 '예측 가능함'을 구분하는 것이다. GPOS가 통계적 성능(평균 지연, 처리량)을 추구한다면, RTOS는 지연의 상한(bounded latency) 과 최악 실행시간(WCET, Worst-Case Execution Time) 을 기준으로 설계·검증된다. 아무리 평균 성능이 뛰어나도 상한을 보증하지 못하면 실시간 시스템으로서는 실패다.

나. 실시간성의 분류와 특징

RTOS가 보장해야 하는 '실시간성'은 마감시간을 어겼을 때의 결과에 따라 세 가지로 나뉜다. 이 구분은 단순한 분류가 아니라 어느 수준의 검증·여유(margin)에 투자할지를 결정하는 설계 기준이 된다.

구분	마감 위반 시 결과	사례
경성(Hard)	시스템 실패·인명 피해	에어백, 항공 비행제어, 원자로 제어
반경성(Firm)	결과 가치 상실(위험은 아님)	산업 비전검사, 실시간 거래 체결
연성(Soft)	품질 저하(허용 가능)	동영상 스트리밍, VoIP

경성 실시간은 마감 위반이 곧 재앙이므로 100% 마감 준수를 수학적으로 증명(스케줄 가능성 분석)해야 하고, 연성 실시간은 간헐적 위반을 품질 저하로 감내한다. 이 때문에 경성 시스템일수록 WCET 산정, 캐시·파이프라인의 불확정성 제거, 인터럽트 지연의 상한 보장에 많은 비용을 들인다. 지연의 흔들림인 지터(jitter) 를 얼마나 억제하느냐가 RTOS 품질의 또 다른 척도다.

여기서 주의할 점은 실시간성이 '절대적으로 빨라야 함'을 뜻하지 않는다는 것이다. 마감시간이 1초인 시스템이라면 응답이 0.9초여도 '실시간'이고, 마감이 1ms인데 평균 0.5ms라도 최악이 1.2ms라면 '비실시간'이다. 즉 실시간의 기준은 속도의 절대값이 아니라 선언된 마감에 대한 상대적 보장 여부다. 이 관점의 전환이 RTOS 설계·분석의 출발점이며, 시험 답안에서도 '빠른 OS'로 서술하면 핵심을 놓친 것으로 간주된다.

2. RTOS의 핵심 개념과 전체 구조

RTOS의 결정성은 몇 가지 메커니즘이 맞물려 구현된다. 가장 중요한 것은 선점형 우선순위 스케줄링(preemptive priority scheduling) 이다. 준비(ready) 상태인 태스크 중 항상 우선순위가 가장 높은 것을 즉시 실행하고, 더 높은 우선순위 태스크가 깨어나면 실행 중인 태스크를 즉시 선점한다. 이 규칙이 지켜지는 한, 어떤 태스크가 언제 CPU를 얻을지 분석적으로 계산할 수 있다.

두 번째는 빠르고 상한이 보장된 문맥 전환(context switch)과 인터럽트 응답이다. GPOS는 처리량을 위해 인터럽트를 길게 비활성화하기도 하지만, RTOS는 인터럽트 비활성 구간을 최소화하고 그 상한을 명시해 외부 이벤트에 수 마이크로초 단위로 반응한다. 세 번째는 우선순위 역전 방지다. 공유 자원을 보호하는 뮤텍스에 우선순위 상속(Priority Inheritance)·상한(Priority Ceiling) 프로토콜을 적용해, 낮은 우선순위 태스크가 높은 태스크를 무한정 가로막는 현상을 유계화한다([[priority-inversion]] 참조).

graph TD
  subgraph APP["응용 계층"]
    T1["태스크A(높음)"]
    T2["태스크B(중간)"]
    T3["태스크C(낮음)"]
  end
  subgraph KERNEL["RTOS 커널"]
    SCH["스케줄러(선점형 우선순위)"]
    IPC["IPC(세마포어·큐·뮤텍스)"]
    MEM["메모리관리(고정블록)"]
    TMR["타이머·틱 서비스"]
  end
  subgraph HW["하드웨어"]
    CPU["CPU/MPU"]
    INT["인터럽트 컨트롤러"]
  end
  T1 --> SCH
  T2 --> SCH
  T3 --> SCH
  SCH --> CPU
  INT -->|ISR| SCH
  IPC --- SCH
  TMR --> SCH
  MEM --- CPU

위 구조도에서 응용 태스크들은 커널의 스케줄러를 통해서만 CPU를 할당받는다. 외부 이벤트는 인터럽트 컨트롤러를 거쳐 ISR(Interrupt Service Routine)로 전달되고, ISR은 최소한의 처리만 한 뒤 세마포어·큐를 통해 관련 태스크를 깨우는 지연 처리(deferred processing) 구조를 취한다. ISR 안에서 모든 일을 처리하면 인터럽트 비활성 구간이 길어져 다른 이벤트 응답이 늦어지므로, '짧은 ISR + 태스크 위임'이 RTOS 설계의 정석이다.

메모리 관리도 GPOS와 다르다. 범용 OS의 가변 크기 동적 할당(malloc)은 단편화로 인해 할당 시간이 들쭉날쭉해 결정성을 해친다. 그래서 RTOS는 고정 크기 블록 풀(fixed-size memory pool) 방식으로 상수 시간 할당을 보장하거나, 아예 동적 할당을 금지(MISRA C 등 안전 코딩 규칙)하고 정적 할당만 쓰기도 한다.

결국 RTOS의 결정성은 '어느 한 가지 비법'이 아니라 여러 비결정성 요인을 하나씩 제거·유계화한 결과다. 스케줄링의 비결정성은 선점형 우선순위로, 인터럽트의 비결정성은 비활성 구간 최소화로, 메모리의 비결정성은 고정블록으로, 자원 경합의 비결정성은 우선순위 상속으로 각각 다스린다. 이 중 하나라도 무너지면 전체 응답시간의 상한이 깨지므로, RTOS 설계는 '최악의 경우'를 끝까지 추적하는 보수적 사고를 요구한다.

3. RTOS 아키텍처와 구성요소

RTOS 커널은 대개 마이크로커널(microkernel) 지향이다. 스케줄링·IPC·타이머 등 최소 기능만 커널 모드에 두고, 파일시스템·네트워크 스택 등은 사용자 영역 서버나 미들웨어로 분리한다. 이렇게 하면 커널이 작고 검증 범위가 좁아져, 안전 인증(항공 DO-178C, 자동차 ISO 26262)을 받기 유리하다. 아래는 태스크의 상태 전이와 커널 서비스의 관계를 보여 주는 세부도다.

stateDiagram-v2
  [*] --> Ready: 생성 create
  Ready --> Running: 디스패치 최고우선순위
  Running --> Ready: 선점 preempt
  Running --> Blocked: 자원대기 P연산·지연
  Blocked --> Ready: 자원반납 V연산·타임아웃
  Running --> Suspended: 명시적 중단
  Suspended --> Ready: 재개 resume
  Running --> [*]: 종료 delete

가. 태스크와 스케줄러

태스크(또는 스레드)는 RTOS의 실행 단위로, 각자 우선순위·스택·문맥(레지스터 집합)을 가진다. 스케줄러는 매 스케줄링 시점(틱 인터럽트, 블로킹 호출, 인터럽트 복귀)마다 Ready 큐에서 최고 우선순위 태스크를 골라 디스패치한다. 동일 우선순위 태스크가 여럿이면 라운드로빈(time slicing)으로 공평하게 나누기도 한다. 이 상태 전이가 O(1) 상수 시간에 이뤄지도록 비트맵 기반 우선순위 테이블을 쓰는 것이 FreeRTOS·μC/OS 등의 공통 기법이다.

나. 태스크 간 통신·동기화(IPC)

여러 태스크가 협력하려면 데이터를 주고받고 실행 순서를 맞춰야 한다. RTOS는 세마포어(동기화·자원 카운트), 메시지 큐(데이터 전달), 뮤텍스(상호배제), 이벤트 플래그(다중 조건 대기) 를 제공한다. 특히 뮤텍스는 우선순위 상속을 내장해 우선순위 역전을 막는다. 예컨대 FreeRTOS의 뮤텍스는 획득한 저우선순위 태스크가 대기 중인 고우선순위 태스크의 우선순위를 일시 상속받아 임계구역을 빨리 빠져나오게 한다.

이때 세마포어와 뮤텍스를 구분하는 것이 실무의 함정이다. 둘 다 상호배제에 쓸 수 있지만, 소유권(ownership) 개념이 다르다. 뮤텍스는 잠근 태스크만 풀 수 있어 소유자를 특정할 수 있으므로 우선순위 상속이 가능하지만, 이진 세마포어는 아무 태스크나 반납할 수 있어 소유자를 알 수 없고 따라서 상속을 걸 수 없다. 그래서 '자원 보호에는 뮤텍스, 이벤트 신호(ISR→태스크 통지)에는 세마포어'라는 원칙이 서며, 이를 혼동해 세마포어로 자원을 보호하면 우선순위 역전이 다시 열리는 결함을 낳는다.

다. 시간 관리와 인터럽트

RTOS는 시스템 틱(system tick) 타이머로 시간을 센다. 틱마다 지연(delay)이 만료된 태스크를 깨우고 타임슬라이스를 갱신한다. 다만 틱 주파수가 너무 높으면 오버헤드가 커지고 낮으면 시간 해상도가 떨어지므로, 최근에는 틱이 필요 없을 때 타이머를 멈추는 틱리스(tickless) 모드로 저전력과 정밀도를 함께 추구한다. 인터럽트 지연(interrupt latency)과 스케줄링 지연의 합인 태스크 응답시간의 상한을 보장하는 것이 커널 설계의 핵심 목표다.

4. 스케줄링 기법 비교

실시간 스케줄링은 우선순위를 '고정'하느냐 '동적'으로 바꾸느냐로 갈린다. 두 대표 알고리즘의 차이는 단순한 구현 차이가 아니라 스케줄 가능성(schedulability)의 상한에서 비롯된다.

기법	우선순위 부여	스케줄 가능 한계(단일 CPU)	특징
RMS(Rate Monotonic)	주기 짧을수록 높음(고정)	약 69.3%(n→∞, `n(2^(1/n)-1)`)	정적·단순·예측 쉬움
EDF(Earliest Deadline First)	마감 임박할수록 높음(동적)	100%	최적이나 오버런 시 연쇄 붕괴

RMS는 주기가 짧은(자주 실행되는) 태스크에 높은 우선순위를 고정 부여한다. 구현이 단순하고 분석이 쉬워 산업에서 널리 쓰이지만, CPU 이용률이 이론적 상한(태스크 수가 많아질수록 약 69.3%)을 넘으면 마감을 보장할 수 없다. 즉 CPU의 약 30%를 '여유'로 비워 둬야 안전하다는 뜻으로, 이는 비용이지만 예측 가능성이라는 가치를 사는 대가다.

EDF는 그 순간 마감이 가장 임박한 태스크에 최고 우선순위를 동적으로 준다. 단일 프로세서에서 이용률 100%까지 모든 마감을 지킬 수 있는 최적 알고리즘이지만, 과부하(overrun)가 생기면 어떤 태스크가 먼저 마감을 어길지 예측하기 어려워 연쇄적 마감 실패(domino effect) 위험이 있다. 그래서 안전이 중요한 경성 시스템은 분석이 명료한 RMS를, 이용률을 쥐어짜야 하는 시스템은 EDF를 택하는 식으로 트레이드오프가 갈린다. 실제 자동차 AUTOSAR의 OS는 고정 우선순위 선점 방식을 기본으로 하여 RMS 계열의 분석 가능성을 중시한다.

가. RMS 스케줄 가능성 — 수치 예시

구체적으로 세 태스크가 있다고 하자. 태스크1은 주기 50ms에 실행시간 10ms, 태스크2는 주기 100ms에 20ms, 태스크3은 주기 200ms에 40ms다. 각 태스크의 CPU 이용률은 10/50=0.2, 20/100=0.2, 40/200=0.2로 합이 0.6이다. RMS의 이용률 상한은 태스크 수 3일 때 3(2^(1/3)-1)≈0.78이므로, 총 이용률 0.6은 상한 0.78보다 작아 세 태스크 모두 마감을 지킬 수 있음이 보장된다. 만약 태스크3의 실행시간을 60ms로 늘려 총 이용률이 0.7이 되면 여전히 상한 아래라 안전하지만, 90ms(0.85)로 늘리면 Liu-Layland 상한을 넘어 이 간단한 판정만으로는 보장할 수 없게 되어 정밀한 응답시간 분석(RTA, Response-Time Analysis)이 필요해진다. 이처럼 RMS는 '계산으로 안전을 증명'할 수 있다는 점이 산업에서 선호되는 이유다.

5. GPOS와의 비교, 그리고 적용 사례

RTOS와 GPOS의 차이는 '무엇을 최적화하는가'라는 설계 목표의 차이에서 비롯된다. 아래 비교는 단순 기능 나열이 아니라, 왜 하나의 OS로 두 요구를 모두 만족시키기 어려운지를 보여 준다.

관점	RTOS	GPOS(리눅스·윈도우)
1차 목표	결정성(응답 상한)	처리량·공평성
스케줄링	선점형 우선순위, 상한 보장	CFS 등 공평성 위주
커널 지연	수 μs, 상한 명시	수 ms, 비결정적
메모리	고정블록·정적 할당	가상메모리·페이징
규모	수 KB~수백 KB	수십 MB 이상

하나의 OS로 두 요구를 모두 만족시키기 어려운 근본 이유는 최적화 대상이 상충하기 때문이다. 처리량과 공평성을 높이려면 스케줄러는 캐시 적중을 노려 실행 순서를 재배치하고 인터럽트를 묶어 처리하며 지연 쓰기(write-back)로 I/O를 모으는데, 이 모든 기법이 '평균'을 좋게 하는 대신 '최악'을 예측 불가능하게 만든다. 반대로 RTOS는 최악을 유계화하기 위해 평균 성능을 일부 희생한다. 그래서 전통적으로는 역할을 나눠 각기 다른 OS를 썼고, 최근에야 멀티코어와 하이퍼바이저로 한 칩에서 둘을 공존시키는 접근이 현실화되고 있다.

실제 사례를 보면 설계 목표의 차이가 분명해진다. 첫째, 자동차 전자제어장치(ECU) 는 엔진·제동 제어에 OSEK/VDX 기반 AUTOSAR Classic OS를 쓴다. 엔진 분사 타이밍은 크랭크각에 따라 수백 μs 단위로 제어되어야 하므로, 평균 성능이 아무리 좋아도 상한이 보장되지 않는 GPOS로는 불가능하다. 둘째, 화성 탐사 로버는 Wind River의 VxWorks를 탑재해 왔는데, 1997년 마스 패스파인더의 재부팅 장애가 우선순위 역전 때문이었고 우선순위 상속을 원격 패치해 해결한 일화는 RTOS 설계의 교과서적 사례로 남아 있다. 셋째, 소형 IoT·웨어러블은 수 KB RAM에서 도는 FreeRTOS(2017년 AWS 인수)나 Zephyr를 써서, 밀리와트 단위 전력으로 센서 샘플링과 무선 통신의 타이밍을 맞춘다.

6. 심화 — 최신 동향과 혼합 임계도

최근 RTOS 영역의 가장 큰 변화는 범용 OS와 실시간성의 경계가 허물어지고 있다는 점이다. 리눅스의 실시간 패치인 PREEMPT_RT 가 오랜 외부 패치 기간을 거쳐 2024년 Linux 6.12 커널에 상당 부분 메인라인으로 병합되면서, 리눅스로도 제한적 경성 실시간에 근접한 응답을 얻을 수 있게 되었다. 이는 하나의 SoC에서 리치한 응용(리눅스)과 실시간 제어를 함께 돌리려는 산업·로봇 수요를 반영한다.

다만 PREEMPT_RT가 모든 경성 실시간을 대체하지는 못한다. 리눅스는 여전히 커널 규모가 크고 가상메모리·캐시의 비결정성을 완전히 제거하기 어려워, 마이크로초 단위의 엄격한 마감이 걸린 제어 루프에는 전용 RTOS나 별도 코어가 함께 쓰인다. 즉 '리눅스가 RTOS를 대체'하는 것이 아니라, 느슨한 실시간은 리눅스가 흡수하고 엄격한 실시간은 RTOS가 맡는 역할 분담의 재편으로 이해하는 것이 정확하다.

이와 맞물려 혼합 임계도(Mixed-Criticality) 시스템이 부상한다. 하나의 멀티코어 칩에서 안전등급이 다른 기능(예: 자율주행의 안전 제어와 인포테인먼트)을 함께 돌리되, 하이퍼바이저(예: Xen, PikeOS, QNX Hypervisor)로 코어·메모리·주변장치를 격리해 저등급 기능의 오작동이 고등급 기능의 타이밍을 침범하지 못하게 한다. 이때 캐시·메모리 대역폭 같은 공유 자원의 간섭(interference)을 어떻게 유계화하느냐가 분석의 난제로 남아 있다.

표준·생태계 측면에서는 Linux Foundation의 Zephyr Project 가 수백 개 보드를 지원하며 오픈소스 RTOS의 사실상 표준으로 성장하고 있고, 산업 네트워크의 결정성을 보장하는 TSN(Time-Sensitive Networking) 과 RTOS가 결합해 '칩에서 네트워크까지' 종단 간 실시간성을 추구하는 방향이 뚜렷하다. 예상 출제 방향으로는 ① 경성/연성 구분과 스케줄 가능성 분석(RMS 이용률 한계 계산), ② 우선순위 역전과 상속·상한 프로토콜, ③ 혼합 임계도·하이퍼바이저 격리, ④ RTOS vs GPOS(PREEMPT_RT 포함) 비교가 자주 결합돼 나올 수 있다.

7. 고려사항 및 시사점

기술사 관점에서 RTOS 도입·설계 시 다음을 종합적으로 고려해야 한다.

적용 전략(요구 등급 정합): 모든 기능을 경성으로 설계하면 과도한 여유와 비용이 든다. 기능별로 경성/반경성/연성을 구분하고, 경성 경로에만 WCET 분석과 여유 CPU를 집중 투입하는 임계도 기반 자원 배분이 비용 대비 효과적이다.
트레이드오프(이용률 vs 예측성): RMS는 CPU의 약 30%를 비워 두는 대신 분석이 명료하고, EDF는 이용률을 100%까지 쓰되 과부하 시 붕괴 위험을 안는다. 시스템의 안전 등급과 부하 특성에 맞춰 선택하고, 과부하 처리(마감 미준수 시 성능 저하 모드)를 함께 설계해야 한다.
검증·인증 관점: 경성 시스템은 WCET 산정의 신뢰성이 전체 안전의 토대다. 캐시·분기예측·멀티코어 간섭은 WCET 산정을 어렵게 하므로, 안전 인증(DO-178C, ISO 26262)에서는 결정성을 해치는 하드웨어 기능을 비활성화하거나 그 영향을 보수적으로 상한 처리하는 설계가 요구된다.
전망·연계기술: PREEMPT_RT 메인라인화와 멀티코어 하이퍼바이저로 'RTOS와 GPOS의 통합'이 가속되고 있다. TSN·엣지 AI·기능안전(ISO 26262)·[[priority-inversion]]·[[race-condition]] 등과 연계해, 종단 간 결정성을 보장하는 아키텍처 설계 역량이 점점 중요해진다.

참고자료

FreeRTOS Documentation, https://www.freertos.org/features.html
Zephyr Project (Linux Foundation), https://www.zephyrproject.org/
Linux 6.12 release notes (PREEMPT_RT), https://kernelnewbies.org/Linux_6.12
Liu & Layland, "Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment", https://dl.acm.org/doi/10.1145/321738.321743

한 줄 요약: RTOS는 처리량이 아니라 마감시간 안의 응답을 보장하는 결정성을 1차 목표로, 선점형 우선순위 스케줄링·상한 보장 인터럽트·우선순위 상속/상한·고정블록 메모리로 예측 가능성을 구현하며, RMS(분석 용이·이용률 69.3%)와 EDF(최적·100%)의 트레이드오프 위에서 경성/연성 요구에 맞춰 설계하고, PREEMPT_RT·혼합 임계도·TSN으로 GPOS와의 경계가 허물어지는 방향으로 진화하고 있다.