운영체제가 여러 프로그램을 동시에 실행하는 원리: 프로세스·스케줄링 완전 정복

[시분할 시스템의 동작 개념]

시간 →  |──20ms──|──20ms──|──20ms──|──20ms──|──20ms──|
         브라우저  음악앱   메신저   브라우저  음악앱
            ↑        ↑        ↑        ↑        ↑
         타이머    타이머   타이머   타이머   타이머
        인터럽트  인터럽트 인터럽트 인터럽트 인터럽트

[타이머 인터럽트 처리 흐름]

1. 프로그램 A 실행 중
2. 타이머 인터럽트 발생 (하드웨어)
3. CPU → 커널 모드 전환 (사용자 모드 → 커널 모드)
4. 인터럽트 핸들러 실행 (운영체제 코드)
5. 스케줄러가 다음 실행할 프로그램 B를 선택
6. 컨텍스트 스위칭 (A의 상태 저장 → B의 상태 복원)
7. 커널 모드 → 사용자 모드 전환
8. 프로그램 B 실행 재개

[프로세스의 가상 메모리 레이아웃]

높은 주소
┌─────────────────────┐
│     커널 영역        │ ← 운영체제 코드 (사용자 접근 불가)
├─────────────────────┤
│      스택 (Stack)   │ ← 함수 호출 정보, 지역 변수
│         ↓           │   (높은 주소 → 낮은 주소 방향으로 성장)
│                     │
│         ↑           │
│       힙 (Heap)     │ ← 동적 할당 메모리 (new, malloc)
├─────────────────────┤   (낮은 주소 → 높은 주소 방향으로 성장)
│     BSS 영역        │ ← 초기화되지 않은 전역/정적 변수
├─────────────────────┤
│    데이터 영역       │ ← 초기화된 전역/정적 변수
├─────────────────────┤
│    코드 영역 (Text) │ ← 실행할 프로그램 명령어 (읽기 전용)
└─────────────────────┘
낮은 주소

[PCB의 주요 구성 요소]

┌────────────────────────────────────┐
│          Process Control Block     │
├────────────────────────────────────┤
│ 프로세스 ID (PID)      : 4823      │ ← 고유 식별자
│ 프로세스 상태          : RUNNING   │ ← 현재 상태
│ 프로그램 카운터 (PC)   : 0x00A4F2 │ ← 다음 실행할 명령어 주소
│ CPU 레지스터 값        : {...}     │ ← 현재 레지스터 스냅샷
│ 메모리 관리 정보       : {...}     │ ← 페이지 테이블 포인터
│ 열린 파일 목록         : [fd0,fd1] │ ← 사용 중인 파일 디스크립터
│ CPU 스케줄링 정보      : priority=5│ ← 우선순위, 대기 시간
│ I/O 상태 정보          : {...}     │ ← 대기 중인 I/O 목록
└────────────────────────────────────┘

                  생성
                   │
                   ▼
  ┌──────────────(New)──────────────┐
  │           프로세스 생성 중       │
  └───────────────┬─────────────────┘
                  │ 승인
                  ▼
  ┌─────────────(Ready)─────────────┐
  │   CPU 할당 대기 중 (준비 완료)   │◄──────────────┐
  └───────────────┬─────────────────┘               │
                  │ 디스패치 (CPU 할당)              │
                  ▼                                  │
  ┌───────────(Running)─────────────┐    타이머      │
  │       현재 CPU에서 실행 중       │──인터럽트──────┘
  └───────┬───────────────┬─────────┘
          │ I/O 요청 등   │ 완료
          ▼               ▼
  ┌────(Waiting)─┐  ┌──(Terminated)──┐
  │ I/O 완료 대기│  │  프로세스 종료  │
  └──────┬───────┘  └────────────────┘
         │ I/O 완료
         └────────────► Ready

[FCFS 예시]

프로세스:  P1(실행시간 24ms) → P2(3ms) → P3(3ms)

타임라인: |────────P1────────|─P2─|─P3─|
시간(ms): 0              24  27   30

P1 대기시간: 0ms
P2 대기시간: 24ms  ← 짧은 작업이 긴 작업 뒤에 오면 오래 기다림
P3 대기시간: 27ms
평균 대기시간: (0 + 24 + 27) / 3 = 17ms

[SJF 예시 (같은 프로세스, 순서 변경)]

프로세스:  P2(3ms) → P3(3ms) → P1(24ms)

타임라인: |─P2─|─P3─|────────P1────────|
시간(ms): 0    3    6              30

P2 대기시간: 0ms
P3 대기시간: 3ms
P1 대기시간: 6ms
평균 대기시간: (0 + 3 + 6) / 3 = 3ms  ← FCFS의 17ms 대비 획기적 감소

[Round Robin 예시 (Quantum = 4ms)]

프로세스:  P1(24ms), P2(3ms), P3(3ms)

타임라인:
|──P1──|─P2─|─P3─|──P1──|──P1──|──P1──|──P1──|──P1──|
0      4    7   10     14     18     22     26     30

→ P2, P3는 4ms 내에 완료되어 빠르게 응답
→ P1은 6번의 Time Quantum으로 나뉘어 실행

평균 대기시간: (6 + 4 + 7) / 3 = 5.67ms

Time Quantum 너무 작음 → 컨텍스트 스위칭 빈번 → 오버헤드 증가
Time Quantum 너무 큼  → FCFS와 유사 → 응답성 저하

일반적으로 10~100ms 사이에서 시스템 특성에 맞게 설정

// Linux에서 프로세스 우선순위 확인 (Java에서 실행)
ProcessBuilder pb = new ProcessBuilder("ps", "-eo", "pid,ni,comm");
Process process = pb.start();

// nice 값: -20(최고 우선순위) ~ 19(최저 우선순위)
// 일반 사용자 프로세스: nice = 0 (기본값)
// 백그라운드 작업: nice = 10~19 (낮은 우선순위)

[MLFQ 구조]

우선순위 높음
┌─────────────────────────────────┐
│  Q0: Quantum=8ms  (대화형 작업) │ ← UI, 마우스 입력 등
├─────────────────────────────────┤
│  Q1: Quantum=16ms              │
├─────────────────────────────────┤
│  Q2: Quantum=32ms (배치 작업)  │ ← 파일 압축, 백업 등
└─────────────────────────────────┘
우선순위 낮음

규칙:
- 새 프로세스는 Q0에 진입
- Q0에서 Quantum을 다 쓰면 → Q1으로 강등 (CPU 집중형으로 판단)
- I/O 후 복귀하면 → 상위 큐로 승격 (대화형으로 판단)
- 오래 기다린 프로세스 → 주기적으로 상위 큐로 승격 (기아 방지)

[프로세스 A → 프로세스 B로의 컨텍스트 스위칭]

1. 타이머 인터럽트 발생
   └─ CPU 제어권 → 커널

2. 현재 프로세스 A의 상태 저장 (PCB_A에 기록)
   ├─ 프로그램 카운터 (PC) 저장
   ├─ CPU 레지스터 전체 저장 (범용 레지스터, 스택 포인터 등)
   ├─ 메모리 관리 정보 저장
   └─ I/O 상태 정보 저장

3. 스케줄러 실행
   └─ 준비 큐에서 다음 실행할 프로세스 B 선택

4. 프로세스 B의 상태 복원 (PCB_B에서 로드)
   ├─ 프로그램 카운터 복원
   ├─ CPU 레지스터 전체 복원
   ├─ 메모리 관리 정보 복원 (TLB 플러시 포함)
   └─ I/O 상태 복원

5. 커널 → 사용자 모드 전환
   └─ 프로세스 B 실행 재개

컨텍스트 스위칭 비용 분류:

직접 비용 (수십 나노초)
├─ 레지스터 저장/복원
├─ 커널-사용자 모드 전환
└─ 스케줄러 실행

간접 비용 (수 마이크로초~수십 마이크로초)
├─ TLB(Translation Lookaside Buffer) 플러시
│  → 가상→물리 주소 변환 캐시 초기화
├─ CPU 캐시 오염 (L1/L2/L3 캐시 미스 증가)
└─ 파이프라인 플러시

// ❌ 과도한 스레드 생성 — 컨텍스트 스위칭 오버헤드 유발
ExecutorService executor = Executors.newFixedThreadPool(1000); // 스레드 1000개
for (int i = 0; i < 1000; i++) {
    executor.submit(() -> {
        // 아주 짧은 작업 (수 마이크로초)
        int result = heavyComputation();
    });
}
// 실제 연산 시간 < 컨텍스트 스위칭 오버헤드 → 오히려 느려짐

// ✅ CPU 코어 수에 맞는 스레드 풀 — 스위칭 최소화
int coreCount = Runtime.getRuntime().availableProcessors();
ExecutorService executor = Executors.newFixedThreadPool(coreCount);
// CPU 코어 수 = 스레드 수 → 컨텍스트 스위칭 최소화

[프로세스 vs 스레드 메모리 구조]

단일 스레드 프로세스          멀티스레드 프로세스
┌─────────────────┐          ┌─────────────────────────────┐
│    코드 영역     │          │         코드 영역            │ ← 공유
│    데이터 영역   │          │         데이터 영역          │ ← 공유
│      힙          │          │           힙                │ ← 공유
│    스택 (T1)    │          │  스택(T1) │스택(T2)│스택(T3) │ ← 각자 보유
│  레지스터 (T1)  │          │  레지스터 │레지스터│레지스터 │ ← 각자 보유
└─────────────────┘          └─────────────────────────────┘

[4코어 CPU의 병렬 실행]

         코어 0     코어 1     코어 2     코어 3
시간 t1:  P1 실행   P2 실행   P3 실행   P4 실행  ← 진짜 동시!
시간 t2:  P5 실행   P1 실행   P6 실행   P2 실행
시간 t3:  P3 실행   P7 실행   P1 실행   P8 실행

// ❌ 경쟁 조건 발생 예시
public class BankAccount {
    private int balance = 1000;

    // 두 스레드가 동시에 호출하면?
    public void withdraw(int amount) {
        if (balance >= amount) {      // 스레드A: 잔고 1000 확인 ✓
                                      // 스레드B: 잔고 1000 확인 ✓ (동시!)
            balance -= amount;        // 스레드A: 1000 - 800 = 200
                                      // 스레드B: 1000 - 800 = 200 (덮어씀!)
        }                             // 결과: 800원을 두 번 인출했는데 잔고가 200원!
    }
}

// ✅ synchronized로 임계 구역 보호
public class BankAccount {
    private int balance = 1000;

    public synchronized void withdraw(int amount) {
        // 한 번에 하나의 스레드만 진입 가능
        if (balance >= amount) {
            balance -= amount;
        }
    }
}

[교착상태 발생 조건]

스레드 A: 자원1 보유 → 자원2 대기 중
                              ↑          ↓
스레드 B:              자원2 보유 → 자원1 대기 중

→ 두 스레드 모두 영원히 대기 상태 (시스템 멈춤)

# Linux에서 프로세스 스케줄링 정보 확인
$ cat /proc/<PID>/sched

# nice 값 변경 (우선순위 낮추기)
$ nice -n 10 ./my_background_task

# 실행 중인 프로세스의 우선순위 실시간 변경
$ renice -n 5 -p <PID>

[이벤트 루프 동작 원리]

단일 스레드
    │
    ▼
┌─────────────────────────────┐
│         이벤트 루프          │
│                             │
│  ① 이벤트 큐에서 작업 꺼냄  │
│  ② 콜백 실행 (빠르게!)      │
│  ③ I/O는 OS에 위임          │
│  ④ 다음 이벤트 처리         │
└─────────────────────────────┘
         ▲
         │ I/O 완료 시 콜백 등록
    [OS 비동기 I/O]
    (파일읽기, 네트워크 등)

// Node.js 이벤트 루프 예시
// 단일 스레드지만 수천 개의 요청을 동시에 처리

const http = require('http');
const fs = require('fs');

http.createServer((req, res) => {
    // I/O 작업을 OS에 위임하고 즉시 반환
    // → 스레드가 블록되지 않음 → 다음 요청 즉시 처리 가능
    fs.readFile('./data.json', (err, data) => {
        // I/O 완료 후 콜백이 이벤트 큐에 등록되어 실행
        res.end(data);
    });
}).listen(3000);

[격리 수준 비교]

프로세스 격리 (기본 OS)
└─ 가상 메모리로 메모리 공간 분리
   단점: 같은 OS 커널 공유, 파일시스템 공유

컨테이너 (Docker)
└─ Linux Namespace + cgroups 활용
   → 프로세스 트리, 네트워크, 파일시스템, 사용자 독립
   → 커널은 공유 (가볍고 빠름)

가상머신 (VM)
└─ 하이퍼바이저가 하드웨어 가상화
   → OS 전체를 독립적으로 실행
   → 완전한 격리 (무겁지만 강력한 보안)