LLMOps

✎ 이 문서 수정하기 GitHub에서 수정

LLMOps란?

LLMOps (Large Language Model Operations)는 LLM 기반 애플리케이션을 프로덕션 환경에서 안정적으로 개발·배포·운영하기 위한 방법론과 도구의 집합이다.

기존 MLOps가 모델을 처음부터 학습시키는 데 초점을 뒀다면, LLMOps는 이미 사전학습된 모델을 가져다 쓰는 것을 전제로 한다. 핵심은 모델 자체보다 프롬프트, 에이전트, 평가, 모니터링에 있다.

Abi Aryan(LLMOps, O’Reilly 2025)은 이 관계를 이렇게 표현한다. MLOps는 집 짓기, DevOps는 쇼핑몰 짓기라면, LLMOps는 부르즈 할리파 짓기다 — 재료는 같아도, 같은 건설 팀에 맡길 수 없다. 실제로 LLMOps는 MLOps보다 DevOps와 더 닮아 있다. LLM 애플리케이션은 소비자 대면 서비스(Software 3.0)로 배포되기 때문에 DevOps의 문제들이 다시 전면에 등장한다.

LLMOps 라이프사이클

세 개의 루프가 하나의 관리 루프(거버넌스·보안·컴플라이언스)로 묶인다.

Explore  →  Build  →  Operationalize
              ↑               ↓
         (반복 개선)     (모니터링 피드백)
               ↑_____________↓
                Management Loop

1. Explore — 탐색

• 비즈니스 요구사항 및 유즈케이스 정의
• 아키텍처 설계 (RAG? Fine-tune? Agent?)
• 모델 선택 — LLM vs SLM, 오픈소스 vs 독점

2. Build — 개발

• 프롬프트 엔지니어링 및 버전 관리
• 에이전트 구성
• 평가 파이프라인 구축 (수동 → 자동화)
• 품질/안전 기준치 달성까지 반복

3. Operationalize — 운영

• 프로덕션 배포
• 모니터링 및 트레이싱 설정
• 비용·지연·품질 지속 추적
• GitHub Actions 등으로 CI/CD 자동화

LLMOps의 4대 목표

LLMOps 프레임워크가 달성해야 할 목표는 네 가지다. 이게 그냥 원칙 나열이 아니라, 팀이 매일 하는 의사결정의 기준이 된다.

1. 신뢰성(Reliability) — LLM은 본질적으로 예측 불가하다. 컨텍스트 이해를 못하거나, 학습 데이터가 오래됐거나, 같은 입력에 다른 응답을 내놓는다. 가동률, 에러율, 고객 만족도(CSAT)로 측정한다.
2. 확장성(Scalability) — LLM은 메모리 덩치가 커서 단일 머신에 안 올라간다. 분산 배포하면서 지연을 낮게 유지하는 게 핵심 난제다. TPM, 처리량, 응답 시간, 자원 확장 속도로 측정한다.
3. 견고성(Robustness) — 데이터 드리프트, 모델 드리프트, 서드파티 모델 업데이트에도 성능이 유지돼야 한다. 데이터 신선도, 성능 저하율(<5%/6개월), 일관성으로 측정한다.
4. 보안(Security) — 프롬프트 인젝션, 탈옥(jailbreaking), 적대적 공격에 취약하다. 다중 테넌트 환경에서 데이터 격리도 어렵다. 침투 탐지율, 보안 감사 빈도, 미인가 접근 시도 수로 측정한다.

SLO / SLA / KPI — 목표를 측정 가능하게 만드는 도구

이 세 개념은 엔지니어링 팀과 비즈니스 팀이 같은 언어를 쓰기 위한 장치다.

• SLO(서비스 수준 목표) — 내부 달성 목표. “월간 가동률 99.9%”
• SLA(서비스 수준 계약) — 고객과의 외부 계약. “가동률 99.9% 미달 시 10% 환불”
• KPI(핵심 성과 지표) — 비즈니스 성과 측정. “CSAT 90점 이상”, “이탈률 월 5% 이하”

Gartner(2024)는 GenAI 프로젝트의 30%가 2025년까지 실패할 것이라 예측했다. 실패 원인 1위는 데이터 품질, 평가 프레임워크 부재, 스케일링 비용 — 전부 운영 문제지 기술 문제가 아니다. SLO/SLA/KPI가 명확하지 않으면 팀이 방향을 잃는다.

모델 선택

LLM vs SLM

• LLM (GPT-4, Llama3 70B, Mistral Large): 복잡한 추론, 긴 컨텍스트, 높은 비용
• SLM (Phi-3, Llama3 8B, Mistral 7B): 빠르고 저렴, 엣지 디바이스 가능

모델 유형

• Chat completion: GPT-4, Mistral Large — 일반 텍스트 대화
• Reasoning: o1, DeepSeek-R1 — 수학·코딩·전략
• Multimodal: GPT-4o, Phi-3 Vision — 텍스트 + 이미지
• Embedding: Ada, Cohere — RAG, 시맨틱 검색
• Image generation: DALL-E 3, Stable Diffusion

선택 기준 4가지

1. Task type — 텍스트만? 멀티모달?
2. Precision — 베이스 모델로 충분? 파인튜닝 필요?
3. Openness — 직접 파인튜닝 가능해야 하나?
4. Deployment — 로컬? 서버리스? 관리형 인프라?

프롬프트 버전 관리

프롬프트는 코드다. 버전 관리하지 않으면 사고가 난다.

프롬프트 변경은 즉각 반영된다 — 컴파일도, 테스트 게이트도 없다. 한 단어 바꾸면 수천 명의 사용자 경험이 달라진다.

DevOps 관행을 프롬프트에 적용:

버전 없을 때 발생하는 문제:

• 조용한 품질 저하 — 바꾼 것 같지 않은데 사용자가 불만
• 환경 불일치 — dev와 prod가 다른 프롬프트를 씀
• 위기 복구 불가 — prod 장애 시 이전 버전이 없음
• 지식 소멸 — “불필요해 보이는” 안전 지침이 삭제됨

권장 레포 구조:

project/
├── src/agents/
│   └── my_agent/
│       ├── agent.py              # 배포 스크립트
│       └── prompts/
│           ├── v1_instructions.txt
│           ├── v2_instructions.txt
│           └── v3_instructions.txt
├── tests/
├── docs/
│   └── prompt-guidelines.md
└── .github/workflows/
    ├── test-agents.yml
    └── deploy-agents.yml

Git 태그로 배포 추적:

git commit -m "Deploy agent V2"
git tag v2
git push origin master --tags

도메인 적응 전략

모델을 내 도메인에 맞게 만드는 방법은 여러 가지다. 비용 순으로 나열하면:

풀 파인튜닝은 특정 모델 버전에 종속되고, 대규모 주석 데이터가 필요하다. 먼저 프롬프트와 RAG를 충분히 시도하고, 그래도 안 될 때 고려한다.

에이전트 평가

평가 없이 최적화는 없다. 측정하지 않으면 개선할 수 없다.

3가지 평가 차원

평가 방식 비교

Git 기반 실험 워크플로우

# 실험별 브랜치 생성
git checkout -b experiment/gpt4o-mini-model

# 평가 후 좋은 결과면 병합
git checkout master
git merge experiment/gpt4o-mini-model
git tag promoted-to-prod-2026-04-12

자동화 평가 (GitHub Actions)

PR이 prompts/ 또는 config/ 파일을 수정하면 자동으로 평가 워크플로우가 실행된다:

on:
  pull_request:
    branches: [master]
    paths: ['prompts/**', 'config/**']

평가 결과는 PR 코멘트로 자동 게시:

## Evaluation Results
- Groundedness: 4.25
- Relevance:    4.10
- Coherence:    3.85
Status: ✅ PASSED (150 examples)

왜 LLM 평가는 이렇게 어려운가

일반 ML 모델은 결정론적이다 — 같은 입력이면 항상 같은 출력. LLM은 학습할 때도, 추론할 때도 난수를 쓴다. 같은 질문에 매번 다른 답을 낸다. 이게 평가를 구조적으로 어렵게 만드는 근본 이유다.

• 정답이 없다 — 개방형 생성에는 “정답"이 존재하지 않음
• 무한한 출력 공간 — 가능한 모든 시나리오를 테스트할 수 없음
• 해석 도구 없음 — ML과 달리 내부 동작 설명 도구(interpretability)가 LLM에는 아직 없음
• “좋음"의 기준이 주관적 — 관련성, 창의성, 정확성이 서로 충돌할 수 있음

평가해야 할 6가지 차원:

BLEU, ROUGE 같은 n-gram 기반 메트릭은 번역·요약 같은 좁은 용도에만 유효하다. “파리"가 정답인데 “프랑스의 수도는 파리입니다"라고 답하면 16.6%만 맞다고 나온다. 개방형 평가에는 LLM-as-Judge가 훨씬 신뢰도가 높다.

모니터링

모니터링은 추측을 엔지니어링으로 바꾼다.

4가지 핵심 메트릭

메트릭 간 연관성

• 토큰 급증 → 지연 상승 + 비용 상승
• 처리량 초과 → 에러율 상승
• 지연 감소 → 처리량 감소 가능 (트레이드오프)

Azure 기준 모니터링 스택

App Code
  └─ AIInferenceInstrumentor()   ← 자동 트레이싱
       └─ OpenTelemetry
            └─ Application Insights
                 └─ Azure Monitor Dashboard
                      └─ Alerts (이메일/웹훅)

트레이싱

모니터링이 “무슨 일이 일어났나"를 알려준다면, 트레이싱은 “왜 그런 일이 일어났나"를 알려준다.

핵심 개념

• Trace: 요청이 시스템을 처음부터 끝까지 흐른 전체 여정
• Span: 트레이스 내의 개별 작업 단위 (모델 호출, API 콜 등) — 시작/종료 시간 포함
• Attribute: Span에 붙는 메타데이터 (세션 ID, 응답 길이, 파싱 성공 여부 등)

트레이스 계층 예시

trail_guide_session              ← 세션 전체
  recommend_hike                 ← 비즈니스 로직
    recommend_model_call         ← 모델 호출 래퍼
      chat gpt-4o                ← SDK 자동 트레이싱
  trip_profile_generation        ← 비즈니스 로직
    trip_profile_model_call
      chat gpt-4o

트레이싱으로 발견할 수 있는 것들

• 성능 병목: trip_profile_generation이 4-6초 vs recommend_hike 1초 이하 → 병목 특정
• 에러 패턴: “겨울 등산 장비"에선 실패, “여름"에선 성공 → 데이터 갭
• 비용 최적화: GPT-4o 호출이 세션당 2번 → 프롬프트 통합으로 1번으로 줄이기 가능
• UX 문제: 전체 8-12초지만 사용자가 5-6초에 이탈 → 중간 피드백 메시지 필요

LLMOps 팀과 역할

LLMOps를 도입할 때 가장 현실적인 질문은 “누가 이걸 하나"다.

기존 ML 팀이 있는 회사: 주로 내부에서 8~10명을 다양한 부서(제품, 풀스택, 데이터, ML, 보안)에서 뽑아 팀을 꾸린다. 이미 비즈니스를 아는 사람이 유즈케이스 타당성을 검증하게 하는 게 낫기 때문이다. MLOps 엔지니어를 LLMOps로 업스킬링하는 게 외부 채용보다 훨씬 현실적이다.

신규 스타트업: 처음부터 팀 구성. LLMOps 인프라(SaaS 툴링) 빌드냐, LLM 유즈케이스(카피라이팅, 교육, 프로세스 자동화) 빌드냐에 따라 팀 모양이 완전히 달라진다.

핵심 4개 역할

이상적인 페어링: AI 엔지니어 + LLMOps 엔지니어. AI 엔지니어가 모델을 조정·파인튜닝하는 동안 LLMOps 엔지니어가 배포와 최적화를 담당한다.

MLOps 엔지니어를 LLMOps로 업스킬링

이미 갖고 있는 것: 모델 버전 관리, 데이터 버전 관리, 롤백, GitHub Actions. 좋은 출발점이다.

추가로 배워야 할 것:

• 트랜스포머 아키텍처와 어텐션 메커니즘
• LLM 전용 최적화 (양자화, 배치처리, 서빙)
• LLM 스케일 데이터 엔지니어링 (중복 제거, 독성 필터링, 청킹)
• 분산 학습 시스템 설계
• 생성형 출력을 위한 가드레일과 모니터링

LLMOps 성숙도 모델

Abi Aryan이 Microsoft MLOps 성숙도 모델을 참고해 정의한 3단계 모델이다.

Level 2가 되려면 이런 게 갖춰져야 한다:

문서화 측면

• 비즈니스 목표와 KPI가 최신 상태로 문서화됨
• LLM 리스크 평가(편향, 공정성, 데이터 드리프트, 성능 저하)가 완비됨
• 모델 선택 근거와 비용 비교가 기록됨
• API 구조, 데이터 흐름, 아키텍처 다이어그램이 최신 상태

운영 측면

• 가드레일과 한계 감지(신뢰도 스코어링, 임계값)
• 모든 입출력 자동 저장·인덱싱
• 정기 A/B 테스트
• 실시간 독성·편향 탐지 파이프라인
• GDPR·HIPAA 컴플라이언스
• 정기 외부 보안 감사 포함

실무 적용 포인트

1. 평가 기준을 먼저 정하라 — 배포 전에 품질/비용/성능 임계값 합의. “4.2점 이상 또는 배포 안 함”
2. 프롬프트를 코드처럼 관리하라 — Git 없이 프롬프트 바꾸는 것은 운영 리스크
3. 작게 시작하고 측정하라 — 100개 예시로 시작, 잘 구성된 소규모 > 무작위 대규모
4. 자동화는 점진적으로 — 자동 테스트 → 모니터링 → 배포 자동화 순서
5. 인간 감독을 유지하라 — 자동화는 인간 판단을 증폭시키는 것이지 대체하는 것이 아님

Observatory — LLMOps 관점에서 본 갭 분석

직접 만들고 있는 플랫폼이라 조금 솔직하게 적는다.

Observatory의 핵심 목표는 **“프로덕션 LLM 애플리케이션을 디버깅·평가·지속 개선할 수 있는 운영 가시성 제공”**이다. Datadog이나 LangFuse를 컴플라이언스 문제로 못 쓰는 팀을 위해, 어차피 App Insights에 쌓이는 OTel 텔레메트리를 KQL로 읽어서 대시보드로 보여주는 구조다. 데이터는 Azure 구독 밖으로 나가지 않는다.

뭘 잘하고 뭐가 빠졌나

관측(Operationalize) 쪽은 가장 잘 됐다. Trace Explorer, Waterfall/Flame Graph, 에이전트·툴 호출 추적, 비용 추적, 멀티 워크스페이스 KQL까지 — 이건 설계 목표에 충실하게 나왔다고 본다.

설계·실험(Explore) 쪽도 나쁘지 않다. Playground 4개 프로바이더, Prompt Registry 버전 이력, 실험 프레임워크에 t-test/Mann-Whitney 유의성 검증까지 내장됐다. 솔직히 이 부분은 상용 도구들도 잘 안 해주는 걸 넣었다.

문제는 평가(Build)와 피드백 루프(Management Loop)다.

현재 평가 엔진은 단어 겹침(word overlap) 기반 휴리스틱이다. Groundedness 점수가 높게 나와도 실제로 근거가 있는 응답인지 보장이 안 된다. 이 상태에서는 평가 점수를 CI/CD 게이트로 쓸 수 없다 — 신뢰를 못 하니까. LLM-as-Judge 없이는 EDD(Evaluation-Driven Development)가 반쪽짜리다.

피드백 루프는 더 구멍이 크다. 지금은 Observatory가 문제를 보여줄 수는 있어도 그 문제를 수집하고 다음 실험으로 연결하는 흐름이 없다. 좋아요/싫어요 하나도 없고, 주석 큐도 없다. 트레이스에서 문제를 발견해도 “이게 왜 나쁜 응답인지” 레이블을 달고 데이터셋으로 만드는 과정이 전부 플랫폼 밖에서 수동으로 이루어진다.

지금 위치

LLMOps 성숙도로 보면 Level 1 완성, Level 2 진입 중이다.

• Level 1 (Instrumented) — OTel 트레이싱, 비용/지연 대시보드, 프롬프트 버전 관리: ✅
• Level 2 (Systematic) — CI/CD 평가 게이트, 피드백 수집, 황금 데이터셋: 아직 절반
• Level 3 (Optimizing) — 구조화 주석, 실험이 배포를 게이팅: 아직

관측 도구로서는 꽤 완성됐다. 하지만 감지 → 레이블링 → 실험 → 배포 결정 사이클이 자동화되려면 Sprint 3 평가 SDK와 Sprint 2 피드백 수집이 관건이다. 특히 CI/CD 게이트는 Sprint 6로 잡혀 있는데, Sprint 3 평가 SDK만 나오면 바로 붙일 수 있으니 앞당길 여지가 있다.

참고 자료 및 관련 독서

• 2026년 AI 책 읽기 — 2026 LLM 독서 계획 (Production/MLOps 섹션 참고)
• johklo/llmopsdashboard — Azure LLM Observatory 플랫폼
• LLM Engineer’s Handbook
• LLMs in Production
• Building LLMs for Production
• AI Engineering (읽는 중)