DevOps와 생성형 AI의 만남: LLM 기반 애플리케이션의 구축, 테스트 및 배포

지난 봄, OpenAI는 모델을 신뢰하기 어렵게 만드는 GPT-4o 업데이트를 출시했습니다. 사용자의 프롬프트(Prompt)나 워크플로우(Workflow)에 아무런 변화가 없었음에도 불구하고, 모델이 평소보다 아첨하는 듯한 태도를 보이거나 신뢰도가 낮은 답변을 내놓았습니다. LLM 시스템이 운영 환경(Production)에서 드리프트(Drift) 현상을 보이기 시작할 때, 배포 이력(Deployment history)으로는 이를 조기에 포착할 수 없습니다. 코드베이스(Codebase)에 변경 사항이 없었고, 제공업체(Provider) 측에서도 공식적인 업데이트를 발표하지 않았기 때문입니다. 한편, 일부 제공업체는 통지 없이 분류기(Classifier)를 조정했을 수도 있으며, 어제까지 잘 작동하던 요청이 내일은 자신 있게 틀린 답변을 반환하기 시작할 수 있습니다. 만약 여러분이 이미 전달 파이프라인(Delivery pipelines)을 운영하고 있다면, 이 전체 과정이 익숙하게 느껴질 것입니다. 하지만 LLM 파이프라인은 다른 종류의 릴리스 객체(Release object)를 가집니다. 메인 코드베이스를 전혀 건드리지 않았더라도 프롬프트(Prompt), 모델 버전(Model version), 또는 가드레일(Guardrail)의 미세한 변화가 시스템 동작을 바꿀 수 있기 때문입니다.

LLM 운영 동작을 결정짓는 요소들
애플리케이션 코드는 주의 깊게 버전 관리(Versioning)가 되지만, 프롬프트, 검색 설정(Retrieval settings), 가드레일의 변경은 종종 공식적인 기록 없이 발생하며, 이로 인해 모델 동작의 드리프트(Drift)를 정확히 무엇이 유발했는지 식별하기가 더 어려워집니다.

• 프롬프트 (Prompts)
  때때로 성능 저하(Regression)의 원인은 시스템 프롬프트(System prompt)의 미세한 변경 때문입니다. 누군가 하나의 에지 케이스(Edge case)를 겨냥해 문장을 수정하면, 전혀 관련 없는 쿼리 카테고리(Query category)의 성능이 예상치 못하게 떨어지기 시작합니다. 이는 여러 사람이 프롬프트를 직접 수정할 수 있고, 그 수정 사항이 릴리스 기록(Release record)에 남지 않을 때 발생합니다.

• 모델 버전 (Model versions)
  2025년 5월, Google은 두 개의 오래된 Gemini 엔드포인트(Endpoints)를 통지 없이 더 새로운 모델로 리다이렉트(Redirect)했습니다. gemini-2.5-pro-preview-03-25를 기반으로 개발하던 개발자들은 소프트웨어가 전날과 다르게 동작한다는 사실을 알게 되었습니다. 이후 Google은 문서(Documentation)를 업데이트하여 다양한 엔드포인트 유형에 대해 '안정(Stable)'과 '프리뷰(Preview)'가 무엇을 의미하는지 명확히 했습니다. 만약 앱이 이상하게 작동한다면, 제공업체가 통지 없이 모델을 업데이트했을 수 있습니다. 따라서 API 응답에 정확히 어떤 모델 버전이 표시되는지 확인해 볼 가치가 있습니다.

• 검색 설정 및 소스 데이터 (Retrieval configuration and source data): RAG (Retrieval-Augmented Generation) 시스템에서는 인덱스 (Index)가 오래되었거나 누군가 청킹 (Chunking), 랭커 (Ranker), Top-k, 또는 임베딩 모델 (Embedding model)을 변경했기 때문에 답변이 드리프트 (Drift)될 수 있습니다. 이 중 그 어떤 것도 애플리케이션이 에러를 발생시키도록 요구하지 않습니다. 결과적으로, 지식 베이스 (Knowledgebase)가 인덱스 갱신 없이 업데이트되었기 때문에 금융 보고 보조 도구가 오래된 분기 보고서의 수치를 인용하기 시작할 수 있습니다.

• • 가드레일 (Guardrails): 가드레일 규칙은 종종 메인 앱 출시 프로세스 외부에서 관리됩니다. 컴플라이언스 (Compliance) 팀이 별도의 콘솔에서 거부 규칙을 강화하면, 엔지니어링 측면에서 아무런 변경이 없었음에도 앱이 기존에 잘 작동하던 쿼리 (Query)를 거부하기 시작할 수 있습니다.

• 평가 (Evaluation): 제품 출시 시점에 구축된 테스트 세트 (Test set)는 제품이 진화함에 따라 자동으로 업데이트되지 않습니다. 모델은 평가를 계속 통과할 수 있지만, 실제 운영 환경은 이미 변했을 수 있습니다. 즉, 쿼리 혼합 (Query mix)이 변화하여 출시 당시에는 드물었던 케이스들이 이제 업무량의 상당 부분을 차지하게 된 경우입니다.

배포 파이프라인 구축하기 (Building the delivery pipeline)
전통적인 소프트웨어 배포에서 출시 범위 (Release surface)는 대부분 코드입니다. LLM 시스템에서는 프롬프트 (Prompts), 모델 버전 (Model versions), 검색 설정 (Retrieval configuration), 그리고 가드레일 (Guardrails)까지 확장됩니다. 이 구성 요소들은 애플리케이션만큼이나 운영 동작에 큰 영향을 미치지만, 동일한 출시 제어를 받는 경우는 드뭅니다.

출시가 배포하기에 충분히 괜찮은 시점인지 알기 (Knowing when a release is good enough to ship)
전통적인 출시에서는 소프트웨어가 올바르게 실행되는지 확인해야 합니다. LLM 시스템을 배포할 때는 운영 환경에서 마주하게 될 전체 입력 범위에 대해 시스템이 수용 가능하고 안전하게 동작하는지 확인해야 합니다.

골든 프롬프트 (Golden prompts): 이는 시스템이 수행해야 하는 역할을 반영하는 고정된 테스트 케이스입니다. 고객 지원 보조 도구의 경우, 이슈를 정확히 식별했는지, 올바른 지원 문서를 안내했는지, 내용을 지어내는 것을 피했는지, 그리고 필요한 경우 에스컬레이션 (Escalation)을 수행했는지 등을 확인합니다. 출시를 준비할 때, 각 골든 프롬프트는 평가 전에 정의된 합격/불합격 (Pass/fail) 기준에 따라 이러한 차원들을 기준으로 검사됩니다.

일부 검사는 자동화할 수 있지만, 모호하거나 사용자에게 직접 노출되거나 위험도가 높은 출력물은 여전히 사람의 주의가 필요합니다. 모든 실패가 동일하게 중요한 것은 아닙니다. 에스컬레이션(Escalation) 실패나 잘못된 인용(Citation)은 즉시 출시를 차단하지만, 트래픽이 적은 쿼리에 대한 약간의 어색한 문구는 아마도 그렇지 않을 것입니다. 베이스라인 비교(Baseline comparison) 평가 점수(Eval scores)는 보이는 것보다 덜 안정적입니다. 프롬프트 민감도(Prompt sensitivity)에 관한 한 연구에 따르면, 의미의 변화 없이 서식(Formatting) 차이만으로도 정확도가 최대 76%까지 휘청이는 것이 발견되었습니다. 이것이 바로 모든 후보 출시 버전(Candidate release)을 운영 버전(Production version)과 비교하여 측정해야 하는 이유입니다. 이러한 참조 기준이 없다면, 높은 점수조차 이미 실행 중인 버전보다 퇴보(Regression)한 결과일 수 있습니다. 통제된 출시(Controlled rollout) 단계적 배포(Staged deployment) 전략을 사용하면 완전히 확정하기 전에 운영 환경에서 출시 버전을 검증할 수 있습니다. 섀도 테스트(Shadow testing)는 현재 버전과 새 버전 모두에 사용자 요청을 병렬로 보내되, 사용자는 현재 버전의 응답만 볼 수 있게 합니다. 카나리 테스트(Canary testing)는 여기서 더 나아가 소수의 실제 사용자에게 새 버전의 응답을 보여줍니다. 문제가 발생하면 적은 트래픽에서 이를 포착하고 더 확산되기 전에 롤백(Roll back)할 수 있습니다. 시작하기 전에 '문제가 발생했다'는 것이 무엇을 의미하는지(응답 품질 저하, 거부 응답 증가, 또는 쿼리당 비용 상승 등)를 미리 결정하십시오. 버전 관리(Versioning) 품질 게이트(Quality gate)의 가치는 그 뒤에 있는 출시 기록(Release record)에 달려 있습니다. 기록에 실제 적용되는 프롬프트, 검색(Retrieval) 또는 가드레일(Guardrail) 설정, 평가 세트(Eval set), 임베딩 모델(Embedding model)의 정확한 버전이 포함되어 있지 않다면, 지난주의 설정을 테스트하고 있는 것일 수도 있습니다. 이들 중 어느 하나라도 변경되면 재평가(Reevaluation)를 트리거해야 합니다. 단 한 번의 수정만으로도 전체 구조가 깨질 수 있기 때문입니다. 이점(Gains)을 잃지 않고 배포하기 모든 품질 게이트를 통과한다고 해서 원활한 출시가 보장되는 것은 아닙니다. 추론 워크로드(Inference workloads)는 동시성(Concurrency) 문제로 인해 표준 웹 애플리케이션과는 다른 방식으로 실패하며, 하드웨어를 추가한다고 해서 제공업체 측의 속도 제한(Rate limits)이나 긴 컨텍스트(Long-context) 요청으로 인해 쌓이는 대기열(Queue)로 인한 병목 현상이 해결되지는 않습니다.

비용 동작(Cost behavior) 또한 단순히 토큰 과금(Token billing)만으로 예측하는 것보다 더 까다롭습니다. 긴 대화에서의 컨텍스트 성장(Context growth), 검색 페이로드(Retrieval payloads), 도구 호출 재귀(Tool-call recursion), 그리고 실패한 호출에 대한 재시도 루프(Retry loops)가 모두 복합적으로 작용하여, 실제 운영 중인 생성형 AI(GenAI) 배포 환경에서는 추론(Inference) 비용이 총 소유 비용(Total cost of ownership, TCO)의 80~90%를 차지하게 됩니다. 추론 비용을 절감하는 방법 중 하나는 쿼리 라우팅(Query routing)입니다. 일상적인 조회는 결정론적 검색(Deterministic search)이나 규칙 기반 로직(Rule-based logic)을 통해 실행하는 것이 더 빠르고 저렴합니다.

실제 운영 시 신뢰성 유지: 시스템이 운영 환경(Production)에 진입하면, 질문은 '시스템이 올바르게 동작하는가'에서 '시스템이 언제 동작을 멈추는지 알고 있는가'로 전환됩니다. 제공업체의 업데이트(Provider update), 가드레일 조정(Guardrail adjustment), 또는 사용자의 요청 방식 변경과 같이 운영 중인 LLM의 동작에 영향을 미치는 요인들은 항상 명확한 신호를 남기지는 않으며, 과제는 사용자가 인지하기 전에 이러한 변화를 더 빨리 포착하는 것입니다.

중요한 요소 모니터링: 재시도 횟수(Retry volume)나 경로 변화(Path shifts)와 같은 특정 지표를 통해 도구 사용(Tool-use) 문제를 조기에 발견할 수 있지만, 이러한 신호는 대개 청구서가 도착하고 사용자들이 불만을 제기하기 시작할 때 비로소 눈에 띄게 됩니다. 비용 증가는 서서히 누적되기 때문에 이를 모니터링 문제로 간과하기 쉽습니다. Azure의 문서에 따르면 콘텐츠 필터 거부(Content filter rejections) 및 타임아웃(Timeout)은 처리에 실패하더라도 비용이 청구됩니다. 따라서 쿼리당 비용, 워크플로우당 비용, 토큰 성장률, 재시도 지출과 같은 비용 임계값(Cost thresholds)을 사전에 모니터링해야 합니다.

인간의 판단이 개입되는 영역: 자동화된 평가(Automated evaluation)가 많은 부분을 잡아내지만, 인간이 알아차릴 수 있는 것들을 놓치기도 합니다. 시스템은 확신에 찬 오답을 건너뛸 수 있는 반면, 실제 출력을 지속적으로 관찰하는 인간은 시스템이 특정 유형의 요청을 일관되게 잘못 처리하는 패턴이나, 그럴듯하지만 틀린 답변(Plausible but wrong answers)이 빈번해지는 패턴을 발견할 수 있습니다.

소유권, 의사결정 및 책임: LLM 시스템의 거버넌스(Governance)는 대개 동일한 이유로 조용히 실패하는 경향이 있습니다. 누가 배포를 차단할 수 있는가? 무엇을 운영 장애(Production incident)로 간주할 것인가? 아무도 요청하지 않은 제공업체의 업데이트 이후 출력 품질이 저하되면 어떤 일이 발생하는가?

애플리케이션, 사용자 경험 (User Experience), 가드레일 (Guardrails), 그리고 평가 세트 (Eval set)에 대한 책임이 서로 다른 부서에 분산되어 있을 때, 이러한 질문들은 종종 답을 얻지 못한 채 남겨집니다. 결과적으로 코드베이스(Codebase)에 흔적도 남지 않은 채 무언가 고장 났을 때, 해당 회귀 (Regression)가 허용 가능한 수준인지 아니면 장애 (Incident)로 선언해야 하는지를 결정할 지정된 담당자가 없게 됩니다.

실제 사례
한 고객사의 기업 성과 관리 플랫폼은 속도가 느리고 비용이 많이 들며 디버깅 (Debugging)이 어려웠습니다. 두 가지 문제가 서로를 악화시키고 있었습니다. 첫 번째는 라우팅 (Routing) 문제였습니다. 데이터베이스 호출 (Database call)로 처리할 수 있는 간단한 쿼리들이 복잡한 분석 작업처럼 LLM에 의해 처리되고 있었습니다. 내부 벤치마킹 (Benchmarking)에 따르면, 데이터베이스 호출을 사용했을 경우 비용은 약 40배 저렴하고 속도는 10배 더 빨랐을 것입니다. 두 번째는 추적 가능성 (Traceability) 문제였습니다. 플랫폼이 각 최종 고객마다 별도의 ML 모델로 구축되어 있었기 때문에, 출력이 저하되었을 때 그것이 모델 때문인지, 검색 (Retrieval) 설정 때문인지, 아니면 다른 요인 때문인지 판단할 수 있는 신뢰할 수 있는 방법이 없었습니다.

우리가 변경한 사항
우리는 고객별 모델 아키텍처 (Architecture)를 공유 벡터 검색 (Vector search) 기반으로 교체하였고, 규칙 기반 라우팅 (Rule-based routing)을 추가하여 간단한 조회는 데이터베이스로, 복잡한 요청은 LLM으로 전달하도록 했습니다. 복잡한 요청을 처리하기 위해 고객 데이터를 사용하여 여러 모델(GPT-4, GPT-4o, GPT-4o-mini, Mistral, Mixtral)을 테스트했습니다. GPT-4o-mini는 더 낮은 비용으로 GPT-4o의 효과와 맞먹는 가장 좋은 균형을 제공했습니다. 모든 프롬프트 (Prompts), 검색 (Retrieval) 설정, 그리고 가드레일 (Guardrails)은 버전 관리 (Versioned)되었으며, 이를 통해 일관된 벤치마크를 바탕으로 각 릴리스 후보 (Release candidate)를 평가할 수 있게 되었습니다. 라우팅 계층 (Routing layer)을 위해 자체 테스트 세트와 회귀 체크 (Regression checks)를 개발하였고, 사용자 쿼리가 진화함에 따라 주기적인 재보정 (Recalibration)을 구성했습니다. 하이브리드 아키텍처 (Hybrid architecture)가 더 단순해진 것은 아니었지만, 테스트가 가능하고 버전 관리가 가능해졌기에 기존 방식보다 관리하기가 더 쉬워졌습니다.

결과
워크로드 (Workload) 유형에 따라 LLM 사용량이 37-46% 감소했으며, 간단한 조회에 대한 지연 시간 (Latency)은 32-38% 개선되었습니다. 부적절하거나 오도하는 것으로 분류된 출력은 68% 감소했습니다.

수동 조정 작업(Manual reconciliation work, 분석가가 출력 오류를 찾아내고 수정하는 데 소비하는 시간)은 58% 감소했습니다. 결론: 성공적인 데모와 첫 번째 운영 장애(Production incident) 사이의 어딘가에는 운영상의 격차가 명확해지는 순간이 대개 존재합니다. 유용한 시작점은 다음과 같습니다. 만약 오늘 귀하의 현재 시스템에 문제(출력 저하, 동작 변화, 비용 급증 등)가 발생한다면, 모델, 프롬프트(Prompt), 검색(Retrieval) 설정, 그리고 소스 데이터의 어떤 조합이 그 문제를 일으켰는지 한 시간 이내에 파악할 수 있습니까? 만약 대답이 '아니오'라면, 바로 그 지점부터 시작해야 합니다. 현재 시스템에 대해 해당 진단을 실행하고 싶다면, 저희가 기꺼이 함께하겠습니다. 운영 환경에서 귀하의 LLM 시스템을 더 신뢰할 수 있고, 확장 가능하며, 비용 효율적으로 만들고 싶으신가요? 블로그에서 LLM 및 DevOps에 관한 저희의 기사들을 읽어보세요 👉 https://sciforce.solutions/blog?tag=LLM&tag=dev-ops