개발자도 사람이다. (with Measuring Developer Productivity via Humans)

이 글은 Measuring Developer Productivity via Humans 내용을 토대로 작성되었습니다.

데이터 기반으로 성과를 평가한다는 것

와인 750mL 1병에는 약 1.27kg의 포도가 소요됩니다. 데이터 기반으로 의사결정에 의미 있는 지표를 추출해내기 위해 업무에 사용되는 툴들에게서 방대한 데이터를 수집하는 과정은 마치 한 병의 좋은 술을 얻기 위해 포도 1.27kg 를 쏟아 넣는 것과 비교해볼 수 있습니다.

데이터 기반으로 성과를 측정하여 평가하고 개선하는 방식은 무수히 많은 이점들을 조직에 제공합니다.

• 단순하게 그동안 CTO의 경험적 판단을 본인과 평가 당사자 또는 인사 담당자들에게 전달할 때 확실하게 하는 근거자료, 백데이터가 되어 줍니다.
• 주관성을 최소화하여 실제 성과에 대한 객관적이고 정확한 평가를 가능하게 합니다. 이는 CTO의 경험적 판단에 의존할 때 발생할 수 있는 편향이나 가정을 제거해줍니다.
• 또한 같은 페르소나(ex. Product Engineer, DevOps Engineer)를 가지고 있는 대상에게 반복 적용이 가능한 효율적인 기술 솔루션을 구축 할 수 있으며, 이로써 조직을 다양한 부문이나 더 큰 규모로 확장하는 것이 용이합니다.
• 실시간으로 피드백을 받고 빠르게 문제를 식별하여 해결할 수 있습니다.
• 뿐만 아니라 CTO의 경험만으로는 놓칠 수 있는 미묘한 패턴이나 경향성까지 발견할 수 있는 기회를 얻습니다.
• 리소스를 보다 전략적으로 할당하는 데 도움이 됩니다. 특히 파악된 인력, 시간, 예산 등의 리소스를 필요한 곳에 우선적으로 배분하여 최대의 효과를 낼 수 있습니다.
• 조직 내부적으로 데이터를 공유한다면 투명성을 높이고, 개인과 팀의 책임성을 강화할 수 있습니다. 이는 모든 구성원이 명확한 목표를 가지고 일하도록 동기를 부여합니다.

하지만 데이터기반의 평가를 도입하는 것은 본업인 비즈니스를 진행하는 데에도 시간이 모자란 조직들에게 있어 굉장히 어려운 과제입니다.

다행히도 이전과 다르게 지금은 전세계적으로 보았을 때 시장에는 다양한 데이터 분석 툴과 소프트웨어가 개발되어, 조직들이 복잡한 데이터를 쉽게 수집하고 분석할 수 있도록 지원하고 있습니다.

또한, 인공지능(AI)과 머신러닝(ML) 기술의 발전은 성과 평가 방법을 한층 더 진화 시키고 있습니다. 이 기술들은 대량의 데이터에서 유의미한 패턴과 인사이트를 도출해내어, 예측 분석과 행동 추천으로 이어질 수 있습니다. 이를 통해 조직들은 미래의 성과를 예측하고, 전략적 결정을 내리는 데 필요한 지원을 받을 수 있습니다.

이러한 도구와 기술들은 조직이 데이터에 기반한 성과 관리의 복잡성을 줄이고, 자원을 효율적으로 활용하여 경쟁력을 강화할 수 있도록 도울 수 있습니다.

그러므로 이제는 비즈니스의 진행에 있어 시간이 부족하다고 느끼는 조직들도 측정 솔루션을 통해 데이터 기반의 성과 평가 접근법을 손쉽게 도입할 수 있는 기회를 가질 수 있게 되었습니다.

측정방식의 한계점

하지만 이것 만으로 기존의 평가를 완벽하게 대체해버릴 수는 없었습니다. 충분히 감격할만한 발전이지만 그 덕분에 우리는 여기서 한 단계 더 바라볼 수 있게 되었습니다. 이제까지 ‘데이터’라고 부르던 것은 대부분 정량적 데이터이고 GitHub, Jira, Jenkins 등 업무 용도의 툴들을 사용하는 과정에서 나오는 활동 데이터들을 예로 들 수 있으며 API 등을 통해 정량적인 방식으로 측정해낼 수 있습니다.

하지만 우리 현실세계의 데이터는 정량적으로 표현된 것만 존재하지는 않습니다. 단적인 예를 들어 한 프로젝트를 완수한 개발자의 정량적인 데이터를 우수할 수 있으나 이에 들어간 개발자의 체력으로 인한 피로와 프로젝트 진행에 대한 만족도는 알 수 없습니다. 이는 정성적인 데이터라고 할 수 있습니다. 이런 데이터들은 정량적인 방식으로 측정할 수 없습니다.

예를 들어 개발 팀이 소프트웨어의 버그를 수정하는 작업을 수행할 때, 일반적으로 버그의 수, 수정에 소요된 시간 등의 정량적 데이터가 수집됩니다. 이러한 데이터는 프로젝트의 진행 상태와 팀의 생산성을 평가하는 데 유용합니다. 하지만 이 방식은 수정 과정의 복잡성이나 개별 개발자의 창의적 해결 방법을 포착하지 못할 수 있습니다. 특히 복잡하거나 재발하는 버그를 처리하는 데 필요한 노력과 전략은 정량적 데이터만으로는 충분히 설명되지 않습니다.

그럼 정성적인 데이터는 어떻게 측정을 해야 하는가? 에 대해 의외로 뻔한 답변을 낼 수 있습니다. 개발자도 사람이고 사람은 말을 할 수 있습니다. 기본적으로 정량적인 데이터는 자동으로 수집하되 그렇지 못한 데이터들은 개발자들을 통해 직접 얻어낼 수 있다는 것입니다.

설문조사

대표적인 정성적인 측정방식으로는 설문조사가 있습니다. 이 글에서는 설문조사를 알아보겠습니다.

설문조사는 1:N의 형태로 조직이 일괄적으로 개발자에게 요청할 수도 있으며 1 on 1의 질문지로 준비할 수도 있습니다.

타당하고 신뢰할 수 있거나 좋은 심리학적 특성을 입증하는 것을 좋은 설문조사라고 합니다. 타당도는 설문조사 항목이 측정하려는 구성을 실제로 측정하는 정도입니다. 신뢰성은 설문 조사 항목이 인구 집단과 시간이 지남에 따라 일관된 결과를 생성하는 정도입니다.

실제로 설문조사를 설계해야 할 실무자에게 도움이 되는 방식 중 하나는 설문 조사 응답 프로세스를 인간의 마음 속에서 일어나는 알고리즘으로 생각하는 것입니다.

개인에게 설문조사 질문이 제시되면 응답에 도달하기 위해 일련의 정신적 단계가 이루어집니다. 아래 모델은 2012년 출간된 저서 The Psychology of Survey Response 에서 발췌한 것입니다 .

1. 설문 항목을 이해하고 페이지에 있는 “단어의 의미를 해석” 합니다.
2. 다음으로, 그들은 장기 기억에서 항목에 대응하는 데 필요한 “관련 정보를 검색” 합니다. 이 정보에는 과거 활동에 대한 구체적인 날짜나 주제에 대한 태도나 의견이 포함될 수 있습니다.
3. 다음으로, 제출자들은 정보를 판단에 “통합”하고, 경우에 따라서는 “추정”합니다. 예를 들어, 한 응답자는 작년에 얼마나 자주 헌혈을 했는지 보고할 것을 요청했고, 따라서 얼마나 자주 헌혈을 하는지에 따라 그 숫자를 추정할 필요가 있습니다. 만약 헌혈이 분기별로 실시된다면, 응답자는 작년에 헌혈한 횟수로 [4]를 추정할 수 있습니다.
4. 마지막으로, 응답자들이 답변을 염두에 둔 후에는 해당 답변을 설문조사에 보고하고 제공된 옵션에 따라 답변을 조정합니다. 위의 예에서 헌혈 빈도에 대한 응답 옵션이 [가끔] 또는 [자주]로 제시된 경우, 응답자는 자신의 대답 [4]를 가장 적절한 응답 범주로 “변환” 해야 합니다.

설문조사 응답 프로세스를 분해하고 위의 모델에 각 단계를 대응하면 입력 내용을 구체화하여 보다 인간적이고 정확한 설문조사 결과를 생성하는 데 도움이 될 수 있습니다. 좋은 설문조사 항목을 개발하려면 소프트웨어를 설계하는 과정과 마찬가지로 엄격한 설계, 테스트 및 분석이 필요합니다.

• 설문조사 항목은 주의 깊게 작성되어야 하며 모든 질문은 한 가지만 질문해야 합니다.
• 설문조사 간 결과를 비교하려면 다른 것을 측정하도록 질문 문구를 변경하는 데 주의해야 합니다.
• 문구를 변경하는 경우 엄격한 통계 테스트를 수행해야 합니다.

설문조사 피로도 방지

많은 조직은 시간이 지남에 따라 설문조사에서 높은 참여율을 유지하는 데 어려움을 겪고 있습니다. 설문조사 후 후속 조치가 늦거나 부족하면 개발자는 설문 조사에 반복적으로 응답하는 것이 가치가 없다고 느낄 수 있습니다. 따라서 리더와 팀이 설문 조사 후에 후속 조치를 취하고 의미 있는 조치를 취하는 것이 중요합니다. 대부분의 조직에서는 분기별 또는 반기 별 설문 조사 흐름을 채택하지만 회고와 같은 정기적인 팀 의식에 통합된 보다 빈번한 설문 조사를 통해서 성공하는 사례들이 나오고 있습니다.

트랜잭션 설문조사

트랜잭션 설문조사는 개발자 업무흐름의 특정 포인트나 상호 작용 중간에 자연스럽게 피드백을 수집합니다. 이는 낮은 피로감으로 솔직한 피드백을 높은 빈도로 얻을 수 있어 정기적인 설문조사의 데이터를 강화 하는데에 도움이 됩니다.

형식 없이 작성된 줄글도 가치 있습니다.

데이터를 측정하고 분석하는 과정에서 형식은 반드시 필요하지만 형식 없는 줄글 또한 놓칠 수 없습니다. 업무마찰이나 작업흐름을 설명하는 것 이외에도 개발자는 스스로 성장할 수 있는 많은 아이디어들을 은연중에 제시하며, 이러한 아이디어를 포착하고 후속 조치를 취할 수 있는 사람을 식별할 수 있습니다. 또한 설문조사에서 다루지 않은 영역을 드러낼 수도 있으며, 이는 향후 설문조사에 추가될 수도 있습니다.

상호 보완

그렇다고 성과에 대한 측정에 정성적 측정방식과 정량적 측정방식 둘 중 하나만 선택할 수 있는 것은 아닙니다. 이 둘은 각각 개발자 성과를 측정하는 보완적인 접근 방식입니다. 정량적 측정방식은 데이터 추출과 같은 방법으로 수집된 객관적이고 정확한 데이터를 제공하며 설문조사 등의 방법으로 수집된 정성적 데이터는 주관적인 인사이트와 객관적인 데이터를 동시에 포함하는 성과에 대한 전체적인 관점을 제공합니다.

이 쯤 에서 “그래서 어떻게 하라고?” 라는 생각이 들 것입니다. 먼저 각각의 측정방식이 가지는 이점을 정리하여 살펴보겠습니다.

정량적인 측정방식은 다음과 같은 이점을 가지고 있습니다.

• 정밀도: 인간은 CI/CD 빌드가 일반적으로 빠른지 느린지(즉, 지속 시간이 1분에 가까웠는지 아니면 1시간에 가까웠는지) 알 수 있지만 빌드 시간을 밀리초 단위까지 말할 수는 없습니다. 측정에 높은 수준의 정밀도가 필요할 때 정량적 측정 방식이 필요합니다.
• 빈도: 일반적으로 조직이 개발자를 대상으로 설문조사를 실시할 수 있는 빈도는 분기당 최대 1~2회입니다. 더 자주 또는 지속적으로 지표를 수집하고 싶겠지만 정성적인 측정은 그 빈도가 커질 수록 인간의 피로도로 인해 정확도가 떨어질 수 있습니다. 측정에 높은 수준의 빈도가 필요하다면 정량적 측정 방식이 필요합니다.

정성적인 측정방식은 다음과 같은 이점을 가지고 있습니다.

• 비개발지역: 개발자의 업무는 코딩과 같은 직접적인 개발 작업 뿐만 아니라 다양한 비 개발 활동을 포함합니다. 이러한 비 개발 활동은 프로젝트 관리, 회의 참석, 동료와의 커뮤니케이션, 멘토링, 기술 검토 및 문서 작성 등이 있습니다. 이 중 많은 영역에서 정량적인 측정방식으로 커버할 수도 있지만 데이터가 자동으로 축적되지 않는 영역에 대한 측정에 대해 정성적 측정 방식이 필요합니다. 예를 들어, 팀 내 소통의 효율성이나 회의의 생산성은 설문조사, 관찰, 자체 평가를 통해서 더 정확하게 이해할 수 있습니다.
• 인사이트: 개발자로부터 얻은 정성적 데이터는 그들의 개인적 경험과 주관적인 견해를 반영합니다. 이는 프로젝트의 성공 요인, 혹은 실패한 이유를 이해하는 데 중요한 역할을 합니다. 예를 들어, 개발자들이 경험한 기술적 도전, 특정 도구나 기술에 대한 만족도, 작업 접근 방식의 선호도 등은 정량적 데이터로는 파악하기 어려운 깊이 있는 정보를 제공합니다. 이러한 인사이트는 직접적인 인터뷰, 자유 형식의 피드백, 개방형 설문조사를 통해 수집되며, 이를 통해 조직은 기술 선택, 프로세스 개선, 그리고 개발 문화 조성에 있어 보다 근거 있는 인사이트를 얻을 수 있습니다.

예를 들어 협업에 대한 측정이 필요하다고 하였을 때 PR 과 코드리뷰에서 생산된 데이터, 함께한 branch 등을 추출하는 정량적인 측정방식을 사용할 수도 있지만 이것 만으로는 코드의 질이나 리뷰 과정에서의 깊이 있는 토론, 개선된 설계에 대한 가치가 옅어 질 수 있습니다.

여기에 정성적 측정방식을 보완하면, 리뷰어와 작성자 간의 상호작용, 피드백의 질, 코드 개선을 위한 논의의 깊이 등을 더 깊게 평가할 수 있습니다. 예를 들어 리뷰 프로세스 중에 수집된 피드백의 내용을 분석하여 어떤 유형의 문제가 자주 발생하는지, 특정 문제를 해결하기 위해 얼마나 많은 논의가 이루어졌는지 등을 파악할 수 있습니다.

정성적 데이터의 활용은 조직 내 의사소통을 개선하고, 직원들의 복지를 증진시키며, 조직 문화를 강화하는 데 기여합니다. 이는 궁극적으로 조직의 생산성과 효율성을 높이는 결과를 가져올 수 있습니다. 팀원들이 업무환경에서 겪는 문제점들을 식별하고, 그에 대한 솔루션을 제공하는 것이 이 데이터의 큰 장점입니다.

이러한 상호 보완된 결합은 비즈니스 인텔리전스를 심화시키고, 경쟁 우위를 확보하며, 지속 가능한 성장을 도모하는 데 필수적입니다.

적용 해보기

이렇게 정성적인 측정방식 또한 필요하다는 사실을 알게 되었으니 이제 이 측정 방식을 적용해볼 시간입니다.

조직마다의 잘하는 개발자에 대한 기준은 다릅니다. 그리고 팀마다, 프로젝트 별로도 다를 수 있습니다. 예를 들어 서비스를 개발하는 개발자와 DevOps 를 담당하는 개발자는 같은 기준으로 평가할 수 없습니다. 때문에 측정 솔루션을 도입하기 전에 조직 내 각각의 개발자들이 어떤 개발자를 목표로 했으면 좋을지를 가장 먼저 정의해야 합니다.

1. 먼저 조직의 장기적인 비전과 단기 목표를 명확히 합니다. 이는 개발자가 달성해야 할 목표와 조직 내에서 그들의 역할을 정의하는 데 도움이 됩니다.
2. 페르소나를 정의합니다. 기본적으로 조직의 인재상을 관통하는 기준은 있을 수 있지만 조직의 개발자들이 모두 같은 일을 하지 않기 때문에 각자의 역할에 맞는 기준을 덧댈 필요가 있습니다. 프로젝트나 업무에 필요한 기술 스택을 기반으로 개발자에게 요구되는 기술적 능력을 명시하고 각 개발자 역할에 대한 책임과 기대하는 성과를 구체적으로 정의합니다.
3. 이제 조직의 목표에 기여하는 데 중요한 역할을 하는 구체적인 성과 지표를 고안합니다.
4. 지표를 나타내는 백 데이터들을 정의합니다. 예를 들어 배포 빈도, 변경에 걸리는 시간, 평균 오류 복구 시간, 변경 시 실패율 과 같은 것들이 있습니다.
5. 일정 기간동안 정량적인 데이터를 측정하고, 정성적인 데이터를 더하여 지표로 나타냅니다. 이를 토대로 삼아 성과를 측정하고 평가합니다.
6. 측정된 지표를 기존 평가방식과 대조 및 만족도 조사를 통해 검증하며 수 번의 사이클을 돌아 완성합니다.

위에도 언급한 것과 같이 이는 굉장히 많은 리소스와 시간이 드는 일입니다.

마무리

조직은 본래 단기적이거나 장기적으로 발생하는 문제를 관찰하고 늦지 않게 대응할 수 있는 인력(ex. Tech Lead, Senior Engineer)에 보통의 개발자들에 비교하여 많은 비용을 투자합니다. 이는 단지 성과를 측정하고 평가하는 것을 넘어서, 더 빠른 의사 결정, 개선된 자원 배분, 그리고 전반적인 조직 효율성 향상으로 지속 가능한 성장과 발전을 도모하는 중요한 전략적 투자가 될 수 있습니다.

조직이 개발자 생산성에 대한 완전한 이해를 구축하려면 최대한 많은 정성적, 정량적 데이터를 결합해야만 합니다. 두 방식을 상호 보완하여 사용한다면 개발자의 성과를 완전히 이해하면서 정성적 및 정량적 지표의 이점을 모두 활용할 수 있을 것입니다.

개발자도 사람이다. (with Measuring Developer Productivity via Humans) was originally published in 프루퍼 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.