MLOps·LLMOps 운영 가이드: 모델을 만든 뒤 계속 잘 돌리는 법

MLOps는 무엇이고 왜 필요한가

모든 산업용 머신러닝 프로젝트의 목표는 ML 제품을 만들어 빠르게 운영 환경에 올리는 것이다. 하지만 이를 자동화하고 운영하기가 어려워 기대만큼 성과를 내지 못하는 프로젝트가 많다고 MLOps 개요 연구논문는 지적한다. 이 연구는 문헌 조사, 도구 조사, 전문가 인터뷰를 함께 써서 MLOps에 필요한 원칙, 구성 요소, 역할, 아키텍처를 정리하고 정의를 내렸다.

Google Cloud 문서글는 진짜 어려움이 모델을 만드는 데 있지 않다고 말한다. 통합된 ML 시스템을 만들어 운영 환경에서 계속 돌리는 일이 어렵다는 것이다. 실제 시스템에서 ML 코드는 작은 부분이고, 설정·데이터 수집·데이터 검증·자원 관리·서빙 인프라·모니터링 같은 주변 요소가 넓고 복잡하다. CD4ML 글글도 2015년 Google 논문 'Hidden Technical Debt in Machine Learning Systems'를 인용해 같은 점을 짚는다. ml-ops.org글는 MLOps의 목적을 머신러닝 애플리케이션에 쌓이는 '기술 부채'를 피하는 것이라고 정리한다.

일반 소프트웨어와 무엇이 다를까. CD4ML 글글은 ML 애플리케이션이 코드, 모델, 데이터라는 세 축에서 바뀐다고 설명한다. Google Cloud 문서글는 코드에 문제가 없어도 들어오는 데이터의 성격이 계속 변하면 모델 성능이 떨어질 수 있다고 본다. 그래서 데이터의 요약 통계와 모델의 온라인 성능을 추적하다가 기대에서 벗어나면 알림을 보내거나 이전 버전으로 되돌려야(롤백) 한다. 정리하면 MLOps는 DevOps 원칙을 ML 시스템에 가져와, 개발(Dev)과 운영(Ops)을 하나로 묶는 엔지니어링 문화이자 실무다글.

구성 요소: 무엇으로 이뤄지나

먼저 모델이 운영에 올라가기까지의 흐름부터 보자. Google Cloud 문서글는 데이터 추출, 데이터 분석, 데이터 준비(정제, 학습·검증·테스트 세트로 나누기, 피처 엔지니어링), 모델 학습, 모델 평가, 모델 검증(기준선보다 나은지 확인), 모델 서빙, 모델 모니터링 순서로 설명한다. 서빙 방식은 REST API를 갖춘 마이크로서비스로 온라인 예측을 하거나, 엣지·모바일 기기에 모델을 넣거나, 배치 예측 시스템의 일부로 돌리는 세 가지다.

이 흐름을 자동화하려면 도구가 필요하다. ml-ops.org글가 든 구성 요소는 다음과 같다. 소스 관리(코드·데이터·모델 버전 관리), 테스트·빌드 서비스, 배포 서비스, 학습된 모델을 보관하는 모델 레지스트리, 학습과 서빙에서 같은 방식으로 입력을 가공하는 피처 스토어, 모델 이름·파라미터·학습/테스트 데이터·지표 결과를 기록하는 ML 메타데이터 저장소, 실험 단계를 자동으로 이어 주는 파이프라인 오케스트레이터다.

CD4ML 글글도 비슷한 목록을 쓴다. 찾기 쉽고 접근 가능한 데이터, 재현 가능한 모델 학습, 모델 서빙, 테스트와 품질, 실험 추적, 모델 배포, 지속적 배포 오케스트레이션, 모델 모니터링과 관측이다. 버전 관리가 왜 필요한지도 ml-ops.org글가 정리했다. 새 데이터나 새 학습 방법으로 다시 학습할 때, 시간이 지나 성능이 떨어질 때, 공격을 받아 고쳐야 할 때, 이전 버전으로 빠르게 되돌려야 할 때, 규제 기관이나 회사의 감사에 대응해야 할 때 모든 운영 모델 버전에 접근할 수 있어야 한다.

자동화 성숙도: 수동에서 완전 자동까지

Google Cloud 문서글와 ml-ops.org글는 이런 단계를 얼마나 자동화했는지가 ML 프로세스의 성숙도를 정한다고 본다. 성숙할수록 새 데이터나 새 구현으로 모델을 다시 학습하는 속도가 빨라진다. ml-ops.org글는 세 단계로 나눈다. 첫째는 수동 프로세스로, 주피터 노트북 같은 도구로 데이터 준비부터 학습·테스트까지 사람이 직접 한다. 둘째는 ML 파이프라인 자동화로, 새 데이터가 들어오면 재학습이 자동으로 시작되고 데이터·모델 검증 단계도 들어간다. 셋째는 CI/CD 파이프라인 자동화로, 데이터·모델·학습 파이프라인 구성 요소를 자동으로 빌드·테스트·배포한다.

Microsoft의 Azure 문서글는 이를 다섯 단계로 더 잘게 나눈다. 레벨 0 'MLOps 없음'에서는 빌드·배포·학습·테스트가 모두 수동이고 모델 성능을 한곳에서 추적하지 않는다. 레벨 1 'DevOps는 있지만 MLOps는 없음'에서는 애플리케이션 코드의 빌드와 테스트는 자동화됐지만, 결과를 추적하고 재현하기 어렵다. 레벨 2 '학습 자동화'에서는 학습이 자동화되고 학습 성능 추적이 한곳에 모이며 모델 관리가 자리 잡는다. 배포는 아직 수동이지만 쉽다. 레벨 3 '모델 배포 자동화'에서는 배포가 자동이고, 배포된 모델에서 원본 데이터까지 거슬러 추적할 수 있으며, A/B 테스트가 배포 과정에 들어간다. 레벨 4 '완전 자동 운영'에서는 드리프트(데이터·성능이 서서히 어긋나는 현상)나 성능 저하 신호가 재학습을 자동으로 일으킨다.

단계는 기술만의 문제가 아니다. Microsoft 문서글에 따르면 레벨 0에서는 데이터 과학자, 데이터 엔지니어, 소프트웨어 엔지니어가 따로 일하고, 결과물은 손으로 넘기는 모델 파일 하나인 경우가 많다. 레벨 2부터는 데이터 과학자와 데이터 엔지니어가 함께 실험 코드를 반복 실행할 수 있는 스크립트로 바꾼다. 이 문서는 한 조직이 여러 단계의 특징을 동시에 보이는 일이 흔하다며, 단계를 끊어진 계단이 아니라 연속선으로 보라고 권한다.

CI·CD·CT: 머신러닝에서 달라지는 지속 통합

DevOps의 두 기둥은 지속 통합(CI)과 지속 배포(CD)다. Google Cloud 문서글는 ML에서 이 둘의 뜻이 넓어진다고 설명한다. CI는 코드와 구성 요소뿐 아니라 데이터, 데이터 스키마, 모델까지 테스트하고 검증한다. CD는 소프트웨어 패키지 하나를 내보내는 것이 아니라, 학습 파이프라인이라는 시스템을 배포하고 그 파이프라인이 다시 예측 서비스를 자동으로 배포하는 구조다. 여기에 CT(Continuous Training, 지속 학습)가 더해진다. 모델을 자동으로 다시 학습해 서빙하는 일로, ML 시스템에만 있는 특성이다. ml-ops.org글는 CM(Continuous Monitoring, 지속 모니터링)도 덧붙인다. 운영 데이터와 모델 성능 지표를 비즈니스 지표와 연결해 계속 지켜본다는 뜻이다.

테스트도 늘어난다. Google Cloud 문서글는 일반적인 단위 테스트와 통합 테스트에 더해 데이터 검증, 학습된 모델의 품질 평가, 모델 검증이 필요하다고 말한다. 재학습을 일으키는 계기에 대해 ml-ops.org글는 정해진 일정, 메시지, 모니터링 이벤트, 그리고 데이터·학습 코드·애플리케이션 코드의 변경을 든다.

CD4ML 글글은 이 원칙을 '작고 안전한 단위로, 재현 가능하게, 언제든 배포할 수 있는 상태로'라고 요약한다. 소프트웨어가 늘 배포 가능한 상태라면 언제 배포할지는 기술 문제가 아니라 비즈니스 결정이 된다. 이 글은 개발 주기를 몇 주나 몇 달이 아닌 며칠이나 몇 시간 단위로 짧게 가져가고, 운영 중 모델의 동작에서 배워 모델을 고치는 피드백 고리를 만드는 것을 목표로 삼는다.

LLMOps에서 달라지는 점

Microsoft 문서글는 GenAIOps(LLMOps라고도 부른다)를 운영 환경에서 대규모 언어 모델(LLM)을 관리하는 실무와 전략으로 정의한다. Databricks글는 LLMOps를 LLM에 맞게 MLOps를 확장한 것으로 보고, MLOps의 운영 요건 대부분이 그대로 적용된다고 설명한다. Microsoft의 MLOps 성숙도 문서글도 GenAIOps가 MLOps 성숙도 단계를 대체하지 않고 보완하며, 프롬프트 생애주기, 검색 증강(RAG), 출력 안전, 토큰 비용 같은 능력을 더한다고 밝힌다.

무엇이 달라지는지는 Databricks글가 자세히 정리했다. 첫째, 모델을 처음부터 학습하기보다 파운데이션 모델에서 출발해 새 데이터로 파인튜닝하는 경우가 많다. 둘째, GPU 같은 전용 하드웨어가 학습과 배포 모두에 필수가 되고, 추론 비용 때문에 모델 압축이나 Distillation(지식 증류) 기법이 중요해진다. 하이퍼파라미터 튜닝도 정확도뿐 아니라 비용을 줄이는 데 쓰인다. 셋째, 프롬프트 템플릿을 다듬는 프롬프트 엔지니어링이 핵심 작업이 된다. 이는 환각, 프롬프트 인젝션, 민감 정보 유출, 탈옥 위험을 줄이는 데도 쓰인다. 넷째, LangChain이나 LlamaIndex 같은 도구로 여러 LLM 호출을 잇고 벡터 DB나 웹 검색과 연결하는 파이프라인을 만드는 일이 새 LLM을 만드는 일보다 개발의 중심이 된다.

평가와 관측 방식도 바뀐다. 전통 ML은 정확도, AUC, F1처럼 계산이 명확한 지표를 쓰지만, LLM 평가에는 BLEU나 ROUGE처럼 다른 지표가 필요하다글. LLM 과제는 답이 하나로 정해지지 않는 경우가 많아 최종 사용자의 피드백이 평가에 중요하다. 이 피드백을 파이프라인에 넣으면 평가가 쉬워지고 이후 파인튜닝 데이터도 얻는다글. Microsoft 문서글는 근거성(groundedness), 관련성, 유사도 같은 평가 지표와 콘텐츠 안전을 권한다. Databricks글는 모니터링 파이프라인에서 모델 드리프트와 악의적인 사용자 행동 모두에 경보를 걸라고 권한다.

Microsoft 문서글는 GenAIOps 성숙도를 초기(initial), 정의(defined), 관리(managed), 최적화(optimized) 네 단계로 나눈다. 초기 단계에서는 여러 LLM API를 익히고 구조화된 프롬프트 설계와 기본 평가 지표를 시작한다. 정의 단계에서는 CI/CD 통합, 고급 평가 지표, 콘텐츠 안전으로 나아간다. 관리 단계에서는 능동적인 모니터링, 파인튜닝, 버전 관리와 롤백을 강화한다.

단계별 도입 방법

입력 자료들이 공통으로 권하는 방향을 처음 시작하는 순서로 정리하면 다음과 같다. 첫째, 유스케이스 하나부터 시작한다. ml-ops.org글는 한 번에 ML 유스케이스 하나만 다루라고 권하고, 설계 단계에서 필요한 데이터를 살피고 모델의 기능·비기능 요구사항을 정해 아키텍처, 서빙 전략, 테스트 묶음을 미리 설계하라고 말한다.

둘째, 버전 관리와 실험 추적을 깐다. 코드뿐 아니라 데이터와 모델도 버전 관리하고, 어떤 파라미터와 데이터로 어떤 지표가 나왔는지 메타데이터 저장소에 남긴다글글. Microsoft 성숙도글로 보면 레벨 1에서 레벨 2로 가는 준비다. 셋째, 학습 파이프라인을 자동화하고 데이터 검증과 모델 검증을 넣은 뒤, 학습된 모델을 모델 레지스트리에 저장한다글글. 넷째, CI/CD로 파이프라인과 모델 배포를 자동화하고 A/B 테스트를 붙인다(w3의 레벨 3). 다섯째, 운영 모니터링을 연결해 드리프트나 성능 저하 신호가 재학습을 일으키도록 만든다(w3의 레벨 4).

LLM 애플리케이션이라면 Microsoft 문서글의 순서를 따를 수 있다. LLM API와 구조화된 프롬프트 설계에 먼저 익숙해지고, 기본 평가 지표를 도입한 다음, CI/CD 통합과 근거성 같은 고급 평가, 콘텐츠 안전으로 넓혀 간다. Microsoft 문서글는 성숙도 모델을 현재 상태를 평가하고 현실적인 성공 기준을 세우는 데 쓰라고, 완성된 구현의 복잡도를 처음부터 떠안지 말고 점진적으로 역량을 키우라고 권한다.

점검 목록과 흔한 실수·한계

실제로 확인할 항목은 다음과 같다. 코드·데이터·모델이 모두 버전 관리되는가. 실험 결과와 학습 성능이 한곳에 기록되는가. 데이터 검증, 모델 품질 평가, 모델 검증 테스트가 있는가. 새 모델이 기준선보다 나은지 확인한 뒤 배포하는가. 이전 서빙 버전으로 빠르게 되돌릴 수 있는가. 데이터 요약 통계와 온라인 성능을 감시하다가 벗어나면 알림이 오는가. 감사 요청이 오면 운영한 모델과 데이터의 모든 버전에 접근할 수 있는가글글글. LLM 애플리케이션이라면 프롬프트의 버전과 생애주기를 관리하는가, 근거성 같은 지표로 평가하는가, 토큰 비용을 지켜보는가, 드리프트와 악의적 사용에 경보가 걸려 있는가를 더한다글글글.

흔한 실수도 있다. CD4ML 글글은 데이터 엔지니어, 데이터 과학자, ML 엔지니어가 각자 맡은 부분을 기대치 합의 없이 다음 팀에 '벽 너머로 던지는' 조직 구조를 첫 번째 문제로 꼽는다. Microsoft 레벨 0글의 모습처럼 점수 계산 스크립트를 실험 뒤에 손으로 만들고 버전 관리하지 않는 것도 흔하다. 오프라인 테스트 세트 성능만 보고 끝났다고 여기는 것도 위험하다. 데이터가 변하면 운영 중에 성능이 떨어지기 때문이다글.

한계도 알아 둘 필요가 있다. MLOps 개요 연구논문는 MLOps가 여전히 모호한 용어이고 연구자와 실무자에게 주는 의미가 분명하지 않다고 지적한다. Google Cloud 문서글는 주로 예측형 AI 시스템을 다루고, Microsoft 성숙도 문서글도 예측·표 형식·전통 ML을 중심에 둔다. 그래서 LLM에 그대로 옮기기는 어렵다. 도구는 빠르게 바뀐다는 점도 기억해야 한다. Microsoft 문서글는 자사 Prompt flow를 2027년 4월 20일에 종료한다고 공지했다. 특정 도구보다 원칙을 먼저 익히는 편이 안전하다.

더 공부하려면

처음이라면 Google Cloud 문서글부터 읽는 것이 좋다. DevOps와 MLOps의 차이, ML 개발 단계, CI·CD·CT, 성숙도 단계를 한 흐름으로 설명한다. 이어서 ml-ops.org의 원칙 글글에서 구성 요소 표, 지속적 X(CI·CD·CT·CM), 버전 관리 이유를 정리해 두면 실무 용어가 잡힌다.

실제 구현 감각을 얻으려면 CD4ML 글글이 맞다. 판매량 예측이라는 예제 애플리케이션으로 데이터, 학습, 서빙, 실험 추적, 모니터링까지 끝에서 끝까지 이어 보여 준다. 우리 조직이 어디쯤인지 진단하려면 Microsoft의 MLOps 성숙도 문서글에서 단계별 사람·프로세스·기술 표를 보면 된다. 학술적인 정의와 아직 풀리지 않은 과제는 MLOps 개요 연구논문가 정리했다.

LLM 쪽은 Databricks 글글에서 MLOps와 무엇이 다른지 먼저 보고, Microsoft의 GenAIOps 성숙도 문서글에서 단계별로 무엇을 늘려 갈지 확인하는 순서를 권한다.