LLMOps 완전 가이드: 모델·프롬프트·평가셋 3축 버전 관리, Canary, 비용 통제, 플랫폼 팀 (2025)

Season 4 Ep 11 — Ep 10이 "지키는 축"이었다면 Ep 11은 "지속 가능하게 돌리는 축". "첫 릴리스까지 1주일, 그 다음 1년은 지옥"을 피하는 방법.

• Prologue — "LLMOps는 MLOps인가 DevOps인가?"
• 1장 · 3축 버전 관리
  • 1.1 축들
  • 1.2 릴리스 메타데이터
  • 1.3 로그와 연결
• 2장 · 배포 전략
  • 2.1 Shadow
  • 2.2 Canary
  • 2.3 Blue-Green
  • 2.4 A/B 실험
  • 2.5 Percentage Router
• 3장 · 비용 통제
  • 3.1 토큰 감사
  • 3.2 캐싱
  • 3.3 모델 라우팅
  • 3.4 토큰 다이어트
  • 3.5 저장·네트워크
  • 3.6 현실적 절감 목표
• 4장 · 플랫폼 팀 구성
  • 4.1 3계층
  • 4.2 인터페이스
  • 4.3 규모별
  • 4.4 정치적 함정
• 5장 · 평가 하네스 — LLMOps의 심장
  • 5.1 평가셋 버저닝
  • 5.2 CI 통합
  • 5.3 On-demand 실험
  • 5.4 프로덕션 피드백 루프
• 6장 · 관측성과 운영
  • 6.1 Ep 6 연장
  • 6.2 핵심 대시보드
  • 6.3 온콜
  • 6.4 벤더 장애 대비
• 7장 · 데이터 거버넌스
  • 7.1 데이터 분류
  • 7.2 사용자 동의
  • 7.3 PII 처리
  • 7.4 라이선스
• 8장 · 실패 사례 10선
  • 8.1 토큰 폭주
  • 8.2 프롬프트 롤백 불가
  • 8.3 모델 deprecation
  • 8.4 한 지역 장애로 전체 다운
  • 8.5 RAG 인덱스 드리프트
  • 8.6 사용자 로그 과보유
  • 8.7 프롬프트 인젝션
  • 8.8 False refusal 폭증
  • 8.9 벡터 DB 비용 폭주
  • 8.10 A/B 결과 해석 오류
• 9장 · KPI·OKR
  • 9.1 제품 KPI
  • 9.2 엔지니어링 KPI
  • 9.3 AI Quality KPI
  • 9.4 운영 KPI
• 10장 · 한국·아시아 환경
  • 10.1 클라우드
  • 10.2 공급사 다각화
  • 10.3 직원 교육·문화
• 11장 · 공구 모음 (2025)
  • 11.1 게이트웨이·라우팅
  • 11.2 관측성
  • 11.3 평가
  • 11.4 프롬프트 레지스트리
  • 11.5 데이터/피처
  • 11.6 서빙
  • 11.7 가드레일·보안
  • 11.8 비용·자원
• 12장 · 안티패턴 10선
  • 12.1 모델만 바꾸고 배포
  • 12.2 단일 벤더 의존
  • 12.3 프롬프트 Git 외부에
  • 12.4 Shadow·Canary 미사용
  • 12.5 비용 대시보드 없음
  • 12.6 Eval set과 훈련 데이터 섞임
  • 12.7 벤더 장애에 대응 계획 없음
  • 12.8 AI Platform 팀 과대권력
  • 12.9 규제·감사 감안 없음
  • 12.10 Postmortem 미작성
• 13장 · 체크리스트 — LLMOps 런칭 전 12가지
• 14장 · 다음 글 예고 — Season 4 Ep 12: "AI 제품 디자인"

Prologue — "LLMOps는 MLOps인가 DevOps인가?"

둘 다이고, 둘 다 아니다.

• MLOps와 달리 모델 학습은 드물다 (사용하는 건 호스팅 API나 어댑터)
• DevOps와 달리 결과가 확률적이라 테스트가 어렵다
• 하지만 배포·관측·롤백·비용 통제는 둘의 교훈이 전부 필요

2025년 LLMOps의 핵심 질문:

1. 3축 버전 관리(모델·프롬프트·평가셋)를 어떻게 일관되게 관리?
2. 비용: 토큰 낭비를 어떻게 찾고 줄일까?
3. 조직: AI 플랫폼 팀 vs 제품 팀의 경계는?
4. 규제·감사: 모든 배포·변경의 흔적을 어떻게 남길까?

1장 · 3축 버전 관리

1.1 축들

• Model: gpt-4o-2025-03-15, claude-3.7-sonnet, qwen2.5-14b-awq 등
• Prompt: 시스템 프롬프트의 Git/레지스트리 버전
• Eval set: 각 릴리스에 연결된 평가셋 스냅샷

1.2 릴리스 메타데이터

release: v1.4.2
model: anthropic/claude-3.5-sonnet-2025-02
prompt_version: sales_copilot@v23
eval_set: v12 (scored 91.3/100)
adapters:
  - korean_tone_lora@v3
guardrails:
  - llama_guard@v1
  - custom_policy@v8
rollout:
  canary: 5%

모든 릴리스에 이 메타데이터가 불변으로 고정돼야 함.

1.3 로그와 연결

• 각 요청 로그에 release_id 포함
• 나중에 "이 응답이 어느 설정에서 나왔는지" 100% 재현 가능
• 규제 감사의 최소 요구사항

2장 · 배포 전략

2.1 Shadow

• 새 버전을 프로덕션 트래픽에 병렬로 호출(응답은 사용하지 않음)
• 기존 응답과 diff·지표 비교
• 사용자 영향 없이 회귀·개선 확인

2.2 Canary

• 1–5% → 10% → 50% → 100% 순차 확대
• 각 단계에서 자동 게이트(평가셋 점수, p95 지연, 에러율)
• 실패 시 즉시 이전 버전으로 롤백

2.3 Blue-Green

• 두 환경(Blue 운영, Green 대기)에 각각 구 버전/신 버전
• 전환은 로드밸런서 스위칭
• 롤백 즉시(초 단위)

2.4 A/B 실험

• 통계적 유의성 확보(표본·기간)
• 지표: Quality, Cost, Latency, User satisfaction
• 엔드유저 구분(사용자/기업 기반)

2.5 Percentage Router

• 작은 LLM gateway 서비스가 사용자/조직/기능별로 트래픽 분할
• 토글로 즉시 버전 변경 가능
• Helicone, Portkey, Martian, LiteLLM 등 오픈/SaaS 게이트웨이

3장 · 비용 통제

3.1 토큰 감사

• 요청별 input/output 토큰 기록
• 사용자·기능·엔드포인트별 집계
• 상위 비용 엔드포인트·프롬프트 주간 리뷰

3.2 캐싱

• 프롬프트 캐시: Anthropic·OpenAI·Google 네이티브
• 응답 캐시: 동일/유사 입력에 대해 이전 응답 재사용
• RAG 검색 캐시: 쿼리 → 문서 매핑 캐싱

3.3 모델 라우팅

• 간단 질의 → 작은 모델 → 복잡 질의 → 큰 모델
• 라우터 자체가 분류기(LoRA 혹은 규칙)
• 2025년 Martian·RouteLLM 같은 오픈 라우터 부상

3.4 토큰 다이어트

• 시스템 프롬프트 지속 감량
• RAG에 넣는 문서 수 최적화
• JSON 응답 필드 필수/선택 구분
• Structured Output(Ep 2)으로 낭비 제거

3.5 저장·네트워크

• 로그 장기 보관은 cold storage
• 벡터 DB 인덱스 압축·파티셔닝
• 크로스 리전 전송 최소화

3.6 현실적 절감 목표

• 첫 3개월: 20–40% (저렴한 과일)
• 6개월 차: 추가 15–30% (모델 라우팅·캐시 고도화)
• 이후: 5–10% 유지 개선

4장 · 플랫폼 팀 구성

4.1 3계층

• Foundation / Infra: GPU·모델 서빙·관측 인프라
• AI Platform: 공용 SDK·프롬프트 레지스트리·평가 하네스·가드레일
• Product AI: 각 제품의 기능 구현(챗봇·RAG·에이전트·음성 등)

4.2 인터페이스

• AI Platform → Product AI: 사용하기 쉬운 SDK + 표준 관측성
• Infra → AI Platform: 안정된 서빙·비용 대시보드
• 각 경계는 SLA + 온콜이 있는 API처럼 관리

4.3 규모별

• 스타트업 10–50명: 팀 분리 없이 "AI 책임자 1–2인 + 제품 엔지니어"
• 중견 50–500명: AI Platform 5–15명, 제품별 AI owner
• 대기업 500+: 3계층 전부 분리, 보안·규제 별도 팀

4.4 정치적 함정

• "모든 AI는 우리 팀에" → 병목
• "제품마다 자체 AI 인프라" → 중복 낭비
• 중도: 공통 플랫폼 + 제품 자율이 2025년 지배적 모델

5장 · 평가 하네스 — LLMOps의 심장

5.1 평가셋 버저닝

• Git LFS 또는 데이터 레지스트리(DVC, Hugging Face Datasets, S3 + 메타)
• 각 평가셋에 버전·스키마·라벨러·생성일
• 훈련 데이터와 엄격히 분리

5.2 CI 통합

• PR마다 경량 평가셋 자동 실행
• 머지 후 대형 평가셋 비동기 실행
• 회귀 감지 시 Slack/Discord 알림

5.3 On-demand 실험

• 새 모델 후보·프롬프트 변형을 즉시 평가
• 비용·결과 비교 대시보드
• 병렬 실험(여러 변형 동시)

5.4 프로덕션 피드백 루프

• 사용자 thumbs → 라벨 후보
• 라벨러 검수 → 평가셋 추가
• 월간 "사고 케이스 통합 릴리스"

6장 · 관측성과 운영

6.1 Ep 6 연장

• Trace/Span/Metric 3층
• OpenTelemetry 기반
• LangFuse/LangSmith/Phoenix/Helicone/W&B

6.2 핵심 대시보드

• 품질: 평가셋 점수 추이, thumbs up/down
• 비용: 일/월 합계, 기능별, 사용자별
• 지연: p50/p95/p99, TTFT, TTL
• 안전: 공격 시도, 거부율, false refusal
• 에러: 상태별, 벤더별, 재시도율

6.3 온콜

• 주요 지표 SLI/SLO 정의
• 알림 등급(P1/P2/P3)
• Runbook: 공급사 장애, 비용 폭주, 품질 회귀
• 사고 후 Postmortem 24–72h

6.4 벤더 장애 대비

• 멀티 프로바이더 라우팅(OpenAI 장애 → Anthropic으로 자동 폴백)
• 로컬 모델 최소 기능 모드
• 에스컬레이션 경로 명확

7장 · 데이터 거버넌스

7.1 데이터 분류

• Public / Internal / Confidential / PII / Regulated
• 각 등급별 모델·벤더·로그 보유 정책
• 자동 분류기(DLP) 활용

7.2 사용자 동의

• AI 사용 고지, 로그 보유 범위 투명
• 삭제·제공 요청 API
• GDPR·개인정보보호법 준수

7.3 PII 처리

• 입력 시 PII 탐지→마스킹/대체(pseudonymize)
• 출력 시 재마스킹
• 감사 로그는 해시로만

7.4 라이선스

• 합성 데이터 생성 모델 약관
• 서드파티 데이터 사용 계약
• 사용자 저작권 대응 (RAG 검색 결과 인용)

8장 · 실패 사례 10선

8.1 토큰 폭주

시스템 프롬프트 3000→8000 토큰 업데이트 후 비용 급증.

8.2 프롬프트 롤백 불가

Git 아닌 인라인 문자열이라 이전 버전 못 찾음.

8.3 모델 deprecation

공급사가 모델 종료 공지, 대체 모델에서 회귀 발생.

8.4 한 지역 장애로 전체 다운

단일 리전 의존. 멀티 리전/멀티 벤더 폴백 부재.

8.5 RAG 인덱스 드리프트

문서 업데이트가 인덱스 재구성 안 됨, 오래된 답.

8.6 사용자 로그 과보유

규제 감사에서 지적, 과태료.

8.7 프롬프트 인젝션

간접 인젝션으로 사내 문서 유출.

8.8 False refusal 폭증

가드레일 강화 후 정상 요청 거부율 상승.

8.9 벡터 DB 비용 폭주

예상보다 많은 청크 생성, 월 비용 2배.

8.10 A/B 결과 해석 오류

표본 부족·분산 무시, 잘못된 버전 승격.

9장 · KPI·OKR

9.1 제품 KPI

• Task completion rate
• Time saved(사용자 당)
• NPS / Retention
• Adoption / Active usage

9.2 엔지니어링 KPI

• p95 latency
• Error rate
• Cost per request
• Availability (SLA)

9.3 AI Quality KPI

• Eval set score (주/월)
• Hallucination rate
• Safety violations
• False refusal rate

9.4 운영 KPI

• MTTR (mean time to recovery)
• 사고 빈도(주/분기)
• 릴리스 주기(주 몇 회)
• 테스트 커버리지

10장 · 한국·아시아 환경

10.1 클라우드

• AWS·GCP·Azure·Oracle + 국내(NHN Cloud, KT Cloud, Naver Cloud)
• 규제 감사에 따라 국내 클라우드/온프레 요구
• 서울·도쿄 리전 지연 대비

10.2 공급사 다각화

• OpenAI·Anthropic·Google·Cohere·Mistral + 국내(Upstage, LG AI Research)
• 금융·공공: 국내 벤더 우대 조건

10.3 직원 교육·문화

• AI 사용 가이드라인(사내 데이터 유출 방지)
• 프롬프트 엔지니어링 기본 교육(1–2시간)
• 신규 프로덕트 AI 도입 전 보안 리뷰

11장 · 공구 모음 (2025)

11.1 게이트웨이·라우팅

• LiteLLM, Portkey, Helicone, Martian, OpenRouter

11.2 관측성

• LangFuse, LangSmith, Phoenix(Arize), Helicone, W&B Weave, Datadog/NewRelic LLM extensions

11.3 평가

• RAGAS, DeepEval, Promptfoo, Giskard, PyRIT(공격), OpenAI Evals, Confident AI

11.4 프롬프트 레지스트리

• LangSmith Prompt Hub, Humanloop, PromptLayer, W&B Weave, Agenta

11.5 데이터/피처

• Weights & Biases Artifacts, MLflow, DVC, LakeFS

11.6 서빙

• vLLM, TGI, SGLang, TensorRT-LLM, Ollama, Modal, Anyscale, Together, Fireworks

11.7 가드레일·보안

• NeMo Guardrails, Guardrails AI, Lakera Guard, Rebuff, Azure Content Safety, Google Cloud Model Armor

11.8 비용·자원

• Helicone Cost Insights, OpenMeter, CloudZero, Cast AI, Karpenter(K8s)

12장 · 안티패턴 10선

12.1 모델만 바꾸고 배포

평가셋·프롬프트 재확인 없이 롤아웃.

12.2 단일 벤더 의존

장애·가격 인상·약관 변경 리스크.

12.3 프롬프트 Git 외부에

Config 파일·인라인 코드·SaaS-only → 버저닝 실종.

12.4 Shadow·Canary 미사용

문제를 프로덕션에서 발견.

12.5 비용 대시보드 없음

월말 청구서 보고 깜짝.

12.6 Eval set과 훈련 데이터 섞임

평가 부풀림.

12.7 벤더 장애에 대응 계획 없음

사용자 체감 큰 다운타임.

12.8 AI Platform 팀 과대권력

Product AI의 자율 억압.

12.9 규제·감사 감안 없음

출시 후 벌금·강제 중단.

12.10 Postmortem 미작성

같은 사고 반복.

13장 · 체크리스트 — LLMOps 런칭 전 12가지

• 3축(모델·프롬프트·평가셋) 버저닝과 릴리스 메타 고정
• Shadow + Canary + 자동 롤백 구축
• 비용 대시보드(일/월, 기능·사용자별)
• 멀티 벤더 폴백 경로
• 평가 하네스 + CI 통합
• 관측성(Trace/Metric) 표준 계측
• 가드레일·Red team CI
• SLI/SLO + 온콜 체계
• 데이터 분류·PII 마스킹·삭제 API
• 사고 대응·Postmortem 프로세스
• AI 플랫폼·제품 간 책임·API 합의
• 직원 교육·보안 가이드

14장 · 다음 글 예고 — Season 4 Ep 12: "AI 제품 디자인"

엔지니어링이 안정됐다면 남은 건 사용자 경험이다.

• 확정적 UI vs 생성적 UI의 경계
• "신뢰"를 만드는 디자인 (인용·불확실성·편집 가능성)
• 피드백 UX: 👍/👎 너머의 패턴
• 스트리밍·지연·피드백 처리
• Agent UX: 진행·승인·중단·리플레이
• Voice UX 깊이 (Ep 9 연장)
• 데이터·학습의 UX
• 온보딩·첫인상 설계
• 실패·장애의 UX
• 접근성·포용성
• 윤리적 AI UX
• 한국어·한국 문화 특화

"좋은 AI 제품 = 좋은 모델 + 좋은 UX"가 아니라 "좋은 AI 제품 = 제약 안에서 신뢰를 만드는 UX 설계"다.

다음 글에서 만나자.

요약: LLMOps는 3축 버전 관리·Shadow/Canary·비용 통제·플랫폼 팀·감사로 요약된다. MLOps와 DevOps의 교훈을 흡수하되, LLM 고유의 확률성과 벤더 의존성을 고려한 추가 관행이 필요하다. 한 번 만드는 건 쉬워졌지만, "1년 동안 멈추지 않고 개선되는 LLM 제품"을 만들려면 이 글의 12-체크리스트가 최소 출발점. "AI는 배포하는 게 아니라, 돌리는 것"이 2025년의 교훈.