LLMOps와 플랫폼 엔지니어링: 누가 AI 파이프라인을 소유해야 하는가?

A few years ago, getting a model into production meant a data scientist, a DevOps engineer, and a narrow set of tools: train it, test it, ship it, watch the dashboards. Large language models broke that picture. The thing being “operated” is now a system that chains prompts, calls vector databases, and produces open-ended text judged on tone and safety, not just accuracy. That's the gap LLMOps fills, and it lands on top of MLOps and DevOps, all competing for the same pipeline platform engineering is supposed to run.

Get the ownership model wrong, and you recreate the shadow-IT problem platform engineering was built to prevent, just with prompts instead of Jenkinsfiles. LLMOps, or large language model operations, is the set of practices, tools, and workflows used to develop, deploy, and manage LLMs throughout their production lifecycle: data management, prompt engineering and fine-tuning, deployment and serving, monitoring and evaluation, and security and governance. It isn't MLOps with a new label.

Google Cloud calls it a specialised subset of MLOps , and the gap comes down to scale and evaluation: LLMs cost more to fine-tune and serve, and their output is far harder to score than a clean accuracy number. An LLM has to be more than accurate; it has to be secure and trustworthy, and that's a much harder thing to measure. It's also the ongoing care and feeding of a model once it's live, not a one-time deployment checklist. Models drift, costs creep, prompts stop working the way they used to, and the integrations tying an LLM to a CRM or an internal knowledge base need constant tending.

The lifecycle runs from data prep and prompt engineering (treating prompts as versioned artefacts, not throwaway strings), through fine-tuning open foundation models with libraries like Hugging Face Transformers, to model and prompt versioning and lineage tracking, inference serving on GPU-backed endpoints, and monitoring with human feedback for drift and cost. Every stage needs infrastructure, access controls, and a place to run. This is exactly the territory platform engineering already occupies for every other kind of workload.