AI 오케스트레이터란? GPU 클러스터 운영의 2026년 흐름
AI 인프라 오케스트레이션은 GPU·NPU 같은 가속기와 워크로드를 운영 정책에 따라 배치하고 실행하는 일입니다. 학습 파이프라인을 이어서 실행하거나 요청량에 맞춰 모델 서빙 규모를 조정하는 기능도 여기에 포함됩니다.
이 과정을 자동화하는 소프트웨어를 AI 오케스트레이터라고 부릅니다.
AI 오케스트레이터를 찾다 보면 GPU 스케줄러, ML 파이프라인 도구와 모델 서빙 플랫폼이 한데 묶여 소개되는 경우가 많습니다. 하지만 이 도구들이 맡는 역할은 서로 다릅니다. 제품을 비교하려면 먼저 어느 과정까지 자동화할지 정해야 합니다.
GPU 클러스터가 커지면 빈 GPU를 찾아 작업을 실행하는 것만으로는 운영하기 어렵습니다. 작업의 우선순위와 GPU 사이의 연결 구조, 장비 상태를 함께 고려해 실행 위치를 정해야 합니다. 모델 서빙에서는 요청량에 맞춰 서버 수를 조정하고, 각 요청을 어느 서버로 보낼지도 결정해야 합니다.
최근 주요 프로젝트는 GPU 종류와 상태, 토폴로지와 워크로드 구조를 배치 조건으로 다루기 시작했습니다. 여러 클러스터에서 자원을 찾거나 LLM 요청을 라우팅하는 기능도 빠르게 늘고 있습니다. 이 글에서는 제품별 설치법보다 AI 오케스트레이션을 바꾸고 있는 다섯 가지 흐름과 선택 기준을 살펴봅니다.
AI 오케스트레이션을 구성하는 네 가지 영역
AI 오케스트레이터가 자동화하는 범위는 크게 네 영역으로 나눌 수 있습니다.
- 인프라 오케스트레이션은 서버와 VM을 준비하고, 컨테이너와 클러스터가 원하는 상태를 유지하도록 관리합니다.
- 자원·워크로드 오케스트레이션은 큐, 쿼터와 우선순위에 따라 워크로드를 언제, 어느 자원에서 실행할지 결정합니다.
- ML 워크플로 오케스트레이션은 데이터 전처리, 학습, 평가와 배포를 정해진 순서와 조건에 따라 실행합니다.
- 추론 오케스트레이션은 모델 서버를 배포하고, 요청을 적절한 서버로 보내며, 트래픽 변화에 맞춰 서버 수를 조정합니다.
예를 들어 ML 파이프라인 도구가 GPU 사이의 연결 구조까지 고려해 실행 위치를 정해 주는 것은 아닙니다. 반대로 GPU 스케줄러는 실행 자원을 할당하지만 모델 파일이나 실험 이력까지 관리하지는 않습니다. 실제 플랫폼은 필요한 영역의 도구를 골라 연결해 만듭니다.
2026년 AI 인프라 오케스트레이션은 어떻게 바뀌고 있나?
큐와 쿼터, fair sharing은 GPU를 여러 팀에 나누는 기본 도구입니다. 분산 작업에는 필요한 자원을 한꺼번에 확보하는 gang scheduling도 널리 쓰입니다. 최근에는 GPU 수뿐 아니라 장치 상태와 연결 구조, 워크로드 전체의 조건까지 배치에 반영하는 방향으로 발전하고 있습니다.
1. GPU는 개수만으로 고를 수 없는 자원이 됐다
과거에는 스케줄러에 GPU 1개처럼 필요한 수량만 적는 경우가 많았습니다. 이제는 작업에 맞는 GPU 종류와 메모리, 분할 방식, 장치 상태와 연결 구조까지 지정해야 합니다.
Kubernetes에서는 이런 요구를 Dynamic Resource Allocation(DRA)으로 표현합니다. Kubernetes v1.34에서 DRA core API가 GA로 올라왔고, v1.36에서는 partitionable devices와 consumable capacity가 beta가 됐습니다.
DRA는 각 벤더의 장치 드라이버를 Kubernetes의 공통 자원 요청 방식과 연결합니다. 사용자는 공통 API로 필요한 조건을 요청하고, 실제 장치 관리는 각 벤더의 드라이버가 담당합니다.
하나의 클러스터에 GPU와 NPU, 세대와 등급이 다른 GPU가 함께 설치되면 GPU 1개라는 요청만으로는 작업에 맞는 장치를 고를 수 없습니다. 같은 제조사의 GPU라도 성능과 메모리 용량, 전력 특성이 다르므로 스케줄러가 서로 다른 자원으로 구분해야 합니다.
GPU를 공유하는 방식에 따라서도 배치 기준이 달라집니다. 전용 GPU, time-slicing, MIG와 소프트웨어 기반 공유는 작업 사이의 격리 수준과 성능 예측 가능성이 서로 다릅니다. 짧은 실험이나 개발 작업은 GPU를 공유해 사용률을 높일 수 있습니다. 일정한 지연시간이나 최대 성능이 필요한 작업에는 전용 GPU가 더 적합할 수 있습니다.
2. 분산 작업은 GPU 수보다 배치 위치가 중요하다
분산 학습은 필요한 GPU 수를 확보하는 것만으로 충분하지 않습니다. GPU가 같은 서버나 랙에 있는지, 고속 네트워크로 연결돼 있는지에 따라 통신시간과 전체 실행시간이 달라집니다.
이를 고려해 서로 가까운 가속기를 묶는 방식을 topology-aware scheduling이라고 합니다. Kueue와 KAI Scheduler는 이런 배치를 지원합니다.
분산 작업에는 학습 프로세스뿐 아니라 데이터 준비, 체크포인트 저장과 제어 작업처럼 역할이 다른 구성 요소가 함께 실행되기도 합니다. JobSet과 Grove는 여러 역할과 의존 관계를 가진 워크로드를 하나의 단위로 표현합니다. JobSet과 Grove는 스케줄러가 분산 작업 전체의 구조를 보고 배치할 수 있게 합니다.
3. 모델 서빙에서는 요청도 스케줄링 대상이 된다
LLM 서빙 용량을 정하려면 모델 서버 수와 GPU 사용률 외에 요청의 특성도 봐야 합니다. 여러 요청이 같은 prompt prefix를 공유하는지, KV cache가 어느 서버에 있는지, 요청 길이가 얼마나 되는지에 따라 처리시간이 달라집니다. Prefill과 decode를 어느 서버에서 처리할지, 모델이 이미 메모리에 올라와 있는지도 지연시간과 처리량에 영향을 줍니다.
llm-d, AIBrix와 NVIDIA Dynamo는 KV cache 위치와 요청 특성을 라우팅에 활용하고, 모델 서버의 배포와 확장도 관리합니다. 클러스터 스케줄러가 모델 서버를 실행할 GPU를 정한다면, 추론 오케스트레이션은 각 요청을 어느 모델 서버로 보낼지 결정합니다.
4. 필요한 GPU가 있는 클러스터를 고른다
원하는 GPU가 한 클러스터에 항상 남아 있지는 않습니다. 현재 클러스터에서 자원을 확보하지 못하면 워크로드를 다른 클러스터로 보내거나 새 노드를 준비해야 합니다.
MultiKueue는 Kubernetes 클러스터 사이에서 작업을 나눠 보냅니다. SkyPilot은 클라우드와 Kubernetes, Slurm 환경에서 조건에 맞는 자원을 찾습니다. Armada는 여러 Kubernetes 클러스터의 작업 대기열을 한곳에서 관리합니다.
실행할 클러스터는 GPU 종류와 수량만으로 정할 수 없습니다. 데이터셋과 모델 가중치의 위치, 전송시간과 비용, 접근 권한, 쿼터와 장애 범위를 함께 확인해야 합니다. 어느 클러스터를 선택하더라도 같은 우선순위와 쿼터, 보안 정책을 적용할 수 있어야 합니다.
5. 측정한 운영 데이터를 다음 배치에 다시 쓴다
기존 스케줄링은 사용자가 제출한 자원 요청과 관리자가 정한 정책을 중심으로 작업을 배치했습니다. 최근에는 워크로드의 구조와 장비 상태, 데이터 위치와 비용처럼 운영 중에 수집한 정보도 다음 판단에 반영합니다.
- Workload-aware는 작업 전체의 구조와 우선순위, 데드라인을 봅니다.
- Topology-aware는 가속기, 서버, 랙과 네트워크의 연결 관계를 봅니다.
- Health-aware는 고장이나 성능 저하가 감지된 장치를 피합니다.
- Data-aware는 데이터와 모델의 위치, 이동시간과 네트워크 비용을 봅니다.
- Energy-aware와 cost-aware는 전력, 냉각과 비용까지 배치 조건에 포함합니다.
이 이름들은 엄격하게 나뉜 표준 용어가 아니며 서로 겹치기도 합니다. 중요한 점은 수집한 정보가 모니터링 화면에 머물지 않고 다음 배치와 확장, 복구 결정에 실제로 쓰이는가입니다. 실행 결과를 다음 결정에 반영해야 운영 환경의 변화에 맞춰 배치와 확장 정책을 조정할 수 있습니다.
Kubernetes Workload API는 여러 Pod의 구조와 스케줄링 조건을 하나의 워크로드로 표현합니다. 아직 alpha 기능이며 기본으로 활성화되지 않습니다. Kueue는 토폴로지를 고려해 워크로드를 가까운 자원에 배치합니다. Kubernetes DRA는 문제가 있는 장치가 새 작업에 할당되지 않도록 표시할 수 있고, SkyPilot은 가격과 가용 용량을 비교해 실행할 자원을 고릅니다.
전력과 냉각까지 자동으로 제어하는 영역은 아직 초기 단계입니다. Kepler는 Kubernetes에서 노드와 워크로드의 전력·에너지 지표를 Prometheus 형식으로 제공합니다. Slurm의 acct_gather_energy 플러그인은 IPMI와 RAPL, AMD GPU의 RSMI에서 에너지 데이터를 수집합니다. 여러 작업이 노드를 공유하면 작업별 값은 실제 사용량을 정확하게 나타내지 않습니다. 두 기능의 주된 역할은 측정과 사용량 집계입니다. 수집한 값을 배치나 전력·냉각 제어에 반영하려면 별도의 제어 로직이 필요합니다.
AI 오케스트레이션은 오픈소스만으로 충분한가?
이 글에서 다룬 AI 오케스트레이션 기능은 오픈소스로도 구성할 수 있습니다. Kubernetes DRA, Kueue, KAI Scheduler, HAMi, KServe와 Kepler를 필요한 범위에 맞춰 조합할 수 있습니다. 요구사항이 명확하고 플랫폼 운영팀이 있다면 특정 제품에 맞추지 않고 원하는 정책을 직접 구현할 수 있습니다.
오픈소스에는 라이선스 비용 대신 통합과 운영에 드는 비용이 있습니다. 구성 요소 사이의 버전 호환성, 업그레이드, 보안 패치, 장애 대응과 사용자 포털을 내부에서 책임져야 합니다.
NVIDIA Run:ai나 Red Hat OpenShift AI 같은 상용제품은 검증된 구성과 관리 화면, 업그레이드 경로와 기술지원을 함께 제공합니다. 운영 인력이 적거나 장애 대응 시간을 줄이는 일이 중요하다면 라이선스 비용보다 이 지원 범위가 더 큰 가치를 가질 수 있습니다.
| 오픈소스 중심 구성이 유리한 환경 | 상용제품이 유리한 환경 | |
|---|---|---|
| 운영 조직 | 내부 플랫폼 운영팀이 있다 | 운영 인력이 적고 빠른 도입이 중요하다 |
| 구성 | 여러 가속기와 환경을 유연하게 연결해야 한다 | 검증된 호환성과 업그레이드 경로가 필요하다 |
| 제어 범위 | 소스 수정과 세밀한 정책 제어가 필요하다 | 통합 UI, 감사 기능과 기술지원 SLA가 중요하다 |
| 비용 판단 | 내부 기술 축적에 투자할 수 있다 | 장애 대응 지연의 비용이 라이선스보다 크다 |
오픈소스와 상용제품을 함께 쓰는 구성도 가능합니다. 오픈소스 스케줄러에 상용 관리 도구를 연결하거나, 기업용 배포판에 필요한 컨트롤러만 직접 개발하는 방식입니다. 제품을 비교할 때는 라이선스 가격뿐 아니라 통합과 검증, 업그레이드와 장애 대응에 드는 총비용을 계산해야 합니다.
AI 오케스트레이터를 고르기 전에 무엇을 정해야 하나?
제품 목록을 만들기 전에 다음 질문부터 정리하면 필요한 오케스트레이션 범위가 보입니다.
- 주된 워크로드는 오래 걸리는 학습 작업인가, 짧은 실험인가, 상시 추론 서비스인가?
- 어떤 가속기가 필요하며 전용·분할·공유 가운데 어떤 방식으로 제공할 것인가?
- GPU 사이의 연결 구조가 성능에 얼마나 큰 영향을 주는가?
- 하나의 클러스터만 운영할 것인가, 온프레미스와 클라우드를 함께 사용할 것인가?
- 팀별 쿼터와 우선순위, 격리와 감사 기능을 어느 수준까지 적용할 것인가?
- 모니터링 결과를 배치와 확장, 장애 복구에 어디까지 반영할 것인가?
- 업그레이드와 장애 대응을 누가 맡으며 어느 수준의 기술지원 SLA가 필요한가?
모든 기능을 처음부터 넣으면 관리할 구성 요소와 장애 지점도 함께 늘어납니다. 현재 가장 큰 병목부터 정하고, 대기시간이나 GPU 사용률처럼 개선 여부를 확인할 기준을 먼저 세우는 편이 좋습니다. 첫 번째 문제가 해결된 뒤 필요한 영역을 순서대로 추가하면 됩니다.
매니코어소프트는 구축에서 오케스트레이션까지 지원합니다
매니코어소프트는 2012년 이종 슈퍼컴퓨터 천둥을 구축해 TOP500 277위와 Green500 32위를 기록했습니다. 천둥에는 작업 대기열과 자원 할당을 담당하는 자체 관리 도구 thor를 개발해 적용했고, 약 10년간 시스템을 운영했습니다.
이후 국책 연구에서는 Slurm을 확장해 NVIDIA·AMD GPU, Xeon Phi와 FPGA 등 서로 다른 가속기를 관리하고 작업에 할당하는 기술을 개발했습니다. 이 경험을 바탕으로 대학과 기업 연구소의 크고 작은 GPU 클러스터를 Slurm이나 Kubernetes 기반으로 구축하고 운영해 왔습니다.
이 과정에서 서버와 가속기를 설치하는 데 그치지 않고, 작업 대기열과 자원 할당, 장비 상태를 함께 관리하는 오케스트레이션 경험을 쌓았습니다. 현재는 GPU·NPU 서버와 냉각 장비, 관제·운영 소프트웨어를 직접 개발하며 장비에서 수집한 전력·온도·냉각 데이터를 자원 배치와 제어에 연결하는 연구를 진행하고 있습니다.
매니코어소프트는 이 경험을 바탕으로 서로 다른 가속기에서 성능 조건을 지키면서 에너지와 총비용을 줄이는 오케스트레이션을 연구하고 있습니다. 지금은 소형 GPU 서버부터 대형 클러스터까지 Slurm이나 Kubernetes 기반으로 구축하고, 워크로드에 맞는 자원 관리 환경도 함께 구성합니다.