指標は定義ではなく計算で分かれる

한 줄 요약

DORA 네 지표는 이름을 아는 것으로 끝나지 않습니다. 같은 데이터를 놓고도 창(window)·분모·대푯값 을 어떻게 잡느냐에 따라 숫자가 몇 배씩 달라지므로, 지표는 정의와 함께 계산 방법을 문서가 아니라 코드로 못박아야 합니다.

왜 이게 필요했나

두 팀이 같은 배포 기록을 보고 각자 "리드 타임 40분" 과 "리드 타임 4시간" 을 보고한 적이 있습니다. 데이터는 같았습니다. 한쪽은 중앙값을, 다른 쪽은 평균을 썼고, 한쪽은 성공한 배포만 세고 다른 쪽은 전부 셌습니다. 이렇게 되면 숫자로 대화할 수 없습니다. 지표가 늘어날수록 회의가 길어지는 조직은 대개 여기서 막혀 있습니다.

그래서 플랫폼 팀이 지표를 도입할 때 가장 먼저 정해야 하는 것은 어떤 지표를 볼지가 아니라 그 지표를 어떻게 계산할지 입니다.

어떻게 동작하나

원장에서 시작합니다

지표는 대시보드가 아니라 원장(ledger) 에서 나옵니다. 배포 한 건마다 서비스 이름, 언제 커밋이 만들어졌고 언제 배포됐는지, 성공인지 실패인지, 실패했다면 복구까지 얼마나 걸렸는지를 한 행으로 남깁니다. 이 한 장이 있으면 네 지표를 모두 계산할 수 있고, 없으면 어떤 도구를 사도 추정만 하게 됩니다.

네 지표의 계산에서 실제로 갈리는 곳

지표	자주 틀리는 지점
배포 빈도	조직 전체 합만 보면 한 서비스가 자주 배포해 나머지를 가린다. 서비스별로도 본다
변경 리드 타임	평균은 오래 걸린 한 건에 끌려간다. 중앙값을 쓴다
변경 실패율	분모는 배포 건수다. 서비스 수나 사고 건수가 아니다
평균 복구 시간	분모는 실패한 배포 건수 다. 전체 배포로 나누면 값이 몇 배로 작아진다

중앙값에는 함정이 하나 더 있습니다. 서비스별 중앙값의 평균은 전체 중앙값이 아닙니다. 배포 건수가 서비스마다 다르기 때문에 두 값은 대체로 다르고, 둘을 섞어 쓰면 같은 원장에서 서로 다른 보고서가 나옵니다.

등급은 임계값을 먼저 적어 놓고 판정합니다

DORA 는 네 지표를 Elite·High·Medium·Low 로 나눕니다. 여기서 중요한 것은 임계값 자체보다, 우리 조직이 쓰는 임계값을 미리 적어 두고 그대로 적용하는 것 입니다. 판정할 때마다 기준을 조금씩 조정하면 등급은 아무 의미가 없어집니다.

그리고 네 지표는 함께 읽습니다. 속도 지표는 좋은데 안정성 지표가 나쁘면 그 조직은 빠른 것이 아니라 검증을 건너뛰고 있는 것 입니다. 반대로 안정성만 좋고 배포가 뜸하면 위험을 회피하느라 개선이 멈춘 상태일 수 있습니다.

채택률은 분모와 '활성' 의 정의가 전부입니다

플랫폼 채택률에서 다투게 되는 것은 언제나 두 가지입니다. 분모를 전체 서비스로 볼 것인가 온보딩한 서비스로 볼 것인가, 그리고 무엇을 '쓰고 있다' 로 볼 것인가입니다. 온보딩 완료를 채택으로 세면 숫자는 예쁘지만 실제로 아무도 쓰지 않는 상태를 숨깁니다. 최근 일정 기간 안에 실제로 배포한 서비스를 세는 편이 정직하고, 그 기간을 함께 적어야 나중에 비교할 수 있습니다.

에러 버짓은 산수입니다

SLO 가 99.5% 이고 창이 28일이면 예산은 이렇게 나옵니다. 28일은 40320분이고, 그 0.5%인 201.6분이 이번 창에서 허용되는 나쁜 시간입니다. 여기서 실제로 소진한 시간을 빼면 남은 예산이 나옵니다. 이 숫자가 있어야 "지금 새 기능을 더 낼 것인가, 안정화에 쓸 것인가" 를 감정이 아니라 잔량으로 이야기할 수 있습니다.

현장에서 만나는 모습

지표를 팀 사이의 순위표로 쓰기 시작하면 원장이 오염됩니다. 실패를 실패로 적지 않게 되고, 배포 단위를 잘게 쪼개 건수를 늘리게 됩니다. 숫자는 좋아지는데 실제 상황은 나빠지고, 그때부터 지표는 현실을 가리는 장치가 됩니다.

그래서 플랫폼 팀은 지표를 자기 자신에게 겨눕니다. 준수율이 낮은 규칙이 있으면 그 팀을 부르는 대신 그 규칙을 지키기 쉽게 만들고, 리드 타임이 유독 긴 서비스가 있으면 그 서비스의 파이프라인에서 무엇이 기다리고 있는지를 봅니다. 지표의 쓸모는 순위가 아니라 다음에 무엇을 고칠지 를 정하는 데 있습니다.

지표가 사람의 행동을 바꾸는 방식

플랫폼 지표를 재기 시작하면 곧 알게 되는 것이 있다. 재는 순간 그 숫자가 목표가 되고, 사람들은 그 숫자를 좋게 만드는 쪽으로 움직인다. 그래서 무엇을 재는지가 곧 무엇이 일어나는지가 된다.

배포 빈도만 재면 의미 없는 배포가 늘어난다. 변경 없는 재배포, 잘게 쪼갠 커밋이 숫자를 올린다. 그래서 네 지표는 함께 본다. 배포 빈도가 오르면서 변경 실패율이 그대로여야 실제로 나아진 것이고, 하나만 좋아졌다면 대개 다른 쪽을 희생한 것이다.

변경 실패율의 분모를 정하지 않으면 아무 값이나 나온다. "실패" 가 되돌림인지, 장애인지, 사고 등급 이상인지에 따라 배가 달라진다. 정의를 적어 두고, 바꿀 때는 과거 값도 함께 다시 계산한다. 그러지 않으면 정의가 바뀐 달의 그래프가 개선처럼 보인다.

복구 시간은 중앙값과 최악을 함께 본다. 대부분 10분에 끝나는데 분기에 한 번 8시간이 걸린다면, 평균은 아무것도 말해 주지 않는다. 사람들이 기억하는 것은 그 8시간이다.

팀 간 비교에 쓰지 않는다. 서비스의 성격이 다르면 숫자도 다르다. 결제 시스템과 사내 도구를 같은 표에 놓으면, 결제 팀은 위험을 감수하지 않는 쪽으로 움직인다. 지표는 같은 팀의 시간에 따른 변화를 보는 데 쓴다.

채택률은 "쓰고 있다" 가 아니라 "이걸로 일한다" 로 정의한다. 계정을 만든 사람 수는 아무것도 말하지 않는다. 지난 30일 안에 실제로 배포를 한 팀 수처럼, 행동을 세는 정의여야 플랫폼이 도움이 되는지를 알 수 있다.

에러 버짓은 협상 도구다. 버짓이 남으면 위험한 변경을 해도 되고, 다 쓰면 안정화에 집중한다는 합의가 미리 있어야 값이 생긴다. 그 합의 없이 숫자만 재면 장애 뒤에 그 숫자를 놓고 다투는 자료가 될 뿐이다.

다음 실습에서 할 것

28일치 배포 원장을 놓고 네 지표를 직접 계산합니다. 중앙값과 평균의 차이, 실패율과 복구 시간의 분모를 손으로 확인하고, 미리 정한 임계값으로 등급을 판정합니다. 이어서 서비스 명부에서 채택률을 활성 사용의 정의대로 계산하고, 마지막으로 에러 버짓의 예산과 소진율을 구합니다.