Skip to main content

서울 공공자전거 데이터로 진행한 Feast·MLflow·KFP 실험

· 44 min read
Jinwoong Kim
Technologist and Cloud Consultant

해당 포스팅은 현재 재직 중인 회사와 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.

읽은 자료: Machine Learning Platform Engineering 4~5장과 스터디 자료. 실습 데이터: UCI Seoul Bike Sharing Demand의 서울 시간별 공공자전거 대여량. 검증 환경: 2026년 10월 31일 Mac M3 Pro의 Rancher Desktop Kubernetes. 이 글의 Job·KFP 상태와 지표는 그날 실행해 남긴 기록을 바탕으로 한다.

책의 소득 분류 데이터를 그대로 따라가는 대신, 서울 공공자전거의 다음 한 시간 대여량을 예측하는 실험으로 4~5장을 다시 읽었다. 이 데이터에는 매 시간의 관측 시각이 있다. 덕분에 Feast가 예측 시각에 맞는 피처 행을 돌려주는지, MLflow에 등록한 모델을 KFP가 다시 찾는지, 무작위 평가 점수가 미래 구간에서도 유지되는지를 한 흐름에서 확인할 수 있다.

본론에 들어가기 전에, 이 글에서 묶는 세 도구를 한 줄로 정리한다. 모두 쿠버네티스 위에서 머신러닝 플랫폼을 이루는 오픈소스 구성요소이고, 각자 맡는 역할이 다르다.

도구한 줄 정의이 실험에서 맡은 일
Feast피처 스토어. 모델이 쓸 입력값(피처)을 한 번 정의해 저장하고, 과거 시점용(오프라인)과 실시간용(온라인)으로 같은 값을 제공한다예측 시각 기준으로 "그때 알 수 있던" 대여량·날씨 피처를 조회
MLflow실험 추적·모델 레지스트리. 어떤 데이터·설정으로 학습한 모델인지 기록하고, 버전을 붙여 등록·배포한다후보 모델의 지표·데이터 해시를 남기고 최종 모델을 버전 1로 등록
KFP(Kubeflow Pipelines)파이프라인 오케스트레이터. 여러 단계(컴포넌트)를 DAG로 묶어 순서대로 실행하고 상태를 관리한다등록된 모델을 재학습 없이 불러와 배치 추론 DAG로 실행

세 도구는 각각 하나의 질문에 대응한다. Feast: 예측 시각에 맞춰 만든 대여량·날씨 피처를 조회할 수 있는가? MLflow: 어떤 데이터와 피처로 선택한 모델인지 다시 찾을 수 있는가? KFP: 등록된 모델을 재학습하지 않고 배치 추론에 다시 쓸 수 있는가? 마지막에는 전체 소스와 제출 코드를 파일별로 본문에 실었다.

쿠버네티스 위에 ML 플랫폼 토대 쌓기 - Docker부터 GitOps·모니터링까지

· 11 min read
Jinwoong Kim
Technologist and Cloud Consultant

해당 포스팅은 현재 재직 중인 회사와 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.

읽은 자료: Machine Learning Platform Engineering(Manning, 2026) 3장 실습 환경: Rancher Desktop의 k3s(v1.36.2+k3s1, arm64), Docker 29.5.3, Helm v4. 모든 명령과 출력은 2026년 10월 25일 로컬에서 직접 확인했다.

지난 글에서 1~2장을 읽으며 "모델보다 비즈니스 문제가 먼저"이고, 머신러닝의 가치는 폐쇄 루프 안에서 나온다는 개념 뼈대를 정리했다. 3장은 그 이론을 실제로 돌릴 수 있는 토대로 옮긴다. 저자들의 표현대로, 여기서 다루는 Docker·쿠버네티스·CI/CD·모니터링은 머신러닝 전용 기술이 아니라 대규모로 신뢰할 수 있는 머신러닝 시스템을 떠받치는 인프라다.

이 글은 책의 흐름을 따라 하나의 데모 앱을 Docker 이미지로 만들고, 쿠버네티스에 올리고, Helm으로 패키징하고, Argo CD로 GitOps 배포를 하고, Prometheus·Grafana로 관측하는 과정을 직접 실행한 기록이다. 앱은 요청 수를 세어 /metrics로 노출하는 작은 Go HTTP 서버다. 모니터링 단계에서 이 커스텀 지표가 Prometheus까지 흘러가는 것을 눈으로 확인하기 위해 골랐다.

모델보다 비즈니스 문제에서 출발하자 - MLOps를 떠받치는 생각의 뼈대

· 13 min read
Jinwoong Kim
Technologist and Cloud Consultant

해당 포스팅은 현재 재직 중인 회사와 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.

읽은 자료: Machine Learning Platform Engineering(Manning, 2026) 1~2장

머신러닝 프로젝트에서 모델을 고르는 일은 생각보다 늦게 찾아온다. 책의 1장에서 던지는 첫 질문은 "어떤 모델을 쓸까"가 아니라 "이 문제를 머신러닝으로 풀어야 하는가"이고, 2장은 배포가 끝이 아니라 시작이라고 말한다. 모델은 완성품이 아니라 목적을 위한 수단이며, 그 목적은 한 번의 배포로 달성되지 않는다. 저자들은 "첫 배포가 끝이었던 머신러닝 프로젝트를 본 적이 없다"고 말한다.

1~2장에서는 도구를 거의 사용하지 않는다. 대신 뒤 장들에서 반복될 사고의 기준을 세운다. 문제를 어떻게 정의하는가, 머신러닝 작업을 왜 하나의 루프로 보아야 하는가, 모델과 코드와 데이터의 리니지(lineage, 계보)를 왜 분리해 추적하는가, MLOps는 DevOps와 어디서 갈라지는가, 그리고 조직의 성숙도를 무엇으로 재는가. 그 다섯 가지 축을 따라 정리했다.

LLM 게이트웨이 세 갈래를 AWS에서 측정하기 - vllm-router · Agent Router · llm-d

· 36 min read
Jinwoong Kim
Technologist and Cloud Consultant

해당 포스팅은 현재 재직 중인 회사와 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.

측정 환경: AWS EC2 g6.12xlarge (NVIDIA L4 24GB × 4, NVLink 없음) · K3s v1.36.4 · vLLM 0.11.0 · Qwen3-0.6B-FP8 × 2 (각 GPU 1장) · vllm-router 0.1.15 · Envoy Gateway v1.9.1 · Agent Router (Envoy AI Gateway) v1.1.0 · GAIE v1.0.1

vLLM 앞에 둘 수 있는 세 구현체를 검토했다. 대상은 vLLM 앞단에 두는 별도 패키지 vllm-router, Envoy 기반 Agent Router(구 Envoy AI Gateway), llm-d였다. 다만 세 구현체를 모두 성능 측정에 넣지는 못했다. Agent Router는 Envoy Gateway와 InferencePool의 호환성 문제로 라우팅 성능을 측정하지 못했고, llm-d는 standalone Envoy 경로에 GAIE EPP를 연결해 approximate 프리픽스 라우팅만 측정했다. 설치와 연동 과정은 8절에 따로 기록했다.

성능 측정에는 K8s Service 대조군을 포함해 다음 다섯 구성을 사용했다.

경로구성파드 선택 방식
K8s Servicekube-proxy연결 단위 분배
vllm-routerround_robin두 파드에 번갈아 분배
vllm-routercache_aware 기본 설정라우터가 추적한 프리픽스 기준
vllm-routercache_aware + 균형 임계값 4096/100프리픽스 우선 선택이 부하 균형 판단에 덮이지 않도록 임계값 조정
llm-d standalone Envoy 경로 + GAIE EPPprefix-cache-scorerEPP가 추정한 프리픽스 캐시 점수 기준

다섯 구성을 같은 GPU와 모델에 올리고 동일한 부하를 걸었다. 처리량 자체보다 "게이트웨이가 달라지면 어떤 차이를 보이는가"를 확인하려는 시험이었다. 그러나 다섯 구성의 처리량과 지연은 사실상 같았다. 이에 워크로드가 도달할 수 있는 상한을 별도로 측정한 뒤 실제 구성과의 차이를 계산했다.

이 워크로드에서 게이트웨이 계층이 활용할 수 있었던 성능 차이는 캐시 히트율 34.7포인트, 처리량 13.6%, p99 TTFT 56%였다. 성능을 측정한 다섯 구성은 이 차이를 실제 성능으로 바꾸지 못했다.

GPU 인식 경로를 AWS G 타입에서 따라가기 - 드라이버부터 K8s DRA까지

· 42 min read
Jinwoong Kim
Technologist and Cloud Consultant

해당 포스팅은 현재 재직 중인 회사와 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.

로컬 PC에서 테스트한 내용은 gasida 님이 작성하신 설치 가이드를 참고했습니다.

비교 기준: 로컬 PC(RTX 4070 Ti SUPER, GeForce) 환경의 같은 절차

측정 환경: AWS EC2 g6.2xlarge (NVIDIA L4 24GB, compute capability 8.9) · 순정 Ubuntu 24.04.4 LTS AMI · NVIDIA Driver 595.84 / CUDA 13.2 · Container Toolkit 1.20.0 · K3s v1.36.4 · device-plugin v0.20.0 · DCGM Exporter 4.6.0 · NFD 0.18.3 · HAMi v2.10.0 · vLLM 0.28.0

GPU가 꽂힌 물리 PC에 Ubuntu를 깔고 드라이버부터 쿠버네티스 GPU 분할까지 올리는 방법을 바탕으로 AWS EC2에서 그대로 진행해 보고 로컬 PC 환경과 어떤 부분에 차이가 있는지 비교하고 기록했다.

Deep Learning AMI를 쓰지 않았다. 앞선 실습들은 드라이버가 미리 깔린 DL용 AMI를 썼는데 이번에는 드라이버 설치 과정 자체가 주요 내용이다. DKMS 빌드, .ko.zst 모듈, /dev/nvidia* 장치 노드가 어떻게 생기는지 보려면 순정 이미지에서 시작해야 한다. 그래서 Canonical 순정 Ubuntu 24.04 AMI로 진행했다.

결론부터 말하자면 계획한 항목이 Utilyze 하나만 빼고 전부 통과했고 로컬 PC와 갈린 지점이 몇 가지 확인되었다. kubeadm과 GPU Operator를 전제로 한 후반부(HAMi, DRA)는 K3s에서 수동 스택으로 돌리려면 손을 봐야 했고, 그 과정에서 나온 것들을 정리했다.