
CPU 스케줄링을 학습하던 중, 대규모 언어 모델에도 유사한 자원 분배 로직이 적용될 수 있음을 직관적으로 느꼈습니다. ChatGPT 응답 지연 현상을 단순한 연산 지연이 아닌, 시스템 레벨의 스케줄링 이슈로 해석할 수 있는지 살펴보고자 했습니다. GPT의 내부 구조는 공개되어 있지 않지만, 운영체제의 스케줄링 이론과 공개된 AI 서빙 인프라 사례를 바탕으로 추론 가능한 수준의 구조적 유사성을 정리했습니다.
입력했는데, 왜 아무 반응이 없을까
ChatGPT를 쓰다 보면 가끔 응답이 늦을 때가 있다. 입력은 했는데, 아무 반응 없이 멈춰 있는 것처럼 보이는 순간. 모델이 복잡한 답변을 구성하느라 시간이 걸리는 걸까? 실제로는 그렇지 않다.
이런 지연은 대부분 서버 측의 처리 대기 때문이며, 리소스를 어떻게 분배할지 결정하는 스케줄링 과정에서 발생한다. 사용자 수는 계속 늘어나고, 연산 자원은 제한되어 있다. 결국 누군가는 먼저, 누군가는 나중에 처리된다. 우리는 이 구조를 낯설지 않게 설명할 수 있다. 바로, 운영체제에서 배우는 CPU Scheduling 개념과 유사하기 때문이다.
하나의 CPU가 여러 작업을 조율하듯, 대형 언어 모델도 수많은 요청 사이에서 연산 자원을 분배해야 한다. 물론 ChatGPT는 수천 대의 서버가 동시에 작동하는 클러스터 환경에 기반하고 있지만, “누가 먼저 처리될 것인가”를 결정해야 하는 문제는 여전히 남는다.
이번 글에서는 이러한 구조적 유사성에 주목해, GPT 응답 속도 이슈를 단순한 체감 지연이 아니라 시스템 레벨의 스케줄링 문제로 바라보는 관점을 공유하고자 한다.
컴퓨터는 모든 걸 동시에 처리하지 않는다
운영체제에서 CPU Scheduling은 기본적인 개념이다. 하나의 CPU가 여러 프로세스를 동시에 처리할 수 없기 때문에, 어떤 작업을 먼저 실행할지 순서를 정하는 정책이 필요하다. 이때 사용되는 대표적인 스케줄링 알고리즘에는 다음과 같은 것들이 있다:
• FCFS (First-Come, First-Served): 먼저 도착한 작업을 먼저 실행
• SJF (Shortest Job First): 실행 시간이 가장 짧은 작업을 먼저
• RR (Round Robin): 각 작업에 동일한 시간 조각(Time Quantum)을 배분해 순차적으로 처리
• Priority Scheduling: 우선순위가 높은 작업부터 처리
스케줄링의 목적은 단순히 “빠른 처리”가 아니다. CPU의 활용률을 최대화하고, 시스템 전체의 응답성과 사용자 만족도를 균형 있게 유지하는 것이 핵심이다. 특히 여러 작업이 동시에 들어오는 상황에서는 “누가 먼저 처리되느냐”에 따라 전반적인 성능이 크게 달라진다.
GPT는 어떻게 순서를 정할까
⚠️ 주의사항
이 글에서 설명하는 GPT의 요청 처리 구조는, 공식적으로 공개된 정보가 아닙니다. 운영체제의 CPU 스케줄링 개념과, 공개된 AI 모델 서빙 인프라의 일반적인 구조를 바탕으로 가능한 흐름을 추론한 내용입니다. OpenAI 또는 특정 모델의 내부 설계와는 차이가 있을 수 있습니다.
GPT 같은 모델은 사용자 요청을 즉시 처리하지 않고, 먼저 Request Queue(요청 대기열)에 저장한다. 이 구조는 흔히 Model Serving Queue라고도 불리며, 요청을 일정 기준에 따라 정렬하고 묶어 처리하기 위한 전처리 단계이다. 즉, 모델이 ‘무엇부터 처리할지’를 결정하는 첫 관문이자, 시스템 전체 성능을 좌우하는 핵심 요소다.
예컨대, 요청의 길이가 짧거나 유료 사용자일수록 우선 처리될 수 있고, 연산 자원이 많이 드는 요청은 후순위로 밀리기도 한다. 또한 시스템은 길이가 비슷한 요청을 동적으로 묶어 GPU 효율을 높이는 방식으로 배치를 구성한다. 이처럼 GPT의 응답 속도 뒤에는 우선순위 큐와 배치 최적화 전략이 함께 작동하고 있으며, 이는 우리가 CPU 스케줄링에서 배우는 원리가 대규모 AI 시스템에서도 여전히 유효함을 보여준다.
📌 Request Queue란?
GPT 같은 모델은 사용자 요청을 즉시 처리하지 않고, 먼저 Request Queue(요청 대기열)에 넣는다. 이 구조는 모델 서빙 환경에서 일반적으로 사용되는 방식으로, 요청은 순차 처리되지 않고 요청 길이, 사용자 유형, 서버 상태 등에 따라 우선순위가 동적으로 조정된다.
GPT 시스템, 아마도 이렇게 작동하지 않을까?
GPT의 실제 요청 처리 방식은 공개되어 있지 않지만, 현재 사용되는 대규모 모델 서빙 구조를 바탕으로 어떤 식으로 작동할 수 있는지 추정해볼 수 있다. 예를 들어, 수천 명의 사용자가 동시에 요청을 보낸다고 가정해보자. 이 구조에서는 사용자 요청을 먼저 Request Queue(요청 대기열)에 저장하고,이후 시스템은 이 큐를 기준으로 처리 순서를 정하고 요청을 배치한다. 여기서 시스템은 다음과 같은 기준으로 처리 순서를 정할 수 있다:
• 요청자가 유료 사용자라면 우선적으로 처리
• 요청의 길이(예상 token 수)가 짧을수록 빠르게 배치
• GPU 자원 사용량이 높을 것으로 예상되는 요청은 대기열에서 후순위로 밀림
• 같은 유형의 요청을 모아 동적 배치(Dynamic Batching)를 구성하여 GPU 효율을 높임
이러한 기준에 따라 요청은 적절한 GPU 서버로 분산되고, 우선순위 큐(priority queue)와 배치 최적화(batch scheduler)가 함께 작동하면서 실제 처리 순서가 결정된다. 즉, GPT는 단순히 입력 순서대로 대답하는 것이 아니라, 비용, 효율, 우선권을 고려해 유연하게 스케줄링되는 시스템 안에서 움직인다. 이는 우리가 운영체제에서 배우는 CPU Scheduling 개념이, 대규모 AI 시스템에서도 확장 가능한 원리임을 보여준다.

GPT의 응답 처리 흐름은 OpenAI에서 공개된 구조는 아니지만, Ray Serve, NVIDIA Triton, TensorFlow Serving과 같은 대표적인 AI 서빙 시스템의 구조와 높은 유사성을 보인다. 특히 Request Queue → Priority Queue → Batch Scheduling → GPU Execution이라는 기본 처리 흐름은 여러 시스템에서 동일하게 반복되는 패턴이다.
[ AI 모델 서빙 시스템에 공통적으로 나타나는 스케줄링 구조 ]
| 시스템 | Request Queue | Priority 적용 | Batch 구성 | GPU 분산 방식 |
| Ray Serve | ✅ | ✅ (Custom policy 기반) | ✅ (@serve.batch 등) | ✅ Replica (Actor 단위 수평 분산) |
| Triton | ✅ | ✅ (Model Priority 설정 가능) | ✅ (dynamic_batching) | ✅ Backend Instance Pool 기반 |
| TF Serving | ✅ | ❌ (요청 단위 Priority 없음) | ✅ (BatchingParameters) | ✅ 단일 모델에 할당, 버전 교체 방식 (AspiredPolicy) |
📌 Batch Inference란?
여러 개의 요청을 하나로 묶어 GPU에서 동시에 처리하는 방식이다. 같은 길이의 요청끼리 묶으면 연산 효율이 올라가고, 전체 응답 시간이 줄어든다. GPT는 이 구조를 통해 비용을 줄이고 성능을 높인다. 이때 요청을 묶는 기준은 요청 길이, 모델 예상 토큰 수 등이다.
📌 Priority Queue란?
모든 요청을 하나의 줄에 단순히 쌓는 게 아니라, 우선순위가 높은 요청부터 먼저 처리하는 방식이다. 예를 들어 유료 사용자, 간단한 요청, 리소스를 적게 쓰는 요청은 먼저 처리될 수 있고, 긴 문장 생성처럼 계산이 오래 걸리는 요청은 뒤로 밀릴 수 있다. GPT 서버는 이 구조를 활용해 서버 부하를 조절하고 응답 속도를 최적화한다.
정해진 순서, 보이지 않는 설계
우리는 종종 컴퓨터나 AI가 모든 일을 동시에 처리할 수 있을 거라 생각하지만, 실제로는 그렇지 않다. 모든 시스템에는 한계가 있고, 그 안에서 ‘누구를 먼저 처리할 것인가’를 결정하는 질서의 로직, 즉 스케줄링이 필요하다.
GPT처럼 거대한 분산 시스템조차도 이 원칙에서 벗어나지 않는다. 아무리 복잡한 연산도, 수천 개의 요청도 결국에는 줄을 서고, 순서를 기다리고, 할당된 리소스 안에서 움직인다.
CPU 스케줄링이라는 개념은 단순히 운영체제 시험에 나오는 이론이 아니다. 우리가 사용하는 많은 시스템 뒤에서 보이지 않게 작동 중인 ‘결정의 알고리즘’을 이해하는 출발점이다. 이런 기본 개념을 알고 있으면, AI의 동작 원리도, 웹 서비스의 성능 이슈도, 나아가 시스템 전체의 설계 방식까지 더 넓게 볼 수 있게 된다.
줄을 세우는 건 단순한 기술 같지만, 그 줄을 ‘어떻게 세우느냐’는 생각보다 훨씬 복잡하고, 흥미롭다. 그리고 바로 그 안에, 우리가 CPU 스케줄링을 배우는 이유가 있다.