AI 옵저버빌리티는 LLM 애플리케이션을 조용한 실패로부터 구해주는 것입니다. 500 에러를 던지는 충돌하는 서버와 달리, 언어 모델은 자신 있게 잘못된 답변만 제공할 뿐 스택 트레이스도 에러 코드도 없습니다. 그래서 기존의 모니터링 도구로는 부족한 것이죠.
한눈에 보는 AI 옵저버빌리티
먼저 팀과 공유할 수 있는 요약입니다.
이제 AI 옵저버빌리티가 기존에 알고 있던 모니터링과 근본적으로 어떻게 다른지부터 설명하겠습니다.
AI 옵저버빌리티란? (모니터링과는 왜 다른가?)
AI 옵저버빌리티는 LLM 시스템이 내부에서 무엇을 하고 있는지 이해하는 능력입니다. 단순히 시스템이 정상인지 다운됐는지뿐만 아니라, 특정 입력에 대해 왜 그 특정 출력을 생성했는지를 알아야 합니다. 분산 추적, 실시간 메트릭, 자동화된 품질 평가, 알림을 하나의 피드백 루프로 통합합니다.
기존 모니터링과의 차이는 이렇게 설명할 수 있습니다. 모니터링은 응답 지연이 8초까지 올라갔다는 것만 알려줍니다. 반면 옵저버빌리티는 왜인지를 알려줍니다. 검색 단계가 5개 대신 47개의 청크를 반환했고, 그 이유는 누군가 임베딩 임계값을 변경했기 때문이고, 이것이 컨텍스트 윈도우를 오버플로우시켜 모델이 더 길고 느린 응답을 생성하게 한 것입니다.
Datadog, New Relic, Grafana 같은 기존 APM 도구는 결정론적 세계를 위해 설계되었습니다. HTTP 상태 코드, CPU 사용량, 메모리 누수 같은 것들은 알 수 있고 재현 가능한 상태입니다. LLM은 이 가정을 완전히 깨뜨립니다. 같은 프롬프트를 두 번 보내면 두 가지 다른 응답을 받을 것입니다. 비교할 "기대값"이 없고, 검증할 스키마도 없고, 반환값의 가능한 enum도 없습니다.
이 비결정성이 AI 시스템이 자체 옵저버빌리티 계층을 필요로 하는 핵심 이유입니다. 인프라 건강만 추적하는 게 아니라, 다음 네 가지 영역에서 출력 품질을 추적해야 합니다:
- 데이터 품질 - RAG 문서가 최신인가? 임베딩이 드리프트하고 있나?
- 모델 동작 - 모델이 지난주보다 더 많이 환각하고 있나? 제공자 업데이트가 출력 패턴을 바꿨나?
- 인프라 성능 - 지연 시간, 처리량, 에러율, 캐시 히트율
- 파이프라인 무결성 - 체인의 모든 단계가 올바른 순서로 올바른 입력으로 실행되고 있나?
모니터링은 뭔가 깨졌다는 것을 알려줍니다. 옵저버빌리티는 왜인지를 알려주는데, 시스템의 실패가 성공처럼 보이는 경우 이 구분이 정말 중요합니다.
AI 시스템이 전문화된 옵저버빌리티를 필요로 하는 이유
"그냥 LLM 호출을 로깅으로 감싸고 그걸로 충분하다고 하자"라고 생각할 수도 있습니다. 왜 그것이 오래가지 않는지 설명하겠습니다.
조용한 실패가 기본값입니다. 기존 API가 실패하면 에러를 받습니다. LLM이 실패하면 완전히 잘못된 그럴듯한 문단이 나옵니다. 사용자가 눈치채지 못할 수도 있고, 환각된 데이터를 기반으로 의사결정을 할 수도 있습니다. 라이브 트래픽에서 품질 평가를 실행하지 않으면 맹목적으로 비행하는 것입니다.
비용이 경고 없이 폭증합니다. 최적화되지 않은 단일 에이전트 루프는 밤새 수백 달러의 토큰을 소모할 수 있습니다. 제가 아는 팀은 재시도 루프가 매번 전체 대화 컨텍스트와 함께 GPT-4를 계속 호출해서 $3,200 청구서를 받고 깨어났습니다. 토큰 수준의 비용 귀속은 선택이 아니라 생존입니다.
모델 드리프트는 보이지 않습니다. OpenAI, Anthropic, Google은 정기적으로 모델을 업데이트합니다. 때로는 변경이 당신의 사용 사례를 개선하고, 때로는 깹니다. 기준 품질 메트릭과 자동화된 평가 없이는 사용자가 불평하거나 떠날 때까지 성능 저하를 알아채지 못합니다.
에이전트는 문제를 증폭시킵니다. 간단한 채팅 완성은 LLM 호출 하나입니다. 에이전트는 5~20개의 호출을 연결하고, 도구를 사용하고, 의사결정을 하고, 백트래킹할 수 있습니다. 세션 수준 추적 없이 나쁜 에이전트 출력을 디버깅하는 것은 print 문만으로 분산 시스템을 디버깅하는 것과 같습니다. 가능하지만 고통스럽습니다.
규정 준수는 선택이 아닙니다. LLM이 PII, 유해 콘텐츠 또는 편향된 출력을 생성하면 감사 추적이 필요합니다. "모델이 그렇게 했어"는 규제 기관에게 수용할 수 있는 답변이 아닙니다. 옵저버빌리티는 이러한 문제를 조사하고 방지하기 위한 추적 수준의 증거를 제공합니다.
AI 옵저버빌리티 뒤에 있는 추적 아키텍처
추적은 AI 옵저버빌리티의 근간입니다. 마이크로서비스를 위한 분산 추적을 사용해봤다면 개념은 익숙하지만, LLM 추적은 몇 가지 중요한 뉘앙스를 추가합니다.
추적(trace)은 하나의 종단 간 작업을 나타냅니다. LLM 컨텍스트에서는 보통 단일 사용자 요청입니다. 각 추적은 스팬(span)을 포함합니다. 이들은 "쿼리 임베딩", "문서 검색", "응답 생성" 또는 "보안 검사 실행" 같은 개별 단계입니다. 스팬은 중첩될 수 있습니다. RAG 파이프라인 추적은 검색 스팬과 생성 스팬을 포함하는 부모 스팬을 가질 수 있으며, 각각은 자신의 타이밍, 토큰 수 및 메타데이터를 가집니다.
여기서 주요 개선 사항은 OpenTelemetry의 생성 AI에 대한 의미론적 규칙(semantic conventions for Generative AI)입니다. 이 규칙들은 LLM 원격 측정을 어떻게 명명하고 구조화할지 표준화합니다. gen_ai.system, gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens 같은 속성들입니다. 이 표준화는 당신의 추적이 백엔드 전반에 걸쳐 이식 가능함을 의미합니다. OTEL로 한 번 계측하고, 오늘은 Langfuse로 보내고, 내일은 Datadog으로 전환합니다.
LLM 호출을 위한 기본 OpenTelemetry 계측은 다음과 같습니다:
RAG 파이프라인의 경우 추적이 더 풍부해집니다. 당신의 부모 스팬은 전체 요청을 감싸고 있으며, 임베딩, 벡터 검색, 재순위 매김, 생성을 위한 자식 스팬을 가집니다. 각 스팬은 자신의 지연 시간, 토큰 수 및 사용자 정의 속성(검색된 청크 수나 유사성 점수 임계값 같은)을 가집니다. 이 중첩 구조가 느리거나 낮은 품질의 응답이 어디서 잘못되었는지 정확히 파악할 수 있게 해줍니다.
대부분의 옵저버빌리티 플랫폼인 Langfuse, Braintrust, Arize는 OTEL 추적을 원래 수용하거나 동등한 추적 구조를 생성하는 경량 SDK를 제공합니다. 추세는 명확히 OTEL을 공통 표준으로 향하고 있으므로, 지금 OTEL 계측에 투자하면 나중에 최대의 유연성을 얻게 됩니다.
LLM에 실제로 중요한 메트릭은 무엇인가?
모든 메트릭이 동등하게 생성되지는 않습니다. 추적할 것을 우선순위에 따라 나열했습니다(각 메트릭이 얼마나 빨리 비용을 절감하거나 사고를 방지하는지에 따라).
지연 시간이 첫 번째 신호입니다. P50, P95, P99를 따로 추적합니다. P50은 일반적인 경험을, P99는 가장 불운한 사용자들에게 얼마나 나쁜지를 알려줍니다. 첫 토큰까지의 시간(TTFT)은 인식된 속도가 모든 것인 스트리밍 애플리케이션에 중요합니다.
토큰 사용량은 비용과 품질을 동시에 주도합니다. 입력 토큰, 출력 토큰, 요청당 총합을 추적합니다. 입력 토큰의 갑작스러운 급증은 RAG 검색이 너무 많은 청크를 반환하고 있음을 의미할 수 있습니다. 출력 토큰의 급증은 모델이 과하게 설명하거나 장황한 루프에 빠져 있음을 의미할 수 있습니다.
비용 귀속은 토큰 수를 달러로 전환합니다. 요청별, 사용자별, 기능별, 모델별로 분류합니다. 사용자의 5%가 비용의 60%를 생성하거나, 요약 기능이 검색 기능보다 10배 비싸다는 것을 발견하는 곳입니다.
"모델별 1K 요청당 일반적인 비용"
모델 간 비용 차이는 엄청납니다. 단순한 쿼리를 더 작은 모델로 라우팅하고 GPT-4o나 Claude Sonnet은 복잡한 쿼리를 위해 예약하면 눈에 띄는 품질 저하 없이 청구서를 60~80%까지 줄일 수 있습니다. 하지만 어떤 쿼리가 "단순한"지 알기 위해서는 메트릭이 필요합니다.
품질 점수는 추적하기 더 어렵지만 궁극적으로 가장 중요합니다. 여기에는 사용자 정의 평가 점수(다음 섹션에서 자세히), RAG 시스템의 환각률, 모델의 출력이 검색된 컨텍스트에 근거해 있는지를 측정하는 충실성 메트릭이 포함됩니다.
운영 메트릭이 그림을 완성합니다: API 에러율, 보안 검사 트리거율, 타임아웃율, 캐시 히트율, 폴백 트리거 수. 타임아웃율의 상승은 제공자의 용량 문제를 의미할 수 있습니다. 캐시 히트율의 저하는 사용자가 더 다양한 질문을 하고 있음을 의미할 수 있습니다.
평가 루프는 어떻게 품질 격차를 해소하는가?
...