RTOS: Deadlines and Predictability

2025년 11월 11일 GDG 슈몰세미나 요약입니다.

• 실시간 시스템의 기준은 실행 속도가 아니라 데드라인이다.
• GPOS → Soft RTOS → Hard RTOS 순으로 시간 보장이 엄격해진다.

실시간 시스템을 구분하는 기준은 단순한 실행 속도가 아니라 정해진 시간 안에 작업을 끝낼 수 있는가에 있다. GPOS에서 Soft RTOS, Hard RTOS로 갈수록 데드라인에 대한 요구가 엄격해지며, RTOS는 이러한 시간 제약을 예측 가능한 방식으로 만족시키기 위해 사용된다.

General-Purpose Operating System

• GPOS는 처리량(Throughput)과 공정성(Fairness)을 우선한다.
• Time-sharing으로 여러 프로세스에 CPU를 배분한다.
• 개별 작업의 정확한 종료 시점은 보장하기 어렵다.

GPOS(General-Purpose Operating System)는 일정 시간 동안 가능한 많은 작업을 처리하는 **처리량(Throughput)**과 여러 프로세스에 CPU를 고르게 배분하는 **공정성(Fairness)**을 중요하게 생각한다. Time-sharing과 preemption을 통해 CPU-bound 작업과 I/O-bound 작업을 함께 처리하고 특정 프로세스의 기아를 방지하지만, 개별 작업이 정확히 언제 끝날지는 보장하기 어렵다. Windows나 Linux 같은 범용 운영체제가 일반적인 사용자 환경에는 적합하지만 Hard Real-Time 시스템에는 그대로 사용되기 어려운 이유다.

Real-Time

• Soft Real-Time과 Hard Real-Time 모두 데드라인이 존재한다.
• Soft Real-Time의 지연은 품질 저하로 이어진다.
• Hard Real-Time의 지연은 시스템 실패나 사고로 이어질 수 있다.

Real-Time 문제에는 모두 데드라인이 있지만, 데드라인을 놓쳤을 때의 결과에 따라 Soft Real-Time과 Hard Real-Time으로 나뉜다. Soft Real-Time에서는 영상이 잠시 끊기거나 품질이 낮아지는 정도의 성능 저하가 발생한다. 반면 자동차 브레이크나 에어백처럼 Hard Real-Time이 필요한 영역에서는 한 번의 지연도 제어 실패나 안전사고로 이어질 수 있다.

• 스트리밍의 실시간성은 애플리케이션 레벨에서 처리할 수 있다.
• 버퍼링과 동적 화질 조절로 일시적인 지연을 흡수한다.

스트리밍 서비스의 Soft Real-Time 요구사항은 반드시 RTOS로 해결할 필요가 없다. 애플리케이션이 네트워크 상태와 버퍼 여유를 관찰하면서 화질을 조절하고 데이터를 미리 확보하면, 일시적인 지연을 흡수해 재생 중단을 줄일 수 있다. 데드라인을 반드시 지키기보다 상황에 맞게 품질을 낮춰 사용자 경험을 유지하는 방식이다.

• ABR은 네트워크와 버퍼 상태에 맞춰 다음 세그먼트의 화질을 결정한다.
• MSE는 브라우저에서 미디어 버퍼를 직접 제어할 수 있게 한다.
• 두 기술을 결합해 재생 안정성과 화질을 조절한다.

브라우저에서는 **ABR(Adaptive Bitrate Streaming)**과 **MSE(Media Source Extensions)**를 이용해 이러한 전략을 구현한다. JavaScript가 네트워크와 버퍼 상태를 수집하면 ABR 알고리즘이 다음 미디어 세그먼트의 화질을 결정한다. MSE는 MediaSource와 SourceBuffer를 통해 세그먼트를 버퍼에 추가하고 현재 확보된 재생 구간을 확인할 수 있게 하므로, 애플리케이션은 RTOS 없이도 재생 안정성과 화질 사이의 균형을 조절할 수 있다.

Soft RTOS

• IoT와 웨어러블 기기는 메모리와 전력이 제한적이다.
• 경량 RTOS는 적은 자원으로 빠른 부팅과 주기적인 작업 실행을 지원한다.
• FreeRTOS와 Zephyr가 대표적인 예다.

IoT 기기와 스마트워치 같은 임베디드 환경은 메모리 용량과 전력 예산이 작고 빠른 부팅이 필요하기 때문에 범용 운영체제를 올리기 어렵다. 이때 FreeRTOS나 Zephyr처럼 가벼운 RTOS를 사용하면 제한된 자원 안에서 필요한 작업을 일정한 주기로 실행하면서 부팅 시간과 전력 소모를 줄일 수 있다.

• 개발자가 Task 우선순위와 자원 사용 방식을 직접 설계한다.
• 적은 RAM에서 동작하도록 정적 메모리 할당을 주로 사용한다.
• 추상화가 적은 대신 하드웨어를 직접 제어하는 비중이 높다.

범용 운영체제가 프로세스와 I/O, 메모리, 하드웨어를 풍부한 추상화로 제공한다면, Soft RTOS에서는 개발자가 Task 우선순위와 자원 사용 방식을 더 직접적으로 설계한다. 적은 RAM에서도 동작할 수 있도록 정적 메모리 할당을 주로 사용하고, 필요한 경우 전용 Memory Pool이나 Allocator를 구성한다. 대신 사용할 수 있는 라이브러리와 프레임워크가 제한적이며 데이터시트를 바탕으로 하드웨어 레지스터를 직접 제어해야 하는 경우가 많다.

Hard RTOS

• Hard RTOS는 최악의 상황에서도 데드라인을 보장해야 한다.
• 평균 속도보다 실행 시간의 예측 가능성이 중요하다.
• 지연이 사고로 이어지는 안전 필수 시스템에 사용된다.

Hard RTOS의 목표는 평균적으로 빠르게 실행하는 것이 아니라 **최악의 상황에서도 데드라인을 지키는 결정성(Determinism)**을 확보하는 것이다. 각 Task의 최악 실행 시간을 계산하고 제한할 수 있어야 하므로, 전투기 비행 제어와 센서 퓨전, 자동차 브레이크와 에어백처럼 지연이 곧 사고로 이어지는 안전 필수 시스템에 사용된다. 이를 위해 예측하기 어려운 동작을 줄이고 정적 메모리, 엄격한 우선순위, 우선순위 상속 같은 기법을 활용한다.

• 정적 메모리 할당으로 실행 시간의 변동을 줄인다.
• Strict Priority Scheduling으로 중요한 Task를 먼저 실행한다.
• Priority Inheritance로 우선순위 역전을 완화한다.

범용 운영체제의 동적 메모리 할당, 가상 메모리, Page Fault, GC는 작업 종료 시점을 예측하기 어렵게 만들 수 있다. Hard RTOS는 대부분의 메모리를 정적으로 할당해 Task별 최악 실행 시간을 계산하기 쉽게 만들고, Strict Priority Scheduling으로 중요한 Task가 먼저 실행되도록 한다. 또한 공유 자원을 사용하는 과정에서 높은 우선순위 Task가 불필요하게 지연되지 않도록 우선순위 상속을 적용한다.

우선순위 역전(Priority Inversion)

우선순위 역전은 높은 우선순위 Task가 낮은 우선순위 Task보다 늦게 실행되는 현상이다. 단순히 낮은 우선순위 Task가 먼저 CPU를 사용한다는 뜻이 아니라, 높은 우선순위 Task가 필요한 공유 자원을 낮은 우선순위 Task가 점유하고 있어 실행할 수 없는 상태를 말한다.

낮은 우선순위 Task L이 mutex를 획득한 상태에서 높은 우선순위 Task H가 실행되면, H는 같은 mutex를 요청한 뒤 L이 자원을 반환할 때까지 대기한다. 이때 공유 자원과 무관한 중간 우선순위 Task M이 실행 가능 상태가 되면 스케줄러는 L보다 M을 먼저 실행한다. M이 L을 계속 선점하는 동안 L은 mutex를 해제하지 못하고, 결과적으로 가장 높은 우선순위인 H도 실행되지 못한다. 겉으로는 H가 M보다 우선순위가 높지만 실제 완료 순서는 M → L → H가 되므로 우선순위가 뒤집힌 것처럼 보인다.

Priority Inheritance는 이러한 지연을 제한하기 위한 방법이다. H가 L이 보유한 mutex를 기다리기 시작하면 L이 일시적으로 H의 우선순위를 상속한다. 우선순위가 높아진 L은 M보다 먼저 실행되어 임계 구역을 끝내고 mutex를 반환한다. 이후 L은 원래 우선순위로 돌아가고, H가 공유 자원을 획득해 작업을 계속한다.

번외: 1997년 Mars Pathfinder 시스템 리셋

Mars Pathfinder는 1997년 7월 4일 화성에 착륙한 뒤 며칠 동안 정상적으로 임무를 수행했지만, 기상 관측을 시작한 이후 간헐적으로 전체 시스템이 리셋됐다. Pathfinder의 VxWorks는 선점형 우선순위 스케줄링을 사용했고, 여러 Task는 데이터를 교환하기 위한 공용 information bus에 mutex로 접근했다.

문제는 낮은 우선순위의 기상 관측 Task인 ASI/MET가 information bus에 데이터를 기록하기 위해 mutex를 보유한 순간에 발생했다. 높은 우선순위의 bus distribution Task인 bc_dist가 같은 mutex를 요청하면서 ASI/MET가 자원을 반환할 때까지 대기 상태에 들어갔다. 이 짧은 사이에 중간 우선순위의 통신 Task가 실행되면, 통신 Task는 ASI/MET보다 우선순위가 높기 때문에 이를 선점했다. 그 결과 ASI/MET는 mutex를 해제하지 못했고, bc_dist도 예정된 시간 안에 작업을 끝낼 수 없었다.

Pathfinder는 bc_dist가 다음 bus scheduling 주기 전에 실행을 마치지 못한 상황을 시스템 이상으로 판단해 컴퓨터를 리셋하도록 설계돼 있었다. 리셋은 하드웨어와 소프트웨어를 다시 초기화하고 당시 수행 중이던 지상 명령을 중단시켰다. 이미 수집해 RAM에 저장한 과학·공학 데이터는 복구할 수 있었지만, 그날 남은 작업은 다음 날 다시 수행해야 했다. 즉, 리셋 자체는 시스템을 복구하기 위한 안전장치였지만 반복적인 우선순위 역전이 임무 진행을 지연시킨 것이다.

JPL 팀은 비행 소프트웨어에 남겨 둔 tracing과 debugging 기능을 이용해 문제를 재현하고 실행 순서를 확인했다. 이후 VxWorks의 IPC 메커니즘이 사용하는 mutex에 Priority Inheritance가 적용되도록 전역 설정을 변경했다. 설정이 활성화되면 bc_dist가 mutex를 기다리는 동안 ASI/MET가 높은 우선순위를 상속해 통신 Task보다 먼저 실행되고, 빠르게 mutex를 반환할 수 있다. 이 변경으로 반복적인 시스템 리셋 문제도 해결됐다.

참고: Glenn Reeves, “What really happened on Mars?”

• 실제 시스템에서는 GPOS와 RTOS가 역할을 나눠 동작한다.
• 인포테인먼트와 내비게이션은 GPOS가 담당한다.
• 브레이크와 센서 같은 안전 기능은 Hard RTOS가 담당한다.

실제 제품에서는 하나의 운영체제로 모든 요구사항을 해결하기보다 GPOS와 RTOS가 역할을 나눠 동작하는 경우가 많다. 자율주행차를 예로 들면 인포테인먼트와 내비게이션처럼 일시적인 지연을 품질 저하로 흡수할 수 있는 기능은 GPOS가 담당하고, 브레이크와 모터, 에어백, 센서처럼 주기마다 정해진 시간 안에 계산과 출력을 끝내야 하는 기능은 Hard RTOS가 담당한다.

정리

• RTOS의 핵심은 빠른 실행이 아니라 예측 가능한 실행이다.
• Soft Real-Time은 제한적인 품질 저하를 허용한다.
• Hard Real-Time은 최악의 경우에도 데드라인을 보장해야 한다.

RTOS의 핵심은 빠른 실행보다 예측 가능한 실행이다. Soft Real-Time은 데드라인을 놓쳤을 때 제한적인 품질 저하를 허용하지만, Hard Real-Time은 실패 자체가 치명적이므로 최악의 경우에도 데드라인을 보장해야 한다. 따라서 운영체제는 이름이나 평균 성능이 아니라 시스템의 자원 제약과 실패 비용, 요구되는 시간 보장 수준을 기준으로 선택해야 한다.