LLM 관측성과 평가

분류: Layer 12 - AI 시스템 & LLM 애플리케이션 | 선수지식: L6-40 (Logs/Metrics/Traces), L11-80 (모델 평가), L12-10 (LLM API), L12-60 (Agent)

LLM 관측성과 평가 — Tracing, Metrics, Production Eval, Drift

1. 한 줄 정의

LLM 관측성·평가는 production LLM 앱의 trace·metric·eval을 통합해 품질·비용·지연·안전을 지속 측정하는 시스템이며, OpenTelemetry GenAI semantic convention과 LangSmith/Langfuse/Arize 같은 도구가 표준이다.

2. 왜 중요한가

Production 운영 핵심: 평가 없이는 prompt·모델 변경의 영향 알 수 없음
LLM 특유 지표: latency·cost·token·cache·hallucination — 일반 APM과 다름
Agent loop debug: trace 없으면 multi-step agent 디버그 불가능 (L12-60)
Continuous improvement: gold dataset + LLM-as-judge + 사용자 피드백 loop
Compliance·사고 대응: audit log, drift detection, incident replay

2.5 등장 배경 — 전통 APM이 LLM에서 무너진 지점

LLM 관측·평가는 새로 발명된 것이 아니라, 전통 APM(Datadog·NewRelic·Jaeger 같은 distributed tracing)이 LLM 워크로드에서 4가지 가정이 깨지면서 등장했다. 선행 토픽 L6-40 logs-metrics-traces는 metric·log·trace로 분산 시스템을 보는 법을 제공하고, L11-80 model-evaluation-and-data-quality(오프라인 평가)와 L12-10 llm-api-basics(token·cost 단위)는 각각 “평가는 학습 직후 한 번”, “RPC 한 번에 비용 고정”이라는 가정 위에 동작했는데, production LLM은 그 양쪽을 모두 깨뜨린다.

전통 APM 가정	LLM에서 깨지는 양상	GenAI semconv가 푸는 방식
한 request = 한 RPC 비용	한 요청 안에 input 150 / output 320 token, 모델별 단가 4~30배 차	`gen_ai.usage.input_tokens` / `output_tokens` / `request.model` 분리 attribute
Response body는 byte 단위 로그	prompt 수 KB ~ 수 MB, 이미지·tool call 포함 (멀티 KB 페이로드는 기존 OTel가 설계 대상으로 삼은 적 없음)	events·streaming span 별도 신호
같은 입력 → 같은 출력 (deterministic)	같은 prompt가 hallucination/refusal로 분기 → error rate로는 안 잡힘	`finish_reasons`, 별도 quality metric (faithfulness 등)
Trace는 HTTP/DB 호출만	한 응답 안에 retrieve → rerank → tool call → LLM call 4단 hierarchical	`gen_ai.*` + LLM·retrieval·tool span 통합

정량 한계 신호: provider별 SDK가 단편화된 결과 — OpenAI/Anthropic/Gemini가 각자 다른 trace 형식 사용, Langfuse·Helicone·LangSmith가 각자 incompatible proprietary 포맷 채택 → 한 도구에서 다른 도구로 trace 옮기면 호환 attribute가 거의 0개. 이게 vendor lock-in을 만들었고, OTel SIG는 2024-04에 GenAI SIG를 발족해 이 단편화를 해결한다고 명시한다.

해결 메커니즘 → 본문 연결: §3.1의 “LLM Observability vs 일반 APM” 표가 위 4가지 깨짐의 dimension 측 결과이고, §3.2의 gen_ai.* attribute 목록이 그 단편화 해소의 구체적 schema다. §3.4의 도구 분류(“OpenTelemetry 표준” 카테고리)가 이 lineage 위에서 비로소 의미를 가진다.

이 토픽이 사라지면: prompt·모델 변경 후 회귀를 잡을 표준 trace 형식이 사라져 도구마다 instrumentation을 따로 짜야 하고, drift·hallucination 같은 LLM 특유 silent failure가 일반 error rate에 숨어 production에서만 발견된다.

출처: OpenTelemetry GenAI Semantic Conventions, OpenTelemetry for Generative AI blog (2024).

3. 핵심 개념

3.1 LLM Observability vs 일반 APM

전통 APM(Datadog, NewRelic) + LLM 특유 dimensions.

차이점	전통 APM	LLM Observability
단위	request, span, error	+ prompt, completion, tool call
비용	infra cost	+ token cost (input/output 분리)
품질	error rate	+ hallucination, faithfulness, helpfulness
Latency	RT	+ TTFT, TPOT, queue
결정성	deterministic	non-deterministic — 같은 입력 다른 출력
Trace	distributed trace	+ LLM·tool·retrieval 통합 trace

3.2 OpenTelemetry GenAI Semantic Conventions

OpenTelemetry가 2024-2025에 정착시킨 LLM trace 표준.

표준 attribute 예시

gen_ai.system: "openai"
gen_ai.operation.name: "chat"
gen_ai.request.model: "gpt-4o"
gen_ai.request.temperature: 0.7
gen_ai.request.max_tokens: 1000
gen_ai.usage.input_tokens: 150
gen_ai.usage.output_tokens: 320
gen_ai.usage.total_tokens: 470
gen_ai.response.id: "..."
gen_ai.response.finish_reasons: ["stop"]

가치

provider 중립: OpenAI·Anthropic·Gemini·open-weight 모두 같은 schema
도구 호환: Datadog, NewRelic, Honeycomb, Grafana 모두 자동 파싱
OpenLLMetry, Traceloop: 자동 instrument 라이브러리 (Python·TS)
버전 고정 필요: GenAI semconv는 development 상태이므로 instrumentation 버전과 OTEL_SEMCONV_STABILITY_OPT_IN 같은 opt-in 정책을 CI에서 고정

3.3 Trace 구조

LLM 앱은 hierarchical trace로 표현.

[Request: chat completion]
├─ Span: prompt_construction (RAG)
│   ├─ Span: query_embedding (10ms)
│   ├─ Span: vector_search (15ms)
│   ├─ Span: reranker (50ms)
│   └─ Span: prompt_assembly (1ms)
├─ Span: llm_call (gpt-4o, 1.2s)
│   ├─ TTFT: 250ms
│   ├─ Output: 320 tokens
│   └─ Cost: $0.005
├─ Span: tool_call (search_db, 200ms)
└─ Span: output_filter (5ms)

짧은 TypeScript pseudo instrumentation은 다음처럼 시작한다. 핵심은 prompt 원문을 span attribute에 바로 넣지 않고, 버전·토큰·해시·finish reason처럼 join 가능한 값만 남기는 것이다.

import { trace, SpanStatusCode } from "@opentelemetry/api";

const tracer = trace.getTracer("refund-agent");

async function runLlmStep(input: RedactedInput) {
  return tracer.startActiveSpan("llm_call", async (span) => {
    span.setAttributes({
      "gen_ai.system": "openai",
      "gen_ai.operation.name": "chat",
      "gen_ai.request.model": "gpt-4.1",
      "app.prompt.version": "refund-v13",
      "app.input.hash": input.hash,
    });

    try {
      const result = await llm.chat(input.messages);
      span.setAttributes({
        "gen_ai.usage.input_tokens": result.usage.input_tokens,
        "gen_ai.usage.output_tokens": result.usage.output_tokens,
        "gen_ai.response.finish_reasons": result.finish_reason,
      });
      return result;
    } catch (error) {
      span.setStatus({ code: SpanStatusCode.ERROR });
      span.recordException(error as Error);
      throw error;
    } finally {
      span.end();
    }
  });
}

Langfuse/OpenTelemetry 통합 경계

Langfuse는 trace·span·generation을 보여주는 관측성 레이어이고, evaluation system은 dataset·run·grader·report를 관리하는 품질 판단 레이어다. 둘을 섞으면 “trace는 많은데 어떤 변경이 좋아졌는지 모르는” 상태가 된다.

경계	책임	저장해야 하는 키
Trace	production 요청 1건의 실제 실행 경로, prompt 조립, retrieval, tool, LLM call	`trace_id`, `span_id`, `session_id`, `user_hash`, `version`
Eval run	특정 dataset 버전 × app/prompt/model 버전을 재실행한 결과	`eval_run_id`, `dataset_version`, `app_version`, `trace_id`
Score	trace·observation·dataset run에 붙는 품질 판단. numeric/categorical/boolean/text	`score_name`, `rubric_version`, `judge_model`, `score`
Report	baseline 대비 delta, 실패 케이스, CI gate 통과 여부	`baseline_run_id`, `candidate_run_id`, `decision`
OpenTelemetry export	provider 중립 trace 전송. Langfuse 외 Datadog·Grafana·Phoenix로도 보낼 수 있는 포맷	`gen_ai.`, `service.`, `deployment.environment`
Langfuse-specific metadata	Langfuse UI·dataset·score 분석에 필요한 확장 필드	`prompt_version`, `release`, `tags`, `metadata`

운영 규칙:

trace와 eval run은 1:N으로 연결한다. production trace 1개가 나중에 여러 grader나 prompt 후보의 eval input으로 재사용될 수 있기 때문이다.
trace_id는 원인 분석용, eval_run_id는 의사결정용이다. 장애 디버깅은 trace에서 시작하고, 배포 승인·회귀 판정은 eval report에서 끝난다.
gen_ai.*는 공통 필드만 담는다: gen_ai.operation.name, gen_ai.request.model, token usage, finish reason처럼 도구 간 이동 가능한 값을 우선한다. prompt 원문·retrieved chunk 원문은 span attribute에 무조건 넣지 말고 events 또는 vendor-specific input/output 필드에 opt-in으로 둔다.
privacy/redaction은 수집 전 단계가 원칙이다. Langfuse masking, OTel Collector processor, app-level PII redactor 중 하나를 ingestion 앞에 두고, 이메일·전화번호·계정 ID·tool argument 안의 secret을 테스트 fixture로 검증한다.
redaction 후 재현성 손실을 보완한다. 원문을 지우면 사고 재현이 어려우므로 input_hash, document_id, retrieval_chunk_id, prompt_version처럼 비식별 재현 키를 함께 남긴다.

Trace 기반 원인 분석 절차

L12에서는 일반 observability 자체보다 LLM/agent trace를 reliability decision으로 바꾸는 과정이 핵심이다. 장애 분석은 dashboard 평균값에서 끝나지 않고, 실패한 요청의 trace_id를 기준으로 span·score·deployment version을 좁혀야 한다.

Alert: hallucination rate +8%p, cost/request +35%
  ↓
Trace filter: route=refund_agent, app_version=2026.05.20, model=gpt-4.1
  ↓
Span diff:
  - retrieval_top_k: 5 → 20
  - prompt_version: refund-v12 → refund-v13
  - tool_call.retry_count: 0 → 3
  ↓
Eval linkage:
  - failed trace 40건을 dataset candidate로 저장
  - baseline run과 candidate run의 slice별 delta 비교
  ↓
Decision:
  - prompt v12 rollback
  - retrieval_top_k guardrail 상한 8
  - high-value refund route는 approval gate 임시 적용

원인 분석 체크포인트:

증상 metric: latency·cost·hallucination·refusal·tool error 중 무엇이 먼저 움직였는지 확인한다.
span coverage: 실패 구간이 trace에 없으면 먼저 instrumentation 누락을 고친다. trace 없는 eval score는 원인 분석이 아니라 알림에 가깝다.
version join: prompt_version, model, retriever_version, tool_schema_version, guardrail_policy_version을 span에 남겨야 rollback 범위가 좁아진다.
failure slice: 전체 평균보다 route, tenant tier, language, retrieval hit/miss, tool name별로 회귀를 본다.
replay 가능성: redaction된 trace라도 input_hash, dataset_item_id, document_id, seed, temperature가 있어야 재현 실험으로 이어진다.

3.4 표준 도구 (2025+ 라인업)

도구	특징
LangSmith	LangChain 기본. trace + eval + dataset
Langfuse	open-source, self-host 가능. trace + cost + eval
Helicone	API gateway + cost dashboard + caching
Arize Phoenix	open-source, eval·drift 강력
OpenLLMetry / Traceloop	OpenTelemetry 기반. 자동 instrument
Weights & Biases (Weave)	ML 생태계 통합. dataset·eval·trace
Datadog LLM Observability	enterprise APM 통합
AgentOps	agent trace 특화
Portkey	gateway + observability + 라우팅
Logfire (Pydantic)	Python 친화, OpenTelemetry-native

선택 기준

OpenTelemetry 표준: OpenLLMetry, Logfire, Datadog
Open-source self-host: Langfuse, Phoenix
LangChain 생태계: LangSmith
API gateway 통합: Helicone, Portkey
Agent 특화: AgentOps, Phoenix

3.5 핵심 Metrics

Latency

TTFT P50/P95/P99 (target: <1s)
TPOT P50/P95/P99 (target: 30~50ms)
End-to-end latency
Queue depth (시간대별)

Cost

호출당 input/output 토큰 분포
모델별 호출 수·비용
Cache hit ratio (target 50%+)
사용자/feature/route별 비용 attribution

Quality

Hallucination rate (faithfulness 기반)
Refusal rate
사용자 피드백 (👍/👎)
Eval 점수 추이

Reliability

Error rate (rate limit, timeout, content filter)
Tool success rate
Agent task completion rate

3.6 Production Eval (L11-80 §3.7 재방문)

Gold Dataset

도메인·작업별 정답 셋 (100~500개). 사람이 검수.

prompt·모델·tool 변경 시 회귀 검증
Promptfoo, Braintrust, LangSmith Hub로 dashboard

LLM-as-Judge in Production

자동 metric (BLEU·ROUGE·exact match) → 1차
LLM-as-judge (GPT-4·Claude) → 자유 텍스트
사람 검수는 의심 케이스만 (sampling 또는 disagreement-based)
bias 주의 (L11-80 §3.5): position·verbosity·self-enhancement·limited reasoning

Online vs Offline Eval

방식	설명	사용처
Offline	변경 전 gold dataset에 회귀	CI/CD에 통합, 빠른 회귀
Online	production traffic 일부에 A/B	실 사용자 영향 측정
Shadow	production traffic 복사로 비교	위험 없이 비교

Evaluation System Architecture

production eval은 “테스트 스크립트 하나”가 아니라 작은 CI 시스템처럼 구성한다.

[Dataset Registry]
   ↓ dataset_version 고정
[Runner]
   ↓ app/prompt/model 실행 + trace_id 생성
[Run Store]
   ↓ output, latency, cost, trace_id, artifacts 저장
[Grader]
   ↓ deterministic check + LLM-as-judge + human sample
[Report]
   ↓ baseline vs candidate 비교, failure slice
[CI Gate]
   ↓ merge/block/manual review

컴포넌트	책임	실패 모드
Dataset registry	gold/shadow/production-sampled dataset과 version, owner, task schema 관리	dataset이 production drift를 반영 못 함
Run store	각 dataset item의 input/output/trace_id/score/artifact를 immutable 저장	run 재현 불가, baseline이 덮어써짐
Grader	exact match, schema validation, Ragas, LLM-as-judge, human annotation 실행	judge prompt 변경으로 점수 의미가 바뀜
Report	score 평균보다 slice별 회귀, p-value/Wilson interval, top failures 출력	평균 점수는 통과하지만 특정 언어·고객군에서 회귀
CI gate	품질·비용·지연 임계 통과 시 배포 승인, 실패 시 block 또는 manual review	flaky judge 때문에 배포가 무작위로 막힘

최소 데이터 모델은 trace와 eval decision을 join할 수 있을 만큼만 시작한다.

테이블/레코드	최소 필드	목적
`datasets`	`dataset_name`, `dataset_version`, `owner`, `task_schema_hash`	어떤 평가 셋을 썼는지 고정
`dataset_items`	`dataset_item_id`, `dataset_version`, `input_hash`, `expected_artifact_ref`, `slice_tags`	재현 가능한 평가 입력과 slice 기준
`eval_runs`	`eval_run_id`, `baseline_run_id`, `app_version`, `prompt_version`, `model_route`, `started_at`, `git_sha`	배포 후보 단위의 비교 기준
`eval_results`	`eval_run_id`, `dataset_item_id`, `trace_id`, `output_hash`, `latency_ms`, `cost_usd`, `status`	실행 결과와 production trace 연결
`scores`	`eval_run_id`, `dataset_item_id`, `score_name`, `score`, `rubric_version`, `grader_name`, `judge_model`	점수 의미와 평가 기준 version 고정

최소 운영 계약:

dataset은 dataset_name@version으로 pinning한다. “latest dataset”으로 CI를 돌리면 같은 commit이 매일 다른 결과를 낸다.
run store는 append-only로 둔다. candidate가 baseline을 덮어쓰면 회귀 분석이 불가능하다.
grader는 grader_name, rubric_version, judge_model, temperature, prompt_hash를 score와 함께 남긴다.
report는 전체 평균 1개가 아니라 slice를 포함한다: language, route, retrieval hit/miss, input length bucket, tenant tier.
CI gate는 hard fail과 soft fail을 나눈다. 예: JSON schema 위반·PII leak은 hard fail, helpfulness -2%p는 manual review.

Evaluation and Reliability Engineering 연결

eval은 “품질 점수표”가 아니라 변경을 배포해도 되는지 판단하는 reliability gate다. SRE의 SLO/error budget이 배포 속도를 조절하듯, LLM 앱에서는 eval score·trace coverage·guardrail violation·human approval rate가 배포 결정을 조절한다.

Reliability 질문	Eval/Trace 신호	운영 결정
이 prompt를 배포해도 되는가	gold dataset pass, slice regression 없음, judge 안정	자동 merge 또는 canary 시작
특정 route가 위험해졌는가	hallucination/refusal/tool error가 route slice에서만 상승	route 단위 rollback 또는 feature flag off
모델 교체가 비용을 폭주시켰는가	token/request, retry_count, cache hit ratio 회귀	model routing rollback, max token guardrail
자동 실행을 유지해도 되는가	confidence 낮음, guardrail hit 증가, human override 증가	approval gate 삽입 또는 risk threshold 상향
평가 자체를 믿어도 되는가	calibration agreement 하락, swap consistency 하락	judge hard gate 해제, 사람 검수 queue로 전환

배포 파이프라인에서는 gate를 3단계로 나눈다.

Pre-merge:
  deterministic check + offline eval + PII/schema hard gate
Canary:
  1~5% traffic + trace coverage + cost/latency SLO + online feedback
Full rollout:
  drift monitor + rollback window + failure trace auto-import

guardrail·rollback·approval gate는 같은 decision layer에 둔다.

Guardrail: 실행 전후 invariant를 강제한다. 예: JSON schema, PII 출력 금지, tool argument allowlist, max token, retrieval top-k 상한.
Rollback: prompt_version, model_route, retriever_config, tool_schema를 독립적으로 되돌릴 수 있어야 한다. 하나의 “LLM 앱 버전”만 있으면 과잉 rollback이 된다.
Approval gate: soft fail이나 high-risk route는 자동 차단 대신 사람 승인 큐로 보낸다. 예: refund amount > $500, legal answer, customer-wide bulk email.
Freeze policy: guardrail hard fail 또는 incident severity가 높으면 prompt/model 변경을 freeze하고, 실패 trace를 dataset에 편입한 뒤 재개한다.

3.7 Drift Detection

production에서 입력 분포·출력 분포가 시간에 따라 변하는 silent failure (L11-30 §3.9).

Input Drift

query 유형 변화 (사용자 행동 변화)
query length, language ratio
새 도메인 등장

Output Drift

평균 응답 길이 변화
refusal rate 변화
hallucination rate 증가
token cost per request 변화

Detection 방법

KS test, MMD (입력 임베딩 분포 비교)
Population Stability Index (PSI)
운영 임계: drift score >0.2 → alert
표준 도구: Evidently AI, Arize Phoenix, Whylabs

깨지는 조건 — drift detection이 거짓말하는 시점

Seasonality와 drift 혼동: 금요일 traffic은 평일과 다른 query 분포를 정상적으로 가진다. 7일 미만 baseline으로 PSI를 돌리면 매 주말 alert가 발화한다. 진단: 같은 요일끼리 비교(weekly seasonality decomposition) 또는 baseline window를 7일 이상으로 늘림.
임베딩 모델 교체 = 가짜 drift: query 임베딩 인코더 버전을 올렸는데 baseline은 옛 인코더 임베딩이면 PSI가 1에 가깝게 튄다 — 실제 사용자 행동은 변하지 않았다. 진단: embedder_version tag를 PSI scope에 함께 묶고, 교체 시 baseline 재계산.
Univariate PSI의 false negative: 개별 feature는 PSI <0.1인데 결합 분포는 다를 수 있음(예: query 길이·언어 비율 각각 정상이나 “짧은 영어 query”가 갑자기 50%→5%로 떨어진 경우). multivariate MMD 또는 임베딩 클러스터 ratio로 보강.
자체 silent failure: drift detector 자체가 죽었는데 metric만 평온해 보일 수 있음 — detector run에 freshness alert(마지막 PSI 계산 시각 >24h 이면 alert) 별도로 걸어야 함.

이 4가지는 §3.16 표의 “Drift false positive 多 → PSI 0.2→0.25”보다 한 단계 앞선 진단(왜 false positive가 나왔는가)에 해당한다.

3.8 Hallucination Detection in Production

Faithfulness check: RAG 답변이 검색 문서에 근거하는가 (Ragas). Score는 “응답 내 claim 중 retrieved context로 뒷받침되는 비율”. 운영 권장 임계는 일반 0.8 이상, 규제 산업(finance·healthcare·legal)은 0.9 이상 (Ragas docs)
- 깨지는 조건 (silent failure): 응답이 단답(숫자·한 단어)이면 LLM이 internal claim 추출에 실패해 점수가 비어버린다 — completeness가 떨어지면 자동 metric을 reference-free(SelfCheckGPT) 또는 사람 검수로 대체. 또한 domain mismatch 시 judge가 “근거 없음”을 “맞음”으로 통과시키는 false positive 발생 (Cleanlab 벤치마크 기준 단순 faithfulness만으로는 hallucination 일부 누락) (Cleanlab RAG hallucination benchmark)
Self-consistency: 같은 query N번 → 일관성 측정
Reference-free: SelfCheckGPT, Lynx, FactScore
Confidence score: logprobs 기반 (낮으면 의심)
Citation 강제: 출처 없는 응답은 의심 표시

3.9 사용자 피드백 Loop

production 운영의 표준.

명시적 피드백: 👍/👎, 별점, 자유 의견
암묵적 피드백: copy/paste 비율, 후속 질문 (재시도), 세션 종료
회귀 케이스 발견: 부정 피드백 → 사람 검수 → gold dataset에 추가
A/B 결정: 두 prompt·모델 중 사용자 만족 더 높은 것

3.10 Incident Response

LLM 사고 대응의 표준.

흔한 사고

비용 폭주 (loop, prompt 누적)
Hallucination 증가 (모델 변경, prompt 변경)
Prompt injection 성공 (system prompt 누출)
응답 품질 저하 (RAG 데이터 stale)
Latency 폭증 (provider 장애)

흐름

1. Alert (cost·latency·error rate 임계 초과)
2. Trace로 원인 분석 (어떤 step·prompt·tool에서)
3. Rollback (이전 prompt·모델·라우팅 정책)
4. Post-mortem (5 whys, gold dataset에 추가)
5. Continuous improvement (prevent recurrence)

Rollback·Guardrail·Approval Gate Runbook

LLM incident는 “서버 재시작”보다 변경면을 좁혀 되돌리는 능력이 중요하다. prompt·retrieval·tool schema·model route가 서로 다른 실패를 만들기 때문이다.

사고 유형	즉시 조치	후속 eval 편입
hallucination 급증	prompt/retriever rollback, citation guardrail	실패 trace를 faithfulness dataset에 추가
tool call 오작동	tool schema freeze, high-risk action 승인 전환	tool argument validation case 추가
비용 폭주	max token 상한, loop breaker, model fallback	long-context·retry loop 케이스 추가
policy/PII 위반	output filter hard block, affected route stop	PII fixture와 refusal/allowed boundary case 추가
judge 회귀로 CI flaky	judge hard gate 해제, human audit queue 확대	calibration set 재채점, rubric version bump

운영 계약:

rollback 대상은 versioned config여야 한다. prompt registry, model routing table, retriever config, guardrail policy를 각각 되돌릴 수 있게 둔다.
approval gate는 incident mitigation 수단이다. route를 완전히 끄기 전에 high-risk action만 사람 승인으로 돌리면 사용자 영향과 위험을 동시에 낮출 수 있다.
post-mortem 산출물은 eval asset이어야 한다. “원인: prompt v13”으로 끝내지 말고, 실패 trace 20~50건을 dataset candidate로 넣고 regression gate에 연결한다.
복구 완료 기준은 metric 정상화 + eval 통과다. P95가 회복되어도 실패 slice가 gold dataset에서 재현되면 full rollout은 보류한다.

운영 도구

PagerDuty/Opsgenie: 알림
trace replay: 사고 시점 재현 (LangSmith·Langfuse)
rollback: prompt·모델·라우팅 이전 버전으로 즉시 복구

3.11 Continuous Improvement Loop

[Production Traffic]
   ↓ trace + 피드백
[Observability dashboard]
   ↓ 문제 식별 (drift, regression, 사용자 부정 피드백)
[Gold dataset에 추가]
   ↓
[Prompt/모델/RAG 개선]
   ↓ Offline eval (gold dataset 회귀)
[A/B test in production]
   ↓ 통계적 유의성 확인
[Full rollout]
   ↓
[다시 모니터링]

이 loop가 LLM 운영 품질의 절반.

3.12 Production Silent Failure

Cache miss explosion: prompt 구조 변경으로 hit ratio 폭락 (L12-70)
Provider 장애: 한 provider만 의존 → 라우팅 fallback 필요
Drift 무시: 입력 분포 변화로 모델 품질 폭락
gold dataset 정체: 새 케이스 안 추가되면 평가가 production 반영 못 함
trace 누락: 일부 step이 trace 안 됨 → debug 불가능
PII trace 노출: trace에 사용자 PII 그대로 — privacy 위험. redaction 필요

3.13 깨지는 조건 정량 표 (운영 결정용)

도구·기법	효과 발휘 범위	깨지는 조건
LangSmith	LangChain 생태계	non-LangChain 앱은 OpenLLMetry로
Langfuse (self-host)	open-source, 독립 운영	큰 traffic은 ClickHouse storage 비용↑
Helicone	API gateway + cost	trace 깊이는 Langfuse·LangSmith가 더 풍부
OpenLLMetry	OTel 표준, provider 중립	자동 instrument 누락 시 manual span 필요
Drift threshold 0.2	input 분포 변화 알림	도메인별 baseline 다름 — 30일 burn-in 후 조정
Gold dataset 50~100	prompt 회귀 빠른 검증	5%p 차이 95% 검출엔 ~400 필요 (Wilson)
LLM-as-judge	자유 텍스트 빠른 평가	코드·수학·전문 영역 → 사람 평가 60%대
A/B test 1% traffic	실 사용자 영향 측정	효과 작으면 통계적 유의성 어려움 (sample 부족)
Shadow eval	위험 없이 비교	실 사용자 영향 측정 X
Faithfulness 자동	RAG 환각 감지	judge 모델 약하면 false positive 多

이 표로 실제 결정한 사례 (도구 선택): 사내 RAG 챗봇 일일 traffic 100k, prompt 회귀를 CI에서 30분 안에 잡아야 했음. 후보 — (a) LangSmith + faithfulness, (b) Langfuse self-host + Ragas, (c) Helicone + 사람 검수.

LangChain을 쓰고 있지 않으니 (a) 제외 — 표의 “LangSmith: non-LangChain 앱은 OpenLLMetry로” 행이 결정 근거.
(c)는 trace 깊이 부족 — 표의 “Helicone: trace 깊이는 Langfuse·LangSmith가 더 풍부” 행이 결정 근거.
(b) 선택, gold dataset은 표의 “5%p 차이 95% 검출엔 ~400 필요”에 따라 50개에서 시작해 부정 피드백 import로 400 목표 (분기 단위).
단점 수용: ClickHouse storage 비용은 일 traffic 100k 기준 월 ~$80 추정으로 trade-off 허용.

이 단계가 표를 본문 결정에 묶는 cross-pollination이다. 같은 표를 보고 다른 traffic·생태계의 팀은 (a)나 (c)를 고를 수 있고, 그 판단도 같은 행을 근거로 표현 가능해야 한다 (일반 SRE의 “tool selection matrix → ADR” 패턴과 동일).

3.14 LLM-as-Judge Bias 완화 절차

수치 출처: “Judging the Judges” (2024, arXiv:2406.07791) — 15개 LLM judge, 22 task, ~150,000 평가 instance 측정. position bias가 무작위 변동이 아니라 모델·task별로 체계적이며, 후보 응답의 품질 차가 클수록 일관성이 회복된다. 따라서 단일 숫자 임계가 아니라 task별 baseline을 잡고 swap test 통과율로 검증해야 한다.

Bias	정량 신호	완화 절차
Position	swap test에서 동일 응답쌍이 순서만 바뀌었을 때 결과가 뒤집힘 (position consistency <0.7 위험)	swap test (반대 순서로 다시 평가, 평균), tie 허용
Verbosity	긴 응답 승률 70%+ — 단 일부 모델은 오히려 padding된 답을 깎아 길이 정규화가 역효과인 경우 있음	length-controlled (AlpacaEval LC) 또는 길이 정규화
Self-enhancement	자기 모델군 승률이 cross-model 평균 대비 +10%p 이상	judge 다양화 (GPT-4 + Claude + open-weight 평균)
Limited reasoning	수학·코드에서 사람 동의율 60%대	도메인 특화 verifier (RLVR style) + 사람 검수
Familiarity	익숙한 형식·톤 선호	random 샘플 사람 검수로 calibration

운영 안전장치

LLM-as-judge는 “평가 모델 하나를 붙이면 끝”이 아니라, judge 자체를 production dependency로 운영해야 한다.

rubric versioning: rubric 문장·점수 스케일·few-shot 예시가 바뀌면 rubric_version을 올린다. 같은 correctness=0.8이라도 v1은 “정답 포함” 기준, v2는 “근거 포함” 기준일 수 있다.
swap test: A/B 응답 순서를 바꿔 judge를 2회 실행하고, 승패가 뒤집히는 비율을 기록한다. position consistency <0.7이면 그 judge 결과는 CI gate의 hard fail로 쓰지 않는다.
calibration set: 사람이 이미 판정한 50~200개 고정 셋을 둔다. judge 모델·prompt·rubric을 바꿀 때 calibration agreement가 baseline보다 떨어지면 배포하지 않는다.
human audit sample: production 자동 평가 중 1~5% 또는 disagreement case를 annotation queue로 보낸다. judge score와 사용자 피드백이 계속 벌어지면 rubric을 수정하고 과거 run을 재채점한다.
judge drift monitoring: 같은 calibration set을 주기적으로 재실행해 score 분포와 reasoning failure를 본다. provider가 모델을 silent update하면 앱은 그대로인데 judge 점수만 움직일 수 있다.
비용·지연 budget: online trace마다 judge를 호출하면 비용이 폭주한다. high-risk route 100%, 일반 route sampling, CI dataset full run처럼 sampling policy를 분리한다.

3.15 Drift Detection 정량

PSI (Population Stability Index):
  PSI < 0.1: 변화 거의 없음
  0.1 ≤ PSI < 0.2: 약간 변화 (모니터링)
  0.2 ≤ PSI < 0.25: 의미 있는 변화 (alert)
  PSI ≥ 0.25: 큰 변화 (즉시 조사·재학습 검토)

KS test:
  p-value < 0.05: 분포 다름 (alert)
  D-statistic > 0.1: 큰 차이

운영 권장: 30일 burn-in 후 PSI > 0.2 alert, 도메인별 추가 조정. baseline은 7일 단위 갱신.

3.16 Silent Failure 복구 절차

증상	정량 신호	원인	복구
Trace 누락	span coverage <90%	instrument 누락	OpenLLMetry 자동, manual span 보강
LLM-as-judge ↔ 사용자 불일치	judge 점수↑ 사용자 ↓	judge bias·도메인 mismatch	judge 재선택, 사람 검수 비율↑
Gold dataset 정체	새 케이스 추가 0/주	피드백 loop 단절	부정 피드백 자동 import, 분기 갱신
Rubric drift	같은 run 재채점 시 delta↑	rubric version 미기록	rubric pinning, calibration 재실행
Eval-run 연결 끊김	score만 있고 trace_id 없음	run store 계약 부재	`eval_run_id`-`trace_id` linkage
Drift false positive 多	drift alert >5/주	임계 너무 낮음	PSI 0.2 → 0.25, multivariate
PII trace 노출	log에 사용자 PII 포함	redaction 누락	Presidio 자동, log mask
Provider 장애 미복구	한 provider 장애로 전체	fallback 부재	LiteLLM·OpenRouter multi-provider
A/B 통계 부족	sample <400, 5%p 검출 불가	traffic 부족	longer rollout, increase % traffic
Guardrail 우회 회귀	hard fail case production 발생	eval fixture 누락	fixture 추가, policy version bump
Approval gate 폭주	reviewer queue backlog↑	threshold 과민·incident 전환	risk threshold 조정, batch review

3.17 Observability·Eval의 일반 매핑 (Transferable Pattern)

LLM observability·eval = “trace + 측정 + 회귀 + 모니터링”. 전통 SRE와 같은 패턴.

LLM Observability·Eval	일반 시스템 매핑
Trace (LangSmith·Langfuse)	distributed tracing (Jaeger, Datadog APM)
Latency P99·TTFT	API endpoint latency SLO
Cost dashboard	cloud cost dashboard (FinOps)
Gold dataset	regression test, golden output
LLM-as-judge	code review bot, automated PR check
A/B test	feature flag rollout (Statsig, GrowthBook)
Drift detection (PSI·KS)	metric anomaly detection, SLO violation alert
Hallucination detection	data validation, contract test
Incident response (rollback)	deploy rollback, feature flag kill switch

일반 공식: “측정 → trace → 비교 → alert → rollback → 학습”의 6단계 SRE 패턴이 LLM 운영에도 동일. LLM이 특별한 점은 비결정적 output + 자유 텍스트 metric이며, observability와 eval이 합쳐진 시스템이 표준.

운영 시나리오 — LLM 챗봇 incident response (예시)

상황: 사내 챗봇 P95 TTFT가 갑자기 5s로 폭증, 비용도 시간당 2× ↑.
Incident 흐름:
  1. Alert (Helicone): TTFT P99 > 3s, cost/h > $50
  2. Trace 분석 (Langfuse):
     - prompt 평균 입력 토큰 800 → 5000 (대화 history 무한 누적!)
     - cache hit ratio 70% → 5% (prompt 구조 변경)
  3. 원인: 어제 prompt 변경 시 sliding window 제거됨
  4. Rollback: prompt 이전 버전으로 즉시 복구
  5. Post-mortem: gold dataset에 long-conversation 케이스 추가, CI 게이트

복구 결과 (가상): 30분 내 P95 정상 (<1s), cost 정상.

대안 비선택:
  - LLM 변경 X (provider 장애 아님)
  - Top-K 변경 X (RAG 정상)
  - 사용자 측 캐시 X (서버측 문제)

drift detection (§3.7):
  - Input drift PSI 0.3 (>0.25 임계) → alert 발동
  - 사용자 피드백 부정 비율 +20% (signal)

§3.4 도구 + §3.7 drift + §3.10 incident response + §3.13 깨지는 조건 + §3.16 silent failure 모두 적용.

4. 실무에서 어디에 쓰이나

LLM 앱의 일상 운영 모니터링
프롬프트·모델 변경 회귀 검증
사고 대응·debugging
비용·SLA 추적
사용자 피드백 → 개선 loop
Compliance audit (HIPAA·GDPR·SOC 2)

5. 현재 내 업무와 연결점

플랫폼 엔지니어가 LLM 관측성·평가를 운영할 때 다음에 도움된다.

OpenTelemetry GenAI 도입: provider·도구 중립적 trace. 자체 instrument
Tool 선택: open-source는 Langfuse·Phoenix, gateway는 Helicone·Portkey, agent는 AgentOps
Gold dataset 운영: 도메인 50~500개 + 사람 검수 + Promptfoo dashboard
Drift detection: PSI·KS test로 입력 분포 모니터링 → retraining 트리거
Incident response: trace replay + rollback 표준화
Continuous improvement: 사용자 피드백 → gold dataset → 재평가 loop 자동화

6. 자주 헷갈리는 개념 비교

개념 A	개념 B	차이점
Observability	Monitoring	trace·log·metric 통합 vs metric 중심
Trace	Log	hierarchical span vs 단일 시점 메시지
Trace	Eval run	실제 요청 실행 경로 vs dataset 기준 재실행 결과
Offline eval	Online eval (A/B)	gold dataset 회귀 vs 실 traffic 측정
Online eval	Shadow eval	일부 사용자에 적용 vs traffic 복사로 비교
Score	Rubric	평가 결과 값 vs 점수 기준·버전
Latency P50	P95/P99	평균적 vs 꼬리. UX는 P95+ 결정
Faithfulness	Hallucination rate	문서 근거 비율 vs 환각 비율 (relation)
Drift detection	A/B test	분포 변화 vs 의도한 변경 효과
LangSmith	Langfuse	LangChain 친화 vs open-source self-host
Datadog LLM Obs	OpenLLMetry	enterprise APM 통합 vs OTel 표준 자동 instrument

7. 체크리스트

8. 추가 학습 키워드

표준: OpenTelemetry GenAI semantic conventions, gen_ai.*, OTLP, OTel Collector, OTEL_SEMCONV_STABILITY_OPT_IN
도구: LangSmith, Langfuse, Helicone, Arize Phoenix, OpenLLMetry, Traceloop, Weave (W&B), Datadog LLM Obs, AgentOps, Portkey, Logfire
Eval: Promptfoo, Braintrust, Ragas, TruLens, DeepEval, ARES, dataset registry, run store, CI gate
Reliability Engineering: reliability gate, rollout policy, rollback, guardrail policy, approval gate, failure slice
Judge 운영: rubric versioning, swap test, calibration set, annotation queue, human audit sample
Drift: Evidently AI, Whylabs, NannyML, Arize Phoenix
Hallucination: SelfCheckGPT, Lynx, FactScore, Patronus, RAGAS faithfulness
Privacy: PII redaction, prompt masking, tool argument masking, data retention
Feedback: implicit signals, A/B framework (Statsig, GrowthBook, Eppo)

9. 내가 직접 확인해볼 것

Trace 도입

OpenLLMetry로 OpenAI/Anthropic API 호출 자동 trace — span attribute 확인
LangSmith 또는 Langfuse 통합 — RAG·agent trace dashboard
gen_ai.operation.name, token usage, finish reason이 OTel exporter와 Langfuse 양쪽에서 같은 trace에 남는지 확인
email·phone·secret이 포함된 fixture로 Langfuse masking 또는 OTel Collector redaction 테스트

Metrics

Helicone API gateway 도입 → cost·latency dashboard 확인
Cache hit ratio·TTFT P95 알람 설정

Eval

gold dataset 50개 만들고 Promptfoo로 prompt A vs B 비교
Ragas로 RAG faithfulness·answer relevance 측정 자동화
dataset@version을 고정해 eval run을 만들고, 각 item output에 trace_id를 연결
deterministic grader + LLM-as-judge + 사람 검수 샘플을 한 report에 합치기
judge rubric v1/v2를 나눠 같은 calibration set 재채점 후 score delta 비교
swap test로 A/B 응답 순서를 바꿨을 때 승패 뒤집힘 비율 측정
CI gate 임계값 설정: schema/PII hard fail, quality delta soft fail

Drift

Evidently AI로 입력 query 임베딩의 PSI 계산 — 한 달 단위
drift > 0.2 alert 설정

Hallucination

SelfCheckGPT 또는 RAGAS faithfulness로 답변 100개 자동 평가
confidence score(logprobs) 기반 의심 케이스 자동 raise

Incident

의도적 prompt 회귀 (잘못된 prompt 배포) → alert 발동·trace replay·rollback 시뮬레이션
비용 폭주 시뮬레이션 (긴 input) → budget alert 발동
실패 trace 20개를 dataset candidate로 저장하고, 다음 CI gate에서 재현되는지 확인
high-risk route를 feature flag로 approval gate에 임시 전환하는 runbook 작성

결과가 예상과 다를 때

trace에 일부 step 누락 → instrument 누락. SDK 또는 manual span 추가
LLM-as-judge 점수가 사용자 피드백과 안 맞음 → judge 모델 변경, judge prompt 개선
같은 candidate가 실행할 때마다 CI에서 통과/실패 반복 → dataset version·rubric version·judge temperature pinning 확인
eval score만 있고 원인 분석이 안 됨 → score에 연결된 trace_id·observation span 누락 확인
redaction 후 trace replay가 안 됨 → 원문 대신 input_hash·document id·prompt version 같은 재현 키 보강
drift detection false positive 多 → 임계값 재조정, multivariate detector
gold dataset 점수는 좋은데 production 부정 피드백 → gold dataset이 production 분포와 다름. 새 케이스 추가

10. 5줄 요약

LLM observability는 trace·metric·prompt·cost·token·hallucination 등 LLM 특유 dimension을 통합 관측한다.
OpenTelemetry GenAI semantic conventions가 provider·도구 중립 표준이고, OpenLLMetry·Logfire가 자동 instrument.
Production eval은 offline·online·shadow 결과를 reliability gate로 바꿔 배포·rollback·approval 전환을 결정한다.
Drift detection (KS·PSI), hallucination detection (faithfulness·SelfCheckGPT), 사용자 피드백 loop가 핵심 도구.
Incident response는 alert → trace 원인 분석 → rollback/guardrail/approval gate → eval asset 편입으로 닫힌다.

11. 출처

최종 수정: 2026-05-21