당신의 팀 생산성 지표는 아마도 쓸모없을 것입니다

만약 당신의 팀이 코드 라인 수(Lines of code)나 커밋(Commit) 횟수로 개발자 생산성을 측정하고 있다면, 당신은 잘못된 것을 측정하고 있는 것입니다. 그렇다면 대신 무엇을 살펴봐야 할까요? Making Software의 에피소드 5에서, 저는 Okta의 생산성 아키텍트(Productivity Architect)인 Dennis Henry와 이야기를 나누었습니다. Dennis는 인간 요인(Human factors) 석사 학위를 가지고 있으며, 이를 매일 소프트웨어 엔지니어링에 어떻게 적용하는지 설명해 주었습니다.

코드베이스에 적용되는 실패의 과학. 인간 요인(Human factors)은 사람들이 시스템과 어떻게 상호작용하는지, 그리고 상황이 어떻게 잘못되는지를 연구합니다. Dennis는 운영 환경의 장애(Production incidents)에서 왜 "인적 오류(Human error)"가 결코 실제 근본 원인이 될 수 없는지, 그리고 대신 무엇을 찾아야 하는지 설명합니다.

전사적 차원의 멀티 모델 AI 게이트웨이. Dennis는 모든 Okta 직원이 Anthropic, OpenAI 및 기타 모델에 안전하게 접근할 수 있는 내부 플랫폼을 구축했습니다. 이 플랫폼은 SSO(Single Sign-On) 뒤에 위치하며, PII(개인정보) 가드레일과 MCP(Model Context Protocol) 호출 감사(Auditing) 기능을 갖추고 있습니다. 그는 왜 지금 특정 벤더에 종속(Locking in)되는 것이 실수인지, 그리고 이를 어떻게 우회하여 설계(Architect)해야 하는지 설명합니다.

엔지니어링 생산성 향상. Dennis는 엔지니어들에게 끊임없이 묻습니다: "무엇이 당신을 짜증 나게 하나요? 무엇이 당신으로 하여금 키보드를 방 저편으로 던져버리고 싶게 만드나요?" 그는 행복한 사람이 최고의 소프트웨어를 만든다는 점을 강조하며, 산출물(Output)을 측정하는 것보다 정서(Sentiment)를 측정하는 것이 더 중요하다고 주장합니다.

실제로 추적해야 할 것. 코드 라인 수? 끔찍합니다. 커밋? 무의미합니다. Dennis는 신뢰성(Reliability), 버그 해결 시간(Bug resolution time), 고객 경험(Customer experience), 그리고 당신의 팀이 업무를 수행할 수 있는 도구를 갖추고 있다고 느끼는지 여부를 추적해야 한다고 주장합니다.

정량적(Quantitative) 데이터보다 정성적(Qualitative) 데이터. 생산성은 사람들에게서 더 많은 산출물을 짜내는 것이 아닙니다. 의미 있는 업무를 방해하는 요소들을 제거하는 것입니다.

당신이 팀에서 본 최악의 생산성 지표는 무엇인가요? 댓글로 알려주세요! 전체 에피소드는 YouTube에서 들을 수 있습니다. 읽어주셔서 감사합니다! 👋