왜 “정답의 시각”까지 채점하는 시스템이 필요한가

01편에서 임베디드 시스템의 핵심 제약으로 실시간성(real-time)을 예고했고, 03편에서 임베디드 시스템의 정의와 제약을 다뤘습니다. 이번 편부터는 그 실시간성을 본격적으로 파고듭니다.

일반적인 데스크톱 프로그램에서 “정답”은 오직 결과값이 맞는가로 결정됩니다. 계산기 앱이 2+2를 계산하는 데 1밀리초가 걸리든 1초가 걸리든, 결과가 4이기만 하면 사용자는 크게 신경 쓰지 않습니다. 그런데 자동차의 에어백 제어기를 생각해 봅시다. 충돌 감지 센서가 신호를 보낸 뒤 에어백이 “언젠가는” 펼쳐지는 것으로는 부족합니다. 충돌 후 수십 밀리초 안에 펼쳐지지 않으면, 계산 자체는 정확했더라도 사람을 보호하지 못해 시스템은 실패한 것입니다.

실시간 시스템(real-time system)은 이렇게 계산 결과의 논리적 정확성뿐 아니라, 그 결과가 나오는 시각까지 정답의 일부로 취급하는 시스템입니다. 국제적으로 널리 쓰이는 정의를 풀어 쓰면 다음과 같습니다.

쉽게 말하면: 일반 시스템의 정답은 “무엇을(what)“만 맞으면 되지만, 실시간 시스템의 정답은 “무엇을, 언제까지(when)“까지 맞아야 합니다.

1. hard·soft·firm 실시간 — 데드라인을 놓쳤을 때 무슨 일이 벌어지는가

실시간 시스템은 하나의 종류가 아닙니다. 데드라인(deadline, 결과가 나와야 하는 마감 시각)을 놓쳤을 때 그 대가가 얼마나 심각한지에 따라 세 종류로 나눕니다. 이 구분은 독학사 시험에서 “다음 중 hard real-time의 예로 옳은 것은?” 유형으로 자주 나옵니다.

• 경성 실시간(hard real-time): 데드라인을 단 한 번이라도 놓치면 시스템 전체가 실패로 간주됩니다. 결과가 아무리 논리적으로 정확해도, 늦게 도착한 결과는 무가치하거나 오히려 위험합니다. 예: 에어백 전개, 항공기 비행 제어, 원자로 안전 정지, 공장 로봇팔의 충돌 회피.
• 연성 실시간(soft real-time): 데드라인을 가끔 놓쳐도 시스템이 완전히 망가지지는 않지만, 품질(QoS)이 점진적으로 나빠집니다. 예: 동영상 스트리밍의 프레임 지연, 온라인 게임의 입력 지연, 음성 통화의 패킷 지연.
• 강성 실시간(firm real-time): 데드라인을 놓친 결과는 아무 가치가 없어 그냥 버려지지만, 그렇다고 시스템 전체가 안전 문제로 이어지지는 않습니다. 예: 주가 시세 갱신(늦은 시세는 버림), 방송 자막 동기화 데이터.

쉽게 말하면: hard는 “늦으면 사고”, soft는 “늦으면 불편”, firm은 “늦으면 그 결과는 버리지만 사고는 아님”입니다.

자주 틀리는 점: “실시간 시스템은 무조건 빠른 시스템이다”는 진술은 틀렸습니다. 실시간 시스템의 핵심은 속도의 절댓값이 아니라 정해진 데드라인을 예측 가능하게(deterministically) 지키는 것입니다. 데드라인이 500밀리초로 널널해도 그 500밀리초를 단 한 번도 어기지 않는다면 hard real-time이 될 수 있고, 반대로 평균 응답이 1밀리초로 매우 빨라도 가끔 데드라인을 넘긴다면 hard real-time 요구사항을 만족하지 못합니다. “빠른 컴퓨터”와 “제때 답하는 컴퓨터”는 다른 목표입니다.

2. 태스크 — 실시간 시스템이 반복해서 처리하는 일의 단위

RTOS(Real-Time Operating System)에서 스케줄링과 자원 배분의 대상이 되는 실행 단위를 태스크(task)라고 부릅니다. 08편에서 배운 프로세스·스레드와 성격이 비슷하지만, 임베디드·RTOS 문맥에서는 보통 하나의 반복 실행 함수(주로 무한 루프 + 대기)로 구현되고, 주기적으로 반복 실행되는 경우가 많다는 점이 특징입니다.

주기적으로 반복 실행되는 태스크를 주기 태스크(periodic task)라 하며, 다음 세 값으로 나타냅니다.

• 실행 시간(execution time, $C_i$): 태스크가 한 번 실행되는 데 CPU를 실제로 점유하는 시간. worst-case를 쓸 때는 최악실행시간(Worst-Case Execution Time, WCET)이라고 부릅니다.
• 주기(period, $T_i$): 태스크가 반복해서 요청(release)되는 간격.
• 데드라인(deadline, $D_i$): 그 요청 이후 결과가 반드시 나와야 하는 마감 시각. 데드라인이 주기와 같으면(즉 $D_i = T_i$) 암시적 데드라인(implicit deadline)이라 부르고, 14편의 RM·EDF 계산도 기본적으로 이 가정을 씁니다.

이 세 값이 갖춰진 태스크 집합을 예로 들어 보겠습니다. 세탁기 제어 MCU에 세 가지 주기 태스크가 있다고 가정합니다.

이 표는 14편에서 RM(Rate Monotonic)·EDF(Earliest Deadline First) 스케줄링 가능성을 계산할 때 그대로 다시 씁니다. 지금은 “태스크 하나를 설명하려면 이 세 숫자가 필요하다”는 점만 확실히 잡고 넘어갑니다.

쉽게 말하면: 태스크는 “몇 밀리초마다 한 번씩(주기), 몇 밀리초 동안 일하고(실행 시간), 몇 밀리초 안에는 끝내야 하는(데드라인) 반복 작업”입니다.

3. 응답 시간 — “요청부터 완료까지” 걸린 실제 시간

응답 시간(response time, $R_i$)은 태스크가 실행을 요청받은 시각(release time, 도착 시각)부터 실행을 완전히 마친 시각까지 걸린 시간입니다.

CPU가 그 태스크만 즉시, 방해 없이 실행해 준다면 응답 시간은 실행 시간과 같겠지만($R_i = C_i$), 실제로는 다른 태스크가 먼저 CPU를 쓰고 있거나 인터럽트 처리가 끼어들 수 있으므로 보통 $R_i \geq C_i$입니다. 이 편 2절의 $\tau_2$(온도 센서 태스크)를 예로 계산해 보겠습니다. $\tau_2$가 시각 10ms에 요청되었는데, 마침 $\tau_1$이 먼저 실행 중이어서 0.5ms 늦게 시작해 12.5ms에 실행을 마쳤다고 하면 다음과 같습니다.

실행 시간 $C_2 = 2$ms인데 응답 시간은 2.5ms이므로, 그 차이 0.5ms는 다른 태스크나 인터럽트에 밀려 대기한 시간입니다. 실시간 시스템 설계에서 가장 중요하게 보는 값은 평균 응답 시간이 아니라 최악응답시간(Worst-Case Response Time, WCRT)입니다. 데드라인을 지킬 수 있는지 판정할 때는 항상 “가장 운이 나쁜 경우에도 데드라인 $D_i$ 안에 끝나는가”($WCRT_i \leq D_i$)를 확인해야 하기 때문입니다. 이 계산은 14편에서 스케줄링 알고리즘별로 전 과정을 다룹니다.

자주 틀리는 점: “평균 응답 시간이 데드라인보다 짧으니 안전하다”는 판단은 hard real-time에서는 위험합니다. 평균이 짧아도 단 한 번의 최악 상황에서 데드라인을 넘기면 hard real-time 시스템은 실패로 간주되므로, 반드시 최악응답시간을 기준으로 판정해야 합니다.

4. 지터 — “제때 도착”이 아니라 “매번 똑같이 도착”의 문제

지터(jitter)는 반복되는 이벤트의 발생 시각이나 완료 시각이 매번 얼마나 들쭉날쭉한가를 나타내는 값입니다. 응답 시간이 매번 데드라인 안에 들어오더라도, 그 값 자체가 매번 크게 달라진다면 지터가 크다고 말합니다.

지터가 문제 되는 대표적인 예가 오디오 샘플링과 모터 제어입니다. 1ms마다 한 번씩 모터의 회전 속도를 측정해 PID 제어값을 계산하는 태스크가 있다고 합시다. 데드라인(1ms)은 매번 지켰지만, 실제 실행 완료 시각이 0.3ms, 0.9ms, 0.5ms, 0.95ms처럼 들쭉날쭉하다면(지터 = 0.95 - 0.3 = 0.65ms), 제어 루프가 실제로 관찰하는 시간 간격이 매번 달라져 제어 계산 자체의 정확도가 흔들립니다. 모터는 “정확히 1ms 간격으로” 측정된다는 가정 위에서 속도·가속도를 계산하는데, 그 간격이 흔들리면 계산에 쓰인 시간 간격과 실제 시간 간격이 어긋나 제어 오차가 누적됩니다.

특히 태스크가 요청되는 시각 자체가 흔들리는 경우를 릴리즈 지터(release jitter)라고 따로 부릅니다. 예를 들어 센서 인터럽트가 정확히 1ms마다 오지 않고 인터럽트 우선순위 처리나 다른 하드웨어 지연 때문에 0.9~1.1ms 사이에서 흔들린다면, 이는 태스크가 실행되기도 전에 이미 시간축이 어긋난 것입니다.

쉽게 말하면: 응답 시간은 “제때 도착했는가”를 보고, 지터는 “매번 똑같은 간격으로 도착했는가”를 봅니다. 버스가 정류장에 늦지 않게 오더라도, 어떤 날은 정각에 어떤 날은 4분 일찍 온다면 승객 입장에서는 예측이 어려워지는 것과 같습니다.

숫자로 확인하기

같은 주기(5ms)로 반복 요청되는 태스크의 응답 시간을 5회 측정했다고 하겠습니다.

결과 해석: 데드라인이 5ms라면 응답 시간 최댓값 2.8ms도 여유 있게 지켰으므로 데드라인 관점에서는 문제가 없습니다. 그러나 지터가 0.8ms나 된다는 것은, 이 태스크의 결과가 나오는 시점이 매번 최대 0.8ms까지 흔들린다는 뜻입니다. 데드라인만 보고 “문제없다”고 결론 내리면 안 되는 이유가 여기 있습니다 — 정밀한 타이밍 제어(모터 PWM 듀티 갱신, 오디오 샘플 출력)에서는 지터 자체가 별도의 품질 지표로 관리됩니다.

5. 실시간 태스크의 생명주기

한 태스크가 요청되고 실행되어 완료되기까지의 흐름을 상태로 정리하면 다음과 같습니다.

준비(ready) 상태에 머무르는 시간이 길어질수록 응답 시간이 늘어나고, 이 대기 시간이 매번 달라질수록 지터가 커집니다. 즉 응답 시간과 지터는 모두 “준비 상태에서 얼마나 기다리는가”에서 비롯되며, 이 기다림을 통제하는 것이 14편의 스케줄링 알고리즘의 역할입니다.

핵심 정리

• 실시간 시스템은 결과의 논리적 정확성뿐 아니라 결과가 나오는 시각까지 정답의 일부로 취급한다.
• 경성(hard) 실시간은 데드라인을 놓치면 시스템 실패, 연성(soft)은 품질 저하, 강성(firm)은 그 결과만 폐기된다는 차이가 있다.
• “실시간 = 빠른 시스템”은 오해다. 실시간의 핵심은 데드라인을 예측 가능하게 지키는 것이다.
• 주기 태스크는 실행 시간 $C_i$, 주기 $T_i$, 데드라인 $D_i$ 세 값으로 나타내며, $D_i = T_i$인 경우를 암시적 데드라인이라 한다.
• 응답 시간은 요청부터 완료까지 걸린 시간이며, hard real-time 판정은 평균이 아니라 최악응답시간을 기준으로 한다.
• 지터는 응답(또는 릴리즈) 시각이 매번 얼마나 들쭉날쭉한지를 나타내며, 데드라인을 지켜도 지터가 크면 정밀 제어에 문제가 생길 수 있다.

마무리 복습

참고 자료

• 국가평생교육진흥원 독학학위제 - 과목별 평가영역 
• FreeRTOS documentation