제01권 · 제10호 CS · AI · Infra 2026년 5월 14일

AI 용어집

용어 사전레퍼런스학습
인프라 · 하드웨어

Observability관측 가능성

난이도

쉽게 이해하기

대규모 서비스는 오류 알림만으로는 부족합니다. 왜 느려졌는지, 어느 구간에서 막혔는지, 특정 사용자만 문제가 생기는지 같은 예상 못 한 질문이 바로 터집니다. 모니터링이 문제가 있음을 알려준다면, 관측 가능성은 왜를 찾아가게 해 줍니다. 이를 위해 서비스는 로그(텍스트 이벤트), 메트릭(시간에 따른 수치), 트레이스(요청의 hop-by-hop 경로)를 함께 남기고, 같은 요청에 붙는 trace ID를 모든 신호에 실어 경로·오류·리소스 지표를 한 화면에서 연결해 봅니다. 택배 상자 운송장 번호로 접수부터 배송까지를 추적하는 것과 같습니다. 실무에서는 OpenTelemetry(OTel)로 애플리케이션을 계측하고 Collector를 사이에 둬 샘플링·PII 마스킹·벤더 전환을 구성으로 바꿉니다. 완료된 트레이스를 보고 에러·지연은 100% 남기고 평시 트래픽은 낮은 비율로 남기는 tail-based 샘플링을 권장합니다.

비유와 예시

  • 야간 배치 추론 지연 추적: 일부 GPU 작업이 14초 지연. 트레이스에서 특정 DB 호출 뒤 CUDA 커널 대기가 길어진 것을 확인해 병목을 제거.
  • 메시지 큐 경계의 오류 상관: 결제 요청이 큐를 건너며 trace ID가 끊김. 메시지 헤더에 컨텍스트를 직렬화하자 생산자 로그와 소비자 스팬이 한 트레이스로 묶임.
  • LLM 비용 이상 탐지: 스팬에 모델명·토큰 수·예상 비용을 속성으로 넣고 tail-based 샘플링으로 고비용 케이스만 보존해 프롬프트 팽창 원인 파악.

한눈에 비교

모니터링관측 가능성프로파일링
초점알려진 지표 감시예기치 않은 질문에 답코드 레벨 성능 분석
단위집계 시계열고카디널리티 이벤트·트레이스프로세스·스레드
상관낮음(대시보드 중심)높음(trace ID 연계)없음(단일 프로세스)
사용 시점운영 지표 경보원인 분석·경험 개선성능 튜닝
비용 관리지표 제한샘플링·필터링개발기/테스트 위주

원인 규명이 목표라면 트레이스·로그·메트릭을 trace ID로 묶는 관측 가능성이 가설 검증을 빠르게 돕습니다.

어디서 왜 중요한가

  • OpenTelemetry Collector 중간층: 백엔드 교체, 샘플링, 민감정보 마스킹을 재배포 없이 변경.
  • Kubernetes 운영: 사이드카+게이트웨이 모드로 각 Pod 텔레메트리를 수집·집중 전송.
  • 샘플링 전략: 에러·슬로우 보존, 일상 트래픽 저비율 유지로 비용/가치 균형.
  • GPU 워크로드: 장치·컨테이너·애플리케이션 맥락 통합으로 병목/스케줄링 실패 예방.
  • 실무 관행 전환: trace ID 상관 표준화로 장애 분석 시간 단축.

자주 하는 오해

  • ❌ 관측 가능성은 멋진 대시보드다 → ✅ 핵심은 상관관계이며, trace ID가 로그·메트릭·트레이스를 묶습니다.
  • ❌ 100% 트레이스 수집이 필수다 → ✅ 테일 샘플링으로 에러/지연 전량, 평시 트래픽은 저비율.
  • ❌ 앱에서 바로 벤더로 보내는 게 단순하다 → ✅ Collector로 벤더 교체·필터링·샘플링을 구성화.

대화에서는 이렇게

  • "이번 장애 트레이스에 trace ID가 로그에 없네요. 로거 컨텍스트 연결부터 고치겠습니다."
  • "백엔드 마이그레이션 전까지 Collector에서 이중 전송으로 팬아웃해 주세요. 앱 재배포 없이 전환하고 싶습니다."
  • "GPU 배치는 tail-based로 5초 이상만 보존합시다. 스토리지 비용이 큽니다."
  • "메트릭 라벨에 사용자 ID는 금지, 요청 단위 정보는 스팬 속성으로 남깁니다."
  • "큐 경계에서 OpenTelemetry 컨텍스트가 끊깁니다. 메시지 헤더에 traceparent 주입 패치하겠습니다."

함께 읽으면 좋은 용어

참고 자료

도움이 되었나요?