# 개발자 생산성 측정하기: 구글, 노션 등의 실제 사례들 > Clean Markdown view of GeekNews topic #12982. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=12982](https://news.hada.io/topic?id=12982) - GeekNews Markdown: [https://news.hada.io/topic/12982.md](https://news.hada.io/topic/12982.md) - Type: news - Author: [xguru](https://news.hada.io/@xguru) - Published: 2024-01-22T11:06:01+09:00 - Updated: 2024-01-22T11:06:01+09:00 - Original source: [newsletter.pragmaticengineer.com](https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity-bae) - Points: 53 - Comments: 1 ## Topic Body - 구글, 링크드인, 펠로톤, Amplitude, 인터컴, 노션, 포스트맨 등 17개 기술 회사들이 개발자 생산성을 측정하는 방법에 대한 심층 분석 ### 1. 17개 기술 회사의 개발자 생산성 지표 - 개발자 생산성 측정은 복잡한 문제로, 지식 기반 작업인 소프트웨어 엔지니어링에서 "생산적"이라는 것의 의미 자체가 모호함 - 개발자 생산성(DevProd) 또는 개발자 경험(DevEx) 팀이라 불리는 팀들이 개발자들이 고품질 소프트웨어를 쉽게 배포할 수 있도록 지원함 - 이들 팀은 엔지니어링 팀의 생산성과 장애 요소를 측정하고, 그들의 작업이 실제로 영향을 미치는지 추적하기 위해 *개발자 생산성 지표*가 필요함 - 이들 회사에서 사용하는 개발자 생산성 지표 - 딜리버리 용이성 (Amplitude, GoodRx, Intercom, Postman, Lattice) - 실험 속도 (Etsy) - 서비스/앱의 안정성 (DoorDash) - SPACE 지표 (Microsoft) - 엔지니어당 주간 집중 시간 (Uber) - 회사 크기별로 4가지를 선정 - Google : 직원 수 100,000명 이상 - LinkedIn : 10,000명 이상 - 펠로톤 : 1,000명 이상 10,000명 미만 - 스케일업 (엔지니어 100명 이상 1,000명 미만): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice ### 2. 구글의 접근 방식 - 구글은 개발자 생산성 측정의 모범 사례로 자주 언급되지만, 구글만큼의 투자를 모방하는 것은 대부분의 회사에게는 불가능하다는 주장도 있음 - 구글의 **Developer Intelligence 팀**은 개발자 생산성을 측정하고 리더들에게 통찰력을 제공하는 전문 부서임 - 구글은 단일 지표가 생산성을 포착하지 못한다고 믿으며, **속도, 용이성, 품질**의 세 가지 차원을 통해 생산성을 바라봄 - Speed 속도: 코드 검토가 완료되는 데 얼마나 걸리나요? - Ease 용이성: 개발자가 코드 리뷰 프로세스를 진행하는 것이 얼마나 쉽거나 어려운가요? - Quality 품질: 코드 리뷰를 통해 받은 피드백의 품질은 어느 정도인가요? - 구글은 질적 및 양적 측정을 혼합하여 지표를 계산함 ### 3. 링크드인 - 링크드인은 마이크로소프트 내에서 독립적으로 운영되며 10,000명 이상의 직원을 고용함 - 링크드인에는 개발자 생산성과 만족도를 측정하고 나머지 조직에 통찰력을 전달하는 **Developer Insights** 팀이 있음 - 링크드인은 분기별 설문조사, 실시간 피드백 시스템, 시스템 기반 지표를 사용하여 지표를 캡처함 - 분기별 설문조사: - 개발자 인사이트 팀은 분기별 설문조사를 통해 다양한 도구, 프로세스 및 활동 전반의 개발자 경험을 평가 - 설문조사에는 약 30개의 질문이 포함되어 있으며 개발자는 약 10분 이내에 답변 가능 - 설문조사는 개발자 인사이트 팀이 개발하고 관리하는 독점 플랫폼을 통해 제공되며, 실시간 피드백 및 지표 시스템에서 수집한 데이터를 기반으로 설문조사 문항을 고급 사용자 지정 및 개인화할 수 있음 - 실시간 피드백 시스템: - 분기별 설문조사 사이에 피드백을 수집하기 위해 LinkedIn은 개발자가 개발 도구 내에서 수행하는 이벤트와 작업을 추적하고 특정 트리거에 따라 대상 설문조사를 전송하는 실시간 피드백 시스템을 개발 - 이 시스템은 스마트 스로틀링 메커니즘을 사용하여 개발자에게 피드백 요청이 과도하게 몰리지 않도록 함 - 시스템 기반 지표: - LinkedIn은 또한 시스템 데이터를 사용하여 지표를 계산하여 빌드 시간 및 배포 빈도와 같은 항목에 대한 고정밀 측정치를 제공 - 개발자 인사이트 팀은 이 데이터를 수집하고 분석하기 위한 글로벌 시스템을 유지 관리하며, 이를 개발자 인사이트 허브(또는 iHub)라고 부름 - 이 시스템을 통해 LinkedIn의 모든 팀은 각자의 필요에 맞는 사용자 지정 대시보드와 메트릭을 만들 수 있음 - 링크드인은 **질적 및 양적 지표**를 모두 고려 - 개발자 순 사용자 만족도(Developer Net User Satisfaction, NSAT) :개발자가 LinkedIn의 개발 시스템에 대해 전반적으로 얼마나 만족하는지를 측정. 분기별로 측정함 - 개발자 빌드 시간(Developer Build Time, P50 및 P90): 개발자가 개발 중에 빌드가 로컬에서 완료되기를 기다리는 데 소요되는 시간을 초 단위로 측정 - 코드 검토자 응답 시간(Code Reviewer Response Time, P50 및 P90): 코드 검토자가 작성자의 각 코드 검토 업데이트에 응답하는 데 걸리는 시간(업무 시간 기준)을 측정 - 커밋 후 CI 속도(Post-Commit CI Speed, P50 및 P90): 각 커밋이 지속적 통합(CI) 파이프라인을 통과하는 데 걸리는 시간을 분 단위로 측정 - CI 결정성(CI Determinism): 테스트 결함의 반대 개념. 테스트 스위트의 결과가 오류가 아닌 유효한 결과일 가능성을 의미 - 배포 성공률(Deployment Success Rate): 프로덕션 환경으로의 배포가 얼마나 자주 성공하는지를 측정 - 윈화 된 평균(Winsorized Means): 이상값 메트릭 내에서 개선 사항을 인식하는 방법. 최고값과 최저값을 가운데에 가까운 숫자로 대체하여 계산 - 개발자 경험 지수(The Developer Experience Index): LinkedIn에서 팀에 제공하는 특별한 지표. 이 지수는 앞서 나열한 지표와 같은 여러 가지 지표를 기반으로 한 종합 점수 ### 4. 펠로톤 - 펠로톤은 약 3,000-4,000명의 직원을 고용하는 큰 회사로, 링크드인보다 훨씬 작음 - 펠로톤의 측정 접근 방식은 개발자 경험 설문조사를 통해 질적 통찰력을 얻기 시작했으며, 나중에는 정량적 지표와 함께 사용함. - 펠로톤은 **참여도, 속도, 품질, 안정성**의 네 가지 주요 영역에 초점을 맞추어 생산성을 측정함 - 참여도(Engagement): 개발자 만족도 점수 - 속도(Velocity): 모든 신입사원의 첫 번째 및 10번째 PR까지의 시간, 리드 타임, 배포 빈도 - 품질(Quality): 250라인 미만 PR의 비율, 회선 커버리지, 변경 실패율 - 안정성(Stability): 서비스 복구 시간 - 지표의 많은 부분을 측정하는 개발자 경험 설문조사는 제품 운영 조직의 일부인 Peloton의 기술 지원 및 개발자 경험 팀이 주도 - 기술 지원 및 개발자 경험 팀은 설문조사 결과를 분석하고 조직 전체의 리더와 공유하는 역할도 담당 ### 5. 스케일업 및 소규모 회사들 - 노션, 포스트맨, 암플리튜드, 굿알엑스, 인터컴, 래티스와 같은 여러 스케일업 회사들은 100명에서 1,000명의 엔지니어를 고용함 - 이들 회사는 **"이동 가능한 지표(Moveable Metrics)"** 에 초점을 맞춤 - 이동 가능한 지표는 개발자 생산성 팀이 업무에 긍정적 또는 부정적으로 영향을 미침으로써 "이동"시킬 수 있는 지표를 말함. 개발자 생산성 팀이 자신의 영향력을 보여주는 데 유용 - 공통 지표들 - 딜리버리 용이성 (Ease of Delivery, moveable): - 대부분의 회사는 개발자가 작업을 수행하는 것이 얼마나 쉬운지 또는 어렵다고 느끼는지에 대한 정성적 척도인 제공 용이성을 측정 - 여러 DevProd 리더는 팀의 목표가 개발자의 삶을 더 편하게 만드는 것이기 때문에 이 지표를 업무의 '북극성'으로 삼는다고 말함 - 이 지표는 상당히 움직일 수 있기 때문에 영향력을 보여주는 데도 유용 - 이론적 관점에서 볼 때 이 지표는 인지 부하 및 피드백 루프와 같은 개발자 경험의 주요 측면도 포착 - 참여도 (Engagement) - 개발자가 업무에 대해 얼마나 흥미를 느끼고 자극을 받는지를 측정하는 참여도를 추적 - 일반적으로 HR 참여도 설문조사에서 참여도를 측정하지만, DevProd 팀도 이러한 이유로 참여도에 집중하는 것을 꼽음 - 개발자 참여도와 생산성은 밀접한 관련이 있음. 즉, "행복한 개발자가 생산적인 개발자"라는 말이 있듯이 개발자 참여도는 생산성의 지표로 볼 수 있음 - 참여도 측정의 진정한 이점은 속도를 강조하는 다른 지표와 균형을 맞출 수 있다는 것. 소프트웨어를 더 빨리 제공하는 것은 좋지만, 개발자의 행복이 감소하는 것을 희생해서는 안 됨 - 시간 손실 (Time Loss, moveable) - GoodRx와 Postman은 평균 시간 손실량에 주목함 - 이는 작업 환경의 장애물로 인해 손실된 개발자의 시간 비율로 측정됨 - 이 지표는 개발팀의 업무에 직접적인 영향을 미칠 수 있는 이동 가능한 지표를 제공한다는 점에서 딜리버리 용이성과 유사 - 비용으로 환산할 수 있다는 점에서 큰 이점이 있고, 따라서 비즈니스 리더가 시간 손실을 쉽게 이해할 수 있음 - 예를 들어 엔지니어링 인건비가 1,000만 달러인 조직에서 이니셔티브를 통해 시간 손실을 20%에서 10%로 줄인다면 이는 100만 달러의 비용 절감으로 이어짐 - 변경 실패율 (Change Failure Rate) - 이는 DORA(DevOps Research and Assessment) 연구 프로그램의 네 가지 주요 지표 중 하나 - Amplitude와 Lattice를 비롯한 여러 회사에서 추적하는 최상위 지표 - DORA 팀은 변경 실패율을 다음과 같이 정의: > "프로덕션 또는 사용자에 대한 릴리스 변경으로 인해 서비스 저하(예: 서비스 장애 또는 서비스 중단)가 발생하고 이후 수정이 필요한 경우(예: 핫픽스, 롤백, 수정 전진, 패치 필요)의 비율" ### 6. 흥미로운 발견들 - **DORA** 및 **SPACE** 지표는 선택적으로 사용되며, 모든 회사가 질적 및 양적 측정을 모두 사용함 - DORA : DevOps Research and Assessment - SPACE : Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow - **"집중 시간"** 에 대한 큰 강조가 있으며, 스트라이프와 우버는 "충분한 집중 시간을 가진 일수"와 "엔지니어당 주간 집중 시간"과 같은 구체적인 지표를 공유함 - 독특한 지표들 - Adoption Rate (DoorDash, GoodRx, Spotify) - Design Docs Generated per Engineer (Uber) - Experiment Velocity (Etsy) - Developer CSAT/NSAT (Chime, LinkedIn) ### 7. 자신만의 지표를 선택하는 방법 - 구글의 [Goals, Signals, Metrics (GSM) 프레임워크](https://abseil.io/resources/swe-book/html/ch07.html)를 사용하여 지표 선택을 안내하는 것이 좋음 - **문제를 해결하고자 하는 목표를 먼저 정의하고, 그 목표를 달성했다는 것을 알려주는 신호를 찾은 다음, 적절한 지표를 선택함** - 목표 정의 - Google: "개발자가 빠르고 쉽게 훌륭한 제품을 제공할 수 있도록 지원합니다." - Slack: "모든 엔지니어에게 원활한 개발 환경을 제공합니다." - Stripe: "소프트웨어 엔지니어링을 더 쉽게 만듭니다." - 목표로 부터 거꾸로 작업해서 최상위 지표를 정의하기 - 개발자가 소프트웨어를 딜리버리하는 것이 얼마나 쉬운가?(Ease) : Ease of Delivery, Deployment Lead Time, Build Failure Rate - 개발자가 소프트웨어를 얼마나 빨리 딜리버리하는지 (Speed) : Perceived Delivery Speed, Perceived Productivity - 제공되는 소프트웨어의 품질 (Quality) : Incident frequency, Perceived Software Quality - 당신이 CTO, VPE, 엔지니어링 리드라면 - 가장 좋은 조언은 **"문제를 재구성 하는 것(reframe the problem)"** - 세가지 버킷에서 지표를 선택할 것 - **비즈니스 임팩트** - 지금 구축해야 하는 이유는 무엇인가요? - 이 프로젝트가 비즈니스에 어떤 방식으로 수익을 창출하거나 목표를 지원하는가? - 이 프로젝트가 순조롭게 진행되고 있나요, 아니면 지연되고 있나요? - **시스템 퍼포먼스** - 엔지니어링 시스템은 빠르고 안정적인가요? - 인프라가 안전하고 잘 유지되고 있나요? - 사용자가 사용하는 서비스에 만족하고 있나요? - **엔지니어링 효율성** - 정성적 지표와 정량적 지표를 혼합하여 측정하는 것은 모든 회사에서 공통적으로 나타나는 현상 - 각 기업이 사용하는 다양한 측정 항목에서 영감을 얻을 것 - 각 기업의 우선순위와 엔지니어링 문화에 따라 중점적으로 측정하는 항목에는 큰 차이가 있음 ## Comments ### Comment 22531 - Author: demorier - Created: 2024-01-24T13:15:38+09:00 - Points: 1 이전 맥킨지 관련 글부터 관심갖고 있었는데, 요약 및 리마인드 되어서 좋았습니다.