개발자 생산성 측정하기: 구글, 노션 등의 실제 사례들
(newsletter.pragmaticengineer.com)- 구글, 링크드인, 펠로톤, 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 팀은 변경 실패율을 다음과 같이 정의:
"프로덕션 또는 사용자에 대한 릴리스 변경으로 인해 서비스 저하(예: 서비스 장애 또는 서비스 중단)가 발생하고 이후 수정이 필요한 경우(예: 핫픽스, 롤백, 수정 전진, 패치 필요)의 비율"
- 딜리버리 용이성 (Ease of Delivery, moveable):
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) 프레임워크를 사용하여 지표 선택을 안내하는 것이 좋음
-
문제를 해결하고자 하는 목표를 먼저 정의하고, 그 목표를 달성했다는 것을 알려주는 신호를 찾은 다음, 적절한 지표를 선택함
- 목표 정의
- 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)"
- 세가지 버킷에서 지표를 선택할 것
-
비즈니스 임팩트
- 지금 구축해야 하는 이유는 무엇인가요?
- 이 프로젝트가 비즈니스에 어떤 방식으로 수익을 창출하거나 목표를 지원하는가?
- 이 프로젝트가 순조롭게 진행되고 있나요, 아니면 지연되고 있나요?
-
시스템 퍼포먼스
- 엔지니어링 시스템은 빠르고 안정적인가요?
- 인프라가 안전하고 잘 유지되고 있나요?
- 사용자가 사용하는 서비스에 만족하고 있나요?
- 엔지니어링 효율성
-
비즈니스 임팩트
- 정성적 지표와 정량적 지표를 혼합하여 측정하는 것은 모든 회사에서 공통적으로 나타나는 현상
- 각 기업이 사용하는 다양한 측정 항목에서 영감을 얻을 것
- 각 기업의 우선순위와 엔지니어링 문화에 따라 중점적으로 측정하는 항목에는 큰 차이가 있음