172. 반환 시간 (Turnaround Time) / 대기 시간 (Waiting Time) / 응답 시간 (Response Time)

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

1. 본질: 반환 시간 (Turnaround Time), 대기 시간 (Waiting Time), 응답 시간 (Response Time)은 하나의 프로세스 생애를 서로 다른 기준점으로 잰 세 개의 시계로, 완료까지의 총 시간, 준비 큐 대기 누적 시간, 첫 반응까지의 시간을 각각 보여 준다.
2. 가치: 배치 시스템은 반환 시간을, 대화형 시스템은 응답 시간을, 스케줄러 자체 성능 비교는 대기 시간을 더 중요하게 보므로 같은 스케줄링 결과도 어떤 지표로 보느냐에 따라 평가는 달라진다.
3. 판단 포인트: 응답 시간을 줄이기 위해 선점과 짧은 타임 퀀텀 (Time Quantum)을 쓰면 문맥 교환 (Context Switch) 오버헤드 때문에 반환 시간이 나빠질 수 있으므로, 워크로드와 서비스 목표에 맞는 지표 우선순위를 먼저 정해야 한다.

Ⅰ. 개요 및 필요성

세 지표는 모두 "프로세스가 얼마나 빨리 처리되었는가"를 말하지만, 보는 각도가 다르다. 반환 시간은 작업이 도착한 순간부터 완전히 끝날 때까지의 전체 수명이고, 대기 시간은 레디 큐 (Ready Queue)에서 CPU (Central Processing Unit)를 기다린 순수한 시간의 합이다. 응답 시간은 그중에서도 처음 CPU를 배정받아 반응이 시작될 때까지의 지연만 따로 떼어 본 값이다.

이 구분이 중요한 이유는 운영체제가 상대하는 워크로드가 하나가 아니기 때문이다. 야간 배치 작업은 "언제 다 끝나는가"가 핵심이지만, 웹 브라우저나 터미널은 "첫 화면이 얼마나 빨리 뜨는가"가 더 중요하다. 따라서 스케줄링 알고리즘은 단순히 CPU를 많이 쓰게 하는 것만으로는 평가할 수 없고, 어떤 시간 지표를 우선 보호하는지 함께 봐야 한다.

아래 그림은 하나의 프로세스 생애에서 세 지표가 서로 다른 구간을 가리킨다는 점을 보여준다.

┌──────────────────────────────────────────────────────────────┐
│ One process, three stopwatches                              │
├──────────────────────────────────────────────────────────────┤
│ arrival -> ready -> run -> I/O wait -> ready -> run -> exit │
│ response   = arrival -> first run start                     │
│ waiting    = all ready intervals added                      │
│ turnaround = arrival -> exit                                │
└──────────────────────────────────────────────────────────────┘

이 그림의 핵심은 세 값이 서로 완전히 독립적이지 않다는 점이다. 반환 시간은 응답 시간보다 항상 크거나 같고, 대기 시간은 그 안에 부분적으로 포함된다. 결국 스케줄러는 같은 생애를 서로 다른 기준으로 좋게 보이게 할 수 있지만, 모든 지표를 동시에 최적으로 만들 수는 없다.

• 📢 섹션 요약 비유: 같은 식당 방문도 "언제 음식이 다 나왔는가", "줄 서서 멍하니 기다린 시간은 얼마인가", "주문받으러 처음 온 시간은 얼마나 빠른가"를 각각 따로 재면 평가가 달라지는 것과 같다.

Ⅱ. 아키텍처 및 핵심 원리

세 지표는 계산식으로 연결된다. 반환 시간은 완료 시점 - 도착 시점이고, 응답 시간은 첫 CPU 할당 시점 - 도착 시점이다. 대기 시간은 프로세스가 실행 중도 아니고 I/O (Input/Output) 대기 중도 아닌 채 Ready Queue에 머문 시간의 총합이며, CPU burst와 I/O 서비스 시간이 정해져 있다면 결국 스케줄러가 가장 직접적으로 바꾸는 값은 대기 시간이라고 볼 수 있다.

아래 그림은 운영체제 스케줄러가 실제로 어떤 구간을 가장 많이 바꿀 수 있는지를 보여 준다.

┌──────────────────────────────────────────────────────────────┐
│ What the scheduler can really change                        │
├──────────────────────────────────────────────────────────────┤
│ CPU burst time   -> workload property                       │
│ I/O service time -> device / subsystem property             │
│ ready-queue wait -> scheduler's main control lever          │
│ therefore waiting time is the cleanest scheduling signal    │
└──────────────────────────────────────────────────────────────┘

이 말은 스케줄러가 모든 시간을 마음대로 조작할 수 있다는 뜻이 아니다. 실제 CPU burst 길이와 디스크 응답 시간은 애플리케이션과 장치가 좌우한다. 그래서 스케줄러 비교에서 대기 시간이 자주 핵심 지표가 되고, 응답 시간은 사용자 체감 성능을 보여 주는 별도 렌즈로 다뤄진다.

또 하나 중요한 것은 평균뿐 아니라 편차다. 평균 응답 시간이 짧아도 어떤 요청은 10ms, 어떤 요청은 2초가 걸린다면 사용자는 시스템을 불안정하다고 느낀다. 그래서 현대 서비스 운영에서는 평균 응답 시간뿐 아니라 p95, p99, 지터 (Jitter)까지 함께 본다.

• 📢 섹션 요약 비유: 스케줄러는 학생의 시험 문제 난이도나 채점 속도를 바꾸는 사람이 아니라, 누가 먼저 시험지를 받고 언제 감독관의 관심을 받는지를 조정하는 사람에 가깝다.

Ⅲ. 비교 및 연결

세 지표는 스케줄링 알고리즘의 성격을 가장 잘 드러낸다. 같은 작업 집합이라도 어떤 정책은 평균 반환 시간을 낮추고, 어떤 정책은 첫 응답을 빠르게 만든다. 결국 알고리즘을 비교할 때는 "누가 더 빠른가"보다 "무엇을 더 빠르게 만들었는가"를 구분해야 한다.

예를 들어 모든 프로세스가 t=0에 도착하고 CPU burst가 P1=8ms, P2=4ms, P3=1ms라고 하자. 문맥 교환 오버헤드는 무시하면 아래처럼 해석할 수 있다.

┌──────────────────────────────────────────────────────────────┐
│ Same workload: P1=8, P2=4, P3=1                             │
├──────────────────────────────────────────────────────────────┤
│ FCFS   : | P1 0-8 | P2 8-12 | P3 12-13 |                    │
│ SJF    : | P3 0-1 | P2 1-5  | P1 5-13  |                    │
│ RR q=2 : |P1|P2|P3|P1|P2|P1|P1|                             │
│ insight: SJF lowers avg wait, RR improves first response    │
└──────────────────────────────────────────────────────────────┘

이 표가 말하는 것은 응답 시간과 반환 시간이 항상 같은 방향으로 좋아지지 않는다는 사실이다. FCFS는 단순하지만 convoy effect를 만들기 쉽고, SJF는 평균 관점에서 훌륭하지만 예측 실패와 starvation 위험이 있다. RR은 인터랙티브 환경에서 첫 반응을 빠르게 만들지만, quantum을 지나치게 짧게 잡으면 context switch 비용 때문에 전체 효율이 떨어진다.

• 📢 섹션 요약 비유: 줄이 긴 은행에서 한 사람 일을 끝까지 다 봐 주면 전체 완료는 단순하지만 뒤 사람은 답답하고, 잠깐씩 돌아가며 응대하면 모두가 빨리 "내 차례가 왔다"는 느낌은 받지만 전체 일처리는 조금 느려질 수 있다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 워크로드 성격에 따라 지표 우선순위를 달리 잡아야 한다. 사용자 클릭, 입력, 화면 갱신처럼 사람을 상대하는 시스템은 응답 시간이 핵심이며, 여기서는 평균보다 tail latency와 jitter가 더 중요하다. 반대로 야간 정산, 대규모 로그 처리, 모델 학습처럼 결과 완료 시점이 중요한 작업은 반환 시간과 처리량이 더 중요한 판단 기준이 된다.

┌──────────────────────────────────────────────────────────────┐
│ Metric-first scheduling choice                              │
├──────────────────────────────────────────────────────────────┤
│ interactive and user-facing?                                │
│   ├─ yes -> response time / variance first                  │
│   └─ no                                                     │
│       │                                                     │
│       ▼                                                     │
│ batch or deadline completion critical?                      │
│   ├─ yes -> turnaround time / throughput first              │
│   └─ mixed -> class-based policy and fairness balance       │
└──────────────────────────────────────────────────────────────┘

실무 판단 기준

1. 서비스가 사람의 즉각 반응을 요구하는가, 아니면 총 완료 시간이 중요한가?
2. 타임 퀀텀이 짧아져 응답 시간은 좋아졌지만 문맥 교환 오버헤드가 급증하지 않았는가?
3. 평균값이 좋아 보여도 특정 클래스의 starvation이나 p99 지연 붕괴가 없는가?
4. I/O 바운드 작업과 CPU 바운드 작업을 같은 정책으로 다뤄도 되는가?

자주 나오는 안티패턴

• 응답 시간 하나만 보고 quantum을 지나치게 짧게 줄여 시스템 전체 효율을 무너뜨리는 것
• 평균 반환 시간만 보고 인터랙티브 작업의 첫 반응 지연을 무시하는 것
• Ready Queue 대기와 I/O 병목을 구분하지 않고 모든 지연을 스케줄러 문제로 보는 것

기술사 답안에서는 세 지표를 정의만 나열하기보다, "어떤 정책이 어떤 지표를 희생하고 어떤 지표를 살리는가"까지 연결해야 한다. 운영체제 설계는 결국 하나의 절대 최적값을 찾는 일이 아니라, 서비스 목적에 맞는 시간 감각을 선택하는 일이다.

• 📢 섹션 요약 비유: 택배 회사도 "문 앞에 처음 도착한 시간"을 중요하게 볼지, "모든 택배를 오늘 안에 끝냈는가"를 중요하게 볼지에 따라 배차 방식이 달라지는 것과 같다.

Ⅴ. 기대효과 및 결론

세 지표를 분리해서 보면 스케줄링 정책의 성격을 더 정확히 해석할 수 있다. 반환 시간은 배치 효율을, 대기 시간은 큐 관리 품질을, 응답 시간은 사용자 체감을 설명해 준다. 그래서 스케줄러 설계, 우선순위 정책, 서비스 수준 목표 (Service Level Objective, SLO) 설정이 훨씬 명확해진다.

물론 한계도 있다. 세 값 모두 CPU 스케줄링을 중심으로 설명되므로, 네트워크 지연이나 저장장치 병목처럼 시스템 외부 요소를 혼자 설명하지는 못한다. 또한 평균값만 보면 starvation, tail latency, 클래스 간 불공정 문제를 놓칠 수 있으므로 분포와 편차를 함께 봐야 한다.

결론적으로 반환 시간, 대기 시간, 응답 시간은 서로 다른 개념이 아니라 하나의 작업 생애를 세 방향에서 읽는 좌표계다. 좋은 스케줄링은 이 세 값을 모두 최소화하는 마법이 아니라, 서비스 목적에 맞는 지표를 우선 보호하면서 다른 지표의 희생을 통제 가능한 범위에 두는 설계라고 기억하는 것이 정확하다.

• 📢 섹션 요약 비유: 같은 여행도 집을 나선 뒤 돌아오기까지 걸린 총시간, 공항 줄에서 보낸 시간, 탑승 안내를 처음 받은 시간을 따로 재면 여행 품질 평가가 달라지는 것과 같다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

process arrival
    │
    ▼
first CPU dispatch
    │
    ├──────────────▶ response time
    ▼
ready-queue accumulations
    │
    ├──────────────▶ waiting time
    ▼
process completion
    │
    └──────────────▶ turnaround time

이 흐름도는 세 지표가 각각 다른 시점에서 잘려 나오는 값이지만, 결국 하나의 프로세스 생애를 단계별로 측정한 결과임을 보여준다.

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

1. 응답 시간은 네가 게임 시작 버튼을 눌렀을 때 화면이 처음 반짝하는 데 걸린 시간이에요.
2. 대기 시간은 네 차례가 오기까지 줄에서 기다린 시간들을 모두 더한 거예요.
3. 반환 시간은 게임을 시작해서 끝내고 결과 화면을 볼 때까지 걸린 전체 시간이에요.