전체 비유: 의사의 진단 과정#

관측성 3요소를 의사의 환자 진단 과정에 비유하면 이해하기 쉽습니다:

이처럼 의사가 환자를 진단할 때 여러 방법을 조합하듯, 시스템 관측도 3요소를 함께 사용해야 정확한 분석이 가능합니다.

대상 독자: Observability 개념을 처음 접하는 개발자 선수 지식: 기본적인 웹 애플리케이션 구조 이해 소요 시간: 약 25-30분 이 문서를 읽으면: 3요소의 역할을 이해하고 언제 무엇을 사용할지 판단할 수 있습니다

TL;DR#

핵심 요약:

• Metrics: “얼마나?” - 수치로 측정 가능한 상태 (CPU 80%, 응답시간 200ms)
• Logs: “무슨 일이?” - 개별 이벤트의 상세 기록
• Traces: “어디서 어디로?” - 요청의 전체 경로 추적
• 3요소는 상호 보완적이며, 함께 사용할 때 가장 효과적입니다

왜 3요소가 모두 필요한가?#

비유: 의사의 진단 과정

환자가 “배가 아파요"라고 호소할 때, 의사는 어떻게 진단할까요?

1. 체온, 혈압, 맥박 측정 (= Metrics): “열이 38.5도, 혈압 정상” → 숫자로 상태 파악
2. 문진과 증상 기록 (= Logs): “3일 전부터 시작, 식후 악화” → 상세한 맥락 수집
3. CT/X-ray 촬영 (= Traces): “충수돌기 부위 염증 확인” → 문제 위치 시각화

하나만으로는 진단이 불가능합니다. 체온만 보고 맹장염을 알 수 없고, 증상 기록만으로는 정확한 위치를 특정할 수 없습니다. 시스템 관측도 마찬가지입니다.

실제 장애 상황으로 이해하기#

하나의 장애 상황을 3요소로 분석해봅시다.

상황: “주문 API 응답이 느려졌다”

graph TD
    A["문제 인지"] --> M["Metrics<br>P99 응답시간 3초"]
    M --> |"언제부터?"| M2["지난 10분간 급증"]
    M2 --> |"상세 원인?"| L["Logs<br>DB 커넥션 타임아웃"]
    L --> |"어떤 요청?"| T["Traces<br>결제 서비스 → DB 구간 지연"]
    T --> |"개선 후 확인"| M

한 요소만으로는 한계가 있습니다:

• Metrics만: “느리다"는 알지만 “왜"인지 모름
• Logs만: 개별 이벤트는 보이지만 전체 추세 파악 어려움
• Traces만: 요청 흐름은 보이지만 시스템 전체 상태 파악 어려움

Metrics (메트릭)#

정의#

메트릭은 시간에 따라 측정된 수치 데이터입니다. 시스템의 상태를 숫자로 표현합니다.

왜 메트릭이 필요한가?#

로그가 “무슨 일이 일어났는가"를 기록한다면, 메트릭은 **“지금 시스템이 얼마나 건강한가”**를 알려줍니다.

비유: 자동차 계기판

운전 중에 엔진 경고등이 켜지면 “문제가 있다"는 것을 즉시 알 수 있습니다. 일일이 엔진 로그를 읽어보지 않아도 됩니다. 메트릭은 이처럼 시스템의 건강 상태를 한눈에 파악할 수 있게 해줍니다.

메트릭의 핵심 가치는 집계와 추세 분석입니다. “지난 1시간 동안 평균 응답시간이 어떻게 변했는가?”, “오늘 오전 10시와 어제 오전 10시의 트래픽 차이는?” 같은 질문에 즉시 답할 수 있습니다.

특징#

메트릭 타입#

graph LR
    subgraph "메트릭 타입"
        C["Counter<br>누적 증가"]
        G["Gauge<br>현재 값"]
        H["Histogram<br>분포"]
        S["Summary<br>백분위"]
    end

    C --> |"예시"| C1["요청 수, 에러 수"]
    G --> |"예시"| G1["CPU 사용률, 메모리"]
    H --> |"예시"| H1["응답시간 분포"]
    S --> |"예시"| S1["P50, P95, P99"]

예시#

# CPU 사용률 (Gauge)
node_cpu_seconds_total

# 초당 요청 수 (Counter → rate로 변환)
rate(http_requests_total[5m])

# P99 응답시간 (Histogram)
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

언제 사용하는가?#

• 시스템 상태 모니터링 (CPU, 메모리, 디스크)
• SLA/SLO 측정 (응답시간, 가용성)
• 트렌드 분석 (트래픽 패턴, 성장률)
• 알림 조건 설정

Logs (로그)#

정의#

로그는 개별 이벤트의 텍스트 기록입니다. 특정 시점에 무슨 일이 발생했는지 상세히 기록합니다.

왜 로그가 필요한가?#

메트릭이 “CPU가 90%다"라고 말해준다면, 로그는 **“왜 90%인지”**를 알려줍니다.

비유: 블랙박스 녹화

자동차 사고가 났을 때 “충돌이 발생했다"는 사실(= 메트릭)만으로는 원인을 알 수 없습니다. 블랙박스 영상(= 로그)을 보면 “앞차가 급정거했다”, “신호를 무시했다” 같은 맥락을 파악할 수 있습니다.

로그의 핵심 가치는 상세한 맥락과 디버깅 정보입니다. 에러가 발생했을 때 “어떤 사용자가”, “어떤 요청으로”, “어떤 데이터를 보냈을 때” 문제가 생겼는지 추적할 수 있습니다.

특징#

로그 레벨#

DEBUG   → 개발 중 상세 정보
INFO    → 정상 동작 기록
WARN    → 잠재적 문제 경고
ERROR   → 오류 발생
FATAL   → 시스템 중단 수준 오류

구조화 로그 예시#

{
  "timestamp": "2026-01-12T10:30:00Z",
  "level": "ERROR",
  "service": "order-service",
  "trace_id": "abc123",
  "message": "주문 생성 실패",
  "error": "재고 부족",
  "order_id": "ORD-456",
  "user_id": "USR-789"
}

구조화 로그의 장점:

• 필드별 검색/필터링 용이
• Trace ID로 분산 추적과 연결
• 자동 파싱 및 대시보드 생성 가능

언제 사용하는가?#

• 오류 상세 원인 분석
• 디버깅 및 문제 재현
• 감사(Audit) 기록
• 비정상 패턴 탐지

Traces (트레이스)#

정의#

트레이스는 분산 시스템에서 요청이 지나가는 전체 경로를 기록합니다. 하나의 요청이 여러 서비스를 거치는 과정을 추적합니다.

왜 트레이스가 필요한가?#

마이크로서비스 환경에서는 하나의 요청이 5개, 10개, 심지어 20개의 서비스를 거칠 수 있습니다. “응답이 느리다"는 메트릭을 봤을 때, 어느 서비스에서 지연이 발생했는지 어떻게 알 수 있을까요?

비유: 택배 추적 시스템

온라인으로 물건을 주문하면 “배송 추적"을 통해 “물류센터 → 지역 허브 → 배송기사 → 배달 완료” 경로를 볼 수 있습니다. 배송이 지연되면 어느 구간에서 멈춰있는지 바로 알 수 있습니다.

트레이스는 요청의 “배송 추적"입니다. API Gateway → 주문 서비스 → 결제 서비스 → 데이터베이스로 이어지는 경로에서 각 구간별 소요 시간을 측정합니다. 결제 서비스에서 2초가 걸렸다면, 그 원인을 집중적으로 분석할 수 있습니다.

핵심 개념#

graph LR
    subgraph "Trace (전체 요청)"
        S1["Span 1<br>API Gateway<br>50ms"]
        S2["Span 2<br>Order Service<br>120ms"]
        S3["Span 3<br>Payment Service<br>200ms"]
        S4["Span 4<br>Database<br>80ms"]
    end

    S1 --> S2
    S2 --> S3
    S2 --> S4

Context Propagation#

서비스 간 Trace ID를 전달하는 방식입니다.

HTTP Header 예시:
traceparent: 00-abc123-def456-01

W3C Trace Context 형식:
version-trace_id-span_id-flags

언제 사용하는가?#

• 마이크로서비스 간 지연 구간 파악
• 특정 요청의 전체 흐름 시각화
• 서비스 간 의존성 분석
• 병목 지점 식별

3요소 연결하기#

Trace ID를 통한 연결#

graph TD
    subgraph "통합 분석 흐름"
        M["Metrics<br>에러율 급증 감지"]
        L["Logs<br>trace_id로 필터링"]
        T["Traces<br>장애 구간 시각화"]
    end

    M --> |"시간대 확인"| L
    L --> |"trace_id 추출"| T
    T --> |"개선 후"| M

실전 예시: 주문 실패 분석#

1. Metrics에서 이상 감지

# 에러율이 5% 초과
sum(rate(http_requests_total{status="500"}[5m]))
/ sum(rate(http_requests_total[5m])) > 0.05

2. 해당 시간대 Logs 검색

level:ERROR AND service:order-service AND timestamp:[2026-01-12T10:00 TO 2026-01-12T10:30]

결과에서 trace_id: abc123 발견

3. Trace로 전체 경로 확인

Trace ID: abc123
├─ API Gateway (10ms) ✓
├─ Order Service (50ms) ✓
├─ Payment Service (2000ms) ✗ ← 병목
└─ Inventory Service (30ms) ✓

4. 결론: Payment Service 외부 API 호출 지연

도구 선택 가이드#

OpenTelemetry는 3요소를 하나의 표준으로 통합합니다. 새 프로젝트라면 OpenTelemetry 도입을 권장합니다.

트레이드오프#

비용 최적화 전략#

1. Metrics: 모든 것을 측정 (저렴함)
2. Logs: ERROR 이상만 장기 보관, DEBUG는 단기 보관
3. Traces: 샘플링 적용 (전체의 1~10%)

핵심 정리#

다음 단계#