MLOps: 프로덕션에서 데이터, 모델, 거버넌스를 하나로 연결하는 방법

많은 팀은 MLOps 논의를 모델 중심으로 시작합니다. 어떤 방식으로 학습했는지, 어디에 배포할지, 재학습 주기를 얼마나 짧게 가져갈 수 있는지를 우선 검토합니다. 하지만 프로덕션 환경에서 모델은 더 큰 ML 운영 시스템을 구성하는 하나의 오브젝트일 뿐입니다. 모델에 입력 데이터를 제공한 테이블, 모델의 입력 신호를 정의한 피처 정의, 3일 늦게 제공된 레이블, 업스트림에서 변경된 스키마, 출력 결과에 대한 사용 권한을 제어하는 액세스 정책까지 모두 운영상 중요한 의존성입니다.

그래서 MLOps를 단순히 “모델을 위한 DevOps”로 축소해서는 안 됩니다. MLOps는 DevOps의 자동화, CI/CD, 릴리스 규율을 차용하지만 일반적인 소프트웨어 팀이 흔히 마주하지 않는 모델 고유의 문제도 고려해야 합니다. 데이터 드리프트, 개념 드리프트, 피처 재사용, 학습-서빙 스큐, 모델 설명 가능성, 모델 계보, 새로운 프로덕션 결과에 기반한 재학습이 여기에 해당합니다. MLOps는 이러한 의존성을 연결하여 비즈니스, 데이터, 운영 환경이 변해도 모델이 안정성을 유지하는 애플리케이션으로 이동할 수 있도록 합니다.

MLOps는 프로덕션에서 ML 모델의 배포, 모니터링, 유지 보수를 자동화하고 표준화하는 실천 방식의 집합입니다. 이러한 실천 방식은 팀이 머신러닝 전체 수명 주기를 관리하는 데 도움이 됩니다.

소프트웨어와 마찬가지로 모델도 코드에 의존합니다. 하지만 모델은 학습 데이터, 피처, 레이블, 매개변수, 평가 지표, 런타임 의존성, 서빙 인프라, 그리고 예측이 사용되는 환경에서 발생하는 피드백에도 의존합니다. MLOps는 팀이 이러한 자산을 버전 관리하고 테스트하며, 승인 게이트를 거쳐 일관되게 배포하고, 여전히 기대한 대로 동작하는지 모니터링할 수 있는 방법을 제공합니다.

리드에 점수를 매기고, 수요를 예측하고, 지원 티켓을 라우팅하거나 의심스러운 거래를 감지하는 모델은 더 이상 단순한 데이터 사이언스 자산이 아닙니다. 이러한 모델은 운영 워크플로우의 일부가 되었으며, 비즈니스 팀은 모델 출력에 의존하고 기술 팀은 모델을 사용 가능하고 최신이며 설명 가능한 상태로 유지할 책임을 집니다.

강력한 MLOps 프로세스를 갖추면 팀은 이러한 책임을 대규모로 더 효과적으로 관리할 수 있습니다. “MLOps는 흔히 도구의 문제로 설명되지만 실제로 더 큰 장애물은 단절된 워크플로우입니다.”라고 Snowflake의 Applied Field Engineering 부문, 수석 AI/ML 아키텍트 Trace Smith는 설명합니다. “오늘날의 흐름은 거버넌스와 모델 워크플로우를 하나의 운영 모델로 통합하는 더 일원화된 데이터 및 ML 환경을 향하고 있습니다. 이러한 통합이 운영상의 마찰을 줄이고 프로덕션 전환을 앞당기는 데 도움이 됩니다.”

각 모델을 일회성 프로젝트로 다루는 대신, 팀은 반복 가능한 파이프라인, 모니터링, 버전 관리, 거버넌스 통제를 활용해 모델을 더 빠르게 프로덕션으로 전환하고, 성능 변화를 감지하며, 운영 프로세스를 처음부터 다시 구축하지 않고도 업데이트할 수 있습니다.

MLOps는 세 가지 실질적인 방식으로 팀을 지원합니다.

• 시장 출시 시간 단축: 자동화된 파이프라인은 수동 인수인계에서 벗어나 반복 가능한 학습, 테스트, 패키징, 배포로 전환할 수 있도록 지원합니다.
• 신뢰성 향상: 모니터링은 성능 변화, 드리프트, 데이터 품질 문제, 런타임 장애가 눈에 띄지 않게 다운스트림 의사결정에 영향을 미치기 전에 이를 감지할 수 있도록 지원합니다.
• 확장성과 거버넌스 강화: 버전 관리, 계보, 승인 워크플로우, 액세스 제어를 통해 조직은 비공식적인 조율에 의존하지 않고도 더 많은 팀에서 더 많은 모델을 운영할 수 있습니다.

DevOps는 소프트웨어 제공에 중점을 둡니다. MLOps는 여기에 데이터와 ML 시스템의 통계적 동작까지 포괄합니다.

MLOps 프로세스는 선형 인계가 아니라 루프처럼 작동합니다. 팀은 데이터를 수집 및 검증하고 피처를 준비한 뒤, 모델을 학습 및 평가하고 승인된 버전을 등록해 배포합니다. 이후 프로덕션 신호를 다음 모니터링 및 재학습 라운드로 다시 연결합니다.

데이터 수집 및 적재

수명 주기는 데이터베이스, 파일, 스트림, API, 애플리케이션, 서드 파티 데이터 세트와 같은 소스 시스템의 데이터에서 시작됩니다. 프로덕션 ML에서 데이터 적재는 데이터를 학습 환경으로 옮기는 것 이상의 의미를 갖습니다. 데이터의 출처, 최신성, 의도한 목적에 사용할 수 있는지 판단할 수 있도록 충분한 컨텍스트를 보존해야 합니다.

데이터 검증 및 품질 점검

데이터가 학습 또는 추론에 사용되기 전에는 누락값, 스키마 변경, 이상값, 중복 레코드, 편향, 개인정보 보호 문제, 최신성을 점검해야 합니다. 이러한 점검은 잘못된 입력이 모델 동작으로 이어지는 것을 방지합니다. 예를 들어 컬럼이 정수에서 문자열로 바뀌거나, 피드 업데이트가 중단되거나, 레이블이 예상보다 늦게 제공되면 눈에 띄는 프로덕션 장애가 발생하기 훨씬 전부터 모델 품질에 영향을 줄 수 있습니다.

데이터 준비 및 피처 엔지니어링

피처 엔지니어링은 가공 전 데이터를 정제, 변환, 조인, 레이블링, 보강하여 모델이 사용할 수 있는 신호로 전환합니다. 성숙한 MLOps 환경에서는 팀이 자주 사용하는 피처를 한 번 정의한 뒤 학습과 추론 전반에서 일관되게 재사용합니다. 이를 통해 한 팀이 '활성 고객'이나 '최근 트랜잭션 규모'를 다른 팀과 다르게 계산하거나, 프로덕션 모델이 학습 당시 사용한 버전과 더 이상 일치하지 않는 피처 로직을 사용할 리스크를 줄일 수 있습니다.

모델 개발

데이터 사이언티스트와 ML 엔지니어는 노트북, 스크립트, 자동 머신러닝(AutoML) 또는 ML 프레임워크를 사용해 모델을 학습시킵니다. 이들은 예측 문제에 가장 적합한 접근 방식을 찾기 위해 알고리즘, 파라미터, 학습 기간, 데이터 세트를 비교합니다. 모델 개발 단계에서 MLOps의 핵심 요건은 실험이 충분한 메타데이터를 생성하도록 하는 것입니다. 이를 통해 다른 담당자, 파이프라인 또는 승인 워크플로우가 학습된 모델, 사용된 데이터, 모델 성능을 명확히 파악할 수 있습니다.

실험 추적

실험 추적은 모델 버전, 데이터 세트, 코드, 매개변수, 지표, 아티팩트, 결과를 기록합니다. 실험 추적이 없으면 어떤 실행이 다른 실행보다 성능이 좋았다는 사실은 알 수 있어도 그 이유는 파악하기 어렵습니다. 반대로 실험 추적이 있으면 후보 모델을 비교하고 결과를 재현하며, 어떤 모델 버전이 프로덕션으로 승격되었는지 설명할 수 있습니다.

모델 검증 및 평가

모델 평가는 학습된 모델이 지원하려는 비즈니스 프로세스에 대해 정확하고 신뢰할 수 있으며 적절한지 테스트합니다. 평가에는 정확도, 정밀도, 재현율, F1, AUC, RMSE, 지연 시간과 같은 기술 지표뿐 아니라 공정성, 견고성, 비즈니스 KPI 추적도 포함됩니다. 평가 프로세스는 모델이 평균적으로 우수한 성능을 내는지뿐 아니라 중요한 세그먼트, 지역, 제품군, 리스크 범주에서도 허용 가능한 방식으로 동작하는지 검증해야 합니다.

모델 패키징 및 등록

모델이 평가를 통과하면 팀은 종속성과 메타데이터를 함께 패키지한 뒤 모델 레지스트리에 저장합니다. 레지스트리는 버전, 승인 상태, 계보, 배포 상태, 운영 메타데이터를 관리하는 통제된 공간 역할을 합니다.

모델 배포

모델 배포는 모델을 배치 작업, 실시간 API, 스트리밍 추론 파이프라인, 임베디드 애플리케이션 피처 또는 엣지 배포 형태로 프로덕션에 릴리스하는 과정입니다. 서빙 패턴은 지연 시간, 비용, 최신성, 비즈니스 요구 사항에 따라 달라집니다. 예를 들어 사기 탐지 모델은 실시간 추론이 필요할 수 있는 반면, 월간 성향 모델은 다운스트림에서 활용할 수 있도록 예측값을 테이블에 다시 쓰는 배치 스코어링 작업으로 실행될 수 있습니다.

모델 서빙

배포 후에는 애플리케이션의 지연 시간, 규모, 비용, 최신성 요구 사항에 맞는 방식으로 모델을 서빙해야 합니다. 모델 서빙은 배치 스코어링, 실시간 API, 스트리밍 추론, 임베디드 애플리케이션 로직 또는 엣지 환경을 통해 예측을 사용할 수 있게 하는 런타임 계층입니다. 이 계층은 승인된 모델 버전을 프로덕션에서 안정적으로 사용할 수 있도록 입력 준비, 피처 검색, 런타임 종속성, 스케일링, 액세스 제어, 지연 시간, 오류 처리를 관리해야 합니다.

모델 모니터링

모델 모니터링은 배포 후에도 모델이 기대한 대로 동작하는지 추적합니다. 일반적으로 팀은 프로덕션 성능, 지연 시간, 오류, 데이터 드리프트, 개념 드리프트, 모델 품질, 비용, 운영 상태를 모니터링합니다.

피드백 및 재학습

프로덕션 예측은 레이블, 사용자 행동, 비즈니스 결과, 사람의 피드백, 드리프트 신호와 같은 새로운 정보를 생성합니다. MLOps는 이 정보를 다시 수명 주기에 반영하여, 현재 버전이 더 이상 충분한 성능을 내지 못할 때 팀이 모델을 재학습하고 재검증한 뒤 재배포할 수 있도록 지원합니다. 재학습 트리거는 사용 사례의 리스크와 변동성에 따라 일정 기반, 이벤트 기반 또는 모니터링 임계값 기반으로 설정될 수 있습니다.

거버넌스 및 규정 준수

거버넌스는 ML 수명 주기 전반에 걸쳐 적용됩니다. 팀은 가공 전 데이터부터 프로덕션 추론에 이르기까지 액세스, 감사 추적, 설명 가능성, 계보, 개인정보 보호, 보안, 승인, 규제 요건을 관리해야 합니다. 모델이 신용, 가격 책정, 헬스케어, 고용, 사기 감지, 안전 등 영향도가 높은 의사결정에 관여하는 경우 이는 특히 중요합니다. 거버넌스는 팀이 다음과 같은 기본적인 운영 질문에 답하는 데도 도움이 됩니다. 현재 실행 중인 모델 버전은 무엇인가? 어떤 데이터로 학습했는가? 어떤 피처를 사용하는가? 누가 승인했는가? 이전 버전 이후 무엇이 변경되었는가?

MLOps에는 서로 유기적으로 연결된 구성 요소가 필요합니다. 일부 조직은 이러한 구성 요소를 여러 시스템에 걸쳐 조합하지만, 데이터, 피처 관리, 모델 운영, 거버넌스를 더 긴밀하게 유지할 수 있는 통합 플랫폼을 선호하는 조직도 있습니다.

MLOps 성숙도는 일반적으로 팀이 수명 주기 전반을 더 많이 자동화하고 재현성, 모니터링, 거버넌스에 대한 통제를 강화할수록 높아집니다. Google Cloud의 MLOps 성숙도 모델은 널리 활용되는 기준점입니다.

레벨 0: 수동 프로세스

레벨 0에서는 ML 작업이 노트북 중심으로 이루어지며 수작업 비중이 매우 높습니다. 데이터 사이언티스트는 비공식 프로세스를 통해 데이터를 준비하고, 모델을 학습시키고, 결과를 평가한 뒤 아티팩트를 전달합니다. 실험 단계에서는 이러한 방식도 가능하지만, 모델을 프로덕션에서 재현, 업데이트 또는 모니터링해야 할 때는 리스크가 발생합니다.

레벨 1: ML 파이프라인 자동화

레벨 1에서는 팀이 ML 파이프라인을 자동화해, 새로운 데이터가 들어왔을 때 반복 가능한 검증, 학습, 평가 단계에 따라 모델을 재학습할 수 있습니다. 목표는 지속적 학습으로, 새로운 데이터가 확보될 때 통제된 방식으로 모델을 업데이트하는 것입니다. 이 단계에서는 수동 인수인계가 줄어들지만, 파이프라인 자체에는 여전히 별도의 릴리스 관리가 필요할 수 있습니다.

레벨 2: CI/CD 파이프라인 자동화

레벨 2에서는 팀이 ML 파이프라인 자체의 빌드, 테스트, 배포를 자동화합니다. 코드, 데이터 검증 로직, 학습 워크플로우, 배포 정의의 변경 사항은 CI/CD 프로세스를 거쳐 이동합니다. 이 단계부터 ML 운영은 버전 관리된 파이프라인, 자동화된 테스트, 환경 간 통제된 승격을 갖춘 프로덕션 엔지니어링 분야에 더 가까워집니다.

고급 성숙도: 자율적이고 거버넌스가 적용된 운영

일부 성숙도 모델은 고급 또는 자율 운영을 위한 더 높은 단계를 추가합니다. 이 단계에서는 모니터링 신호가 재학습 워크플로우를 트리거할 수 있고, 거버넌스 검사가 승격 경로에 내장되며, 팀은 일관된 정책으로 다수의 모델을 관리할 수 있습니다. 특히 영향도가 높은 모델에서 인간의 판단을 배제하는 것이 목표는 아닙니다. 반복적인 감지, 검증, 에스컬레이션을 더 체계화하는 것이 핵심입니다.

Snowflake ML로 대규모 모델을 구축하고 프로덕션에 적용하는 방법 알아보기:

대규모 언어 모델 운영(LLMOps)은 MLOps 관행을 생성형 AI 애플리케이션으로 확장합니다. LLMOps는 프롬프트, 검색, 컨텍스트, 토큰 사용량, 안전성, 평가와 관련된 새로운 운영 과제를 MLOps에 추가합니다.

LLMOps에는 일반적으로 다음이 포함됩니다.

• 프롬프트 및 시스템 지침 버전 관리
• 사실성, 관련성, 어조, 안전성, 작업 완료 여부를 평가하는 프레임워크
• 문서 최신성과 검색 품질을 포함한 RAG 파이프라인 모니터링
• 토큰 비용 추적 및 지연 시간 최적화
• 개인정보 보호, 유해성, 근거성, 정책 위반을 모니터링하는 가드레일
• 사람의 검토와 모델 개선을 위한 피드백 루프

그러나 기본 운영 원칙은 같습니다. 애플리케이션의 신뢰성은 그 기반이 되는 데이터, 컨텍스트, 평가, 거버넌스에 의해 좌우됩니다.

강력한 MLOps 실천 방식은 프로덕션 ML이 일회성 인계의 반복으로 끝나지 않도록 팀을 지원합니다. 모델이 개발 환경에서 실제 운영 워크플로우로 이동하면 팀은 모델 동작에 영향을 주는 자산을 일관되게 버전 관리하고, 릴리스 전에 변경 사항을 테스트하고, 프로덕션 성능을 모니터링하며, 추적성을 잃지 않고 모델을 업데이트할 수 있어야 합니다.

모델 동작에 영향을 주는 모든 요소의 버전 관리

MLOps에서는 코드, 데이터 세트, 피처 정의, 파라미터, 모델 아티팩트, 종속성, 평가 결과, 배포 메타데이터를 모두 버전 관리해야 합니다. 모델이 변경되면 팀은 성능 변화가 새로운 학습 데이터 때문인지, 새로운 피처 로직 때문인지, 다른 파라미터 집합 때문인지, 새로운 런타임 환경 때문인지 파악할 수 있어야 합니다.

리스크를 줄이는 영역부터 테스트와 CI/CD 자동화

자동화는 팀이 안정적으로 반복해야 하는 점검을 포괄해야 합니다. 여기에는 데이터 검증, 피처 검증, 모델 평가, 패키징, 배포, 롤백이 포함됩니다. ML을 위한 CI/CD에는 드리프트 점검, 편향 테스트, 지연 시간 임계값, 비즈니스 KPI 가드레일처럼 모델에 특화된 테스트도 포함해야 합니다.

프로덕션 모델의 지속적 모니터링

프로덕션 모니터링은 시스템 상태와 모델 동작을 함께 추적해야 합니다. 지연 시간, 오류, 비용도 중요하지만 입력 분포, 예측 분포, 모델 성능, 드리프트, 데이터 최신성 역시 그만큼 중요합니다.

재현성을 고려한 설계

또한 모델 생성 방식, 학습에 사용된 데이터 세트와 피처, 사용된 코드와 파라미터, 승격을 뒷받침한 지표, 현재 예측을 서빙 중인 버전을 명확히 설명할 수 있어야 합니다. 재현성은 디버깅, 감사 가능성, 협업, 규정 준수에 도움이 됩니다.

팀이 지속할 수 있는 성숙도 수준에서 시작

MLOps 성숙도는 조직의 요구 사항, 역량, 리스크 프로필에 맞아야 합니다. 위험도가 낮은 배치 모델 하나만 운영하는 팀이라면 처음부터 자율 재학습이 필요하지 않을 수 있습니다. 고객 대면 모델이 많거나, 규제 대상 사용 사례를 다루거나, 빠르게 변하는 데이터를 사용하는 팀이라면 더 이른 단계부터 강력한 자동화, 모니터링, 거버넌스가 필요합니다.

많은 MLOps 아키텍처는 준비, 학습, 피처 관리, 레지스트리, 서빙, 모니터링을 위해 데이터를 별도 시스템 간에 이동시킵니다. 이러한 분리는 추가 복사본과 단절된 계보를 만들고, 액세스 정책이나 피처 정의가 어긋날 수 있는 지점을 늘릴 수 있습니다. Snowflake의 접근 방식은 ML 수명 주기의 더 많은 부분을 Snowflake AI 데이터 클라우드 안의 거버넌스가 적용된 데이터 가까이 가져오는 것입니다.

Snowflake ML을 사용하면 팀은 모델이 사용하는 데이터에 더 가까운 곳에서 모델을 구축, 학습, 배포, 모니터링할 수 있습니다. Snowflake ML은 개발을 위한 Snowpark ML API, 탐색과 협업을 위한 Snowflake Notebooks, 피처 관리를 위한 Snowflake Feature Store, 버전 관리와 거버넌스를 위한 Snowflake Model Registry 같은 기능을 제공합니다. ML Observability는 성능, 드리프트, 볼륨 지표를 포함하여 등록된 프로덕션 모델을 모니터링할 수 있도록 지원합니다. 현재는 회귀 및 이진 분류 모델을 지원합니다.

피처는 한 번 정의한 뒤 액세스 제어를 통해 관리되고, 학습에서 추론으로 이동하는 과정에서 계보를 통해 추적될 수 있습니다. 모델은 레지스트리를 통해 메타데이터, 버전 이력, 배포 상태를 함께 유지합니다. 데이터 사이언티스트는 여전히 노트북에서 실험할 수 있지만, 작업은 거버넌스가 적용된 데이터에 더 가까운 곳에서 이뤄집니다. 또한 모니터링을 통해 프로덕션 입력이 평가 시 사용한 가정에서 벗어나기 시작하는 시점을 감지할 수 있습니다.

MLOps는 흔히 파이프라인, 레지스트리, CI/CD, 모니터링, 재학습 같은 배포 메커니즘으로 설명됩니다. 이러한 실행 방식은 유효하지만, 모델 주변의 데이터 컨텍스트와 거버넌스 컨텍스트에 연결되어 있을 때에만 더 근본적인 운영 문제를 해결할 수 있습니다. 팀이 모델 학습에 사용된 데이터를 추적하고, 모델이 사용하는 피처를 파악하며, 평가 단계의 성능을 확인하고, 프로덕션 동작의 변화가 시작되는 시점을 감지할 수 있을 때 모델 버전에 대한 신뢰성이 높아집니다.

ML이 더 많은 애플리케이션과 비즈니스 워크플로우에 편입될수록 이러한 운영 컨텍스트는 선택적 요소로 취급할 수 없습니다. 팀은 계보를 유지하면서 빠르게 작업하고, 로직 중복 없이 피처를 재사용하며, 모델이 의존하는 데이터와 분리하지 않은 상태로 모델을 모니터링하고, 수동 인계에 의존하지 않고 프로덕션 시스템을 업데이트할 수 있는 체계가 필요합니다. MLOps는 이러한 구조를 제공합니다.