개발자 생산성을 '제대로' 측정하는 법

등록일: 01.22.2021 16:09:43  |  조회수: 81
개발팀에 지라 소프트웨어(Jira Software), 애저 데브옵스(Azure DevOps) 또는 사용 중인 다른 애자일 관리 툴에서 시간을 캡처하도록 지시한다는 말을 들을 때마다 필자는 깜짝깜짝 놀라곤 한다. 

시간 확인은 계약에 따라 고객에 비용을 청구하는 서비스 부서에는 정상적인 일이고 필요한 부분도 있다. 그러나 이런 회계적 지표를 이용해 개발 생산성을 정량화하는 것은 낡은 지휘 통제식 관리 관행에서 이어진 좋지 않은 관습이다.

개발 생산성을 정량화하는 데 사용되는 지표 중 문제가 있는 것은 또 있다. 완성한 코드 라인 수로 생산성을 산출하는 방식이다. 기업 인프라를 지저분한 코드 베이스의 '기술적 부채' 속에 파묻도록 사실상 개발팀을 독려하는 방법이다. 제공된 사용자 스토리 또는 스토리 포인트의 수로 측정하는 것은 어떨까? 개발자에게 기능을 더 많은 스토리로 쪼개 스토리 포인트 추정을 부풀리라고 지시하는 것과 다르지 않다.

완료된 릴리스의 수를 파악하는 방법은 그나마 낫지만 이 역시 부가적인 확인이 필요하다. 결함이 포함되거나 중대한 사고를 유발하거나 최종 사용자 경험의 질이 떨어지는 프로덕션 릴리스는 성공적인 릴리스와는 다르게 평가돼야 하기 때문이다.

이처럼 소프트웨어 개발 생산성을 측정하는 데는 많은 어려움이 있다. 필자는 이런 업무의 전문가인 맥밀란 러닝(Macmillan Learning)의 부사장 사가르부지발과 이야기한 적이 있는데, 그는 잘못된 평가 기준은 팀 사기를 저하할 수 있다며 다음과 같이 경고했다.

"오류, 전달 지연 또는 사고의 수에 따라 개발자 생산성을 측정해서는 안 된다. 이 경우 더 많은 기능을 더 빨리, 더 효과적으로 제공해야 한다는 압박에 항상 시달리는 개발팀에 불필요한 불안을 야기한다. 대신 심리적 안정감을 주고 운영 프레임워크를 지속해서 정렬하고 엔지니어링 방식을 개선해야 한다"

여기서는 소프트웨어 개발자와 개발팀에 합리적인 생산성 지표를 적용해 이들의 (발목을 잡는 것이 아닌) 생산성과 사기를 높이고 비즈니스 성과까지 개선하는 방법을 알아본다.
 
개발 생산성 평가 기준으로 성과를 평가하지 말 것
결론적으로 필자는 개발 및 데브옵스 KPI와 메트릭으로 프로세스와 품질, 생산성의 개선을 촉구하는 방식을 강력히 지지한다. 가장 우려하는 것은 기업이 생산성 지표를 팀 또는 개별 성과 목표와 동일시하는 것이다. 적절한 맥락 없이 생산성을 성과와 동일시하면 다음과 같은 바람직하지 않은 행동으로 이어질 가능성이 크다.
 
비즈니스 영향이 거의 없는 기능을 더 많이 개발
위험, 보안, 품질, 운영 영향을 고려하지 않고 더 많은 소프트웨어 릴리스
성공적인 실험을 위한 실질적인 프로덕션 경로가 없는 혁신

대신 필자는 인사팀과 대화하거나 소프트웨어 개발 그룹의 전체적인 성과에 대해 논의할 때마다 생산성 이상의 더 넓은 지표를 안내하기 위해 노력한다.
 
개발 생산성 지표를 사용해 비즈니스 돕기
그렇다면 소프트웨어 개발팀의 어느 부분에 생산성 지표를 적용하면 비즈니스 성과를 개선할 수 있을까? 구체적으로, 생산성 개선은 기업이 수익을 늘리고 최종 사용자 경험을 개선하고 품질을 높이고 비용을 낮추고 혁신을 실현하는 데 도움이 돼야 한다. 또한, 전략적 역량을 제공하고 협업을 개선하고 효율성을 유도하고 정보 접근을 간소화하거나 위험을 낮추는 것도 중요하다.

소프트웨어 개발(그리고 IT 전반)은 이와 같은 비즈니스 성과의 기여자인 경우가 많다. 또한 성과 기반 KPI는 소프트웨어 개발 및 IT 메트릭을 위한 맥락을 제시해야 한다. 이러한 KPI의 운영 측면은 팀이 명시된 가치와 표준을 얼마나 효과적으로 제공했는지에 관한 메트릭이어야 한다. 이와 같은 메트릭에 대한 연구 성과가 계속 쌓이고 있는데, 몇 가지 예를 들면 다음과 같다.
 
현재 중요한 소프트웨어 개발 메트릭에는 사이클 시간, 팀 속도와 같은 애자일 메트릭과 평균 복구 시간(mean time to repair)과 같은 프로덕션 메트릭이 포함된다.
일부 참신한 생산성 메트릭은 생산성, 품질, 협업을 포착하는 완료된 코드 리뷰, 작성된 문서, 다른 사람과의 대화와 같은 행동에 초점을 둔다.
소프트웨어 설계, 테스트, 통합과 같은 부가가치 활동을 환경 구성, 구성 문제 처리, 기존 코드가 어떻게 작동하는지 파악하기 위한 새 코드 작성과 같은 비부가가치 활동과 비교한다.

이러한 생산성 지표를 고려할 때는 현재 성과 평가 기준 대비 델타를 평가하는 것이 좋다. 팀 속도와 사이클 시간을 개선하거나 결함 탈출 비율, 평균 복구 시간이 단축된다면 팀 생산성이 개선될 가능성이 높다.
 
개발 생산성 지표를 사용한 생산성 개선
생산성을 측정하는 목표 중 하나는 생산성 개선을 이끄는 투자를 최적화하는 것이다. 소프트웨어 개발팀이 중요한 비즈니스 문제를 해결하는 데 더 많은 시간과 에너지를 집중할 수 있게 해주는 투자가 여기에 해당한다. 몇 가지 예를 들면 다음과 같다.
 
수동 배포 대신 CI/CD로 배포 자동화
코드형 인프라(IaC)와 컨테이너로 환경을 표준화해 수동 구성을 최소화하고 

시스템의 차이에 따라 발생하는 결함 감소
회귀 테스트를 자동화해 개발자가 개발 과정 중 버그를 수정하고 프로덕션에서 발견된 결함을 조사 및 수정하는 데 소비하는 시간을 줄일 수 있도록 함

맥밀란 러닝의 부지발은 생산성에 영향을 미치는 팀 행동 및 툴의 중요함에 대해 “비즈니스 부서와의 낮은 마찰, 매끄러운 협업, 툴 최적화와 같은 무형적 지표가 궁극적으로 바람직하고 시의적절한 성과를 달성하는 데 도움이 된다”라고 말했다.
 
생산성 메트릭의 초점을 비즈니스 성과에 맞춰야 함
서던 컴퍼니 서비스(Southern Company Services)의 CIO인 마틴 데이비스 역시 비즈니스 가치와 성과에 대한 초점을 다음과 같이 말했다.

"IT에서 비즈니스 지표를 사용한 생산성 측정이 늘수록 경영진이 그 가치를 이해하기 쉬워진다. 나는 항상 추가된 기능 또는 해결된 비즈니스 문제 측면에서 개발 생산성을 측정하고, 이상적으로는 추가된 가치를 금액으로 환산하기 위해 노력한다. 이렇게 하면 비용으로써 IT에서 가치 제공자로써 IT로 대화의 방향을 전환할 수 있다”

제트블루(JetBlue)의 IT, 기술, 통합 부문 VP인 람키 라마스와미역시 개발 생산성은 전달된 가치로 측정돼야 한다는 데 동의했다. 

더불어 위험 제거도 언급했다. 그는 "개발 생산성은 일반적으로 시간, 결함 또는 금액으로 산출된다. 그러나 아무것도 하지 않을 때의 위험(보안, 기회) 대비 소비한 비용당 가치(수익, 기회, 운영 비용 절감)로 측정하는 것이 더 이상적이다”라고 말했다.

라마스와미와 데이비스의 지적은 필자가 가장 중요한 애자일 KPI로 꼽는 것이기도 하다. 궁극적으로, 팀은 먼저 비즈니스 성과를 측정한 다음 목표로 한 행동을 나타내는 평가 기준으로 이를 정성화해야 한다. 

성과와 전달 정성화를 결합한 KPI는 누가, 무엇이, 왜, 어떻게 높은 품질의 소프트웨어를 전달하는지에 대한 답을 찾는 데 도움이 된다. 이런저런 저수준 지표에 집중하는 것보다 이와 같은 KPI에서 훨씬 더 큰 의미를 얻을 수 있다.

일단 이와 같은 KPI가 정의되면 기술과 프로세스 개선에서 소프트웨어 개발자와 기업, 모두에 대한 풍부한 인사이트를 확보할 수 있다. 예를 들면 다음과 같다.
 
-비즈니스 성과로 고객 만족 메트릭 개선을 요청한 개발팀은 평균 복구 시간 문제와 결함 탈출률을 개선하는 데 초점을 맞출 수 있다.

-개발팀은 이러한 메트릭에서 개선을 입증하면서 자동화, 문서 작성 또는 기술 부채 감소 등 생산성 개선에 투자하는 부분을 명시해야 한다.

-개발팀은 개선을 전달하면서 고객 만족도를 측정하고 선택한 메트릭에 대해 보고해야 한다.

비즈니스 성과와 개발자 생산성 메트릭을 결합한 KPI는 '팀이 생산성을 개선하면서 우선순위가 높은 비즈니스 성과를 제공하고 있는가'라는 질문에 답하는 데 도움이 된다. 

기업은 팀이 모든 부분을 동시에 개선할 수 없음을 고려해 생산성을 개선하면서 성과를 제공하는 현명한 의사 결정을 내리는 팀을 높이 평가해야 한다.

<출처 : CIO KOREA>



이민법

사람찾기

상법 · 소송