McKinsey 에 대한 반박과 그에 대한 분석 — from Daniel Terhorst-North
DAN NORTH & ASSOCIATES LIMITED. 이곳의 저자는 Daniel Terhorst-North, 줄여서 DAN NORTH 라는 닉네임을 쓰는데, 애자일의 시작부터 함께하며 커리어를 쌓아온 코치 및 컨설턴트입니다.
이 글은 그런 Dan North 의 McKinsey Developer Productivity Review 에 기반하여 작성되었습니다.
반박
Dan North 는 McKinsey 의 보고서에 대해 소프트웨어 개발이 단순히 정량적인 지표로 측정될 수 없는 복잡한 작업임을 강조합니다.
“단순한 지표는 잘못된 동기 부여를 초래할 수 있다”며, 정량적인 지표가 개발자들에게 부적절한 인센티브를 제공할 위험성을 경고합니다. 그는 이 지표가 개발자들이 실제 중요한 작업보다 지표를 충족시키기 위해 행동하게 만들 수 있다고 설명합니다.
또한 “소프트웨어 개발은 협력적이고 생성적인 작업이며, 팀의 효율성을 측정하는 것이 중요하다”고 하는데요. 때문에 Dan은 “개별 기여만 측정하는 방식으로 접근해서는 안 된다”, “개인을 평가하는 것은 엔진의 피스톤의 성과를 측정하는 것이나 마찬가지다” 라며, 기여 분석이 잘못된 접근 방식임을 지적합니다. 더하여 이러한 방식은 개발자 개개인의 복잡한 역할을 간과하고, 팀 전체의 성과를 평가하는 데 실패할 수 있다고 합니다.
특히 McKinsey 가 내부 루프와 외부 루프로 나누어 단순하게 코드를 작성하는 것에 관련된 것 만을 내부 루프에 포함시킨 것에 대해 단순히 코드를 작성하는 것이 아니라, 문제를 이해하고 해결하는 과정임을 강조합니다. “프로그래밍의 대부분은 문제를 이해하고 가능한 해결책을 평가하는 것”이라며, 이러한 과정을 무시한 성과 측정은 개발자의 실제 가치를 반영하지 못한다고 지적합니다.
제안
가장 중요한 것은 프로젝트의 특성과 개발 환경을 고려한 컨텍스트 기반의 평가를 실시해야 하는 것입니다. 모든 프로젝트가 동일한 기준으로 평가될 수 없기 때문에, 각 프로젝트의 고유한 요구사항과 도전 과제를 반영한 평가 지표를 설정되었을 때 만이 프로젝트의 특수성을 반영한 성과 평가가 이루어질 수 있습니다.
또한 기존의 정량적인 지표에 코드 리뷰의 질, 테스트 커버리지, 버그 수정 시간 등 질적 지표를 도입하여 코드의 질을 평가하자고 제안합니다. 이러한 지표들은 코드의 기능적 완성도와 유지보수성을 더 잘 반영할 수 있으며, 개발자의 실제 기술적 역량을 평가하는 데 도움이 된다고 합니다.
코드리뷰도 빼놓을 수 없습니다. 정기적인 코드 리뷰와 피드백 세션을 통해 개발자들이 지속적으로 성장할 수 있는 환경을 제공합니다. 이를 통해 개발자들이 단순한 지표 충족을 넘어서 실제로 중요한 기술적 성장과 협업 능력을 강화할 수 있다고 합니다.
개발자가 코드 작성 외에도 문제를 이해하고 해결하는 과정에 집중할 수 있도록 평가합니다. 문제 해결 능력, 비즈니스 도메인 이해, 다양한 기술적 솔루션 평가 능력 등을 평가하여 개발자의 실제 기여도를 반영합니다.
마지막으로 Dan은 소프트웨어 개발이 본질적으로 협력적이고 협업을 필요로 하는 작업이기 때문에 개발자 개개인의 성과보다는 팀의 목표 달성도, 프로젝트 완료 시간, 고객 만족도 등을 평가하여 팀 단위의 협력과 성과를 평가하는 것이 더 효과적이라고 합니다.
이렇게 Dan North 의 반박과 제안까지 살펴보았습니다. 개발자의 생산성, 그리고 성과에 대한 평가 방법 논의는 현재 진행중입니다.
Measurable Developer 뉴스레터를 구독하고 이 논의의 흐름에 올라타보세요!
