LLM 관측성 (LLM Observability): 프로덕션 환경에서 무엇이 문제를 일으키며 어떻게 계측할 것인가
요약
LLM 애플리케이션의 프로덕션 환경에서 전통적인 APM 지표만으로는 부족함을 설명하고, LLM 특화 관측성(Observability)의 필요성을 다룹니다. 지연 시간의 세분화, 토큰 사용량 및 비용 추적 등 LLM 성능과 품질을 예측하기 위한 핵심 신호들을 제시합니다.
핵심 포인트
- 전통적 APM 지표(RED) 외에 LLM 특화 지표가 필요함
- 지연 시간을 TTFT, 토큰 간 지연, 전체 완료 시간으로 분해하여 측정
- 토큰 사용량과 비용(input/output tokens)에 대한 정밀한 추적 필수
- 환각 및 행동 경계 이탈을 감지하는 품질 모니터링의 중요성
전통적인 애플리케이션 성능 모니터링 (Application Performance Monitoring, APM)은 지연 시간 (latency), 에러율 (error rate), 그리고 처리량 (throughput)을 추적합니다. PostgreSQL 데이터베이스를 기반으로 하는 REST API의 경우, 이것만으로 충분합니다. 시스템은 결정론적 (deterministic)이며, 실패 모드는 잘 알려져 있고, p99 지연 시간 급증은 한정된 원인을 가집니다.
LLM 애플리케이션은 이 모델을 깨뜨립니다. 동일한 프롬프트 (prompt)가 연속된 호출에서 서로 다른 출력을 생성할 수 있습니다. 지연 시간은 출력 길이에 따라 수 자릿수 차이가 납니다. "성공적인" 응답 (HTTP 200, 유효한 JSON)이라 할지라도 환각 (hallucination)된 사실, 유해한 콘텐츠, 또는 시스템 프롬프트 (system prompt)와 모순되는 지침을 포함할 수 있습니다. 전통적인 모니터링의 기준이 되는 에러율 지표는 기껏해야 후행 지표 (lagging indicator)가 되거나, 최악의 경우 오해의 소지가 있는 지표가 됩니다.
LLM 관측성 (LLM observability)은 단순히 가용성 (availability)과 지연 시간 (latency)뿐만 아니라, 토큰 경제성 (token economics), 출력 품질 (output quality), 그리고 자율 에이전트 (autonomous agents)가 경로를 이탈하지 않도록 유지하는 행동 경계 (behavioral boundaries) 등 프로덕션 실패를 실제로 예측할 수 있는 신호들을 포착하기 위해 LLM 애플리케이션을 계측 (instrumenting)하는 관행을 의미합니다.
중요한 다섯 가지 신호
전통적인 APM은 세 가지 신호, 즉 지연 시간 (latency), 에러율 (error rate), 처리량 (throughput) (RED 방법론)을 제공합니다. LLM 애플리케이션에는 다섯 가지가 필요합니다.
1. 지연 시간 (Latency) — 분해
단일 LLM 호출에는 세 가지 지연 시간 구성 요소가 있습니다: 첫 번째 토큰까지의 시간 (time to first token, TTFT), 토큰 간 지연 시간 (inter-token latency) (스트리밍 속도), 그리고 **전체 완료 시간 (total completion time)**입니다. TTFT는 사용자가 체감하는 응답성이 첫 단어가 얼마나 빨리 나타나는지에 달려 있는 사용자 대면 채팅 애플리케이션에서 중요합니다. 전체 완료 시간은 작업을 수행하기 전에 전체 응답을 기다려야 하는 배치 파이프라인 (batch pipelines) 및 에이전트 도구 호출 (agent tool calls)에서 중요합니다.
8초의 p99 지연 시간은 배치 요약 작업에는 괜찮지만, 채팅 인터페이스에는 치명적입니다. TTFT와 전체 시간을 별도의 지표로 보고하되, 모델과 제공자 (provider)별로 세분화하십시오.
2. 토큰 사용량 및 비용 (Token usage and cost)
모든 LLM 호출에는 입력 토큰 (input tokens, 사용자의 프롬프트)과 출력 토큰 (output tokens, 모델의 응답)에 의해 결정되는 비용이 발생합니다. 모델이 최대 길이의 출력을 생성하도록 유도하는 프롬프트 인젝션 (prompt injection)은 요청당 비용을 급격히 상승시킬 수 있습니다. 너무 많은 컨텍스트를 프롬프트에 밀어 넣는 검색 증강 생성 (RAG, retrieval-augmented generation) 파이프라인은 품질을 개선하지 못한 채 입력 토큰만 소모합니다.
요청당 input_tokens, output_tokens, 그리고 total_cost_usd를 추적하십시오. 모델, 엔드포인트 (endpoint), 사용자별로 집계하십시오. 분당 비용 (cost-per-minute)에 대한 알림을 설정하십시오. 제어되지 않는 에이전트 루프 (agent loop)나 프롬프트 인젝션 공격은 에러율 (error rates)에 나타나기 전에 비용 급증으로 먼저 나타납니다.
3. 에러율 (Error rate) — 확장
HTTP 레벨의 에러 (429 속도 제한 (rate limits), 500 서버 에러, 타임아웃 (timeouts))는 명백한 실패 사례입니다. 하지만 LLM 애플리케이션에는 두 가지 추가적인 에러 클래스가 있습니다:
- 구조화된 출력 실패 (Structured output failures). 특정 스키마 (schema)를 가진 JSON을 요청했으나, 모델이 파싱할 수 없는 값을 반환한 경우입니다. 이는 유효한 JSON을 포함한 200 응답이지만 사용자의 스키마와 일치하지 않는 경우로, 전통적인 모니터링으로는 감지할 수 없습니다.
- 가드레일 위반 (Guardrail violations). 모델이 안전 필터 (safety filters)에서 거부되는 콘텐츠를 생성한 경우입니다. API 관점에서는 LLM 호출이 "성공"했지만, 애플리케이션은 해당 결과를 제공하기를 거부한 상황입니다.
각 클래스를 별도로 추적하십시오. "OpenAI가 429를 반환함"과 "출력이 스키마 검증에 실패함"을 혼합한 집계 에러율은 근본 원인을 가립니다.
4. 출력 품질 지표 (Output quality indicators)
이는 전통적인 APM (Application Performance Monitoring)에는 상응하는 개념이 없는 신호입니다. 결정론적 (deterministic) API는 올바른 결과를 반환하거나 에러를 반환합니다. 반면 LLM은 구문론적으로 유효하고 구조적으로 정확하지만, 사실관계가 틀린 응답을 반환할 수 있습니다.
모든 응답을 정답 (ground truth)과 대조하는 풀스택 품질 평가 (Full-stack quality evaluation)는 프로덕션 환경에서 비용이 너무 많이 듭니다. 대신, 다음과 같은 대리 지표 (proxy indicators)를 추적하십시오:
- 종료 사유 (Finish reason).
stop은 모델이 자연스럽게 완료되었음을 의미합니다.length는 토큰 제한에 도달했음을 의미하며, 이는 응답이 불완전함을 뜻합니다.content_filter는 안전 시스템(safety system)이 개입했음을 의미합니다. 종료 사유의 분포를 추적하십시오.length가 급증한다면 프롬프트가 컨텍스트 윈도우 (context window)를 초과하는 응답을 생성하고 있다는 신호입니다. - 잠재적 피드백 루프 (Latent feedback loops). 출력 품질과 상관관계가 있는 사용자 행동들 — 재시도율 (retry rate), 제안 수락 후 수정률 (edit rate), 행동 전 읽기에 소비된 시간 등입니다. 이는 애플리케이션마다 다르지만, 종종 사용 가능한 가장 좋은 품질 신호가 됩니다.
- 기대 출력과의 의미론적 유사도 (Semantic similarity to expected output). 참조 답변이 있는 작업 (RAG, 요약 등)의 경우, 모델 출력과 기대 결과 사이의 임베딩 코사인 유사도 (embedding cosine similarity)를 계산하십시오. 이를 지표로 추적하고 분포 변화 (distribution shifts) 발생 시 알림을 설정하십시오.
5. 비용 차단기 (Cost circuit breakers)
도구를 호출하고, 결과에 대해 추론하며, 다시 더 많은 도구를 호출하는 루프를 도는 에이전트 시스템 (Agent systems)은 무제한의 비용을 축적할 수 있습니다. 오류를 잘못 해석하여 실패하는 동일한 방식을 50번이나 재시도하는 코딩 에이전트는 진전 없이 토큰만 소모합니다.
세션당 및 사용자당 누적 비용을 추적하십시오. 엄격한 제한을 설정하십시오. 단일 에이전트 세션이 비용 임계값을 초과하면 종료하십시오. 이는 단순한 비즈니스 문제가 아니라, 단 하나의 잘못된 입력이 API 예산을 고갈시키는 것을 방지하는 안전 경계 (safety boundary)입니다.
전통적인 모니터링이 충분하지 않은 이유
근본적인 문제는 **비결정성 (non-determinism)**입니다. 전통적인 모니터링은 동일한 입력이 동일한 출력을 생성한다고 가정하므로, 집계된 지표 (aggregate metrics)를 통해 시스템 동작을 추론할 수 있습니다. 하지만 LLM 애플리케이션은 모든 계층에서 이 가정을 위반합니다:
- 프롬프트 민감도 (Prompt sensitivity). 프롬프트에 단어 하나를 추가하는 것만으로도 모델의 동작이 유익한 상태에서 유해한 상태로 변할 수 있습니다. 전통적인 시스템에는 이와 유사한 사례가 없습니다. REST 엔드포인트에 쿼리 파라미터를 추가한다고 해서 응답 스키마 (response schema)가 무작위로 변하지는 않기 때문입니다.
- 모델 드리프트 (Model drift). OpenAI가 백그라운드에서
gpt-4o를 업데이트할 때 (모델 이름은 동일하지만 가중치 (weights)가 변경됨), 사용자의 측면에서 별도의 배포가 없었음에도 애플리케이션의 동작이 변합니다.gen_ai.request.model과gen_ai.response.model속성이 서로 다를 수 있으며, 이 차이는 모니터링할 가치가 있습니다. - 컨텍스트 윈도우 경제성 (Context window economics). 128k 컨텍스트 윈도우 (context window)를 가진다고 해서 그 전부를 사용해야 한다는 의미는 아닙니다. 한계치에 가까워질수록 성능과 비용이 저하됩니다. 전통적인 APM (Application Performance Monitoring)에는 "이 요청이 가용 입력 용량의 87%를 사용했다"와 같은 개념이 없습니다.
OpenTelemetry GenAI 컨벤션을 활용한 계측 (Instrumenting)
OpenTelemetry GenAI 시맨틱 컨벤션 (semantic conventions)은 LLM 텔레메트리 (telemetry)를 위한 표준 스키마를 정의합니다. v1.40.0 (2026년 2월) 기준으로 gen_ai.* 네임스페이스 (namespace)는 실험적 단계이지만, 이미 주요 계측 라이브러리들에 채택되었습니다.
모든 LLM 호출은 {operation} {model}이라는 표준화된 이름을 가진 스팬 (span)이 됩니다. GPT-4o에 대한 채팅 완성 (chat completion)은 chat gpt-4o라는 이름의 스팬을 생성합니다. 주요 속성은 다음과 같습니다:
Span: chat gpt-4o
Kind: CLIENT
Attributes:
...
에이전트 시스템 (agent systems)의 경우, 컨벤션은 create_agent, invoke_agent, execute_tool과 같은 추가적인 스팬 유형을 정의합니다. 에이전트 스팬 트리 (span tree)는 전체 결정 체인 (decision chain) — 즉, 에이전트가 무엇을 하기로 결정했는지, 어떤 도구 (tools)를 호출했는지, 그리고 각 도구가 무엇을 반환했는지를 보여줍니다. 에이전트 스팬은 gen_ai.agent.name을 포함하고 도구 실행 스팬은 gen_ai.tool.name을 포함하므로, 도구별 및 에이전트 단계별로 비용과 지연 시간 (latency)을 추적할 수 있는 능력을 제공합니다.
OTel Collector는 이러한 스팬 (spans)을 다른 모든 OTLP 데이터와 동일하게 처리합니다. 트레이스 (trace) 시각화를 위해 Jaeger로, 메트릭 (metrics) 집계를 위해 Prometheus로, 그리고 이벤트 수준의 상세 정보를 위해 로그 백엔드 (log backend)로 내보낼 수 있습니다. 별도의 커스텀 파이프라인 (custom pipeline)은 필요하지 않습니다.
프롬프트 (Prompt) 및 완성 (completion) 콘텐츠는 기본적으로 캡처되지 않습니다 — 이 데이터에는 사용자 데이터가 포함되어 있으며 잠재적으로 크기가 클 수 있기 때문입니다. 전체 텍스트 디버깅 (full-text debugging)이 필요한 경우 OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT 환경 변수를 사용하여 옵트인 (opt in) 하십시오.
도구 생태계 — 솔직한 평가
LLM 특화 관측성 플랫폼
| 도구 | 강점 | 약점 |
|---|---|---|
| LangSmith | 깊은 LangChain 통합, 프롬프트 버전 관리 (prompt versioning), 평가 데이터셋 (evaluation datasets), 어노테이션 큐 (annotation queues). | LangChain에 밀접하게 결합됨. LangChain을 사용하지 않는 경우 가치가 제한적임. 폐쇄 소스 (Closed source). |
| ... |
LLM 지원을 포함하는 일반 관측성 플랫폼
| 도구 | 강점 | 약점 |
|---|---|---|
| Datadog LLM Observability | 기존 APM과 통합됨, 새로운 벤더 (vendor)가 필요 없음, 프롬프트 수준의 트레이스 (traces). | 비용이 비쌈. LLM 모니터링은 이미 고가인 플랫폼에 추가되는 애드온 (add-on) 형태임. |
| New Relic AI Monitoring | 유사한 통합 접근 방식, 사용량 기반 가격 책정 (consumption-based pricing). | GenAI 기능이 Datadog에 비해 최신이며 성숙도가 낮음. |
OpenTelemetry 네이티브 경로
자동 계측 (auto-instrumentation) 라이브러리(opentelemetry-instrumentation-openai, opentelemetry-instrumentation-anthropic)와 함께 OTel GenAI 시맨틱 컨벤션 (semantic conventions)을 사용하고, 기존의 관측성 스택 (Jaeger + Prometheus + Grafana)으로 내보내며, 컨벤션이 다루지 않는 품질 신호 (quality signals)를 위한 커스텀 메트릭 (custom metrics)을 추가하십시오.
이 경로는 설정 비용이 가장 높지만 벤더 종속성 (vendor lock-in)이 가장 낮습니다. 데이터 파이프라인을 직접 소유하고, 스키마 (schema)를 직접 소유하며, 재계측 (re-instrumenting) 없이 백엔드를 전환할 수 있습니다.
무엇을 먼저 계측할 것인가
오늘날 프로덕션 환경에서 LLM 호출을 실행하고 있으면서 HTTP 수준의 모니터링 외에 관측성 (Observability)이 전혀 없다면, 다음과 같은 우선순위를 권장합니다.
1주 차: 토큰 사용량 및 비용 추적 (Token usage and cost tracking). 이는 프로덕션 장애가 막대한 비용으로 이어지기 전에 포착할 가능성이 가장 높은 신호입니다. OTel 자동 계측 (auto-instrumentation)을 추가하고, 기존의 메트릭 백엔드 (metrics backend)로 내보낸 뒤, 일일 비용 알림을 설정하세요.
2주 차: 지연 시간 분해 (Latency decomposition). 모델별로 첫 토큰 생성 시간 (TTFT, Time To First Token) 대 전체 완료 시간 (total completion time)을 분해하여 분석하세요. 각 항목에 대해 SLO (Service Level Objectives)를 설정하세요. 예를 들어, 채팅 인터페이스의 경우 TTFT를 p95 기준 500ms 미만으로, 배치 (batch) 작업의 경우 전체 시간을 p95 기준 10초 미만으로 설정할 수 있습니다.
3주 차: 에러 분류 (Error classification). HTTP 에러, 구조화된 출력 (structured output) 실패, 가드레일 (guardrail) 위반을 분리하세요. 각 클래스를 독립적으로 보여주는 대시보드를 구축하세요.
4주 차: 출력 품질 베이스라인 (Output quality baselines). 종료 사유 (finish reason) 분포 로깅을 시작하세요. 참조 답변 (reference answers)이 있다면 임베딩 유사도 점수 (embedding similarity scores)를 계산하고 그 분포를 추적하세요. 절대적인 임계값이 아니라 분포의 변화 (distribution shifts)에 대해 알림을 설정하세요. 여러분이 찾는 것은 완벽함이 아니라 변화입니다.
그 아래에 있는 인프라 계층
LLM 관측성 도구는 애플리케이션 내부에서 발생하는 일을 추적합니다. 하지만 여러분의 애플리케이션은 외부 인프라, 즉 OpenAI API, Anthropic API, 벡터 데이터베이스 (vector database), 임베딩 서비스 (embedding service)에 의존합니다. 이 중 어느 하나라도 성능이 저하되면 LLM 애플리케이션도 저하되며, 그 근본 원인은 애플리케이션 수준의 계측 (instrumentation)으로는 보이지 않습니다.
모델 제공업체의 API 상태, Pinecone 엔드포인트의 상태, 임베딩 서비스의 지연 시간을 30초마다 확인하는 외부 모니터를 사용하면, 제공업체의 장애가 애플리케이션 전체로 전파되기 전에 포착할 수 있습니다. LLM 관측성 대시보드에 지연 시간 급증 (latency spike)이 나타났을 때, 그것이 여러분의 코드 문제인지 아니면 제공업체의 문제인지 즉시 알아야 합니다. 가장 중요한 모델 제공업체 엔드포인트부터 시작하여 app.devhelm.io에서 인프라 체크를 설정하세요.
원문은 DevHelm에 게시되었습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기