큐 간 스케줄링 (Scheduling between Queues)

핵심 인사이트 (3줄 요약)

본질: 다단계 큐(Multilevel Queue) 환경에서, 여러 개의 독립된 큐(Queue)들 중 "이번엔 어느 큐의 프로세스에게 CPU를 배분할 것인가"를 결정하는 상위 레벨의 통제 규칙이다.

가치: 큐 내부의 스케줄링(RR, FCFS)과 분리된 독립적 메커니즘으로, 시스템이 **'절대적 권력 보장(고정 우선순위)'**을 택할 것인지 **'자원의 공평한 분배(시간 할당)'**를 택할 것인지에 대한 거시적 자원 관리 철학을 담고 있다.

융합: 고정 우선순위 방식은 실시간 시스템(RTOS)의 생명줄이지만 하위 큐의 기아 상태(Starvation)를 유발하며, 시간 할당 방식은 이를 막기 위해 시분할 개념을 큐 단위로 확장한 현대적 절충안이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 다단계 큐 시스템에서는 각 큐 안에서 프로세스들이 라운드 로빈이나 FCFS로 순서를 기다리고 있다. 그렇다면 스케줄러는 Q0, Q1, Q2라는 여러 개의 큐 중에서 어떤 큐에 접근하여 프로세스를 꺼낼지 먼저 결정해야 하는데, 이를 '큐 간 스케줄링'이라 부른다. 크게 **고정 우선순위 선점 방식(Fixed-priority Preemptive)**과 타임 슬라이스(Time Slice) 방식 두 가지로 나뉜다.
필요성: 아무리 큐 내부에 좋은 RR(라운드 로빈)을 깔아두어도, 큐 자체를 선택하는 룰이 잘못되면 특정 큐(예: 백그라운드 작업 큐) 전체가 통째로 굶어 죽는 대참사가 발생한다. 따라서 큐와 큐 사이의 권력 서열과 자원 파이를 어떻게 나눌지에 대한 명확한 규칙이 커널 레벨에서 정의되어야 한다.
💡 비유: 대형 마트에 '일반 계산대', '소량 계산대', 'VIP 전용 계산대'가 따로 있을 때, 총지배인이 계산원(CPU)을 어느 계산대에 우선 배치할 것인지 정하는 직원 관리 규칙과 같다.
등장 배경: 초기 다단계 큐는 무조건 1번 큐가 다 비어야 2번 큐로 넘어가는 '고정 우선순위' 방식을 썼다. 하지만 시스템 데몬이나 마우스 렌더링 같은 1번 큐의 작업이 끊임없이 발생하자 사용자 프로그램이 아예 멈춰버리는 부작용이 터졌다. 이를 무마하기 위해 전체 CPU 시간의 80%는 1번 큐에, 20%는 2번 큐에 강제로 분배하는 거시적 시간 할당 개념이 도입되었다.

  [스케줄링의 2단계 (Two-Level) 아키텍처 구조]

  (상위: 큐 간 스케줄링)                 (하위: 큐 내부 스케줄링)
  어느 큐를 고를까? ────────┐
                        ▼
             [ Queue 0 (System) ] ───▶ 여기서 RR로 누굴 꺼낼까?
             [ Queue 1 (User)   ] ───▶ 여기서 SJF로 누굴 꺼낼까?
             [ Queue 2 (Batch)  ] ───▶ 여기서 FCFS로 누굴 꺼낼까?
                            │
                        ▼
               선택된 프로세스 CPU 진입

[다이어그램 해설] 단일 큐 스케줄러와 차별화되는 핵심 구조다. CPU가 큐 안의 프로세스를 쳐다보기 전에, 먼저 "건물(큐) 자체의 문을 열 열쇠"를 결정하는 상위 스케줄러가 개입한다. 이 윗단(큐 간 스케줄링)의 룰이 너무 가혹하면 아랫단(큐 내부 스케줄링)이 아무리 공평해도 빛을 발하지 못한다.

📢 섹션 요약 비유: 회사에서 사장님(스케줄러)이 각 부서(큐) 내부에서 대리가 과장보다 일을 먼저 할지 정하는 것(내부 스케줄링)보다, 100억의 예산을 A부서에 80억, B부서에 20억 줄지(큐 간 스케줄링) 결정하는 것이 회사의 명운을 가르는 훨씬 큰 결정입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

방식 1: 고정 우선순위 선점형 방식 (Fixed-Priority Preemptive Scheduling)

가장 원초적이고 무자비한 계급주의 방식이다.

작동 원리: 상위 우선순위 큐(Q0)가 완전히 텅 비어 있어야만 그 아래 큐(Q1)의 프로세스를 쳐다본다. 만약 하위 큐(Q1)의 프로세스가 CPU를 잡고 신나게 돌고 있는데 상위 큐(Q0)에 새로운 프로세스가 방금 들어왔다면? 하위 큐 프로세스는 즉각 목이 잘리고(선점) CPU를 Q0에게 강제로 빼앗긴다.
치명적 단점: Q0에 끝없이 작업이 유입되면, Q1과 Q2의 모든 프로세스는 완벽한 **기아 상태(Starvation)**에 빠져 시스템 재부팅 때까지 한 번도 실행되지 않는다.

방식 2: 큐 간 시간 할당 방식 (Time Slice between Queues)

기아 상태를 막기 위해 큐들 사이에도 타임 퀀텀(시분할) 개념을 확장 적용한 방식이다.

작동 원리: CPU의 전체 가동 시간(100%)을 각 큐에 비율로 쪼개어 지급한다. (예: Q0에 80%, Q1에 20%)
동작 예시: CPU가 1초(1000ms)를 일한다면, 800ms 동안은 무조건 Q0 큐에 있는 녀석들을 위해 일하고, 나머지 200ms는 억지로라도 Q1 큐에 있는 녀석들에게 가서 일을 해준다. 이 200ms 동안은 Q0에 작업이 넘쳐나도 무시한다.
장점: 아무리 천민이 모인 하위 큐라 하더라도 최소 20%의 생존권이 보장되므로 기아 상태가 원천 소멸한다.

  ┌────────────────────────────────────────────────────────────────────────┐
  │         고정 우선순위 vs 큐 간 시간 할당(Time Slice) 동작 비교         │
  ├────────────────────────────────────────────────────────────────────────┤
  │                                                                        │
  │ [상황] Q0(VIP)에 무한정 작업 유입 / Q1(일반)에 3개 대기 중             │
  │                                                                        │
  │ 1. 고정 우선순위 방식 (기아 발생)                                      │
  │ CPU 점유: | Q0 | Q0 | Q0 | Q0 | Q0 | Q0 | Q0 | Q0 | 영원히...          │
  │           └─▶ Q1의 작업은 평생 1초도 실행 못 함 (System Hang 체감)     │
  │                                                                        │
  │ 2. 큐 간 시간 할당 방식 (Q0: 80%, Q1: 20% 보장)                        │
  │ CPU 점유: | Q0 | Q0 | Q0 | Q0 | ⭐Q1 | Q0 | Q0 | Q0 | Q0 | ⭐Q1        │
  │           └─▶ 아무리 Q0이 바빠도 주기적으로 Q1이 CPU를 한 입 베어 뭄   │
  │           └─▶ 응답성은 다소 느려지지만 절대 굶어 죽지는 않음 (공정성)  │
  └────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 상단은 실시간 제어가 중요한 미사일이나 자동차 브레이크 시스템에서 쓴다. (내비게이션 Q1이 버벅대더라도 브레이크 Q0은 절대 양보할 수 없기 때문). 하단은 일반 사용자가 쓰는 데스크톱 OS의 철학이다. 백그라운드 압축 작업(Q1)이 느려지더라도 마우스(Q0)가 잘 움직이게 하되, 그렇다고 압축 작업이 아예 멈추게(기아) 두지는 않겠다는 타협점이다.

📢 섹션 요약 비유: 왕(Q0)이 배부를 때까지 백성(Q1)은 굶어야 하는 폭정(고정 우선순위)을 버리고, 창고의 쌀 10가마니 중 8가마니는 왕이 먹고 최소 2가마니는 백성에게 의무적으로 배급하는 세금 제도(시간 할당)를 도입한 것입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

우선순위 결정의 계층적 트레이드오프

비교 지표	고정 우선순위 큐 (Fixed Priority)	큐 간 시간 할당 (Time Slicing)
응답성 보장	최상위 큐 프로세스에 대한 절대적이고 확정적인 마이크로초 단위 반응 보장	상위 큐라도 시간 할당이 끊기면 대기해야 하므로 지연 변동성(Jitter) 발생
기아 상태 여부	하위 큐는 100% 확률로 굶어 죽을 위험 내재	모든 큐가 최소한의 지분을 먹고 삼 (기아 원천 차단)
커널 구현 난이도	매우 단순 (그냥 Q0 헤드만 보면 됨)	복잡 (타이머가 큐 수준과 프로세스 수준 두 번 돌아야 함)
적용 도메인	군사/의료 하드 RTOS, 인터럽트 핸들러	범용 서버, 웹 호스팅, 클라우드 가상 머신 환경

"타임 퀀텀" 개념의 2차원 확장

우리가 아는 타임 퀀텀(Time Slice)은 보통 '프로세스' 단위(예: A에게 10ms, B에게 10ms)로 주어진다고 배웠다. 하지만 큐 간 스케줄링에서의 시간 할당은 **'큐' 단위로 거대한 퀀텀(예: Q0에 800ms)**을 덩어리째 던져주는 것이다. 그러면 Q0 내부의 RR 스케줄러가 그 800ms를 다시 10ms씩 쪼개어 자기 소속 프로세스들에게 나눠주는 '프랙탈(Fractal)' 구조를 띤다.

📢 섹션 요약 비유: 정부(OS)가 각 시도청(큐)에 먼저 국가 예산(거대 Time Slice)을 80억, 20억으로 덩어리째 쪼개서 내려보내면, 시도지사(큐 내부 스케줄러)가 그 예산을 동네 주민(프로세스)들에게 10만 원씩 골고루 다시 나눠주는 이중 분배 구조입니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오

네트워크 라우터 (QoS, Quality of Service)의 패킷 큐잉: CPU 프로세스 스케줄링뿐만 아니라, 네트워크 장비(Cisco 등)에서 트래픽을 처리할 때 이 개념이 100% 동일하게 쓰인다. 보이스/비디오 통화(VoIP) 패킷은 딜레이가 튀면 뚝뚝 끊기므로 고정 최우선 큐(PQ: Priority Queuing)에 넣고 절대 선점권을 준다. 반면 일반 웹 서핑 패킷은 WFQ(Weighted Fair Queuing)라는 큐 간 시간(대역폭) 할당 방식을 써서 80%, 20%로 파이를 쪼개어 기아 상태를 막는다.
리눅스 cgroups (컨트롤 그룹) 기반 컨테이너 자원 할당: 도커(Docker)나 쿠버네티스 노드에서 여러 컨테이너가 돌 때, 특정 컨테이너 큐(cgroup)에 --cpu-shares 파라미터를 준다. 컨테이너 A에 1024, B에 512를 주면, 커널의 큐 간 스케줄러는 정확히 2:1 (약 66% 대 33%)의 시간 할당(Time Slice) 비율로 큐 단위의 CPU를 배분한다. A가 아무리 바빠도 B는 최소 33%의 CPU 생존권을 법적으로 보장받는 완벽한 큐 간 스케줄링의 현대적 실무 구현체다.

  ┌──────────────────────────────────────────────────────────────────┐
  │     가상화/컨테이너 환경(K8s/Docker)의 큐 간 시간 할당 아키텍처  │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │   [물리 CPU 코어 (100% Time)]                                    │
  │                │ (커널 cgroups 스케줄러의 큐 간 분배)            │
  │                ▼                                                 │
  │   [ Cgroup A 큐 (비중: 80) ]      [ Cgroup B 큐 (비중: 20) ]     │
  │   (쇼핑몰 결제 마이크로서비스)      (백그라운드 로그 수집 서비스)│
  │          │                                   │                   │
  │          ▼ (큐 내부 스케줄링)                  ▼                 │
  │  ┌──────┴─────────┐                 ┌────────┴─────┐             │
  │  │스레드1│스레드2│스레드3│                 │스레드1│스레드2│     │
  │  └────────────────┘                 └──────────────┘             │
  │                                                                  │
  │   🚨 결론: 결제 서비스(A)에 스레드가 1만 개 폭주하더라도,        │
  │          큐 간 시간 할당 규칙에 의해 절대 B의 20% 파이를         │
  │          침범(선점)할 수 없다. 완벽한 자원 격리(Isolation) 완성! │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 만약 큐 간 분배 룰 없이 단순히 스레드 우선순위(단일 큐)만으로 싸웠다면, 스레드가 1만 개 폭주한 A 서비스가 시스템의 99%를 강탈하고 B 서비스는 기아에 빠져 서버가 먹통이 되었을 것이다. 하지만 현대 클라우드는 cgroups라는 강력한 '큐 간 시간 할당(Time Slice)' 방어벽을 쳐서 이웃 컨테이너의 난동(Noisy Neighbor)으로부터 내 컨테이너의 20% 몫을 안전하게 철통 방어해 낸다.

📢 섹션 요약 비유: 아파트 층간 소음을 막기 위해 벽(큐 간 시간 할당)을 두껍게 치는 것과 같습니다. 옆집(A 큐)에서 스피커 100개를 틀고 춤을 춰도(스레드 폭주), 내 집(B 큐)의 평화로운 공간 20%는 방음벽에 의해 절대 침해받지 않도록 물리적으로 구역을 자르는 설계입니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

기대효과

큐 간 스케줄링 방식을 '시간 할당(Time Slicing)'으로 설계함으로써, 고정 우선순위의 치명적 결함이었던 하위 큐의 기아(Starvation) 현상을 100% 근절했다. 이를 통해 수백 개의 마이크로서비스가 한 노드에 동거하는 클라우드 환경에서 완벽한 자원 격리(Resource Isolation)와 SLA(서비스 수준 협약) 보장이 가능해졌다.

결론 및 미래 전망

큐 간의 거시적 스케줄링 룰은 단순한 CPU 배분을 넘어 "어떤 서비스에 얼마의 가중치 자본을 투입할 것인가"라는 비즈니스 논리와 직결된다. 미래의 스케줄러는 고정된 80:20의 시간 할당을 벗어나, 클라우드 로드밸런서에서 들어오는 트래픽의 종류나 유료/무료 고객의 비율 등 외부 메타데이터(eBPF 활용)를 실시간으로 커널에 밀어 넣어, 매 초 단위로 큐 간 파이 크기(비율)가 유기적으로 꿈틀대며 최적화되는 동적 가중치 큐 할당(Dynamic Weighted Queuing) 체계로 완벽히 진화할 것이다.

📢 섹션 요약 비유: 옛날엔 연초에 각 부서 예산(큐 간 파이)을 한 번 8:2로 고정해 놓고 1년 내내 썼다면, 미래의 스케줄러는 오후 2시에는 마케팅부에 9:1로 몰아주고, 새벽 3시에는 서버팀에 2:8로 알아서 예산 비율을 찰흙처럼 바꾸는 유연한 CFO(재무책임자)가 될 것입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
다단계 큐 (Multilevel Queue)	여러 개의 큐를 물리적으로 쪼개어 놓았기 때문에, 이들 사이의 지분을 어떻게 나눌 것인가(큐 간 스케줄링)하는 새로운 과제를 낳은 부모 아키텍처다.
기아 상태 (Starvation)	큐 간 스케줄링에서 '고정 우선순위 방식'을 선택했을 때 필연적으로 잉태되는 치명적인 무한 대기 버그다.
타임 슬라이스 (Time Slice)	기아 상태를 막기 위해 큐와 큐 사이에도 시분할(할당량) 개념을 도입하여 하위 계급의 숨통을 트여준 해결책이다.
다단계 피드백 큐 (MLFQ)	큐 간 시간 할당도 좋지만, 아예 하위 큐의 프로세스를 상위 큐로 직접 이사(Feedback/Boost)시켜주어 기아를 근본적으로 부수는 최종 진화형 스케줄러다.
cgroups (Control Groups)	리눅스 커널이 컨테이너(Docker) 간의 CPU 자원을 '큐 간 스케줄링(시간 할당)' 원리를 이용해 6:4, 8:2 비율로 썰어서 완벽히 격리해 주는 마법의 그룹핑 기술이다.

👶 어린이를 위한 3줄 비유 설명

장난감을 빌려주는 선생님(스케줄러) 앞에 "유치원생 줄(큐 0)"과 "초등학생 줄(큐 1)"이 따로따로 서 있어요.
만약 고정 우선순위 규칙을 쓰면, 유치원생이 1명이라도 있으면 초등학생은 유치원생이 다 집에 갈 때까지 평생 장난감을 못 만지고 서서 굶어 죽어요.
그래서 똑똑한 선생님은 시간 할당 규칙을 써서, 1시간 중에 50분은 유치원생 줄에 주고, 나머지 10분은 억지로라도 무조건 초등학생 줄로 가서 장난감을 나눠주는 착한 배려를 한답니다!