팀별로 GPU 쿼터를 나눠뒀는데도 "GPU가 없어요"라는 말이 끊이지 않는다면, 원인은 대개 쿼터의 크기가 아니라 할당과 사용 사이의 간극에 있습니다.
금요일 오후에 띄워둔 Jupyter 노트북이 월요일까지 GPU를 붙잡고 있고, 실험이 끝난 개발 환경이 아무도 모르게 쿼터를 차지하고 있습니다. 대시보드에는 GPU가 모두 '할당됨'으로 보이지만 실제 연산은 거의 일어나지 않는 상태. 이른바 '유령 점유'입니다.
이 글에서는 GPU 쿼터의 개념과 쿠버네티스 기본 기능의 한계, 실무에서 통하는 쿼터 설계 원칙, 그리고 유휴 자원을 자동으로 회수하는 방법을 정리합니다.
GPU 쿼터란?
GPU 쿼터(Quota)는 팀, 프로젝트, 사용자가 동시에 점유할 수 있는 GPU 자원의 상한을 정책으로 정해두는 것입니다.
쿼터는 '얼마나 쓸 수 있는가'를 정할 뿐, '언제 돌려받는가'와 '누가 먼저 쓰는가'는 정하지 않습니다. 그래서 쿼터는 혼자서는 제 역할을 못 하고, 회수 정책과 우선순위가 함께 있어야 합니다.
정책 | 답하는 질문 | 없을 때 생기는 문제 |
쿼터 | 얼마나 쓸 수 있는가? | 한 팀이 클러스터 독점 |
회수 | 언제 돌려받는가? | 쓰지 않는 자원이 쿼터를 계속 점유 |
우선순위 | 누가 먼저 쓰는가? | 급한 작업이 긴 대기열 뒤에 묶임 |
쿠버네티스 ResourceQuota만으로 부족한 이유
쿠버네티스는 ResourceQuota로 Namespace별 GPU 사용량을 제한할 수 있습니다. 하지만 GPU 운영에서는 다음 한계가 금방 드러납니다.
- 장 단위 제한:
requests.nvidia.com/gpu: 4처럼 GPU 장 수로만 제한하므로, 분할된 GPU를 쿼터로 관리하기 어렵습니다.
- Namespace 단위만: 팀 안에서 사용자별 한도를 두려면 별도 설계가 필요합니다.
- 자원 조합 단편화: CPU, 메모리, GPU를 따로 제한하면 GPU는 남는데 CPU가 부족해 작업이 못 뜨는 식의 단편화가 생깁니다.
- 시간 개념 없음: 쿼터 안에서라면 자원을 며칠이고 점유해도 막을 방법이 없습니다.
GPU 쿼터 설계 원칙 4가지
- 할당 단위부터 정한다: GPU 장 단위로 줄지, 분할 블록 단위로 줄지, CPU·메모리·GPU 묶음으로 줄지 먼저 정해야 쿼터 숫자가 의미를 가집니다.
- 2단 쿼터로 설계한다: 프로젝트 상한으로 팀 간 공정성을, 사용자 상한으로 팀 내 독점을 막습니다.
- 워크로드 유형별로 다르게 둔다: 개발 환경, 학습, 서빙은 자원을 쓰는 방식이 다르므로 같은 규칙을 적용하면 안 됩니다.
- 실사용 데이터로 분기마다 조정한다: 쿼터를 다 쓰는 팀과 늘 남기는 팀을 사용량 집계로 확인하고 재배분합니다.
워크로드 유형 | 자원 사용 패턴 | 쿼터 운영 가이드 |
개발 환경 (Workspace) | 장기 실행, 실제 연산은 간헐적 | 작게 + 점유 시간 제한으로 자동 회수 |
학습·배치 (Job) | 단기 집중 사용, 완료 후 종료 | 크게 + 우선순위로 실행 순서 관리 |
서빙 (Operation) | 상시 실행, 트래픽 따라 변동 | 최소 보장 + 자동 확장 여유분 |
유휴 자원 회수 방식 3가지 비교
방식 | 동작 | 장점 | 한계 |
수동 회수 | 관리자가 메신저로 확인 후 종료 요청 | 별도 도구 불필요 | 관리자 부담, 갈등 유발, 늦음 |
시간 기반 자동 회수 | 점유 시간 한도 초과 시 자동 일시정지 | 규칙이 명확, 예측 가능 | 한도 설정을 워크로드별로 설계해야 함 |
사용률 기반 재분배 | 할당됐지만 쓰지 않는 비율을 감지해 다른 작업에 분배 | 할당 상태를 유지하면서 효율 상승 | 분할 방식 등 플랫폼 지원 필요 |
두 가지 자동 방식은 대체가 아니라 보완 관계입니다. 시간 기반 회수는 '잊힌 환경'을 정리하고, 사용률 기반 재분배는 '켜져 있지만 덜 쓰는 자원'을 살립니다.
AIPub으로 GPU 쿼터와 회수를 구현하는 방법
TEN의 AIPub은 쿼터, 회수, 우선순위, 사용량 집계를 FinOps Suite와 자체 스케줄러로 함께 제공합니다.
ResourceSet: 자원을 묶음 단위로 할당
AIPub은 CPU, 메모리, GPU를 ResourceSet이라는 하나의 단위로 묶어 할당합니다. 노드의 가용 자원을 균등하게 나눠 Set을 자동 생성하므로, GPU는 남는데 CPU가 없어 작업이 못 뜨는 단편화를 줄입니다. MIG나 Block 분할과 결합하면 더 작은 Set도 만들 수 있어, 같은 GPU에서 다양한 크기의 Set이 공존합니다.
ResourceSet Quota와 Storage Quota
쿼터는 Project 단위와 User 단위 두 단계로 적용되고, 스토리지 쿼터도 별도로 설정합니다. 사용자가 워크로드를 요청하면 AIPub은 권한 확인 다음 단계에서 쿼터를 검증한 뒤 허용 여부를 결정합니다.
Workspace Reclaim: 잊힌 개발 환경 자동 회수
Workspace Reclaim은 사용자별 Workspace의 자원 점유 시간을 0~99,999시간 범위에서 제한합니다. 한도를 넘으면 Workspace를 자동으로 일시정지(Pause)해 자원을 회수하고, 사용자가 다시 시작(Resume)하면 시간이 갱신됩니다. 관리자가 메신저로 "이거 쓰시는 건가요?"를 묻지 않아도 되는 구조입니다.
Dynamic Allocation과 Priority Queue
Block 분할 모드에서는 Dynamic Allocation이 컨테이너에 할당된 자원 중 실제로 쓰지 않는 비율을 실시간으로 감지해 다른 컨테이너에 분배하고, 새 워크로드가 들어오면 필요한 만큼 회수해 할당합니다. 대기 중인 작업은 관리자가 Priority Queue에서 순서를 직접 바꾸거나 즉시 격상할 수 있어, 쿼터 때문에 급한 작업이 막히는 상황에 대응할 수 있습니다.
Usage로 쿼터를 데이터 기반으로 조정
Usage 기능은 컨테이너별 자원 할당 시간을 기준으로 월별 사용량을 집계하고, 계정별·프로젝트별로 조회해 Excel로 내려받을 수 있습니다. 주간·월간 자동 리포트와 함께 보면 어느 팀이 쿼터를 늘 다 쓰고 어느 팀이 남기는지 분기마다 근거를 갖고 재배분할 수 있습니다.
GPU가 부족하다고 느껴질 때 먼저 봐야 할 것은 GPU 수량이 아니라 '할당됐지만 쓰지 않는 자원'의 규모입니다. 쿼터로 상한을 정하고, 회수로 잊힌 자원을 돌려받고, 우선순위로 급한 작업을 앞에 세우면 같은 GPU로 더 많은 팀이 일할 수 있습니다.
자주 묻는 질문(FAQ)
Q. 쿼터를 너무 작게 잡으면 어떻게 되나요?
연구자의 대기 시간이 늘고, 팀이 쿼터를 확보하려고 자원을 미리 붙잡아 두는 역효과가 생깁니다. 처음에는 여유 있게 두고, 사용량 데이터를 보며 줄여가는 편이 안전합니다.
Q. Workspace Reclaim이 실행 중인 학습을 중단시키나요?
Workspace Reclaim은 개발·디버깅용 Workspace에 적용되는 기능입니다. 학습은 완료 후 종료되는 Job으로 실행하는 것이 원칙이며, Workspace의 작업 내용은 볼륨이나 이미지 커밋으로 저장해 두도록 운영 규칙을 함께 안내하는 것이 좋습니다.
Q. 쿼터와 Chargeback은 어떤 관계인가요?
쿼터는 사전 한도이고 Chargeback은 사후 비용 배분입니다. 사용량 집계가 있어야 쿼터를 조정할 근거와 비용을 나눌 근거가 동시에 생깁니다.
Q. 쿼터가 꽉 찼는데 긴급한 작업이 들어오면요?
관리자가 우선순위 큐에서 해당 작업의 순서를 올리거나, Dynamic Allocation으로 유휴 자원을 재분배해 대응할 수 있습니다. 긴급 작업 기준을 미리 정해두면 판단이 빨라집니다.
참고 자료
- Kubernetes Documentation, Resource Quotas
- TEN, AIPub Technical Document (2026.05)
Share article