NVIDIA가 바운서를 인수했다: SchedMD와 Lock‑In이 실제로 존재하는 곳

발행: 4시간 전 (2025년 12월 29일 오전 09:37 GMT+9)

24 min read

Source: Dev.to

번역하려는 전체 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.

NVIDIA’s Acquisition of SchedMD

2025년 12월 15일, NVIDIA가 SchedMD를 인수했습니다. 인수 금액은 공개되지 않았으며, 보도 자료에서는 오픈 소스에 대한 약속을 강조했고 대부분의 보도는 NVIDIA의 소프트웨어 포트폴리오 확장에 초점을 맞추어 이 사건의 의미를 완전히 놓쳤습니다. 대부분의 사람들은 이 인수가 얼마나 큰 의미를 갖는지 놓쳤습니다.

SchedMD는 **Slurm**을 유지 관리합니다. Slurm은 **TOP500 슈퍼컴퓨터의 65 %**에서 사용되는 워크로드 매니저이며, 상위 10대와 상위 100대 중 절반 이상에서 운영됩니다. 연구자가 학습 작업을 제출할 때마다, 머신러닝 엔지니어가 배치 추론을 큐에 넣을 때마다, 국가 연구소가 시뮬레이션을 위해 컴퓨팅 자원을 할당할 때마다, Slurm이 실제로 어떤 GPU가 작업을 실행할지 결정할 가능성이 높습니다.

모두가 CUDA 방어벽을 주시하고 있습니다. Judah Taub의 최근 Substack 글은 이를 완벽하게 설명합니다: 프로그래밍 모델이 락인(lock‑in)의 원천이며, OpenAI의 Triton, Google의 TPU, AMD의 ROCm, Modular의 Mojo, Tenstorrent의 RISC‑V 접근 방식 등 다섯 가지 잠재적 탈출 경로가 존재합니다. 이 모든 것이 유효한 경쟁 위협입니다.

하지만 NVIDIA는 그들의 공로를 인정받아야 할 만큼, 프로그래밍 모델 논쟁을 꿰뚫어 보고 규모 확장의 핵심 방법 중 하나를 찾아냈습니다. 그들은 문지기를 사들인 것입니다.

Slurm이 실제로 하는 일

만약 HPC 클러스터에 작업을 제출해 본 적이 없다면, Slurm은 눈에 보이지 않는 인프라이며, 이는 의도된 설계입니다. 연구자들은

sbatch my_training_job.sh

와 같이 입력하고, 그들의 코드는 GPU에서 실행됩니다. 하지만 GPU가 어떻게 할당되는지, 작업이 실제로 언제 시작되는지, 어떤 노드가 분산 학습의 어느 부분을 담당하는지, 경쟁 작업들의 우선순위가 어떻게 정해지는지, 실험이 오늘 밤에 실행될지 다음 주 화요일에 실행될지는 모두 Slurm이 담당합니다.

공식 설명은 거의 너무 기본적인 수준처럼 들립니다:

“자원을 독점적·비독점적으로 할당하고, 작업을 시작·실행·모니터링하기 위한 프레임워크를 제공하며, 대기 중인 작업 큐를 관리함으로써 자원 경쟁을 중재한다.”

실제로 Slurm은 조직 정책을 컴퓨팅 할당으로 변환하는 계층입니다. 여기에는 다음과 같은 내용이 포함됩니다:

연구 그룹 간 공정‑공유 스케줄링
마감 기한이 민감한 프로젝트를 위한 우선순위 우선 적용
클러스터를 한 사용자가 독점하지 못하도록 하는 자원 제한
처리량을 균형 있게 유지하는 선점 정책
네트워크 토폴로지를 최적화하는 Hilbert‑curve scheduling 에 대한 대응

…그리고 훨씬 더 많은 기능이 있습니다. 혹은 SSH 없이 바로 작업을 시작할 수도 있습니다!

Slurm을 운영하는 모든 조직은 수년간의 튜닝을 통해 구성 파일에 자체적인 자원 관리 철학을 녹여 넣었으며, 파티션 정의와 서비스 품질 정책, 보조금 및 예산과 연계된 회계 시스템, 그리고 Slurm 명령어를 중심으로 한 사용자 교육까지 모두 체계화되어 있습니다. 이것은 주말에 교체할 수 있는 간단한 프로그램이 아닙니다.

왜 Slurm이 승리했는가

Slurm은 명백한 선택이 아니었습니다. 2001년 Lawrence Livermore National Laboratory에서 개발이 시작될 때(https://slurm.schedmd.com/slurm_ug_2010/01-keynote.pdf?ref=distributedthoughts.org), HPC 세계는 프로프라이어터리 스케줄러에 의존하고 있었습니다:

PBS(Portable Batch System)는 다양한 변형이 곳곳에 존재했으며
IBM의 LoadLeveler가 그들의 생태계를 장악하고 있었고
Quadrics RMS는 특수 클러스터를 담당했으며
Platform Computing의 LSF(Load Sharing Facility)는 엔터프라이즈 HPC를 제공했습니다

LLNL은 프로프라이어터리 슈퍼컴퓨터에서 일반 Linux 클러스터로 전환하면서, 수만 대의 노드까지 확장 가능하고 다양한 아키텍처에 고도로 이식 가능하며 오픈 소스인 리소스 관리자가 필요했습니다. 2002년 첫 번째 릴리스(https://www.schedmd.com/about-schedmd/slurm-history/?ref=distributedthoughts.org)는 의도적으로 단순하게 설계되었으며, 이름은 원래 **“Simple Linux Utility for Resource Management”**를 의미했습니다(나중에 약어는 사라졌지만 Futurama에 대한 언급은 남아 있었습니다).

다음에 일어난 일은 오픈 소스가 인프라 시장에서 어떻게 승리하는지 보여주는 사례 연구입니다.

PBS는 OpenPBS, Torque, 그리고 PBS Pro(현재 Altair)로 분열되어 커뮤니티가 분산되었습니다.
LSF는 IBM이 2012년에 Platform Computing을 인수하면서 상업화되었고, 라이선스 비용이 규모가 커질수록 장벽이 되었습니다.
Grid Engine은 Sun, Oracle, Univa 사이를 오가며 소유권이 바뀌었고, 그 결과 커뮤니티 신뢰가 약화되었습니다.

Slurm은 하나의 코드베이스와 GPLv2 라이선스를 고수했으며, 이를 폐쇄할 수 없고 플러그인 아키텍처를 통해 조직이 포크 없이도 맞춤화할 수 있게 했습니다. 2010년, Morris Jette와 Danny Auble이 LLNL을 떠나 SchedMD(https://en.wikipedia.org/wiki/SchedMD)를 설립하고, 소프트웨어는 무료로 유지하면서 지속적인 개발을 지원하는 상용 지원 모델을 만들었습니다—HPC 스케줄링에 적용된 Red Hat 방식이었습니다.

2023년 Hyperion Research 데이터(https://hyperionresearch.com/product/slurm-remains-top-resource-manager/?ref=distributedthoughts.org)에 따르면 전체 HPC 사이트의 50 %가 Slurm을 사용하고 있으며, 그 다음으로 높은 비율은 OpenPBS가 18.9 %, PBS Pro가 13.9 %, LSF가 **10.6 %**를 차지합니다. 격차는 좁혀지고 있는 것이 아니라 점점 벌어지고 있습니다.

두‑문 전략

그 모든 소음과 동시에, NVIDIA는 가만히 있지 않았다.

2024년 4월, NVIDIA는 약 7억 달러에 Run:AI를 인수했습니다. Run:AI는 Kubernetes 기반 GPU 오케스트레이션을 구축합니다…

(원문은 여기서 끊겼으며, 기사 나머지는 이 이후에 계속됩니다.)

Run:AI vs. Slurm – 같은 목표를 향한 두 경로

Slurm이 슈퍼컴퓨터와 전통적인 HPC 클러스터에서 GPU 작업을 관리하는 방식이라면, Run:AI는 클라우드‑네이티브 조직이 Kubernetes에서 동일한 일을 수행하는 방식입니다—다른 패러다임이지만 같은 기능을 제공하며, 이제 NVIDIA가 두 경우 모두의 스케줄링 레이어를 소유하고 있습니다.

Run:AI 세계

Run:AI는 컨테이너와 마이크로‑서비스에서 탄생한 세계를 다룹니다:

조직이 GKE, EKS 또는 온‑프레미스 Kubernetes 클러스터에서 운영
데이터 사이언스 팀이 다음을 중심으로 워크플로를 구축
기업이 배치 큐와 노드 할당 대신 파드와 디플로이먼트로 사고

Slurm 세계

Slurm은 슈퍼컴퓨팅에서 탄생한 세계를 다룹니다:

국립 연구소
연구 대학
분자 동역학을 수행하는 제약회사
위험 시뮬레이션을 수행하는 금융회사
HPC가 클라우드보다 먼저 도입된 조직, 그리고 “스케일”이 수천 대 노드의 전용 클러스터를 의미하는 곳

두 길 모두 GPU로 이어지며, 이제 NVIDIA가 양쪽의 트래픽을 제어합니다.

Source: https://judahtaub.substack.com/p/the-startup-escape-plan-for-cuda?ref=distributedthoughts.org

실제 락‑인 모습

Judah Taub의 CUDA 분석은 프로그래밍 모델이 실제 락‑인을 만든다는 점을 정확히 짚고 있습니다. GPU 커널을 다른 플랫폼용으로 다시 작성하는 비용이 크고, CUDA 주변의 라이브러리·툴·커뮤니티 지식 생태계는 수십 년에 걸친 투자 결과이기 때문입니다.

하지만 프로그래밍 모델은 추상화될 수 있고, 컴파일러가 번역해 주며, 호환성 레이어도 존재합니다.

PyTorch는 ROCm을 통해 AMD GPU에서도 실행됩니다.

JAX는 TPU에서 실행됩니다.

코드 자체가 반드시 CUDA에 영구적으로 묶여 있을 필요는 없습니다. 전환에 마찰이 있더라도 말이죠.

오케스트레이션 끈끈함

오케스트레이션은 다른 형태의 끈끈함을 만들어냅니다. 워크플로우가 Slurm에 다음과 같이 인코딩되어 있기 때문입니다:

모든 배치 스크립트
모든 잡‑어레이 정의
“단계 B는 단계 A가 성공적으로 완료된 후에만 실행한다”는 의존성 체인

이는 단순한 코드가 아니라 기관의 기억입니다.

회계 시스템은 Slurm과 연동돼 부서장이 GPU 할당량 사용 현황을 확인할 수 있는 보고서를 제공합니다.
청구 시스템은 내부 프로젝트에 비용을 청구합니다.
컴플라이언스 로그는 정부 지원 연구가 승인된 인프라에서 실행됐는지 검증합니다.

사용자는 명령어를 입력할 때 Slurm을 떠올리고, 잡이 멈추거나 실패했을 때 디버깅 직관을 사용하며, HPC 팀이 만든 교육 자료와 새벽 2시 구글링을 통해 찾은 Stack Overflow 답변을 활용합니다.

클러스터 토폴로지는 Slurm 알고리즘에 맞게 최적화돼 있습니다:

Fat‑tree 토폴로지를 Slurm이 이해하도록 맞춘 네트워크 구성
조직 계층 구조를 반영한 파티션 구조
로컬리티와 공정성을 균형 있게 배분한 노드 그룹화

스케줄러를 바꾸는 것은 재컴파일이 아니라 재조직화입니다.

약속과 패턴

NVIDIA는 Slurm이 계속해서 오픈‑소스이며 벤더‑중립을 유지할 것이라고 말하고, GPL‑v2 라이선스 때문에 소스를 폐쇄하는 것이 법적으로 문제된다고 강조합니다. 따라서 SchedMD의 기존 고객들이 차단될 일은 없습니다.

하지만 로드맵에 대한 통제와 코드 자체에 대한 통제는 다릅니다.

NVIDIA가 기능을 우선시할 때, 어떤 하드웨어가 일류 Slurm 지원을 받게 될까?
성능 최적화가 배포될 때, 어떤 GPU가 가장 큰 혜택을 받을까?
Slurm과 NVIDIA 소프트웨어 스택 전체 간의 통합이 강화될 때, “벤더‑중립”이라는 약속이 AMD와 Intel 가속기에 대한 동등한 최적화를 의미할까?

이러한 패턴은 엔터프라이즈 소프트웨어에서도 나타납니다:

Oracle은 MySQL을 실행하는 것을 막지 않습니다.
Microsoft는 비‑Azure 클라우드에서 GitHub를 사용하는 것을 막지 않습니다.

그럼에도 불구하고 통합 포인트, 다듬기 정도, 성능 최적화는 소유자의 제품 쪽으로 흐르게 됩니다.

NVIDIA의 공식 입장은 Slurm이 “전 세계 개발자, 연구 기관, 클라우드 서비스 제공자가 대규모 학습 인프라를 운영하는 데 필수적인 인프라를 형성한다”고 강조하는데, 이는 사실이며 이제 그 필수 인프라를 NVIDIA가 소유하고 있습니다.

Source: …

분산 격차

전통적인 HPC 스케줄링—Slurm이든 경쟁 제품이든—은 특정 아키텍처를 전제로 합니다. 큰 중앙 집중식 클러스터에서 작업이 노드에 걸쳐 스케줄링되며, 최적화 문제는 통합 시스템 내에서 작업을 자원에 매핑하는 형태가 됩니다.

이 아키텍처는 데이터와 컴퓨팅이 동일한 위치에 있을 때 잘 작동합니다. 학습 작업은 고속 병렬 파일 시스템에서 데이터를 가져오고, 시뮬레이션은 로컬 스토리지에 스테이징된 데이터셋을 사용하므로 클러스터 자체가 하나의 독립된 세계가 됩니다.

하지만 세상은 변하고 있습니다

데이터 주권 요구로 인해 데이터셋을 GPU가 있는 곳으로 옮길 수 없습니다.
엣지 배포는 데이터를 네트워크를 통해 이동시키지 않고 추론을 수행해야 합니다.
연합 학습은 민감한 정보를 중앙화하지 않고 기관 간 학습을 조정해야 합니다.
멀티 클라우드 전략은 컴퓨팅을 공급자, 지역, 아키텍처 전반에 걸쳐 분산시킵니다.

Run:AI는 Kubernetes 기반 오케스트레이션을 지원하지만 Kubernetes를 전제로 하고, Slurm은 전통적인 클러스터 아키텍처를 전제로 합니다. 두 솔루션 모두 다음 문제를 해결하지 못합니다:

“데이터가 50곳에 있고, 컴퓨팅은 12가지 다른 구성에 분산되어 있으며, 규제 제약 때문에 이것을 하나의 큰 클러스터로 가정할 수 없습니다.”

NVIDIA의 인수는 중앙 집중화 흐름을 강화합니다. 더 큰 클러스터, 더 많은 GPU, 데이터를 우리에게 가져오라는 것이죠. 이는 많은 워크로드에 유효한 아키텍처이며, 초대규모 파운데이션 모델 학습에는 유일한 아키텍처일 수도 있습니다.

하지만 그것이 유일한 아키텍처는 아니며, 진정으로 분산된 컴퓨팅을 위한 오케스트레이션 격차는 여전히 넓게 남아 있습니다. (관심 있으시면 몇 가지 생각을 공유합니다 :))

I’m happy to translate the passage for you, but I don’t see the “> Source: …” line that you’d like me to keep unchanged at the top. Could you please provide the source line (or confirm that there isn’t one) so I can include it exactly as you need?

NVIDIA의 플레이북: 오케스트레이션 레이어 장악

하드웨어 경쟁이 주목받고 있습니다—AMD의 MI300X, Intel의 Gaudi, Google의 TPU, 그리고 맞춤형 실리콘을 만들기 위해 수억 달러를 모으는 스타트업들—모두가 칩에 집중하게 만들죠.

NVIDIA는 한 단계 위를 바라보며 오케스트레이션 레이어를 장악하는 자가 어떤 칩이 어떤 워크로드를 실행할지 결정하는 권한을 가진다는 것을 깨달았습니다. 스케줄러는 단순히 자원을 할당하는 것이 아니라, 어떤 자원이 존재하고 어떻게 사용되어야 하는지에 대한 가정을 코드에 담고 있습니다.

Slurm과 Run:AI를 모두 인수함으로써, NVIDIA는 전통적인 HPC든 클라우드‑네이티브 Kubernetes든 어떤 패러다임을 사용하든 GPU 워크로드를 스케줄링하는 소프트웨어 레이어가 NVIDIA에서 나오도록 보장합니다. 즉, CUDA 대안이라 할지라도 여전히 NVIDIA의 오케스트레이션을 거쳐야 합니다. 이는 도로와 신호등을 모두 소유한 것과 같습니다: 차종은 다를 수 있지만 모두 같은 교차로에서 멈춥니다.

이것이 다른 모든 사람에게 남는 상황

기존 Slurm 사용자

즉시 크게 변하는 것은 없습니다.
소프트웨어는 여전히 오픈 소스입니다.
SchedMD의 지원 계약은 계속될 것으로 보입니다.
Slurm을 운영하는 데 경력을 쌓은 40명의 직원은 이제 NVIDIA 직원이 되었으며, 아마도 NVIDIA 자원을 이용하게 될 것입니다.

NVIDIA 하드웨어 지배에 대한 대안 구축자들

상황이 더욱 어려워졌습니다.
새로운 가속기는 소프트웨어‑생태계 지원이 필요하며, 이는 이제 다음 중 하나를 의미합니다:
1. NVIDIA가 소유한 Slurm이 귀하의 하드웨어를 일등 시민으로 대우하도록 설득하거나, 또는
2. 자체 오케스트레이션 레이어를 처음부터 구축하는 것입니다.

클러스터 모델 밖에서 분산 컴퓨팅을 고민하는 모든 사람

메시지는 명확합니다: 주요 업체들은 여러분을 위해 구축하지 않습니다.
진정으로 분산되고 이기종이며 데이터‑중력을 고려한 배포를 위한 오케스트레이션 레이어는 그들의 포트폴리오에 존재하지 않습니다.

그것은 도전이면서 기회이기도 합니다.

The Moats

CUDA moat – 실제적이고 눈에 보이며 지속적으로 논의되는, 경쟁 에너지의 초점이 되는 영역.
Orchestration moat – Slurm이 GPU만큼 헤드라인을 장식하지 않고, 스케줄링 소프트웨어가 “섹시”하지 않기 때문에 조용하지만, 실제 의사결정이 이루어지는 곳.

인텔리전트 데이터 파이프라인이 AI 비용을 줄이는 방법을 배우고 싶으신가요?

Expanso 확인하기

아니면 안 보셔도 됩니다. 제가 뭘 시키겠어요?

NOTE: 저는 현재 머신러닝을 위한 데이터 준비의 실제적인 과제—운영, 컴플라이언스, 비용 측면—에 대해 책을 쓰고 있습니다.
여러분의 의견을 듣고 싶습니다

원문은 Distributed Thoughts에 처음 게시되었습니다.