P4-6.3 보충학습: 사이트 신뢰성 엔지니어링에서 지표(metrics)를 읽는 법¶

Section ID: P4-6.3 Version: v2026.07.20

P4-6.1과 P4-6.2에서는 모델 평가 지표(metric)를 봤습니다. 이제 시선을 조금 바깥으로 돌립니다. 모델이 잘 맞는 것과 서비스가 잘 운영되는 것은 같은 말이 아닙니다. 이 차이를 이해하려면 SRE(site reliability engineering)에서 metric이라는 말을 어떻게 쓰는지 볼 필요가 있습니다.

이 절은 SRE 입문서를 대신하지 않습니다. 목적은 하나입니다. 모델의 품질을 읽는 숫자와 서비스의 상태를 읽는 숫자가 어디서 닮고 어디서 갈라지는지 보충학습으로 정리하는 것입니다.

보충학습: 사이트 신뢰성 엔지니어링에서 지표(metrics)를 읽는 법에서 구분할 경계¶

이 절은 머신러닝 평가 지표와 운영 지표를 구분하는 보충학습 절입니다. SLI(service level indicator), SLO(service level objective), SLA(service level agreement), 에러 버짓(error budget), 그리고 운영에서 자주 보는 지연 시간(latency), 트래픽(traffic), 오류(errors), 포화도(saturation)를 입문 수준으로 연결합니다.

이 절은 다음 질문에 답합니다.

• 좋은 모델과 좋은 서비스는 왜 같은 말이 아닌가?
• 머신러닝 metric과 SRE metric은 무엇이 다른가?
• SLI, SLO, SLA는 어떤 관계인가?
• 운영에서는 왜 평균(mean) 하나보다 분포(distribution), 백분위수(percentile), 오류율(error rate)을 함께 보는가?
• AI 서비스에서는 왜 모델 평가와 서비스 운영 평가가 동시에 필요한가?

보충학습: 사이트 신뢰성 엔지니어링에서 지표(metrics)를 읽는 법에서 복구할 연결¶

• 모델 metric과 운영 metric이 서로 다른 층위(level)의 숫자라는 점을 설명할 수 있습니다.
• SLI, SLO, SLA의 차이를 입문 수준에서 구분할 수 있습니다.
• latency, traffic, errors, saturation이 왜 운영의 기본 신호인지 설명할 수 있습니다.
• AI 서비스에서 답의 품질과 서비스의 신뢰성을 따로 봐야 한다는 점을 말할 수 있습니다.

학습 배경¶

모델 metric과 운영 metric은 무엇이 다른가¶

머신러닝에서 metric은 주로 예측 결과를 읽기 위한 숫자입니다. 예를 들어 accuracy, precision, recall, MAE, RMSE 같은 값은 모델이 얼마나 잘 맞는지, 어떤 오차를 만들고 있는지 보여 줍니다.

SRE에서 metric은 주로 서비스가 실제로 어떻게 동작하는지를 읽기 위한 숫자입니다. 예를 들어 latency, error rate, throughput, availability 같은 값은 사용자가 지금 어떤 서비스를 경험하고 있는지 보여 줍니다.

둘 다 무엇을 중요하게 측정할 것인가를 정한다는 점에서는 닮았습니다. 그러나 대상이 다릅니다.

모델 metric은 답의 품질에 가깝고, 운영 metric은 서비스의 상태에 가깝습니다.

flowchart TD
  A["사용자 요청"]
  B["모델 출력"]
  C["서비스 응답"]
  D["모델 지표<br/>정확도 / 정밀도 / 재현율 / RMSE"]
  E["서비스 지표<br/>지연 시간 / 오류 수 / 트래픽 / 포화"]

  A --> B --> C
  B --> D
  C --> E

이 도식의 핵심은, 하나의 AI 서비스 안에서도 두 종류의 metric이 함께 존재한다는 점입니다.

주요 학습내용¶

좋은 모델이 곧 좋은 서비스는 아니다¶

이 구분은 AI 서비스에서 특히 중요합니다.

예를 들어 챗봇 서비스는 다음 두 질문을 동시에 받습니다.

1. 답변이 적절한가?
2. 답변이 제때 도착하는가?

첫 번째는 모델 품질 질문이고, 두 번째는 서비스 운영 질문입니다.

즉, 모델 성능이 좋아도 지연 시간이 길거나 실패율이 높으면 서비스 품질은 낮을 수 있습니다. 반대로 서비스는 빠르고 안정적이어도 예측이 자꾸 틀리면 제품 목표를 달성하지 못합니다.

같은 서비스를 두 층위로 읽는 예시¶

핵심은 같은 서비스라도 질문이 둘로 나뉜다는 점입니다. 챗봇 하나만 놓고 봐도 이렇게 읽을 수 있습니다.

즉, 같은 제품을 보더라도 무엇을 잘 답했는가와 사용자가 실제로 버틸 만한 경험을 하는가는 다른 평가 문제입니다.

두 상황을 대비하면 차이가 더 직관적으로 드러납니다.

이 대비는 AI 서비스 품질 = 모델 품질 + 운영 품질이라는 감각을 줍니다.

모델 지표와 운영 지표의 구분은 지금 보는 문제가 예측 품질 문제인가, 서비스 상태 문제인가를 먼저 확인하면 정리됩니다.

SLI, SLO, SLA는 어떻게 다른가¶

Google SRE Book은 SLI, SLO, SLA를 구분해서 정의합니다. 이 구분은 중요합니다. 세 용어는 비슷해 보이지만 질문이 다릅니다.

• SLI(service level indicator): 무엇을 측정할 것인가?
• SLO(service level objective): 그 측정값을 어느 수준으로 유지하고 싶은가?
• SLA(service level agreement): 그 약속이 깨졌을 때 어떤 결과가 따르는가?

같은 서비스를 예로 들면 다음처럼 읽을 수 있습니다.

flowchart TB
  A["측정된 동작"]
  B["SLI<br/>고른 지표"]
  C["SLO<br/>목표값"]
  D["SLA<br/>못 지켰을 때의 결과"]

  A --> B --> C --> D

이 흐름을 보면, 운영에서 숫자를 읽는 일은 단순 관측이 아니라 무엇을 약속하고 어떻게 반응할 것인가까지 이어지는 구조라는 점을 알 수 있습니다.

에러 버짓(error budget)은 무엇을 더해 주는가¶

SLO를 정하면 자연스럽게 에러 버짓(error budget)이라는 개념이 따라옵니다. 아주 단순하게 말하면, 완벽하지 않아도 되는 범위를 숫자로 잡아두는 생각입니다.

예를 들어 가용성 목표가 99.9%라면, 나머지 0.1%는 허용 가능한 실패 범위입니다. 이 개념은 두 가지를 동시에 가능하게 합니다.

1. 현실적으로 100% 완벽을 강요하지 않는다.
2. 그렇다고 실패를 무시하지도 않는다.

즉, 에러 버짓은 실패를 허용하는 개념이 아니라 실패를 관리 가능한 범위 안에 두는 개념입니다.

에러 버짓을 업무 감각으로 읽기¶

에러 버짓은 추상적으로 들리기 쉽습니다. 하지만 실제로는 지금 공격적으로 바꿔도 되는가, 잠시 안정화에 집중해야 하는가를 판단하는 기준으로 읽을 수 있습니다.

즉, 에러 버짓은 운영팀만의 숫자가 아니라, 제품 팀과 개발 팀이 함께 읽는 변경 속도의 신호이기도 합니다.

운영에서는 왜 평균보다 분포와 백분위수를 더 보게 되는가¶

Google SRE Book은 운영에서 단순 평균(mean)이 중요한 사실을 가릴 수 있다고 설명합니다. 특히 지연 시간(latency)은 평균만 보면 긴 꼬리 구간(tail)이 숨겨질 수 있습니다.

예를 들어 평균 응답 시간이 100ms여도, 일부 요청이 5초씩 걸리면 사용자는 서비스를 느리다고 느낄 수 있습니다. 그래서 운영에서는 p95, p99 같은 백분위수(percentile)를 자주 봅니다.

다음처럼 정리하면 됩니다.

즉, 운영에서 숫자를 읽는 일은 평균적으로 괜찮은가만 묻는 것이 아니라, 가장 불편한 구간이 얼마나 심한가도 함께 묻는 일입니다.

SRE의 네 가지 기본 신호¶

Google SRE Book은 사용자 대상 시스템에서 특히 중요한 네 가지 기본 신호로 latency, traffic, errors, saturation을 제시합니다.

이 네 가지는 운영 관점의 기본 좌표처럼 쓸 수 있습니다.

flowchart TD
  A["사용자 요청이 들어옴"]
  B["트래픽<br/>얼마나 많은 요청이 들어오는가?"]
  C{"시스템이 한계 용량에 가까운가?"}
  D["포화<br/>CPU / 메모리 / 큐 / 연결 풀이 차오름"]
  E["지연 시간 상승<br/>응답이 느려짐"]
  F["오류 수 상승<br/>시간 초과 / 실패 요청이 늘어남"]
  G["사용자 체감 신뢰성이 떨어짐"]
  H["지연 시간가 안정적임<br/>평소와 비슷한 사용자 경험"]

  A --> B
  B --> C
  C -->|예| D
  D --> E
  D --> F
  E --> G
  F --> G
  C -->|아니오| H

이 도식은 네 신호를 단순 목록으로 외우기보다, 운영 팀이 실제로 읽는 질문 순서로 보여 줍니다. 먼저 traffic으로 지금 얼마나 많은 요청이 들어오는가를 보고, saturation으로 시스템이 한계에 가까운가를 확인합니다. 한계에 가까워지면 latency와 errors가 사용자에게 드러나는 문제로 나타나고, 그 결과 최종적으로 서비스 신뢰성이 흔들립니다. 반대로 saturation이 높지 않다면 latency가 안정적으로 유지되는지 보며 정상 상태를 확인할 수 있습니다.

이 네 신호는 머신러닝 지표를 대체하지 않습니다. 대신 좋은 모델이 실제 사용자에게 좋은 경험으로 전달되고 있는가를 확인하게 해 줍니다.

네 가지 신호를 AI 서비스 장면에 대입해 보기¶

네 가지 신호는 추상 개념으로 외우기보다 장면에 대입할 때 더 잘 남습니다.

이 표를 보면 운영 metric은 시스템이 버티는가를 읽고 있다는 점이 더 분명해집니다.

세부 학습내용¶

SRE metric을 알면 머신러닝 metric도 더 덜 낯설다¶

SW 엔지니어가 SRE metric에 익숙하다면, 머신러닝 metric도 조금 다른 종류의 판단 숫자로 받아들이기 쉬워집니다.

• latency를 보면 무엇이 느린가를 묻는다.
• error rate를 보면 무엇이 자주 실패하는가를 묻는다.
• precision과 recall을 보면 어떤 종류의 예측 실수가 더 문제인가를 묻는다.

즉, 두 세계 모두 결국 무엇을 측정하고, 어떤 실패를 줄이며, 어떤 기준으로 반응할 것인가를 정하는 일입니다. 차이는 대상이 모델이냐 서비스냐에 있습니다.

사례 및 예시¶

사례 1. 답변 품질은 좋아졌는데 서비스 불만이 늘어나는 챗봇¶

운영 팀이 상담 챗봇을 개선했습니다. 사람 기준으로는 답변 내용이 더 풍부해졌고, 내부 평가에서도 분류 정확도와 응답 적절성이 좋아졌습니다.

그런데 실제 사용자 불만은 줄지 않습니다. 이유를 보니 피크 시간에 응답 지연이 길어지고 timeout이 늘어, 좋은 답변이 나와도 늦게 도착하는 경우가 많았습니다. 이 상황은 모델 metric과 운영 metric이 서로 다른 층위를 본다는 점을 보여 줍니다.

flowchart TD
  A["챗봇 배포"]
  B["오프라인 품질 상승"]
  C["사용자 불만은 여전히 높음"]
  D["지연 시간와 시간 초과 확인"]
  E["답변 품질 확인"]
  F["서비스 문제"]
  G["모델 문제"]

  A --> B --> C
  C --> D --> F
  C --> E --> G

여기서 모델 metric은 답의 품질을, 운영 metric은 서비스 경험을 읽습니다. 답변 적절성이 높아도 latency와 error rate가 나쁘면 서비스 품질은 낮게 느껴질 수 있습니다. 반대로 서비스는 빨라도 답이 부정확하면 역시 목표를 이루지 못합니다.

확인 가능한 결과는 두 종류의 숫자를 나란히 놓을 때 드러납니다. 오프라인 평가 점수와 함께 p95 latency, timeout rate, availability를 보면, 왜 좋은 모델이 바로 좋은 서비스를 뜻하지 않는지 설명할 수 있습니다.

사례 및 예시¶

사회현상과 업무 예시로 다시 보기¶

SRE 관점의 metric은 단순한 서버 숫자가 아니라, 실제 서비스 경험과 연결됩니다.

업무 현장에서는 이런 식으로 읽을 수 있습니다.

이 표가 보여 주는 핵심은 간단합니다.

모델 metric과 운영 metric은 경쟁 관계가 아니라, 서로 다른 질문에 답하는 보완 관계다.

사회현상 예시를 조금 더 구체적으로 읽기¶

사회적 영향이 있는 서비스일수록 두 층위의 metric을 함께 읽어야 할 이유가 더 분명해집니다.

즉, 사회현상과 연결되는 시스템에서는 맞는 판단과 버티는 운영이 함께 있어야 합니다.

업무 현장에서 바로 떠올릴 수 있는 예시¶

조금 더 기술 현장에 가까운 예시로 바꾸면 다음처럼 읽을 수 있습니다.

연습 및 예제¶

Python 예제로 p95 latency를 읽어 보기¶

운영에서 평균(mean)만 보면 무엇을 놓치게 되는지 바로 드러납니다. 다음 예제는 몇 개의 요청이 매우 느릴 때 평균과 p95가 다르게 읽힌다는 점을 보여 줍니다.

문제 상황:

• 운영 지표에서는 평균만 보면 일부 매우 느린 요청이 가려질 수 있다

입력(input):

• 요청 지연 시간 목록 latencies_ms

기대 출력(output):

• 정렬된 지연 시간 목록
• 평균 latency
• p95 latency

확인할 개념:

• 평균과 백분위수는 서로 다른 사용자 경험을 보여 준다
• tail latency를 읽기 위해 p95 같은 지표가 필요하다

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 지연 시간, 오류율, SLO 달성률처럼 서비스 운영에서 쓰는 지표를 계산하는 예제입니다.
latencies_ms = [95, 100, 98, 102, 97, 105, 99, 101, 96, 110, 480, 520]

sorted_latencies = sorted(latencies_ms)
mean_latency = sum(sorted_latencies) / len(sorted_latencies)

index_95 = int(len(sorted_latencies) * 0.95) - 1
index_95 = max(0, min(index_95, len(sorted_latencies) - 1))
p95_latency = sorted_latencies[index_95]

print("sorted latencies:", sorted_latencies)
print("mean latency    :", round(mean_latency, 2), "ms")
print("p95 latency     :", p95_latency, "ms")

실행 결과는 다음과 같습니다.

1
2
3

sorted latencies: [95, 96, 97, 98, 99, 100, 101, 102, 105, 110, 480, 520]
mean latency    : 158.58 ms
p95 latency     : 480 ms

이 예제는 다음 질문을 던지게 해 줍니다.

• 평균은 158ms 정도인데, 왜 사용자는 훨씬 느리다고 느낄 수 있는가?
• 일부 느린 요청이 사용자 경험을 얼마나 크게 흔드는가?

직접 실험해 볼 수 있는 방법:

• 480, 520을 180, 220으로 바꿔 본다.
• 느린 요청을 하나 더 추가해 본다.
• 평균과 p95 중 어느 값이 먼저 크게 흔들리는지 본다.

즉, 운영에서 백분위수(percentile)를 보는 이유는 대부분 괜찮아 보이는 평균 뒤에 숨어 있는 느린 꼬리 구간(tail)을 드러내기 위해서입니다.

Python 예제로 error budget을 읽어 보기¶

에러 버짓(error budget)은 개념으로만 들으면 추상적입니다. 다음 예제는 아주 단순한 성공/실패 기록으로 SLO와 남은 버짓을 계산해 보는 연습입니다.

문제 상황:

• 에러 버짓은 정의만 읽으면 추상적이므로, 성공/실패 기록에서 허용 실패율과 실제 실패율을 직접 계산해 봐야 감각이 붙는다

입력(input):

• 요청 성공/실패 기록 requests
• 목표 SLO slo_target

기대 출력(output):

• 전체 요청 수
• availability
• 허용 실패율
• 실제 실패율
• 남은 버짓

확인할 개념:

• 에러 버짓은 허용 가능한 실패 범위를 숫자로 읽게 해 준다
• 남은 버짓이 음수가 되면 이미 목표를 초과해 실패했다는 뜻이다

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# 지연 시간, 오류율, SLO 달성률처럼 서비스 운영에서 쓰는 지표를 계산하는 예제입니다.
requests = [
    "ok", "ok", "ok", "ok", "ok",
    "ok", "ok", "fail", "ok", "ok",
    "ok", "fail", "ok", "ok", "ok",
    "ok", "ok", "ok", "ok", "ok",
]

slo_target = 0.95

total_requests = len(requests)
successful_requests = sum(1 for item in requests if item == "ok")
availability = successful_requests / total_requests
error_budget = 1 - slo_target
actual_failure_rate = 1 - availability
remaining_budget = error_budget - actual_failure_rate

print("total requests      :", total_requests)
print("successful requests :", successful_requests)
print("availability        :", round(availability, 3))
print("slo target          :", slo_target)
print("allowed failure rate:", round(error_budget, 3))
print("actual failure rate :", round(actual_failure_rate, 3))
print("remaining budget    :", round(remaining_budget, 3))

실행 결과는 다음과 같습니다.

1
2
3
4
5
6
7

total requests      : 20
successful requests : 18
availability        : 0.9
slo target          : 0.95
allowed failure rate: 0.05
actual failure rate : 0.1
remaining budget    : -0.05

이 결과는 현재 실패율이 이미 허용 범위를 넘어섰다는 뜻으로 읽을 수 있습니다.

직접 실험해 볼 수 있는 방법:

• "fail"을 하나 줄여 본다.
• slo_target을 0.99로 바꿔 본다.
• 요청 수는 같고 실패 수만 조금 바뀔 때 remaining budget이 어떻게 달라지는지 본다.

즉, 에러 버짓은 막연한 불안이 아니라 허용 범위를 아직 남겨 두고 있는가를 숫자로 읽게 해 줍니다.

Python 예제로 모델 품질과 운영 품질을 함께 읽어 보기¶

이제 같은 서비스에서 두 종류의 숫자를 같이 놓고 읽어 봅니다.

문제 상황:

• AI 서비스에서는 모델 품질과 운영 상태가 모두 중요하므로 두 종류의 숫자를 함께 읽는 연습이 필요하다

입력(input):

• 사례별 precision, recall
• 사례별 p95 latency, error rate

출력(output):

• 각 사례의 모델 품질 판단
• 각 사례의 운영 상태 판단
• 두 숫자를 함께 읽었을 때의 해석 문장

확인할 개념:

• 좋은 모델이 바로 좋은 서비스가 되는 것은 아니다
• 모델 metric과 운영 metric은 서로 다른 층위의 판단 기준이다

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

# 지연 시간, 오류율, SLO 달성률처럼 서비스 운영에서 쓰는 지표를 계산하는 예제입니다.
service_cases = [
    {
        "name": "case_A",
        "precision": 0.91,
        "recall": 0.88,
        "p95_latency_ms": 420,
        "error_rate": 0.06,
    },
    {
        "name": "case_B",
        "precision": 0.72,
        "recall": 0.68,
        "p95_latency_ms": 180,
        "error_rate": 0.01,
    },
]

model_precision_threshold = 0.85
model_recall_threshold = 0.85
latency_threshold_ms = 250
error_rate_threshold = 0.02

for case in service_cases:
    model_ok = (
        case["precision"] >= model_precision_threshold
        and case["recall"] >= model_recall_threshold
    )
    service_ok = (
        case["p95_latency_ms"] <= latency_threshold_ms
        and case["error_rate"] <= error_rate_threshold
    )

    if model_ok and not service_ok:
        interpretation = "model is strong, but service reliability is weak"
    elif not model_ok and service_ok:
        interpretation = "service is stable, but model quality is weak"
    elif model_ok and service_ok:
        interpretation = "model quality and service reliability are both acceptable"
    else:
        interpretation = "both model quality and service reliability need work"

    print(case["name"])
    print(
        "  model quality :",
        "good" if model_ok else "needs work",
        f"(precision={case['precision']}, recall={case['recall']})",
    )
    print(
        "  service state :",
        "stable" if service_ok else "unstable",
        f"(p95 latency={case['p95_latency_ms']}ms, error rate={case['error_rate']})",
    )
    print("  interpretation :", interpretation)

실행 결과는 다음과 같습니다.

1
2
3
4
5
6
7
8

case_A
  model quality : good (precision=0.91, recall=0.88)
  service state : unstable (p95 latency=420ms, error rate=0.06)
  interpretation : model is strong, but service reliability is weak
case_B
  model quality : needs work (precision=0.72, recall=0.68)
  service state : stable (p95 latency=180ms, error rate=0.01)
  interpretation : service is stable, but model quality is weak

이 예제의 핵심은 두 사례를 점수 하나로 줄이지 않는 데 있습니다. case_A는 모델 품질은 좋지만 운영 상태가 불안정하고, case_B는 서비스는 안정적이지만 모델 품질이 부족합니다. 즉, 어떤 숫자가 나쁜지에 따라 다음 행동도 달라져야 합니다.

• case_A에서는 precision이나 recall보다 p95 latency와 error rate를 먼저 고쳐야 합니다.
• case_B에서는 인프라보다 모델 개선이나 데이터 품질 점검이 먼저일 수 있습니다.
• 결국 AI 서비스 운영에서는 모델이 약한가와 서비스가 약한가를 분리해서 읽어야 다음 조치가 선명해집니다.

체크리스트¶

• 왜 좋은 모델과 좋은 서비스가 같은 말이 아닌지 설명할 수 있는가
• 지금 겪는 문제가 precision/recall 문제인지, latency/error-rate 문제인지 구분할 수 있는가
• SLI, SLO, SLA가 각각 무엇을 묻는지 입문 수준에서 말할 수 있는가
• 모델 metric은 예측 품질을 읽고, 운영 metric은 서비스 상태를 읽는다는 점을 설명할 수 있는가
• 좋은 모델이 곧 좋은 서비스는 아니고, 좋은 서비스가 곧 좋은 모델도 아니라는 점을 설명할 수 있는가
• 운영에서는 평균 하나보다 백분위수, 오류율, 가용성, 포화도 같은 여러 신호를 함께 봐야 한다는 점을 설명할 수 있는가

출처와 참고 자료¶

• Google SRE, Service Level Objectives, Site Reliability Engineering Book, 확인 날짜: 2026-06-26. https://sre.google/sre-book/service-level-objectives/
• Google SRE, Monitoring Distributed Systems, Site Reliability Engineering Book, 확인 날짜: 2026-06-26. https://sre.google/sre-book/monitoring-distributed-systems/