(’26) 머신러닝 플랫폼 엔지니어링 책 Study를 기반으로 AWS 환경에서 MLOps 플랫폼을 구성하기 위한 운영 요구사항을 정리했다. MLOps는 데이터 준비부터 학습·평가·배포·모니터링과 재훈련까지 연결하고, 이를 반복 가능하게 운영하기 위한 실천 체계다. 이 글에서는 AWS가 소개하는 네 가지 원칙과 Level 0·1·2를 살펴보고, 쿠버네티스 기반 구성요소를 Amazon EKS 환경에 적용했을 때의 역할과 연결 관계를 정리한다.
MLOps란 머신러닝에 해당하는 ML (Machine Learning)과 운영에 해당하는 Operations를 줄여서 쓴 Ops가 만난 단어로, 실제 운영 관점에서 볼 때 반복적으로 이루어지는 머신러닝 모델 학습부터 추론, 그리고 관련한 피처 엔지니어링 등 종합적인 부분을 다루는 넓은 범위에 속한다. 스터디에서 기반으로 한 책에서 MLOps 성숙도에 대해 소개하고 있는데, AWS MLOps 성숙도와 함께, 책에서 언급된 쿠버네티스 실습 기반 내용을 Amazon EKS로 시작하는 내용에 대해 글로 정리해본다.
1. 무엇을 운영할 것인가
MLOps 플랫폼 관점에서 중요한 것이 바로 "문제 정의부터 데이터 준비, 학습, 평가, 배포와 모니터링까지 머신러닝 수명주기" 와 "그 과정을 어떻게 반복 가능하고 신뢰할 수 있게 운영하는가"라 볼 수 있겠다.
모델을 학습시켜 원하는 평가 점수를 얻었다고 하더라도, 서비스에 적용하려면 확인해야 할 것이 많다. 학습할 때 사용한 전처리를 추론에서도 동일하게 적용하는지, 어떤 버전의 모델이 배포되어 있는지, 실제 요청을 처리하는 데 필요한 성능을 확보했는지 등을 살펴야 한다. 입력 데이터와 사용 환경이 달라졌을 때 모델을 다시 평가하고 갱신하는 과정도 필요하다.
그래서 MLOps 플랫폼의 운영 대상은 모델이 만들어지고 사용되며 다시 개선되는 전체 과정이라고 볼 수 있겠다.
이 흐름의 시작은 해결할 문제를 정하는 것이다. 간단한 규칙으로 충분한지, 학습에 필요한 데이터를 확보할 수 있는지, 어떤 오류를 줄여야 하는지에 따라 이후 설계가 달라진다. 모델의 평가 기준도 문제 정의와 연결되어야 한다.
예를 들어 이상 거래 탐지에서는 정상 거래를 잘못 차단하는 비용과 이상 거래를 놓치는 비용이 다르다. 추천 시스템에서는 오프라인 평가 점수가 좋아졌더라도 실제 사용자의 반응이 개선되는지 확인해야 한다. 플랫폼은 이러한 판단에 필요한 데이터와 실행 결과를 남길 수 있어야 한다.
배포 이후에는 서비스가 정상 응답하는지와 예측이 유효한지를 함께 살펴야 한다. API가 HTTP 200을 반환하더라도 잘못된 예측을 하고 있을 수 있기 때문이다. 요청 지연시간과 오류율을 관찰하는 것에 더해, 실제 정답을 확보할 수 있는 시점에 예측 품질을 확인하는 절차가 필요하다.
플랫폼이 지원해야 할 연결 관계는 다음 질문으로 정리할 수 있다.
- 어떤 데이터와 코드로 모델을 만들었는가?
- 어떤 설정과 실행 환경을 사용했는가?
- 무엇을 검증한 뒤 배포했는가?
- 현재 서비스하는 모델은 어느 버전인가?
- 문제가 생기면 어떤 버전으로 돌아갈 수 있는가?
이 질문에 실행 기록으로 답할 수 있어야 재현, 장애 분석과 복구가 가능해진다.
2. 반복 가능한 운영을 위한 AWS MLOps의 네 가지 원칙
AWS — MLOps란 무엇인가요?에 따르면, AWS는 MLOps의 핵심 원칙으로 버전 제어, 자동화, Continuous X, 모델 거버넌스를 제시한다. 이 원칙들은 모든 단계에 함께 적용되며, 성숙도가 높아질수록 관리 대상과 자동화 범위가 넓어진다.
2.1. 버전 제어: 모델을 만든 조건을 함께 기록한다
코드의 Git 커밋을 알고 있어도 학습 데이터와 설정이 다르면 같은 결과를 기대하기 어렵다. 하나의 모델 릴리스에는 데이터셋 식별자, 전처리 방식, 학습 설정, 실행 환경, 모델 아티팩트와 평가 결과가 연결되어야 한다. 여기에 추론 컨테이너 이미지와 배포 구성을 연결하면 현재 서비스하는 모델의 출처를 따라갈 수 있다.
| 관리 대상 | 기록할 정보 |
| 코드 | 전처리·학습·평가·추론 코드의 Git 커밋 |
| 데이터 | 원천 위치, 데이터셋 버전, 분할 조건 |
| 설정 | 피처 정의, 하이퍼파라미터, 난수 시드 |
| 실행 환경 | 라이브러리, 컨테이너 이미지, 실행 조건 |
| 모델 | 모델 버전, 아티팩트 위치, 학습 실행 식별자 |
| 평가 | 평가 데이터, 지표, 기준 모델과의 비교 결과 |
| 배포 | 모델 버전, 이미지 버전, 배포 설정과 시점 |
예를 들어 S3 Versioning을 사용하면 개별 객체의 여러 버전을 유지할 수 있다. 학습 데이터가 여러 파일로 구성된다면 사용한 버킷·객체 키·버전 ID를 매니페스트로 묶어 하나의 데이터셋을 식별할 수 있다. 이때, 데이터셋 버전과 학습·검증·테스트 분할은 구분해야 한다. 데이터셋 버전은 수집하거나 정제한 데이터의 변화 이력이고, 분할은 해당 버전 안에서 데이터를 어떤 용도로 사용할지 나눈 결과다. 분할 규칙과 시점까지 기록해야 평가 결과를 비교할 근거가 된다.
이처럼 데이터, 코드, 실행과 모델 사이의 관계를 연결한 것이 리니지다. 리니지가 있으면 모델을 다시 만들거나, 잘못된 데이터가 어떤 모델에 영향을 주었는지 조사하고, 이전 릴리스로 복구할 수 있다. AWS의 ML 운영 지침도 코드·설정·모델·인프라의 버전 관리와 재현 가능한 환경을 함께 강조한다.
2.2. 자동화: 입력과 통과 조건을 명시한다
자동화는 실행할 명령을 순서대로 묶는 것에서 시작할 수 있다. 하지만 운영에 사용하려면 각 단계의 입력과 출력, 성공·실패 조건도 정의해야 한다. 데이터 검증에 실패하면 학습을 중단하고, 평가 기준을 충족하지 못한 모델은 배포 후보로 승격하지 않는 식이다. 실패한 단계와 원인을 확인하고, 필요한 조건을 수정한 뒤 다시 실행할 수 있어야 한다.
프로덕션 승인에 사람의 검토가 필요하다면 평가 결과와 변경 내용을 함께 제공하고 승인 기록을 남긴다. 자동화된 작업과 사람의 판단을 같은 흐름 안에 두면 반복 작업을 줄이면서도 책임 있는 결정을 유지할 수 있다.
실행 환경과 인프라 구성도 코드로 관리하면 개발·검증·운영 환경의 차이를 줄이고 재구성할 수 있다. 파이프라인과 환경의 일관성은 자동화된 결과를 신뢰하기 위한 기반이다.
2.3. Continuous X: 운영 결과를 다음 변경으로 연결한다
AWS는 지속적 활동을 CI (Continuous Integration / 지속적 통합), CD (Continuous Delivery / 지속적 전달), CT (Continuous Training / 지속적 훈련), CM (Continuous Monitoring / 지속적 모니터링)으로 설명한다.
| 활동 | 의미 | MLOps에서 확인할 내용 |
| 지속적 통합, CI | 변경을 통합하고 검증 | 코드 테스트, 데이터 검증, 파이프라인 호환성 |
| 지속적 전달, CD | 검증된 결과를 배포 가능한 상태로 전달 | 모델 패키징, 스테이징 검증, 배포 절차 |
| 지속적 훈련, CT | 새로운 데이터와 조건에 따라 재훈련 | 데이터 적합성, 후보 모델 생성과 비교 |
| 지속적 모니터링, CM | 운영 중 상태와 품질을 관찰 | 서비스 지표, 데이터 변화, 예측 품질, 비즈니스 지표 |
이 활동들은 하나의 피드백 흐름으로 연결된다. 운영 중 입력 데이터가 달라지거나 예측 품질이 떨어지면 원인을 확인하고 재훈련을 검토한다. 새 후보 모델은 평가 기준을 통과한 뒤 배포 절차로 전달한다. 재훈련과 프로덕션 승격에는 서로 다른 통과 조건이 필요하다. 새로운 데이터로 학습했다는 사실만으로 기존 모델을 교체할 근거가 충분해지는 것은 아니다.
2.4. 모델 거버넌스: 책임과 승인 근거를 남긴다
모델 거버넌스는 모델의 책임자, 검토·승인 기준, 접근 권한과 감사 기록을 관리하는 과정이다.
누가 모델의 비즈니스 목표를 정의하는지, 어떤 평가 결과를 근거로 배포를 승인하는지, 민감 데이터와 모델 접근을 어떻게 통제하는지 정해야 한다. 운영 중 문제가 발생했을 때 판단하고 대응할 담당자도 명확해야 한다.
모델의 승인과 배포 이력에 다음 정보가 연결되면 운영 책임을 설명하기 쉬워진다.
- 모델 소유자와 운영 담당자
- 평가 기준과 검증 결과
- 승인자와 승인 시점
- 배포된 모델 및 실행 환경
- 운영 중 발견된 문제와 대응 기록
거버넌스는 데이터 사용부터 모델 검토, 배포, 피드백과 사용 종료까지 수명주기 전체에 적용된다.
3. ML 워크플로 자동화 수준: Level 0·1·2
AWS가 소개하는 Level 0·1·2는 ML 워크플로의 자동화 수준을 설명한다. 이를 이해할 때는 어떤 도구를 설치했는지보다 운영하는 대상이 무엇이며 변경을 어떻게 처리하는지를 살펴보는 것이 도움이 된다.
3.1. Level 0: 사람이 학습한 모델을 전달하는 단계
Level 0에서는 데이터 준비·학습·검증과 단계 간 전환을 사람이 수행하고, 학습한 모델을 엔지니어링 팀에 전달하는 방식이다. EKS를 사용하는 환경에서도 충분히 나타날 수 있는 모습이다. 예를 들어 데이터 사이언티스트가 노트북에서 학습한 모델 파일을 전달하면, 엔지니어가 이를 API에 포함하고 컨테이너 이미지로 만들어 배포할 수 있다.
여기서 쿠버네티스/EKS에 배포하는 과정은 API 배포 측에 복잡한 테스트·배포 체계가 존재할 수 있는 것과 같이 이미 자동화되어 있을 수도 있다. ML 수명주기의 자동화 수준을 판단하려면 그 앞에 있는 데이터 준비와 학습, 평가 과정까지 함께 확인해야 한다. 예를 들어, 새 데이터가 들어왔을 때 어느 코드를 어떤 순서로 실행해야 하는지, 모델과 전처리 코드가 서로 맞는지, 평가 결과가 어떤 모델에 해당하는지를 담당자가 연결하고 있다면 그 부분이 개선 대상이라고 볼 수 있겠다.
Level 0 에서는 우선 다음 질문에 대한 답을 찾아보면서 현재의 운영 방식을 점검하는 것을 권장한다.
지금 서비스 중인 모델을 같은 조건으로 다시 만들려면, 누구에게 무엇을 물어봐야 하는가?
필요한 정보가 특정 담당자의 노트북이나 기억에 모여 있다면, 이를 코드·설정·실행 기록으로 옮기는 것부터 시작할 수 있다.
3.2. Level 1: 학습 파이프라인을 반복 실행하는 단계
Level 1에서는 새로운 데이터에 따라 학습을 반복할 수 있도록 ML 파이프라인을 자동화한다. 운영 환경에 전달하는 중심 대상이 학습된 모델에서 반복 실행할 학습 파이프라인으로 넓어진다. 데이터 준비 완료나 일정 등의 트리거에 따라 정해진 절차가 실행되며, 개발·검증·운영 환경에서 일관된 파이프라인을 사용하고 생성된 모델을 예측 서비스로 전달하는 흐름을 구성한다.
이 단계에서 중요한 것은 한 번의 파이프라인 실행을 설명할 수 있는가다. 어떤 데이터셋을 입력으로 받았고, 어떤 검증을 거쳐, 어떤 설정으로 학습했으며, 어떤 모델과 평가 결과가 생성되었는지를 연결해야 한다.
EKS 기반 구성에서는 컨테이너 기반 ML 워크플로를 정의하고 실행하는 Kubeflow Pipelines 를 검토할 수 있다. 파이프라인을 여러 컴포넌트로 나누면 단계별 입력과 출력, 실행 순서와 상태를 관리할 수 있다.
실험 기록과 모델 관리는 역할을 구분한다.
- MLflow Tracking으로 실행별 데이터·파라미터·지표·아티팩트를 기록하도록 구성한다.
- MLflow Model Registry 로 등록 모델의 버전과 별칭을 관리하고 학습 실행과 연결한다.
이렇게 하면 선택한 모델이 어떤 실험에서 만들어졌는지 추적할 수 있다.
모델은 학습에 사용하지 않은 데이터에서 정해진 기준으로 평가하고, 필요하면 현재 운영 모델과 비교한다. 후보 모델 생성과 프로덕션 승격을 각각 관리하면 재훈련을 반복하면서도 배포 판단의 근거를 유지할 수 있다.
3.3. Level 2: 학습 파이프라인 자체를 CI/CD로 관리하는 단계
Level 2에서는 파이프라인 소스 작성, 컴포넌트의 빌드·테스트·배포, 예측 서비스 운영과 모니터링을 연결한다. AWS는 여러 ML 파이프라인을 조율하는 오케스트레이터와 여러 모델을 추적하는 모델 레지스트리도 이 수준의 구성요소로 설명한다.
Level 1과의 차이는 모델을 만드는 방법이 바뀔 때 드러난다. 기존 파이프라인에 새로운 데이터셋을 넣는 경우에는 이미 정의한 절차를 반복 실행한다. 피처 계산 로직을 수정하거나 학습 알고리즘을 교체하거나 평가 단계를 추가하면 파이프라인 자체가 변경된다. 이 변경에도 테스트와 릴리스 절차가 필요하다.
Level 2의 흐름은 다음 세 부분으로 나눌 수 있다.
- 실험을 바탕으로 파이프라인 소스를 작성하고 변경한다.
- 컴포넌트와 파이프라인을 빌드·테스트하고 실행 환경에 배포한다.
- 파이프라인 실행으로 생성한 모델을 검증·배포하고 운영 지표를 수집한다.
EKS 기반에서는 학습 오케스트레이션과 서빙 배포의 역할을 구분한다. 예를 들어 CI에서 Kubeflow Pipelines의 컴포넌트와 파이프라인 정의를 검증한 뒤 등록하는 흐름을 구성할 수 있다. 서빙 리소스는 Git에 기록한 배포 설정을 Argo CD가 Kubernetes에 동기화하도록 구성할 수 있다.
두 흐름은 학습 실행 식별자, 모델 버전, 컨테이너 이미지 버전과 배포 기록으로 연결한다. 그래야 운영 중인 예측 서비스에서 출발해 모델의 생성 과정까지 추적할 수 있다.
세 수준을 운영 대상의 변화로 정리하면 다음과 같다. 오케스트레이터나 모델 레지스트리를 Level 1에서 먼저 도입할 수도 있다. 도구의 유무만으로 수준을 판정하기보다, 데이터와 파이프라인의 변경을 어떤 절차로 검증하고 운영에 반영하는지 확인해야 한다.
| 수준 | 운영의 중심 | 확인할 질문 |
| Level 0 | 학습된 모델의 수동 전달 | 해당 모델을 만든 조건을 다시 찾을 수 있는가? |
| Level 1 | 반복 실행하는 학습 파이프라인 | 새로운 데이터로 검증된 절차를 실행할 수 있는가? |
| Level 2 | 학습 파이프라인 자체의 CI/CD | 모델을 만드는 방법의 변경도 검증하고 전달할 수 있는가? |
4. 조직과 플랫폼의 확장도 함께 고려하기
여러 팀이 같은 플랫폼을 사용하기 시작하면 자동화 외에도 공통으로 풀어야 할 문제가 늘어난다. 팀별 데이터와 실행 권한은 어떻게 나눌지, 새로운 팀에 환경을 어떻게 제공할지, 각 모델의 운영 책임을 어떻게 유지할지 정해야 한다.
이 관점에서 함께 볼 수 있는 자료가 2022년 AWS 블로그에 소개된 「MLOps foundation roadmap for enterprises with Amazon SageMaker」이다. 이 자료에서는 사람·운영·기술을 포함한 기반 구축을 Initial, Repeatable, Reliable, Scalable 네 단계로 설명한다.
| 단계 | 중심 목표 |
| Initial | 안전한 실험 환경에서 ML의 비즈니스 가능성 검증 |
| Repeatable | 학습 파이프라인, 저장소와 모델 관리 방식의 표준화 |
| Reliable | 스테이징 검증, 승인, 운영 배포·모니터링·롤백 |
| Scalable | 공통 템플릿과 환경 제공을 통한 여러 팀으로의 확장 |
두 체계는 서로 다른 관점을 제공한다.
- Level 0·1·2는 ML 워크플로의 자동화 깊이를 설명한다.
- 네 단계 로드맵은 조직과 플랫폼의 운영 역량을 확장하는 과정을 설명한다.
따라서 두 체계를 일대일로 대응시키기보다 함께 참고하는 편이 적절하다.
EKS 기반 플랫폼에 적용하면, 팀마다 환경을 수동으로 만들어 주던 방식에서 공통 템플릿과 표준 배포 절차를 제공하는 방향을 생각할 수 있다. 플랫폼 팀은 공통 실행 환경, 배포와 관측 도구를 제공하고, 각 도메인 팀은 데이터·모델·평가 기준과 운영 책임을 유지하도록 역할을 나눌 수 있다. 공통화할 대상과 팀별로 결정할 대상을 함께 정리해야 플랫폼을 확장하면서도 모델별 요구사항을 반영할 수 있다.
5. Amazon EKS에 어떤 역할을 맡길 것인가
Amazon EKS는 AWS가 Kubernetes 컨트롤 플레인을 관리하는 서비스다. EKS Auto Mode를 사용하면 컴퓨팅·네트워킹·스토리지 등 데이터 플레인 인프라의 프로비저닝, 확장과 유지관리도 AWS에 맡길 수 있다. 이 기반 위에서 학습 작업과 추론 서비스를 실행하고, 데이터 저장·실험 추적·모델 관리·배포 도구를 연결한다 (참고: "What is Amazon EKS? [docs.aws.amazon.com]").
이 기반 위에 학습 워크로드와 추론 서비스를 배치하고, 데이터 저장, 실험 추적, 모델 관리와 배포 도구를 연결하는 구성을
생각할 수 있다. 앞서 정리한 운영 요구사항을 기준으로 역할을 나누면 다음과 같다.
| 운영 영역 | 구성요소 예시 | 담당 역할 |
| 워크로드 실행 | Amazon EKS | 컨테이너 기반 학습 작업과 추론 서비스 실행 |
| 데이터·아티팩트 저장 | Amazon S3 | 데이터셋, 모델 아티팩트와 평가 결과 보관 |
| 컨테이너 이미지 관리 | Amazon ECR | 학습·추론 애플리케이션 이미지 보관 |
| 학습 오케스트레이션 | Kubeflow Pipelines | 학습·평가 단계의 실행과 의존성 관리 |
| 실험 추적 | MLflow Tracking | 실행별 입력·설정·지표·아티팩트 기록 |
| 모델 버전 관리 | MLflow Model Registry | 등록 모델과 버전·별칭 관리 |
| 변경 검증 | Git 저장소와 CI | 코드·컴포넌트 테스트, 이미지 빌드 |
| 서빙 배포 | Helm·Argo CD | 배포 설정 관리와 Kubernetes 상태 동기화 |
| 관측과 대응 | Prometheus·Grafana 등 | 요청·자원 메트릭 수집, 조회·시각화와 규칙 기반 경보 |
이는 역할을 이해하기 위한 구성 예시로, 실제 구현에서는 요구사항과 팀의 운영 역량에 따라 관리형 서비스를 활용할 범위와 직접 운영할 컴포넌트를 선택할 필요가 있다. 특히, 데이터 드리프트와 예측 품질을 관찰하려면 애플리케이션이나 별도 평가 과정에서 관련 지표를 생성하고, 이를 모니터링·경보 체계에 연결할 필요가 있겠다.
어떤 데이터를 학습에 사용할지, 모델이 어떤 평가를 통과해야 하는지, 누가 프로덕션 배포를 승인할지는 플랫폼의 운영 절차로 정의한다.
컨테이너 이미지 버전과 모델 버전도 구분해야 한다. 추론 이미지 안에 모델을 포함할 수도 있고, 실행 시 S3 등에서 모델을 가져올 수도 있다. 어느 방식을 선택하든 배포 기록에는 사용한 이미지와 모델 버전이 함께 식별되어야 한다.
6. MLOps에서 LLMOps로 확장하면 무엇이 달라지는가
생성형 AI와 RAG 시스템에서도 버전 제어, 자동화, 지속적 개선과 거버넌스는 중요하다. 관리해야 할 대상에는 프롬프트, 검색 데이터, 평가 세트와 모델 제공자의 설정 등이 추가된다. AWS도 생성형 AI 운영에서 이러한 자산과 평가·배포·모니터링의 연결을 강조한다.
| 운영 영역 | LLMOps에서 추가로 관리할 대상 |
| 버전 관리 | 프롬프트, 기반 모델, 추론 설정 |
| 데이터 | RAG 문서, 청크, 임베딩, 벡터 인덱스 |
| 평가 | 답변의 정확성·관련성·근거 일치 |
| 관측 | 토큰 사용량, 비용, 응답 지연시간 |
| 거버넌스 | 민감 정보, 가드레일, 프롬프트 공격 대응 |
운영 중인 응답이 어떤 모델과 프롬프트, 검색 문서에서 만들어졌는지 추적할 수 있어야 한다. 변경 전후의 품질을 비교할 평가 세트와 문제가 있는 구성을 되돌릴 절차도 필요하다.
7. 마치며
MLOps 플랫폼을 구성할 때는 모델이 만들어지고 사용되는 과정을 어디까지 연결할 것인지부터 정리해야 한다.
AWS의 Level 0·1·2는 운영의 중심이 학습된 모델에서 반복 실행하는 학습 파이프라인으로, 다시 파이프라인 자체의 CI/CD와 운영으로 확장되는 흐름을 이해하는 데 도움이 된다. 기업 도입 로드맵은 이러한 역량을 여러 팀과 사용 사례로 확장할 때 필요한 운영 구조를 함께 생각하게 한다.
쿠버네티스는 학습·추론 워크로드를 실행하고 관리하는 기반을 제공한다. 여기에 데이터·코드·모델의 버전, 평가와 승인, 배포와 모니터링 기록을 연결하면 재현하고 복구할 수 있는 플랫폼으로 발전시킬 수 있다. 본 글에서는 이러한 운영 요구사항을 Amazon EKS 기반 구성요소의 역할과 연결 관계로 정리했다.
MLOps/LLMOps 플랫폼을 구성하면서 계속 생각해볼만한 질문은 다음과 같다.
지금 서비스하는 모델을 어떤 근거로 배포했는지 설명할 수 있는가? 그리고 같은 과정을 다시 실행하고 복구할 수 있는가?
각 구성요소를 연결하고 실행 기록을 남기는 과정에서 이 질문에 답할 수 있는 플랫폼을 구성하는 것이 중요하다고 할 수 있겠다.
