12. 평가 파이프라인 — Offline · Online · Monitoring

쉽게 읽기

한 줄: 평가는 한 번에 한 곳이 아니라 3단계 파이프라인 — 배포 전(Offline) / 운영 중 샘플(Online) / 시계열 모니터링 — 각 단계마다 평가자 종류와 적용 비율이 다르다.

비유: 자동차 품질관리에 비유. 출고 전 전수 검사(Offline), 운행 중 임의 샘플 점검(Online), 정기 주행 데이터 모니터링(Monitoring). 단계별 비용 vs 커버리지가 다름.

이 문서에서 챙길 3가지

1. Offline: 배포 전 게이트(smoke·회귀·수용·안전·비용) 모두 100% 적용
2. Online: 프로덕션 trace 중 층화 샘플링 — 실패·thumbs-down은 100%, 일반은 1–5%
3. Monitoring: drift 알람(전 7일 -2σ, p99 latency 1.5x 등) → 인간 검토 트리거. 흥미로운 케이스는 부메랑처럼 Offline 데이터셋으로 들어가 시스템이 학습됨

1. 정의

평가 파이프라인은 어느 단계에 어떤 평가를 어느 빈도로 굴리느냐 를 정하는 운영 설계다. 단일 평가 한 번이 아니라, 상시 흐르는 시스템 으로 평가를 본다.

3 단계가 표준:

• Offline (배포 전): 큐레이션 데이터셋에 모든 평가자를 100% 적용. 회귀 검증·수용 검증.
• Online (프로덕션): 실 트래픽에 샘플링 으로 평가. 비용 통제 + 진짜 사용 패턴 측정.
• Monitoring (지속): 실시간 또는 준실시간 alarm — drift, 환각률 등.

각 단계는 다른 메트릭 과 다른 빈도 를 가진다. 같은 메트릭을 단계 가로질러 비교하면 드리프트 를 잡을 수 있다.

2. 핵심 메커니즘

flowchart LR
    Build[배포 후보] --> Offline[Offline<br/>smoke·회귀·수용·안전·비용]
    Offline -->|모든 게이트 통과| Deploy([프로덕션 배포])
    Offline -->|실패| Block[배포 차단]

    Deploy --> Trace[프로덕션 trace]
    Trace --> Sample{샘플링}
    Sample -->|실패·thumbs-down 100%| Online[Online 평가<br/>LLM-judge / deterministic]
    Sample -->|random 1–5%| Online
    Sample -->|신규 기능 10–20%| Online

    Online --> Monitor[Monitoring<br/>drift / latency / 환각률]
    Monitor -->|임계 위반| Alarm[Alarm → roll-back / 인간 검토]
    Online --> Boomerang[흥미로운 케이스<br/>→ Offline 데이터셋 추가]
    Boomerang -.다음 배포.-> Build

    classDef ok fill:#efe,stroke:#080
    classDef warn fill:#fee,stroke:#c00,color:#600
    class Deploy ok
    class Block,Alarm warn

2.1 Offline — 회귀 + 수용

배포 전 단계에서 거치는 게이트.

게이트	메트릭	임계
Smoke test	시스템이 응답하나, 명백 오류 X	100% pass
회귀 (regression)	기존 데이터셋 점수가 떨어지지 않았나	마지막 배포 대비 ≥ -1%
수용 (acceptance)	새 기능이 의도대로 동작	신규 항목 ≥ 80%
안전 (safety)	정책 위반 0	0
비용·latency	p95 latency, 평균 토큰	임계 이내

이 단계의 모든 평가자가 100% 적용. 비용 부담은 빌드 시점에 한 번이라 OK.

2.2 Online — 샘플링 평가

프로덕션의 모든 trace를 평가하면 비용 폭증. 따라서 층화 샘플링 (stratified sampling).

층	샘플링 비율	이유
실패한 trace (HTTP 5xx, timeout)	100%	디버깅
사용자 thumbs-down 받은 trace	100%	품질 조사
Random sample	1–5%	통계
신규 기능 사용 trace	10–20%	안정화 모니터링
Tail (낮은 사용자/엣지)	우선순위 加	분포 보존

각 샘플에 LLM-as-judge 또는 deterministic 평가자 자동 적용. 결과 → dashboard.

2.3 Monitoring — 드리프트 alarm

Online 평가 결과를 시계열 로 모니터. drift 탐지:

• Concept drift: 사용자 입력 분포가 변함 → 모델이 못 따라감
• Model drift: 모델 자체 (또는 prompt) 가 바뀜 → 점수 변화
• Data drift: RAG 코퍼스가 stale → 답변 품질 ↓

Alarm 임계: 지난 7일 평균 대비 -2σ. P99 latency 1.5x. 환각률 +5%p.

대응: roll-back, alarm → 인간 검토, 자동 재학습 트리거 등.

2.4 Production-edge → 데이터셋 부메랑

Online 평가에서 발견된 흥미로운 케이스 는 익명화 후 offline 데이터셋에 추가. 다음 배포부터 그 케이스 가 회귀 게이트로 들어감.

이 부메랑이 시스템을 학습 하게 만든다. 사람이 일일이 데이터셋을 늘리지 않아도 됨.

2.5 Grader 3종의 단계별 배치

2장에서 본 code/model/human grader가 단계별로 다르게 배치된다:

단계	Code grader	Model grader	Human grader
Offline	100% trace	100% trace	일부 (어려운 케이스)
Online	100% (저비용)	1–5% sampling	0.1% (큐 기반)
Monitoring	100% (alarm 자동)	sampling 결과 집계	alarm 시

Code grader는 어디서나 풀로 굴리고, model grader는 점점 줄이고, human은 가장 좁게 적용.

3. 강점과 약점

강점	약점
비용 통제 가능 (단계별 비율)	설계 복잡 — 셋업 부담
Drift 자동 탐지	임계 설정이 도메인 지식 필요
데이터셋 자동 진화 (부메랑)	부메랑이 편향 강화 가능 (자주 본 패턴만 늘어남)
단계별 책임 분리 (offline 게이트 / online 모니터)	작은 N 실험엔 과투자

4. 대안과의 비교

비-에이전트 ML 의 MLOps 파이프라인 과 매우 유사. 차이점:

• 에이전트는 상태가 있음 (메모리·세션). MLOps의 stateless 모델 평가와 다름
• 에이전트 평가는 trajectory 단위 — span tree가 풍부
• LLM-as-judge가 사실상 표준 평가자 → MLOps의 deterministic metric (accuracy 등) 과 다름

엄밀한 LLMOps 이름으로 같은 개념을 묶는 것이 2025–26 트렌드.

5. 우리 실험에의 적용

본 실험은 14일 짜리 오프라인 실험에 가깝다. 프로덕션이 없다. 그래도 3 단계 사고를 축소판으로 적용 가능.

5.1 Offline 단계 = Day 0–3

Day 0–3 활동	본 실험 매핑
Smoke test	codex CLI 로그인, 가짜 워크스페이스 1개 메시지 발송 (이미 함)
회귀	양 도구가 가장 단순 태스크 (T1) 를 둘 다 통과하나
수용	4-rubric 차원 점수 평균 ≥ 3.0
안전	페르소나 모드 위반 0 (LLM-as-judge boolean)
Latency	TTC 평균 < 5분

이 게이트를 통과 못 하면 본 실험 (Day 4~) 시작 X.

5.2 Online 단계 = Day 4–13

Online 활동	본 실험 매핑
100% code grader	정책 위반 카운트 (페르소나 모드), 함수호출 정확도 (10장)
5–10% model grader	5장 LLM-as-judge 로 결과물 자동 채점 (민지 채점과 ρ 측정용)
1% human grader	민지의 결과물 1–5 점수 (사실상 100% 라 비율 의미 X)

우리는 N이 작아서 비율 의미는 약하지만, 사고 구조 는 동일.

5.3 Monitoring = Day 별 일일 점검

매일 끝나면:

• 도구별 평균 점수 plot
• 직전 day 대비 ±1점 이상 변화 시 alarm (rubric drift 의심)
• 정책 위반 발생 시 즉시 기록

이게 사실상 Evo-Memory 식 학습 곡선 (9장) 을 일일 단위로 보는 것.

5.4 부메랑 — 발견 사례를 다음 실험으로

본 실험 종료 후, 흥미로운 trial (예: “T1 에서 OpenClaw 가 Discord 만 송신하고 Slack 누락” 같은 재현 가능한 실패)을 별도 데이터셋으로 export. 다음 실험 Day 0의 회귀 게이트 데이터.

이게 본 실험의 재현 가능 셋업 가이드 (산출물 #3) 가치를 높이는 길. 후속자에게 단순 가이드 + 데이터셋까지 전달.

5.5 결정

• 3 단계 사고는 적용. 인프라는 추가 X (hook + CSV로 충분)
• Day 0–3을 명시적 게이트 로 운용. Day 4~ 진입 전 통과 체크
• 일일 monitoring plot 한 장 (도구별 평균 rubric 점수 시계열)
• 부메랑 데이터셋 export → 후속 실험 자산

6. 더 읽을거리

• Adaline, “Complete Guide to LLM & AI Agent Evaluation in 2026” — offline → online → monitoring 3단 파이프라인의 종합 가이드
• Anthropic Engineering, “Demystifying evals for AI agents” — code/model/human grader의 단계별 배치 권고
• Google Cloud, “Agent Factory Recap” 블로그 — Vertex AI 기반 3단 파이프라인 산업 사례
• McKinsey QuantumBlack, “Evaluations for the agentic world” — 비즈니스 outcome 관점에서 본 에이전트 평가 컨설팅 시각

---

다음 장 미리보기

이제 비판적 시각으로. 모든 벤치는 게임 가능하다. Berkeley RDI 의 “How We Broke Top AI Agent Benchmarks” — 8개 주요 벤치를 태스크를 안 풀고도 만점 받는 익스플로잇. 우리 실험에의 함의. 13장.

이 장에서 확실히 알아야 하는 것

• Offline / Online / Monitoring 3 단계의 책임 차이를 안다.
• 층화 샘플링 (실패 100% / random 1–5% 등)의 이유를 설명할 수 있다.
• Code / Model / Human grader가 단계별로 다르게 배치되는 패턴을 안다.
• 데이터셋 부메랑이 왜 시스템을 학습하게 하는지 설명할 수 있다.
• 본 실험의 Day 0–3 = offline gate 로 운용하는 의미를 안다.