[분석] MLOps에서 LLMOps로, 아직 끝나지 않은 진화의 서막

 

 

[ kt cloud AI플랫폼팀 최지우 님 ]

📋 요약

이 글에서는 AI 모델 운영의 핵심인 MLOps에서 LLMOps로의 진화 과정을 다룹니다.
생성형 AI 시대에 필요한 운영 체계의 변화와 기업이 고려해야 할 실무 관점을 정리합니다.

#MLOps #LLMOps #AI운영 #생성형AI #RAG

---

AI 모델을 만들고 배포하는 일은 이제 그 자체로 특별하지 않습니다. 누구나 튜토리얼을 따라 모델을 학습시키고, 몇 번의 시도로 눈에 띄는 성능을 낼 수 있습니다.
그러나 모델을 ‘운영’하기 시작하는 순간, 이야기는 완전히 달라집니다.

 

실제 환경에서 AI는 하나의 모델로 완성되지 않습니다. 데이터 검증, 파이프라인 자동화, 자원 스케줄링, 거버넌스 정책 등이 동시에 맞물려야 합니다. 각 단계는 서로 의존적이기 때문에, 한 부분의 결함이 시스템 전체의 품질 저하로 이어질 수 있습니다.
모델을 갱신하고 배포하며, 그 영향을 관찰하고 다시 개선하는 일련의 순환이 끊기지 않아야 비로소 지속 가능한 사업 가치가 만들어집니다.

 

이 지점에서 MLOps가 등장합니다. MLOps는 눈에 띄는 성과를 만들어내기보다, 그 성과가 안정적으로 유지되도록 돕는 공정입니다.
그리고 이 공정이 제대로 작동하기 전에는, 어떤 인상적인 모델도 장기적인 성과를 보장할 수 없습니다.

 

오늘날 AI는 사회 전반의 변화를 이끄는 핵심 기술로 자리 잡았습니다.
AI 기술의 변화 주기는 이제 개발자의 학습 속도를 앞지르고 있습니다. 매주 새로운 연구가 발표되고, 수많은 논문이 쏟아지며, 기업들은 앞다투어 개발자 도구를 출시해 시장 선점을 노립니다. 이제 그 속도는 인간의 학습 곡선을 훌쩍 넘어섰습니다.

 

이 생태계에 막 발을 들인 사람이라면, 끊임없이 변하는 풍경 속에서 무엇부터 이해해야 할지 막막함을 느낄지도 모릅니다.

 

초기에는 학습, 배포, 모니터링을 한곳에서 처리할 수 있다는 통합형 플랫폼의 효율성이 가장 눈에 띕니다.
학습부터 배포, 모니터링까지 일체형으로 연결되는 경험은 도입 속도를 높여주지만, 시간이 지나면 팀마다 요구가 달라지고, 보안/컴플라이언스/거버넌스/비용 구조가 서로 다른 방식으로 작동하면서 고정된 추상화와 현장의 세부 요구 사이에 간극이 생깁니다.

 

결국 중요한 것은 특정 제품에 적응하는 능력이 아니라, 우리 조직이 반복적으로 수행할 공정을 스스로 정의하고 표준화하는 역량입니다.
플랫폼은 그 표준을 담는 그릇일 뿐이며, 그릇이 내용물을 대신해 주지는 않습니다.

 

이 글에서는 오늘날의 MLOps가 어떤 지점에 서 있으며, 앞으로 어디로 향하고 있는지를 함께 살펴보려 합니다.

---

MLOps의 정의와 구조

MLOps는 AI 시스템을 프로덕션에 배포하고 신뢰성 있게 “운영”하기 위한 일련의 프로세스와 도구를 뜻합니다. 즉, 모델이 ‘한 번의 성공’으로 끝나지 않도록 데이터를 다루고, 학습/배포/모니터링을 반복 가능한 프로세스로 만드는 역할을 합니다.

흔히 MLOps를 DevOps의 확장판으로 설명하지만, 그 정의만으로는 중요한 본질이 빠집니다.
소프트웨어는 코드가 바뀌면 결과가 바뀌지만, AI는 데이터가 바뀌어도 결과가 바뀝니다. 즉, 변화의 차원이 하나 더 존재합니다. 이 때문에 운영의 단위는 코드에 머무르지 않고, 데이터/피처/모델/파이프라인/평가 규칙까지 확장됩니다.

 

MLOps의 핵심은 이러한 복잡한 변화를 효율적으로 관리하기 위한 파이프라인입니다. 이 파이프라인은 모델이 현실에 투입되기까지의 여정을 구조화하며, 일반적으로 다음 일곱 단계로 구성됩니다.

• 데이터 수집
  내부 시스템과 외부 채널에서 데이터를 확보하고, 활용 가능한 형태로 통합합니다.
• 데이터 검증
  수집된 데이터의 누락, 이상치, 불일치를 점검해 이후 단계의 오류를 예방합니다.
• 데이터 전처리
  모델 학습에 필요한 구조로 데이터를 정리하고, 의미 있는 피처를 구성합니다.
• 모델 학습
  다양한 알고리즘을 실험하며, 성능을 극대화할 수 있는 파라미터를 탐색합니다.
• 모델 평가 및 튜닝
  독립된 데이터셋을 활용해 모델의 일반화 성능을 평가하고, 필요 시 구조를 조정합니다.
• 모델 배포
  검증을 통과한 모델을 실제 서비스 환경에 배포하고, 트래픽과 요청을 처리하도록 구성합니다.
• 성능 모니터링 및 실험 추적
  모델이 실제 환경에서 어떻게 작동하는지를 관찰하며, 성능 저하나 데이터 변화를 탐지해 개선 루프를 이어갑니다.

이 모든 요소를 추적 가능한 상태로 유지해야 재현성과 회귀 방지를 보장할 수 있습니다.
따라서 MLOps는 단순한 도구의 나열이 아니라, 시스템 전체를 설계하고 운영하는 엔지니어링의 문제입니다.

---

운영의 본질: 루프를 설계하는 일

출차: https://www.pasqal.com/resources/new-gartner-hype-cycle-for-ai-report-2025/

AI 연구는 여전히 놀라운 속도로 발전하고 있습니다. 하지만 지금 우리가 서 있는 무대는, 그보다 훨씬 현실적인 단계인 ‘배포(Deployment)’입니다. 한때는 모델의 정확도가 모든 화두를 이끌었지만, 이제는 “이걸 어떻게 안정적으로 운영할 것인가”가 중심 질문이 되었습니다.

 

가트너의 하이프 사이클로 표현하자면, 클라우드 기반 AI 서비스와 MLOps는 이제 ‘운영 효율’의 단계로 넘어가고 있습니다. 초기의 과장된 기대가 사라지고, 이제는 예측 가능성과 유지비용 같은 현실적인 지표가 중심이 되었습니다.

 

이제 조직들은 “이 투자를 할만한 가치가 있을까?”를 묻습니다.
그리고 그 답은 더 이상 기술 그 자체가 아니라, 운영의 성숙도에서 찾아야 한다는 사실을 깨닫고 있습니다.

 

운영의 핵심은 루프가 얼마나 빠르고 정확하게 돌아가느냐에 있습니다. 데이터 검증이 미흡하면 잘못된 입력이 학습을 오염시키고, 실험 추적이 부실하면 어떤 변경이 품질 향상에 기여했는지 알 수 없습니다. 배포 절차가 느슨하면 우발적인 결함이 그대로 사용자에게 노출됩니다.

 

반대로 이 루프가 단단히 설계되어 있다면, 모델의 작은 개선도 위험 없이 빠르게 전달할 수 있습니다. 조직이 진정으로 얻는 가치는 성능 그래프의 급등이 아니라, 예측 가능성과 변동성의 축소에서 비롯됩니다.

---

도구의 과잉 속에서 길을 찾는 법

수많은 도구가 등장했지만, 이 루프를 단단하게 만드는 도구는 의외로 많지 않습니다.

 

현재의 MLOps 생태계는 풍부함을 넘어 과잉에 가깝습니다.
파이프라인 오케스트레이션, 데이터 버전 관리, 실험 관리, 모델 저장소, 피처 플랫폼, 모니터링, 평가 자동화 등 굵직한 범주들이 존재하지만, 실제 제품들은 서로의 영역을 침범하며 경계가 점점 흐려지고 있습니다.

 

예를 들어, 최근의 모델 서빙 플랫폼은 단순히 배포만 담당하지 않습니다. 실험 추적, 버전 관리, A/B 테스트까지 통합하며, 기존의 실험 관리 도구가 담당하던 역할을 일부 대체하고 있습니다. 표면적으로는 세분화처럼 보이지만, 실제로는 같은 문제를 다른 관점에서 재포장하는 경우가 적지 않습니다.

출처 : https://mad.firstmark.com/

선택의 기준은 “기능이 많은가”가 아닙니다. 진짜 중요한 것은 도구가 무엇을 책임지는지와, 얼마나 예측 가능하게 유지할 수 있는가입니다.

 

특정 도구가 우리 공정에서 정확히 어떤 부분을 책임지는지, 그 도구가 실패했을 때 어떤 절차가 호출되는지, 그리고 그 시점에 다른 컴포넌트가 어떤 정보를 참조해 복구를 시도하는지를 미리 그려보아야 합니다.

 

이 구조가 없다면, 기능이 늘어날수록 운영은 오히려 불안정해집니다. 반대로 책임과 경계가 명확하다면, 각 도구는 상호 교체 가능한 모듈이 됩니다.

 

또한 도구 선택은 또한 시간의 함수입니다. 도입 초기에는 일체형 플랫폼이 빠른 온보딩을 돕지만, 운영이 성숙해질수록 특화된 모듈이 더 큰 유연성을 제공합니다.

 

이 전환은 서두를 필요가 없습니다. 내부 루틴이 안정되고, 지표가 일관성 있게 해석되는 단계가 되었을 때 그제야 병목을 분해하고 기능을 외부로 분리하는 것이 합리적입니다. 성급한 분리는 비용만 늘리고 책임만 분산합니다. 중요한 것은 현재의 병목을 정확히 측정하고, 단계적으로 해소하는 일입니다.

 

산업 전반을 조금 더 냉정하게 들여다보면, 우리는 아직 완전한 AI 파이프라인 아키텍처의 표준을 정립하는 과정에 있습니다. 각 조직은 저마다의 방식으로 모범 사례를 쌓아가고 있지만, 표준은 빠르게 만들어지지 않습니다. 클라우드 시대의 DevOps가 정착하는 데도 십여 년이 걸렸듯, MLOps 역시 여러 산업의 운영 데이터를 통해 천천히 실무 표준이 형성될 것입니다.

 

MLOps 툴링 기업들의 궤적은 대체로 비슷합니다. 처음에는 작은 틈새 시장을 공략해 진입하고, 곧 주변 아키텍처 영역까지 확장하며 점차 책임의 경계를 넓혀갑니다. 문제는 그 경계가 끊임없이 변한다는 점입니다.

 

이처럼 도구의 역할이 지속적으로 재정의되는 환경에서, 신규 진입자에게 MLOps는 가장 가파른 언덕입니다. 무엇을 표준으로 삼아야 할지, 어떤 조합이 유효한지조차 명확하지 않습니다.

 

그런데 이 복잡한 지형이 아직 정리되기도 전에, 생성형 AI라는 더 큰 파도가 등장했습니다.

---

생성형 AI가 바꾼 판: LLMOps와 RAG, 그리고 AgentOps까지

대규모 언어모델(LLM)은 기존의 운영 상식을 완전히 뒤흔들었습니다. 이제 모델 개선은 더 이상 학습만의 문제가 아닙니다. 프롬프트, 컨텍스트, 정책, 실행 흐름이 품질을 결정짓는 주요 요인이 되었고, 이를 운영 중에 제어하는 것 핵심이 되었습니다.

 

이 변화 속에서 MLOps는 LLMOps로 확장되었습니다. 이 새로운 패러다임은 프롬프트를 코드처럼 관리하고, 체인과 에이전트를 그래프 형태로 구성하며, 실행의 흔적을 표준 방식으로 수집하고 비교하는 운영 방식을 요구합니다.

출처 : https://www.geeksforgeeks.org/data-science/llmops-vs-mlops-making-the-right-choice/

프롬프트에는 버전이 있고, 변경에는 릴리즈 노트가 있어야 합니다. 회귀를 방지하는 테스트 역시 필수입니다. 이 규율이 없다면, 모델은 하루에도 여러 번 성격이 바뀌는 불안정한 서비스가 됩니다.

 

운영의 단위는 이제 텍스트 생성 모델에 머물지 않습니다. 음성, 이미지, 코드, 센서 데이터 등 멀티모달 입력이 통합되고, 하나의 모델이 아니라 여러 에이전트가 협업하는 체계가 등장하면서 운영 복잡성은 급격히 높아지고 있습니다.

 

이러한 환경에서는 모델 간 상호작용과 의존 관계를 추적하고 제어할 수 있는 새로운 운영 계층이 필요합니다.
즉, MLOps의 확장된 형태로서의 AgentOps가 요구되고 있습니다. 이 계층은 개별 모델의 성능보다 시스템 전체의 협업 품질과 안정성을 보장하는 역할을 합니다.

 

품질의 정의도 바뀌었습니다. 생성형 시스템은 단일 정답률로 평가하기 어렵습니다. 대신 문맥 일치, 근거 충실, 형식 준수, 편향 회피, 정책 위반율 등 다면 지표가 필요합니다. 이 지표는 자동화된 평가로 수집되고, 경계 사례는 휴먼 리뷰로 정제되며, 실제 트래픽에서는 온라인 A/B로 검증됩니다. 결국 평가는 “출시의 관문”이면서 “개선의 나침반”이 됩니다. 평가가 잘 설계되어 있을수록 팀은 빠르게 실험하고, 안전하게 출시할 수 있습니다.

 

RAG(Retrieval-Augmented Generation)는 생성형 시스템의 가장 현실적인 해법입니다. 모델 외부의 지식을 검색해 주입함으로써 환각(hallucination)을 줄이고, 최신성을 확보합니다.

 

하지만 RAG는 단순한 추가 기능이 아닙니다. 색인 주기와 증분 빌드, 임베딩 품질, 문서 압축/청크/샤딩 전략,
그리고 메타데이터/접근 권한 정책까지 이 모든 요소가 검색 적중률과 컨텍스트 정밀도를 결정합니다. 그리고 이 정밀도가 다시 생성 품질로 이어집니다.

 

운영 관점에서 RAG는 검색 실패, 부분 적중, 중복 문서, 권한 누락과 같은 문제 상황을 어떻게 감지하고 회복할지까지 포함해야 하는 체계입니다.

 

결국 RAG의 성공은 모델의 성능만큼이나 데이터 운영의 성숙도에 달려 있습니다.

 

모니터링 또한 로그를 넘어 실행 그래프의 수준으로 올라와야 합니다. 프롬프트 버전, 단계별 입력과 출력, 도구 호출과 응답, 토큰 소비와 지연 분포, 캐시 적중과 재시도 이력이 표준 스키마로 남아야 원인 분석과 비교 실험이 현실화됩니다. 이 표준은 엔진이나 오케스트레이터를 바꾸어도 유효해야 합니다. 그렇게 해야 품질·비용 SLO가 플랫폼 교체와 무관하게 유지됩니다. 모니터링은 이제 선택 기능이 아니라 운영의 인프라입니다.

 

하지만 이런 이상적인 운영 체계를 당장 구현할 수 있는 조직은 많지 않습니다.

---

AI 도입의 현실과 기업들이 원하는 플랫폼

겉으로 보이는 AI 업계의 화려함과 달리, 현장의 AI 성숙도는 생각보다 높지 않습니다. 투자 규모나 도입한 툴만 보면 높은 수준으로 보이지만, 막상 내부를 들여다보면 아직은 기초를 다지는 단계에 가깝습니다.

 

초대형 데이터와 인프라를 실제로 운영하는 기업은 많지 않습니다. 대부분의 조직은 자신들의 규모와 목표에 맞는 범위에서 데이터를 활용하며, 점진적으로 AI 역량을 확장하고 있습니다. 그럼에도 시장의 담론은 늘 소수의 ‘AI 퍼스트’ 기업들을 중심으로 흘러갑니다. 그들의 기준이 곧 업계의 표준이 되어버린 셈입니다.

 

이 때문에 착시가 생깁니다. 모두가 고도화된 AI 시스템을 운영을 하고 있는 것처럼 보이지만, 실제로는 많은 기업이 아직 자신에게 맞는 전략을 실험하는 중입니다. 완벽한 파이프라인보다 중요한 것은, 각자의 여건 속에서 지속 가능한 학습 루프를 구축하는 일입니다.

대부분의 기업은 거대한 AI 모델을 만드는 곳이 아닙니다. 자동차, 제조, 유통 등 각자의 분야에서 고유한 데이터를 가진 ‘AI 도입을 준비하는 기업들’이 점점 늘어나고 있습니다. 수백 GB에서 수 TB에 이르는 독점 데이터를 쌓아왔지만, AI의 도입은 이제 막 시작 단계에 가깝습니다.

 

이들에게 필요한 것은 복잡한 인프라가 아닙니다. 처음부터 서브밀리초 지연을 추구할 이유도 없습니다. 대부분의 초기 성과는 작은 자동화나 단순한 예측 모델처럼 명확하고 빠른 성과를 낼 수 있는 과제에서 나옵니다.

kt cloud는 이 현실적인 과제에서 출발합니다.

우리가 만드는 AI플랫폼은 거대한 시스템이 아니라, 기업들이 스스로의 속도와 맥락에 맞춰 AX(AI Transformation)를 시도할 수 있도록 돕는 기반입니다. 초고도화된 시스템보다, 첫 번째 성공 경험을 빠르게 만들어주는 플랫폼을 설계하고 있습니다.

 

앞으로 5년, kt cloud의 AI 플랫폼은 기업들이 안정적이고 지속 가능한 방식으로 AI를 활용하고 확장할 수 있는 토대가 될 것입니다.

 

 

---

❓ 자주 묻는 질문 (FAQ)

Q. LLMOps는 기존 MLOps와 무엇이 다른가요?

A. 모델 개선의 단위가 코드와 데이터에서 프롬프트/컨텍스트/정책/체인 구조로 확장되었고, 이를 운영 중에 관리해야 하기 때문에 기존 MLOps의 범위를 넘어섭니다.

---

📚 관련/출처

2025 Gartner® Hype Cycle™ for AI research has been published - Pasqal FirstMark | 2025 MAD (ML/AI/Data) Landscape LLMOPS vs MLOPS: Making the Right Choice - GeeksforGeeks