AI 오케스트레이터란? GPU 클러스터 운영의 2026년 흐름

AI 인프라 오케스트레이션은 GPU와 NPU 같은 가속기, 워크로드, ML 파이프라인과 모델 서빙을 운영 정책에 맞춰 배치·실행·확장하는 기술과 도구를 통틀어 부르는 말입니다. AI 오케스트레이터는 이를 구현하는 하나 이상의 소프트웨어 구성 요소입니다.

AI 오케스트레이터를 검색하면 GPU 스케줄러, ML 파이프라인과 모델 서빙 플랫폼이 한 목록에 섞여 나옵니다. 이들은 자동화하는 결정이 다릅니다. 제품을 비교하기 전에 필요한 자동화 범위부터 구분해야 합니다.

GPU 클러스터가 커지면 빈 GPU를 찾는 것만으로는 부족합니다. 여러 팀의 우선순위를 조정하고, 서로 가까운 GPU를 묶고, 장애가 난 장비를 피해야 합니다. Inference 요청이 늘면 서비스 규모도 조정해야 합니다. 오케스트레이터가 다뤄야 할 정보와 판단 범위가 계속 넓어지고 있습니다.

2026년 7월 28일 기준 AI 오케스트레이터는 GPU를 개수가 아닌 조건이 있는 자원으로 다루고 토폴로지와 워크로드 구조를 반영합니다. Inference 요청과 여러 클러스터까지 판단 범위도 넓어졌습니다. 이 글에서는 개별 제품의 설치법보다 이 다섯 가지 흐름과 선택 기준을 살펴봅니다.

AI 오케스트레이터란 무엇인가?

AI 오케스트레이션은 크게 네 영역으로 나눠 볼 수 있습니다.

• 인프라 오케스트레이션은 서버, VM, 컨테이너와 클러스터를 구성하고 유지합니다.

• 자원·워크로드 오케스트레이션은 큐, 쿼터와 우선순위를 적용하고 워크로드를 실제 자원에 배치합니다.

• ML 워크플로 오케스트레이션은 전처리, 학습, 평가와 배포 단계를 순서대로 실행합니다.

• Inference 오케스트레이션은 모델 서버를 배포하고 요청을 라우팅하며 트래픽에 맞춰 확장합니다.

예를 들어 ML 파이프라인 도구가 GPU 토폴로지까지 알아서 최적화해 주는 것은 아닙니다. 반대로 GPU 스케줄러는 모델 파일과 실험 이력을 관리하지 않습니다. 하나의 거대한 제품을 찾기보다 필요한 영역을 연결해 플랫폼을 만드는 접근이 일반적입니다.

2026년 AI 인프라 오케스트레이션은 어떻게 바뀌고 있나?

큐와 쿼터, fair sharing과 gang scheduling은 중요한 기본 기능으로 자리 잡았습니다. 최근에는 오케스트레이션이 다루는 정보와 범위가 더 넓어지고 있습니다.

1. GPU가 개수에서 조건이 있는 자원으로 바뀐다

과거에는 GPU 1개처럼 개수만 요청하는 방식이 일반적이었습니다. 이제는 GPU 종류, 메모리, 분할 방식, 상태와 연결 조건까지 표현하려는 방향으로 바뀌고 있습니다.

Kubernetes Dynamic Resource Allocation은 v1.34에서 stable이 되었고, v1.36에서는 partitionable devices와 consumable capacity가 beta로 올라왔습니다. 특정 벤더의 관리 방식을 없애는 기능은 아닙니다. 서로 다른 가속기를 공통 API로 요청할 기반을 제공합니다.

이종 가속기는 GPU와 NPU의 조합만 뜻하지 않습니다. 같은 제조사의 세대나 등급이 다른 GPU도 성능, 메모리와 전력 특성이 다르므로 서로 다른 조건을 가진 자원으로 다뤄야 합니다.

GPU 공유 방식도 하나로 정리되지 않습니다. 전용 GPU, time-slicing, MIG와 소프트웨어 기반 공유는 격리 수준과 성능 예측 가능성이 다릅니다. 작은 개발 워크로드에는 공유가 유리하지만 일정한 지연시간이나 최대 성능이 중요하다면 전용 GPU가 더 나을 수 있습니다.

2. GPU 수보다 토폴로지와 워크로드 구조가 중요해진다

분산 워크로드는 필요한 GPU 수만 확보한다고 빠르게 실행되지 않습니다. 같은 노드에 있는지, 같은 랙이나 고속 네트워크 안에 있는지에 따라 통신시간이 달라집니다.

Kueue와 KAI Scheduler는 토폴로지를 반영한 배치를 지원합니다. JobSet과 Grove처럼 여러 역할과 의존 관계를 가진 워크로드를 하나의 단위로 표현하는 API도 늘고 있습니다.

스케줄러의 판단 단위가 개별 프로세스나 컨테이너에서 서로 연결된 워크로드 전체로 커지는 흐름입니다.

3. Inference 요청을 함께 최적화한다

LLM inference는 replica 수와 GPU 사용률만으로 운영하기 어렵습니다. prompt prefix, KV cache 위치, 요청 길이, prefill과 decode의 역할, 모델을 불러오는 시간이 지연시간과 처리량에 영향을 줍니다.

llm-d, AIBrix와 NVIDIA Dynamo 같은 프로젝트가 요청 라우팅, 캐시, 워크로드 배치와 자동 확장을 함께 다루는 이유입니다. Inference engine과 클러스터 스케줄러 사이의 간격이 좁아지고 있습니다.

4. 여러 클러스터에서 필요한 자원을 확보한다

현재 클러스터에 원하는 GPU가 없으면 다른 클러스터로 워크로드를 보내거나 새 노드를 준비해야 합니다. MultiKueue, SkyPilot과 Armada는 서로 다른 방식으로 여러 클러스터의 자원을 활용합니다.

이때 계산 자원만 보면 안 됩니다. 데이터셋과 모델 가중치의 위치, 네트워크 비용, 접근 권한, 쿼터와 장애 범위도 함께 살펴야 합니다. 여러 클러스터를 운영하는 일은 클러스터 수를 늘리는 기능이 아니라 운영 정책을 여러 환경에서 일관되게 유지하는 문제에 가깝습니다.

5. 운영 데이터를 배치와 제어에 반영한다

오케스트레이터의 성격은 어떤 조건을 실제 배치와 제어에 반영하느냐에 따라 달라집니다.

• Workload-aware는 작업 전체의 구조, 우선순위와 데드라인을 봅니다.

• Topology-aware는 가속기, 서버, 랙과 네트워크의 연결 관계를 봅니다.

• Health-aware는 고장이나 성능 저하가 감지된 장치를 피합니다.

• Data-aware는 데이터와 모델이 있는 위치, 이동시간과 네트워크 비용을 봅니다.

• Energy-aware와 cost-aware는 전력, 냉각과 비용까지 판단 범위를 넓힙니다.

이 이름들은 엄격하게 구분된 표준 용어가 아니며 서로 겹치기도 합니다. 중요한 것은 이름보다 수집한 정보가 실제 운영 판단으로 돌아가는 closed loop입니다.

워크로드와 토폴로지는 Kubernetes의 Workload API와 Kueue에서 구체적인 API와 기능으로 구현되고 있습니다. 장치 상태를 전달하고 문제가 있는 가속기를 피하는 기능도 Kubernetes DRA에 들어왔습니다. SkyPilot처럼 가격과 가용 용량을 함께 비교하는 도구도 있습니다.

전력과 냉각을 오케스트레이션 판단에 반영하는 영역은 아직 초기 단계입니다. Kepler는 Kubernetes에서 노드와 워크로드의 전력·에너지 지표를 Prometheus 형식으로 제공합니다. Slurm의 acct_gather_energy 플러그인은 IPMI, RAPL과 일부 GPU 관리 라이브러리에서 노드 단위 에너지 데이터를 수집합니다. 두 기능 모두 관측과 사용량 집계에 가깝고, 수집 결과를 배치나 냉각 설비 제어에 자동으로 반영하는 오케스트레이터는 아닙니다.

AI 오케스트레이션은 오픈소스만으로 충분한가?

꼭 상용제품을 사야 하는 것은 아닙니다. DRA, Kueue, KAI Scheduler, HAMi, KServe와 Kepler처럼 핵심 구성 요소는 오픈소스로 공개되어 있습니다. 요구사항이 명확하고 이를 통합·운영할 팀이 있다면 필요한 기능을 선택해 유연하게 구성할 수 있습니다.

다만 오픈소스가 곧 운영비가 없다는 뜻은 아닙니다. 버전 호환성, 업그레이드, 보안 패치, 장애 대응과 사용자 포털은 누군가 책임져야 합니다. NVIDIA Run:ai나 Red Hat OpenShift AI 같은 상용제품을 쓰면 통합, 업그레이드와 기술지원을 한 업체에 맡길 수 있습니다.

두 방식을 섞을 수도 있습니다. 오픈소스 스케줄러에 내부 포털을 붙이거나, 기업용 배포판에 필요한 컨트롤러만 직접 개발할 수 있습니다. 라이선스 비용만 보지 말고 통합·검증·운영에 드는 시간도 계산해야 합니다.

AI 오케스트레이터를 고르기 전에 무엇을 정해야 하나?

다음 질문에 답하면 필요한 영역과 제품 범위가 좁아집니다.

1. 주된 워크로드는 오래 걸리는 학습 작업인가, 짧은 실험인가, 상시 inference 서비스인가?

2. 어떤 종류의 가속기가 필요하며 전용·분할·공유 중 어느 방식이 맞는가?

3. 네트워크 토폴로지가 성능에 얼마나 큰 영향을 주는가?

4. 하나의 클러스터만 운영할 것인가, 온프레미스와 클라우드를 함께 쓸 것인가?

5. 어느 수준의 격리, 감사 기능과 기술지원 SLA가 필요한가?

6. 모니터링 결과를 배치, 확장과 복구에 어디까지 반영할 것인가?

모든 기능을 한 번에 넣으면 관리할 구성 요소와 장애 지점도 함께 늘어납니다. 현재 병목을 먼저 해결하고, 측정 가능한 운영 기준을 만든 뒤 범위를 넓히는 편이 안전합니다.

매니코어소프트가 준비하는 다음 단계

매니코어소프트는 GPU가 HPC에서 낯설던 시절 SnuCL과 액체냉각 슈퍼컴퓨터 천둥을 만들었습니다. 천둥은 소비자용 GPU로 TOP500 277위와 Green500 32위에 올랐습니다.

현재는 콜드플레이트, GPU·NPU 서버와 CDU를 직접 만들고, Gadgetini로 서버와 CDU 및 연결 장치를 관제·제어합니다. Redfish, BACnet, Modbus와 OPC UA 같은 표준을 이용하면 HVAC, 시설수와 데이터센터 관제 시스템도 연결할 수 있습니다. 매니코어소프트의 역할은 하드웨어에서 끝나지 않습니다. 상용 소프트웨어와 오픈소스를 활용해 사용자가 실제 업무에 쓸 수 있는 AI 인프라 전체를 구축하고, 도입 이후 운영까지 지원합니다.

이 기반을 오케스트레이션과 자율 운영 인프라로 확장하는 저희 연구는 후속 글에서 하나하나 소개하겠습니다. AI 인프라 구축과 운영, 공동 연구나 기술 협업을 논의하고 싶다면 매니코어소프트와 상의해 주세요.

함께 읽을 글

• AI 서빙이란? vLLM vs SGLang, LLM 엔진 선택 기준

• Slurm 작업 스케줄러의 주요 기능과 구조

주요 참고 자료

• Kubernetes v1.34: DRA has graduated to GA

• Kubernetes Dynamic Resource Allocation

• Kueue Topology-Aware Scheduling

• llm-d Architecture

• MultiKueue

• Kepler Metrics