Kubernetes

AI 워크로드의 세 가지 요구 — 비싼 자원의 공유, 대량 병렬 실행, 탄력적 확장 — 이 쿠버네티스의 원래 강점과 맞물리기 때문입니다. 그래서 쿠버네티스 GPU 운영이 AI 인프라의 기본 골격이 됩니다.

AI 워크로드는 크게 학습(training)과 추론(inference)으로 나뉩니다. 학습은 GPU 여러 장을 오래 점유하는 배치 작업이고, 추론은 사용자 요청에 따라 순간적으로 늘었다 줄어드는 온라인 서비스입니다. 성격이 정반대인 두 워크로드가 같은 GPU 풀(pool)을 두고 경쟁하는 것이 AI 인프라의 기본 구도입니다.

이 구도를 수작업이나 가상 서버 단위 관리로 풀기는 어렵습니다. 서버마다 구성이 조금씩 다른 이른바 ‘스노우플레이크 서버’가 쌓이면 AI 자동화 도구가 전체 맥락을 파악할 수 없고, 각 단계를 일일이 지시하는 명령형 운영은 규모가 커질수록 사람을 병목으로 만듭니다. 반면 쿠버네티스는 원하는 최종 상태만 선언하면 중앙 컨트롤 플레인이 전체 시스템을 맞춰 가는 선언형 구조라, AI 시대의 완전 자동화와 맞는 짝이라는 분석이 나옵니다(AI 시대의 쿠버네티스 선택).

수치도 이 방향을 가리킵니다. 2025년 CNCF 조사에서 컨테이너 사용 조직의 82%가 쿠버네티스를 프로덕션에서 운영한다고 답했고, CNCF는 이 발표에서 쿠버네티스가 AI 워크로드의 기반 계층으로 자리 잡았다는 점을 함께 짚었습니다(CNCF, 2026-01-20). 웹 서비스의 표준이었던 플랫폼이 AI 인프라의 표준으로 무게 중심을 옮기는 중입니다. 쿠버네티스 GPU 스케줄링이 그 이동의 실무적 접점입니다.

쿠버네티스 GPU 배분은 device plugin으로 GPU를 자원으로 인식하는 데서 출발하고, MIG·time-slicing 으로 GPU 한 장을 여러 워크로드가 나눠 쓰게 만듭니다.

쿠버네티스가 CPU·메모리 외의 하드웨어를 다루는 표준 통로는 디바이스 플러그인(device plugin) 프레임워크입니다. GPU 제조사가 제공하는 플러그인이 노드의 GPU를 클러스터에 등록하면, 파드는 CPU를 요청하듯 GPU를 요청해 배정받습니다(kubernetes.io — GPU 스케줄링).

문제는 배정 단위입니다. 기본 동작은 GPU 한 장을 파드 하나가 통째로 점유하는 방식이라, 작은 추론 워크로드가 대형 GPU를 붙잡고 있으면 나머지 용량이 그대로 낭비됩니다. 이를 풀기 위한 공유 기법이 두 가지입니다.

• MIG(Multi-Instance GPU) — NVIDIA A100·H100 계열에서 GPU 한 장을 하드웨어 수준에서 최대 7개의 독립 인스턴스로 분할하는 기술입니다. 인스턴스마다 메모리와 연산 자원이 격리되므로, 서로 다른 팀의 워크로드가 한 장을 나눠 써도 간섭이 없습니다(NVIDIA MIG 문서).
• Time-slicing(시분할) — GPU를 시간 단위로 잘라 여러 파드가 번갈아 쓰는 소프트웨어 방식입니다. 하드웨어 격리는 없지만, 간헐적으로만 GPU를 쓰는 개발·실험 워크로드의 밀도를 높이는 데 유용합니다(NVIDIA GPU Operator 문서).

정리하면 이렇게 고르면 됩니다. 프로덕션 추론처럼 격리와 예측 가능성이 중요하면 MIG, 개발·실험처럼 활용률이 우선이면 time-slicing, 대형 학습처럼 GPU 전체 성능이 필요하면 전용 배정입니다. 어떤 방식이든 쿠버네티스 GPU 스케줄링을 클러스터가 맡는 순간, “누가 어느 GPU를 쓰는가”가 수작업 예약표에서 선언형 정책으로 바뀝니다. 예약표를 관리하던 사람이 정책을 설계하는 사람으로 역할을 옮기는 지점이기도 합니다.

학습은 잡(Job) 기반 배치 스케줄링, 추론은 오토스케일링이 붙는 서빙 계층 — 두 패턴 모두 쿠버네티스 생태계에 표준 도구가 자리 잡았습니다.

학습 쪽의 기본 단위는 배치 잡입니다. 쿠버네티스 생태계에는 분산 학습 잡을 정의하고 관리하는 도구로 Kubeflow가 자리 잡았습니다. Kubeflow는 CNCF 인큐베이팅을 거쳐 여러 프레임워크의 분산 학습 잡을 커스텀 리소스로 선언하는 표준 경로를 제공합니다(kubeflow.org). 학습 잡은 실패한 워커를 다시 띄우는 재시도, 자원이 빌 때까지 기다리는 큐잉, 우선순위 기반 선점이 관건인데, 이 요구는 쿠버네티스의 잡 스케줄링 확장(Kueue 등)이 다루는 영역과 겹칩니다.

추론 쪽은 일반 웹 서비스와 비슷하되 자원이 GPU라는 점이 다릅니다. 표준 서빙 계층으로는 KServe가 대표적입니다. 모델을 커스텀 리소스로 선언하면 배포·버전 관리·트래픽 분할·오토스케일링을 플랫폼이 처리합니다(kserve.github.io). 대규모 언어 모델(LLM) 추론에서는 vLLM 같은 고성능 추론 엔진을 쿠버네티스 위에 올려 GPU 처리량을 끌어올리는 구성이 일반화됐습니다(vLLM 문서).

두 패턴의 공통점은 분명합니다. 모델 코드가 아니라 선언과 컨트롤러가 운영을 담당한다는 것입니다. 학습 잡이 몇 개 떠야 하는지, 추론 복제본이 트래픽에 따라 몇 개까지 늘 수 있는지를 선언해 두면, 새벽에 워커가 죽어도 사람이 아니라 컨트롤러가 되살립니다. 웹 서비스 운영에서 검증된 이 원리가 AI 워크로드에 그대로 이식되는 셈입니다. 쿠버네티스 GPU 위에서 학습과 추론이 같은 문법으로 관리된다는 점이 운영팀 입장에서는 가장 큰 이득입니다.

GPU 비용 절감의 핵심은 더 싼 GPU를 찾는 것이 아니라, 놀고 있는 GPU를 클러스터가 자동으로 회수해 다른 워크로드에 돌리는 구조입니다.

GPU는 서버 자원 중 가장 비싼 축에 들지만, 실제 활용률은 생각보다 낮은 경우가 많습니다. 학습 잡이 끝난 뒤 반납되지 않은 GPU, 야간에 놀고 있는 개발용 GPU, 특정 팀이 ‘혹시 몰라’ 잡아 둔 GPU가 대표적입니다. 수작업 예약 방식에서는 이 유휴분이 보이지도, 회수되지도 않습니다.

쿠버네티스 기반 GPU 풀은 이 문제를 구조적으로 다룰 수 있습니다. 우선순위와 선점(preemption)을 선언해 두면, 유휴 상태의 저순위 워크로드에서 자원을 회수해 대기 중인 고순위 잡에 배정합니다. 앞서 본 MIG·time-slicing 공유 기법과 조합하면, 같은 GPU 수로 더 많은 워크로드를 수용하는 밀도 개선이 가능합니다.

인프라 계층의 선택도 비용에 직결됩니다. 가상 머신 위에 쿠버네티스를 얹는 이중 구조는 하이퍼바이저 오버헤드와 이중 라이선스 비용이라는 ‘가상화 세금’을 물게 되는데, GPU 성능을 극대화하려면 가상화 계층을 걷어 낸 베어메탈(bare metal, 하이퍼바이저 없이 물리 서버에 직접 구축) 쿠버네티스가 유리하다는 분석이 나옵니다(AI 시대 인프라 전략 — 베어메탈 쿠버네티스). 같은 글은 퍼블릭 클라우드 비용과 데이터 주권 문제로 자체 인프라로 돌아오는 클라우드 송환(repatriation) 흐름에서도, 관건은 인프라의 위치가 아니라 운영 방식이라고 짚습니다. 요컨대 GPU 비용 문제의 답은 구매 단가가 아니라 회수와 공유가 자동으로 일어나는 운영 구조에 있습니다. 쿠버네티스 GPU 풀을 구성하는 목적도 결국 그 구조를 만드는 데 있습니다.

GPU 노드 풀 설계, 공유 정책, 관측 지표 세 가지를 갖추면 쿠버네티스 GPU 운영의 뼈대가 섭니다.

AI 워크로드를 쿠버네티스에 올리려는 조직이 준비할 것은 세 층위로 정리됩니다.

1. GPU 노드 풀 설계 — 학습용(대형 GPU 전용 배정)과 추론·실험용(MIG/time-slicing 공유) 노드 풀을 분리하고, 테인트·톨러레이션으로 일반 워크로드와 섞이지 않게 합니다.
2. 공유·회수 정책 선언 — 팀별 자원 쿼터, 우선순위 클래스, 선점 정책을 선언형으로 박아 둡니다. 예약표 대신 정책이 GPU를 배분하게 만드는 단계입니다.
3. GPU 관측 지표 확보 — GPU 활용률·메모리 사용량을 지표로 수집해야 유휴분이 보입니다. 관측 없는 회수 정책은 감으로 하는 비용 절감에 그칩니다. 쿠버네티스 GPU 지표는 노드 단위가 아니라 파드·팀 단위로 쪼개 봐야 회수 대상이 특정됩니다.

대규모 클러스터 운영의 일반 원칙(자동화·관측성·표준화)은 AI 워크로드에서도 그대로 유효합니다. 실제 기업들의 운영 기록은 쿠버네티스 프로덕션 도입 사례에서, 조직 차원의 도입 판단 기준은 쿠버네티스 도입 전략에서 이어집니다. AI 인프라 투자가 본격화되는 지금, 쿠버네티스 GPU를 다루는 능력은 클러스터 운영 역량의 연장선 위에 있습니다. 새 조직을 꾸리기보다 기존 플랫폼 팀의 역량을 확장하는 편이 현실적인 이유입니다.

AI 워크로드에 쿠버네티스가 필요한 이유는 무엇인가요?

값비싼 GPU를 여러 팀·워크로드가 나눠 쓰고, 학습 잡을 병렬 실행하며, 추론 서비스를 트래픽에 맞춰 늘렸다 줄여야 하기 때문입니다. 이 요구가 쿠버네티스의 자원 스케줄링·오토스케일링·자가 치유와 맞물려, CNCF는 쿠버네티스를 “AI를 위한 사실상의 운영체제”로 규정했습니다(CNCF, 2026-01-20).

쿠버네티스 GPU는 어떻게 할당하나요?

GPU 제조사의 디바이스 플러그인이 노드의 GPU를 클러스터 자원으로 등록하면, 파드가 CPU처럼 GPU를 요청해 배정받습니다(kubernetes.io — GPU 스케줄링). 기본은 GPU 한 장 통째 배정이며, 공유가 필요하면 MIG나 time-slicing을 조합합니다. 쿠버네티스 GPU 요청은 CPU·메모리 요청과 같은 문법이라 기존 매니페스트 구조를 그대로 씁니다.

MIG와 time-slicing은 무엇이 다른가요?

MIG는 A100·H100 계열 GPU를 하드웨어 수준에서 최대 7개의 격리된 인스턴스로 나누는 기술이고, time-slicing은 GPU를 시간 단위로 여러 파드가 번갈아 쓰는 소프트웨어 방식입니다. 격리·예측 가능성이 중요한 프로덕션 추론은 MIG, 활용률이 우선인 개발·실험은 time-slicing이 적합합니다.

학습과 추론은 같은 클러스터에서 운영해도 되나요?

노드 풀과 정책을 분리하면 가능합니다. 학습용 전용 노드 풀과 추론·실험용 공유 노드 풀을 나누고, 우선순위·선점 정책으로 자원 경쟁을 조율하는 구성이 일반적입니다. 관건은 물리적 분리가 아니라 정책의 분리입니다. 쿠버네티스 GPU 쿼터를 팀 단위로 나눠 두면 같은 클러스터에서도 학습이 추론 자원을 잠식하지 않습니다.

AI 인프라는 베어메탈과 가상 머신 중 무엇이 유리한가요?

GPU 성능을 극대화하려면 하이퍼바이저 계층이 없는 베어메탈 쿠버네티스가 유리하다는 분석이 우세합니다. 가상화 계층은 오버헤드와 이중 라이선스 비용을 더하기 때문입니다(베어메탈 쿠버네티스 가이드). 다만 결론은 워크로드 특성에 따라 달라지므로, 위치보다 운영 방식을 먼저 설계해야 합니다.

• CNCF 2025 조사 발표 — 쿠버네티스, AI의 사실상 운영체제로
• 쿠버네티스 공식 문서 — GPU 스케줄링
• NVIDIA MIG 사용자 가이드
• NVIDIA GPU Operator — GPU 공유(time-slicing)
• Kubeflow 공식 사이트
• 쿠버네티스 프로덕션 도입 사례 — 카카오·LY·Adobe
• KServe 공식 문서
• AI 시대의 쿠버네티스 선택 — cncf.co.kr
• AI 시대 인프라 전략 — 베어메탈 쿠버네티스 가이드
• 쿠버네티스란 무엇인가 — 필러 가이드

더 깊이 들어가려면

쿠버네티스 위의 AI 워크로드 운영을 직접 실험해 보고 싶다면 아래 경로로 이어가 보세요.

• GitHub repo 방문 — kubeflow/kubeflow 에서 분산 학습 플랫폼의 소스와 릴리스 노트를 확인하세요.
• Kubeflow 살펴보기 — kubeflow.org 에서 분산 학습·파이프라인 구성 요소를 확인하세요.
• CNCF Slack 참여 — slack.cncf.io 에서 AI 인프라를 운영하는 전 세계 실무자와 토론할 수 있습니다.
• CNCF Landscape 확인 — landscape.cncf.io 에서 AI/ML 카테고리의 클라우드 네이티브 프로젝트를 한눈에 살펴보세요.