▲

개발자 생산성 측정하기: 구글, 노션 등의 실제 사례들

 (newsletter.pragmaticengineer.com)
53P by xguru 10달전 | favorite | 댓글 1개
  • 구글, 링크드인, 펠로톤, 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) 프레임워크를 사용하여 지표 선택을 안내하는 것이 좋음
  • 문제를 해결하고자 하는 목표를 먼저 정의하고, 그 목표를 달성했다는 것을 알려주는 신호를 찾은 다음, 적절한 지표를 선택함
    • 목표 정의
      • 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)"
    • 세가지 버킷에서 지표를 선택할 것
      • 비즈니스 임팩트
        • 지금 구축해야 하는 이유는 무엇인가요?
        • 이 프로젝트가 비즈니스에 어떤 방식으로 수익을 창출하거나 목표를 지원하는가?
        • 이 프로젝트가 순조롭게 진행되고 있나요, 아니면 지연되고 있나요?
      • 시스템 퍼포먼스
        • 엔지니어링 시스템은 빠르고 안정적인가요?
        • 인프라가 안전하고 잘 유지되고 있나요?
        • 사용자가 사용하는 서비스에 만족하고 있나요?
      • 엔지니어링 효율성
  • 정성적 지표와 정량적 지표를 혼합하여 측정하는 것은 모든 회사에서 공통적으로 나타나는 현상
    • 각 기업이 사용하는 다양한 측정 항목에서 영감을 얻을 것
    • 각 기업의 우선순위와 엔지니어링 문화에 따라 중점적으로 측정하는 항목에는 큰 차이가 있음
▲
demorier 10달전  [-]

이전 맥킨지 관련 글부터 관심갖고 있었는데, 요약 및 리마인드 되어서 좋았습니다.

답변달기