지표(Metric)란 무엇인가?
서비스를 운영하다 보면 "오늘 서버가 느린 것 같아요"라는 주관적 의견이 아닌, 정량적이고 객관적인 판단이 필요합니다. 이때 필요한 것이 바로 지표(Metric)입니다.
데이터 vs 지표
원시 정보(Raw Data)
로그, 이벤트, 요청 기록 등 가공되지 않은 정보
예: "2026-02-16 14:23:01 - ERROR: Connection timeout"
측정 가능한 값(Metric)
데이터에서 추출한 정량적, 비교 가능한 수치
예: "API 에러율 2.3% (어제 대비 +0.5%)"
좋은 지표의 3가지 조건
Measurable (측정 가능)
명확하게 수치화할 수 있어야 합니다
✓ "p99 레이턴시 250ms" / ✗ "서버가 느림"
Comparable (비교 가능)
시간에 따라 또는 목표치와 비교할 수 있어야 합니다
✓ "어제 대비 +0.5%" / ✗ "오늘 조금 높음"
Actionable (행동 유도)
지표를 보고 구체적 행동을 취할 수 있어야 합니다
✓ "임계값 초과, 스케일 아웃 필요" / ✗ "총 요청 수 1억 건"
좋은 지표
"API 에러율 2.3%"
어제 대비 +0.5%
- ✓ 수치화됨 (2.3%)
- ✓ 비교 가능 (어제 대비)
- ✓ 행동 유도 (원인 파악 필요)
나쁜 지표
"오늘 서버가 좀 느린 것 같다"
(주관적 느낌)
- ✗ 주관적, 수치화 안 됨
- ✗ 비교 불가능
- ✗ 무엇을 해야 할지 모름
핵심 포인트
지표는 단순한 숫자가 아닙니다. 의사결정을 돕는 도구입니다. 좋은 지표는 "무엇이 문제인지", "얼마나 심각한지", "무엇을 해야 하는지"를 명확하게 알려줍니다.
지표의 유형 (모니터링 관점)
모든 지표가 동일한 가치를 가지는 것은 아닙니다. 모니터링 관점에서 지표를 분류하면 어떤 지표에 집중해야 하는지 명확해집니다.
Leading vs Lagging 지표
Leading (선행 지표)
장애를 예측할 수 있는 지표입니다. 문제가 발생하기 전에 미리 경고를 줍니다.
예시
- • CPU 사용률 증가 추세 (80% → 85% → 90%)
- • 디스크 여유 공간 감소 (20GB → 15GB → 10GB)
- • 메모리 누수 패턴 (점진적 증가)
Lagging (후행 지표)
이미 발생한 결과를 측정하는 지표입니다. 장애가 일어난 후에 알 수 있습니다.
예시
- • 월간 장애 발생 건수 (5건)
- • MTTR (평균 복구 시간: 15분)
- • 총 다운타임 (2시간 30분)
Vanity vs Actionable 지표
Vanity (허영 지표)
보기에는 좋지만 구체적인 행동을 유도하지 못하는 지표입니다.
예시
- • 총 가동시간 99.99% (언제 장애가 있었는지 모름)
- • 총 요청 수 1억 건 (성공/실패 구분 없음)
- • 평균 응답시간 150ms (p99는 5초일 수도)
Actionable (실행 가능 지표)
즉시 행동을 취할 수 있는 지표입니다. 임계값 초과 시 무엇을 해야 하는지 명확합니다.
예시
- • Error Budget 잔여 42% (배포 속도 조절)
- • p99 레이턴시 350ms (목표 200ms 초과)
- • 5xx 에러율 1.2% (임계값 0.5% 초과)
모니터링 지표 분류 매트릭스 (4분면)
| 분류 | Actionable | Vanity |
|---|---|---|
| Leading |
★ 최고 가치 CPU 증가 추세, 디스크 여유 공간 |
예측 가능하지만 행동 불가 시스템 온도 추이 |
| Lagging |
개선 지표 MTTR, 장애 발생 건수 |
보고용 총 가동시간, 총 요청 수 |
Tip: Leading + Actionable 지표에 집중하세요
가장 가치 있는 지표는 장애를 예측하고 즉시 행동할 수 있는 Leading + Actionable 지표입니다. CPU 사용률 증가 추세, 디스크 여유 공간 감소, Error Budget 소진 속도 등이 여기에 해당합니다.
RED Method & USE Method
어떤 지표를 모니터링해야 할지 막막할 때 사용하는 두 가지 프레임워크입니다. RED는 서비스 레벨, USE는 인프라 레벨 모니터링에 적합합니다.
RED Method Request-oriented
마이크로서비스와 API 모니터링에 최적화된 방법론입니다. 사용자 요청을 중심으로 3가지 핵심 지표를 측정합니다.
Rate (요청률)
초당 요청 수 (throughput) - 시스템이 얼마나 바쁜가?
예: 1,500 requests/sec
Errors (에러율)
실패한 요청의 비율 - 얼마나 많은 요청이 실패하는가?
예: 0.3% (5xx errors)
Duration (처리 시간)
요청 처리 시간 (latency) - 얼마나 빠르게 응답하는가?
예: p99 = 180ms
USE Method Resource-oriented
인프라와 리소스 모니터링에 최적화된 방법론입니다. CPU, 메모리, 디스크 등 물리적 리소스를 중심으로 3가지 지표를 측정합니다.
Utilization (사용률)
리소스가 얼마나 바쁜가? (% busy)
예: CPU 75%, Memory 82%
Saturation (포화도)
대기열 길이 (오버로드 정도) - 처리하지 못한 작업이 얼마나 쌓였나?
예: Disk I/O queue length = 15
Errors (에러)
리소스 레벨에서 발생한 에러 수
예: Disk read errors = 3/hour
Golden Signals vs RED vs USE 대응 관계
| Golden Signals | RED (Service) | USE (Resource) |
|---|---|---|
| Latency | Duration | - |
| Traffic | Rate | Utilization |
| Errors | Errors | Errors |
| Saturation | - | Saturation |
리소스별 USE Method 적용 예시
| Resource | Utilization | Saturation | Errors |
|---|---|---|---|
| CPU | CPU usage % | Run queue length | CPU throttling events |
| Memory | Memory usage % | Swap usage, page faults | OOM kills |
| Disk I/O | Disk busy % | I/O queue depth | Disk read/write errors |
| Network | Bandwidth usage % | Socket buffer overruns | Packet loss, CRC errors |
Tip: 서비스는 RED, 인프라는 USE
마이크로서비스/API는 RED Method로, 서버/컨테이너 인프라는 USE Method로 모니터링하면 효과적입니다. 두 방법론을 함께 사용하면 서비스부터 인프라까지 전체 스택을 커버할 수 있습니다.
비즈니스 지표와 기술 지표의 연결
기술 지표만 보면 "왜 이걸 해야 하는지" 설명이 안 되고, 비즈니스 지표만 보면 "무엇을 고쳐야 하는지" 모릅니다. 두 지표를 연결하면 기술 개선이 비즈니스 성과로 이어지는 것을 증명할 수 있습니다.
AARRR 프레임워크 (Pirate Metrics)
사용자 여정을 5단계로 나눈 프레임워크입니다. 각 단계마다 기술 지표가 비즈니스에 영향을 미칩니다.
AARRR 단계별 기술 지표 매핑
| AARRR | 비즈니스 의미 | 연결되는 기술 지표 | 영향 |
|---|---|---|---|
| Acquisition | 사용자 유입 | 페이지 로딩 시간 (LCP) | LCP 3초↑ → 이탈률 53%↑ |
| Activation | 첫 경험 | API 응답 시간 (p99) | p99 1초↑ → 가입 전환율↓ |
| Retention | 재방문 | 에러율, 서비스 안정성 | 에러율 5%↑ → 7일 리텐션↓ |
| Revenue | 매출 | 결제 API 성공률 | 타임아웃 → 직접 매출 손실 |
| Referral | 추천 | 전체 UX 품질 (CWV) | NPS 점수와 상관 |
North Star Metric (북극성 지표)
조직 전체가 집중해야 할 단 하나의 핵심 지표입니다. 기술팀의 North Star는 "서비스 안정성이 비즈니스 성장의 기반"이라는 것입니다.
기술팀의 North Star
"에러율 1% 개선 → 사용자 이탈률 X% 감소 → 월 매출 Y만원 증가"
기술 개선이 비즈니스 성과로 이어지는 인과관계를 명확히 하면, 기술 투자의 ROI를 증명할 수 있습니다.
왜 모니터링하는가?의 비즈니스 답변
"에러율을 줄이기 위해"가 아니라, "1%의 에러율 개선이 매출 X% 증가로 이어질 수 있기 때문에"입니다. 기술 지표와 비즈니스 지표를 연결하면, 모니터링이 단순한 운영 업무가 아니라 성장 전략이 됩니다.
주의: 지표의 함정
기술 지표만 보면 "왜 이걸 해야 하는지" 설명이 안 되고,
비즈니스 지표만 보면 "무엇을 고쳐야 하는지" 모릅니다.
두 지표를 함께 추적하고, 인과관계를 증명하는 것이 핵심입니다.
퀴즈
학습한 내용을 확인해봅시다. 5문제를 모두 풀어보세요.