긴 계산 작업과 짧은 대화형 요청이 CPU를 함께 씁니다. FCFS, SJF, Round Robin은 대기 시간을 어떻게 바꾸나요?

세 정책의 차이는 ‘누가 먼저 CPU를 얻는가’와 ‘어떤 지연을 줄이려는가’에 있습니다. FCFS는 도착 순서를 지켜 구현이 단순하지만 긴 계산이 앞에 서면 뒤의 짧은 요청도 함께 기다립니다. SJF는 실행 시간이 짧다고 예상되는 작업을 먼저 선택해 특정 작업 집합의 평균 대기·완료 시간을 줄일 수 있지만, 미래 실행 시간을 정확히 알기 어렵고 긴 작업이 계속 밀릴 수 있습니다. Round Robin은 각 runnable 작업에 일정한 시간을 번갈아 주어 첫 응답과 공정성을 개선합니다. 따라서 평균 대기 하나가 아니라 첫 응답, 완료 시간, 최장 대기, 전환 비용을 목표에 맞춰 비교해야 합니다. 이 기준으로 CPU 스케줄링 정책을 선택합니다.

같은 입력을 정책별로 재생합니다

긴 작업 A가 먼저 들어오고 짧은 작업 B·C가 뒤따르면 FCFS는 A가 끝날 때까지 B·C를 기다리게 합니다. 비선점 SJF도 A가 이미 실행 중이라면 A를 끝낸 뒤 B·C를 처리합니다. 세 작업이 모두 준비된 선택 시점이라면 B·C를 먼저 선택할 수 있습니다. 실행 중인 작업도 중단할 수 있는 SRTF라면 새로 도착한 더 짧은 작업이 현재 작업을 선점해 반응성을 높일 수 있지만, 선점과 예측 오류가 추가됩니다. Round Robin에서는 quantum 안에 끝나는 B·C가 빠르게 응답할 수 있고 A는 여러 번의 차례를 거쳐 끝납니다. quantum이 너무 작으면 전환이 잦아져 실제 CPU가 스케줄링에 쓰이고, 너무 크면 긴 작업 하나가 오래 차지해 FCFS와 비슷해집니다.

작업 길이를 과거 실행 시간으로 예측한다면 예측값이 짧은 작업을 우선하되 실제로 긴 작업이 되는 순간 우선순위가 어긋납니다. 짧은 작업 우선에 aging을 넣거나 일정 시간 이상 기다린 작업의 우선순위를 높여 기아를 제한할 수 있습니다. 실제 운영체제는 이런 교과서 정책 하나를 그대로 노출하기보다 우선순위·타이머·I/O 대기·공정성 목표를 조합합니다. 그러므로 특정 OS의 실제 동작을 말할 때는 정책 이름보다 사용 중인 스케줄러와 우선순위 규칙을 먼저 확인하겠습니다.

평균이 아닌 사용자 영향으로 검증합니다

테스트에서는 동일한 도착 순서와 실행 시간 분포를 두고 정책별 대기·첫 응답·완료·최장 대기와 전환 횟수를 계산합니다. I/O 작업은 CPU를 스스로 양보하므로 순수 계산 작업과 별도 시나리오로 분리합니다. 대화형 요청의 p99가 중요하면 평균 개선만으로 정책을 선택하지 않고, 긴 작업이 허용된 시간 안에 끝나는지와 낮은 우선순위 작업이 기아에 빠지지 않는지를 함께 확인합니다.

SJF의 선택 시점과 선점 여부를 분리해야 합니다. A가 10ms이고 B·C가 각각 1ms라고 하겠습니다. A·B·C가 모두 실행 큐에 있는 순간 선택한다면 비선점 SJF는 B와 C를 먼저 처리할 수 있습니다. 그러나 A가 이미 실행 중인 상태에서 B·C가 도착하면 비선점 SJF는 A를 중간에 끊지 않고 끝낸 뒤 B·C를 처리합니다. 실행 중인 A를 B가 선점하게 하려면 선점형 SRTF 같은 다른 정책을 적용해야 하며, 그때는 선점 비용과 예측 오차를 추가로 부담합니다.

짧은 요청이 계속 들어오는 서비스에서는 평균 대기 시간이 좋아져도 긴 배치 작업이 굶을 수 있습니다. aging으로 오래 기다린 작업의 우선순위를 올리거나 긴 작업에 최소 CPU 몫을 예약하되, 그 결과 짧은 요청의 p99가 목표를 넘지 않는지 확인하겠습니다. 테스트에는 ‘모두 준비됨’, ‘A 실행 중 B·C 도착’, ‘짧은 작업 지속 유입’을 각각 넣고 도착 시각·선점 가능성·I/O 양보를 기록하겠습니다.

예를 들어 A가 이미 실행 중이고 남은 실행 시간이 8ms일 때 1ms 작업 B가 도착하면, 비선점 SJF는 A를 끝까지 실행한 뒤 B를 처리합니다. SRTF만 남은 실행 시간을 비교해 A를 선점합니다. 이 차이를 설명하지 않고 ‘SJF가 짧은 작업을 즉시 우선한다’고 말하면 정책의 핵심 전제를 놓친 것입니다.