GenAI는 놀라울 정도로 짧은 시간에 연구 데모 단계에서 이사회 우선순위 과제로 이동했습니다. 기업들은 LLM을 고객 지원, 검색, 지식 관리 및 내부 워크플로우에 통합하기 위해 경쟁하고 있습니다. 하지만 채택률이 가속화됨에 따라, 이러한 시스템을 안정적으로 운영하는 데 필요한 엔지니어링 관행은 속도를 맞추는 데 어려움을 겪고 있습니다.
문제는 GenAI 애플리케이션을 데모에서 작동하게 만드는 것과 이를 프로덕션 환경에서 신뢰성 있게 실행하는 것은 매우 다르다는 것입니다. 검색 증강 생성(RAG: retrieval-augmented generation) 파이프라인은 조용히 관련 없는 컨텍스트를 반환할 수 있습니다. 프롬프트 변경이나 모델 업데이트는 전통적인 테스트 실패를 유발하지 않으면서 응답 품질을 저하시킬 수 있습니다. 소수의 테스트 쿼리로는 잘 작동하는 애플리케이션이라도 실제 환경 조건에서는 일관성 없는 답변을 생성할 수 있으며, 사용량에 따라 토큰 소비와 추론 비용(inference costs)이 예측 불가능하게 증가합니다. 체계적인 평가 및 모니터링 없이는 이러한 문제들이 사용자나 비즈니스 결과에 영향을 미칠 때까지 감지되지 않을 수 있습니다.
부족한 부분은 GenAI 애플리케이션을 작동하는 프로토타입에서 프로덕션 등급 시스템으로 전환하는 데 필요한 엔지니어링 규율입니다. LLM 호출을 하는 것은 단지 시작점일 뿐입니다. 팀들은 출력 품질을 평가하고, 회귀(regressions)를 감지하며, 실패를 조사하고, 비용을 모니터링하며, 애플리케이션이 발전함에 따라 통제력을 유지할 방법을 필요로 합니다.
본 블로그 게시물에서는 GenAI 애플리케이션을 프로덕션에서 실행하는 데 따르는 어려움과 이를 해결하는 엔지니어링 관행들을 탐구할 것입니다. 여기에는 LLM 출력 평가, 시스템 동작 모니터링부터 변경 사항 관리 및 시간 경과에 따른 신뢰성 유지 방법까지 포함됩니다.
프로덕션에서 GenAI 시스템이 실패하는 이유
AI 애플리케이션 스택 이해하기
LLM은 더 큰 애플리케이션의 단지 하나의 구성 요소일 뿐입니다. 프로덕션 실패는 오래된 검색 데이터부터 오케스트레이션 버그나 인프라 문제에 이르기까지 스택 어디에서든 발생할 수 있습니다. 팀들이 모델을 전체 애플리케이션으로 간주할 때, 이러한 문제는 종종 모델 품질 문제로 잘못 진단됩니다. 일반적인 GenAI 애플리케이션은 다음 레이어들로 구성됩니다:
- 애플리케이션/UX 레이어: 요청이 시스템에 들어오는 방식과 응답이 최종 사용자에게 렌더링되는 방식
- 오케스트레이션 레이어: 다른 레이어 전반의 호출을 순서화하는 프레임워크
- 검색 레이어 (Retrieval layer): 응답의 근거가 되는 지식 기반에 대한 검색 및 랭킹
- 임베딩 레이어 (Embedding layer): 유사성 검색을 위한 문서와 쿼리를 나타내는 벡터
- 벡터 데이터베이스 (Vector database): 저장 및 인덱싱, 자체적인 일관성과 최신성 동작 포함
- 도구/외부 API (Tools/external APIs): 행동을 취하거나 데이터를 가져오기 위해 모델이 호출하는 함수 및 서비스
- LLM 레이어: 모델 자체, 호스팅 또는 API 기반
- 인프라 레이어: 위에 있는 모든 것을 위한 컴퓨트, 네트워킹, 호스팅
[Image - The Hidden Cost of Shipping GenAI Without Production-Grade MLOps ]
각 레이어는 고유의 실패 표면적(failure surface)을 가지고 있으며, 실패는 거의 격리된 상태로 머무르지 않습니다:
- 검색(Retrieval): 오래된 문서(Stale documents)는 모델 자체가 정상적으로 작동하더라도 환각성 답변을 유발할 수 있습니다.
- 오케스트레이션(Orchestration): 라우팅 버그(routing bug)가 쿼리를 잘못된 도구 또는 워크플로우로 전송하여, 모델 품질 문제처럼 보이는 자신감 있지만 부정확한 응답을 생성할 수 있습니다.
- 벡터 인덱스(Vector index): 인덱스가 뒤처지면, 아무도 알아차리지 못하는 사이에 검색 품질이 몇 시간 동안 조용히 저하될 수 있습니다.
- 인프라스트럭처(Infrastructure): 리소스 제약이나 네트워크 장애는 지연 시간(latency)을 증가시키거나 서비스를 사용할 수 없게 만들 수 있습니다.
이러한 실패 사례들은 모델 자체를 검증하는 것만으로는 충분하지 않다는 것을 보여줍니다. GenAI 애플리케이션은 컨텍스트를 공급하고, 실행을 조정하며, 응답을 제공하는 구성 요소를 포함하여 전체 시스템으로 평가 및 모니터링되어야 합니다.
이것이 바로 MLOps와 LLMOps가 중요해지는 지점입니다.
- MLOps는 머신러닝 시스템의 수명 주기 전반에 걸쳐 버전 관리(versioning), 배포(deploying), 모니터링, 관리하는 관행을 제공합니다.
- [LLMOps]는 이러한 관행을 기반으로 구축되어 프롬프트 버전 관리, 출력 품질 평가, RAG 파이프라인 신뢰성, 환각 감지, 토큰 및 추론 비용 관리 등 LLM 기반 애플리케이션의 추가적인 과제들을 다룹니다.
이러한 관행들이 결합되면 팀들은 모델, 프롬프트, 데이터, 종속성(dependencies)이 진화함에 따라 스택 전반의 변경 사항을 추적하고, 회귀(regressions)를 감지하며, 실패를 조사하고, 일관된 동작을 유지하는 데 도움을 받을 수 있습니다. 프로덕션 준비 상태는 모델 자체가 아니라 전체 애플리케이션 스택의 속성입니다.
대규모로 GenAI를 운영할 때의 운영상의 어려움
GenAI 애플리케이션은 전통적인 소프트웨어에서는 거의 마주치지 못하는 도전 과제를 도입합니다. 바로 동일한 입력이 호출마다 다른 출력을 생성할 수 있다는 점입니다.
예를 들어, AI 에이전트에게 실패한 배포를 조사하도록 요청하면, 한 번 실행할 때는 로그를 먼저 확인하고 다른 실행에서는 리소스 사용량이나 구성 변경 사항을 확인할 수 있습니다. 결과는 비슷할 수 있지만, 경로가 매번 달라질 수 있어 테스트와 문제 해결이 더 어려워집니다. 이러한 비결정성(non-determinism)은 몇 가지 다른 실패 모드들과 결합됩니다:
- [프롬프트 드리프트 (Prompt drift)]: 프롬프트에 작은 변경만 가해도 출력이 여러 방식으로 바뀔 수 있습니다. 예를 들어, 응답을 더 짧게 하도록 지침을 변경하는 것이 애플리케이션의 다른 부분이 의존하는 정보를 모델이 건너뛰게 만들 수도 있습니다.
- [모델 업데이트 (Model updates)]: 제공업체 측의 모델 변경은 코드를 전혀 수정하지 않아도 애플리케이션에 영향을 미칠 수 있습니다. 예를 들어, 애플리케이션이 Claude Sonnet 4.6을 중심으로 구축되고 조정되었는데, 제공업체가 해당 버전을 단종시키거나 교체하는 경우, 새 모델이 재테스트와 조정을 필요로 할 만큼 다르게 작동할 수 있습니다.
- 검색 품질 저하 (Retrieval degradation): 지식 기반이 변경됨에 따라 콘텐츠나 임베딩(embeddings)이 더 이상 정렬되지 않으면 검색 품질이 떨어질 수 있습니다. 예를 들어, 대량의 새 문서를 적절하게 재인덱싱(re-indexing)하지 않고 추가하면 시스템이 오래되었거나 관련성이 낮은 정보를 표시할 수 있습니다.
- 데이터 최신성 (Data freshness): 시스템이 더 이상 현재가 아닌 정보에 기반하여 자신감 있는 답변을 제공할 수 있습니다. 예를 들어, 지식 출처가 업데이트되지 않았기 때문에 몇 주 전에 변경된 배포 프로세스를 내부 AI 비서가 추천할 수 있습니다.
- 지연 시간 및 비용 (Latency and cost): 단일 요청이 여러 단계를 유발할 수 있으며, 각 단계마다 시간과 비용을 추가합니다. 예를 들어, 사용자가 응답을 보기 전에 요청은 임베딩 호출(embedding call), 벡터 검색(vector search), 재순위 지정(reranking) 및 다중 LLM 호출을 포함할 수 있습니다.
- 외부 종속성 실패 (External dependency failures): 애플리케이션 외부의 장애도 여전히 프로덕션 사고가 될 수 있습니다.
예를 들어, 모델 제공업체의 장애(outage)나 벡터 데이터베이스의 시간 초과(timeout)는 겉보기에는 정상적인 애플리케이션마저 실패하게 만들 수 있습니다.
이러한 문제들은 오류를 발생시키지 않기 때문에 기존 모니터링으로는 포착하기 어렵습니다.
성능이 저하된 검색 파이프라인은 500 에러를 반환하는 것이 아니라, 더 나쁜 답변을 담아 200 OK로 응답합니다.
인프라 모니터링은 가용성(availability)과 성능 문제 감지에 초점을 맞추었지, 품질(quality) 문제를 감지하도록 설계되지 않았으며, 바로 이 품질 영역에서 GenAI 시스템이 실패하는 경우가 많습니다. 효과적인 LLM 모니터링은 단순히 가동 시간(uptime)뿐만 아니라 답변의 품질을 추적해야 합니다.
기존 DevOps가 부족한 이유
기존 DevOps가 미흡한 이유는 다음과 같습니다:
Image - The Hidden Cost of Shipping GenAI Without Production-Grade MLOps
MLOps를 건너뛰는 것의 숨겨진 비용
신뢰성 및 엔지니어링 비용
버전 관리(versioning), 지속적인 평가(continuous evaluation), 모니터링과 같은 MLOps 관행이 없으면, 팀은 종종 프로덕션 문제를 사후적으로 처리하게 되며, 문제 진단과 해결에 더 많은 엔지니어링 시간을 소비합니다.
- 검증되지 않은 프롬프트 변경, 오래된 문서를 제공하는 검색 파이프라인, 또는 공지되지 않은 모델 회귀(model regression)로 인해 발생한 프로덕션 사고
- 어떤 레이어가 잘못된 출력을 유발했는지, 혹은 수정 조치가 실제로 효과가 있었는지를 확인할 신뢰할 수 있는 방법이 없기 때문에 디버깅이 수동적이고 시간이 많이 걸리는 추측 게임이 됨
- 누구도 그 근거를 기억하지 못하는 프롬프트 형태의 기술 부채, 그리고 측정(measurement)보다는 시행착오로 조정된 검색 설정
각 변경 사항은 테스트할 재현 가능한 기준선(reproducible baseline)이 없기 때문에 본래보다 더 많은 위험을 안고 옵니다.
비즈니스, 운영 및 재정적 영향
엔지니어링 비용은 비즈니스 비용으로 직접 전환됩니다:
- [추론(Inference)] 비용은 기능별 또는 프롬프트 버전별 토큰 사용량에 대한 가시성이 없어 조용히 증가하며, 보통 월간 청구서가 도착했을 때만 드러난다.
- 리소스 활용도는 과도하게 할당된 컴퓨팅 자원이나 눈에 띄지 않는 중복 모델 호출로 인해 손상된다.
- [개발자 생산성(Developer productivity)]은 팀이 다른 문제가 발생하지 않음을 확인할 빠르고 쉬운 방법 없이 프롬프트나 검색 로직을 변경하는 것을 꺼리게 되면서 떨어진다.
- AI 기능이 일관되지 않게 작동하거나 경고 없이 저하될 때 고객 신뢰가 침식되며, 이를 회복하는 데 걸리는 시간은 잃는 데 걸린 시간보다 훨씬 길다.
이러한 비용들은 클라우드 청구서, 출시 지연 또는 고객 불만으로 나타날 때까지 눈에 띄지 않는 경우가 많다. 이는 평가(evaluation), 모니터링(monitoring) 및 효과적인 관리에 필요한 [비용 통제(cost controls)] 없이 확률적이고 다층적인 시스템을 운영하기 때문에 발생한다. 개발 중의 지름길로 시작한 것이 프로덕션 환경에서는 값비싼 문제가 될 수 있다.
신뢰할 수 있는 GenAI를 위한 프로덕션 등급 MLOps
전체 AI 라이프사이클 관리
신뢰성의 출발점은 시스템에 데이터를 공급하는 데이터 및 지식 소스부터 모델, 프롬프트, 검색 구성(retrieval configuration), 평가, 그리고 프로덕션 모니터링에 이르기까지 전체 AI 라이프사이클을 관리하는 것이다.
- 데이터 및 지식 준비(Data and knowledge preparation): 소스 데이터를 시스템의 지식 기반 일부로 사용하기 전에 수집하고, 정리하며, 검증하고, 최신 상태로 유지해야 합니다.
- 버전 관리(Versioning): 프롬프트, 데이터셋, 임베딩, 평가 세트, 모델 모두 애플리케이션 코드와 마찬가지로 변경 이력 및 롤백 기능이 필요합니다.
- 실험 추적(Experiment tracking): 결과는 해당 결과를 생성한 아티팩트 버전의 정확한 조합과 연결되어야 하므로, 실험이 비교 가능하고 재현 가능하게 유지됩니다.
- 배포 파이프라인(Deployment pipelines): 프롬프트, 모델 및 검색 구성의 변경 사항은 프로덕션 환경에 도달하기 전에 자동화된 평가를 거쳐야 합니다.
이러한 단계들은 이전 게시물에서 다룬 MLOps의 기본 원칙을 기반으로 하며, 여기서는 GenAI가 도입하는 추가적인 아티팩트와 실패 모드를 고려하여 확장되었습니다.
지속적인 평가 및 AI 관측 가능성 (Continuous evaluation and AI observability)
AI 라이프사이클 관리(AI lifecycle management)는 팀에게 배포되는 것에 대한 통제권을 제공합니다. 지속적인 평가는 배포된 것이 실제로 좋은지 알려줍니다. 이는 단순히 유효한 응답을 반환하는지 여부가 아니라, 시스템이 유용한지를 결정하는 차원을 측정한다는 의미입니다:
- 환각률(Hallucination rate)
- 검색 품질(Retrieval quality)
- 검색된 컨텍스트에 대한 근거성(Groundedness against retrieved context)
- 사용자 질의와의 관련성(Relevance to the user's query)
- 상호작용당 지연 시간 및 비용(Latency and cost per interaction)