AI 스케줄러 (AI scheduler) 전쟁은 이미 시작되었지만, 거의 아무도 이를 다루지 않고 있습니다. 업계가 그 모델이 무엇을 할 수 있는지 조용히 결정하는 레이어 (layer) 대신 모델 자체에만 카메라를 비추고 있기 때문입니다. 매 분기마다 컨텍스트 윈도우 (context windows), 추론 벤치마크 (reasoning benchmarks), 또는 에이전트 프레임워크 (agent frameworks)에 대한 새로운 발표가 이어집니다. 하지만 이러한 모든 발표의 이면에는 마케팅 팀이 전면에 내세우고 싶어 하지 않는, 아무도 주목하지 않는 동일하고 지루한 질문이 자리 잡고 있습니다. 바로 무엇을, 언제, 어디서 실행할지, 그리고 누구의 권한으로 실행할지를 누가 결정하느냐는 것입니다. 이것은 모델의 문제가 아닙니다. 그것은 스케줄러 (scheduler)의 문제입니다.

AI scheduler war — resource, task, and authority scheduling converging above the model layer

AI 스케줄러 전쟁: 모델은 아무것도 결정하지 않는다

단순한 메커니즘부터 시작해 봅시다. 모델은 출력을 생성합니다. 모델은 실행 순서를 결정하지 않으며, 예산을 강제하지도 않고, 어떤 GPU에서 실행될지 선택하지도 않으며, 방금 제안한 동작이 실제로 실행되어도 되는지를 결정하지도 않습니다. 이러한 모든 결정은 모델이 결코 볼 수 없는 레이어 (layer)에서 일어납니다.

모델은 모든 사람이 직접 상호작용하는 부분이기 때문에 이를 놓치기 쉽습니다. 모델은 채팅창, 벤치마크 점수, 릴리스 노트 (release note)를 가진 부분입니다. 스케줄러에는 그런 것이 전혀 없습니다. 제품 페이지도, 리더보드 (leaderboard)도, 언론 보도 주기 (press cycle)도 없습니다. 그것은 그저 밑에 자리 잡고 앉아 비용, 성능, 그리고 리스크를 실제로 결정하는 결정을 내릴 뿐입니다. 모델 품질만으로 AI 플랫폼을 평가하는 엔터프라이즈 아키텍트 (Enterprise architects)들은 잘못된 레이어를 평가하고 있는 것입니다. 모델은 눈에 보이는 제품입니다. 스케줄러는 실제 아키텍처 (architecture)가 존재하는 레이어입니다.

스케줄링은 새로운 컨트롤 플레인 (Control Plane)이 되고 있다

인프라를 오랫동안 지켜본 사람이라면 익숙한 패턴입니다. 클라우드 전략은 컴퓨팅 (compute)에 관한 논의에서 컨트롤 플레인 (control plane)을 차지하기 위한 싸움으로 변했습니다. 가상화 (virtualization)는 하이퍼바이저 (hypervisor) 기능에 관한 논의에서 운영의 단순성 (operational simplicity)을 위한 싸움으로 변했습니다. 관측성 (observability)은 대시보드 (dashboard)의 문제가 아니라 증거 (evidence)의 문제가 되었습니다. 모든 경우에서, 가치는 모두가 바라보고 있던 레이어(layer) 아래로 이동했습니다.

AI 인프라 역시 동일한 전략을 실행하고 있습니다. 추론 플랫폼 (inference platforms)은 어떤 모델을 실행할지, 어떤 GPU에 할당할지, 그리고 요청이 대기열 (queue)에 쌓일 때 누구에게 우선순위를 부여할지를 결정합니다. 에이전트 프레임워크 (agent frameworks)는 어떤 작업이 다음에 실행될지, 어떤 도구 (tool)가 호출될지, 그리고 무언가 실패했을 때 재시도 (retry) 및 동시성 (concurrency) 동작이 어떻게 이루어질지를 결정합니다. AI 플랫폼은 이 모든 것이 모델에 도달하기 전에 예산 집행 (budget enforcement), 실행 할당량 (execution quotas), 승인 게이트 (approval gates)를 결정합니다. 이 중 그 어떤 것도 모델의 기능 (model capability)이 아닙니다. 이 모든 것이 스케줄링 (scheduling)입니다. "AI 플랫폼"을 소유하기 위해 경주하는 벤더들은, 스스로 입 밖으로 내뱉든 아니든, AI 스케줄러 전쟁 (AI scheduler war)을 치르고 있습니다. 단지 아직 그 이름을 붙이지 않았을 뿐입니다.

AI 스케줄러 전쟁은 모델 상단에 위치한다

여기서 깊이 생각해 볼 만한 역전 현상이 있습니다. 대부분의 사람들은 여전히 모델 → 플랫폼 → 결과의 관점에서 생각하며, 마치 모델이 다른 모든 것의 상류 (upstream)에 있는 것처럼 여깁니다. 하지만 그렇지 않습니다. 스케줄러가 모델의 상류에 있습니다.

업계는 계속해서 모델 전쟁 (model wars)에 대해 이야기합니다. 모델은 무엇을 실행할지, 무엇이 우선순위를 가질지, 무엇이 자원을 받을지, 무엇이 예산 내에 머물지, 또는 어떤 권한이 행사될지를 결정하지 않습니다. 스케줄러가 결정합니다.

단 하나의 토큰 (token)이 생성되기도 전에, 어떤 모델이 어떤 하드웨어에서, 어떤 우선순위로, 어떤 지출 한도 하에, 그리고 어떤 실행 권한을 가지고 실행될지가 이미 결정됩니다. 모델은 결정 체인 (decision chain)의 첫 번째 단계가 아니라 마지막 단계입니다. 스케줄링 레이어를 단순한 구현 세부 사항 (implementation detail)으로 취급하면서 모델 선택을 중심으로 AI 시스템을 설계하는 아키텍트들은, 실제로는 아직 파악하지 못한 결정 표면 (decision surface) 위에 건물을 짓고 있는 것입니다.

The three scheduling layers — resource, task, and authority — stacked by contest maturity

동시에 진행 중인 세 가지 스케줄러 전쟁

AI 스케줄러 전쟁은 단 하나의 싸움이 아닙니다. "스케줄링 (scheduling)"이라는 단어가 너무 많은 역할을 수행하고 있기 때문에, 실제로 무엇이 경합 중인지 분리해서 보는 것이 도움이 됩니다. 현재 세 가지의 뚜렷한 싸움이 병렬적으로 진행되고 있으며, 이들의 성숙도는 서로 다릅니다.

**리소스 스케줄링 (Resource scheduling)**은 대부분의 아키텍트들이 이미 알고 있는 계층입니다. 누가 GPU를 가질 것인지, 어떤 우선순위로 가질 것인지, 어떤 할당량 (quota) 하에 둘 것인지 — 이것은 Kubernetes 스케줄러, Kueue, Volcano, Ray, Slurm, Run:ai, 그리고 벤더별 오케스트레이션 도구들 사이에서 벌어지는 싸움입니다. 이는 실재하며 운영 측면에서 중요하고, 점점 더 구현 방식에 따라 특화되고 있습니다. 바로 이 점 때문에 전략적이라기보다는 전술적인 영역이 되는 것입니다. 이것은 "누가 이기는가"의 결정이 아니라 "어떤 도구를 사용할 것인가"의 결정입니다. 만약 당신이 실제로 평가하려는 것이 바로 이 결정이라면, 이 글이 주장하는 시장 수준의 논쟁보다는 스케줄러 메커니즘 자체부터 시작하십시오.

**태스크 스케줄링 (Task scheduling)**은 한 단계 위 계층입니다. 어떤 태스크가 다음에 실행될 것인지, 어떤 도구가 실행할 것인지, 동시성 제한 (concurrency limits)은 무엇인지, 재시도 (retry) 시에는 어떤 일이 발생하는지 — 이 계층은 에이전트 프레임워크 (agent frameworks)들이 여전히 정의하기 위해 싸우고 있는 영역이며, 진정으로 미결정된 상태입니다. 서로 다른 프레임워크들은 이 문제에 대해 각기 다른 도박을 하고 있으며, 아직 어느 것도 승리하지 못했습니다.

**권한 스케줄링 (Authority scheduling)**은 실제로 중요한 계층이며, 거의 아무도 직접적으로 이름을 붙이지 않고 있는 영역입니다. 이것은 누가 자원을 소비하고, 모델을 호출하며, 작업을 위임하고, 예산을 사용하거나, 실행을 트리거할 수 있는가에 대한 문제입니다. 이는 추상적인 개념이 아니라, 강제되고 취소 가능하며 증거를 생성하는 경계로서의 문제입니다. 대부분의 조직은 자신들이 AI 시스템을 구축하고 있다고 생각합니다. 하지만 점점 더 그들은 누가 계산 권한 (computational authority)을 부여받을지를 결정하는 시스템을 구축하고 있습니다. 이는 "어떤 모델을 사용할 것인가"와는 근본적으로 다른 설계 문제이며, 대부분의 AI 플랫폼 아키텍처는 이 질문에 답할 수 있도록 구축되지 않았습니다.

이것이 바로 Framework #141, Agentic Authority Boundary가 설명하기 위해 만들어진 영역입니다. 즉, 에이전트 시스템 (agentic system)이 실행 권한을 위임할 수 있는 공식적인 경계와, 그 경계가 붕괴되었음을 정의하는 네 가지 실패 상태, 즉 범위 확장 위임 (scope creep delegation), 암묵적 신뢰 상속 (implicit trust inheritance), 취소 불가능한 권한 부여 (non-revocable grants), 그리고 권한 체인의 불투명성 (authority chain opacity)을 다룹니다. 에이전트 기능 (agentic capability)을 출시하기 위해 경쟁하고 있는 모든 AI 플랫폼 벤더들은, 이름을 붙였든 아니든, 이 경계 내부에서 아키텍처 결정을 내리고 있습니다. 대부분은 설계 (by design)에 의한 것이 아니라 기본값 (by default)에 의해 이러한 결정을 내리고 있습니다.

벤더 플랫폼이 스케줄링에 그토록 신경 쓰는 이유

이 중 어느 것도 우연이 아니며, 개발자의 편의성과는 진정한 관련이 없습니다. 스케줄러를 소유하는 자가 비용을 소유합니다. 왜냐하면 스케줄링 결정이 GPU 활용도와 유휴 용량 (idle capacity)을 결정하기 때문입니다. 스케줄러를 소유하는 자가 성능을 소유합니다. 왜냐하면 배치 (placement) 및 우선순위 결정이 부하 상황에서의 지연 시간 (latency)을 결정하기 때문입니다. 스케줄러를 소유하는 자가 거버넌스 (governance)를 소유합니다. 왜냐하면 예산 집행, 승인 게이트 (approval gates), 그리고 실행 할당량 (execution quotas)은 모델의 기능이 아니라 스케줄링 기능이기 때문입니다.

이것은 Framework #115, Control Plane Capture가 직접적으로 명명한 메커니즘입니다: 대안이 비현실적으로 느껴질 때까지 단일 벤더나 플랫폼의 컨트롤 플레인 (control plane)이 운영 권한을 축적하는 현상입니다. 표면적으로는 벤더 중립적으로 보이는 스케줄링 레이어 (scheduling layer)를 구축하는 모든 AI 플랫폼 벤더는, 구조적으로 클라우드 랜딩 존 (cloud landing zones), 서비스 메시 (service mesh), Kubernetes 배포판 (Kubernetes distributions) 등 스택의 다른 모든 레이어에서 나타났던 것과 동일한 통합 패턴 (consolidation pattern)을 구축하고 있는 것입니다. 스케줄러는 단지 이 현상이 일어나고 있는 가장 최신의 장소일 뿐입니다.

하지만 '포획 (capture)'은 메커니즘에 대한 설명일 뿐, 근본적인 질문은 아닙니다. 근본적인 질문은 소유권 (ownership)입니다. 이것이 바로 Framework #135, Control Plane Ownership Boundary입니다: 시스템의 컨트롤 플레인에 대한 권한이 실제로 어디에 존재하는가, 대조적으로 조직은 그것이 어디에 존재한다고 가정하는가에 대한 문제입니다. #115는 통합이 어떻게 일어나는지를 설명합니다. #135는 실제로 무엇이 통합되고 있는지를 설명합니다. 이 둘을 종합하면 AI 스케줄러 전쟁에서 무엇이 걸려 있는지 정확히 설명할 수 있습니다: 그것은 기능 경쟁이 아니라, 실행 결정권 (execution decision rights)을 누가 보유하느냐에 대한 소유권 다툼입니다.

모델 품질, 컨텍스트 윈도우 (context window), 또는 에이전트 프레임워크 (agent framework)의 인체공학적 편의성을 기준으로 AI 플랫폼을 평가하는 아키텍트들은 18개월 뒤면 구식이 될 기준들을 평가하고 있는 것입니다. 여전히 중요할 기준은 다음과 같습니다: 누가 스케줄링 레이어를 소유하는가, 그것이 어떤 권한 모델 (authority model)을 강제하는가, 그리고 당신이 플랫폼을 떠나고 싶을 때 어떤 일이 발생하는가입니다.

Control plane ownership and capture — who holds execution decision rights over AI scheduling

차세대 AI 플랫폼 차별화 요소

현재 모든 AI 벤더(Vendor) 간의 대화는 모델 역량(Model capability)이나 도구 생태계(Tool ecosystem)의 확장성에 집중되어 있습니다. 하지만 이 중 어느 것도 다음 세대의 진정한 차별화 요소가 될 수 없습니다. 더 큰 모델도, 더 많은 도구도 아닙니다. 다음에 무엇을 실행할지, 누구의 권한 하에 실행할지, 어떤 비용으로 실행할지, 그리고 실행이 완료된 후 어떤 증거 추적(Evidence trail)을 남길지에 대한 더 나은 결정이 핵심입니다.

이는 가설적인 변화가 아닙니다. 오픈 인프라(Open infrastructure) 벤더들은 이미 모델 계층(Model layer)이 아닌 이 계층에서 명확하게 포지셔닝하고 있습니다. CNCF 졸업 프로젝트인 Crossplane을 기반으로 구축된 Upbound의 Modelplane은 올해 기존의 서빙 엔진(Serving engines), 스케줄러(Schedulers), 게이트웨이(Gateways)와 경쟁하는 대신, 그 상단에서 작동하는 플릿 규모(Fleet-wide)의 스케줄링 인프라로 출시되었습니다. 이는 지속적인 싸움의 핵심이 추론 품질(Inference quality)이 아니라, 그 상위의 결정 계층(Decision layer)을 누가 소유하느냐에 달려 있다는 것을 정확히 내다본 벤더의 베팅입니다.

기업용 AI의 다음 단계에서 승리할 조직은 최고의 모델 접근 권한을 가진 조직이 아닙니다. 벤더가 대신 정의해주기 전에 자신들의 스케줄링 계층 — 즉 리소스(Resource), 작업(Task), 권한(Authority) — 을 직접 설계한 조직이 승리할 것입니다. 이는 관측성 아키텍트(Observability architects)들이 혹독한 경험을 통해 배운 것과 같은 교훈입니다. 즉, 당신이 구매한 계층과 당신에게 실제로 필요했던 계층은 결코 같지 않았다는 사실입니다.

이것이 가장 먼저 나타나는 곳

만약 귀하의 조직이 AI 거버넌스 평가(AI Governance Assessment) 논의를 진행 중이라면, 이는 대개 모델 리스크가 아니라 아무도 명시적으로 설계하지 않은 실행 계층(Execution layer)에서 시작됩니다. AI 거버넌스 평가 (AI Governance Assessment) — 조직도상에서 권한을 가진 것으로 가정되는 주체와 대비하여, 귀하의 AI 스택 전반에서 실제로 실행 권한을 보유하고 있는 주체가 누구인지를 매핑합니다.

아키텍트의 판결 (Architect's Verdict)

AI 스케줄러 전쟁은 모델 품질, 컨텍스트 윈도우(Context windows), 또는 에이전트 프레임워크(Agent framework)의 사용 편의성을 두고 벌어지는 것이 아닙니다. 이 모든 것의 한 단계 아래 계층, 즉 무엇을, 언제, 어디서, 그리고 누구의 권한 하에 실행할지를 결정하는 주도권을 두고 벌어지는 전쟁입니다.

오늘날 AI 시스템을 구축하는 대부분의 조직은 자신들이 모델에 관한 결정을 내리고 있다고 믿습니다. 하지만 그들은 사실 검토되지 않은 벤더(vendor)의 기본 설정들을 하나씩 수용하며, 기본적으로 스케줄링 (scheduling) 결정을 내리고 있는 것입니다. 그리고 사고가 발생하여 질문을 던질 수밖에 없는 상황이 오기 전까지는 자신들이 어떤 권한을 위임했는지 깨닫지 못할 것입니다. 스케줄러 (scheduler)는 결코 지루한 구현 세부 사항 (implementation detail)이 아니었습니다. 그것은 처음부터 아키텍처 (architecture) 그 자체였습니다.

클라우드 (cloud), 가상화 (virtualization), 관측성 (observability) 등 이전의 모든 컨트롤 플레인 (control-plane) 전쟁은 아무도 주목하지 않던 계층을 점유한 자가 승리했습니다. 이번 전쟁도 다르지 않습니다. 모델 (model)은 결코 컨트롤 플레인이 아니었습니다. 스케줄러 (scheduler)가 바로 컨트롤 플레인입니다.