CPU 바운드 프로세스 (CPU Bound Process)

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

본질: CPU 바운드 프로세스 (CPU Bound Process)는 생명 주기 동안 입출력(I/O) 대기 시간보다 CPU에서 수학적 연산과 데이터 처리를 수행하는 시간(CPU Burst)이 압도적으로 긴 프로세스다.

가치: 이들은 시스템의 연산 처리량(Throughput)을 주도하는 핵심 워크로드이지만, 단일 프로세스가 CPU를 너무 오래 독점하면 대화형 프로그램의 응답성을 심각하게 해치므로 스케줄러의 타임 슬라이싱 (Time Slicing) 대상 1순위가 된다.

융합: 인공지능 모델 학습, 빅데이터 분석, 동영상 인코딩 등이 대표적이며, 현대 클라우드에서는 이들을 위한 전용 고성능 컴퓨팅 (HPC) 인스턴스 할당과 다단계 피드백 큐(MLFQ)에서의 백그라운드 처리가 필수적이다.

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

개념: 프로세스의 실행은 CPU 버스트(연산 수행)와 I/O 버스트(입출력 대기)의 교대로 이루어지는데, CPU 바운드 프로세스는 한 번 CPU를 할당받으면 주어진 시간 할당량(Time Quantum)을 모두 소진할 때까지 I/O 요청 없이 계속해서 연산만 수행하는 성향을 가진다.
필요성: 과학 기술 연산, 암호화, 영상 처리 등 컴퓨팅의 본질적 목적은 '계산'에 있다. 시스템이 최대한의 연산 능력을 발휘하려면 CPU 바운드 프로세스가 코어를 쉬지 않고 100% 점유하도록 밀어붙여야 한다. 그러나 다른 프로세스들과의 공정성을 위해 스케줄러는 이 '계산 벌레'들의 폭주를 적절히 제어해야만 한다.
💡 비유: 한 번 마이크(CPU)를 잡으면 자의로는 절대 내려놓지 않고 노래방 1시간(할당 시간)을 꽉 채워 부르는 **'열창형 손님'**과 같다.
등장 배경: 과거 펀치 카드를 쓰던 일괄 처리(Batch) 메인프레임 시절의 모든 프로세스는 본질적으로 CPU 바운드였다. 그러나 시분할 시스템이 등장하면서, 대화형(I/O 바운드) 작업의 응답 시간을 보장하기 위해 CPU 바운드 프로세스를 강제로 중단(선점, Preemption)시키는 스케줄링 메커니즘이 발전하게 되었다.

  [프로세스의 버스트 교대 (Burst Cycle) 모델]

  CPU 바운드:  [ CPU Burst (길다) ] -> [ I/O ] -> [ CPU Burst (길다) ]
  I/O 바운드:  [ CPU ] -> [ I/O Burst (매우 길다) ] -> [ CPU ] -> [ I/O Burst ]
  
  (시각적 비교)
  CPU Bound: ███████████████████▒███████████████████▒
  I/O Bound: █▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒█▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
             (█: CPU 연산, ▒: I/O 대기)

[다이어그램 해설] 그림에서 보듯 CPU 바운드 프로세스는 생명 주기의 대부분을 연산(검은색 블록)으로 채운다. 이런 프로세스는 스케줄러가 강제로 뺏지 않으면 영원히 CPU를 놓지 않는 특성이 있다. 따라서 스케줄러는 반드시 타이머 인터럽트(Timer Interrupt)를 발생시켜 일정 시간마다 이들을 끌어내려야 시스템이 멈추지 않는다.

📢 섹션 요약 비유: 공부를 한 번 시작하면 쉬는 시간 종이 울릴 때까지 책에서 절대 눈을 떼지 않는 모범생(연산 몰두)과 같습니다. 선생님(스케줄러)이 강제로 쉬라고 하지 않으면 혼자서 교실을 독차지하게 됩니다.

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

특성 및 상태 변화 원리

특성	설명	내부 동작	비유
긴 CPU 버스트	연산 위주의 코드 블록 실행	캐시와 레지스터를 극도로 활용	마라톤 선수
타임 퀀텀 소진	자발적 반납 없이 시간 종료로 쫓겨남	타이머 인터럽트 발생 → Preempted	수능 시험 종료 알람
높은 캐시 의존도	문맥 교환 시 성능 페널티 극심	지속 실행 시 L1/L2 캐시 적중률 100% 수렴	예열된 엔진
배치 (Batch) 지향	빠른 응답보다 총 처리 시간이 중요	반환 시간(Turnaround Time)이 핵심 지표	대량 택배 발송

다단계 피드백 큐 (MLFQ) 에서의 처리 매커니즘

현대 스케줄러(예: 윈도우 스케줄러, 전통적 유닉스 스케줄러)는 CPU 바운드 프로세스를 식별하여 백그라운드 큐로 밀어내는 방식을 쓴다.

최고 우선순위 부여 (초기): 프로세스가 처음 생성되면 일단 I/O 바운드인지 알 수 없으므로 가장 높은 우선순위 큐(Q0)에 배치한다.
타임 퀀텀 만료 (Time Quantum Expired): 프로세스가 짧은 시간(예: 10ms)을 다 소진하고도 자발적으로 I/O를 요청하지 않으면, 스케줄러는 이 프로세스를 CPU 바운드로 낙인찍는다.
우선순위 강등 및 타임 슬라이스 증가: 해당 프로세스는 하위 큐(Q1)로 강등된다. 대신 하위 큐에서는 더 긴 시간(예: 20ms)을 부여받는다. 이 과정을 반복하여 최종적으로 가장 밑바닥 큐(최저 우선순위)에 도달한다.
백그라운드 일괄 처리: 최하위 큐에서는 100ms 이상의 아주 긴 타임 슬라이스를 받으며, 상위 큐가 텅 비었을 때만 CPU를 할당받아 방해받지 않고 묵직한 연산을 몰아서 수행한다.

  ┌──────────────────────────────────────────────────────────────────┐
  │       다단계 피드백 큐 (MLFQ)에서의 CPU 바운드 강등 원리         │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │  [Q0: 최고 우선순위, 할당량 10ms]  ◀── 처음 진입                 │
  │     │                                                            │
  │     ▼ (10ms 꽉 채워서 사용 → 강제로 쫓겨남)                      │
  │                                                                  │
  │  [Q1: 중간 우선순위, 할당량 20ms]                                │
  │     │                                                            │
  │     ▼ (20ms 꽉 채워서 사용 → 강제로 쫓겨남)                      │
  │                                                                  │
  │  [Q2: 최하 우선순위, 할당량 40ms]  ◀── 최종 정착지 (배치 큐)     │
  │     │                                                            │
  │     └─▶ 40ms 내내 CPU 독점 후 라운드 로빈 순환                   │
  │                                                                  │
  │  * 결과: CPU 바운드는 최하위 큐로 강등되나, 한 번 잡으면 길게 씀 │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 구조는 두 가지 토끼를 모두 잡는 천재적인 설계다. 대화형 작업(I/O 바운드)은 즉시 처리되도록 상위 큐에 남기고, 연산 작업(CPU 바운드)은 문맥 교환에 따른 오버헤드를 줄이기 위해 하위 큐에서 한 번에 길게 실행시킨다. 문맥 교환이 잦으면 캐시가 계속 무효화(Cache Miss)되어 연산 성능이 떨어지므로, CPU 바운드에게는 잦은 전환보다 한 번에 긴 시간을 주는 것이 시스템 전체의 처리량(Throughput) 상승으로 이어진다.

📢 섹션 요약 비유: 은행 창구에서 복잡한 대출 상담(CPU 바운드)을 하러 온 손님은, 잔돈을 바꾸러 온 손님들(I/O 바운드)이 다 끝날 때까지 기다리게 하되, 한 번 상담이 시작되면 1시간 동안 온전히 집중해 주는 것과 같습니다.

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

CPU 바운드 vs I/O 바운드의 스케줄링 트레이드오프

비교 항목	CPU 바운드 프로세스	I/O 바운드 프로세스
CPU 점유 패턴	길고 묵직함 (수십~수백ms)	아주 짧고 빈번함 (1~5ms)
문맥 교환 오버헤드	치명적 (캐시 무효화 발생)	상대적으로 적음 (어차피 대기하러 감)
스케줄러의 대우	우선순위 낮춤, 타임 슬라이스는 길게	우선순위 높임, 타임 슬라이스는 짧게
최우선 성능 지표	반환 시간 (Turnaround Time), 처리량(Throughput)	응답 시간 (Response Time)

단기 스케줄러가 CPU 바운드에게 낮은 우선순위를 주지만, 절대 버리는 것은 아니다. 만약 I/O 바운드 프로세스들이 CPU를 계속 차지하여 CPU 바운드가 너무 오랫동안 실행되지 못하면 **기아 상태 (Starvation)**에 빠진다. 이를 막기 위해 일정 주기(예: 1초)마다 시스템 내의 모든 프로세스의 우선순위를 일시적으로 최고 단계로 끌어올리는 에이징(Aging) 기법이 적용된다.

  [CPU 바운드 프로세스의 스케줄링 딜레마]
  
  시간 할당량(Quantum)이 너무 작을 때:
  [Q][스위치][Q][스위치][Q][스위치]
  >> 결과: 오직 문맥 교환만 하다가 CPU 낭비, 연산 진행 불가
  
  시간 할당량(Quantum)이 너무 클 때:
  [██████████████ Quantum ██████████████]
  >> 결과: 연산 효율은 좋으나 I/O 바운드(마우스 클릭)가 얼어붙음(프리징)
  
  * 최적점: I/O보다는 후순위로 미루되, 한 번 할당 시 오버헤드를 상쇄할 만큼 충분한 시간을 부여 (동적 조절)

📢 섹션 요약 비유: 자동차가 고속도로(CPU)에 올랐을 때 가다 서다를 반복(잦은 스위치)하면 연비(효율)가 최악이 되므로, 한적한 차선(하위 큐)으로 몰아서 한 번에 쭉 달리게 해주는 것이 좋습니다.

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

실무 시나리오

빅데이터 분석 및 AI 모델 훈련 노드 구성: 쿠버네티스 (K8s) 클러스터에서 머신러닝 훈련 컨테이너는 전형적인 극단적 CPU/GPU 바운드 워크로드다. 이를 일반 웹 서버(I/O 바운드)와 같은 노드에 섞어두면, 훈련 작업이 노드의 L3 캐시를 모조리 밀어내고 CPU를 잡아먹어 웹 서버의 지연율(Latency)이 치솟는 Noisy Neighbor (시끄러운 이웃) 문제가 발생한다.
- 아키텍처 결단: Taint/Toleration 및 Node Affinity를 사용하여 CPU 바운드 전용 노드 그룹(HPC 노드)을 하드웨어 레벨에서 격리해야 한다.
리눅스 CFS (Completely Fair Scheduler)의 튜닝: 배치 작업(동영상 인코딩 등)을 수행하는 리눅스 서버에서는, 잦은 문맥 교환을 막기 위해 커널 파라미터인 sched_min_granularity_ns (최소 보장 실행 시간) 값을 높게 튜닝한다. 이를 통해 CPU 바운드 프로세스가 선점당하지 않고 캐시 히트를 유지하며 더 오랫동안 연산할 수 있게 만들어 전체 인코딩 시간을 단축시킨다.

  ┌────────────────────────────────────────────────────────────┐
  │     워크로드 특성에 따른 노드 분리 (Isolation) 전략        │
  ├────────────────────────────────────────────────────────────┤
  │                                                            │
  │   신규 마이크로서비스 배포                                 │
  │                │                                           │
  │                ▼                                           │
  │   어떤 성격의 워크로드인가?                                │
  │          ├─ [API 웹/모바일 백엔드 (I/O Bound)]             │
  │          │      │                                          │
  │          │      ▼                                          │
  │          │  General Purpose 노드 배포 (스레드/비동기)      │
  │          │                                                 │
  │          └─ [이미지/비디오 변환, AI 추론 (CPU Bound)]      │
  │                 │                                          │
  │                 ▼                                          │
  │             Compute Optimized (C-type) 전용 노드 배포      │
  │                 │                                          │
  │                 ▼                                          │
  │         스케줄러 퀀텀 증가 & 캐시 간섭(Noisy Neighbor) 차단│
  └────────────────────────────────────────────────────────────┘

[다이어그램 해설] 클라우드 아키텍트가 워크로드를 식별하고 AWS EC2 인스턴스 타입을 고를 때의 기본 원칙이다. I/O 바운드는 네트워크 대역폭과 병렬 연결 처리가 중요하므로 범용(M 인스턴스)이나 메모리 최적화가 어울린다. 반면 CPU 바운드는 고주파수 코어와 큰 L3 캐시가 중요하므로 컴퓨팅 최적화(C 인스턴스) 노드에 단독으로 격리하여, 그들이 마음껏 CPU를 독점하도록 풀어주어야 비용 대비 성능(ROI)이 극대화된다.

📢 섹션 요약 비유: 조용한 독서실(CPU 바운드 노드)과 시끌벅적한 콜센터(I/O 바운드 노드)를 같은 방에 두면 둘 다 망합니다. 업무 성격에 맞춰 공간을 아예 분리해 주는 것이 최고의 스케줄링입니다.

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

기대효과

운영체제가 CPU 바운드 프로세스를 식별하여 타임 슬라이스를 길게 주고 백그라운드로 밀어내면, 대화형 프로그램의 응답성을 해치지 않으면서도 시스템의 유휴 CPU 자원을 100%까지 쥐어짜 내어 거대한 연산 작업을 효율적으로 완수할 수 있다.

결론 및 미래 전망

미래의 운영체제는 멀티코어 환경에서 CPU 바운드 프로세스의 스케줄링을 '어느 코어에 고정할 것인가(CPU Affinity)'로 최적화하고 있다. 프로세스가 다른 코어로 이동하면 해당 코어의 L1/L2 캐시를 처음부터 다시 채워야 하는 웜업(Warm-up) 페널티가 막심하기 때문이다. 나아가 ARM의 big.LITTLE 구조처럼, 가벼운 I/O 바운드는 전력 소모가 적은 LITTLE 코어에 배정하고, 무거운 CPU 바운드 연산은 고성능 big 코어에 배정하는 이기종 스케줄링(HMP)이 모바일과 서버 프로세서의 새로운 표준으로 자리 잡았다.

📢 섹션 요약 비유: 이제 스케줄러는 단순한 시간 배분을 넘어, 짐이 많은 트럭(CPU 바운드)은 아예 튼튼한 트럭 전용 고속도로(고성능 코어)로 배정하여 도로 파손(캐시 미스)을 막는 입체적인 관리자로 진화했습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
I/O 바운드 프로세스 (I/O Bound)	CPU 바운드와 정반대의 성격을 지니며, 이 두 유형을 어떻게 구별하고 대우하느냐가 모든 OS 스케줄링 알고리즘의 핵심 과제다.
다단계 피드백 큐 (MLFQ)	CPU 바운드 프로세스를 식별하여 타임 퀀텀을 소진할 때마다 하위 큐로 강등시키는 가장 대표적인 스케줄러 알고리즘이다.
타임 퀀텀 (Time Quantum)	시분할 시스템에서 한 번에 허용하는 CPU 점유 시간으로, 이 값이 너무 작으면 CPU 바운드 프로세스는 문맥 교환 오버헤드에 짓눌려 성능이 급감한다.
기아 상태 (Starvation)	I/O 바운드 프로세스들이 CPU를 지속적으로 가로챌 때, 하위 큐에 처박힌 CPU 바운드 프로세스가 영원히 실행되지 못하는 상태다.
코어 친화도 (CPU Affinity)	CPU 바운드 프로세스가 스케줄링될 때 캐시 히트율을 극대화하기 위해 이전에 실행되었던 특정 물리 코어에 계속 할당되도록 고정하는 최적화 기법이다.

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

CPU 바운드 프로세스는 한 번 책상에 앉아 수학 문제(CPU 연산) 풀기를 시작하면 다른 데 한눈팔지 않고 끝까지 집중하는 엉덩이가 무거운 친구예요.
하지만 이 친구가 선생님(CPU)의 관심을 계속 혼자서만 독차지하면, 다른 친구들이 질문을 못해서 교실이 엉망이 되겠죠?
그래서 컴퓨터 선생님(스케줄러)은 এই 친구에게 "너는 이따가 다른 친구들 다 끝나면 아주 길~~게 선생님이랑 따로 풀자!" 하고 배려 있는 순서 조정을 해준답니다!