대규모 언어 모델을 프로덕션 환경에서 운영하는 일은 더 이상 모델을 학습하고 테스트하며 배포하고 대시보드를 모니터링하는 데 국한되지 않는다. 현대적인 시스템은 프롬프트와 벡터 데이터베이스 및 지식 소스를 연결한 뒤, 정확성과 더불어 어조·안전성·신뢰성을 기준으로 평가되는 개방형 텍스트를 생성할 수 있다. 이에 따라 다니엘 브라이언트는 CNCF 블로그에 게시한 글에서 실용적인 질문을 제기한다. AI 파이프라인은 누가 소유해야 하는가?
저자는 답이 LLMOps에 별도의 왕국을 부여하는 데 있는 것이 아니라, 잘 조직된 엔지니어링 플랫폼 안에 이를 통합하는 데 있다고 본다. 이를 통해 필요한 역량을 다른 워크로드에서 개발 팀이 사용하는 것과 동일한 인터페이스로 제공할 수 있다.
LLMOps란 무엇인가?
LLMOps는 대규모 언어 모델을 개발하고 배포하며 프로덕션 수명 주기 전반에 걸쳐 관리하는 데 필요한 관행·도구·워크플로의 집합을 가리킨다. 여기에는 데이터 관리, 프롬프트 엔지니어링, 파인튜닝, 배포 및 추론 서비스, 모니터링과 평가뿐 아니라 보안과 거버넌스도 포함된다.
분석에 따르면 LLMOps는 단순히 MLOps의 명칭을 바꾼 것이 아니다. 대규모 언어 모델은 파인튜닝과 서비스 제공에 더 많은 비용이 들며, 그 결과를 명확한 정확도 수치 하나로 축약하기도 더 어렵다. 모델이 정확하기만 해서는 충분하지 않다. 모델은 안전하고 신뢰할 수 있어야 하며, 이러한 특성은 측정하기가 더 복잡하다.
또한 모델 운영은 최초 배포로 끝나지 않는다. 모델은 이전의 동작에서 벗어날 수 있고, 비용이 상승하며, 프롬프트가 평소와 같은 방식으로 작동하지 않을 수 있다. 고객 관계 관리 시스템 또는 내부 지식 기반과의 통합 역시 지속적인 추적이 필요하다.
플랫폼 엔지니어링과 교차하는 수명 주기
LLMOps의 수명 주기는 데이터를 준비하고 프롬프트를 엔지니어링하는 일에서 시작한다. 이때 프롬프트는 임시 텍스트가 아니라 버전 관리가 가능한 요소로 다뤄진다. 또한 Hugging Face Transformers와 같은 라이브러리를 사용해 오픈 기반 모델을 파인튜닝하고, 모델과 프롬프트의 버전 및 계보를 추적하며, GPU가 지원하는 엔드포인트를 통해 추론을 제공하고, 인간 피드백을 바탕으로 모니터링하여 드리프트와 비용을 감지하는 과정도 포함한다.
이 수명 주기의 모든 부분에는 인프라와 접근 제어 및 실행 환경이 필요하며, 이는 본래 플랫폼 엔지니어링의 범위에 속하는 영역이다. 그러나 저자는 두 영역의 성격을 구분한다. 플랫폼 엔지니어링은 인프라를 중심으로 하고, MLOps는 모델을 중심으로 한다. 따라서 유용한 질문은 «누가 파이프라인을 소유하는가?»가 아니라 «각 계층을 누가 소유하며, 이들을 실제로 조정하는 주체가 존재하는가?»이다.
병렬 스택 구축의 위험
이 분석은 소프트웨어 제공 환경을 배포 요청에 파묻힐 수 있는 DevOps 팀, 표준화된 셀프서비스 경로를 구축하는 플랫폼 엔지니어링 팀, 그리고 DevOps 도구가 데이터 버전이나 드리프트 모니터링을 관리하도록 설계되지 않았기 때문에 병렬 스택을 구축한 MLOps 팀으로 나눈다. 여기에 LLMOps가 추가되면, 거버넌스를 담당하는 주체와 떨어진 곳에 프롬프트·벡터 데이터베이스·RAG 파이프라인을 위한 세 번째 독립 스택이 등장할 수 있다.
저자는 이 가능성을 «숨은 AI 운영» 문제와 연결한다. 어느 한 팀이 자체 RAG 파이프라인을 만들고 검토되지 않은 벡터 데이터베이스에 연결할 수 있지만, 책임 주체는 실제로 무엇이 작동하고 있는지 명확히 알지 못할 수 있다. 분석에 따르면 가장 큰 운영 위험은 환각을 생성하는 챗봇 자체가 아니라, 이러한 역량이 플랫폼 밖으로 확산된 뒤 가시성과 통제의 범위 밖에 남는 것이다.
저자는 이를 막기 위해 팀의 속도를 늦추자고 제안하지 않는다. 대신 플랫폼이 요청을 신속하게 충족할 수 있도록 하면서 사용 경로 자체에 거버넌스를 포함해야 한다고 말한다. 준비된 경로가 없으면 팀은 플랫폼 밖에서 자체 역량을 구축할 수 있지만, 표준 경로를 제공하면 이러한 역량을 관리 가능한 환경으로 다시 가져오는 데 도움이 된다.
플랫폼 계층 안의 LLMOps
브라이언트는 CNCF의 TAG App Delivery 그룹이 발행한 플랫폼 백서의 개념에 기반을 둔다. 이 백서는 환경을 세 계층으로 나눈다. 상단은 제품, 중간은 합리적으로 가능한 한 가장 얇은 통합 계층으로서의 플랫폼, 하단은 역량 제공자다.
이 개념에 따르면 파인튜닝 작업, 벡터 데이터베이스, 프롬프트 로그, 추론 엔드포인트와 같은 기능을 또 하나의 플랫폼 역량으로 다룰 수 있다. 이러한 기능도 다른 기능과 마찬가지로 API, 버전, 명확한 소유권이 필요하다. 저자는 이 모델을 지원할 수 있는 CNCF 생태계의 도구들을 언급한다. Backstage는 제품 계층에서 표준 경로를 제시하고, Crossplane은 하위 계층에서 인프라를 구성하며, Kratix·KusionStack·KubeVela와 같은 프레임워크는 중간에서 다른 서비스와 유사한 셀프서비스 인터페이스를 통해 LLM 파이프라인을 제공한다.
파이프라인 거버넌스를 위한 실용적인 통제
분석은 플랫폼 팀이 다음과 같은 실용적인 통제를 도입해야 한다고 제안한다.
- 비공식 스크립트가 아닌 관리되는 API: 파인튜닝 작업, 프롬프트 배포, 추론 엔드포인트를 개발자의 다른 요구 사항에 사용하는 동일한 셀프서비스 인터페이스를 통해 요청해야 한다.
- 요청 시점의 정책 적용: 작업을 시작한 뒤 클라우드 서비스 청구서가 나타난 다음이 아니라, 그 전에 비용 한도와 데이터 거주 규칙 및 모델 접근 제어를 검사해야 한다.
- 영향 규모에 비례하는 인간 승인: 모든 프롬프트에 사전 승인이 필요한 것은 아니지만, 고객의 개인 데이터를 처리하거나 독립적인 결정을 내리는 모델에는 승인이 필요할 수 있다.
- 명확한 감사 로그: 변경 사항이 모델·프롬프트·데이터 중 무엇에 관한 것이든, 무엇이 왜 변경되었는지, 누가 승인했는지 또는 무엇을 승인했는지와 같은 질문에 로그가 답할 수 있어야 한다.
저자는 LLM 파이프라인이 플랫폼 역량을 사용하는 또 하나의 자동화된 소비자이며, 인간 개발자나 독립 에이전트가 받는 것과 동일한 보장이 필요하다고 결론 내린다. 이 모델에서 성공하는 팀은 DevOps와 플랫폼 및 MLOps 간의 논쟁에서 한쪽을 선택하지 않는다. 대신 전체 파이프라인을 지속적인 피드백 루프와 함께 버전 관리·모니터링·비용 고려가 가능한 제품으로 다룬다.
이러한 의미에서 브라이언트는 LLMOps가 소유권에 관한 질문을 없애거나 새롭게 발명한다고 보지 않는다. 오히려 모델의 규모와 높은 비용 및 평가의 어려움 때문에 기존 플랫폼에 더 큰 압박을 가한다고 본다. 그의 견해에 따르면 해결책은 표준 경로를 한 번 구축한 뒤, API 또는 공통 사용자 인터페이스를 통해 개발자와 데이터 과학자 및 지능형 에이전트 모두에게 관리되는 역량으로 제공하는 것이다. 그는 이 논의가 CNCF 내부, 특히 TAG App Delivery 산하 Platforms Working Group에서 계속되고 있으며, 기여를 원하는 누구에게나 열려 있다고 언급한다.