금요일 저녁, 금융 서비스 기업의 머신러닝(ML) 엔지니어인 Priya는 시간당 55달러짜리 GPU 클러스터에 이상 거래 탐지(fraud-detection) 모델의 파인튜닝 작업을 걸어둡니다. 작업 완료까지는 약 40시간이 소요될 예정이며, 연산 비용은 대략 2,200달러입니다. 그는 하이퍼파라미터를 다시 확인하고 작업을 제출한 뒤 주말을 보내기 위해 퇴근합니다.
월요일 아침, 그는 노트북을 엽니다. 모델은 금요일 밤 어느 시점에 학습을 중단했지만, 작업은 계속 실행되어 아무런 성과 없는 학습 과정에 이틀 분량의 GPU 시간을 소모했습니다. 이로 인해 1,500달러 이상의 컴퓨팅 비용이 낭비되었으며, 작업을 처음부터 다시 시작해야 합니다.
이러한 상황이 익숙하게 느껴진다면, 이는 여러분만의 문제가 아닙니다. 며칠 동안 학습 작업을 실행해 본 실무자라면 다음과 같은 곤란한 질문을 한 번쯤 떠올려 보았을 것입니다.
- 모델이 실제로 학습하고 있는 것이 맞을까요?
- 일찍 중단하고 다른 하이퍼파라미터를 시도해야 할까요?
- 화요일에 있을 이해관계자 검토 전에 작업이 완료될 수 있을까요?
상황을 파악하지 못해 발생하는 비용은 실질적인 부담이 됩니다. 온디맨드 GPU 클러스터 비용은 시간당 50달러 이상에 달할 수 있습니다. 며칠이 소요되는 단일 학습 실행 비용은 수천 달러에 달하기 쉬우며, 설정이 잘못된 작업은 누군가 알아차리기 전까지 주말 내내 컴퓨팅 자원을 낭비할 수 있습니다. 공유 클러스터에서는 그 영향이 배가됩니다. 중단된 작업은 한 팀의 예산을 낭비할 뿐만 아니라, 다른 팀이 필요한 GPU에 액세스하는 것을 방해합니다. 한 팀의 무분별한 실행이 다른 팀의 지연으로 이어지는 것입니다. 문제는 팀이 부주의하다는 점이 아닙니다. 상황을 전혀 알지 못한 채 작업을 진행하고 있다는 점입니다. 모든 GPU 시간은 소중합니다. 학습 진행 상황을 실시간으로 가시화하지 못하면 너무나 많은 리소스가 낭비됩니다.
관측성 격차
불편한 진실은 플랫폼 관점에서 볼 때, 학습이 원활하게 진행되는 작업과 완전히 중단된 작업이 동일하게 보인다는 점입니다. 두 작업 모두 running 상태의 포드이며, 동일한 리소스를 사용하고 동일한 녹색 상태 표시등을 보여줍니다. 쿠버네티스는 모델이 실제로 학습 중인지 여부를 인식하지 못합니다.
현재도 학습 진행 상황을 모니터링할 수는 있지만, 필요 이상으로 복잡합니다.
- 로그가 분산되어 있어 활용하기 어렵습니다. 분산 학습 작업에서 로그는 여러 포드에 흩어져 있습니다. 관련 출력을 찾으려면 어떤 포드를 확인해야 하는지, 어떻게 액세스하는지, 그리고 프레임워크별 로그 형식을 어떻게 해석하는지 알아야 합니다. 여기에는 쿠버네티스 전문 지식이 필요합니다. 하지만 대부분의 데이터 사이언티스트와 AI 엔지니어가 학습 실행을 모니터링하기 위해 이러한 추가 기술까지 갖출 필요는 없습니다. 구조화되지 않은 불량 로그는 머신이 읽기 어렵기 때문에 자동화를 구현할 수 없습니다.
- 외부 툴은 관측성 문제를 해결하지만 관리 오버헤드를 가중시킵니다. MLflow나 Weights & Biases와 같은 실험 추적 플랫폼은 본연의 역할에 매우 충실합니다. 하지만 배포 및 유지 관리를 위한 추가 인프라, 관리해야 할 API 키와 액세스 제어가 필요하며, 플랫폼 계층 위에서 작동합니다. 또한 쿠버네티스 API와 연결되어 있지 않아, 사용자 정의 쿠버네티스 네이티브 워크플로우와 사용자 정의 오퍼레이터와 통합하기가 더 어렵습니다. 이러한 툴은 학습 루프 내부의 상황은 알려주지만, 플랫폼 자체에는 정보를 전달하지 못합니다.
- 프레임워크마다 방식이 다릅니다. PyTorch DDP, FSDP, DeepSpeed, JAX는 각기 고유한 로깅 규칙, 메트릭 형식, 그리고 진행 상황 보고 방식을 가지고 있습니다. 프레임워크 간의 일관성이 없기 때문에, 이기종 학습 환경을 관리하는 플랫폼 팀은 통합된 뷰를 가질 수 없습니다.
- 표준 API가 없습니다. 지금까지 학습 작업이 플랫폼에 진행 상황을 보고하는 표준화된 방법은 없었습니다. 그 결과, 공유 GPU 클러스터를 관리하는 플랫폼 관리자는 어떤 작업이 진행 중인지, 중단되었는지, 혹은 곧 완료될지를 추측에 의존해 파악해야 합니다. 이러한 가시성이 확보되지 않으면 용량 계획과 트러블슈팅은 짐작에 의존할 수밖에 없습니다.
격차 해소: Red Hat OpenShift AI의 진행 상황 추적 기능
Red Hat OpenShift AI에는 이제 Kubeflow Trainer v2를 기반으로 구축된 분산 학습 작업용 프로덕션 레디 진행 상황 추적 기능이 포함되어 있으며, Red Hat OpenShift AI 3.4 버전부터 정식 버전으로 제공됩니다. 작업이 진행되는 동안 실시간으로 상황을 파악하고, 너무 늦기 전에 조치를 취할 수 있습니다. 이 기능은 데이터 사이언티스트, ML 엔지니어, 플랫폼 관리자에게 학습 작업 성능에 대한 실시간 가시성을 제공하여 관측성 격차를 직접적으로 해결합니다.
이러한 가시성은 다음의 세 가지 핵심 요소를 기반으로 합니다.
- 대시보드 시각화: 실시간 진행 상황 메트릭을 Red Hat OpenShift AI 대시보드에서 직접 확인할 수 있습니다. TrainJob의 진행률, 현재 및 총 단계 수, 현재 에포크(epoch), 예상 잔여 시간, 학습 손실과 평가 메트릭을 한눈에 확인할 수 있습니다. 별도의 툴이나 추가 설정이 필요하지 않습니다.
- SDK 통합: Kubeflow SDK를 통해 프로그래밍 방식으로 동일한 진행 상황 데이터를 활용할 수 있습니다. 이를 통해 팀은 실시간 메트릭을 기반으로 조기 중단을 트리거하거나, 알림을 보내거나, 리소스를 재할당하는 등 학습 진행 상황에 대응하는 자동화된 파이프라인을 구축할 수 있습니다.
- 멀티프레임워크 일관성: PyTorch DDP, FSDP, DeepSpeed, JAX 중 무엇을 사용하더라도 진행 상황 추적은 동일한 방식으로 작동합니다. 또한 CustomTrainer API를 통해 사용자 정의 학습 코드도 지원합니다. 이를 통해 프레임워크 전반에 걸쳐 통합된 경험을 제공합니다.
실행 중인 학습 과정 확인하기
진행 상황 추적 기능을 이해하는 가장 좋은 방법은 실제 사용 환경이 어떤지 살펴보는 것입니다. 중요한 세 가지 단계는 다음과 같습니다.
- 학습 작업 시작: 지금과 동일하게 Kubeflow SDK를 사용하여 노트북에서 학습 작업을 제출합니다. HuggingFace Transformers를 사용하는 경우, 코드 변경 없이 진행 상황이 자동으로 추적됩니다. 통합 기능이 Kubeflow 환경을 감지하고 학습 루프에서 메트릭 보고를 시작합니다.
- 진행 상황 모니터링: 학습이 진행됨에 따라 진행률, 예상 잔여 시간, 완료된 단계, 에포크, 그래디언트 노름(gradient norm), 학습 손실, 학습률 등의 실시간 메트릭이 Red Hat OpenShift AI 대시보드에 표시됩니다. 로그 테일링이나 포드에 대한 SSH 접속, 외부 툴 설정이 전혀 필요 없습니다.
그림 1: Red Hat OpenShift AI 대시보드에는 실행 중인 TrainJob의 완료율이 40%임을 나타내는 진행률 표시줄과 함께 작업 목록이 표시됩니다.
그림 2: 작업 진행 상황과 실시간 메트릭을 보여주는 상세 측면 패널입니다.
- 가시화된 정보를 바탕으로 조치 수행: 진행 상황 추적 기능은 바로 이 지점에서 시간과 컴퓨팅 자원을 실제로 절약해 줍니다. 손실(loss)이 개선되지 않는 것을 확인하셨나요? 작업을 조기에 중단하여 GPU 시간을 대폭 절약하세요. 작업이 예상보다 빠르게 수렴되고 있나요? 팀원들을 위해 리소스를 확보해 주세요. 작업이 완료되는 시점을 정확히 파악하여 계획을 세울 수 있습니다. 화요일의 이해관계자 검토를 위해 결과가 준비될지 더 이상 추측할 필요가 없습니다.
이 기능을 실용적으로 만드는 주요 특징은 다음과 같습니다.
- 설정 불필요(Zero setup): 추가 인프라, 외부 종속성, 추가 구성이 필요하지 않습니다. 진행 상황 추적 기능을 즉시 사용할 수 있습니다.
- 최소한의 오버헤드: 학습 성능에 영향을 주지 않으면서 자연스러운 학습 체크포인트에서 메트릭이 보고됩니다.
- 프레임워크 간 호환성: PyTorch DDP, FSDP, DeepSpeed, JAX 또는 사용자 정의 학습 코드를 사용하더라도 동일한 경험을 제공합니다.
주요 혜택 대상
데이터 사이언티스트와 ML/AI 엔지니어는 포드에 SSH로 접속하거나 로그를 테일링하지 않고도 학습 손실, 진행률, 예상 완료 시간(ETA)을 실시간으로 확인할 수 있습니다. 학습 분산이나 중단 상황을 조기에 감지할 수 있습니다. 월요일이 아닌 토요일 아침에 중단된 작업을 파악하면 낭비되는 GPU 시간을 수 시간 절약할 수 있습니다. 대시보드에서 학습 실행을 한눈에 비교하여 어떤 하이퍼파라미터 설정의 성능이 가장 좋은지 빠르게 식별할 수 있습니다.
플랫폼 관리자는 클러스터 내의 모든 학습 작업에 대한 통합 대시보드 뷰를 확보할 수 있습니다. 작업에서 DDP, FSDP, DeepSpeed 중 무엇을 사용하든 일관된 메트릭을 확인할 수 있으며, 어떤 작업이 진행 중인지, 중단되었는지, 완료에 가까운지를 파악하여 더 나은 용량 계획을 세울 수 있습니다.
여러 팀이 동일한 클러스터를 공유하는 멀티테넌트(Multi-tenant) GPU 환경에서, 이러한 가시성은 자원 활용도와 투자 대비 효과(ROI)를 높이는 직접적인 동력이 됩니다. GPU-as-a-Service 모델을 구축하는 조직의 경우, 진행 상황 추적 기능은 'GPU 사용률 블랙박스'를 관찰 가능하고 관리 가능한 시스템으로 전환하여 중요한 격차를 메워줍니다. 결과적으로 플랫폼 팀은 인프라 병목 현상을 제거하고, 데이터 사이언티스트가 AI 혁신을 가속화하는 데 필요한 리소스를 자신 있게 제공할 수 있게 됩니다.
모니터링 이상의 가치: 더욱 스마트한 학습을 위한 기반 구축
진행 상황 추적은 단순한 모니터링 기능을 넘어 하나의 토대입니다. 플랫폼이 실시간 학습 진행 데이터에 액세스할 수 있게 되면, 일련의 더욱 스마트한 동작들이 가능해집니다. 이러한 고급 기능이 아직 Red Hat의 제품 로드맵으로 확정된 것은 아니지만, 이를 위한 기반은 마련되어 있습니다. 업스트림 Kubeflow Trainer 커뮤니티에서는 다음과 같은 여러 방향을 적극적으로 모색하고 있습니다.
- 더욱 스마트한 하이퍼파라미터 튜닝: 현재 Katib과 같은 하이퍼파라미터 최적화 엔진은 불안정한 정규식 패턴으로 로그를 파싱하여 실험 성능을 평가합니다. 쿠버네티스 API에서 직접 학습 메트릭을 사용할 수 있게 되면, Katib은 기본적으로 학습 상태를 읽을 수 있어 더 긴밀한 통합과 효율적인 실험 오케스트레이션이 가능해집니다. 이는 업스트림 커뮤니티에서 논의 중인 KEP의 내용입니다.
- 탄력적 확장: 수렴 속도와 ETA 데이터는 스케일 업 및 스케일 다운 결정의 근거가 될 수 있습니다. 빠르게 수렴하는 모델은 다른 팀을 위해 GPU를 조기에 반환할 수 있고, 정체기에 머물러 있는 모델은 추가 워커를 요청할 수 있습니다. 업스트림 커뮤니티에서는 이를 가능하게 하기 위해 TrainJob의 탄력적 PyTorch 지원을 모색하고 있습니다.
- CLI 진행 상황 가시성:
PROGRESS %열이 내장된kubectl get trainjob을 통해 학습 진행 상황을 커맨드라인에서 직접 확인할 수 있게 되면, 운영자는 대시보드나 SDK 없이도 즉각적인 가시성을 확보할 수 있습니다. - 더욱 스마트한 체크포인트 설정: OpenShift AI는 이미 주기적 및 적시(just-in-time) 모델 체크포인트 설정을 지원하고 있지만, ETA 및 진행 상황 데이터를 활용하면 플랫폼이 작업 ETA에 따라 상태를 자동으로 저장하는 등 체크포인트 시점에 대해 더 스마트한 결정을 내릴 수 있습니다. 업스트림 커뮤니티에서는 TrainJob의 내결함성과 복원력을 강화하기 위해 CRIU를 이용한 투명한 GPU 체크포인트 설정을 탐색하고 있습니다.
이러한 영역은 Kubeflow 프로젝트에서 활발히 탐색 중인 단계로, 제품 출시가 확정된 것은 아닙니다. 하지만 이는 진행 상황 추적 기능이 단순한 기능을 넘어 전체 학습 스택의 토대가 되는 데이터 계층을 생성한다는 점에서 왜 중요한지를 잘 보여줍니다.
분산 학습을 위한 진행 상황 추적 기능은 Red Hat OpenShift AI 3.4에서 정식 버전으로 제공됩니다. 자세한 내용은 Red Hat OpenShift AI 도큐멘테이션을 참조하세요. 또는 Red Hat OpenShift AI 60일 체험판을 통해 직접 경험해 보세요.
리소스
적응형 엔터프라이즈: AI 준비성은 곧 위기 대응력
저자 소개
I am a Software Quality Engineer at Red Hat specializing in Kubeflow and distributed AI training. I am focused on making large-scale infrastructure efficient and resilient, and I share insights on distributed model training and fine-tuning on Kubernetes.
유사한 검색 결과
AI 에이전트 프레임워크만으로는 충분하지 않은 이유: 프로덕션 환경에서 누락된 7가지 플랫폼 기능
asago 소개: 오픈소스 AI 안전 및 거버넌스 오케스트레이션
How Red Hat cleared IT debt for scalable AI
Standardizing the AI stack with PyTorch
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
가상화
온프레미스와 클라우드 환경에서 워크로드를 유연하게 운영하기 위한 엔터프라이즈 가상화의 미래