Slurm이란? GPU 클러스터에 작업 대기열이 필요한 순간

GPU 서버가 네 대 있다고 해보겠습니다. 연구자마다 필요한 GPU 수와 실행 시간이 다릅니다. 한 작업은 GPU 1장으로 끝나지만, 다른 작업은 서버 두 대의 GPU 16장을 동시에 확보해야 합니다. 사용자가 빈 서버를 직접 확인하고 실행 순서를 맞추기 시작하면 서버를 더 사기 전에 운영이 먼저 꼬입니다.

Slurm은 Linux 클러스터의 자원을 작업에 할당하고 실행 순서를 정하는 오픈소스 시스템입니다. 사용자는 필요한 노드, GPU, CPU, 메모리와 실행 시간을 요청합니다. Slurm은 요청을 대기열에 넣고 운영 정책과 자원 상태에 맞춰 실행할 노드를 정합니다.

이 글에서는 Slurm이 어떤 문제를 푸는지, 어떤 환경에 필요한지, Kubernetes와는 언제 나눠 쓰거나 함께 쓸지를 살펴봅니다.

2024년 7월 31일 처음 발행한 글을 2026년 7월 28일 기준으로 전면 개편했습니다.

Slurm은 무엇을 관리하나?

Slurm은 크게 세 가지 일을 합니다.

1. 자원을 할당합니다. 작업에 필요한 노드, GPU, CPU와 메모리를 일정 시간 동안 확보합니다.

2. 작업을 실행합니다. 확보한 노드에서 프로그램을 시작하고 종료 상태를 추적합니다.

3. 충돌을 조정합니다. 여러 사용자가 같은 자원을 원하면 요청을 대기열에 넣고 정책에 따라 순서를 정합니다.

Slurm에서는 제출한 작업 한 건을 job이라고 부릅니다. 사용자는 실행할 스크립트와 함께 필요한 자원을 적어 냅니다.

sbatch --nodes=2 --gpus-per-node=8 --time=04:00:00 train.sh

이 요청은 “노드 2대에서 각각 GPU 8장을 4시간 동안 사용하겠다”는 뜻입니다. sbatch가 빈 서버를 직접 찾는 것은 아닙니다. 요청을 받은 slurmctld가 현재 자원과 정책을 확인해 실행 시점과 노드를 정합니다. 실제 계산 노드에서는 slurmd가 작업을 시작하고 상태를 전달합니다.

Slurm의 주요 구성 요소는 다음과 같습니다.

partition은 물리적으로 완전히 분리된 서버 묶음만 뜻하지 않습니다. 예를 들어 같은 GPU 노드를 짧은 시험 작업용 debug partition과 긴 학습용 train partition에 함께 넣고, 최대 실행 시간과 접근 권한을 다르게 정할 수 있습니다.

작업 대기열은 선착순으로만 움직이지 않는다

공유 클러스터에서는 먼저 제출한 작업만 계속 실행하는 방식이 공정하지 않을 수 있습니다. 한 팀의 큰 작업이 자원을 오래 차지하면 짧은 시험 작업이나 마감이 정해진 작업이 밀릴 수 있기 때문입니다.

Slurm은 운영자가 정한 규칙에 따라 작업의 우선순위를 계산합니다. 대기 시간, 사용자나 조직의 과거 사용량, QoS, 예약, 작업이 요청한 자원의 종류와 양 등을 조합할 수 있습니다. 짧은 작업을 빈 구간에 넣는 backfill scheduling도 지원합니다. 구체적인 정책은 Slurm이 자동으로 정해 주는 값이 아니라 조직이 합의하고 설정해야 할 운영 규칙입니다.

이 점이 단순한 원격 실행 도구와 다릅니다. Slurm을 도입한다는 것은 프로그램을 대신 실행해 주는 명령어를 추가하는 일이 아니라, 누가 어떤 자원을 언제까지 쓸 수 있는지 운영 정책으로 만드는 일에 가깝습니다.

GPU 클러스터에 Slurm이 필요한 신호

다음 상황이 겹치기 시작하면 Slurm을 검토할 이유가 생깁니다.

• 여러 사용자가 같은 GPU 서버를 쓰며 실행 순서를 직접 조율하고 있습니다.

• 분산 학습이나 MPI 작업처럼 여러 노드와 GPU를 한꺼번에 확보해야 합니다.

• 팀별 할당량, 우선순위, 예약과 사용 이력을 관리해야 합니다.

• GPU 종류와 네트워크 연결이 달라 작업마다 적합한 노드를 골라야 합니다.

• 점검 중인 노드를 안전하게 빼고, 실패한 작업과 자원 상태를 운영자가 추적해야 합니다.

반대로 한 명이 서버 한 대를 전용으로 쓰고 작업 수도 적다면 Slurm이 지나치게 클 수 있습니다. 이 경우 셸 스크립트나 컨테이너 실행 환경만으로 충분할 수 있습니다. 상시 실행되는 웹 서비스의 배포, 자동 복구와 트래픽 분산이 중심이라면 Kubernetes가 더 자연스러운 출발점일 수 있습니다.

Slurm과 Kubernetes는 무엇이 다른가?

Slurm과 Kubernetes는 모두 여러 서버의 작업을 다루지만 출발점이 다릅니다. Slurm은 제한된 계산 자원을 여러 사용자와 일괄 작업에 나누는 데 강합니다. Kubernetes는 컨테이너로 만든 애플리케이션이 원하는 상태를 유지하도록 배포하고 복구하는 데 강합니다.

이 표를 “학습은 Slurm, 추론은 Kubernetes”라는 고정 공식으로 읽으면 안 됩니다. Kubernetes에도 Job과 분산 작업을 위한 확장 도구가 있습니다. Slurm도 OCI 컨테이너와 REST API를 지원합니다. 실제 선택은 학습과 추론이라는 이름보다 완료되면 자원을 반환하는 일괄 작업인지, 상시 상태를 유지해야 하는 서비스인지, 대기열과 공정한 자원 배분이 얼마나 중요한지에 달려 있습니다.

둘을 연결하려는 움직임도 있습니다. SchedMD의 Slinky는 Kubernetes 안에서 Slurm을 운영하는 slurm-operator와, Slurm으로 Kubernetes 워크로드까지 배치하는 slurm-bridge를 제공합니다. 다만 연동 기능이 있다는 사실과 운영이 단순하다는 말은 다릅니다. 인증, 네트워크, 스토리지, 장애 범위와 책임 주체를 먼저 정해야 합니다.

Slurm은 오래된 HPC 전용 도구인가?

Slurm은 슈퍼컴퓨터와 HPC에서 시작했지만, GPU 클러스터 운영에 필요한 기능도 계속 확장하고 있습니다. 2026년 7월 28일 기준 공식 문서는 Slurm 26.05를 다루고 있습니다. GPU는 GRES로 요청하고 제한할 수 있으며, OCI 컨테이너 작업과 scrun, REST API도 지원합니다.

그렇다고 설치만 하면 AI 플랫폼이 완성되는 것은 아닙니다. Slurm은 모델, 데이터셋과 실험 이력을 관리하지 않습니다. GPU 온도, 전력과 네트워크 상태를 자세히 보여 주는 통합 모니터링 화면도 별도의 구성이 필요합니다. Slurm의 작업 상태와 사용량 정보에 모니터링, 사용자 포털, 인증과 스토리지를 연결해야 실제 사용자가 쓸 수 있는 환경이 됩니다.

도입 전에 무엇을 정해야 하나?

1. 자원 단위: GPU 전체를 할당할지, MIG처럼 나눈 자원도 제공할지 정합니다.

2. 사용 정책: 팀별 할당량, 우선순위, 최대 실행 시간, 예약과 초과 사용 규칙을 정합니다.

3. 서버와 네트워크: GPU 종류, 노드 안팎의 연결 구조와 분산 작업의 통신 조건을 확인합니다.

4. 스토리지: 여러 노드가 같은 데이터와 결과를 어떤 경로와 성능으로 읽고 쓸지 확인합니다.

5. 계정과 기록: 사용자 인증, 프로젝트별 사용량과 작업 이력을 어디까지 남길지 정합니다.

6. 운영 체계: slurmctld 이중화, 설정 변경, 버전 업그레이드, 장애 대응과 모니터링 책임을 정합니다.

Slurm은 무료 오픈소스이지만 운영까지 공짜라는 뜻은 아닙니다. 라이선스 비용 대신 통합, 검증, 업그레이드와 장애 대응에 시간과 전문성이 필요합니다. 내부 운영팀이 있다면 직접 구성할 수 있고, 빠른 도입과 책임 있는 지원이 중요하다면 구축·운영 지원이나 상용 기술지원을 함께 검토할 수 있습니다.

AI 인프라는 스케줄러만으로 완성되지 않는다

매니코어소프트는 2012년 구축한 이종 슈퍼컴퓨터 천둥을 약 10년간 운영하며 작업 대기열과 자원 할당을 담당하는 관리도구를 직접 개발해 사용했습니다. 이후 국책 연구에서는 Slurm을 기반으로 GPU, Xeon Phi와 FPGA 등 서로 다른 가속기를 관리하는 기술을 개발했습니다.

이 경험을 바탕으로 여러 대학·기업 연구소에 Slurm 기반 GPU 자원 관리 환경을 구축하고 운영을 지원하고 있습니다. 서버, 고속 네트워크와 스토리지부터 Slurm·Kubernetes, 사용자 환경과 모니터링까지 함께 설계합니다. AI 인프라 도입, GPU 클러스터 구축이나 운영을 준비하고 있다면 매니코어소프트에 문의해 주세요.

자주 묻는 질문

GPU 서버 한 대에도 Slurm이 필요한가?

한 명이 서버 한 대를 전용으로 쓰고 작업 수가 적다면 보통은 필요하지 않습니다. 서버가 한 대여도 여러 사용자의 실행 순서, GPU 할당량과 사용 이력을 관리해야 한다면 Slurm을 쓸 이유가 생깁니다.

Slurm과 Kubernetes 중 하나만 선택해야 하나?

아닙니다. 대기열 중심의 일괄 계산과 상시 서비스를 분리해 각각 운영할 수 있습니다. Slinky처럼 두 시스템을 연결하는 방법도 있습니다. 다만 운영 복잡성이 늘 수 있으므로 먼저 역할과 장애 범위를 나누는 것이 중요합니다.

Slurm이 GPU 사용률과 온도까지 보여 주나?

Slurm은 작업 상태와 할당 자원, 설정에 따라 수집한 사용량을 기록할 수 있습니다. GPU 사용률, 온도, 전력, 네트워크와 스토리지 상태를 한 화면에서 지속적으로 관찰하려면 별도의 모니터링 구성이 필요합니다.

Slurm이 필요한 서버를 자동으로 만들어 주나?

Slurm의 역할은 준비된 계산 자원을 작업에 할당하는 것입니다. 동적 노드와 클라우드 연동 기능을 구성할 수 있지만, 서버나 VM을 준비하고 네트워크와 스토리지를 연결하는 과정까지 Slurm 하나가 모두 맡는 것은 아닙니다.

함께 읽을 글

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

주요 참고 자료

• SchedMD, Slurm Workload Manager Overview

• SchedMD, Slurm FAQ

• SchedMD, Generic Resource Scheduling

• SchedMD, Containers Guide

• SchedMD, Slinky: Slurm and Kubernetes

• Kubernetes Documentation, Overview

• Kubernetes Documentation, Jobs