RTOS — 임베디드 면접 (실제 기출 기반·심화)

"RTOS를 왜 쓰나", "RTOS 구성 요소", "뮤텍스랑 세마포어 차이", "우선순위 역전이 뭐냐", "컨텍스트 스위칭은 어떻게", "데드락 4조건", "태스크 스택 오버플로 막는 법" — 실시간 멀티태스킹 감각을 보는 핵심 단골. 인터럽트 편의 동시성을 스케줄링으로 확장한다.

"세마포어와 뮤텍스 차이"는 임베디드 면접 최다 빈출 중 하나다. "둘 다 동기화"에서 멈추면 끝. 소유권·우선순위 상속까지 가야 한다.

---

1. RTOS vs 베어메탈·구성 요소 (★ 단골)

실제 질문: "RTOS를 왜 쓰는가?" · "RTOS의 주요 구성 요소 3가지는?" (velog @verilog Q61·@embeddedjune)

• 베어메탈(super loop): while(1){ doA(); doB(); } — 단순하나 한 작업이 길면 다른 게 밀림(응답 지연). 급한 것만 인터럽트로.
• RTOS: 작업을 태스크로 나눠 우선순위로 스케줄링 → 결정적 응답(높은 우선순위가 마감 시간 보장).
• 구성 요소 3가지: ① 태스크/스레드 ② 스케줄러 ③ 태스크 간 통신/동기화(큐·세마포어·뮤텍스).

"RT"는 빠름이 아니라 결정성(determinism)(★ 함정). 최악 응답 시간이 예측 가능해야 실시간. 태스크가 많고 타이밍 요구가 빡세면 RTOS, 단순하면 베어메탈.

함정: ❌ "RTOS = 리눅스 같은 범용 OS" → RTOS는 경량 커널(== embedded OS). ❌ "RTOS는 더 빠르다" → 빠른 게 아니라 결정적.

---

2. 태스크 상태·스케줄링 (★★ 단골)

실제 질문: "태스크의 상태(4가지)는?" · "Preemptive Scheduling이란?" · "태스크가 Block 상태에 들어가는 경우는?" (velog @verilog Q62·Q65·@embeddedjune)

각 태스크는 **자기 스택·우선순위·TCB(Task Control Block)**를 갖는다. 스케줄러가 Ready 중 최고 우선순위를 Running으로.

• 선점형(preemptive): 높은 우선순위 Ready가 생기면 즉시 현재 태스크를 뺏음(실시간). vs 협력형(cooperative): 태스크가 *스스로 양보(yield)*할 때만 전환(단순·한 태스크가 멈추면 전체 정지).
• 라운드로빈(time-slicing): 같은 우선순위 태스크끼리 tick마다 번갈아(FreeRTOS는 priority preemptive + 동일 우선순위 RR).
• RMS(Rate Monotonic): 주기 짧은 태스크에 높은 우선순위(고정 우선순위 최적). idle 태스크: 할 일 없을 때 도는 최저 우선순위(저전력 진입).

꼬리질문: "Block과 Suspend 차이?" → Block은 이벤트/타임아웃 대기(자동 복귀), Suspend는 명시적 정지(resume까지). / "태스크가 끝나면?" → vTaskDelete(반환하면 안 됨).

---

3. 컨텍스트 스위칭 — Cortex-M (★★ 심화·재검증)

실제 질문: "RTOS에서 context switch란 무엇인가?" (velog @verilog Q64)

스위칭 = 현재 태스크 레지스터(컨텍스트)를 그 태스크 스택(PSP)/TCB에 저장 → 다음 태스크 것 복원.

• SysTick 인터럽트가 주기적으로 스케줄러를 깨우고, 전환이 필요하면 PendSV를 pending.
• PendSV는 최저 우선순위 예외 → 모든 인터럽트가 끝난 뒤 실행 → 시간 임계 ISR을 절대 지연시키지 않음. 여기서 실제 레지스터 저장/복원.
• SVC 명령은 스케줄러 시작(첫 태스크 진입)에 사용.
• 태스크는 PSP, 커널/ISR은 MSP(03편) → 태스크 스택끼리 격리.

"왜 SysTick에서 바로 안 바꾸고 PendSV로 미루나?"(★) — SysTick 도중 더 높은 ISR이 끼면 거기서 컨텍스트를 바꾸면 위험·복잡. PendSV를 최저 우선순위로 미뤄 모든 ISR이 정리된 뒤 안전하게 스위칭.

꼬리질문: "정확히 무엇이 저장되나?" → 범용 레지스터·PC·xPSR·SP(Cortex-M은 HW가 8개 자동 + RTOS가 R4–R11 SW 저장). / "스위칭 비용을 줄이려면?" → tickless·필요할 때만 yield.

---

4. 뮤텍스 vs 세마포어 (★★★ 최다 빈출·재검증)

실제 질문: "Semaphore와 Mutex의 차이는?" · "뮤텍스가 바이너리 세마포어와 거의 같은데 결정적 차이는?" (velog @verilog Q63·gyoogle Semaphore&Mutex·@embeddedjune)

핵심 구분(★): 뮤텍스 = 화장실 열쇠(쓴 사람이 반납·소유권·우선순위 상속) → 공유 자원 보호. 세마포어 = 빈 좌석 수 신호(아무나 신호) → ISR→태스크 깨우기·생산자/소비자. "공유 변수 보호엔 뮤텍스, ISR이 태스크 깨우는 덴 세마포어"라고 답하면 정확.

• 큐(Queue): 태스크 간 데이터 전달(복사) + 동기화. ISR→태스크 데이터 전달의 표준.
• 이벤트 그룹·플래그: 여러 조건 비트를 한 번에 대기(AND/OR).

꼬리질문: "세마포어로 상호배제하면 뭐가 문제?" → 소유권 없어 다른 태스크가 give 가능·우선순위 역전 미해결. / "ISR에서 뮤텍스 take?" → 뮤텍스는 블로킹·우선순위 상속을 수반하는데 ISR은 블록 불가(+소유권 개념 없음) → 금지, 세마포어 give로.

함정: ❌ "세마포어 = 뮤텍스" → 소유권·우선순위 상속이 다르다.

---

5. 우선순위 역전 — Mars Pathfinder (★★★ 단골·재검증)

실제 질문: "우선순위 역전(priority inversion)이 무엇이고 어떻게 해결하나?" (@embeddedjune FreeRTOS·검색 다수)

우선순위 역전: 높은 태스크(H)가 낮은 태스크(L)가 쥔 락을 기다리는데, 그 사이 중간 태스크(M)가 L을 선점 → L이 락을 못 놓고 → H가 M 때문에 무한정 밀린다.

해결:

• 우선순위 상속(priority inheritance): L이 H가 기다리는 락을 쥐면 L을 일시적으로 H 우선순위로 승격 → M이 못 끼어듦 → L이 빨리 끝내고 락 반납(FreeRTOS 뮤텍스 기본 제공).
• 우선순위 천장(priority ceiling): 락마다 *그 락을 쓰는 태스크 중 최고 우선순위(천장)*를 정해두고, 잡는 순간 그 천장으로 승격.

실화: 화성 패스파인더(1997) — 고우선 bc_dist가 저우선 ASI/MET이 쥔 정보 버스(information bus, 공유 메모리)를 보호하던 뮤텍스를 기다리는데 중간 태스크가 끼어 역전 → 최고우선 bc_sched가 bc_dist의 하드 데드라인 미스를 감지(watchdog)→시스템 리셋 반복. 원인은 VxWorks 뮤텍스의 우선순위 상속이 성능 이유로 꺼져 있던 것. 지구에서 원격으로 상속 플래그를 켜 해결. → "왜 뮤텍스가 세마포어보다 자원 보호에 나은가"의 결정적 근거.

꼬리질문: "우선순위 상속이 역전을 완전히 없애나?" → 아니다(★ 함정). 빈도·지속시간만 줄인다 → 근본은 락 보유 시간 최소화. / "상속 vs 천장 차이?" → 상속은 대기가 생긴 뒤 동적 승격, 천장은 잡는 즉시 천장으로.

함정: ❌ "우선순위 상속으로 역전이 사라진다" → 완화일 뿐.

---

6. 데드락·기아·critical section (★ 단골)

실제 질문: "데드락 발생 4조건은?" · "critical section을 보호하는 방법 3가지는?" (검색 Coffman·@embeddedjune)

• 데드락 4조건(OS 편과 동일): 상호배제·점유와 대기·비선점·환형대기. 모두 성립해야. 현실적 예방은 환형대기 제거(자원 순서화·락 순서 일관)·타임아웃.
• critical section 보호 3가지: ① taskENTER_CRITICAL()(인터럽트 차단·가장 짧게) ② 세마포어·뮤텍스 ③ 공유 자원을 애초에 안 만드는 설계(메시지 전달).
• 기아(starvation): 낮은 우선순위가 영영 실행 못 함 → 에이징·우선순위 재설계.

꼬리질문: "데드락을 어떻게 깨나?" → 락 순서 통일·타임아웃·한 번에 하나만. / "ENTER_CRITICAL을 길게 쓰면?" → 인터럽트가 막혀 지연 폭증 → 최소 구간만.

함정: ❌ 데드락 조건을 3개만 답하거나 환형대기를 빠뜨림.

---

7. 스택 오버플로 (★ 단골)

실제 질문: "태스크 스택 오버플로를 어떻게 방지/감지하나?" (velog @verilog Q66)

태스크마다 고정 스택이라 깊은 호출·큰 지역배열·재귀로 넘치면 *옆 메모리(다른 태스크 TCB)*가 손상된다.

• 감지: FreeRTOS configCHECK_FOR_STACK_OVERFLOW(Method 1=SP 경계 검사, Method 2=스택 끝 패턴 워터마크 훼손 검사)·uxTaskGetStackHighWaterMark(사용 최고치).
• 방지: 스택 넉넉히·재귀/큰 지역배열 지양·MPU 스택 가드 영역(02편).

꼬리질문: "스택 크기를 어떻게 정하나?" → 최악 호출 깊이 + ISR 프레임 측정·워터마크로 튜닝·여유. / "워터마크 검사의 한계?" → 패턴을 정확히 덮어쓰면 못 잡음(신뢰성 제한) → MPU 병행.

---

8. ISR ↔ 태스크 — deferred (인터럽트 편 연결)

ISR은 짧게(04편) → 세마포어 give/큐 send(...FromISR)로 태스크를 깨워 무거운 일을 넘긴다(deferred interrupt processing). ...FromISR는 블로킹하지 않고, 깨운 태스크가 더 높으면 portYIELD_FROM_ISR()로 즉시 스위칭.

---

한국 임베디드 면접 단골 Q&A (답변 골격)

꼬리질문 대비 (상 난이도)

• "공유 변수 보호에 세마포어 쓰면?" → 소유권·상속 없어 역전 방어 안 됨 → 뮤텍스.
• "ISR에서 뮤텍스 take?" → 블로킹·상속 수반·ISR은 블록 불가·소유권 없음 → 금지 → 세마포어 give.
• "우선순위 상속도 한계?" → 연쇄 상속·데드락은 못 막음 → 락 보유 최소화.
• "태스크 스택 크기?" → 최악 호출 깊이 + ISR 프레임·워터마크 튜닝.
• "tickless가 왜?" → idle 때 주기 인터럽트 제거 → 저전력(배터리).
• "협력형이 더 안전할 때?" → 매우 단순·자원 극소 시스템(race 적음·대신 한 태스크 멈추면 전체 정지).

한 줄 요약 — RTOS는 결정적 우선순위 스케줄링(구성=태스크·스케줄러·통신/선점·RR·RMS·idle). 컨텍스트 스위칭은 SysTick→PendSV(최저 우선순위·ISR 뒤)·SVC 시작·PSP/TCB. 뮤텍스(소유권+우선순위 상속·자원 보호) vs 세마포어(소유권 없음·시그널링)·큐(데이터). 우선순위 역전은 H가 L의 락 대기 중 M이 끼는 것 → 우선순위 상속/천장(화성 패스파인더·완전 해결 아님). 데드락 4조건(상호배제·점유대기·비선점·환형대기)·락 순서. 태스크별 스택 오버플로는 워터마크·MPU. ISR→태스크는 ...FromISR deferred.

(출처 — 한국 면접 기출·1차자료 교차검증 2026-06: velog @verilog Firmware 직무적성(Q61~66)·velog @embeddedjune FreeRTOS 총집본·gyoogle Semaphore & Mutex · FreeRTOS — Mutexes/Priority Inheritance·Memfault Cortex-M RTOS Context Switching·NASA/JPL Mars Pathfinder priority inversion 교차검증.)