포스트

[OS] 선점 vs 비선점 스케줄링 & 현대 백엔드 서버 표준

커널·스레드 심화 개념과 선점/비선점 스케줄링 전략을 정리하고, 현대 백엔드 서버가 선점 스케줄링을 표준으로 채택한 이유를 살펴봅니다.

[OS] 선점 vs 비선점 스케줄링 & 현대 백엔드 서버 표준

커널, 스레드 심화 개념과 스케줄링 전략을 정리하고, 현대 백엔드 서버가 선점 스케줄링을 표준으로 채택한 이유를 함께 살펴본다.


1. 커널(Kernel)과 스레드 심화

커널(Kernel)이란?

  • 정의: 운영체제의 핵심부로, 하드웨어(CPU, 메모리 등)와 소프트웨어 사이의 중재자 역할을 하는 절대 권력자.
1
[ 사용자 앱 ]  ←→  시스템 콜(System Call)  ←→  [ 커널 ]  ←→  [ 하드웨어 ]

커널 모드 vs 사용자 모드

구분사용자 모드 (User Mode)커널 모드 (Kernel Mode)
실행 주체일반 애플리케이션OS 핵심 코드
하드웨어 접근❌ 직접 접근 불가✅ 모든 자원 접근 가능
권한제한된 영역무제한
진입 방법—시스템 콜(System Call) 호출

💡 시스템 콜(System Call): 사용자 앱이 하드웨어 자원을 쓰기 위해 커널에게 보내는 ‘공식 요청’.
파일 읽기/쓰기, 네트워크 소켓, 프로세스 생성 등이 모두 시스템 콜을 통해 이루어진다.

사용자 수준 스레드 vs 커널 수준 스레드

구분사용자 수준 스레드 (User-level)커널 수준 스레드 (Kernel-level)
관리 주체사용자 영역 라이브러리운영체제(Kernel)
장점전환 속도가 매우 빠름 (오버헤드 적음)독립적 스케줄링 가능 (안정적)
단점하나가 멈추면(Blocking) 전체가 멈춤모드 전환 비용 발생 (상대적으로 무거움)
현대 OS주로 커널 수준과 1:1 매핑하여 사용멀티코어 활용을 위해 표준으로 사용

⚠️ 현대 OS(Linux, Windows 등)는 커널 수준 스레드를 기본으로 사용한다.
멀티코어 CPU에서 진정한 병렬 실행(True Parallelism)을 달성하려면 커널이 각 스레드를 독립적으로 스케줄링할 수 있어야 하기 때문이다.


2. 오버헤드(Overhead)와 스케줄링 전략

오버헤드(Overhead)란?

  • 개념: 특정 작업을 수행하기 위해 본질적인 작업 외에 부가적으로 소모되는 시간, 메모리, 자원 등의 비용.
1
2
3
[본질적 작업] + [오버헤드] = [실제 총 비용]
     ↑                ↑
  실제 연산        PCB 저장/복구, 모드 전환, 캐시 초기화 등

오버헤드 발생 예시

상황발생하는 오버헤드
문맥 교환(Context Switching)PCB 저장/복구, CPU 캐시 초기화
사용자 모드 → 커널 모드 전환레지스터 저장, 권한 검사 비용
스레드 생성/소멸메모리 할당 및 해제 비용
잦은 I/O 요청시스템 콜 호출 비용

3. 선점 vs 비선점 스케줄링 상세 비교

핵심 개념

1
2
3
4
5
6
7
8
9
[선점 스케줄링]                        [비선점 스케줄링]

프로세스 A 실행 중                      프로세스 A 실행 중
       ↓                                      ↓
타임아웃/우선순위 높은 프로세스 등장         끝날 때까지 대기
       ↓                                      ↓
OS가 강제로 CPU 회수                    프로세스 A가 직접 반납
       ↓
프로세스 B에게 CPU 할당

스케줄링 타임라인

비교 테이블

비교 항목선점 스케줄링 (Preemptive)비선점 스케줄링 (Non-preemptive)
방식OS가 CPU를 강제로 뺏을 수 있음프로세스가 스스로 끝낼 때까지 대기
오버헤드높음 (잦은 문맥 교환 및 감시)낮음 (전환 빈도가 매우 낮음)
응답성빠름 (대화형 시스템에 적합)느림 (긴 작업이 CPU 독점 가능)
공정성✅ 높음❌ 낮음 (starvation 가능)
구현 복잡도복잡단순
사용 사례현대 범용 OS (Windows, Linux 등)일괄 처리(Batch) 시스템

⚠️ Starvation(기아 현상): 비선점 방식에서 우선순위가 낮은 프로세스가 CPU를 영원히 할당받지 못하는 문제.

대표 알고리즘 분류

방식알고리즘
선점Round Robin (RR), SRTF(Shortest Remaining Time First), 다단계 큐
비선점FCFS(First Come First Served), SJF(Shortest Job First), Priority

4. 현대 백엔드 서버의 표준

현대 백엔드 서버 환경 요약

항목표준 선택이유 요약
스케줄링 방식선점 스케줄링 (Preemptive)다수 요청에 공평하고 빠른 응답 필수
스레드 모델커널 수준 스레드 (1:1 매핑)멀티코어 병렬 처리, I/O 블로킹 격리
OSLinux (Ubuntu, RHEL, Amazon Linux 등)선점 스케줄러 + 커널 스레드 최적화
스케줄러CFS (Completely Fair Scheduler)모든 스레드에 공평한 CPU 시간 배분
I/O 처리Non-blocking I/O + 이벤트 루프 혼합스레드 낭비 없이 높은 동시성 확보

현대 백엔드 서버 아키텍처 흐름

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[ 클라이언트 요청 1 ]  ──┐
[ 클라이언트 요청 2 ]  ──┼──→  [ 로드 밸런서 ]
[ 클라이언트 요청 3 ]  ──┘
                               ↓
                    [ 백엔드 서버 (Linux + CFS) ]
                     ┌─────────────────────────┐
                     │  스레드 풀 (Thread Pool) │
                     │  T1 | T2 | T3 | T4 ...  │
                     │  (커널 수준 스레드)       │
                     └──────────┬──────────────┘
                                ↓
                  [ 선점 스케줄러 (CFS) 가 공평하게 배분 ]
                                ↓
                    [ 멀티코어 CPU 병렬 실행 ]

백엔드 아키텍처


5. 왜 선점 스케줄링이 표준인가?

이유 1 — 요청의 동시성과 공평성

백엔드 서버는 동시에 수천~수만 개의 HTTP 요청을 처리한다. 비선점 방식이라면 한 요청이 CPU를 독점하는 동안 나머지 요청은 전부 대기해야 한다.

1
2
3
4
5
6
7
8
9
10
11
[비선점 방식의 문제]
요청 A (DB 쿼리 500ms) ━━━━━━━━━━━━━━━━━━━━━━━━ 완료
요청 B                  ← 500ms 동안 무조건 대기
요청 C                  ← 500ms 동안 무조건 대기

[선점 방식]
요청 A ━━╸  ━━╸  ━━╸  ━━━ 완료 (조각 조각 실행)
요청 B    ━━╸  ━━╸  ━━━ 완료
요청 C      ━━╸  ━━━ 완료
              ↑
         타임 슬라이스 단위로 번갈아 실행

이유 2 — I/O Blocking 격리

DB 조회, 파일 읽기, 외부 API 호출 등 I/O 작업 중에 해당 스레드가 블로킹되더라도, 선점 스케줄러가 CPU를 다른 스레드에 즉시 넘겨준다. 서버 전체가 멈추지 않는다.

1
2
3
4
5
스레드 A: DB 쿼리 요청 → Blocking 대기 중
              ↓ 선점 스케줄러가 CPU 회수
스레드 B: 다른 요청 처리 → 정상 실행
              ↓ A의 I/O 완료 시 다시 준비 큐로
스레드 A: 재실행

이유 3 — 멀티코어 병렬 처리

현대 서버 CPU는 수십 개의 코어를 갖는다. 커널 수준 스레드 + 선점 스케줄러 조합으로 각 코어에 스레드를 독립적으로 배분할 수 있어 진정한 병렬 처리가 가능하다.

1
2
3
4
5
6
코어 0  ─ 스레드 1 (요청 A 처리)
코어 1  ─ 스레드 2 (요청 B 처리)
코어 2  ─ 스레드 3 (요청 C 처리)
코어 3  ─ 스레드 4 (요청 D 처리)
         ↑
   CFS가 각 코어에 공평하게 스레드 배분

이유 4 — 응답 시간 예측 가능성 (Latency SLA)

서비스 수준 협약(SLA)에서 응답 시간을 보장하려면 특정 요청이 CPU를 무한정 점유하는 상황을 막아야 한다. 선점 스케줄링의 타임 슬라이스가 이를 가능하게 한다.

이유 5 — Linux CFS의 공정성 보장

Linux의 기본 스케줄러인 CFS(Completely Fair Scheduler) 는 선점 방식을 기반으로, 모든 스레드가 CPU 시간을 공평하게 나눠 갖도록 설계되어 있다.

1
2
3
4
CFS 핵심 원리:
- 각 스레드의 "실행 시간 부채(vruntime)"를 추적
- vruntime이 가장 작은(= 가장 적게 실행된) 스레드를 우선 선택
- 결과적으로 모든 스레드가 균등한 CPU 시간을 보장받음

CFS 스케줄러


6. 결론 및 면접 답변 정리

한눈에 보기

1
2
3
4
5
6
비선점 스케줄링          선점 스케줄링
──────────────          ──────────────
오버헤드 낮음     vs     응답성 높음
단순한 구조       vs     공정한 자원 배분
Batch 시스템      vs     현대 서버/OS 표준
CPU 독점 가능     vs     Starvation 방지

면접 답변 예시

Q. 선점 스케줄링과 비선점 스케줄링의 차이는 무엇인가요?

선점 스케줄링은 OS가 실행 중인 프로세스로부터 CPU를 강제로 회수할 수 있는 방식이고, 비선점 스케줄링은 프로세스가 스스로 CPU를 반납할 때까지 기다리는 방식입니다.

선점 방식은 잦은 문맥 교환으로 오버헤드가 크지만 응답성과 공정성이 높아 현대 범용 OS의 표준입니다. 반면 비선점 방식은 오버헤드는 낮지만 긴 작업이 CPU를 독점할 수 있어 대화형 시스템에는 부적합합니다.

Q. 현대 백엔드 서버가 선점 스케줄링을 사용하는 이유는 무엇인가요?

백엔드 서버는 동시에 수많은 클라이언트 요청을 처리해야 하므로, 특정 요청이 CPU를 독점하는 상황을 반드시 막아야 합니다.

선점 스케줄링은 타임 슬라이스 단위로 CPU를 공평하게 배분하여 모든 요청에 고른 응답 시간을 보장합니다. 또한 I/O 블로킹이 발생해도 즉시 다른 스레드로 전환되므로 서버 전체가 멈추지 않습니다. Linux의 CFS 스케줄러가 이 역할을 담당하며, 커널 수준 스레드와 결합해 멀티코어 병렬 처리까지 가능하게 합니다.


참고

  • Linux 기본 스케줄러: CFS (Completely Fair Scheduler) — 선점 방식 기반
  • 현대 백엔드 스레드 모델: 커널 수준 스레드 (1:1 매핑) 표준
  • 비선점 방식이 적합한 환경: 일괄 처리(Batch), 임베디드 시스템 등 응답 시간보다 처리량(Throughput)이 중요한 경우
  • Starvation 해결책: 에이징(Aging) — 오래 기다린 프로세스의 우선순위를 점진적으로 높이는 기법
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.