LLM 운영을 위한 관측성과 평가

LLM 관측성과 평가는 trace, metric, cost, token, hallucination, eval run을 연결해 변경을 배포해도 되는지 판단하는 운영 체계다. 핵심은 provider 중립 trace와 재현 가능한 평가 자산을 묶어 장애 분석, 회귀 검증, rollback, 개선 loop까지 닫는 것이다.

Layer: L12
Duration: 길이 미정
Generated: 2026. 5. 25. 오후 4:24:03

원본 문서 읽기 오디오 파일 열기

Script Companion

오디오와 함께 스크립트 보기

01
LLM 관측성과 평가는 production 운영에서 prompt나 모델 변경의 영향을 확인하기 위한 기반이다. 평가가 없으면 응답이 좋아졌는지, 비용이 늘었는지, 특정 route에서 hallucination이 증가했는지 알기 어렵다. 특히 LLM 앱은 일반 웹 요청처럼 성공과 실패가 명확히 나뉘지 않는다. 같은 입력에도 다른 출력이 나올 수 있고, 응답은 정상처럼 보여도 근거가 부족하거나 tool call이 잘못될 수 있다. 그래서 latency, cost, token, cache, hallucination, 사용자 피드백을 함께 보아야 한다.
02
일반 APM과 LLM Observability의 차이는 관측 단위에서 시작된다. 전통 APM은 request, span, error를 중심으로 보지만, LLM 관측성은 여기에 prompt, completion, tool call을 더한다. 비용도 infra cost만 보는 것이 아니라 input token과 output token을 분리해 본다. 품질도 error rate 하나로 충분하지 않고 hallucination, faithfulness, helpfulness 같은 자유 텍스트 품질 지표가 필요하다. Latency 역시 전체 응답 시간뿐 아니라 TTFT, TPOT, queue를 나누어 보아야 병목을 찾을 수 있다.
03
OpenTelemetry GenAI Semantic Conventions는 2024년에서 2025년에 정착된 LLM trace 표준으로, provider와 도구를 바꾸어도 같은 schema로 관측하려는 목적을 가진다. OpenAI, Anthropic, Gemini, open-weight를 같은 방식으로 다룰 수 있고 Datadog, NewRelic, Honeycomb, Grafana가 자동 파싱할 수 있다는 점이 가치다. OpenLLMetry와 Traceloop은 Python과 TypeScript 자동 instrument 라이브러리로 언급된다. 다만 GenAI semconv는 development 상태이므로 instrumentation 버전과 OTEL_SEMCONV_STABILITY_OPT_IN 같은 opt-in 정책을 CI에서 고정해야 한다.
04
LLM 앱의 trace는 hierarchical trace로 보는 것이 자연스럽다. 한 production 요청 안에 prompt 조립, retrieval, tool, LLM call이 이어지고, 각각이 span으로 남는다. 여기서 중요한 원칙은 prompt 원문을 span attribute에 바로 넣지 않는 것이다. 대신 trace_id, span_id, session_id, user_hash, version, token usage, finish reason, input_hash, document_id, retrieval_chunk_id, prompt_version처럼 join 가능하고 재현 가능한 값을 남긴다. 원문이나 retrieved chunk는 events 또는 vendor-specific input/output 필드에 opt-in으로 둔다.
05
Langfuse와 evaluation system의 경계도 분리해야 한다. Langfuse는 trace, span, generation을 보여주는 관측성 레이어이고, evaluation system은 dataset, run, grader, report를 관리하는 품질 판단 레이어다. 둘을 섞으면 trace는 많은데 어떤 변경이 좋아졌는지 모르는 상태가 된다. 운영 규칙은 trace와 eval run을 1:N으로 연결하는 것이다. production trace 1개가 나중에 여러 grader나 prompt 후보의 eval input으로 재사용될 수 있기 때문이다. trace_id는 원인 분석용이고 eval_run_id는 의사결정용이다.
06
Trace 기반 원인 분석은 dashboard 평균값에서 끝나지 않는다. 실패한 요청의 trace_id를 기준으로 span, score, deployment version을 좁혀야 한다. 먼저 latency, cost, hallucination, refusal, tool error 중 어떤 metric이 움직였는지 확인한다. 실패 구간이 trace에 없다면 score를 해석하기 전에 instrumentation 누락부터 고친다. prompt_version, model, retriever_version, tool_schema_version, guardrail_policy_version을 span에 남겨야 rollback 범위가 좁아진다. 전체 평균보다 route, tenant tier, language, retrieval hit/miss, tool name별 failure slice를 보는 것도 중요하다.
07
도구 선택은 생태계와 운영 경계에 맞춰야 한다. LangSmith는 LangChain 기본 trace, eval, dataset에 강하고, Langfuse는 open-source와 self-host 가능성이 장점이다. Helicone은 API gateway, cost dashboard, caching에 가깝고, Arize Phoenix는 open-source eval과 drift에 강하다. OpenLLMetry와 Traceloop은 OpenTelemetry 기반 자동 instrument이고, Weights & Biases Weave는 ML 생태계 통합을 제공한다. Datadog LLM Observability는 enterprise APM 통합, AgentOps는 agent trace 특화, Portkey는 gateway와 observability와 routing, Logfire는 Python 친화와 OpenTelemetry-native가 특징이다.
08
핵심 metric은 latency, cost, quality, reliability로 나누어 본다. Latency에서는 TTFT P50, P95, P99의 target을 1초 미만으로 보고, TPOT P50, P95, P99는 30에서 50밀리초를 target으로 둔다. End-to-end latency와 시간대별 queue depth도 함께 본다. Cost에서는 호출당 input과 output 토큰 분포, 모델별 호출 수와 비용, cache hit ratio를 본다. Cache hit ratio target은 50% 이상으로 제시된다. Quality에서는 faithfulness 기반 hallucination rate, refusal rate, 사용자 피드백, eval 점수 추이를 추적한다.
09
Production eval은 테스트 스크립트 하나가 아니라 작은 CI 시스템처럼 구성된다. Gold Dataset은 도메인과 작업별 정답 셋으로 100에서 500개를 사람이 검수해 만들고, prompt, 모델, tool 변경 시 회귀 검증에 쓴다. Offline eval은 변경 전 gold dataset으로 빠른 회귀를 보고 CI/CD에 통합한다. Online eval은 production traffic 일부에 A/B를 적용해 실사용자 영향을 본다. Shadow eval은 production traffic 복사로 위험 없이 비교하지만 실사용자 영향 측정은 아니다. 이 세 방식은 서로 대체가 아니라 다른 위험을 보는 장치다.
10
Evaluation system의 최소 계약은 재현성과 비교 가능성이다. Dataset registry는 dataset version, owner, task schema를 관리하고, run store는 각 item의 input, output, trace_id, score, artifact를 immutable하게 저장한다. Grader는 exact match, schema validation, Ragas, LLM-as-judge, human annotation을 실행한다. Report는 평균 점수만 내지 않고 slice별 회귀, p-value, Wilson interval, top failures를 보여야 한다. CI gate는 JSON schema 위반이나 PII leak처럼 hard fail할 항목과 helpfulness 2%p 하락처럼 manual review로 보낼 항목을 나누어야 한다.
11
Eval은 품질 점수표가 아니라 변경을 배포해도 되는지 판단하는 reliability gate다. SRE의 SLO와 error budget이 배포 속도를 조절하듯, LLM 앱에서는 eval score, trace coverage, guardrail violation, human approval rate가 배포 결정을 조절한다. Guardrail은 JSON schema, PII 출력 금지, tool argument allowlist, max token, retrieval top-k 상한 같은 실행 전후 invariant를 강제한다. Rollback은 prompt_version, model_route, retriever_config, tool_schema를 독립적으로 되돌릴 수 있어야 한다. Approval gate는 soft fail이나 high-risk route를 사람 승인 큐로 보내는 장치다.
12
Drift Detection은 production에서 입력 분포나 출력 분포가 시간에 따라 변하는 silent failure를 잡기 위한 장치다. Input drift는 query 유형 변화, query length, language ratio, 새 도메인 등장으로 드러난다. Output drift는 평균 응답 길이 변화, refusal rate 변화, hallucination rate 증가, token cost per request 변화로 보인다. 방법으로는 KS test, 입력 임베딩 분포 비교를 위한 MMD, Population Stability Index가 제시된다. 운영 권장은 30일 burn-in 후 PSI 0.2 초과 alert이고, baseline은 7일 단위로 갱신하며 도메인별 추가 조정이 필요하다.
13
Drift detection은 깨지는 조건도 명확하다. 금요일 traffic처럼 정상적인 seasonality를 drift로 오해할 수 있으므로 같은 요일끼리 비교하거나 baseline window를 7일 이상으로 늘려야 한다. query 임베딩 인코더 버전을 올렸는데 baseline은 옛 인코더라면 PSI가 1에 가깝게 튀어도 실제 사용자 행동 변화가 아닐 수 있다. 이때는 embedder_version tag를 PSI scope에 묶고 baseline을 재계산한다. 개별 feature의 PSI가 낮아도 결합 분포가 달라질 수 있으므로 multivariate MMD나 임베딩 클러스터 ratio로 보강한다. detector run 자체에는 freshness alert도 필요하다.
14
Hallucination Detection에서는 faithfulness check가 핵심이다. RAG 답변이 검색 문서에 근거하는지 보고, score는 응답 내 claim 중 retrieved context로 뒷받침되는 비율로 정의된다. 운영 권장 임계는 일반 0.8 이상, finance, healthcare, legal 같은 규제 산업은 0.9 이상이다. 다만 단답 응답에서는 LLM이 internal claim 추출에 실패해 점수가 비어버릴 수 있고, domain mismatch에서는 judge가 근거 없음을 맞음으로 통과시키는 false positive가 생길 수 있다. 이 경우 reference-free 방식이나 사람 검수로 대체한다. 사용자 피드백은 부정 피드백을 사람 검수로 보내 gold dataset에 추가하는 loop로 연결한다.
15
Incident response에서는 변경면을 좁혀 되돌리는 능력이 중요하다. 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를 eval에 넣는다. 복구 완료 기준은 metric 정상화와 eval 통과다.
16
LLM-as-judge는 평가 모델 하나를 붙이면 끝나는 기능이 아니라 production dependency로 운영해야 한다. Judging the Judges는 15개 LLM judge, 22 task, 약 150,000 평가 instance에서 position bias가 무작위 변동이 아니라 모델과 task별로 체계적이라고 설명한다. 그래서 task별 baseline을 잡고 swap test 통과율을 본다. position consistency가 0.7 미만이면 그 judge 결과를 CI gate의 hard fail로 쓰지 않는다. rubric 문장, 점수 스케일, few-shot 예시가 바뀌면 rubric_version을 올리고, calibration set 50에서 200개로 agreement를 확인한다. online trace마다 judge를 호출하지 않고 high-risk route와 일반 route sampling을 분리하는 비용과 지연 budget도 필요하다.

같은 레이어

L12에서 이어 듣기

원본 문서: content/topics/L12/llm-observability-and-evals.md
오디오 파일: /podcasts/l12-llm-observability-and-evals.mp3