Observability

관측 가능성은 소프트웨어 시스템이 내보내는 텔레메트리, 주로 로그, 메트릭, 트레이스를 바탕으로 시스템 내부에서 일어나는 일을 파악하고, 새 코드를 배포하지 않고도 동작에 관한 새로운 질문에 답할 수 있는 능력입니다. 이 용어는 제어 이론에서 유래했습니다. Rudolf Kálmán은 1960년에 출력을 통해 내부 상태를 파악할 수 있는 시스템을 관측 가능하다고 정의했습니다. 시스템이 수많은 서비스로 분리되고 장애가 사전에 구축된 대시보드의 범위를 벗어나기 시작한 2010년대에 소프트웨어 팀이 이 용어를 도입했습니다. 머신 러닝 시스템에서 관측 가능성은 데이터와 예측도 다룹니다. 즉, 모델이 어떤 입력을 받고 무엇을 출력하는지, 얼마나 확신하는지, 시간이 지나면서 이 모든 요소가 어떻게 바뀌는지를 살핍니다.

로그, 메트릭, 트레이스#

흔히 관측 가능성의 기둥이라 부르는 세 가지 유형의 텔레메트리는 서로 다른 질문에 답합니다.

• 메트릭: 요청률, 오류율, 지연 시간 백분위수, 메모리, GPU 사용률과 같은 숫자형 시계열입니다. 저장 비용이 저렴하며 대시보드와 알림에 적합합니다. Google의 사이트 신뢰성 엔지니어링 서적은 모든 서비스에서 지연 시간, 트래픽, 오류, 포화도라는 네 가지 핵심 신호를 측정하도록 권장합니다.
• 로그: 개별 이벤트에 관한 타임스탬프가 포함된 기록입니다. 요청 ID, 모델 버전, 입력 크기와 같은 필드가 포함된 JSON 형식으로 구조화하면 필터링과 집계가 용이합니다.
• 트레이스: 하나의 요청이 거치는 모든 서비스 경로를 나타내며, 스팬의 트리 형태로 기록됩니다. 각 스팬에는 이름, 시작 시간, 지속 시간, 속성이 포함되어 요청이 어디에서 시간을 소모했는지 보여 줍니다.

2019년 OpenTracing과 OpenCensus 프로젝트의 통합으로 만들어진 OpenTelemetry는 세 가지 신호 모두에 대해 벤더 중립적인 API, SDK, 와이어 프로토콜 (OTLP)을 제공하며, Prometheus, Grafana, Jaeger와 같은 백엔드가 이를 저장하고 표시합니다. 다음 예제는 OpenTelemetry Python SDK로 이미지 분류 요청 하나를 추적하며, 요청에 대한 상위 스팬과 각 단계에 대한 하위 스팬을 기록합니다.

import torch
import torchvision
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import SimpleSpanProcessor
from opentelemetry.sdk.trace.export.in_memory_span_exporter import InMemorySpanExporter

# Keep finished spans in memory; a production service exports them over OTLP instead
exporter = InMemorySpanExporter()
provider = TracerProvider()
provider.add_span_processor(SimpleSpanProcessor(exporter))
tracer = provider.get_tracer("classifier")
model = torchvision.models.resnet18().eval()
frame = torch.rand(3, 1080, 1920)

# Trace one request as a parent span with a child span for each stage
with tracer.start_as_current_span("predict", attributes={"model.name": "resnet18", "image.height": 1080}):
    with tracer.start_as_current_span("preprocess"):
        batch = torchvision.transforms.functional.resize(frame, [224, 224]).unsqueeze(0)
    with tracer.start_as_current_span("inference"), torch.inference_mode():
        logits = model(batch)

spans = exporter.get_finished_spans()
names = {span.context.span_id: span.name for span in spans}
for span in spans:
    parent = names[span.parent.span_id] if span.parent else "-"
    print(f"{span.name:<11} {(span.end_time - span.start_time) / 1e6:5.1f} ms  parent: {parent}")

Apple M5 Pro CPU에서 실행하면 1.0~1.4ms의 preprocess 스팬과 7~9ms의 inference 스팬이 출력되며, 두 스팬의 상위 스팬은 predict입니다. 또한 8~10ms의 predict 스팬도 출력되므로 트레이스는 요청 시간의 대부분이 모델에서 소요됨을 보여 줍니다. 스팬을 OTLP를 통해 내보내면 요청을 처리하는 모든 서비스가 동일한 트레이스 ID 아래에 스팬을 추가하며, Jaeger와 같은 백엔드는 이를 하나의 타임라인으로 표시합니다.

관측 가능성과 모니터링#

모델 모니터링은 오류율 1% 초과 또는 추론 지연 시간이 목표치 초과와 같은 알려진 장애 유형을 미리 정의된 메트릭, 대시보드, 알림 임계값으로 감시합니다. 관측 가능성은 누구도 예상하지 못한 장애를 조사할 수 있게 하는 더 포괄적인 속성입니다. 고객, 모델 버전, 카메라 또는 기타 속성별로 세부 텔레메트리를 사후 분석할 수 있습니다. Google SRE 서적은 모니터링이 무엇이 고장 났는지와 왜 고장 났는지라는 두 가지 질문에 답해야 한다고 설명하며, 조사 과정에서는 세 가지 신호를 모두 살펴 첫 번째 답변에서 두 번째 답변으로 나아갑니다.

설명 가능한 AI는 입력 특징이나 내부 활성화를 바탕으로 모델이 특정 출력을 생성한 이유를 설명하는 별도의 분야이며, 어트리뷰션을 또 하나의 신호로 기록할 수 있습니다.

머신 러닝의 관측 가능성#

머신 러닝 시스템은 조용히 실패하는 경우가 많습니다. 컴퓨터 비전 모델은 모든 요청에 HTTP 200을 반환하면서도 카메라가 이동했거나, 조명이 바뀌었거나, 새로운 제품이 등장해 예측 품질이 저하될 수 있습니다. 따라서 ML 관측 가능성은 일반적인 서비스 신호에 데이터와 예측에 관한 텔레메트리를 추가합니다. 팀은 이미지 크기와 밝기 같은 입력 통계를 기록해 데이터 드리프트를 탐지하고, 클래스 수, 빈 결과, 평균 신뢰도 등 예측 분포를 추적하며, 며칠 후에 도착하는 경우가 많은 정답 라벨이 확보되면 세그먼트별 정확도를 계산합니다. 학습 중에는 콜백이 모든 실행의 손실 곡선, 메트릭, 시스템 사용량을 실험 추적 도구인 TensorBoard 및 MLflow로 전송합니다. AI 에이전트 및 대규모 언어 모델 애플리케이션에서는 트레이스가 각 프롬프트, 검색 단계, 도구 호출, 응답을 기록하며, OpenTelemetry GenAI 시맨틱 규칙은 gen_ai.usage.input_tokens과 같은 속성을 표준화해 도구 간 토큰 수와 비용을 일관되게 비교할 수 있도록 합니다.

Ultralytics Platform의 모든 전용 엔드포인트에는 배포 모니터링이 기본 제공됩니다. 여기에는 요청 수, 오류율, p95 지연 시간 카드, 심각도 수준 및 오류·경고 항목 필터가 포함된 Logs 탭, 그리고 상위 클래스, 시간에 따른 평균 신뢰도, 이미지당 예측 수, 요청 지연 시간과 별도로 측정한 모델 추론 시간을 차트로 표시하는 예측 통계가 포함됩니다. 모든 요청이 성공하더라도 신뢰도 곡선의 하락이나 상위 클래스의 변화가 해당 차트에 나타납니다.