3.3 성과 메트릭과 결과 대리 지표

개요 및 동기

SPACE(주제 3.1)에서 P에 해당하는 성과는 활동과 가장 흔히 혼동되는 차원이며, 그 혼동이야말로 이 주제가 예방하기 위해 존재하는 것이다. 성과는 엔지니어나 팀의 작업이 실제로 좋은 결과를 만들어 냈는지 묻는다: 출시되어 작동한 기능, 신뢰성 있게 유지된 시스템, 비즈니스나 사용자 메트릭을 올바른 방향으로 움직인 변경. 활동(주제 3.4)은 오직 얼마나 많은 움직임이 일어났는지만 묻는다. 팀은 결과를 결코 움직이지 않는 끊임없는 작은 변경을 출시하며 매우 활동적이면서 저성과일 수 있으며, 그 반대도 똑같이 가능하다: 드물게 출시하지만 그 변경이 신뢰성 있게 정확히 제대로 자리 잡는 팀.

이 차원의 어려움은 결과가 흔히 단일한 사람이나 심지어 단일한 팀에게 귀속될 수 없다는 것이다. 소프트웨어 결과는 협업으로부터, 이후 다른 프로젝트로 옮긴 사람들이 몇 달 전에 내린 결정으로부터, 어떤 엔지니어도 통제하지 못하는 시장 상황으로부터 나타난다. SPACE 연구자들은 이에 대해 명시적이었다: 성과는 하나의 수치로 축소되어서도 안 되고 확실히 고립된 개별 엔지니어에게 귀속되어서도 안 되며, 여러 개의 수렴하는 신호를 사용해 시스템이나 팀 수준에서 측정되어야 한다. 이 주제는 그 지침을 진지하게 받아들이며 개인 성과 귀속을 편리할 때 취할 지름길이 아니라 능동적으로 피해야 할 함정으로 취급한다.

대규모 팀에게 성과 측정을 올바르게 하는 것이야말로 실제로 결과를 개선하는 메트릭 프로그램을 단지 눈에 보이는 분주함을 보상하는 프로그램으로부터 구별하는 것이다. 많은 팀에 걸쳐 성과를 비교하는 엔터프라이즈 조직은 원시 산출물 물량을 통한 게임에 저항하는 신호가 필요하다. 감독 기구에 기술 투자를 정당화하는 정부 조직은 엔지니어링 노력이 단지 전달된 산출물이 아니라 실제 결과를 만들어 냈다는 것을 입증해야 하는데, 이것이 정확히 이 특정 차원에 적용된 주제 1.3의 산출물보다 결과 원칙이다.

핵심 원칙

성과는 작업이 얼마나 많이 일어났는지가 아니라 좋은 결과를 만들어 냈는지 측정한다. 이것이 활동 차원과의 핵심 구분이다.
여러 개의 수렴하는 신호를 사용하고, 결코 단일한 성과 수치를 사용하지 마라. 어떤 개별 대리 지표도 홀로 서기에 충분히 신뢰할 수 없다.
팀이나 시스템 수준에서 측정하라. 개인 결과 귀속은 보통 신뢰할 수 없으며 정확히 이 책 전체가 경고하는 게임을 초래한다.
품질은 별개의 관심사가 아니라 성과의 일부다. 출시되었지만 다른 무언가를 망가뜨린 작업은 실제로 잘 성과를 낸 것이 아니다.
결정이 붙어 있지 않은 성과 신호는 장식이다, 이 차원에 적용된 주제 1.1의 일반 원칙 그대로다.

권장 사항

하나의 성과 점수 대신 여러 개의 수렴하는 신호를 결합하라

여러 출처로부터 성과 증거를 끌어오라: 품질을 위한 변경 실패율(주제 2.10)과 결함 누락률(주제 5.1), 작업이 중요했는지를 위해 실제 기능 채택(주제 5.2)에 연결된 배포 결과, 그리고 순수한 메트릭이 포착할 수 없는 맥락을 위한 전략적 목표에 대한 팀의 기여에 대한 정성적인 동료나 관리자 평가. 이것들 중 어느 것도 홀로는 신뢰할 수 없다. 그것들이 같은 결론으로 수렴할 때 함께 있으면 어떤 단일 수치보다 훨씬 더 신뢰할 수 있다.

팀 수준에서 측정하고 개인 귀속에 저항하라

소프트웨어 결과는 좀처럼 한 사람의 작업만의 산물이 아니다. 그것들은 설계 결정, 리뷰 피드백, 이후 팀을 떠났을 수 있는 사람들의 이전 작업, 그리고 경계를 넘는 협업으로부터 나타난다. 결과를 단일 엔지니어에게 귀속시키는 것은 보통 이 현실을 무시하는 거짓 정밀함이며 자유롭게 협업하기보다 공로를 보호하려는 강한 유인을 개인에게 만들어 내며, 이는 정확히 주제 1.2가 경고하는 종류의 유인 왜곡이다.

품질을 성과의 정의에 직접 접어 넣어라

제시간에 출시되었지만 프로덕션 인시던트의 물결을 초래한 기능은 순진한 산출물 전용 관점이 그것을 전달된 것으로 셀지라도 잘 성과를 낸 것이 아니다. 품질을 이 책의 4부와 6부에서만 측정되는 별개의 단절된 관심사로 취급하는 대신, 변경 실패율, 결함 누락률, 릴리스 후 인시던트 데이터를 당신이 성과를 평가하는 방식에 직접 구축하라.

개인 순위가 아니라 투자와 프로세스 결정을 알리는 데 성과 데이터를 사용하라

성과 데이터의 생산적인 사용은 어디에 더 투자할지(지속적으로 강한 결과를 전달하는 팀은 더 많은 자원과 자율성을 받을 자격이 있다) 그리고 어디를 조사할지(작업이 지속적으로 자리 잡지 못하는 팀은 주제 1.1의 진단적 프레이밍에 따라 비난이 아니라 도움을 받을 자격이 있다) 결정하는 것이다. 성과 데이터에 기반해 개인이나 팀을 경쟁적으로 순위 매기는 것은 정확히 이 책이 경고하는 게임과 사기 저하를 초래하며 진단적 사용보다 더 나은 결과를 좀처럼 만들어 내지 못한다.

특히 플랫폼과 지원 팀에 대해 귀속 한계에 대해 정직해져라

공유 인프라, 내부 도구, 혹은 플랫폼 역량을 구축하는 팀(자매편인 software-engineering-guide 책의 플랫폼 엔지니어링 주제가 이를 직접 다룬다)은 흔히 결과에 대한 그들의 기여가 어떤 단일한 고객 대면 메트릭으로부터 여러 단계 떨어져 있다. 본질적으로 간접적인 작업에 맞지 않는 직접 결과 메트릭을 강제로 적용하는 대신, 그들이 가능하게 하는 팀에 대한 효과, 즉 그 플랫폼의 채택, 소비하는 팀이 보고하는 마찰 감소를 통해 이 팀들의 성과를 측정하라.

트레이드오프: 장단점

접근법	장점	단점
팀당 단일 성과 점수	제시하고 비교하기 단순함	거짓 정밀함; 어떤 근본 신호가 실제로 그 점수를 이끌었는지 숨김
여러 수렴하는 신호	더 신뢰할 수 있고, 단일 메트릭 게임에 저항함	하나의 수치로 요약하기 더 어려움; 해석하는 데 더 많은 맥락이 필요함
팀 수준 성과 측정	소프트웨어 결과가 실제로 나타나는 방식과 일치함	개인 기여에 대한 질문에 직접 답할 수 없음
개인 수준 성과 귀속	평가를 위해 더 직접적으로 실행 가능하게 느껴짐	보통 거짓 정밀함; 강한 게임과 공로 보호 위험

핵심 긴장은 정밀함 대 정직함이다. 팀당, 혹은 더 나쁘게는 개인당 단일 성과 수치는 비교하고 순위를 매기기 쉽지만, 그 정밀함은 보통 거짓이며 깔끔해 보이는 수치 뒤에 귀속과 품질에 대한 진짜 불확실성을 숨긴다. 덜 깔끔한 다중 신호 그림을 정직한 것으로 받아들이고, 그것을 다시 단일하고 거짓으로 정밀한 점수로 무너뜨리라는 리더십이나 성과 평가 절차로부터의 압박에 저항함으로써 이 긴장을 해결하라.

팀과 논의할 질문

우리의 현재 성과 측정은 여러 개의 수렴하는 신호를 결합하는가, 아니면 실제보다 더 정밀하게 느껴지는 단일 수치에 의존하는가? 당신이 현재 “성과 메트릭”이라고 부르는 것을 감사하고 실제로 얼마나 많은 독립적이고 수렴하는 신호가 그것으로 들어가는지 확인하라.
우리는 결과가 실제로 일어난 방식의 협업적이고 팀 간 본질을 고려하지 않은 채 팀이나 개인의 성과를 귀속시킨 적이 있는가? 최근의 성공 사례를 골라 그것이 공로를 인정받은 팀이나 개인 밖의 사람, 결정, 혹은 이전 작업에 얼마나 의존했는지 추적해 보라.
우리의 성과 측정은 품질을 포함하는가, 아니면 전달 속도와 산출물 물량만 포함하는가? 나중에 중대한 프로덕션 인시던트를 초래한 출시된 기능은 높은 성과로 점수를 받아서는 안 된다. 당신의 현재 측정이 실제로 이 사례를 잡아낼지 확인하라.
결과에 대한 기여가 간접적인 플랫폼이나 지원 팀의 성과를 우리는 어떻게 측정하는가? 정직한 답이 “글쎄, 우리는 하지 않는다”라면, 그 간극은 그 팀들을 사실상 측정하지 않거나 그들의 작업에 맞지 않는 고객 대면 결과 메트릭에 비추어 불공정하게 측정되게 두는 대신 직접 이름 붙이고 다룰 가치가 있다.
성과 데이터가 공식적으로든 비공식적으로든 개인을 경쟁적으로 순위 매기는 데 사용된 적이 있는가? 주제 3.2의 만족도 데이터 위험과 유사한 이 드리프트는 데이터의 정직함과 팀이 개방적으로 협업하려는 의지 둘 다를 손상시킨다.
우리의 수렴하는 신호가 서로 일치하지 않을 때, 예를 들어 높은 전달 속도지만 상승하는 결함률일 때, 우리는 무엇을 결론 내리며, 우리의 절차는 그 불일치를 잘 다루는가? 신호 간의 불일치는 그 자체로 가치 있는 정보다. 당신의 팀이 현재 그것을 무시할 잡음으로 취급하는지 조사할 가치가 있는 진정한 발견으로 취급하는지 논의하라.

분야별 관점

스타트업. 성과는 보통 직접 보인다: 기능이 작동했는가, 고객이 그것을 채택했는가, 메트릭이 움직였는가. 공식적인 다중 신호 측정은 이 규모에서 흔히 불필요하다. 위험은 대신 성공이나 실패를 공로나 비난이 좀처럼 단 한 명에게만 속하지 않는 빠르게 움직이고 매우 협업적인 소규모 팀에서 너무 빠르게 한 사람에게 귀속시키는 것이다.

중소기업. 유지할 역량이 없는 공식적인 다중 신호 계측을 구축하는 대신, 당신이 이미 가지고 있는 전달 및 품질 데이터(주제 2.10, 주제 5.1)를 최근 작업이 실제로 비즈니스에 도움이 되었는지에 대한 직접적이고 정직한 대화와 결합하라.

엔터프라이즈. 이곳이 팀 수준, 다중 신호 측정의 규율이 그 투자에 값하는 곳인데, 수십 개 팀에 걸쳐 성과를 비교 가능한 단일 수치로 줄이라는 압박이 여기서 가장 강하고, 거짓 정밀함으로부터의 피해가 조직 전체의 자원 배분 결정에 걸쳐 복합적으로 커지기 때문이다. 그 압박에 명시적으로 저항하고 왜 그것이 중요한지에 대한 다중 신호 사례를 구축하라.

정부. 엔지니어링 투자가 단지 전달된 산출물이 아니라 실제 결과를 만들어 냈다는 것을 입증하는 것은 흔히 감독 기구가 묻는 핵심 질문이다. 전달 전용 대리 지표가 아니라 명시적으로 결과 메트릭(주제 5.3)에 묶인 다중 신호 성과 측정은 활동이나 전달 개수 홀로보다 훨씬 더 강하고 더 방어 가능한 답을 준다.

사례

엔터프라이즈. 한 소매 기술 회사의 리더십은 스프린트당 완료된 스토리 포인트로 엔지니어링 팀을 비공식적으로 순위 매겨 왔으며, 이를 성과 대리 지표로 취급했다. 전달 데이터, 변경 실패율, 릴리스 후 기능 채택을 결합하는 다중 신호 접근법을 도입한 후, 리더십은 가장 높은 스토리 포인트 완료율을 가진 팀이 회사에서 가장 낮은 기능 채택률을 가지고 있다는 것을 발견했다: 그들은 빠르게 출시하고 있었지만 고객이 사용하지 않는 것을 만들고 있었다. 오도하는 단일 수치 순위 대신 더 완전한 성과 그림에 근거해 그 팀의 로드맵 우선순위를 재배분하는 것은 한 분기 안에 상당한 엔지니어링 역량을 더 높은 영향력의 작업으로 재조정했다.

정부. 한 국가 세무 기관의 엔지니어링 프로그램은 주요 시스템 투자가 단지 계약된 범위를 전달한 것이 아니라 성과를 개선했다는 것을 감독 위원회에 입증해야 했다. 스토리 포인트나 마일스톤 완료만 보고하는 대신, 그 프로그램은 수렴하는 신호 집합을 제시했다: 줄어든 처리 오류율, 줄어든 중앙값 처리 시간, 전달된 특정 시스템 구성 요소에 모두 연결된 증가된 성공적인 셀프 서비스 완료율. 다중 신호의 결과에 묶인 제시는 전년도 이전 프로그램의 단순한 “일정대로 전달됨” 보고서가 하지 못했던 방식으로 위원회의 정밀 조사를 만족시켰다.

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

거짓 정밀함을 가진 단일 수치가 아니라 수렴하고 결과에 묶인 신호를 통해 성과를 측정하는 것의 수익은 더 나은 자원 배분 결정이다: 어떤 팀의 작업이 진정으로 결과를 움직이는지 볼 수 있는 조직은 중요한 곳에 더 투자하고 그렇지 않은 곳을 조사할 수 있으며, 가장 바빠 보이는 팀을 보상하는 대신 그렇게 할 수 있다. 위의 소매 사례가 전형적이다: 오도하는 단일 수치 순위가 투자 관심을 실제로 도움이 되었을 곳으로부터 멀어지게 이끌고 있었다.

총 소유 비용은 단일 메트릭 접근법보다 더 높은데, 여러 출처(전달, 품질, 결과)로부터 데이터를 결합하고 그림을 다시 하나의 비교 가능한 수치로 무너뜨리라는 조직적 압박에 저항하는 것이 필요하기 때문이다. 그 비용은 치를 가치가 있는데, 대안, 즉 거짓으로 정밀한 단일 점수는 성과 데이터가 알려주도록 의도된 자원 배분 결정을 적극적으로 오도하기 때문이다.

안티패턴과 함정

활동을 성과와 혼동하기: 이 차원이 특별히 예방하도록 설계된 가장 흔한 오류.
협업적이고 팀 간의 결과에 대한 개인 성과 귀속: 보통 협업을 저해하는 거짓 정밀함.
성과의 정의에서 품질을 제외하기: 출시되지만 다른 무언가를 망가뜨리는 작업을 보상한다.
플랫폼이나 지원 팀에 직접 결과 메트릭을 강제로 적용하기: 본질적으로 간접적인 작업에 대해 잘못된 것을 측정한다.
조직적 압박 아래서 여러 수렴하는 신호를 다시 하나의 거짓으로 정밀한 수치로 무너뜨리기: 다중 신호 접근법이 제공하도록 만들어진 정직함을 잃는다.
성과 데이터를 사용해 개인을 경쟁적으로 순위 매기기: 데이터의 정직함과 팀의 협업 둘 다를 손상시킨다.

성숙도 모델

1단계, 시작: 성과가 활동이나 산출물 물량과 혼동되며, 검토되지 않은 단일 수치로 측정된다.
2단계, 개발: 일부 품질 신호가 산출물과 함께 고려되지만, 일관된 다중 신호 접근법이 없고 개인 귀속이 여전히 비공식적으로 일어난다.
3단계, 표준화: 성과는 조직 전체에서 일관되게 품질을 포함한 여러 수렴하는 신호를 사용해 팀 수준에서 측정된다.
4단계, 관리: 수렴하는 신호 간의 불일치가 능동적으로 조사되며, 플랫폼과 지원 팀은 그들의 실제 작업에 맞는 적절하게 간접적인 성과 측정치를 가지고 있다.
5단계, 조율: 성과 데이터가 자원 배분 및 투자 결정을 직접 알려주며, 조직은 다중 신호 관점이 가능하게 했고 단일 수치 관점이 놓쳤을 구체적인 재배분 결정을 제시할 수 있다.

논의를 위한 아이디어

우리가 현재 성과 대리 지표로 사용하고 있는, 수렴하는 집합을 위해 은퇴시켜야 할 단일 수치는 무엇인가?
귀속이 불명확했기 때문에 결과를 잘못된 팀이나 사람에게 공로로 돌린 적이 있는가?
우리는 현재 플랫폼이나 지원 팀의 성과를 어떻게 측정하는가?
다음 분기에 우리의 수렴하는 신호가 서로 일치하지 않는다면 어떻게 보일까?
스토리 포인트나 전달 개수 순위가 우리의 투자 관심을 어디서 잘못 이끌었는가?

핵심 요약

성과는 얼마나 많은 움직임이 일어났는지가 아니라 작업이 좋은 결과를 만들어 냈는지 측정한다. 그것을 활동(주제 3.4)과 혼동하지 마라.
여러 개의 수렴하는 신호를 사용하고, 결코 단일한 성과 수치를 사용하지 말며, 거짓 정밀함을 의심하라.
팀이나 시스템 수준에서 측정하라. 개인 결과 귀속은 보통 신뢰할 수 없으며 협업을 손상시킨다.
품질은 별개의 단절된 관심사가 아니라 성과의 일부다.
플랫폼과 지원 팀에게 그들의 작업에 맞지 않는 직접 결과 메트릭을 강제로 적용하는 대신 적절하게 간접적인 성과 측정치를 주어라.

참고 문헌 및 추가 자료

Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler. “The SPACE of Developer Productivity.” ACM Queue, 2021.
Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
Skelton, Matthew, and Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press, 2019.
Austin, Robert D. Measuring and Managing Performance in Organizations. Dorset House, 1996.