LLMOps Lifecycle & Stack
LLMOps (Large Language Model Operations)는 LLM을 생산 환경에서 안정적·안전하게·비용 효율적으로 운영하는 학문이다. MLOps와 다르다: MLOps는 모델 학습, LLMOps는 모델 출력의 운영에 초점.
설명
LLMOps vs MLOps vs DevOps
| 분야 | 핵심 대상 | 주요 활동 | 주요 위험 |
|---|---|---|---|
| DevOps | 코드 배포 | CI/CD, 인프라 | 다운타임, 보안 |
| MLOps | 모델 학습 | 데이터 파이프라인, 재학습 | 모델 드리프트 |
| LLMOps | 프롬프트·출력 | 버전관리, 평가, 가드레일 | 환각, 주입 공격, 비용 폭발 |
| AIOps | IT 운영 자동화 | 이상 탐지 | 오탐지 |
핵심 차이: LLM은 API로 소비하는 사전학습 모델이므로, 학습 파이프라인이 없다. 대신 프롬프트 버전관리·출력 평가·가드레일·비용 제어가 핵심.
7단계 LLMOps Lifecycle
Stage 1: 유스케이스 정의 & 모델 선택
- 비즈니스 목표 정의 (e.g., 고객 지원 자동화)
- 수용 가능한 품질 기준 설정
- 레이턴시 요구사항 (e.g., <2초 응답)
- 데이터 거주 요구사항 (e.g., EU only)
- Model Card 작성: 왜 이 모델을 선택했나?
Stage 2: 프롬프트 엔지니어링 & 버전관리
- 시스템 프롬프트 (역할 정의)
- Few-shot examples (예제)
- Output format spec (JSON, Markdown 등)
- Chain-of-Thought 패턴
필수: 모든 프롬프트는 Git 또는 PromptLayer에서 버전관리 테스트셋: 50-200개 대표 입력 사전 준비
Stage 3: 배포 & 통합
- 목표 시스템에 통합 (API, 챗봇, CRM)
- Day-1 Instrumentation (필수):
- 입력 토큰·출력 토큰
- 레이턴시
- 모델 버전
- Trace ID (디버깅용)
- 비용 알림 설정
Stage 4: 모니터링 & 옵저버빌리티
- Metrics: 평균 레이턴시, 비용/요청, 에러율
- Observability: 개별 요청의 trace-level 디버깅
- 구분: 모니터링 = “시스템 건강한가?”, 옵저버빌리티 = “왜 이 요청이 실패했나?”
Stage 5: 평가 & 품질 보증
- 자동화된 평가 (매번 프롬프트/모델 변경 시)
- 평가 지표: Faithfulness, Relevance, Format compliance
- 인간 검증: 수상한 출력의 5-10% 주간 샘플링
Stage 6: 비용 & 레이턴시 최적화
- Semantic caching: 유사 쿼리 캐시 → 30-50% 비용 절감
- Model routing: 단순 요청은 저비용 모델 (GPT-4o mini)로 → 40-70% 절감
- Prompt compression: 불필요한 토큰 제거
- max_tokens 제한: 장황한 답변 방지
효과: 보통 40-60% API 비용 절감 (품질 손상 없음)
Stage 7: 거버넌스, 규정준수, 사건 대응
- Data handling policy: 어떤 PII를 모델에 전달할 수 있나?
- Audit trail: 모든 AI 생성 출력의 로그
- Bias & fairness review: 분기 1회 감시
- Incident runbook: 비용 폭발·품질 저하·PII 유출·주입 공격 시 대응
5계층 Production Stack
모든 production LLM은 5계층이 필요하다. (각 계층에 뭔가는 필요)
┌─────────────────────────────────────┐
│ Application (Chatbot, API, CRM) │
├─────────────────────────────────────┤
│ 1. Gateway Layer │ ← LiteLLM, Portkey
│ (routing, load balance, fallback)│
├─────────────────────────────────────┤
│ 2. Safety Layer │ ← Guardrails AI, NeMo
│ (PII, injection, toxicity) │
├─────────────────────────────────────┤
│ 3. Caching Layer │ ← GPTCache, Redis Vector
│ (semantic cache for similarity) │
├─────────────────────────────────────┤
│ 4. Observability Layer │ ← LangSmith, Phoenix
│ (tracing, metrics, dashboards) │
├─────────────────────────────────────┤
│ 5. Governance Layer │ ← PromptLayer, Git
│ (versioning, audit, compliance) │
├─────────────────────────────────────┤
│ LLM APIs (OpenAI, Anthropic, etc) │
└─────────────────────────────────────┘
Best Practices 10가지
- 프롬프트를 코드처럼 취급 — Git에서 버전관리, changelog 유지
- 배포 전 기준선 평가 — 무엇이 “좋음”인지 정의 후 배포
- 먼저 기록, 나중에 최적화 — Day-1 instrumentation이 나중에 디버깅을 10배 빠르게 함
- 비용 상한은 provider에서 — 코드 버그도 survive
- Dual guardrails — 입력 + 출력 (하나만으로는 부족)
- Provider model update 시 자동 평가 — 침묵한 모델 변경이 품질 저하의 #1 원인
- 복잡도별 라우팅 — 습관적으로 최고급 모델 사용하지 말 것 (40-70% 절감 가능)
- Semantic 캐싱 — Literal matching은 유사 표현 못 잡음
- Model card 작성 — 왜 선택했나, 제약사항, 금지 사용
- 사건 runbook 미리 쓰기 — 비용 폭발·품질 저하·PII 유출·주입 공격 (4가지)
관련 개념
- recommendation-system-architecture — 추천 모델 운영 시 LLMOps 적용
- agentic-ai-patterns — 에이전틱 시스템의 모니터링·평가
- ai-governance-and-compliance — LLMOps의 거버넌스·규정 계층