1.3

1.3 산출물보다 결과: 무엇을 측정할지 선택하기

개요 및 동기

모든 엔지니어링 메트릭은 세 범주 중 하나에 속하며, 이를 혼동하는 것은 굿하트의 법칙을 완전히 무시하는 것 다음으로 이 책에서 두 번째로 흔한 실패 양상이다. 투입 메트릭은 투입된 노력을 측정한다: 엔지니어 시간, 투입된 금액, 약속된 스토리 포인트. 산출 메트릭은 시스템이 만들어 낸 것을 측정한다: 출시된 기능, 병합된 풀 리퀘스트, 닫힌 티켓. 결과 메트릭은 실제로 중요했던 변화를 측정한다: 유지된 매출, 예방된 장애, 사용자를 위해 절약된 시간. 팀은 투입과 산출 쪽으로 끌리는데, 그것들이 세기 쉽고 완전히 팀의 통제 안에 있기 때문이다. 가치는 거의 언제나 결과 안에 있으며, 결과는 더 늦게 나타나고, 측정하기에 더 시끄러우며, 어느 한 팀의 작업으로 귀속시키기가 더 어렵다.

이 주제는 그 중력에 의도적으로 저항하는 것을 다룬다. 전적으로 투입과 산출로만 만들어진 대시보드는 실제 가치를 전혀 만들어 내지 못하면서도 인상적으로 분주해 보일 수 있다: 팀은 아무도 사용하지 않는 수십 개의 기능을 출시할 수 있고, 일주일 뒤 다시 열리는 수백 개의 티켓을 닫을 수 있으며, 제품의 실제 결과인 유지율, 만족도, 매출이 정체되거나 하락하는 동안 모든 스토리 포인트 추정치를 달성할 수 있다. 그 어떤 분주함도 산출물 전용 대시보드에는 문제로 나타나지 않는데, 산출물 전용 대시보드는 애초에 그것을 보도록 만들어지지 않았기 때문이다.

엔터프라이즈와 정부 규모에서는 이 구분이 리더십이 생산적인 팀과 단지 활동적이기만 한 팀을 구별할 수 있는지를 결정한다. 한 사업부는 몇 년 동안 출시된 기능, 마감된 스프린트 같은 훌륭한 산출 수치를 게시할 수 있는 한편, 자금 제공자나 입법부가 실제로 신경 쓰는 결과, 즉 유지된 매출, 줄어든 시민 대기 시간은 그 아래에서 조용히 침식될 수 있다. “우리는 로드맵을 전달했다”는 “그 로드맵이 상황을 개선했다”와 같은 주장이 아니며, 오직 결과에 가중치를 둔 메트릭 집합만이 그 둘을 구별할 수 있다.

핵심 원칙

  • 투입과 산출은 대리 지표이고, 결과는 그 자체다. 닿을 수 있는 곳이라면 어디든 메트릭 집합을 결과 쪽으로 더 무겁게 설계하라.
  • 측정의 용이성은 무언가를 측정할 이유가 아니다. 가장 세기 쉬운 것들은 보통 투입과 산출인데, 그것들이 가장 중요해서가 아니라 기계적으로 포착하기 단순하기 때문이다.
  • 결과 쪽으로 이동할수록 귀속은 더 어려워진다. 결과가 귀속시키기 더 어렵다고 산출로 물러서지 말고, 그 트레이드오프를 의도적으로 받아들여라.
  • 팀은 자신의 투입과 산출은 통제할 수 있지만 결과에는 영향만 미칠 수 있다. 그에 맞게 책임을 설계하라: 팀이 실제로 통제할 수 있는 것에 대해서는 팀에 책임을 묻고, 결과는 공유되는 팀 간 신호로 추적하라.
  • 소수의 동인을 거느린 단일한 노스스타 결과는 산출 타일의 벽보다 낫다. 커버리지는 순전한 대시보드 물량이 아니라 구조에서 나와야 한다.

권장 사항

채택하기 전에 모든 메트릭을 분류하라

후보 메트릭에 대해, 그것이 세 범주 중 어디에 속하는지 물어라. “주당 병합된 풀 리퀘스트”는 산출이다. “일주일 안에 프로덕션 장애를 일으킨 병합된 풀 리퀘스트의 비율”은 물량이 아니라 결과를 측정하기 때문에 결과에 더 가깝다. 이 분류는 30초가 걸리며, 어떤 메트릭이든 팀이나 조직의 대시보드에 추가되기 전에 필수여야 한다. 이는 대시보드가 가치를 측정한다고 믿으면서 세기 쉬운 산출물로 조용히 채워지는 것을 잡아내는 가장 빠른 방법이기 때문이다.

단일한 결과 아래 메트릭 트리를 구축하라

평평한 목록을 추적하지 마라. 메트릭을 메트릭 트리(때로는 KPI 트리라고도 불린다)로 배열하라: 최상위 결과 메트릭을 인과적으로 또는 수학적으로 그것에 영향을 미치는 동인들로 분해하여, 개별 팀이 실제로 소유한 운영상의 산출 및 투입 측정치까지 내려간다. 최상위 결과가 움직일 때, 그 트리는 어느 하위 수준의 동인을 조사해야 하는지 알려주며, “수치가 떨어졌다”를 “파이프라인의 이 특정 단계가 원인이다”로 바꾼다. 당신의 영역이 하나를 지탱할 수 있는 곳이라면 어디든 최상단에 단일한 노스스타 메트릭의 이름을 붙여라: 전달된 가치를 가장 잘 포착하는 측정치, 플랫폼 팀이라면 변경 실패율과 짝을 이룬 배포 빈도, 제품 팀이라면 핵심 기능의 주간 활성 사용.

대시보드뿐 아니라 검토에서도 결과에 가중치를 두라

메트릭 트리는 실제로 어떻게 사용되는가에 따라서만 좋아진다. 스프린트 검토, 분기 비즈니스 검토, 그리고 리더십 업데이트에서, 결과 수준의 수치를 앞세우고 그 아래의 산출 및 투입 메트릭은 그것을 대체하는 것이 아니라 오직 움직임을 설명하는 데만 사용하라. 어떤 결과 맥락도 없이 “이번 스프린트에 40개의 티켓을 닫았다”고 보고하는 팀은 그 작업이 중요했는지에 대해 아무것도 말해 주지 않았다. “누락된 결함이 30% 줄었고, 이를 이끈 테스트 투자는 이것이다”라고 보고하는 팀은 실제적인 무언가를 말해 주었다.

결과 메트릭에 대해서는 더 느린 피드백을 받아들이고, 더 빠른 선행 지표와 짝지어라

결과 메트릭은 흔히 후행적이다: 충분한 시간이 지나 확신할 수 있게 된 후에야 결과를 확인해 준다. 그 지연은 진짜 비용인데, 학습을 지연시키기 때문이다. 모든 결과 메트릭을 적어도 하나의 선행 지표, 즉 더 일찍 움직이며 결과를 예측하는 메트릭과 짝지어, 느리고 권위 있는 수치가 마침내 도착하기 전에 팀이 방향을 조종할 수 있게 하라. 배포 빈도는 전달 결과에 대한 선행 지표이고, 상승하는 결함 누락 추세는 다가오는 신뢰성 결과에 대한 선행 지표다. 선행 지표를 이용해 일찍 행동하고, 후행하는 결과 메트릭을 이용해 당신이 옳았음을 확인하라.

트레이드오프: 장단점

범주장점단점
투입 메트릭완전히 팀의 통제 안에 있고 세기 쉬움실제 가치와의 연결이 가장 약함; 물량으로 쉽게 게임됨
산출 메트릭세기 쉽고, 소유권이 명확하며, 빠른 피드백영향보다 활동을 보상함; 가치가 떨어지는 동안에도 올라갈 수 있음
결과 메트릭중요한 것을 직접 반영함; 값싸게 게임하기 어려움느리고, 시끄러우며, 단일 팀으로 귀속시키기 어려움
메트릭 트리 구조일상 업무를 전략적 가치에 연결함; 진단을 돕는다올바르게 구축하고 유지하려면 실제 분석 작업이 필요함

핵심 긴장은 통제 가능성 대 가치다. 투입과 산출은 완전히 팀의 통제 안에 있어 팀에 책임을 묻고 싶게 만들지만, 가치를 지니는 것은 결과이며 결과는 어느 한 팀의 영향 안에만 부분적으로 있다. 좋은 기능도 엔지니어링과 전혀 무관한 이유로 실패할 수 있기 때문이다. 팀이 완전히 통제하는 투입과 산출에 대해서는 팀에 책임을 묻고, 결과는 “우리는 작업을 했다”와 “그것이 도움이 되었다” 사이의 설명되지 않은 간극으로 남겨 두는 대신 명시적인 메트릭 트리를 통해 연결된, 조직 전체가 함께 소유하는 공유 신호로 추적함으로써 이를 해결하라.

팀과 논의할 질문

  1. 우리의 현재 대시보드에 있는 각 메트릭에 대해, 그것은 투입인가, 산출인가, 결과인가, 그리고 셋 사이의 균형은 정직한 이야기를 전하는가? 정직하게 감사해 보면 대부분의 대시보드는 거의 전적으로 투입과 산출로 밝혀지는데, 도구가 기본적으로 보고하는 것이 바로 그것들이기 때문이다. 모든 타일을 분류하고 그 분할을 세어 보라. 결과 타일이 전혀 없는 대시보드는 활동을 측정하면서 그것을 성과로 제시하고 있는 것이다.

  2. 우리의 단일한 노스스타 결과 메트릭은 무엇이며, 이를 메트릭 트리를 통해 각 팀이 실제로 소유한 것까지 추적할 수 있는가? 이 연결 구조 없이는 움직이는 최상위 수치가 어디를 봐야 할지 단서를 전혀 주지 못하고, 팀은 자신의 일상적인 산출 메트릭이 중요한 무언가와 어떻게 연결되는지 볼 수 없다. 현재의 최상위 메트릭이 있다면 그것을 가져와 실시간으로 그 트리를 만들어 보라.

  3. 팀이 통제할 수는 없고 영향만 미칠 수 있는 결과에 대해 팀에 책임을 묻고 있는 곳은 어디인가? 이것은 흔한 좌절의 원천이자 조용한 게임의 원천인데, 자신의 통제 밖에 있는 요인에 의해 형성된 결과로 벌받는 팀은 실제 시스템을 개선하기보다 스스로를 보호할 온갖 유인을 갖게 되기 때문이다. 이러한 불일치를 식별하고 책임을 조정하거나 누락된 지렛대를 추가하라.

  4. 우리의 후행하는 결과 메트릭 각각에 대해 어떤 선행 지표가 있으며, 그것은 얼마나 앞서서 그것을 예측하는가? 순전히 후행하는 메트릭 집합은 저렴하게 경로를 바꾸기에는 너무 늦은 후에야 당신이 틀렸다는 것을 알게 된다는 뜻이다. 결과 메트릭을 가져와 각각에 대해 진정한 선행 지표가 존재하는지, 아니면 보고 기간 사이에 눈을 감고 비행하고 있는지 확인하라.

  5. 검토와 회고에서 우리가 축하하는 것 중 얼마나 많은 부분이 산출(“우리는 X를 출시했다”)이고 얼마나 많은 부분이 결과(“X가 Y를 더 낫게 바꾸었다”)인가? 팀이 작업을 축하하는 데 사용하는 언어는 흔히 대시보드보다 더 강하게 시간이 지남에 따라 팀이 무엇을 최적화하는지를 형성한다. 한 스프린트 동안 자신의 검토 회의를 들어 보고 그 분할을 정직하게 세어 보라.

  6. 만약 우리의 주요 산출 메트릭이 하룻밤 사이에 두 배가 된다면, 우리의 결과 메트릭은 반드시 개선될 것인가, 아니면 더 나빠질 수도 있는가? 이 사고 실험은 그것이 봉사하도록 의도된 결과로부터 단절되었거나 심지어 적극적으로 반대되는 산출 메트릭을 드러낸다. 이를테면 채택을 늘리는 것보다 더 빠르게 유지보수 부담을 늘리는 기능 물량 같은 것이다.

분야별 관점

스타트업. 하나의 결과, 보통 고객이 계속 가치를 얻고 있는지에 대한 대리 지표, 이를테면 주간 유지율이나 활성화율을 골라 첫날부터 그것을 당신의 노스스타로 취급하라. 누적 기능 수처럼 투자자에게 보고하기에는 유혹적이지만 제품이 실제로 누군가에게 효과가 있는지에 대해서는 아무것도 말해 주지 않는 산출 허영 메트릭 쪽으로의 끌림을 물리쳐라.

중소기업. 당신의 기존 도구, 결제 시스템, 지원 데스크, 분석 도구는 보통 이미 결과에 가까운 수치, 즉 재구매율, 티켓 재오픈율을 보고한다. 유지할 역량이 없는 맞춤형 결과 계측을 구축하는 대신 그것들을 사용하고, 그것이 기본 화면이라는 이유만으로 원시 활동 개수에 의지하고 싶은 유혹을 물리쳐라.

엔터프라이즈. 지배적인 실패 양상은 각각 지역적인 산출 메트릭을 최적화하지만 그 어떤 일관된 조직적 결과로도 합쳐지지 않는 팀들의 포트폴리오다. 메트릭 트리를 의도적으로 구축하고, 사업부 전반에 걸쳐 결과 정의를 표준화하며, 모든 주요 이니셔티브가 자금 지원 전에 산출 계획뿐 아니라 결과 가설을 명시하도록 요구하라.

정부. 감독 기구와 대중은 “작업 명세서를 전달했다”와 “결과를 개선했다”의 차이에 점점 더 밝아지고 있으며, 산출물 전용 보고서는 정확히 그런 정밀 조사를 초래한다. 법적으로 그리고 실무적으로 가능한 곳이라면 어디든 성공을 시민 대면 결과(대기 시간, 오류율, 만족도)로 정의하고, 산출 메트릭만 이용 가능한 경우에는 그것과 그 이유를 명시하라.

사례

엔터프라이즈. 한 물류 회사의 엔지니어링 사업부는 2년 동안 “분기당 출시된 기능”의 꾸준히 상승하는 수치를 보고했지만, 그동안 회사의 핵심 고객 만족도 점수는 조용히 정체되었다. 새로운 엔지니어링 VP는 실제 비즈니스 결과인 정시 배송률에 뿌리를 둔 메트릭 트리를 구축했고, 이를 허브 체류 시간과 라스트 마일 성공을 거쳐 팀 수준의 엔지니어링 산출까지 분해했다. 단 하나의 보고 주기 안에 여러 고산출 팀이 노스스타 메트릭에 측정 가능한 영향이 전혀 없는 영역에서 기능을 출시하고 있었다는 것이 명확해졌고, 투자는 그 트리가 실제로 중요하다고 보여 준 동인 쪽으로 이동했다.

정부. 한 국가 보건 서비스의 디지털 팀은 다년간의 환자 기록 현대화 프로그램에 대해 “작업 명세서 대비 전달된 모듈”을 보고해 왔다. 감독 위원회는 다른 질문을 던졌다: 임상의들이 행정 데이터 입력에 쓰는 시간이 줄었는가? 팀은 결과 메트릭인 환자 진료당 행정 시간의 중앙값(분)을 사후에 도입했고, 모든 전달 마일스톤을 달성했음에도 초기 모듈이 워크플로 마찰로 인해 실제로 이 시간을 늘렸다는 것을 발견했다. 이후의 모듈은 그 결과 메트릭을 중심으로 직접 재설계되었고, 프로그램의 공개 보고는 전달 체크리스트에서 전후 결과 비교로 전환되었다.

비즈니스 사례: 동기, ROI, TCO

결과 가중치의 수익은 낭비를 피하는 것이다: 산출물의 흐름이 어떤 결과도 움직이고 있지 않다는 것을 거의 실시간으로 볼 수 있는 조직은 그것을 어렵게 알아내는 데 온전한 예산 주기를 다 쓰기 전에 그 투자를 재조정할 수 있다. 대규모 엔지니어링 조직에서 지배적인 숨겨진 비용은 과소투자가 아니라, 어떤 실제 결과로부터도 단절되어 애초에 자금 지원을 받지 말았어야 할, 훌륭하게 실행된 작업이며, 산출물 전용 대시보드는 그 단절을 전혀 볼 수 없다.

결과 측정의 총 소유 비용은 산출 측정보다 높은데, 결과는 정의하고, 귀속시키고, 계측하기가 진정으로 더 어렵고, 실제 메트릭 트리를 구축하려면 도구가 기본적으로 내보내는 것을 받아들이는 대신 의도적인 분석 노력이 필요하기 때문이다. 그 비용은 적당한 규모 이상의 어떤 이니셔티브에 대해서도 치를 가치가 있는데, 대안, 즉 자신 있게 보고된 일 년치 산출이 실제 가치를 전혀 만들어 내지 못했다는 것을 사후에 발견하는 것은 사전 분석보다 훨씬 더 많은 비용이 들기 때문이다.

안티패턴과 함정

  • 전적으로 산출 타일로만 이루어진 대시보드: 활동을 측정하면서 그것을 성과로 제시한다.
  • 팀이 통제할 수 없는 결과에 대해 팀에 전적으로 책임을 묻기: 좌절을 낳고 부당한 비난으로부터 스스로를 보호하기 위한 게임을 초대한다.
  • 후행하는 결과에 대한 선행 지표가 없음: 팀은 고치기에는 너무 비싸진 후에야 자신이 틀렸다는 것을 배운다.
  • 결과를 중시한다고 주장하면서 검토에서는 산출 언어를 축하하기: 명시된 우선순위와 실제로 체감되는 유인이 어긋나며, 실제로 체감되는 유인이 이긴다.
  • 트리 구조가 없는 평평한 메트릭 목록: 움직이는 최상위 수치가 어디를 봐야 할지 단서를 전혀 주지 못한다.
  • 결과 측정을 시도하기에는 너무 어렵다고 취급하기: 조직을 세기 쉬운 투입과 산출로 영구히 되돌린다.

성숙도 모델

  • 1단계, 시작: 메트릭은 거의 전적으로 투입과 산출이다. 아무도 조직의 결과 메트릭의 이름을 대거나 그것으로의 경로를 추적할 수 없다.
  • 2단계, 개발: 일부 팀이 비공식적으로 결과 메트릭을 식별했지만, 공유되는 메트릭 트리도 일관된 선행 지표도 없다.
  • 3단계, 표준화: 문서화된 메트릭 트리가 공유되는 노스스타 결과를 팀이 소유한 산출까지 연결하며, 조직 전반에 걸쳐 일관되게 적용된다.
  • 4단계, 관리: 선행 지표와 후행 지표가 함께 추적되고 검토된다. 팀은 오직 그들이 통제하는 것에 대해서만 책임을 지며, 결과 측정에 적극적으로 자원이 배분된다.
  • 5단계, 조율: 결과 측정이 자금 지원 및 우선순위 결정에 직접 통합된다. 조직은 온전한 예산 주기가 지나기 전에 고산출-저결과 작업에서 투자를 일상적으로 재조정한다.

논의를 위한 아이디어

  1. 우리 조직의 단 하나의 가장 중요한 결과 메트릭의 이름을 대라. 모두가 그것에 동의할 수 있는가?
  2. 아직 어떤 결과로도 추적할 수 없는 산출에 대한 우리의 가장 큰 현재 투자는 무엇인가?
  3. 우리의 책임 구조는 팀이 통제할 수 없는 결과에 대해 팀을 어디에서 벌하는가?
  4. 모든 순수한 산출 타일을 삭제한다면 우리 대시보드는 어떻게 보일 것인가?
  5. 출시된 기능이 실제로 도움이 되었는지 알아내는 데 현재 우리에게 얼마나 걸리는가?

핵심 요약

  • 모든 메트릭을 투입, 산출, 혹은 결과로 분류하고, 의도적으로 집합을 결과 쪽으로 더 무겁게 설계하라.
  • 움직이는 최상위 수치가 원인을 가리킬 수 있도록 단일한 노스스타 메트릭 아래 메트릭 트리를 구축하라.
  • 팀이 통제하는 것(투입, 산출)에 대해서는 팀에 책임을 묻고, 결과는 조직 전체가 함께 영향을 미치는 공유 신호로 추적하라.
  • 느린 수치가 당신이 틀렸다는 것을 확인해 주기 전에 방향을 조종할 수 있도록 모든 후행하는 결과 메트릭을 더 빠른 선행 지표와 짝지어라.
  • 산출물 전용 대시보드는 활동을 측정하면서 그것을 성과라고 부른다. 그것을 위안이 아니라 경고 신호로 취급하라.

참고 문헌 및 추가 자료

  • Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
  • Croll, Alistair, and Benjamin Yoskovitz. Lean Analytics: Use Data to Build a Better Startup Faster. O’Reilly Media, 2013.
  • Doerr, John. Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs. Portfolio, 2018.
  • Ries, Eric. The Lean Startup. Crown Business, 2011.
  • Parmenter, David. Key Performance Indicators: Developing, Implementing, and Using Winning KPIs. Wiley, 2015.