지표

지표는 무언가가 잘 되고 있는지를 숫자 하나로 가늠하게 해 줍니다. 서비스 운영에서는 실패한 요청의 비율이, 제품에서는 하루 방문자 수가 흔한 지표입니다. 잰 값을 시간 순으로 쌓아 둔 메트릭도 우리말로 지표라고 부르곤 합니다. 이 글은 판단에 쓰려고 정해 둔 숫자 쪽을 다룹니다.

상세

건강검진 결과지에는 혈압과 공복 혈당 같은 숫자가 몇 줄 적혀 있습니다. 몸속에서 일어나는 일은 셀 수 없이 많습니다. 의사는 그 몇 줄을 정상 범위와 견주어 괜찮은지부터 가늠합니다.

지표는 대상이 바라는 상태에 있는지 판단하려고 정해 둔 숫자입니다. 영어로는 indicator 라고 합니다. 웹 서비스라면 「최근 5분 동안 들어온 요청 가운데 오류로 끝난 비율」이 지표 하나입니다. 기준을 1%로 정해 두었다면 이 숫자가 1%를 넘을 때 무언가 잘못됐다고 봅니다.

지표가 필요한 까닭은 잴 수 있는 값이 너무 많아서입니다. 요청 하나가 끝날 때마다 걸린 시간과 성공 여부가 남습니다. 결과지의 몇 줄처럼 볼 숫자를 미리 골라 두고 셈법까지 정하면 누가 그 숫자를 봐도 같은 판단에 닿습니다.

아래 소절은 지표가 잰 값의 기록과 어떻게 다른지에서 시작합니다. 이어 지표 하나를 정할 때 적어 두는 것과 숫자를 줄이는 방법을 봅니다. 끝으로 지표를 잘못 고르거나 사람의 평가에 걸 때 생기는 일을 봅니다.

잰 값과 판단하는 숫자

메트릭은 시스템이 도는 동안 잰 값을 시각과 함께 쌓아 둔 기록입니다. 흔한 메트릭으로 카운터가 있습니다. 일이 한 번 일어날 때마다 1씩 올라가기만 하는 값입니다. 들어온 요청 수를 세는 카운터와 오류로 끝난 요청 수를 세는 카운터가 그런 예입니다.

지표는 이런 기록을 골라 계산한 결과입니다. 오류율은 5분 동안 늘어난 오류 수를 같은 5분 동안 늘어난 요청 수로 나눠 얻습니다. 메트릭 둘이 지표 하나의 재료가 됩니다. 여러 값을 모아 하나로 줄이는 이 계산을 집계라고 부릅니다.

flowchart TD
    A["5분 동안 들어온 요청 1,000건 · 하나하나 성공이나 실패로 끝남"] --> B["메트릭 · 요청 수 1,000 · 오류 수 20"]
    B --> C["지표 · 오류율 2%"]
    C --> D["판단 · 기준 1%를 넘었다"]

그림은 5분 동안 벌어진 일을 위에서 아래로 줄여 갑니다. 아래로 갈수록 숫자가 줄어듭니다. 그만큼 판단은 쉬워집니다. 대신 어느 요청이 왜 실패했는지는 내려가는 동안 사라집니다.

우리말에서는 두 낱말이 자주 섞입니다. 이 글에서는 잰 값의 기록을 메트릭, 판단에 쓰려고 정한 숫자를 지표라고 가릅니다.

지표 하나에 적어 두는 것

「오류율」이라는 이름만으로는 지표가 정해지지 않습니다. 같은 이름을 붙여도 셈법이 다르면 팀마다 다른 숫자가 나옵니다. 그래서 지표 하나를 정할 때는 셈법을 함께 적어 둡니다.

순서는 판단할 상태에서 시작합니다. 무엇이 바라는 상태인지 먼저 정합니다. 그다음 그 상태를 드러낼 숫자를 고릅니다. 그 숫자마다 아래 다섯 가지를 적습니다.

표에서 흔히 어긋나는 줄은 범위입니다. 사용자가 주소를 잘못 쳐서 실패한 요청을 오류로 세면 서버가 멀쩡해도 오류율이 오릅니다. 서버 탓인 실패만 셀지는 이 지표로 무엇을 판단하려는지에 달렸습니다.

기간도 숫자를 바꿉니다. 1분 단위로 모으면 잠깐 튄 오류가 크게 보입니다. 하루 단위로 모으면 10분짜리 장애가 나머지 시간에 묻혀 거의 안 보입니다. 이렇게 값을 모으는 구간을 측정 창이라고 부릅니다.

방향과 기준이 있어야 숫자가 판단이 됩니다. 오류율 2%는 기준이 1%일 때만 경보를 울릴 일입니다. 기준을 넘으면 담당자를 부르는 알림이 울리게 걸어 두는 일이 많습니다.

앞의 오류율은 사용자가 겪는 품질을 바로 잽니다. 이렇게 사용자 쪽에서 본 품질을 재는 지표를 서비스 수준 지표, 영어로 SLI(Service Level Indicator)라고 부릅니다.

SLI 에 거는 기준에도 이름이 있습니다. 오류율 1% 같은 기준을 서비스 수준 목표, 영어로 SLO(Service Level Objective)라고 부릅니다. 서비스가 지켜야 할 선을 정해 둔 값입니다. 이 선을 사람의 평가에 걸 때 생기는 일은 아래 「평가에 걸린 지표」에서 봅니다.

평균과 백분위수

줄이는 방법을 잘못 고르면 지표가 문제를 가립니다. 요청 하나가 끝나기까지 걸린 응답 시간을 지표로 삼을 때 이 일이 흔합니다.

아래 코드는 요청 100개의 응답 시간을 세 방법으로 줄여 봅니다. 98개는 10밀리초 만에 끝났습니다. 2개는 2초가 걸렸습니다. 단위는 밀리초입니다.

ms = [10] * 98 + [2000] * 2
sum(ms) / len(ms)        # 49.8
sorted(ms)[49]           # 10
sorted(ms)[98]           # 2000

둘째 줄은 평균입니다. 셋째 줄은 값을 작은 것부터 줄 세웠을 때 한가운데 값인 중앙값입니다. 넷째 줄은 줄 세운 100개 가운데 99번째 값입니다.

평균 49.8밀리초는 요청 어느 것의 응답 시간과도 맞지 않습니다. 대부분은 10밀리초였습니다. 두 개만 2초였습니다. 평균은 드문 2초짜리 요청을 10밀리초짜리 요청 사이에 나눠 흐리게 만듭니다.

중앙값 10밀리초는 전형적인 요청을 잘 보여 줍니다. 대신 2초가 걸린 두 개는 전혀 드러나지 않습니다.

넷째 줄의 값이 백분위수입니다. 요청의 99%가 그 값 이하로 끝나는 값을 99번째 백분위수라고 합니다. 줄여서 p99라고 씁니다. p 는 percentile(백분위수)의 머리글자입니다. 이 코드의 p99 는 2000밀리초입니다.

p99 는 오래 걸린 쪽 끝에 걸린 사용자가 무엇을 겪는지 드러냅니다. 그래서 응답 시간 지표는 평균보다 p99 같은 높은 백분위수로 잡는 일이 많습니다.

서비스에서 흔히 보는 지표

요청을 받아 처리하는 서비스라면 무엇을 볼지 처음부터 고민할 일이 적습니다. 흔히 먼저 보는 넷이 있습니다.

이 넷을 묶어 골든 시그널이라고 부릅니다. 앞의 셋은 지금 요청이 어떻게 처리되고 있는지 보여 줍니다. 포화도는 곧 닥칠 문제를 미리 보여 줍니다. 자원이 꽉 차면 그다음부터 지연과 오류가 늘기 때문입니다.

마이크로서비스처럼 서비스가 여럿으로 쪼개진 구조에서는 서비스마다 이 넷을 같은 셈법으로 둡니다. 그래야 어느 서비스에서 문제가 시작됐는지 나란히 견줄 수 있습니다.

제품을 만드는 쪽은 사용자의 행동을 지표로 삼습니다. 하루에 한 번이라도 서비스를 쓴 사람 수인 일간 활성 사용자 수가 그런 지표입니다. 방문한 사람 가운데 가입이나 구매까지 간 사람의 비율인 전환율도 그렇습니다. 재료가 서버 기록이 아니라 사용자 행동 기록입니다. 정하고 읽는 방법은 같습니다.

판단에 못 쓰는 숫자

숫자라고 다 지표 노릇을 하지는 않습니다. 판단에 쓰려면 숫자가 오르내린 것을 보고 할 일이 떠올라야 합니다.

누적 가입자 수는 사용자가 떠나도 줄지 않습니다. 떠난 사람이 많아도 예전의 가입은 남기 때문입니다. 늘 오르기만 해서 성과처럼 보입니다. 무엇을 고칠지는 알려 주지 않습니다. 이런 숫자를 허영 지표라고 부릅니다.

같은 사람 수라도 「이번 주에 다시 찾아온 사람의 비율」로 바꾸면 쓸모가 달라집니다. 이 숫자는 사용자가 떠나면 떨어집니다. 떨어진 주에 무엇이 바뀌었는지 찾아보는 일로 이어집니다.

평가에 걸린 지표

지표는 상태를 비추는 숫자입니다. 경보의 기준선으로 걸어 두면 숫자가 선을 넘을 때 사람들은 상태를 고치러 갑니다. 사람의 평가나 보상을 이 숫자에 걸면 사정이 달라집니다. 상태보다 숫자를 고치는 편이 쉬울 때 숫자와 상태 사이가 벌어집니다.

오류율이 성과 평가 항목에 들어간 팀을 떠올려 봅시다. 가장 손쉬운 길은 서버를 고치는 것이 아닐 수 있습니다. 실패한 요청에도 성공했다는 응답을 돌려줍니다. 오류는 응답 본문에만 적습니다.

오류율은 서버가 돌려준 응답이 오류인지로 셉니다. 응답 본문은 열어 보지 않습니다. 그래서 오류율은 곧장 떨어집니다. 사용자가 겪는 실패는 하나도 줄지 않았는데도 그렇습니다.

숫자가 평가의 목표가 되는 순간 상태를 비추는 힘을 잃는다는 관찰을 굿하트의 법칙이라고 부릅니다. 흔히 쓰는 대책은 지표를 짝지어 보는 것입니다. 오류율 옆에 사용자가 실패를 신고한 건수를 함께 두면 한쪽 숫자만 끌어내리는 길이 좁아집니다.

지표가 답하지 못하는 물음

지표는 「괜찮은가」에 답합니다. 「왜 안 괜찮은가」에는 답하지 못합니다. 숫자로 줄이는 동안 사건 하나하나의 사연을 버렸기 때문입니다.

오류율이 2%로 올랐다는 것은 지표가 알려 줍니다. 어느 요청이 어떤 입력을 받아 어디서 멈췄는지는 다른 기록이 알려 줍니다. 사건마다 남긴 로그와 요청 하나가 거쳐 간 경로를 적은 트레이스입니다. 그래서 운영에서는 지표로 이상을 알아챕니다. 원인은 로그와 트레이스로 좁힙니다.

한 건을 끝까지 따져야 하는 일에는 지표가 맞지 않습니다. 사용자 한 명의 결제가 왜 실패했는지는 오류율을 봐서는 모릅니다. 그 사람의 요청 기록을 찾아봐야 합니다.

관련 항목

지표의 재료가 되는 측정 기록

메트릭 · 로그 · 트레이스 · 이벤트 · 텔레메트리 · 계측 · 시계열

잰 값을 지표로 줄이는 계산

집계 · 측정 창 · 평균 · 중앙값 · 백분위수 · p99 · 히스토그램 · 이동 평균

서비스 운영에서 쓰는 지표

오류율 · 지연 · 응답 시간 · 처리량 · 포화도 · 가용성 · 골든 시그널

제품과 조직을 재는 지표

일간 활성 사용자 수 · 전환율 · 재방문율 · 핵심 성과 지표 · DORA

지표에 기준을 거는 약속

서비스 수준 지표 · 서비스 수준 목표 · 서비스 수준 계약 · 오류 예산

지표를 보고 움직이는 실천

모니터링 · 관측성 · 대시보드 · 알림 · 경보 · 온콜

지표를 잘못 쓸 때 생기는 문제

굿하트의 법칙 · 허영 지표 · 지표 조작 · 알림 피로 · 카디널리티 폭발