McKinsey 에 대한 반박과 그에 대한 분석— from Kent Beck

이 글은 Kent Beck 의 Measuring developer productivity? A response to McKinsey 1, 2 에 기반하여 작성되었습니다.

개발자 성과의 세가지 차원으로 소개 드렸던 McKinsey 의 아티클에 대해 당시 많은 갑론을박이 있었습니다.

이번 글에서는 해당 내용들 중 누구나 알 법한 사람의 의견들을 다뤄보려고 합니다.

Kent Beck — Measuring developer productivity? A response to McKinsey

바로 TDD를 해보려는, 그리고 해봤던 사람들은 한번씩 읽어봤을 “테스트 주도 개발" 의 저자 Kent Beck 입니다.

Kent Beck은 40년 이상의 소프트웨어 엔지니어링 경험을 보유하고 있으며 거의 ​​일생의 모든 시간 동안 개발자 생산성을 측정하기 위해 시도하고 실패하고 다시 시도하기를 반복했다고 합니다.

McKinsey 의 방법에 대하여 켄트 벡은 주로 컨설팅 업의 한계와 고질적인 문제가 있다고, 또한 그들은 비즈니스 관점에서 생산성이 아닌 활동만 측정한다고 말합니다.

컨설팅을 받은 회사(ex: Facebook)의 사례를 들었을 때, 이들은 McKinsey 가 제시한 가이드대로 설문을 진행했고, 처음 1년 동안은 McKinsey 가 보고한 것 과 같이 의미 있는 피드백을 받았다고 합니다. 하지만 이내 측정되는 점수를 높이는 것 자체가 목표가 되면서 팀에 “높은 점수로 책정하면 높은 평가를 주겠다” 라고 하며 평가담당자들이 팀 리드들과 협상하는 일이 생기고 맙니다.

평가담당자들은 회사의 목표에 대해 정렬 되어있지 않았고 그들의 성과 또한 해당 성과의 측정치를 높이는 것에 있었기 때문에 안타깝게도 자신들의 성과를 올리기 위해 어뷰징을 해버린 것 입니다.

개발자의 생산성은 측정할 수 없다?

그래서 Kent 는 말합니다. “Measure developer productivity? Not possible”

하지만 재밌게도 글에서는 동시에 생산성을 측정하는 방법에 대해 다룹니다. 이는 아예 불가능하진 않고 연관되지 않은, 단순히 컨트롤 타워에 앉아서 결과로 나온 정량적인 데이터만 가지고는 측정하는 것이 불가능하다는 것을 뜻합니다.

Kent 는 프루퍼 팀 또한 여러 회사와 컨택하며 느꼈던 포인트인, CTO가 “소프트웨어 엔지니어링은 측정하기에는 너무 미묘해서 할 수가 없다” 라고 말하는 것에 대해 CEO와 CFO는 점점 더 좌절하고 있는 점을 짚습니다.

영업 팀은 명확한 할당량과 성과 목표가 있으며, 채용 팀도 마찬가지로 직책 수를 기준으로 성과를 측정합니다. 경영진들은 엔지니어링 팀도 이와 같은 방식으로 성과를 측정할 수 있기를 기대합니다.

생산성 측정의 필요성은 다양한 이해관계자들로부터 비롯되는데, 특히 측정을 원하는 이유는 측정을 통해 얻고자 하는 목표에 따라 다릅니다.

최근 투자시장의 축소로 이어진 기술 업계의 일괄 해고사태(ex: layoff)로 인해 일부 CTO들은 가장 비생산적인 10%의 엔지니어를 식별하고 해고하기 위해 생산성을 측정해야 하는 입장에 처했습니다.

추가 인력을 할당할 팀을 결정하기 위해서는 팀의 생산성을 측정하고, 투자 대비 효율성을 평가하는 것이 필요합니다.

최상위 10%의 엔지니어를 식별해서 보상하기 위해, 그리고 하위 25%의 엔지니어를 식별하여 그들의 성과를 개선하기 위해서도 필요합니다.

또한 관리자 뿐만 아니라 자신을 더 나은 엔지니어로 성장시키기 위해 생산성을 측정하려는 엔지니어들에게도 개선하여 성장하기 위한 특정 지표가 필요합니다.

이런 목표들을 위해 직접적으로 관련된 동료 또는 자기 자신이 생산성을 측정하고 평가하는데 이것을 협업하고 있지 않는 관리자에게 보여주고 관리자가 성과를 평가한다면 과정과 결과가 아니라 결과만으로 평가될 것 이라고 합니다. 예를 들어 도움이 필요한 팀을 돕기 위해 새로운 언어를 배우는 등 접근 방식을 실험할 때 팀이 더 나은 결과를 달성하도록 돕고 있더라도 결과가 떨어질 수 있는 점을 짚습니다.

Kent 는 지금의 엔지니어링 직군의 매니징이 일반적으로 예상치 못한 어려움, 기술 부채, API와 같은 요소가 포함된 개인에 대한 케어를 전혀 해주고 있지 않아 이것을 행하고 있는 다른 부서보다 엔지니어링 부서에 대해 ​​생산성을 개인 수준까지 측정하는 데에 지금보다 더 많은 노력을 기울여야 한다고 말합니다.

그래서 McKinsey 에 대해 Kent 가 잘못되었다고 꼬집은 점은 무엇이었을까요?

성과의 기준은 비즈니스와 연동되어있어야 한다

첫째로 지표를 보는 대상이 제한적입니다. 주로 이를 수집하고 평가하는 평가담당 직원만을 그럴듯하게 만족 시키는 지표라고 합니다.

고객은 이러한 지표들을 중요하게 생각하지 않습니다. 고객이 기대하는 것은 제품이나 서비스의 품질, 기능, 사용자 경험 등입니다.

경영진 또한 이러한 세부 지표보다는 회사의 전체적인 성과, 전략적 목표, 수익성 등에 더 관심이 많습니다.

투자자 역시 개별 활동 지표보다는 투자 대비 수익, 시장 점유율, 성장 가능성 등과 같은 보다 거시적인 지표에 관심을 갖습니다.

둘째로는 지표를 수집하고 평가하는데 드는 시간과 과정이 실제로 중요한 목표를 달성하는 데 방해가 될 수 있습니다.

팀은 지표를 맞추기 위해 불필요한 활동에 시간을 할애하게 되며, 이는 실제 중요한 프로젝트나 업무의 효율성을 저하시킬 수 있습니다.

지표를 맞추는 것이 목표가 되어 버리면, 본래의 중요한 목표인 수익성, 고객 만족, 제품 품질 등에서 벗어나게 될 위험이 있습니다.

팀원들이 지표 달성을 위해 일하게 되면, 본래의 업무에 대한 동기부여가 떨어지고, 이는 전체적인 팀 사기에도 부정적인 영향을 미칠 수 있다고 합니다.

결국 McKinsey 접근 방식의 문제는 지표가 실제로 중요한 목표와는 동떨어져 있으며, 지표 수집과 평가 과정이 팀의 본래 목표 달성을 방해한다는 점을 꼬집습니다. 이를 해결하기 위해서는 고객, 경영진, 투자자들이 실제로 중요하게 여기는 목표를 중심으로 지표를 재정립하고, 그에 맞는 측정 방식을 도입해야 한다고 말합니다.

정리하자면 측정하는 지표들은 기본적으로 비즈니스에 대한 긍정적인 방향으로 연결이 되어있어야 한다고 할 수 있습니다.

필요한 것은 “개발을 잘한다” 에 대한 노력 및 결과에 대한 지표가 아닌 “비즈니스에 어떤 영향을 준다” 에 대한 세부적인 기여와 영향력에 대한 지표인 것입니다. 만약 직접적인 영향이 미미한 역할이라면 간접적으로 어떤 영향을 주어 비즈니스가 성공할 수 있도록 기여하는지에 대한 평가가 이루어져야 합니다.

개인의 성과는 팀의 성과와 연동되어 있어야 한다

또한 Kent 는 개발조직은 스포츠팀과 비슷하고, 개인의 성과도 중요하지만 팀워크로 개인의 역량을 커버할 수 있는 점이 특히 그렇다고 합니다. 하지만 역시나 개인의 성과를 측정하려는 시도는 여러 스포츠에도 존재합니다.

특히 아이스하키를 예로 듭니다. 이들은 선수의 골 차이를 측정하는 “플러스-마이너스” 라는 통계를 사용합니다. 이 통계는 해당 선수가 빙판 위에 있을 때 팀이 얼마나 더 많은 골을 득점하고 얼마나 적은 골을 허용하는지를 측정합니다. 이는 일종의 “팀 성공에 대한 기여” 지표이며, 팀을 훨씬 더 효율적으로 만드는 플레이어를 식별하는 데 유용합니다.

그러나 스포츠 게임과 소프트웨어 엔지니어링 프로젝트는 매우 다릅니다. 스포츠는 매주 경기를 치르며 엄격한 시간 제한이 있습니다. 승리의 조건은 매우 명확합니다. 대조적으로, 소프트웨어 프로젝트는 훨씬 더 오래 지속되는 경향이 있고 시간 제한이 없으며 간단한 채점 시스템이 없습니다.

때문에 이를 위한 지표설계의 난이도는 굉장히 높으며 많은 조직에서 쉽사리 성공하지 못하고 포기해버리고는 합니다. Kent 또한 개인보다는 팀 성과를 측정하는 것이 쉽다고 말합니다.

하지만 여기서 개인의 성과에 대한 측정은 곧 “팀의 성공에 대한 기여도” 임을 발견합니다.

적용

이제는 Kent 가 제안한 내용을 바탕으로 실제 상황을 들어 가상으로 성과 측정의 기준을 생각해보겠습니다.

팀이 비즈니스에서 어떤 역할을 수행하는지에 대해 먼저 고민해보고, 어느정도의 영향을 가지는지를 분석하였습니다.

비즈니스와 연동된 대표적인 개발조직인 서비스팀 예시 하나와, 비즈니스와 연동 되어있지 않은 어려운 조직 예시들을 들어보았습니다.

서비스 개발팀의 성과

가장 대표적인 개발 조직입니다. 비즈니스와 굉장히 밀접한 업무를 수행하며 이들의 역량에 따라 서비스의 공급과 퀄리티가 달라질 수 있습니다. 서비스는 곧 비즈니스와 직접적으로 연결됩니다.

따라서 이들의 성과로는 주로 서비스의 제공에 대한 내용을 다룹니다.

• 새로운 기능이나 업데이트를 릴리즈하는 빈도를 측정합니다. 이는 팀의 생산성과 릴리즈 주기의 효율성을 나타냅니다.
• 릴리즈 후 발생한 버그의 수와 심각도를 평가합니다. 이는 배포의 품질과 안정성을 반영합니다.
• 서비스의 평균 응답 시간을 측정합니다. 이는 사용자 경험에 직접적인 영향을 미치는 중요한 지표입니다.
• 서비스의 가동 시간과 장애 발생률을 측정합니다. 높은 가동 시간은 시스템의 안정성과 신뢰성을 나타냅니다.

또한 직접적으로 서비스와 맞닿아 있어 서비스를 제공받는 고객에 대한 지표도 빼놓을 수 없습니다.

• 사용자 피드백을 기반으로 서비스의 품질과 기능에 대한 만족도를 평가합니다. NPS(Net Promoter Score) 또는 CSAT(Customer Satisfaction Score)와 같은 지표를 사용할 수 있습니다.
• 사용자 피드백을 수집하고 이를 실제로 반영한 기능 개선 사항의 수를 평가합니다.

뿐만 아니라 비즈니스는 곧 매출이므로 비즈니스 지표와 연동 지어볼 수도 있습니다.

• 새로운 기능이나 서비스 개선이 매출 증가에 미친 영향을 평가합니다. 이는 서비스 개발의 비즈니스 기여도를 직접적으로 나타냅니다.
• 기능 개선이나 신규 서비스 도입 후 사용자 유지율의 변화를 측정합니다. 이는 사용자가 서비스에 만족하고 지속적으로 이용하는지를 평가합니다.

이외에도 팀 내 협업에 대한 능력, 커뮤니케이션, 성장정도에 대해서도 평가해볼 수 있습니다.

보안팀의 성과

조직의 보안팀이라고 한다면 보안 활동이 비즈니스 목표와 어떻게 연계되는지를 먼저 정의해야 합니다. 고객 데이터 보호, 규제 준수에 대한 내용이 될 수 있습니다. 그리고 보안에 투자한 자원이 실제로 비즈니스에 어떤 긍정적인 영향을 미쳤는지를 분석합니다.

그 예시로 아래와 같은 항목들을 생각해봅니다.

• 취약점 발견 및 해결 활동에 대해 측정해볼 수 있습니다. 보안팀의 주요 목표는 시스템의 안전성을 유지하는 것입니다. 따라서 발견된 취약점의 수와 이를 해결한 비율을 측정합니다. 이는 팀의 적극적인 보안 활동과 문제 해결 능력을 반영합니다.
• 문제 발생 시 대응 시간을 측정합니다. 빠르고 효율적인 대응은 팀의 준비성과 능력을 나타냅니다.

하지만 보안팀은 문제가 생기지 않으면 오히려 좋은 신호이기 때문에 문제 발생시 대처만으로 평가하는 것은 옳지 않습니다. 따라서 평소의 적극적인 보안 활동도 평가합니다.

• 정기적인 보안 점검과 모니터링 활동을 평가합니다.
• 정기적인 침투 테스트에서 발견된 문제와 이를 해결한 비율을 평가합니다. 이는 팀의 보안 강화 노력을 반영합니다.
• 외부 및 내부 보안 감사를 정기적으로 실시하고, 감사 결과를 기반으로 한 개선 활동의 성공률을 평가합니다.
• 팀이 제공한 보안 교육 세션 수, 참여도, 교육 후 보안 인식 향상 평가 등을 측정합니다.
• CI/CD 파이프라인에 자동화된 보안 테스트를 도입하고, 그로 인해 발견된 문제를 미리 해결한 비율을 평가합니다.

이렇듯 비즈니스와 직접적이지 않은 보안팀에 대해서는 고객 데이터 보호와 규제 준수 활동으로 비즈니스에 기여하는 점을 먼저 찾고, 그에 대한 성과를 측정하는 방식을 취했습니다.

사내 툴 개발팀의 성과

사내 툴 개발팀은 조직 내 다른 팀들이 효율적으로 업무를 수행할 수 있도록 지원하는 도구와 시스템을 개발하는 팀입니다. 비즈니스와 직접적인 연관은 굉장히 적지만, 이들의 업무는 전체 조직의 생산성과 효율성을 높이는 데 중요한 역할을 합니다. 따라서 이들의 성과를 측정하기 위해 다음과 같은 지표를 사용할 수 있습니다.

• 새로운 기능이나 업데이트를 릴리즈하는 빈도를 측정합니다. 이는 팀의 생산성과 릴리즈 주기의 효율성을 나타냅니다.
• 릴리즈 후 발견된 버그의 수와 심각도를 평가합니다. 이는 배포의 품질과 안정성을 반영합니다.
• 개발된 툴의 평균 응답 시간을 측정합니다. 이는 내부 사용자 경험에 직접적인 영향을 미치는 중요한 지표입니다.
• 툴의 가동 시간과 장애 발생률을 측정합니다. 높은 가동 시간은 시스템의 안정성과 신뢰성을 나타냅니다.

또한 사내 툴 개발팀의 성과는 서비스팀과 비슷하게 내부 사용자와의 상호작용 및 만족도 지표로 평가할 수 있습니다.

• 사내 사용자 피드백을 기반으로 툴의 품질과 기능에 대한 만족도를 평가합니다. 역시 NPS와 CSAT 같은 지표를 사용할 수 있습니다.
• 사내 사용자 피드백을 수집하고 이를 실제로 반영한 기능 개선 사항의 수를 평가합니다.

사내 툴 개발팀은 직접적으로 매출을 창출하지 않지만, 비즈니스 목표와의 연계를 통해 성과를 측정할 수 있습니다.

• 툴을 사용한 팀들의 업무 효율성 향상을 평가합니다. 예를 들어, 툴 도입 후 작업 완료 시간이 얼마나 단축되었는지를 측정합니다.
• 툴 도입으로 인한 운영 비용 절감 효과를 평가합니다. 이는 툴의 도입으로 불필요한 비용이 얼마나 줄어들었는지를 나타냅니다.

이렇듯 사내 툴 개발팀의 성과는 비즈니스와 직접적이지 않더라도, 내부 사용자 만족도와 시스템 효율성, 비즈니스 목표와의 연계를 통해 측정해볼 수 있습니다.

DevOps팀의 성과

DevOps 팀은 개발과 운영의 효율성을 높이고, 소프트웨어 릴리즈 과정을 자동화하며, 시스템의 안정성과 확장성을 유지하는 역할을 합니다. DevOps 팀의 성과는 비즈니스와 직접적인 연관은 적지만, 전체 개발 및 운영 프로세스의 효율성을 높이는 데 중요한 역할을 합니다. 따라서 이들의 성과를 측정하기 위해 다음과 같은 지표를 사용할 수 있습니다.

• 코드 변경이 실제 배포로 이어지는 데 걸리는 시간을 측정합니다. 이는 DevOps 팀이 기여하는 타 개발팀의 효율성과 자동화 수준을 나타냅니다.
• 릴리즈 후 발생한 배포 실패의 수와 그 심각도를 평가합니다. 이는 DevOps 팀이 만드는 배포 프로세스의 품질과 안정성을 반영합니다.
• 시스템의 평균 응답 시간을 측정합니다. 이는 DevOps 팀이 사용자 경험에 직접적인 영향을 미치는 중요한 지표입니다.
• 시스템의 가동 시간과 장애 발생률을 측정합니다. 높은 가동 시간은 시스템의 안정성과 신뢰성을 나타냅니다.

뿐만아니라 DevOps 팀의 성과는 내부 사용자와의 상호작용 및 만족도 지표로 평가할 수 있습니다.

• 사내 사용자 피드백을 기반으로 DevOps 도구와 프로세스의 품질과 기능에 대한 만족도를 평가합니다. 역시 NPS 또는 CSAT 와 같은 지표를 사용할 수 있습니다.
• 사내 사용자 피드백을 수집하고 이를 실제로 반영한 개선 사항의 수를 평가합니다.

DevOps 팀은 직접적으로 매출을 창출하지 않지만, 비즈니스 목표와의 연계를 통해 성과를 측정할 수 있습니다.

• DevOps 도구와 프로세스를 사용한 팀들의 업무 효율성 향상을 평가합니다. 예를 들어, DevOps 도입 후 작업 완료 시간이 얼마나 단축되었는지를 측정합니다.
• DevOps 도입으로 인한 운영 비용 절감 효과를 평가합니다. 이는 DevOps 도입으로 불필요한 비용이 얼마나 줄어들었는지를 나타냅니다.

이렇듯 DevOps 팀의 성과는 비즈니스와 직접적이지 않더라도, 내부 사용자 만족도와 시스템 효율성, 비즈니스 목표와의 연계를 통해 측정할 수 있습니다.

정리

어쩌면 Kent 의 반박이 진짜 “개발자 생산성은 측정할 수 없다” 라고 말하는 것일 수도 있습니다. 하지만 이 정도의 위치에 있는 사람이 그렇게 무책임할 것이라고 생각하지 않았고 반증하듯 글에서도 측정 방법에 대해 서술되어있습니다. 이는 단순히 “측정할 수 없다”는 의미보다는, 그 과정이 매우 복잡하고 어려움을 수반한다는 것을 강하게 이야기 하는 것으로 해석하였습니다.

따라서 Kent 의 주장은 개발자 생산성을 측정할 수 없다는 것보다는,

• 측정을 매우 신중하게 접근해야 하고
• 측정 그 자체가 목적이 되어서는 안 된다

는 경고로 이해할 수 있습니다. 그리고 무엇보다 중요한 것으로

• 성과를 평가하는 주체는 뽑아낸 데이터만 보고 평가 하는게 아닌 데이터로부터 인사이트를 얻을 수 있는 실제 업무와 가까운 사람이어야 한다

를 말합니다. 이는 무분별한 측정이 오히려 조직의 목표와 성과에 부정적인 영향을 미칠 수 있다는 것이라고 볼 수 있습니다.

또한 Kent는 후속글 Productivity Measurement as a Tradeoff 에서 다음과 같이 이야기합니다.

제가 함께 일했던 임원들 중 최고의 임원들도 데이터를 사용했습니다. 하지만 그들은 항상 업무와 직접적으로 연관되어 있었습니다. 그들은 정기적으로 대화를 나누는 다양한 실무자가 있었습니다.

마지막으로 Kent가 강조한 내용을 조금 더 이해하기 쉽게 각색한 항목들과 함께 마무리하겠습니다.

• 측정자와 대상자의 관계를 고려하세요. 견제되지 않는 성과평가는 반드시 부작용이 발생하게 됩니다.
• 자기계발을 위한 자기측정은 훌륭합니다!
• 충분히 가공되지 않은 데이터를 바로 인센티브(금전, 지위, 승진, 자율성 등)에 연동하지 마세요. 정작 데이터도 의미 없을뿐더러 다시는 정확한 데이터를 받을 수 없을 것입니다.
• ‘데이터’ 에만 의존하는 경영진은 책임을 회피하는 것처럼 보입니다. 데이터를 참고하여 스스로의 결론을 내리십시오.
• 성과 측정에 대한 논의에서, 가장 효과적인 방법은 고객이 가치를 인정하는 것을 제공하는 것입니다. 이는 조직의 목표와 가장 잘 맞고, 평가 과정에서 발생할 수 있는 왜곡이나 부작용이 적습니다.

다음으로는 또 다른 반박인 Dan North 의 McKinsey Developer Productivity Review 에 대해 다뤄보겠습니다.

McKinsey 에 대한 반박과 그에 대한 분석— from Kent Beck was originally published in 프루퍼 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.