데이터와 모델 파이프라인 연결하기

핵심 메시지

AI 플랫폼은 모델을 한 번 학습시키는 환경이 아니라, 데이터를 준비하고, 모델을 학습하고, 검증한 뒤, 배포 가능한 형태로 넘기는 반복 가능한 흐름이어야 합니다. Kubernetes 위에서 이 흐름을 만들 때 중요한 질문은 "어떤 도구를 쓸 것인가"보다 "각 단계가 다시 실행될 수 있는가"입니다.

좋은 파이프라인은 다음 조건을 만족합니다.

• 데이터 전처리, 학습, 평가, 등록, 배포가 분리되어 있다.

• 각 단계의 입력과 출력 위치가 명확하다.

• 실패한 단계만 다시 실행할 수 있다.

• 모델 파일뿐 아니라 데이터 버전, 코드 버전, 평가 지표가 함께 남는다.

• 배포는 자동화하되, 운영 반영 전 검증 게이트를 둔다.

이 장에서는 Kubernetes에서 데이터와 모델 파이프라인을 연결하는 기본 구조를 정리합니다.

AI 생성 이미지

먼저 파이프라인을 단계로 나눈다

AI 파이프라인은 보통 다음 흐름으로 구성됩니다.

원천 데이터 수집
  → 데이터 전처리
  → 학습 데이터 생성
  → 모델 학습
  → 모델 평가
  → 모델 등록
  → 배포 후보 생성
  → 추론 서비스 반영

처음부터 모든 단계를 자동화할 필요는 없습니다. 하지만 단계의 경계는 초기에 정해두는 편이 좋습니다. 전처리 코드와 학습 코드가 하나의 긴 스크립트에 섞여 있으면, 데이터 오류 하나를 고치기 위해 전체 학습을 다시 돌려야 합니다. GPU 학습 시간이 길거나 비용이 큰 조직에서는 이런 구조가 곧 비용 문제로 이어집니다.

실무에서는 최소한 다음 세 단계는 분리하는 것을 권장합니다.

1. 전처리 Job: 원천 데이터를 읽고 학습 가능한 형태로 변환한다.

2. 학습 Job: 전처리된 데이터를 입력으로 받아 모델을 만든다.

3. 평가 Job: 모델을 검증 데이터로 평가하고 배포 가능 여부를 판단한다.

여기서 Job은 Kubernetes의 완료형 작업 단위입니다. 시작과 끝이 있고, 성공 또는 실패 상태가 남습니다. 전처리, 학습, 평가처럼 결과가 명확한 작업에 적합합니다. 중요한 것은 "한 번 실행되는 스크립트"가 아니라 "기록이 남는 실행 단위"로 다루는 것입니다.

오케스트레이터 선택: Argo, Kubeflow Pipelines, Airflow

파이프라인 단계가 늘어나면 단순한 CronJob만으로는 관리가 어려워집니다. 이때 워크플로 오케스트레이터가 필요합니다. 오케스트레이터는 "어떤 작업을 어떤 순서로 실행할지" 관리하는 도구입니다.

대표적인 선택지는 Argo Workflows, Kubeflow Pipelines, Airflow입니다. 세 도구는 모두 파이프라인을 만들 수 있지만 출발점이 다릅니다.

Argo Workflows는 Kubernetes의 CRD로 동작하며, 각 워크플로 단계를 컨테이너로 실행하고 DAG, 병렬 작업, 아티팩트, 재시도 같은 기능을 제공합니다¹. 이미 Kubernetes 운영 역량이 있고, 전처리·학습·평가 단계를 컨테이너 단위로 명확히 나누고 싶다면 좋은 출발점입니다.

Kubeflow Pipelines는 ML 워크플로에 더 가까운 선택지입니다. 파이프라인 컴포넌트, 아티팩트, 실험 이력, 모델 서빙 도구와의 연결을 함께 고려할 때 유리합니다. 다만 Kubeflow 전체를 운영하려면 설치, 업그레이드, 권한, 멀티테넌시까지 함께 관리해야 하므로 작은 팀에는 부담이 될 수 있습니다.

Airflow는 오래된 데이터 워크플로 생태계와 Python 기반 DAG 작성 방식이 강점입니다. 이미 사내 데이터 파이프라인이 Airflow로 운영되고 있다면 AI 전처리나 배치 추론까지 확장하기 쉽습니다. 반면 GPU 학습 Job, Kubernetes 리소스 쿼터, Pod 단위 격리까지 깊게 활용하려면 KubernetesExecutor나 KubernetesPodOperator 같은 연동 방식을 신중히 설계해야 합니다.

선택 기준은 간단히 정리할 수 있습니다.

• Kubernetes가 운영 표준이고 인프라 팀이 주도한다면 Argo Workflows

• ML 실험, 메타데이터, 모델 서빙까지 한 플랫폼에서 묶고 싶다면 Kubeflow Pipelines

• 기존 데이터 파이프라인과 Python DAG 자산을 재사용해야 한다면 Airflow

도구보다 중요한 것은 단계 간 계약입니다. 어떤 도구를 쓰더라도 입력 데이터 위치, 출력 아티팩트 위치, 성공 조건, 실패 처리 방식이 명확해야 합니다. 도구는 이 계약을 실행해주는 수단이고, 파이프라인의 품질은 결국 계약이 얼마나 분명한지에서 갈립니다.

전처리 Job과 학습 Job을 분리한다

전처리와 학습을 분리하면 재실행 비용을 줄일 수 있습니다. 예를 들어 원천 데이터가 1TB이고 학습에 GPU 8장이 필요하다고 가정해보겠습니다. 전처리 로직에 오류가 있다면 학습을 다시 실행하기 전에 전처리 결과만 검증해야 합니다. 반대로 모델 하이퍼파라미터만 바꿨다면 전처리는 다시 실행할 필요가 없습니다.

기본 패턴은 다음과 같습니다.

preprocess-job
  input: s3://raw/customer-events/2026-07-20/
  output: s3://features/customer-events/date=2026-07-20/version=v3/

train-job
  input: s3://features/customer-events/date=2026-07-20/version=v3/
  output: s3://models/recommendation/run=20260720-001/

evaluate-job
  input_model: s3://models/recommendation/run=20260720-001/
  input_data: s3://features/customer-events/date=2026-07-20/version=v3/
  output: accuracy, latency, drift_check, approval_status

각 단계는 컨테이너 이미지로 고정합니다. 예를 들어 전처리는 feature-builder:1.4.2, 학습은 trainer-pytorch:2.5-gpu, 평가는 model-evaluator:0.9.1처럼 버전을 명시합니다. 이렇게 해야 같은 입력을 넣었을 때 같은 결과를 재현할 가능성이 높아집니다.

또 하나의 원칙은 출력을 덮어쓰지 않는 것입니다. latest 경로에 계속 저장하면 어떤 데이터로 어떤 모델이 만들어졌는지 추적하기 어렵습니다. 날짜, 데이터 버전, 코드 버전, 실행 ID를 포함한 불변 경로를 사용하는 편이 안전합니다.

나쁜 예: s3://models/recommendation/latest/
좋은 예: s3://models/recommendation/model_name=reco/run_id=20260720-001/git_sha=ab12cd/

운영 환경에서는 모든 단계를 자동으로 배포까지 연결하지 않아도 됩니다. 초기에는 전처리, 학습, 평가까지만 자동화하고, 모델 등록과 운영 배포에는 승인 절차를 둘 수 있습니다. 중요한 것은 수동 승인도 파이프라인 기록 안에 남기는 것입니다. "누가, 어떤 평가 결과를 보고, 어떤 모델을 승인했는가"가 남아야 나중에 문제가 생겼을 때 되짚을 수 있습니다.

오브젝트 스토리지와 PersistentVolume을 구분한다

AI 파이프라인에서 스토리지는 크게 두 종류로 나뉩니다.

첫째는 오브젝트 스토리지입니다. S3, GCS, Azure Blob, MinIO 같은 저장소가 여기에 해당합니다. 대용량 데이터셋, 전처리 결과, 모델 파일, 평가 리포트처럼 오래 보관해야 하는 결과물에 적합합니다. 파이프라인 단계가 끝난 뒤에도 남아야 하는 산출물은 오브젝트 스토리지에 두는 것이 일반적입니다.

둘째는 PersistentVolume입니다. Kubernetes Pod에 파일시스템 형태로 붙는 저장 공간입니다. 학습 중 임시 캐시, 체크포인트 저장, 반복적으로 읽고 쓰는 중간 파일처럼 컨테이너가 파일 경로로 접근해야 하는 작업에 유용합니다.

다만 두 저장소를 혼동하면 문제가 생깁니다.

• 오브젝트 스토리지는 대용량 산출물 보관과 단계 간 전달에 적합하다.

• PersistentVolume은 실행 중 파일 접근과 임시 작업 공간에 적합하다.

• 모델의 최종 산출물은 PV에만 두지 말고 오브젝트 스토리지나 모델 레지스트리에 등록해야 한다.

• 학습 Pod가 삭제되어도 필요한 결과는 남아 있어야 한다.

• RWX, RWO 같은 볼륨 접근 모드를 확인해야 한다. 여러 Pod가 동시에 읽고 써야 하는지, 단일 Pod 또는 단일 노드에서만 쓰면 되는지에 따라 스토리지 선택이 달라진다.

실무에서 자주 쓰는 구조는 다음과 같습니다.

원천/전처리 데이터: 오브젝트 스토리지
학습 중 체크포인트: PersistentVolume 또는 오브젝트 스토리지
최종 모델 파일: 오브젝트 스토리지
모델 버전/메타데이터: 모델 레지스트리
추론 서비스 로딩 대상: 모델 레지스트리 URI 또는 승인된 모델 경로

GPU 학습에서는 스토리지 성능도 중요합니다. GPU가 비어 있는데 데이터 로딩이 느려 학습이 지연되면 비싼 자원이 낭비됩니다. 따라서 대용량 학습에서는 데이터셋 크기, 파일 개수, 네트워크 대역폭, 캐시 전략을 함께 확인해야 합니다. 작은 파일이 너무 많으면 오브젝트 스토리지 요청 수와 지연 시간이 병목이 될 수 있고, 반대로 큰 파일만 있으면 병렬 로딩이 어려울 수 있습니다. 데이터 포맷과 로딩 방식도 파이프라인 설계의 일부로 봐야 합니다.

모델 레지스트리는 "모델 파일 목록"이 아니다

모델 파일을 오브젝트 스토리지에 저장했다고 해서 모델 운영 체계가 만들어진 것은 아닙니다. 운영에는 "어떤 모델이 배포 가능한가", "이 모델은 어떤 데이터와 코드로 만들어졌는가", "이전 버전으로 되돌릴 수 있는가"가 필요합니다.

모델 레지스트리는 이 정보를 관리하는 중앙 저장소입니다. MLflow Model Registry 같은 도구는 등록 모델, 모델 버전, 태그, 설명, alias, 실험 실행과의 연결 정보를 관리합니다². 여기서 alias는 champion, candidate, staging처럼 특정 모델 버전을 가리키는 이름으로 사용할 수 있습니다.

기본적으로 모델 레지스트리에 남겨야 할 정보는 다음과 같습니다.

• 모델 이름

• 모델 버전

• 학습 실행 ID

• 학습 데이터 버전

• 코드 버전 또는 Git commit

• 컨테이너 이미지 태그

• 주요 평가 지표

• 승인 상태

• 배포 대상 환경

• 롤백 가능한 이전 버전

예를 들어 추천 모델의 새 버전이 기존 운영 모델보다 정확도는 높지만 응답 시간이 느릴 수 있습니다. 이때 단순히 정확도만 보고 배포하면 추론 서비스의 지연 시간이 악화될 수 있습니다. 모델 레지스트리에는 정확도뿐 아니라 지연 시간, 메모리 사용량, 모델 크기, 검증 데이터 범위까지 함께 남기는 것이 좋습니다.

모델 레지스트리는 배포 자동화와도 연결됩니다. 추론 서비스는 임의의 파일 경로가 아니라 "승인된 모델 버전"을 바라보게 설계할 수 있습니다. 예를 들어 운영 추론 서비스가 recommendation@champion 같은 승인 alias를 로딩하도록 만들면, 새 모델을 운영에 반영할 때 서비스 설정 전체를 바꾸지 않고 alias만 갱신하는 방식도 가능합니다. 이 방식은 배포 자동화에는 편리하지만, alias 변경 자체도 승인·감사 기록에 남겨야 합니다.

실패, 재시도, 알림, 롤백을 기본 설계에 넣는다

파이프라인은 실패합니다. 데이터가 늦게 들어오거나, 스키마가 바뀌거나, GPU 노드가 부족하거나, 학습 중 OOM이 발생할 수 있습니다. 중요한 것은 실패를 없애는 것이 아니라 실패했을 때 어디서 멈췄고 무엇을 다시 실행할지 빠르게 아는 것입니다.

기본 패턴은 다음과 같습니다.

1. 단계별 재시도

네트워크 오류나 일시적인 노드 장애는 재시도로 해결될 수 있습니다. 전처리 데이터 다운로드, 모델 업로드, 평가 리포트 저장 같은 단계에는 제한된 재시도를 설정합니다. 반면 데이터 스키마 오류나 코드 오류는 재시도해도 해결되지 않으므로 빠르게 실패시키는 편이 낫습니다.

2. 실패 알림

모든 실패를 같은 심각도로 다루면 알림 피로가 생깁니다. 운영 배포 직전 평가 실패, 정기 학습 실패, 개발 실험 실패는 서로 다른 채널과 우선순위로 알려야 합니다. 최소한 파이프라인 이름, 실패 단계, 실행 ID, 입력 데이터 버전, 로그 링크는 알림에 포함합니다.

3. 검증 게이트

평가 지표가 기준을 넘지 못하면 모델 등록은 하되 운영 alias는 바꾸지 않습니다. 예를 들어 정확도, F1, P95 지연 시간, 모델 크기, 금지어 테스트, 편향성 점검 같은 기준을 통과해야 staging 또는 champion 후보로 승격할 수 있습니다. 여기서 검증 기준은 모델 종류에 따라 달라져야 합니다. 추천 모델이라면 클릭률이나 전환율 관련 지표가 중요할 수 있고, 문서 요약 모델이라면 품질 평가와 안전성 테스트가 더 중요할 수 있습니다.

4. 배포 롤백

모델 배포는 애플리케이션 배포보다 더 자주 되돌릴 일이 생깁니다. 데이터 분포가 바뀌거나 특정 고객군에서 성능이 낮아질 수 있기 때문입니다. 따라서 이전 모델 버전을 즉시 다시 참조할 수 있어야 합니다. 모델 파일, 컨테이너 이미지, 추론 서버 설정, feature schema가 함께 롤백 가능해야 합니다.

5. 부분 재실행

전처리 결과가 유효하다면 학습부터 다시 실행할 수 있어야 합니다. 학습 결과가 유효하다면 평가만 다시 실행할 수 있어야 합니다. 이를 위해 각 단계의 입력과 출력에는 명확한 버전이 붙어 있어야 합니다. "어제 만든 데이터"나 "방금 학습한 모델"처럼 사람이 기억해야 하는 표현이 아니라, 실행 ID와 경로만 보고도 다시 찾을 수 있어야 합니다.

작은 팀을 위한 시작 구조

처음부터 복잡한 MLOps 플랫폼을 만들 필요는 없습니다. 다음 정도면 PoC 이후 운영 전환을 준비하기에 충분한 출발점이 됩니다.

Argo Workflows 또는 Airflow
  - 전처리 Job
  - 학습 Job
  - 평가 Job
  - 모델 등록 Job

오브젝트 스토리지
  - raw 데이터
  - processed 데이터
  - model artifact
  - evaluation report

모델 레지스트리
  - 모델 버전
  - 평가 지표
  - 승인 상태
  - 배포 alias

Kubernetes
  - CPU 노드풀: 전처리, 평가
  - GPU 노드풀: 학습, GPU 추론
  - ResourceQuota: 팀별 자원 한도
  - Secret: 스토리지와 레지스트리 접근 정보

이 구조의 장점은 나중에 확장하기 쉽다는 점입니다. 전처리 데이터가 커지면 Spark Job을 붙일 수 있고, 학습이 복잡해지면 분산 학습 컨트롤러를 추가할 수 있습니다. 추론이 중요해지면 KServe나 별도 서빙 프레임워크로 연결할 수 있습니다. 하지만 기본 흐름은 같습니다. 입력을 고정하고, 단계를 분리하고, 산출물을 기록하고, 승인된 모델만 배포합니다.

작은 팀일수록 처음부터 많은 도구를 붙이기보다, "실행 기록이 남는가"와 "다시 실행할 수 있는가"를 먼저 확인하는 편이 좋습니다. 도구 수가 적어도 데이터 버전, 코드 버전, 모델 버전, 승인 상태가 남아 있으면 운영 전환의 기반을 만들 수 있습니다.

도입 전 체크리스트

파이프라인 도구를 선택하기 전에 다음 질문에 답해보는 것이 좋습니다.

• 전처리와 학습이 독립적으로 다시 실행될 수 있는가?

• 원천 데이터, 전처리 데이터, 모델 파일의 저장 위치가 분리되어 있는가?

• GPU가 필요한 단계와 CPU로 충분한 단계가 구분되어 있는가?

• 모델 파일과 함께 데이터 버전, 코드 버전, 평가 지표가 남는가?

• 실패한 단계만 재실행할 수 있는가?

• 운영 배포 전 승인 기준이 있는가?

• 새 모델이 실패했을 때 이전 모델로 되돌릴 수 있는가?

• 파이프라인 실패 알림에 실행 ID와 로그 링크가 포함되는가?

AI 플랫폼의 성숙도는 모델 학습 횟수로 결정되지 않습니다. 같은 과정을 안전하게 반복할 수 있는지, 실패했을 때 원인을 찾을 수 있는지, 검증된 모델만 운영으로 보낼 수 있는지가 더 중요합니다. Kubernetes는 이 반복 과정을 컨테이너, Job, 스토리지, 리소스 정책으로 표준화할 수 있는 기반을 제공합니다.

참고

¹Argo Workflows 공식 문서

²MLflow Model Registry 문서