Insight

GPU 클러스터 스케줄링의 진화: 워크로드에 맞는 운영 설계가 성능을 만든다

AI 인프라의 경쟁력은 GPU의 개수만으로 결정되지 않습니다. 같은 GPU를 보유하고 있어도 어떤 작업을 언제 실행하고, 어떤 장비에 배치하며, 사용하지 않는 자원을 어떻게 회수하는지에 따라 실제 처리량과 연구 생산성은 크게 달라질 수 있습니다.
특히 AI 워크로드는 하나의 유형으로 정의하기 어렵습니다. 수백 개의 GPU가 동시에 협력해야 하는 대규모 분산 학습, 반복적인 파인튜닝과 데이터 전처리, 요청량에 따라 자원을 조정해야 하는 실시간 추론은 서로 다른 실행 조건을 요구합니다.
따라서 차세대 GPU 플랫폼은 특정 스케줄러를 모든 작업에 일괄 적용하기보다, 워크로드의 특성을 먼저 파악하고 그에 맞는 배치·격리·확장·복구 정책을 조합해야 합니다. 핵심은 기술의 이름이 아니라, 작업의 특성과 운영 목표를 연결하는 설계입니다.
 

대규모 분산 학습에 적합한 Slurm 기반 운영
대규모 모델 학습은 여러 노드의 GPU가 하나의 작업처럼 움직이는 대표적인 배치 워크로드입니다. 일부 노드만 먼저 실행되거나 GPU 간 통신 경로가 비효율적으로 구성되면, 전체 작업의 처리 시간이 늘어날 수 있습니다. 따라서 작업에 필요한 자원을 한 번에 확보하고, 관련 GPU를 가능한 한 효율적인 위치에 배치하는 전략이 중요합니다.

이러한 환경에서는 Gang Scheduling이 중요한 역할을 합니다. Gang Scheduling은 작업을 구성하는 여러 자원을 함께 스케줄링하는 방식으로, 분산 학습 작업이 필요한 자원을 동시에 확보하도록 돕습니다.
Slurm은 HPC 환경에서 널리 활용되는 워크로드 매니저로, 이러한 작업 단위 실행과 배치 스케줄링을 지원합니다. 파티션, 우선순위, 공정성 정책 등을 조합해 대규모 분산 학습을 효율적으로 운영할 수 있으며, 높은 동시성과 예측 가능한 자원 배치가 필요한 환경에서 강점을 보입니다.

반복 학습과 데이터 전처리: 빠른 회전율과 자원 공유가 중요한 작업
전처리, 특성 추출, 평가, 파인튜닝과 같은 작업은 대규모 사전학습보다 짧고 빈번하게 실행되는 경우가 많습니다. 작업마다 필요한 GPU 수와 실행 시간이 달라질 수 있기 때문에, 고정된 자원 점유보다 빠른 할당과 회수가 중요합니다.
이 단계에서는 컨테이너 기반 환경, 작업 단위의 격리, 자동 재시도, 자원 요청량에 따른 배치가 생산성에 직접적인 영향을 줍니다. 연구자가 환경 설정과 자원 신청을 반복하지 않고 표준화된 템플릿으로 실험을 시작할 수 있다면 GPU 자체의 성능뿐 아니라 실험 회전율도 높아집니다.

실시간 추론: 지속적인 가용성과 지연시간을 관리해야 하는 서비스
추론은 학습과 달리 특정 시점에만 대규모 자원이 필요한 작업이 아닙니다. 서비스가 운영되는 동안 일정한 응답시간과 가용성을 유지해야 하며, 요청량이 증가하면 서비스 인스턴스를 확장하고 감소하면 자원을 축소해야 합니다.
Kubernetes의 Deployment와 같은 서비스 관리 방식은 컨테이너 기반 애플리케이션을 지속적으로 유지하고, 장애가 발생한 인스턴스를 복구하며, 서비스 단위 확장을 구성하는 데 적합합니다. GPU를 여러 서비스가 공유하는 경우에는 자원 격리와 QoS 정책을 함께 설계해야 합니다.
 

토폴로지 인식 배치: 가까운 GPU를 함께 묶는 이유
대규모 GPU 작업에서는 단순히 빈 GPU를 찾는 것만으로 충분하지 않습니다. GPU가 어느 노드에 있고, 노드 간 연결이 어떻게 구성되어 있으며, 네트워크와 스토리지 경로가 어떤 특성을 갖는지까지 고려해야 합니다.
토폴로지 인식 배치는 작업의 통신 특성과 장비의 물리적 위치를 고려해 자원을 배치하는 방식입니다. 통신량이 많은 작업을 서로 가까운 자원에 배치하면 데이터 이동 경로를 줄이고, 네트워크 병목 가능성을 낮출 수 있습니다.
Slurm은 토폴로지 인식 자원 할당을 구성할 수 있으며, Kubernetes 역시 토폴로지 분산 제약을 통해 포드가 노드·가용 영역 등 특정 장애 도메인에 어떻게 배치될지 제어할 수 있습니다.

큐와 공정성: 먼저 요청한 작업만으로는 부족하다
GPU 클러스터에서 단순한 FIFO 큐만 사용하면 중요한 작업이 장시간 대기하거나, 특정 팀이 자원을 과도하게 점유하는 문제가 발생할 수 있습니다. 반대로 우선순위만 지나치게 강조하면 일반 작업이 계속 밀려 조직 전체의 실험 기회가 줄어들 수 있습니다.
효율적인 스케줄링은 프로젝트 중요도, 예상 실행 시간, 사용 이력, 긴급성, 팀별 자원 한도 등을 함께 고려해야 합니다. 이러한 정책은 고정된 규칙이 아니라 조직의 연구 목표와 GPU 운영 상황에 맞게 조정될 수 있어야 합니다.
공정성은 모든 작업을 똑같이 대기시키는 것이 아니라, 투명한 기준으로 자원을 배분하고 예측 가능한 사용 경험을 제공하는 데서 출발합니다.

유휴 자원 관리: 할당과 사용을 구분하라
GPU가 특정 작업에 할당되어 있다는 사실이 실제로 GPU가 사용되고 있다는 뜻은 아닙니다. 연구자가 데이터를 준비하거나 코드를 수정하는 동안 GPU가 유휴 상태로 남을 수 있고, 작업이 오류로 멈췄는데도 자원이 반환되지 않을 수 있습니다.
따라서 GPU 플랫폼은 사용률을 모니터링하고, 사전에 정의된 정책에 따라 유휴 자원을 회수할 수 있어야 합니다.
사용 중인 작업을 보호하면서도 대기 중인 작업에 자원을 재배치하는 유휴 자원 회수는 GPU 활용률과 연구자의 대기시간을 함께 개선하는 운영 장치가 될 수 있습니다.
 

학습 계층: 성능과 작업 단위 실행을 우선한다
대규모 분산 학습은 GPU 간 통신과 작업 동시성이 핵심이므로, HPC에 적합한 배치 스케줄링과 고속 인터커넥트 환경을 중심으로 설계하는 것이 유리합니다.
컨테이너를 활용하더라도 실행 계층에서 불필요한 오버헤드를 줄이고, 작업에 필요한 GPU와 네트워크 자원을 예측 가능하게 확보해야 합니다. 특히 대규모 학습에서는 개별 GPU의 평균 사용률뿐 아니라 전체 작업의 완료 시간과 통신 효율을 함께 봐야 합니다.

서비스 계층: 확장성과 복구를 우선한다
모델 서빙과 추론은 서비스의 상태를 지속적으로 관리하고, 트래픽에 따라 인스턴스를 조정하며, 장애 시 자동 복구하는 능력이 중요합니다.
서비스 계층에서는 Deployment, Service, 자동 확장, 관측성 도구와 같은 클라우드 네이티브 운영 요소가 자연스럽게 결합됩니다. 학습 작업에 적합한 배치 실행 방식을 그대로 서빙 환경에 적용하기보다, 서비스의 가용성과 응답시간을 중심으로 별도의 운영 정책을 마련해야 합니다.

통합 계층: 사용자는 단순하게, 운영자는 일관되게
실행 계층을 역할별로 나누더라도 연구자와 개발자가 여러 도구를 각각 배워야 한다면 플랫폼의 복잡성은 줄어들지 않습니다.
포털은 프로젝트와 워크스페이스를 기준으로 권한과 자원을 관리하고, 작업 생성부터 환경 연결, 실행 상태 확인, 결과 확인까지 일관된 경험을 제공해야 합니다.
운영자는 하나의 화면에서 GPU 사용률, 작업 대기열, 자원 회수 상태, 장애와 재시도 현황을 확인할 수 있어야 합니다. 이처럼 서로 다른 실행 기술을 사용자 경험과 정책 레이어에서 통합하는 것이 플랫폼의 중요한 역할입니다.
 

하나의 플랫폼으로 통합
NovaTier는 Slurm과 Docker 기반의 개발 컨테이너와 Kubernetes 기반의 서비스 컨테이너를 통합, 모델 학습(Train)부터 배포·서빙(Serving)까지 하나의 플랫폼에서 가능하게 합니다. 학습 계층에는 HPC 방식의 작업 단위 실행을, 서비스 계층에는 클라우드 네이티브 방식의 확장과 복구를 각각 배정하는 구조로, 앞서 살펴본 '역할별 실행 계층 설계'를 구현한 것입니다.

계층 구조와 정책으로 관리하는 자원 운영
NovaTier는 클러스터–테넌트–프로젝트로 이어지는 리소스 계층 구조를 통해 조직별 자원을 논리적으로 분리하고, 역할 기반 접근 제어(RBAC)로 접근 권한을 관리합니다. 하나의 시스템을 여러 테넌트가 공동으로 사용하더라도 회사 단위로 자원과 데이터가 격리되며, 여러 클러스터 환경을 하나의 통합 관리 서버에서 중앙 관리해 운영 안정성과 확장성을 확보합니다.

자원 운영 정책 측면에서는 CPU/GPU 자원 제한과 디스크 쿼터(quota)를 조직 정책에 맞게 적용할 수 있으며, 유휴 GPU 자원 회수 기능을 통해 사용되지 않는 GPU를 회수하고 대기 중인 작업에 재배치합니다. 이는 물리적인 GPU 수량을 늘리지 않고도 자원 회전율을 높이는 방법으로, GPU 운영을 스케줄러의 기본 기능에만 맡기지 않고 조직의 정책과 연결해야 한다는 방향성을 보여줍니다.

연구자에게는 익숙한 환경을, 운영자에게는 하나의 관리 체계를
기업과 연구기관의 GPU 환경은 하나의 형태로 고정되지 않습니다. 온프레미스 베어메탈, 가상화 환경, 퍼블릭 클라우드, 서로 다른 GPU 세대가 함께 사용될 수 있습니다.
이 때 중요한 것은 특정 환경에 종속된 단일 실행 방식이 아니라, 자원의 위치와 성능 특성을 파악하고 워크로드를 적합한 곳에 배치하는 운영 역량입니다.
NovaTier는 Slurm, Kubernetes, Docker 기반 환경을 하나의 관리 경험으로 연결해 학습·전처리·서빙의 흐름을 통합하는 방향을 제시합니다.
연구자는 웹 터미널, JupyterLab, VS Code 등 익숙한 개발 환경을 활용하고, 운영자는 자원 정책과 사용 현황을 통합적으로 관리할 수 있습니다.
 

워크로드 분류
대규모 분산 학습, 반복 실험, 전처리, 추론, 서빙을 같은 기준으로 배치하고 있지 않은지 확인해야 합니다.
각 작업에 필요한 GPU 수, 실행 시간, 통신량, 응답시간, 장애 허용 수준을 구분해야 적절한 스케줄링 정책을 설계할 수 있습니다.
통신과 토폴로지
GPU의 수량뿐 아니라 GPU 간 연결, 노드 위치, 네트워크 경로와 스토리지 처리량을 함께 고려해야 합니다.
특히 분산 학습에서는 자원 배치가 작업 완료 시간에 영향을 줄 수 있으므로, 작업의 통신 패턴과 하드웨어 토폴로지를 함께 분석해야 합니다.
자원 정책
팀·프로젝트별 한도, 우선순위, 공정성, 유휴 자원 회수, 예외 작업 기준이 명확해야 합니다.
정책이 명확하지 않으면 자원이 충분한데도 작업이 대기하거나, 특정 프로젝트에 자원이 편중되는 문제가 발생할 수 있습니다.
운영 자동화
작업 실패, 자원 부족, 사용률 저하, 환경 구성 오류를 운영자가 수동으로 처리하고 있지 않은지 점검해야 합니다.
작업 상태 감지, 자동 재시작, 재대기열, 자원 회수, 알림과 같은 기능이 운영 절차에 포함되어야 합니다.
사용자 경험
연구자가 인프라 구성 요소를 개별적으로 학습하지 않고, 하나의 포털에서 환경·작업·결과를 연결할 수 있어야 합니다.
플랫폼의 목적은 기술을 감추는 것이 아니라, 연구자가 필요한 기술을 적절한 방식으로 사용할 수 있도록 복잡한 운영 과정을 단순화하는 데 있습니다.
 

AI 인프라의 성능은 가장 비싼 GPU를 확보하는 것만으로 완성되지 않습니다.
대규모 학습에는 함께 시작하고 효율적으로 통신하는 자원 배치가 필요하고, 반복 실험에는 빠른 회전율과 유휴 자원 회수가 필요하며, 추론에는 지속적인 가용성과 지연시간 관리가 필요합니다.
이처럼 서로 다른 요구사항을 하나의 기준으로 처리하기보다 워크로드별 실행 계층을 설계하고, 그 위에 공통 정책·가시성·자동화·사용자 경험을 통합하는 것이 차세대 GPU 플랫폼의 방향입니다.

NovaTier는 HPC의 고성능 작업 실행 특성과 클라우드 네이티브 환경의 유연성을 역할별로 결합하고, 동적 자원 회수와 정책 기반 스케줄링으로 조직 전체의 GPU 활용을 최적화합니다.
이제 AI 인프라의 경쟁력은 GPU를 얼마나 많이 보유했는지가 아니라, 보유한 자원을 얼마나 지능적으로 배치하고 회수하며 연결하는지에 달려 있습니다.
연구 생산성과 인프라 효율을 동시에 높이고 싶다면, 먼저 우리 조직의 워크로드를 분류하고 그에 맞는 실행·정책·운영 계층을 설계해야 합니다.
GPU 플랫폼의 미래는 단일 기술의 승부가 아니라, 서로 다른 기술을 목적에 맞게 조율하는 운영 설계에서 시작됩니다.