핵심 인사이트 (3줄 요약)
- 본질: 선점형 스케줄링 (Preemptive Scheduling)은 운영체제가 현재 실행 중인 작업의 CPU를 강제로 회수해 더 적절한 작업에 재할당할 수 있게 하는 스케줄링 방식이다.
- 가치: 이 메커니즘 덕분에 대화형 시스템은 응답성을 확보하고, 실시간 시스템은 높은 우선순위 작업의 지연을 줄이며, 다중 사용자 환경은 공정성을 유지할 수 있다.
- 판단 포인트: 선점은 빠른 반응성을 주지만 문맥 교환 (Context Switch) 오버헤드, 캐시 교란, 경쟁 조건 (Race Condition), 우선순위 역전 같은 비용을 함께 가져오므로 정책과 동기화를 같이 설계해야 한다.
Ⅰ. 개요 및 필요성
선점형 스케줄링 (Preemptive Scheduling)은 실행 중인 프로세스나 스레드가 자발적으로 CPU를 내놓지 않아도, 커널이 인터럽트와 우선순위 정책을 이용해 제어권을 강제로 회수할 수 있는 스케줄링 방식이다. 핵심은 "누가 CPU를 오래 붙잡고 있느냐"가 아니라 "시스템 전체 기준에서 지금 누구를 실행해야 하는가"를 운영체제가 결정한다는 데 있다.
이 방식이 필요해진 이유는 비선점형 환경이 대화형 시스템에 치명적이기 때문이다. 만약 한 작업이 긴 계산이나 무한 루프에 들어가면, 마우스 입력 처리·오디오 재생·응답 메시지 출력 같은 짧고 중요한 작업이 전부 뒤로 밀린다. 선점형 스케줄링은 이런 독점을 끊어, 사용자에게는 "동시에 여러 일이 진행되는 것 같은" 반응성을 제공한다.
이 그림은 선점형과 비선점형의 체감 차이를 보여준다.
┌──────────────────────────────────────────────────────────────┐
│ CPU 제어권의 차이: 자발적 양보 vs 강제 회수 │
├──────────────────────────────────────────────────────────────┤
│ 비선점형 │
│ Task A : [████████████████████] │
│ Task B : ....................(계속 대기) │
│ │
│ 선점형 │
│ Task A : [████][████][██] │
│ ▲ ▲ │
│ │ └─ 타이머 또는 고우선순위 이벤트 │
│ └────── 커널이 CPU 회수 │
│ Task B : .....[██][████] │
└──────────────────────────────────────────────────────────────┘
즉 선점형 스케줄링은 단순한 교체 기술이 아니라, 시스템 응답성·공정성·실시간성의 기반이다. 현대 운영체제에서 이것이 기본값이 된 이유도 여기에 있다.
- 📢 섹션 요약 비유: 선점형 스케줄링은 발표 시간이 끝나면 사회자가 마이크를 회수해 다음 발표자에게 넘기는 회의 규칙과 같다. 누군가 계속 말하고 싶어 해도 전체 진행을 위해 끊어야 한다.
Ⅱ. 아키텍처 및 핵심 원리
선점이 실제로 일어나려면 정책만으로는 부족하다. 하드웨어 타이머가 주기적으로 인터럽트를 발생시키고, 커널이 현재 작업의 남은 실행 시간과 우선순위를 확인한 뒤, 필요하면 다른 작업으로 문맥을 전환해야 한다. 따라서 선점형 스케줄링은 스케줄러 알고리즘과 타이머 인터럽트, 디스패처 (Dispatcher)가 함께 움직이는 구조다.
| 트리거 | 커널의 판단 | 기대 효과 | 주의할 비용 |
|---|---|---|---|
| 타임 퀀텀 (Time Quantum) 소진 | 현재 작업을 Ready Queue로 이동 | 공정성 확보 | 문맥 교환 증가 |
| 더 높은 우선순위 작업 도착 | 즉시 선점 여부 결정 | 응답 시간 단축 | 우선순위 역전 가능 |
| I/O 완료 작업 복귀 | 기존 작업보다 중요한지 비교 | 대기 감소 | 큐 관리 복잡도 증가 |
| 실시간 데드라인 접근 | 즉시 CPU 재배치 | 데드라인 준수 | 일반 작업 기아 위험 |
이 그림은 타이머 인터럽트 기반 선점의 흐름을 보여준다.
┌──────────────────────────────────────────────────────────────┐
│ 타이머 인터럽트 기반 선점: 정책이 메커니즘으로 실행됨 │
├──────────────────────────────────────────────────────────────┤
│ Running Task │
│ │ │
│ ├─ 타이머 인터럽트 발생 │
│ ▼ │
│ Kernel 진입 │
│ │ │
│ ├─ 실행 시간 차감 / 우선순위 확인 │
│ ├─ need_resched 판단 │
│ └─ 디스패처 호출 여부 결정 │
│ │ │
│ ├─ No → 현재 작업 계속 실행 │
│ └─ Yes → 문맥 교환 후 다른 작업 실행 │
└──────────────────────────────────────────────────────────────┘
여기서 중요한 트레이드오프가 타임 퀀텀 크기다. 퀀텀이 너무 짧으면 반응성은 좋아지지만 문맥 교환과 캐시 미스가 늘고, 너무 길면 오버헤드는 줄지만 사용자 체감 지연이 커진다. 그래서 선점형 스케줄링은 "무조건 자주 바꾸는 것"이 아니라, 어떤 작업군에서 어느 정도 주기로 회수해야 가장 좋은지 조정하는 설계 문제다.
- 📢 섹션 요약 비유: 선점형 스케줄링은 교차로 신호등과 같다. 너무 자주 바뀌면 차들이 멈추기만 하고, 너무 늦게 바뀌면 한 방향 차량이 끝없이 막힌다.
Ⅲ. 비교 및 연결
선점형 스케줄링의 가치는 비선점형과 비교할 때 가장 선명해진다. 비선점형은 현재 작업이 스스로 CPU를 내놓을 때까지 기다리므로 구현과 동기화가 단순하고 문맥 교환 비용도 적다. 반면 선점형은 응답성은 뛰어나지만, 공유 데이터가 언제든 중간 상태에서 끊길 수 있어 락 (Lock), 세마포어 (Semaphore), 우선순위 상속 같은 추가 장치가 필요하다.
| 항목 | 선점형 스케줄링 | 비선점형 스케줄링 |
|---|---|---|
| CPU 회수 시점 | 커널이 강제로 회수 가능 | 작업이 자발적으로 양보 |
| 응답성 | 우수 | 낮음 |
| 문맥 교환 오버헤드 | 큼 | 작음 |
| 동기화 난이도 | 높음 | 상대적으로 낮음 |
| 적합 분야 | GUI, 서버, 실시간 시스템 | 단순 배치, 제한된 임베디드 작업 |
또한 선점형 스케줄링은 여러 알고리즘의 기반이 된다. 라운드 로빈 (Round Robin, RR)은 동일 우선순위 작업을 시간 단위로 순환시키고, 선점형 우선순위 스케줄링은 더 중요한 작업이 나타났을 때 즉시 끼어들게 한다. 리눅스의 CFS (Completely Fair Scheduler)는 가상 실행 시간 (virtual runtime)을 사용해 공정성을 수학적으로 근사한다. 즉 선점은 하나의 알고리즘이 아니라, 여러 정책이 CPU 회수 권한을 행사할 수 있게 만드는 공통 메커니즘이다.
운영체제 내부로 들어가면 "커널 자체도 선점 가능한가"라는 질문이 이어진다. 현대 시스템은 커널 선점 (Kernel Preemption)을 통해 시스템 호출 중에도 더 긴급한 작업이 개입할 수 있게 하지만, 그만큼 임계 구역 보호가 더 중요해진다. 따라서 선점형 설계는 스케줄러만의 문제가 아니라 커널 전체 구조 문제다.
- 📢 섹션 요약 비유: 선점형은 여러 손님이 오는 응급실 운영과 같고, 비선점형은 한 손님을 끝까지 보는 예약 진료에 가깝다. 어느 쪽이 좋은지는 "급한 환자를 끼워 넣어야 하는가"에 달려 있다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서 선점형 스케줄링은 보통 응답성과 안정성의 균형 문제로 나타난다. 예를 들어 웹 서버는 많은 요청을 짧게 나눠 처리해야 하므로 선점형이 유리하지만, 락 경합이 심하면 오히려 CPU를 자주 빼앗는 비용 때문에 처리량이 떨어질 수 있다. 실시간 제어 시스템에서는 더 극단적이다. 센서 처리 태스크가 제때 CPU를 받지 못하면 단순 성능 저하가 아니라 안전 문제로 이어질 수 있어, 일반 공정성보다 데드라인 보장이 우선된다.
또 하나의 핵심 판단 포인트는 우선순위 역전 (Priority Inversion)이다. 낮은 우선순위 작업이 락을 쥔 상태에서 높은 우선순위 작업이 그 락을 기다리면, 선점형 시스템임에도 긴급 작업이 실제로는 막힌다. 이 문제를 풀기 위해 우선순위 상속 (Priority Inheritance)이나 우선순위 천장 (Priority Ceiling) 같은 기법이 필요하다. 즉 선점이 있다고 해서 자동으로 빠른 시스템이 되는 것은 아니다.
판단 체크리스트
- 응답 시간 목표와 처리량 목표 중 무엇이 더 중요한가?
- 타임 퀀텀을 작업 특성에 맞게 조정했는가?
- 공유 자원 접근 구간이 짧고 명확하게 보호되는가?
- 실시간 업무라면 우선순위 역전 대응 기법이 있는가?
- 잦은 문맥 교환으로 캐시 손실이 과도하지 않은가?
안티패턴
-
모든 작업에 무조건 짧은 퀀텀을 줘 반응성만 올리려는 설계
-
선점형 환경인데 공유 자료구조를 락 없이 수정하는 구현
-
우선순위만 높이고 실제 락 경합 구조는 그대로 두는 실시간 설계
-
📢 섹션 요약 비유: 선점형 시스템은 빠른 교대가 가능한 릴레이 경기와 같다. 하지만 바통을 건네는 규칙이 없으면, 교대가 빠를수록 오히려 더 많이 떨어뜨린다.
Ⅴ. 기대효과 및 결론
선점형 스케줄링을 잘 설계하면 시스템은 특정 작업의 독점에서 벗어나고, 사용자 입력·네트워크 이벤트·실시간 태스크를 더 균형 있게 처리할 수 있다. 이는 데스크톱의 부드러운 체감 성능, 서버의 응답성, 임베디드 제어의 예측 가능성으로 이어진다. 결국 현대 운영체제가 다중 작업 환경을 자연스럽게 보이게 하는 핵심 토대가 선점이다.
다만 선점은 항상 비용을 동반한다. 문맥 교환, 캐시 무효화, 동기화 복잡도, 우선순위 역전 같은 문제를 방치하면 오히려 더 느리고 더 불안정한 시스템이 될 수 있다. 따라서 선점형 스케줄링은 "CPU를 강제로 빼앗는 기술"보다 "언제, 누구에게, 어떤 비용을 감수하고 빼앗을지 정하는 기술"로 기억하는 것이 정확하다.
- 📢 섹션 요약 비유: 선점형 스케줄링은 교실에서 선생님이 발표 순서를 관리하는 것과 같다. 끼어들 수 있는 권한이 중요한 것이지, 아무 때나 발표자를 끊는 것이 목적은 아니다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 타이머 인터럽트 (Timer Interrupt) | 선점을 실제로 시작하게 만드는 하드웨어 신호 |
| 문맥 교환 (Context Switch) | 선점 후 CPU 상태를 저장·복원하는 절차 |
| 타임 퀀텀 (Time Quantum) | 선점 주기를 결정하는 핵심 매개변수 |
| 디스패처 (Dispatcher) | 새 작업에게 CPU 제어권을 실제로 넘기는 모듈 |
| 우선순위 역전 (Priority Inversion) | 선점형 환경에서 높은 우선순위 작업이 막히는 대표 문제 |
| CFS (Completely Fair Scheduler) | 선점 메커니즘 위에서 공정성을 구현하는 현대 스케줄러 |
📈 관련 키워드 및 발전 흐름도
타이머 인터럽트 / 우선순위 이벤트
│
▼
선점 필요 판단 (need_resched)
│
▼
문맥 교환 / 디스패처 실행
│
├─▶ 라운드 로빈 (RR)
├─▶ 우선순위 기반 스케줄링
└─▶ CFS / 실시간 선점 커널
이 흐름도는 선점이 단독 개념이 아니라, 하드웨어 이벤트에서 시작해 스케줄러 정책과 커널 설계로 확장되는 구조임을 보여준다.
👶 어린이를 위한 3줄 비유 설명
- 선점형 스케줄링은 놀이터에서 한 친구가 그네를 너무 오래 타면 선생님이 순서를 바꿔 주는 규칙이에요.
- 그래서 기다리던 친구도 차례를 빨리 받을 수 있어요.
- 하지만 친구를 자주 바꾸면 오르내리는 시간이 늘어나니까, 적당한 타이밍으로 바꾸는 게 중요해요.