AI 플랫폼 GPU 도입부터 Kubeflow까지 도입기

AI 플랫폼 GPU 도입부터 Kubeflow까지 도입기

요약: 카카오페이는 기존 AI 시스템의 반복적인 수작업과 비효율 문제를 해결하기 위해 AI 플랫폼 구축을 결정했어요. 표준화, 확장성, 통합을 핵심 가치로 삼아 Kubeflow 기반 플랫폼을 도입하고, 고성능 GPU(H200, MIG) 및 하이브리드 클러스터 등 기술적 난제를 극복하며 안정적인 AI 개발 환경을 완성했어요. 이 과정은 금융 환경의 제약 속에서 카카오페이에 맞는 최적의 기술적 해답을 찾아나가는 여정이었어요.

💡 리뷰어 한줄평

wayne.cai AI 모델이 어떻게 작동하는지와 어떤 어려움을 겪으며 환경을 구축했는지에 대한 고민과 답을 볼 수 있는 글이라고 생각됩니다.

시작하며

안녕하세요. 카카오페이 DevOps팀의 스텔라입니다. 이번 글에서는 if(kakao)25에서 발표한 “AI 플랫폼 하드웨어부터 코드까지”에서 소개한 내용을 공유드리고자 합니다. 왜 저희는 플랫폼을 만들어야만 했는지 그 시작점부터, 수많은 현실의 벽을 넘어 어떻게 플랫폼을 완성했는지, 그리고 이 여정이 앞으로 어디를 향하고 있는지 그 전체적인 내용을 공유해 드리고자 합니다. LLM 서비스를 처음 시작하는 분들이나 도입을 고민하는 분들에게 도움이 되길 바랍니다.

먼저, AI 플랫폼의 부재로 우리가 마주했던 문제들에 대해서 이야기해보도록 하겠습니다.


AI 플랫폼의 부재: 우리가 마주했던 문제들

저희가 AI 플랫폼을 만들어야만 했던 이유는 명확했습니다.

먼저, 내부 개발자들이 AI 기술을 손쉽게 활용하고, 카카오페이의 다양한 서비스에 AI를 빠르게 적용할 수 있는 환경이 부재했습니다. 현실은 반복적인 수작업에 의존하는 레거시 시스템으로 개발 속도가 저해되고 서비스 안정성을 위협하는 기술적 부채로 작용했습니다.

그럼 기존에 저희가 사용하던 레거시 시스템을 살펴보도록 하겠습니다.

레거시 시스템 구조
레거시 시스템 구조

이 다이어그램은 저희가 과거에 사용했던 레거시 모델 서빙 프로세스입니다. 데이터 사이언티스트가 모델 학습(Training)을 완료하고, 그 결과를 MLflow 모델 레지스트리에 등록하는 것으로 과정이 시작됩니다. 그러면 ML 엔지니어가 등록된 모델 정보를 확인하고, 서비스에 필요한 파일들을 포함하여 Container 이미지로 직접 빌드합니다. 빌드된 이미지를 실제 운영 GPU 서버에 배포하여 Container로 서비스를 시작하는 흐름이며, 각 단계마다 사람의 개입이 필수적인 구조였습니다. 이러한 반복되는 수작업의 고리를 끊고 내부 개발자와 카카오페이 AI 서비스에서 쉽게 활용 가능한 새로운 AI 플랫폼을 구축하고자 했습니다.


우리의 고민에 답하다: Kubeflow

저희의 고민은 ‘플랫폼을 왜 만들어야 하는가’에서 ‘어떤 플랫폼을 만들어야 하는가’ 로 자연스럽게 넘어가게 되었습니다. 그래서 저희는 아래 도구들을 검토하게 되었습니다.

AI 플랫폼 도구 검토
AI 플랫폼 도구 검토

저희는 대부분의 서비스가 IDC를 사용하고 있어 온프레미스 환경에 직접 AI 플랫폼을 구축하기로 결정하고 ‘어떤 아키텍처의 플랫폼을 선택할 것인가?’ 하는 고민을 하게 되었고, 세 가지 선택지를 검토했습니다. Airflow나 MLflow 같은 솔루션들은 저희가 중요하게 생각했던 확장성과 장기적인 운영 안정성 측면에서 한계가 있었습니다.

결국 ‘쿠버네티스 기반의 Kubeflow’ 를 선택하게 되었습니다. 카카오페이 시스템 대부분이 이미 쿠버네티스 기반이었기 때문에, 운영의 일관성을 확보할 수 있는 가장 자연스러운 선택이었습니다.

초기 학습 곡선과 비용이라는 단점에도 불구하고, 표준화된 기술이 주는 유연함, 압도적인 확장성, 그리고 강력한 생태계를 기반으로 한 시스템 통합 능력이라는 장점이 훨씬 크다고 판단했습니다.

지금부터 저희가 Kubeflow를 선택한 이유를 하나씩 설명해 드리겠습니다.


표준화

누가 하든, 어디서 하든 동일하게

과거에는 실행하는 사람의 환경이 달라 문제가 잦았지만, Kubeflow는 ‘파이프라인’과 ‘컨테이너’ 기술로 이 문제를 해결합니다. 파이프라인은 누가 실행하든 동일한 순서로 작업을 보장하고, 컨테이너는 어디서 실행하든 동일한 환경을 보장합니다.


확장성

필요한 만큼만, 낭비 없이 알뜰하게

저희의 목표는 “필요한 만큼만 자원을 사용하고 낭비 없이 운영하는 것” 이었습니다. 과거에는 GPU를 고정적으로 할당하여 사용하지 않을 때도 자원이 낭비되고, 사용을 위해 기다리는 ‘자원의 전쟁’이 있었습니다. 하지만 Kubeflow는 쿠버네티스 위에서 동작하며 이 문제를 해결합니다. 학습 시에는 필요한 만큼만 자원을 동적으로 할당하고 즉시 반납하며, 서빙 시에는 트래픽에 따라 자동으로 확장(Autoscaling) 하여 낭비 없는 운영을 가능하게 합니다.


통합

AI 개발에 필요한 모든 것, 올인원

과거에는 여러 도구들을 파편적으로 사용하며 일관된 경험을 제공하기 어려웠지만, Kubeflow는 AI 개발의 전체 과정을 하나의 플랫폼 안에 유기적으로 통합하여 이 문제를 해결했습니다. 결론적으로, Kubeflow의 ‘통합’된 환경 덕분에 개발자들은 더 이상 인프라가 아닌 ‘AI 모델’ 자체에만 집중할 수 있게 되었고, 저희는 표준화, 확장성, 그리고 통합이라는 세 가지 기준으로 Kubeflow라는 최적의 답을 찾을 수 있었습니다.


새로운 AI 플랫폼 아키텍처

그럼 저희가 실제로 구현한 AI 플랫폼 아키텍처를 소개해 드리겠습니다.

AI 플랫폼 아키텍처
AI 플랫폼 아키텍처

저희 AI 플랫폼은 두 종류의 사용자를 위해 설계되었습니다. 모델을 직접 만드는 ‘AI 전문가’ 와 모델을 서비스에 적용하는 ‘서비스 개발자’ 입니다.

AI 전문가인 데이터 사이언티스트는 Kubeflow 파이프라인을 통해 학습부터 모델 등록까지의 반복적인 작업을 자동화할 수 있게 되었습니다. ML 엔지니어 또한 더 이상 서버에 직접 접속할 필요 없이, 등록된 모델을 코드로 간편하고 안정적으로 배포하며 모델 서빙 자체에만 집중할 수 있게 되었습니다.

반면, 서비스 개발자는 복잡한 Kubeflow 대신, 저희가 자체 개발한 ‘웹 콘솔’ 을 통해 원하는 모델을 간편하게 호출하고 배포할 수 있습니다. 결론적으로 저희는 AI 전문가의 생산성과 서비스 개발자의 사용 편의성을 모두 만족시키는 아키텍처를 구축하게 되었습니다.


그 답을 현실로 만드는 여정

하지만, 이론적으로 답을 찾는 것과 그것을 저희의 현실에 성공적으로 안착시키는 것은 전혀 다른 차원의 문제였습니다. 지금부터 저희가 그 이상적인 답을 현실로 만들어가며 부딪혔던, ‘여정’에 대해서 들려드리고자 합니다. 그 첫걸음은 바로 비용과 성능이라는 두 마리 토끼를 잡기 위한 클러스터 설계에서 시작되었습니다.

저희는 고성능 AI 모델 학습을 위해 H200 GPU를 도입했습니다. 하지만 이런 고성능 장비는 CPU가 데이터 처리 속도를 따라가지 못해 오히려 병목이 되는 문제가 발생합니다. 이를 해결하고, 특히 대규모 분산 학습의 효율을 극대화하기 위해 CPU를 거치지 않고 GPU끼리 직접 통신하는 RDMA 기술과 Infiniband 네트워크 도입을 결정했습니다. 하지만 저희의 가장 큰 고민은 “어떻게 이 특수한 Infiniband 네트워크를 기존의 쿠버네티스 환경에 통합할 것인가?”였습니다.


하이브리드 클러스터

Infiniband 네트워크 통합 아키텍처
Infiniband 네트워크 통합 아키텍처

저희의 해결책은 하이브리드 클러스터를 사용하는 것이었습니다.

일반 워커 노드들은 이더넷 네트워크를 통해 연결되어 있으며, kubeflow를 배포하거나 모니터링 pod를 배포하는 등의 일반적인 작업을 처리합니다.

GPU 노드들은 인피니밴드 네트워크를 통해 연결되어 있으며, 특히 RDMA와 GPUDirect 기술을 활용하여 CPU를 거치지 않고 GPU끼리 직접 데이터를 교환함으로써, 병렬 처리 성능을 극대화하고 학습 시간의 병목을 제거하고 비용 효율을 높였습니다.


MIG 적용

저희 또 다른 고민은 바로 가장 값비싼 자원인 ‘GPU의 투자 효율(ROI)을 어떻게 극대화할 것인가’ 하는 문제였습니다.

MIG
MIG

MIG(Multi-Instance GPU)는 하나의 물리적 GPU를 격리된 여러 개의 작은 GPU 인스턴스로 분할하여, 여러 워크로드가 동시에 GPU 자원을 나눠 쓸 수 있게 함으로써 활용률을 극대화하는 기술입니다.

왼쪽 그림은 MIG를 적용하기 전의 상황입니다. 왼쪽 그림처럼, 쿠버네티스 환경에서는 정책상 하나의 물리 GPU는 오직 하나의 워크로드, 즉 파드(Pod)만이 점유할 수 있었습니다.

이러한 비효율을 해결하기 위해 도입한 기술이 바로 NVIDIA의 ‘MIG’ 입니다.

오른쪽 그림을 보시면, MIG는 하나의 물리 GPU를 마치 여러 개의 작은 가상 GPU가 있는 것처럼 논리적으로 분할해 줍니다. 각각의 분할된 인스턴스는 하드웨어 레벨에서 완벽하게 격리되어, 서로의 성능에 영향을 주지 않습니다.

그 결과, 과거에는 단 하나의 작업만 실행할 수 있었던 GPU에서, 이제는 여러 개의 워크로드(Pod)를 동시에, 그리고 안정적으로 실행할 수 있게 되었습니다.


더 나은 답을 찾아서

하지만 저희의 여정은 여기서 끝나지 않았습니다. 단단한 토대가 만들어진 이후, 저희의 질문은 ‘어떻게 하면 더 효율적으로 사용할 수 있을까?’ 라는 새로운 단계로 접어들었습니다. 마지막으로 바로 그 ‘더 나은 답’을 찾기 위한 이야기 해보고자 합니다.


비용 최적화와 성능 보장 사이의 균형

저희는 KServe와 Knative를 이용해 자원 효율을 극대화하고 비용을 최적화하는 것을 목표로 했습니다. knative란 쿠버네티스를 서버리스 플랫폼으로 이용할 수 있는 도구이며, 필요한 순간에만 동적으로 자원을 할당하고 회수하는 서버리스의 핵심적인 역할을 수행합니다.

특히 Knative의 ‘Scale to Zero’ 기능은 사용하지 않는 모델의 자원을 0으로 줄여주어 비용 측면에서 매우 매력적이었습니다. 하지만 이 기능을 사용하면, 유휴 상태의 모델에 첫 요청이 들어왔을 때 Pod를 다시 시작하는 ‘콜드 스타트(Cold Start)’ 가 발생한다는 문제가 있었습니다.

저희가 테스트해 본 결과, 모델의 크기에 따라 이 콜드 스타트 시간이 최대 6분 이상 소요될 수 있음을 확인했습니다. 6분이라는 응답 지연은 저희 서비스에서는 결코 허용할 수 없는 시간이었습니다.

Knative와 Kserve
Knative와 Kserve

따라서 저희는 비용 효율을 일부 포기하더라도, 서비스 응답 속도를 보장하는 것이 더 중요하다고 판단했습니다. 그래서 저희는 Pod가 0으로 줄어들지 않도록 최소 복제본(minReplicas)을 1로 유지하는 정책을 최종적으로 결정했습니다. 이는 비용 최적화와 서비스 안정성 사이의 현실적인 트레이드오프(trade-off)를 고려한 저희의 전략적인 선택이었습니다.


GPU 자원 최적화 전략

이렇게 ‘최소 1개의 Pod를 항상 유지한다’는 배포 정책을 결정하고 나니, 저희에게는 또 다른 숙제가 생겼습니다. “그렇다면, 항상 켜져 있는 그 GPU 자원을 어떻게 하면 가장 알뜰하게 사용할 수 있을까?” 하는 문제였죠. 단순히 Pod를 띄워놓는 것을 넘어, 그 Pod가 사용하는 GPU를 워크로드에 맞게 최적으로 분할하는 것이 중요해졌습니다. 그래서 저희는 최적의 답을 찾기 위해, ‘사용처(학습/추론)’, ‘사용 모델’, ‘모델 크기’ 라는 세 가지 기준을 만들었습니다.

사용처: 실시간 추론에는 동시 처리를 위해 작게 분할된 여러 인스턴스를, 공용 모델이나 테스트에는 더 큰 인스턴스를 유연하게 할당합니다.

사용 모델: GPT나 Gemma와 같이, 각 모델의 아키텍처 특성을 분석하여 가장 효율적인 MIG 인스턴스를 매칭합니다.

모델 크기: 모델의 메모리 요구량을 정확히 계산하여, 낭비 없이 가장 딱 맞는 크기의 GPU 조각을 할당하는 것을 원칙으로 합니다.

이 기준들 덕분에 저희는 더 이상 감이 아닌, 데이터에 기반하여 각 워크로드에 최적의 GPU 자원을 할당하는 의사결정 체계를 구축할 수 있었습니다.


모니터링

저희가 모니터링을 위해 주요하게 보는 지표는 다음과 같습니다.

그라파나 대시보드주요 지표 매트릭

먼저 ‘GPU 전체 자원 및 할당량’GPU 유휴 자원(Idle Resource)’ 입니다. 지표를 통해 저희는 현재 플랫폼에서 사용 중인 GPU 자원이 얼마나 되는지, ‘낭비’가 어디서 발생하고 있는지를 명확하게 보여줍니다.

그리고 GPU 리소스 사용량 현황입니다. 각 모델이나 사용자가 실제로 GPU를 얼마나 효율적으로 사용하고 있는지 정량적으로 파악할 수 있습니다. 저희는 이 데이터를 기반으로 GPU 분할 시나리오를 지속적으로 개선하고, 한정된 자원의 효율을 극대화하며 저희의 AI 플랫폼을 더욱 발전시켜 나가고 있습니다.


마치며

저희는 과거 반복적인 수작업과 비효율이라는 문제에 직면했고, 이러한 문제를 해결하기 위해 AI 플랫폼을 구축하기로 결정했습니다. 저희는 ‘표준화, 확장성, 통합’ 이라는 세 가지 핵심 가치를 기준으로 Kubeflow를 선택했고, 이를 통해 AI 개발을 위한 튼튼한 기반을 마련했습니다. 물론 그 과정은 순탄치만은 않았습니다. GPU 비용과 같은 현실의 벽에 부딪혔지만, 저희는 하나씩 문제를 해결하며 저희만의 플랫폼을 완성해 나갔습니다.

“AI 플랫폼 구축은 단순히 도구를 도입하는 것이 아니라, 저희가 마주한 금융 환경의 제약과 수많은 기술적 난제 속에서, 우리 환경에 맞는 최적의 답을 찾아가는 ‘과정’ 그 자체였습니다.”

앞으로도 저희는 끊임없이 더 나은 답을 찾아 나아갈 것입니다.

AI플랫폼 구축을 위해 함께 해주신 모든 분들께 감사드립니다.

stella.yu
stella.yu

카카오페이에서 DevOps 업무를 담당하고 있는 stella입니다.