MLFQ 파라미터 (큐 개수, 스케줄링 알고리즘, 승급/강등 기준)

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

본질: 다단계 피드백 큐 (MLFQ)는 단일 알고리즘이 아니라 여러 개의 튜닝 변수로 구성된 거대한 '스케줄링 프레임워크'이며, 이 5가지 핵심 MLFQ 파라미터를 어떻게 설정하느냐가 시스템의 성격을 결정한다.

가치: 큐의 개수(층계 높이), 큐별 타임 퀀텀 알고리즘, 그리고 위아래로 프로세스를 이동시키는 승급(Promotion)/강등(Demotion) 조건 값을 통해 데스크톱, 서버, 모바일 등 모든 환경의 요구사항을 하나의 구조로 찍어낼 수 있는 궁극의 범용성을 제공한다.

융합: 파라미터 튜닝이 어긋나면 I/O 바운드가 쫓겨나 마우스가 버벅거리거나(응답성 파괴), 부스트(Boost) 주기가 너무 짧아 캐시 무효화가 폭발하는 스래싱(Thrashing) 오버헤드를 겪게 되므로 아키텍트의 정밀한 수학적 모델링이 필수적이다.

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

개념: MLFQ는 그 자체로 완성된 제품이 아니라, 5가지 주요 인자(Parameters)에 값을 대입해야 비로소 동작하는 함수와 같다. 주요 파라미터는 ① 큐의 개수, ② 각 큐의 스케줄링 알고리즘, ③ 프로세스를 강등시키는 기준, ④ 프로세스를 승급시키는 기준, ⑤ 처음 진입하는 큐의 결정이다.
필요성: 고정된 스케줄링 룰(예: 무조건 라운드 로빈 10ms) 하나로는 게임, 동영상 인코딩, 네트워크 통신 등 천차만별의 워크로드를 감당할 수 없다. MLFQ 설계자는 이 변수들의 미세 조정을 통해 "가벼운 놈은 빠르게, 무거운 놈은 방해 안 되게 구석으로"라는 완벽한 칵테일 비율을 빚어내야만 한다.
💡 비유: 커피 머신의 '물 온도, 원두 굵기, 추출 시간, 압력 강도' 다이얼과 같다. 기계(MLFQ)는 하나지만, 다이얼(파라미터)을 어떻게 세팅하느냐에 따라 에스프레소(빠른 응답)가 나오기도 하고 드립 커피(배치 처리)가 나오기도 한다.
등장 배경: 1960년대 초, 단순한 큐잉 모델에서 한계를 느낀 컴퓨터 공학자들은 "스케줄러의 규칙 자체가 상황에 맞게 튜닝 가능(Tunable)해야 한다"는 설계 철학을 도입했다. 이 파라미터 체계 덕분에 UNIX, Windows 등 다양한 범용 OS들이 하나의 철학(MLFQ)을 공유하면서도 각자의 입맛에 맞게 독자적인 성능 튜닝을 할 수 있게 되었다.

  [MLFQ의 5대 핵심 파라미터 결정 트리]

   Parameter 5. 신규 프로세스는 어디로 들어갈 것인가? (대부분 최상단 Q0)
                 │
                 ▼
  [ Q0 ] ───▶ Parameter 2. 이 층의 스케줄링 방식은? (예: RR, q=8ms)
   │  ▲          │
   │  │      ▼ Parameter 4. 퀀텀을 다 쓰면 아래로 강등시킬 조건은?
   │             │
  [ Q1 ] ───▶ Parameter 2. 이 층의 스케줄링 방식은? (예: RR, q=16ms)
   │  ▲          │
   │  │      ▼ Parameter 4. 퀀텀을 다 쓰면 아래로 강등시킬 조건은?
   │             │
  [ Q2 ] ───▶ Parameter 2. 이 층의 스케줄링 방식은? (예: FCFS)
                 │
      └────── Parameter 3. 밑바닥에서 오래 굶은 놈들을 언제 위로 구출(승급)시킬 것인가?

   Parameter 1. 도대체 큐(층)를 총 몇 개나 만들 것인가? (여기선 3개)

[다이어그램 해설] MLFQ를 구현하려는 OS 커널 개발자는 코딩을 시작하기 전, 반드시 위 다이어그램에 그려진 5개의 빈칸(Parameter)에 숫자를 채워 넣어야 한다. 이 숫자들의 조합이 어긋나면 시스템은 호위 효과나 기아 상태에 빠져 즉시 파멸한다. 각 파라미터는 서로 강하게 묶여있는 트레이드오프(Trade-off) 관계다.

📢 섹션 요약 비유: 이퀄라이저(EQ) 오디오 믹서와 같습니다. 저음(강등 조건), 중음(큐 개수), 고음(승급 조건) 레버를 미세하게 조절해서 록 음악(무거운 연산)을 틀 때는 저음을 올리고, 클래식(가벼운 I/O)을 틀 때는 고음을 올리는 식으로 소리(시스템 성능)를 최적화해야 합니다.

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

핵심 파라미터 3요소 심층 분석

1. 큐의 개수 (Number of Queues)

너무 많으면 (예: 64개): 분류는 기가 막히게 세밀해진다. 하지만 스케줄러가 다음 프로세스를 찾기 위해 64개의 큐 헤더를 뒤지거나, 프로세스가 64번이나 강등을 겪으며 문맥 교환 오버헤드(디스패치 지연)를 일으켜 시스템 CPU가 쓸데없는 일로 폭파된다.
너무 적으면 (예: 2개): 극단적으로 단순해 오버헤드는 적지만, I/O 바운드와 CPU 바운드가 하나의 큐에 금방 뒤섞여버리므로 분류의 의미가 사라지고 사실상 단순 라운드 로빈(RR)으로 퇴화해 버린다.
실무: 일반적으로 3~4개의 층이 가장 널리 쓰이며, 윈도우 스케줄러처럼 32단계를 두는 경우엔 O(1) 탐색을 위한 비트맵(Bitmap) 하드웨어 명령어 보조가 필수적이다.

2. 각 큐별 스케줄링 알고리즘 (Scheduling Algorithm per Queue)

MLFQ의 마법은 **"아래로 내려갈수록 타임 퀀텀(q) 크기가 2배씩 늘어난다"**는 설정에서 터진다.
Q0 (최상위): q = 8ms (가벼운 마우스, 타이핑을 8ms 안에 즉시 쳐내고 빠짐)
Q1 (중간): q = 16ms (약간 무거운 로딩 처리)
Q2 (최하위): FCFS 또는 아주 긴 q = 100ms (백그라운드 바이러스 검사, 동영상 렌더링)
아래로 떨어질수록 오버헤드(교체 비용) 없이 한 번에 쭉 길게 CPU를 쓰게 해 주므로, 무거운 프로세스는 자신의 본성(CPU Bound)에 맞는 편안한 처리량(Throughput) 환경에 안착하게 된다.

3. 승급/강등(Promotion / Demotion) 기준 파라미터

강등 기준 (Demotion): 프로세스가 자신에게 주어진 타임 퀀텀을 "완전히 다 썼을 때(Expire)" 무자비하게 아래로 강등시킨다.
- 꼼수 방어: 악성 프로세스가 9.9ms만 쓰고 0.1ms 남긴 채 자발적으로 I/O를 요청해 강등을 피하는 걸 막기 위해, 최신 커널은 "이 큐에서 머문 누적 시간"이 한도를 넘으면 얄짤없이 강등시키는 룰을 적용한다.
승급 기준 (Promotion, Priority Boost): 매 주기 $S$ 마다 시스템에 있는 모든 프로세스를 묻지도 따지지도 않고 최상위 Q0으로 통째로 올려버린다.
- 이 $S$ 값(부스트 주기)을 정하는 것이 튜닝의 꽃이다. 이를 '부두 주술(Voodoo Constants)'이라 부르며, 너무 짧으면 무거운 놈들이 자꾸 위로 올라와 응답성을 망치고, 너무 길면 밑바닥 놈들이 오랫동안 기아(Starvation) 상태에서 굶어 죽는다.

  ┌────────────────────────────────────────────────────────────────────────┐
  │     강등과 부스트(승급) 주기에 따른 CPU 연산 패턴의 역동성             │
  ├────────────────────────────────────────────────────────────────────────┤
  │                                                                        │
  │ [시나리오: P1(무거운 배치), P2(가벼운 UI) 혼재. 부스트 S=50ms]         │
  │                                                                        │
  │  0ms        10ms         20ms               50ms                       │
  │  │ P1 (Q0)  │ P1 (Q1강등)│ P1 (Q2에서 구름)    │ 💥 BOOST!             │
  │  │ P2 (Q0)  │ P2 (Q0유지)│ P2 (Q0에서 구름)    │ P1,P2 둘다 Q0         │
  │                                                                        │
  │  [50ms 부스트 직후의 상황]                                             │
  │  ▶ 50ms: 밑바닥에 처박혀 숨죽이던 무거운 P1이 최상위 Q0로 강제 소환됨. │
  │  ▶ 50~60ms: P1이 다시 Q0의 10ms 슬라이스를 꿀꺽 뺏어 먹음.             │
  │  ▶ 결과: 이때 P2(마우스 클릭)가 발생하면, P1이 선점한 시간 때문에      │
  │          살짝 마우스가 렉 걸림(Jitter 발생).                           │
  └────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 주기 $S$(Boost)가 터지는 순간은 밑바닥 천민들에겐 구원의 빛이지만, 최상위 VIP 프로세스들에겐 길을 가로막는 재앙이다. S가 터지면 잠시 동안 I/O 바운드의 응답 속도가 튄다. 이 스파이크(Spike)를 시스템이 감내할 수 있는 주기가 과연 몇 초일까? 이것을 찾아내는 것이 아키텍트가 성능 테스팅(Load Testing)을 돌리며 파라미터를 튜닝하는 가장 핵심적인 이유다.

📢 섹션 요약 비유: 부스트 주기($S$)는 교도소의 특사(사면) 기간과 같습니다. 너무 자주 특사(짧은 S 주기)를 내리면 흉악범(무거운 프로세스)들이 계속 사회(최상위 큐)로 나와 물을 흐리고, 특사를 영원히 안 하면 억울한 죄수(하위 큐 기아)가 평생 썩어 죽습니다.

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

파라미터 설정에 따른 극단적 아키텍처 변형

MLFQ는 파라미터를 어떻게 세팅하느냐에 따라 완전히 다른 스케줄러로 둔갑하는 카멜레온이다.

파라미터 세팅 (다이얼 돌리기)	변형된 시스템의 정체 (결과물)
큐를 딱 1개만 만들고, Boost 주기를 무한대로 둔다.	순수 라운드 로빈 (RR) 스케줄러와 100% 동일해짐.
큐를 1개만 만들고 퀀텀을 무한대(∞)로 둔다.	구시대 메인프레임의 FCFS (선착순 비선점)로 완벽 퇴화.
큐를 N개 만들되 강등(Demotion) 룰을 꺼버린다.	한 번 꽂힌 큐에서 절대 못 움직이는 다단계 큐 (Multilevel Queue)로 회귀.

이 표가 시사하는 바는 크다. MLFQ는 그 자체로 독립된 알고리즘이라기보다, **"시분할 환경에서 상상할 수 있는 모든 스케줄링 룰을 구현할 수 있는 범용 메타 프레임워크"**에 가깝다.

부스트(Boost) 방식 vs 점진적 에이징(Aging)의 차이

하위 큐의 기아를 막는 방식에도 두 가지 파라미터 철학이 있다.

전체 부스트 (Rule 5 적용): 특정 주기마다 무조건 모든 프로세스를 다 Q0으로 쓸어 올린다. 빠르고 시원하지만, 순간적으로 무거운 놈들이 섞여 일시적 렉(Jitter)을 유발한다.
점진적 에이징 (Gradual Aging): 대기 시간 점수에 비례해 천천히 한 계단씩(Q2 -> Q1 -> Q0) 우선순위를 올린다. 부스트 렉은 덜하지만 커널이 매번 점수 계산을 해야 해서 오버헤드가 극심하다. 현대 시스템은 전산 비용이 저렴한 "전체 부스트"를 선호한다.
📢 섹션 요약 비유: MLFQ 파라미터는 레고 블록의 기본 세트와 같습니다. 조립 설명서(파라미터 세팅)에 따라 투박한 네모 상자(FCFS)가 될 수도 있고, 정교한 우주선(완성형 MLFQ)이 될 수도 있는 궁극의 확장성을 가집니다.

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

실무 시나리오

솔라리스 (Solaris) OS의 파라미터 테이블 매핑: 구형 유닉스인 솔라리스는 하드코딩된 로직 대신, 아예 텍스트 테이블(디스패치 테이블) 형태로 MLFQ 파라미터를 외부로 빼두었다. 우선순위(0~59), 각 순위별 퀀텀 크기, 퀀텀 다 쓰면 강등될 다음 순위 번호, 대기만 하다가 부스트 될 상위 번호를 엑셀 표처럼 관리했다. 시스템 관리자는 커널 소스 수정 없이 이 텍스트 테이블 수치만 바꿔서 DB 전용 서버로 만들지, 터미널 서버로 만들지 실시간으로 아키텍처를 스위칭할 수 있었다. 파라미터화(Parameterization)의 극치다.
리눅스 O(1) 스케줄러의 타임 슬라이스 설계: 과거 리눅스 2.6 초기의 스케줄러는 철저한 MLFQ 구조였다. 이때의 핵심 파라미터 튜닝은 I/O 바운드 프로세스에게 주는 보너스 점수였다. 프로세스가 Sleep(대기) 상태에 오래 있을수록 내부 보너스 점수를 높여주어 강등을 막고, 깨어났을 때 무려 100ms에 가까운 거대한 타임 퀀텀을 상으로 주었다. 반면 CPU를 혹사하는 녀석은 보너스를 깎고 타임 퀀텀을 10ms로 확 줄여버렸다(보통의 MLFQ 강등 퀀텀 룰과 반대로 동작시켜 징벌함). 이는 설계자(Inigo Molnar)가 정한 파라미터 철학의 차이였다.

  ┌───────────────────────────────────────────────────────────────────────┐
  │     MLFQ 파라미터 튜닝(S값) 실패로 인한 시스템 장애 트러블슈팅        │
  ├───────────────────────────────────────────────────────────────────────┤
  │                                                                       │
  │   [장애 현상: 백그라운드 영상 렌더링 중 1초마다 마우스가 툭툭 끊김]   │
  │                │                                                      │
  │                ▼ 원인 분석 (Top 명령, Perf 도구)                      │
  │   스케줄러의 부스트 주기 파라미터 (S) 가 어떻게 설정되어 있는가?      │
  │          ├─ [S = 1,000ms (1초) 설정 됨]                               │
  │          │      │                                                     │
  │          │      ▼ 장애 발생 매커니즘                                  │
  │          │  1. 렌더링 작업이 강등되어 바닥 큐(Q2)로 떨어짐            │
  │          │  2. 그런데 S값이 1초로 너무 짧음                           │
  │          │  3. 1초마다 렌더링 괴물이 최상위 Q0으로 강제 소환됨        │
  │          │  4. 렌더링이 Q0의 퀀텀을 잡아먹는 순간 마우스 멈춤         │
  │          │                                                            │
  │          ▼ [해결 조치: 커널 튜닝 (Tuning)]                            │
  │          S 파라미터를 10초(10,000ms) 이상으로 대폭 늘려,              │
  │          무거운 프로세스가 Q0의 맑은 물을 흐리는 빈도를 대폭 감소시킴.│
  └───────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 개발자가 스케줄러 파라미터를 잘못 튜닝하면 시스템에 어떤 끔찍한 간헐적 장애(Jitter)가 발생하는지 보여주는 사례다. 무거운 놈을 구제하겠다고 너무 자주 끌어올리면(짧은 S 주기), 정작 응답성이 생명인 I/O 바운드 프로세스들이 CPU를 제때 못 받아 전체 UX가 붕괴한다.

📢 섹션 요약 비유: 더러운 물(CPU 바운드)을 밑으로 가라앉히는 필터(강등 룰)를 훌륭하게 만들어 놓고선, 가라앉은 찌꺼기를 치우겠다고 1분에 한 번씩 정수기 바닥을 막대기로 뒤집어엎는(짧은 부스트 주기) 멍청한 파라미터 세팅입니다.

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

기대효과

MLFQ 파라미터를 정밀하게 모델링하면, 운영체제는 어떠한 사전 정보(실행 길이 예측) 없이도 런타임 찰나의 순간에 I/O 바운드(즉시 응답)와 CPU 바운드(백그라운드 일괄 처리)를 자동 필터링해 내어, 마우스는 미끄러지듯 부드럽게 움직이면서 남는 짜투리 자원으로 거대한 데이터 연산을 효율적으로 쳐내는 완벽한 시분할 경험을 선사한다.

결론 및 미래 전망

MLFQ의 5대 파라미터 모델은 40년 가까이 범용 OS 스케줄링의 알파이자 오메가로 군림했다. 그러나 그 **'적절한 파라미터 값(매직 넘버)을 찾는 노가다'**의 한계에 부딪혔다. 클라우드에서 천 개의 컨테이너가 뜰지 만 개가 뜰지 모르는 현대 환경에서 고정된 파라미터 S나 q값은 필연적으로 튜닝의 실패를 가져온다. 그 결과, 현대 리눅스는 MLFQ의 복잡한 큐 계층과 부스트 파라미터를 싹 다 쓰레기통에 버리고, 레드-블랙 트리 위에서 가상 실행 시간(vruntime)이라는 동적 상대점수 단 하나만으로 작동하는 CFS (Completely Fair Scheduler) 구조로 패러다임을 180도 전환하며 새로운 미래의 표준을 정립했다.

📢 섹션 요약 비유: 수십 개의 버튼과 다이얼(파라미터)을 돌려가며 라디오 주파수(시스템 최적점)를 맞추던 아날로그 라디오 시대(MLFQ)는 가고, 버튼 하나만 누르면 기계(CFS)가 알아서 노이즈가 없는 채널을 오토 서칭으로 딱 잡아주는 디지털 시대로 완전히 넘어갔습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
다단계 피드백 큐 (MLFQ)	이 5가지 파라미터들의 튜닝 값 조합이 모여서 비로소 물리적인 실체로 동작하게 되는 뼈대 프레임워크다.
타임 퀀텀 (Time Quantum/Slice)	MLFQ 파라미터 중 각 큐의 특성을 결정짓는 가장 날카로운 칼날이며, 위로 갈수록 짧고 아래로 갈수록 길어진다.
기아 상태 (Starvation)	승급(Promotion) 주기 S 파라미터를 잘못 설정하여 무한대급으로 늘려놓았을 때 최하위 큐에서 터지는 필연적 비극이다.
문맥 교환 (Context Switch)	큐의 개수(층) 파라미터가 너무 많거나, 퀀텀이 너무 짧을 때 폭주하여 시스템의 순수 연산 처리량을 깎아먹는 오버헤드다.
CFS (Completely Fair Scheduler)	"더 이상 사람이 파라미터(매직 넘버)를 찍어 맞추는 노가다를 하지 말자"며 MLFQ를 폐기하고 등장한 현대 리눅스 스케줄러다.

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

게임기(CPU)를 빌려줄 때, 선생님은 5가지 중요한 **규칙(파라미터)**을 정해야 해요. "줄은 몇 개로 나눌까?", "한 번에 몇 분씩 하게 해 줄까?" 같은 것들이죠.
만약 게임을 길게 한 친구를 쫓아내는 규칙(강등)을 너무 빡빡하게 1초로 잡으면, 애들이 게임은 1초만 하고 자리만 계속 바꾸느라 정작 게임기가 계속 놀게 돼요.
반대로 오래 기다린 불쌍한 친구를 맨 앞으로 부르는 규칙(승급 주기)을 10년으로 잡으면 애들이 기다리다 지쳐 집에 가버려요. 이 황금 비율의 숫자들을 알아내는 게 운영체제의 핵심 비밀이랍니다!