마이크로서비스가 실패할 때는 눈에 띄는 특징이 있습니다. Java 백엔드의 Null Pointer Exception(널 포인터 예외)이거나, Datadog에 명확한 흔적을 남기는 NGINX 인그레스(ingress)의 504 Gateway Timeout일 것입니다.
에러율의 급증이 보이고, p99 지연 시간(latency)이 상승하며, 온콜(on-call) 엔지니어는 PagerDuty 알림을 받게 됩니다.
하지만 LLM 기반 애플리케이션은 어떨까요? 이들은 그렇게 작동하지 않습니다. 이들은 조용히 실패합니다.

검색 증강 생성 (RAG, Retrieval-Augmented Generation) 시스템에서 사용자가 "기업 고객을 위한 환불 정책은 무엇인가요?"라고 물을 수 있습니다. 시스템은 개인 등급 환불에 관한 문서를 검색하고, LLM은 이를 처리하여 정중하고 형식이 잘 갖춰졌지만 완전히 틀린 답변을 반환합니다.
모니터링 스택 입장에서 이것은 성공처럼 보입니다. HTTP 상태 코드는 200입니다. 지연 시간은 2초 예산 내에 있습니다. 토큰(token) 수도 정상입니다. 이것이 바로 "소프트 실패(soft failure)"입니다. 즉, 시스템은 운영상으로는 건강하지만 기능적으로는 고장 난 상태인 시맨틱 편차(semantic deviation)입니다.

전통적인 "골든 시그널 (Golden Signals)" (지연 시간(Latency), 에러(Errors), 트래픽(Traffic), 포화도(Saturation))은 AI에서 가장 중요한 실패 모드를 놓칩니다. 그 원인은 AI 환각(hallucination)입니다. 용량 계획을 위해 첫 번째 토큰 생성 시간 (TTFT, Time to First Token) 및 출력 토큰당 시간 (TPOT, Time Per Output Token)과 같은 엔진 수준의 지표를 여전히 추적해야 하지만, 이러한 지표는 출력이 참인지 알려주지는 않습니다.
vLLM metrics documentation에 따르면, TTFT를 추적하는 것은 프리필(prefill) 단계의 응답성을 측정하는 데 필수적이지만, 이는 여전히 시스템 지표일 뿐 품질 지표는 아닙니다.

전통적 모니터링 (TRADITIONAL MONITORING)               시맨틱 관측성 (SEMANTIC OBSERVABILITY)
┌──────────────────────┐             ┌──────────────────────┐
│ HTTP 200/500         │             │ 충실도 점수 (Faithfulness Score)   │
...

우리는 LLM 출력을 결정론적인 문자열(deterministic string)이 아닌 확률 변수(probabilistic variable)로 취급하는 프레임워크가 필요합니다. 이는 인프라를 모니터링하는 것에서 의미(meaning)를 관측하는 것으로의 전환을 요구합니다.

시맨틱 관측성 스택 (The Semantic Observability Stack)

표준 OpenTelemetry (OTel) span은 마이크로서비스 전반의 분산 트레이싱 (Distributed Tracing)을 위해 설계되었지만, LLM을 디버깅하는 데 필요한 필드들이 부족합니다. LLM 호출이 시맨틱 (Semantic) 측면에서 실패할 경우, 전체 프롬프트 (Prompt), 완성된 텍스트 (Completion), 모델 온도 (Temperature), 그리고 사용된 시스템 프롬프트 (System Prompt)의 특정 버전이 필요합니다.

이러한 정보들을 표준 로그에 주입하는 것은 저장 비용 재앙과 개인정보 (PII) 유출을 초래하는 지름길입니다. 대신, 우리는 AI를 위한 시맨틱 컨벤션 (Semantic Conventions)을 도입한 OTel의 오픈 소스 확장 기능인 OpenLLMetry를 사용합니다. 이는 OpenAI 또는 Anthropic과 같은 제공업체에 대한 호출을 자동으로 인스트루먼테이션 (Instrumentation)하여, 입력과 출력을 span 내의 속성 (Attributes)으로 캡처합니다.

한 가지 주요한 아키텍처적 과제는 오버헤드 (Overhead)입니다. 모든 요청에 대해 복잡한 평가를 실행하면 지연 시간 (Latency)이 증가합니다. 우리는 이를 **섀도 로깅 (Shadow Logging)**으로 해결합니다. 애플리케이션 스레드는 사용자 요청을 처리하고 즉시 응답을 반환합니다. 동시에, 트레이스 (Trace) 데이터를 비동기 큐 (예: RabbitMQ 또는 AWS SQS 버퍼)로 푸시합니다. 그런 다음 워커 풀 (Worker Pool)이 이러한 트레이스들을 가져와 오프라인에서 시맨틱 평가를 실행합니다.

from traceloop.sdk import Traceloop
from opentelemetry import trace

...

추론 경로 (Inference Path)에서 평가를 분리함으로써, 포렌식 분석 (Forensic Analysis)에 필요한 데이터를 캡처하면서도 사용자 경험을 보호할 수 있습니다. 만약 사용자가 잘못된 답변을 보고하면, Arize Phoenix에서 정확한 트레이스 ID (Trace ID)를 조회하여 오류를 유발한 검색된 청크 (Retrieved Chunks)를 확인할 수 있습니다.

품질 정량화: RAG Triad 구현

RAG 시스템의 품질을 측정하려면 단일한 "정확도 (Accuracy)" 점수 그 이상의 것이 필요합니다. 우리는 TruLens에 의해 대중화된 프레임워크인 RAG Triad를 사용하며, 이는 파이프라인을 측정 가능한 세 가지 관계(Relationships)로 분해합니다:

1. Context Relevance: 검색된 정보 중 실제로 질의와 관련성이 있는 부분이 얼마나 되는가? 벡터 DB가 10개의 청크를 반환했지만 오직 청크 8에만 답이 포함되어 있다면, 관련성은 낮은 것이다.
2. Groundedness: 답변이 검색된 컨텍스트에서 오직 파생되었는가? 이는 LLM이 사용자의 독점 문서 대신 내부 학습 데이터를 사용하는 환각(hallucination)을 감지한다.
3. Answer Relevance: 응답이 실제로 사용자의 의도에 부합하는가?

이러한 메트릭들을 자동화하기 위해, 우리는 RAGAS 라이브러리를 사용하는데, 이 라이브러리는 자체적인 메트릭 이름(Faithfulness (groundedness의 유사 개념), Context Precision (검색 관련성을 평가하는 순위 인식 측정치), Answer Relevancy)으로 동일한 세 가지 관계를 구현한다. 이는 'Judge' 모델(일반적으로 GPT-4o와 같은 더 강력한 모델)을 사용하여 0부터 1까지의 척도로 이러한 메트릭들을 점수화한다.

프로덕션 신뢰성을 위해서는 단순히 라이브 샘플링에 의존하지 않는다. 우리는 골든 세트(Golden Set)를 유지한다. 이는 50~100개의 고위험 질의-컨텍스트-답변 트리플로 구성된 큐레이션된 JSON 파일이다. CI/CD 과정에서, 우리는 현재 파이프라인을 이 세트에 대해 실행한다. 만약 Faithfulness 점수가 임계값(예: 0.85) 이하로 떨어지면 빌드가 실패한다. 이는 임베딩 모델을 업데이트하거나 고정 크기 512 토큰 창에서 재귀적 문자 분할(recursive character splitting)로 전환하는 등 청킹 전략을 변경할 때 발생하는 회귀를 방지한다.

Meta CRAG 벤치마크를 참조하는 것은 이러한 데이터셋이 모호하거나 동적인 정보를 처리하기 위해 어떻게 구조화되어야 하는지에 대한 표준을 제공한다. 골든 세트가 없다면, 새로운 프롬프트가 이전 것보다 나은지 추측만 하고 있는 셈이다.

대규모 LLM-as-a-Judge 아키텍처링

판단 모델(judge model)을 트래픽의 100%에 대해 실행하는 것은 엄청나게 비싸다. 초당 1,000개의 요청에서 모든 응답을 GPT-4o로 평가한다면 프로젝트가 파산할 것이다. 대신, 우리는 프로덕션 트래픽의 5%를 샘플링하는 사이드카(sidecar) 평가 서비스를 구현한다.

휴리스틱(heuristic)으로서, "판사(Judge)"는 "작업자(Worker)"보다 더 뛰어난 능력을 갖추어야 합니다. 다만, 판사 모델 또한 자체적인 편향(자기 선호 편향(self-preference bias), 위치 편향(position bias))을 가지고 있으므로, 이는 절대적인 법칙이라기보다는 경험적인 원칙(rule of thumb)입니다. 만약 프로덕션 모델이 Llama 3-8B라면, Claude 3.5 Sonnet이나 GPT-4o와 같은 모델을 판사로 선택하는 것이 합리적인 선택입니다. 판사를 위한 프롬프트는 정확성을 보장하기 위해 반드시 사고 사슬 (Chain-of-Thought (CoT))을 사용해야 합니다. 우리는 판사가 판단을 내리기 전에 컨텍스트(context)에서 특정 인용구를 추출하도록 강제합니다.

from pydantic import BaseModel, Field
from typing import List

...

Pydantic을 통해 구조화된 출력(structured output)을 강제함으로써, 평가 데이터는 기계가 읽을 수 있는(machine-readable) 상태로 유지됩니다. 그런 다음 이러한 점수들을 시계열 데이터베이스(time-series database)에 집계할 수 있습니다. 이를 통해 특정 모델 업데이트가 전체 플릿(fleet)에서 환각(hallucination)의 급증을 유발했는지 확인할 수 있습니다.

피드백 루프의 운영화 (Operationalizing the Feedback Loop)

마지막 단계는 시맨틱 지표(semantic metrics)를 연구자의 노트북에서 SRE(Site Reliability Engineer)의 대시보드로 옮기는 것입니다. 우리는 평가 작업자(evaluation worker)로부터 결과를 스크래핑(scrape)하는 커스텀 Prometheus 익스포터(exporter)를 사용합니다. 이를 통해 Grafana에서 CPU 사용률 (CPU Usage) 및 **메모리 포화도 (Memory Saturation)**와 함께 **환각률 (Hallucination Rate)**을 시각화할 수 있습니다.

"시맨틱 알림(Semantic Alerts)"을 설정하는 것은 온콜(on-call) 철학의 근본적인 변화를 의미합니다. 5xx 에러에 대해서만 알림을 보내는 대신, 우리는 5분 이동 창(rolling window) 동안 평균 충실도(Faithfulness) 점수가 0.8 미만으로 떨어지면 PagerDuty를 트리거합니다. 이는 손상된 벡터 인덱스(vector index)나, 성능이 저하되거나 0으로 채워진 벡터를 조용히 반환하기 시작한 임베딩 제공업체(embedding provider)와 같이 시스템 지표가 놓치기 쉬운 문제들을 종종 포착해냅니다.

THE FEEDBACK LOOP
┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│ User Query   │─────▶│ RAG Pipeline │─────▶│ Response     │
...

또한 스팬(span) 수준의 사용자 피드백을 통합합니다. 사용자가 UI에서 '엄지손가락 아래'를 클릭하면, 프론트엔드는 트레이스 ID를 관측성 백엔드로 전송합니다. 우리는 이 수동 신호들을 자동화된 RAG Triad 점수와 상관관계 분석합니다. 만약 자동 판정기가 응답이 '근거 기반(grounded)'이라고 말하지만 사용자가 그것을 싫어한다면, 이는 우리의 평가 로직에 격차가 있음을 의미합니다. 이러한 지속적인 개선은 관측성을 수동적 모니터링 작업에서 모델 개선을 위한 능동적인 엔진으로 변화시킵니다. LLM을 위해 엔지니어링한다는 것은 출력이 결코 완벽할 수 없다는 것을 받아들이는 것이지만, 항상 측정 가능할 수는 있다는 것을 의미합니다.

이 기사는 Ozigi의 도움을 받아 생성되었습니다.
이 글을 읽고 즐거움을 느꼈고 자신만의 글을 생성하고 싶다면, 저희 무료 아티클 제너레이터로 이동하여 생각할 거리를 주제로 Google에서 순위를 차지하기 시작하세요.